網路直播對實時通信的技術要求有多高？
題主指的實時通信是視頻本身還是針對直播中的即時通訊，就是聊天室，可以互動送禮物點贊這種通信？
已經有答案把直播架構各個環節應該說的都已經介紹全了，本文就從一個技術瓶頸最大的問題來說——延時。網路直播按需求場景，可以分為兩種：高延遲直播，低延遲實時互動直播。
- 高延遲直播：是單向傳輸，只有主播端數據下行到觀眾端。
- 低延遲實時互動直播：是雙向的，既有主播端到觀眾端的下行視頻流，也有觀眾端到主播段的上行視頻流。
高延遲直播：通過CDN進行內容分發，大多數直播平台的做法是，同時選擇多家CDN服務商。這種方案的延遲一般是2秒到數十秒。這種方案，是目前的主流方案。
- 從架構實現上來說，採用了CDN進行內容的緩存分發。不大可能像某友商說的達到毫秒級延遲。
- 從需求上來說，由於主播和觀眾沒有互動。因此，CDN方案沒有動力將延遲從秒級降低到毫秒級
北京-上海，距離1200km，往返延時12ms
北京-紐約，距離11000km，往返延時110ms
赤道周長，距離40000km，往返延時400ms
這個速度，可以理解為一條專線拉到頭的速度。因此，某些宣傳說自己零延遲的，基本是違背物理規律了。
實際應用中，拿北京到上海舉例，主播端的視頻、音頻數據，要經過- 主播的硬體設備前處理-編碼：
- 傳輸：中間要經過數個機房、小區寬頻、用戶的路由器，
- 到達用戶終端設備，經過用戶設備硬體設備解碼，後處理，最終呈現到播放出來。
每一個環節都會產生延時。
回答題主的問題，網路直播對實時通信的技術要求有多高？1、編解碼技術。在保證音質、畫質的前提下，盡量做到低碼率。碼率越低，數據包越小，傳輸越快。2、網路傳輸架構改造。我司沒有採用基於TCP協議的CDN方案，從底層協議和布網上開始，創建了基於UDP協議的SD-RTN方案。全球端到端，延時平均76ms。端到端是指，從編碼器發出開始，進入解碼器之前的延時。包含兩地傳輸、server之間的傳輸、Lastmile的策略。不含捕捉、播放、編碼、解碼的延時。由於一些童鞋對平均延時76ms這個數字提出了一些質疑，補充幾個圖。（下圖的數據，取自我們某客戶，量級足夠進行數學統計，8月20日-9月1日的數據。
直播中一方面是視頻的直播，另外一方面用戶可以和主播互動，發文字消息、點贊、送禮物。這個其實用到的是im即時通訊中的聊天室的功能。也是題主所說的對實時通信的要求。
一、聊天室架構應滿足哪些條件
高可用：任何一個節點故障都不應該引起服務不可用；
易擴展：具有水平擴展的特性，對不同量級的在線用戶數都有應變的能力；
高並發低延遲：能支持大量的用戶同時收發消息，消息從發出到送達所有在線端的延時在毫秒級；
客戶端兼容性：新型的應用都是能同時跨多種設備實現消息互通的，比如網頁端，手機端和桌面端，甚至智能電視等。
二、設計架構
客戶端層
處理各種設備的兼容問題，包括對ios，Android，Windows， Web等各種開發平台的語言適配；消息通道的管理維護，包括移動設備上的弱網路管理，斷線重連等；保證數據安全，所有上行下行的數據包都需要加解密處理，規避數據泄露或中間人攻擊等各種安全風險。
網關接入層
管理大量客戶端連接，單個節點可以維護的客戶端數量在數十萬量級；處理不同類型客戶端的協議兼容，由於客戶端實現技術的多樣性，導致客戶端與網關之間底層的數據通信協議存在差異，需要由不同的接入網關做協議轉換；處理數據安全邏輯；跨網路的高可用邏輯，網路級別的主備(誰知道哪天網線會被藍翔的畢業生挖斷呢?)；廣播消息的高效下行分發，將收到的廣播消息分發到所有連接在本節點上的客戶端。
路由層
作為業務層接入的中轉，同時承擔負載均衡和高可用的作用，單個業務節點處理能力達到瓶頸時更方便的擴容，路由層使業務層擴容對前置網關層完全透明；當一個網路的業務集群出現網路故障時，可以切換到備用網路，保證服務可用性。
業務層
處理聊天室內的業務消息，一個集群內有眾多節點，節點角色相互對等，任何一個節點的故障會使整個集群的處理能力下降，但不會引起服務的中斷，因為其他節點可以繼續接管業務數據包的處理；業務集群同樣有多個網路環境的熱備，以應對可能出現的區域性網路故障。
三、難點在哪裡
客戶端多樣性
目前的應用都存在跨平台的需求，iOS、安卓和PC端，網頁端，甚至IOT物聯網設備，能連多少是多少，多多益善；但是不同開發平台之間的技術差異性極大，不是所有公司都有這麼全的全棧程序猿的；如果團隊開發的話單就客戶端開發人員就不是幾個人可以完成的。
數據安全的保證
當前的網路安全形勢異常複雜，開發應用時如果不在通信安全上花心思，那你的用戶就是在互聯網上裸奔；開發者需要針對不同的平台，不同的通信技術實現可靠的安全方案，避免用戶數據在傳輸過程中泄露，避免中間人攻擊等安全風險。
跨機房網路級的高可用方案
當機房網路出現故障時把責任推給市政施工隊或者「網路抽風」已經不流行了，用戶需要的是故障無感知。
所有環節的單點故障排除
任何硬體和軟體都存在故障的可能，我們無法避免應用罷工，那就需要隨時準備替補上場。
能應對任何用戶量級的需求
架構級做到水平擴展的能力，當用戶量增長時隨時可以通過堆伺服器來解決，而不是將架構推倒重來。
四、這麼難？怎麼做
技術發展到現在已經不流行重複造輪子了，因為輪子的結構越來越複雜，功能性和非功能性的指標要求越來越高；而我們的用戶卻不會再等我們了。當我們還在畫輪子的圖紙的時候，競爭對手可能已經把車子都造好，在路上跑了。雖然我們不是非得自己造輪子，但是了解如何完成一個完美的輪子的製作過程和質量標準卻是非常有必要的，這也是我前面和你介紹了這麼多的原因。
就像近幾年大數據技術非常流行，如果你對這個領域有所了解你就會發現幾乎所有公司都在使用現有的平台，比如Hadoop；或者直接使用，或者在上面做二次改造，原因無非就是上面說的幾點。現在你遇到的也是同樣的問題，聊天室這種功能在最近兩年又火了起來，主要還是視頻直播業務的大規模擴張；所以能借用目前已有的平台或工具是最快捷的路徑，應用需要關注的是怎麼以最快的速度抓住用戶。
五、利益相關
我們團隊是做IM、直播技術的，底層架構都是做好的，開放給開發者sdk和api介面，開發者接入後就可以實現直播的功能。感興趣可以加我的qq3103607948 細聊。
知乎專欄 這篇文章彙集了我對這個行業的理解，歡迎大家指點。
現在的通信技術都能滿足一般的網路直播。直播最大的問題就是延時，交互要求高的延時要低，交互要求低的，延時就不大重要。見的最多的主播與觀眾互動，延遲在一般在4s—10s。
延遲主要是涉及到兩個技術。- 編解碼技術。在保證音質、畫質的前提下，盡量做到低碼率。碼率越低，數據包越小，傳輸越快。又拍直播雲支持在線實時轉碼，支持一轉多（一次性將直播畫面轉碼成適合各種設備播放的格式、解析度的多條直播流），適配不同網路、解析度的終端設備，並能夠根據終端設備接入的網路質量實現多碼率無縫切換。
- 網路傳輸技術：現階段流行的視頻直播，其主要手段是通過 TCP/IP 協議來進行通信。從架構實現上來說，採用了CDN進行內容的緩存分發。
知乎首答
先說答案
1.視頻通話對講，延時300ms可用2.視頻直播，文字或者信息互動（就是你發個圖支持，發個禮物這樣的）1200ms內可用3.視頻直播.音頻對講，延時500ms內可用
任何直播其實都有延時，只是延時對業務有沒有影響是看場景的，交互要求高的延時就要低，交互要求低的你也看不出來，實際上電視台做節目直播都上延時器延時30s-120s的，你也沒覺得有什麼問題，這是因為你不需要跟主持什麼的做互動。
但是一旦需要互動就要考慮到互動的場景要求有多高，你在做手術，教授都叫停了你刀子還在划了2秒就不合適吧，這時就要求更低的延時
開個網上課程，學生看著老師講課又不允許直接對話發言的，只能打字打賞老師看著好高興，回你幾句話多謝客官什麼的，這種延時1-2秒其實也沒啥
其它的什麼tcp udp rtsp rtmp 之類的協議在一般直播上都不存在問題，但是到了極端情況下需要交互的場景中，就是要控制好整改過程了，特別是解碼器的緩衝區要儘可能的低。多年前做過基於3G網路的視頻會議系統，各種抓包分析，對比。得到的經驗是一切基於TCP的RTC都是耍流氓。
原因在於移動網路包括wifi的丟包可能性遠遠大於Cable network，而TCP則要丟包重傳。
一個優秀的實時視頻應用要有如下功能：帶寬檢測，在完成初始帶寬協商後還要能再會議中實時檢測丟包情況，動態調整碼流，解碼器對丟包的兼容等，還要考慮防火牆穿透問題。伺服器要可以同時提供不同碼率的編碼，解碼這一塊基本都是用的webrtc，包括csiso在內的眾多解決方案提供商都是在webrtc的基礎上包裝。
編碼加組播
一般直播需要比較好的移動信號，wifi不行用4G是常態。如果移動信號不好，那麼移動wifi信號也好不到哪去。比如工體，除非有專門wifi通道，否則是無法正常進行移動直播的。說到4G問題就來了，流量怎麼辦？哈哈，各家直播平台都有補貼啊！——以上說的是手機直播
如果是傳統直播推流到終端，那麼必須得有wifi專線，看要求到什麼質量，一般拍攝團隊會要求在512以上。
現在的通信技術都能滿足一般的網路直播，就看你本身有什麼特殊的要求，比如質量要達到多高？
推薦閱讀：