Ağ Yavaşlığının Gerçek Nedenini Bulmanın 7 Yolu

Kullanıcılar ağın yavaşladığından şikayet ettiğinde, yapabileceğim en kötü şey tahmin yürütmeye başlamaktır. Benim ortamımda, ağ yavaşlığının gerçek nedenini bulmanın bir kontrol listesi üzerinden gitmek demek olduğunu öğrendim — direkt ping komutuna atlayıp umut etmek değil. Çoğu "ağ yavaş" talebi aslında DNS, doymuş bir uplink, yanlış yapılandırılmış duplex ayarı veya ağ sorunu gibi görünen bir uygulama problemi çıkıyor. İşte gerçek darboğazı sistemli olarak tespit etmek için kullandığım yedi yöntem.

Latency İçin Ping ve Traceroute ile Başla

Bu temel bir adım ama her seferinde buradan başlıyorum. Kullanıcının şikayet ettiği hedefe ping at, sonra bilinen sağlıklı bir referans host ile karşılaştır.

ping -c 10 8.8.8.8
ping -c 10 internal-app.local
mtr -r -c 100 remote-site-gateway

Burada aradığım şey ping'in başarılı olup olmadığı değil — desen. Sürekli 2ms latency sorun değil. 2ms'den 200ms'ye anlık sıçramalar bana bir yerlerde buffer bloat, congestion veya flapping link olduğunu söyler. mtr, bu iş için düz traceroute'tan daha iyidir çünkü sürekli çalışır ve her hop için paket kaybını gösterir.

İpucu: Eğer kayıp hop 4'te başlıyorsa ve sonraki her hop'ta devam ediyorsa, sorun hop 3 ile hop 4 arasındadır. Hedefi suçlama.

iftop ve nload ile Bant Genişliği Doygunluğunu Kontrol Et

Latency normal olabilir ama uplink'in sınırını dolduysa her şey sürünür. Edge router veya firewall'a giriş yapıp interface kullanımını kontrol ederim.

iftop -i eth0 -n
nload -u M

iftop bana hangi bağlantıların bant genişliğini sömürdüğünü gösterir. 1 Gbps link üzerinde tek bir IP'nin 900 Mbps çektiğini görürsem, suçluyu bulmuşum demektir. Bazen bu, birinin öğlen saatine planladığı bir backup job'dur. Bazen de devasa bir dosya indiren bir kullanıcıdır. Nasıl olursa olsun, sorunu çözmeden önce trafiği görmem lazım.

SNMP kuruluysa (ki kurmalıyız), vnstat veya Zabbix, PRTG gibi monitoring platform'unuz size geçmiş verileri verir — bu da sorun aralıklı olduğunda çok önemli hale gelir.

DNS Resolution Gecikmelerini İncele

Bu beni itiraf etmekten daha sık ısırır. Kullanıcı "internet yavaş" der ama aslında DNS yavaştır. Sayfa parça parça yüklenir çünkü her yeni hostname'i çözmek 5ms yerine 300ms alar.

dig +trace example.com
dig @8.8.8.8 example.com
time nslookup internal-service.local

Harici bir DNS resolver'ı sorgulamak hızlıysa ama internal resolver yavaşsa, local DNS sunucuna bak. Dead bir upstream'e mi forward ediyor? Aşırı yüklenmiş mi? Bir zamanlar "ağ yavaşlığı" sorunu diye iki saat kovaladığım bir olay, haftalar önce decommission edilmiş bir sunucuyu işaret eden bir DNS forwarder çıkmıştı.

Paket Kaybı ve Interface Hatalarını Ara

Paket kaybı sessiz bir katildir. Küçük miktarlar — %0.5 bile — retransmission nedeniyle TCP throughput'u mahvedebilir. Yoldaki her cihazda interface istatistiklerini kontrol ederim.

ip -s -s link show eth0
show interfaces counters | include error

Cisco cihazlarda input error, output error, CRC error ve runt ararım. Linux'ta dropped packet, overrun ve frame error'a bakarım. CRC error'ların arttığını görürsem, bu neredeyse her zaman bir kablo sorunu veya duplex mismatch'tır.

MTU ve Path MTU Discovery'yi Doğrula

MTU sorunları "büyük transferler yavaş ama küçük olanlar sorunsuz" şeklinde ortaya çıkar. Bir kullanıcı sunucuyu pingleyebiliyorsa ama büyük dosyaları takılmadan transfer edemiyorsa, MTU'dan şüphelenirim.

ping -M do -s 1472 10.0.0.50
ip route get 10.0.0.50

1472-byte paketler düşüyorsa ama 1400 çalışıyorsa, bir path MTU sorunu vardır — muhtemelen bir VPN tüneli veya yolda bir yerde daha küçük MTU'ya sahip bir tunnel interface. ICMP "fragmentation needed" paketleri bir firewall tarafından engelleniyor olabilir, bu da Path MTU Discovery'yi tamamen bozar.

Daha önce Windows Server performans katilleri hakkındaki yazımda (https://furkanikkan.com/urun/windows-server-performans-katilleri-hemen-duzeltmen-gereken-gizli-ayarlar-44) belirttiğim gibi, TCP autotuning ve chimney offload gibi OS-level ayarlar da ağ problemi gibi görünen garip throughput sorunları yaratabilir.

Uygulama Trafiğini İncelemek için tcpdump ve Wireshark Kullan

Yukarıdakilerin hepsi normal çıkıp sorun devam ediyorsa, kabloda gerçekte ne aktığına bakma zamanıdır. Sunucu tarafında tcpdump, ardından pcap'i Wireshark'a çek.

tcpdump -i eth0 -w /tmp/capture.pcap host 10.0.0.50 and port 443
tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn-ack'

Aradığım şeyler:

TCP retransmission ve duplicate ACK — bir yerde kayıp olduğunu gösterir
Çok küçük window boyutları — alıcı yetişemiyor
Alışılmadık reset paketleri — firewall veya middleware müdahale ediyor
TLS handshake'in çok fazla round trip alması — sertifika zinciri veya SNI sorunları

Burada network-level tanı, application-level tanı ile buluşur. Ağ temiz ama uygulama yavaşsa, sorun ağda değil — uygulama, veritabanı veya sunucunun kendisinde.

Monitoring ve Geçmiş Baseline ile Korelasyon Yap

Son yöntem bana en çok zaman kazandıran: sorun olmadan önce monitoring verisine sahip olmak. "Normal"'in nasıl göründüğünü bilmeden bir yavaşlık sorununu düzgün teşhis edemezsin.

Sorun çıkmadan önce monitoring için kontrol listem:

Tüm kritik linklerde SNMP tabanlı bant genişliği polling — en az 1 dakika granularity
Birden fazla siteden kritik servislere latency monitoring
Internal resolver'larda DNS response time tracking
Interface error counter'ları sadece up/down değil, eşiklerde alert veren
Edge cihazlarda trafik analizi için NetFlow veya sFlow export
Uygulama response time monitoring — sadece availability değil
Desen karşılaştırması için en az 30 gün saklanan geçmiş veri

Bir kullanıcı yavaşlık bildirdiğinde, monitoring dashboard'unu açarım ve mevcut metrikleri geçen haftanın baseline'ı ile karşılaştırırım. Bant genişliği normal, latency normal, DNS normal ve error sıfırsa — application team'e geri dönerim. Ağ her zaman kötü adam değildir ve iyi veri bunu kanıtlar.

Anahtar çıkarım: acele kararlar verme. Sorunu yukarıdan aşağıya çalış — latency, bant genişliği, DNS, hatalar, MTU, packet capture ve geçmiş veri. Çoğu zaman gerçek neden bu katmanlardan birinde gizlidir ve sistemli bir yaklaşım onu tahmin yürütmekten her zaman daha hızlı bulur.

Kapak görseli: ₡ґǘșϯγ Ɗᶏ Ⱪᶅṏⱳդ · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/148598741@N02/52879212541