TCP 提供有序可靠的字节流，UDP 提供不保证交付的独立数据报，QUIC 则在 UDP 上实现安全连接、可靠流和连接管理等能力。三者不能简单按“快慢”排序；适合什么应用以及是否可用，取决于网络、协议实现和实际工作负载。
三者的职责
| 技术 | 提供的基本能力 | 常见例子 |
|---|---|---|
| TCP | 有序可靠字节流、拥塞控制 | HTTP/1.1、HTTP/2 的常见连接 |
| UDP | 保留数据报边界、较少传输保证 | DNS 的常见查询、部分实时媒体 |
| QUIC | 在 UDP 上提供安全传输及独立流 | HTTP/3、Hysteria 2 的底层 |
UDP 本身不重传丢失数据，但应用可以在它上面实现可靠性。QUIC 就是这样的完整传输协议，所以“UDP 不可靠”不能推出“QUIC 不能可靠下载文件”。
丢包与队头阻塞
TCP 的同一字节流必须按序交付，前面的数据缺失会让后续数据等待。多个逻辑请求共用一个 TCP 连接时，丢包可能影响多个请求。QUIC 的独立流机制可以减少不同流之间的这种交付等待，但仍受共同网络拥塞及实现资源限制。
这不意味着 QUIC 在所有情况下更快。较低丢包的网络、服务器负载、握手复用和应用行为都可能改变结果，不能仅凭协议名预测下载速度。
代理中的 TCP 和 UDP
客户端接管应用流量后，还要通过所用代理协议及服务器转发。应用使用 UDP、代理连接使用何种底层传输，是不同层次的问题。例如，某协议可能把 UDP 请求封装到另一种连接里，表现需要具体分析。
系统代理对 UDP 应用的覆盖通常与 TUN 不同。检查语音或游戏问题时，先确认应用流量是否进入客户端，再检查协议与服务端支持。
如何做对照
固定设备、目标、网络及时间窗口，分别记录是否能连接、首个响应耗时、持续吞吐量和异常。针对网页、视频及实时语音分别测试；大文件下载成绩不能替代实时延迟。
如果 UDP 被网络策略阻断，QUIC 可能无法工作，某些应用可能回退到 TCP，也有应用不会回退。查看应用日志和实际连接，不能把网页打开推断为 HTTP/3 成功。
选择建议
先采用设备、服务器和网络共同支持的方案。出现丢包或高延迟时，再比较适合的协议及配置。不要通过无依据调大参数或关闭安全校验来追求测速成绩。