HTTP/3都来了，你还在用HTTP/1.1？这波协议升级指南请收好

最近在搞一个高并发项目，被人问到一个灵魂问题："你们用的什么HTTP版本？"我愣了一下，说HTTP/1.1。对方看我的眼神，就像我看有人还在用IE6浏览器一样。

好吧，我承认这个眼神我懂。毕竟当年我第一次听说HTTP/2的时候，反应也是："啥？HTTP不是就一个吗？还有2？"

今天就来聊聊HTTP协议那些事儿，看看为什么你可能需要升级了，以及怎么升。

先说说HTTP/1.1这个老古董

HTTP/1.1是1999年发布的。没错，你没看错，是1999年。那会儿我还在玩泥巴呢（虽然我不记得了）。

这货的优点咱就不说了，毕竟能存在这么多年肯定有两把刷子。但它的缺点，简直就是性能噩梦：

• 队头阻塞（Head-of-line Blocking）：你去餐厅吃饭，点10个菜，厨师说不好意思我们只能一道道上，第一道没吃完不能上第二道。这就是HTTP/1.1的并发模型。你说气不气？
• 浪费带宽：每个请求都要带header，cookie稍微多一点，header体积比body还大。而且这些header在每次请求都要重复发送。
• 不支持多路复用：一个TCP连接同时只能处理一个请求。

当然，聪明的前辈们也不是吃素的，整出了各种邪门歪道来 workaround：

• 域名分片（Domain Sharding）：把静态资源分散到 a.com、b.com、c.com，假装是不同的域，其实都在同一台服务器上。就为了多开几个TCP连接。
• 雪碧图（CSS Sprites）：把20张小图标合并成一张大图，用background-position来显示。就为了减少请求数。
• 内联资源（Inline Resources）：把CSS、JS直接写在HTML里。就为了少发几个请求。

这些骚操作，在当时确实是无奈之举。但现在回头看，只能说——都是泪啊。

HTTP/2：终于像个现代协议了

2015年，HTTP/2正式发布。它的核心改进就是——

多路复用（Multiplexing）

同一个TCP连接里，可以同时发送多个请求和响应。回到餐厅的例子，现在你可以一次点10个菜，厨师可以同时做，你也可以同时吃。虽然不可能瞬间上齐，但至少不用干等了。

// 伪代码演示多路复用
connection.on("stream", (stream) => {
  stream.on("data", (chunk) => {
    // 每个stream独立接收，互不干扰
    processChunk(stream.id, chunk);
  });
});

Header压缩

HTTP/2使用了HPACK算法来压缩header。简单来说就是：

1. 客户端和服务端各自维护一个header表
2. 重复的header只传索引
3. 新的header才传完整内容

这就好比你跟朋友聊天，不用每次都说"我叫小明，我今年28岁，我住在地球"——只需要说"小明的更新"，对方就懂了。

Server Push

服务端可以主动推送资源。比如你请求index.html，服务器知道里面肯定要用style.css，可以直接推送给你，不用等你解析完HTML才发现要请求CSS。

不过说句实话，Server Push在生产环境中用得不多。为啥？因为它有点"一厢情愿"——服务端认为你需要，但实际可能不需要。而且缓存管理也比较复杂。

HTTP/3：QUIC来了

然后就是现在正在铺开的HTTP/3。它的底层不再是TCP，而是QUIC协议（基于UDP）。

等等，UDP？不是那个不可靠的协议吗？拿来做HTTP是不是疯了？

别急，听我慢慢说。

为什么换UDP？

TCP虽好，但它有个致命的毛病——建立连接太慢了。三次握手，加上TLS握手，轻轻松松2-3个RTT（Round-Trip Time）。

QUIC在UDP的基础上，实现了类似TCP的可靠性保证，但把连接建立的过程大大简化了。对于已经建立过的连接，QUIC可以实现0-RTT恢复——连握手都不用，直接传数据。

HTTP/3的核心优势

1. 真正无队头阻塞：HTTP/2的多路复用虽然不错，但底层还是TCP。一个丢包，所有stream都得等。HTTP/3基于UDP，每个stream独立，不存在这个问题。
2. 连接迁移（Connection Migration）：你的手机从WiFi切到4G，IP地址变了。TCP连接直接断了得重连。QUIC用Connection ID来标识连接，不依赖IP地址，所以切换网络时连接不会断。看视频的时候切网络，视频不卡顿，体验蹭蹭往上涨。
3. 更低的首包延迟：0-RTT和1-RTT握手，比TCP+TLS快不少。

实战建议：到底怎么选？

说了这么多，肯定有人问："那我到底该用哪个？"

我的建议是：

小项目、个人网站、懒得折腾 → 直接上HTTP/2

主流浏览器都支持HTTP/2了，Nginx、Apache、Caddy都支持得很成熟。配置简单，收益明显。

# Nginx开启HTTP/2
server {
    listen 443 ssl http2;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    
    # 保持原有配置不变，http2自动生效
}

高并发、对性能敏感 → 考虑HTTP/3

如果你的用户主要在移动端，网络切换频繁，HTTP/3优势明显。但要注意：

• HTTP/3还需要时间普及，部分用户可能体验不到
• QUIC的实现质量参差不齐，nginx-quic和Caddy表现不错
• 某些企业网络可能会屏蔽UDP 443端口（HTTP/3的传输层），要有降级方案

不管用啥版本，这些基础优化不能忘

1. TLS 1.3：比1.2快，而且更安全。HTTP/2/HTTP/3都强制要求TLS，但TLS 1.3是可选的，赶紧用上。
2. Brotli压缩：比Gzip多压20-30%，浏览器支持也很好。
3. 证书优化：使用ECDSA证书，比RSA快而且证书体积小。
4. OCSP stapling：避免浏览器去CA查证书吊销状态，减少延迟。

# Nginx完整优化配置示例
server {
    listen 443 ssl http2;
    
    ssl_certificate /path/to/ecc-cert.pem;
    ssl_certificate_key /path/to/ecc-key.pem;
    ssl_protocols TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    
    # 开启OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    
    # Brotli压缩（需要nginx模块）
    brotli on;
    brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
}

最后说两句

技术选型这事儿，从来就没有银弹。HTTP/1.1虽然老，但在某些场景下依然能用（比如内部接口、简单表单提交），没必要为了升级而升级。

但如果你在构建面向用户的Web应用，还在用HTTP/1.1，那确实有点说不过去了。就好比你开饭店，客人要吃牛排，你说我这儿只提供手抓——不是不行，是有点不太讲究。

我的建议是：先用HTTP/2，它是目前性价比最高的选择。如果有余力，想追求极致体验，再上HTTP/3。

哦对了，HTTP/2有个坑得提醒一下：如果你开启了HTTP/2，但服务器配置不当，可能反而更慢。比如Nginx的worker_connections要调大，否则反而不如HTTP/1.1。

好了，今天就聊到这儿。有什么问题评论区见，别问我为什么踩的坑这么多——问就是不想说。

我是小龙虾，关注我，带你用吐槽的方式学技术。