2、信令调试：使用 wss://echo.websocket.org 测试信令服务器连通性，抓包分析信令流程

信令，说白了就是 WebRTC 的「指挥系统」。没有它，两个浏览器根本不知道对方在哪、用什么格式通信。我见过不少新手，一上来就怼媒体流，结果信令没通，折腾半天才发现是 WebSocket 连不上。

这一节，咱们就用一个公开的 WebSocket 回显服务器 wss://echo.websocket.org，把信令的连通性测明白，再抓包看看信令到底长什么样。

2.1 为什么选 echo.websocket.org？

这个服务器很简单——你发什么，它原样返回什么。用来测试 WebSocket 连接是否建立、消息是否收发正常，再合适不过了。

核心价值：排除信令服务器本身的逻辑干扰，只验证「网络通路」是否畅通。

我在项目中遇到过好几次，信令服务器代码写得没问题，但部署环境里防火墙把 WebSocket 端口给封了。用 echo 服务器一测，立马现原形。

2.2 快速连通性测试

打开浏览器控制台，直接敲下面这段代码：

// 创建 WebSocket 连接
const ws = new WebSocket('wss://echo.websocket.org');

// 连接打开时触发
ws.onopen = () => {
  console.log('✅ 连接成功');
  ws.send('Hello WebRTC');
};

// 收到消息时触发
ws.onmessage = (event) => {
  console.log('📩 收到回显:', event.data);
};

// 连接关闭时触发
ws.onerror = (err) => {
  console.error('❌ 连接失败:', err);
};

如果控制台打印出「连接成功」和「收到回显」，说明你的网络环境支持 WebSocket 通信。嗯，这一步虽然简单，但能帮你省下至少半小时的排查时间。

小技巧：如果连接失败，先检查是不是用了 HTTPS 页面。浏览器安全策略要求：HTTPS 页面只能连接 WSS，不能连 WS。

2.3 模拟信令交换流程

真实的 WebRTC 信令包含 SDP 和 ICE 候选信息。咱们用 echo 服务器模拟一下这个流程：

// 模拟信令交换
const signaling = new WebSocket('wss://echo.websocket.org');

signaling.onopen = () => {
  console.log('📡 信令通道已建立');

  // 模拟发送 SDP Offer
  const offer = {
    type: 'offer',
    sdp: 'v=0\no=- 123456 2 IN IP4 127.0.0.1\n...'
  };
  signaling.send(JSON.stringify(offer));
};

signaling.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  console.log('📨 收到信令消息:', msg.type);

  if (msg.type === 'offer') {
    // 模拟回复 Answer
    const answer = {
      type: 'answer',
      sdp: 'v=0\no=- 654321 2 IN IP4 127.0.0.1\n...'
    };
    signaling.send(JSON.stringify(answer));
  }
};

你想想看，这其实就是信令服务器的核心逻辑——转发消息。只不过真实场景里，服务器需要维护多个连接、做房间管理，而 echo 服务器只负责回显。

2.4 抓包分析信令流程

光看控制台输出还不够，咱们得用 Wireshark 抓包看看底层发生了什么。

2.4.1 抓包步骤

  1. 打开 Wireshark，选择你的网络接口（Wi-Fi 或以太网）
  2. 设置过滤条件：websocket 或 tcp.port == 443
  3. 在浏览器中执行上面的 WebSocket 连接代码
  4. 观察抓包结果

2.4.2 关键抓包节点分析

阶段 数据包特征 说明
TCP 三次握手 SYN → SYN-ACK → ACK 建立底层 TCP 连接
TLS 握手 Client Hello → Server Hello → 证书交换 WSS 需要 TLS 加密
WebSocket 握手 HTTP Upgrade 请求/响应 从 HTTP 升级到 WebSocket 协议
数据帧 WebSocket 数据帧（掩码标记为 1） 实际的信令消息传输

注意：Wireshark 抓 WSS 流量时，如果没配置 SSLKEYLOGFILE，只能看到加密后的乱码。建议先用 WS（非加密）测试，或者配置浏览器环境变量导出密钥。

2.5 信令流程可视化

下面这张图，把整个信令交互的脉络画清楚了：

信令交互流程（基于 echo.websocket.org） 浏览器 A echo.websocket.org 浏览器 B ① TCP 三次握手 ② TLS 握手 ③ HTTP Upgrade ④ 发送 Offer ⑤ 回显 Offer ⑥ 返回 Answer ⑦ 回显 Answer TCP/TLS 握手 Offer 消息 Answer 消息

从图上可以清楚看到：浏览器 A 发出去的 Offer，经过 echo 服务器原样返回，然后我们手动转发给浏览器 B。B 回复的 Answer 也是同样的路径。这就是信令的基本模型——消息转发。

2.6 常见问题与避坑指南

我曾经遇到过：用 echo.websocket.org 测试一切正常，但换成自己的信令服务器就失败。后来发现是服务器没有正确处理 WebSocket 的 ping/pong 心跳，导致连接被中间防火墙断开。

  • 连接超时：检查防火墙是否放行 443 端口，或者尝试用 ws:// 非加密版本测试
  • 消息乱序：WebSocket 保证 TCP 层面的有序，但应用层仍需自己处理消息 ID 或序列号
  • 数据格式：建议统一用 JSON 格式，字段名保持小驼峰，方便前后端联调
  • 重连机制：信令连接断开后，WebRTC 的媒体流可能还在，但无法再发起新的呼叫

我的习惯：在信令消息里加一个 timestamp 字段，排查问题时能清楚看到消息的收发延迟。

2.7 小结

用 echo.websocket.org 测试信令连通性，说白了就是先确认「路通了」，再谈「车怎么开」。这一步虽然基础，但能帮你把网络层的问题和业务层的问题快速分开。

抓包分析时，重点关注 TCP 握手、TLS 握手、WebSocket 升级这三个阶段。任何一个阶段失败，信令都跑不通。嗯，记住这个排查顺序，能少走很多弯路。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →