AV已經(jīng)融合到了網(wǎng)絡(luò)的大潮流中，對(duì)于AV人來(lái)說(shuō)了解和精通更多的IT知識(shí)勢(shì)在必行。Phil Hippensteel為我們帶來(lái)了一些常見(jiàn)的網(wǎng)絡(luò)問(wèn)題分析。

帶寬

在 AV 行業(yè)中，帶寬是我們常用的術(shù)語(yǔ)。提到帶寬，當(dāng)它與頻譜和信令一起使用時(shí)，往往都具有明確的含義。但是，當(dāng)它在IP環(huán)境中使用時(shí)，如 “網(wǎng)絡(luò)帶寬”中的含義就很大差異。這在音視頻行業(yè)的培訓(xùn)和學(xué)習(xí)課程中尤為常見(jiàn)。 

使用術(shù)語(yǔ)“網(wǎng)絡(luò)帶寬”時(shí)，通常指的是單個(gè)鏈接可以支持的最大比特率或最大比特率之一。 例如，假設(shè)我們有一個(gè)包含所有千兆以太網(wǎng)交換機(jī)的音頻網(wǎng)絡(luò)， 您可能會(huì)說(shuō)正在使用千兆網(wǎng)絡(luò)。如果 1 Gbps 和 10 Gbps 交換機(jī)都在網(wǎng)絡(luò)中，您可以說(shuō)它是 1G 或 10G 網(wǎng)絡(luò)。

但是，在IT行業(yè)，對(duì)于網(wǎng)絡(luò)可以承載多少信息，通常有幾種描述。事實(shí)上，術(shù)語(yǔ)“網(wǎng)絡(luò)”可能用于指代兩個(gè)終端設(shè)備之間的連接。假設(shè)服務(wù)器通過(guò) 1G 網(wǎng)絡(luò)連接到交換機(jī)，并且到客戶端的路徑中，接下來(lái)的幾個(gè)交換機(jī)通過(guò) 10G 鏈路連接。最后，假設(shè)最后一個(gè)交換機(jī)通過(guò) 1G 鏈路連接到客戶端。網(wǎng)絡(luò)管理員可能會(huì)將此客戶端—服務(wù)器連接稱為 1G 連接，因?yàn)樗梢栽趦蓚€(gè)終端設(shè)備之間承載 1 Gbps 的理論負(fù)載。

通常，兩個(gè)此類設(shè)備之間的路徑描述由兩個(gè)相關(guān)術(shù)語(yǔ)描述。首先，術(shù)語(yǔ)“吞吐量”通常用于描述實(shí)際通過(guò)路徑的位數(shù)。因此，在前面描述的情況下，測(cè)量時(shí)的吞吐量可能是 600 Mbps 或 850 Mbps。它肯定永遠(yuǎn)不會(huì)是 1 Gbps，即理論上的最大速率。

這是由于以太網(wǎng)幀之間的時(shí)間間隔、交換機(jī)的存儲(chǔ)和轉(zhuǎn)發(fā)操作以及許多其他因素造成的。最后， IT 行業(yè)中的一些人使用術(shù)語(yǔ)“goodput”。該術(shù)語(yǔ)是指通過(guò)設(shè)備之間的路徑傳輸?shù)膶?shí)際應(yīng)用程序數(shù)據(jù)量。Goodput 將始終低于最低帶寬鏈路并低于吞吐量。

我們來(lái)舉個(gè)例子，假設(shè)攝像機(jī)使用1 Gbps以太網(wǎng)交換機(jī)，通過(guò)路徑連接到查看設(shè)備，我們可以說(shuō)路徑的帶寬是 1Gbps。但是，另外假設(shè)攝像機(jī)輸出是SRT，它是基于UDP的，并且實(shí)際視頻是MPEG 傳輸?shù)男问健?br /> 現(xiàn)在，每個(gè)發(fā)送的數(shù)據(jù)包至少有58字節(jié)的協(xié)議頭開(kāi)銷，此類數(shù)據(jù)包的長(zhǎng)度通常約為1,372字節(jié)。

因此，我們的有效吞吐量已降至最大比特率的 95% 左右，即 950 Mbps 左右。即使鏈路中沒(méi)有其他流量，這也幾乎不可能實(shí)現(xiàn)。

最后，MPEG 傳輸數(shù)據(jù)部分中的實(shí)際視頻和音頻每個(gè)以太網(wǎng)幀 1,316 字節(jié),由于 UDP 不涉及重傳，并且 SRT 通過(guò)前向糾錯(cuò)處理一些錯(cuò)誤，因此吞吐量可能接近吞吐量。另一方面，如果傳輸是 NDI 或自適應(yīng)比特率，兩者都允許重傳，則在存在丟失的情況下吞吐量會(huì)更低。

HTTP

萬(wàn)維網(wǎng)在超文本傳輸協(xié)議 (HTTP) 和 TCP 上運(yùn)行。從 1990 年代初期開(kāi)始，作為網(wǎng)絡(luò)一部分的服務(wù)器已經(jīng)使用這兩種協(xié)議的一個(gè)版本建立連接和提供信息。作為AV人，我們應(yīng)該熟悉 HTTP 有三個(gè)重要原因。

首先，幾乎所有 AV 行人每天都使用網(wǎng)絡(luò)來(lái)接收信息。 其次，視頻通常使用 HTTP 傳送。 第三，也是最重要的一點(diǎn)，HTTP 和 TCP 都在進(jìn)行重大修改。TCP 可能接近其生命周期結(jié)束狀態(tài)，替換它可能會(huì)導(dǎo)致 HTTP 和 Web 本身發(fā)生重大變化。

在其標(biāo)題中使用術(shù)語(yǔ)“文本”是因?yàn)樵?.9版本旨在允許僅使用文本進(jìn)行請(qǐng)求和響應(yīng)。請(qǐng)求/響應(yīng)字符保留在最初廣泛采用的 1.0 版和后續(xù)協(xié)議 HTTP 1.1 中。由于 1.1 版是在 1.0版 之后的六個(gè)月內(nèi)采用的，并且非常相似，我們來(lái)看看最廣泛的 HTTP 1.1版本。

客戶端使用稱為“get”的命令發(fā)出請(qǐng)求，該命令標(biāo)識(shí)它需要的一個(gè)或多個(gè)文件。 Web 服務(wù)器通常以“OK”響應(yīng)，然后發(fā)送資源。如果資源不可用或位于其他地方，它可能會(huì)以錯(cuò)誤代碼“404 Resource Not Found”或指示所需資源位置的重定向進(jìn)行響應(yīng)。 1.1 版的問(wèn)題之一是隊(duì)頭 (HOL) 阻塞，必須以特定順序接收開(kāi)始呈現(xiàn)網(wǎng)頁(yè)所需的資源，當(dāng)資源被無(wú)序接收時(shí)發(fā)生 HOL。

大約十年前，Ilya Gregorik 討論了一個(gè)問(wèn)題，即典型的網(wǎng)頁(yè)檢索涉及客戶端向 15 個(gè)或更多不同主機(jī)發(fā)出 90 次訪問(wèn)。顯然，可變延遲可能會(huì)對(duì)需要資源的順序造成嚴(yán)重破壞，并減慢頁(yè)面的構(gòu)建速度。通常，每個(gè)請(qǐng)求都是在單獨(dú)的 TCP 連接中進(jìn)行的。這意味著每個(gè)會(huì)話的三向握手以及在接收到每個(gè)資源后適當(dāng)?shù)臅?huì)話關(guān)閉。其中許多會(huì)話也將從 DNS 請(qǐng)求開(kāi)始，所有這些都是相當(dāng)?shù)托У摹L試使用稱為保活、流水線和持久連接的技術(shù)來(lái)糾正這些問(wèn)題。然而，他們?nèi)〉昧瞬煌某晒Α?/p>

HTTP 2.0 正在逐步部署，它對(duì)協(xié)議進(jìn)行了重大更改，包括：

•    HTTP 標(biāo)頭的數(shù)據(jù)壓縮；
•    HTTP/2 服務(wù)器推送；
•    請(qǐng)求流水線；
•    單個(gè) TCP 會(huì)話中的多個(gè)請(qǐng)求。

雖然基本每個(gè)主流瀏覽器都支持 HTTP/2，但即使得到了 HTTP/2 的廣泛支持，TCP 性能問(wèn)題依然存在，目前很難將較差的 TCP 性能與較差的 HTTP 性能區(qū)分開(kāi)來(lái)。但一群有影響力的研究人員正在推動(dòng)采用谷歌的 QUIC（不再用作首字母縮寫(xiě)詞）作為 TCP 的替代品。這將為互聯(lián)網(wǎng)用戶和開(kāi)發(fā)人員創(chuàng)造一個(gè)全新的環(huán)境。

丟包控制

我們經(jīng)常討論被丟棄的錯(cuò)誤數(shù)據(jù)包，而不了解決定數(shù)據(jù)包被丟棄原因的底層技術(shù)，有幾個(gè)協(xié)議層的錯(cuò)誤檢查，因此，當(dāng)數(shù)據(jù)包在目的地被接收時(shí)，會(huì)在網(wǎng)絡(luò)中的多個(gè)點(diǎn)以及不同級(jí)別檢查數(shù)據(jù)包是否存在問(wèn)題。

我們基本上在第二層對(duì)所有數(shù)據(jù)包進(jìn)行的第一次檢查，它被稱為幀校驗(yàn)序列（FCS）。每個(gè)以太網(wǎng)幀都有一個(gè)四字節(jié)字段附加到幀的末尾，這是發(fā)送方計(jì)算的結(jié)果。計(jì)算的輸入由幀中的所有字段組成，每個(gè)交換機(jī)、路由器和終端站都會(huì)重新計(jì)算 FCS。如果結(jié)果與幀中記錄的結(jié)果不同，則丟棄該幀。如果只有一位被損壞，則該值與接收器的計(jì)算結(jié)果匹配的可能性大大低于十億分之一。該過(guò)程中的一個(gè)假設(shè)是更高層將處理重傳問(wèn)題。

IP 字段還包含一個(gè)稱為校驗(yàn)和的錯(cuò)誤校驗(yàn)碼，該值是通過(guò)使用 IP 標(biāo)頭中的所有字段計(jì)算得出的。但是，與以太網(wǎng)不同的是，數(shù)據(jù)不包括在計(jì)算中。 IP 不負(fù)責(zé)檢測(cè)損壞的有效負(fù)載數(shù)據(jù)。由于計(jì)算使用跳數(shù)字段，該字段隨每個(gè)路由器而變化，因此每次路由數(shù)據(jù)包時(shí) IP 校驗(yàn)和都會(huì)更改。如果報(bào)頭中的代碼與它計(jì)算的校驗(yàn)和不匹配，下一個(gè)路由器將丟棄該數(shù)據(jù)包。

第四層協(xié)議 TCP 和 UDP 有不同的方法來(lái)處理數(shù)據(jù)包中的錯(cuò)誤。在目的地，TCP 會(huì)根據(jù) TCP 標(biāo)頭、有效載荷數(shù)據(jù)和 IP 標(biāo)頭中的關(guān)鍵字段進(jìn)行計(jì)算，這些字段有時(shí)被稱為 IP 偽標(biāo)頭。然而，如果計(jì)算與校驗(yàn)和字段中存儲(chǔ)的值不匹配，TCP 將簡(jiǎn)單地丟棄數(shù)據(jù)包。與流行的看法相反，TCP 沒(méi)有明確通知發(fā)送方丟棄，它只是不確認(rèn)收到該段。由于段的排序，發(fā)送方最終將意識(shí)到該段沒(méi)有被正確接收并且將被重傳。

UDP 不提供重傳，但它執(zhí)行錯(cuò)誤檢查。 如果報(bào)頭中有錯(cuò)誤，UDP 不想將數(shù)據(jù)段向上傳遞到應(yīng)用層。 這一點(diǎn)尤其重要，因?yàn)樵摌?biāo)頭包含正確識(shí)別正確接收應(yīng)用程序的端口。

當(dāng)不包括有效載荷數(shù)據(jù)的錯(cuò)誤檢查時(shí)，接收器將獲得無(wú)效數(shù)據(jù)。 這在 VoIP 中會(huì)變得很明顯，尤其是在使用壓縮時(shí)：用戶可能會(huì)聽(tīng)到聲音失真。 相反，在諸如 Apple 的 HLS 之類的自適應(yīng)比特率視頻中，正在使用 TCP。 損壞的數(shù)據(jù)將在播放前重新傳輸。 因此，雖然延遲可能會(huì)增加，但視頻應(yīng)該正確播放。

延遲如何產(chǎn)生的？

延遲也是 AV 行業(yè)中討論最廣泛的一個(gè)問(wèn)題。延遲對(duì)基于 TCP 的視頻流的影響有哪些呢？這些視頻流包括自適應(yīng)比特率流，例如 HLS、DASH 和 NDI。由于它們是基于 TCP 的，所以它們的傳輸速率、頻率和重傳規(guī)則都受 TCP 算法的約束。這是我們需要更仔細(xì)地觀察的地方。

TCP 有三個(gè)流行版本：TCP Reno、Cubic 和 Compound。

它們的基本操作是相似的，因此為簡(jiǎn)單起見(jiàn)，我們將基于 TCP Reno 進(jìn)行討論。當(dāng)設(shè)備有 TCP 流要傳輸時(shí)，它會(huì)與建議的接收器協(xié)商，并被告知伙伴設(shè)備將使用的接收窗口，這是它可以在其接收緩沖區(qū)中保存的字節(jié)數(shù)。常見(jiàn)的窗口大小為 128kB、256kB 或這些大小的倍數(shù)。發(fā)送方還發(fā)起發(fā)送塊大小，通常用術(shù)語(yǔ) cwnd 表示，通常是四個(gè) TCP 段。當(dāng)傳輸開(kāi)始時(shí)，所有四個(gè)段都被發(fā)送。發(fā)送方等待對(duì)該四塊的確認(rèn)。接收者的行為完全不同，它確認(rèn)所有其他段。因此，它將確認(rèn)第二段，然后是第四段。

在確保接收方擁有所有四個(gè)段的情況下，發(fā)送方將 cwnd 提高到 8，或者是其先前值的兩倍，它立即發(fā)送所有八個(gè)段并等待該組的確認(rèn)。接收方再次確認(rèn)收到每隔一段。遵循相同的模式，發(fā)送方將繼續(xù)加倍 cwnd 并等待整個(gè)數(shù)據(jù)塊的確認(rèn)。當(dāng) cwnd 達(dá)到接收者通告窗口的一半時(shí)，快速升級(jí)會(huì)變慢。然后發(fā)送方將 cwnd 增加 1。請(qǐng)注意，如果 cwcn 為 8，并且只有一個(gè)段丟失、丟棄或只是在繁忙緩沖區(qū)中延遲，則發(fā)送方必須等待塊中每個(gè)段的確認(rèn)。

此過(guò)程的目的是使發(fā)送方和接收方之間的鏈接逐漸飽和。當(dāng)發(fā)送方收到網(wǎng)絡(luò)或接收方丟棄數(shù)據(jù)包的通知時(shí)，它會(huì)降低其傳輸速率。雖然這是另一課的主題，但我們有足夠的理解來(lái)評(píng)估延遲對(duì) TCP 進(jìn)程的影響。

延遲會(huì)影響傳輸速率，因?yàn)榘l(fā)送方必須等待在當(dāng)前 cwnd 下發(fā)送的所有數(shù)據(jù)包都得到確認(rèn)。同樣重要的是要注意返回路徑中的延遲很關(guān)鍵，如果確認(rèn)返回給發(fā)送方的速度很慢，則發(fā)送方將繼續(xù)等待整個(gè)塊的確認(rèn)。TCP 操作的這一方面通常被忽視。這可能是出售給消費(fèi)者的非對(duì)稱帶寬鏈路的一個(gè)重大問(wèn)題。電信、DSL 和電纜鏈路的下行方向通常是上行方向的 10倍。在接收ABR視頻時(shí)，承載確認(rèn)的是上行連接，上行鏈路上的高流量（例如視頻上傳）將導(dǎo)致任何下載速度顯著減慢。