Bir sunucu neden bir SYN paketine yanıt olarak bir SYN / ACK paketi göndermiyor?

Son zamanlarda, web sitelerimize göz atan mac ve Linux kullanıcıları ile sınırlı olan bir TCP bağlantı sorununun farkında olduk.

Kullanıcı bakış açısından, web sitelerimizle (> 11 saniye) çok uzun bir bağlantı süresi sunuyor.

Bu sorunun teknik imzasını bulmayı başardık, ancak neden olduğunu veya nasıl düzeltileceğini çözemedik.

Temel olarak, olan şey, müşterinin makinesinin TCP bağlantısını kurmak için SYN paketini gönderiyor olması ve web sunucusunun bunu alması, ancak SYN / ACK paketiyle yanıt vermemesidir. İstemci birçok SYN paketi gönderdikten sonra, sunucu sonunda bir SYN / ACK paketi ile yanıt verir ve bağlantının kalanı için her şey yolundadır.

Ve elbette, soruna yol açan: aralıklı ve her zaman gerçekleşmiyor (her zaman% 10-30 arasında olmasına rağmen)

Fedora 12 Linux'u işletim sistemi olarak ve Nginx'i web sunucusu olarak kullanıyoruz.

Wireshark analizinin ekran görüntüsü

Güncelleme:

İstemcide pencere ölçeklendirmeyi kapatmak, sorunun olmasını engelledi. Şimdi bir sunucu tarafı çözünürlüğüne ihtiyacım var (tüm istemcilerin bunu yapmasını sağlayamıyoruz) :)

Son Güncelleme:

Çözüm, sunucularımızda hem halka açık olan hem de TCP pencere ölçeklendirmeyi ve TCP zaman damgalarını kapatmaktı .

Bu aynı sorunu yaşadık. Sadece TCP zaman damgalarını devre dışı bırakmak sorunu çözdü.

sysctl -w net.ipv4.tcp_timestamps=0

Bu değişikliği kalıcı yapmak için giriş yapın /etc/sysctl.conf.

TCP Pencere Ölçeği seçeneğini devre dışı bırakma konusunda çok dikkatli olun. Bu seçenek internet üzerinden maksimum performans sağlamak için önemlidir . 10 megabit / sn bağlantısı olan bir kişi, gidiş dönüş süresi (temelde ping ile aynı) 55 ms'den daha fazla ise, alt-transfer aktarımına sahip olacaktır .

Aynı NAT'ın arkasında birden fazla cihaz varken bu sorunu gerçekten fark ettik. Sunucunun, zaman damgası alanlarına tamamen farklı değerler koyduğundan, Android cihazlardan ve OSX makinelerinden gelen zaman damgalarını aynı anda görmekle karıştırıldığından şüpheleniyorum.

Benim durumumda aşağıdaki komut Linux sunucusundan eksik SYN / ACK cevaplarıyla sorunu düzeltti:

sysctl -w net.ipv4.tcp_tw_recycle=0

TCP zaman damgalarını devre dışı bırakmaktan daha doğru olduğunu düşünüyorum, çünkü TCP zaman damgaları yüksek performans için yararlıdır (PAWS, pencere ölçeklendirmesi vb.).

tcp_tw_recycleAçıkça belgelenmesi, birçok NAT yönlendiricisinin zaman damgalarını koruduğu ve aynı IP’nin zaman damgaları tutarlı olmadığı için PAWS’ın başladığı için etkinleştirilmesinin önerilmediğini açıkça belirtir.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.

Merak ediyorum, ama neden SYN paketi için (çerçeve # 539; kabul edilen), WS ve TSV alanları "Bilgi" sütununda eksik?

WS, TCP Pencere Ölçeklemesi ve TSV, Zaman Damgası Değeridir . Her ikisi de tcp.options alanı altında bulunur ve Wireshark hala varsa bunları göstermelidir. Belki de İstemci TCP / IP yığını, 8. girişimde farklı SYN paketlerini yeniden göndermiştir ve neden aniden onaylanmasının nedeni budur?

Bize çerçeve 539 iç değerleri verebilir misiniz? SYN / ACK, her zaman WS'nin etkin olmadığı bir SYN paketi için mi geliyor?

Biz de aynı problemle karşılaştık (senkronizasyon göndermemek için sunucuya sabitlemek biraz zaman aldı).

"Çözüm, tcp pencerelerini ölçeklendirmeyi ve sunucularımızda halka açık olan tcp zaman damgalarını kapatmaktı."

Ansis'in söylediklerini sürdürmek için, güvenlik duvarı TCP Windows Ölçeklendirmeyi desteklemediğinde böyle sorunlar gördüm. Bu iki ana bilgisayar arasında hangi marka / model güvenlik duvarı var?

Eksik SYN / ACK, güvenlik duvarındaki SYNFLOOD korumanızın çok düşük limitlerinden kaynaklanabilir. Sunucu kullanıcınıza kaç tane bağlantı kurduğuna bağlıdır. Spdy kullanmak bağlantı sayısını azaltacaktır ve net.ipv4.tcp_timestampskapatmanın işe yaramadığı durumlarda yardımcı olabilir.

Bu, bekleme süresi dolduğunda, dinleyen bir TCP soketinin davranışıdır.

Ngnix, backlog argümanının yapılandırmada ayarlanmasına izin verir: http://wiki.nginx.org/HttpCoreModule#listen

dinle 80 backlog = num

Num değerini varsayılan değerden daha büyük bir şeye ayarlamayı deneyin, 1024 gibi.

Tam bir dinleme sırasının gerçekte senin sorunun olduğuna dair hiçbir garanti veremem, ama bu kontrol edilmesi gereken ilk şey.

Linux TCP istemcilerinin 3 denemeden sonra SYN paketlerini değiştirdiklerini ve Pencere Ölçeklendirme seçeneğini kaldırdıklarını keşfettim. Sanırım çekirdek geliştiriciler bunun internetteki bağlantı başarısızlığının ortak bir nedeni olduğunu düşünüyorlardı.

Bu istemcilerin neden 11 saniye sonra bağlantı kurmayı başardıklarını açıklıyor (penceresiz TCP SYN, varsayılan ayarlarla kısa testimde 9 saniye sonra oluyor)

Benzer bir problemim vardı, ama benim durumumda yanlış hesaplanan TCP sağlama toplamıydı. Müşteri bir veth arkasındaydı ve çalışan ethtool -K veth0 rx kapalı tx off yaptı.