昨天大年三十下了一整天雨,去了一趟上海迪士尼,非常驚喜,人非常少,全程不用排隊,幾乎玩遍了所有的專案,估摸著以后是不會再去了,
如果沒有人排隊,那些占地面積巨大的迂回曲折的綜合排隊設施就很尷尬地完全成了擺設,但你依然不得不 “迂回曲折” 地經過它們,即便是一路小跑,也要花不少的時間繞過那九曲回廊,如果你是第一次去,還以為穿過這種迷宮式的九曲回廊是專案的一部分呢,
…
都沒人排隊了,要這些排隊設施還有什么用?
本文接著前天那篇接著寫:
https://blog.csdn.net/dog250/article/details/113783209
我在想,如果沒有任何魔改且實作完美的BBR普及了整個網路,是不是路由器交換機就不再把buffer大小作為重要指標了呢?畢竟buffer沒有大用了啊,
這很容易讓我聯想起我最近比較關注的bufferbloat, 路由器配備越來越多的buffer讓資料包在里面盡情排隊, …這解釋起來似乎很容易:
- 資料包的到達時間是隨機的,
- 路由器轉發資料包的時間是固定的,
- …
balabala…感覺又要扯到排隊論了…大過年的…
排隊論只能解釋bufferbloat的低級成因,我們需要一種更加高級層面的解釋,這又當如何解釋?
最近在看一本書,侯世達的《我是個怪圈》,里面很詳細地解釋了什么是低級成因,什么是高級成因,
精心設計一套多米諾骨牌組成的裝置,使得它可以在你 “輸入” 一個素數的時候看到 “某一個特定的分支” 的多米諾骨牌倒下,現在問, “你輸入641之后,某塊多米諾骨牌為什么倒下? 如果你回答 “因為它前面的那塊倒下了,” 那這就是低級成因,如果你回答 “因為你輸入的641是一個素數” ,那么這就是高級成因,
那么bufferbloat的高級成因是什么?
如果從路由器的視角看,它似乎只能看到底層的成因,對于某個路由器,它只能看到資料包的到達是符合一定分布,它會將暫時處理不過來的資料包存入buffer…這似乎很合理,也是分內之事,
但是,路由器可以引導并且利用 破窗效應,
- 給你buffer,就是讓你用的,buffer給你的越多,你用的就越多,
- 最終所有資料包為越來越多的buffer買單,
從資料包的視角來看,路由器提供的buffer可以帶來 踮腳效應,
- 如果我不占buffer,別人就會占更多,我就會更慘,
這么一拉一推,bufferbloat就成了,
踮腳效應,破窗效應事實上是非常損人不利己的相互傷害!
那么到底誰在召喚誰?
如果路由器真的在使喚破窗效應,比如配置了稍微昂貴但還算優惠的大buffer,真的會被用盡嗎?
反過來,資料包的踮腳效應會讓路由器配備越來越大同時越來越昂貴的buffer嗎?
這就要看各個TCP CC演算法的收斂點在哪里了,即大家在瓜分什么,是在瓜分帶寬呢,還是在瓜分buffer:

只要網路有一個Reno流,都會趨使所有流的收斂點向右邊偏移,最終讓路由器廠商得逞,提供越來越大的buffer,利用破窗效應讓所有的資料流為這些buffer買單,
但是現在我們假設網路上已經沒有Reno流了,全部是BBR流,那會怎樣?
很多稍微懂點兒的人這個時候又該瞎逼逼了,告訴我國內的網路環境多么多么特殊,告訴我不可知的運營商如何如何,BBR還是會占buffer的,總會有新建連接的吧,我說資料包不排隊,這不是瞎JB扯淡嗎?你可能會拿一組實實在在的資料甩在我臉上,來告訴我BBR在現實中是多么不靠譜…
這些都不是核心,核心是什么?核心就是那個 ProbeRTT的自動同步, 為什么會自動同步?很簡單:
- 占據buffer最多的那個流總會在10s后進入ProbeRTT,它將會排空它自己所占的buffer,此時所有因排隊造成RTT增加的其它流均會同時采集到一個新的更小的RTT,即便此時仍然有排隊,這些流的該RTT也會在從當刻起10s后同時過期,進而同時進入ProbeRTT,網路buffer被同時排空,
即便你再次用短連接撐不了10s,網路抖動等因素來懟,也無法改變這個核心,這是一個長期的趨勢,一個穩定的狀態,這個狀態在上圖中是將收斂點往左邊拉的,換句話說,BBR有一種將buffer排空的 欲望 ,
BBR對任何buffer的占據都是暫時的迫不得已,路由器配置大buffer將無法成為亮點,
一直以來傳統的觀點就是路由器交換機上一定要有大buffer,這其實是一種誤區,我一向的觀點是將資料的始發/終點和資料的通路分開,也就是把整個處理程序分為計算,傳輸和存盤,其實傳輸就是網路,而存盤則是資料的落盤,網路只是一條需要快速經過的路,而磁盤才是家,所以在網路上搞那么大buffer干什么? 不要把快速路當成停車場,
buffer是要有,但絕不是越來越大,buffer是應對突發和暫時擁塞的,但擁塞絕不是趨勢,Reno家族事實上它最大的成果就是AIMD的公平,但對于擁塞控制的策略,它本質上是用擁塞治擁塞:
- 只有我觀察到了擁塞,我才知道發生了擁塞!
有點意思吧,
更有意思的是,后面出現了Westwood,但是卻沒有把BBR從中剝離出來,看起來Westwood中已經蘊含了BBR了啊,少了什么呢?
嗯,Westwood少了那個ProbeRTT的收斂點,不過這是后話了,
我想噴一會兒,針對某些人或者不針對某些人,
對TCP演算法的魔改有收益,那完全是對自私的一種蒼白辯解,
早在大約10幾年前,中國本土或者一些香蕉人社區開始出現一批希望通過多發些資料包企圖繞過TCP固有擁塞控制的人,這是一種樸素的 “TCP加速” 的思想,在今天看來,這是一種倒行逆施(即使在今天這批人也不承認他們在開歷史倒車,依然以元老泰斗的身份招搖撞騙),但在那個時候,這些人彷佛開辟了新世界,
他們根本不知道維護公平性的意義! 回到1986年之前,每個人都在做TCP加速!!!
誠然,人各為己,但那是建立在契約之上的,損人利己,就會被唾棄,他們行為的結果并非什么技術上的突破,而是幾乎所有的公司甚至個人都開始了自己的 TCP加速!
最開始是APPEX,然后是網宿,依托這種伎倆構建了足夠高的門檻,洋洋自得,但這個行當遲早還是被互聯網公司,特別被大型互聯網公司盯上了,于是這批 自稱 第一代,第二代,第三代,第xx代的各種 掌門人 開始躍躍欲試于大型互聯網公司之各家(通俗點說他們也是在主動找作業,而不是作業在找他們),幾乎用同一種非常樸素的方式讓這個行當(遠遠不能稱之為行業)在整個互聯網行業里成了帶點烏煙瘴氣的 “黑科技” ,這種烏七八黑里摸索出來的rubbish反過來又吸引了各類本應該在其它領域里創造輝煌的精英或者那些僅僅想蹭點技術熱度的媒體人的注意,這就是現狀,
這些 “掌門人” , “長老” 們,除了可以抑揚頓挫地鄙視一下晚輩們,還能做些什么呢?本著一種態度上的較真兒,這些人真的比谷歌的Neal Cardwell更牛逼嗎? 為啥Neal看起來更善良呢?這幫掌門人長老泰斗們,如果你問他們一些形而上的問題,他們可以給你扯上8個小時17分鐘29秒,如果你問一些具體的問題,比如CUBIC的細節是什么,比如Reordering是怎么計算的,他們的回答只有 “這么簡單的問題還不會?” 或者 “自己看代碼去,” 其實我很清楚,他們自己根本就不懂這些,
核心的中轉設備之間很多都不是用裸TCP封裝IP頭之后傳輸的,要么換頭,要么再封裝,SCTP,GRE,UDP這種用的也很多,至少在網路設備看來,能看到TCP的就很少,把TCP當成整個網路,就以為網路就像大學課本上講TCP/IP原理時那么樸素,也太簡單了點,
具體情節,請在各大論壇,知乎,微信群,QQ群會會他們就知道,但唯獨在maillist和github上找不到他們,哈哈,是不是覺得是時候像干馬保國一樣干他們一波了啊哈,然后看他們 “鼻青臉腫” 的樣子去PR,最后再編出各種段子?
那么我是誰?我也是什么都不懂的,我甚至不會寫JAVA,想 “打” 他們的,那絕對不是我,我 “打” 不過,哈哈,我甚至連他們都不如,
大年初一早上了,回想昨日,玩遍了整個迪士尼幾乎所有專案,排除加倍的溢價,如果平時去迪士尼,一天只能玩三四個大型專案,甚至都不如,那么排隊的成本(抵消掉了我玩新專案的時間)誰來買單呢?當然是我啊!
所以,用Reno/CUBIC的,你還覺得路由器僅僅轉發了你的資料包嗎?記住,本來你只能發1k資料,結果你把10k資料全部burst出去了,你以為這就完事了嗎?結果呢:
- 最后一個ACK的到達時間沒有絲毫改變(可能還更遲),
- 你要花更多的錢買buffer更大的路由器(即便中間設備你不直接買,最終也是攤錢了的),
經理滑倒了的瞬間,可是領帶卻還保持在原來的高度,皮鞋本來就在地面上,也沒有降低高度,降低了的只有經理的襯衫,西褲,皮帶,以及經理本人,
浙江溫州皮鞋濕,下雨進水不會胖,
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/259279.html
標籤:其他
