Yavaş Ağ Bağlantısı: Bant Genişliği ve Gecikme Analizi

Ağın yavaşladığını fark ettiğinizde ilk içgüdü genellikle “ISP’yi ara” ya da “router’ı resetle” olmaktadır. Ancak gerçek hayatta sorun çok daha katmanlı olabiliyor. Bant genişliği doygunluğu mu var, gecikme mi artmış, paket kaybı mı yaşanıyor? Bunları birbirinden ayırt etmeden doğru çözüme ulaşmak neredeyse imkansız. Bu yazıda, yavaş ağ bağlantısını sistematik bir şekilde analiz etmek için kullanabileceğiniz araçları ve gerçek dünya senaryolarını ele alacağız.

Temel Kavramlar: Bant Genişliği mi, Gecikme mi?

Çoğu zaman “ağ yavaş” şikayeti aslında iki farklı problemi tanımlıyor olabilir. Bant genişliği (bandwidth), belirli bir zaman diliminde aktarılabilen maksimum veri miktarıdır. Gecikme (latency) ise bir paketin kaynaktan hedefe ulaşma süresidir.

Pratik bir örnek verelim: Büyük dosya transferleri yavaşsa muhtemelen bant genişliği sorununuz var. Ama web sayfaları küçük olmasına rağmen geç açılıyorsa, SSH oturumunda komutlar geç yanıt veriyorsa, sorun gecikme veya paket kaybıdır. Bu ayrımı yapmadan doğru teşhisi koymak mümkün değil.

Adım 1: Temel Bağlantı Testi

Her şeyden önce bağlantının var olup olmadığını ve temel gecikme değerlerini ölçmek gerekiyor. Klasik ping komutu hala en hızlı başlangıç noktası.

# Basit gecikme testi - 100 paket gönder
ping -c 100 8.8.8.8

# Paket boyutunu büyüterek test et (MTU sorunlarını yakalamak için)
ping -c 20 -s 1472 8.8.8.8

# Flood ping - sadece root ile, LAN içi testler için
ping -f -c 1000 192.168.1.1

ping çıktısındaki min/avg/max/mdev değerlerine dikkat edin. mdev (mean deviation) değeri yüksekse, yani gecikme tutarsızsa, bu jitter probleminiz olduğunu gösterir. Jitter, VoIP ve video konferans gibi gerçek zamanlı uygulamaları mahveden bir sorundur.

Örnek çıktı yorumu:

• rtt min/avg/max/mdev = 2.1/2.4/18.7/3.2 ms – mdev değeri 3.2 ms, ciddi jitter var
• %5 packet loss – Paket kaybı var, bu kritik bir bulgudur

Adım 2: Traceroute ile Yol Analizi

Ping sorun olduğunu gösterdi, ama sorunun nerede olduğunu bulmamız gerekiyor. traceroute ve mtr burada devreye giriyor.

# Klasik traceroute
traceroute -n 8.8.8.8

# UDP yerine ICMP kullan (bazı firewall'lar UDP'yi bloklayabilir)
traceroute -I -n 8.8.8.8

# TCP ile traceroute (80 portuna) - en fazla firewall'ı aşar
traceroute -T -p 80 -n 8.8.8.8

# Linux'ta mtr - hem traceroute hem ping kombine
mtr --report --report-cycles 100 8.8.8.8

mtr burada altın değerinde bir araç. --report parametresiyle 100 döngü boyunca her hop’a gecikme ve paket kaybı istatistiklerini toplar. Çıktıda şunu arayın: Belirli bir hop’tan sonra kayıp oranı artıyorsa, sorun o hop’ta veya öncesindedir. Eğer bir hop’ta kayıp var ama sonraki hop’larda kayıp yoksa, o router sadece ICMP’ye düşük öncelik veriyordur, gerçek bir sorun değildir.

Gerçek dünya senaryosu: Bir müşteri “internete çıkamıyoruz” dedi. mtr çıktısı incelendiğinde, ISP’nin 3. hop’unda %30 paket kaybı görüldü. Sorun bizim altyapımızda değil, ISP’nin omurgasındaydı. Bu raporla ISP’yi aradık ve 2 saat içinde sorun çözüldü. mtr raporu olmadan bu kanıtı göstermek çok daha zor olurdu.

Adım 3: Bant Genişliği Ölçümü

Bağlantı kalitesini anladıktan sonra gerçek bant genişliğini ölçme zamanı.

# iperf3 ile bant genişliği testi - sunucu tarafı
iperf3 -s -p 5201

# iperf3 ile bant genişliği testi - istemci tarafı
iperf3 -c sunucu_ip -t 30 -P 4

# Paralel bağlantı sayısını artır (gerçek dünya trafiğini simüle eder)
iperf3 -c sunucu_ip -t 60 -P 8 --bidir

# UDP testi - jitter ve paket kaybı için
iperf3 -c sunucu_ip -u -b 100M -t 30

iperf3 parametrelerini açıklayalım:

• -t 30: 30 saniye boyunca test yap
• -P 4: 4 paralel akış kullan
• –bidir: Hem upload hem download’u aynı anda test et
• -u: UDP modu kullan
• -b 100M: UDP için hedef bant genişliğini 100 Mbps olarak belirle

Eğer ağınızda iperf3 sunucusu yoksa, speedtest-cli de işe yarar:

# speedtest-cli kurulumu ve kullanımı
pip3 install speedtest-cli
speedtest-cli --simple

# Belirli bir sunucuya test yap
speedtest-cli --server 1234 --verbose

Adım 4: Gerçek Zamanlı Trafik İzleme

Teorik maksimum bant genişliğini bilmek yeterli değil. Şu an gerçekte ne oluyor, bunu görmemiz lazım.

# iftop - arayüz bazında gerçek zamanlı bant genişliği
iftop -i eth0 -n -P

# nethogs - process bazında bant genişliği kullanımı
nethogs eth0

# nload - basit ve temiz bant genişliği grafiği
nload eth0

# vnstat - günlük/aylık trafik istatistikleri
vnstat -i eth0 -l  # live mod
vnstat -i eth0 -h  # saatlik istatistik

nethogs özellikle kritik bir araç. “Ağ yavaş” şikayetinin çoğu zaman arkasında tek bir process’in tüm bant genişliğini yiyor olması vardır. nethogs ile hangi uygulamanın kaç KB/s kullandığını process bazında görebilirsiniz.

Gerçek dünya senaryosu: Bir web sunucusu saatlerdir yavaş yanıt veriyordu. nethogs çalıştırdık, bir backup scriptinin gece çalışmak yerine gündüz çalıştığını ve 900 Mbps’lik bağlantının 850 Mbps’ini kullandığını gördük. Cron job’u düzeltmek 5 dakika sürdü, sorun anında çözüldü.

Adım 5: Paket Analizi ile Derinlemesine İnceleme

Sorun daha gizliyse, tcpdump ve wireshark devreye giriyor.

# Temel paket yakalama
tcpdump -i eth0 -n -c 1000 -w /tmp/capture.pcap

# Belirli bir host'a giden trafiği yakala
tcpdump -i eth0 -n host 8.8.8.8 -w /tmp/dns_traffic.pcap

# Yüksek RTT olan TCP bağlantılarını izle
tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0'

# DNS sorgularını izle - yavaş DNS genellikle gözden kaçar
tcpdump -i eth0 -n port 53

# TCP retransmission'ları yakala
tcpdump -i eth0 -n 'tcp[13] & 4 != 0'

TCP retransmission’lar özellikle önemli. Eğer çok sayıda retransmission görüyorsanız, bu paket kaybının ciddi boyutlarda olduğunu gösterir. Wireshark’ta bu .pcap dosyasını açıp “Statistics > TCP Stream Graphs > Time-Sequence Graph” ile görselleştirebilirsiniz.

ss ve netstat ile mevcut bağlantı durumlarını kontrol etmek de önemli:

# Tüm TCP bağlantılarını ve durumlarını göster
ss -tupn

# Sadece ESTABLISHED bağlantılar
ss -tupn state established

# Bekleyen bağlantıları say - SYN flood kontrolü
ss -n state syn-recv | wc -l

# Soketlerin kuyruk durumunu kontrol et
ss -tlnp

ss -tlnp çıktısındaki Recv-Q değeri sürekli yüksekse, sunucu gelen bağlantıları işleyemez hale gelmiştir. Bu bant genişliği sorunu değil, uygulama veya sistem kaynak sorunudur.

Adım 6: DNS Gecikme Analizi

“Ağ yavaş” şikayetlerinin tahmin edilenden çok daha fazlası aslında DNS gecikme sorunudur. Web sitesi ilk açılışta yavaş ama sonraki ziyaretlerde hızlıysa, DNS’i şüphelenin.

# DNS sorgu süresini ölç
time dig google.com @8.8.8.8

# Farklı DNS sunucularını karşılaştır
for dns in 8.8.8.8 1.1.1.1 9.9.9.9 192.168.1.1; do
    echo -n "DNS $dns: "
    dig +stats google.com @$dns | grep "Query time"
done

# DNS trace - hangi sunucudan cevap geliyor
dig +trace google.com

# Yerel DNS önbelleğini kontrol et
systemd-resolve --statistics

Gerçek dünya senaryosu: Bir şirkette tüm kullanıcılar “internet yavaş” diye şikayet ediyordu ama speedtest normal değer gösteriyordu. time dig komutuyla DNS sorgu süresini ölçtük, yerel DNS sunucusu 800-1200 ms arası yanıt veriyordu. Sorun, şirket içi DNS sunucusunun upstream DNS’e bağlantısındaki bir routing sorunuydu. DNS sunucusunu Cloudflare’e (1.1.1.1) yönlendirmek sorunu anında çözdü.

Adım 7: Ağ Arayüzü ve Donanım Kontrolü

Yazılım tarafında sorun bulamadıysanız, donanıma bakmak gerekiyor.

# Ağ kartı istatistiklerini görüntüle
ethtool -S eth0

# Ağ kartının hız ve duplex ayarlarını kontrol et
ethtool eth0

# Otomatik müzakere durumu ve hız
ethtool eth0 | grep -E "Speed|Duplex|Auto"

# Hata sayaçlarını kontrol et
ip -s link show eth0

# Driver ve firmware bilgisi
ethtool -i eth0

ethtool eth0 çıktısında Speed: 100Mb/s görüyorsanız ama Gigabit ağınız varsa, auto-negotiation hatası yaşıyorsunuzdur. Hız ve duplex’i manuel ayarlamak gerekebilir:

# Hız ve duplex'i manuel ayarla (geçici)
ethtool -s eth0 speed 1000 duplex full autoneg off

# ip link ile MTU kontrolü
ip link show eth0 | grep mtu

# MTU boyutunu değiştir
ip link set eth0 mtu 9000  # Jumbo frames için

Half-duplex modunda çalışan bir ağ kartı, aynı anda hem gönderip hem alamadığı için ciddi performans kaybına yol açar. ethtool çıktısında Duplex: Half görüyorsanız, bu ciddi bir bulgudur.

Adım 8: Sistem Kaynaklarının Ağ Performansına Etkisi

Bazen ağın kendisi sorunsuz, ama sistem ağ trafiğini işleyemiyor olabilir.

# CPU interrupt dağılımını kontrol et - ağ kartı hangi CPU'yu kullanıyor
cat /proc/interrupts | grep eth0

# Ağ kartı için IRQ affinity ayarla
# Önce hangi IRQ numarasını kullandığını bul
grep eth0 /proc/interrupts

# Ağ tamponu boyutlarını kontrol et
sysctl net.core.rmem_max
sysctl net.core.wmem_max
sysctl net.core.netdev_max_backlog

# Ağ performansı için kernel parametrelerini optimize et
cat >> /etc/sysctl.d/99-network-performance.conf << EOF
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
EOF

sysctl -p /etc/sysctl.d/99-network-performance.conf

Yüksek trafik altında softirq CPU kullanımı aşırı yükseliyorsa (top komutunda si değeri), NIC’in RSS (Receive Side Scaling) özelliğini aktifleştirmek veya birden fazla CPU core’a interrupt dağıtmak faydalı olabilir.

Sorun Giderme Akışı: Gerçek Bir Senaryo

Diyelim ki sabah 09:00’da “VPN üzerinden yapılan video konferanslar donuyor” şikayeti geldi. İşte adım adım nasıl yaklaşırım:

1. Hızlı kontrol:

# Önce VPN gateway'e ping at
ping -c 50 vpn.sirket.com

# mtr ile VPN yolunu izle
mtr --report --report-cycles 50 vpn.sirket.com

Diyelim ki ping %0 kayıp ama mdev 45 ms. Bu jitter problemi. VoIP ve video için jitter 20 ms’nin altında olmalı.

2. ISP segmenti mi, yerel ağ mı?

# Default gateway'e (router) ping
ping -c 50 192.168.1.1

# ISP'nin ilk hop'una ping
mtr --report -c 50 8.8.8.8

Gateway’e ping pürüzsüzse sorun ISP tarafında demektir. mtr raporunu alıp ISP destek hattını arayın, elinizdeki veriyle çok daha hızlı destek alırsınız.

3. Yerel ağda sorun varsa:

# Switch üzerinde hangi port sorunlu?
# Önce MAC adresini bul
arp -n | grep sorunlu_ip

# Switch port istatistiklerini kontrol et (SNMP ile)
snmpwalk -v2c -c public switch_ip ifInErrors
snmpwalk -v2c -c public switch_ip ifOutErrors

Yüksek CRC hatası veya input error sayısı fiziksel kablo veya SFP sorununa işaret eder.

Windows Tarafında Ağ Analizi

Sysadmin çoğu zaman mixed environment yönetiyor. Windows tarafında da işler yapılacak.

# PowerShell ile bant genişliği ve gecikme testi
Test-NetConnection -ComputerName google.com -TraceRoute

# Windows'ta ağ istatistikleri
netstat -e
netstat -s | findstr /i "failed|discarded|error"

# DNS sorgu süresi PowerShell ile
Measure-Command { Resolve-DnsName google.com }

# Windows'ta iperf3 çalıştır (binary indirildikten sonra)
.iperf3.exe -c sunucu_ip -t 30 -P 4

netstat -s çıktısındaki Segments Retransmitted değeri yüksekse, Windows tarafında da TCP retransmission sorunu yaşanıyordur.

Otomasyon: Sürekli İzleme için Basit Script

Tek seferlik testler yeterli değil, sorun aralıklıysa yakalayabilmek için sürekli izleme şart.

#!/bin/bash
# Basit ağ kalitesi izleme scripti
# /usr/local/bin/network_monitor.sh

TARGET="8.8.8.8"
LOG="/var/log/network_quality.log"
THRESHOLD_LOSS=5
THRESHOLD_LATENCY=100

while true; do
    TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
    
    # 10 paket gönder, istatistikleri çek
    PING_OUT=$(ping -c 10 -q $TARGET 2>&1)
    LOSS=$(echo "$PING_OUT" | grep -oP 'd+(?=% packet loss)')
    RTT=$(echo "$PING_OUT" | grep -oP 'avg = K[d.]+' | cut -d'/' -f2)
    
    echo "$TIMESTAMP | Loss: ${LOSS}% | RTT: ${RTT}ms" >> $LOG
    
    # Eşik değerleri aşıldığında uyar
    if [ "$LOSS" -gt "$THRESHOLD_LOSS" ] || 
       [ "$(echo "$RTT > $THRESHOLD_LATENCY" | bc)" -eq 1 ]; then
        echo "$TIMESTAMP UYARI: Ağ kalitesi düşük!" | 
        mail -s "Ağ Uyarısı" [email protected]
    fi
    
    sleep 60
done

Bu scripti systemd service olarak ya da screen/tmux içinde çalıştırabilirsiniz. Log dosyasını düzenli inceleyerek sorunun ne zaman başladığını, ne kadar sürdüğünü ve ne zaman bittiğini görebilirsiniz. Bu veriler ISP ile konuşurken çok işe yarıyor.

Sonuç

Yavaş ağ sorunlarını çözmek, metodoloji gerektiren bir iştir. Rastgele “router resetle”, “DNS değiştir” tavsiyelerini uygulamak yerine önce ölçün, sonra analiz edin, sonra müdahale edin.

Özet olarak kontrol listeniz şöyle olmalı:

• Ping ve mtr ile gecikme ve paket kaybını ölçün
• iperf3 ile gerçek bant genişliğini test edin
• nethogs ve iftop ile kimin bant genişliğini yuttuğunu bulun
• tcpdump ile TCP retransmission ve paket kayıplarını yakalayın
• time dig ile DNS gecikmesini kontrol edin
• ethtool ile donanım seviyesini inceleyin
• Sistematik izleme ile aralıklı sorunları yakalayın

Unutmayın: ISP’ye ya da kullanıcıya “ağ yavaş” demenin hiçbir değeri yok. Ama “mtr raporuna göre ISP’nin 3. hop’unda %15 paket kaybı var, aynı zamanda 09:00-11:00 arası her gün yaşanıyor ve network_quality.log dosyamda bunu kanıtlayan 2 haftalık veri var” dediğinizde, sorun çok daha hızlı çözülüyor. Veriler konuşur.