即使你的工作也許不需要對TCP了如指掌，也不需要去了解具體的TCP/IP實例。你也應該懂一些基本的TCP知識，本文會告訴你為什麼。
我以前在Recurse Center工作的時候，曾經用Python寫過一個TCP棧（還寫了一篇博文 用Python實現TCP棧可以學到什麼）。這是很有意思的一課，也基本上是我對TCP的所有了解了。
一年之後，工作上遇到了困難。有同事在Slack上問到：“嘿，我向NSQ推消息總是會有40ms的延遲，不知道為什麼。”這個問題我思來想去，過了一個周，還是毫無頭緒。
這裡解釋一下： NSQ是一個用來發消息的隊列。發送方式是向localhost發出一個HTTP請求，這個動作不可能花費40ms，一定是出了錯。但是NSQ不具備很高的CPU優先級，也沒有占用大量內存，所以問題不是出在垃圾回收那邊。
後來，我想起來一周之前讀過的一篇文章——我們是如何在每一個POST請求上省出200ms的。這篇文章討論了一開始每一個POST都會多花200ms的原因，多少有些詭異。下面是這篇文章中的內容。
Ruby的 Bet::HTTP 將POST請求分成兩個TCP包——一個header，一個body.curl，相比之下，將它們組合成一個倒是更加合適。不過更糟的是，Net:HTTP沒有給它打開的TCP socket設置TCP_NODELAY，所以發送第一個包之後，要等到確認才會發送第二個。歸根結底，這是Nagle算法導致的。
連接的另一端，HAProxy要選擇用何種方式確認這兩個包。在1.4.18（正式我們使用的版本），它使用的是TCP延時確認，延時確認在Nagle算法中表現很糟糕，導致請求在這個地方暫停了，直至超時。
我來總結一下這段話：
整個過程就像下面這樣：
- application：嗨！給你第一個包
- HAProxy：噓……我們要等第二個包
- HAProxy：對了，我們要給他個確認，不過沒什麼大不了的，等會再說
- application：噓……我們等到第一個包的確認再發第二個，也許網絡堵車了，再等一會
- HAProxy：煩死了，我們發第一個包的確認吧
- application：收到確認，發第二個包！！！！
- HAProxy：搞定！
這段時間內，HAProxy和application都在消極地等待，直到超過200ms。application等待是因為Nagle算法，HAProxy等待是因為延遲ACK。
據我所知，延遲的ACK在所有Linux系統都是默認打開的。所以這不是特例，只要你發送的數據多於一個TCP包，你也會碰上這種事。
讀了這篇文章之後，覺得沒什麼了不起的。但是在我們的神秘40ms掙扎了許久，我想起來這篇文章。
我想：這可能是我的問題嗎？可能嗎？？可能嗎？！我給團隊發了一封郵件說“可能是我瘋了，不過，有可能是TCP的問題。”
於是我將TCP_NODELAY打開，然後——BOOM！
所有的40ms延遲統統消失了，這個世界完美了。我真TM是個天才！
提一個小插曲，我在HN上看到了這條評論：
真正的問題處在ACK延遲上。200ms延時設定是糟糕的主意，1985年在伯克利搞BSD的那幫人，根本不理解這個問題。ACK延遲是賭應用層一定會在200ms之內收到回復。雖然幾乎每次都輸，但是ACK延遲依然在用。
他在評論中討論了ACK是成本很低的，這中做法所導致的問題比它解決的問題要嚴重的多。
以前我總認為TCP是相當底層的東西，我永遠不需要去了解它。雖然差不多是這樣，但是實際生活中，你依然可能遇見和TCP算法相關的bug，這時候懂一些TCP的知識就至關重要了。（本文也可以引申為，系統調用，操作系統這些都很重要，這個道理適用於很多東西）
ACK延時/TCP_NODELAY很糟糕——它可能對任何寫HTTP 請求代碼的人造成影響。但是你不必成為系統編程方面的天才，懂一點TCP就幫我搞定了這個問題，也讓我意識到，出現這個問題我也有責任。我也在用strace，strace萬歲！
