我本人其實對於直播相關業務的參與度並不高，也並不了解這些直播使用的底層技術，只是偶然進入了一次webrtc技術分享會議，發現對於直播技術的探索過程是與計算機網路相關知識息息相關的，於是就進行回看記錄總結，希望能與各位分享。
屬性單向直播
雙向互動直播
推拉流方式
單向推拉流
雙向推拉流
延時3-10s
1s以內
網路傳輸協議
rtmp+tcp
rtcp(rtp)+udp粘包
由於tcp可視為流式的傳輸層協議，因此所有基於tcp的應用層協議，都需要注意「粘包」的問題，而rtmp協議使用定長資料塊的方式解決問題。
傳輸的延時累計
tcp協議是可靠的傳輸協議，在網路傳輸中如果遇到丟包或者超時，便會等待及對資料報進行排隊重傳，從而導致延遲不斷的累計。
如何解決網路層面帶來的延時？優化tcp協議的丟包重傳策略，我們都知道tcp在丟包情況下採用的擁塞控制演算法對應的「擁塞發生」演算法非常暴力如下圖所示，將傳送端的傳送視窗急劇縮小，導致後面延時累計。因此我們可以不再使用預設的擁塞控制演算法，比如bbr等來優化。
再不濟，我們使用基於udp的rtmp協議也可以，不用傳送、接收確認，不用被「君子協議」擁塞控制演算法綁架，況且對於直播這種對於資料報傳輸可靠性沒那麼高的應用場景來說（當前丟了幾幀，後面立刻補上了），udp算是比較適合的。
面臨的互相發現問題
由於ipv4位址數量的問題，我們每個接入網際網路的個人電腦都需要通過nat位址轉換協議。
如下圖所示假設a主機想訪問網際網路伺服器c，那麼首先它首先把訊息發出給nat路由器。路由器記錄了它的內網位址和埠，並且給它分配乙個全域性位址和全域性埠。這個位址關係記錄在nat路由表中。之後按照目的位址發給伺服器。一段時間之後，伺服器回應了請求給nat路由器，那麼路由器根據目的位址和埠（此時是全域性的）按照nat路由表轉換為對應的主機位址，再傳送給主機，這樣主機就收到了伺服器的回應。
因此如何將自己的機器與網際網路中的另外一台機器建立起網路連線，這就是peer-to-peer需要面臨的經典「nat打洞」問題。肯定還是需要借助伺服器幫助的，通過中間伺服器，交換兩邊機器的「位址」資訊，然後建立tcp長連線，使用keep-alive引數保證。而nat的多種型別，導致真實場景遠比想想中複雜的多。
錐型nat，有完全錐型、受限制錐型、埠受限制錐型三種：
full cone nat（完全圓錐型）：從同一私網位址埠192.168.0.8:4000發至公網的所有請求都對映成同乙個公網位址埠1.2.3.4:62000 ，192.168.0.8可以收到任意外部主機發到1.2.3.4:62000的資料報。
address restricted cone nat （位址限制圓錐型）：從同一私網位址埠192.168.0.8:4000發至公網的所有請求都對映成同乙個公網位址埠1.2.3.4:62000，只有當內部主機192.168.0.8先給伺服器c 6.7.8.9傳送乙個資料報後，192.168.0.8才能收到6.7.8.9傳送到1.2.3.4:62000的資料報。
port restricted cone nat（埠限制圓錐型）：從同一私網位址埠192.168.0.8:4000發至公網的所有請求都對映成同乙個公網位址埠1.2.3.4:62000，只有當內部主機192.168.0.8先向外部主機位址埠6.7.8.9：8000傳送乙個資料報後，192.168.0.8才能收到6.7.8.9：8000傳送到1.2.3.4:62000的資料報。
把所有來自相同內部ip位址和埠號，到特定目的ip位址和埠號的請求對映到相同的外部ip位址和埠。如果同一主機使用不同的源位址和埠對，傳送的目的位址不同，則使用不同的對映。只有收到了乙個ip包的外部主機才能夠向該內部主機傳送回乙個udp包。對稱的nat不保證所有會話中的(私有位址，私有埠)和(公開ip，公開埠)之間繫結的一致性。相反，它為每個新的會話分配乙個新的埠號。
需要根據不同的nat型別，採用不同的打洞方案，具體可見參考內容。
如果webrtc技術只是在nat方面需要伺服器的一點小小的「協助」，如下圖的mesh模式，那麼在多人會話的場景下也會給端上帶來很大的效能問題，因此也衍生了2和3。
這篇文章借助直播技術學習，發現了在直播技術探索中遇到的很多網路上的問題，包括傳輸層協議tcp特性：丟包重傳、擁塞控制、流式傳輸帶來的延時累計、應用層粘包等問題。也有webrtc中遇到的nat技術帶來的如何在peer-to-peer場景中互相發現的難題，大資料量的傳輸問題。希望跟大家一起以點知面，借助這些真實的場景完善自己的網路相關知識。正如上面直播技術演進中對於網路問題的探索，感覺一些生硬的知識，只有在遇到相應的問題時才能感受到學習他帶來的愉悅感。
nat打洞：
webrtc多方會話方案：
直播技術中的基礎網路知識
我本人其實對於直播相關業務的參與度並不高，也並不了解這些直播使用的底層技術，只是偶然進入了一次webrtc技術分享會議，發現對於直播技術的探索過程是與計算機網路相關知識息息相關的，於是就進行回看記錄總結，希望能與各位分享。屬性單向直播 雙向互動直播 推拉流方式 單向推拉流 雙向推拉流 延時3 10s...
無線與網路技術的增強與演進學習總結
1 基帶，通常指手機中的基帶晶元或基站的基帶處理單元。而其中處於這個頻帶的訊號，則稱為基帶訊號，其頻率範圍在0頻附近。這些訊號會通過基帶中的ad數模轉換電路，完成取樣 量化 編碼，變成數碼訊號。而手機中基帶負責完成流動網路中無線訊號的解調 解擾 解擴和解碼工作，並將最終解碼完成的數碼訊號傳遞給上層處...
網路中的交換技術
計算機網路交換技術 computer network switching technology 指的是對資料交換進行實施的技術，它包含線路交換技術 報文交換技術 分組交換技術。電路交換 整個報文從源點到達終點，不中斷，像在一條管道中傳輸 報文交換 整個報文傳輸到相鄰節點，儲存下來，再根據 表，到下乙...