Websocket、HTTP/2、HTTP/3原理解析

Websocket

真正的全双工长连接

HTTP/1.1的长连接本质上还是请求-响应 模式，只是复用了TCP连接，无法满足实时、双向通信的需求，因此，Websocket协议被设计了出来

原理

阶段一：握手

Websocket连接时由一个HTTP请求开始的，这个请求是特殊的升级请求

客户端发起握手请求

客户端发送一个标准的HTTP请求，但包含了一些特殊字段
复制代码
```
GET /index.html HTTP/1.1
Host: www.example.com
Upgrade: websocket  # 请求升级协议
Connection: Upgrade # 请求切换连接
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==  # 客户端随机生成的密钥
Sec-WebSocket-Version: 13 # WebSocket协议版本（通常是13）
Origin: http://example.com # 用于安全校验
```
- Upgrade: websocket和Connection: Upgrade是为了告诉服务器，想要将连接升级为Websocket协议
- Sec-WebSocket-Key 是一个由客户端随机生成的Base64编码的字符串，用于确保服务器真正支持WebSocket，防止意外升级
服务器返回握手响应

如果服务器同意升级，就会返回一个HTTP 101状态码响应
复制代码
```
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
```
- HTTP 101：代表同意升级，协议已切换
- Sec-WebSocket-Accept：是服务器对客户端密钥的验证，确保握手成功且没有中间人拦截篡改

至此，HTTP使命完成 ，建立在原有TCP连接上的通信协议从HTTP协议切换到Websocket，之后所有的数据传输，都不遵循HTTP报文格式和规则。一旦握手成功，TCP连接就会被用于Websocket通信，此后，客户端和服务器可以独立地、实时地 向对方发送数据，不再受HTTP请求-响应模式的限制。这种通信是全双工的，即双方可以同时发送和接收数据

阶段二：数据传输

WebSocket定义了自己的数据帧格式，允许发送文本消息（UTF-8编码）和二进制消息，解决了HTTP协议在传输二进制数据上的不足。数据帧格式：

阶段三：连接生命周期与心跳

**保持连接：**一旦建立，Websocetk连接会一直保持打开状态，直到一方主动关闭，避免HTTP的重复握手挥手开销
**心跳机制：**为保持连接活跃并检测对端是否存活，Websocket定义了Ping/Pong帧。服务器或客户端可以随时发送一个Ping帧，对方接收到后必须回复一个Ping帧，这在TCP层的Keep-Alive之上，提供了应用层的心跳机制
关闭连接： 当一方向终止连接，会发送一个关闭帧，另一方接收到之后，如果之前没有发送过关闭帧，也应该回复一个关闭帧，之后，底层的TCP连接才会被安全关闭

与HTTP长连接的区别

HTTP长连接仍是请求-响应模型，只是复用TCP
WebSocket是独立于HTTP的协议，建立在TCP之上，提供全双工、消息流式的通信。它仅仅是借助HTTP的握手机制来完成协议的升级

HTTP/2

单TCP连接的多路复用

为应对HTTP/1.1的对头阻塞问题以及性能优化，HTTP/2针对其TCP连接增加了多路复用的功能，实现了在一个TCP连接上进行并行传输的功能

特性及原理

二进制分帧
- HTTP/2不再使用纯文本传输，而是将所有请求和响应数据分割成更小的、独立的二进制帧。这些帧有类型和标识符。
- 这些帧可以在同一个TCP连接 上进行乱序发送和接收，然后在另一端根据帧标识符重新组装成完整的HTTP消息。
多路复用
- HTTP/2允许在单个TCP连接上同时处理多个请求和响应，每个请求和响应都被分解成多个帧，这些帧可以交错发送不会互相阻塞
- **解决对头阻塞：**即使一个请求的数据包丢失或处理缓慢，也不影响其他请求的数据传输。因为他们都是一个独立的流，TCP层看到的只是一个连接的字节流，而HTTP/2层则能将这些字节流根据流ID重新映射到不同的请求和响应，解决对头阻塞问题
请求优先级
- 客户端可以为不同的请求设置优先级，服务器会根据优先级分配资源和发送帧
服务器推送
- 服务器可以在客户端明确请求之前，主动向客户端发送可能需要的资源，进一步提高加载速度
头部压缩
- HTTP/2通过HPACK算法对HTTP头部压缩，避免重复发送大量冗余的头部信息，减少请求和响应开销

优势与应用

大幅提升性能： 通过多路复用、头部压缩、服务器推送等特性，HTTP/2显著提升了网页加载速度和性能。
更高效的资源利用： 单一TCP连接减少了连接建立和维护的开销。
广泛采用： 几乎所有现代浏览器和主要网站都支持HTTP/2，并在逐渐普及。

局限性

尽管HTTP/2解决了应用层的队头阻塞，但它仍然基于TCP。TCP协议本身在传输层仍然存在队头阻塞问题。如果某个TCP数据包在传输过程中丢失，TCP协议会等待该丢失的数据包重传并到达，才能向上层交付后续的所有数据包，即使这些数据包属于不同的HTTP/2流。这意味着，如果底层TCP连接出现丢包，即使HTTP/2设计了多路复用，所有流的传输仍然会被阻塞。

HTTP/3

基于QUIC协议的下一代长连接

HTTP/2虽然解决了应用层的对头阻塞问题，但TCP层面中的对头阻塞问题仍然存在，HTTP/3则彻底解决了TCP层面的队头阻塞问题，并进一步优化连接建立和传输效率，HTTP/3最大的变化就是放弃TCP，转而基于UDP协议之上的QUIC协议

特性与原理

基于UDP： QUIC运行在UDP协议之上，UDP是无连接、不可靠的协议，但QUIC在其之上实现了可靠传输、拥塞控制、流量控制等TCP的特性。
多路复用：
- QUIC在传输层实现了多路复用。每个HTTP/3请求都被封装在独立的QUIC流中，这些流在QUIC层是相互独立的。
- 彻底解决队头阻塞： 即使某个QUIC流中的数据包丢失，只会影响该流的传输，而不会阻塞其他流的数据传输。这是与HTTP/2最大的区别，HTTP/2的队头阻塞仍然存在于TCP层，而HTTP/3通过QUIC在传输层就解决了这个问题。
更快的连接建立：
- QUIC将TLS握手集成到其本身的握手过程中。
- 首次连接： 通常只需要1个往返时间（1-RTT）即可完成加密和传输层的握手。
- 恢复连接： 如果客户端曾经连接过该服务器，它可以在连接恢复时直接发送数据，实现0-RTT握手，进一步减少延迟。
连接迁移（Connection Migration）：
- QUIC连接由一个连接ID标识，而不是IP地址和端口号的四元组。这意味着当客户端的IP地址或端口号发生变化时（例如，从Wi-Fi切换到蜂窝网络），QUIC连接可以继续保持活跃，而无需重新建立连接。这对于移动设备用户体验至关重要。
前向纠错：
- QUIC引入了FEC机制，通过发送冗余数据包，可以在一定程度上减少丢包重传的次数，进一步降低延迟。

优势

极致的低延迟： 彻底解决传输层队头阻塞，结合0-RTT握手和连接迁移，在网络环境不佳或移动场景下表现尤为突出。
更强的网络适应性： 连接迁移使得用户在网络切换时无需重新建立连接，体验更流畅。
安全性： QUIC在协议设计之初就强制加密，提供了更强的安全性。