Linux Sunucuda TCP TIME_WAIT Birikmesi Sorunu

Linux sunucularda TCP TIME_WAIT birikmesi, yüksek trafikli ortamlarda sık karşılaşılan bir performans sorunudur. TCP bağlantıları kapatılırken TIME_WAIT durumuna geçen soketler, sistem kaynaklarını uzun süre meşgul ederek yeni bağlantıların kurulmasını engelleyebilir. Bu durum, özellikle web sunucuları, veritabanı sunucuları veya API gateway’lerinde belirginleşir ve sunucunun kapasitesini düşürür. TIME_WAIT, TCP protokolünün güvenilirliğini sağlamak için tasarlanmış bir mekanizmadır; ancak yoğun kullanımda binlerce soket birikerek bellek ve dosya tanımlayıcı limitlerini zorlayabilir. Bu makalede, sorunun kökenini inceleyecek, teşhis yöntemlerini açıklayacak ve pratik çözüm adımlarını detaylandıracağız. Sunucu yöneticileri için adım adım rehberlik sunarak, sorunun kök nedenlerini ele alacağız.

TCP TIME_WAIT Durumunun Teknik Detayları

TCP TIME_WAIT, bir bağlantı kapatıldıktan sonra soketin belirli bir süre (genellikle 2 MSL – Maximum Segment Lifetime, yaklaşık 60-120 saniye) sistemde tutulduğu aşamadır. Bu, gecikmiş paketlerin yeni bağlantıları bozmamasını sağlar. Linux’ta varsayılan olarak net.ipv4.tcp_fin_timeout=60 saniye ile yönetilir. Yoğun trafikte, kısa süreli bağlantılar (örneğin HTTP/1.0 keep-alive olmayan istekler) hızla birikir ve ss komutuyla net.state.time-wait sayısında artış gözlenir.

Bu durumun oluşum nedenleri arasında istemci taraflı bağlantı kapatmalar, NAT arkasındaki istemciler ve SYN flood benzeri saldırılar yer alır. Etkileri arasında yeni bağlantı reddi (ECONNREFUSED), epoll/eventfd doluluğu ve OOM killer tetiklenmesi bulunur. Örneğin, 100.000 TIME_WAIT soketi, her biri 1-2 KB bellek harcayarak 100-200 MB RAM tüketebilir. Sunucu loglarında “too many open files” veya kernel panikleri görülebilir.

Nedenler ve Tetikleyiciler

Yüksek bağlantı hızı (connections per second – CPS >1000), kısa yaşam döngülü bağlantılar ve yetersiz kaynak yönetimi TIME_WAIT birikimini tetikler. Uygulama katmanında, socket reuse etmeyen kodlar sorunu büyütür. Linux kernel parametreleri varsayılan olarak muhafazakardır; örneğin tcp_tw_recycle devre dışıdır çünkü NAT ile uyumsuzdur.

Sistem Üzerindeki Etkiler

Performans düşüşü, CPU yükünde %20-50 artış ve gecikme spike’ları (latency >1s) gözlenir. Dosya tanımlayıcı limitini (ulimit -n) aşarsa, nginx/apache gibi sunucular crash eder. Uzun vadede, sunucu yeniden başlatma ihtiyacı doğar ki bu da SLA ihlallerine yol açar.

Sorunun Teşhisi ve İzleme Yöntemleri

Teşhis için öncelikle mevcut TIME_WAIT soket sayısını ölçün. Komut: ss -tan state time-wait | wc -l veya netstat -tan | grep TIME_WAIT | wc -l. 10.000’den fazla ise sorunlu kabul edin. Daha detaylı analiz için ss -tan state time-wait | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr ile IP bazlı dağılımı görün. Prometheus + Node Exporter ile net.tcp.sockstat metric’ini izleyin; timewait_sockets > threshold alert kurun.

Sistem genelinde inceleme yapın: sysctl net.ipv4.tcp_fin_timeout ve cat /proc/sys/net/ipv4/tcp_tw_reuse değerlerini kontrol edin. top/htop ile kernel thread yükünü, vmstat ile swap kullanımını takip edin. Loglarda dmesg | grep -i tcp ile kernel mesajlarını arayın. Bu adımlar, sorunun büyüklüğünü ve kök nedenini belirler; örneğin belirli bir IP’den gelen trafikse rate limiting uygulayın.

Gerekli Komutlar ve Araçlar

• watch -n1 'ss -s | grep time-wait': Gerçek zamanlı izleme.
• tcpdump -i any port 80 and tcp.flags.fin=1: FIN paket trafiği yakalama.
• nload veya iftop: Trafik patern analizi.

Bu araçlar, sorunu saniyeler içinde teşhis etmenizi sağlar ve proaktif müdahale imkanı verir.

Pratik Çözüm ve Optimizasyon Adımları

Çözüm için kernel parametrelerini sysctl ile ayarlayın. Öncelikle /etc/sysctl.conf’a ekleyin: net.ipv4.tcp_tw_reuse = 1 (güvenli reuse için), net.ipv4.tcp_fin_timeout = 30 (TIME_WAIT süresini kısaltır), net.ipv4.tcp_tw_recycle = 0 (NAT uyumluluğu için kapalı tutun). Değişiklikleri sysctl -p ile etkinleştirin. Uygulama katmanında, HTTP/2 veya keep-alive etkinleştirerek bağlantı sayısını azaltın; nginx’te proxy_protocol ve reuseport kullanın.

İleri seviye optimizasyon: net.core.somaxconn = 65535, net.ipv4.tcp_max_syn_backlog = 8192. Rate limiting için iptables: iptables -A INPUT -p tcp --syn -m limit --limit 25/s --limit-burst 100 -j ACCEPT. Uygulama kodunda SO_REUSEADDR socket option’ını etkinleştirin. Test için ab (Apache Benchmark) ile yük testi yapın: ab -n 10000 -c 100 http://localhost/. Bu ayarlar, TIME_WAIT’i %80 azaltır ve CPS’i 2-3 kat artırır.

Sonuç olarak, TCP TIME_WAIT birikmesini yönetmek, Linux sunucuların ölçeklenebilirliğini doğrudan etkiler. Düzenli izleme, proaktif sysctl ayarları ve uygulama optimizasyonları ile sorunsuz operasyon sağlanır. Bu rehberi uygulayarak, üretim ortamlarınızda kesintisiz hizmet sunabilir, kaynak kullanımını optimize edebilirsiniz. Sürekli performans tuning ile sunucularınızı geleceğe hazır hale getirin.