# 以統計觀點看電腦網路傳輸品質
> 資料整理: [jserv](https://wiki.csie.ncku.edu.tw/User/jserv)
本文從統計觀點，衡量電腦網路傳輸品質，將多項網路指標轉換為「陽性特徵」，並結合 sigmoid 函數與統計分佈，構建統一的指數圖像系統，從而協助精準診斷如擁塞、突發抖動與隨機封包遺失等傳輸異常狀況。
> 本文改寫[傳輸品質評估系統簡介](https://blog.csdn.net/dog250/article/details/143164573)
## 衡量電腦網路傳輸品質
在衡量電腦網路傳輸品質以進行預測時，我們會運用多種指標，而這些指標彼此之間存在差異：它們擁有不同的單位、不同的作用範圍、不同的平均與採集方式。因此，我們仰賴統一的方法來彙整這些複雜的資訊，以因應以下需求：
- 跨指標評估
- 跨主體比較與基準
- 僅區分正向與負向影響
- 強化關鍵特徵的判斷力
其主軸目的是為了取得早期預警信號，並輔助決策制定。
時間與空間具有漸變性，而世界因其時間與空間的局部性，也呈現出漸變的特徵，在經濟學領域，常藉由「指數」描述。指數消除量綱 (dimension)，使得使用單一的指數曲線來描繪趨勢變得十分便利。在任何以統計學為基礎的領域中，如氣象學、社會學與網際網路，主體想法大致相同。
相較於單一指標，指數的穩定性更高，因為它是多項因素共同作用的結果。當所有因素同步變動時，往往顯示某種深層原因正在產生具體效應；反之，單一或少數指標的異常波動通常無法顯著影響整體指數，因此可合理視為雜訊予以忽略。
本文將電腦網路傳輸的頻寬及延遲，作為整體效能衡量依據，並延伸為一種「指數」，藉此建立一套電腦網路傳輸品質評價機制，作為改善網路傳輸的依據，甚至影響通訊協定的行為。
## 建構指數的步驟
在此簡述如何設定並應用此評價機制中的指數，步驟如下：
1. 抽取指標的顯式特徵，例如在擁塞狀態下延遲一定偏高，但延遲的變異程度 (variance，變異數) 卻不一定如此，也就是說，延遲為顯式特徵，延遲變異數則否。
2. 將那些「越小越好」的顯式特徵，藉由 [sigmoid 函數](https://en.wikipedia.org/wiki/Sigmoid_function)轉換為「越大越好」，並將度量值映射至 $[0, 1]$ 區間
3. 經過轉換的「越大越好」的特徵稱為「陽性特徵」
4. 選擇一個數學函數 $f(\ldots)$，使其滿足這特性：當所有陽性特徵皆「足夠大」時，$f(\ldots)$ 顯著上升，否則維持在較低值
該方法的依據在於，唯有當所有顯式特徵皆轉化為陽性特徵時，方可合理地判斷成因。為了驗證概念，採用以下修改過的 sigmoid 函數：
為了讓第三步所提到的函數 $f(\ldots)$ 發揮更強烈的效應，本文刻意讓 $y$ 在 $x \ge 0$ 的區間內，其最大值略微超過 1。其背後的想法是：
- 僅當所有 $v_1, v_2, v_3, \ldots$ 均足夠大時，$f(v_1, v_2, v_3, \ldots)$ 才會顯著提升；
- 因此，我們需要拉大數值之間的區別，讓小的更小、大的更大；
- 換言之，將大於 1 的視為「大」，小於 1 的視為「小」；
舉例來說，可以使用如下形式來構建 $f(\ldots)$：
$$
f(\ldots) = \left( \prod a_i \right)^n
$$
或
$$
f(\ldots) = \left( \sum a_i \right)^n - \sum a_i
$$
可將 $f(\ldots)$ 的圖像視為一種「指數圖像」，當圖像凸起即代表異常出現，其幅度則反映嚴重程度。
以下說明該案例的情境與特徵：
| 狀況 | 延遲時間 | 延遲時間變異數 | 頻寬 | 頻寬變異數 |
|-----------|------|----------|------|----------|
| 穩定擁塞 | 大 | 小 | N/A | N/A |
| 突發性擁塞 | 大 | 大 | N/A | N/A |
| 隨機封包遺失（高）| 小 | 小 | 小 | 大 |
| 隨機封包遺失（低）| 小 | 小 | 大 | 小 |
低延遲時間與高頻寬幾乎是端到端 (end-to-end) 傳輸所追求的最終目標，本文以此為基礎建立評價指標。仍可透過更細緻的圖像進一步產生指數，或為現有的圖像指數新增指標，範例如下：
- 封包遺失間隔
- 封包遺失間隔變異數
- 連續兩次封包遺失時的 [TCP 壅塞視窗](https://en.wikipedia.org/wiki/TCP_congestion_control) (congestion window, cwnd) 比值
- `bw / delay` 及其變異數
- 通用 QoE ([Quality of experience](https://en.wikipedia.org/wiki/Quality_of_experience)) 映射模型
藉由上方表格，以下是模擬用的 Python 程式碼：
```python
if n > 500 and n <= 1000:
# 隨機突發擁塞
Buff = random.randint(0, 20)
elif n > 1500 and n <= 2000:
# 持續擁塞
Buff = 20
elif n > 2500 and n <= 3000:
# 逐漸擁塞
Buff += 0.04
elif n > 3500 and n <= 4000:
# 隨機高封包遺失率（無擁塞）
Buff = 0
if random.random() < drate:
wx[n] = wx[n]/2
wy[n] = wy[n]/2
elif n > 4200 and n <= 4600:
# 隨機低封包遺失率（無擁塞）
Buff = 0
if random.random() < drate/50:
wx[n] = wx[n]/2
else:
# Good
Buff = 0
while wx[n] + wy[n] + Buff > 1.2 * C * R:
wx[n] = wx[n]/2
wy[n] = wy[n]/2
```
其目標是藉由觀察「擁塞指數」、「突發指數」與「隨機封包遺失指數」，成功區分出突發性抖動、常規擁塞與隨機封包遺失等不同現象。藉由這些指數，能夠精確診斷頻寬下降的具體原因，進而有效引導通訊協定的行為調整。
以下針對前述模擬場景，加入上述指數圖像後的實作結果，並以 [matplotlib](https://matplotlib.org/) 繪製的展示：
注意最後的 Good 區段，它成功濾除出真正「有問題」且需要處理的區間，唯獨低封包遺失率的隨機封包遺失區段未被標示，這表示在目前這個濾波器的靈敏度範圍內，該區段不構成需要處理的異常。接下來，我們用低通特性更明顯的濾波器 (low-pass filter) 來觀察其效果：
透過觀察此圖來診斷傳輸效能的方法相當直觀：
- 將每個指標對應的指數圖像，與實際測得的頻寬變化圖像一同排列顯示，並保持一致的時間尺度；
- 當發現頻寬出現異常時，針對該時間區段逐一檢視各個指標的指數圖像；
- 若某個指數圖像在該時間區段呈現明顯的陽性凸起，則可判定該指標在該區段為陽性特徵；
藉由上述方法，便可清楚識別出傳輸異常的成因。
在任何時刻，我們都可檢視這些指數圖像，以改善通訊協定的表現。由於現實世界具有時間與空間的局部性，並呈現漸變特性，這類圖像能夠準確反映真實情況，具備高度可信度。
不過，在變化剛開始出現的邊緣地帶，務必謹慎，切勿輕率預測。行為應與變化本身保持一致，其策略如下：
- 若已偵測到處於持續性擁塞階段，則應維持保守的擁塞控制策略
- 若首次偵測到異常，應假設其為潛在災難的起點，轉為保守模式，直到圖像顯示這只是短暫的毛刺，才可恢復積極策略
- 持續關注指數圖像中出現的早期異常始終是正確的，關鍵在於如何做出反應
上述展示更像是一幅素描、甚至僅是輪廓，用來說明這套評價體系的基本工作原理。未來仍可引入更多指標，並透過 sigmoid 函數提取「陽性特徵」，圖像愈豐富、表現愈細緻，其指數圖像就愈接近真實，一如從素描走向油畫級的精緻程度。
在實際應用層面，這套評估體系可以部署於任何作為傳送導向的伺服器上，並以背景程式的形式持續執行。它會不斷蒐集傳輸流的資料來產生指數圖像，通訊協定則可隨時參考這些圖像，以獲得即時的決策指引。
舉例來說，可用阿里雲發布的 TCP 傳輸工具 [TCP-RT](https://www.alibabacloud.com/help/en/alinux/user-guide/tcp-rt-configurations)，取用其資料蒐集模組，透過背景程式主動拉取，或由通訊協定主動推送的方式獲取原始資料，便可即時產生指數圖像。
## 回顧 sigmoid 函數
sigmoid 函數是種極為實用的工具，能輸入的高低或大小變化，映射至固定且歸一化的數值區間，從而簡化並統一後續的分析流程。該特性與類神經網路中的「激勵」（activation) 機制相似：當輸入強度超過某個臨界值，輸出便迅速上升，對應為一種「陽性特徵」。
只有當某一特徵對應的所有 Sigmoid 輸出皆為陽性（邏輯上的 AND 關係）時，該特徵才能被整體判定為陽性，如持續擁塞、突發擁塞、隨機封包遺失等情境，皆可藉此準確識別。
這類具備相似特性的函數被統稱為「邏輯函數」，其中標準邏輯函數亦稱為 S 函數 (Sigmoid 即代表其「S 形」曲線)。Sigmoid 函數常以 $\sigma(x)$ 或 $\text{sig}(x)$ 表示，其圖像為一條平滑的 S 形曲線，如下圖中的綠線所示，而其導數則如圖中的粉紅線。
不過，稍早圖示所用的 Sigmoid 函數，其實伴隨著一系列參數的調整：
$$
f(x) = \frac{a}{1 + e^{bx}} + c
$$
也就是說，真正使用這類函數之前，必須先透過大量資料來校準參數 $a$, $b$, $c$，Sigmoid 函數的計算也涉及冪運算，在某些情境下實作困難，尤其是在 Linux 核心中，這類運算成本極高，即便採用泰勒展開近似，也仍屬於重計算。
事實上，我們真正需要的，只是某種「從 0 到某個上界 a 為定義域，輸出值域為 0 到 1 的遞增函數 $f(x)$」，且其遞增幅度 $g(x)$ 最好是 $f(x)$ 的導數。現成的替代方案早已存在，也就是機率密度函數（PDF）和累積分佈函數（CDF)。PDF 描述資料的分佈情況，不需要額外參數調整，而在電腦網路持續蒐集到的大量資料，可直接用來產生 PDF，隨後藉由透過積分取得 CDF，該 CDF 就可視為自訂化的 sigmoid 函數來運用。
這種做法的理論依據在於：既然大量資料來自於日常環境下的穩定蒐集，其分佈自然能代表未來局部時間段的趨勢。PDF 的產生過程本質上是一種擬合過程，而由此得到的預測模型，其精準性遠高於參數調整所得的 sigmoid 函數。
## 真實網路資料分佈實例
RTT (封包來回時間，Round-Trip Time) 主要與傳送路徑的實體距離有關，無論訊號是透過電還是光進行傳輸，其理論速度相近，若路徑條件一致，距離越遠，RTT 理應越大。但若網路路徑相同，RTT 卻出現差異，問題多半出在中途設備處理所產生的額外延遲，也就是封包被接收、處理再送出所耗費的時間。
藉由 [ping](https://man7.org/linux/man-pages/man8/ping.8.html) 或 [traceroute](https://man7.org/linux/man-pages/man8/traceroute.8.html) 等命令可測量 RTT，這些工具藉由傳送 ICMP 回應封包並計算往返時間，能大致反映網路延遲狀況。當封包目的地為路由器本身時，該封包需經由程序交換處理，即由處理器讀取並回應封包內容。然而，路由器設計的主要任務是轉發封包，回應 `ping` 僅屬於「盡力而為」(best effort) 的服務。
以下為實際範例，從 Router1 對 Router2 執行 `ping`：
```
Router1# ping 172.16.0.12
Sending 5, 100-byte ICMP Echos to 172.16.0.12:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
```
當在 Router2 上啟用大量運算操作後再次執行：
```
Router1# ping 172.16.0.12
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms
```
RTT 顯著上升，原因是 Router2 資源繁忙，降低回應 `ping` 的優先權。
相較之下，評估路由器效能更準確的方法是觀察「通過路由器」的實際流量。封包在此情境下會經過快速交換（fast switching），由高優先順序的處理機制完成。
舉例：從 Router1 `ping` Router3，封包需經過中間的 Router2：
```
Router1# ping 10.0.3.23
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
```
此時在 Router2 啟用高負載功能後再次測試：
```
Router1# ping 10.0.3.23
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
```
幾乎無明顯變化。這是因為通過型封包在 Router2 是藉由核心網路層級進行，不受使用層級程式所影響，效能相對穩定。由上可知，針對網路延遲的分析，需區分封包「目的地」與「轉發路徑」，才能得出正確結論。
> 延伸閱讀: [瞭解 Ping 和 Traceroute 命令](https://www.cisco.com/c/zh_tw/support/docs/ios-nx-os-software/ios-software-releases-121-mainline/12778-ping-traceroute.html)
電腦網路連線的平均 RTT 通常呈現常態分佈，電腦網路範圍越大，PDF 越矮胖。若要判定 RTT 是否構成陽性特徵，只需持續蒐集 RTT 資料，產生其 PDF，進而求得 CDF。這個 CDF 就能直接當作 sigmoid 函數使用。例如，當 RTT 超過 $\mu + 3\sigma$ 時，即可視為顯著陽性。
至於網路吞吐量，因為網路中通常存在多個頻寬各異的瓶頸，加上分散式路由的特性，其統計分佈往往呈現多峰，甚至是雙峰特徵。在這種情況下，可使用 CDF 作為指數圖像工具，並將超出最後一個主要峰值 $3\sigma$ 區間以外的吞吐量視為陽性特徵予以凸顯。
再來看 jitter（延遲時間抖動），這項指標對尾端延遲時間（[tail latency](https://en.wikipedia.org/wiki/Long-tail_traffic)，如 P99）有顯著影響。當平均延遲時間較小時，網路中的突發性通常較強，分佈形態更接近 [Pareto 分佈](https://en.wikipedia.org/wiki/Pareto_distribution)；反之，若延遲時間較高，則傾向於常態分佈，且分佈峰值會向右偏移。在這種情況下，可將 CDF 的 P90 作為判斷陽性特徵的閾值，超過此值即凸顯為陽性。
諸如此類的應用，皆可直接利用統計特徵，將原本繁瑣的參數調整過程自然地展現於資料的分佈之中，也就是說，參數調整實際上早已在 PDF 的產生過程中完成。
## 從數學函數到資料驅動
換個視角來看 PDF、CDF 與 Sigmoid 的關係：雖然 sigmoid 在數學上是一種常見的激勵函數，常用於神經網路中將輸入映射到 0 到 1 的區間，用以模擬「激勵」的過程；但 CDF 本身就是在描述一個隨機變數落在某個值以下的累積機率。當我們想知道「某事件是否值得注意」時，本質上就是在問：發生的機率是否已「超過某個臨界點」。
從這個角度來看，「激勵」、「陽性」這類判斷，其實就是在檢查某件事的出現是否已達成某種累積的臨界量，亦即從量變邁向質變。其過程本質上是種機率意義上的轉換。因此，sigmoid 函數的形狀與 CDF 極為相似並非巧合，而是源自它們在功能上的高度一致性：兩者皆可用來描述現象的演變。使用 CDF 作為自適應激勵函數，不僅保留 sigmoid 的數學性質，還可真實反映資料的統計特徵，避免過度依賴參數調整，從而提升系統在變化環境中的自我適應能力。該思維也體現從「建模」到「資料驅動」的分析轉向。
Sign in with Wallet
Connect another wallet