Masalah khusus TCP/IP
Teknik pemrograman tertentu mengalami masalah performa yang terkait dengan implementasi TCP/IP. Masalah performa tersebut tidak menunjukkan bahwa TCP/IP tidak efisien atau penyempitan performa; sebaliknya, masalah ini terlihat ketika operasi TCP/IP tidak dipahami.
Masalah berikut mengidentifikasi skenario umum di mana kombinasi operasi TCP/IP dan pilihan pengembangan aplikasi jaringan menghasilkan performa yang buruk.
Aplikasi Connect-heavy.
Beberapa aplikasi membuat instans koneksi TCP baru untuk setiap transaksi. Pembentukan koneksi TCP membutuhkan waktu, berkontribusi pada RTT tambahan, dan tunduk pada permulaan yang lambat. Selain itu, koneksi tertutup tunduk pada TIME-WAIT, yang menggunakan sumber daya sistem.
Aplikasi connect-heavy sebagian besar umumnya karena mudah dibuat; pengujian dan penanganan kesalahan sangat sederhana. Mendeteksi kesalahan pada koneksi persisten dapat memakan kode dan upaya yang cukup besar, dan oleh karena itu terkadang tidak selesai.
Perbaiki situasi ini dengan menggunakan kembali koneksi TCP. Ini dapat menyebabkan serialisasi melalui koneksi TCP kecuali transaksi di-multipleks melalui beberapa koneksi. Jika pendekatan ini diambil, jumlah koneksi harus dibatasi hingga dua, dan pembingkaian lapisan aplikasi dan penanganan kesalahan tingkat lanjut diperlukan.
Buffer Kirim dan Pemblokiran Pengiriman dengan panjang nol.
Menonaktifkan buffering dengan menggunakan fungsi setsockopt untuk mengatur buffer kirim (SO_SNDBUF) ke nol mirip dengan menonaktifkan penembolokan disk. Saat mengatur buffer kirim ke nol dan menerbitkan pengiriman pemblokiran, aplikasi memiliki peluang lima puluh persen untuk mencapai pengakuan tertunda 200 milidetik.
Jangan nonaktifkan kirim buffering kecuali Anda telah mempertimbangkan dampaknya di semua lingkungan jaringan. Satu pengecualian: streaming data menggunakan I/O yang tumpang tindih harus mengatur buffer kirim ke nol.
Model pemrograman Kirim-Kirim-Terima.
Menyusun aplikasi untuk melakukan send-send-receives meningkatkan kemungkinan Anda menghadapi Algoritma Nagle, yang menyebabkan penundaan RTT+200 ms. Algoritma Nagle dapat ditemui jika pengiriman terakhir kurang dari Ukuran Segmen Maksimum TCP (MSS, data maksimum dalam satu datagram). MSS bisa menjadi nilai yang sangat besar (64K di IPv4, dan bahkan lebih besar di IPv6), jadi jangan mengandalkan MSS yang biasanya kecil. Opsi yang lebih baik adalah menggabungkan keduanya mengirim ke dalam satu pengiriman menggunakan fungsi WSASend atau memcpy .
Sejumlah Besar Koneksi Simultan.
Koneksi bersamaan tidak boleh melebihi dua, kecuali dalam aplikasi tujuan khusus. Melebihi dua koneksi bersamaan menghasilkan sumber daya yang terbuang sia-sia. Aturan yang baik adalah memiliki hingga empat koneksi berumur pendek, atau dua koneksi persisten per tujuan.
Topik terkait