原文：https://www.sohu.com/a/190664909_210640
報告人：高峰
低時延網絡的實踐：
第一是低時延網絡解決方案，會介紹百度在低時延網絡解決方案設計過程中如何思考的
第二是低時延網絡技術展望，會介紹低時延網絡技術研究方向
第三是總結。
以前數據中心：
追求大帶寬，無阻塞 。
現在數據中心：
追求低時延、無丟包。
網絡時延組成5部分：光電傳輸時延、數據串行時延、設備轉發時延、重新排隊時延、主機處理時延。
光電傳播時延：是固定值，沒辦法改變
數據串行時延和設備轉發時延：主要是取決於芯片技術的發展
我們聚焦的重點是重新排隊時延和主機處理時延，通過主機端加速技術，可以減小主機處理時延，我們選擇的方向是RDMA和RoCE，主要考慮成本和技術成熟度，另外隨着100G技術的成熟，RoCE的優勢越來越明顯，網絡側我們選擇的方向是DCB和ECN，通過流控技術，避免網絡擁塞造成的業務丟包。
主機端的加速，我們是RDMA和RoCE，RDMA性能方面有兩個方面，RDMA的性能優勢主要體現在以下幾個方面：
1.Zerocopy：減少數據拷貝次數，由於沒有將數據拷貝到內核態，傳輸延遲會顯著提高，
2、Kernelbypass&Protocoloffload：不需要內核參與，數據通路中沒有繁瑣的處理報頭邏輯，不僅會使延遲降低，而且也大大節省了CPU的資源。
RDMA和TCP相比，性能提升比較明顯，但是數據包大小，以及業務模型不同情況下，提升的效果也不同。我們在語音識別訓練提速2倍，在機器翻譯訓練提速15倍。
RoCE是RDMA承載協議，RoCE和Infiniband的性能基本相近，而且比iWARP產業生態更加健全，主流網卡廠商都已支持。除此之外，RoCE網絡在數據鏈路層支持標准以太網協議，在網絡層上支持IP協議，因此可以無縫融合到現有的數據中心網絡中，部署和運維更加方便，而且設備成本更低。
以太網為何容易丟包
以太網采用的是盡力而為的轉發方式，每個網絡設備都會盡力的把數據轉發給下游的設備。當下游設備處理能力不足的時候，網絡就會出現擁塞或者丟包，所以網絡本身是不可靠的，無論是TCP或者RDMA協議，網絡擁塞和丟包重傳都會讓業務性能受到影響，尤其是RDMA協議對網絡丟包的容忍度更低。如何減少或者避免網絡擁塞和丟包，現在通用的解決方案是PFC和ECN的流控技術。
PFC 和 ECN
PFC是一種基於隊列的反壓協議，在單機場景下，PFC可以快速、有效的調節服務器速率來保證網絡不丟包，但是在多級網絡中，就會出現不公平降速、PFC風暴、死鎖等問題，而且當有異常服務器向網絡中注入PFC報文時，還可能造成整個網絡癱瘓，因此，在數據中心開啟PFC，需要通過對Pause幀進行嚴格的監控、管理，以保證網絡的可靠性。
ECN是一種基於流的端到端流控技術，效果上會優於PFC，但是也不是很理想，主要有幾個問題：
1、ECN缺點是需要網卡側生成反壓報文，反饋路徑周期比較長。
2、隨機性標記，會不公平。
3、水線設計比較復雜，這也是現階段ECN方案的最大挑戰，因為水線不是一個固定值，要結合網絡架構和業務特點來設計。
4、目前各個網卡廠商擁塞算法不一致。雖然方案不理想，但是目前也沒有更好的選擇。
從解決方案設計上面來說，ECN和PFC組合配置，針對PFC固有的缺陷問題，可以通過優先觸發ECN報文，用來減少網絡中PFC的數量，在PFC生效前完成流量的降速。
避免觸發流控機制+加速比
（PFC流控，但是擁塞發生后觸發的。那要在擁塞之前就接入，避免發生擁塞：ECN）
依靠有效流控機制只能是減少網絡擁塞和丟包的發生，網絡是共享資源，面對多個業務並發流量導致擁塞的問題，是很難避免的。高效的網絡一定是避免觸發流控機制，那么在組網架構方面也要同步思考這個問題，比較有效的辦法是用帶寬來換時間，為服務器提供端到端的線速轉發能力。下面介紹一下網絡架構設計過程中要關注什么，在低時延網絡架構設計中最關鍵的指標是加速比，加速比越大，網絡擁塞越少，時延越低。目前我們的網絡架構設計是1：1加速比，下一代新架構會提升加速比到4：3以上，主要來避免fabric內部擁塞和丟包問題，加速比提升會讓網絡性能提升，新架構在性能提升的同時，也要付出更高的組網成本。
（加速比：http://blog.chinaunix.net/uid-26893610-id-3769239.html ?、http://net.zhiding.cn/network_security_zone/2008/0925/1152705.shtml ?）
下面分享一下在整個設計過程中的思考。在整個低時延網絡解決方案中有兩個選擇：
第一個是單獨部署PFC，
第二個就是PFC和ECN的結合。
結果很明顯：
1、ECN+PFC的方式優於單獨部署PFC.
2、加速比是很關鍵的指標，決定了我們的效率，加速比越高，網絡優勢就越明顯。
3、就是水線的設計，PFC的水線越大，ECN的水線要適合網絡模型。
下面分享一下我們在方案設計過程中的一些分析，有兩種技術方案選擇，
第一種是單獨部署PFC
第二種是PFC+ECN組合
我們分別在加速比1：1和加速比4：3環境下，以及在不同的帶寬利用率下面測試，分別是50%、75%、100%利用率。
結果很明顯：
1、ECN+PFC優於單獨部署PFC，而且在各種利用率情況下均有優勢。
2、加速比是關鍵指標，加速比決定網絡效率，越高，優勢越明顯。
3、水線設計一定要合理，PFC水線的設置只要滿足HEADROOM，越大越好，ECN水線的設置需要視不同流量模型而定。
PFC+ECN VS 新方案
這個分享是PFC+ECN和新方案的對比，新方案是我們在探索的一個方向，就是在tor下行端口單獨部署ECN，這個方案需要兩個前提條件，ECN控制環不失效，fabirc內部不能丟包，提高加速比來解決fabric內部丟包問題，從結果上看會優於PFC+ECN的方案，但是如果fabric內部無法保證不丟包，在僅部署ECN時，丟包率非常高，100%利用率時，丟包率高達5%以上，影響會非常嚴重，穩妥一些還是PFC+ECN的組合方案比較好。提高加速比可以緩解Fabric內部端口的擁塞，仍然存在流量不均導致丟包的可能，也要配合一種理想的負載均衡方案。
對未來的技術展望
以上是百度在低時延網絡解決方案上面的思考，下面是我們對未來的技術展望。我們
希望從四個方面進行深度的優化，控制面、數據面、管理面、功能強化。
控制面-優化反饋機制，目前擁塞反饋信息比較單一，反饋內容很少，由於是網卡做擁塞通知，反饋路徑周期太長，控制面數據未高優保障。需要優化通知消息，引入更多級別的擁塞通知機制，包括擁塞程度等信息，通過多種方式提速，比如交換機設備直接反饋擁塞通知，縮短反饋路徑，確保控制面消息在網絡傳遞過程中不被丟棄，同時由交換機來觸發丟包重傳。
數據面-多路徑負載均衡，當前多路徑下多采用基於流的哈希算法，實現數據在不同鏈路上調度，大象流疊加容易造成流量不均，在特定路徑的擁塞。如前面解決方案中介紹，fabric內部的負載均衡很重要，需要從負載均衡算法方面進行優化，例如：基於成員接口歷史負載情況，選擇空閑鏈路。把出接口隊列長度作為流量均衡的hash因子。切割大象流，把一條流切分為多組，調度到不同路徑，且保證不亂序。從這三個方面協作處理，實現完美的負載均衡調度
管理面-自適應網絡。低時延網絡對運維的管理自動化提出更多的要求，相對於低時延網絡在丟包、性能方面提出更高的要求，網絡運維管理要屏蔽網絡環境變化對性能的影響，確保配置永遠是最優的。要達到自適應的網絡效果，我們認為應該建立分析。第一點是業務的探索和發現，我們要構建自己業務測量的能力，把業務沿途網絡節點轉發信息進行記錄和提取，第二點是計算和特征分析，根據現網實時數據和業務特征，計算出最優的水線閾值和最優策略。第三點是下發和持續的優化。根據業務流量特點，自動配置並動態調整參數，自動下發給服務器和網絡設備，實現自適應網絡配置。
功能強化-隊列優化，數據中心內流量特征有兩種，大象流和老鼠流，大象流對時延不敏感，丟包對整體性能影響較小，但是占據了80%的流量，網絡擁塞期間，很容易把交換機的隊列占滿，時延敏感的業務流量被餓死，需要從交換機隊列層面優化，將大象流隔離到單獨的隊列中，為老鼠流預留足夠的buffer，以及單獨的隊列設計，實現設備層面的低時延轉發。
以上技術分享就結束了。在低時延網絡里面業界也關注很多，也有很多相應的技術，由於時間關系就分享這么多。總結一下今天我的分享。共4個部分，第一部分是業務定位，低時延網絡在百度來說主要是面向百度雲和人工智能的內生需求，我們分別部署了25G、40G、100G的低時延網絡，用來支撐業務需求。從網絡定位上面，我們配合整體的網絡布局，實現局部的加速的能力。第三點是產品定位，目前低時延網絡中仍然有很多問題和挑戰，技術的優化空間還很大，在未來也希望跟廠商共同的去探索。第四點是架構演進定位，向大規模網絡架構探索，隨着技術發展，逐步優化迭代。
大象流和老鼠流
主要是通過流的大小和速率區分。
大象流：大速率，長時的流就是elephant flow，如：虛機的遷移，數據的遷移，MapReduce
老鼠流：小速率，短時的就是mouse flow，如：發郵件，看網頁，聊微信
多說一點，因為 per flow的哈希肯定是不精確的，所以elephant flow會影響到mouse flow。雖然 per packet能解決問題，但使用同時也有亂序的可能。所以，可以通過使用segment routing的flowlets來徹底解決這個問題。
鏈接：https://www.zhihu.com/question/50171430/answer/470878604
https://www.zhihu.com/question/50171430
自適應地隔離大象流和老鼠流在不同的路徑上傳輸：https://blog.csdn.net/qq_36028921/article/details/85012707
@UESTC