Paket Kaybı Nedir?

Bir görüşmede sesin kesilmesi veya oyunda karakterin takılması paket kaybından kaynaklanabilir; ancak aynı belirti yüksek gecikme, değişken gecikme veya uygulamanın kendisi yüzünden de oluşabilir. Paket kaybı, gönderilen paketlerin bir bölümünün hedefe ulaşmamasıdır. Teşhiste asıl soru, hangi trafik için, hangi aralıkta ve nerede kayıp gözlendiğidir.

Kayıp, gecikme ve bağlantı hızı ayrı ölçümlerdir

Gecikme bir paketin yolculuğunun ne kadar sürdüğünü, jitter gecikmenin ne kadar değiştiğini anlatır. Paket kaybı ise teslim edilemeyen paketlerle ilgilidir. Yüksek indirme hızı bu üç ölçümün iyi olacağını garanti etmez. Özellikle bağlantı yoğunken kuyruklar dolabilir; Wi-Fi paraziti, hatalı kablo veya arayüz hataları da araştırılmalıdır.

Kayıp olması, indirilen dosyanın mutlaka bozuk kalacağı anlamına gelmez. TCP eksik veriyi yeniden iletebilir; bunun bedeli ek bekleme ve düşen aktarım hızıdır. Gerçek zamanlı uygulamalar ise geç ulaşan veriyi kullanamayabilir. Bu yüzden dosya indirmek ile canlı görüşme yapmak aynı sorunu farklı hissettirir.

Önce kısa ve karşılaştırılabilir ölçümler al

Windows'ta ipconfig çıktısından etkin bağlantının varsayılan ağ geçidini bul. Aşağıdaki 192.168.1.1 yalnızca örnektir; kendi ağ geçidinle değiştir:

ping -n 20 192.168.1.1

Linux ve macOS için aynı sınırlı denemenin biçimi şöyledir:

ping -c 20 192.168.1.1

Ardından ping yanıtı verdiğini bildiğin ve test etme yetkin olan bir uzak hedefi aynı sayıda paketle kontrol et. Hedef, saat, bağlantı türü ve o sıradaki indirme/yükleme trafiğini kaydet. Yoğunluk sırasında ve bağlantı sakinken alınan ölçümleri karıştırma. Yirmi paket bir başlangıç örneklemidir; aralıklı sorunu dışlamak için yeterli olmayabilir. Microsoft ping belgesi Windows seçeneklerini açıklar.

“20 gönderildi, 19 alındı” neyi kanıtlar?

Bu temsili ölçümde ping yanıtlarının yüzde 5'i alınmamıştır. İstek mi kayboldu, cevap mı dönmedi, hedef mi ICMP'yi sınırladı? Tek başına sayaç bunları ayırmaz. Ölçümü doğrudan “uygulamam yüzde 5 veri kaybediyor” diye yorumlama. Ağ geçidi de ping yanıtlarını sınırlayabilir; yanıt vermemesi tek başına cihazın bozuk olduğunu göstermez.

Ethernet ile aynı denemeyi yapmak, Wi-Fi yolunun etkisini araştırmak için yararlıdır. Sadece kablosuzda tekrar eden kayıp yerel radyo koşullarına bakmayı gerektirir. Hem kablolu hem kablosuzda yalnız uzak hedef etkileniyorsa WAN ve hedef tarafını da incele; bu yine doğrudan servis sağlayıcıyı suçlamak için yeterli değildir.

MTR'de ara satırdaki kayba takılma

Bir ara yönlendirici kendisine yönelik ICMP yanıtlarını azaltırken üzerinden geçen trafiği iletmeye devam edebilir. Ara satırdaki yüksek kayıp son hedefte görülmüyorsa bu ayrım önemlidir. Sonraki noktalara da taşınan kayıp daha fazla inceleme gerektirir, fakat dönüş yolları farklı olabileceğinden tek başına arızalı kabloyu veya portu belirlemez. Cloudflare'ın MTR açıklaması kontrol trafiği ile iletilen trafik arasındaki farkı örnekler.

Destek kaydına kısa testlerin zamanını, gönderilen/alınan paket sayılarını, kullanılan bağlantıyı ve uygulamanın aynı anda etkilenip etkilenmediğini ekle. Güvenlik duvarını veya antivirüsü topluca kapatmak yerine ilgili engelleme kayıtlarını incele. Yapılan değişiklikten sonra aynı hedefe, benzer yük altında tekrar ölçüm al; yalnız tek bir başarılı ping ile sorunu kapanmış sayma.