尧图网页设计 
简介基于WebSocket实现浏览器端文本、视频与语音即时通讯的完整项目资料面向具备一定Web前后端基础的开发者可用于课程设计、毕业设计或工程实训参考。包内包含111个文件涵盖Java后端服务、HTML/JS前端页面、CSS样式及Docker部署配置等代码结构清晰便于按模块理解实时通信的实现思路。资源包仅959KB轻量易用可直接导入开发环境运行调试并通过启动脚本快速启动服务。文件中提供麦克风、摄像头调用与文本收发测试页面可帮助开发者验证音视频采集、信令交互及WebSocket消息传输效果。目前已有56人学习下载适合希望快速掌握WebSocket实际应用、并参考前后端联调细节的开发者借鉴。1. 为什么浏览器端实时通讯绕不开 WebSocket在做一个网页版微信风格的即时通讯项目时最容易被忽略的不是发消息而是连接本身的生死。基于WebSocket实现浏览器端文本、视频、语音的即时通讯核心难点在于全双工通道的管理和媒体协商文本消息要广播视频与语音要依赖WebRTC而WebSocket恰好是两者之间唯一的信令管道。很多课程设计Demo能跑通聊天却经不住断网重连和多人房间的考验。下面从连接管理讲起再看消息协议、媒体协商最后把Dockerfile和启动脚本里的坑也填上。适合正在做课程设计、毕设或想在内部系统加一个实时通讯模块的开发者特别是那些希望理解握手、心跳、SDP交换等底层参数的人。2. WebSocket 连接管理与消息协议从握手到广播2.1 协议层为什么比 HTTP 轮询强浏览器端做即时通讯第一反应往往是HTTP轮询。轮询的代价是每次请求都要携带完整Header服务端要解析、鉴权、处理重复连接一个100人在线的聊天室如果2秒轮询一次每秒就有100个请求其中可能只有2条是有效消息。WebSocket用一个HTTP Upgrade请求把双向通道建立起来之后每个数据帧头部只有2到14字节。对于文本消息几百字节的Payload加2字节帧头比HTTP省了一个数量级。更重要的是浏览器原生提供WebSocket对象不需要额外引入SDK。但这个通道不是免死金牌。WebSocket服务端要自己处理心跳、死连接、未认证连接和消息边界。用Node.js的ws库时connection事件后对象就已经可以收发框架不提供房间和会话概念所有东西都要自己定义。这也是下面从协议层开始搭的原因。ws库轻量、二进制帧处理简单能和Express/Node HTTP server复用同一个端口如果换成Spring Boot常见做法是ServerEndpoint加SpringConfigurator思路一致只是把连接生命周期交给容器管理。2.2 服务端广播与连接生命周期管理项目里server.js的核心结构如下我用ws加Express托管public目录下的chat.html、microphoneTest2.html和cameraTest.html。const http require(http); const express require(express); const { WebSocketServer } require(ws); const app express(); app.use(express.static(public)); const server http.createServer(app); const wss new WebSocketServer({ server, path: /ws }); // 用Map保存在线连接key是会话idvalue是ws实例 const clients new Map(); wss.on(connection, (ws, req) { const userId new URL(req.url, http://localhost).searchParams.get(token) || guest-${Date.now()}; clients.set(userId, ws); ws.isAlive true; ws.on(pong, () { ws.isAlive true; }); ws.send(JSON.stringify({ type: welcome, userId })); ws.on(message, (buf) { let msg; try { msg JSON.parse(buf.toString()); } catch { ws.send(JSON.stringify({ type: error, code: 400, message: body must be json })); return; } if (msg.type chat) { const text String(msg.text || ).slice(0, 500); clients.forEach((client) { if (client.readyState 1) { client.send(JSON.stringify({ type: chat, from: userId, text, time: Date.now() })); } }); } }); ws.on(close, () clients.delete(userId)); }); setInterval(() { clients.forEach((ws, id) { if (!ws.isAlive) { ws.terminate(); clients.delete(id); return; } ws.isAlive false; ws.ping(); }); }, 30000); server.listen(3000, () console.log(listening on 3000));这里readyState 1表示连接处于OPEN状态可以直接send。ws.ping()是协议层控制帧浏览器会自动回应pong30秒一次的探测能及时清掉“假死”连接。token从URL参数读取只是为了演示生产环境应该放在请求头或首帧消息里避免日志泄漏。所有业务消息统一走JSON解析失败时返回400而不是直接断开这样前端可以根据错误码提示用户而不是眼睁睁看着连接掉线。2.3 前端连接状态机与重连策略浏览器端连接管理要显式处理“主动关闭”和“异常断开”。下面是一个带指数退避重连的封装let ws null; let attempt 0; function connect() { ws new WebSocket(/ws?token${encodeURIComponent(userId)}); ws.addEventListener(open, () { attempt 0; ws.send(JSON.stringify({ type: hello, client: web })); }); ws.addEventListener(message, (event) { const msg JSON.parse(event.data); dispatch(msg); }); ws.addEventListener(close, (event) { // 1000 是主动关闭1006 说明网络中断或对端终止 if (event.code 1000 || event.code 4000) return; const timeout Math.min(500 * 2 ** attempt, 10000); attempt 1; setTimeout(connect, timeout); }); } connect();Math.min(500 * 2 ** attempt, 10000)实现指数退避第一次1秒、第二次2秒最多10秒。如果用固定间隔服务端重启时会有一堆客户端同时重连造成“惊群”。close事件里不能只判断code 1000因为1006在浏览器端是“连接异常关闭且没有关闭帧”常见原因是NAT超时、服务端terminate()或代理回收空闲连接这种情况必须重连。关闭码含义重连策略1000正常关闭不重连1001页面/服务端离开按业务决定1006非正常关闭无关闭帧指数退避重连4000-4999自定义业务关闭按业务码处理3. 文本聊天实现JSON 协议、心跳与消息去抖3.1 定义统一消息协议消息结构要能同时承载文本、信令和状态我用一个type加一个data字段{ type: chat, to: room:lobby, data: { text: hello } }type用可读的字符串而不是数字方便在浏览器控制台和Nginx日志里直接排查问题。to字段支持room:xxx和user:xxx两种前缀这样同一个后端既能群聊也能私聊。时间戳统一用Date.now()返回的毫秒不要用秒因为前端new Date()默认接收毫秒传秒会出现1970年的诡异时间。type方向用途helloC→S连接后鉴权chatC↔S文本消息typingC→S正在输入事件ping/pongC↔S业务心跳offer / answer / candidateC↔SWebRTC信令注意业务心跳和2.2里的协议层ping不是一回事。协议层ping是为了保活TCP连接业务心跳是为了上报“用户还在这条会话里”前端可以每30秒发一个ping服务端回pong。如果只靠ws协议层心跳服务端无法区分用户是切后台还是真离线。3.2 服务端路由与转发在2.2的Map基础上扩展一个路由函数function sendTo(target, payload) { const [type, key] target.split(:); if (type room) { clients.forEach((client) { if (client.readyState 1) client.send(JSON.stringify(payload)); }); return; } const ws clients.get(key); if (ws ws.readyState 1) { ws.send(JSON.stringify(payload)); } else { // 目标离线可在这里写入Redis离线消息 console.warn(offline: ${key}); } } ws.on(message, (buf) { const msg JSON.parse(buf.toString()); if (msg.type chat) { const data msg.data || {}; if (typeof data.text ! string || data.text.length 0) return; sendTo(msg.to, { type: chat, from: userId, data, time: Date.now() }); } });用split(:)而不是正则是因为这里只需要切割一次正则反而增加阅读成本。room:前缀直接遍历所有连接广播适合聊天室场景user:前缀做精确投递适合私聊和WebRTC信令。单台服务器几千连接直接遍历Map没有性能问题真正到十万并发再考虑Redis Pub/Sub到时候把clients换成订阅关系业务层的sendTo函数不用改。3.3 前端低延迟渲染与 DTO 校验前端拿到消息后不要无脑appendChild先做轻量校验再渲染const list document.getElementById(messages); function appendMessage(msg) { const el document.createElement(div); el.className msg.from currentUser ? message mine : message other; el.textContent ${msg.from}: ${msg.data.text}; list.appendChild(el); } let lastPaint 0; function enqueueMessage(msg) { const now Date.now(); if (msg.from currentUser now - lastPaint 16) { const last list.lastElementChild; last.textContent msg.data.text; return; } lastPaint now; appendMessage(msg); }这里16ms对应60fps的渲染周期。普通文本聊天每秒几十条消息其实无所谓但配合typing事件连续触发时把相似消息合并到同一帧能明显减少DOM重排。lastElementChild只引用最后一个节点避免每次从querySelector重新查找。Vue 3项目里“增加 websocket”的常见做法是在onMounted里建立连接、onUnmounted里关闭然后用reactive数组和watch触发渲染和这里的逻辑一样只是框架替代了手动DOM操作。4. 视频与语音通话WebRTC 信令 媒体协商4.1 为什么媒体流不走 WebSocket反直觉的地方在于WebSocket明明是全双工为什么不能直接推视频帧因为WebSocket基于TCPTCP保证顺序和可靠一旦丢包就要重传视频画面会卡在等待重传的帧上。WebRTC走UDP用SRTP加密通过RTCP反馈丢包情况丢包时优先恢复音频而不是重传整帧对实时通话的容忍度完全不同。因此这个项目里WebSocket只做信令通道负责交换SDP和ICE候选真正的媒体流通过RTCPeerConnection点对点传输。看到microphoneTest2.html和cameraTest.html就知道它们是媒体采集调试页不是信令页面。4.2 getUserMedia 与设备遍历摄像头和麦克风要单独测试我一般用下面这个方法async function startLocalStream(kind) { const constraints { video: kind video ? { width: { ideal: 1280 }, height: { ideal: 720 }, facingMode: user } : false, audio: kind ! video ? { echoCancellation: true, noiseSuppression: true, autoGainControl: true } : false }; return await navigator.mediaDevices.getUserMedia(constraints); }echoCancellation回音消除必须开否则扬声器的声音会被麦克风再次采集形成刺耳回声noiseSuppression压制键盘敲击声autoGainControl让音量自动调整。facingMode: user指定前置摄像头需要后置时改成environment。还要注意getUserMedia必须在用户手势里调用比如点击“开始通话”按钮否则浏览器直接拒绝。在“电脑端模仿微信浏览器”场景下修改UA不会让权限判断变宽松部分浏览器还把navigator.mediaDevices隐藏到navigator.getUserMedia上需要做兼容降级。4.3 RTCPeerConnection 与 SDP 交换采集到本地流之后创建RTCPeerConnection并添加轨道const pc new RTCPeerConnection({ iceServers: [ { urls: stun:stun.l.google.com:19302 } ] }); stream.getTracks().forEach((track) pc.addTrack(track, stream)); pc.onicecandidate (event) { if (event.candidate) { ws.send(JSON.stringify({ type: candidate, to: remoteUserId, data: event.candidate.toJSON() })); } }; pc.onnegotiationneeded async () { const offer await pc.createOffer(); await pc.setLocalDescription(offer); ws.send(JSON.stringify({ type: offer, to: remoteUserId, data: pc.localDescription.toJSON() })); };远端收到offer后要回一个answerasync function onRemoteOffer(from, data) { await pc.setRemoteDescription(new RTCSessionDescription(data)); const answer await pc.createAnswer(); await pc.setLocalDescription(answer); ws.send(JSON.stringify({ type: answer, to: from, data: pc.localDescription.toJSON() })); }onnegotiationneeded在添加轨道后自动触发不需要手动调用createOffer。event.candidate为null表示ICE收集完成这个null事件不需要发送给对端。要注意toJSON()而不是直接序列化整个对象因为SDP和ICE对象里有浏览器内部字段直接发送会造成对端setRemoteDescription解析失败。信令消息体必须带to否则多人房间里所有人都去处理同一份offer会把peer connection状态搅乱。4.4 房间模型与参会者管理消息 type发送方接收方载荷offer发起方房间内目标用户SDPanswer应答方offer来源SDPcandidate任意一方对方ICE候选bye任意一方对端空服务端对信令只做转发不解析SDP内容ws.on(message, (buf) { const msg JSON.parse(buf.toString()); if ([offer, answer, candidate, bye].includes(msg.type)) { const target msg.to; if (target clients.has(target)) { clients.get(target).send(buf.toString()); } else { ws.send(JSON.stringify({ type: error, code: 404, message: target offline })); } } });这种“对称转发”模型省掉了服务端的媒体处理一个Node进程可以同时支持几百路信令。多对多房间要在参与者加入时广播成员列表并让新成员向其他成员逐个发送offer超过4人视频建议改用SFU架构如mediasoup但本项目是一对一或小房间演示P2P足够。注意转发时直接发buf.toString()而不是重新JSON.stringify(msg)能保持原始字段顺序减少不必要的对象序列化开销。5. 部署与排错Dockerfile、批量启动和 1006 断连5.1 容器化部署项目根目录的Dockerfile可以这样写FROM node:20-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --omitdev COPY . . EXPOSE 3000 CMD [node, server.js]启动服务.bat里最核心的两行就是npm install和node server.js也可以封装成docker build -t ws-im . docker run -p 3000:3000 ws-im选node:20-alpine而不是node:latest是因为alpine镜像体积小且自带TLS CA能保证前后端构建环境一致。npm ci --omitdev按package-lock.json锁版本安装避免他人克隆项目后因为依赖版本差异跑不起来。express.static(public)会把microphoneTest2.html、cameraTest.html一起托管调试时直接访问http://localhost:3000/microphoneTest2.html就能测设备。5.2 常见坑1006、媒体权限与移动端置顶症状原因处理浏览器报[websocket] onclose, code: 1006心跳未回复服务端终止缩短ping间隔检查代理超时getUserMedia返回 NotAllowedError非HTTPS或非localhost本地用localhost公网用HTTPS/WSS移动端视频自动置顶百度浏览器/微信内核默认全屏播视频video标签加playsinline webkit-playsinlineChrome 109 出现 wss 握手失败自签名证书不受信手动导入证书并重启浏览器1006不是业务错误而是连接被强制关闭且没有关闭帧。常见于Nginx按秒断开空闲连接或者服务端心跳间隔大于连接清理周期。解决方式是WebSocket层每25秒发一次ping并把Nginx的proxy_read_timeout调到60秒以上。用JMeter的WebSocket Sampler压测时如果看到stream disconnected before completion多半就是服务端并发连接触顶或者心跳没有响应先查这两个点。5.3 用一条命令验证连接闭环不需要开浏览器用Node脚本直接验证服务端广播逻辑const WebSocket require(ws); const ws new WebSocket(ws://localhost:3000/ws?tokentest); ws.on(open, () { ws.send(JSON.stringify({ type: chat, to: room:lobby, data: { text: hello } })); }); ws.on(message, (buf) { const msg JSON.parse(buf); console.log(received:, msg.type, msg.from); process.exit(0); });如果收到welcome但没有chat说明服务端消息路由有问题如果两个都没有先检查path: /ws是否和访问路径一致。microphoneTest2.html和cameraTest.html这两个调试页在生产环境也建议保留排查“没有声音/没有图像”时先单独测试采集设备再走WebRTC能把问题范围缩小一半。本文还有配套的精品资源点击获取 WebSocket实战：从握手到WebRTC信令，构建浏览器实时通讯
简介基于WebSocket实现浏览器端文本、视频与语音即时通讯的完整项目资料面向具备一定Web前后端基础的开发者可用于课程设计、毕业设计或工程实训参考。包内包含111个文件涵盖Java后端服务、HTML/JS前端页面、CSS样式及Docker部署配置等代码结构清晰便于按模块理解实时通信的实现思路。资源包仅959KB轻量易用可直接导入开发环境运行调试并通过启动脚本快速启动服务。文件中提供麦克风、摄像头调用与文本收发测试页面可帮助开发者验证音视频采集、信令交互及WebSocket消息传输效果。目前已有56人学习下载适合希望快速掌握WebSocket实际应用、并参考前后端联调细节的开发者借鉴。1. 为什么浏览器端实时通讯绕不开 WebSocket在做一个网页版微信风格的即时通讯项目时最容易被忽略的不是发消息而是连接本身的生死。基于WebSocket实现浏览器端文本、视频、语音的即时通讯核心难点在于全双工通道的管理和媒体协商文本消息要广播视频与语音要依赖WebRTC而WebSocket恰好是两者之间唯一的信令管道。很多课程设计Demo能跑通聊天却经不住断网重连和多人房间的考验。下面从连接管理讲起再看消息协议、媒体协商最后把Dockerfile和启动脚本里的坑也填上。适合正在做课程设计、毕设或想在内部系统加一个实时通讯模块的开发者特别是那些希望理解握手、心跳、SDP交换等底层参数的人。2. WebSocket 连接管理与消息协议从握手到广播2.1 协议层为什么比 HTTP 轮询强浏览器端做即时通讯第一反应往往是HTTP轮询。轮询的代价是每次请求都要携带完整Header服务端要解析、鉴权、处理重复连接一个100人在线的聊天室如果2秒轮询一次每秒就有100个请求其中可能只有2条是有效消息。WebSocket用一个HTTP Upgrade请求把双向通道建立起来之后每个数据帧头部只有2到14字节。对于文本消息几百字节的Payload加2字节帧头比HTTP省了一个数量级。更重要的是浏览器原生提供WebSocket对象不需要额外引入SDK。但这个通道不是免死金牌。WebSocket服务端要自己处理心跳、死连接、未认证连接和消息边界。用Node.js的ws库时connection事件后对象就已经可以收发框架不提供房间和会话概念所有东西都要自己定义。这也是下面从协议层开始搭的原因。ws库轻量、二进制帧处理简单能和Express/Node HTTP server复用同一个端口如果换成Spring Boot常见做法是ServerEndpoint加SpringConfigurator思路一致只是把连接生命周期交给容器管理。2.2 服务端广播与连接生命周期管理项目里server.js的核心结构如下我用ws加Express托管public目录下的chat.html、microphoneTest2.html和cameraTest.html。const http require(http); const express require(express); const { WebSocketServer } require(ws); const app express(); app.use(express.static(public)); const server http.createServer(app); const wss new WebSocketServer({ server, path: /ws }); // 用Map保存在线连接key是会话idvalue是ws实例 const clients new Map(); wss.on(connection, (ws, req) { const userId new URL(req.url, http://localhost).searchParams.get(token) || guest-${Date.now()}; clients.set(userId, ws); ws.isAlive true; ws.on(pong, () { ws.isAlive true; }); ws.send(JSON.stringify({ type: welcome, userId })); ws.on(message, (buf) { let msg; try { msg JSON.parse(buf.toString()); } catch { ws.send(JSON.stringify({ type: error, code: 400, message: body must be json })); return; } if (msg.type chat) { const text String(msg.text || ).slice(0, 500); clients.forEach((client) { if (client.readyState 1) { client.send(JSON.stringify({ type: chat, from: userId, text, time: Date.now() })); } }); } }); ws.on(close, () clients.delete(userId)); }); setInterval(() { clients.forEach((ws, id) { if (!ws.isAlive) { ws.terminate(); clients.delete(id); return; } ws.isAlive false; ws.ping(); }); }, 30000); server.listen(3000, () console.log(listening on 3000));这里readyState 1表示连接处于OPEN状态可以直接send。ws.ping()是协议层控制帧浏览器会自动回应pong30秒一次的探测能及时清掉“假死”连接。token从URL参数读取只是为了演示生产环境应该放在请求头或首帧消息里避免日志泄漏。所有业务消息统一走JSON解析失败时返回400而不是直接断开这样前端可以根据错误码提示用户而不是眼睁睁看着连接掉线。2.3 前端连接状态机与重连策略浏览器端连接管理要显式处理“主动关闭”和“异常断开”。下面是一个带指数退避重连的封装let ws null; let attempt 0; function connect() { ws new WebSocket(/ws?token${encodeURIComponent(userId)}); ws.addEventListener(open, () { attempt 0; ws.send(JSON.stringify({ type: hello, client: web })); }); ws.addEventListener(message, (event) { const msg JSON.parse(event.data); dispatch(msg); }); ws.addEventListener(close, (event) { // 1000 是主动关闭1006 说明网络中断或对端终止 if (event.code 1000 || event.code 4000) return; const timeout Math.min(500 * 2 ** attempt, 10000); attempt 1; setTimeout(connect, timeout); }); } connect();Math.min(500 * 2 ** attempt, 10000)实现指数退避第一次1秒、第二次2秒最多10秒。如果用固定间隔服务端重启时会有一堆客户端同时重连造成“惊群”。close事件里不能只判断code 1000因为1006在浏览器端是“连接异常关闭且没有关闭帧”常见原因是NAT超时、服务端terminate()或代理回收空闲连接这种情况必须重连。关闭码含义重连策略1000正常关闭不重连1001页面/服务端离开按业务决定1006非正常关闭无关闭帧指数退避重连4000-4999自定义业务关闭按业务码处理3. 文本聊天实现JSON 协议、心跳与消息去抖3.1 定义统一消息协议消息结构要能同时承载文本、信令和状态我用一个type加一个data字段{ type: chat, to: room:lobby, data: { text: hello } }type用可读的字符串而不是数字方便在浏览器控制台和Nginx日志里直接排查问题。to字段支持room:xxx和user:xxx两种前缀这样同一个后端既能群聊也能私聊。时间戳统一用Date.now()返回的毫秒不要用秒因为前端new Date()默认接收毫秒传秒会出现1970年的诡异时间。type方向用途helloC→S连接后鉴权chatC↔S文本消息typingC→S正在输入事件ping/pongC↔S业务心跳offer / answer / candidateC↔SWebRTC信令注意业务心跳和2.2里的协议层ping不是一回事。协议层ping是为了保活TCP连接业务心跳是为了上报“用户还在这条会话里”前端可以每30秒发一个ping服务端回pong。如果只靠ws协议层心跳服务端无法区分用户是切后台还是真离线。3.2 服务端路由与转发在2.2的Map基础上扩展一个路由函数function sendTo(target, payload) { const [type, key] target.split(:); if (type room) { clients.forEach((client) { if (client.readyState 1) client.send(JSON.stringify(payload)); }); return; } const ws clients.get(key); if (ws ws.readyState 1) { ws.send(JSON.stringify(payload)); } else { // 目标离线可在这里写入Redis离线消息 console.warn(offline: ${key}); } } ws.on(message, (buf) { const msg JSON.parse(buf.toString()); if (msg.type chat) { const data msg.data || {}; if (typeof data.text ! string || data.text.length 0) return; sendTo(msg.to, { type: chat, from: userId, data, time: Date.now() }); } });用split(:)而不是正则是因为这里只需要切割一次正则反而增加阅读成本。room:前缀直接遍历所有连接广播适合聊天室场景user:前缀做精确投递适合私聊和WebRTC信令。单台服务器几千连接直接遍历Map没有性能问题真正到十万并发再考虑Redis Pub/Sub到时候把clients换成订阅关系业务层的sendTo函数不用改。3.3 前端低延迟渲染与 DTO 校验前端拿到消息后不要无脑appendChild先做轻量校验再渲染const list document.getElementById(messages); function appendMessage(msg) { const el document.createElement(div); el.className msg.from currentUser ? message mine : message other; el.textContent ${msg.from}: ${msg.data.text}; list.appendChild(el); } let lastPaint 0; function enqueueMessage(msg) { const now Date.now(); if (msg.from currentUser now - lastPaint 16) { const last list.lastElementChild; last.textContent msg.data.text; return; } lastPaint now; appendMessage(msg); }这里16ms对应60fps的渲染周期。普通文本聊天每秒几十条消息其实无所谓但配合typing事件连续触发时把相似消息合并到同一帧能明显减少DOM重排。lastElementChild只引用最后一个节点避免每次从querySelector重新查找。Vue 3项目里“增加 websocket”的常见做法是在onMounted里建立连接、onUnmounted里关闭然后用reactive数组和watch触发渲染和这里的逻辑一样只是框架替代了手动DOM操作。4. 视频与语音通话WebRTC 信令 媒体协商4.1 为什么媒体流不走 WebSocket反直觉的地方在于WebSocket明明是全双工为什么不能直接推视频帧因为WebSocket基于TCPTCP保证顺序和可靠一旦丢包就要重传视频画面会卡在等待重传的帧上。WebRTC走UDP用SRTP加密通过RTCP反馈丢包情况丢包时优先恢复音频而不是重传整帧对实时通话的容忍度完全不同。因此这个项目里WebSocket只做信令通道负责交换SDP和ICE候选真正的媒体流通过RTCPeerConnection点对点传输。看到microphoneTest2.html和cameraTest.html就知道它们是媒体采集调试页不是信令页面。4.2 getUserMedia 与设备遍历摄像头和麦克风要单独测试我一般用下面这个方法async function startLocalStream(kind) { const constraints { video: kind video ? { width: { ideal: 1280 }, height: { ideal: 720 }, facingMode: user } : false, audio: kind ! video ? { echoCancellation: true, noiseSuppression: true, autoGainControl: true } : false }; return await navigator.mediaDevices.getUserMedia(constraints); }echoCancellation回音消除必须开否则扬声器的声音会被麦克风再次采集形成刺耳回声noiseSuppression压制键盘敲击声autoGainControl让音量自动调整。facingMode: user指定前置摄像头需要后置时改成environment。还要注意getUserMedia必须在用户手势里调用比如点击“开始通话”按钮否则浏览器直接拒绝。在“电脑端模仿微信浏览器”场景下修改UA不会让权限判断变宽松部分浏览器还把navigator.mediaDevices隐藏到navigator.getUserMedia上需要做兼容降级。4.3 RTCPeerConnection 与 SDP 交换采集到本地流之后创建RTCPeerConnection并添加轨道const pc new RTCPeerConnection({ iceServers: [ { urls: stun:stun.l.google.com:19302 } ] }); stream.getTracks().forEach((track) pc.addTrack(track, stream)); pc.onicecandidate (event) { if (event.candidate) { ws.send(JSON.stringify({ type: candidate, to: remoteUserId, data: event.candidate.toJSON() })); } }; pc.onnegotiationneeded async () { const offer await pc.createOffer(); await pc.setLocalDescription(offer); ws.send(JSON.stringify({ type: offer, to: remoteUserId, data: pc.localDescription.toJSON() })); };远端收到offer后要回一个answerasync function onRemoteOffer(from, data) { await pc.setRemoteDescription(new RTCSessionDescription(data)); const answer await pc.createAnswer(); await pc.setLocalDescription(answer); ws.send(JSON.stringify({ type: answer, to: from, data: pc.localDescription.toJSON() })); }onnegotiationneeded在添加轨道后自动触发不需要手动调用createOffer。event.candidate为null表示ICE收集完成这个null事件不需要发送给对端。要注意toJSON()而不是直接序列化整个对象因为SDP和ICE对象里有浏览器内部字段直接发送会造成对端setRemoteDescription解析失败。信令消息体必须带to否则多人房间里所有人都去处理同一份offer会把peer connection状态搅乱。4.4 房间模型与参会者管理消息 type发送方接收方载荷offer发起方房间内目标用户SDPanswer应答方offer来源SDPcandidate任意一方对方ICE候选bye任意一方对端空服务端对信令只做转发不解析SDP内容ws.on(message, (buf) { const msg JSON.parse(buf.toString()); if ([offer, answer, candidate, bye].includes(msg.type)) { const target msg.to; if (target clients.has(target)) { clients.get(target).send(buf.toString()); } else { ws.send(JSON.stringify({ type: error, code: 404, message: target offline })); } } });这种“对称转发”模型省掉了服务端的媒体处理一个Node进程可以同时支持几百路信令。多对多房间要在参与者加入时广播成员列表并让新成员向其他成员逐个发送offer超过4人视频建议改用SFU架构如mediasoup但本项目是一对一或小房间演示P2P足够。注意转发时直接发buf.toString()而不是重新JSON.stringify(msg)能保持原始字段顺序减少不必要的对象序列化开销。5. 部署与排错Dockerfile、批量启动和 1006 断连5.1 容器化部署项目根目录的Dockerfile可以这样写FROM node:20-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --omitdev COPY . . EXPOSE 3000 CMD [node, server.js]启动服务.bat里最核心的两行就是npm install和node server.js也可以封装成docker build -t ws-im . docker run -p 3000:3000 ws-im选node:20-alpine而不是node:latest是因为alpine镜像体积小且自带TLS CA能保证前后端构建环境一致。npm ci --omitdev按package-lock.json锁版本安装避免他人克隆项目后因为依赖版本差异跑不起来。express.static(public)会把microphoneTest2.html、cameraTest.html一起托管调试时直接访问http://localhost:3000/microphoneTest2.html就能测设备。5.2 常见坑1006、媒体权限与移动端置顶症状原因处理浏览器报[websocket] onclose, code: 1006心跳未回复服务端终止缩短ping间隔检查代理超时getUserMedia返回 NotAllowedError非HTTPS或非localhost本地用localhost公网用HTTPS/WSS移动端视频自动置顶百度浏览器/微信内核默认全屏播视频video标签加playsinline webkit-playsinlineChrome 109 出现 wss 握手失败自签名证书不受信手动导入证书并重启浏览器1006不是业务错误而是连接被强制关闭且没有关闭帧。常见于Nginx按秒断开空闲连接或者服务端心跳间隔大于连接清理周期。解决方式是WebSocket层每25秒发一次ping并把Nginx的proxy_read_timeout调到60秒以上。用JMeter的WebSocket Sampler压测时如果看到stream disconnected before completion多半就是服务端并发连接触顶或者心跳没有响应先查这两个点。5.3 用一条命令验证连接闭环不需要开浏览器用Node脚本直接验证服务端广播逻辑const WebSocket require(ws); const ws new WebSocket(ws://localhost:3000/ws?tokentest); ws.on(open, () { ws.send(JSON.stringify({ type: chat, to: room:lobby, data: { text: hello } })); }); ws.on(message, (buf) { const msg JSON.parse(buf); console.log(received:, msg.type, msg.from); process.exit(0); });如果收到welcome但没有chat说明服务端消息路由有问题如果两个都没有先检查path: /ws是否和访问路径一致。microphoneTest2.html和cameraTest.html这两个调试页在生产环境也建议保留排查“没有声音/没有图像”时先单独测试采集设备再走WebRTC能把问题范围缩小一半。本文还有配套的精品资源点击获取