這不是指要明白 TCP 的所有東西，也不是說要通讀 《TCP/IP 詳解》。不過懂一點(diǎn) TCP 知識(shí)是很有必要的。理由如下：

當(dāng)我還在 Recurse Center 的時(shí)候，我用 Python 寫過 TCP 協(xié)議棧(還寫過一篇文章：如果你用 Python 寫 TCP 協(xié)議棧會(huì)遇到什么?)。這是一次有趣的學(xué)習(xí)經(jīng)歷，但是也僅此而已。

一年以后，工作中有人在 Slack 上提到：“嘿，我在向 NSQ 發(fā)布消息時(shí)，每次要耗費(fèi) 40 毫秒”。我已經(jīng)斷斷續(xù)續(xù)思考了一個(gè)星期，但是沒有任何結(jié)果。

一點(diǎn)背景知識(shí)：NSQ 是一個(gè)消息隊(duì)列，你通過本地的一個(gè) HTTP 請(qǐng)求向其發(fā)布消息。發(fā)送本地的一個(gè) HTTP 請(qǐng)求確實(shí)不應(yīng)該花費(fèi) 40 毫秒，有時(shí)候會(huì)更差。NSQ 守護(hù)進(jìn)程的負(fù)載不高，也沒有使用過多的內(nèi)存，也看不到 GC 停頓。這究竟是為什么呢?神吶，救救我吧!

 [[161136]]

突然我記起我一周以前看過的一篇叫做“性能研究(In search of performance)”的文章——我們?nèi)绾螢槊總€(gè) POST 請(qǐng)求節(jié)省 200ms。在這篇文章中，他們說到為什么每個(gè) POST 請(qǐng)求會(huì)花費(fèi)額外的 200 毫秒。就是這個(gè)原因。這是該文章中的關(guān)鍵段落：

延遲確認(rèn)(ACK) 與 TCP_NODELAY

Ruby 的 Net::HTTP 會(huì)將 POST 請(qǐng)求切分為兩個(gè) TCP 包，一個(gè)消息頭，一個(gè)消息體。相反，curl 會(huì)將這兩者合并為一個(gè)包。更糟糕的是，Net::HTTP 在打開 TCP 套接字時(shí)不會(huì)設(shè)置 TCP_NODELAY，這將導(dǎo)致第二個(gè)包需要等到第一個(gè)包的接收確認(rèn)通知之后才能發(fā)送。這是 Nagle 算法導(dǎo)致的。

轉(zhuǎn)換到連接的另一端，HAProxy 需要決定如何確認(rèn)這兩個(gè)包。在 1.4.18 版本中(我們正在用的版本)，它是通過 TCP 延遲確認(rèn)通知來實(shí)現(xiàn)的。延遲確認(rèn)對(duì) Nagle 算法有非常糟糕的影響，會(huì)導(dǎo)致請(qǐng)求暫停直到服務(wù)器延遲確認(rèn)超時(shí)。

現(xiàn)在我們解釋這個(gè)段落說的內(nèi)容。

TCP 是一個(gè)通過數(shù)據(jù)包傳輸數(shù)據(jù)的算法

他們的 HTTP 庫將 POST 請(qǐng)求分割成兩個(gè)小的數(shù)據(jù)包發(fā)送

接下來，TCP 采用類似如下的步驟進(jìn)行交互：

application：Hi!這里有一個(gè)數(shù)據(jù)包。

HAProxy：(沉默)，等待第二個(gè)包發(fā)送

HAProxy：對(duì)了，我需要返回一個(gè)確認(rèn)，不過沒關(guān)系，等會(huì)吧

application: (沉默)

application：好吧，我正在等待確認(rèn)，可能現(xiàn)在網(wǎng)絡(luò)延遲比較大

HAProxy：好吧，太煩人了，這是一個(gè)確認(rèn)。

application：好極了，這是第二個(gè)數(shù)據(jù)包!!!

HAProxy：親，我們已經(jīng)搞定了。

這個(gè)過程是不是應(yīng)用程序和 HAProxy 都在消極等待另一方發(fā)送信息?這就是那額外的 200ms。應(yīng)用程序這么做的是因?yàn)?Nagle 算法，而 HAProxy 消息等待的原因是延遲確認(rèn)。

據(jù)我所知，延遲確認(rèn)是所有 Linux 系統(tǒng)的默認(rèn)行為。所以這不是一個(gè)偶然或者異常情況，如果發(fā)送 TCP 數(shù)據(jù)包多一個(gè) 1 個(gè)，你就會(huì)遇到這種情況。

現(xiàn)在，我們成為專家了

讀過這篇文章之后我很快就忘了。不過當(dāng)我被額外的 40 毫秒難住的時(shí)候，我又記起來了。

所以我認(rèn)為——這不可能是我的問題，可能嗎?可能嗎??然后我發(fā)了一封郵件給我團(tuán)隊(duì)說：“我想我快要瘋了，但是這可能是 TCP 的問題”。

所以我提交了一次修訂，將我的應(yīng)該調(diào)整為 TCP_NODELAY，然后問題就“嘣”的一聲解決了。

40 毫秒的延遲立馬就消失了。所有的事情都解決了，我就是個(gè)天才。

我們是否應(yīng)該完全停止使用延遲確認(rèn)?

我剛好在 Hacker News 看到 John Nagle (Nagle 算法的創(chuàng)始人)對(duì) @alicemazzy 提到這個(gè)問題的評(píng)論。

本質(zhì)問題是延遲確認(rèn)。200 毫秒的“延遲確認(rèn)”是一個(gè)非常不好的主意，1985 年中，在伯利克(Berkeley)研究 BSD 的人實(shí)際上沒有真正明白這個(gè)問題。延遲確認(rèn)是應(yīng)用層對(duì) 200 毫秒內(nèi)是否響應(yīng)的一場(chǎng)賭博，但是即便每次它都賭輸了，TCP 仍在使用延遲確認(rèn)。

他繼續(xù)說到，確認(rèn)本身是很小并且消耗很低的，延遲確認(rèn)引起的問題可能比它解決的問題還要多。

不懂得 TCP 你就無法解決 TCP 問題

我曾經(jīng)也認(rèn)為，TCP 是一個(gè)相當(dāng)?shù)讓拥膯栴}，我不需要明白。大多數(shù)時(shí)候你的確不需要明白。但是有的時(shí)候，當(dāng)你在實(shí)踐中遇到由于 TCP 算法引起的 bug 時(shí)，懂點(diǎn) TCP 知識(shí)就變得非常重要了。(正如我們經(jīng)常在博客中討論的，許多事情都是這樣，比如系統(tǒng)調(diào)用和操作系統(tǒng):) )

延遲確認(rèn)及 TCP_NODELAY 的交互非常不好——這對(duì)任何語言實(shí)現(xiàn)的 HTTP 請(qǐng)求都有影響。你不需要很深入的去了解，成為系統(tǒng)程序?qū)＜摇５橇私庖稽c(diǎn) TCP 是如何運(yùn)作的，對(duì)我的工作的確大有裨益。通過對(duì) TCP 的學(xué)習(xí)，我才意識(shí)到這篇博客所描述的問題也許正好是我所熟悉的領(lǐng)域。我也一直在使用 strace，并且會(huì)一直使用下去。