應用響應時延背後 深藏的網路時延

應用異常時，基本可以分為服務訪問不通和服務響應慢兩個大類。其中服務響應慢的問題定位非常棘手，很多無頭案。應用團隊有日誌和追蹤，對於自認為的不可能不合理的事情都會甩給基礎設施團隊，又由於基礎設施團隊現有的監控資料缺乏應用的觀測視角，通常成為一切「不是我的問題」超自然現象的終極背鍋俠，其中以網路團隊尤為嚴重。

01｜響應時延

服務為什麼響應慢？？？首先，我們需要一種方式來度量何為響應慢，參考 Google 在 SRE Handbook 中提到過4 個黃金訊號及 Weave Cloud 提出來的 RED 方法，都存在度量的指標（Latency/Duration），後文統稱為響應時延。

Latency 表達的是服務處理某個請求所需要的時間，站在的是服務端視角Duration 表達的是每個請求所花費的時間，站在的是客戶端視角
總結下來，不論站在什麼視角，響應時延表達的都是處理一個請求所花費的時間，可以用來表徵服務響應慢的度量指標，但若要定位為什麼響應慢還需要進一步剖解響應時延：

系統時延：系統轉發請求/響應的時延消耗
網路時延：包含查詢 DNS 時延及網路處理的時延
應用時延：從不同視角來看，包含客戶端應用處理時延 + 服務端應用處理時延

響應時延拆解

確定度量指標後，接下就可以分析服務響應慢的原因，此時可以利用分散式鏈路追蹤能力來快速來定界瓶頸點，例如可利用 DeepFlow 的分散式追蹤能力來快速定界瓶頸點在應用、系統還是網路。

分散式鏈路追蹤-火焰圖

完成瓶頸點定界後，則需要去查詢根因。對於應用或者系統的問題，可以利用效能剖析（profile）繼續追查根因，而對應網路時延的分析，其中 DNS 時延分析是相對簡單的，只需要關注請求的響應時延即可，但網路處理時延瓶頸的定位卻缺少了分析的工具，接下來將主要聚焦討論網路傳輸時延如何分析。

效能剖析-火焰圖

02｜網路時延

參考 AWS 中的定義網路時延是指網路通訊中的延時，網路時延顯示了資料透過網路傳輸所需的時間。討論網路時延如何，也是需要可度量的指標，AWS 也指定了使用“首位元組時間”和“往返時間”等指標來衡量網路時延，這兩個指標是可以適用於所有網路協議的傳輸時延的度量，但實際應用 80% 都使用的 TCP 協議，對於 TCP 協議是需要更細粒度的度量指標，下文透過圖文的形式，詳細的介紹目前可用的度量指標及用法。

TCP 協議是面向連線的傳輸層通訊協議，對其詳細的通訊過程分析，時延可分為三大類：

1) 建連時產生的時延

1. 完整的建連時延包含客戶端發出 SYN 包到收到服務端回覆的 SYN+ACK 包，並再次回覆 ACK 包的整個時間。建連時延拆解開又可分為客戶端建連時延與服務端建連時延
2. 客戶端建連時延為客戶端收到 SYN+ACK 包後，回覆 ACK 包的時間
3. 服務端建連時延為服務端收到 SYN 包後，回覆 SYN+ACK 包的時間

2) 資料通訊時產生的時延，可拆解為客戶端等待時延+資料傳輸時延

1. 客戶端等待時延為建連成功後，客戶端首次傳送請求的時間；為收到服務端的資料包後，客戶端再發起資料包的時間
2. 資料傳輸時延為客戶端傳送資料包到收到服務端回覆資料包的時間
3. 在資料傳輸時延中還會產生系統協議棧的處理時延，稱為系統時延

3) 斷連時產生的時延：因為斷連的時延並不影響到應用的響應時延，因此並不會單獨統計此部分使用

TCP 網路時延解剖

度量的網路時延的指標已經拆解好了，接下來討論在哪裡採集指標，網路的報文將在客戶端，各種虛擬和物理網路與服務端之間穿梭，因此可報文穿梭的位置點來採集，後續統稱為統計位置。當然統計位置越多，定位網路的瓶頸路徑越快，但是統計位置多則隨之帶來的計算量也是成倍增加，企業在有成本壓力時，建議在重要節點進行採集即可，比如 K8s Pod 虛擬網路卡、K8s Node 網路卡、雲伺服器網路卡、閘道器（如 LVS/Nginx 等）網路卡、硬體防火牆/負載均衡器前後......

統計位置

分析到這，基本已經清晰網路時延的詳細的度量指標了，回過頭結合響應時延再討論下如何檢視網路時延對其的影響，基本可以分兩種情況討論:

a) 應用發起請求為短連線：此時分析網路時延需要檢視 DNS 時延 + 建連時延 + 客戶端等待時延 + 資料傳輸時延 + 系統時延，則可快速定位時延發生的具體原因了。

• DNS 時延高，結合統計位置，則可回答是網路傳輸時延高還是DNS服務響應慢
• 建連時延高，結合客戶端建連時延 + 服務端建連時延 + 統計位置，則可回答是網路傳輸時延高還是客戶端系統回覆慢還是服務端處理建連響應慢
• 客戶端等待時延高，結合統計位置，則可回答是網路傳輸時延高還是客戶端請求傳送延遲
• 資料傳輸時延高，結合統計位置，則可回答是網路傳輸時延高還是服務端響應慢
• 系統時延高，結合統計位置，則可回答網路傳輸時延高還是服務端協議棧處理慢

b) 應用發起請求為長連線：因為長連線是保持長期活動的 HTTP 連線，不需要考慮 DNS 查詢與建連的時延消耗，只需要關注客戶端等待時延 + 資料傳輸時延 + 系統時延即可

03｜案例分析

限於筆者時間限制又想早點將應用響應時延背後深藏的網路時延剖解分享給大家，本文不繼續補充實際案例，將在一週後分享在某xx智慧終端公司的如何結合 DeepFlow 在服務響應慢時，網路團隊在存在可觀測性的時延資料時，如何硬氣回懟。

04｜什麼是 DeepFlow

DeepFlow[1] 是一款開源的高度自動化的可觀測性平臺，是為雲原生應用開發者建設可觀測效能力而量身打造的全棧、全鏈路、高效能資料引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技術，創新的實現了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心機制，幫助開發者提升埋點插碼的自動化水平，降低可觀測性平臺的運維複雜度。利用 DeepFlow 的可程式設計能力和開放介面，開發者可以快速將其融入到自己的可觀測性技術棧中。
GitHub 地址：https://github.com/deepflowys/deepflow
訪問 DeepFlow Demo[2]，體驗高度自動化的可觀測性新時代。

05｜參考文件

• https://aws.amazon.com/cn/what-is/latency/
• https://baike.baidu.com/item/%E7%B3%BB%E7%BB%9F%E5%93%8D%E5%B...
• https://dev.to/aws/why-are-services-slow-sometimes-mn3
• https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus...
• https://www.weave.works/blog/the-red-method-key-metrics-for-m...

• https://aws.amazon.com/what-is/latency/

  引用資料

[1] DeepFlow: https://github.com/deepflowys/deepflow

[2] DeepFlow Demo: https://deepflow.yunshan.net/docs/zh/install/overview/