TCP_DEFER_ACCEPT Gerçek Dünya Kullanımı?

Çevrimiçi Apache httpd el kitabını inceliyordum ve bunu etkinleştirmek için bir direktifle karşılaştım. Man sayfasında şunun için bir açıklama bulundu tcp:

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

Sonra bu makaleyi buldum, ancak bunun ne tür iş yükleri için yararlı olacağından hala emin değilim. httpdÖzellikle bunun için bir seçenek varsa , web sunucuları ile ilgili olması gerektiğini varsayıyorum . Ayrıca httpd, ağ bağlantılarının nasıl yapıldığını değil, istediğiniz yerde ve istemediğiniz yerlerde kullanım durumlarının olduğunu da bir seçenek olarak kabul ediyorum.

Makaleyi okuduktan sonra bile, üç yollu el sıkışmasının tamamlanmasını beklemenin avantajının ne olacağından emin değilim. httpdBir bağlantı kurulduktan sonra potansiyel olarak bu gecikmeye neden olmak yerine el sıkışma devam ederken, ilgili örneği değiştirmeye gerek kalmamasını sağlamak avantajlı görünecektir .

Makale için, TCP_DEFER_ACCEPTbir soketin durumu ne olursa olsun, hala dört pakete ihtiyacınız olacak gibi görünüyor (el sıkışma sonra her durumda veri). Sayıyı nasıl üçe düşürdüğünü veya bunun nasıl anlamlı bir artış sağladığını bilmiyorum.

Yani sorum şu: Bu sadece eski bir seçenek mi yoksa bu seçenek için gerçek bir kullanım durumu var mı?

(OP hakkındaki yorumlarımı özetlemek için)

Bahsedildikleri üç yönlü el sıkışma TCP bağlantı kuruluşunun bir parçasıdır, söz konusu seçenek özellikle bununla ilgili değildir. Ayrıca veri alışverişinin üç yollu el sıkışmasının bir parçası olmadığını unutmayın, bu sadece TCP bağlantısını açık / yerleşik durumda oluşturur.

Bu seçeneğin varlığı ile ilgili olarak, bu bir soketin geleneksel davranışı değildir, normalde bağlantı kabul edildiğinde (yine de üç yönlü el sıkışmasının tamamlanmasından sonradır) soket işleyicisinin ipliği uyanır ve bazı protokoller için aktivite burada başlar ( örneğin bir SMTP sunucusu 220 karşılama satırı gönderir), ancak HTTP için konuşmadaki ilk mesaj GET / POST / etc satırını gönderen web tarayıcısıdır ve bu gerçekleşene kadar HTTP sunucusunun bağlantıya ilgisi yoktur (zamanlama dışında) bu nedenle, soket kabulü tamamlandığında HTTP sürecini uyandırmak, işlemin gerekli verileri bekledikten hemen sonra tekrar uykuya dalacağı için savurgan bir etkinliktir.

Boşta kalma işlemlerini uyandırmanın onları daha fazla işlem için hazır hale getirebileceğine dair bir argüman olsa da (özellikle çok eski makinelerde giriş terminallerini uyandırmayı ve takastan çekilmelerini hatırlıyorum), ancak aynı zamanda söz konusu sürecin kaynakları üzerinde zaten talepte bulunduğunu ve daha fazla gereksiz talepte bulunmanın genel olarak sistem performansını düşürebileceğini belirtti - bireysel iş parçanızın görünür performansı iyileşse bile (ki bu çok da yoğun olmayan bir makinenin disk IO'sunda darboğazlar olurdu) takas ederseniz diğer şeyleri yavaşlatır ve eğer o meşgulse, hemen uyku hemen geri takas edebilir). Bir kumar gibi görünüyor ve nihayetinde 'açgözlü' kumar, yoğun bir makinede mutlaka ödemez,

Bu performans ayarlama düzeyi ile ilgili genel tavsiyem, neyin en iyi olduğuna dair programlı kararlar vermek değil, sistem yöneticisi ve işletim sisteminin kaynak yönetimi sorunları ile başa çıkmak için birlikte çalışmasına izin vermek - bu onların işi ve çok tüm sistemin ve ötesindeki iş yüklerini anlamak için daha uygundur. Seçenekler ve yapılandırma seçenekleri verin.

Soruyu özel olarak cevaplamak için, seçenek, HTTP trafiğinin aşırı yükü dışında fark edeceğiniz seviyeye değil, tüm yapılandırmalarda yararlıdır, ancak teorik olarak bunu yapmanın "doğru" yoludur. Bu bir seçenektir, çünkü tüm Unix (hatta tüm Linux değil) lezzetleri bu özelliğe sahip değildir ve bu nedenle taşınabilirlik için dahil edilmeyecek şekilde yapılandırılabilir.

Üç yollu el sıkışmasının tamamlanmasının avantajının ne olacağından emin değilim.

Üç yönlü el sıkışmalar sesli telefon konuşmalarında yaygın olarak kullanılan bir protokoldür:

1. Sunucu : "İyi günler, Epiphyte Corp."
2. Arayan : "Merhaba, bu Randy."
3. Sunucu : "Evet, size nasıl yardımcı olabilirim?"
4. Arayan : çağrı gövdesi bir şaka talep etmeye başlar

TCP'de kanalın kurulmasını sağlamak için önemlidirler. Müşteri , işitmeden önce çağrı gövdesi göndermeye başladıysa (3), Sunucunun dinlememesi veya hazır olmaması ihtimali vardır. İşitme (3), Sunucunun iletimden hemen sonra kendiliğinden yanmadığını garanti etmez, ancak Sunucunun almaya hazır olduğu güvenini artırır.

El Sıkışma hakkındaki Wikipedia'da belirtildiği gibi :

1. Alice [Sunucu], Bob [İstemci] tarafından alınan ve yanıtlaması gerekmeyen onay numarası y + 1 olan bir onay mesajıyla yanıt verir .

Bu nedenle, sunucunun hazır olduğuna dair biraz ek kesinlikten vazgeçmek istiyorsanız, Sunucu (3) adımını atlayabilir ve istemci sunucunun hazır olduğunu varsayar. Bu, yukarıdaki protokol değişimini şuna dönüştürür:

1. Sunucu : "İyi günler, Epiphyte Corp."
2. Arayan : "Merhaba, bu Randy."
3. Arayan : "Imelda Marcos hakkında şakalar biliyor musun?"