您的 ITS 網路支援影片的最佳頻寬是多少？

當我們聽到影片頻寬時，通常會以每秒兆位元（Megabits per second）來表示。然而，如果不準確理解這種頻寬表達方式，可能會引起問題。它會產生一種錯覺，認為在任何時刻，頻寬都是相同的（即數據和速度在整個時間間隔內均勻分佈）。但正如任何好的封包捕捉軟體所顯示的那樣，這在現實情況中並非如此。每秒兆位元這種表達方式僅提供了一個非常粗略且 平均 的頻寬指標，僅限於整秒的時間間隔，但並未提供關於頻寬在整秒內如何分佈的詳細訊息。這些訊息將幫助您了解何時以及如何在網路上開始發生封包丟失。

一般來說，如果我們想知道頻寬在給定時間段內是否真正均勻分佈，我們需要在指定的時間間隔內更仔細地觀察較短時間段內的流量。以下訊息記錄了數據在網路上實際移動的方式，以及平均頻寬表示如何可能誤導數據在網路上的移動方式。

■ 理想資料頻寬需求與實際資料頻寬需求

假設我們有一個"理想"的網路，運行速度為 100 Mbps。在下表中，每個綠色高亮的單元格表示在這個網路上一秒鐘內發送的影片流量。我們通常會描述這組影片流量在這一秒鐘內的傳輸速度為 50 Mbps，這被稱為平均頻寬或數據速度。

讓我們看看當間隔變短時，數據在我們的"理想"網路中如何移動。同樣，我們假設影片流量在整個間隔內均勻分佈。

下表顯示了與上圖相同的流量，但時間間隔縮短為十分之一秒（0.1 秒），而不是一秒。重要的是要注意，影片流量的數據速度在每個十分之一秒的時間間隔內保持在 50 Mbps。這被稱為真正的恆定比特率（True Constant Bit Rate），不要與稍後討論的影片壓縮標準的恆定比特率編碼混淆，因為數據在整個時間間隔內均勻分佈，使得在較短時間間隔內測量的數據速度與在較長的原始時間間隔內測量的數據速度相同。

下表讓我們更接近展示數據實際移動的方式。與其在整個時間間隔內均勻地發送影片數據，下表顯示了在不同的較短時間間隔內以 100 Mbps 發送的影片數據，在 5 個不同的十分之一秒（0.1 秒）間隔內發送。注意，數據速度現在在不同的十分之一秒間隔內在 100 Mbps 和 0 Mbps 之間交替變化。這被稱為突發頻寬（bursty bandwidth），因為數據不再在整個時間間隔內均勻分佈，並且在較短時間間隔內測量的數據速度比在較長的原始時間間隔內測量的數據速度更快。

上述示例僅用於說明目的。實際上，我們應該使用比十分之一秒更精細的時間間隔，以捕捉任何流量的突發性。如果上述示例是真實情況，由於線速為 100 Mbps，我們將使用百分之一秒的更精細時間間隔，而不是十分之一秒的時間間隔。

■ 所有流量往往都是突發性的

所有流量都是突發性的，通過觀察不同時間間隔內的數據，我們可以開始看到突發現象。下圖是從封包分析器中獲取的 100 Mbps 網路上的 Ping 流量的圖形分析。Ping 流量攜帶了 10 KB 的緩衝數據。如圖所示，以正常的一秒為時間間隔，Ping 流量顯示為 160 Kbps（0.16 Mbps）的平均數據速度。這是準確的，因為 20 KB 的往返 Ping 數據產生了 13.5 個全尺寸的以太網封包（13.5 * 12304 位元 = 160,104 位元，或 0.16 兆位元）。

然而，如下圖所示，如果我們只看前一圖中第一個完整秒時間間隔內的 0.16 兆位元的 Ping 數據，但使用十分之一秒（0.1 秒）的較小時間間隔，我們會看到相同的 0.16 兆位元的 Ping 數據在兩個不同的十分之一秒時間間隔內以 800 Kbps（0.8 Mbps）的速度發送（第 1 和第 3 個時間間隔，一個是 Ping 請求，另一個是回應），每個時間間隔內有 0.08 兆位元的突發數據。因此，我們可以看到 Ping 數據開始顯得相當突發。

由於線速為 100 Mbps，為了真正表徵 Ping 流量的突發性，我們必須進一步縮短到百分之一秒（0.01 秒）的時間間隔。如圖所示，在百分之一秒（0.01 秒）的時間間隔內，相同的 0.16 兆位元的 Ping 數據現在顯示在兩個不同的百分之一秒時間間隔內以 8 Mbps 的速度發送（第 1 和第 26 個時間間隔，一個是 Ping 請求，另一個是回應），每個時間間隔內有相同的 0.08 兆位元的突發數據。

最後兩個圖表之間突發速度增加的原因是，由於其中一個圖表中使用的十分之一秒時間間隔對於測量這兩個微突發來說過於粗糙。通過使用百分之一秒的更精細時間間隔，上述圖表能夠測量這兩個微突發的真正突發性。

■ 影片流量本質上是突發性的設計

影片流量的突發性與普通流量不同，這是由於一種稱為時間壓縮（Temporal Compression）的技術。這種技術使用運動預測來創建兩種類型的影片幀：關鍵幀和增量幀。關鍵幀包含形成完整圖片所需的所有圖片訊息。而增量幀則僅包含部分圖片訊息，不足以形成完整圖片，它將依賴於前一個關鍵幀來填補空白以形成完整圖片。任何時間壓縮的影片流量將由關鍵幀封包和增量幀封包的組合構成，其中大部分是增量幀封包。這意味著影片流量本質上是突發性的，週期性的突發來自關鍵幀封包。

下圖是從封包分析器中獲取的顯示來自 100 Mbps 網路上的 10 百萬像素監視器的捕獲影片封包。我們將查看圖中第 25 個時間間隔附近的影片數據，並在整個討論過程中將其作為參考。如圖所示，以正常的一秒為時間間隔，第 25 個時間間隔內的影片流量顯示為 5 Mbps 的平均數據速度。

如果我們使用十分之一秒（0.1 秒）的時間間隔來查看相同的影片數據，而不是正常的一秒時間間隔，我們會看到影片數據現在顯示為以 8 Mbps 的速度發送。

由於線速為 100 Mbps，最佳做法是使用百分之一秒（0.01 秒）作為時間間隔來表徵突發性。如圖所示，在百分之一秒（0.01 秒）的時間間隔內，這些影片數據的真正突發速度顯示為 25 Mbps。

上述影片的例子是影片流量異常的一個典型特徵。一般來說，影片流量的突發速度通常是所報平均影片頻寬的 5 到 6 倍。

■ 影片頻寬的迷思

一開始，我們討論了影片頻寬是以每秒兆位元（Megabits per second）來表示的，這種表達方式可能會引起問題，因為它給我們一種錯覺，認為可以根據所報的數據速度來構建和設計影片網路。下面的兩個例子將說明這一點，使用兩台監視器而不是一台。

假設我們的網路運行速度為 100 Mbps，每台監視器可以產生 50 Mbps 的影片數據。我們進一步假設兩台監視器都可以以真正的恆定比特率（True Constant Bit Rate）輸出影片數據。下表顯示了兩台監視器合併後的影片流量形狀，使用十分之一秒（0.1 秒）的時間間隔。每台監視器的影片數據用不同顏色的單元格表示。僅作為說明用途，這種情況不應在網路上引起任何問題。

現在假設每台監視器不是以 50 Mbps 的真正恆定比特率（True Constant Bit Rate）輸出影片數據，而是以 100 Mbps 的速度在 5 個不同的十分之一秒時間間隔內輸出突發影片數據。下表顯示了這種情況下可能的流量模式。同樣，每台監視器的影片數據用不同顏色的單元格表示。當然，這個表假設兩台監視器不會同時輸出它們的突發數據，而是在不同的時間間隔內進行。如果確實如此，那麼這個網路上也不應該有任何問題。然而，現實中，我們無法控制監視器何時輸出其數據。雖然我們無法在同一表格中說明這一點，但如果兩台監視器在任何時候同時開始輸出數據，那麼網路將立即在那一刻經歷流量擁堵，並因此遭受影片丟失。其原因僅僅是因為網路在任何十分之一秒（0.1 秒）間隔內最多只能接受 10 Mb 的數據（100 Mbps * 0.1 秒 = 10 Mb），而如果兩台監視器在同一十分之一秒間隔內輸出數據，則該時間間隔內的網路總數據量將達到 20 Mb。

下圖完美地展示了這一點，使用的是一個真實的場景。圖中捕獲的數據是來自 100 Mbps 網路上多台監視器的實時影片數據。當時，該網路經歷了週期性的影片丟失。如圖所示，以正常的一秒為時間間隔，所有數據顯示為以約 45 Mbps 的平均數據速度發送。從這樣一個高層次的圖表中，我們無法發現影片丟失的原因。

由於線速為 100 Mbps，我們將使用百分之一秒（0.01 秒）的時間間隔來進一步檢查影片流量。如圖所示，我們現在可以看到許多以極高數據速度發送的影片數據突發（有些接近 100 Mbps）。這很可能是影片丟失的原因。

■ 總結

影片流量本質上總是突發性的。我們應該始終記住這一事實，並在設計網路或實施應用時考慮到這一點。這裡的經驗法則是，每當我們聽到影片頻寬以每秒兆位元（Megabits per second）為單位報告時，將這個平均影片頻寬乘以 5 或 6，轉換為其真正的突發頻寬，然後根據突發頻寬進行設計。

在嘗試避免由影片突發引起的網路擁堵問題時，有一些替代方案。例如，您可以嘗試找到一台使用流量整形機制的監視器，以平滑影片輸出，達到真正的恆定比特率（True Constant Bit Rate）。然而，您必須確保監視器確實實施了流量整形機制。有些監視器報告具有恆定比特率（Constant Bit Rate）能力，但這些解決方案基於 H.264 等技術的影片編碼技術。這些壓縮技術是以影片流的質量和存儲為設計考量，與網路上的真正流量整形無關。您應該始終通過封包捕捉來確認任何此類解決方案。簡而言之，除非封包捕捉能證明否則，始終假設影片流量是極其突發的。

在為未來的項目規劃網路頻寬時——特別是涉及影片的項目——始終採取這些額外步驟，以確保您的網路在今天和未來都能成功運行。