在當今競爭激烈的商業環境中，企業越來越需要構建自己的即時通訊工具來提升內部溝通效率和信息安全，減少第三方工具依賴帶來的潛在風險，并能與自身的行業業務深入融合。

擁有專用的通訊平臺能夠加快信息的流動，提升工作協同和任務執行效率。此外，自定義的通訊工具還能增強企業對通訊數據的掌控，降低數據泄露和濫用的風險。同時，它也為團隊協作和創新提供了便捷的溝通工具，促進了信息的共享和問題的解決，對提升企業的競爭力和創新能力有積極作用。

那如何來構建點對點的即時通訊工具呢？

眾所周知，瀏覽器之間通常不能直接通信，需要通過服務器中轉。但這種方式效率較低，不適合數據流傳輸。因此，WebRTC(Web Real-Time Communications)項目應運而生。

它是一項開源的實時通訊技術，為瀏覽器提供了簡單的JavaScript接口，允許通訊雙方在不借助中間媒介的情況下，建立點對點（Peer-to-Peer）的連接，實現視頻流、音頻流或其他任意數據的傳輸。此外，WebRTC是一個跨平臺的多媒體框架，支持Android和iOS設備，使它們能像瀏覽器一樣進行即時通信。

綠色部分是 WebRTC 核心部分（核心庫）

紫色部分是 JS 提供的 API（應用層），整體是應用層調用核心層。

雖然WebRTC的最終目主要是讓開發者能夠基于瀏覽器輕易快捷開發出豐富的實時多媒體應用，但是除了媒體捕獲和處理模塊我們不用太多關心外，我們還是要自建信令服務器，交換并協商雙方的媒體與網絡信息；搭建網絡打洞服務器，實現網絡通訊；還需要嚴格控制媒體通道的建立時序，保證媒體通道的正常建立。

以下將從3個方面來討論WebRTC的構建過程。

WebRTC的連接需要依賴于兩類服務器：信令服務器與ICE（Interactive Connectivity Establishment，互動式連接建立）服務器。

信令服務器：是整個連接建立的驅動核心，用于控制系統中各個模塊之間的前后調用關系，包括：

包括媒體協商和網絡協商2個階段，涉及3種角色：ICE服務（綠色）、信令服務（黃色）、客戶端（藍色）。

當通訊的一方或者雙方不是公網地址時，就需要通過STUN/TURN協議繞過NAT進行網絡打洞。

STUN（Session Traversal Utilities for NAT，NAT會話穿越應用程序）用來取外網地址，以嘗試是否可以P2P通訊，而TURN（Traversal Using Relay NAT，通過中繼方式穿越NAT）則通過中繼轉發來通訊。

STUN基于一個簡單的觀察，當NAT內的客戶端訪問公網服務器時，服務器看到的是NAT設備的公網地址。將該信息通過信令服務告訴對端，后者就知道該和哪個地址建立連接了。

TURN允許通過UDP或TCP方式穿透NAT?？蛻舳讼扰cTURN服務進行交互，分配中繼轉發地址?？蛻舳藢祿魉椭猎撝欣^轉發地址，再由它中轉到另一方的客戶端上。

WebRTC本身提供的是1對1的通信，如果想要實現多對多模式，常見的有3種方案：MCU（Multipoint Control Unit）、SFU（Selective Forwarding Unit）和Mesh（網狀網絡）。

Mesh 即多個終端之間兩兩連接，形成網狀結構，一個終端需要同時向其他終端發送數據。

以n代表連接終端數，每一個終端都要與n-1個終端通訊，所以總連接數=n*(n-1)，上行帶寬=下行帶寬=總連接數*連接帶寬=n*連接帶寬。

優點：去中心化，每個節點直接與其他節點通信，具有高度的容錯性和可擴展性。適用于對可靠性要求較高的場景。

缺點：需要更多的帶寬，當節點數量增加時，網絡延遲可能會增加。

MCU由一個服務器和多個終端組成星形結構。各終端將自己要共享的音視頻流發送給服務器，服務器將音視頻流混合后再發給其他終端。

總連接數=n，上行帶寬=下行帶寬=總連接數*連接帶寬=n*連接帶寬。

優點：可以集中處理視頻流，提供強大的控制和管理功能。適合小規模會議和需要集中控制的場景。

缺點：存在單點故障風險，如果MCU出現故障，整個系統可能會中斷。需要較高的帶寬和計算資源來處理多個視頻流，服務器壓力非常大。

SFU也是由一個服務器和多個終端組成，但與 MCU 不同的是，SFU 不對音視頻進行混流，收到某個終端共享的音視頻流后，就直接將該音視頻流轉發給其他終端。

每一個終端都有對SFU服務器有1個上行連接，還有n-1個下行連接，總連接數為n+(n-1)*n，上行帶寬=n*連接帶寬，下行帶寬=((n-1)*n)*連接帶寬。

優點：分布式架構，可以選擇性地轉發視頻流。不進行混合或轉碼，服務器壓力小。較低延遲和較好擴展性，適用于大規模實時視頻應用。

缺點：不提供集中式的控制和管理功能，因此需要在應用層實現一些額外的邏輯。此外，SFU需要較高的帶寬來處理多個并發的視頻流。

總的來說，選擇適合的實時視頻方案取決于具體的應用場景和需求。MCU適合小規模會議和需要集中控制的場景，SFU適用于大規模的實時視頻應用，而Mesh適用于對可靠性要求較高的點對點通信場景。

只要涉及到音視頻相關的應用WebRTC都有用武之地，以下列舉了部分應用場景。

視頻會議作為WebRTC 最常用的場景之一，已經被廣泛的應用在企業、教育、醫療等領域。它可以實現實時視頻、音頻傳輸，同時還可以支持屏幕共享、白板等功能，使得遠程協作變得更加便捷。

實現在線客服場景下的實時視頻、音頻交流，方便用戶與客服人員進行溝通。此外，還可以支持屏幕共享、文件傳輸等功能，幫助客服人員更好地解決用戶的問題。

可以實現一方有難八方協助的場景，通過屏幕共享、實時音視頻，幫助后端專家可以同時指導并協助現場人員解決問題。

在線教育場景下，可以實現教師和學生實時的視頻、音頻交互，同時支持屏幕共享、白板等功能，幫助學生更好地理解課程內容。

在線考試場景下，可以實現考生桌面和面部的監控，監控考生是否有切換桌面，是否有線下查看資料，還能錄制整個考試過程，便于后期追述。

可以實現互動直播場景下的實時視頻、音頻交互，同時支持彈幕、禮物等功能，提高用戶的參與度。

可以實現遠程醫療場景下的實時視頻、音頻交互，同時支持圖像傳輸、遠程診斷等功能，方便醫生和患者之間的遠程溝通和診療。

可以用于實時文件共享和協作，在線進行文件傳輸、編輯和協作，提高團隊的工作效率和協同能力。

可以實現主機資源的安全訪問，先通過賬號限定可訪問的主機，再通過遠程訪問技術實現遠程主機的完全登錄與遠程控制。

WebRTC雖然提供了簡單的API來實現點對點的音視頻通訊，但是如果應用不當，很容易現在性能問題與客戶體驗不佳的情況。以下是在項目過程中總結的一些經驗與注意事項。

Websocket需要一直保持著長連接，服務器需要為每個連接分配一定的內存和處理資源，如果一個業務一條連接，將造成連接數的劇增，服務器就需要更多的資源來維持。所以需要多路復用，讓各類業務同享信息通道，通過消息類型區分不同業務。

實時視頻通訊需要足夠的網絡帶寬。而且客戶端需要進行編碼、解碼和處理，這對于設備的處理能力要求較高。特別是在高分辨率和高幀率的情況下，需要更強大的處理器和圖形處理單元（GPU）來實時處理視頻數據，造成終端的CPU占用偏高。以下是6個連接終端通過Mesh連接的帶寬情況。

同時開啟音視頻的帶寬差不多39.6Mb/s。

同時關閉攝像頭只開語音的帶寬差不多3.15Mb/s。

從上面的測試結果看，開不開啟視頻帶寬上相差有13倍。而且在開啟視頻的情況下，i5的cpu終端在連接4個終端時cpu達到40%，9個終端時CPU就達到100%了，而只開音頻的情況下cpu就占用很小。

所以在視訊過程中建議新接入的終端默認關閉攝像頭，在視頻分享時盡量只有一個終端，其他參與方只開音頻。

視頻會占用比較大的帶寬，640*480視頻流一路帶寬差不多1Mb/s。這樣1Gb/s（1000Mb/s）的帶寬最多只能支持1000個視頻連接。在整個系統中，我們除了視頻，還需要分出一部分帶寬給業務應用功能，所以需要限制同時在線的最大視頻人員數，超過該數值后，將不允許開啟新的視頻連接。