RFC 6349 是 Viavi 與來自 Bell Canada 和 Deutsche Telecom 的代表合作開發(fā)的一種新的傳輸控制 協(xié)議 (TCP) 吞吐量測試方法。RFC 6349 最近由互聯(lián)網(wǎng)工程任務(wù) 組 (IETF) 組織發(fā)布，提供了一種可 重復(fù)的 TCP 吞吐量分析測試方法，以及用于優(yōu)化網(wǎng)絡(luò)和服務(wù)器性能的系統(tǒng)化流程、指標和準則。

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

RFC 6349 TCP 測試方法 

RFC 6349 指定了一種用于在托管 IP 網(wǎng)絡(luò)中測量端對端 TCP 吞吐量的實 用方法，其目標是為了更好地展現(xiàn)用戶體驗情況。在 RFC 6349 框架中， 還指定了 TCP 和 IP 參數(shù)來優(yōu)化 TCP 吞吐量。

RFC 6349 建議在 TCP 測試之前始終執(zhí)行第 2/3 層開通測試。驗證位于第 2/3 層的網(wǎng)絡(luò)之后，RFC 6349 指定執(zhí)行以下三個測試步驟。

● 路徑 MTU 檢測（依照 RFC 4821），用于驗證網(wǎng)絡(luò)最大傳輸單元 (MTU)， 并進行活動 TCP 段大小測試來確保 TCP 凈荷保持完整。

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

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

路徑 MTU 發(fā)現(xiàn)（依照 RFC 4821） 

TCP 實現(xiàn)應(yīng)使用依賴于互聯(lián)網(wǎng)控制消息協(xié)議 (ICMP)“需要分片”消息的 路徑 MTU 發(fā)現(xiàn)技術(shù) (PMTUD) 來了解路徑 MTU。如果設(shè)備要發(fā)送的數(shù) 據(jù)包在 IP 頭中設(shè)置了不分片 (DF) 位，并且該數(shù)據(jù)包比下一個中繼段的 MTU 大，則會丟棄該數(shù)據(jù)包，且該設(shè)備會將一條 ICMP 需要分片消息發(fā) 回到最初發(fā)出該數(shù)據(jù)包的主機。ICMP 需要分片消息包括下一個中繼段的 MTU，PMTUD 使用該 MTU 來對自身進行調(diào)整。遺憾的是，由于許多網(wǎng) 絡(luò)管理員完全禁用了 ICMP，因此這一技術(shù)可能多少有些不可靠。

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

基準往返延遲和帶寬 

務(wù)必要確定基準往返時間 (RTT) 或非堵塞固有延遲以及端到端網(wǎng)絡(luò)的瓶 頸帶寬 (BB)，然后才能開始 TCP 測試。這些基準測量用于計算 BDP 和 估算 TCP 接收窗口 (RWND) 大小，并發(fā)送將在后續(xù)測試步驟中使用的套 接字緩沖區(qū)。

在廣域網(wǎng) (WAN) 鏈路上，必須對 TCP 進行適當(dāng)?shù)呐渲茫瑏碚{(diào)整發(fā)送方在 接收來自接收方的確認 (ACK) 之前可傳輸?shù)淖止?jié)數(shù)。這一“in-flight”字 節(jié)數(shù)通常稱為 TCP 窗口；盡管事實上存在若干個工作中的 TCP 窗口機制。

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

在圖 1 中，TCP 窗口的調(diào)優(yōu)不適當(dāng)，在請求 ACK 之前只從發(fā)送方傳輸了 64 kB。

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

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

RFC 6349 定義了以下機制用于測量 RTT：

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

● 數(shù)據(jù)包捕獲

● 網(wǎng)絡(luò)設(shè)備中的擴展管理信息庫 (MIB) (RFC 4898)

● ICMP ping

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

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

決定是要采用單一還是多個 TCP 連接測試取決于與最終用戶環(huán)境中配置的 TCP RWND 相關(guān)的 BDP 大小。例如，長肥網(wǎng)絡(luò) (LFN) 的 BDP 為 2 MB， 則使用多個連接測試此網(wǎng)絡(luò)路徑可能更加現(xiàn)實。假定是 64 kB 的典型主機 TCP RWND 大?。ɡ纾琖indows XP），則使用 32 個 TCP 連接將模擬 出小型辦公室場景。

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

RFC 6349 指標

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

TCP 傳輸時間 

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

更多信息，網(wǎng)盤下載文檔：

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

提取碼：5ojx