Chrome DevTools Websocket机制及SignalR ping发送异常相关问题咨询

1. Chrome DevTools WebSocket消息采集逻辑 #

Chrome DevTools的Network面板中展示的WebSocket帧，采集自浏览器网络栈底层已提交到系统套接字的数据，而非对上层WebSocket类实例的send方法调用监听。

• 调用WebSocket.send()后，如果网络处于正常状态，消息会先进入浏览器内部发送队列，再提交到套接字发往网络，此时DevTools才会展示这条消息。
• 如果发送时出现短暂网络故障，消息会暂存在内部队列中，DevTools不会立刻展示。如果后续连接在消息提交到套接字前就被关闭，这条消息会被直接丢弃，全程不会出现在DevTools的帧列表中。这也符合你遇到的场景：SignalR的自定义ping消息已经入队，但还没来得及提交到网络，连接就因服务端超时被关闭，所以DevTools没有对应记录。

2. 网络故障对WebSocket内部消息队列的影响 #

网络故障会直接影响内部队列的生命周期，分两种场景：

• 短暂可恢复的网络中断（比如代理断连2~3秒）：只要TCP连接未被两端判定为超时失效，所有send调用传入的消息都会按顺序存入内部队列缓存，等网络恢复后会自动按序发送，不会丢失。
• 网络中断超过超时阈值、或TCP连接已被重置/关闭：内部队列中所有未发送的消息会被直接清空，后续调用send()会直接抛出InvalidStateError异常。

你遇到的关闭事件code: 1000; wasClean: true属于服务端主动发起的合法正常关闭，触发时客户端未发送的队列消息也会被全部清空。

3. 访问WebSocket内部队列的可行性 #

浏览器未开放任何公共Web API支持直接访问WebSocket内部发送队列，也没有提供原生能力查询某条消息是否已经被发送到网络接口。
唯一可用于间接判断队列状态的属性是WebSocket.bufferedAmount，它表示当前队列中还未被提交到网络的待发消息总字节数：

• 调用send()后如果bufferedAmount增加了对应消息的字节数，说明消息已经成功入队；
• 当bufferedAmount降为0时，说明队列中所有待发消息都已经被提交到系统套接字。

注意：bufferedAmount为0仅代表消息已经交给操作系统的网络层，不代表服务端已经成功接收，TCP层的丢包、网络延迟仍可能导致消息未送达对端。

内容的提问来源于stack exchange，提问作者Andrew