服务器
HTTP/3 的出现解决了 TCP 拥塞控制算法不受浏览器控制的问题，但这同时也引入了一个新的挑战：UDP 并不适合现有的 BSD socket API。回顾历史，BSD socket API 当初设计时，网络速度非常缓慢，系统调用的时间几乎可以忽略不计，真正耗费时间的是数据包在网络中的传输。然而，随着技术的发展，如今的
服务器网卡速度已经达到了 40G、100G，甚至 400G。TCP 协议可以在内核层面进行分包处理，这意味着应用程序只需通过一次系统调用提交大量待发送的数据，然后由内核逐步拆分成多个小包进行发送。相比之下，UDP 则不具备这种能力，它需要为每一组数据单独发起系统调用。问题在于，BSD socket API 设计得较为重型，每次调用 sendto 系统调用都会消耗相当长的时间。即使 CPU 性能再强大，10G 网卡也难以达到满负荷运行。唯一的解决方案是放弃应用层的流控机制，改用 sendmmsg 系统调用，这样可以批量发送数据包，但代价是失去了对每个包发送时间的精确控制，从而丧失了流控的能力。当然，在普通用户端，尤其是那些宽带速率仅为 100M 的场景下，这个问题并不显著。然而，当这一机制应用于
服务器环境时，UDP socket API 的缺陷便暴露无遗。在高带宽、高性能需求的环境下，UDP 的这种特性限制了其进一步的应用和优化。因此，尽管 HTTP/3 带来了诸多改进，但在实际部署过程中，如何有效应对 UDP 在现代高速网络环境下的不足，依然是一个亟待解决的问题。这不仅考验着开发者的技术水平，也对网络协议的设计提出了更高的要求。
