Linux sunucularda TCP yeniden gönderme (retransmission) olayları, ağ performansını doğrudan etkileyen kritik göstergelerdir. Bu durum, paketlerin alıcıya ulaşmaması veya zaman aşımı nedeniyle tekrar gönderilmesini ifade eder. Yüksek retransmission oranları, gecikme, veri kaybı ve genel sistem yavaşlığına yol açar. Kurumsal ortamlarda, bu sorunları erken tespit etmek, servis kesintilerini önler ve kullanıcı deneyimini iyileştirir. Bu makalede, Linux tabanlı sunucularda TCP retransmission’ları anlamak, izlemek ve analiz etmek için adım adım rehberlik sunacağız. Pratik komutlar ve araçlar üzerinden somut örneklerle ilerleyerek, sistem yöneticilerine actionable insights sağlayacağız.
TCP Yeniden Gönderme Kavramı ve Nedenleri
TCP protokolü, güvenilir veri iletimi için yeniden gönderme mekanizmasını kullanır. Bir paket belirli bir süre içinde onaylanmazsa (ACK alınmazsa), gönderici taraf otomatik olarak paketi tekrar iletir. Linux kernel’inde bu davranış, net.ipv4.tcp_retries2 gibi sysctl parametreleri ile yönetilir. Varsayılan olarak, üç başarısız denemeden sonra bağlantı sıfırlanır. Retransmission’lar, sunucu yükü altında CPU ve bellek tüketimini artırır, özellikle yüksek trafikli web veya veritabanı sunucularında belirgindir.
Yaygın nedenler arasında ağ tıkanıklığı, fiziksel katman sorunları ve konfigürasyon hataları yer alır. Örneğin, MTU uyumsuzluğu nedeniyle parçalanma (fragmentation) retransmission’lara yol açar. Firewall kuralları veya NAT cihazları da SYN paketlerini bloke ederek bağlantı kurulumunda sorun yaratır. Bu faktörleri anlamak, kök neden analizi için temel oluşturur. Sistem yöneticileri, düzenli izleme ile bu olayları %20-30 oranında azaltabilir, ancak kesin oranlar trafiğe göre değişir.
Tipik Nedenler ve Belirtiler
Ağ tıkanıklığı, bant genişliği yetersizliğinde queue dolmasıyla retransmission’ları tetikler. Belirti olarak, ss komutu ile görülen yüksek retransmit sayılarıdır. Paket kaybı oranını hesaplamak için, toplam gönderilen paketlere oranla retransmit’leri inceleyin. MTU sorunlarında, path MTU discovery etkinleştirilmelidir: sysctl net.ipv4.ip_no_pmtu_disc=0. Firewall kaynaklıysa, iptables -L -v ile kuralları doğrulayın. Bu belirtileri erken yakalamak, proaktif müdahale sağlar.
Sunucu Tarafı Etkileri
Yüksek retransmission, TCP bağlantı havuzunu şişirir ve yeni bağlantıları geciktirir. Apache veya Nginx gibi servislerde, backlog queue dolarken 503 hataları görülür. Kernel log’larında (dmesg | grep TCP) timeout uyarıları belirir. Uzun vadede, bu durum disk I/O’yu etkileyerek veritabanı sorgularını yavaşlatır. İzleme için cron job ile ss -s çıktısını loglayın ve eşik aşımlarında alert kurun.
Linux Araçları ile İzleme
Linux’ta yerleşik araçlar, retransmission analizi için yeterlidir. netstat ve ss komutları hızlı snapshot’lar sağlar, tcpdump ise derinlemesine capture yapar. Bu araçları root olarak çalıştırın ve çıktıları pipe ile grep filtreleyin. Düzenli kullanım, trend analizi için log toplama script’leri ile entegre edilebilir. Örneğin, bir bash script ile dakikada bir ss çıktısını /var/log/tcp_stats.log’a kaydedin.
- netstat Kullanımı: netstat -s | grep -i retrans ile toplam retransmit sayısını görün. TcpRetransSegs satırını izleyin; ani artışlar sorun işaretidir.
- ss Komutu: ss -m | grep retransmit ile bellek tamponu ve retrans durumundaki soketleri listeleyin. -tulnP filtreleri ile PID bazlı filtreleme yapın.
- sar Entegrasyonu: sysstat paketiyle sar -n EDEV 1 5 çalıştırarak ağ istatistiklerini zaman serisi olarak alın.
Bu komutlar, 10 saniyelik aralıklarla çalıştırıldığında gerçek zamanlı monitoring sağlar. Çıktıları analiz ederek, belirli IP’lerden gelen trafiği izole edin.
Tcpdump ile Paket Yakalama
Tcpdump, retransmission’ları yakalamak için idealdir. tcpdump -i eth0 -w capture.pcap ‘tcp[tcpflags] & tcp-ack != 0’ ile ACK’li paketleri kaydedin. Sonra tcpdump -r capture.pcap | grep ‘tcp.analysis.retransmission’ ile filtreleyin. Bu, duplicate ACK’leri ve fast retransmit’leri gösterir. Capture süresini 60 saniye ile sınırlayın, yüksek trafik için ring buffer kullanın: -b 100 -c 10000. Analiz sonrası, pcap dosyasını silmeyi unutmayın.
Gelişmiş Metrikler: sysctl ve /proc
/proc/net/snmp dosyasından TcpRetransSegs’i okuyun: cat /proc/net/snmp | grep TcpRetransSegs. Sysctl net.ipv4.tcp_slow_start_after_idle=0 ile tuning yapın. Bu değerler, cron ile awk script’inde diff hesaplayarak oran verir: retrans_rate=$(echo “scale=2; $new/$old” | bc). Eşik 0.01’i aşarsa uyarı üretin. Bu yaklaşım, otomatize edilmiş dashboard’lar için temel oluşturur.
Adım Adım Analiz ve Çözümleme
Analiz sürecini sistematik hale getirin: Önce genel metrikleri toplayın, sonra spesifik capture yapın ve kök nedeni doğrulayın. Bir vaka: Yüksek retransmission tespit edildiğinde, traceroute hedef IP’ye sorun. RTT >200ms ise upstream sağlayıcıyla görüşün. Tuning için net.core.rmem_max=16777216 artırın, ardından sysctl -p ile uygula.
Pratik adımlar şöyle olsun:
- Toplam retrans sayısını netstat -s ile baseline alın.
- Şüpheli soketleri ss -tpi ile listeleyin ve kill edin.
- Tcpdump capture sonrası, retrans oranını hesaplayın: %1 üzeri inceleyin.
- Tuning uygula ve 30 dakika sonra yeniden test et.
Bu döngü, sorunları %90 oranında çözer. Ağ ekibiyle koordinasyon şarttır.
Sonuç olarak, Linux sunucularda TCP retransmission analizi, proaktif ağ yönetimi için vazgeçilmezdir. Düzenli araç kullanımı ve tuning ile performansınızı optimize edin, kesinti riskini minimize edin. Sistem yöneticileri, bu rehberi temel alarak kendi script’lerini geliştirerek otomasyonu artırabilirler.