公司
HTTP/3 实际上是基于 QUIC 协议的 HTTP2，我敢肯定这个协议不会广泛流行。因为它更像是大
公司为了自身需求而设计的产品，只适合那些拥有雄厚资源和技术实力的大企业。先前已经有不少人详细阐述了 QUIC 协议的优点，这里就不再赘述了。QUIC 协议确实有很多特性，其中最受关注的是它能够在 UDP 上重新构建流协议，从而绕过各种防火墙的封锁。然而，这个协议过于庞大和复杂。首先，抛开 HTTP 部分不谈，QUIC 协议本身就包含了三大部分内容。这种重型协议在业界推广起来非常缓慢。举个例子，尽管 HTTP2 已经推出多年，但它至今仍未被
Python 和
Java 的标准库所接纳。
C++ 的标准库更是没有考虑将其纳入其中，甚至连 Boost 库也没有计划整合 HTTP2。如果连 HTTP2 都未能获得普遍支持，那么 QUIC 协议的推广难度可想而知。其次，实现 QUIC 协议必须依赖于 TLS 协议，这可不是一般人能够轻松搞定的事情。虽然可以使用 openssl 或 libressl 这样的开源库来实现，但要真正将它们应用于 QUIC 协议却并非易事。直到最近，openssl 才解决了相关问题。即便你对 openssl 非常熟悉，在嵌入式环境中运行 TLS 仍然是一个巨大的挑战。TLS 协议过于庞大，只有像
Google、
微软这样的大
公司才有足够的资源来使用和维护它们。我们不禁要问，真的有必要在 QUIC 上面跑 TLS 吗？简单的对称流加密难道不行吗？再者，多流协议其实主要是 HTTP2 的事情，并没有必要在 QUIC 中重复定义。在协议中再次定义这些内容，岂不是等于重新发明一次 HTTP2？还要区分 stream 的流控和 connection 的流控，实在是太过复杂。因此，目前只有浏览器和 Nginx 实现了这个协议，并且主要由各大
公司部署，其他开发者对此兴趣不大。设想一下，如果我们用这个协议来做 P2P 或者游戏协议，是否需要同时使用 TLS 和多流功能？实际上，我们根本不需要这样一个臃肿的协议。一个运行在 UDP 上的简单流协议就已经足够了。我建议将 KCP 标准化并提交为 RFC 标准，命名为 SLOW 协议，相信它一定能比 QUIC 更加实用和高效。总结QUIC 协议虽然具有很多优点，但其复杂性和庞大的架构使其难以在广大开发者和中小企业中普及。相比之下，一个轻量级、易于实现和维护的协议更能满足大多数人的需求。与其追求功能全面但却难以驾驭的重型协议，不如选择一个简单实用的方案，这样才能更好地推动技术的发展和应用。我们应该更加关注实际需求，而不是盲目追求新技术带来的表面优势。只有这样，才能真正实现技术的普及和广泛应用。
