Hala TCP zaman aşımını ve yeniden iletimini anlamıyor musunuz? Bu uzun makaleyi okumaktan çok yararlanacaksınız
TCP protokolünün bir yeniden iletim mekanizmasına sahip olduğunu hepimiz biliyoruz, yani gönderen paket kaybının meydana geldiğini düşünürse, bu paketleri yeniden iletecektir. Açıkçası, bir yola ihtiyacımız var " tahmin "Herhangi bir paket kaybı olup olmadığı. En basit fikir, alıcının her paket aldığında, gönderene bir paket göndermesidir. ACK , Bu, bu veri parçasını aldığı anlamına gelir. Tersine, gönderen belirli bir süre ACK almazsa, Çok olası Veri paketi kaybolur ve ardından veri paketi, ACK alınana kadar yeniden iletilir.
"Tahmin" özelliğini kullandığımı fark etmiş olabilirsiniz, çünkü zaman aşımına uğramış olsa bile paket kaybolmamış olabilir, uzun bir yoldan saptı ve çok geç geldi. Sonuçta, TCP protokolü şurada bulunur: Taşıma katmanı Veri bağlantı katmanında ve fiziksel katmanda tam olarak ne olduğunu bilmek imkansızdır. Ancak bu, zaman aşımı yeniden iletim mekanizmamızı engellemez, çünkü alıcı otomatik olarak yinelenen paketleri görmezden gelir.
Zaman aşımı ve yeniden iletim kavramı aslında bu kadar basit, ancak birçok iç ayrıntı var. Aklımıza gelen ilk sorun, Bir zaman aşımı olarak sayılması ne kadar sürer? ?
Zaman aşımı nasıl belirlenir?
Her duruma uyan tek çözüm şu: Zaman aşımı süresini doğrudan sabit bir değere ayarlayın , Örneğin, 200ms, ama bu kesinlikle bir sorun. Bilgisayarımız birçok sunucuyla etkileşim kuruyor. Bu sunucular ülkenin kuzeyinde ve güneyinde, yurtiçinde ve yurtdışında yer alıyor ve gecikmeler büyük ölçüde değişiklik gösteriyor.
- Kişisel blogum Çin'de kuruldu ve gecikme yaklaşık 30 ms, yani ACK normal koşullar altında veri paketleri için yaklaşık 60 ms içinde alınabilir, ancak bizim yöntemimize göre paket kaybı 200 ms'de belirlenebilir (normalde 90 ila 120 olabilir ms), bu Verimlilik biraz düşük .
- 130 ms gecikmeli yabancı bir web sitesini ziyaret ettiğinizi varsayalım ki bu zahmetli. Normal veri paketleri, çok sayıda veri paketinin yeniden iletilmesine neden olan zaman aşımı olarak kabul edilebilir.Yeniden iletilen veri paketlerinin zaman aşımı olarak kolayca yanlış değerlendirilebileceği düşünülebilir. . . Çığ etkisi hissi
Bu nedenle sabit bir değer belirlemek çok güvenilmezdir. Zaman aşımını ağ gecikmesine göre dinamik olarak ayarlamamız gerekiyor , Gecikme ne kadar büyükse, zaman aşımı süresi o kadar uzun olur.
Önce burada iki kavramı tanıtın:
- RTT (Gidiş Dönüş Süresi): Gidiş dönüş gecikmesi, yani ** veri paketinin gönderildiği andan ilgili ACK'nın alındığı ana kadar geçen süredir. ** RTT bağlantı içindir, her bağlantının kendi bağımsız RTT'si vardır.
- RTO (Yeniden İletim Zaman Aşımı): Daha önce bahsedilen zaman aşımı süresi olan yeniden iletim zaman aşımı.
Standart RTT tanımı:
Belirli bir sıra numarasına sahip bir veri sekizlisini gönderme ile arasındaki geçen süreyi ölçün. bu sıra numarasını kapsayan bir alındı bildirimi almak (gönderilen bölümlerin alınan bölümlerle eşleşmesi gerekmez) Bu ölçülen geçen süre Gidiş Dönüş Süresidir (RTT).
Klasik yöntem
Orijinal "RFC0793" spesifikasyonu, düzgün bir RTT tahmini elde etmek için aşağıdaki formülü kullandı (SRTT olarak adlandırılır):
SRTT < - · SRTT + (1-) · RTT
RTT, en son örnek değeri ifade eder. Bu tahmin yöntemine "Üstel Ağırlıklı Hareketli Ortalama" adı verilir. Adı görece uzun gibi görünür, ancak tüm formülün anlaşılması daha kolaydır, yani mevcut SRTT değerini ve en son ölçülen RTT değerini bir ağırlık almak için kullanmak ortalama.
SRTT ile karşılık gelen RTO değerini ayarlama zamanıdır, "RFC0793" şu şekilde hesaplanır:
RTO = min (ubound, max (lbound, (SRTT) · ))
İçeride ubound RTO Üst sınır , lbound RTO için altında sınır , denir Gecikme dağılım faktörü Önerilen değer 1.3 ~ 2.0'dır. Bu hesaplama formülü (SRTT) · değerini RTO olarak kullanır, ancak ek olarak RTO'nun üst ve alt sınırlarını sınırlayın .
Bu hesaplama yöntemi ilk bakışta bir problem değil (en azından öyle hissediyorum), ancak gerçek uygulamada iki kusur var:
RFC-793'te belirtilen RTO hesaplamalarıyla ilgili bilinen iki sorun vardı. Birincisi, RTT'lerin doğru ölçümü zordur. yeniden iletimler olduğunda İkinci olarak, yumuşatılmış gidiş-dönüş süresini hesaplayan algoritma yetersizdir, RTT değerlerindeki varyansın küçük ve sabit olacağını yanlış varsaydığı için Bu sorunlar tarafından çözüldü. Karn ve Jacobson algoritması , sırasıyla.
Bu pasaj "RFC1122" den alınmıştır, açıklamama izin verin:
- ne zaman Veri paketlerinin yeniden iletimi Sonra, RTT'nin hesaplanması çok "zahmetli" olacaktır. Bu durumları göstermek için bir resim çizdim: Resimde listelenen iki durum var Bu iki durumda, RTT'yi hesaplama yöntemi farklıdır (bu sözde yeniden iletimdir). Belirsizlik): Ancak müşteri için ne olduğunu bilmiyor Yanlış seçimin sonucu RTT'nin çok büyük / küçük olması ve bu da RTO hesaplamasını etkiliyor. (En basit ve kaba çözüm, Yeniden iletilen paketleri göz ardı edin ve yalnızca yeniden iletilmemiş paketleri sayın , Ama bu başka sorunlara neden olur. . Ayrıntılar için Karn algoritmasına bakın)
- Durum 1: RTT = t2-t0
- Durum 2: RTT = t2-t1
- Başka bir sorun ise, Bu algoritma, RTT dalgalanmalarının nispeten küçük olduğunu varsayar , Çünkü bu ağırlıklı ortalama algoritmaya aynı zamanda Alçak geçiş filtresi , Ani ağ dalgalanmalarına karşı duyarsız. Ağ gecikmesi aniden artarsa ve gerçek RTT değeri tahmin edilen değerden çok daha büyükse, gereksiz yeniden iletimlere neden olacak ve ağ yükünü artıracaktır. (RTT'deki artış, ağın aşırı yüklendiğini ve bu gereksiz yeniden aktarımların ağ üzerindeki yükü daha da artıracağını göstermiştir).
Standart yöntem
Dürüst olmak gerekirse, bu standart yöntem karşılaştırır ,,, sorun, doğrudan formülü yapıştıracağım:
SRTT < - (1-) · SRTT + · RTT // Temel yöntemle aynı, SRTT'nin ağırlıklı ortalamasını bulun
rttvar < - (1-h) · rttvar + h · (| RTT-SRTT |) //Hesaplamak SRTT ve gerçek değer arasındaki fark (Mutlak hata deyin | Err |), ayrıca kullanılır Ağırlıklı ortalama
RTO = SRTT + 4 · rttvar // Tahmini yeni RTO, rttvar'ın 4 katsayısı ayarlanarak ayarlanır
Bu algoritmanın genel fikri, ortalama değer (Temel yöntem) ve Ortalama sapma Tahmin etmek gerekirse, bir metafizik ayarlama dalgası iyi sonuçlar elde etti. Bu algoritma hakkında daha fazla bilgi edinmek istiyorsanız, lütfen "RFC6298" bölümüne bakın.
Yeniden iletim - TCP için önemli bir olay
Zamanlayıcı tabanlı yeniden iletim
Bu mekanizma altında, Her paketin karşılık gelen bir zamanlayıcısı vardır RTO aşıldığında ve ACK alınmadığında, paket yeniden gönderilecektir. Bir ACK almayan veri paketleri yeniden iletim arabelleğinde saklanacak ve ACK'dan sonra arabellekten silinecektir.
Her şeyden önce, TCP için zaman aşımı yeniden iletiminin Oldukça önemli (RTO genellikle RTT'nin iki katından fazladır, zaman aşımı genellikle tıkanıklık anlamına gelir), bu olduğunda, TCP yalnızca ilgili veri segmentini yeniden iletmekle kalmaz, aynı zamanda mevcut veri gönderme hızını da düşürür. Çünkü TCP, mevcut ağın tıkalı olduğunu düşünecektir.
Basit zaman aşımı yeniden iletim mekanizması, aşağıdaki durum gibi genellikle verimsizdir:
Paket 5'in kaybolduğunu ve paket 6, 7, 8 ve 9'un alıcıya ulaştığını varsayarsak, istemci şu anda yalnızca sunucunun bir ACK göndermesini bekleyebilir.6, 7, 8 ve 9 numaralı paketler için sunucunun bir ACK gönderemeyeceğini unutmayın. Bu, kayan pencere mekanizması ile belirlenir.Bu nedenle, müşteri için kaç paketin kaybolduğunu bilmiyor, 5'ten sonraki veri paketlerinin de kaybolması karamsar olabilir, bu nedenle bu 5 veri paketini yeniden ileteceklerdir. Bu daha savurgan.
Hızlı yeniden iletim
Hızlı yeniden iletim mekanizması "RFC5681", yeniden iletim zamanlayıcısının sona ermesi yerine alıcıdan gelen geri bildirim bilgisine dayalı olarak yeniden iletimi tetikler.
Daha önce de belirtildiği gibi, zamanlayıcı tabanlı yeniden iletim genellikle uzun sürer ve hızlı yeniden iletim bu sorunu çözmek için çok akıllı bir yöntem kullanır: Sunucu sıra dışı paketler alırsa, istemciye de ACK yanıtını verecektir. , Bu sadece tekrarlanan bir ACK. Şimdi örneği ele alalım, sıra dışı paketler 6, 7, 8, 9 alırken, sunucunun tümü ACK = 5 gönderiyor. Bu şekilde müşteri 5'in boş olduğunu bilir. Genel olarak, müşteri arka arkaya üç kez tekrarlanan ACK'leri alırsa, zamanlayıcının süresinin dolmasını beklemeden karşılık gelen paketi yeniden iletecektir.
Ancak hızlı yeniden iletim yine de ikinci sorunu çözmez: Kaç paket yeniden iletilmelidir?
Seçim onayı ile yeniden iletim
Geliştirilmiş yöntem, basitçe hızlı yeniden iletime dayanan SACK'tir (Seçmeli Onay). En son alınan segmentin sıra numarası aralığını verir Böylece istemci, sunucuya hangi paketlerin ulaştığını bilir.
İşte birkaç basit örnek:
- durum 1: İlk paket kaybolur ve kalan 7 paket alınır. 7 paket alırken kimse O zaman alıcı, gönderene hangi sıra dışı paketleri aldığını bildirmek için SACK seçeneğiyle bir ACK döndürür. Not: Sol Kenar, Sağ Kenar, bu sıra dışı paketlerin sol ve sağ sınırlarıdır .
- durum 2: İkinci, dördüncü, altıncı ve sekizinci veri paketleri kaybolur.
- İlk paket alındığında herhangi bir düzensizlik yoktur ve ACK normal bir şekilde döndürülür.
- Sıra dışı paketler nedeniyle 3., 5. ve 7. paketler alındığında, SACK ile ACK döndürülür.
- Bu durumda birçok fragman olduğu için, karşılık gelen Blok segmentinin de birçok grubu vardır.Elbette, seçenek alanının boyut sınırlaması nedeniyle, Blok'un da bir üst limiti vardır.
Bununla birlikte, "RFC2018" SACK özelliği biraz aldatmacadır. Alıcı, bu bilgiyi gönderene bildirmek için bir SACK sağlayabilir ve ardından "sözünü bozabilir". Diğer bir deyişle, alıcı bu (sıra dışı) paketleri silebilir ve sonra Ardından gönderene bildirin. Aşağıdaki "RFC2018" den bir alıntıdır:
Veriler bir SACK seçeneğinde rapor edilmiş olsa bile, veri alıcısının kuyruğundaki verileri gönderen tarafından onaylanmamış verileri atmasına izin verildiğini unutmayın. SAKLANMIŞ paketlerin bu şekilde atılması tavsiye edilmez, ancak alıcının arabellek alanı kalmazsa kullanılabilir.
Son cümle şöyle diyor: Alıcının tamponu neredeyse bittiğinde , Bu önlem alınabilir, tabi ki bu davranış önerilmez. . .
Bu işlem nedeniyle, SACK'i aldıktan sonra, alıcı, maksimum sıra numarasından daha büyük bir normal ACK numarası gönderene kadar, gönderici, yeniden iletim arabelleğindeki verileri doğrudan temizleyemez. Ek olarak, yeniden iletim zamanlayıcısı da etkilenir Yeniden iletim zamanlayıcısı SACK'in etkisini göz ardı etmelidir Sonuçta, alıcı tarafından silinen veriler paket kaybından farklı değildir.
DSACK uzantısı
DSACK, yani SACK tekrarlanır, bu mekanizma SACK'e dayanır ve ek bilgiler taşır, Gönderene hangi veri paketlerinin tekrar tekrar alındığını söyleyin . DSACK'in amacı, gönderenin paketin sıra dışı, ACK kaybı, paket çoğaltması veya sözde yeniden iletimin meydana gelip gelmediğini belirlemesine yardımcı olmaktır. TCP'nin ağ akış denetimini daha iyi yapmasına izin verin.
DSACK ile ilgili olarak, "RFC2883" de birçok örnek var İlgilenen okuyucular okuyabilir. Burada bu ayrıntıya girmeyeceğim.
Zaman aşımı ve yeniden iletimin içeriği muhtemelen çok fazladır, umarım size yardımcı olur.
Programcı bilgi teknolojisi hakkında daha fazla bilgi edinmek ve zengin mimari bilgileri almak için beni takip edin
