我經(jīng)常說，傳統(tǒng)的 TCP 優(yōu)化已經(jīng)到頂，不會(huì)有大意義了，這有兩方面意思。

一方面，內(nèi)在的，TCP 的 ACK 時(shí)鐘帶回的信息就那么多，用足了又能怎樣。一個(gè)學(xué)習(xí)最差的差生能控制的分?jǐn)?shù)是是 0～100 分的區(qū)間，寬度足足 100 分，他控制不了自己能考多少分，而一個(gè)學(xué)習(xí)最好的學(xué)生能控制的分?jǐn)?shù)則是任意值，寬度為 0 分！

另一方面，按照 TCP/IP or OSI 分層模型，任何上層的機(jī)制都是在彌補(bǔ)下層的缺陷。比如傳輸層需要重傳，因?yàn)橄聦渔溌凡豢煽?，那么如果下層鏈路保證可靠了，上層的可靠傳輸機(jī)制是不是就沒用了呢？答案是肯定的。

假設(shè)物理層有了極大突破，實(shí)現(xiàn)了無限帶寬，還需要擁塞控制嗎？

Linux 內(nèi)核的 task 調(diào)度算法可能就是來源于 CPU 核少 task 多的環(huán)境。幾千個(gè) task 排隊(duì)，肯定要精致化排隊(duì)體驗(yàn)。但如果有幾千個(gè) CPU 核，每個(gè)核只有幾個(gè) task 排隊(duì)，要需要精致化排隊(duì)體驗(yàn)嗎？隨便排就好了嘛！

所有花哨的算法，都源于資源不足，不得已需要權(quán)衡取舍。一種資源調(diào)度算法，要保證相對公平，所謂不患寡而患不均，但問題恰恰就是寡，資源要是豐盈，就不需要這些算法了。簡單的日常例子，高速公路上沒有紅綠燈。因?yàn)椴恍枰{(diào)度，道路立交，資源豐盈，各行不悖。

有意義的事在傳輸層之外。

全局意識下，不能指望傳輸層可以解決所有問題。以 incast 流量為例，無論任何傳輸層方案，包括 Homa，SRD 在內(nèi)，都只是 workaround，需要從物理拓?fù)渖现植拍芙鉀Q根本問題。

比如 MapReduce，它本身就是一個(gè)以服務(wù)器為中心的星型邏輯，而服務(wù)器還單獨(dú)掛在胖樹上，不 incast 才怪，最后一跳 TOR 往往最容易擁塞。各種大成本投入在傳輸協(xié)議研發(fā)以及交換機(jī) PFC 上卻始終解決不了問題。其實(shí)只要改變拓?fù)浼纯桑?br>

將交換機(jī)為中心的視角改為服務(wù)器為中心就豁然開朗了，服務(wù)器星型拓?fù)涫翘烊坏?MapReduce，多連了幾根線而已，總不能空手套白狼。

剩下的事情逐層自下而上，網(wǎng)絡(luò)層需要支持多路徑。IP 路由規(guī)劃與宣告是個(gè)細(xì)活兒，這里不談，但仔細(xì)想想 IP 理由到底還適合不適合，就發(fā)現(xiàn)這里還是有問題。IP 天然就不適合 MapReduce。

數(shù)據(jù)中心網(wǎng)絡(luò)需要 IP 做隔離，但 MapReduce 卻明明不需要隔離，相反，如果有一個(gè)廣播發(fā)送，單播回復(fù)的協(xié)議就好了。

總之，單純從傳輸層解決不了的問題，如果可以著手從物理層做出改變，那么完整的方案又何止一個(gè)。點(diǎn)對點(diǎn)拓?fù)湟恢北徽J(rèn)為是不合理的，但三層架構(gòu)樹就一定正確嗎？

有一個(gè)其它領(lǐng)域的例子，Intel CPU 的 FSB(前端總線) 速率一直在提升，可終究有問題解決不了，最終發(fā)現(xiàn)本質(zhì)問題就是 FSB 自身，于是干掉它就好了。Intel FSB 的問題是一個(gè)與 incast 問題非常類似的例子，十幾年前我看 AMD 發(fā)布的 CPU 架構(gòu)時(shí)，發(fā)現(xiàn)它們 “一點(diǎn)都不美”，布線引腳亂七八糟，沒有 FSB 將大家匯聚在一起進(jìn)入 CPU，然而優(yōu)美并不意味著正確。大多數(shù)時(shí)候，優(yōu)美的架構(gòu)源自于資源緊缺，“如果空間有的是，誰還會(huì)去整理物品，只有狹小的空間才需要靈巧的收納?！?/p>

為了解決 incast，應(yīng)用層方案，傳輸層方案都有，就是沒有物理層方案，可物理拓?fù)涞南拗撇攀菃栴}的根本。條件允許時(shí)，浪費(fèi)并不可恥，明明連幾根線就能解決的問題，非要執(zhí)念于一個(gè)根本不存在的完美傳輸協(xié)議，豈不悲哀。

再看回傳輸本身。

MapReduce 除了可作為編程范式之外，它竟然可以作為一種非常自然的方式解釋傳輸?shù)谋举|(zhì)。傳輸?shù)哪繕?biāo)是在 receiver 還原 sender 的數(shù)據(jù)，傳輸?shù)倪^程就是 map，而 receiver 交付數(shù)據(jù)的過程則是 reduce，非常自然的一種多路徑亂序傳輸?shù)姆妒?。類似多臺服務(wù)器一起提供一個(gè)文件的不同片段的 map 過程最終匯總成一個(gè)完整文件的 reduce，多條鏈路可以同時(shí)傳輸一條流 or 一則消息的不同片段最終在 receiver 匯總成原始數(shù)據(jù)流 or 消息，這就是傳輸?shù)倪^程，我們發(fā)現(xiàn)它不僅僅是一個(gè)傳輸協(xié)議，而是包含從物理拓?fù)涞綉?yīng)用語義的全部。

當(dāng)然，基于最優(yōu)路徑的逐跳 IP 路由已經(jīng) 40 多年了，顯然，它并不 match 上述 MapReduce 的意思。但我們必須明白，物理基礎(chǔ)設(shè)施并不是一成不變的，在需要的時(shí)候，它們必須 “有能力被改進(jìn)”，并且，我們也不能總盯著幾個(gè)傳輸協(xié)議，現(xiàn)在越來越多的方向都在模糊分層模型的各層，應(yīng)用層可以自己控制 pacing rate，物理層也可以。

傳統(tǒng)網(wǎng)絡(luò)以交換機(jī)為中心，意在鞏固利好上層，如果以服務(wù)器為中心，則鞏固利好底層，很多問題都將解決。多對多，人人為我，我為人人，自服務(wù)器為中心的交叉。這是一個(gè)在來溫州的

路上想到的一個(gè)問題，寫篇文字以記錄。

浙江溫州皮鞋濕，下雨進(jìn)水不會(huì)胖。文章來源地址http://www.zghlxwxcb.cn/news/detail-433055.html

到了這里，關(guān)于網(wǎng)絡(luò)基礎(chǔ)設(shè)施 & 擁塞控制的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！