TCP_NODELAY seçeneğinin sürekli kullanımı

TCP_NODELAY ayarının önemi

• Dağıtık sistemlerde gecikme sorunlarını debug ederken ilk kontrol edilmesi gereken şey, TCP_NODELAY seçeneğinin etkin olup olmadığıdır
• Birçok dağıtık sistem geliştiricisi, bu basit soket seçeneğini etkinleştirerek gecikme sorunlarını hızla çözdüğünü deneyimlemiştir
• Bu, varsayılan davranışın hatalı olabileceğini ya da kavramın tamamının eskimiş olabileceğini düşündürür

Nagle algoritmasının arka planı ve sorunları

• İlk olarak 1984'te John Nagle'ın RFC896'sında önerilen Nagle algoritmasının amacı, TCP header maliyetini daha iyi amorti ederek ağda daha iyi throughput elde etmekti
• Nagle algoritması, daha önce gönderilmiş veriye ait onay yanıtı alınmadıysa yeni TCP segmentlerinin gönderimini bastıracak şekilde çalışır
• Ancak bu, delayed ACK ile etkileşime girerek sorun yaratır
  • Nagle algoritması, ACK alınana kadar daha fazla veri gönderimini engeller; delayed ACK ise yanıt hazırlanana kadar ACK'yi geciktirir
  • Bu, paketleri doldurmak açısından iyidir ancak gecikmeye duyarlı pipeline uygulamaları için uygun değildir

Modern sistemlerde Nagle algoritmasına duyulan ihtiyaç

• Modern sunucular yüzlerce mikrosaniye içinde çok büyük miktarda iş yapabildiğinden, verinin tek bir RTT kadar bile geciktirilmesinin açık bir faydası olmayabilir
• Çoğu dağıtık veritabanı ve sistem tek baytlık paketler göndermez
  • Bunun nedeni, gönderilecek daha fazla veri bulunması ve TLS gibi protokollerin overhead'i ile encoding ve serialization overhead'idir
• Küçük mesajlar göndermemek hâlâ önemlidir, ancak bu artık uygulama katmanında etkili biçimde ele alınmaktadır

TCP_NODELAY kullanımına dair görüş

• Gecikmeye duyarlı dağıtık sistemler kurarken, gönül rahatlığıyla TCP_NODELAY'i etkinleştirebilir (Nagle algoritmasını devre dışı bırakabilirsiniz)
• Modern sistemlerde trafik ve uygulama mix'i ile donanım performansı dikkate alındığında, Nagle algoritmasına ihtiyaç kalmamış olabilir
  • Yani TCP_NODELAY varsayılan olmalıdır
  • Bu, bazı "her baytı yaz" kodlarını yavaşlatabilir, ancak verimliliğe önem veriyorsanız zaten o uygulamayı düzeltmeniz gerekir

GN⁺ görüşü

• Nagle algoritması ile delayed ACK arasındaki etkileşim sorunu, protokol tasarımının ne kadar zor olduğunu gösteren iyi bir örnektir. İki makul özelliğin istenmeyen davranış üretmesi durumu, sistem tasarımcılarına tanıdık gelecektir.

• Uygulama katmanında küçük mesaj gönderimini optimize etmek genel eğilimdir. Verimli encoding ve serialization ile gereksiz overhead'i en aza indirmek önemlidir.

• Nagle algoritmasının amacı ağ bant genişliğini optimize etmek idiyse, bugün gecikmeyi en aza indirmek daha önemli bir gereksinimdir. Uygulamanın yanıt verebilirliğinin kullanıcı deneyimini doğrudan etkilediği durumlarda gereksiz gecikmeden kaçınılmalıdır.

• Ancak TCP_NODELAY'i varsayılan yapmak her durumda ideal olmayabilir. Bant genişliğinin kısıtlı olduğu ortamlarda ya da iletim verimliliğinin gecikmeden çok daha önemli olduğu sistemlerde, Nagle algoritmasının seçici biçimde kullanılması gerekebilir.

• Ağ protokolü tasarımında farklı gereksinimler arasında denge kurmak önemlidir. Genel amaçlı bir protokolün varsayılan davranışını değiştirmek dikkat gerektirir, ancak uygulamanın ihtiyaçlarına uygun seçenekleri seçebilecek esnekliğe sahip olmak da gerekli görünmektedir.

[GN⁺]

Hacker News yorumu

Özet:

• Nagle algoritması, toplu yazmayı deneme yaklaşımıydı; donanım, ağ, uygulama veya kullanım senaryosundan bağımsız olarak toplu yazmanın daha iyi olduğu durumlar vardır
• Günümüzdeki pek çok bilgi işlem, toplu yazmayı kullanır; QUIC gibi yeni üst düzey protokoller de yazma toplulaştırması yaparak TCP’nin bağımsız bağlantı ve hata işleme işini kullanıcı alanına taşır
• Ağ doygunluğa ulaştığında, Nagle algoritması QUIC benzeri düzeltmeler biçiminde uygulama kodunun daha derin katmanlarında yeniden ortaya çıkacaktır
• Nagle algoritması, küçük paketler nedeniyle saniye başına paket (PPS) değerinin doygunluğa ulaştığı durumlarda da faydalıdır
• Nagle algoritması bazı iş yüklerinde iyi çalışmaz; bu nedenle mühendislerin soket oluştururken bunu zorunlu olarak ayarlamasının daha iyi olduğu savunulur
• Gecikmeli ACK, TCP_QUICKACK soket seçeneği ya da /proc/sys/net/ipv4/tcp_delack_min ve /proc/sys/net/ipv4/tcp_ato_min kullanılarak devre dışı bırakılabilir
• Bant genişliğinin sınırlı olduğu bir dünyada, her bayt için TCP paketi göndermek bant genişliğini boşa harcar; bu yüzden Nagle algoritmasına ihtiyaç vardır
• Uygulama kaynağına erişiminiz yoksa, TCP_NODELAY’i etkinleştirmenin iyi bir yolu hâlâ yoktur
• Go gibi modern diller varsayılan olarak TCP_NODELAY’i etkinleştirdiğinden bu sorun yaşanmaz
• Eğer uygulamanın etkileşimli bir kabuk olduğunu TCP yığınına bildirebilmesinin bir yolu olsaydı, TCP_NODELAY varsayılan olarak kapalı tutulup yalnızca o uygulama için açılabilir ve ek yük azaltılabilirdi