|
7-13：能否更詳細(xì)些討論一下糊涂窗口綜合癥及其解決方法？ 答：發(fā)送端產(chǎn)生的癥狀 如果發(fā)送端為產(chǎn)生數(shù)據(jù)很慢的應(yīng)用程序服務(wù)，例如，一次產(chǎn)生一個(gè)字節(jié)。這個(gè)應(yīng)用程序一次將一個(gè)字節(jié)的數(shù)據(jù)寫(xiě)入發(fā)送端的TCP的緩存。如果發(fā)送端的TCP沒(méi)有特定的指令，它就產(chǎn)生只包括一個(gè)字節(jié)數(shù)據(jù)的報(bào)文段。結(jié)果有很多41字節(jié)的IP數(shù)據(jù)報(bào)就在互連網(wǎng)中傳來(lái)傳去。 解決的方法是防止發(fā)送端的TCP逐個(gè)字節(jié)地發(fā)送數(shù)據(jù)。必須強(qiáng)迫發(fā)送端的TCP收集數(shù)據(jù)，然后用一個(gè)更大的數(shù)據(jù)塊來(lái)發(fā)送。發(fā)送端的TCP要等待多長(zhǎng)時(shí)間呢？如果它等待過(guò)長(zhǎng)，它就會(huì)使整個(gè)的過(guò)程產(chǎn)生較長(zhǎng)的時(shí)延。如果它的等待時(shí)間不夠長(zhǎng)，它就可能發(fā)送較小的報(bào)文段。Nagle找到了一個(gè)很好的解決方法。 ?Nagle算法 Nagle算法非常簡(jiǎn)單，但它能解決問(wèn)題。這個(gè)算法是為發(fā)送端的TCP用的： 1. 發(fā)送端的TCP將它從發(fā)送應(yīng)用程序收到的第一塊數(shù)據(jù)發(fā)送出去，哪怕只有一個(gè)字節(jié)。 2. 在發(fā)送第一個(gè)報(bào)文段（即報(bào)文段1）以后，發(fā)送端的TCP就在輸出緩存中積累數(shù)據(jù)，并等待：或者接收端的TCP發(fā)送出一個(gè)確認(rèn)，或者數(shù)據(jù)已積累到可以裝成一個(gè)最大的報(bào)文段。在這個(gè)時(shí)候，發(fā)送端的TCP就可以發(fā)送這個(gè)報(bào)文段。 3. 對(duì)剩下的傳輸，重復(fù)步驟2。這就是：如果收到了對(duì)報(bào)文段x的確認(rèn)，或者數(shù)據(jù)已積累到可以裝成一個(gè)最大的報(bào)文段，那么就發(fā)送下一個(gè)報(bào)文段(x + 1)。 Nagle算法的優(yōu)點(diǎn)就是簡(jiǎn)單，并且它考慮到應(yīng)用程序產(chǎn)生數(shù)據(jù)的速率，以及網(wǎng)絡(luò)運(yùn)輸數(shù)據(jù)的速率。若應(yīng)用程序比網(wǎng)絡(luò)更快，則報(bào)文段就更大（最大報(bào)文段）。若應(yīng)用程序比網(wǎng)絡(luò)慢，則報(bào)文段就較小（小于最大報(bào)文段）。 接收端產(chǎn)生的癥狀 接收端的TCP可能產(chǎn)生糊涂窗口綜合癥，如果它為消耗數(shù)據(jù)很慢的應(yīng)用程序服務(wù)，例如，一次消耗一個(gè)字節(jié)。假定發(fā)送應(yīng)用程序產(chǎn)生了1000字節(jié)的數(shù)據(jù)塊，但接收應(yīng)用程序每次只吸收1字節(jié)的數(shù)據(jù)。再假定接收端的TCP的輸入緩存為4000字節(jié)。發(fā)送端先發(fā)送第一個(gè)4000字節(jié)的數(shù)據(jù)。接收端將它存儲(chǔ)在其緩存中。現(xiàn)在緩存滿(mǎn)了。它通知窗口大小為零，這表示發(fā)送端必須停止發(fā)送數(shù)據(jù)。接收應(yīng)用程序從接收端的TCP的輸入緩存中讀取第一個(gè)字節(jié)的數(shù)據(jù)。在入緩存中現(xiàn)在有了1字節(jié)的空間。接收端的TCP宣布其窗口大小為1字節(jié)，這表示正渴望等待發(fā)送數(shù)據(jù)的發(fā)送端的TCP會(huì)把這個(gè)宣布當(dāng)作一個(gè)好消息，并發(fā)送只包括一個(gè)字節(jié)數(shù)據(jù)的報(bào)文段。這樣的過(guò)程一直繼續(xù)下去。一個(gè)字節(jié)的數(shù)據(jù)被消耗掉，然后發(fā)送只包含一個(gè)字節(jié)數(shù)據(jù)的報(bào)文段。這又是一個(gè)效率問(wèn)題和糊涂窗口綜合癥（見(jiàn)下圖）。 對(duì)于這種糊涂窗口綜合癥，即應(yīng)用程序消耗數(shù)據(jù)比到達(dá)的慢，有兩種建議的解決方法。 ?Clark解決方法 Clark解決方法是只要有數(shù)據(jù)到達(dá)就發(fā)送確認(rèn)，但宣布的窗口大小為零，直到或者緩存空間已能放入具有最大長(zhǎng)度的報(bào)文段，或者緩存空間的一半已經(jīng)空了。 ?延遲的確認(rèn) 第二個(gè)解決方法是延遲一段時(shí)間后再發(fā)送確認(rèn)。這表示當(dāng)一個(gè)報(bào)文段到達(dá)時(shí)并不立即發(fā)送確認(rèn)。接收端在確認(rèn)收到的報(bào)文段之前一直等待，直到入緩存有足夠的空間為止。延遲的確認(rèn)防止了發(fā)送端的TCP滑動(dòng)其窗口。當(dāng)發(fā)送端的TCP發(fā)送完其數(shù)據(jù)后，它就停下來(lái)了。這樣就防止了這種癥狀。 遲延的確認(rèn)還有另一個(gè)優(yōu)點(diǎn)：它減少了通信量。接收端不需要確認(rèn)每一個(gè)報(bào)文段。但它也有一個(gè)缺點(diǎn)，就是遲延的確認(rèn)有可能迫使發(fā)送端重傳其未被確認(rèn)的報(bào)文段。 可以用協(xié)議來(lái)平衡這個(gè)優(yōu)點(diǎn)和缺點(diǎn)，例如現(xiàn)在定義了確認(rèn)的延遲不能超過(guò)500毫秒
| 
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
