本來想說說 tcp fastopen(tfo)，但沒什么意義，看 rfc7413 好了，還是 tcp 的慣常套路，引入一個新特性，解決了某個問題，帶來一些新問題，然后就是各種 tradeoff，哪里適用哪里不適用。久而久之，tcp 就成了一個極其擰巴的協(xié)議，都煩，但誰也逃不過，但凡 tcp 問題都不是容易解決的，都是仁者見仁的形而上。

昨天刷到一個搞云原生項目管理的經(jīng)理 up 主竟然單獨出一期視頻講 tcp 超時，我就擰巴了，說明 tcp 真就是一團亂麻，得好好理一下。

tcp 是 internet(首字母 i 應(yīng)該大寫) 開山協(xié)議，后來從中分出了 ip，就是 tcp/ip 第四版，可見前面至少折騰了三個版本，其實遠遠不止。事后來看，這就是 tcp 擰巴的核心原因，如果 tcp/ip 是設(shè)計出來而不是進化出來的，應(yīng)該是個反過來的過程，先有一個盡力而為的 ip 奠定瘦網(wǎng)胖端的細腰基礎(chǔ)，然后在其上鋪設(shè)其它協(xié)議。

果真如此的話，分層協(xié)議就沒了傳輸層，協(xié)議會更加平坦，不會有 tcp 協(xié)議，更不會有 udp，而是 app 自決，由 app 自行規(guī)定傳輸控制語義，標準化的過程會更自然，哪個 app 比較流行，哪個 app 規(guī)定的傳輸控制語義就是標準，就像 quic 后來做的那樣，其底色就是流行的 http，但 quic 卻不為路由器交換機所知，這才是真正的端到端。

但事實和理想是相反的，tcp/ip 不是設(shè)計出來的，而是進化出來的，所以 iso/osi 說好的分層協(xié)議層間隔離就成了瞎話，它們本質(zhì)是不同的東西。tcp 既沒有隔離上層，也沒有隔離下層，我就說幾個例子。

對上層，程序員完全在 tcp 之上編程(inet steam socket)，如果 tcp 發(fā)生異常比如斷了，程序員必須顯式處理，一大堆惡心纏繞的代碼在處理異常，這種習慣慢慢成了范式，以至于 quic 已經(jīng)有了連接遷移能力時，程序員依然害怕五元組變化。當談到 google 家的 plb 時，人們首先想到的不是它的作用，而是它的問題，“它是如何更換五元祖不導致連接掛掉的？” 連接掛就掛了唄，為什么 app 和 tcp 之間沒有一個 lib 解決這個問題呢。程序員害怕 tcp 斷，但其實 tcp 本不該被程序員感知。

對下層，tso/gso，lro/gro 依賴順序 stream，但傳輸優(yōu)化卻要亂序，這兩者相悖，但網(wǎng)卡還是害怕 tcp socket 在 cpu 間遷移，不然它那些個 offloading，rss 就不起作用，空耗復雜性，當我提到這兩者相悖時，程序員懟我，拼命維護 offloading 和 rss，大意是 “我靠，你怎么連優(yōu)秀的 rss 都噴”，我就說，有了 rss，你怎么玩亂序。

網(wǎng)絡(luò)和 cpu 完全不同，帶寬的發(fā)展是無關(guān)比特并行度的提高，而 cpu 則被串行流約束，兩者如不解耦，性能根本上不去，然而程序員思維大大偏向 cpu，他們根本無法理解如果取消了流的串行約束，還能剩下什么。

核心交換容量都 100Tbps 了，還在玩 lro/gro，你們難道不知道它們受限于 cpu 嗎，這還沒考慮內(nèi)存墻，你們懂交換容量嗎，你們拼命節(jié)省 cpu，但你們?nèi)绦睦速M核心交換機的背板能耗嗎。懂網(wǎng)絡(luò)的程序員很少，無論 xdp，dpdk，offloading，用戶態(tài)，在他們沒看懂近乎無限的交換容量前，他們完全不懂如何浪費這種容量，將精力集中在 cpu 沒錯，但錯在他們忽略了帶寬。

tcp 已經(jīng)運行 40 年，雖然大家都在談 tcp/ip 分層，但它和分層思想是相悖的，tcp 貫穿了從 socket 到網(wǎng)卡，在路由器，交換機，都有 tcp，tcp 無處不在，侵染了系統(tǒng)思想。

一個 web 前端程序員懂 tcp，一個網(wǎng)卡驅(qū)動程序員也懂 tcp，看起來都很精通，但其實并不懂，不怪人，只怪 tcp 太擰巴。當然，說的都是經(jīng)理。

吃飯了。

浙江溫州皮鞋濕，下雨進水不會胖。