Skip to main content

> linux_tcp_syn_ve_dinleme_(listen)_kuyruğu_taşması_ve_sessiz_paket_düşmeleri

Linux TCP SYN ve Dinleme (Listen) Kuyruğu Taşması ve Sessiz Paket Düşmeleri

Linux işletim sistemi, yüksek trafik patlamalarında uygulama seviyesinde hiçbir hata logu üretmeden gelen TCP el sıkışmalarını (SYN) neden sessizce düşürür; `somaxconn` ve `tcp_max_syn_backlog` nasıl ayarlanır?

Staff/Principal (L6+)

ÖZET VE TEKNİK CEVAP

Bir istemci sunucuya (Nginx, Envoy, Node.js) TCP bağlantısı başlattığında, Linux çekirdeği bu süreci iki ayrı çekirdek kuyruğunda yönetir: (1) SYN Kuyruğu (3'lü el sıkışmada istemcinin son ACK'sini bekleyen yarı açık bağlantılar) ve (2) Accept/Listen Dinleme Kuyruğu (el sıkışması bitmiş ancak uygulamanın `accept()` çağrısıyla henüz almadığı hazır bağlantılar). Varsayılan olarak Linux eski çekirdek ayarlarıyla gelir (`somaxconn = 128` ve `tcp_max_syn_backlog = 128`). Ani bir trafik patlamasında (ör. saniyede 5.000 istek), uygulama bu bağlantıları yeterince hızlı çekemez. Listen kuyruğu dolduğu anda Linux çekirdeği gelen yeni TCP SYN paketlerini uygulamaya hiçbir hata vermeden SESSİZCE DÜŞÜRÜR (drop). İstemciler 3-15 saniyelik bağlantı zaman aşımı yaşarken sunucu loglarında tek bir hata bile görünmez.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Çekirdek TCP bağlantı kurma mekanizması 3 aşamadan geçer: (1) SYN Kuyruğu Aşaması: İstemci SYN gönderir. Çekirdek bağlantıyı SYN kuyruğuna (`tcp_max_syn_backlog`) ekler ve SYN-ACK döner. (2) Accept Kuyruğu Aşaması: İstemci son ACK'yi atar. Çekirdek bağlantıyı el sıkışması tamamlanmış olarak Accept kuyruğuna taşır (boyutu $min( ext{listen_param}, ext{somaxconn})$ ile belirlenir). (3) Taşma ve Düşürme Davranışı: Accept kuyruğu dolduğunda çekirdek gelen yeni SYN paketlerini sessizce çöpe atar (`tcp_abort_on_overflow = 0`). İstemci TCP katmanında 1s, 3s, 7s şeklinde retransmission beklemesine girer ve büyük gecikme uçurumları doğar.

2. Doğru Kullanım Senaryosu

Yüksek hacimli ters vekil sunucular (Nginx, HAProxy, Envoy), Kubernetes Ingress kontrolcüleri, anlık indirim e-ticaret siteleri ve mikroservis RPC giriş kapıları.

3. Prodüksiyon Arıza Modları

Linux'ta varsayılan `somaxconn = 128` ile Java/Node.js sunucusu çalıştırmak ve sabah trafik patlamasında gelen bağlantıların %20'sinin çekirdek tarafından sessizce düşürülmesi; uygulamada `listen(4096)` yazılmasına rağmen çekirdekte `somaxconn = 128` olduğu için kuyruk boyutunun sessizce 128'e kırpılması.

4. Teşhis ve Telemetri Sinyalleri

`netstat -s` çıktısında `SYNs to LISTEN sockets dropped` veya `listen queue of a socket overflowed` sayacının sürekli artması; istemcilerin 3 saniyelik bağlantı gecikmesi bildirmesine rağmen uygulama içi yanıt süresinin 10 ms görünmesi.

5. Önleme ve Mimari Bariyerler

Çekirdek parametrelerini optimize edin: `net.core.somaxconn=65535` ve `net.ipv4.tcp_max_syn_backlog=65535`; uygulamadaki listen backlog parametresini yükseltin (Nginx `listen 80 backlog=65535;`); SYN Flood saldırılarına ve ani patlamalara karşı `net.ipv4.tcp_syncookies=1` ayarını açın.

6. Mimari Ödünleşimler (Trade-offs)

Kuyruk boyutlarını artırmak bekleyen soketler için çekirdekte birkaç megabaytlık önemsiz bir RAM tüketimi yaratır; ancak trafik patlamalarında yaşanan sessiz paket düşmelerini ve bağlantı gecikmelerini tamamen yok eder.

Vaka İncelemesi (TinyCTO Örneği)

Bir biletleme sitesinde bilet satış anında kullanıcılar 3,1 saniyelik garip bağlantı gecikmeleri yaşıyordu. Sunucu CPU'su %30'du ve sıfır 5xx hatası vardı. `netstat -s` çalıştırıldığında `somaxconn = 128` olduğu için dakikada 14.000 SYN paketinin çekirdek tarafından düşürüldüğü anlaşıldı. SRE ekibi `net.core.somaxconn=65535` ve Nginx `backlog=65535` ayarlarını yaptı. Düşen paket sayısı anında sıfıra indi ve 20.000 eşzamanlı bağlantı altında gecikme 3.100 ms'den 4 ms'ye düştü.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Linux'ta bir TCP bağlantısı kurulurken görev alan iki çekirdek kuyruğu nedir?

1. SYN Kuyruğu (yarı açık el sıkışmalar), 2. Accept / Listen Dinleme Kuyruğu (el sıkışması bitmiş, `accept()` bekleyen hazır bağlantılar).
Q2

Düşen TCP SYN paketleri istemci bağlantılarında neden 3 saniyelik bir gecikmeye yol açar?

Çünkü istemcinin TCP yığını düşen SYN paketini yeniden göndermeden önce ilk retransmission zaman aşımı süresini (genellikle 1 ila 3 saniye) bekler.

Linux TCP SYN ve Dinleme (Listen) Kuyruğu Taşması ve Sessiz Paket Düşmeleri — Sıkça Sorulan Sorular

Linux sunucunuzun o anda SYN paketlerini düşürüp düşürmediğini nasıl kontrol edebilirsiniz?

`netstat -s | grep -i listen` çalıştırarak veya `ss -lnt` ile dinleme yapan portların Send-Q / Recv-Q doluluk oranlarına bakarak.

Uygulamadaki `listen(backlog)` parametresi ile `net.core.somaxconn` arasındaki ilişki nedir?

Gerçek kuyruk boyutu ikisinin minimumudur: $min( ext{uygulama_backlog}, ext{somaxconn})$. İkisinin de birlikte yükseltilmesi şarttır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Linux manages TCP connection establishment via the SYN Queue and Accept/Listen Queue.
  • ▸Default `somaxconn = 128` causes silent TCP drops during modest traffic surges.
  • ▸Dropped SYNs trigger 1-3 second client-side TCP retransmission delays.
  • ▸Tune both `net.core.somaxconn` and application `listen(backlog)` to 65535.

Yaygın Yanılgılar

  • ✗Yanılgı: Application servers will log an error when the TCP listen queue overflows (Gerçek: The kernel drops packets before the application is ever aware).
  • ✗Yanılgı: Setting `somaxconn` in sysctl is enough (Gerçek: Application server configurations like Nginx/Gunicorn must also specify matching backlog sizes).

Karar Kılavuzu & Önceliklendirme

Set `net.core.somaxconn = 65535` and `net.ipv4.tcp_max_syn_backlog = 65535` on all API servers. Monitor `netstat -s` drop counters in Datadog/Prometheus as a critical networking SLI.

Doğrulanmış Kaynaklar & Referanslar