計(jì)算機(jī)網(wǎng)絡(luò)中的帶寬、交換結(jié)點(diǎn)中的緩存和處理機(jī)等，都是網(wǎng)絡(luò)的資源。在某段時(shí)間，若對(duì)網(wǎng)絡(luò)中某一資源的需求超過(guò)了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就會(huì)變壞。這種情況就叫做擁塞。擁塞控制就是防止過(guò)多的數(shù)據(jù)注入網(wǎng)絡(luò)中，這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不致過(guò)載。擁塞控制是一個(gè)全局性的過(guò)程，和流量控制不同，流量控制指點(diǎn)對(duì)點(diǎn)通信量的控制。
TCP通過(guò)滑動(dòng)窗口機(jī)制檢測(cè)丟包，并在丟包發(fā)生時(shí)調(diào)整數(shù)據(jù)傳輸速率?；瑒?dòng)窗口機(jī)制利用數(shù)據(jù)接收端的接收窗口來(lái)控制數(shù)據(jù)流。
接收窗口值由數(shù)據(jù)接收端指定，以字節(jié)數(shù)形式存儲(chǔ)于TCP報(bào)文頭，并告知傳輸設(shè)備有多少數(shù)據(jù)將會(huì)存儲(chǔ)在TCP緩沖區(qū)。緩沖區(qū)就是數(shù)據(jù)暫時(shí)放置的地方，直至傳遞至應(yīng)用層協(xié)議等待處理。因此，發(fā)送端每次只能發(fā)送Window Size字段指定的數(shù)據(jù)量。為了使發(fā)送端繼續(xù)傳送數(shù)據(jù)，接收端必須發(fā)送確認(rèn)信息：之前的數(shù)據(jù)接收到了。同時(shí)必須對(duì)占用緩沖區(qū)的數(shù)據(jù)進(jìn)行處理以釋放緩存空間。下圖顯示了接收窗口是如何工作的：
上圖中，客戶端向服務(wù)器發(fā)送數(shù)據(jù)，服務(wù)器接收窗口是5000字節(jié)?？蛻舳税l(fā)送了2500字節(jié)，服務(wù)器緩沖區(qū)還剩2500字節(jié)，之后又發(fā)送了2000字節(jié)，從而緩沖區(qū)只剩500字節(jié)。服務(wù)器發(fā)送確認(rèn)信息。對(duì)緩存中數(shù)據(jù)進(jìn)行處理并清空緩存。此過(guò)程重復(fù)進(jìn)行，客戶端又發(fā)送3000字節(jié)和1000字節(jié)，服務(wù)器緩存減少至1000字節(jié)，客戶端再次確認(rèn)數(shù)據(jù)并處理緩存中內(nèi)容。
調(diào)整窗口大?。?/strong>
當(dāng)TCP堆 棧接收到數(shù)據(jù)的時(shí)候，生成一個(gè)確認(rèn)信息并以回復(fù)的方式發(fā)送，但是放置在接收端緩存中的數(shù)據(jù)并不總是立即被處理。當(dāng)服務(wù)器忙于處理從多個(gè)客戶端接收的報(bào)文， 服務(wù)器很有可能因?yàn)榍謇砭彺娑兊镁徛?，無(wú)法騰出空間接收新的數(shù)據(jù)，如果沒(méi)有流控，則可能會(huì)造成丟包和數(shù)據(jù)損壞。好在，接收窗口所設(shè)定的速率無(wú)法使服務(wù)器 正常處理數(shù)據(jù)時(shí)，能夠調(diào)整接收窗口大小。通過(guò)減小返回給發(fā)送端的ACK報(bào)文的TCP頭窗口大小值來(lái)實(shí)現(xiàn)。如下圖所示：
上圖中，服務(wù)器初始窗口大小為5000字節(jié)?？蛻舳税l(fā)送2000字節(jié)，之后又發(fā)送了2000字節(jié)，緩沖區(qū)中只有1000字節(jié)可用。服務(wù)器意識(shí)到緩沖區(qū)正在快速填滿，它知道如果數(shù)據(jù)繼續(xù)以此速率傳輸，很快會(huì)有報(bào)文丟失。為了防止報(bào)文丟失，服務(wù)器發(fā)送確認(rèn)信息給客戶端，更新窗口大小為1000字節(jié)。結(jié)果，客戶端減少數(shù)據(jù)發(fā)送，服務(wù)器以可以接受的速率處理緩存內(nèi)容，即保持?jǐn)?shù)據(jù)流以穩(wěn)定的速率傳輸。
調(diào)整窗口大小在兩個(gè)方向都是可行的。當(dāng)服務(wù)器能夠更加快速的處理報(bào)文時(shí)，它會(huì)發(fā)送一個(gè)較大窗口的ACK報(bào)文。
零窗口暫停數(shù)據(jù)流：
某些情況下，服務(wù)器無(wú)法再處理從客戶端發(fā)送的數(shù)據(jù)?？赡苁怯捎趦?nèi)存不足，處理能力不夠，或其他原因。這可能會(huì)造成數(shù)據(jù)被丟棄以及傳輸暫停，但接收窗口能夠幫助減小負(fù)面影響。
當(dāng)上述情況發(fā)生時(shí)，服務(wù)器會(huì)發(fā)送窗口為0的報(bào)文。當(dāng)客戶端接收到此報(bào)文時(shí)，它會(huì)暫停所有數(shù)據(jù)傳輸，但會(huì)保持與服務(wù)器的連接以傳輸探測(cè)(keep-alive)報(bào)文。探測(cè)報(bào)文在客戶端以穩(wěn)定間隙發(fā)送，以查看服務(wù)器接收窗口狀態(tài)。一旦服務(wù)器能夠再次處理數(shù)據(jù)，將會(huì)返回非零值窗口大小，傳輸會(huì)恢復(fù)。下圖示例了零窗口通知過(guò)程。
服務(wù)器初始接收數(shù)據(jù)窗口為5000字節(jié)大小。從客戶端接收4000字節(jié)數(shù)據(jù)之后，服務(wù)器負(fù)載變得非常繁重，無(wú)法繼續(xù)處理客戶端任何數(shù)據(jù)。服務(wù)器于是發(fā)送窗口大小值為0的報(bào)文?？蛻舳藭和?shù)據(jù)傳輸并發(fā)送一個(gè)探測(cè)報(bào)文。探測(cè)報(bào)文之后，服務(wù)器回復(fù)以告知客戶端現(xiàn)在可以接收數(shù)據(jù)的報(bào)文，以及窗口大小為1000字節(jié)?？蛻舳嘶謴?fù)傳送數(shù)據(jù)。
TCP滑動(dòng)窗口實(shí)戰(zhàn)：
本例中，開(kāi)始從192.168.0.20發(fā)送至192.168.0.30。我們關(guān)心的是窗口大小字段，可以從Packet List面板的Info欄以及Packet Details的TCP報(bào)文頭看到。前三個(gè)報(bào)文后，可看到該值立刻減小，如下圖所示：
窗口大小值從第一個(gè)報(bào)文的8760字節(jié)變成第二個(gè)報(bào)文的5840字節(jié)到第三個(gè)報(bào)文的2920字節(jié)①。窗口大小值的減小是主機(jī)延時(shí)的典型標(biāo)志。在時(shí)間欄注意到這一過(guò)程發(fā)生的非常迅速②。當(dāng)窗口大小迅速減小的時(shí)候，通常就有可能下降為零。這就是第四個(gè)報(bào)文所發(fā)生的，如下圖所示：
第四個(gè)報(bào)文從192.168.0.20發(fā)送至192.168.0.30，目的是告訴192.168.0.30它不再接收任何數(shù)據(jù)。0值見(jiàn)于TCP報(bào)文頭①，Wireshark的Packet List面板Info欄，以及TCP報(bào)文頭的SEQ/ACK Analysis字段②也告訴我們這是一個(gè)0窗口報(bào)文。
一旦發(fā)送了零窗口報(bào)文，192.168.0.30的設(shè)備不會(huì)再發(fā)送任何數(shù)據(jù)，直到收到從192.168.0.20的窗口更新，告知窗口大小已經(jīng)增加了。本例中導(dǎo)致零窗口的問(wèn)題是暫時(shí)的，所以在下一個(gè)報(bào)文中發(fā)送了窗口更新信息，如下圖所示。
本例中，窗口大小增加到一個(gè)非常健康的數(shù)值64，240字節(jié)①。Wireshark再次在SEQ/ACK Analysis告訴我們這是一個(gè)窗口更新。
一旦收到更新報(bào)文，192.168.0.30的主機(jī)就再次開(kāi)始發(fā)送數(shù)據(jù)，在報(bào)文6和報(bào)文7中。這一過(guò)程發(fā)生很快。如果它持續(xù)時(shí)間再長(zhǎng)一點(diǎn)，就可能會(huì)導(dǎo)致網(wǎng)絡(luò)的潛在中斷，引起數(shù)據(jù)傳輸減慢或失敗。
下一個(gè)關(guān)于滑動(dòng)窗口的例子，第一個(gè)報(bào)文是正常HTTP，從195.81.202.68至172.31.136.85。此報(bào)文之后立刻跟隨一個(gè)從172.31.136.85發(fā)送的零窗口報(bào)文，如下圖所示：
這與上一個(gè)例子中的零窗口報(bào)文十分類似，但結(jié)果顯著不同，172.31.136.85主機(jī)不是發(fā)送一個(gè)窗口更新并回復(fù)通訊，而是一個(gè)探測(cè)報(bào)文，如下圖所示：
此報(bào)文被Wireshark標(biāo)注為探測(cè)報(bào)文①。時(shí)間欄告訴我們這一報(bào)文發(fā)生于最后一個(gè)接收到的報(bào)文3.4秒之后。這一過(guò)程持續(xù)若干次，一端發(fā)送零窗口報(bào)文另一端發(fā)送探測(cè)報(bào)文，如下圖所示：
探測(cè)報(bào)文發(fā)送間隙為3.4，6.8，13.5秒。這一過(guò)程可能會(huì)持續(xù)相當(dāng)長(zhǎng)一段時(shí)間，取決于通訊設(shè)備的操作系統(tǒng)。該情況下，把時(shí)間欄的值加起來(lái)，通訊暫停了25秒。
TCP差錯(cuò)控制和流控排查總結(jié)：
重傳報(bào)文
重 傳的發(fā)生是由于客戶端檢測(cè)到服務(wù)器沒(méi)有接收到它所發(fā)送的數(shù)據(jù)。因此，取決于你所分析的是通訊的哪一端，有可能是看不見(jiàn)重傳的。如果從服務(wù)器端抓取數(shù)據(jù)，并 且它確實(shí)沒(méi)有接收到客戶端所發(fā)送的和重傳報(bào)文，可能會(huì)一無(wú)所獲因?yàn)闊o(wú)法看見(jiàn)重傳報(bào)文。如果懷疑并不是服務(wù)器端導(dǎo)致的報(bào)文丟失，可以考慮在客戶端嘗試抓取報(bào) 文，以查看實(shí)際是否有重傳發(fā)生。
重復(fù)ACK
可以將重復(fù)ACK看作重傳的“所謂相反面”，因?yàn)樗窃诜?wù)器檢測(cè)到客戶端發(fā)送報(bào)文丟失的時(shí)候產(chǎn)生的。大多數(shù)情況下，在通訊兩端抓取流量時(shí)都可以看到重復(fù)ACK。需記住當(dāng)接收?qǐng)?bào)文亂序時(shí)會(huì)觸發(fā)重復(fù)ACK。例如，如果服務(wù)器之接收到發(fā)送的第一個(gè)和第三個(gè)報(bào)文，就會(huì)導(dǎo)致發(fā)送重復(fù)ACK引起客戶端對(duì)第二個(gè)報(bào)文的快速重傳，因?yàn)槟阋呀?jīng)收到了第一個(gè)和第三個(gè)報(bào)文，因此不管導(dǎo)致第二個(gè)報(bào)文丟棄的原因是什么，都很有可能是暫時(shí)的，因此大多數(shù)情況下重復(fù)ACK都會(huì)成功發(fā)送和接收。當(dāng)然，這種情形并不一定永遠(yuǎn)會(huì)發(fā)生，因此當(dāng)你懷疑在服務(wù)器端丟失報(bào)文而又看不到任何重復(fù)ACK，考慮從通訊的客戶端抓取報(bào)文。
零窗口和探測(cè)報(bào)文
滑動(dòng)窗口直接與服務(wù)器無(wú)法接收和處理報(bào)文有關(guān)，任何窗口大小的縮小以及零值都是服務(wù)器問(wèn)題的直接結(jié)果。所以如果你在哪里看到這兩者之一發(fā)生，就應(yīng)該在那里深入研究。通常應(yīng)當(dāng)在網(wǎng)絡(luò)通訊兩端一直主機(jī)窗口更新報(bào)文。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-466365.html
以上就是解決TCP窗口與擁塞控制的辦法，希望能幫到大家，謝謝閱讀。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-466365.html
到了這里，關(guān)于如何解決TCP窗口與擁塞？ TCP窗口與擁塞控制的解決辦法的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
