QUIC作为一种传输层网络协议，旨在解决TCP在现代互联网中的延迟和多数据流支持不足等问题。尽管QUIC已在互联网流量中占据重要地位，但其在Linux内核中的支持进展缓慢。近期，Xin Long提交了首个补丁集，旨在为主流内核提供QUIC支持，标志着这一进程可能加速。

标题：QUIC协议在Linux内核中的实现

主要内容：

QUIC（Quick UDP Internet Connections）是一种传输层网络协议，旨在解决TCP在现代互联网中的一些问题。尽管QUIC已经在互联网流量中占据了重要地位，但其在Linux内核中的支持进展一直较为缓慢。然而，最近Xin Long提交了第一组补丁，旨在为QUIC协议提供主线支持。

QUIC的设计初衷是为了解决TCP在连接建立时的延迟问题、多数据流支持不足以及协议僵化等问题。QUIC基于UDP协议，简化了连接建立过程，避免了TCP的三次握手，从而加快了连接速度。此外，QUIC支持多数据流，单个UDP数据包的丢失不会影响其他数据流。QUIC的传输数据始终是端到端加密的，中间设备无法窥探其内容。

QUIC协议在RFC 9000和RFC 9369中进行了详细规定，并且已经在许多软件中得到支持，尤其是在Web浏览器中。然而，目前的QUIC实现主要位于用户空间，这虽然加快了其开发和分发速度，但也限制了其性能。随着协议的演进，人们开始关注将QUIC引入内核，以提升性能并使其更广泛地应用于各种应用程序。

Xin Long提交的补丁集旨在将QUIC尽可能自然地集成到内核中。新增的IPPROTO_QUIC协议类型可以与socket()系统调用一起使用，类似于TCP的方式。QUIC使用TLS进行身份验证和加密管理，但TLS会话的建立工作被推送到用户空间处理。一旦连接建立，双方需要完成TLS握手后才能开始数据传输。

尽管QUIC的设计目标是快速，但目前的基准测试结果显示，内核中的QUIC实现尚未达到预期性能。与内核中的TLS实现相比，QUIC的吞吐量在某些测试中仅为TLS的三分之一。性能差距的原因包括QUIC缺乏分段卸载支持、传输路径中的额外数据拷贝以及QUIC头部的加密需求。

尽管如此，QUIC在内核中的实现仍然引起了广泛关注。Samba服务器和客户端已经提交了添加QUIC支持的拉取请求，并且有人对在内核中的SMB和NFS文件系统中添加QUIC支持表现出兴趣。此外，curl工具也在开发基于内核的QUIC支持。

然而，QUIC在内核中的完全实现还需要时间。目前提交的补丁集仅为低层支持代码，预计完整的实现还需要更多的补丁。代码审查过程刚刚开始，预计需要较长时间才能完成。因此，QUIC可能最早要到2026年才能进入Linux内核主线。

关键词：
内核 | 网络/协议

评论主要围绕QUIC协议的优缺点、内核实现、性能问题以及未来发展方向展开讨论。以下是主要观点总结：

1. QUIC的性能问题：

   • 评论2指出，内核QUIC的性能表现不佳，与内核TLS和TCP相比，吞吐量显著较低。"A comparison of in-kernel QUIC with in-kernel TLS shows the latter achieving nearly three times the throughput in some tests."
   • 评论6提到，尽管QUIC可能降低游戏延迟，但整体网络速度仍受网站臃肿影响。"But I guess this can make game latency lower."

2. QUIC的优势与灵活性：

   • 评论3强调QUIC的灵活性，认为其能够避免协议僵化，无需依赖Linux维护者的同意。"The whole appeal of QUIC is being immune to ossification, being free to change parameters of the protocol without having to beg Linux maintainers to agree."

3. 内核与用户空间的争议：

   • 评论4批评Linux内核的复杂性，认为每年增加的代码量增加了攻击面，呼吁转向微内核操作系统。"We're adding a million lines of code to the linux kernel every year. That's so much attack surface area."
   • 评论9则对将网络栈移回内核表示困惑，认为过去十年的趋势是将其移至用户空间以提升性能。"I thought the revolution of the past decade or so was in moving network stacks to userspace for better performance."

4. QUIC的未来发展与应用：

   • 评论1认为QUIC的改进是正确方向，未来可能获得硬件支持。"Seems like this is a step in the right direction to resole some of those issues."
   • 评论8希望OpenSSH支持QUIC，以结合Mosh的优势和OpenSSH的功能。"I would love to see OpenSSH support QUIC so that I get some of the benefits of Mosh."

5. 技术细节与API设计：

   • 评论7讨论了QUIC的多流API设计，希望有更明确的连接对象和流管理方式。"I would hope for something more explicit, where you get a connection object and then open streams from it."
   • 评论5询问是否包含不可靠数据报扩展。"Would this (eventually) include the unreliable datagram extension?"

总结：评论者对QUIC的性能、灵活性、内核实现及其未来发展方向持有不同看法，既有对其潜力的认可，也有对其当前表现的批评。