【Golang | gRPC】HTTP的连接管理——从HTTP/1.0到HTTP/2.0的演进

1. 前言

gRPC

• 客户端流
• 服务端流
• 双向流

HTTP

2. HTTP连接

HTTPTCP

3. HTTP连接管理

3.1 串行连接（短连接）

如果对HTTP连接只进行简单的管理，当HTTP事务串行加载时，TCP的连接时延就会叠加起来，如下图：

3.2 并行连接

通过多条TCP连接发起并发的HTTP请求，克服单条连接的空载时间和带宽限制。但是并行连接会导致服务端打开大量连接从而消耗内存资源，引发性能问题

3.3 持久连接（长连接）

重用TCP连接，以消除连接及关闭时延。HTTP/1.1（包括HTTP/1.0的各种增强版本）允许事务处理结束后保持TCP连接处于打开状态

3.4 管道化连接

无论是串行连接还是持久连接，HTTP报文都遵循一发一收的流程，HTTP/1.1引入的管道化连接允许将多条请求放入队列，依次发送，服务端按照与请求相同的顺序回送HTTP响应（这种机制可能导致队首阻塞问题，即如果服务端的某一个请求处理耗时过久，会导致后面请求对应的响应阻塞，不能发送给客户端）

3.5 HTTP/2.0中的流（stream）

不同HTTP/1.0协议，HTTP/2.0在TCP层（或者TLS层，如果有）和HTTP层之间添加一层二进制分帧层（Binary Framing Layer），将HTTP报文分为更小的Headers帧（对应HTTP/1.0报文的起始行和首部）和DATA帧（对应HTTP/1.0报文主体部分），然后进行二进制编码发送给对端

stream（流message（消息）frame（帧）

streammessageHeaders FrameDATA FrameTypeStream IdentifierframeFlags

如下是一个HTTP/2.0帧格式和gRPC报文格式

HEADERS帧DATA帧

4. HTTP/2.0与gRPC的流模式

gRPC框架中的C/S通信就是使用的HTTP/2.0协议

HTTP/2.0的优点除了降低了通信时延，另一方面使C/S通信不再局限于HTTP/1.0的一发一收模式，同时有效地解决了HTTP/1.1的管道化连接带来的响应报文队首阻塞问题（注：这里的队首阻塞仅是指HTTP层）

客户端可以发送多个message请求，服务端在获取所有的message请求后返回message响应（对应gRPC中的客户端流模式）；客户端发送单个message请求，服务端接收处理后，可以返回多个message响应（对应gRPC中的服务端流模式）；客户端也可以每发送一个message请求，服务端接受处理后就返回一个message响应（对应gRPC中的双向流模式）