TCP/IP詳解系列，關(guān)于tcp擁塞控制和數(shù)據(jù)流的地方講的不細(xì)致俯邓，或許是涉及概念/算法太多座舍，作者略去了一些對(duì)初學(xué)者來(lái)說(shuō)比較陌生的細(xì)節(jié)吧。比如SWS未說(shuō)明是什么就開(kāi)始介紹其避免方法啥容，還和nagle扯在了一起，直覺(jué)告訴我二者一定有貓膩顷霹，邊搜索一下咪惠，果然很有收獲。今天貼在這里淋淀，分享給大家遥昧。?
關(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é)；而傳輸開(kāi)銷有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ù)寫(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è)很好的解決方法割坠，發(fā)明了Nagle算法。而他選擇的等待時(shí)間是一個(gè)RTT,即下個(gè)ACK來(lái)到時(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ǔ)在其緩存中∑烀牵現(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)文段洛巢。這樣的過(guò)程一直繼續(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)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ù)后善延，它就停下來(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毫秒揩魂。
第二部分：治療辦法
2.1 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ā)送出去后，沒(méi)有收到對(duì)方發(fā)送的ACK確認(rèn)該數(shù)據(jù)已收到笨鸡。
從Nagle算法生效情況的補(bǔ)集姜钳，可以側(cè)面理解其本質(zhì)坦冠，參考tcp_output.c文件里tcp_nagle_check函數(shù)：
?? ? ?（1）如果包長(zhǎng)度達(dá)到MSS，則允許發(fā)送哥桥；
?? ? ?（2）如果該包含有FIN辙浑，則允許發(fā)送；
?? ? ?（3）設(shè)置了TCP_NODELAY選項(xiàng)（意在禁止nagle）拟糕，則允許發(fā)送判呕；
?? ? ?（4）未設(shè)置TCP_CORK選項(xiàng)時(shí)，若所有發(fā)出去的小數(shù)據(jù)包（包長(zhǎng)度小于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é)議蕊梧，只不過(guò)它是基于包停-等的霞赫，而不是基于字節(jié)停-等的。Nagle算法完全由TCP協(xié)議的ACK機(jī)制決定肥矢，這會(huì)帶來(lái)一些問(wèn)題端衰，比如如果對(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í)不要通告緩沖空間的很小增長(zhǎng)康吵，不通知小窗口，除非緩沖區(qū)空間有顯著的增長(zhǎng)访递。這里顯著的增長(zhǎng)定義為完全大小的段（MSS）或增長(zhǎng)到大于最大窗口的一半晦嵌。
注意：
BSD的實(shí)現(xiàn)是允許在空閑鏈接上發(fā)送大的寫(xiě)操作剩下的最后的小段，也就是說(shuō)，當(dāng)超過(guò)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)用程序來(lái)說(shuō)是不允許的灾炭，使用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)核仍然沒(mé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)沒(méi)有拼接成一個(gè)大包（努力接近MTU）的話鸥印，內(nèi)核就會(huì)無(wú)條件發(fā)送勋功。
也就是說(shuō)若應(yīng)用層程序發(fā)送小包數(shù)據(jù)的間隔不夠短時(shí)，TCP_CORK就沒(méi)有一點(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算法并沒(méi)有阻止發(fā)送小包梭姓，它只是阻止了發(fā)送大量的小包霜幼！誠(chéng)然，發(fā)送大量的小包是降低了網(wǎng)絡(luò)利用率誉尖，但是罪既，發(fā)送少量必須發(fā)送的小包也是對(duì)網(wǎng)絡(luò)利用率的降低，想徹底提高網(wǎng)絡(luò)利用率铡恕，為嘛不直接阻止小包發(fā)送呢萝衩？不管是大量小包還是少量小包，甚至一個(gè)小包也不讓發(fā)送没咙，這才是提高網(wǎng)絡(luò)利用率的正解猩谊！是的，TCP_CORK就是做這個(gè)的祭刚。所以有人說(shuō)牌捷，CORK選項(xiàng)是Nagle的增強(qiáng)，而實(shí)際上涡驮，它們是完全不同的兩回事暗甥，初衷不同。
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算法同樣也是通過(guò)設(shè)置或者清除TCP_CORK使能或者禁用之，然而Nagle算法關(guān)心的是網(wǎng)絡(luò)擁塞問(wèn)題茎毁，只要所有的ACK回來(lái)則發(fā)包克懊，而CORK算法卻可以關(guān)心內(nèi)容，在前后數(shù)據(jù)包發(fā)送間隔很短的前提下（很重要，否則內(nèi)核會(huì)幫你將分散的包發(fā)出）谭溉，即使你是分散發(fā)送多個(gè)小數(shù)據(jù)包墙懂，你也可以通過(guò)使能CORK算法將這些內(nèi)容拼接在一個(gè)包內(nèi)，如果此時(shí)用Nagle算法的話扮念，則可能做不到這一點(diǎn)垒在。
? ? 2.2 延遲ACK
? ? ? ? 這里要說(shuō)明一下，Nagle算法和延遲ACK作用在方向相反的數(shù)據(jù)包和針對(duì)該數(shù)據(jù)包的確認(rèn)包上扔亥，因此它們的作用力會(huì)相悖，結(jié)果就是誰(shuí)也不能發(fā)包谈为。就像一根繩子上拴兩只青蛙一樣旅挤，被對(duì)方牽制誰(shuí)也跑不了！關(guān)鍵點(diǎn)在于伞鲫，小包的發(fā)送依賴于ACK粘茄，然而延遲ACK阻止了ACK的即時(shí)發(fā)送，形成了僵持狀態(tài)秕脓。本來(lái)只是為了減少網(wǎng)絡(luò)上小包的數(shù)量(再次強(qiáng)調(diào)Nagle算法以及延遲ACK的目的柒瓣，注意，糊涂窗口綜合癥只是網(wǎng)絡(luò)上小包泛濫的原因之一吠架！)芙贫，卻人為引入了大量的延遲！
后記：文章是2013年9月份找工作時(shí)現(xiàn)學(xué)現(xiàn)賣寫(xiě)的傍药，不知不覺(jué)網(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延遲問(wèn)題》
?《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
