前記：TCP/IP詳解系列，畢竟不是一本教材，很多地方講的不細(xì)致。比如SWS未說明是什么就開始介紹其避免方法，還和nagle扯在了一起，直覺告訴我二者一定有貓膩，邊搜索一下，果然很有收獲。今天貼在這里，分享給大家。 

第一部分：SWS

何謂糊涂窗口綜合癥

　　當(dāng)發(fā)送端應(yīng)用進程產(chǎn)生數(shù)據(jù)很慢、或接收端應(yīng)用進程處理接收緩沖區(qū)數(shù)據(jù)很慢，或二者兼而有之；就會使應(yīng)用進程間傳送的報文段很小，特別是有效載荷很小。 極端情況下，有效載荷可能只有1個字節(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)生一個字節(jié)。這個應(yīng)用程序一次將一個字節(jié)的數(shù)據(jù)寫入發(fā)送端的TCP的緩存。如果發(fā)送端的TCP沒有特定的指令，它就產(chǎn)生只包括一個字節(jié)數(shù)據(jù)的報文段。結(jié)果有很多41字節(jié)的IP數(shù)據(jù)報就在互連網(wǎng)中傳來傳去。解決的方法是防止發(fā)送端的TCP逐個字節(jié)地發(fā)送數(shù)據(jù)。必須強迫發(fā)送端的TCP收集數(shù)據(jù)，然后用一個更大的數(shù)據(jù)塊來發(fā)送。發(fā)送端的TCP要等待多長時間呢？如果它等待過長，它就會使整個的過程產(chǎn)生較長的時延。如果它的等待時間不夠長，它就可能發(fā)送較小的報文段，于是，Nagle找到了一個很好的解決方法，發(fā)明了Nagle算法。而他選擇的等待時間是一個RTT,即下個ACK來到時。

接收端引起的SWS

　　接收端的TCP可能產(chǎn)生糊涂窗口綜合癥，如果它為消耗數(shù)據(jù)很慢的應(yīng)用程序服務(wù)，例如，一次消耗一個字節(jié)。假定發(fā)送應(yīng)用程序產(chǎn)生了1000字節(jié)的數(shù)據(jù)塊，但接收應(yīng)用程序每次只吸收1字節(jié)的數(shù)據(jù)。再假定接收端的TCP的輸入緩存為4000字節(jié)。發(fā)送端先發(fā)送第一個4000字節(jié)的數(shù)據(jù)。接收端將它存儲在其緩存中。現(xiàn)在緩存滿了。它通知窗口大小為零，這表示發(fā)送端必須停止發(fā)送數(shù)據(jù)。接收應(yīng)用程序從接收端的TCP的輸入緩存中讀取第一個字節(jié)的數(shù)據(jù)。在入緩存中現(xiàn)在有了1字節(jié)的空間。接收端的TCP宣布其窗口大小為1字節(jié)，這表示正渴望等待發(fā)送數(shù)據(jù)的發(fā)送端的TCP會把這個宣布當(dāng)作一個好消息，并發(fā)送只包括一個字節(jié)數(shù)據(jù)的報文段。這樣的過程一直繼續(xù)下去。一個字節(jié)的數(shù)據(jù)被消耗掉，然后發(fā)送只包含一個字節(jié)數(shù)據(jù)的報文段。

　　對于這種糊涂窗口綜合癥，即應(yīng)用程序消耗數(shù)據(jù)比到達(dá)的慢，有兩種建議的解決方法：
　　1） Clark解決方法 Clark解決方法是只要有數(shù)據(jù)到達(dá)就發(fā)送確認(rèn)，但宣布的窗口大小為零，直到或者緩存空間已能放入具有最大長度的報文段，或者緩存空間的一半已經(jīng)空了。
　　2 ）延遲確認(rèn) 第二個解決方法是延遲一段時間后再發(fā)送確認(rèn)。這表示當(dāng)一個報文段到達(dá)時并不立即發(fā)送確認(rèn)。接收端在確認(rèn)收到的報文段之前一直等待，直到入緩存有足夠的空間為止。延遲的確認(rèn)防止了發(fā)送端的TCP滑動其窗口。當(dāng)發(fā)送端的TCP發(fā)送完其數(shù)據(jù)后，它就停下來了。這樣就防止了這種癥狀。遲延的確認(rèn)還有另一個優(yōu)點：它減少了通信量。接收端不需要確認(rèn)每一個報文段。但它也有一個缺點，就是遲延的確認(rèn)有可能迫使發(fā)送端重傳其未被確認(rèn)的報文段。可以用協(xié)議來平衡這個優(yōu)點和缺點，例如現(xiàn)在定義了確認(rèn)的延遲不能超過500毫秒。

第二部分：Nagle算法

        TCP/IP協(xié)議中，無論發(fā)送多少數(shù)據(jù)，總是要在數(shù)據(jù)前面加上協(xié)議頭，同時，對方接收到數(shù)據(jù)，也需要發(fā)送ACK表示確認(rèn)。為了盡可能的利用網(wǎng)絡(luò)帶寬，TCP總是希望盡可能的發(fā)送足夠大的數(shù)據(jù)。（一個連接會設(shè)置MSS參數(shù)，因此，TCP/IP希望每次都能夠以MSS尺寸的數(shù)據(jù)塊來發(fā)送數(shù)據(jù)）。Nagle算法就是為了盡可能發(fā)送大塊數(shù)據(jù)，避免網(wǎng)絡(luò)中充斥著許多小數(shù)據(jù)塊。
        Nagle算法的基本定義是任意時刻，最多只能有一個未被確認(rèn)的小段。 所謂“小段”，指的是小于MSS尺寸的數(shù)據(jù)塊，所謂“未被確認(rèn)”，是指一個數(shù)據(jù)塊發(fā)送出去后，沒有收到對方發(fā)送的ACK確認(rèn)該數(shù)據(jù)已收到。
        Nagle算法的規(guī)則（可參考tcp_output.c文件里tcp_nagle_check函數(shù)注釋）： 

      （1）如果包長度達(dá)到MSS，則允許發(fā)送；

      （2）如果該包含有FIN，則允許發(fā)送；

      （3）設(shè)置了TCP_NODELAY選項，則允許發(fā)送；

      （4）未設(shè)置TCP_CORK選項時，若所有發(fā)出去的小數(shù)據(jù)包（包長度小于MSS）均被確認(rèn)，則允許發(fā)送； 

      （5）上述條件都未滿足，但發(fā)生了超時（一般為200ms），則立即發(fā)送。

         Nagle算法只允許一個未被ACK的包存在于網(wǎng)絡(luò)，它并不管包的大小，因此它事實上就是一個擴展的停-等協(xié)議，只不過它是基于包停-等的，而不是基于字節(jié)停-等的。Nagle算法完全由TCP協(xié)議的ACK機制決定，這會帶來一些問題，比如如果對端ACK回復(fù)很快的話，Nagle事實上不會拼接太多的數(shù)據(jù)包，雖然避免了網(wǎng)絡(luò)擁塞，網(wǎng)絡(luò)總體的利用率依然很低。另外，他是一個自適應(yīng)的方法，讀者可以自己按上述規(guī)則試驗一下。 

        Nagle算法是silly window syndrome(SWS)預(yù)防算法的一個半集。SWS算法預(yù)防發(fā)送少量的數(shù)據(jù)，Nagle算法是其在發(fā)送方的實現(xiàn)，而接收方要做的時不要通告緩沖空間的很小增長，不通知小窗口，除非緩沖區(qū)空間有顯著的增長。這里顯著的增長定義為完全大小的段（MSS）或增長到大于最大窗口的一半。

注意：BSD的實現(xiàn)是允許在空閑鏈接上發(fā)送大的寫操作剩下的最后的小段，也就是說，當(dāng)超過1個MSS數(shù)據(jù)發(fā)送時，內(nèi)核先依次發(fā)送完n個MSS的數(shù)據(jù)包，然后再發(fā)送尾部的小數(shù)據(jù)包，其間不再延時等待。（假設(shè)網(wǎng)絡(luò)不阻塞且接收窗口足夠大）

TCP_NODELAY 選項

        默認(rèn)情況下，發(fā)送數(shù)據(jù)采用Negale 算法。這樣雖然提高了網(wǎng)絡(luò)吞吐量，但是實時性卻降低了，在一些交互性很強的應(yīng)用程序來說是不允許的，使用TCP_NODELAY選項可以禁止Negale 算法。 

        此時，應(yīng)用程序向內(nèi)核遞交的每個數(shù)據(jù)包都會立即發(fā)送出去。需要注意的是，雖然禁止了Negale 算法，但網(wǎng)絡(luò)的傳輸仍然受到TCP確認(rèn)延遲機制的影響。

TCP_CORK 選項 

        所謂的CORK就是塞子的意思，形象地理解就是用CORK將連接塞住，使得數(shù)據(jù)先不發(fā)出去，等到拔去塞子后再發(fā)出去。設(shè)置該選項后，內(nèi)核會盡力把小數(shù)據(jù)包拼接成一個大的數(shù)據(jù)包（一個MTU）再發(fā)送出去，當(dāng)然若一定時間后（一般為200ms，該值尚待確認(rèn)），內(nèi)核仍然沒有組合成一個MTU時也必須發(fā)送現(xiàn)有的數(shù)據(jù)（不可能讓數(shù)據(jù)一直等待吧）。
        然而，TCP_CORK的實現(xiàn)可能并不像你想象的那么完美，CORK并不會將連接完全塞住。內(nèi)核其實并不知道應(yīng)用層到底什么時候會發(fā)送第二批數(shù)據(jù)用于和第一批數(shù)據(jù)拼接以達(dá)到MTU的大小，因此內(nèi)核會給出一個時間限制，在該時間內(nèi)沒有拼接成一個大包（努力接近MTU）的話，內(nèi)核就會無條件發(fā)送。也就是說若應(yīng)用層程序發(fā)送小包數(shù)據(jù)的間隔不夠短時，TCP_CORK就沒有一點作用，反而失去了數(shù)據(jù)的實時性（每個小包數(shù)據(jù)都會延時一定時間再發(fā)送）。

Nagle算法與CORK算法區(qū)別

　　Nagle算法和CORK算法非常類似，但是它們的著眼點不一樣，Nagle算法主要避免網(wǎng)絡(luò)因為太多的小包（協(xié)議頭的比例非常之大）而擁塞，而CORK算法則是為了提高網(wǎng)絡(luò)的利用率，使得總體上協(xié)議頭占用的比例盡可能的小。如此看來這二者在避免發(fā)送小包上是一致的，在用戶控制的層面上，Nagle算法完全不受用戶socket的控制，你只能簡單的設(shè)置TCP_NODELAY而禁用它，CORK算法同樣也是通過設(shè)置或者清除TCP_CORK使能或者禁用之，然而Nagle算法關(guān)心的是網(wǎng)絡(luò)擁塞問題，只要所有的ACK回來則發(fā)包，而CORK算法卻可以關(guān)心內(nèi)容，在前后數(shù)據(jù)包發(fā)送間隔很短的前提下（很重要，否則內(nèi)核會幫你將分散的包發(fā)出），即使你是分散發(fā)送多個小數(shù)據(jù)包，你也可以通過使能CORK算法將這些內(nèi)容拼接在一個包內(nèi)，如果此時用Nagle算法的話，則可能做不到這一點。

參考：http://www.cnblogs.com/ggjucheng/archive/2012/02/03/2337046.html