简介这份资源是在AS3.0环境下实现的WebSocket客户端库面向使用Flash Professional、Flex Builder等工具开发交互式网页、游戏或移动应用的ActionScript开发者帮助其在Flash环境中建立客户端与服务器之间的长连接实现低延迟的双向实时通信适用于在线游戏、实时聊天、股票行情推送等场景。压缩包共133个文件以115个as源码类文件为主体另含mxml示例、project与prefs工程配置、xml描述文件、swc编译产物及md说明文档等整体约392KB结构紧凑便于查阅。库已对底层TCP套接字进行封装开发者无需处理复杂网络细节导入后创建WebSocket对象、指定服务器地址与端口即可通过send方法发送数据并监听onMessage、onOpen、onClose、onError等事件完成收发与状态管理。目前已有222人学习下载结合源码、示例与文档可快速集成WebSocket功能提升实时网络应用的开发效率与用户体验。1. as3.0 websocketFlash 退场之后这套老技术为什么还在被翻出来如果你现在还在搜 as3.0 websocket大概率不是要做一个全新的 Flash 网站而是手里有一份跑了很多年的 ActionScript 3.0 工程需要让它跟后端保持长连接。可能是某个工业看板、某套内网教学系统、某个还在服役的互动展示程序前端是 AS3 写的后端已经换成了 WebSocket 服务中间这层协议怎么接上就是全部问题所在。AS3 原生只给了 Socket 和 XMLSocket没有 WebSocket 类。想在 AS3 里用 WebSocket绕不开两条路一是自己按 RFC 6455 在 Socket 上实现握手和帧解析二是用现成的 as3-websocket 类库。这篇文章就把这两条路都拆开讲清楚包括握手报文怎么拼、掩码怎么算、帧怎么拆、心跳怎么保、断线怎么重连以及那些只有真跑过才会遇到的坑。适合手上真有 AS3 工程、需要落地长连接的开发者也适合想理解 WebSocket 协议底层的人拿它当练手样本。2. AS3 里接 WebSocket 的两条路自研帧解析还是用现成库2.1 为什么 AS3 没有原生 WebSocket只能自己补Flash Player 和 AIR 的网络 API 里能建立 TCP 连接的是flash.net.Socket能发文本的是XMLSocket。WebSocket 是建立在 TCP 之上的应用层协议握手阶段用 HTTP Upgrade之后是二进制帧。AS3 的 Socket 给你的是原始字节流readUTFBytes、writeUTFBytes、readByte这些方法足够你手动完成整个协议。浏览器里的 JS 有new WebSocket(url)Flash 没有对应封装这是历史原因WebSocket 标准定稿时 Flash 已经进入生命周期后段Adobe 没有动力再往运行时里加新 API。所以 AS3 侧的一切都要自己写或者依赖社区库。这里有个关键判断如果你的后端是标准 WebSocket 服务比如基于某开源框架实现的 ws 服务那 AS3 必须严格按 RFC 6455 来握手头、帧格式一个字节都不能错否则服务端会直接断开。如果后端是你自己能改的理论上可以自定义一套更简单的协议但那样就失去了用 WebSocket 的意义不推荐。2.2 自研实现的最小骨架Socket 连接与握手先看握手。WebSocket 握手本质是一个 HTTP GET 请求带几个特定头// AS3 手动发起 WebSocket 握手 // 假设已建立 socket 连接connected 事件已触发 private function sendHandshake():void { // 1. 生成 16 字节随机数Base64 编码作为 Sec-WebSocket-Key var nonce:ByteArray new ByteArray(); for (var i:int 0; i 16; i) { nonce.writeByte(Math.floor(Math.random() * 256)); } var key:String Base64.encodeByteArray(nonce); // 2. 拼接握手请求行与头部 var req:String GET /chat HTTP/1.1\r\n Host: host : port \r\n Upgrade: websocket\r\n Connection: Upgrade\r\n Sec-WebSocket-Key: key \r\n Sec-WebSocket-Version: 13\r\n \r\n; // 3. 以 UTF 字节写入 socket socket.writeUTFBytes(req); socket.flush(); }这段代码的逻辑是先生成客户端随机 key再按 HTTP 报文格式拼出请求最后通过 Socket 发出。参数上要注意三点。第一Sec-WebSocket-Key必须是 16 字节随机数的 Base64长度固定 24 字符服务端会拿它和固定 GUID 拼接后做 SHA-1 再 Base64返回在Sec-WebSocket-Accept里客户端应当校验这个值。第二Host头必须和实际连接的主机端口一致很多服务端会校验。第三行尾必须是\r\n最后要有一个空行少一个\r服务端就认为报文没结束。握手响应回来后你需要从 Socket 的字节流里读出 HTTP 响应头找到101 Switching Protocols和Sec-WebSocket-Accept校验通过后后续字节就都是 WebSocket 帧了。这里有个容易翻车的点握手响应和第一帧数据可能在同一批字节里到达如果你读完响应头就把缓冲区清了第一帧就丢了。正确做法是读完头部后把剩余字节留在缓冲区里交给帧解析器。2.3 帧解析掩码、操作码和分片怎么处理WebSocket 帧格式是自研实现里最需要耐心的部分。一个帧的头部至少 2 字节结构如下字段位数含义FIN1是否为消息最后一帧RSV1-33扩展位通常为 0Opcode4帧类型1 文本、2 二进制、8 关闭、9 ping、10 pongMask1客户端发往服务端必须为 1Payload len7载荷长度126 表示后跟 2 字节长度127 表示后跟 8 字节Masking-key32掩码密钥Mask 为 1 时存在Payload data变长实际数据需与掩码异或还原客户端发数据必须加掩码服务端发数据不能加掩码。掩码算法是对载荷第 i 个字节与 masking-key 的第 i%4 个字节做异或。解析时反过来做一次就还原了。// 解析一个 WebSocket 帧简化版假设数据已完整到达 private function parseFrame(buf:ByteArray):void { buf.position 0; var b0:int buf.readUnsignedByte(); var b1:int buf.readUnsignedByte(); var fin:Boolean (b0 0x80) ! 0; var opcode:int b0 0x0F; var masked:Boolean (b1 0x80) ! 0; var len:int b1 0x7F; // 长度扩展126 读 2 字节127 读 8 字节 if (len 126) { len buf.readUnsignedShort(); } else if (len 127) { // AS3 没有无符号 64 位实际项目里载荷很少超过 65535 var high:uint buf.readUnsignedInt(); var low:uint buf.readUnsignedInt(); len low; // 简化处理真实场景需判断 high 是否为 0 } // 读取掩码密钥 var maskKey:ByteArray new ByteArray(); if (masked) { buf.readBytes(maskKey, 0, 4); } // 读取并还原载荷 var payload:ByteArray new ByteArray(); buf.readBytes(payload, 0, len); if (masked) { for (var i:int 0; i len; i) { payload[i] payload[i] ^ maskKey[i % 4]; } } // 按 opcode 分发 switch (opcode) { case 0x1: // 文本帧 handleText(payload); break; case 0x2: // 二进制帧 handleBinary(payload); break; case 0x8: // 关闭帧 socket.close(); break; case 0x9: // ping需回 pong sendPong(payload); break; } }这段解析里fin和opcode决定消息边界。如果收到opcode0的续帧说明上一条消息还没结束要把载荷拼接到上一条消息的缓冲区里直到fin1才算完整。很多自研实现只处理单帧消息遇到分片就乱码这是最常见的翻车点之一。参数上len的三种编码方式必须都支持虽然实际业务里超过 65535 字节的消息不多但一旦后端发了大消息而你没处理 127 分支解析就会错位后面所有帧全乱。掩码密钥是 4 字节异或时用i % 4取对应字节这个细节写错会导致中文乱码。2.4 用现成库的取舍省事但要看维护状态如果不想自己啃协议社区里有 as3-websocket 这类库封装了握手、帧解析、事件回调。用库的好处是省掉上面所有字节级操作坏处是这类库大多停止维护多年遇到新版本服务端的某些行为比如强制 permessage-deflate 压缩扩展可能不兼容。选型时我一般看三点库是否处理了分片、是否支持 ping/pong 心跳、是否暴露了原始字节接口。前两点决定稳定性第三点决定你遇到协议层问题时能不能自己排查。如果库把 Socket 完全封装死出问题时你连抓到的字节都看不到那就成了黑匣子排查成本反而更高。3. 把连接跑起来心跳、重连与二进制消息的落地细节3.1 心跳保活为什么 30 秒是个常见阈值WebSocket 连接建立后中间可能经过多层网络设备空闲连接会被静默断开。AS3 侧需要主动发 ping 帧保活。常见做法是每 30 秒发一次 ping服务端回 pong连续两次没收到 pong 就判定连接已死触发重连。// 心跳定时器每 30 秒发一次 ping private var heartbeatTimer:Timer new Timer(30000); private var missedPong:int 0; private function startHeartbeat():void { heartbeatTimer.addEventListener(TimerEvent.TIMER, onHeartbeat); heartbeatTimer.start(); } private function onHeartbeat(e:TimerEvent):void { if (missedPong 2) { // 连续两次没收到 pong判定断线 heartbeatTimer.stop(); reconnect(); return; } sendPing(); missedPong; } // 收到 pong 帧时重置计数 private function onPong():void { missedPong 0; }30 秒这个值不是随便定的。太短会增加无谓流量太长则断线发现不及时。多数反向代理和负载均衡的空闲超时在 60 秒左右心跳间隔取它的一半比较稳妥。如果你的服务端自己也会发 ping那客户端只要负责回 pong 就行不必再主动发。注意 ping 帧的载荷可以是空的也可以带应用数据服务端必须原样回在 pong 里。有些实现把 ping 当业务消息处理这是误用。3.2 断线重连指数退避比固定间隔靠谱断线后立刻重连如果服务端还没恢复会形成大量无效连接。指数退避是更稳的做法第一次 1 秒后重连失败则 2 秒、4 秒、8 秒上限 30 秒。private var retryDelay:int 1000; private const MAX_DELAY:int 30000; private function reconnect():void { var timer:Timer new Timer(retryDelay, 1); timer.addEventListener(TimerEvent.TIMER, function(e:TimerEvent):void { openSocket(); }); timer.start(); // 下次延迟翻倍封顶 30 秒 retryDelay Math.min(retryDelay * 2, MAX_DELAY); } // 连接成功后重置延迟 private function onConnected(e:Event):void { retryDelay 1000; sendHandshake(); }这里的关键是连接成功后必须把retryDelay重置回 1 秒否则下次断线会直接从 30 秒开始等。另外重连时要先清理旧的 Socket 对象和定时器不然会出现多个连接同时存在的诡异状态消息重复处理。3.3 二进制消息ByteArray 的读写位置陷阱AS3 的ByteArray有个position指针读写都会移动它。解析帧时如果忘了重置position读出来的数据就是错的。上面parseFrame开头那句buf.position 0就是防这个。发二进制消息时要按帧格式组装// 发送二进制帧客户端需加掩码 private function sendBinary(data:ByteArray):void { var frame:ByteArray new ByteArray(); frame.writeByte(0x82); // FIN1, opcode2 var len:int data.length; if (len 126) { frame.writeByte(0x80 | len); // Mask1 } else if (len 65536) { frame.writeByte(0x80 | 126); frame.writeShort(len); } // 4 字节掩码密钥 var mask:ByteArray new ByteArray(); for (var i:int 0; i 4; i) { mask.writeByte(Math.floor(Math.random() * 256)); } frame.writeBytes(mask); // 载荷异或掩码 data.position 0; for (var j:int 0; j len; j) { frame.writeByte(data[j] ^ mask[j % 4]); } socket.writeBytes(frame); socket.flush(); }参数上0x82是 FIN 加二进制 opcode文本消息则是0x81。掩码位必须置 1否则服务端会按协议错误关闭连接。data.position 0这行不能省如果这个 ByteArray 之前被读过position 停在末尾循环就从越界位置开始发出去的全是空。3.4 用 Wireshark 验证帧格式对不对自研实现出问题时最有效的排查手段是抓包。在本地跑一个 WebSocket 服务用 Wireshark 过滤tcp.port 你的端口看握手请求和响应再看后续帧的 FIN、opcode、mask 位是否符合预期。如果服务端返回400 Bad Request多半是握手头拼错重点检查Sec-WebSocket-Key长度和行尾。如果握手成功但消息乱码重点看掩码异或和长度字段。如果连接几秒后断开看是不是没回 pong。抓包能看到字节级真相比在代码里加日志猜要快得多。4. as3.0 websocket 避坑五条血泪经验4.1 握手响应和首帧粘包首条消息丢失现象连接建立成功但服务端发的第一条欢迎消息客户端收不到从第二条开始正常。原因握手响应和第一帧数据在同一批 TCP 字节里到达代码读完 HTTP 头后把整个缓冲区清空首帧被丢弃。解决读完响应头后计算已消耗的字节数把剩余字节保留在缓冲区直接交给帧解析器处理不要清空。4.2 中文消息乱码英文正常现象服务端发的中文显示为乱码英文和数字正常。原因掩码异或时用了错误的索引或者文本帧没有按 UTF-8 解码直接当单字节字符处理。解决确认异或索引用i % 4文本载荷用payload.readUTFBytes(payload.length)读取不要用readByte逐个转字符。4.3 分片消息只收到第一片现象大消息只收到开头一部分后续内容丢失或解析报错。原因解析器只处理fin1的帧遇到opcode0的续帧没有拼接逻辑。解决维护一个消息缓冲区收到opcode1或2时开始累积收到opcode0时追加直到fin1才交付业务层。4.4 重连后消息重复处理现象断线重连后同一条消息被处理了两次。原因旧 Socket 的事件监听没有移除新旧两个 Socket 同时收到消息。解决重连前调用socket.removeEventListener清理所有监听把 socket 置空再创建新对象。4.5 心跳发了但服务端不回 pong现象客户端按时发 ping但一直收不到 pong误判断线频繁重连。原因服务端实现只处理文本帧把 ping 帧当未知类型忽略或者服务端要求客户端回 pong 而不是主动发 ping。解决先确认服务端的心跳策略如果服务端主动发 ping客户端只需在收到 ping 时回 pong不要自己再发。抓包确认 ping 帧确实到达服务端。5. 进阶用 AS3 做 WebSocket 代理层把老工程接进新后端手上有一份庞大的 AS3 业务代码直接改网络层风险太大更稳的做法是在 AS3 里做一个薄代理层上层业务照旧调用原来的接口代理层负责把调用翻译成 WebSocket 帧收到帧再翻译回业务事件。这样协议细节被隔离在一层里业务代码几乎不用动。代理层的核心是一个请求-响应映射表。每条发出去的消息带一个自增的seq代理层把seq和回调函数存进字典收到响应时按seq找回回调。private var pending:Object {}; // seq - callback private var seq:int 0; public function request(cmd:String, params:Object, callback:Function):void { seq; pending[seq] callback; var msg:Object { seq: seq, cmd: cmd, params: params }; sendText(JSON.stringify(msg)); } private function onMessage(text:String):void { var msg:Object JSON.parse(text); var cb:Function pending[msg.seq]; if (cb ! null) { delete pending[msg.seq]; cb(msg.data); } }这个模式的好处是业务层完全不用关心 WebSocket 的帧、掩码、心跳只面对request和回调。参数上seq用自增整数即可注意在重连后要清空pending字典否则旧请求的回调会永远挂着造成内存泄漏。验证代理层是否可靠我一般做两件事一是模拟服务端延迟响应和乱序响应看回调是否按seq正确匹配二是模拟断线重连确认重连后新请求正常、旧请求被清理。这两步过了代理层基本就能扛住日常使用。最后说个我自己的习惯每次改完帧解析代码先不接业务而是写一个回环测试客户端发什么服务端原样回什么用不同长度的消息1 字节、125 字节、126 字节、70000 字节各跑一遍。长度边界是帧解析最容易错的地方回环测试能在接业务之前就把问题暴露出来。这套方法帮我省了很多事后排查的时间希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/14 8:20:05 · 阅读 1.2k AS3.0 WebSocket实战：自研帧解析与现成库选型避坑指南
简介这份资源是在AS3.0环境下实现的WebSocket客户端库面向使用Flash Professional、Flex Builder等工具开发交互式网页、游戏或移动应用的ActionScript开发者帮助其在Flash环境中建立客户端与服务器之间的长连接实现低延迟的双向实时通信适用于在线游戏、实时聊天、股票行情推送等场景。压缩包共133个文件以115个as源码类文件为主体另含mxml示例、project与prefs工程配置、xml描述文件、swc编译产物及md说明文档等整体约392KB结构紧凑便于查阅。库已对底层TCP套接字进行封装开发者无需处理复杂网络细节导入后创建WebSocket对象、指定服务器地址与端口即可通过send方法发送数据并监听onMessage、onOpen、onClose、onError等事件完成收发与状态管理。目前已有222人学习下载结合源码、示例与文档可快速集成WebSocket功能提升实时网络应用的开发效率与用户体验。1. as3.0 websocketFlash 退场之后这套老技术为什么还在被翻出来如果你现在还在搜 as3.0 websocket大概率不是要做一个全新的 Flash 网站而是手里有一份跑了很多年的 ActionScript 3.0 工程需要让它跟后端保持长连接。可能是某个工业看板、某套内网教学系统、某个还在服役的互动展示程序前端是 AS3 写的后端已经换成了 WebSocket 服务中间这层协议怎么接上就是全部问题所在。AS3 原生只给了 Socket 和 XMLSocket没有 WebSocket 类。想在 AS3 里用 WebSocket绕不开两条路一是自己按 RFC 6455 在 Socket 上实现握手和帧解析二是用现成的 as3-websocket 类库。这篇文章就把这两条路都拆开讲清楚包括握手报文怎么拼、掩码怎么算、帧怎么拆、心跳怎么保、断线怎么重连以及那些只有真跑过才会遇到的坑。适合手上真有 AS3 工程、需要落地长连接的开发者也适合想理解 WebSocket 协议底层的人拿它当练手样本。2. AS3 里接 WebSocket 的两条路自研帧解析还是用现成库2.1 为什么 AS3 没有原生 WebSocket只能自己补Flash Player 和 AIR 的网络 API 里能建立 TCP 连接的是flash.net.Socket能发文本的是XMLSocket。WebSocket 是建立在 TCP 之上的应用层协议握手阶段用 HTTP Upgrade之后是二进制帧。AS3 的 Socket 给你的是原始字节流readUTFBytes、writeUTFBytes、readByte这些方法足够你手动完成整个协议。浏览器里的 JS 有new WebSocket(url)Flash 没有对应封装这是历史原因WebSocket 标准定稿时 Flash 已经进入生命周期后段Adobe 没有动力再往运行时里加新 API。所以 AS3 侧的一切都要自己写或者依赖社区库。这里有个关键判断如果你的后端是标准 WebSocket 服务比如基于某开源框架实现的 ws 服务那 AS3 必须严格按 RFC 6455 来握手头、帧格式一个字节都不能错否则服务端会直接断开。如果后端是你自己能改的理论上可以自定义一套更简单的协议但那样就失去了用 WebSocket 的意义不推荐。2.2 自研实现的最小骨架Socket 连接与握手先看握手。WebSocket 握手本质是一个 HTTP GET 请求带几个特定头// AS3 手动发起 WebSocket 握手 // 假设已建立 socket 连接connected 事件已触发 private function sendHandshake():void { // 1. 生成 16 字节随机数Base64 编码作为 Sec-WebSocket-Key var nonce:ByteArray new ByteArray(); for (var i:int 0; i 16; i) { nonce.writeByte(Math.floor(Math.random() * 256)); } var key:String Base64.encodeByteArray(nonce); // 2. 拼接握手请求行与头部 var req:String GET /chat HTTP/1.1\r\n Host: host : port \r\n Upgrade: websocket\r\n Connection: Upgrade\r\n Sec-WebSocket-Key: key \r\n Sec-WebSocket-Version: 13\r\n \r\n; // 3. 以 UTF 字节写入 socket socket.writeUTFBytes(req); socket.flush(); }这段代码的逻辑是先生成客户端随机 key再按 HTTP 报文格式拼出请求最后通过 Socket 发出。参数上要注意三点。第一Sec-WebSocket-Key必须是 16 字节随机数的 Base64长度固定 24 字符服务端会拿它和固定 GUID 拼接后做 SHA-1 再 Base64返回在Sec-WebSocket-Accept里客户端应当校验这个值。第二Host头必须和实际连接的主机端口一致很多服务端会校验。第三行尾必须是\r\n最后要有一个空行少一个\r服务端就认为报文没结束。握手响应回来后你需要从 Socket 的字节流里读出 HTTP 响应头找到101 Switching Protocols和Sec-WebSocket-Accept校验通过后后续字节就都是 WebSocket 帧了。这里有个容易翻车的点握手响应和第一帧数据可能在同一批字节里到达如果你读完响应头就把缓冲区清了第一帧就丢了。正确做法是读完头部后把剩余字节留在缓冲区里交给帧解析器。2.3 帧解析掩码、操作码和分片怎么处理WebSocket 帧格式是自研实现里最需要耐心的部分。一个帧的头部至少 2 字节结构如下字段位数含义FIN1是否为消息最后一帧RSV1-33扩展位通常为 0Opcode4帧类型1 文本、2 二进制、8 关闭、9 ping、10 pongMask1客户端发往服务端必须为 1Payload len7载荷长度126 表示后跟 2 字节长度127 表示后跟 8 字节Masking-key32掩码密钥Mask 为 1 时存在Payload data变长实际数据需与掩码异或还原客户端发数据必须加掩码服务端发数据不能加掩码。掩码算法是对载荷第 i 个字节与 masking-key 的第 i%4 个字节做异或。解析时反过来做一次就还原了。// 解析一个 WebSocket 帧简化版假设数据已完整到达 private function parseFrame(buf:ByteArray):void { buf.position 0; var b0:int buf.readUnsignedByte(); var b1:int buf.readUnsignedByte(); var fin:Boolean (b0 0x80) ! 0; var opcode:int b0 0x0F; var masked:Boolean (b1 0x80) ! 0; var len:int b1 0x7F; // 长度扩展126 读 2 字节127 读 8 字节 if (len 126) { len buf.readUnsignedShort(); } else if (len 127) { // AS3 没有无符号 64 位实际项目里载荷很少超过 65535 var high:uint buf.readUnsignedInt(); var low:uint buf.readUnsignedInt(); len low; // 简化处理真实场景需判断 high 是否为 0 } // 读取掩码密钥 var maskKey:ByteArray new ByteArray(); if (masked) { buf.readBytes(maskKey, 0, 4); } // 读取并还原载荷 var payload:ByteArray new ByteArray(); buf.readBytes(payload, 0, len); if (masked) { for (var i:int 0; i len; i) { payload[i] payload[i] ^ maskKey[i % 4]; } } // 按 opcode 分发 switch (opcode) { case 0x1: // 文本帧 handleText(payload); break; case 0x2: // 二进制帧 handleBinary(payload); break; case 0x8: // 关闭帧 socket.close(); break; case 0x9: // ping需回 pong sendPong(payload); break; } }这段解析里fin和opcode决定消息边界。如果收到opcode0的续帧说明上一条消息还没结束要把载荷拼接到上一条消息的缓冲区里直到fin1才算完整。很多自研实现只处理单帧消息遇到分片就乱码这是最常见的翻车点之一。参数上len的三种编码方式必须都支持虽然实际业务里超过 65535 字节的消息不多但一旦后端发了大消息而你没处理 127 分支解析就会错位后面所有帧全乱。掩码密钥是 4 字节异或时用i % 4取对应字节这个细节写错会导致中文乱码。2.4 用现成库的取舍省事但要看维护状态如果不想自己啃协议社区里有 as3-websocket 这类库封装了握手、帧解析、事件回调。用库的好处是省掉上面所有字节级操作坏处是这类库大多停止维护多年遇到新版本服务端的某些行为比如强制 permessage-deflate 压缩扩展可能不兼容。选型时我一般看三点库是否处理了分片、是否支持 ping/pong 心跳、是否暴露了原始字节接口。前两点决定稳定性第三点决定你遇到协议层问题时能不能自己排查。如果库把 Socket 完全封装死出问题时你连抓到的字节都看不到那就成了黑匣子排查成本反而更高。3. 把连接跑起来心跳、重连与二进制消息的落地细节3.1 心跳保活为什么 30 秒是个常见阈值WebSocket 连接建立后中间可能经过多层网络设备空闲连接会被静默断开。AS3 侧需要主动发 ping 帧保活。常见做法是每 30 秒发一次 ping服务端回 pong连续两次没收到 pong 就判定连接已死触发重连。// 心跳定时器每 30 秒发一次 ping private var heartbeatTimer:Timer new Timer(30000); private var missedPong:int 0; private function startHeartbeat():void { heartbeatTimer.addEventListener(TimerEvent.TIMER, onHeartbeat); heartbeatTimer.start(); } private function onHeartbeat(e:TimerEvent):void { if (missedPong 2) { // 连续两次没收到 pong判定断线 heartbeatTimer.stop(); reconnect(); return; } sendPing(); missedPong; } // 收到 pong 帧时重置计数 private function onPong():void { missedPong 0; }30 秒这个值不是随便定的。太短会增加无谓流量太长则断线发现不及时。多数反向代理和负载均衡的空闲超时在 60 秒左右心跳间隔取它的一半比较稳妥。如果你的服务端自己也会发 ping那客户端只要负责回 pong 就行不必再主动发。注意 ping 帧的载荷可以是空的也可以带应用数据服务端必须原样回在 pong 里。有些实现把 ping 当业务消息处理这是误用。3.2 断线重连指数退避比固定间隔靠谱断线后立刻重连如果服务端还没恢复会形成大量无效连接。指数退避是更稳的做法第一次 1 秒后重连失败则 2 秒、4 秒、8 秒上限 30 秒。private var retryDelay:int 1000; private const MAX_DELAY:int 30000; private function reconnect():void { var timer:Timer new Timer(retryDelay, 1); timer.addEventListener(TimerEvent.TIMER, function(e:TimerEvent):void { openSocket(); }); timer.start(); // 下次延迟翻倍封顶 30 秒 retryDelay Math.min(retryDelay * 2, MAX_DELAY); } // 连接成功后重置延迟 private function onConnected(e:Event):void { retryDelay 1000; sendHandshake(); }这里的关键是连接成功后必须把retryDelay重置回 1 秒否则下次断线会直接从 30 秒开始等。另外重连时要先清理旧的 Socket 对象和定时器不然会出现多个连接同时存在的诡异状态消息重复处理。3.3 二进制消息ByteArray 的读写位置陷阱AS3 的ByteArray有个position指针读写都会移动它。解析帧时如果忘了重置position读出来的数据就是错的。上面parseFrame开头那句buf.position 0就是防这个。发二进制消息时要按帧格式组装// 发送二进制帧客户端需加掩码 private function sendBinary(data:ByteArray):void { var frame:ByteArray new ByteArray(); frame.writeByte(0x82); // FIN1, opcode2 var len:int data.length; if (len 126) { frame.writeByte(0x80 | len); // Mask1 } else if (len 65536) { frame.writeByte(0x80 | 126); frame.writeShort(len); } // 4 字节掩码密钥 var mask:ByteArray new ByteArray(); for (var i:int 0; i 4; i) { mask.writeByte(Math.floor(Math.random() * 256)); } frame.writeBytes(mask); // 载荷异或掩码 data.position 0; for (var j:int 0; j len; j) { frame.writeByte(data[j] ^ mask[j % 4]); } socket.writeBytes(frame); socket.flush(); }参数上0x82是 FIN 加二进制 opcode文本消息则是0x81。掩码位必须置 1否则服务端会按协议错误关闭连接。data.position 0这行不能省如果这个 ByteArray 之前被读过position 停在末尾循环就从越界位置开始发出去的全是空。3.4 用 Wireshark 验证帧格式对不对自研实现出问题时最有效的排查手段是抓包。在本地跑一个 WebSocket 服务用 Wireshark 过滤tcp.port 你的端口看握手请求和响应再看后续帧的 FIN、opcode、mask 位是否符合预期。如果服务端返回400 Bad Request多半是握手头拼错重点检查Sec-WebSocket-Key长度和行尾。如果握手成功但消息乱码重点看掩码异或和长度字段。如果连接几秒后断开看是不是没回 pong。抓包能看到字节级真相比在代码里加日志猜要快得多。4. as3.0 websocket 避坑五条血泪经验4.1 握手响应和首帧粘包首条消息丢失现象连接建立成功但服务端发的第一条欢迎消息客户端收不到从第二条开始正常。原因握手响应和第一帧数据在同一批 TCP 字节里到达代码读完 HTTP 头后把整个缓冲区清空首帧被丢弃。解决读完响应头后计算已消耗的字节数把剩余字节保留在缓冲区直接交给帧解析器处理不要清空。4.2 中文消息乱码英文正常现象服务端发的中文显示为乱码英文和数字正常。原因掩码异或时用了错误的索引或者文本帧没有按 UTF-8 解码直接当单字节字符处理。解决确认异或索引用i % 4文本载荷用payload.readUTFBytes(payload.length)读取不要用readByte逐个转字符。4.3 分片消息只收到第一片现象大消息只收到开头一部分后续内容丢失或解析报错。原因解析器只处理fin1的帧遇到opcode0的续帧没有拼接逻辑。解决维护一个消息缓冲区收到opcode1或2时开始累积收到opcode0时追加直到fin1才交付业务层。4.4 重连后消息重复处理现象断线重连后同一条消息被处理了两次。原因旧 Socket 的事件监听没有移除新旧两个 Socket 同时收到消息。解决重连前调用socket.removeEventListener清理所有监听把 socket 置空再创建新对象。4.5 心跳发了但服务端不回 pong现象客户端按时发 ping但一直收不到 pong误判断线频繁重连。原因服务端实现只处理文本帧把 ping 帧当未知类型忽略或者服务端要求客户端回 pong 而不是主动发 ping。解决先确认服务端的心跳策略如果服务端主动发 ping客户端只需在收到 ping 时回 pong不要自己再发。抓包确认 ping 帧确实到达服务端。5. 进阶用 AS3 做 WebSocket 代理层把老工程接进新后端手上有一份庞大的 AS3 业务代码直接改网络层风险太大更稳的做法是在 AS3 里做一个薄代理层上层业务照旧调用原来的接口代理层负责把调用翻译成 WebSocket 帧收到帧再翻译回业务事件。这样协议细节被隔离在一层里业务代码几乎不用动。代理层的核心是一个请求-响应映射表。每条发出去的消息带一个自增的seq代理层把seq和回调函数存进字典收到响应时按seq找回回调。private var pending:Object {}; // seq - callback private var seq:int 0; public function request(cmd:String, params:Object, callback:Function):void { seq; pending[seq] callback; var msg:Object { seq: seq, cmd: cmd, params: params }; sendText(JSON.stringify(msg)); } private function onMessage(text:String):void { var msg:Object JSON.parse(text); var cb:Function pending[msg.seq]; if (cb ! null) { delete pending[msg.seq]; cb(msg.data); } }这个模式的好处是业务层完全不用关心 WebSocket 的帧、掩码、心跳只面对request和回调。参数上seq用自增整数即可注意在重连后要清空pending字典否则旧请求的回调会永远挂着造成内存泄漏。验证代理层是否可靠我一般做两件事一是模拟服务端延迟响应和乱序响应看回调是否按seq正确匹配二是模拟断线重连确认重连后新请求正常、旧请求被清理。这两步过了代理层基本就能扛住日常使用。最后说个我自己的习惯每次改完帧解析代码先不接业务而是写一个回环测试客户端发什么服务端原样回什么用不同长度的消息1 字节、125 字节、126 字节、70000 字节各跑一遍。长度边界是帧解析最容易错的地方回环测试能在接业务之前就把问题暴露出来。这套方法帮我省了很多事后排查的时间希望帮到你。本文还有配套的精品资源点击获取