TCP、UDP 与 QUIC：理解协议差异，不靠名称判断快慢

选择节点或阅读客户端说明时，经常遇到 TCP、UDP 和 QUIC。它们不是从低到高排列的性能档次。对使用者更有意义的问题是：应用需要什么能力，客户端如何转发，以及当前路径是否支持这种通信方式。

TCP 关心有序交付的字节流

TCP 为通信双方提供有序的字节流传输，包含确认、重传等机制。应用不必把每次丢失都当作全新的任务重做，但等待缺失数据也可能增加延迟。连接可靠不意味着网络永远不会中断。

浏览网页或下载文件时，软件还会涉及应用层协议、服务器处理和本地写入。看到 TCP 连接成功，只能说明已经完成相应连接步骤，不能直接推断文件传输速度、网站响应时间或账号功能是否正常。

UDP 提供数据报传输，本身不保证到达、排序或去重。上层应用可以自行处理丢包，也可以根据任务性质接受部分数据丢失。是否需要重传，取决于具体业务，而不是把所有数据都按同一方式处理。

语音、实时交互和文件传输对等待时间的容忍不同。但使用 UDP 的程序也可能做复杂的可靠性控制，不能把“UDP 没有内置重传”扩大为“使用 UDP 的应用都不重传”。

QUIC 建立在 UDP 之上，提供流、丢包恢复和安全握手等机制，HTTP/3 使用它承载通信。因此，看到 UDP 并不代表内容是明文，也不代表上层一定没有可靠性。判断时要沿着协议层次逐层看。

QUIC 的设计可以改善某些连接场景，但实际体验仍受路径、实现和服务器影响。不能只因节点名称含 QUIC 就承诺更快，也不应把所有不顺畅都归因于它。应比较同一任务能否完成及其具体失败阶段。

应用发送的流量如何进入客户端，与客户端如何连接节点，是两个维度。一个客户端界面出现 TCP，不一定意味着它完全不能承接其他类型的应用流量；反过来，节点采用某种传输也不保证每个入口都支持 UDP。

核对说明时分成三项：应用请求是否进入代理、客户端是否支持转发该类请求、节点和路径是否允许对应通信。任何一项不满足，都可能造成“网页正常、某项实时业务失败”的现象。

先写下真正需要的任务，例如加入语音、加载网页或下载资料。再使用客户端连接记录确认该任务的实际协议和路径；没有日志证据时，把协议类型记为未确认，不要凭应用名称猜测。

选择相同设备、相同时间窗口和同一任务进行对照，每次只改一个条件。网页测试通过后，还要单独检查目标业务；任务表现更好也只适用于本次条件，不能扩展为某协议在所有网络中都更优。

如果某层没有所需能力，应按软件或服务说明选择受支持的方式。组织管理的网络可能有明确的业务策略，遇到限制应交由管理员确认，不通过关闭防护或改变身份信息来试探。

保存任务、网络、客户端版本、所选路径和失败阶段，就能形成可复查的记录。协议知识的作用是减少误判，而不是迫使每位使用者修改底层参数。已有配置满足任务时，没有必要为了名称更新而调整。