Şahsen ACK'ya ihtiyaç olduğunu bile hissetmiyorum. Alınan her paket için bir ACK göndermek yerine kayıp paketler için NACK (n) gönderirsek daha hızlı olur. Peki NACK ve viceversa üzerinden ACK ne zaman / hangi durumlarda kullanılır?
Şahsen ACK'ya ihtiyaç olduğunu bile hissetmiyorum. Alınan her paket için bir ACK göndermek yerine kayıp paketler için NACK (n) gönderirsek daha hızlı olur. Peki NACK ve viceversa üzerinden ACK ne zaman / hangi durumlarda kullanılır?
Yanıtlar:
ACK'nın nedeni bir NACK'in yeterli olmamasıdır. Size X segmentlerinin bir veri akışını gönderdiğimi varsayalım (basitlik için 10 diyelim).
Kötü bir bağlantınız var ve yalnızca 1, 2, 4 ve 5 numaralı bölümleri alıyorsunuz. Bilgisayarınız bölüm 3 için NACK gönderir, ancak 6-10 numaralı bölümler olması gerektiğini ve bunların NACK olmadığını fark etmez.
Bu nedenle, segment 3'ü tekrar gönderiyorum, ancak daha sonra bilgisayarım verilerin hatalı bir şekilde gönderildiğine inanıyor.
ACK'ler, segmentin hedefe ulaştığına dair bazı güvence sağlar.
Uygulamanın veri ve yeniden iletimlerin sırası ile ilgilenmesini istiyorsanız, UDP gibi bir protokol kullanmayı tercih edebilirsiniz (örneğin, TFTP'nin yaptığı gibi).
Her şey kayıp olasılık dağılımı ve trafik modeline dayanır.
Örneğin, sabit bir% 10-30 kayıp oranıyla tipik bir kablosuz bağlantıyı ele alalım. Alınan her kareyi (802.11abg gibi) onaylarsanız, bir karenin ne zaman kaybolduğunu hızlı bir şekilde tespit edersiniz, böylece zaman aşımını beklemek için zaman kaybetmezsiniz.
Bunun yerine NAK için olsaydınız, trafik düzenine bağımlı olursunuz: - Tek bir istek paketi gönderir ve bir yanıt beklerseniz ve bu istek kaybolursa, Cevap. - Çoğunlukla sessiz alıcıya sadece bir paket akışı gönderiyorsanız, yalnızca alıcı bir sonraki paketi aldığında NAK almak kabul edilebilir. Ancak bu, alıcının paketleri yeniden sıralaması gerektiği ve gönderenin gönderdiği iletilerin büyük birikmiş işlerini izlemesi gerektiği anlamına gelir.
(802.11n'nin hangi çözümü seçtiğini tahmin edin? her ikisi de. Alıcı aldığı kare uzunluğundaki değişken bitmap'i gönderir)
Şimdi tipik bir İnternet ağı alın: Kötü bir şey olana kadar% 0'a yakın paket kaybınız var ve bir üstel dağıtım yasasını takip eden belirli bir süre için 200 ms'lik bir kesintiden bir dakikaya ve bir dakikaya kadar% 100'e yakın paket kaybınız var. yarım.
Bağlantının kesildiği durumu düşününceye kadar her paketi almak kayıpsız bir ağda anlamsız görünecektir: ACK veya NACK'i uzun bir süre boyunca almazsınız ve alıcı bağlantıya kadar genellikle hiçbir şey göndermez geri yüklendi.
ACK kullanırsanız, gönderen göndermeyi durduracak ve bağlantı geri yükleninceye kadar biriktirmeye devam edecektir. Bunun yerine NACK kullanırsanız, alıcı sonunda, göndericinin birikmesinden uzun bir süre sonra düşen paketi almadığını ve bağlantının temelde kurtarılamaz olduğunu söyleyebilir.
ACK'lar kayan pencere protokollerinde faydalıdır, Verici A'nın uzaktaki B tarafından alınan verilerin alındığının farkında olmasına izin verir. Verici A, daha sonra iletim penceresi dolana kadar (uzak olana gönderilen verilerin henüz gönderilmediği halde sonraki verileri göndermeye devam edebilir). kabul).
ACK'ların NAK'lardan daha önemli olduğu düşünülebilir. A tarafından gönderilen bir paketin / bloğun B tarafından alınmaması ve B'nin bir şekilde bir paketin / bloğun eksik olduğunu tespit etmesi durumunda NAK'ler daha hızlı iyileşmeye izin verir .
NAK olmadan yalnızca ACK ile güvenilir aktarım ve akış kontrolünü destekleyen bir protokol tasarlamak mümkündür (Vericinin her durumda gerekli olan bir ACK, yeniden iletim mekanizması almaması durumunda Verici tarafından yeniden iletim ile).
Burada eklemek istiyorum en önemli şey, TCP, biz HER ALINAN PAKET için ACK göndermeyin.
Ancak, ACK'lar yalnızca SON ALINAN PAKET için gönderilir.
Yanlışım varsa lütfen düzelt.