先引用自己的兩篇文章：
流水線式的TCP中繼代理是如何提高吞吐的 ：https://blog.csdn.net/dog250/article/details/83997773
eBPF/sockmap實現socket轉發offload ：https://blog.csdn.net/dog250/article/details/103629054
TCP是一個對長距離大帶寬(長肥管道)傳輸很不友好的端到端協議，它既保證不了效率(對丟包很敏感)，又保證不了公平性(對時延很不敏感)，它只是一個 收斂於剛剛可用 的協議，TCP，是垃圾！
依靠數據中繼，TCP可以將傳輸行爲流水線化，慢啓動窗口在短RTT內快速打開，對丟包的敏感通過對對時延的敏感來補償，從而最大化吞吐，這是TCP性能優化的一個創舉，而eBPF可以作爲TCP數據中繼實現的一個具體的技術。
兩篇文章所談的技術相結合，週末我來扯一下這背後的動機和意義。
當我們關注數據包是如何從起點到達終點的時候，我們被告知這一切都基於 IP路由！
TCP/IP分層模型讓路由器在數據包逐跳選路的過程中扮演了核心角色。整個互聯網看起來是由一堆路由器織成的：
上圖中所示的最短路徑是通過一種叫做動態路由的協議計算出來的，每一臺路由器都會運行這類路由協議並且參與全網任意兩點間最短路徑的計算，這是一個 全網協作的分佈式過程 。
在全網全部路由器分佈式協作的前提下，我們可以想象計算結果是 全局最優 的。
如果你非要擡槓說在效果上並不是最優的，那是因爲路徑度量不準確而導致，並不是路由協議本身的問題，類似Floyd算法和Dijkstra算法都可以從數學上嚴格證明結果是全局最優的。
路由器僅僅提供選路和轉發的功能，它們並不會產生或者消費數據包，那麼數據內容是如何產生的呢？
我就簡單點說吧，當整張由路由器織成的網絡成型時，運營商維護並管理着這張網絡，運營上提供 接入服務 並且獲得收入，數據的生產者比如說某某門戶網站，某某大學接入運營商的網絡並且爲之付費，從而讓自己的數據可以釋放到網絡上。
另一方面，數據的消費者，也就是普通用戶，花錢訂閱運營商的上網服務，用這種方式接入互聯網，因此運營商將數據的生產者和數據的消費者通過路由器組成的這張網連接了起來。
到目前爲之，沒有看出這有什麼問題。
…
哦，我可能忽略了一點，那就是 提供內容的網站服務器放在什麼地方？？
每一個網站的主人都不想讓自己成爲重資產的經營者，因此運營商可以提供機房和服務器的租用服務，運營商因此構建了大量的機房，這些機房多數和接入層路由直連，少數和匯聚路由器直連以提供更優質的服務：
任何人都可以租用運營商的數據中心服務，構建自己的網站成爲一個內容提供者，這大概就是web 1.0時代的事了。
在這個時期，各級運營商提供的IP路由始終如一地免費提供最優路徑服務，最優路徑成了互聯網的屬性。
…
大概從web 2.0開始，隨着交互的增多，多到移動互聯網時代無以復加的程度，流量也隨之爆發增長。
按字節付費給運營商已經越來越不划算，這使得這期間誕生的巨頭互聯網內容提供商開始想另外的對策。
大概就是騰訊，百度，阿里這一批吧。
自己挖地埋光纜顯然更不划算，甚至不被gov允許，但是蓋兩幢房子的錢還是有的。因此類似BAT這類公司開始自建機房，然後僅僅租用運營商最最底層的傳輸介質。
互聯網公司開始部署各大自建節點，越來越密集，其效果就是 讓用戶在最近的地方獲取需要的數據！
這便是CDN了，內容分發網絡：
互聯網公司的自建DC簡直成了既有IP網絡的 網中網 ，它們overlay在既有的IP網絡上！
好了，現在我們看看這種互聯網公司自建的DC是如何打破路徑計算的全局最優解的。
所有互聯網公司的所有內容都可以分爲兩種類型：
- 靜態內容：永遠不變的內容。比如一個固定的視頻文件。
- 動態內容：隨訪問發生變化的內容。比如獲取當前的北京時間。
CDN節點幾乎都具備緩存能力，因此它們可以把靜態內容通過DC之間的虛擬互聯路徑(或TCP的，或UDP，或臨時隧道)提前從源站緩存在離用戶最近的那個DC中，當用戶訪問時，DC的內容可以最短的時間推給用戶。
存儲和管道永遠都是同一件事的兩面。 網絡是管道，數據庫就是存儲，沿着空間橫向拉伸就是存儲，沿着時間縱向拉伸就是網絡，我覺得Kafka同時統一了二者，非常之優雅。
我不想談這個關於靜態內容如何緩存以及如何推給用戶的話題，這讓我覺得非常糟糕。我想大致說下互聯網公司如何對待動態內容。
對於動態內容的產生必然是源站參與，因此從客戶端到源站之間的通信則是必不可少的，現在的問題是，如何爲這次通信尋找一條最優的路徑。
注意上圖中的互聯網公司各個自建DC 簡直附着在運營商的路由器上！！ 那麼這些DC是不是可以繞開全球BGP以及各運營商IGP的路由呢？
答案是肯定的！比如運營商按照全局BGP/IGP路由提供了下面的全局最優解：
可是，該互聯網公司卻不認爲這條路對自己是最優的，它通過更加精細的指標發現了另外的更好的路徑，畢竟一個公司只會考慮自己，它纔不會在乎全局呢。
在全局意義上，可能“最短路徑”意味着功耗最小，物理距離最短等，但在具體公司的具體業務上，“最短路徑”可能指的就是RTT最小，或者丟包率最低，或者多者加權。
通過測量一系列的指標，比方說用TCP或者UDP測量的RTT，丟包率，包重傳率等等，這個公司在自私策略的前提下，發現存在另一條路徑，通過自家的另一個DC中轉，會更優：
這家公司纔不會關心這條路具體跨越了哪些路由器，它只關心這條路跨越了自己的哪些DC。
由於這家公司無法控制網絡層的IP路由，也就無法控制數據包途徑的路徑，但是它可以控制傳輸層路由：
- 它可以事先在各個DC之間構建IP隧道啊！！！
- 它可以在自己各個DC之間按照自己的算法逐跳做DNAT啊！！！
- 它可以在自己各個DC之間做4層/7層代理啊！！！(eBPF的SOCKMAP就可以支持幹這個事)
- …
總而言之，這家公司完全可以通過隧道，NAT，Proxy等技術繞開底層的IP選路，從而把從源站始發的數據包導入到自己發現的路徑中！
雖然不是標準的IP逐跳路由，但在更高的層次上，如果把DC看作路由器的話，數據包的路由方式和IP路由如出一轍，只不過它是虛擬的而已：
在這種overlay路由中，標準的IP路由尋找下一跳的問題就轉換成了 尋找下一段隧道 或者 尋找下一段的TCP連接 問題了。
我來放大某一個DC節點：
…
OK，我們看到，事實上，各個互聯網公司是將自己的DC節點當 路由器 來使用了，它被傳統的IP網絡承載，在這張虛擬的網絡上，數據包依然是 逐跳轉發 的，只不過跳數的度量是DC節點，而不再是路由器了。
相比於標準的IP路由，這種方式對於一個特定的互聯網公司而言，選路更加靈活和精確，只要DC節點部署的足夠密集，數據包可以非常靈活的在這些節點之間被轉發，直到它到達最終的目的地。
你會質疑，這有什麼問題嗎？這種辦法難道不是比純粹IP層的物理距離，線路帶寬，靜態配置的metric更加可信嗎？
對也不對！
有一個關鍵點我沒說：
- 按照這種算法計算最優路徑的可遠不止一家公司！！
因此就根本談不上所謂的 全局協作！
騰訊有自己的自建DC，百度也有，阿里也有，京東，字節等也差不到哪去，所有的公司都採用自私的策略來計算最優路徑，在總體資源有限的情況下，這幾家公司的帶寬分配就會拼命 內卷！
一切虛擬網絡的底層，大多數依然還是那些傳統的基礎設施，而互聯網公司DC的存在，徹底打破了IP路由：
原來的S->D的純IP層選路，一下子就變成了多個DC之間的多個IP層選路，這勢必會讓IP路由混淆問題和結論。
除卻選路破壞了全局最短路徑的收斂，在各個獨立的路徑，各家還是部署激進的TCP加速算法(注意⚠️它們和擁塞控制算法的本質區別，從名字上就能看得出來)，所謂的加速的本質就是 “盡其所能將數據送到對端” ，所有以此爲目的的都是手段，破壞此目標的都可以忽略，這完全破壞了作爲一個負反饋系統的網絡資源分配機制，該機制要求所有的資源分配都要全局收斂到公平。
“各大互聯網公司各自都有自己選路系統和加速算法，卻被同一個IP網絡承載，資源爭搶無法得到控制” 這就是局部擁塞的根源。
只要互聯網公司沒有自己的物理鏈路，那麼這種局部擁塞就會永遠存在 ，騰訊阿里的一幫人玩的越花哨，頭條快手的另一幫人就能玩的更花哨，就好像好好的一幢30層的樓房，二樓裝了防盜網，三樓就要裝，然後四樓就要裝，最終全部樓層都裝了防盜網，這就是內卷。
這就是國內CDN廠商所謂的加速服務的現狀，其實這些都沒有意義，只要一個相對激進的廠商退出，所有的都會退出，依靠統一的全局最優選路系統不香嗎？部署自己的選路和加速算法，無非就是想讓自己此時快一點。
一個TCP協議，together with QUIC and so on，在沒有全局視角的前提下，還能折騰成啥樣？損人利己或者損人不利己而已，這種端到端協議的首要意義就是收斂到公平，其次纔是別的。
不過這種內卷相關的事情，也是國情吧，競爭先於協作，壓力先於激勵。你肯定不同意我說的，你會說外國的月亮也不圓，但是你會收到正告，所有折騰這種事的公司，都有中國的基因，無論是創始人，還是客戶。
需要特別指出的是，Google家的BBR並不在此列，與CUBIC的混部公平性一直在其考慮之列，詳情可以直接和其作者聯繫。
喈夫，土坯房子裝修得再好也不能抵禦地震，但是住在房子裏的人看到豪華的壁紙，卻感覺像是住在鋼筋混凝土房屋裏一樣安全無憂！
經理！
最後，有一說一之外還要一分爲二，說說自研選路系統和加速算法的必要性和好處。
說真的，現有的全球範圍內的運營商維護的那套網絡體系，在20～30年前就基本落地了，後來修修補補，肯定是無法滿足當前爆發增長的高帶寬以及低延遲需求，這正好催生了CDN這種業務：
- 將靜態內容通過緩存部署在離用戶儘可能近的地方。
- 將動態內容通過自選高帶寬低時延路徑傳輸給用戶。
以此來規避30年前的陳年TCP協議對長肥管道的不友好性。各大以業務爲依託的互聯網公司根本無力推進新協議的研發和部署，它們更善於短平快的快速迭代：
- 對於靜態內容的傳輸，拿既有的TCP協議開刀當然是最有效的方式。
- 對於動態內容的傳輸，在自家DC節點之間構建密集mesh中繼/隧道/代理當然OK。
不然還能怎樣呢？
放眼世界，如今的互聯網內容幾乎都集中在各大互聯網公司手中，那麼話語權當然也在他們那裏，Google家自己就有可以完爆運營商的“內網”，國內的騰訊家，阿里家都有這種網絡，這些公司在技術層面幾乎就和運營商一樣在運作，擁有自己的AS號，維護着海量的IP地址以及路由條目，和其它運營商網絡peering or 甩熱土豆，在技術層面，它們可運營商已經沒有什麼區別，甚至更有優勢。甚至已經有很多公司在鋪挖自己的光纜了…
對了，還有，如果你從傳統運營商的機房購買了或租用了一個服務器部署了自己的網站，記得再從互聯網公司手中購買一個CDN服務：
看起來這裏要做廣告了，但我就是個賣洗衣膏兒的。
賣洗衣昂膏兒誒賣阿拉洗衣昂膏兒誒…
浙江溫州皮鞋溼，下雨進水不會胖。