Üretimde “API cevap vermiyor” diye görünen bazı incident’ların kökü uygulama değil, Linux TCP kuyruğudur. Özellikle ani trafik artışı, yanlış health-check davranışı veya gerçek bir SYN flood; connect() çağrısını daha uygulama işleme girmeden öldürebilir.
Bu yazı, SYN backlog + accept queue davranışını operasyonel açıdan okunabilir hâle getiren ve hem hızlı müdahale hem kalıcı dayanıklılık için kullanılabilecek bir runbook’tur.
1) Mental model: iki farklı kuyruk
Bir TCP dinleyicisinde iki ayrı “bekleme alanı” vardır:
- SYN backlog (yarım açık bağlantılar): SYN geldi → SYN/ACK gitti → ACK bekleniyor.
- Accept queue (tamamlanmış bağlantılar): 3-way handshake tamamlandı → uygulama
accept()ile alacak.
İkisi farklı sınırlara ve farklı failure modlarına sahiptir. Bu yüzden sadece listen(backlog) değerine bakarak karar vermek çoğu zaman yanıltır.
2) Triage: 5 dakikalık kontrol listesi
2.1 Belirti doğrulama
İstemci tarafı tipik semptomlar:
connect timeout,i/o timeout,upstream connect error- 5xx artışı (proxy/LB katmanında)
- Latency değil, başarısız bağlantı oranı artar
Sunucu üzerinde hızlı kontrol:
# Dinleyen soket ve backlog göstergeleri
ss -ltnp
# Dinleyen soketlerin özet kuyruğu
ss -ltnRecv-Q (accept queue) artıyorsa uygulama accept() yetişemiyor olabilir.
2.2 SYN cookie devrede mi?
sysctl net.ipv4.tcp_syncookies0: kapalı (yük altında daha erken çöküş)1: açık (SYN backlog dolunca devreye girer)
2.3 Kernel sayaçlarına bak (kanıt)
netstat -s | rg -n "listen|SYN|cookie|overflow|drop|retrans" -SSaha yorumu:
- “listen queue overflow” benzeri sayaçlar: accept queue doluyor
- “SYNs to LISTEN sockets dropped” / “SYN cookies sent”: SYN backlog baskısı
Not: sayaç isimleri kernel sürümüne göre değişebilir; amaç metni ezberlemek değil, overflow/drop/cookie üçlüsünü yakalamaktır.
3) Hızlı mitigasyon (incident anında)
Öncelik: bağlantıyı stabilize et, sonra kök nedeni ayrıştır.
3.1 SYN cookie aç (kontrollü)
sudo sysctl -w net.ipv4.tcp_syncookies=1Kalıcı yapmak için:
echo 'net.ipv4.tcp_syncookies = 1' | sudo tee /etc/sysctl.d/99-syncookies.conf
sudo sysctl --system3.2 Backlog sınırlarını büyüt
Uygulama listen(backlog) büyük bile olsa, kernel üst sınırları dar ise etkisi sınırlı kalır.
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192Saha notu:
somaxconn: accept queue için tavantcp_max_syn_backlog: SYN backlog için tavan (özellikle yoğun SYN altında)
3.3 LB/edge davranışını düzelt (en çok kazanç burada)
En pahalı hata: health-check’in sorun anında trafiği artırması.
Operasyonel kontrol listesi:
- Health-check frequency aşırı agresif mi?
- Birden fazla katman aynı anda retry ediyor mu? (LB + gateway + client)
- Tek bir problemli pod/host’a trafik “yapışıyor” mu?
Mümkünse incident sırasında:
- Retry sayısını düşür / retry budget uygula
- Health-check threshold’u yükselt (flap’i azalt)
- Trafiği kademeli dağıt (weight/priority)
4) Kalıcı dayanıklılık: tasarım kararları
4.1 “Backlog büyütmek” tek başına strateji değildir
Backlog, sadece tampon. Gerçek hedef:
- SYN baskısını edge’de kesmek (rate limit / SYN proxy / WAF)
- Accept hızını artırmak (event loop,
accept()akışı, thread modeli) - Burst davranışını öngörmek (kampanya, batch, cron)
4.2 Observability: hangi metrikler alarm olmalı?
Önerilen sinyaller:
- SYN cookie kullanım oranı / sayacı
- Listen/accept overflow sayaçları
SYN-RECVstate oranı (ani artış)- LB “connect error” oranı (upstream connect failure)
5) Runbook kapanış: doğrulama ve geri dönüş
Mitigasyon sonrası doğrulama:
- 401/5xx değil, özellikle connect error oranı düşüyor mu?
- SYN cookie sayaçları azalıyor mu?
ssçıktısındaRecv-Qnormale döndü mü?
Geri dönüş:
- Geçici sysctl’leri kalıcıya taşımadan önce kapasite artışını ve edge politikasını netleştir.
- Geri alma planı yaz: eski değerler, değişiklik zamanı, rollback komutu.
Son söz: Bu incident sınıfı, “uygulama yavaş” diye başlar ama çoğu zaman ağ ve kernel davranışıdır. Operasyonel liderlik, doğru katmanda doğru refleksi kurabilmektir: kanıt → mitigasyon → kalıcı tasarım.