Penggunaan Berkelanjutan Opsi TCP_NODELAY

Pentingnya pengaturan TCP_NODELAY

• Saat men-debug masalah latensi di sistem terdistribusi, hal pertama yang perlu diperiksa adalah apakah opsi TCP_NODELAY diaktifkan
• Banyak pengembang sistem terdistribusi punya pengalaman menyelesaikan masalah latensi dengan cepat hanya dengan mengaktifkan opsi socket sederhana ini
• Ini mengisyaratkan bahwa perilaku default mungkin keliru atau keseluruhan konsepnya sudah usang

Latar belakang dan masalah pada algoritma Nagle

• Algoritma Nagle, yang pertama kali diusulkan dalam RFC896 oleh John Nagle pada 1984, bertujuan memperoleh throughput jaringan yang lebih baik dengan mengamortisasi biaya header TCP secara lebih efisien
• Algoritma Nagle bekerja dengan menahan pengiriman segmen TCP baru jika belum menerima acknowledgment untuk data yang sebelumnya dikirim
• Namun, hal ini menimbulkan masalah saat berinteraksi dengan delayed ACK
  • Algoritma Nagle memblokir pengiriman data tambahan sampai ACK diterima, sementara delayed ACK menunda ACK sampai respons siap
  • Ini bagus untuk memenuhi paket, tetapi tidak cocok untuk aplikasi pipeline yang sensitif terhadap latensi

Kebutuhan algoritma Nagle di sistem modern

• Server modern dapat melakukan pekerjaan dalam jumlah besar dalam ratusan mikrodetik, sehingga menunda pengiriman data bahkan selama satu RTT mungkin tidak memberikan manfaat yang jelas
• Sebagian besar database dan sistem terdistribusi tidak mengirim paket satu byte
  • Ini karena data yang dikirim lebih banyak, serta adanya overhead protokol seperti TLS dan overhead encoding serta serialisasi
• Tetap penting untuk tidak mengirim pesan kecil, tetapi hal ini kini ditangani secara efektif di lapisan aplikasi

Pandangan tentang penggunaan TCP_NODELAY

• Saat membangun sistem terdistribusi yang sensitif terhadap latensi, tidak masalah mengaktifkan TCP_NODELAY (menonaktifkan algoritma Nagle) tanpa banyak khawatir
• Di sistem modern, dengan mempertimbangkan trafik, campuran aplikasi, dan performa perangkat keras, algoritma Nagle mungkin tidak lagi diperlukan
  • Artinya, TCP_NODELAY seharusnya menjadi nilai default
  • Ini mungkin membuat sebagian kode "write setiap byte" menjadi lebih lambat, tetapi jika efisiensi penting maka aplikasi tersebut memang harus diperbaiki

Pendapat GN⁺

• Masalah interaksi antara algoritma Nagle dan delayed ACK adalah contoh yang baik tentang betapa sulitnya desain protokol. Situasi ketika dua fitur yang sama-sama masuk akal menghasilkan perilaku tak terduga akan terasa akrab bagi para perancang sistem.

• Mengoptimalkan pengiriman pesan kecil di lapisan aplikasi adalah tren yang umum. Penting untuk meminimalkan overhead yang tidak perlu melalui encoding dan serialisasi yang efisien.

• Jika tujuan algoritma Nagle adalah optimalisasi bandwidth jaringan, maka saat ini meminimalkan latensi menjadi kebutuhan yang lebih penting. Dalam situasi ketika responsivitas aplikasi langsung memengaruhi pengalaman pengguna, penundaan yang tidak perlu harus dihindari.

• Namun, menjadikan TCP_NODELAY sebagai default mungkin tidak ideal untuk semua situasi. Dalam lingkungan dengan bandwidth terbatas, atau pada sistem yang efisiensi transmisinya jauh lebih penting daripada latensi, algoritma Nagle mungkin tetap perlu digunakan secara selektif.

• Saat merancang protokol jaringan, penting untuk menyeimbangkan berbagai kebutuhan. Mengubah perilaku default protokol umum perlu dilakukan dengan hati-hati, tetapi fleksibilitas untuk memilih opsi yang sesuai dengan kebutuhan aplikasi juga tampaknya diperlukan.

[GN⁺]

Komentar Hacker News

Ringkasan:

• Algoritme Nagle adalah upaya untuk melakukan penulisan secara batch, dan ada kasus di mana penulisan batch lebih baik terlepas dari perangkat keras, jaringan, aplikasi, maupun kasus penggunaannya
• Banyak komputasi modern saat ini menggunakan penulisan batch, dan protokol tingkat tinggi yang lebih baru seperti QUIC juga melakukan batching penulisan dengan memindahkan penanganan koneksi dan kesalahan TCP yang sebelumnya independen ke ruang pengguna
• Ketika jaringan menjadi jenuh, algoritme Nagle akan kembali lebih dalam ke kode aplikasi dalam bentuk modifikasi QUIC
• Algoritme Nagle juga berguna ketika kejenuhan terjadi pada paket per detik (PPS) akibat paket-paket kecil
• Karena algoritme Nagle tidak bekerja baik untuk sebagian beban kerja, sebaiknya para engineer dipaksa menentukannya saat membuat socket
• ACK tertunda dapat dinonaktifkan dengan menggunakan opsi socket TCP_QUICKACK atau /proc/sys/net/ipv4/tcp_delack_min dan /proc/sys/net/ipv4/tcp_ato_min
• Di dunia yang bandwidth-nya terbatas, mengirim paket TCP untuk setiap byte adalah pemborosan bandwidth, sehingga algoritme Nagle diperlukan
• Jika tidak memiliki akses ke source aplikasi, masih belum ada cara yang baik untuk mengaktifkan TCP_NODELAY
• Bahasa modern seperti Go mengaktifkan TCP_NODELAY secara default, sehingga masalah ini tidak terjadi
• Jika ada cara bagi aplikasi untuk memberi tahu stack TCP bahwa itu adalah shell interaktif, TCP_NODELAY bisa dibiarkan nonaktif secara default dan hanya diaktifkan untuk aplikasi tersebut, sehingga overhead dapat dikurangi