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

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

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

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

后來，我想起來一周之前讀過的一篇文章——我們是如何在每一個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，所以發送***個包之后，要等到確認才會發送第二個。歸根結底，這是Nagle算法導致的。
連接的另一端，HAProxy要選擇用何種方式確認這兩個包。在1.4.18(正式我們使用的版本)，它使用的是TCP延時確認，延時確認在Nagle算法中表現很糟糕，導致請求在這個地方暫停了，直至超時。

我來總結一下這段話：

TCP是將你要發送的數據打包的算法

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

整個過程就像下面這樣：

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

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

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

終于搞定了問題

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

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

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

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

ACK延遲應該完全關閉嗎

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

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

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

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

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

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