[點(diǎn)晴永久免費(fèi)OA]說說過量 tcp pure ack 的利弊
當(dāng)前位置:點(diǎn)晴教程→點(diǎn)晴OA辦公管理信息系統(tǒng)
→『 經(jīng)驗分享&問題答疑 』
tcp 的 ack 實在太多了,如果互聯(lián)網(wǎng)上 80% 報文是 tcp,那么其中 1/3 的報文都是 ack,此前寫過幾篇短文,比如 丟棄一些 pure ack 和 注入或利用 pure ack。 簡單說,tcp 依靠 ack 提供 self-clock,發(fā)送 data 越多,ack 越多,如果 ack 與 data 不同步,將出現(xiàn)各種問題,詳見 rfc2525-Stretch ACK violation。 正如哥斯拉將會壓垮自身一樣,tcp 的 pure ack 也會隨著帶寬進(jìn)一步提高對系統(tǒng)帶來越來越大的重負(fù)。pure ack 是小包,與 data 數(shù)量線性同步的 pure ack 對系統(tǒng)帶來不對稱的壓力,系統(tǒng)最怕高頻小包。 典型的三種場景不得不防,pure ack 在 sender/receiver 端與 data 競爭 cpu,pure ack 在 wifi 等 csma 網(wǎng)絡(luò)與同流 data 競爭信道,pure ack 在交換節(jié)點(diǎn)與 data 競爭 buffer 和帶寬。無論哪一種問題,都因摩爾定律落后于帶寬發(fā)展而日趨嚴(yán)重。 在端側(cè),pure ack 的每次處理需要一次 cpu 中斷,而定期輪詢將損害 delivery rate 計算并降低靈敏度;在 wifi,每個反向 pure ack 都要和正向 data 競爭時隙,以 2:1 為例將侵占系統(tǒng) 1/3 的帶寬資源;在交換節(jié)點(diǎn),大量資源用于管理大量 pure ack,對 data 照顧不周將加劇擁塞,特別在丟包和恢復(fù)階段,tcp 的 data/ack 將達(dá)到 1:1,對交換機(jī)資源占用更高,越丟包越容易更丟包。 固定資源的系統(tǒng),tcp 最終吞吐將被自身 ack 限制在固定比例,ack 損耗隨處理器和帶寬的不對稱發(fā)展趨向增加。 lro,wifi frame-aggregation 等治標(biāo)不治本的技術(shù)來掩蓋問題也不知是福是禍,很少有人能認(rèn)識上述三個場景的問題,甚至很少有人意識到它們存在。 tcp 在 100Gbps+ 的理論吞吐有一半,另一半資源用來處理 pure ack 了,允許 tso/lro/ack-aggregation/big-tcp 再擠出些帶寬,勉強(qiáng)到 70% 甚至 90%,但擠牙膏皮顯然毫無意義,就看 1.6Tbps 網(wǎng)絡(luò)中 tcp 如何應(yīng)對。問題在 tcp self-clock 對 ack 太過依賴。 問題的意義在于新協(xié)議而不是如何改進(jìn) tcp。你會將 tcp 某特征抄進(jìn)新協(xié)議嗎?教科書里教的都是這特征解決了什么問題,而只字不提它是哪些問題的所在。因此我們看到一個又一個的 yet another tcp。 同樣基于 tcp ack 太多的問題,果真百害無一利嗎? tcp ack 實在太多,但并非沒用,正如 self-clock 顧名思義,流量由 ack 觸發(fā)。在如 clos/spine-leaf 這種規(guī)整且局域?qū)ΨQ的拓?fù)湎?,路徑也對稱,交換機(jī)可分析 ack 提前預(yù)期大流量,對反向的 ack 整形即可對未來流量整形,從而提前避免擁塞。這比等大流量真正到了再反壓或者丟包要好太多。 對于 tcp 長連接,上述方法可以捕捉源自同一 receiver 但目標(biāo)卻是不同 sender 的大量 pure ack 從而預(yù)期一次潛在的 incast,對這些扇出的 pure ack 進(jìn)行 pacing 整形,就可消除未來的扇入 incast,是不是很有趣。 這思路適用于一切規(guī)則拓?fù)湎碌膫鬏攨f(xié)議用來消除 incast,規(guī)則拓?fù)湎拢粨Q機(jī)可分析途徑的 request 而提前預(yù)知 response 流量特征,在獲知將來潛在擁塞后,交換機(jī)可對這些 request 整形,間接控制 response 流量。 看起來像是在利用 pure ack,實際是在利用規(guī)則拓?fù)?,?guī)則拓?fù)渲?,交換機(jī)比端對流量具有更全局且精確的預(yù)期,得益于交換機(jī)知道流量源自哪里去往哪里。在同一尺度的網(wǎng)絡(luò)中,規(guī)則相通,問題也相通。在廣域網(wǎng)中,分布式特征更傾向于端到端控制,因為傳播時延太大,拓?fù)洳粚ΨQ,交換機(jī)它算不準(zhǔn)。 周末的文章 incast,擁塞控制,內(nèi)存墻的秘密 我的一個回復(fù) “數(shù)據(jù)中心服務(wù)器扇出每個 request 都攜帶唯一的 expired id,這個id 在請求端生成,每個 id 均唯一,該 id 表示一個時間戳,指示在發(fā)送 response 前等待多久…”,expired id 只為放大波動,每臺服務(wù)器都受負(fù)載隨機(jī)波動而波動,將這個波動放大到交換機(jī)帶寬的粒度,incast 隨之消失。這事實在廣域網(wǎng)能得到印證,廣域網(wǎng)沒有 incast,原因就是多級鏈路,長距離放大了波動,從而消除了全局同步。隨機(jī)修剪光纖長度就是想在數(shù)據(jù)中心人為放大隨機(jī)波動。 回到 pure ack 過多問題,如果數(shù)據(jù)中心可利用 pure ack 度量或預(yù)測潛在流量特征是因為網(wǎng)絡(luò)足夠規(guī)則,那么在廣域網(wǎng),1:2 的 data/ack 比例則沒必要,廣域網(wǎng)波動性被放大而損害的預(yù)測精度損失不會隨樣本增加而緩解,按照大數(shù)定律,樣本增加只能更精確測量波動本身,而波動是滯后的,擁塞控制要做的是在更粗粒度感知波動而不是精確測量波動。 以我的從業(yè)經(jīng)驗,細(xì)粒度度量和粗粒度度量相比,對于預(yù)測未來鏈路畫像,并不能更精確。用歷史預(yù)測未來更多的是經(jīng)驗走勢,而它本就是粗粒度的。 足球場的面積,腿腳的靈活性決定了球門的大小,同時也約束了上場人數(shù),因為人數(shù)不能改變每一個次射門的進(jìn)球概率,人數(shù)過少或過多都將降低觀賞性。這是尺度決定的,相反,將桌球打進(jìn)直徑 10cm 的洞卻是每一個桌球玩家的基本要求。 tcp 說舊不舊,quic 幾乎就是 yet another tcp,但 tcp 確實很舊,當(dāng)我們要優(yōu)化 tcp 或迭代一個新協(xié)議時,不能被表面現(xiàn)象牽著鼻子走,一定要回到 1970 年代彼時彼刻的現(xiàn)實,你會發(fā)現(xiàn) tcp 幾乎一切的設(shè)計都出自四個字,簡單能用。所以也就沒有那么多為什么和好不好了。tcp 后來的問題并不影響它的可用性,可如今人們幾乎把高性能 tcp 玩成了煙花特效,但當(dāng)人們真去設(shè)計一個試圖取代 tcp 的新協(xié)議時,卻把那些導(dǎo)致低性能的特性也一并抄了去,結(jié)果新協(xié)議也只是可用,并不簡單,在它針對的范圍外也不高效。 浙江溫州皮鞋濕,下雨進(jìn)水不會胖。 ———————————————— 版權(quán)聲明:本文為CSDN博主「dog250」的原創(chuàng)文章,遵循CC 4.0 BY-SA版權(quán)協(xié)議,轉(zhuǎn)載請附上原文出處鏈接及本聲明。 原文鏈接:https://blog.csdn.net/dog250/article/details/134649784 該文章在 2023/12/26 10:03:01 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |