2. 协议转换基础：常见网络协议的特点与适用场景
API Gateway 的核心职责之一是协议转换——在异构客户端与后端服务之间建立通信桥梁。不同的网络协议在传输效率、连接模型、数据格式、实时性等方面存在显著差异。理解这些协议的本质特征，是设计中间件链路适配策略的前提。
学习目标：掌握 HTTP/1.1、HTTP/2、gRPC、WebSocket、MQTT 五种协议的核心差异，能够根据业务场景选择正确的协议转换路径。
2.1 协议全景对比
下表从传输模型、数据格式、连接复用、实时性、生态成熟度五个维度，对五种常见协议进行横向对比：
| 协议 | 传输模型 | 数据格式 | 连接复用 | 实时性 | 典型场景 |
|---|---|---|---|---|---|
| HTTP/1.1 | 请求-响应（同步） | 文本（JSON/XML） | 有限（Pipelining 不成熟） | 低 | REST API、浏览器应用 |
| HTTP/2 | 请求-响应（多路复用） | 二进制帧 | 强（Stream 级复用） | 中 | 微服务间通信、SPA 应用 |
| gRPC | RPC（支持流式） | Protobuf（二进制） | 基于 HTTP/2 | 高 | 内部微服务、低延迟系统 |
| WebSocket | 全双工（长连接） | 文本/二进制帧 | 单连接双向 | 极高 | 实时推送、在线协作 |
| MQTT | 发布-订阅（异步） | 二进制（QoS 分级） | 单连接多主题 | 中高 | IoT 设备、弱网环境 |
2.2 各协议深度解析
2.2.1 HTTP/1.1：最广泛的请求-响应协议
HTTP/1.1 自 1997 年标准化以来，一直是 Web 生态的基石。其核心特征包括：
- 文本协议：请求行、头部、正文均以明文传输，便于调试但带宽利用率低。
- 队头阻塞（HOL Blocking）：同一连接上的请求必须按顺序处理，前一个请求的响应延迟会阻塞后续请求。
- 连接管理：支持 Keep-Alive 复用 TCP 连接，但浏览器通常限制单域名并发连接数（6~8 个）。
API Gateway 适配要点：HTTP/1.1 是网关最常接收的入口协议。网关需要解析请求行、头部、Cookie，并支持 chunked 传输编码。对于长轮询场景，需注意连接超时和线程池隔离。
2.2.2 HTTP/2：二进制多路复用
HTTP/2 在 2015 年成为标准，解决了 HTTP/1.1 的队头阻塞问题，并引入了多项性能优化：
- 二进制分帧层：将请求和响应拆分为帧（Frame），通过流（Stream）标识多路复用。
- 头部压缩（HPACK）：使用静态/动态表压缩头部，减少冗余传输。
- 服务器推送（Server Push）：服务器可主动向客户端推送资源，减少往返次数。
HTTP/2 的流式复用机制如下图所示：
2.2.3 gRPC：高性能 RPC 框架
gRPC 由 Google 开发，基于 HTTP/2 和 Protocol Buffers，专为微服务间高效通信设计：
- IDL 驱动：使用 .proto 文件定义服务接口和消息结构，自动生成客户端/服务端代码。
- 四种通信模式：一元 RPC、服务端流式、客户端流式、双向流式。
- 强类型与序列化：Protobuf 二进制序列化比 JSON 快 3~10 倍，体积小 60%~80%。
网关适配挑战：gRPC 使用 HTTP/2 的 Trailers 传递状态码，且默认使用 h2 协议升级。API Gateway 需要支持 gRPC-Web 转换（将浏览器端的 HTTP/1.1 请求转换为 gRPC 调用），或直接暴露 gRPC 端口给内部服务。
2.2.4 WebSocket：全双工实时通信
WebSocket 在 2011 年成为 W3C 标准，通过一次 HTTP 升级握手建立持久连接，实现双向实时通信：
- 握手阶段：客户端发送
Upgrade: websocket请求，服务端返回 101 Switching Protocols。 - 帧格式：数据帧最小仅 2 字节头部，支持文本帧、二进制帧、Ping/Pong 心跳。
- 无同源限制：浏览器端 WebSocket 不受同源策略限制，但网关仍需校验 Origin 头。
WebSocket 在 API Gateway 中的典型适配流程：
2.2.5 MQTT：轻量级物联网协议
MQTT（Message Queuing Telemetry Transport）是 OASIS 标准下的发布-订阅协议，专为受限设备和低带宽网络优化：
- QoS 分级：QoS 0（至多一次）、QoS 1（至少一次）、QoS 2（恰好一次），按可靠性需求选择。
- 最小报文：固定头部仅 2 字节，非常适合 NB-IoT、LoRa 等窄带网络。
- 遗嘱消息（Will Message）：设备异常断开时，Broker 自动发布预设遗嘱，实现设备状态感知。
网关集成模式：API Gateway 通常作为 MQTT Broker 的 HTTP 桥接层，将设备上报的 MQTT 消息转换为 REST 或 gRPC 请求转发给业务服务。同时，网关也可将管理命令从 HTTP 转换为 MQTT 发布给设备。
2.3 协议转换决策矩阵
在 API Gateway 中设计协议转换链路时，可参考以下决策逻辑：
- 客户端类型：浏览器端优先 HTTP/1.1 或 WebSocket；移动端可考虑 HTTP/2；IoT 设备强制 MQTT。
- 实时性要求：秒级延迟用 HTTP/1.1 轮询；毫秒级用 WebSocket 或 gRPC 流式。
- 吞吐量需求：高并发场景优先 HTTP/2 多路复用或 gRPC 二进制协议。
- 网络环境：弱网、高丢包环境选择 MQTT（QoS 1/2）或 gRPC 的流式重试机制。
- 生态兼容：需要与现有 REST 工具链集成时，保留 HTTP/1.1 入口，内部转换为 gRPC。
最佳实践：大多数生产级 API Gateway 采用“多协议入口 + 统一内部协议”架构。例如：对外暴露 HTTP/1.1、WebSocket、MQTT 三种入口，内部统一转换为 gRPC 调用后端服务，降低协议适配复杂度。
2.4 协议转换的中间件链路位置
在后续章节中，我们将深入每个协议的转换实现细节。协议转换在中间件链路中的典型位置如下：
| 中间件阶段 | 协议相关职责 | 典型组件 |
|---|---|---|
| 连接管理 | TCP/TLS 握手、连接池、Keep-Alive 策略 | Netty、Envoy L4 过滤器 |
| 协议解析 | HTTP/1.1 请求行解析、HTTP/2 帧解码、MQTT 报文拆包 | 协议解码器、帧处理器 |
| 协议转换 | 将入口协议转换为内部协议（如 HTTP→gRPC） | 协议适配器、Transcoder |
| 路由转发 | 根据协议类型和路径分发到不同后端集群 | 路由表、负载均衡器 |