如果你接手过“WebSocket实时音视频传输”这类需求，多半也有过类似的纠结：是不是把视频帧切成小块，往WebSocket里一塞，就能做出一个实时音视频应用？说实话，这个思路在局域网或者纯Demo环境里跑通完全没问题，但一旦放到公网上，延迟、带宽、弱网丢包这些问题会立刻教会你重新做人。

这篇文章来自我之前做的一个多人实时语音和视频协作工具。整个项目里WebSocket承担了连接管理、消息转发、房间控制这些核心工作，而真正的大流量媒体数据传输走了更合适的通道。全文会完整记录这套方案从设计到落地的全过程，包括服务端用Go + Gin怎么写、前端用Vue3 + VueUse怎么接、二进制帧怎么封装、1006断开怎么排查、H5能连但打包成App连不上是什么原因，以及JMeter怎么压测WebSocket。如果你正在做类似的功能，或者准备面试前系统梳理一下WebSocket，这篇应该能帮上忙。

1. 先想清楚：WebSocket在音视频链路里到底扮演什么角色

1.1 这个项目的需求背景

先交代一下背景。当时要做的是一个网页端的多人实时协作工具，核心功能包括语音通话、视频画面的实时共享，以及房间内各成员的上下线通知。表面上看需求很清晰，但拆开以后至少有这么几个模块：客户端与服务器的连接管理、房间与成员关系维护、信令的可靠转发、媒体数据的实时传输，以及弱网和异常场景下的连接恢复。

这里每一步都有WebSocket的身影，但它承担的职责并不一样。很多人一听到“实时音视频”就想着用WebSocket直接把媒体流扔过去，这是对WebSocket能力边界的误解。WebSocket是一个全双工的长连接协议，天然适合做控制消息的实时双向转发，但它的底层是TCP，传输音视频这种大数据量、容忍丢包、对延迟敏感的数据时，效率并不理想。

1.2 WebSocket与WebRTC的分工逻辑

用一个生活化的类比来说：你要搬家，WebSocket就是那个骑着电动车来回跑的调度员，负责不断确认“你搬完没有”“他什么时候来”“走哪个门”，而真正拉家具和家电的应该是货车，也就是WebRTC。你非要用电动车一车一车拉沙发，不是不行，但效率极低，还容易堵在路上一动不动。

在我们的项目里，最终的架构是WebSocket负责信令通道，媒体流走WebRTC的P2P通道。WebRTC底层基于UDP，自带抖动缓冲、丢包重传、拥塞控制这些机制，很适合公网弱网环境。WebSocket虽然也能传二进制数据，但它没有RTP那套时序恢复和丢包容忍能力，一旦出现网络抖动，TCP的重传机制反而会让延迟越拉越大。

当然，也存在一些场景里WebSocket直传是合理选择。比如局域网内部的小工具、演示Demo、或者传输Opus编码后的语音分帧这种小体积、可容忍少量丢失的数据。项目里我们就做了一套基于WebSocket直接传输二进制音频帧的备用方案，后面会详细讲。

1.3 这个项目的整体架构

整个系统的组成大致是这样的：客户端A通过WebSocket连接到信令服务器，登录时携带token完成鉴权；进入房间后，通过WebSocket交换SDP和ICE候选信息；媒体流在WebRTC通道里直接建立；房间内其他人上线、下线、名称变更等情况通过WebSocket推送。服务端选择的是Go语言，Gin作为HTTP框架，gorilla/websocket作为连接升级库；前端使用的是Vue3和VueUse。

选Go的原因很直接：goroutine模型天然适合维护大量长连接，而且部署简单，一个二进制文件扔服务器上就能跑。VueUse是Vue3生态里非常实用的组合式工具库，里面的useWebSocket封装得很完整，能省掉不少手写连接管理的坑。

2. 信令服务端：连接、房间与广播的实现

2.1 连接升级与鉴权

WebSocket连接从HTTP升级而来，这个升级动作在Go里用Upgrader完成。But这里有个关键点：连接建立之前的鉴权必须在升级之前处理掉，不能让未认证的客户端先连上再踢出去。

实际做法是，前端建立连接的时候把token放在URL的query参数里，比如wss://域名/ws?token=xxxxxx。服务端在升级Handler里解析query，校验token，校验通过才允许升级连接。这种方案虽然后来被一些团队吐槽“token会留在日志里”，但在绝大多数业务系统里依然是最简单直接的做法。如果你的安全要求更高，可以在WebSocket握手阶段通过自定义Header传递token，但浏览器端的WebSocket API不支持自定义Header，需要通过子协议Sec-WebSocket-Protocol来带，复杂度会高一点。

package main

import (
	"encoding/json"
	"net/http"
	"strings"

	"github.com/gin-gonic/gin"
	"github.com/gorilla/websocket"
)

var upgrader = websocket.Upgrader{
	ReadBufferSize:  4096,
	WriteBufferSize: 4096,
	CheckOrigin: func(r *http.Request) bool {
		// 生产环境一定要校验 Origin，防止跨域 WebSocket 攻击
		return strings.HasPrefix(r.Header.Get("Origin"), "https://你的域名")
	},
}

type Client struct {
	conn   *websocket.Conn
	roomID string
	userID string
	send   chan []byte
}

func wsHandler(c *gin.Context) {
	token := c.Query("token")
	userID, err := validateToken(token)
	if err != nil {
		c.JSON(http.StatusUnauthorized, gin.H{"error": "invalid token"})
		return
	}

	conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)
	if err != nil {
		return
	}

	client := &Client{
		conn:   conn,
		userID: userID,
		send:   make(chan []byte, 64),
	}
	// ... 注册到 Hub
}

还有一个很容易被忽略的配置是ReadLimit。如果不设置，客户端可以发送任意大小的消息，容易把内存打爆。按业务需要设置一个合理的上限，比如4KB或者2MB，这个看你的业务诉求。我们当时考虑到要支持小尺寸画面帧的直传，Binary消息的上限放宽到了1MB。

2.2 Hub与房间模型

WebSocket服务端不像HTTP那样无状态，一个客户端连接就是一个长期存活的对象，所以必须有一个内存里的管理器来统一维护。我们设计了一个Hub结构，本质上就是一个大Map，按房间号分组存储每个连接的客户端对象。

Hub需要提供这样几个能力：客户端注册（上线）、注销（下线）、加入房间、离开房间、向指定房间广播、向指定用户私聊。这里有一个重点：所有的连接对象和发送通道在并发环境下访问，必须加锁或者设计成单一goroutine处理，否则很容易出现data race。我们采用的是给Hub的每个操作分配一个事件channel，由Hub自身的一个goroutine顺序消费，这样从根上避免了锁竞争。

type Hub struct {
	rooms map[string]map[*Client]struct{}
}

func (h *Hub) JoinRoom(roomID string, client *Client) {
	if h.rooms[roomID] == nil {
		h.rooms[roomID] = make(map[*Client]struct{})
	}
	h.rooms[roomID][client] = struct{}{}
	client.roomID = roomID
}

func (h *Hub) Broadcast(roomID string, msg []byte) {
	for client := range h.rooms[roomID] {
		select {
		case client.send <- msg:
		default:
			// 发送缓冲区满了，说明客户端消费速度跟不上，主动断开
			close(client.send)
			delete(h.rooms[roomID], client)
		}
	}
}

Broadcast里那个select-default很关键。每个Client有一个send channel，写循环从这个channel取数据然后写到WebSocket连接上。如果客户端处理不过来，channel会持续堆积，此时不能无限塞下去，否则goroutine泄漏和内存泄漏等着你。遇到缓冲区满了，直接关闭这个连接是合理的选择，让客户端走重连逻辑。

2.3 消息协议格式

整个信令层的消息协议我建议统一用JSON。虽然二进制协议更省流量，但信令消息频率低、体量小，JSON带来的可读性和调试便利性远大于那些微小的性能收益。

我们定义的信令信封长这样：

{
  "type": "offer",
  "room_id": "room-001",
  "from": "user-a",
  "to": "user-b",
  "data": {}
}

type字段控制消息类型，常用的是join、leave、offer、answer、candidate、heartbeat、broadcast。from和to用于标识消息来源和接收者，data存放具体的业务负载，比如SDP或者ICE候选。

注意一个容易踩的坑：ICE候选消息正是高频消息，客户端可能在一秒内产生十几个candidate，每一帧都要走WebSocket信令通道。这时候JSON的性能问题会被放大，一定要保证服务端处理逻辑足够简单，不做多余的反序列化和再封装，直接透传原消息体。

3. 前端接入：Vue3 + VueUse 的WebSocket实践

3.1 用VueUse封装连接管理

前端如果从零手写WebSocket连接，需要考虑的事情并不少：连接状态管理、断线自动重连、心跳保活、消息统一分发。VueUse的useWebSocket把这些都封装好了，直接安装@vueuse/core就能用。

import { useWebSocket } from '@vueuse/core'

const { status, data, send, open, close } = useWebSocket('wss://api.example.com/ws?token=' + token, {
  autoReconnect: {
    retries: 10,
    delay: 1000,
    onFailed() {
      console.error('WebSocket 重连失败')
    }
  },
  heartbeat: {
    message: JSON.stringify({ type: 'heartbeat' }),
    interval: 30000
  },
  immediate: true
})

这样配置的好处是：页面加载即建立连接，连接意外断开后自动尝试重连，每30秒自动发一次心跳。不过要注意，autoReconnect的retries不会无限重试，重试次数用完后状态会进入CLOSED，这时候需要UI层提示用户手动刷新或者重新登录。

vueuse下的useWebSocket还有一个很实用的点：它把send和open分开封装，你可以自己写一个带重试的发送方法。比如用户发言时，如果连接还没建好，先等onopen事件再发送。我们项目里封装了一个safeSend函数，发送之前检查status.value，如果处于CONNECTING状态就等待，避免消息丢失。

3.2 消息分发与状态管理

WebSocket收到一条消息，怎么分发到对应的业务模块？我们用一个central handler统一监听data，然后根据消息里的type字段调用不同的处理函数。这个模式类似于前端的reducer，代码清晰且好维护。

watch(data, (raw) => {
  if (!raw) return
  const msg = JSON.parse(raw)
  switch (msg.type) {
    case 'offer':
      handleOffer(msg)
      break
    case 'candidate':
      handleCandidate(msg)
      break
    case 'user_joined':
      roomStore.addUser(msg.from)
      break
    case 'user_left':
      roomStore.removeUser(msg.from)
      break
  }
})

组件层级上，我们只在负责音视频通话的页面组件里调用useWebSocket，通过provide/inject把连接对象共享给子组件。不要在多个组件里各建各的连接，否则一个页面会同时存在多条WebSocket连接，服务端维护成本翻倍，调试的时候也容易晕。

4. 媒体流传输：不只有WebRTC一条路

4.1 首选方案：WebSocket做信令，WebRTC传音视频

这个方案是整个项目的核心。WebRTC负责媒体传输，但它的连接建立过程依赖信令交换SDP和ICE候选。SDP是媒体的描述信息，包括编解码器、IP端口这些内容；ICE候选则是候选的传输地址。两者通过WebSocket转发，逻辑非常简单。

关键流程是这样的：发起方通过getUserMedia拿到摄像头和麦克风流，创建RTCPeerConnection，调用createOffer生成一个SDP，设置本地描述后用WebSocket发给接收方；接收方同样创建RTCPeerConnection，接收到offer后调用setRemoteDescription、createAnswer，再通过WebSocket把answer发回去；此后双方通过onicecandidate回调收集ICE候选，也走WebSocket互换。

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' }
  ]
})

pc.onicecandidate = (event) => {
  if (event.candidate) {
    ws.send(JSON.stringify({
      type: 'candidate',
      from: myUserId,
      to: remoteUserId,
      data: event.candidate
    }))
  }
}

pc.ontrack = (event) => {
  remoteVideo.srcObject = event.streams[0]
}

async function makeOffer() {
  const offer = await pc.createOffer()
  await pc.setLocalDescription(offer)
  ws.send(JSON.stringify({
    type: 'offer',
    from: myUserId,
    to: remoteUserId,
    data: offer
  }))
}

这里有个细节要注意：ICE候选是收集和发送异步进行的，如果你等着所有候选都收集完再统一发送，会显著增加连接建立时间。正确做法是onicecandidate一旦触发就通过WebSocket发出去，这叫Trickle ICE。对应地，接收端每收到一个candidate就调用pc.addIceCandidate。

4.2 备选方案：WebSocket直接传二进制帧

上面说WebRTC是首选，但有些场景下你没法用WebRTC。比如两个客户端处于复杂的NAT后面，又没有可用的STUN/TURN中转；或者业务本身就是局域网内的小型工具，额外架一台媒体服务器明显过重。这时候WebSocket直传二进制数据就是一条退路。

我们做了一套基于音频的直传方案。前端用AudioWorklet拿到PCM音频数据，切成小块，封装成自定义的二进制帧，通过WebSocket发送到服务端，服务端原样广播给房间里其他人。帧头设计很简单，关键信息包括魔数、帧类型、序号和payload长度。

| 2 bytes magic (0xAA55) | 1 byte type | 4 bytes sequence | 2 bytes payload length | payload |

这个方案的优点是实现非常快，而且不用处理ICE、STUN那些复杂概念。缺点是只要网络一抖，音频就会断续、卡顿甚至花音，因为它没有WebRTC那套抖动缓冲和丢包恢复机制。作为应急方案或者演示用可以，生产环境还是得老实回归WebRTC。

4.3 方案对比与选型建议

做技术选型的时候，建议一定要回归到业务场景去对比，不要为了用新技术而用。我们整理过一个简单的对比表：

方案	延迟	带宽效率	抗丢包能力	开发成本	适用场景
WebSocket直传二进制	局域网内很低	一般	很差	低	局域网演示、内网工具、小规模原型
WebSocket信令 + WebRTC媒体通道	低	高	较好	中高	公网实时音视频、多人通话、直播连麦
WebSocket信令 + 媒体服务器中转	中	中	好	高	大型直播、万人房间、服务端录制

如果你拿不准项目该用哪种，可以先看自己的客户端数量级和网络环境。两个房间且公网环境，直接上WebRTC；内网工具而且只是演示，WebSocket直传快速跑通更划算；如果是大规模分发，考虑媒体服务器架构，WebSocket主要还是干信令的活。

5. 连接稳定性：1006、心跳、重连与H5/App差异

5.1 1006错误到底是什么

浏览器里WebSocket连接断开时，onclose事件的code是1006，全称是Abnormal Closure，意思就是连接异常关闭，不是正常的Close帧导致的关闭。这个问题在WebSocket项目里出现频率极高，原因却五花八门。

最常见的是代理服务器或负载均衡器超时断开的。比如Nginx默认对上游连接的空闲超时是60秒，如果WebSocket连接在60秒内没有任何数据流动，Nginx就把连接断掉。表现就是正常连着但突然onclose code 1006。解决办法就是心跳，客户端定时发ping或者应用层心跳消息，保持连接有数据流动，服务端配置也要把proxy_read_timeout调大。

其次是移动网络切换。手机从Wi-Fi切到4G/5G，TCP连接被重置，WebSocket自然断开。这种场景只能靠前端自动重连兜底。另外，服务端进程panic或者重启也会导致所有连接瞬间掉线，客户端看到的就是1006，同时服务端日志里能看到异常堆栈。

排查1006的正确姿势是：先看服务端日志，确认有没有收到Close帧或者异常；再看代理层和负载均衡层的超时配置；最后看客户端网络环境。千万不要只盯着浏览器控制台，否则你只能看到一个冷冰冰的1006。

5.2 心跳与重连策略

心跳保活基本是WebSocket项目的标配。我们用的是应用层心跳，客户端每30秒发送一条JSON心跳消息，服务端收到后原样回一条pong。设计上让心跳消息和业务消息共用同一个WebSocket连接，不需要额外建通道。

重连策略要注意退避，不能崩溃后立刻疯狂重连。我们采用的逻辑是：第一次重连延迟1秒，之后每次翻倍，最大不超过30秒，这个方案在业界被称为指数退避。好处是网络恢复前重连频率逐步降低，避免加重服务端压力。

前端重连成功后，必须重新完成一次房间join动作，把客户端状态恢复到断线之前。这一步非常容易漏：自动重连只是恢复了WebSocket连接，房间里其他成员并不知道你回来了，如果是音视频通话场景，还需要重新发起一次offer协商。我们在这块踩过坑，后来在onopen的回调里固定执行一个restoreSession方法，才把这个问题根治。

5.3 H5能连、打包成App连不上的排查

这个热词组合我搜了下，遇到的人还真不少。现象是同一个项目，浏览器里打开H5页面WebSocket连接正常，打包成Android或iOS的App后就连接失败。问题通常出在平台的网络权限和安全策略上。

Android端最常见的是明文流量限制。Android 9开始默认禁止应用使用明文HTTP和WebSocket流量，如果你的连接是ws://开头，打包后就直接报错。解决办法要么升级到wss://，要么在AndroidManifest里配置usesCleartextTraffic="true"，或者在network_security_config.xml里针对特定域名放行明文流量。

iOS端的情况类似，App Transport Security会默认阻止不安全的HTTP连接，同样需要你配置NSAppTransportSecurity相关的例外规则。另外一个容易被忽略的问题是打包后的网络权限，Android需要在Manifest里声明INTERNET权限，iOS需要确保没有误删网络相关配置。

排查这类问题最快的路径就是看App端的日志，一般会明确告诉你连接失败的原因。另外提醒一句：测试的时候先分清是握手失败还是连接被拒，握手失败大多是地址、端口、证书问题，连接被拒多是域名白名单或者网络权限问题。

5.4 “Stream disconnected before completion”这类异常

这个报错常见于WebSocket请求发出后还没完成就断开连接。出现这种问题，先检查是不是消息体过大，超出了服务端设置的ReadLimit。其次是服务端在消息处理过程中主动关闭了连接，比如鉴权中间件在某个错误路径上直接return关掉了连接。再有一种情况是发送方在消息未完全写入socket时就关闭了连接。

排查思路和1006差不多，但从服务端日志入手更快。如果看到服务端日志里还没有收到完整的消息就EOF了，大概率是代理层或者客户端主动断开；如果服务端收到了完整消息但处理异常，那就是代码逻辑的问题。

6. 压测、框架话题与高频面试题

6.1 用JMeter WebSocket Sampler做基础压测

WebSocket长连接服务和普通HTTP接口的压测思路完全不同。HTTP压测是发一次请求收一次响应就结束，WebSocket得先建连接、保持连接、再发消息、再收响应。JMeter原生不支持WebSocket协议，需要通过Plugins Manager安装WebSocket Samplers插件。

压测脚本里面至少需要三个采样器：WebSocket Open Connection建立连接，WebSocket Request Response Sampler发送信令消息并等待响应，WebSocket Close Connection关闭连接。每个线程代表一个虚拟用户，线程数可以模拟并发连接数。我们当时压下来的结果是单机Go服务端支撑了大概两万个并发连接，内存占用还在可接受范围，瓶颈反而是文件描述符限制。

需要注意的是，压测WebSocket时不要只关注连接建立，还要关注连接建立后的消息转发延迟。我们的做法是在Request Response Sampler里发送一条信令消息，观察响应时间，重点看P99和P95两个指标，而不是被平均值忽悠。

6.2 其他后端技术栈的等价实现

如果你的后端不是Go，其实思路是通用的。Netty做WebSocket服务时，鉴权可以在pipeline里自定义一个handler，在HttpRequest解析阶段校验收到的token，然后再交给WebSocketFrame处理。Spring Boot生态里，实现WebSocketHandler之后重写afterConnectionEstablished和handleMessage两个方法就够了，群组广播用SimpMessagingTemplate可以非常方便地向指定用户或所有连入用户推送消息。

Spring Boot选框架的话，我会优先考虑Spring官方自带的WebSocket模块，功能虽然基础但胜在稳定；如果需求里有广播、群组、属性设置这些复杂能力，Netty-SocketIO或Spring Messaging结合STOMP协议会更顺手。

6.3 WebSocket面试高频问题整理

因为热词里带了面试题，这块也顺便说说。面试官问WebSocket的时候，最爱问的其实就这么几类：WebSocket和HTTP的关系是什么，为什么WebSocket能保持连接而HTTP不行；WebSocket底层是怎么做帧解析的；服务端如何维护大量连接；断线重连怎么设计；鉴权怎么做；以及和TCP长连接、SSE这些方案的选型区别。

回答这些问题时，最好的方式是用真实项目经历说话。比如讲WebSocket和HTTP的关系，就直接说WebSocket握手本身就是一次HTTP Upgrade请求，状态码返回101之后才切换成WebSocket协议。讲服务端如何维护大量连接，就结合自己项目里Hub和goroutine的设计来讲。一个做过真实项目的候选人，在这些问题上说的话和背八股的人一眼就能区分开。

7. 常见问题速查表

最后整理一张速查表，把项目里遇到的高频问题列出来，方便以后排查。

现象	可能原因	解决办法
连接在空闲后断开，onclose code 1006	代理层或负载均衡空闲超时	加心跳保活，调大proxy_read_timeout
H5正常，打包成App连不上	明文流量限制或缺少网络权限	用wss或配置cleartext和权限
消息发送失败：stream disconnected	消息体过大或服务端处理异常	调整ReadLimit，检查服务端日志
连接建立后无法收发消息	服务端没有正确启动读写循环	检查是否启用了readPump和writePump
房间内广播丢失	send channel缓冲区满被关闭	检查客户端消费速度，增加缓冲区或强制重连
自动重连后状态不一致	没有重新join房间	在onopen里恢复会话状态

这里再补充一个经验心得：WebSocket项目里最难排查的问题有一半出在服务端和客户端对连接生命周期理解不一致。客户端以为连接还活着，服务端早就超时清理掉了；服务端以为连接已关闭，客户端还在傻等消息。与其等出了问题再查，不如把心跳、超时、重连这三件事在项目一开始就设计好。

我个人在实际项目里的体会是，WebSocket本身并不复杂，复杂的是围绕连接衍生的鉴权、超时、重连、消息可靠性这些工程化问题。如果你的业务核心是音视频，一定把媒体流交给WebRTC这种专业组件，WebSocket安心做调度员就好。最后再分享一个小技巧：不管前端还是后端，把日志里每条连接的建立、心跳、关闭都打上时间戳和用户标识，线上的很多灵异问题，到最后都是靠这些日志定位到的。