AV已經融合到了網絡的大潮流中，對于AV人來說了解和精通更多的IT知識勢在必行。Phil Hippensteel為我們帶來了一些常見的網絡問題分析。
帶寬
在 AV 行業中，帶寬是我們常用的術語。提到帶寬，當它與頻譜和信令一起使用時，往往都具有明確的含義。但是，當它在IP環境中使用時，如 “網絡帶寬”中的含義就很大差異。這在音視頻行業的培訓和學習課程中尤為常見。
使用術語“網絡帶寬”時，通常指的是單個鏈接可以支持的最大比特率或最大比特率之一。 例如，假設我們有一個包含所有千兆以太網交換機的音頻網絡， 您可能會說正在使用千兆網絡。如果 1 Gbps 和 10 Gbps 交換機都在網絡中，您可以說它是 1G 或 10G 網絡。
但是，在IT行業，對于網絡可以承載多少信息，通常有幾種描述。事實上，術語“網絡”可能用于指代兩個終端設備之間的連接。假設服務器通過 1G 網絡連接到交換機，并且到客戶端的路徑中，接下來的幾個交換機通過 10G 鏈路連接。最后，假設最后一個交換機通過 1G 鏈路連接到客戶端。網絡管理員可能會將此客戶端—服務器連接稱為 1G 連接，因為它可以在兩個終端設備之間承載 1 Gbps 的理論負載。
通常，兩個此類設備之間的路徑描述由兩個相關術語描述。首先，術語“吞吐量”通常用于描述實際通過路徑的位數。因此，在前面描述的情況下，測量時的吞吐量可能是 600 Mbps 或 850 Mbps。它肯定永遠不會是 1 Gbps，即理論上的最大速率。
這是由于以太網幀之間的時間間隔、交換機的存儲和轉發操作以及許多其他因素造成的。最后， IT 行業中的一些人使用術語“goodput”。該術語是指通過設備之間的路徑傳輸的實際應用程序數據量。Goodput 將始終低于最低帶寬鏈路并低于吞吐量。
我們來舉個例子，假設攝像機使用1 Gbps以太網交換機，通過路徑連接到查看設備，我們可以說路徑的帶寬是 1Gbps。但是，另外假設攝像機輸出是SRT，它是基于UDP的，并且實際視頻是MPEG 傳輸的形式。
現在，每個發送的數據包至少有58字節的協議頭開銷，此類數據包的長度通常約為1,372字節。
因此，我們的有效吞吐量已降至最大比特率的 95% 左右，即 950 Mbps 左右。即使鏈路中沒有其他流量，這也幾乎不可能實現。
最后，MPEG 傳輸數據部分中的實際視頻和音頻每個以太網幀 1,316 字節,由于 UDP 不涉及重傳，并且 SRT 通過前向糾錯處理一些錯誤，因此吞吐量可能接近吞吐量。另一方面，如果傳輸是 NDI 或自適應比特率，兩者都允許重傳，則在存在丟失的情況下吞吐量會更低。
HTTP
萬維網在超文本傳輸協議 (HTTP) 和 TCP 上運行。從 1990 年代初期開始，作為網絡一部分的服務器已經使用這兩種協議的一個版本建立連接和提供信息。作為AV人，我們應該熟悉 HTTP 有三個重要原因。
首先，幾乎所有 AV 行人每天都使用網絡來接收信息。 其次，視頻通常使用 HTTP 傳送。 第三，也是最重要的一點，HTTP 和 TCP 都在進行重大修改。TCP 可能接近其生命周期結束狀態，替換它可能會導致 HTTP 和 Web 本身發生重大變化。
在其標題中使用術語“文本”是因為原始0.9版本旨在允許僅使用文本進行請求和響應。請求/響應字符保留在最初廣泛采用的 1.0 版和后續協議 HTTP 1.1 中。由于 1.1 版是在 1.0版 之后的六個月內采用的，并且非常相似，我們來看看最廣泛的 HTTP 1.1版本。
客戶端使用稱為“get”的命令發出請求，該命令標識它需要的一個或多個文件。 Web 服務器通常以“OK”響應，然后發送資源。如果資源不可用或位于其他地方，它可能會以錯誤代碼“404 Resource Not Found”或指示所需資源位置的重定向進行響應。 1.1 版的問題之一是隊頭 (HOL) 阻塞，必須以特定順序接收開始呈現網頁所需的資源，當資源被無序接收時發生 HOL。
大約十年前，Ilya Gregorik 討論了一個問題，即典型的網頁檢索涉及客戶端向 15 個或更多不同主機發出 90 次訪問。顯然，可變延遲可能會對需要資源的順序造成嚴重破壞，并減慢頁面的構建速度。通常，每個請求都是在單獨的 TCP 連接中進行的。這意味著每個會話的三向握手以及在接收到每個資源后適當的會話關閉。其中許多會話也將從 DNS 請求開始，所有這些都是相當低效的。嘗試使用稱為保活、流水線和持久連接的技術來糾正這些問題。然而，他們取得了不同的成功。
HTTP 2.0 正在逐步部署，它對協議進行了重大更改，包括：
• HTTP 標頭的數據壓縮；
• HTTP/2 服務器推送；
• 請求流水線；
• 單個 TCP 會話中的多個請求。
雖然基本每個主流瀏覽器都支持 HTTP/2，但即使得到了 HTTP/2 的廣泛支持，TCP 性能問題依然存在，目前很難將較差的 TCP 性能與較差的 HTTP 性能區分開來。但一群有影響力的研究人員正在推動采用谷歌的 QUIC（不再用作首字母縮寫詞）作為 TCP 的替代品。這將為互聯網用戶和開發人員創造一個全新的環境。
丟包控制
我們經常討論被丟棄的錯誤數據包，而不了解決定數據包被丟棄原因的底層技術，有幾個協議層的錯誤檢查，因此，當數據包在目的地被接收時，會在網絡中的多個點以及不同級別檢查數據包是否存在問題。
我們基本上在第二層對所有數據包進行的第一次檢查，它被稱為幀校驗序列（FCS）。每個以太網幀都有一個四字節字段附加到幀的末尾，這是發送方計算的結果。計算的輸入由幀中的所有字段組成，每個交換機、路由器和終端站都會重新計算 FCS。如果結果與幀中記錄的結果不同，則丟棄該幀。如果只有一位被損壞，則該值與接收器的計算結果匹配的可能性大大低于十億分之一。該過程中的一個假設是更高層將處理重傳問題。
IP 字段還包含一個稱為校驗和的錯誤校驗碼，該值是通過使用 IP 標頭中的所有字段計算得出的。但是，與以太網不同的是，數據不包括在計算中。 IP 不負責檢測損壞的有效負載數據。由于計算使用跳數字段，該字段隨每個路由器而變化，因此每次路由數據包時 IP 校驗和都會更改。如果報頭中的代碼與它計算的校驗和不匹配，下一個路由器將丟棄該數據包。
第四層協議 TCP 和 UDP 有不同的方法來處理數據包中的錯誤。在目的地，TCP 會根據 TCP 標頭、有效載荷數據和 IP 標頭中的關鍵字段進行計算，這些字段有時被稱為 IP 偽標頭。然而，如果計算與校驗和字段中存儲的值不匹配，TCP 將簡單地丟棄數據包。與流行的看法相反，TCP 沒有明確通知發送方丟棄，它只是不確認收到該段。由于段的排序，發送方最終將意識到該段沒有被正確接收并且將被重傳。
UDP 不提供重傳，但它執行錯誤檢查。 如果報頭中有錯誤，UDP 不想將數據段向上傳遞到應用層。 這一點尤其重要，因為該標頭包含正確識別正確接收應用程序的端口。
當不包括有效載荷數據的錯誤檢查時，接收器將獲得無效數據。 這在 VoIP 中會變得很明顯，尤其是在使用壓縮時：用戶可能會聽到聲音失真。 相反，在諸如 Apple 的 HLS 之類的自適應比特率視頻中，正在使用 TCP。 損壞的數據將在播放前重新傳輸。 因此，雖然延遲可能會增加，但視頻應該正確播放。
延遲如何產生的？
延遲也是 AV 行業中討論最廣泛的一個問題。延遲對基于 TCP 的視頻流的影響有哪些呢？這些視頻流包括自適應比特率流，例如 HLS、DASH 和 NDI。由于它們是基于 TCP 的，所以它們的傳輸速率、頻率和重傳規則都受 TCP 算法的約束。這是我們需要更仔細地觀察的地方。
TCP 有三個流行版本：TCP Reno、Cubic 和 Compound。
它們的基本操作是相似的，因此為簡單起見，我們將基于 TCP Reno 進行討論。當設備有 TCP 流要傳輸時，它會與建議的接收器協商，并被告知伙伴設備將使用的接收窗口，這是它可以在其接收緩沖區中保存的字節數。常見的窗口大小為 128kB、256kB 或這些大小的倍數。發送方還發起發送塊大小，通常用術語 cwnd 表示，通常是四個 TCP 段。當傳輸開始時，所有四個段都被發送。發送方等待對該四塊的確認。接收者的行為完全不同，它確認所有其他段。因此，它將確認第二段，然后是第四段。
在確保接收方擁有所有四個段的情況下，發送方將 cwnd 提高到 8，或者是其先前值的兩倍，它立即發送所有八個段并等待該組的確認。接收方再次確認收到每隔一段。遵循相同的模式，發送方將繼續加倍 cwnd 并等待整個數據塊的確認。當 cwnd 達到接收者通告窗口的一半時，快速升級會變慢。然后發送方將 cwnd 增加 1。請注意，如果 cwcn 為 8，并且只有一個段丟失、丟棄或只是在繁忙緩沖區中延遲，則發送方必須等待塊中每個段的確認。
此過程的目的是使發送方和接收方之間的鏈接逐漸飽和。當發送方收到網絡或接收方丟棄數據包的通知時，它會降低其傳輸速率。雖然這是另一課的主題，但我們有足夠的理解來評估延遲對 TCP 進程的影響。
延遲會影響傳輸速率，因為發送方必須等待在當前 cwnd 下發送的所有數據包都得到確認。同樣重要的是要注意返回路徑中的延遲很關鍵，如果確認返回給發送方的速度很慢，則發送方將繼續等待整個塊的確認。TCP 操作的這一方面通常被忽視。這可能是出售給消費者的非對稱帶寬鏈路的一個重大問題。電信、DSL 和電纜鏈路的下行方向通常是上行方向的 10倍。在接收ABR視頻時，承載確認的是上行連接，上行鏈路上的高流量（例如視頻上傳）將導致任何下載速度顯著減慢。