如何診斷 Linux 網路效能問題

如何診斷 Linux 網路效能問題

在日常的系統管理工作中，網路延遲（Latency）或頻寬飽和往往是最難捉摸的「鬼影」問題。當應用反應變慢，是 DNS 解析的問題？還是底層網路驅動程式的瓶頸？對於中階 Linux 使用者而言，建立一套標準化的診斷流程至關重要。本文將帶領您使用 Ubuntu 22.04 / Debian 12 上通用的工具，由淺入深地剖析網路效能。

第一階段：連線品質與延遲測試

診斷的第一步是確認基礎連線的穩定性。我們需要區分「延遲」與「頻寬」兩個概念。延遲影響即時互動體驗，而頻寬影響大檔案傳輸速度。

1. 使用 ping 檢查基礎延遲與丟包

最基礎的工具莫過於 ping，它能測試主機與目標之間來回的時間（RTT）。

# 發送 10 個封包，每個封包間隔 1 秒，並顯示統計資訊
ping -c 10 -i 1 example.com

觀察輸出結果中的 rtt min/avg/max/mdev 行。如果 avg 值遠高於預期（例如在本地網路應小於 1ms，卻高達 50ms），或出現 packet loss（封包丟失），則代表網路基礎層面存在問題。

2. 使用 mtr 進行路徑追蹤

ping 只能看到起點到終點的平均值，無法知道是哪一跳路由器出了問題。mtr 結合了 traceroute 和 ping 的功能，能動態顯示路徑上每一跳的延遲與丟包率。

# 安裝 mtr (若尚未安裝)
sudo apt update && sudo apt install mtr -y

# 追蹤到 example.com 的路徑，持續監控 30 秒後自動結束
mtr -r -c 30 example.com

在輸出報表中，關注 Loss% 欄位。如果中間某跳的 Loss% 顯著高於 0%，且後續跳數也受影響，問題很可能出在那台設備或該鏈路上。

第二階段：頻寬與流量分析

當延遲正常但傳輸速度慢時，需要檢查頻寬佔用情況。

1. 使用 iptraf-ng 監控即時流量

iptraf-ng 是一個互動式的網路統計工具，適合快速查看哪個介面卡（Interface）流量最大。

sudo apt install iptraf-ng -y
sudo iptraf-ng

在介面上選擇對應的網路介面（如 eth0 或 ens18），即可看到即時的上傳/下載速率（Bytes/sec）。若頻寬已達 100% 飽和，則需檢查是否有異常進程在佔用頻寬。

2. 使用 ss 檢查 TCP 連線狀態

有時頻寬未飽和，但大量連線處於 TIME_WAIT 或 SYN_RECV 狀態，會導致新連線無法建立或變慢。

# 查看所有 TCP 連線狀態的數量統計
ss -s

# 查看特定端口（如 80）的連線狀態
ss -tlnp | grep :80

若發現大量 TIME_WAIT，可能表示系統短時連線過多，需調整核心參數（後續常見問題會提及）。

第三階段：核心網路指標調優

Linux 核心提供了一系列透過 /proc 檔案系統暴露的網路指標，是診斷進階問題的关键。

1. 檢查網路佇列與錯誤計數器

網路介面卡（NIC）的驅動程式會記錄錯誤計數，這能幫助判斷是否為硬體或驅動問題。

# 查看 eth0 的錯誤計數
cat /sys/class/net/eth0/statistics/errors
cat /sys/class/net/eth0/statistics/dropped

若 errors 或 dropped 數值持續增長，通常代表硬體故障、驅動程式相容性問題，或 MTU 設定不匹配。

2. 調整 TCP 緩衝區大小

對於高頻寬、高延遲（High-Bandwidth Delay Product, HDP）的網路環境，預設的 TCP 緩衝區可能不足，導致頻寬無法跑滿。

# 查看目前的 TCP 緩衝區限制
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

若發現頻寬無法跑滿，可嘗試臨時調整（需 root 權限）：

sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

常見問題與解決方案

Q1：頻寬未飽和，但 TCP 吞吐量極低，如何判斷是否為 TCP Window Scaling 問題？

若使用 ss -ti 查看連線詳情，發現 rcv_space（接收視窗）始終很小（如 87380 字节），且 ssthresh 未增加，可能是 TCP Window Scaling 未啟用。檢查 /proc/sys/net/ipv4/tcp_window_scaling 是否為 1。若為 0，請改為 1 並重新測試。

Q2：mtr 顯示中間節點丟包，但終端機連線正常，該如何解釋？

這通常是由於中間路由器（Router）的 QoS（品質服務）設定所致。許多路由器對 ICMP 封包（ping/mtr 使用）優先級低於 TCP/UDP 資料封包。因此，即使 ICMP 丟包，實際應用（如 HTTP、SSH）仍可能正常運作。此時應以實際應用測試為準，而非過度依賴 ICMP 診斷結果。

小結

診斷 Linux 網路效能並非單一工具的任務，而是需要結合 ping、mtr、ss 與核心指標的多維度分析。建議在日常維護中，先建立基準線（Baseline），當問題發生時，對照異常指標才能快速定位。記住，網路問題往往具有時效性，建議定期使用腳本記錄關鍵指標，以便在故障發生時擁有歷史數據可供比對。