Mengapa server tidak mengirim paket SYN / ACK sebagai tanggapan terhadap paket SYN

Akhir-akhir ini, kami menyadari masalah koneksi TCP yang sebagian besar terbatas pada pengguna mac dan Linux yang menelusuri situs web kami.

Dari perspektif pengguna, ini menghadirkan dirinya sebagai waktu koneksi yang sangat lama ke situs web kami (> 11 detik).

Kami telah berhasil melacak tanda tangan teknis masalah ini, tetapi tidak dapat mengetahui mengapa itu terjadi atau bagaimana cara memperbaikinya.

Pada dasarnya, apa yang terjadi adalah bahwa mesin klien mengirimkan paket SYN untuk membuat koneksi TCP dan server web menerimanya, tetapi tidak merespons dengan paket SYN / ACK. Setelah klien mengirim banyak paket SYN, server akhirnya merespons dengan paket SYN / ACK dan semuanya baik-baik saja selama sisa koneksi.

Dan, tentu saja, kicker untuk masalah: itu berselang dan tidak terjadi setiap saat (meskipun itu terjadi antara 10-30% dari waktu)

Kami menggunakan Fedora 12 Linux sebagai OS dan Nginx sebagai server web.

Cuplikan layar analisis wireshark

Memperbarui:

Mematikan penskalaan jendela pada klien menghentikan masalah terjadi. Sekarang saya hanya perlu resolusi sisi server (kami tidak dapat membuat semua klien melakukan ini) :)

Pembaruan Terakhir:

Solusinya adalah mematikan penskalaan jendela TCP dan cap waktu TCP pada server kami yang dapat diakses oleh publik.

Kami memiliki masalah yang sama persis ini. Hanya menonaktifkan cap waktu TCP memecahkan masalah.

sysctl -w net.ipv4.tcp_timestamps=0

Untuk membuat perubahan ini permanen, buat entri di /etc/sysctl.conf.

Berhati-hatilah untuk menonaktifkan opsi Skala Jendela TCP. Ini pilihan adalah penting untuk memberikan performa yang maksimal melalui internet. Seseorang dengan koneksi 10 megabit / detik akan memiliki transfer suboptimal jika waktu pulang pergi (pada dasarnya sama dengan ping) lebih dari 55 ms.

Kami benar-benar memperhatikan masalah ini ketika ada beberapa perangkat di belakang NAT yang sama. Saya menduga bahwa server mungkin bingung melihat cap waktu dari perangkat Android dan mesin OSX pada saat yang sama karena mereka meletakkan nilai yang sama sekali berbeda di bidang cap waktu.

Dalam kasus saya, perintah berikut memperbaiki masalah dengan tidak adanya balasan SYN / ACK dari server Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Saya pikir itu lebih benar daripada menonaktifkan cap waktu TCP, karena cap waktu TCP berguna untuk kinerja tinggi (PAWS, skala jendela, dll).

Dokumentasi pada tcp_tw_recyclesecara eksplisit menyatakan bahwa tidak disarankan untuk mengaktifkannya, karena banyak router NAT menyimpan stempel waktu dan karenanya PAWS masuk, karena stempel waktu dari IP yang sama tidak konsisten.

   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.

Hanya ingin tahu, tetapi mengapa untuk paket SYN (frame # 539; yang diterima), bidang WS dan TSV hilang di kolom "Info"?

WS adalah TCP Window Scaling dan TSV adalah Nilai Timestamp . Keduanya ditemukan di bawah bidang tcp.options dan Wireshark masih harus menunjukkannya jika ada. Mungkin Client TCP / IP stack membenci paket SYN yang berbeda pada upaya ke-8 dan itulah alasan mengapa tiba-tiba diakui?

Bisakah Anda memberi kami nilai internal frame 539? Apakah SYN / ACK selalu datang untuk paket SYN yang tidak memiliki WS diaktifkan?

Kami hanya mengalami masalah yang sama persis (butuh waktu cukup lama untuk menyematkannya ke server tidak mengirim syn-ack).

"Solusinya adalah mematikan penskalaan jendela tcp dan stempel waktu tcp di server kami yang dapat diakses oleh publik."

Untuk menjalankan apa yang telah dinyatakan Ansis, saya telah melihat masalah seperti ini ketika firewall tidak mendukung TCP Windows Scaling. Apa yang membuat / model firewall antara dua host ini?

SYN / ACK yang hilang dapat disebabkan oleh batas perlindungan SYNFLOOD Anda yang terlalu rendah pada firewall. Itu tergantung pada berapa banyak koneksi ke pengguna server Anda buat. Menggunakan spdy akan mengurangi jumlah koneksi dan dapat membantu dalam situasi di mana mematikan net.ipv4.tcp_timestampstidak membantu.

Ini adalah perilaku soket TCP yang mendengarkan ketika tumpukannya penuh.

Ngnix memungkinkan argumen backlog untuk mendengarkan diatur dalam konfigurasi: http://wiki.nginx.org/HttpCoreModule#listen

dengarkan 80 backlog = num

Coba atur num ke sesuatu yang lebih besar dari standar, seperti 1024.

Saya tidak memberikan jaminan bahwa mendengarkan penuh antrian sebenarnya adalah masalah Anda, tetapi ini adalah hal pertama yang baik untuk diperiksa.

Saya baru saja menemukan bahwa klien Linux TCP mengubah paket SYN mereka setelah 3 kali mencoba, dan menghapus opsi Window Scaling. Saya kira para pengembang kernel menemukan bahwa ini adalah penyebab umum dari kegagalan koneksi di Internet

Ini menjelaskan mengapa klien ini berhasil terhubung setelah 11 detik (TCP SYN tanpa jendela terjadi setelah 9 detik dalam pengujian singkat saya dengan pengaturan default)

Saya memiliki masalah yang sama, tetapi dalam kasus saya itu adalah checksum TCP yang salah dihitung. Klien berada di belakang veth dan menjalankan ethtool -K veth0 rx off tx off melakukan trik.