Anda sedang offline saat ini, menunggu internet Anda untuk menyambung kembali

Masalah desain - mengirim data kecil segmen melalui TCP dengan Winsock

PENTING: Artikel ini diterjemahkan oleh perangkat lunak penerjemahan mesin Microsoft, dan mungkin telah diedit oleh Masyarakat Microsoft melalui teknologi CTF dan bukan oleh seorang penerjemah profesional. Microsoft menawarkan baik artikel yang diterjemahkan oleh manusia maupun artikel hasil editan terjemahan oleh mesin/komunitas, sehingga Anda dapat mengakses semua artikel di Sentra Pengetahuan yang kami miliki dalam berbagai bahasa. Namun artikel hasil editan mesin atau bahkan komunitas tidak selalu sempurna. Artikel ini dapat mengandung kesalahan dalam hal kosa kata, sintaksis atau tatabahasa, sangat mirip dengan penutur asing yang membuat kekeliruan ketika berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab atas ketidakakuratan, kesalahan atau kerugian apa pun akibat dari kekeliruan dalam penerjemahan isi atau penggunaannya oleh pelanggan kami. Microsoft juga akan senantiasa memperbarui perangkat lunak penerjemahan mesin dan alat untuk menyempurnakan Editan Hasil Penerjemahan Mesin.

Klik disini untuk melihat versi Inggris dari artikel ini: 214397
Ringkasan
Apabila Anda ingin mengirim paket data kecil melalui TCP, desain aplikasi Winsock ini sangat penting. Desain yang tidak memperhitungkan interaksi pengakuan tertunda, Nagle algoritma dan Winsock buffer secara drastis dapat mempengaruhi kinerja. Artikel ini membahas masalah ini, menggunakan beberapa kajian kasus, dan berasal serangkaian rekomendasi untuk mengirim paket data kecil efisien dari aplikasi Winsock.
Informasi lebih lanjut

Latar belakang

Ketika kehabisan memori Microsoft TCP menerima paket data, waktu tunda 200-ms berbunyi. Ketika ACK akhirnya mengirim, waktu tunda reset dan akan memulai lain 200-ms penundaan saat paket data berikutnya yang diterima.Untuk meningkatkan efisiensi Internet dan aplikasi intranet, tumpukan Microsoft TCP menggunakan kriteria berikut ini untuk menentukan ketika untuk mengirim satu ACK pada paket menerima data:
  • Jika paket data kedua 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 kedaluwarsa, ACK piggybacked dengan data segmen dan segera dikirim.
  • Saat waktu tunda berakhir, ACK dikirim.
Untuk menghindari paket data kecil Spun jaringan, tumpukan Microsoft TCP memungkinkan algoritma Nagle secara asali, yang coalesces buffer data kecil dari beberapa kirim panggilan dan penundaan mengirim hingga dikirim ACK untuk paket data sebelumnya yang diterima dari host jauh. Berikut adalah dua pengecualian algoritma Nagle:
  • Jika kehabisan memori telah bersatu buffer data yang lebih besar daripada Unit transmisi maksimum (MTU), paket berukuran penuh yang dikirim segera tanpa menunggu ACK dari host jauh. Di jaringan Ethernet, MTU untuk TCP/IP adalah 1460 byte.
  • Opsi soket TCP_NODELAY diterapkan untuk menonaktifkan algoritma Nagle sehingga paket kecil data yang dikirim ke host jauh tanpa penundaan.
Untuk mengoptimalkan kinerja pada lapisan aplikasi, Winsock kopi karbon data buffer dari aplikasi mengirim panggilan ke Winsock kernel buffer. Kemudian, tumpukan menggunakan sendiri heuristik (seperti Nagle algoritma) untuk menentukan kapan harus benar-benar menempatkan paket pada kabel. Anda dapat mengubah jumlah buffer kernel Winsock dialokasikan untuk soket menggunakan opsi SO_SNDBUF (ini adalah 8K secara asali). Bila perlu, Winsock dapat buffer jauh lebih SO_SNDBUF buffer ukuran. Dalam kebanyakan kasus, kirim penyelesaian di aplikasi hanya menunjukkan buffer data pada aplikasi mengirim panggilan disalin ke Winsock kernel buffer dan tidak menunjukkan bahwa data yang telah mencapai media jaringan. Satu-satunya pengecualian adalah apabila Anda menonaktifkan buffer Winsock dengan mengatur SO_SNDBUF ke 0.

Winsock menggunakan aturan berikut untuk menunjukkan kirim penyelesaian untuk aplikasi (tergantung pada bagaimana kirim dipanggil, pemberitahuan penyelesaian dapat fungsi kembali dari panggilan pemblokiran, menandakan peristiwa atau memanggil fungsi pemberitahuan, dan sebagainya):
  • Jika soket masih dalam SO_SNDBUF kuota, Winsock menyalin data dari kirim aplikasi dan menunjukkan penyelesaian kirim ke aplikasi.
  • Jika soket luar SO_SNDBUF kuota dan ada hanya satu sebelumnya buffer kirim masih dalam kehabisan memori kernel buffer, Winsock menyalin data dari kirim aplikasi dan menunjukkan penyelesaian kirim ke aplikasi.
  • Jika soket luar SO_SNDBUF kuota dan ada lebih dari satu sebelumnya buffer mengirimkan buffer kehabisan memori kernel, Winsock menyalin data dari kirim aplikasi. Winsock tidak menunjukkan penyelesaian kirim ke aplikasi hingga tumpukan selesai mengirim cukup untuk menempatkan soket kembali dalam SO_SNDBUF kuota atau hanya satu kondisi kirim biasa.

Kasus penelitian 1

Ikhtisar:

Winsock TCP klien harus mengirim 10000 data ke server Winsock TCP untuk menyimpan dalam database. Ukuran data bervariasi dari 20 byte 100 byte lama. Untuk menyederhanakan logika aplikasi, desain adalah sebagai berikut:
  • Klien melakukan memblokir pengiriman hanya. Server tidak memblokir recv saja.
  • Soket klien menetapkan SO_SNDBUF 0 sehingga setiap kumpulan dokumen keluar di segmen data tunggal.
  • Server panggilan recv di sebuah loop. Buffer yang dikirim dalam recv adalah 200 byte sehingga setiap kumpulan dokumen dapat diterima dalam satu recv panggilan.

Kinerja:

Selama pengujian, pengembang menemukan klien hanya dapat mengirimkan lima catatan per detik untuk server. Catatan 10000 total, maksimum 976K bytes data (10000 * 100 / 1024), memerlukan waktu lebih dari satu jam untuk mengirim ke server.

Analisis:

Karena klien tidak menetapkan opsi TCP_NODELAY, algoritma Nagle memaksa tumpukan TCP untuk menunggu ACK sebelum dapat mengirim paket lain pada kabel. Namun, klien telah dinonaktifkan Winsock buffer dengan menetapkan opsi SO_SNDBUF ke 0. Oleh karena itu, 10000 mengirim panggilan harus dikirim dan ACK'ed secara individual. Setiap ACK adalah 200-ms tertunda karena berikut ini terjadi pada server TCP memori:
  • Ketika server paket, waktu tunda 200-ms yang berbunyi.
  • Server tidak harus mengirim sesuatu kembali, sehingga ACK tidak piggybacked.
  • Klien tidak akan mengirim paket lain kecuali paket sebelumnya mengakui.
  • Waktu tunda di server berakhir dan ACK dikirim kembali.

Cara memperbaiki:

Ada dua masalah dengan desain ini. Pertama, ada penundaan timer masalah. Klien harus dapat mengirimkan dua paket ke server dalam 200-ms. karena klien menggunakan algoritma Nagle secara asali, harus hanya menggunakan default Winsock buffer dan tidak ditetapkan SO_SNDBUF ke 0. Setelah tumpukan TCP telah bersatu buffer yang lebih besar daripada Unit transmisi maksimum (MTU), paket berukuran penuh yang dikirim segera tanpa menunggu ACK dari host jauh.

Kedua, desain ini panggilan mengirim satu untuk setiap kumpulan dokumen tersebut berukuran kecil. Mengirim ini kecil dari ukuran yang sangat tidak efisien. Dalam hal ini, pengembang dapat pad setiap kumpulan dokumen ke 100 byte dan mengirim 80 data pada waktu dari satu klien mengirim panggilan. Untuk memberi tahu berapa banyak data akan dikirim Total server, klien mungkin ingin memulai komunikasi dengan judul berukuran perbaikan yang mengandung jumlah data untuk mengikuti.

Kasus penelitian 2

Ikhtisar:

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

Kinerja:

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

Analisis:

Desain ini hanya memungkinkan satu posisi saham Penawaran permintaan bersamaan. Simbol saham pertama dikirim ke server melalui saluran perintah (koneksi) dan respons segera dikirim kembali dari server ke klien melalui saluran data (koneksi). Kemudian, klien akan segera mengirimkan permintaan simbol saham kedua dan kirim Segera Kembali sebagai buffer permintaan panggilan kirim disalin ke Winsock kernel buffer. Namun, tumpukan TCP klien tidak dapat mengirim permintaan dari buffer kernel dengan segera karena pertama mengirim melalui saluran perintah tidak mengakui belum. Setelah 200-ms menunda timer saluran perintah server berakhir, ACK untuk permintaan simbol pertama kembali kepada klien. Kemudian, permintaan penawaran kedua berhasil dikirim ke server setelah penundaan untuk 200-ms. kutipan untuk kedua simbol saham kembali segera melalui saluran data karena saat ini, waktu tunda di saluran data klien telah kedaluwarsa. ACK untuk respons kutipan sebelumnya diterima oleh server. (Ingat bahwa klien tidak dapat mengirimkan permintaan penawaran saham kedua untuk 200-ms, sehingga memberikan waktu untuk waktu tunda di klien kedaluwarsa dan mengirim ACK ke server.) Akibatnya, klien mendapatkan respons kutipan kedua dan dapat masalah permintaan penawaran lain yang dapat Lingkaran Berkelanjutan yang sama.

Cara memperbaiki:

Desain dua koneksi (saluran) tidak perlu di sini. Jika Anda menggunakan hanya satu sambungan penawaran harga saham dan respons, ACK untuk permintaan penawaran dapat piggybacked pada respons kutipan dan kembali segera. Untuk lebih meningkatkan kinerja, klien dapat "multipleks" beberapa permintaan harga saham ke satu panggilan kirim ke server dan server dapat juga "multipleks" beberapa penawaran respons ke satu kirim panggilan kepada klien. Jika saluran searah dua desain benar-benar diperlukan untuk beberapa alasan, kedua sisi harus menetapkan opsi TCP_NODELAY sehingga paket kecil dapat dikirim segera tanpa harus menunggu ACK untuk paket sebelumnya.

Rekomendasi:

Saat ini kasus dua palsu, mereka membantu untuk menggambarkan beberapa skenario kasus terburuk. Ketika Anda merancang aplikasi yang melibatkan ekstensif kecil data segmen mengirimkan dan recvs, Anda harus mempertimbangkan pedoman berikut:
  • Jika data segmen yang tidak waktu penting, aplikasi harus bersatu mereka ke dalam blok data yang lebih besar untuk melewati panggilan kirim. Karena buffer kirim mungkin akan disalin ke Winsock kernel buffer, buffer tidak boleh terlalu besar. Sedikit kurang dari 8K ini biasanya efektif. Selama Winsock kernel mendapat blok yang lebih besar daripada MTU, itu akan mengirim beberapa paket berukuran penuh dan paket terakhir dengan apa pun yang tersisa. Sisi pengiriman, kecuali paket terakhir, tidak akan terkena waktu tunda 200-ms. Paket terakhir, hal itu terjadi menjadi sebuah paket ganjil, Apakah masih dapat tertunda pengakuan algoritma. Jika tumpukan akhir pengiriman mendapat blok lain lebih besar daripada MTU, itu masih dapat bypass algoritma Nagle.
  • Jika mungkin, Hindari soket sambungan dengan alur data searah. Komunikasi melalui searah soket yang lebih mudah dipengaruhi oleh Nagle dan tertunda pengakuan algoritma. Jika komunikasi berikut permintaan dan aliran respons, Anda harus menggunakan soket tunggal untuk melakukan pengiriman dan recvs sehingga ACK dapat piggybacked pada respons.
  • Jika semua data kecil segmen harus segera dikirim, menetapkan opsi TCP_NODELAY di akhir pengiriman.
  • Kecuali jika Anda ingin menjamin paket yang dikirim pada kabel saat penyelesaian kirim ditunjukkan dengan Winsock, Anda tidak harus menetapkan SO_SNDBUF ke nol. Pada kenyataannya, default 8K buffer heuristically telah ditentukan untuk bekerja dengan baik untuk sebagian besar situasi dan Anda tidak dapat mengganti itu kecuali jika Anda telah diuji bahwa pengaturan buffer Winsock baru memberikan kinerja yang lebih baik daripada default. Selain itu, pengaturan SO_SNDBUF ke nol sebagian besar bermanfaat untuk aplikasi yang massal transfer data. Kemudian, maksimum efisiensi Anda harus menggunakan bersamaan dengan double buffer (lebih dari satu kirim biasa pada waktu tertentu) dan tumpang tindih I/O.
  • Jika pengiriman data tidak harus dijamin, menggunakan UDP.
Referensi
Untuk informasi lebih lanjut tentang pengakuan tertunda dan algoritma Nagle, lihat berikut ini:

Braden, R. [1989], RFC 1122, persyaratan untuk Internet tuan rumah--lapisan komunikasi, Internet Engineering tugas Force.

Peringatan: Artikel ini telah diterjemahkan secara otomatis

Properti

ID Artikel: 214397 - Tinjauan Terakhir: 03/14/2015 06:51:00 - Revisi: 3.0

  • kbdswnet2003swept kbapi kbinfo kbip kbnetwork kbwinsock kbmt KB214397 KbMtid
Tanggapan
dy> var varAutoFirePV = 1; var varClickTracking = 1; var varCustomerTracking = 1; var Route = "76500"; var Ctrl = ""; document.write("