通過 Viavi MTS-5800TrueSpeed 進行的 RFC 6349 測試— 像客戶一樣體驗您的網絡

RFC 6349 是 Viavi 與來自 Bell Canada 和 Deutsche Telecom 的代表合作開發的一種新的傳輸控製 協議 (TCP) 吞吐量測試方法。RFC 6349 最近由互聯網工程任務 組 (IETF) 組織發布，提供了一種可 重複的 TCP 吞吐量分析測試方法，以及用於優化網絡和服務器性能的係統化流程、指標和準則。

本應用指南對“TCP 吞吐量測試框架”即 RFC 6349 進行了簡要說明，並且 重點描述了 TrueSpeed 這一自動化並且完全符合標準的 Viavi RFC 6349 的實現——TrueSpeed 現在可在 Viavi MTS-6000A 多服務應用程序模塊 (MSAM) 和 MTS-5800 手持式乐鱼开奖app 上提供。 本應用指南還討論了 TrueSpeed RFC 6349 與 ITU Y.1564 以太網服務激活 標準的集成。這一功能強大的測試組合提供了一種全麵的方法來確保在多 服務（例如三網融合）環境中實現最佳最終客戶體驗。

RFC 6349 TCP 測試方法 

RFC 6349 指定了一種用於在托管 IP 網絡中測量端對端 TCP 吞吐量的實 用方法，其目標是為了更好地展現用戶體驗情況。在 RFC 6349 框架中， 還指定了 TCP 和 IP 參數來優化 TCP 吞吐量。

RFC 6349 建議在 TCP 測試之前始終執行第 2/3 層開通測試。驗證位於第 2/3 層的網絡之後，RFC 6349 指定執行以下三個測試步驟。

● 路徑 MTU 檢測（依照 RFC 4821），用於驗證網絡最大傳輸單元 (MTU)， 並進行活動 TCP 段大小測試來確保 TCP 淨荷保持完整。

● 基準往返延遲和帶寬測試，預測最佳 TCP 窗口大小，用於自動計算 TCP BDP 。

● 單一和多個 TCP 連接吞吐量測試，用於驗證實現自動“滿管”TCP 測試的 TCP 窗口大小預測 以下各個小節提供了每個 RFC 6349 測試步驟的詳細信息。

路徑 MTU 發現（依照 RFC 4821） 

TCP 實現應使用依賴於互聯網控製消息協議 (ICMP)“需要分片”消息的 路徑 MTU 發現技術 (PMTUD) 來了解路徑 MTU。如果設備要發送的數 據包在 IP 頭中設置了不分片 (DF) 位，並且該數據包比下一個中繼段的 MTU 大，則會丟棄該數據包，且該設備會將一條 ICMP 需要分片消息發 回到最初發出該數據包的主機。ICMP 需要分片消息包括下一個中繼段的 MTU，PMTUD 使用該 MTU 來對自身進行調整。遺憾的是，由於許多網 絡管理員完全禁用了 ICMP，因此這一技術可能多少有些不可靠。

因此，RFC 6349 建議執行依照 RFC 4821 的分組層路徑 MTU 發現 (PLPMTUD) 來驗證網絡路徑 MTU，因為它可在有或者沒有 ICMP 的情 況下使用。PLPMTUD 指定使用實時 TCP 流量輪詢網絡來確定 MTU。 采用了與設置 IP 數據包 DF 位相同的技術，但由於它使用實時 TCP 會話，因此不依賴於 ICMP。該算法使用 TCP 重發條件來搜索 MTU， 用於避免在所有後續步驟中分片。

基準往返延遲和帶寬 

務必要確定基準往返時間 (RTT) 或非堵塞固有延遲以及端到端網絡的瓶 頸帶寬 (BB)，然後才能開始 TCP 測試。這些基準測量用於計算 BDP 和 估算 TCP 接收窗口 (RWND) 大小，並發送將在後續測試步驟中使用的套 接字緩衝區。

在廣域網 (WAN) 鏈路上，必須對 TCP 進行適當的配置，來調整發送方在 接收來自接收方的確認 (ACK) 之前可傳輸的字節數。這一“in-flight”字 節數通常稱為 TCP 窗口；盡管事實上存在若幹個工作中的 TCP 窗口機製。

圖 1 描繪了往返延遲 (RTD) 為 25 毫秒的 45 Mbps WAN 鏈路上的 TCP 傳 輸中數據字節數這一概念。

在圖 1 中，TCP 窗口的調優不適當，在請求 ACK 之前隻從發送方傳輸了 64 kB。

如 RFC 6349 所述，BDP 為最佳 TCP 窗口，計算方式為

在此示例中，BDP 將為 140 kB，是發送方 64 kB 窗口大小的兩倍多，並且 發送方將隻獲得大約 20 Mbps 的吞吐量。

RFC 6349 定義了以下機製用於測量 RTT：

● 第 2/3 層的活動流量生成，以及從一端到另一端的環回

● 數據包捕獲

● 網絡設備中的擴展管理信息庫 (MIB) (RFC 4898)

● ICMP ping

BDP 同時依賴於 RTT 和 BB，因此它還需要測量 BB。為運營網絡采用 的第 2/3 層測試（例如 RFC 2544）被指定為用於測量 BB 的一種方法。 知道了 RTT 和 BB 之後，RFC 6349 將能夠計算後續 TCP 吞吐量測試的 預期 TCP 性能。

單一和多個 TCP 連接吞吐量測試

決定是要采用單一還是多個 TCP 連接測試取決於與最終用戶環境中配置的 TCP RWND 相關的 BDP 大小。例如，長肥網絡 (LFN) 的 BDP 為 2 MB， 則使用多個連接測試此網絡路徑可能更加現實。假定是 64 kB 的典型主機 TCP RWND 大小（例如，Windows XP），則使用 32 個 TCP 連接將模擬 出小型辦公室場景。

盡管 RFC 6349 不要求測試多個連接，但作為最現實的方法，強烈建議進 行此測試來準確地驗證 TCP 吞吐量。RFC 6349 還定義了在 TCP 吞吐量測 試過程中要測量的特定指標，接下來將加以討論。

RFC 6349 指標

下麵介紹了 RFC 6349 TCP 指標，以及使用這些指標來診斷 TCP 性能不理 想原因的示例。

TCP 傳輸時間 

第一個 RFC 6349 TCP 指標是 TCP 傳輸時間，該指標僅測量跨同步 TCP 連接傳輸數據塊所花費的時間。理想的 TCP 傳輸時間來源於網絡路徑 BB 以及與網絡路徑關聯的各種第 1/2/3 層開銷，例如，通過 500 Mbps 以太 網服務在五個同步 TCP 連接上進行的 100 MB 批量傳輸，每個連接上傳 100 MB。每個連接在測試期間可能會獲得不同的吞吐量，因此確定總體 吞吐率並不總是很容易，特別是在連接數增加的情況下尤為如此。

更多信息，網盤下載文檔：

鏈接：https://pan.baidu.com/s/1CU6In3-auO5B9icyRDHX1g 

提取碼：5ojx