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

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Ç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

Kapsam

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ı

Kritik Risk
  • ✓

    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

Metrikler
  • ✓

    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

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)

Ödünleşim

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 Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

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