即使你的工作也許不需要對TCP了如指掌，也不需要去了解具體的TCP/IP實例。你也應該懂一些基本的TCP知識，本文會告訴你為什么。

我以前在Recurse Center工作的時候，曾經用Python寫過一個TCP棧(還寫了一篇博文用Python實現(xiàn)TCP棧可以學到什么)。這是很有意思的一課，也基本上是我對TCP的所有了解了。

一年之后，工作上遇到了困難。有同事在Slack上問到：“嘿，我向NSQ推消息總是會有40ms的延遲，不知道為什么。”這個問題我思來想去，過了一個周，還是毫無頭緒。

這里解釋一下： NSQ是一個用來發(fā)消息的隊列。發(fā)送方式是向localhost發(fā)出一個HTTP請求，這個動作不可能花費40ms，一定是出了錯。但是NSQ不具備很高的CPU優(yōu)先級，也沒有占用大量內存，所以問題不是出在垃圾回收那邊。

后來，我想起來一周之前讀過的一篇文章——我們是如何在每一個POST請求上省出200ms的(In search of performance - how we shaved 200ms off every POST request)。這篇文章討論了一開始每一個POST都會多花200ms的原因，多少有些詭異。下面是這篇文章中的內容。

ACK延遲和TCP_NODELAY

Ruby的Bet::HTTP將POST請求分成兩個TCP包——一個header，一個body.curl，相比之下，將它們組合成一個倒是更加合適。不過更糟的是，Net:HTTP沒有給它打開的TCP socket設置TCP_NODELAY，所以發(fā)送***個包之后，要等到確認才會發(fā)送第二個。歸根結底，這是Nagle算法導致的。
連接的另一端，HAProxy要選擇用何種方式確認這兩個包。在1.4.18(正式我們使用的版本)，它使用的是TCP延時確認，延時確認在Nagle算法中表現(xiàn)很糟糕，導致請求在這個地方暫停了，直至超時。

我來總結一下這段話：

TCP是將你要發(fā)送的數(shù)據(jù)打包的算法

他們的HTTP需要用兩個小包發(fā)送POST請求

整個過程就像下面這樣：

application：嗨!給你***個包
HAProxy：噓……我們要等第二個包
HAProxy：對了，我們要給他個確認，不過沒什么大不了的，等會再說
application：噓……我們等到***個包的確認再發(fā)第二個，也許網絡堵車了，再等一會
HAProxy：煩死了，我們發(fā)***個包的確認吧
application：收到確認，發(fā)第二個包!!!!
HAProxy：搞定!

這段時間內，HAProxy和application都在消極地等待，直到超過200ms。application等待是因為Nagle算法，HAProxy等待是因為延遲ACK。

據(jù)我所知，延遲的ACK在所有Linux系統(tǒng)都是默認打開的。所以這不是特例，只要你發(fā)送的數(shù)據(jù)多于一個TCP包，你也會碰上這種事。

終于搞定了問題

讀了這篇文章之后，覺得沒什么了不起的。但是在我們的神秘40ms掙扎了許久，我想起來這篇文章。

我想：這可能是我的問題嗎?可能嗎??可能嗎?!我給團隊發(fā)了一封郵件說“可能是我瘋了，不過，有可能是TCP的問題。”

于是我將TCP_NODELAY打開，然后——BOOM!

所有的40ms延遲統(tǒng)統(tǒng)消失了，這個世界***了。我真是個天才!

ACK延遲應該完全關閉嗎

提一個小插曲，我在HN上看到了這條評論：

真正的問題處在ACK延遲上。200ms延時設定是糟糕的主意，1985年在伯克利搞BSD的那幫人，根本不理解這個問題。
ACK延遲是賭應用層一定會在200ms之內收到回復。雖然幾乎每次都輸，但是ACK延遲依然在用。

他在評論中討論了ACK是成本很低的，這中做法所導致的問題比它解決的問題要嚴重的多。

如果你不懂TCP，就搞不定這個問題

以前我總認為TCP是相當?shù)讓拥臇|西，我永遠不需要去了解它。雖然差不多是這樣，但是實際生活中，你依然可能遇見和TCP算法相關的Bug，這時候懂一些TCP的知識就至關重要了。(本文也可以引申為，系統(tǒng)調用，操作系統(tǒng)這些都很重要，這個道理適用于很多東西。)

ACK延時/TCP_NODELAY很糟糕——它可能對任何寫HTTP請求代碼的人造成影響。但是你不必成為系統(tǒng)編程方面的天才，懂一點TCP就幫我搞定了這個問題，也讓我意識到，出現(xiàn)這個問題我也有責任。我也在用strace，strace萬歲!