WebSocket协议让浏览器与服务器之间建立真正的双向通信，而HTTP协议只能单向“发报”。这背后是怎样的技术革命？
HTTP协议是我们每天都在使用的基础通信协议，但它的设计初衷决定了它只能做一件事：请求-响应。你发一个请求，服务器回一个响应，然后连接就断开了。这种模式在早期的互联网中是合理的，但随着实时通信需求的增长，HTTP的局限性逐渐显现。
那么，WebSocket是怎么做到突破HTTP的限制的呢？它并非从零开始设计，而是基于HTTP协议，但又拥有全新的通信机制。这种“继承者”身份让它在兼容性与性能之间找到了微妙的平衡。
在握手阶段，WebSocket使用了一种特殊的HTTP请求，称为Upgrade请求。浏览器会发送一个带有Upgrade: websocket头的HTTP请求，服务器如果支持WebSocket，就会返回一个101 Switching Protocols状态码，并开始使用WebSocket的自定义协议进行通信。这个阶段就像一场“变身秀”，HTTP协议在这一刻悄然退出历史舞台，取而代之的是WebSocket的全双工通信能力。
一旦握手成功，WebSocket连接就变成了一个持久的双向通道。数据不再是通过HTTP的GET或POST请求来传输，而是通过帧（Frame）进行交换。每个帧都带有标志位，用于标识数据类型（比如文本、二进制、关闭连接等），并且可以分割成多个部分传输，这种机制让数据在传输过程中更加灵活和高效。
如果你仔细观察Wireshark抓包，会发现WebSocket连接的帧结构非常有趣。例如，一个文本帧的结构包括：FIN（标志是否是最后一个帧）、RSV1-3（保留位）、Opcode（操作码，如文本、二进制、Ping、Pong等）、Mask（掩码字段）以及Payload Data（实际数据）。这些字段虽然看起来简单，却构成了WebSocket协议的核心。
与HTTP协议相比，WebSocket的性能优势在于它避免了重复的握手流程。在HTTP中，每次通信都需要重新建立连接，而WebSocket在握手后保持连接状态，减少了延迟。这种设计对于实时应用（如在线聊天、游戏、IoT设备通信）至关重要。
不过，WebSocket并不是万能的。它仍然存在一些局限性，比如不支持传统的HTTP缓存机制，也不具备内置的加密能力。这些限制促使了TLS协议与WebSocket的结合使用，从而在安全性和性能之间找到了一个折中的解决方案。
在实际开发中，WebSocket常被用于构建实时应用，而gRPC则因其基于HTTP/2的特性，成为高性能服务通信的首选。两者各有千秋，但都试图解决HTTP协议的不足。
你是否曾思考过：如果HTTP协议支持持久连接，我们是否还需要WebSocket？
关键字：WebSocket, HTTP协议, 双向通信, 帧结构, TLS, 实时应用, gRPC, 协议升级, 网络性能, 网络编程