大家下午好，非常高興能有機會這里跟大家分享，我來自百度系統部，今天分享的主題是百度低時延網絡的實踐，主要包括三個部分，第一是低時延網絡解決方案，會介紹百度在低時延網絡解決方案設計過程中如何思考的，第二是低時延網絡技術展望，會介紹低時延網絡技術研究方向，第三是總結。

首先說一下業務背景，人工智能、高性能計算云，實時大數據的分析，這些業務都屬于時延敏感型業務，為什么說是時延敏感業務，這里面要介紹幾個技術場景，如深度學習、分布式計算、分布式存儲、計算存儲分離，這些技術對數據中心網絡提出了明確的要求，無丟包和低時延。網絡丟包對業務性能的影響非常嚴重，網絡的時延也是影響集群計算性能的首要指標。面對這些需求和挑戰，我們的數據中心網絡也要同步做出相應的改變，來適應技術發展需要。以前我們數據中心是追求大帶寬，無阻塞，到今天應該追求低時延、無丟包。我們的數據中心網絡架構設計，要從以帶寬為中心的設計切換到以時延為中心的設計，降低時延的波動范圍。

設計低時延網絡，先要分析一下網絡時延組成，有五個部分，光電傳輸時延、數據串行時延、設備轉發時延、重新排隊時延、主機處理時延。光點傳播時延是固定值，沒辦法改變，數據串行時延和設備轉發時延，主要是取決于芯片技術的發展，其中信號傳輸和芯片pipeline轉發時延是固化的，依靠升級硬件降低時延的效果非常有限，我們聚焦的重點是重新排隊時延和主機處理時延，通過主機端加速技術，可以減小主機處理時延，我們選擇的方向是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網絡在數據鏈路層支持標準以太網協議，域名免費備案 directadmin購買，在網絡層上支持IP協議，因此可以無縫融合到現有的數據中心網絡中，部署和運維更加方便，而且設備成本更低。

以太網采用的是盡力而為的轉發方式，每個網絡設備都會盡力的把數據轉發給下游的設備。當下游設備處理能力不足的時候，網絡就會出現擁塞或者丟包，所以網絡本身是不可靠的，無論是TCP或者RDMA協議，網絡擁塞和丟包重傳都會讓業務性能受到影響，尤其是RDMA協議對網絡丟包的容忍度更低。如何減少或者避免網絡擁塞和丟包，現在通用的解決方案是PFC和ECN的流控技術，PFC是一種基于隊列的反壓協議，在單機場景下，PFC可以快速、有效的調節服務器速率來保證網絡不丟包，但是在多級網絡中，就會出現不公平降速、PFC風暴、死鎖等問題，而且當有異常服務器向網絡中注入PFC報文時，還可能造成整個網絡癱瘓，因此，在數據中心開啟PFC，需要通過對Pause幀進行嚴格的監控、管理，以保證網絡的可靠性。ECN是一種基于流的端到端流控技術，效果上會優于PFC，但是也不是很理想，主要有幾個問題，1、ECN缺點是需要網卡側生成反壓報文，反饋路徑周期比較長，2、隨機性標記，會不公平。3、水線設計比較復雜，這也是現階段ECN方案的最大挑戰，因為水線不是一個固定值，要結合網絡架構和業務特點來設計。4、目前各個網卡廠商擁塞算法不一致。雖然方案不理想，但是目前也沒有更好的選擇。

從解決方案設計上面來說，ECN和PFC組合配置，針對PFC固有的缺陷問題，可以通過優先觸發ECN報文，用來減少網絡中PFC的數量，在PFC生效前完成流量的降速。

依靠有效流控機制只能是減少網絡擁塞和丟包的發生，網絡是共享資源，面對多個業務并發流量導致擁塞的問題，是很難避免的。高效的網絡一定是避免觸發流控機制，那么在組網架構方面也要同步思考這個問題，比較有效的辦法是用帶寬來換時間，為服務器提供端到端的線速轉發能力。下面介紹一下網絡架構設計過程中要關注什么，在低時延網絡架構設計中最關鍵的指標是加速比，加速比越大，網絡擁塞越少，時延越低。目前我們的網絡架構設計是1：1加速比，下一代新架構會提升加速比到4：3以上，主要來避免fabric內部擁塞和丟包問題，加速比提升會讓網絡性能提升，新架構在性能提升的同時，也要付出更高的組網成本。