Baru-baru ini kami memiliki server apache yang merespons sangat lambat karena banjir SYN. Solusi untuk ini adalah mengaktifkan tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf).
Saya memposting pertanyaan tentang ini di sini jika Anda ingin lebih banyak latar belakang.
Setelah mengaktifkan sinkronisasi kami mulai melihat pesan berikut di / var / log / pesan kira-kira setiap 60 detik:
[84440.731929] possible SYN flooding on port 80. Sending cookies.
Vinko Vrsalovic memberi tahu saya bahwa ini berarti backlog syn semakin penuh, jadi saya menaikkan tcp_max_syn_backlog menjadi 4096. Pada titik tertentu saya juga menurunkan tcp_synack_retries menjadi 3 (turun dari default 5) dengan menerbitkan sysctl -w net.ipv4.tcp_synack_retries=3. Setelah melakukan ini, frekuensinya sepertinya turun, dengan interval pesan bervariasi antara sekitar 60 dan 180 detik.
Selanjutnya saya menerbitkan sysctl -w net.ipv4.tcp_max_syn_backlog=65536, tetapi saya masih mendapatkan pesan di log.
Sepanjang semua ini saya telah menonton jumlah koneksi dalam keadaan SYN_RECV (dengan menjalankan watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'), dan tidak pernah lebih tinggi dari sekitar 240, jauh lebih rendah dari ukuran backlog. Namun saya memiliki server Red Hat yang melayang di sekitar 512 (batas pada server ini adalah default 1024).
Apakah ada pengaturan tcp lain yang akan membatasi ukuran backlog atau saya menggonggong pohon yang salah? Haruskah jumlah koneksi SYN_RECV netstat -tunaberkorelasi dengan ukuran backlog?
Memperbarui
Yang terbaik yang bisa saya katakan adalah saya sedang berurusan dengan koneksi yang sah di sini, netstat -tuna|wc -lberkisar sekitar 5000. Saya telah meneliti ini hari ini dan menemukan posting ini dari karyawan last.fm, yang agak berguna.
Saya juga menemukan bahwa tcp_max_syn_backlog tidak berpengaruh ketika sinkronisasi diaktifkan (sesuai tautan ini )
Jadi sebagai langkah selanjutnya saya mengatur yang berikut ini di sysctl.conf:
net.ipv4.tcp_syn_retries = 3
# default=5
net.ipv4.tcp_synack_retries = 3
# default=5
net.ipv4.tcp_max_syn_backlog = 65536
# default=1024
net.core.wmem_max = 8388608
# default=124928
net.core.rmem_max = 8388608
# default=131071
net.core.somaxconn = 512
# default = 128
net.core.optmem_max = 81920
# default = 20480
Saya kemudian mengatur tes waktu tanggapan saya, berlari sysctl -pdan menonaktifkan sinkronisasi oleh sysctl -w net.ipv4.tcp_syncookies=0.
Setelah melakukan ini, jumlah koneksi dalam keadaan SYN_RECV masih tetap sekitar 220-250, tetapi koneksi mulai tertunda lagi. Setelah saya perhatikan penundaan ini, saya mengaktifkan kembali sinkronisasi dan penundaan berhenti.
Saya percaya apa yang saya lihat masih merupakan perbaikan dari kondisi awal, namun beberapa permintaan masih tertunda yang jauh lebih buruk daripada mengaktifkan sinkronisasi. Jadi sepertinya saya terjebak dengan mereka diaktifkan sampai kita bisa mendapatkan lebih banyak server online untuk mengatasi beban. Bahkan kemudian, saya tidak yakin saya melihat alasan yang valid untuk menonaktifkannya lagi karena mereka hanya dikirim (tampaknya) ketika buffer server penuh.
Tetapi backlog syn tampaknya tidak penuh dengan hanya ~ 250 koneksi di negara SYN_RECV! Mungkinkah pesan flooding SYN adalah herring merah dan itu bukan syn_backlog yang terisi?
Jika ada yang punya opsi penyetelan lain yang belum saya coba, saya akan dengan senang hati mencobanya, tapi saya mulai bertanya-tanya apakah pengaturan syn_backlog tidak diterapkan dengan benar karena alasan tertentu.