从HTTP/1.1到HTTP/3，我们经历了从阻塞到并发的转变。但HTTP/1.1真的只是“老古董”吗？
还记得你第一次用curl抓取网页时，看到的是HTTP/1.1的响应吗？那时候你可能以为这就是最终形态。如今回头看看，HTTP/1.1的持久连接（keep-alive）和管线化（pipelining）虽然解决了部分问题，但头阻塞（head-of-line blocking）和队头阻塞（queueing）却成为性能瓶颈。
HTTP/1.1的管线化功能被引入，本意是让客户端能在一次TCP连接中发送多个请求，但实际中由于请求头必须按顺序到达服务器，任何一个请求的头阻塞都会影响后续请求。这就像是你和朋友同时问十个问题，但因为对方只回答第一个，你只能一个一个等。这种设计在HTTP/2中被多路复用取代，但HTTP/2仍然基于TCP，所以队头阻塞依然存在。
直到HTTP/3，也就是QUIC协议的落地，我们才真正摆脱了TCP的限制。QUIC是基于UDP的，它允许每个请求独立处理，不再受队头阻塞的困扰。这让HTTP/3在低延迟和高并发方面表现得异常出色，尤其是在移动端和高延迟网络中。
大家可能会问，QUIC真的能替代TCP吗？答案是：不能完全替代，但它是一种更现代的传输层协议，在某些场景下能显著提升性能。QUIC的0-RTT握手机制、内置拥塞控制和快速重传等特性，让它在实时音视频传输、游戏和IoT等领域大放异彩。
在Wireshark中，你可以看到HTTP/3的数据包不再像HTTP/1.1那样在TCP层排队，而是以独立流的形式直接在UDP层传输。这种流式传输让网络更加灵活，也更接近我们的实际需求。
但是，HTTP/3的普及还是需要时间。它依赖于TLS 1.3，而TLS 1.3的加密握手虽然更快了，但兼容性和部署成本仍然是问题。而且，QUIC的实现复杂度比TCP高得多，这对服务器端和客户端的开发和维护提出了更高的要求。
如果你是前端开发者，那你可能已经用上了HTTP/2的服务器推送（server push）和流式响应（streaming）。但HTTP/3的多路复用和连接迁移（connection migration）让你能更进一步。
QUIC的连接迁移机制尤其值得关注。它允许在网络切换时，无缝地将数据传输迁移到新的网络连接上，而不用重新建立连接。这在移动设备和Wi-Fi切换的场景中尤为重要。
我们不妨思考一下：在未来的网络环境中，你还会继续使用TCP吗？还是会拥抱QUIC**这样的新协议？毕竟，技术是为了解决问题，而不是为了延续旧习惯。
关键字：HTTP/1.1, HTTP/3, QUIC, TCP, 低延迟, 队头阻塞, 多路复用, 网络编程, 性能优化, 传输协议