Ping ve Traceroute ile Gecikme Ölçümü

"Site yavaş" cümlesi tek başına bir teşhis değildir. Yavaşlık sunucunun kendisinden, aradaki ağdan, ziyaretçinin operatöründen ya da tamamen tarayıcı tarafındaki bir kaynaktan geliyor olabilir. Bu dört ihtimali birbirinden ayırmanın en hızlı ve en ucuz yolu, elinizin altında zaten var: ping ve traceroute. Doğru kullanıldıklarında bu iki komut, problemin sizde mi karşı tarafta mı yoksa arada bir yerde mi olduğunu dakikalar içinde söyler.

Bu rehberde iki komutun çıktısını satır satır okumayı, mtr ile ikisini nasıl birleştireceğinizi ve en önemlisi çıktıyı yanlış yorumlamanın klasik tuzaklarını anlatacağım. Özellikle "ortadaki atlamalar yüksek gecikme gösteriyor, sorun orada" gibi çok yaygın ama çoğu zaman tamamen hatalı olan yorumu düzelteceğim. Sonunda elinizde, bir gecikme şikâyeti geldiğinde izleyeceğiniz somut bir teşhis sırası olacak.

ping: Temel Ölçüm ve Çıktının Anlamı#

ping, hedefe ICMP echo isteği gönderir ve cevabın dönmesi için geçen süreyi ölçer. Ölçtüğü şey gidiş-dönüş süresidir (RTT). Tek bir paket hiçbir şey söylemez; her zaman bir dizi paket gönderip dağılıma bakın.

# Linux/macOS: 20 paket gönder
ping -c 20 firmaniz.com

# Windows: 20 paket
ping -n 20 firmaniz.com

Çıktının anlamlı kısmı sondaki özet satırlarıdır:

--- firmaniz.com ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 11.842/13.204/19.771/1.612 ms

Bu dört sayıyı birlikte okuyun:

Kritik nokta şudur: ortalama düşük olsa bile sapma yüksekse deneyim kötüdür. min 11 / avg 13 / max 19 / mdev 1.6 sağlıklı bir tablodur. Buna karşılık min 12 / avg 68 / max 340 / mdev 92 çok daha kötüdür; ortalama iki katına çıkmış görünse de asıl problem 340 ms'lik sıçramalar ve büyük sapmadır. Video görüşmesi, oyun ya da etkileşimli panel kullanımında kullanıcıyı rahatsız eden şey ortalama değil, bu sıçramalardır.

Paket kaybı ise en ciddi bulgudur. TCP, kaybolan paketi yeniden gönderir ama bunu fark etmesi ve yeniden göndermesi zaman alır; %1 kayıp bile web sayfası yüklenmesinde belirgin duraklamalar üretir. Kayıp gördüğünüzde ölçümü uzatın ve farklı saatlerde tekrarlayın:

# Uzun soluklu ölçüm: 5 dakika boyunca saniyede bir paket
ping -c 300 firmaniz.com | tail -3

# Sadece özet satırlarını al, arka planda çalıştırıp sonra bak
ping -c 600 -i 1 185.12.34.56 > /tmp/ping-olcum.txt 2>&1 &

ping'in Yanıltabileceği Durumlar#

ping basitliği yüzünden fazla güvenilir sanılır; oysa üç önemli sınırı vardır ve bunları bilmeden yapılan yorum yanlış olur.

Birincisi, ICMP filtrelenebilir. Birçok sunucu, özellikle Windows Server kurulumları ve güvenlik duvarı kuralları sıkı yapılandırılmış makineler, ICMP echo isteklerine hiç cevap vermez. Bu durumda ping "100% packet loss" der ama sunucu gayet sağlıklı çalışıyor olabilir; web sitesi açılır, SSH bağlanır. Yani ping cevapsızlığı "sunucu kapalı" demek değildir. Doğru yorum "ICMP ile ulaşamadım"dır.

Sunucunun gerçekten ayakta olup olmadığını anlamak için TCP düzeyinde deneyin:

# Belirli bir porta TCP bağlantısı kurulabiliyor mu (ICMP'den bağımsız)
nc -zv -w 3 firmaniz.com 443
# Connection to firmaniz.com 443 port [tcp/https] succeeded!

# Alternatif: hping3 ile TCP SYN "ping"
hping3 -S -p 443 -c 5 firmaniz.com

# En pratik: HTTP düzeyinde ölçüm
curl -o /dev/null -s -w 'ilk_bayt: %{time_starttransfer}s\n' https://firmaniz.com/

İkincisi, ICMP düşük öncelikli olabilir. Yönlendiriciler, ICMP cevabını üretmeyi kendi CPU'sunda yapar ve bu işi trafik iletmeye göre düşük öncelikli sayabilir. Yani yüksek bir ping süresi, o cihazdan geçen gerçek trafiğin de yavaş olduğu anlamına gelmez.

Üçüncüsü, ping yalnızca ağ katmanını ölçer. Sunucunuz 12 ms'de cevap veriyor ama siteniz 3 saniyede açılıyorsa, sorun ağda değil uygulamada demektir. Bu ayrım teşhisin ilk adımıdır: ping düşük ama curl ile ölçtüğünüz ilk bayt süresi yüksekse ağa hiç bakmayın, doğrudan sunucu tarafına yönelin. Lokasyon ve mesafe ilişkisini sunucu lokasyonu ve gecikme yazısında ele aldım; sunucu üretim süresi yüksekse veritabanı sorguları sayfa hızını nasıl etkiler yazısındaki sıraya geçin.

traceroute: Paketin İzlediği Yolu Görmek#

traceroute, paketin hedefe giderken geçtiği yönlendiricileri sırayla listeler. Çalışma mantığı zekicedir: TTL (Time To Live) değeri 1 olan bir paket ilk yönlendiricide ölür ve o yönlendirici "süre doldu" hatası döner; böylece kim olduğunu öğrenirsiniz. Sonra TTL 2 ile ikinci atlamayı, TTL 3 ile üçüncüyü öğrenir ve hedefe ulaşana kadar devam edersiniz.

# Linux (UDP varsayılan)
traceroute firmaniz.com

# ICMP ile (bazı ağlarda UDP engellidir)
traceroute -I firmaniz.com

# TCP 443 ile — güvenlik duvarlarını en iyi geçen yöntem
sudo traceroute -T -p 443 firmaniz.com

# Windows
tracert firmaniz.com

Örnek bir çıktı ve nasıl okunacağı:

traceroute to firmaniz.com (185.12.34.56), 30 hops max, 60 byte packets
 1  192.168.1.1              1.204 ms   1.118 ms   1.092 ms
 2  10.44.0.1                8.412 ms   8.377 ms   8.501 ms
 3  * * *
 4  81.212.x.x              12.744 ms  12.801 ms  12.688 ms
 5  212.156.x.x             14.229 ms  14.104 ms  62.918 ms
 6  195.175.x.x             15.881 ms  15.902 ms  15.774 ms
 7  185.12.34.56            16.402 ms  16.318 ms  16.377 ms

Satır satır: birinci atlama kendi yönlendiricinizdir. İkinci atlama operatörünüzün ilk cihazıdır. Üçüncü satırdaki yıldızlar, o cihazın TTL aşımı bildirimi göndermediğini ya da hızlıca cevap vermediğini gösterir. Son satır hedeftir ve toplam RTT'nizi verir.

Her satırda üç süre görmenizin sebebi, traceroute her atlama için varsayılan olarak üç paket göndermesidir. Aralarındaki fark size o noktadaki kararlılığı söyler; beşinci satırda üçüncü ölçümün 62 ms olması anlık bir kuyruklanmadır.

En Yaygın Yorumlama Hatası: Ortadaki Yüksek Değerler#

Şimdi en önemli bölüme geldik, çünkü traceroute çıktısı en sık burada yanlış okunur. Şöyle bir çıktı gördüğünüzü varsayalım:

 5  212.156.x.x            14.229 ms
 6  10.255.0.9            186.554 ms      <-- "işte sorun burada!"
 7  195.175.x.x            15.881 ms
 8  185.12.34.56           16.402 ms

Altıncı atlamada 186 ms görüp "problem o cihazda" demek çok cazip ama yanlıştır. Nedeni şudur: her satırdaki süre, o cihazın kendi ICMP cevabını üretme süresini içerir; paketin oradan hedefe gidip gelmesini değil. Yönlendiriciler asıl işlerini (paket iletme) donanımda çok hızlı yaparken, TTL aşımı bildirimi üretmeyi yazılım katmanında ve düşük öncelikle yapar. Meşgul bir çekirdek yönlendirici, kendisine sorulan soruya geç cevap verirken üzerinden geçen trafiği milisaniyenin altında iletiyor olabilir.

Kanıt zaten aynı çıktının içindedir: yedinci ve sekizinci atlamalar 15–16 ms'ye geri dönmüştür. Altıncı atlama gerçekten 186 ms gecikme ekliyor olsaydı, ondan sonraki tüm atlamaların da en az 186 ms olması gerekirdi; çünkü paket oradan geçmek zorunda.

Doğru okuma kuralı şudur:

1. Yüksek değer bir atlamada başlayıp sonuna kadar devam ediyorsa gerçek bir gecikme artışı vardır ve o noktadan sonrası etkilenmiştir.
2. Yüksek değer tek bir atlamada görünüp sonra düşüyorsa bu yalnızca o cihazın ICMP cevap üretme yavaşlığıdır; görmezden gelin.
3. Yıldızlar (* * *) tek başına problem değildir; birçok cihaz TTL aşımı bildirimi göndermeyecek şekilde yapılandırılmıştır. Hedefe ulaşabiliyorsanız aradaki yıldızlar önemsizdir.
4. Son satır hedefe ulaşmıyorsa ve sürekli yıldız görüyorsanız, hedef ICMP/UDP'yi engelliyor olabilir; -T -p 443 ile TCP denemesi yapın.

Bir de asimetrik yol meselesi var: paketin gidiş yolu ile dönüş yolu farklı olabilir ve traceroute yalnızca gidişi gösterir. Sorun dönüş yolundaysa çıktıda hiç görünmez. Bu yüzden ciddi bir ağ sorununda karşı taraftan da size doğru bir traceroute alınması istenir; iki yönün karşılaştırılması sorunun hangi yönde olduğunu ortaya çıkarır.

mtr: İkisini Birleştiren Doğru Araç#

traceroute anlık bir fotoğraf çeker; oysa ağ sorunları genellikle aralıklıdır. mtr (My TraceRoute), traceroute ile ping'i birleştirir: yolu bulur ve sürekli paket göndererek her atlama için kayıp oranı ve gecikme istatistiği tutar. Aralıklı sorunları yakalamak için doğru araç budur.

# Kurulum
apt install mtr-tiny        # Debian/Ubuntu
dnf install mtr             # RHEL/Rocky/Alma

# 200 paketlik rapor üret ve çık (paylaşmak için ideal)
mtr --report --report-cycles 200 firmaniz.com

# TCP 443 ile ölç (ICMP engelli ağlarda)
sudo mtr --report --report-cycles 100 -T -P 443 firmaniz.com

Örnek rapor:

HOST: istemci                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%   200    1.1   1.2   1.0   3.4   0.2
  2.|-- 10.44.0.1                  0.0%   200    8.4   8.6   8.1  14.2   0.6
  3.|-- 81.212.x.x                12.0%   200   12.7  13.1  12.2  48.9   3.1
  4.|-- 212.156.x.x               12.5%   200   14.2  14.4  13.8  52.1   3.3
  5.|-- 185.12.34.56              12.0%   200   16.4  17.9  15.9  61.7   4.8

Bu rapor gerçek bir problem gösteriyor. Üçüncü atlamada başlayan %12 kayıp, sonraki tüm atlamalarda devam ediyor ve hedefe kadar sürüyor. Bu, kaybın gerçekten o noktada oluştuğunu ve tüm trafiği etkilediğini söyler. Buna karşılık, tek bir ara atlamada yüksek kayıp görüp sonraki satırlarda %0'a dönüyorsa bu yine ICMP hız sınırlamasıdır, gerçek kayıp değildir.

Yorumlama kuralını netleştirelim:

Destek talebi açarken sağlayıcınıza gönderilecek en değerli çıktı mtr --report sonucudur; tek bir ping ekran görüntüsü çok daha az bilgi taşır.

Teşhis Sırası: Şikâyetten Sonuca#

Bir "site yavaş" bildirimi geldiğinde şu sırayı izleyin; her adım bir ihtimali eler.

1. Sorun ağda mı uygulamada mı? ping düşük (örneğin 15 ms) ama curl ile ölçtüğünüz ilk bayt süresi yüksekse (1 saniye üstü) ağ temizdir, sorun sunucudadır. Ağ ölçümüyle vakit kaybetmeyin.
2. Ağdaysa, kendi tarafınızda mı? Aynı ölçümü farklı bir ağdan yapın: mobil veriden, başka bir operatörden ya da bir bulut sunucudan. Sadece sizde varsa sorun yerel bağlantınızdadır.
3. Yol nerede bozuluyor? mtr --report --report-cycles 200 çalıştırın ve kaybın hangi atlamada başlayıp devam ettiğine bakın.
4. İlk atlamalar mı, ortası mı, sonu mu? İlk iki atlamada kayıp varsa kendi modeminiz/operatörünüz, ortada başlayıp devam ediyorsa transit operatör, yalnızca son atlamada varsa hedef sunucu ya da veri merkezidir.
5. Zamana bağlı mı? Aynı ölçümü sabah ve akşam yoğunluğunda tekrarlayın. Sadece akşam bozuluyorsa kapasite/tıkanma sorunudur.
6. Uygulama tarafındaysa yük altındaki davranışı ölçün; tek istekte hızlı görünen sistem eşzamanlı yükte çökebilir. k6 ile yük testi yazısındaki senaryolar bunun için uygundur.

Ölçümlerinizi kaydedin. Sağlıklı günlerdeki mtr raporunu saklarsanız, bir sorun çıktığında karşılaştırma yapacak referansınız olur. Referans olmadan "bu değer normal mi" sorusuna cevap veremezsiniz.

Windows ve Tarayıcı Tarafında Ölçüm#

Windows'ta tracert yerleşik olarak gelir ama ICMP kullanır ve istatistik tutmaz. Daha iyi bir seçenek pathping komutudur; traceroute ile ping'i birleştirir ve her atlama için kayıp yüzdesi hesaplar:

# Yolu bulup her atlama için istatistik toplar (varsayılan ~5 dakika sürer)
pathping firmaniz.com

# Sürekli ping (durdurmak için Ctrl+C)
ping -t firmaniz.com

# Belirli bir porta TCP bağlantı testi
Test-NetConnection firmaniz.com -Port 443

Test-NetConnection özellikle işe yarar; ICMP engelliyken bile hedefin belirli bir portta dinleyip dinlemediğini ve gecikmeyi gösterir.

Tarayıcı tarafında ise ağ katmanını değil, gerçek kullanıcının yaşadığı toplam süreyi ölçersiniz. Geliştirici araçlarının ağ sekmesinde bir isteğin üzerine geldiğinizde zaman dökümünü görürsünüz: DNS çözümlemesi, ilk bağlantı, TLS, istek gönderimi, "waiting (TTFB)" ve içerik indirme. Buradaki Waiting/TTFB satırı sunucunun düşünme süresidir; Connecting ve SSL satırları ise mesafeye bağlı ağ maliyetidir. İkisini ayırt etmek, aynı curl -w ölçümünün tarayıcıdaki karşılığıdır ve teşhisin ilk adımı için yeterlidir.

Sıkça Sorulan Sorular#

Ping cevap vermiyor, sunucum kapalı mı#

Hayır, bu sonuca varamazsınız. Birçok sunucu ve güvenlik duvarı ICMP echo isteklerini bilinçli olarak engeller; özellikle Windows Server varsayılan olarak cevap vermez. Sunucunun ayakta olup olmadığını TCP düzeyinde test edin: nc -zv firmaniz.com 443 ya da Windows'ta Test-NetConnection firmaniz.com -Port 443 komutu bağlantı kurulabiliyorsa sunucu çalışıyordur.

Traceroute'ta ortadaki bir atlama çok yüksek, sorun orada mı#

Neredeyse her zaman hayır. Her satırdaki süre, o cihazın kendi ICMP cevabını üretme süresini içerir ve yönlendiriciler bu işi düşük öncelikle yapar. Gerçek bir gecikme artışı olsaydı, o atlamadan sonraki tüm satırların da yüksek olması gerekirdi. Sonraki atlamalar normale dönüyorsa yüksek değeri yok sayın.

mtr çıktısında kayıp görüyorum, ne yapmalıyım#

Önce kaybın hangi atlamada başladığına ve sonrasında devam edip etmediğine bakın. Bir atlamada var, sonrakinde yoksa bu ICMP hız sınırlamasıdır ve gerçek kayıp değildir. Kayıp bir noktada başlayıp hedefe kadar sürüyorsa gerçek bir problem vardır. Bu durumda mtr --report --report-cycles 200 çıktısını kaydedip sağlayıcınıza iletin; tek bir ping ekran görüntüsünden çok daha değerlidir.

Ping süresi kaç ms olmalı#

Aynı ülkedeki bir sunucu için 5–25 ms iyi kabul edilir, yakın Avrupa için 35–60 ms normaldir. Mutlak değerden daha önemlisi tutarlılıktır: mdev (sapma) düşük olmalı ve max değeri ortalamanın birkaç katını aşmamalıdır. Ortalaması 20 ms ama zaman zaman 400 ms'ye sıçrayan bir bağlantı, sabit 60 ms'lik bir bağlantıdan daha kötü hissedilir.

Ping düşük ama sitem yavaş, sebep ne olabilir#

Ping yalnızca ağ katmanını ölçer; sunucunun sayfayı üretme süresini içermez. Ping 15 ms ama sayfa 3 saniyede açılıyorsa sorun uygulama tarafındadır: yavaş veritabanı sorguları, eksik önbellek, ağır PHP işleme ya da harici API beklemeleri. Ayrımı curl -o /dev/null -s -w '%{time_starttransfer}' ile ölçtüğünüz ilk bayt süresine bakarak yaparsınız.

Traceroute neden bazı satırlarda yıldız gösteriyor#

Yıldızlar, o atlamadaki cihazın TTL aşımı bildirimi göndermediği anlamına gelir. Birçok yönlendirici bunu güvenlik ya da CPU tasarrufu için kapatır. Hedefe ulaşabiliyor ve son satırda gerçek IP'yi görüyorsanız, aradaki yıldızlar sorun değildir. Tüm satırlar yıldızsa ve hedefe hiç ulaşamıyorsanız, protokolü değiştirip TCP ile deneyin: traceroute -T -p 443.

Farklı saatlerde farklı sonuç alıyorum, normal mi#

Evet ve bu aslında değerli bir bulgudur. Akşam yoğunluk saatlerinde transit hatlar dolabilir, kuyruklanma başlar ve gecikme belirgin biçimde artar. Sabah 35 ms olan bir yol akşam 120 ms'ye çıkıyorsa bu bir kapasite sorununa işaret eder. Ölçümlerinizi her zaman en az iki farklı zaman diliminde tekrarlayın ve kararlarınızı yoğun saatteki değere göre verin.

Kapanış#

ping ve traceroute, doğru okunduğunda bir gecikme şikâyetinin kaynağını dakikalar içinde daraltan iki güçlü araçtır; yanlış okunduğunda ise sizi olmayan bir sorunun peşine düşürür. Aklınızda kalması gereken dört şey şudur: tek pakete değil dağılıma ve sapmaya bakmak, ICMP cevapsızlığını "sunucu kapalı" diye yorumlamamak, traceroute'ta ortadaki tek yüksek değeri değil sonuna kadar devam eden artışı ciddiye almak ve aralıklı sorunlar için mtr --report kullanmak. Sağlıklı günlerdeki ölçümü saklamak da beşinci ve en çok işe yarayan alışkanlıktır.

Ağ tarafındaki gecikmeyi kalıcı olarak azaltmanın yolu genellikle sunucuyu ziyaretçilerinize yaklaştırmaktan geçer. Clou.TR tarafında düşük gecikmeli barındırma için web hosting ve kurumsal hosting paketlerimizi, kendi ağ yapılandırmanızı yönetmek isterseniz VDS ve bulut sunucu çözümlerimizi inceleyebilirsiniz. Saldırı kaynaklı paket kaybı ve gecikme yaşıyorsanız DDoS koruma hizmetimiz, sürekli izleme ve teşhisi bize bırakmak isterseniz sunucu yönetimi hizmetimiz bu işi üstlenir.