Ağ Performans Sorunları: ss, iftop ve nethogs ile Derinlemesine Analiz

yazar

Sunucunda bir şeyler ters gidiyor. Kullanıcılar yavaşlıktan şikayet ediyor, disk I/O normal görünüyor, CPU boşta, RAM yeterli. Peki sorun nerede? Büyük ihtimalle ağda. Linux’ta ağ sorunlarını teşhis etmek, doğru araçları bilmiyorsan gerçekten sinir bozucu olabilir. Bu yazıda ss, iftop ve nethogs üçlüsünü kullanarak ağ performans sorunlarını nasıl bulacağını ve çözeceğini adım adım anlatacağım.

Neden Bu Üç Araç?

Her aracın farklı bir bakış açısı var. ss sana soket düzeyinde detaylı bilgi verir, TCP bağlantılarının durumunu, kuyruk dolulukları ve bağlantı sayılarını gösterir. iftop arayüz bazında anlık trafik akışını görselleştirir, hangi IP’ler ne kadar bant genişliği tüketiyor görebilirsin. nethogs ise işlem bazında bant genişliği kullanımını gösterir, yani tam olarak hangi uygulamanın ağı yorduğunu bulursun.

Üçünü birlikte kullandığında ağ performans sorunlarının neredeyse tamamını yakalayabilirsin.

ss: Soket İstatistiklerinin Derinliklerine İnmek

ss aracı, eski netstat komutunun yerini almış modern bir soket analiz aracıdır. netstat‘tan çok daha hızlı çalışır çünkü /proc/net dosyalarını doğrudan okumak yerine kernel’in netlink arayüzünü kullanır. Özellikle binlerce aktif bağlantı olan sunucularda bu fark çok belirgindir.

Temel ss Kullanımı

# Tüm TCP bağlantılarını listele
ss -t

# Dinleyen portları göster
ss -tlnp

# UDP bağlantıları dahil tümünü göster
ss -tunlp

# Detaylı istatistiklerle birlikte
ss -s

ss -s çıktısı sana özet bilgi verir. Toplam soket sayısı, TCP durumlarının dağılımı, TIME_WAIT sayısı gibi bilgiler bir anda sorunun boyutunu anlamamı sağlar.

Bağlantı Durumlarına Göre Filtreleme

# Sadece ESTABLISHED bağlantıları göster
ss -t state established

# TIME_WAIT durumundaki bağlantıları say
ss -t state time-wait | wc -l

# SYN_RECV durumundaki bağlantılar (SYN flood tespiti için kritik)
ss -t state syn-recv

# Belirli bir porta gelen bağlantılar
ss -t dst :443

# Belirli bir IP'den gelen bağlantılar
ss -t src 192.168.1.100

Gerçek Dünya Senaryosu: TIME_WAIT Salgını

Geçen ay bir e-ticaret sitesinin yük dengeleyici sunucusunda ciddi bir yavaşlama yaşandı. CPU %15, RAM kullanımı normal, ama uygulama yanıt vermekte gecikmeler vardı. İlk baktığım şey TIME_WAIT sayısı oldu:

ss -s

Çıktıda 28.000’i aşkın TIME_WAIT bağlantısı gördüm. Bu ciddi bir sorundu. Kernel ephemeral port havuzu tükenmek üzereydi. Sorunun kaynağını bulmak için:

# Hangi remote IP ile en çok TIME_WAIT var?
ss -t state time-wait | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Çıktı bana tek bir backend sunucuyla 15.000’den fazla TIME_WAIT bağlantısı olduğunu gösterdi. Sorun, yük dengeleyicinin her istek için yeni TCP bağlantısı kurmasıydı. Keep-alive ayarlarını düzenlemek ve kernel parametrelerini ayarlamak sorunu çözdü:

# Geçici çözüm: TIME_WAIT yeniden kullanımını etkinleştir
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

# Kalıcı çözüm için /etc/sysctl.conf'a ekle
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

ss ile Recv-Q ve Send-Q Analizi

Bu iki kolon çok önemli, çoğu kişi görmezden gelir:

# Recv-Q ve Send-Q değerlerini göster
ss -tnp

# Yüksek Recv-Q olan bağlantıları filtrele
ss -tnp | awk '$3 > 0 {print}'

Recv-Q: Uygulamanın kernel buffer’dan henüz okumadığı byte sayısı. Bu değer sürekli yüksekse uygulama ağ verisini işleyemeyecek kadar yavaş demektir.

Send-Q: Gönderilmeyi bekleyen byte sayısı. Yüksekse ya ağ yavaş ya da karşı taraf veriyi alamıyor demektir.

Bir veritabanı sunucusunda Recv-Q değerlerinin düzenli olarak 50KB’ı geçtiğini gördüğümde, sorunun ağda değil uygulamanın bağlantı havuzu ayarlarında olduğunu anladım.

iftop: Arayüz Bazında Anlık Trafik Analizi

iftop kurulu değilse hemen kur:

# Debian/Ubuntu
apt install iftop

# RHEL/CentOS
yum install iftop
# veya
dnf install iftop

Temel iftop Kullanımı

# Varsayılan ağ arayüzünde izle
iftop

# Belirli bir arayüzü izle
iftop -i eth0

# DNS çözümlemesini kapat (daha hızlı)
iftop -n

# Port numaralarını göster
iftop -P

# Belirli bir ağı filtrele
iftop -F 192.168.1.0/24

# Hem port hem de DNS çözümlemesiz
iftop -nNP -i eth0

iftop Ekran İçi Kontroller

iftop çalışırken kullanabileceğin klavye kısayolları:

  • n: DNS çözümlemesini aç/kapat
  • p: Port görünümünü aç/kapat
  • P: Duraklatma
  • s: Kaynak görünümünü gizle/göster
  • d: Hedef görünümünü gizle/göster
  • t: Trafik yönü görünümü
  • 1, 2, 3: 2, 10, 40 saniyelik ortalamalara göre sırala
  • : Kaynak veya hedefe göre sırala
  • l: Filtre satırını aç

Gerçek Dünya Senaryosu: Gizli Bandwidth Hırsızı

Bir hosting müşterisi “ağımız neden bu kadar yavaş?” diye şikayet etti. Sunucuya bağlandım, iftop -nP -i eth0 çalıştırdım. Ekran gözlerimi kör etti. Tek bir IP adresi saniyede 80-90 Mbit trafik üretiyordu. Üstelik bu trafik outbound yani sunucudan dışarı gidiyordu.

# Yüksek trafikli IP'yi bulduktan sonra ss ile detay bak
ss -tnp | grep "OUTBOUND_IP_HERE"

# Hangi process bu IP ile konuşuyor?
ss -tnp dst OUTBOUND_IP_HERE

Sonuç ilginçti: Sunucuya yerleştirilmiş bir zararlı yazılım bir video streaming sunucusuna veri gönderiyordu. iftop olmadan bu tür bir durumu tespit etmek saatler alabilirdi.

iftop ile Bant Genişliği Kullanım Raporu

# 30 saniye boyunca izle ve çık, sonuçları kaydet
iftop -nNt -s 30 2>&1 | tee /tmp/bandwidth_report.txt

# Sadece belirli bir porta giden trafiği izle
iftop -nN -f "port 443"

# İki ağ arasındaki trafiği izle
iftop -nN -F 10.0.0.0/8 -G 192.168.0.0/16

nethogs: Process Bazında Bandwidth Takibi

nethogs benim favorim. Diğer araçlar sana IP veya port bazında bilgi verirken, nethogs “bu ağ trafiğini hangi uygulama üretiyor?” sorusunu yanıtlar. Bu soruyu sormadan ağ sorunlarını tam olarak çözemezsin.

# Kurulum
apt install nethogs  # Debian/Ubuntu
yum install nethogs  # RHEL/CentOS

# Temel kullanım
nethogs

# Belirli bir arayüzü izle
nethogs eth0

# Birden fazla arayüzü izle
nethogs eth0 eth1

# Refresh hızını ayarla (saniye)
nethogs -d 2 eth0

# KB/s yerine MB/s göster
nethogs -v 3 eth0

nethogs Görünüm Modları

Çalışırken m tuşuna basarak görünüm modlarını değiştirebilirsin:

  • kb/s: Kilobit per saniye
  • kb: Toplam kilobyte
  • b: Toplam byte

Gerçek Dünya Senaryosu: Beklenmedik Yedekleme Trafiği

Bir production sunucusunda mesai saatleri içinde ağ yavaşlıyor, akşam 5’te düzeliyor gibiydi. Klasik bir “birisi yanlış saatte yedekleme yapıyor” senaryosu gibi görünüyordu ama crontab -l ve crontab -l -u root kontrolleri normal görünüyordu.

# nethogs ile gerçek zamanlı izleme
nethogs -d 1 eth0

nethogs ekranında /usr/bin/rsync prosesi 45 MB/s outbound trafik üretiyordu. Hangi rsync job’u olduğunu bulmak için:

# rsync process'inin detaylarına bak
ps aux | grep rsync

# Process'in açık dosyalarını ve bağlantılarını gör
lsof -p PID_NUMBER | grep -E "IPv|TCP"

Sonuç: Bir geliştirici yanlışlıkla production sunucusunda test rsync job’u çalıştırmış ve işlemi bitirmeden çıkmıştı. Terminal kapatılmış ama process arka planda çalışmaya devam ediyordu.

Üç Aracı Birlikte Kullanmak: Metodoloji

Bir ağ sorunuyla karşılaştığında şu sırayı takip et:

1. Adım: Genel Duruma Bak

# Hızlı özet
ss -s

# Dinleyen servisler ve bağlantı sayıları
ss -tlnp

# Arayüz istatistikleri
ip -s link show eth0

2. Adım: iftop ile Trafik Akışını Anlat

iftop -nNP -i eth0

Burada yüksek trafik üreten IP adreslerini not al. Hangi yönde (inbound/outbound) trafik var, bant genişliğinin ne kadarı kullanılıyor?

3. Adım: ss ile Bağlantıları Detaylandır

Şüpheli IP’yi bulduysan:

# O IP ile tüm bağlantılar
ss -tnp dst SUSPICIOUS_IP

# O porta gelen bağlantılar
ss -tnp dport = :PORT_NUMBER

4. Adım: nethogs ile Process’i Bul

nethogs eth0

Process’i bulduktan sonra ps, lsof ve gerekirse strace ile detaylandır.

Gelişmiş ss Kullanımı: Filtreler ve İfadeler

ss çok güçlü bir filtre dili destekliyor. Bu filtreleri bilmek analiz sürecini dramatik ölçüde hızlandırır:

# 1024'ten büyük portlarda ESTABLISHED bağlantılar
ss -t state established '( dport > :1024 or sport > :1024 )'

# Belirli bir subnet ile bağlantılar
ss -t dst 10.0.0.0/8

# Belirli process'in bağlantıları (PID ile)
ss -tp | grep "pid=1234,"

# Çok sayıda bağlantı açan IP'leri bul
ss -tn state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -10

# Yüksek port numaralarındaki bağlantıları listele
ss -tnp '( dport >= :32768 )'

Son komut özellikle zararlı yazılım tespitinde işe yarar. Kötü amaçlı yazılımlar genellikle yüksek port numaralarını kullanır.

Performans Sorunlarının Otomatik Tespiti

Manuel izleme her zaman mümkün değil. Özellikle gece yarısı oluşan sorunlar için basit bir izleme script’i işe yarar:

#!/bin/bash
# network_monitor.sh
# Kullanım: chmod +x network_monitor.sh && ./network_monitor.sh

THRESHOLD_TW=5000      # TIME_WAIT eşiği
THRESHOLD_RECV=10000   # Recv-Q eşiği (byte)
LOG_FILE="/var/log/network_monitor.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

# TIME_WAIT sayısını kontrol et
TW_COUNT=$(ss -t state time-wait | wc -l)
if [ "$TW_COUNT" -gt "$THRESHOLD_TW" ]; then
    echo "$DATE - UYARI: TIME_WAIT sayisi yuksek: $TW_COUNT" >> $LOG_FILE
    ss -s >> $LOG_FILE
fi

# Yüksek Recv-Q olan bağlantıları kontrol et
HIGH_RECV=$(ss -tnp | awk 'NR>1 && $3+0 > '"$THRESHOLD_RECV"' {count++} END {print count+0}')
if [ "$HIGH_RECV" -gt "0" ]; then
    echo "$DATE - UYARI: $HIGH_RECV baglanti yuksek Recv-Q degerine sahip" >> $LOG_FILE
    ss -tnp | awk 'NR>1 && $3+0 > '"$THRESHOLD_RECV"'' >> $LOG_FILE
fi

# Arayüz hatalarını kontrol et
ETH_ERRORS=$(ip -s link show eth0 | grep -A1 "RX:" | tail -1 | awk '{print $3}')
if [ "$ETH_ERRORS" -gt "100" ]; then
    echo "$DATE - UYARI: eth0 RX hata sayisi: $ETH_ERRORS" >> $LOG_FILE
fi

echo "$DATE - Kontrol tamamlandi. TW:$TW_COUNT HighRecv:$HIGH_RECV Errors:$ETH_ERRORS" >> $LOG_FILE

Bu script’i cron’a ekleyerek her 5 dakikada bir çalıştırabilirsin:

# crontab -e
*/5 * * * * /usr/local/bin/network_monitor.sh

Bant Genişliği Tespiti ve Kapasite Planlaması

Sadece sorun tespiti değil, kapasite planlaması için de bu araçları kullanabilirsin:

# Günlük ortalama trafik için nethogs çıktısını kaydet
nethogs -t eth0 >> /var/log/nethogs_daily.log 2>&1 &

# iftop ile peak saatlerde trafik kaydı
iftop -nNt -s 60 -i eth0 2>&1 | grep -E "Total|peak" >> /var/log/bandwidth_daily.log

# Arayüz istatistikleri snapshot
while true; do
    echo "$(date): $(ip -s link show eth0 | grep -A1 'TX:' | tail -1)"
    sleep 60
done >> /var/log/interface_stats.log

Yaygın Ağ Performans Sorunları ve Çözümleri

Yıllar içinde en sık karşılaştığım sorunları ve çözümlerini paylaşayım:

Sorun 1: Çok Fazla TIME_WAIT

ss -s çıktısında binlerce TIME_WAIT görüyorsan:

# Mevcut durumu kontrol et
cat /proc/sys/net/ipv4/tcp_fin_timeout
cat /proc/sys/net/ipv4/tcp_tw_reuse

# Optimize et
sysctl -w net.ipv4.tcp_fin_timeout=15
sysctl -w net.ipv4.tcp_tw_reuse=1

Sorun 2: SYN Flood veya Bağlantı Kuyruk Dolması

# SYN_RECV durumundaki bağlantıları sayarken
ss -t state syn-recv | wc -l

# SYN cookie'leri etkinleştir
sysctl -w net.ipv4.tcp_syncookies=1

# Backlog kuyruğunu büyüt
sysctl -w net.ipv4.tcp_max_syn_backlog=4096

Sorun 3: Buffer Boyutları Yetersiz

# Mevcut TCP buffer boyutları
cat /proc/sys/net/ipv4/tcp_rmem
cat /proc/sys/net/ipv4/tcp_wmem

# Yüksek throughput için optimize
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 87380 16777216"

Araçların Sınırlılıkları

Dürüst olmak gerekirse bu araçların da sınırlılıkları var:

ss kernel space’de çalışan şeyleri gösterir. Container ortamlarında her container kendi network namespace’ine sahipse, host’ta ss çalıştırmak container içindeki bağlantıları göstermeyebilir. Bunun için:

# Belirli bir container'ın namespace'inde ss çalıştır
nsenter -t CONTAINER_PID -n ss -tnp

iftop promiscuous mode gerektirmeyebilir ama switched ağlarda sadece kendi arayüzündeki trafiği görür. Span port veya network tap olmadan tüm ağ trafiğini göremezsin.

nethogs bazı eski kernel versiyonlarında bazı network türleriyle düzgün çalışmayabilir. Özellikle tunnel arayüzleri veya VPN bağlantılarında sınırlı bilgi verebilir.

Sonuç

ss, iftop ve nethogs üçlüsü ağ sorunlarını katmanlı şekilde incelemenizi sağlar. ss ile soket seviyesinde gerçekten ne olduğunu anlarsın, iftop ile hangi IP adreslerinin bant genişliği tükettiğini görürsün, nethogs ile sorumlu process’i parmakla işaret edersin.

Bu araçları reaktif değil proaktif kullanmayı öğren. Sorun çıkmadan önce normal trafik profilini biliyorsan, anormallikleri çok daha hızlı tespit edersin. Basit bir cron job ile bu araçların çıktılarını düzenli olarak kaydetmek, gelecekteki sorun tespitlerinde sana inanılmaz avantaj sağlar.

Son olarak şunu belirteyim: Bu araçlar teşhis araçlarıdır. Sorunun ne olduğunu söylerler ama çözümün ne olması gerektiğini söylemezler. Bulguları uygulama davranışı, altyapı değişiklikleri ve sistem loglarıyla birleştirerek yorumlamak sysadmin’in asıl işidir. Araçları ne kadar iyi bilirsen bil, bağlamı anlama becerisinin yerini hiçbir şey tutamaz.

Yorum yapın