前記：TCP/IP詳解系列，畢竟不是一本教材，很多地方講的不細(xì)致。比如SWS未說明是什么就開始介紹其避免方法，還和nagle扯在了一起，直覺告訴我二者一定有貓膩，邊搜索一下，果然很有收獲。今天貼在這里，分享給大家。
第一部分：SWS
何謂糊涂窗口綜合癥
當(dāng)發(fā)送端應(yīng)用進(jìn)程產(chǎn)生數(shù)據(jù)很慢、或接收端應(yīng)用進(jìn)程處理接收緩沖區(qū)數(shù)據(jù)很慢，或二者兼而有之；就會(huì)使應(yīng)用進(jìn)程間傳送的報(bào)文段很小，特別是有效載荷很小。 極端情況下，有效載荷可能只有1個(gè)字節(jié)；而傳輸開銷有40字節(jié)(20字節(jié)的IP頭+20字節(jié)的TCP頭) 這種現(xiàn)象就叫糊涂窗口綜合癥。
發(fā)送端引起的SWS
如果發(fā)送端為產(chǎn)生數(shù)據(jù)很慢的應(yīng)用程序服務(wù)(典型的有telnet應(yīng)用)，例如，一次產(chǎn)生一個(gè)字節(jié)。這個(gè)應(yīng)用程序一次將一個(gè)字節(jié)的數(shù)據(jù)寫入發(fā)送端的TCP的緩存。如果發(fā)送端的TCP沒有特定的指令，它就產(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í)間呢？如果它等待過長(zhǎng)，它就會(huì)使整個(gè)的過程產(chǎn)生較長(zhǎng)的時(shí)延。如果它的等待時(shí)間不夠長(zhǎng)，它就可能發(fā)送較小的報(bào)文段，于是，Nagle找到了一個(gè)很好的解決方法，發(fā)明了Nagle算法。而他選擇的等待時(shí)間是一個(gè)RTT,即下個(gè)ACK來(lái)到時(shí)。
接收端引起的SWS
接收端的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ǔ)在其緩存中?，F(xià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)文段。這樣的過程一直繼續(xù)下去。一個(gè)字節(jié)的數(shù)據(jù)被消耗掉，然后發(fā)送只包含一個(gè)字節(jié)數(shù)據(jù)的報(bào)文段。
對(duì)于這種糊涂窗口綜合癥，即應(yīng)用程序消耗數(shù)據(jù)比到達(dá)的慢，有兩種建議的解決方法：
1） Clark解決方法 Clark解決方法是只要有數(shù)據(jù)到達(dá)就發(fā)送確認(rèn)，但宣布的窗口大小為零，直到或者緩存空間已能放入具有最大長(zhǎng)度的報(bào)文段，或者緩存空間的一半已經(jīng)空了。
2 ）延遲確認(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)文段?？梢杂脜f(xié)議來(lái)平衡這個(gè)優(yōu)點(diǎn)和缺點(diǎn)，例如現(xiàn)在定義了確認(rèn)的延遲不能超過500毫秒。
第二部分：Nagle算法
TCP/IP協(xié)議中，無(wú)論發(fā)送多少數(shù)據(jù)，總是要在數(shù)據(jù)前面加上協(xié)議頭，同時(shí)，對(duì)方接收到數(shù)據(jù)，也需要發(fā)送ACK表示確認(rèn)。為了盡可能的利用網(wǎng)絡(luò)帶寬，TCP總是希望盡可能的發(fā)送足夠大的數(shù)據(jù)。（一個(gè)連接會(huì)設(shè)置MSS參數(shù)，因此，TCP/IP希望每次都能夠以MSS尺寸的數(shù)據(jù)塊來(lái)發(fā)送數(shù)據(jù)）。Nagle算法就是為了盡可能發(fā)送大塊數(shù)據(jù)，避免網(wǎng)絡(luò)中充斥著許多小數(shù)據(jù)塊。
Nagle算法的基本定義是任意時(shí)刻，最多只能有一個(gè)未被確認(rèn)的小段。 所謂“小段”，指的是小于MSS尺寸的數(shù)據(jù)塊，所謂“未被確認(rèn)”，是指一個(gè)數(shù)據(jù)塊發(fā)送出去后，沒有收到對(duì)方發(fā)送的ACK確認(rèn)該數(shù)據(jù)已收到。
Nagle算法的規(guī)則（可參考tcp_output.c文件里tcp_nagle_check函數(shù)注釋）：
（1）如果包長(zhǎng)度達(dá)到MSS，則允許發(fā)送；
（2）如果該包含有FIN，則允許發(fā)送；
（3）設(shè)置了TCP_NODELAY選項(xiàng)，則允許發(fā)送；
（4）未設(shè)置TCP_CORK選項(xiàng)時(shí)，若所有發(fā)出去的小數(shù)據(jù)包（包長(zhǎng)度小于MSS）均被確認(rèn)，則允許發(fā)送；
（5）上述條件都未滿足，但發(fā)生了超時(shí)（一般為200ms），則立即發(fā)送。
Nagle算法只允許一個(gè)未被ACK的包存在于網(wǎng)絡(luò)，它并不管包的大小，因此它事實(shí)上就是一個(gè)擴(kuò)展的停-等協(xié)議，只不過它是基于包停-等的，而不是基于字節(jié)停-等的。Nagle算法完全由TCP協(xié)議的ACK機(jī)制決定，這會(huì)帶來(lái)一些問題，比如如果對(duì)端ACK回復(fù)很快的話，Nagle事實(shí)上不會(huì)拼接太多的數(shù)據(jù)包，雖然避免了網(wǎng)絡(luò)擁塞，網(wǎng)絡(luò)總體的利用率依然很低。另外，他是一個(gè)自適應(yīng)的方法，讀者可以自己按上述規(guī)則試驗(yàn)一下。
Nagle算法是silly window syndrome(SWS)預(yù)防算法的一個(gè)半集。SWS算法預(yù)防發(fā)送少量的數(shù)據(jù)，Nagle算法是其在發(fā)送方的實(shí)現(xiàn)，而接收方要做的時(shí)不要通告緩沖空間的很小增長(zhǎng)，不通知小窗口，除非緩沖區(qū)空間有顯著的增長(zhǎng)。這里顯著的增長(zhǎng)定義為完全大小的段（MSS）或增長(zhǎng)到大于最大窗口的一半。
注意：BSD的實(shí)現(xiàn)是允許在空閑鏈接上發(fā)送大的寫操作剩下的最后的小段，也就是說，當(dāng)超過1個(gè)MSS數(shù)據(jù)發(fā)送時(shí)，內(nèi)核先依次發(fā)送完n個(gè)MSS的數(shù)據(jù)包，然后再發(fā)送尾部的小數(shù)據(jù)包，其間不再延時(shí)等待。（假設(shè)網(wǎng)絡(luò)不阻塞且接收窗口足夠大）
TCP_NODELAY 選項(xiàng)
默認(rèn)情況下，發(fā)送數(shù)據(jù)采用Negale 算法。這樣雖然提高了網(wǎng)絡(luò)吞吐量，但是實(shí)時(shí)性卻降低了，在一些交互性很強(qiáng)的應(yīng)用程序來(lái)說是不允許的，使用TCP_NODELAY選項(xiàng)可以禁止Negale 算法。
此時(shí)，應(yīng)用程序向內(nèi)核遞交的每個(gè)數(shù)據(jù)包都會(huì)立即發(fā)送出去。需要注意的是，雖然禁止了Negale 算法，但網(wǎng)絡(luò)的傳輸仍然受到TCP確認(rèn)延遲機(jī)制的影響。
TCP_CORK 選項(xiàng)
所謂的CORK就是塞子的意思，形象地理解就是用CORK將連接塞住，使得數(shù)據(jù)先不發(fā)出去，等到拔去塞子后再發(fā)出去。設(shè)置該選項(xiàng)后，內(nèi)核會(huì)盡力把小數(shù)據(jù)包拼接成一個(gè)大的數(shù)據(jù)包（一個(gè)MTU）再發(fā)送出去，當(dāng)然若一定時(shí)間后（一般為200ms，該值尚待確認(rèn)），內(nèi)核仍然沒有組合成一個(gè)MTU時(shí)也必須發(fā)送現(xiàn)有的數(shù)據(jù)（不可能讓數(shù)據(jù)一直等待吧）。
然而，TCP_CORK的實(shí)現(xiàn)可能并不像你想象的那么完美，CORK并不會(huì)將連接完全塞住。內(nèi)核其實(shí)并不知道應(yīng)用層到底什么時(shí)候會(huì)發(fā)送第二批數(shù)據(jù)用于和第一批數(shù)據(jù)拼接以達(dá)到MTU的大小，因此內(nèi)核會(huì)給出一個(gè)時(shí)間限制，在該時(shí)間內(nèi)沒有拼接成一個(gè)大包（努力接近MTU）的話，內(nèi)核就會(huì)無(wú)條件發(fā)送。也就是說若應(yīng)用層程序發(fā)送小包數(shù)據(jù)的間隔不夠短時(shí)，TCP_CORK就沒有一點(diǎn)作用，反而失去了數(shù)據(jù)的實(shí)時(shí)性（每個(gè)小包數(shù)據(jù)都會(huì)延時(shí)一定時(shí)間再發(fā)送）。
Nagle算法與CORK算法區(qū)別
Nagle算法和CORK算法非常類似，但是它們的著眼點(diǎn)不一樣，Nagle算法主要避免網(wǎng)絡(luò)因?yàn)樘嗟男“▍f(xié)議頭的比例非常之大）而擁塞，而CORK算法則是為了提高網(wǎng)絡(luò)的利用率，使得總體上協(xié)議頭占用的比例盡可能的小。如此看來(lái)這二者在避免發(fā)送小包上是一致的，在用戶控制的層面上，Nagle算法完全不受用戶socket的控制，你只能簡(jiǎn)單的設(shè)置TCP_NODELAY而禁用它，CORK算法同樣也是通過設(shè)置或者清除TCP_CORK使能或者禁用之，然而Nagle算法關(guān)心的是網(wǎng)絡(luò)擁塞問題，只要所有的ACK回來(lái)則發(fā)包，而CORK算法卻可以關(guān)心內(nèi)容，在前后數(shù)據(jù)包發(fā)送間隔很短的前提下（很重要，否則內(nèi)核會(huì)幫你將分散的包發(fā)出），即使你是分散發(fā)送多個(gè)小數(shù)據(jù)包，你也可以通過使能CORK算法將這些內(nèi)容拼接在一個(gè)包內(nèi)，如果此時(shí)用Nagle算法的話，則可能做不到這一點(diǎn)。
參考：http://www.cnblogs.com/ggjucheng/archive/2012/02/03/2337046.html