go语言系统http3方案

不同层级的HTTP3

• 系统级HTTP/3(QUIC协议)，linux正在研究，若实现，语言级的QUIC实现可转调系统的提升效率。
• 语言级HTTP/3(QUIC协议)，比如go语言实现，在语言级别支持HTTP3/QUIC，用于充当客户端发起HTTP3请求和充当服务端进行HTTP3响应，go语言正在实现该能力。
• 应用级HTTP/3(QUIC协议)，比如go语言的quic-go库，未来gRPC的http3版，在语言未提供支持或者支持不太好或者应用库想完全控制的情况下自行实现。
• 中间件HTTP/3(QUIC协议)，比如Nginx的http_v3_module、caddy的HTTP3支持

 

如果网站使用了代理服务器（如Nginx、caddy）且开启了HTTP3处理客户端请求，那么go项目中不需再使用quic-go库，直接与web服务器交换数据即可。

目前代理服务器与浏览器之间就算使用HTTP3连接，但与go后端的连接还是会采用HTTP1或HTTP2，流程：浏览器 (HTTP/3) → Caddy (HTTP/3终端) → (HTTP/1.1或HTTP/2) → Go应用

这是目前代理服务器有意为之的，因为这种架构代理服务器与go后端通常在同一个内网，普通HTTP足够快了，另外很多后端语言还不支持HTTP3，库也很少。（当然也可以通过配置强制代理服务器与go之间也使用HTTP3）

如果浏览器直接连接go启动的web服务，就需要用quic-go库处理HTTP3请求，但需要自行管理证书和 QUIC 实现。

 

几种网络架构模式

（主要考虑用户端浏览器到服务器之间的传输）

1. 浏览器 → go后端 （go使用quic-go库实现HTTP3）
2. 浏览器 → 代理服务器 → go后端 （代理服务器开启HTTP3，go不必http3）
3. 浏览器 → 微服务gateway → go服务 （gateway开启HTTP3，微服务之间不必基于HTTP3）
4. 浏览器 → 代理服务器 → 微服务gateway → go服务（代理服务器开启HTTP3）

推荐架构: caddy代理服务器 → 微服务gateway → go服务。微服务架构：etcd + gRPC + gin

caddy相对Nginx而言天然支持http3，配置简单，且内置SSL证书且自动续期。