Editorial Note

隨著5G技術(shù)與邊緣計(jì)算的發(fā)展，流媒體的視頻技術(shù)也將越發(fā)精湛。現(xiàn)在的技術(shù)更多從視頻媒體，包括流媒體的一個容器、技術(shù)、存儲協(xié)議，以及在傳輸層面做的一些優(yōu)化，這些技術(shù)都將成為實(shí)現(xiàn)超低時延而需要的關(guān)鍵技術(shù)，而超低時延將成為未來視頻技術(shù)的主流。超低時延的形成也將離不開邊緣計(jì)算的輔助，良好的邊緣計(jì)算技術(shù)也是形成超低時延的重要輔助。本次LiveVideoStackCon 2021上海站我們邀請到了Akamai紀(jì)永康分享播放器、格式和容器編解碼和視頻內(nèi)容準(zhǔn)備，網(wǎng)絡(luò)協(xié)議和數(shù)據(jù)傳輸，互聯(lián)網(wǎng)流量增長趨勢。

文 / 紀(jì)永康

整理 / LiveVideoStack

大家好，我是來自Akamai的紀(jì)永康。我們非常感謝LiveVideoStack的邀請來進(jìn)行這個演講。從第一屆LiveVideoStackCon開始，每次都會與大家聊關(guān)于視頻技術(shù)方面的演進(jìn)。之前Akamai的首席視頻架構(gòu)師也是DASH協(xié)議組的主席Will Law和大家聊過CMAF DASH；前一屆時，我們也講過動態(tài)協(xié)議優(yōu)化方面的技術(shù)方面嘗試和進(jìn)展。

本次我將更多從視頻媒體，包括流媒體的容器、技術(shù)、存儲協(xié)議，以及在傳輸層面優(yōu)化的角度來分享。

Akamai主要提供出海客戶的CDN和安全以及邊緣計(jì)算的服務(wù)。Akamai是全球最大的一家CDN，同時也是CDN概念的發(fā)明者。當(dāng)時的發(fā)明者和創(chuàng)始人麻省理工計(jì)算機(jī)系教授Tom Leighton現(xiàn)在依然是Akamai的CEO。

本次分享主要分為六個主題。分別是在播放器、格式和容器在過去20年以及未來的技術(shù)發(fā)展趨勢；編解碼和視頻內(nèi)容準(zhǔn)備包括內(nèi)容生產(chǎn)方面的技術(shù)的演進(jìn)；網(wǎng)絡(luò)協(xié)議和數(shù)據(jù)傳輸協(xié)議方面的演進(jìn)；從Akamai平臺的角度分析互聯(lián)網(wǎng)流量增長趨勢，Akamai平臺承載了非常多的音視頻內(nèi)容，大部分視頻直播是Akamai承載的包括蘋果發(fā)布會，絕大多數(shù)是Akamai做的全球分發(fā)包括奧運(yùn)會、世界杯；如何在大規(guī)模流量的情況下做不同層面的優(yōu)化，以及最后對本次演講內(nèi)容的總結(jié)。

01

播放器、視頻格式和容器

1.1 流量媒體格式和容器進(jìn)展

上圖是關(guān)于播放器、視頻格式和容器方面的一些進(jìn)展，可以看出，針對流媒體協(xié)議本身，更多且較成熟地大規(guī)模運(yùn)用還是從2010年開始的。從大家一開始做流媒體協(xié)議而熟悉的RTMP，包括我們現(xiàn)在在做的personal broadcasting 或者個人網(wǎng)紅直播用的FLV協(xié)議，都和RTMP有著密切的關(guān)系。

在2010年左右，當(dāng)時已經(jīng)有HAS技術(shù)的進(jìn)展，最常見的是技術(shù)非常成熟的HLS和DASH，但當(dāng)時大家還是用和廠商相關(guān)的協(xié)議，比如蘋果的HLS、微軟的SMOOTH等等，都是廠商的私有協(xié)議偏多。

隨著協(xié)議的發(fā)展，2015年DASH出現(xiàn)了。它是基于ISO開放標(biāo)準(zhǔn)，與平臺無關(guān)的協(xié)議。2020年，可以看到針對切片層面協(xié)議，大家更多的是在做LL，也就是超低時延的協(xié)議，包括LL的HLS和LL的DASH。2016左右，蘋果也終于從它的HLS里，支持從TS變到Fragment MP4，像CMAF格式的出現(xiàn)。它要解決當(dāng)時兩大主流HLS和DASH協(xié)議之間不一致的問題，如此無論用HLS或在蘋果平臺或者安卓等其他平臺都可以使用Fragment MP4。在用DASH的情況下，都可以用CMAF統(tǒng)一格式來解決存儲、編碼方面的二次工作或者冗余的工作量。我們認(rèn)為未來在直播協(xié)議、流協(xié)議層面只會有這兩個基于CMAF的HLS和DASH協(xié)議，這樣協(xié)議碎片化的問題最終會被解決掉。

國內(nèi)從2015年開始，大量的直播APP的協(xié)議還是FLV。從標(biāo)準(zhǔn)化的情況來看，我們認(rèn)為FLV還是一個私有協(xié)議。在國內(nèi)的這種生態(tài)是非常完備的，但在國外的使用環(huán)境下不是非常充足，所以如果要在海外做一些大規(guī)模的直播、直播帶貨、賽事直播，首選是切片協(xié)議。一方面它對于CDN的分發(fā)非常友好；另一方面，它基于標(biāo)準(zhǔn)，這對于它的生態(tài)也會逐漸完整。在國外，無論基于HLS還是DASH的應(yīng)用都非常多，包括Twitch的游戲直播、YouTube還是賽事，都是基于切片協(xié)議的。在海外這樣的應(yīng)用非常普遍，這和我們國內(nèi)做直播的場景有著很大的不同。

1.2 HLS和DASH的區(qū)別

我們具體來看看它們之間的區(qū)別。上圖是一個簡單的示意圖，可以看到像傳統(tǒng)的HLS和DASH是沒有小切片的方式，它們一個一個地拿，拿到一個傳輸一個。蘋果最早的建議是每個切片10秒鐘，它至少要拿10個切片才能開始播放，這樣本身的時延就達(dá)到30秒以上。為了解決這個問題，我們的思路非常的直接，把它做成類似于邊下邊播的形式，不需要一個完整的段，只要拿到其中一部分就可以開始播放，從而有效降低時延。對于HLS來說道理也是類似的。

1.3?直播流媒體的延遲

上圖是這幾個錄屏的結(jié)果。上方是CMAF DASH，下方是CMAF HLS的方式。兩個協(xié)議的時延都能低于5秒。或許大家覺得5秒在國內(nèi)的直播情況下很普遍，但如果你要做一個全球事件，如世界杯、游戲直播、以及直播帶貨等，全球范圍內(nèi)實(shí)現(xiàn)一個相對穩(wěn)定的時延并不容易。從下面在全球范圍內(nèi)做的具體數(shù)據(jù)可以看到，它的時延基本上不到3秒。因此CMAF可以在全球范圍內(nèi)做到更低的時延和更好的交互。

上圖是與我們的合作伙伴THEO一起做的，以從波士頓的編碼器到美西的播放器作為場景，跨越北美大陸，它可以做到穩(wěn)定低于0.5秒的時延。你這邊做很低的時延，是會有些trade off，卡頓也會有所上升。時延越低，抗卡頓能力就越小。從技術(shù)上來看，通過切片協(xié)議可以非常有效的做到用戶所需要的低時延交互形式。

1.4 聚合視頻格式

CMAF可以有效地被大家接受是因?yàn)镃MAF有效地解決了HLS和DASH的分割，原來的HLS是用傳統(tǒng)廣電的TS容器，DASH一直用的是mp4的格式，現(xiàn)在蘋果終于接受了Fragment MP4，可以通過CMAF統(tǒng)一的格式，讓你的生產(chǎn)、分發(fā)和在用戶的緩存層面所有的都變成一份，而不是為了適應(yīng)HLS和安卓，需要有兩份的存儲、緩存和轉(zhuǎn)碼。現(xiàn)在通過CMAF只要一份就可以適應(yīng)不同的格式。不同播放器情況下，CMAF時延的情況會不太一樣，但好處在于通過CMAF分裝可以適應(yīng)不同的平臺。左下方是LL-HLS的播放器，左上方是標(biāo)準(zhǔn)的DASH播放器，右側(cè)是傳統(tǒng)的HLS播放器，他們都是通過CMAF分裝，但時延都不一樣，在用LL-HLS和LL-DASH的情況下都可以達(dá)到2秒的時延，而用傳統(tǒng)播放器，時延就可能要8秒甚至更長。好處是如果你有三種不同類型的客戶端，那在CDN層面的緩存、存儲和轉(zhuǎn)碼可以復(fù)用，可以有效提升緩存熱度，降低存儲壓力，也可以提升工作流的簡捷性。

上圖是一些具體內(nèi)容的截圖。在CDN層面，它的第一個請求是沒有緩存的，但隨著后面幾個播放器的加入，第一個播放器就CACHE HIT了，這也就證明整個緩存是可以復(fù)用的。

1.5 CMAF/CBCS

國內(nèi)對于內(nèi)容安全層面，包括內(nèi)容版權(quán)、防盜鏈和有些版權(quán)方要求的DRM系統(tǒng)保護(hù)等層面的關(guān)注度不大。在這個層面，CMAF也做了最大程度上的溝通。可以看到CBCS的統(tǒng)一加密方式應(yīng)該是最終的未來。雖然現(xiàn)在還有CTR和CBCS兩種不同的加密方式，但我們認(rèn)為在最終情況下，隨著時間的演進(jìn)和從Akamai平臺上監(jiān)測到的加密方式來看，絕大部分的設(shè)備都會支持CBCS。

02

編解碼和內(nèi)容準(zhǔn)備

第二個主題是針對編解碼和內(nèi)容準(zhǔn)備，包括轉(zhuǎn)碼、分裝層面的一些變化。

2.1 視頻質(zhì)量

上圖是關(guān)于視頻質(zhì)量的參數(shù)，包括鏈接、分辨率、幀數(shù)等。在過去10多年時間，有非常多的協(xié)議進(jìn)行演進(jìn)，包括HDMI；分辨率從1080p到4k甚至到8k；幀率也從25、30幀到現(xiàn)在60幀；對于SDR等技術(shù)的演進(jìn)是非常快速的。從視頻標(biāo)準(zhǔn)來看，更多關(guān)注的是視頻編碼標(biāo)準(zhǔn)，它的編碼標(biāo)準(zhǔn)演化周期較長，通常情況下在7-10年會出現(xiàn)一個演化周期。現(xiàn)在大家用的最多的像AVC等，已經(jīng)17年了，而現(xiàn)在更多的像HEVC等更強(qiáng)的編碼算法還在不停地出現(xiàn)，但它的替換周期還是比較長的。現(xiàn)在我們依然在用相當(dāng)于17年前的編碼算法。

2.2 編碼策略的演變

從編碼的策略的來看，大家一開始還是更多以固定碼率為主。

到現(xiàn)在來看，大家更希望做到碼率自適應(yīng)和編碼格式的根據(jù)內(nèi)容的不同的自適應(yīng)，比如一個動畫片和一個動作片的碼率就不一樣。

對于編碼策略的變化，我們認(rèn)為也是要自適應(yīng)的。

2.3 視頻壓縮率和選擇編碼方式

像我剛才說的AVC依舊是比較主流的編碼方式，但是它已經(jīng)用了17年了。大家可能更加考慮的點(diǎn)是，我們怎么去選擇一個編碼方式。

我認(rèn)為有幾個考慮的點(diǎn)。但更重要的是大家做To C或者To B的業(yè)務(wù)，關(guān)心的是用戶的感知質(zhì)量。這之下會考慮編碼成本、存儲成本和交付成本有多高。如果我的設(shè)備支持HEVC、AAC這種高階的視頻解碼，還是要考慮我們的內(nèi)容是冷還是熱，熱內(nèi)容我們就選擇高效率的壓縮，會減少我們的存儲和交付成本；但如果內(nèi)容非常冷，比如短視頻，每個內(nèi)容就訪問個幾次，這時候用高階算法就會花很大的力氣去壓縮，那之后會不會有效是需要大家去考慮的。所以我們選擇認(rèn)為編碼是一個動態(tài)的場景而不是一個靜態(tài)，也不是說我所有的場景都會用HEVC或者AAC等等，而是要看到場景的不同選擇不同的編碼來做。

可以把公式反過來。在保證用戶感知質(zhì)量不變的情況下，我怎么去優(yōu)化我的編碼成本、存儲成本和交付成本這幾個層面。

2.4 動態(tài)編碼的重要性

把編解碼作為動態(tài)來實(shí)現(xiàn)非常關(guān)鍵，在海外，大家通常都會做ABR，也就是做動態(tài)碼率。在海外的場景下，用戶的網(wǎng)絡(luò)情況變化非常大。如印度的網(wǎng)絡(luò)環(huán)境已經(jīng)有非常大的提升，他們的4G甚至5G的覆蓋率都已經(jīng)非常高，但是4G網(wǎng)絡(luò)建設(shè)非常不均衡，他們的覆蓋點(diǎn)很多都在大城市。這時候就能看到一現(xiàn)象，雖然印度觀眾對于視頻的卡頓、幀數(shù)等有較好的容忍度。但大家還是希望能夠看到比較好的場景，但這樣，碼率的變化范圍就特別大，在大城市的碼率會達(dá)到1Mb，但在某些農(nóng)村就只有200kb甚至更低，才能讓他進(jìn)行播放。

2.5 視頻分辨率

不論是長視頻的OTT、優(yōu)酷、騰訊等等，還是短視頻的up主，短視頻的抖音、快手等，都在追求高分辨率。從以前在手機(jī)上的480p，到現(xiàn)在很多短視頻的up主都在做720p甚至1080p的視頻。

現(xiàn)在像奇異在大陸做虛擬的演唱會或者綜藝節(jié)目，分辨率已經(jīng)可以做的非常高了，2K、4K甚至更高的分辨率。當(dāng)然現(xiàn)在很多電視都支持8K，雖然8K的內(nèi)容還是很少的，但是這并不妨礙8K電視的普及會對4K內(nèi)容造成非常大的推動作用，我們會看到越來越多的4K內(nèi)容會出現(xiàn)。

03

協(xié)議層面

下面我們進(jìn)入到第三個層面：協(xié)議層面。協(xié)議層面會對做網(wǎng)絡(luò)優(yōu)化的人來說會比較熟悉。過去這么多年來，HTTP協(xié)議在最近幾年的演變非常快。在過去十幾年基本上都是HTTP1.1，在5年之前，H2的協(xié)議被采納。現(xiàn)在可能更多的談?wù)換UIC、H3這樣的一些協(xié)議。但從Akamai平臺的數(shù)據(jù)來看雖然H2協(xié)議出來這么年了，采納率依然有待提升，QUIC也是一樣的。不論是從客戶端的支持層面還是瀏覽器的層面來講，對QUIC來講還是在逐步的演進(jìn)過程當(dāng)中。因?yàn)閺腁kamai平臺來看，大概是3年前開始在全網(wǎng)做QUIC，我們看到有一些長視頻的用戶在用gQUIC去做，而現(xiàn)在一些視頻客戶和其他客戶開始考慮IETF QUIC。我們認(rèn)為在今年或者明年的范圍內(nèi)，IETF QUIC會逐漸替代掉gQUIC，因?yàn)間QUIC是一個廠商私有協(xié)議。如果大家現(xiàn)在做QUIC可以考慮一下演進(jìn)路線，以便將來比較容易的升級到IETF QUIC。

3.1 協(xié)議的影響

這一塊是擁塞控制算法，現(xiàn)在用的比較多的、比較新的是谷歌BBR。從Akamai本身的數(shù)據(jù)來看，我們認(rèn)為BBR并不能適應(yīng)所有的場景，所以從Akamai看到的現(xiàn)網(wǎng)數(shù)據(jù)來看，我認(rèn)為對擁塞控制算法的選擇也是要做動態(tài)的。

現(xiàn)在你有非常多的運(yùn)算控制算法去做，像BBR、QDK、FastTCP等，它們的算法都有自己不同的特點(diǎn)，需要考慮的因素也非常多，會考慮RTT、數(shù)據(jù)丟包、抖動甚至考慮服務(wù)器的負(fù)載等等。Akamai的建議是大家可以考慮綜合的場景來選擇合適的運(yùn)算控制算法。我們也能發(fā)現(xiàn)現(xiàn)在的機(jī)器學(xué)習(xí)，包括AI的技術(shù)應(yīng)用得也非常廣泛。Akamai也認(rèn)為動態(tài)選擇也可以通過機(jī)器學(xué)習(xí)來實(shí)現(xiàn)，它在通過不同場景和時間的數(shù)據(jù)情況下，可以做一個動態(tài)選擇，Akamai將這個選擇叫做DPO(Dynamic Protocol Optimization)，即動態(tài)協(xié)議優(yōu)化，你可以根據(jù)當(dāng)時網(wǎng)絡(luò)的場景不同來做一個優(yōu)化。

我們也非常建議尤其是在高并發(fā)鏈接的情況下去采納HTTP2協(xié)議，因?yàn)镠TTPP2協(xié)議的優(yōu)化結(jié)果還是很不錯的。

3.2 網(wǎng)絡(luò)協(xié)議棧

在整個網(wǎng)絡(luò)協(xié)議棧上面看到比較多的是這三個HTTP協(xié)議，另外更多的是WebSocket和WebRTC協(xié)議，會有非常多的選擇在不同的應(yīng)用場景。這些都是比較主流的協(xié)議。

現(xiàn)在依然是手動選擇的方式，在不同場景下選擇不同的協(xié)議。現(xiàn)在像IETF和W3C也在規(guī)劃新的WebTransport網(wǎng)絡(luò)協(xié)議棧。希望能夠做一種自適應(yīng)的動態(tài)的選擇，根據(jù)用戶不同的應(yīng)用場景來選擇H2、QUIC還是用其他的一些協(xié)議。當(dāng)然WebTransport還是處于在IETF和W3C的草案階段。我們認(rèn)為在今年下半年甚至明年的時候會有更多的應(yīng)用場景和定稿出來。需要去適應(yīng)不同的場景，是要可靠連接還是不可靠連接，說到底這和之前的方法論是類似的，希望動態(tài)選擇是根據(jù)場景的選擇，而不是一個固定選擇。

04

流量規(guī)模增長

最后我們來看一下整個流量的增長規(guī)模以及在CDN層面能做哪些優(yōu)化。

4.1 流量規(guī)模增長

上圖是Akamai平臺上顯示的過去十年整個流量增長情況，是實(shí)際的峰值數(shù)據(jù)。因?yàn)槿ツ甑囊咔?#xff0c;這個峰值量在原有的基礎(chǔ)上有提升了40%，在這種情況下，對于整個網(wǎng)絡(luò)的壓力非常大。大家有印象的話，大概在去年4、5月份，在印度和歐洲疫情非常嚴(yán)重的時，歐洲的運(yùn)營商，對YouTube、Amazon等幾個大型在線視頻廠商，TikTok短視頻應(yīng)用等要求降低碼率。因?yàn)楫?dāng)時他們看到非常巨量的互聯(lián)網(wǎng)流量，對運(yùn)營商的核心網(wǎng)造成了非常大的壓力。基于這一點(diǎn)，Akamai也與運(yùn)營商進(jìn)行了非常多的合作，在那期間CDN起到了非常大的作用，因?yàn)镃DN有效地降低互聯(lián)網(wǎng)在核心網(wǎng)之間帶寬的擁塞。現(xiàn)在有的CDN廠商的思路是建設(shè)大節(jié)點(diǎn)，和云計(jì)算的思路類似的，比如在全球建100個大節(jié)點(diǎn)來覆蓋全球大多數(shù)用戶。從Akamai的角度來講，我們依然認(rèn)為CDN的價(jià)值是在邊緣，因?yàn)镃DN更多的是放在更靠近用戶的地方，所以Akamai建了大概2000多個節(jié)點(diǎn)，我們的做法更加接近用戶，和全球90%-95%的互聯(lián)網(wǎng)用戶在同一個運(yùn)營商網(wǎng)絡(luò)。在疫情期間所體現(xiàn)的價(jià)值會更明顯，這樣的架構(gòu)可以有效地降低網(wǎng)間穿越流量，降低核心網(wǎng)的壓力。

4.2 規(guī)模與性能

我們知道規(guī)模肯定是長的，雖然編碼效率有提升，但是分辨率、用戶上傳的內(nèi)容和視頻產(chǎn)出的內(nèi)容呈幾何級數(shù)的增長。我們要統(tǒng)籌好規(guī)模與性能之間的關(guān)系。

4.3 Akamai對規(guī)模與性能做的探索與技術(shù)實(shí)現(xiàn)

大的方面是容量、性能和成本，需要做到平衡。在這方面，Akamai做了相應(yīng)的探索和技術(shù)的實(shí)現(xiàn)。下面我將從容量模型、服務(wù)器性能、磁盤延遲、源站優(yōu)化、全球網(wǎng)絡(luò)部署這六個層面來講述Akamai是怎么做的。

4.3.1 容量模型

現(xiàn)在硬件設(shè)備便宜了，內(nèi)存可以做得非常大，網(wǎng)絡(luò)接口可以做到20G、45G甚至100G。對于Akamai來講，除了堆設(shè)備外，依然要考慮成本和最高效利用率的問題。為了達(dá)到目標(biāo)緩存率，需要了解你的存儲需要多大、內(nèi)存需要多大；當(dāng)達(dá)到相同的目標(biāo)緩存率，你的運(yùn)用場景不同，數(shù)據(jù)是否也會不一樣，比如一個長視頻或短視頻或冷熱視頻，它的內(nèi)容不同，它對緩存命中是有非常大的影響的；最后它的熱度有多高，它的內(nèi)容被緩存下來，是被很多人訪問還是只有個別的人在訪問。Akamai根據(jù)現(xiàn)有的流量模型做了一套算法，我們希望能夠?qū)崿F(xiàn)最合理的容量來達(dá)到最合理的緩存命中率的效果。我們針對最上層的緩存做一個曲線，就可以看到多大的緩存就可以實(shí)現(xiàn)特定的緩存命中率。這樣的情況下，我們在和一些用戶合作，比如一些用戶會特別關(guān)心源站的出口帶寬或源站流出的流量，我們可以把最后的回源節(jié)點(diǎn)做成某個用戶專有的，比如回源節(jié)點(diǎn)的特定能力只供特定客戶來用，他需要多少存儲，就可以通過上圖來進(jìn)行判斷。

4.3.2 服務(wù)器性能

第二塊是說我們的服務(wù)器性能。通常對CDN來講，如何找到特定的緩存，它的時效性非常關(guān)鍵。通常大家會通過HASH算法來做，我們認(rèn)為HASH算法在小范圍的情況下，HASH算法是非常有效的。如果在切片的情況下文件特別多；用戶量大的情況下，文件特別多時，HASH算法的效率就不會很高。在這種情況下，我們Akamai就采用布隆過濾器，我們通過布隆過濾器和專有的算法，當(dāng)請求到來的時候它的時延可以做到最低，當(dāng)然它不能保證你的緩存能100%被找到，它有一定的錯誤率，但這個錯誤度是可以去做平衡的。采用了我們的布隆過濾器和更好的搜索算法，服務(wù)器的命中率，包括網(wǎng)絡(luò)的使用率和硬盤的效率都有提升。上圖顯示的是采用前后的變化，可以看出采用前每秒的寫入數(shù)是更高的，采用后，每秒的寫入數(shù)變少，從而使緩存的查找效率變高。

4.3.3 磁盤延遲

第三塊是指磁盤的延遲。磁盤的延遲對于CDN來講很關(guān)鍵，我們希望能夠把內(nèi)容盡快吐出去，所以磁盤延遲是非常重要的。當(dāng)然，磁盤的延遲和文件的大小是有關(guān)的。通常情況下，磁盤有個零延遲的閾值，這個值大概是800k左右，但通過Akamai的優(yōu)化以后，當(dāng)值大于800k時或者更大一些的時候，磁盤延遲依舊可以降到比較低的程度。

4.3.4 邊緣計(jì)算實(shí)現(xiàn)源站卸載

上圖內(nèi)容是關(guān)于如何去降低源站壓力。比如可以把源站的邏輯和計(jì)算卸載到CDN邊緣實(shí)現(xiàn)，通常的計(jì)算包括邊緣鑒權(quán)和中央鑒權(quán)、防盜鏈，甚至做一些業(yè)務(wù)邏輯，做一些訪問的控制，如特定的區(qū)域用戶才能訪問這個內(nèi)容，所以很多業(yè)務(wù)邏輯需要在邊緣里去實(shí)現(xiàn)的。我們Akamai希望能夠把更多的業(yè)務(wù)邏輯下沉到邊緣，我們認(rèn)為CDN是天然的、非常適合做邊緣的平臺，所以在CDN作為邊緣計(jì)算的情況下，我們可以有效降低源站壓力，把很多復(fù)雜的計(jì)算從源站扔到邊緣里去做，這樣一方面可以降低運(yùn)維方面的壓力，另一方面可以降低業(yè)務(wù)部門對運(yùn)維的壓力。比如說，基于 Token Authentication，并基于分布式控制，控制某個內(nèi)容的訪問頻率，區(qū)域的限制，甚至做一些AB TEST和token的一些計(jì)算等，很多的業(yè)務(wù)邏輯都可以到邊緣去實(shí)現(xiàn)。上圖是我們?yōu)橛《瓤蛻糇霭迩蚴澜绫辈r，它們訪問量非常大。在過去兩三年里，他們的直播閾值都在千萬級別，而且這些訪問都是在移動互聯(lián)網(wǎng)的基礎(chǔ)上來做的。可以看到，印度的版權(quán)方在培養(yǎng)了幾年的用戶習(xí)慣之后，他們在去年逐漸地做收費(fèi)的策略，有收費(fèi)之后就會出現(xiàn)版權(quán)墻，很多人會嘗試去突破版權(quán)墻來達(dá)到免費(fèi)收看的問題。但因?yàn)橛《鹊闹辈ナ乔衅龅?#xff0c;在做切片時，你怎么把用戶的訪問給吊銷掉，也就是說，過邊緣或者源站的業(yè)務(wù)邏輯判斷出你是一個盜鏈用戶，或你是一個非付費(fèi)用戶的情況下，如何在你還在訪問的情況下把你的訪問給吊銷掉，可以在邊緣實(shí)現(xiàn)。所以一開始可以看到盜鏈的情況會非常高，但隨著在邊緣開始做封禁，它的量級就會慢慢下降，當(dāng)然你很難禁掉所有的盜鏈，所以要在維持一定成本的情況下把盡量多的盜鏈給禁掉。

4.3.5 全球網(wǎng)絡(luò)

最后一點(diǎn)我們從Akamai網(wǎng)絡(luò)建設(shè)層面做的一些事情，從全球網(wǎng)絡(luò)來看，用戶訪問到你的源站分為三個部分:第一個部分是first mile，也就是用戶到CDN節(jié)點(diǎn)，這一塊的事情依然延續(xù)Akamai過去一直在做的把邊緣節(jié)點(diǎn)靠近用戶，讓first mile對用戶的影響更小，你的CDN越接近用戶，你的last mile的影響數(shù)就越小。第二部分是middle mile，指的是從CDN 節(jié)點(diǎn)到源站之間的網(wǎng)絡(luò)，這一塊是CDN 發(fā)揮非常大的作用的一個地方，能把你中間回源的路徑，它的丟包、時延和帶寬的效率提升。Akamai有一些動態(tài)的選路機(jī)制，選擇各個不同運(yùn)營商的路徑；另一方面我們也建設(shè)了專線網(wǎng)絡(luò)，這樣能把Akamai一些中間層的點(diǎn)直接連接起來，讓Akamai有更多的選擇空間。很多客戶希望CDN的回源盡可能小，Akamai做了兩個方面，一方面是我們的CDN節(jié)點(diǎn)可以和用戶的源站建立直連，通過Cross Connect直連的方式和你的源站連接起來，當(dāng)然這時在源站流量特別大的情況下，比如至少10G以上，這樣我們的直連才有意義；第二方面是Akamai在靠近用戶源的地方部署了一些專有緩存，這個緩存就是利用了剛才的緩存算法能算出來多大的緩存量就能夠回源一次，這樣我們就能為某一個客戶劃定一個存儲空間來實(shí)現(xiàn)他的專有緩存回源盡可能少的一個場景。

總之，視頻技術(shù)在各個方面都在快速發(fā)展，流媒體的未來會向著更加高效、融合、統(tǒng)一的方向演進(jìn)。謝謝大家。

- The cover?by?Sarah?Pflug from Burst

講師招募 LiveVideoStackCon 2021 北京站

LiveVideoStackCon 2021 北京站（9月3-4日）正在面向社會公開招募講師，歡迎通過?speaker@livevideostack.com?提交個人及議題資料，無論你的公司大小，title高低，老鳥還是菜鳥，只要你的內(nèi)容對技術(shù)人有幫助，其他都是次要的，我們將會在24小時內(nèi)給予反饋。

總結(jié)

以上是生活随笔為你收集整理的流媒体的未来——视频技术如何演变的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。