# 以延遲、並行與輸送量測量來規劃傳輸規模 | SwissOctet 深入解析 https://swissoctet.com/zh-tw/insights/size-throughput-with-bandwidth-delay/ SwissOctet / 深入解析 / 網路工程 網路工程 進階 · 4 分鐘閱讀 以延遲、並行與輸送量測量來估算傳輸規模 使用酬載容量、交付時段與往返時間建立可重複的傳輸模型，然後進行測試，而不將連接埠標籤與有用的輸送量混為一談。 由 SwissOctet 編輯部撰寫 儲存指南 複製連結 本頁內容 01 將交付時窗轉換為速率 02 將埠容量與有效輸送量分開看待 03 了解來回時間為何重要 04 建立受控的測試矩陣 05 測試期間查看兩端端點 06 以真實的酬載測試應用程式 07 使用結果來選擇設定 您的實用檢查清單 來源與延伸閱讀 返回資料庫 直接答案 計算交付時窗所需的有效傳輸速率，然後測量完整路徑。埠容量、來回時間、TCP 行為、儲存與應用程式處理都會影響結果。在選擇網路層級之前，請使用具真實並行度的受控測試，並透過實際應用程式重複執行。 01 將交付時窗轉換為速率 從有效應用程式資料量與可交付時間開始。使用十進位單位，在兩小時內傳輸 2 TB 需要約每秒 278 MB 的酬載，或 2.22 Gbps，這還未計入協定額外負擔與中斷。此算術是規劃範例，不是實測的服務結果。 納入會重疊的傳輸。排定的匯出、客戶下載與備份上傳即使每月總量看起來不大，也可能共用資源。撰寫尖峰時段模型，而不只是月平均值。指明哪個方向重要，以及失敗的傳輸必須重新開始還是可以續傳；該行為會影響系統執行的工作量。 02 將埠容量與有效輸送量分開看待 伺服器埠描述的是連結容量。有效輸送量描述的是應用程式在觀察區間內交付的資料。加密、協定框架、重傳、儲存活動與接收端的工作都會佔用該路徑的一部分。因此，列出 10 Gbps 埠並不代表應用程式會持續交付 10 Gbps 的酬載。 IETF RFC 6349 特別區分了測試網路路徑與檢視 TCP 效能。在你的診斷中也採用這種區分。先確認端點與路由是否適當，再調查傳輸與應用程式。增加購買的埠並不能修正寫入資料緩慢的接收端，或一次只處理一個請求的應用程式。 03 了解來回時間為何重要 TCP 控制確認返回之前可有多少資料在傳輸中。頻寬延遲乘積提供了有用的尺度：速率乘以來回時間。一個假設的 10 Gbps 路徑若有 40 毫秒的來回延遲，代表約有 50 MB 在傳輸中。這項計算說明了為何延遲與傳輸行為屬於高速規劃的一部分。 這個結果並不是要你套用任意的 socket 設定。作業系統、壅塞控制、協商視窗與實際路徑都會影響行為。在調校前，請查閱目前的軟體文件並檢視測量結果。更多平行連線在某些情況下可能改善總輸送量，但也可能掩蓋應用程式所依賴的個別傳輸行為。 04 建立受控的測試矩陣 只使用你擁有或獲授權測試的端點。約定測試時窗與速率，以免這項作業干擾正常服務。iperf3 等工具提供可設定的方向、持續時間與平行串流；官方文件定義了這些控制項。將版本、端點、路由情境與設定連同結果一併記錄，讓其他操作人員可以重現。 從單一流程開始，然後加入具代表性的並行度。如果應用程式同時依賴兩個方向，請執行雙向測試。這個示例矩陣分開了單一總體結果會混在一起的不同問題。當原始結果會揭露內部位址或營運細節時，請私下保留，只發布決策所需的測量結果。 測試 所調查的內容 它無法證明的事 單一傳輸流程 單一流程路徑行為 總體應用程式交付 多個平行流程 並行度與總量限制 單一客戶的傳輸速率 應用程式傳輸 儲存、協定與軟體共同作用 每個資料集的效能 尖峰時段重複測試 真實活動下的變異 永久的輸送量保證 05 測試期間查看兩端端點 在兩端記錄 CPU 使用量、記憶體壓力、儲存活動與錯誤計數器。沒有端點觀察的傳輸結果可能讓真正的瓶頸隱形。檢查是否有一個處理程序或 CPU 已飽和，而其他仍閒置。避免一次變更多項設定，因為那會難以辨識哪項調整有幫助。 將記憶體支撐的測試與實際讀寫資料的測試分開。前者有助於調查傳輸路徑；後者更能反映應用程式的工作。如果結果差異很大，請檢查儲存與處理，而不是將記憶體支撐的數字當成交付承諾。當範圍明確時，兩項測量都可能有用。 06 以真實的酬載測試應用程式 HTTP 匯出、加密複寫串流與檔案傳輸工作階段有不同的處理模式。使用具代表性的檔案大小、請求速率與加密設定。當使用者等待該步驟時，將傳送第一個位元組之前準備資料所花費的時間納入。區分首次回應延遲與完成時間，而不是將其一當成另一者來報告。 在足夠多的區間重複測試以觀察變異，並在變更設定前保留基準。對於假設的 2 TB 匯出，將實際完成時間與兩小時時窗比較，並為中斷保留餘裕。針對觀察到的瓶頸選擇改善措施，而不是無理由地倍增埠容量。 07 使用結果來選擇設定 有用的輸出是附有證據的資源需求：測得的酬載速率、可接受的完成時間、預期並行度與已知的限制階段。將 SwissOctet 網路方案與該需求比較，包括流量額度以及 CPU 與儲存規格。單靠位置並不能決定到每個接收端的路由或端對端延遲。 部署後保留測試程序。當資料集成長、軟體變更或使用者移至不同網路時重複使用它。可重複的基準能讓效能事件更容易診斷，並為變更設定提供比單獨的速度測試或廣告中的最大值更可靠的依據。 付諸行動 您的實用檢查清單。 ✓ 從資料量與期限計算酬載速率。 ✓ 為重疊的傳輸與方向建立模型。 ✓ 約定獲授權的測試端點與限制。 ✓ 比較單一流程、並行度與應用程式測試。 ✓ 測試時觀察兩端端點。 ✓ 保留可重複的基準與有用的餘裕。 下載檢查清單 常見問題 重要細節。 更大的 TCP 視窗一定能修正緩慢的傳輸嗎？ + 不能。請先診斷路徑與端點。儲存、CPU、遺失與應用程式行為可能主導結果，而傳輸調校必須適合實際系統。 為什麼要測試單一流程與多個流程？ + 它們回答不同的問題。總容量可能高於單一傳輸的速率；應用程式的並行度決定哪個結果重要。 我可以對任何公開伺服器執行容量測試嗎？ + 請使用你控制或獲准測試的端點。約定持續時間、速率與時機，以免測量干擾無關的服務。 主要參考資料 前往來源。 這些參考資料支持本指南中的技術概念。在變更生產系統之前，請遵循最新文件。 IETF RFC 6349：TCP 輸送量測試框架 datatracker.ietf.org ESnet：呼叫 iperf3 software.es.net 由 SwissOctet 提供的編輯指引。範例僅供說明。服務規格、可用選項與合約條件必須另行驗證。 連結知識 相關基礎架構。 Metal Atlas 瑞士 Transit 40 瑞士 Transit 100 瑞士 保持脈絡 您的下一份實地筆記。 探索所有指南 實地筆記 / 01 + 專屬與 GPU 基礎 VPS 或專屬：選擇合適的界線 了解實體機器改變了什麼、沒有改變什麼，以及它何時成為您工作負載的有用一步。 4 分鐘閱讀 閱讀指南 實地筆記 / 02 + 網路工程 基礎 頻寬、連接埠速度與傳輸：閱讀完整說明 估算您專案傳輸的資料量，並了解為何更大的連接埠只是網路效能的一部分。 4 分鐘閱讀 閱讀指南 實地筆記 / 03 + 網路工程 進階 將 40、100 或 200 Gbps 來源規劃為完整系統 在選擇高容量散布配置之前，將大型連接埠等級轉化為儲存、CPU、並行與營運問題。 4 分鐘閱讀 閱讀指南