在當今（jīn）競爭（zhēng）激烈（liè）的商業環境中，企業越（yuè）來越需要構建自己的即（jí）時通訊工具來提升內部溝通效率和（hé）信息安全，減少第三方工具依（yī）賴帶來的潛在風險（xiǎn），並能與自身的行業業務（wù）深入融合。
擁有（yǒu）專用的通訊平台（tái）能夠加快信息的流動，提升工作協（xié）同和任務執行效率。此外，自定（dìng）義的通訊工具還能增強企業對通訊數據的（de）掌控，降低（dī）數據泄露和濫用的風險。同時，它也（yě）為（wéi）團隊協作和創新提供了便捷的溝通工（gōng）具，促進了信息的共享和問題的解決（jué），對提升企業的競爭力和創新能（néng）力有積極作用。
那如何來構建點對點的即時（shí）通訊工具呢？
眾所周知，瀏覽（lǎn）器之間通常不能（néng）直（zhí）接通信，需要通過服務器中轉。但這種方式（shì）效率較低（dī），不適合數據流傳輸。因此，WebRTC(Web Real-Time Communications)項目應運而生。
它（tā）是一項開源的實時通訊技術，為瀏覽器提供了簡單的JavaScript接口，允許通訊雙方在（zài）不借助中間媒介的情況下（xià），建立點對點（Peer-to-Peer）的（de）連接，實現視頻流、音頻流或其他任意（yì）數據的傳輸。此外，WebRTC是一個跨平台的多媒體框架，支持androids和ioses設備，使它們能像瀏覽器一樣進行即時通信。
綠色部分是 WebRTC 核心部分（核心庫）
第（dì）一層 C++ API：提供給外麵的接口，最主要的是（PeerConnedtion 對等連接）
第（dì）二層 Session：上下文管理層（音視頻）
音視（shì）頻引擎：編解碼；音頻緩衝 BUFFER 防止音頻網絡（luò）抖動 NetEQ；回音消除；降噪；靜音檢測
視頻引擎 ：編解碼；jitter buffer 防止（zhǐ）視頻網絡抖（dǒu）動；圖像處（chù）理增強
傳輸：SRTP 加密後（hòu）的 RTP；多路複用；P2P（STUN+TURN+ICE)
第四（sì）層是硬件相關層（céng），包括音視頻采集；網絡（luò） IO
紫色部分是 JS 提（tí）供的 API（應用層），整體是應用層調用核心層。
雖然WebRTC的最終目主要是讓開發者能夠基於瀏覽器輕易快捷開發出豐富的實時多媒體應用，但是除了媒體（tǐ）捕獲和（hé）處理模（mó）塊我們不用太多關心外，我們還是要自建信令服務器（qì），交換並協商雙（shuāng）方的媒（méi）體與網絡信息（xī）；搭建網絡打洞服務（wù）器，實現網絡（luò）通訊（xùn）；還需（xū）要嚴格控製（zhì）媒體通道（dào）的建立時序，保證媒體通道的正常建立。
以下將從3個（gè）方麵來討論WebRTC的構（gòu）建過程。
WebRTC的連接需要依賴（lài）於兩類服（fú）務器：信（xìn）令服務器與ICE（Interactive Connectivity Establishment，互動式連接建立）服務器（qì）。
信令服務器：是整個連接建立的驅動核（hé）心（xīn），用於控製係（xì）統中各個模塊之（zhī）間的前後調用（yòng）關係（xì），包括（kuò）：
實現業務管理：如用戶創建房間，加入房間，退出房間等。
交換網絡信息：交（jiāo）換彼此的IP地址和（hé）端口，為（wéi）網絡穿透作準備（bèi）。
交換媒體信息（xī）：交換彼此（cǐ）的（de）媒體信息（xī），為媒體協商作準備。
ICE服務器：負責網絡的打洞，包括STUN與TURN服務。
包括媒（méi）體協商和網絡協商2個階段，涉及3種角色：ICE服務（綠（lǜ）色）、信令（lìng）服務（黃色）、客戶端（藍（lán）色）。
Client A和Client B連接信（xìn）令服務。A為發起方（Offer），B為回應方（fāng）（Answer）。
A先創建PeerConnection對象，然後通過addLocalStream將其加入（rù）。
A調用createOffer方法生成SDP(Session Description Protocol)，先調用setLocalDescription本地保（bǎo）存，接著通過（guò）信令服務器轉（zhuǎn）發給B。
B收到A的SDP後（hòu）先創建自己的PeerConnection，將本地的媒體流加入到其中，然後調用（yòng）setRemoteDescription保存A的（de）SDP。
B調用createAnswer方法（fǎ）生（shēng）成B的SDP，先setLocalDescription本地保存，再通過信令服務轉發給A。
A收到B的SDP後，調用setRemoteDescription保存，這樣媒體協商（shāng）就完成了。
通過向ICE服務器（qì）詢問來獲取網絡候選對象Candidate，包括原（yuán）始、NAT映射、ICE轉發的IP地址與端口。
客戶端通過信令服務器交換網絡信息，同時嚐試打洞與連接（jiē）。
如果打洞成功則進行（háng）點對點通訊，不（bú）然則通過ICE服務器中轉。
當通訊的（de）一（yī）方或者雙方不是公網地址時，就需（xū）要通過STUN/TURN協議繞過NAT進行網絡打洞。
STUN（Session Traversal Utilities for NAT，NAT會話穿越應用程序）用來取外網（wǎng）地址，以嚐試是否可以P2P通訊，而TURN（Traversal Using Relay NAT，通過中繼方式穿（chuān）越NAT）則通過中繼轉發來通訊。
STUN基於一個簡單的觀察，當NAT內的客戶（hù）端訪問公網（wǎng）服務（wù）器時，服務（wù）器看到的是NAT設備的公網地址。將（jiāng）該信息通過信令服務（wù）告訴對端，後者就知道該（gāi）和哪個地址建立連接了。
TURN允許通過UDP或TCP方式穿透NAT。客戶端先與TURN服務進行交互，分配中繼轉（zhuǎn）發地（dì）址。客戶端將數據傳（chuán）送至該中繼轉發地址，再由它（tā）中轉到另一方的客戶端（duān）上。
WebRTC本身提（tí）供的是1對1的通信，如果想要實現多對多模式，常見的有3種方案：MCU（Multipoint Control Unit）、SFU（Selective Forwarding Unit）和Mesh（網狀網（wǎng）絡）。
Mesh 即多個終端之間兩（liǎng）兩（liǎng）連（lián）接（jiē），形成網狀結構，一個終端（duān）需要同時向其他終端發送數據。
以n代表連接終端數，每一個（gè）終端都（dōu）要與n-1個終端通訊，所以總連接數=n*(n-1)，上（shàng）行帶寬=下行（háng）帶寬=總連（lián）接數*連接帶寬=n*連接帶寬。
優點：去中心化，每個節點直接與其他節點通信，具有高度的容錯性和可擴展性。適（shì）用於對可靠性要求較高的（de）場景。
缺點：需要更（gèng）多的帶寬，當節點數量增加時，網絡延遲可能會增加。
MCU由一個服務器和多（duō）個終端組成星形結（jié）構。各（gè）終（zhōng）端將自己要共享的音視頻流發送給服務器，服（fú）務器將音視頻流混合後再（zài）發給其他終端。
總連接數=n，上行帶寬=下行帶寬=總連接（jiē）數*連（lián）接帶寬=n*連（lián）接帶寬。
優點（diǎn）：可以集（jí）中處理視頻流，提供強大的控製和管理功能。適合小規模（mó）會議和需要（yào）集中（zhōng）控製的場景。
缺點：存在單點故障風險，如果MCU出現（xiàn）故障，整個係統可能會中斷。需要較高的帶寬和計算（suàn）資源來處（chù）理多個視頻流，服務器壓力非常（cháng）大（dà）。
SFU也（yě）是（shì）由一個（gè）服務器和多（duō）個終端組成，但與 MCU 不同的是，SFU 不對音視頻進行混流，收到某個終（zhōng）端共享的音視頻流後，就直接將該音視頻流轉發給其他終（zhōng）端。
每一個終端都（dōu）有對SFU服務器有1個上行連接，還有n-1個下行連接，總連接數為n+(n-1)*n，上行帶寬=n*連接帶寬，下（xià）行帶寬=((n-1)*n)*連接帶寬。
優點：分布式架構，可以選（xuǎn）擇性地轉發視頻流。不進行混（hún）合或轉碼，服務器壓力小。較低延遲和較好擴展性，適（shì）用（yòng）於大規模（mó）實時視頻應用。
缺點：不提供集中式的控製和管理功能，因此（cǐ）需要（yào）在應用（yòng）層實現一（yī）些額外的邏輯。此外，SFU需要（yào）較高的（de）帶寬來處理多個並發的視頻流。
總的來說，選擇適合的實時視頻方案取決於（yú）具體的應用場景和需求。MCU適合小規模會議和需要集中控製的場景，SFU適用於大規模的實時視頻應用，而Mesh適用於對可靠性要求較高的點對點通信場景。
隻要涉及到音視頻相（xiàng）關的應用WebRTC都有用武（wǔ）之地，以下（xià）列舉了部分應用場景。
視頻會議作為WebRTC 最常用的場景之一，已（yǐ）經被廣泛的應用在企業、教育、醫療等（děng）領域。它可以實現實時視頻、音頻傳輸（shū），同時還可以支持屏幕共享、白板（bǎn）等功能，使得遠程協作變（biàn）得更加便捷。
實（shí）現在線客服場景下的實時視頻、音頻（pín）交流，方便用戶（hù）與客服人員進行溝通。此外，還可以支持屏幕共享、文件（jiàn）傳輸等功能，幫助（zhù）客服人員更好地解決用戶的問題。
可（kě）以實現一方有難八（bā）方協助（zhù）的場（chǎng）景，通過屏幕共享、實時音視（shì）頻，幫助（zhù）後端專家可以同時指（zhǐ）導並協助現（xiàn）場人員解決問題。
在線教育場景下，可以（yǐ）實現教師和學生實時的視頻、音頻（pín）交互，同時支持屏幕共享（xiǎng）、白板等功能，幫助學生更好地（dì）理解課程內容。
在線考試場景下，可以實現（xiàn）考生桌麵和麵部的監控，監控考生是否（fǒu）有切換桌麵（miàn），是否有（yǒu）線下查看資料，還能錄製整（zhěng）個考試過程，便於後期追述。
可以實現互動直播場景下的實（shí）時視頻（pín）、音（yīn）頻（pín）交互，同時支持彈幕（mù）、禮（lǐ）物等功能（néng），提高用戶的參與度。
可以實現遠程醫療場景下（xià）的實時（shí）視頻、音頻交互，同時支持圖像傳輸、遠程診斷等功能，方便醫生和（hé）患者（zhě）之間的遠程溝通和診療。
可以用於實時文件共享和（hé）協作，在線進行文件傳輸、編輯和協作，提高團隊（duì）的工作效率和（hé）協同能力。
可以實現（xiàn）主機資源的安全訪問，先通過賬號限定可訪問的主機，再（zài）通過遠程訪問技術實現遠程主機的完全登錄與（yǔ）遠程控製。
WebRTC雖然（rán）提供了簡單的API來實現點對點的音視頻通訊，但是如果應用不當，很容易現在性能問題與客戶體驗（yàn）不佳的（de）情況。以（yǐ）下是在項目過程中總結的一些（xiē）經驗（yàn）與注意（yì）事項。
Websocket需要一直（zhí）保持著長連接，服務器需要為（wéi）每個連接分配一定的內存和處理資源，如果一個業務一條連接，將造成連（lián）接數的劇增，服務器就需要更多的資源（yuán）來維持。所以需要多路複用，讓各類業務同享信息通道，通過（guò）消息類型區分不同業務。
實時視頻通訊需要足夠的網絡帶寬。而且客（kè）戶端需要進行編（biān）碼、解碼和處（chù）理（lǐ），這對於設備（bèi）的處理能力要求較高。特別是在高分（fèn）辨率和高幀率的（de）情況下，需要更強大的處理（lǐ）器和圖形處理單（dān）元（GPU）來實（shí）時處（chù）理視頻數據，造成終（zhōng）端的（de）CPU占用偏高。以下是6個（gè）連接終（zhōng）端通（tōng）過Mesh連接的帶寬情況（kuàng）。
同時開啟音視頻的帶寬差不多39.6Mb/s。
同時關閉攝像頭隻開語音的帶寬差不（bú）多3.15Mb/s。
從（cóng）上麵的測試結果看，開不開啟視頻帶寬上相差有13倍。而（ér）且（qiě）在開啟視頻的情況下，i5的cpu終端在連接4個終端時cpu達到40%，9個終端時CPU就達到100%了，而隻開（kāi）音（yīn）頻的情況（kuàng）下cpu就占用很（hěn）小。
所以在視訊過程中建議新接入的終端默認關閉攝像頭，在視頻分享時盡量隻有一個終端，其他參與方隻開音（yīn）頻。
視頻會占用比較大的帶寬，640*480視頻流一路帶（dài）寬差不多1Mb/s。這樣1Gb/s（1000Mb/s）的帶寬最多隻能支持1000個視頻連接。在整個係統中，我們除了（le）視頻，還需要分出一部分帶寬給（gěi）業務應用功能，所以需要限製同時在線的最大視頻人員數，超過該（gāi）數值後，將不允許開啟新的視頻連（lián）接。