HTTP/2、HTTP/3、WebSocket 与 gRPC 选型

协议选型不是把最新名词排成等级。先确定调用者是谁、通信方向、消息频率、网络环境、浏览器限制和运维设施，再选择最简单的满足方案。

Open Table of contents

从交互需求开始

运行协议决策样例下载：

mvn -Dtest=NetworkServerLabTest#choosesProtocolsFromInteractionNeeds test

样例只是决策起点，不是自动架构器。生产选择还要验证网关、负载均衡、客户端 SDK、可观测性和故障演练能力。

HTTP/2 在一条 TCP 连接上多路复用多个流，使用二进制帧和头部压缩，减少 HTTP 层排队；一个 TCP 丢包仍可能暂时影响同连接多个流。

HTTP/3 把 HTTP 映射到 QUIC。QUIC 基于 UDP，在用户态提供加密连接和独立流，单个流丢包通常不会阻挡其他流的数据交付。它改善弱网与连接迁移场景，但需要端到端基础设施支持 UDP、QUIC 观测和回退。

HTTP 版本是传输能力，不替你设计资源、幂等、错误码、缓存和鉴权。

WebSocket 在 HTTP 握手后建立全双工消息通道，适合客户端和服务端都频繁主动发送的协作、游戏或控制场景。应用需要自己定义消息模式、心跳、重连、顺序和背压。

SSE（Server-Sent Events，服务端发送事件）基于 HTTP 文本流，只支持服务端到浏览器的单向推送。通知、进度和事件订阅若不需要双向低延迟消息，SSE 往往更简单，并能复用现有 HTTP 基础设施。

gRPC 通常使用 Protocol Buffers 定义服务和消息，并基于 HTTP/2 提供一元调用和多种流式调用。它适合强类型内部服务和多语言代码生成，但浏览器接入、网关转换、模式治理和调试工具都要提前验证。

不要把 gRPC 等同于“必然高性能”。小流量系统的主要成本可能在数据库和业务；错误的流控、无限截止时间或巨大消息照样会拖垮服务。

选两个候选方案实现同一个最小业务，测试正常延迟、丢包、网络切换、大消息、慢消费者、重连和灰度兼容。记录客户端、代理和服务器三端证据，最终决策写清适用边界与退出方案。

完成本阶段后，你应该能从一次请求的网络路径定位到 Java 事件循环、协议解析、服务器线程和下游容量，而不是看到超时就先调大连接池。

回到从开发者到架构师查看全路线，再进入 Spring 阶段，把服务器交给应用框架后继续追踪对象创建、请求代理与事务边界。