Isu-isu desain - mengirim data kecil segmen atas TCP dengan Winsock

Ketika Anda perlu mengirim paket data kecil atas TCP, desain aplikasi Winsock Anda terutama penting. Desain yang tidak memperhitungkan interaksi pengakuan tertunda, tiba algoritma dan Winsock buffer dapat secara drastis mempengaruhi kinerja. Artikel ini membahas isu-isu ini, menggunakan beberapa kasus studi, dan berasal dari rekomendasi untuk mengirimkan paket-paket data kecil efisien dari aplikasi Winsock serangkaian.

Latar belakang

Ketika setumpuk Microsoft TCP menerima paket data, waktu tunda 200-ms pergi. Ketika ACK akhirnya dikirim, waktu tunda reset dan akan memulai lain 200-ms menunda ketika paket data berikutnya yang diterima. Untuk meningkatkan efisiensi di Internet dan aplikasi intranet, Microsoft TCP tumpukan menggunakan kriteria berikut untuk memutuskan kapan untuk mengirim satu ACK pada paket data yang diterima:

• Jika kedua paket data yang diterima sebelum waktu tunda berakhir, ACK dikirim.
• Jika ada data untuk dikirim ke arah yang sama sebagai ACK sebelum paket data kedua yang diterima dan waktu tunda berakhir, ACK piggybacked dengan segmen data dan dikirim segera.
• Ketika waktu tunda berakhir, ACK dikirim.

Untuk menghindari paket data kecil yang congest jaringan, Microsoft TCP tumpukan memungkinkan algoritma tiba secara default, yang coalesces buffer data kecil dari beberapa Kirim panggilan dan penundaan mengirim sampai ACK untuk paket data sebelumnya dikirim yang diterima dari remote host. Berikut adalah dua pengecualian tiba algoritma:

• Jika tumpukan telah menyatu data buffer yang lebih besar daripada Unit transmisi maksimum (MTU), berukuran penuh paket dikirim segera tanpa menunggu ACK dari remote host. Pada jaringan Ethernet, MTU menawarkan adalah 1460 byte.
• TCP_NODELAY soket pilihan diterapkan untuk menonaktifkan algoritma tiba sehingga paket kecil data dikirim ke host jauh tanpa penundaan.

Untuk mengoptimalkan kinerja pada lapisan aplikasi, Winsock salinan data buffer dari aplikasi mengirim panggilan ke Winsock kernel buffer. Kemudian, tumpukan menggunakan heuristik sendiri (seperti tiba algoritma) untuk menentukan kapan harus benar-benar menempatkan paket pada kabel. Anda dapat mengubah jumlah Winsock kernel buffer dialokasikan ke soket menggunakan pilihan SO_SNDBUF (it's 8 K secara default). Jika perlu, Winsock dapat penyangga secara signifikan lebih dari SO_SNDBUF penyangga ukuran. Dalam kebanyakan kasus, kirim selesai pada aplikasi hanya menunjukkan data buffer dalam aplikasi mengirim panggilan disalin ke Winsock kernel buffer dan tidak menunjukkan bahwa data telah mencapai jaringan media. Satu-satunya pengecualian adalah ketika Anda menonaktifkan buffer Winsock dengan menetapkan SO_SNDBUF ke 0.

Winsock menggunakan aturan berikut untuk menunjukkan penyelesaian kirim ke aplikasi (tergantung pada bagaimana Kirim dipanggil, pemberitahuan penyelesaian dapat fungsi kembali dari Pemblokiran panggilan, menandakan suatu peristiwa atau memanggil fungsi pemberitahuan, dan sebagainya):

• Jika soket masih dalam SO_SNDBUF kuota, Winsock salinan data dari Kirim aplikasi dan menunjukkan penyelesaian kirim ke aplikasi.
• Jika soket adalah di luar kuota SO_SNDBUF dan hanya satu sebelumnya buffered Kirim masih di stack kernel buffer, Winsock menyalin data dari Kirim aplikasi dan menunjukkan penyelesaian kirim ke aplikasi.
• Jika soket luar kuota SO_SNDBUF dan ada lebih dari satu sebelumnya buffered mengirim di stack kernel buffer, Winsock salinan data dari Kirim aplikasi. Winsock tidak menunjukkan penyelesaian kirim ke aplikasi sampai tumpukan selesai mengirim cukup untuk menempatkan soket kembali dalam SO_SNDBUF kuota atau hanya satu syarat Kirim luar biasa.

Studi kasus 1

Ikhtisar:

Kebutuhan Winsock TCP klien untuk mengirim catatan 10000 Winsock TCP server untuk menyimpan dalam database. Ukuran catatan bervariasi dari 20 bytes 100 byte yang panjang. Untuk menyederhanakan logika aplikasi, desain adalah sebagai berikut:

• Klien Apakah memblokir kirim hanya. Server tidak menghalangi recv hanya.
• Soket klien menetapkan SO_SNDBUF 0 sehingga setiap record keluar dalam data satu segmen.
• Server panggilan recv dalam lingkaran. Penyangga posted in recv adalah 200 byte sehingga setiap record dapat diterima dalam satu recv panggilan.

Kinerja:

Selama pengujian, pengembang menemukan klien hanya bisa mengirim catatan lima per detik ke server. Total 10000 catatan, maksimum pada 976 K bytes of data (10000 * 100 / 1024), mengambil lebih dari setengah jam untuk mengirim ke server.

Analisis:

Karena klien tidak menetapkan pilihan TCP_NODELAY, algoritma tiba memaksa TCP tumpukan untuk menunggu ACK sebelum itu dapat mengirim paket lain pada kabel. Namun, klien telah dinonaktifkan Winsock buffer dengan menetapkan pilihan SO_SNDBUF ke 0. Oleh karena itu, 10000 Kirim panggilan harus dikirim dan ACK'ed secara individual. ACK masing-masing adalah 200-ms tertunda karena berikut terjadi pada server TCP tumpukan:

• Ketika server mendapat paket, yang waktu tunda 200-ms pergi.
• Server tidak perlu mengirim sesuatu kembali, sehingga ACK tidak dapat piggybacked.
• Klien tidak akan mengirim paket lain kecuali paket sebelumnya yang diakui.
• Waktu tunda di server berakhir dan ACK dikirim kembali.

Bagaimana untuk meningkatkan:

Ada dua masalah dengan desain ini. Pertama, ada masalah waktu penundaan. Klien harus dapat untuk mengirim dua paket ke server dalam 200-MS karena klien menggunakan algoritma tiba secara default, itu harus hanya menggunakan default Winsock buffer dan tidak mengatur SO_SNDBUF ke 0. Setelah tumpukan TCP telah menyatu buffer yang lebih besar daripada Unit transmisi maksimum (MTU), berukuran penuh paket dikirim segera tanpa menunggu ACK dari remote host.

Kedua, desain ini panggilan mengirim satu untuk setiap record seperti ukuran kecil. Mengirimkan ini kecil ukuran ini tidak sangat efisien. Dalam kasus ini, pengembang mungkin ingin pad setiap record untuk 100 byte dan mengirim catatan 80 pada waktu dari satu klien mengirim panggilan. Untuk membiarkan server yang tahu berapa banyak catatan akan dikirim secara total, klien mungkin ingin memulai komunikasi dengan memperbaiki berukuran header yang berisi jumlah record untuk mengikuti.

Studi kasus 2

Ikhtisar:

Aplikasi klien Winsock TCP membuka dua koneksi dengan aplikasi server Winsock TCP yang menyediakan layanan saham. Sambungan pertama digunakan sebagai saluran perintah untuk mengirim simbol saham ke server. Koneksi kedua digunakan sebagai saluran data untuk menerima penawaran saham. Setelah dua sambungan telah dibentuk, klien mengirimkan simbol saham ke server melalui saluran perintah dan menunggu Penawaran saham kembali melalui saluran data. Mengirim permintaan simbol saham berikutnya ke server hanya setelah Penawaran saham pertama telah diterima. Klien dan server tidak mengatur opsi SO_SNDBUF dan TCP_NODELAY.

Kinerja:

Selama pengujian, pengembang menemukan klien hanya bisa mengutip lima per detik.

Analisis:

Desain ini hanya memungkinkan satu permintaan penawaran saham biasa pada satu waktu. Simbol saham pertama dikirim ke server melalui saluran perintah (sambungan) dan respon segera dikirim kembali dari server untuk klien melalui saluran data (sambungan). Kemudian, klien segera mengirimkan permintaan simbol saham kedua dan kirim kembali segera sebagai penyangga permintaan dalam panggilan mengirim disalin ke Winsock kernel buffer. Namun, tumpukan TCP klien tidak dapat mengirim permintaan dari kernel buffer segera karena pertama mengirim lebih dari saluran perintah tidak diakui lagi. Setelah 200-ms menunda timer pada server perintah saluran berakhir, ACK untuk permintaan simbol pertama datang kembali ke klien. Kemudian, permintaan penawaran kedua berhasil dikirim ke server setelah terlambat untuk 200-MS penawaran untuk simbol saham kedua datang kembali segera melalui saluran data karena, pada saat ini, waktu tunda pada saluran data klien telah kedaluwarsa. ACK untuk respon kutipan sebelumnya yang diterima oleh server. (Ingat bahwa klien tidak dapat mengirim permintaan penawaran saham kedua untuk 200-ms, sehingga memberikan waktu untuk waktu tunda pada klien untuk berakhir dan mengirim ACK ke server.) Sebagai hasilnya, klien mendapatkan respon kutipan kedua dan dapat mengeluarkan permintaan penawaran lain, yang tunduk pada siklus yang sama.

Bagaimana untuk meningkatkan:

Desain dua koneksi (saluran) tidak perlu di sini. Jika Anda menggunakan hanya satu sambungan untuk penawaran saham permintaan dan tanggapan, ACK untuk permintaan penawaran dapat piggybacked pada respon kutipan dan kembali segera. Untuk lebih meningkatkan kinerja, klien bisa "membuat" beberapa permintaan penawaran saham ke dalam satu panggilan kirim ke server dan server dapat juga "membuat" beberapa kutipan tanggapan ke satu Kirim panggilan kepada klien. Jika dua saluran unidirectional desain benar-benar perlu untuk beberapa alasan, kedua belah pihak harus menyetel opsi TCP_NODELAY sehingga paket-paket kecil dapat dikirim langsung tanpa harus menunggu ACK untuk paket sebelumnya.

Rekomendasi:

Sementara ini studi kasus dua fabrikasi, mereka membantu untuk menggambarkan beberapa skenario kasus yang terburuk. Ketika Anda merancang aplikasi yang melibatkan data kecil yang luas segmen mengirim dan recvs, Anda harus mempertimbangkan panduan berikut:

• Jika data segmen yang tidak waktu kritis, aplikasi harus bergabung mereka ke dalam blok data yang besar untuk lulus untuk mengirim panggilan. Karena buffer Kirim mungkin akan disalin ke Winsock kernel buffer, buffer tidak boleh terlalu besar. Sedikit kurang dari 8 K biasanya efektif. Selama Winsock kernel mendapatkan sebuah blok lebih besar daripada MTU, itu akan mengirimkan paket multiple berukuran penuh dan paket terakhir dengan apa pun yang tersisa. Pengiriman sisi, kecuali paket terakhir, tidak akan memukul oleh 200-ms waktu tunda. Paket terakhir, jika itu terjadi menjadi ganjil paket, adalah masih tunduk pada algoritma pengakuan tertunda. Jika tumpukan akhir pengiriman mendapat blok lain yang lebih besar daripada MTU, itu masih dapat melewati algoritma tiba.
• Jika mungkin, menghindari soket koneksi dengan arus searah data. Komunikasi atas unidirectional soket adalah lebih mudah dipengaruhi oleh tiba dan tertunda pengakuan algoritma. Jika komunikasi berikut permintaan dan respons aliran, Anda harus menggunakan soket tunggal untuk melakukan mengirim dan recvs sehingga ACK dapat piggybacked pada respon.
• Jika semua segmen kecil data harus segera dikirim, menyetel opsi TCP_NODELAY pada akhir pengiriman.
• Kecuali jika Anda ingin untuk menjamin paket Dikirim pada kabel saat penyelesaian kirim yang ditunjukkan oleh Winsock, Anda tidak harus mengatur SO_SNDBUF ke nol. Pada kenyataannya, standar 8 K buffer heuristically telah bertekad untuk bekerja dengan baik untuk kebanyakan situasi dan Anda harus tidak mengubah itu kecuali Anda telah diuji pengaturan buffer Winsock baru memberikan performa yang lebih baik daripada default. Juga, menetapkan SO_SNDBUF ke nol sangat bermanfaat untuk aplikasi yang massal data transfer. Bahkan kemudian, untuk efisiensi maksimum Anda harus menggunakannya dalam hubungannya dengan double buffer (lebih dari satu mengirim posisi pada waktu tertentu) dan tumpang tindih I/O.
• Jika pengiriman data tidak harus dijamin, menggunakan UDP.

Untuk informasi lebih lanjut tentang tertunda pengakuan dan algoritma tiba, silakan lihat berikut:

Braden, R. [1989], RFC 1122, persyaratan untuk Internet host--komunikasi lapisan, Internet Engineering Task Force.