TCP/IP詳解系列，關(guān)于tcp擁塞控制和數(shù)據(jù)流的地方講的不細(xì)致，或許是涉及概念/算法太多，作者略去了一些對(duì)初學(xué)者來說比較陌生的細(xì)節(jié)吧。比如SWS未說明是什么就開始介紹其避免方法，還和nagle扯在了一起，直覺告訴我二者一定有貓膩，邊搜索一下，果然很有收獲。今天貼在這里，分享給大家。?
關(guān)鍵字：糊涂窗口綜合癥 ?nagle算法 ?延遲ACK/clark算法 ? CORK選項(xiàng)
第一部分?糊涂窗口綜合癥
當(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ā)送端求解（negle）
如果發(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)中傳來傳去。解決的方法是防止發(fā)送端的TCP逐個(gè)字節(jié)地發(fā)送數(shù)據(jù)。必須強(qiáng)迫發(fā)送端的TCP收集數(shù)據(jù)，然后用一個(gè)更大的數(shù)據(jù)塊來發(fā)送。發(fā)送端的TCP要等待多長時(shí)間呢？如果它等待過長，它就會(huì)使整個(gè)的過程產(chǎn)生較長的時(shí)延。如果它的等待時(shí)間不夠長，它就可能發(fā)送較小的報(bào)文段，于是，Nagle找到了一個(gè)很好的解決方法，發(fā)明了Nagle算法。而他選擇的等待時(shí)間是一個(gè)RTT,即下個(gè)ACK來到時(shí)。
接收端求解（delay-ack）
接收端的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)，但宣布的窗口大小為零，直到或者緩存空間已能放入具有最大長度的報(bào)文段，或者緩存空間的一半已經(jīng)空了。
2 ）延遲確認(rèn)ACK?
? ? ? 這表示當(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ù)后，它就停下來了。這樣就防止了這種癥狀。遲延的確認(rèn)還有另一個(gè)優(yōu)點(diǎn)：它減少了通信量。接收端不需要確認(rèn)每一個(gè)報(bào)文段。但它也有一個(gè)缺點(diǎn)，就是遲延的確認(rèn)有可能迫使發(fā)送端重傳其未被確認(rèn)的報(bào)文段。可以用協(xié)議來平衡這個(gè)優(yōu)點(diǎn)和缺點(diǎn)，例如現(xiàn)在定義了確認(rèn)的延遲不能超過500毫秒。
第二部分：治療辦法
2.1 nagle算法
?? ? ? ?TCP/IP協(xié)議中，無論發(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ù)塊來發(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算法生效情況的補(bǔ)集，可以側(cè)面理解其本質(zhì)，參考tcp_output.c文件里tcp_nagle_check函數(shù)：
?? ? ?（1）如果包長度達(dá)到MSS，則允許發(fā)送；
?? ? ?（2）如果該包含有FIN，則允許發(fā)送；
?? ? ?（3）設(shè)置了TCP_NODELAY選項(xiàng)（意在禁止nagle），則允許發(fā)送；
?? ? ?（4）未設(shè)置TCP_CORK選項(xiàng)時(shí)，若所有發(fā)出去的小數(shù)據(jù)包（包長度小于MSS）均被確認(rèn)，則允許發(fā)送；
?? ? ?（5）上述條件都未滿足，但發(fā)生了超時(shí)（一般設(shè)置延遲ACK，一般為200ms），則立即發(fā)送。
通常我們比較關(guān)注的是情況(1)和(5)。
Nagle算法只允許一個(gè)未被ACK的包存在于網(wǎng)絡(luò)，它并不管包的大小，因此它事實(shí)上就是一個(gè)擴(kuò)展的停-等協(xié)議，只不過它是基于包停-等的，而不是基于字節(jié)停-等的。Nagle算法完全由TCP協(xié)議的ACK機(jī)制決定，這會(huì)帶來一些問題，比如如果對(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è)半集，預(yù)防SWS不止nagle算法一個(gè)途徑。SWS算法預(yù)防發(fā)送少量的數(shù)據(jù)，Nagle算法是其在發(fā)送方的實(shí)現(xiàn)，而接收方要做的時(shí)不要通告緩沖空間的很小增長，不通知小窗口，除非緩沖區(qū)空間有顯著的增長。這里顯著的增長定義為完全大小的段（MSS）或增長到大于最大窗口的一半。
注意：
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ù)采用Nagle 算法。這樣雖然提高了網(wǎng)絡(luò)吞吐量，但是實(shí)時(shí)性卻降低了，在一些交互性很強(qiáng)的應(yīng)用程序來說是不允許的，使用TCP_NODELAY選項(xiàng)可以禁止Negale 算法。此時(shí)，應(yīng)用程序向內(nèi)核遞交的每個(gè)數(shù)據(jù)包都會(huì)立即發(fā)送出去。需要注意的是，雖然禁止了Negale 算法，但網(wǎng)絡(luò)的傳輸仍然受到TCP確認(rèn)延遲機(jī)制的影響。
?相關(guān)：linux環(huán)境下的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ì)無條件發(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算法的初衷：避免發(fā)送大量的小包，防止小包泛濫于網(wǎng)絡(luò)，理想情況下，對(duì)于一個(gè)TCP連接而言，網(wǎng)絡(luò)上每次只能一個(gè)小包存在。它更多的是端到端意義上的優(yōu)化。
CORK算法的初衷：提高網(wǎng)絡(luò)利用率，理想情況下，完全避免發(fā)送小包，僅僅發(fā)送滿包以及不得不發(fā)的小包。
很多人都把Nagle算法的目的理解為“提高網(wǎng)絡(luò)利用率”，事實(shí)上，Nagle算法所謂的“提高網(wǎng)絡(luò)利用率”只是它的一個(gè)副作用(Side effect...)，Nagle算法的主旨在于“避免發(fā)送‘大量’的小包”。Nagle算法并沒有阻止發(fā)送小包，它只是阻止了發(fā)送大量的小包！誠然，發(fā)送大量的小包是降低了網(wǎng)絡(luò)利用率，但是，發(fā)送少量必須發(fā)送的小包也是對(duì)網(wǎng)絡(luò)利用率的降低，想徹底提高網(wǎng)絡(luò)利用率，為嘛不直接阻止小包發(fā)送呢？不管是大量小包還是少量小包，甚至一個(gè)小包也不讓發(fā)送，這才是提高網(wǎng)絡(luò)利用率的正解！是的，TCP_CORK就是做這個(gè)的。所以有人說，CORK選項(xiàng)是Nagle的增強(qiáng)，而實(shí)際上，它們是完全不同的兩回事，初衷不同。
Nagle算法和CORK算法著眼點(diǎn)不一樣，Nagle算法主要避免網(wǎng)絡(luò)因?yàn)樘嗟男“▍f(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)核會(huì)幫你將分散的包發(fā)出），即使你是分散發(fā)送多個(gè)小數(shù)據(jù)包，你也可以通過使能CORK算法將這些內(nèi)容拼接在一個(gè)包內(nèi)，如果此時(shí)用Nagle算法的話，則可能做不到這一點(diǎn)。
? ? 2.2 延遲ACK
? ? ? ? 這里要說明一下，Nagle算法和延遲ACK作用在方向相反的數(shù)據(jù)包和針對(duì)該數(shù)據(jù)包的確認(rèn)包上，因此它們的作用力會(huì)相悖，結(jié)果就是誰也不能發(fā)包。就像一根繩子上拴兩只青蛙一樣，被對(duì)方牽制誰也跑不了！關(guān)鍵點(diǎn)在于，小包的發(fā)送依賴于ACK，然而延遲ACK阻止了ACK的即時(shí)發(fā)送，形成了僵持狀態(tài)。本來只是為了減少網(wǎng)絡(luò)上小包的數(shù)量(再次強(qiáng)調(diào)Nagle算法以及延遲ACK的目的，注意，糊涂窗口綜合癥只是網(wǎng)絡(luò)上小包泛濫的原因之一！)，卻人為引入了大量的延遲！
后記：文章是2013年9月份找工作時(shí)現(xiàn)學(xué)現(xiàn)賣寫的，不知不覺網(wǎng)絡(luò)上已經(jīng)很多人引用了。今天工作中涉及到類似知識(shí)，再整理完善一遍~
2014年03月20日
參考文獻(xiàn)
《再次談?wù)凾CP的Nagle算法與TCP_CORK選項(xiàng)》
《tcp/ip詳解卷2》 ?24章 TCP 傳輸控制協(xié)議
《連續(xù)發(fā)送多份小數(shù)據(jù)時(shí)40ms延遲問題》
?《so_linger選項(xiàng)關(guān)閉timewait》http://www.xuebuyuan.com/1783143.html
? 《nginx實(shí)現(xiàn)的應(yīng)用層linger選項(xiàng)》http://blog.csdn.net/wangpengqi/article/details/17245889 以及http://blog.csdn.net/fangru/article/details/9024759
