WebRTC是实现浏览器视频通话的核心技术，它通过JavaScript API实现p2p音视频通信。首先调用getUserMedia()获取本地音视频流，再创建RTCPeerConnection实例管理连接。通过信令服务器交换SDP（Offer/Answer）描述会话信息，并利用STUN/TURN服务器收集ICE Candidate进行网络穿透。信令服务器协调连接建立，不传输媒体流；STUN用于获取公网地址，TURN在P2P失败时中继数据。连接成功后，音视频流直接在浏览器间传输，低延迟且安全加密，实现高效实时通信。
JavaScript实现视频通话，核心在于利用WebRTC技术，它让浏览器之间可以直接进行实时通信，无需经过服务器中转音视频流。这大大降低了延迟，也提升了用户体验。
解决方案
要用JavaScript实现视频通话，我们主要依赖WebRTC（Web Real-Time Communication）这个API集合。它的基本流程可以概括为几个关键步骤：获取本地媒体流、建立P2P连接、交换会话描述信息（SDP）、交换网络候选地址（ICE Candidate），最终实现音视频数据的直接传输。
首先，你需要通过
navigator.mediaDevices.getUserMedia()
来获取用户的摄像头和麦克风权限，拿到本地的音视频流。这通常会返回一个
MediaStream
<video>
标签上，这样用户就能看到自己的画面了。
接着，创建一个
RTCPeerConnection
实例，这是WebRTC的核心。这个对象负责管理点对点连接的所有细节，包括编解码、网络传输、安全性等等。
然后，就是连接的建立过程，这需要一个“信令服务器”（Signaling Server）来协调。信令服务器本身不传输媒体数据，它只负责在两个通信方之间传递一些控制信息，比如：
- 创建Offer/Answer： 一方（发起方）会创建一个“Offer”（提议），里面包含了它支持的音视频编解码能力、网络地址等信息。这个Offer通过信令服务器发送给另一方（接收方）。接收方收到Offer后，会根据自己的能力创建一个“Answer”（应答），再通过信令服务器发回给发起方。这些Offer和Answer都是SDP（Session Description Protocol）格式的文本。
- 交换ICE Candidate： 在Offer/Answer交换的同时，双方会通过STUN/TURN服务器收集自己的网络地址信息（ICE Candidate）。这些Candidate也需要通过信令服务器交换给对方。当双方都收到对方的Candidate后，它们就会尝试建立直接的P2P连接。
一旦P2P连接建立起来，媒体流就会直接在两个浏览器之间传输了。这个过程中，你还需要监听
RTCPeerConnection
的各种事件，比如
onicecandidate
（收集到新的ICE Candidate时触发）、
ontrack
（收到远端媒体流时触发）等，以便及时处理和更新连接状态。
// 示例：获取本地媒体流 async function getLocalStream() { try { const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true }); document.getElementById('localVideo').srcObject = stream; return stream; } catch (error) { console.error('获取媒体流失败:', error); // 这里可以做一些错误提示，比如用户拒绝了权限 } } // 示例：创建RTCPeerConnection const pc = new RTCPeerConnection(); // 监听远端媒体流 pc.ontrack = (event) => { document.getElementById('remoteVideo').srcObject = event.streams[0]; }; // 监听ICE Candidate pc.onicecandidate = (event) => { if (event.candidate) { // 将ICE Candidate发送给远端，通过信令服务器 // sendIceCandidateToRemote(event.candidate); } }; // 示例：创建Offer (发起方) async function createOffer(localStream) { localStream.getTracks().forEach(track => pc.addTrack(track, localStream)); const offer = await pc.createOffer(); await pc.setLocalDescription(offer); // 将Offer发送给远端，通过信令服务器 // sendOfferToRemote(offer); } // 示例：处理Offer (接收方) async function handleOffer(offer, localStream) { localStream.getTracks().forEach(track => pc.addTrack(track, localStream)); await pc.setRemoteDescription(new RTCSessionDescription(offer)); const answer = await pc.createAnswer(); await pc.setLocalDescription(answer); // 将Answer发送给远端，通过信令服务器 // sendAnswerToRemote(answer); }
这只是一个简化版的骨架，实际应用中，信令服务器的实现、错误处理、网络抖动和带宽适应等都是需要细致考量的部分。
WebRTC在视频通话中扮演了什么角色？
WebRTC，全称Web Real-Time Communication，直译过来就是“网页实时通信”。它不是一个简单的库，而是一整套开放标准和API，让浏览器（或者其他支持WebRTC的客户端）能够直接进行点对点（P2P）的音视频、数据传输。在我看来，它就是浏览器实现“面对面”交流的幕后英雄。
它的核心作用在于：
- 媒体流的获取与管理： 提供了
getUserMedia()
这样的API，让开发者能够轻松访问用户的摄像头和麦克风，获取音视频流。同时，它也负责这些流的编码、解码、处理（比如降噪、回声消除）。
- 点对点连接的建立： 这是WebRTC最引人注目的地方。它通过
RTCPeerConnection
对象，实现了NAT穿透（Network Address Translation Traversal）和防火墙穿越，让两个位于不同网络环境下的设备也能直接通信，而无需所有数据都经过中央服务器。这大大降低了服务器的带宽压力和延迟。
- 网络适应性： WebRTC内置了多种算法来适应网络状况。比如，它会根据实时的网络带宽动态调整视频的质量，确保在网络不佳时也能保持通话的流畅性，只是画质可能有所牺牲。它还会处理丢包重传、拥塞控制等问题，力求提供最佳的通信质量。
- 安全性： 所有通过WebRTC传输的数据都是加密的，这通常是通过DTLS（Datagram Transport Layer Security）和SRTP（Secure Real-time Transport Protocol）协议来保证的。这意味着，即使数据包在传输过程中被截获，也无法被轻易解读。
所以，WebRTC就像一个幕后的总指挥，它不仅提供了获取媒体的能力，更重要的是，它解决了实时通信中最复杂、最头疼的网络连接和数据传输问题，让我们开发者能够专注于应用层面的逻辑，而不是深陷于底层网络协议的泥潭。没有WebRTC，我们可能还在为如何在浏览器里实现一个稳定的视频通话而绞尽脑汁，或者不得不依赖复杂的插件。
信令服务器在WebRTC视频通话中是必需的吗？它的作用是什么？
信令服务器在WebRTC视频通话中是必需的，但它扮演的角色常常被误解。它不是用来传输音视频数据的，而是用来协调和管理WebRTC连接建立过程中的“握手”信息的。可以把它想象成一个婚介所或者电话交换机，它负责把双方介绍认识，交换各自的“名片”和“地址”，但一旦双方建立了联系，它就功成身退了。
具体来说，信令服务器的主要作用包括：
- 交换会话描述（SDP）： 当一方想要发起视频通话时，它会生成一个“Offer”（提议），里面包含了它支持的编解码器、网络信息等。这个Offer需要通过信令服务器发送给另一方。另一方收到Offer后，会生成一个“Answer”（应答），同样通过信令服务器发回给发起方。SDP是描述会话的关键信息，没有它，双方就不知道如何互相通信。
- 交换ICE候选者（ICE Candidates）： ICE（Interactive Connectivity Establishment）是WebRTC用来发现最佳连接路径的框架。在连接建立过程中，每一方都会收集自己的网络地址信息（比如本地IP、公网IP、通过STUN/TURN服务器获取的反射地址等），这些地址信息就是ICE Candidate。这些Candidate也需要通过信令服务器在双方之间进行交换。双方会尝试所有可能的Candidate组合，直到找到一个能够成功建立P2P连接的路径。
- 管理呼叫状态： 信令服务器还可以用来管理整个呼叫的生命周期，比如通知对方有来电、呼叫挂断、忙线等状态。它提供了一个中央化的机制来处理这些非媒体数据的信息。
信令服务器的实现非常灵活，你可以用websocket、Socket.IO、http长轮询等任何你觉得方便的技术来构建它。因为它不传输媒体数据，所以它的带宽和性能要求相对较低。没有信令服务器，WebRTC的两个端点就无法知道对方的存在，更无法交换建立P2P连接所需的关键信息。所以，尽管它不参与媒体流的直接传输，但它是WebRTC连接建立不可或缺的“中间人”。
如何处理WebRTC视频通话中的网络穿透和防火墙问题？
WebRTC在设计之初就考虑到了复杂的网络环境，尤其是NAT（网络地址转换）和防火墙问题。要处理这些挑战，WebRTC主要依赖于ICE（Interactive Connectivity Establishment）框架，而ICE又离不开STUN和TURN服务器的协助。
-
STUN（Session Traversal Utilities for NAT）服务器：
- 作用： STUN服务器的主要任务是帮助客户端发现自己的公网IP地址和端口号。想象一下，你的设备在一个局域网（NAT后面），它只知道自己的局域网IP，但要和外部网络通信，它需要知道自己在公网上的“身份”。STUN服务器就像一个“回音壁”，你向它发送一个请求，它会告诉你这个请求是从哪个公网IP和端口发出来的。
- 工作原理： 客户端向STUN服务器发送一个请求，STUN服务器收到后，会将请求的源IP和端口返回给客户端。客户端拿到这个公网地址后，就可以把它作为自己的一个ICE Candidate，告知给对方。如果双方都能通过STUN服务器获取到可达的公网地址，并且NAT类型是“全锥形NAT”或“受限锥形NAT”，那么P2P连接很可能就能直接建立起来。
- 局限性： STUN服务器无法穿透所有类型的NAT（特别是对称型NAT，Symmetric NAT），也无法穿透严格的防火墙。在这种情况下，就需要TURN服务器出场了。
-
TURN（Traversal using Relays around NAT）服务器：
- 作用： 当STUN无法建立直接的P2P连接时，TURN服务器就充当了“中继”的角色。它不只是帮助发现公网IP，而是直接转发所有的媒体数据流。
- 工作原理： 客户端无法直接与对方建立P2P连接时，它会向TURN服务器请求一个“中继地址”。然后，所有的音视频数据都会先发送到TURN服务器，再由TURN服务器转发给对方。这就像两个人无法直接对话，于是找了个中间人来传话。
- 优点与缺点： TURN服务器能够解决绝大多数NAT和防火墙问题，确保连接的建立。但它的缺点也很明显：所有的媒体数据都要经过它转发，这会增加服务器的带宽和计算资源消耗，引入额外的延迟，并且成本也更高。因此，TURN服务器通常只作为最后的备用方案，只有在STUN无法成功建立P2P连接时才使用。
在实际的WebRTC实现中，通常会配置一个ICE服务器列表，其中包含STUN服务器地址，以及在必要时使用的TURN服务器地址。WebRTC客户端会尝试所有这些服务器和它们提供的候选地址，直到找到一个可行的连接路径。这个过程是自动的，开发者只需要提供正确的服务器配置即可。虽然我们希望P2P直连是常态，但为了确保通话的成功率，STUN和TURN服务器是不可或缺的基础设施。
