評估單個 TCP 流的真實效能上限
網絡延遲頻寬計算器是一款免費的線上工具，專門用於根據網絡路徑的實際狀況，計算單個 TCP 流在現實環境中的效能上限。使用者只需輸入鏈路速率、往返時間（RTT）以及傳輸數據大小，即可即時識別出限制連線速度的關鍵瓶頸，並檢視預期的 TCP 吞吐量與總傳輸時間估算。
本工具完全在你的瀏覽器中進行本地計算，你輸入的每個數值都會在此瀏覽器中進行計算 —— 不會發送至任何地方。
輸入參數與配置說明
要準確模擬網絡路徑與傳輸表現，你需要配置以下輸入參數：
- 鏈路速率：路徑上最慢的一站 —— 通常是你的服務計劃標稱速度。此數值必須大於零。
- 往返時間 (RTT)：到遠端的 Ping 時間 —— 請使用你在負載下預期的最大值。此數值必須大於零。
- 數據大小：要傳輸的負載 —— 檔案、備份或數據集。此數值必須大於零。
- 接收視窗：接收端可緩衝的位元組數。此數值必須大於零，且不能超過 1,073,725,440 位元組。留空則表示無視窗限制。
- MSS (位元組)：每個封包的負載位元組 —— 1,460 可填滿標準乙太網路訊框。此數值必須是介乎 1 至 65,495 位元組之間的整數。留空則會忽略協定開銷與遺失。
- 封包遺失 (%)：平均封包遺失概率。數值必須介乎 0% 至 100% 之間。留空或輸入 0 表示無遺失限制。
- 顯示小數位數：控制輸出結果的十進制精確度。
介面同時提供載入範例按鈕以快速填入範例數據，以及清空按鈕以重設所有輸入欄位。
輸出結果與動態系統提示
計算完成後，工具會在三個主要區塊中呈現詳細分析：
吞吐量與傳輸時間
- 預期 TCP 吞吐量：顯示預估的實際吞吐量，並附帶子標籤說明當前的瓶頸來源：「受限於
‹constraint›」，其中的限制因素會動態顯示為鏈路容量、接收視窗或封包遺失。 - 傳輸時間
- 到首個位元組的時間 (1 RTT)
- 大容量傳輸時間
- 頻寬時延乘積
- 填滿路徑所需視窗
- 受視窗限制的吞吐量
- 受遺失限制的吞吐量 (Mathis)
- 扣除開銷後的鏈路上限
- 協定效率
動態系統提示訊息
根據輸入的數值組合，系統會顯示相應的技術提示：
- 「填滿此路徑需要
‹window›的視窗 —— 已超出 65,535 位元組的未縮放最大值，因此兩端必須協商 TCP 視窗縮放 (RFC 7323)。」 - 「填滿此路徑需要
‹window›—— 已超出 TCP 可協商的最大視窗（1,073,725,440 位元組）。此路徑上的單個流永遠無法超過‹value›。」 - 「將接收視窗提高到
‹window›可讓此傳輸達到高達‹value›。」 - 「遺失率高於 1% 已超出 Mathis 模型的可靠範圍 —— 請將此遺失上限視為樂觀估計。」
公式與數值代入步驟
工具會完整展示計算過程中的數學公式與代入數值：
- 核心公式：
吞吐量 = min(速率 × 效率, 視窗 ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = 速率 × RTT - 協定效率：
協定效率 = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff›（40 B 封包標頭 + 38 B 實體線路開銷） - 鏈路上限：
鏈路上限 = 速率 × 效率 = ‹rate› × ‹eff› = ‹value› - BDP：
BDP = 速率 × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes› - 填滿路徑所需視窗：
填滿路徑所需視窗 = BDP ÷ 8 = ‹bdp› → ‹window› - 視窗上限：
視窗上限 = 視窗 ÷ RTT = ‹window› ÷ ‹rtt› = ‹value› - 遺失上限 (Mathis)：
遺失上限 (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value› - 預期吞吐量：
預期吞吐量 = 以下上限的最低值 = ‹value› → 受限於 ‹constraint› - 傳輸時間：
傳輸時間 = RTT + 8 × 大小 ÷ 吞吐量 = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›
使用者可點擊複製結果按鈕，將上述所有計算數據複製至剪貼簿。
網絡模型規則與邊界條件
為了確保計算結果符合網絡工程實務，本工具遵循以下規則與限制：
- 十進制單位慣例：所有單位均採用十進制計算（例如 1 kbit = 1,000 位元，1 MB = 1,000,000 位元組）。然而，作業系統與檔案管理器通常使用以 1024 為底數的二進制單位（例如 100 MB 檔案實際上是 100 MiB，約等於 104.86 十進制 MB），這會導致實際傳輸時間比純十進制估算稍長。
- 協定開銷模型：以標準乙太網路為基準，每個封包加入 78 位元組的開銷（包含 40 位元組的 TCP/IP 標頭，以及 38 位元組的實體線路開銷）。
- Mathis 遺失模型限制：Mathis 公式假設封包遺失是均勻分佈且相互獨立的。此模型僅在遺失率低於約 1% 時才可靠。若遺失率超過 1%，工具會發出 警告，此時計算出的遺失上限應視為偏向樂觀的估算。
- TCP 視窗縮放限制：未啟用縮放的 TCP 視窗最大值為 65,535 位元組。若填滿路徑所需的視窗超過此值，必須透過 RFC 7323 協商視窗縮放。依據 RFC 7323，TCP 可協商的最大視窗上限為 1,073,725,440 位元組。
- 排除的現實因素：本模型僅針對穩態下的單個 TCP 流進行計算。實際網絡傳輸中的 TCP 慢啟動、擁塞控制動態調整、接收端處理延遲以及 TLS 握手等因素均不在計算範圍內，因此實際傳輸開始時的速度會較慢，整體表現亦可能低於理論上限。
錯誤訊息與輸入驗證
當輸入數據不符合規範時，系統會顯示相應的錯誤提示：
- 輸入無法解析：
"‹field›：「‹token›」不是數字。" - 鏈路速率非正數：
"鏈路速率必須大於零。" - 往返時間非正數：
"往返時間必須大於零。" - 數據大小非正數：
"數據大小必須大於零。" - 接收視窗非正數：
"接收視窗必須大於零。" - 接收視窗超出 RFC 7323 上限：
"TCP 無法協商超過 1,073,725,440 位元組的視窗（RFC 7323 視窗縮放）。" - MSS 超出範圍：
"MSS 必須是介乎 1 至 65,495 位元組之間的整數。" - 封包遺失率超出範圍：
"遺失率必須介乎 0% 至 100% 之間。" - 計算數值溢位：
"數值或中間計算結果超出支援的數字範圍。"
常見問題解答
什麼是頻寬時延乘積？為什麼它會決定視窗大小？
BDP（頻寬時延乘積，即鏈路速率 × 往返時間）是指在任何給定時刻傳輸中的數據量。TCP 最多只能有一個未確認的視窗在傳輸，因此小於 BDP 的視窗會讓管道處於半空狀態：在 100 Mbit/s 速率和 50 ms RTT 下，管道可容納 625 kB，而一個 65,535 位元組的視窗僅能填滿其十分之一。這就是為什麼快速且長途的路徑需要 TCP 視窗縮放 (RFC 7323)，它將可協商的最大值從 65,535 位元組提高到約 1 GB。
為什麼我的傳輸速度慢過我付費訂閱的鏈路速率？
單個 TCP 流面臨三個獨立的上限，並以最低者為準。協定開銷會將鏈路本身削減約 5% —— 標準乙太網路訊框在線路上的 1,538 位元組中攜帶 1,460 位元組的負載。接收視窗將吞吐量限制在「視窗 ÷ RTT」，因此無論鏈路有多快，經典的 65,535 位元組視窗都會將 50 ms 路徑限制在約 10.5 Mbit/s。而封包遺失則將其限制在 (MSS ÷ RTT) ÷ √遺失率。上方的計算結果會指出哪一個上限正在限制你的數據。
封包遺失是如何限制 TCP 吞吐量的？
TCP 將遺失視為網絡擁塞，並在每次發生遺失事件時將其發送速率減半，因此即使是極微小的遺失率，在快速路徑上也會產生重大影響。Mathis 模型估算的上限為 (MSS ÷ RTT) ÷ √p —— 在 50 ms 路徑、1,460 位元組 MSS 且有 0.01% 遺失的情況下，不論鏈路速度如何，上限約為 23 Mbit/s。該模型假設遺失事件均勻分佈且相互獨立；在遺失率低於約 1% 時，它能很好地反映現實，而對於突發性遺失，其估算則偏向樂觀。
這裡的 MB 與我檔案管理器中的 MB 相同嗎？
不完全相同。本頁面使用網絡界慣用的十進制單位：1 kbit = 1,000 位元，1 MB = 1,000,000 位元組。大多數檔案管理器使用以 1024 為底數的單位，且經常被誤標為 MB —— 當中的「100 MB」檔案通常是 100 MiB ≈ 104.86 十進制 MB，因此傳輸所需的時間會比十進制數值顯示的長約 5%。在此輸入 104.86 MB 即可完全對應。