即使你的工作也許不需要對(duì)TCP了如指掌，也不需要去了解具體的TCP/IP實(shí)例。你也應(yīng)該懂一些基本的TCP知識(shí)，本文會(huì)告訴你為什么。
我以前在Recurse Center工作的時(shí)候，曾經(jīng)用Python寫(xiě)過(guò)一個(gè)TCP棧（還寫(xiě)了一篇博文用Python實(shí)現(xiàn)TCP?？梢詫W(xué)到什么）。這是很有意思的一課，也基本上是我對(duì)TCP的所有了解了。
一年之后，工作上遇到了困難。有同事在Slack上問(wèn)到：“嘿，我向NSQ推消息總是會(huì)有40ms的延遲，不知道為什么?！边@個(gè)問(wèn)題我思來(lái)想去，過(guò)了一個(gè)周，還是毫無(wú)頭緒。
這里解釋一下： NSQ是一個(gè)用來(lái)發(fā)消息的隊(duì)列。發(fā)送方式是向localhost發(fā)出一個(gè)HTTP請(qǐng)求，這個(gè)動(dòng)作不可能花費(fèi)40ms，一定是出了錯(cuò)。但是NSQ不具備很高的CPU優(yōu)先級(jí)，也沒(méi)有占用大量?jī)?nèi)存，所以問(wèn)題不是出在垃圾回收那邊。
后來(lái)，我想起來(lái)一周之前讀過(guò)的一篇文章——我們是如何在每一個(gè)POST請(qǐng)求上省出200ms的（In search of performance - how we shaved 200ms off every POST request）。這篇文章討論了一開(kāi)始每一個(gè)POST都會(huì)多花200ms的原因，多少有些詭異。下面是這篇文章中的內(nèi)容。
Ruby的Bet::HTTP將POST請(qǐng)求分成兩個(gè)TCP包——一個(gè)header，一個(gè)body.curl，相比之下，將它們組合成一個(gè)倒是更加合適。不過(guò)更糟的是，Net:HTTP沒(méi)有給它打開(kāi)的TCP socket設(shè)置TCP_NODELAY，所以發(fā)送第一個(gè)包之后，要等到確認(rèn)才會(huì)發(fā)送第二個(gè)。歸根結(jié)底，這是Nagle算法導(dǎo)致的。
連接的另一端，HAProxy要選擇用何種方式確認(rèn)這兩個(gè)包。在1.4.18（正式我們使用的版本），它使用的是TCP延時(shí)確認(rèn)，延時(shí)確認(rèn)在Nagle算法中表現(xiàn)很糟糕，導(dǎo)致請(qǐng)求在這個(gè)地方暫停了，直至超時(shí)。
我來(lái)總結(jié)一下這段話：
整個(gè)過(guò)程就像下面這樣：
application：嗨！給你第一個(gè)包
HAProxy：噓……我們要等第二個(gè)包
HAProxy：對(duì)了，我們要給他個(gè)確認(rèn)，不過(guò)沒(méi)什么大不了的，等會(huì)再說(shuō)
application：噓……我們等到第一個(gè)包的確認(rèn)再發(fā)第二個(gè)，也許網(wǎng)絡(luò)堵車了，再等一會(huì)
HAProxy：煩死了，我們發(fā)第一個(gè)包的確認(rèn)吧
application：收到確認(rèn)，發(fā)第二個(gè)包?。。?！
HAProxy：搞定！
這段時(shí)間內(nèi)，HAProxy和application都在消極地等待，直到超過(guò)200ms。application等待是因?yàn)镹agle算法，HAProxy等待是因?yàn)檠舆tACK。
據(jù)我所知，延遲的ACK在所有Linux系統(tǒng)都是默認(rèn)打開(kāi)的。所以這不是特例，只要你發(fā)送的數(shù)據(jù)多于一個(gè)TCP包，你也會(huì)碰上這種事。
讀了這篇文章之后，覺(jué)得沒(méi)什么了不起的。但是在我們的神秘40ms掙扎了許久，我想起來(lái)這篇文章。
我想：這可能是我的問(wèn)題嗎？可能嗎？？可能嗎？！我給團(tuán)隊(duì)發(fā)了一封郵件說(shuō)“可能是我瘋了，不過(guò)，有可能是TCP的問(wèn)題?！?/p>
于是我將TCP_NODELAY打開(kāi)，然后——BOOM！
所有的40ms延遲統(tǒng)統(tǒng)消失了，這個(gè)世界完美了。我真是個(gè)天才！
提一個(gè)小插曲，我在HN上看到了這條評(píng)論：
真正的問(wèn)題處在ACK延遲上。200ms延時(shí)設(shè)定是糟糕的主意，1985年在伯克利搞BSD的那幫人，根本不理解這個(gè)問(wèn)題。ACK延遲是賭應(yīng)用層一定會(huì)在200ms之內(nèi)收到回復(fù)。雖然幾乎每次都輸，但是ACK延遲依然在用。
他在評(píng)論中討論了ACK是成本很低的，這中做法所導(dǎo)致的問(wèn)題比它解決的問(wèn)題要嚴(yán)重的多。
以前我總認(rèn)為T(mén)CP是相當(dāng)?shù)讓拥臇|西，我永遠(yuǎn)不需要去了解它。雖然差不多是這樣，但是實(shí)際生活中，你依然可能遇見(jiàn)和TCP算法相關(guān)的Bug，這時(shí)候懂一些TCP的知識(shí)就至關(guān)重要了。（本文也可以引申為，系統(tǒng)調(diào)用，操作系統(tǒng)這些都很重要，這個(gè)道理適用于很多東西。）
ACK延時(shí)/TCP_NODELAY很糟糕——它可能對(duì)任何寫(xiě)HTTP請(qǐng)求代碼的人造成影響。但是你不必成為系統(tǒng)編程方面的天才，懂一點(diǎn)TCP就幫我搞定了這個(gè)問(wèn)題，也讓我意識(shí)到，出現(xiàn)這個(gè)問(wèn)題我也有責(zé)任。我也在用strace，strace萬(wàn)歲！
聯(lián)系客服
