握手之后双方都可发消息
RFC 6455的基础握手使用HTTP/1.1的Upgrade请求和服务器的101响应，之后进入WebSocket消息交换，不必为每条服务器推送再发起一个普通HTTP查询。双方仍需同意目标端点、可选子协议及扩展等条件。
这种握手不是所有版本的唯一形式。HTTP/2通过扩展CONNECT在一个流上建立WebSocket，省去HTTP/1.1的Connection、Upgrade和相应Key/Accept处理；HTTP/3也有对应映射。因此，应用持续双向通信的能力与具体建连报文需要分开理解。
消息与帧不是同一个边界
应用消息可以是文本或二进制，文本按UTF-8解释，二进制的实际含义由应用协议决定。一条消息可由一帧或多个有序片段组成；中间组件在允许条件下还能拆分或合并帧，所以应用不能把每次网络读取都当成完整消息。
Ping、Pong和Close属于控制帧，可以按规则插入分片消息之间，避免必须等一个大消息结束才处理控制信号。基础控制帧不能再分片；消息片段和其他消息的片段是否能交错，又受扩展协商限制，不等于内建了任意多路通道。
参考：[1]
掩码不是加密或账号认证
基础协议要求客户端用每帧新选的32位掩码处理发送内容，掩码本身随帧传输。这是为限制应用操纵线上字节对中间设备产生的影响，并不把消息变成旁观者无法解读的密文；保密连接通常还需要相应TLS保护。
浏览器的Origin信息帮助服务器判断是否接受某来源脚本，但也不代替账号登录与操作权限。连接建立、消息成功传输和服务端真正执行了某次业务动作，仍是不同状态；断线重连、应用确认和去重策略由具体应用继续规定。
参考：[1]