TCP yeniden iletimi, kaybolan veya hasar gören paketlerin ağ üzerinden yeniden gönderilmesi anlamına gelir. Burada yeniden iletim, aşağıdaki gibi protokoller tarafından kullanılan bir mekanizmadır: TCP güvenilir iletişim sağlamak. Burada güvenilir iletişim, veri paketi kaybolsa veya hasar görse bile protokolün paketin teslimini garanti ettiği anlamına gelir.
monitör boyutumu nasıl öğrenirim
Ağlar güvenilmezdir ve kaybolan veya hasar gören paketlerin gecikmesini veya yeniden iletilmesini garanti etmez. Hasarlı veya kayıp paketlerin onaylanması ve yeniden iletilmesi kombinasyonunu kullanan ağ, güvenilirlik sunar.
Yeniden iletim mekanizması
Burada yeniden iletim, veri paketlerinin kaybolduğu anlamına gelir ve bu da onay eksikliğine yol açar. Bu onay eksikliği, zamanlayıcının zaman aşımına uğramasına neden olur ve bu da veri paketlerinin yeniden iletilmesine yol açar. Burada zamanlayıcı, zamanlayıcının süresi dolmadan herhangi bir onay alınmaması durumunda veri paketinin yeniden iletileceği anlamına gelir.
Aşağıdaki yeniden iletim senaryolarını ele alalım.
Senaryo 1: Veri paketi kaybolduğunda veya hatalı olduğunda.
Bu senaryoda paket alıcıya gönderilir ancak bu zaman aşımı süresi içinde herhangi bir onay alınmaz. Zaman aşımı süresi dolduğunda paket yeniden gönderilir. Paket yeniden iletildiğinde onay alınır. Onay alındıktan sonra yeniden iletim yapılmayacaktır.
Senaryo 2: Paket alındığında ancak onay kaybolduğunda.
Bu senaryoda paket diğer taraftan alınır ancak onay kaybolur, yani gönderen tarafta ACK alınmaz. Zaman aşımı süresi dolduğunda paket yeniden gönderilir. Diğer tarafta paketlerin iki kopyası var; Paket doğru bir şekilde alınsa da onay alınamadığı için gönderen paketi yeniden iletir. Bu durumda yeniden iletim önlenebilirdi ancak ACK kaybı nedeniyle paket yeniden iletilir.
Senaryo 3: Erken zaman aşımı oluştuğunda.
Bu senaryoda paket gönderilir ancak onaydaki gecikme veya zaman aşımının gerçek zaman aşımından önce oluşması nedeniyle paket yeniden iletilir. Bu durumda, onaydaki gecikme nedeniyle paket gereksiz yere tekrar gönderilmiştir veya zaman aşımı süresi, gerçek zaman aşımından daha erkene ayarlanmıştır.
Yukarıdaki senaryolarda ilk senaryodan kaçınılamaz ancak diğer iki senaryodan kaçınılabilir. Bakalım bu durumlardan nasıl kaçınabiliriz.
Gönderen ne kadar beklemeli?
Gönderen, ACK için zaman aşımı süresini belirler. Zaman aşımı süresi iki tür olabilir:
bash while döngüsü
Yukarıdaki iki durumun üstesinden gelmek için, TCP Zaman aşımını RTT'nin (gidiş dönüş süresi) bir fonksiyonu olarak ayarlar; burada gidiş-dönüş süresi, paketin kaynaktan hedefe gitmesi ve sonra tekrar geri gelmesi için gereken süredir.
RTT'yi nasıl edinebiliriz?
RTT, ağın özelliklerine bağlı olarak değişebilir; yani ağda yoğunluk varsa bu, RTT'nin çok yüksek olduğu anlamına gelir. Sadece ACK'leri izleyerek RTT'yi tahmin edebiliriz.
RTT'yi nasıl ölçebileceğimizi görelim.
kullanacağız orijinal algoritma RTT'yi ölçmek için.
Aşama 1: İlk önce ölçüyoruz ÖrnekRTT her segment veya ACK çifti için. Gönderen paketi gönderdiğinde, paketin gönderildiği zamanlayıcıyı biliyoruz ve ayrıca onayın alındığı zamanlayıcıyı da biliyoruz. Bu ikisi arasındaki süreyi hesaplayın ve bu ÖrnekRTT .
Adım 2: Tek bir örnek almayacağız. Farklı örnekler almaya devam edip bu örneklerin ağırlıklı ortalamasını hesaplayacağız ve bu EstRTT (Tahmini RTT) olur.
burada, α+ β = 1
α 0,8 ile 0,9 arasındadır
β 0,1 ile 0,2 arasındadır
Aşama 3: Zaman aşımı EstRTT'ye göre ayarlanır.
zaman aşımı = 2 * EstRTT.
Java'yı yakalamayı dene
Zaman aşımı tahmini RTT'nin iki katı olacak şekilde ayarlanmıştır. Gerçek zaman aşımı faktörü bu şekilde hesaplanır.
Bu yaklaşımdaki bir kusur
Orijinal algoritmada bir kusur var. İki senaryoyu ele alalım.
Senaryo 1.
Yukarıdaki şema, gönderenin, orijinal iletim olduğu söylenen verileri gönderdiğini göstermektedir. Zaman aşımı süresi içerisinde herhangi bir onay alınmaz. Böylece gönderen verileri yeniden iletir. Veriler yeniden iletildikten sonra onay alınır. Yeniden iletim için değil, orijinal iletim için onay alındığını varsayalım. Orijinal iletimin onayını aldığımıza göre, ÖrnekRTT orijinal iletim zamanı ile onayın alındığı zaman arasında hesaplanır. Ama aslında ÖrnekRTT yeniden iletim zamanı ile onay zamanı arasında olmalıdır.
Senaryo 2.
Yukarıdaki şema, gönderenin, bizim de onayını aldığımız orijinal veri paketini gönderdiğini göstermektedir. Ancak veri yeniden iletildikten sonra onay alınır. Bildirimin yeniden iletime ait olduğunu varsayarsak, o zaman ÖrnekRTT yeniden iletim zamanı ile onay zamanı arasında hesaplanır.
Yukarıdaki her iki senaryoda da, bildirimin orijinal iletim için mi yoksa yeniden iletim için mi olduğunu bilmeme konusunda bir belirsizlik vardır.
Yukarıdaki algoritmanın sonucu.
- Burada ACK, bir aktarımın onaylanması anlamına gelmez, ancak aslında verinin alındığını onaylar.
- İlk senaryoyu ele alırsak kayıp paket için yeniden iletim yapılır. Bu durumda, SampleRTT'nin çok büyük çıkması nedeniyle ACK'nin orijinal iletime ait olduğunu varsayıyoruz.
- İkinci senaryoya bakarsak iki aynı paket gönderiliyor ve bu durumda kopyalar oluşuyor. Bu durumda, SampleRTT'nin çok küçük olması nedeniyle ACK'nin yeniden iletime ait olduğunu varsayıyoruz.
Yukarıdaki sorunların üstesinden gelmek için Karn/Partridge algoritması ile basit bir çözüm verilmiştir. Bu algoritma, tek seferde gönderilen örnekleri toplayan ve tahmini RTT'yi hesaplamak için yeniden iletim zamanındaki örnekleri dikkate almayan basit bir çözüm verdi.
Karn/Partridge Algoritması
Yukarıdaki iki senaryoda yeniden iletim meydana gelir ve Örnek RTT'yi dikkate aldık. Ancak bu algoritma, yeniden iletim sırasında Örnek RTT'yi dikkate almaz. Yeniden iletim gerçekleştiğine göre, bu gidiş-dönüş süresinde bir şeyler olduğu veya ağda bazı tıkanıklıkların meydana gelebileceği anlamına gelir. Bu sorunun üstesinden gelmek için bu algoritma, her yeniden iletimden sonra zaman aşımını iki katına çıkarır. Bu algoritma TCP ağında uygulanır.
Sınırlama
RTT'deki varyansı dikkate almaz.
Yukarıdaki sınırlamanın üstesinden gelmek için RTT'ye varyans faktörünü getiren Jacobson/Karels algoritması geliştirildi.
Jacobson/Karels Algoritması
Java'daki liste örneği
Bu algoritma sınırlamanın üstesinden gelmek için geliştirilmiştir. Karn/Keklik algoritma. SampleRTT ile EstimatedRTT arasındaki farkı hesaplar ve farka göre RTT'yi artırır.
Ortalama RTT için hesaplamalar
- Öncelikle fark faktörünü hesaplıyoruz.
Fark = ÖrnekRTT - TahminiRTT
- Şimdi yukarıda yaptığımız gibi hesaplanacak olan EstimatedRTT'yi hesaplıyoruz.
EstRTT = EstRTT + (δ*Fark)
- Şimdi fark faktörünün ortalamasını hesaplıyoruz.
Dev = Dev + δ ( |Fark| - Dev)
dizeyi tarihe dönüştürme
Burada Dev bir sapma faktörüdür ve δ 0 ile 1 arasında bir faktördür. Geliştirici arasındaki farkın bir tahminidir. EstRTT .
- Zaman aşımı değerini hesaplarken varyansı dikkate alacağız.
Nerede, µ =1 ve ɸ =4
Hızlı Yeniden İletim
Yeniden iletim için zaman aşımı temelli strateji verimsizdir. TCP, kayan pencere tipi bir protokoldür, dolayısıyla yeniden iletim gerçekleştiğinde, onu kayıp paketten itibaren göndermeye başlar.
Diyelim ki 0, 1, 2 ve 3 numaralı paketleri iletiyorum. 0 ve 1 numaralı paketler karşı taraftan alındığından, ağda 2 numaralı paket kayboluyor. Paket 0 ve paket 1'in onayını aldım, bu yüzden iki paket daha gönderiyorum, yani paket 4 ve paket 5. Paket 3, 4 ve 5 gönderildiğinde, paket 1'in onayını TCP bildirimleri olarak alacağım kümülatif olduğundan, aldığı pakete kadar sırayla bilgi verir. Zaman aşımı süresi içinde 2, 3,4 ve 5. paketlerin onayını alamadım, bu yüzden 2, 3, 4 ve 5. paketleri yeniden iletiyorum. 2. paket kaybolduğu için ancak diğer paketler, yani 3, 4. ,5 karşı taraftan alınsa da bu zaman aşımı mekanizması nedeniyle yine de yeniden iletilmeye devam edilir.
Bu zaman aşımı verimsizliği nasıl ortadan kaldırılabilir?
Kayar pencere altında daha iyi çözüm:
n paketin kaybolduğunu ancak yine de n+1, n+2 vb. paketlerin alındığını varsayalım. Alıcı sürekli olarak paketleri alıyor ve alıcının hala n'inci paketi beklediğini söyleyen ACK paketlerini gönderiyor. Alıcı tekrarlanan veya yinelenen bildirimler gönderiyor. Yukarıdaki durumda, paket 2 kaybolduğundan paket 1'in ACK'si üç kez gönderilir. Bu kopya ACK paketi, n'inci paketin eksik olduğunu ancak daha sonraki paketlerin alındığının bir göstergesidir.
Yukarıdaki durum aşağıdaki şekillerde çözülebilir:
- Gönderici, 'yinelenen ACK'leri' n'inci paketin kaybolduğuna dair erken bir ipucu olarak alabilir, böylece gönderici yeniden iletimi mümkün olduğu kadar erken yapabilir, yani gönderici zaman aşımı oluşana kadar beklememelidir.
- Gönderen, TCP'de hızlı bir iletim stratejisi uygulayabilir. Hızlı iletim stratejisinde göndericinin üçlü kopya ACK'leri tetikleyici olarak düşünmesi ve yeniden iletmesi gerekir.
TCP, tetikleyici olarak üç kopya ACK kullanır ve ardından yeniden iletim gerçekleştirir. Yukarıdaki durumda, paket 1'in üç ACK'si alındığında, göndericinin zaman aşımı süresinin dolmasını beklemeden kayıp paketi, yani paket 2'yi göndermesi gerekir.