關于 400Gbps+ 場景的概括,參見:400Gbps 網絡面臨的挑戰(zhàn)
網站設計、成都網站建設的開發(fā),更需要了解用戶,從用戶角度來建設網站,獲得較好的用戶體驗。成都創(chuàng)新互聯多年互聯網經驗,見的多,溝通容易、能幫助客戶提出的運營建議。作為成都一家網絡公司,打造的就是網站建設產品直銷的概念。選擇成都創(chuàng)新互聯,不只是建站,我們把建站作為產品,不斷的更新、完善,讓每位來訪用戶感受到浩方產品的價值服務。
首先定義規(guī)則:
然后看圖:
若說到達率和服務率相等,在足夠久的相同一段時間,垂直線和水平線的數量是相等的,但表示到達的垂直線是實在累加的,而表示處理的水平線中有很多空閑的浪費,所謂逝去時間不可追回。
刪掉空閑水平線后,垂直線數量將大于水平線數量,二者的差值就是平均隊列長度。因此有:
這大致直觀詮釋了排隊論的那些個公式。有下圖做統(tǒng)一展示:
看這個鏈接:Towards 800G and 1600G Ethernet,網卡的發(fā)展似乎比 DDRx 快,幾乎有追趕 CPU 內存帶寬的趨勢,當網卡速率與 CPU 讀寫內存的速率趨同甚至超越時,按照上圖展示的排隊率原理,a >= b,沒得玩了。
回到 CPU 處理 TCP 的問題。
TCP 必須保序,故在單 CPU 串行處理比 “多 CPU 并行 + 同步” 的總效能更高。但 CPU 處理 TCP 邏輯時間約定值,以 Linux Kernel TCP 為例,即 tcp_v4_rcv 函數的指令時間(包括內存拷貝時間)約定值,該時間很難壓縮到 500ns 以內。
假設 TCP 報文的到達與 CPU 的處理已完全校準,統(tǒng)一達到 100Gbps 的速率。
TCP 報文的到達雖非完全隨機分布,但一定不是均勻的,只要兩次到達時間稍微錯過 1 個處理周期,依照上圖解釋,排隊即將無窮增加,為清空隊列,TCP 只能降速。
為實現初始假設,CPU 處理 100Gbps 到達率,需在 100ns 內完成 tcp_v4_rcv 調用(除 CPU 執(zhí)行冗長的指令,還要加入內存操作,batch 只降低 overhead,但內存時間也相應越久,ZeroCopy 也不例外,稍好,但不完全),CPU 很難完成該任務,初始假設都難,匡論后續(xù)隨機過程。
難道不能提升 CPU 和內存的能力?當然可以,但 CPU 主頻已經接近極限,內存帶寬已經上百 GB,還能提升多少呢?正如大家說,不如上專門硬件,FPGA,SmartNIC,… 可為什么非要猛件迎合 TCP 呢?難道不是 TCP 自己的問題嗎?
假設 TCP 可以亂序接收,就可以并行多路徑傳輸并行處理 TCP 報文了,1 個 CPU 處理 25Gbps 綽綽有余,20 個 CPU 不就可以處理 500Gbps 了嗎?問題不在硬件,問題在 TCP。
再給個形象的類比,工地上工人往樓上接力扔磚。
Linux Kernel TCP 就是如此這般扔磚接力,換個實現方式就好很多:
?
那么,以上就是亂序傳輸的好處,可以并行處理。然而 TCP 并不具備這能力。
這還不算擁塞控制的副作用,比如丟包,亂序帶來的損耗,全在 TCP 保序約束。
放棄 TCP,人們一時半會兒不能接受,且不說新協議部署升級問題,人們從心理上也不能接受,但凡說了這話,大部分人都覺得此人在瞎咧咧,那就不再說,但 TCP 也不是什么都不能做:
單流 TCP 挑戰(zhàn) 100Gbps+ 是難成功的,但 100Gbps+ 的網絡根本就不是讓單流跑滿的,那么似乎多線程多流 TCP 跑滿 100Gbps+ 也算。但是還有更有趣的,那就是不用 TCP,It’s Time to Replace TCP in the Datacenter 這篇不錯,讀后感也寫過:It’s Time to Replace TCP in the Datacenter 讀后 本文接著寫點感想。
浙江溫州皮鞋濕,下雨進水不會胖。
你是否還在尋找穩(wěn)定的海外服務器提供商?創(chuàng)新互聯www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源,準確流量調度確保服務器高可用性,企業(yè)級服務器適合批量采購,新人活動首月15元起,快前往官網查看詳情吧