文/eBPF 技術探索 SIG

一、網路抖動背景

延時高，網路卡，卡住了美好！

應用抖，業務驚，驚擾了誰的心？

當你在觀看世界盃梅西主罰點球突然影片中斷了幾秒鐘

當你在遊戲中奮力廝殺突然手機在轉圈圈無法響應

當你守候多時為了搶一張化妝品優惠券突然遲遲載入不出來...

我們經常在觀看影片、手機遊戲、網上購物時，會遇到上面這些煩心事，作為使用者，我們總有被卡在“臨門一腳”的感覺，此時的你，是否有種想把手機或電視砸掉的衝動？或者破口大罵網路服務商的線路不穩定？是的，這種現象一般是網路抖動引起的。

“高頻率、難攻克”一直是業界對 抖動問題的評價，特別是在我們雲端計算場景下，複雜的網路拓撲，眾多的業務承載形態，容器、虛擬機器和傳統的物理機並存，業務的應用也出現了微服務眾多、多語言開發、多通訊協議的鮮明特徵，這給我們定位這類問題帶來非常大的挑戰。試想從我們的手機或者 PC 瀏覽器發出的一個付款請求，可能要經過你的家庭路由器，運營商網路，雲服務商物理網路、虛擬網路，以及電商伺服器，容器或者虛擬機器，最後才是具體的服務程式對請求進行處理，這裡面每個節點都可能存在延遲。

購物、遊戲、影片、金融等領域，受限於傳統的 IDC 物理網路的環境因素，多樣化的雲網路場景，以及業務系統的複雜性， 所有涉及到網路請求和處理的地方，都會存在業務網路抖動的情況。

在雲服務商內部，業務所在的 ECS 伺服器，日誌的儲存和上傳、資料庫訪問，可能分散在不同的節點，節點之間也有各種閘道器和內部網路。當出現抖動時，每個功能模組都只能維護自己的節點診斷資訊，無法透過統一平臺呈現具體時延資訊，相互之間的自證清白的能力比較弱。

到具體業務和應用處理上，由於作業系統上面跑著各種任務，相互之間的排程和處理都會有干擾，記憶體分配、報文解析、IO 訪問延遲等等，都給我們分析抖動問題帶來困難。

二、網路抖動的定義

2.1 網路抖動的定義和現象

前面我們一直在提延遲，提抖動，以及抖動如何難分析。現在我們回到一個最初的問題， 什麼是網路延遲？什麼是網路抖動？雲端計算場景中抖動都有哪些具體的現象？

網路延遲是指報文在網路中傳輸所用的時間，即從報文開始進入網路到它開始離開網路所經歷的時間。各式各樣的資料在網路介質中透過網路協議(如 TCP/IP)進行傳輸，如果資訊量過大不加以限制，超額的網路流量就會導致裝置反應緩慢，從而造成網路延遲。

而 抖動是 Qos 裡面常用的一個概念，當報文經過交換機、路由器等裝置時，容易出現網路擁塞，通常報文會進行排隊，這個排隊延遲將影響端到端的延遲，並導致透過同一個連線進行傳輸的報文經歷的延遲各不相同，所以抖動，就是用來描述這樣一延遲變化的程度。 網路抖動值越小說明網路質量越穩定。舉例說明，假設 A 網路最大延遲是 15 毫秒，最小延遲為 5 毫秒，那麼網路抖動值是 10 毫秒。

總結起來，網路抖動是指在某一時刻業務的流量下跌、正常業務指標受損，網路出現延遲等。延時和抖動主要的後果是 影響使用者體驗，特別是在遊戲場景中更是來不得半點抖。試想當你在打怪買裝備時抖了那麼 20ms，裝備沒了，此時捶胸頓足砸鍵盤也於事無補啊。

另外，雲場景下，使用者不僅關心正常場景的平均延遲，對異常場景下的長尾延遲，也越來越關注。 影響長尾延遲的因素，如當機、網路延時、磁碟抖動、系統夯機等等。長尾延遲還存在著放大效應，比如系統 A 序列向系統 B 傳送 5 個請求，前一個請求返回才能進行後一個請求，當系統 B 出現一個慢請求時，會堵住後面 4 個請求，系統 B 中的 1 個 Slow IO 可能會造成系統 A 的 5 個 Slow IO。所以，每個節點的每一個系統服務都有義務主動減少或降低處理延遲。

我們通常說的網路抖動，拿 雲端計算場景來看，可能有如下現象：

1、兩臺 ECS 伺服器之間從發出 ping request 到 reply 回覆的正常水平是 5ms，在某個時間點突然發生抖動，增加至 50ms，隨後馬上恢復。

2、負載均衡 SLB 上的 HTTP 請求平均延遲的正常水平在 10ms，在某個時間點突然發生抖動，整體延遲增加至 100ms，隨後馬上恢復。

3、透過 ECS 訪問 RDS 資料庫，在某個時間點突然列印大量日誌如"SocketTimeOut"、"Request timeout" 等，持續時間為秒級，隨後馬上恢復。

從上述現象可以看出，網路抖動在雲端計算場景下有了新的理解，它產生的原因可能是由於 傳送端和接收端之間的鏈路、系統內部的一個瞬時抖動，比如業務所在 Linux 系統 crash、鏈路有丟包重傳、網路卡 up/down、交換機快取瞬時打滿等。

我們先看一下解決網路延遲和抖動的一般方法：

1、交換機和路由器等裝置，主動避免網路報文排隊和處理時間。

2、雲網路及上雲等閘道器裝置主動降低處理延遲，透過硬體提高轉發速度，透過 RDMA 技術降低時延。

3、業務應用所在的虛擬機器或者容器的核心協議棧開啟 tso 等硬體加速方案，採用零複製等技術降低延遲。

2.2 網路抖動的分類

在雲端計算場景下，透過對抖動問題進行分析，根據抖動發生的時刻和是否可復現，將抖動分成三大類：

1、當前還在發生的抖動問題，且這個現象還繼續存在，我們稱之為 Current 當前抖動。這類問題一般由於鏈路中有持續性或週期性丟包、Qos 限流引起。

2、過去某一時刻出現的抖動，當前現象已不存在，我們稱之為 歷史抖動。這類抖動問題一般在日誌中列印“socket timeout”，或者有重傳報文記錄，這類問題相對來說少，很難定位。

3、透過 ping 包去檢測連通性或網路狀態，經常有幾十甚至上百 ms 的延遲，而正常情況是幾個 ms 不到。 ping 毛刺問題，有可能該現象還一直存在，或者是間歇性地出現。這類問題一般是業務負載高(load 高)，系統卡頓，或者存在虛擬化環境中的 CPU 爭搶問題。

一般的，丟包和重傳會引起當前和歷史抖動問題，拿 tcp 協議來說，只要從 tcp 發出去的報文在鏈路上出現了丟包，核心協議棧就會對該 報文進行重傳， 大量的重傳會導致業務超時和引起網路抖動。因此，丟包問題，也是網路抖動的頭號宿敵。但還得明確一個概念：網路丟包可能造成業務超時，但是業務超時的原因不一定是丟包。原因前面也提到過，包括鏈路上的硬體轉發或路由等裝置，以及其上的系統及應用軟體的每一個環節都存在引起業務超時的情況。

2.3 網路抖動的衡量指標

衡量“網路抖動”的指標，大家能想到的肯定是看業務的請求和回覆報文的延遲是多少，即 latency 或者 RT(Reponse Time)，在雲端計算場景中，具體化到了一些特定的網路指標，比如 RT、請求數、連線數、bps、pps 等。其中一些指標的含義如下：

1. 響應時間(RT Response Time)

響應時間是指執行一個請求從開始到最後收到響應資料所花費的總體時間，即從客戶端發起請求到收到伺服器響應結果的時間。RT 是一個系統最重要的指標之一，它的數值大小直接反映了系統的快慢。

對於一個遊戲軟體來說，RT 小於 100 毫秒應該是不錯的，RT 在 1 秒左右可能屬於勉強可以接受，如果 RT 達到 3 秒就完全難以接受了。而對於編譯系統來說，完整編譯一個較大規模軟體的原始碼可能需要幾十分鐘甚至更長時間，但這些 RT 對於使用者來說都是可以接受的。所以 RT 的多少，對不同系統的感受是不一樣的。

2. 吞吐量(Throughput)

吞吐量是指系統在單位時間內處理請求的數量。

系統的吞吐量（承壓能力）與 request 對 CPU 的消耗、外部介面、IO 等緊密關聯。單個 request 對 CPU 消耗越高，外部系統介面、IO 速度越慢，系統吞吐能力越低，反之越高。影響系統吞吐量幾個重要引數：QPS（TPS）、併發數、響應時間。

3. 併發數

併發數是指系統同時能處理的請求數量，這個也是反映了系統的負載能力。一個系統能同時處理的請求數量，連線數量都有一個規格要求，當請求數越多時，系統處理的速度就會出現瓶頸。

4、QPS 每秒查詢數量(Query Per Second)****

QPS 是一臺伺服器每秒能夠響應的查詢次數，是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。

5、TPS 每秒執行的事務數量(throughput per second)

TPS 代表每秒執行的事務數量，可基於測試周期內完成的事務數量計算得出。一個事務是指一個客戶機向伺服器傳送請求然後伺服器做出反應的過程。例如，使用者每分鐘執行 6 個事務，TPS 為 6 / 60s = 0.10 TPS。

指標：

• QPS(TPS)：每秒鐘的請求/事務數

• 併發數：系統同時處理的請求/事務數

• 響應時間：一般取平均響應時間

這三者之間的關係：

• QPS(TPS) = 併發數/平均響應時間

• 併發數 = QPS * 平均響應時間

為了描述更廣泛意義上的網路抖動，雲場景中我們一般用 RT 這個術語，我們會有監控檢測某個業務的 RT 值，比如 nginx 服務的 RT 值。一般本文所述的延遲、超時、響應慢、卡頓等詞彙，只要影響到了使用者的體驗，都認為是抖動問題。

下圖是衡量指標的彙總：

三、 Linux 核心網路抖動

3.1核心網路抖動點

使用者的業務部署在雲上，一般執行在容器裡或者直接部署在 guest OS 上，前面也提到過，作業系統內部、業務程式的排程執行、業務的請求和處理也會存在網路抖動的點。其中，報文的收發過程也存在諸多耗時的地方。首先看一個 Linux 核心網路協議棧的分層架構圖。

我們先來回顧一下 Linux 的網路收包流程：

1、資料包文從外部網路到達網路卡。

2、網路卡把資料幀透過 DMA 送到系統記憶體儲存。

3、硬中斷通知 CPU 有報文到達。

4、CPU 響應硬中斷，簡單處理後發出軟中斷。

5、軟中斷或者透過 ksoftirqd 核心執行緒處理報文，然後透過網路卡 poll 函式開始收包。

6、幀被從 Ringbuffer 上摘下來儲存為一個 skb。

7、協議層開始處理網路幀，經過 netdev、IP、tcp 層處理。

8、協議層處理完之後，把資料放在 socket 的接收佇列中，然後透過喚醒使用者程式來進行收包。

9、使用者程式經過作業系統的排程獲得 CPU，開始從核心複製資料包到使用者態進行處理。

Linux 網路的發包流程如下：

1、應用程式透過 send 系統呼叫傳送資料包，從使用者態陷入到核心態，核心會申請一個 sk_buff，然後將使用者待傳送的資料複製到 sk_buff ，並將其加入到傳送緩衝區。

2、網路協議棧從 Socket 傳送緩衝區中取出 sk_buff，並按照協議棧從上到下逐層處理，最後報文進入網路介面層處理。

3、網路介面層會透過 ARP 協議獲得下一跳的 MAC 地址，然後對 sk_buff 填充幀頭和幀尾，接著將 sk_buff 放到網路卡的傳送佇列中，一般使用 qdisc 設定排隊規則，進行入隊和出隊處理。

4、網路卡驅動會從傳送佇列中讀取 sk_buff，將這個 sk_buff 掛到 RingBuffer 中，接著將 sk_buff 資料對映到網路卡可訪問的記憶體 DMA 區域，最後觸發真實的傳送。

5、當傳送完成的時候，網路卡裝置會觸發一個硬中斷來釋放記憶體，主要是釋放 sk_buff 記憶體和 RingBuffer 記憶體的清理。

處理流程如下圖所示，數字編號不一定完全對應。

上面所述的報文收發過程，存在網路抖動的地方是： 協議棧和驅動的入口和出口處，以及核心態和使用者態的銜接處。 比如接收報文到達後發出中斷到報文真正得到處理這段時間的耗時，這個耗時很多時候都是由於某個程式長時間關中斷導致中斷和軟中斷處理延遲；另一個是資料到達接收佇列後，喚醒使用者程式到真正呼叫 recvmsg 收包處理的這段時間的耗時，這個主要由於系統繁忙而出現排程延遲，被喚醒的程式長時間未能真正去處理收到的包。

因此，Linux 核心裡，網路抖動一般是在中斷和軟中斷處理的延遲，程式的睡眠和喚醒延遲，qdisc 排隊延遲，Netfilter 處理延遲，tcp 的超時重傳延遲等。

3.2 三類抖動的根因探尋和解決之道

雲端計算涉及到的網路節點較多，且每個點都有發生抖動的可能，限於篇幅，同時由於作業系統和業務最貼合，本文只基於節點內部作業系統的視角。針對前面提到的三類抖動： 當前抖動、歷史抖動、ping 毛刺，來討論一下如何去發現和解決這三類抖動的問題。

經過我們在實踐中的摸索和分析總結，提出以下抖動根因的探測方法和抖動問題解決之道：

1. 針對 Ping 毛刺問題，提出在使用者態構造報文進行探測的方法： Pingtrace。不同於大家常用的 ping 程式，Pingtrace 透過在 icmp/tcp/udp 的基礎上增加 pingtrace 協議頭，在 pingtrcace 報文沿途經過的節點填上對應的收發時間戳，最後透過計算各個節點的延時資訊，構建一個拓撲來描繪節點詳細資訊，從而找到抖動的節點和抖動原因。

2. 針對當前抖動問題，對真實報文直接跟蹤挖掘時延： Rtrace。它對真實業務報文所經過的核心處理函式特別是協議棧處理函式進行 tracing， 得到每個函式點的時間戳資訊，支援 icmp/tcp/udp/lacp/arp 等協議報文呼叫路徑的獲取和時延資訊的統計，還能清楚知道某個協議包在哪裡由於什麼原因丟包的，或者哪個函式處理慢了。

3. 針對歷史抖動問題，提出常態化抖動監控系統： Netinfo。它對容器（pod）、流、邏輯介面的各項指標進行監控，追蹤業務抖動的根因，進行叢集和單機的告警上報。深度加工丟包、重傳、擁塞控制、視窗變化、流量突發、中斷延遲等指標進行分析，歸一化成簡單的健康度指標；同時在資料處理中心進行離群檢測，找出影響抖動的幾個重點指標和具有叢集共性的指標。

4. 針對不同的業務應用，提出應用觀測引擎 Raptor。業務應用的內在問題是客戶直接能看到的，但是如何與系統指標關聯，是當今觀測領域的難點，它透過把應用內部的細節進行展開，結合系統的 profiling 剖析，能找到應用抖動的密碼。

透過 網路抖動三劍客和應用觀測引擎 Raptor，我們能系統的監控和觀測在節點內部出現的抖動，同時能定界出是業務應用自身的問題，還是外部網路的問題。下面的章節我們將簡單介紹網路抖動三劍客的原理。（關於應用觀測引擎 Raptor，限於篇幅會另外組織一個專題介紹）

四、瞬時毛刺的主動探測：Pingtrace

4.1 背景

在碰到網路聯通性較差或者系統比較卡時，我們喜歡用系統自帶的 ping 命令向目標地址傳送請求包進行檢測，然後透過目標機回覆的響應包來判斷是否出現了延遲，這種方法簡單又高效。但有時我們想知道，這個 ping 包延遲了，和業務的關係怎樣？是否延遲高了或者又丟包了，業務應用就真的出問題了？延遲和丟包的具體點在什麼地方？是系統內部還是外部鏈路？原因是什麼？

經過這麼幾個靈魂拷問之後，我們發現，對於瞬時 ping 延遲突然衝高的問題（ping 毛刺），傳統的 ping 工具已經不能直觀的拿到背後的資訊。為此我們提出了 透過構造新報文（pingtrace 報文）的方式進行主動的探測，透過在 pingtrace 沿途經過的點填充 timestamp 的方式，把系統內部的延遲精細化到使用者態和核心態的函式處理點，然後透過視覺化方式展現延遲高的模組。

4.2 pingtrace功能介紹

Pingtrace 透過在使用者態構造探測協議報文，在獨有的 pingtrace 頭部增加 icmp、 tcp 及 udp 協議頭，可以進行 多種協議探測，同時 基於 eBPF 技術，可以做到無侵入的方式實現系統內部細節的窺探，開銷遠遠小於 tcpdump 等已有工具，並可實時展示各個資料鏈路的時延資訊，快速發現問題邊界。

下圖是 icmp pingtrace 的協議實現（icmp 頭可以替換為 tcp 和 udp 協議頭）。在各個節點，要求其他節點捕獲到特定 pingtrace 報文時填入 node id 和 timestamp（變通的實現方法是透過 eBPF 把報文送到使用者態，然後補發帶有 timestamp 的報文回送到源端），為了讓報文儘可能小於 1500 個位元組，可以透過控制表項數量來避免沿途的 IP 報文分片。

下圖是其工作過程：

下圖是最終呈現出來的效果，每個藍點地方滑鼠放過去會顯示延時資訊：

注意：很多人關心傳送端和接收端的時鐘源不統一，如何來進行延遲節點的判定。我們在邊界點採取了相對延遲的計算方法，而不是像其他幾個點的絕對延遲計算方法。

計算方法如下： 透過對邊界的兩個採集點時間戳資訊計算出差值，以最近 100 個報文中最小的差值作為基準值，對下一個報文的差值進行校正（校正就是用當前算出來的兩臺機器時間戳差值相減得到 delta，減去基準值 base 算出來的結果），最後得到相對延遲。如果發現相對延遲較高，則說明鏈路上出現了問題。

這個是 udp 的 pingtrace 探測：

這個是 tcp 的 pingtrace 探測：

tcp 和 udp 的延遲探測，主要目的是為了探測系統 tcp 和 udp 處理路徑是否出現延遲，因為絕大部分業務都會採用  tcp 和 udp（icmp pingtrace 不能滿足此需求），由於埠號的原因，它主要多了一個埠探測和學習的過程。

4.3 pingtrace 如何進行探測

具體的使用上，有介面和命令列兩種方式。介面方式只需要填入對應的源和目的 IP，它會自動下發安裝命令到 client 和 server，然後開始進行診斷，診斷結果可以直接呈現是哪個節點的哪個階段出現的延遲。

或者透過命令列方式：

sysak pingtrace_raw -c 127.0.0.1 -m 1000 -o log

五、 真實業務報文延遲挖掘：Rtrace

使用自定義報文探測方式雖然可以瞭解當前的系統負載和鏈路情況，但很難說明對某個業務或者協議是否真的有影響，所以我們還需要對實際業務的報文，包括 tcp 、udp、icmp、arp 及 lacp 等報文進行跟蹤確定報文走的路徑和每個函式的耗時。

rtrace 是一款基於 eBPF 的網路診斷工具，利用 eBPF 技術動態打點來取得報文時間資訊，以及每個網路層的詳細資訊，比如 tcp 常見的 memory 使用情況，擁塞和回覆 ack 情況，記錄在日誌裡，可以輔助問題的定界和丟包檢視。如下圖，rtrace 監控的部分協議棧處理函式點：

在雲端計算的叢集環境裡，抓取到的單個節點的延時和 tcp 連線資訊，有時還是很難去判斷是否真的有問題，如果能從叢集的維度，或者多個節點的共性事件的方式，或許能收穫更多。rtrace dump 功能還支援集中式抓包的能力，類似一鍵發起抓包功能，然後進行集中式分析，比如分析 tcp 的傳送接和接收到 ack 時間，到底是慢在哪個節點上，透過對比 tcp 的 sequence 來彙總資料，很快就能得到結果。

六、 歷史抖動監控：Netinfo

歷史抖動問題，是幾種抖動問題裡最難解決的，由於問題不再復現，我們能想到的是增加一些監控手段，把歷史某個時間點的系統狀態、協議互動情況等資訊收集起來是不是就能解決抖動問題了？答案是否定的。如果單純從網路本身的丟包和 tcp 連線狀態資訊來判斷，顯然還不夠。還需要看當時 IO 是否 hang 住，記憶體是否 oom，系統是否當機，中斷是否有突發，排程是否延遲等。

如何在上百個指標中快速找到異常點？Netinfo 在檢測到抖動後(業務的 RT 值或者健康度指標)，會先彙集所有指標進行組合，進行離群檢測。最終把叢集裡的共性事件，透過離群統計演算法來確定抖動根因。

Netinfo 主要由資料採集和資料分析告警兩部分功能組成：

關於 Netinfo 可以參考文章 Netinfo：揭開網路抖動面紗的神器。Netinfo 的功能，後面會移到 SysAK 裡，同時，後端的資料處理部分，也會移到 SysOM 統一平臺分析。

七、 網路抖動探測標準化設想及未來展望

藉助於網路抖動三劍客（Pingtrace、Rtrace、Netinfo），我們很容易知道系統的抖動點和原因。但是這些可能只是我們自己的理解，我們基於雲場景做了很多探索，並把這些探索沉澱到了龍蜥作業系統，還進行了很多最佳化。而目前作業系統呈現百花齊放的態勢，網路抖動的發現和檢測方法不統一，將很難在一些指標評測和系統對接時，有一個有效的驗收標準。因此我們覺得有必要形成一個標準，比如：

1）雲端計算場景下抖動的定義和表現是什麼？不同型別的業務有什麼具體現象就算是抖動了？

2）抖動包含哪些內容和衡量指標？指標的範圍是什麼？

3）如何檢測網路抖動？有沒有統一的工具進行探測？探測哪些點合適？

4）需要在哪些點增加時間戳統計？比如 Linux 使用者態到核心態的發包點，網路卡的發包點。

針對網路抖動，每個人的理解可能不一樣，上文 2.1 節提到抖動的幾個現象，就是具體的案例。如果能結合具體的指標去衡量，就會有很大的可實操性。比如 RT 這個指標，我們選擇 nginx 的業務作為衡量物件，RT 在多少範圍算是異常的？10ms 或者 100ms 都可能，關鍵評判是不同使用者場景，是否這個 RT 值影響到了使用者體驗，如果使用者體驗很差，就認為是發生了抖動。

當然最重要的，我們需要制定出一套方案和工具去進行探測，只要工具說探測到 nginx 業務的 RT 指標高了，那麼就說明在同一個系統負載下，你的整個雲服務網路抖動大，網路質量不太好，這個時候我們就要根據探測到的根因去解決問題。

回到作業系統層面，我們需要指定哪些探測點呢？只有大家形成一個統一認識，在Linux 核心收發包的出入口進行時間戳資訊的提取是合適的。例如在核心 sendmsg 系統呼叫函式和網路卡發包的地方（比如 virtio-net 的 start_xmit 函式）增加時間戳資訊。這樣大家實現的工具，就能統一到一個衡量維度。

比如，我們在 virtio-ne 驅動裡，我們也在積極推動增加一個時間戳的點，將有助於我們在發包處時間戳的統一：

+#define VIRTIO_NET_HDR_F_TSTAMP        8

最後做一個總結，抖動的檢測和治理是一個長期的任務，如果能將 Linux 系統內部的檢測工作標準化起來，將有助於我們制定統一的效能評測方案，以及運維自動化的實現。

另外，上述工具幾乎全部採用無侵入的方式實現，基於eBPF實現給了我們很大的發揮空間，它們將會在 SyaAK 裡全部開源（目前已大部分開源）敬請關注，後面也會有系列文章再次詳細介紹。************************************

相關連結可移步龍蜥公眾號（OpenAnolis龍蜥）2022年12月12日相同推送檢視。

—— 完 ——