TCP 与 UDP 的区别及其对连接体验的影响
TCP 通过握手、确认与重传保证数据可靠有序,代价是更高的延迟与开销;UDP 不做这些保证,换来低开销与低时延。多数代理协议基于 TCP,而 Hysteria 2、TUIC 等基于 UDP 的协议自行实现拥塞控制,在高丢包链路上往往吞吐更高。游戏与语音通话依赖 UDP 转发,需要客户端与服务端同时支持;QUIC 则证明了在 UDP 之上同样可以构建可靠传输。
核心要点
- TCP 面向连接、可靠有序并内置拥塞控制,UDP 无握手、无重传、无顺序保证,协议开销更低。
- 多数经典代理协议基于 TCP,高丢包链路上拥塞控制会压低吞吐;Hysteria 2、TUIC 等基于 UDP 的协议自行实现拥塞控制,往往表现更稳。
- 在线游戏与语音视频通话大量使用 UDP,只有代理客户端开启 UDP 转发且协议与服务端都支持时,这类应用才能正常走代理。
- QUIC 建立在 UDP 之上却提供可靠有序传输,说明传输层协议的选择只是设计起点而非能力上限。
本文目录
打开任意一个网络代理客户端的设置页,几乎都能看到”UDP 转发”这样的开关;再看协议列表,Shadowsocks 和 Trojan 默认运行在 TCP 上,Hysteria 2 却建立在 UDP 之上。TCP 与 UDP 是传输层的两种基础协议,网页加载、视频播放、在线游戏、代理隧道等几乎所有网络应用都要在两者之间做出选择。理解 TCP 与 UDP 的差异,是理解各类代理协议性能表现的前提。
两种协议各自如何工作
TCP(传输控制协议)是面向连接的协议。通信双方在传输数据前需要完成三次握手建立连接;传输过程中,接收方对收到的每段数据发送确认,发送方对超时未确认的数据自动重传;每段数据带有序号,接收端按序号重组,保证应用层读到的字节流与发送顺序完全一致。TCP 还内置拥塞控制:当网络出现丢包时,发送端主动降低发送速率,避免进一步加剧拥塞。
UDP(用户数据报协议)几乎不做任何承诺。UDP 没有握手过程,应用程序把数据打包成数据报后直接发出;没有确认与重传机制,数据报丢了就是丢了;没有顺序保证,后发的数据报可能先到;也没有拥塞控制,发送速率完全由应用自行决定。UDP 报文头部只有 8 字节,协议开销远小于 TCP。
核心差异逐项拆解
- 可靠性:TCP 保证数据送达,UDP 不保证。文件传输、网页加载这类”一个字节都不能错”的场景离不开可靠性;实时语音这类”晚到不如不到”的场景,重传反而有害。
- 有序性:TCP 按序交付,乱序到达的数据必须等前面的数据补齐后才交给应用,这会造成队头阻塞;UDP 的每个数据报独立处理,互不等待。
- 握手成本:TCP 建立连接至少需要一个往返时间(RTT),叠加 TLS 握手后成本更高;UDP 无需握手,第一个数据报即可携带数据。
- 拥塞控制:TCP 把丢包视为拥塞信号并主动降速。在真实丢包率较高的跨境链路上,这种判断往往过度保守,导致实际速度远低于链路能力。丢包与吞吐的关系可参考延迟、抖动、丢包与带宽的含义。
对代理连接体验的影响
Shadowsocks(TCP 模式)、Trojan、VMess、VLESS 这些经典代理协议的隧道建立在 TCP(或 TCP 之上的 TLS、WebSocket)上,因此继承了 TCP 的全部特性:连接可靠,但在高丢包链路上,拥塞控制会明显压低吞吐。如果代理隧道内部再承载一层 TCP 流量(即 TCP over TCP),两层重传与两套拥塞控制相互干扰,性能损失会更明显。
Hysteria 2、TUIC 等较新的协议选择建立在 UDP 之上,在应用层自行实现可靠传输和更激进的拥塞控制。这类协议不受操作系统 TCP 栈保守策略的约束,在丢包率较高的链路上往往能维持明显更高的吞吐。这也是不少用户发现同一条物理线路上 Hysteria 2 节点比 Shadowsocks 节点快的原因之一。四种主流协议的完整差异见 Shadowsocks、Trojan、VLESS 和 Hysteria 2 对比。
游戏、语音与 UDP 转发开关
网页浏览基本只依赖 TCP,但在线游戏、语音通话和视频会议大量使用 UDP:这些实时应用宁可丢弃个别数据包,也不能接受重传带来的延迟波动。如果代理客户端只转发 TCP 流量,游戏的对战数据、通话的音视频流就无法进入代理隧道,表现为游戏连不上服务器、通话无法建立或单向无声。
因此主流网络代理客户端普遍提供”UDP 转发”(UDP relay)开关。开启后,客户端会把本机的 UDP 流量一并封装进代理隧道。UDP 转发生效有两个前提:所用代理协议本身支持 UDP 转发(例如 Shadowsocks 的 UDP relay 功能、Hysteria 2 原生支持),并且服务端也开启了对应能力。任何一个环节缺失,依赖 UDP 的应用都会失败。
QUIC:跑在 UDP 上的可靠传输
QUIC 是一个常被误解的例子:QUIC 建立在 UDP 之上,却提供与 TCP 类似的可靠、有序传输,并整合了 TLS 1.3 加密。设计者选择 UDP 作为底座,是为了在用户态实现自己的重传与拥塞控制逻辑,摆脱操作系统内核 TCP 实现的更新限制;同时 QUIC 通过多流复用避免了 TCP 的队头阻塞,一条流的丢包不会阻塞其他流。HTTP/3 运行在 QUIC 之上,Hysteria 2 同样以 QUIC 为基础。可见”基于 UDP”并不等于”不可靠”,关键在于应用层如何设计。
限制与注意事项
- 部分网络对 UDP 流量实施限速或屏蔽,在 QoS 策略严格的运营商环境下,基于 UDP 的协议高峰期可能反而不稳定,需要实测验证。
- 防火墙和 NAT 设备为 UDP 会话保留的超时时间通常比 TCP 短,长时间空闲的 UDP 映射更容易被回收;有状态设备回收连接同样是 WebSocket 长连接中断的主要成因之一。
- 判断某条线路更适合 TCP 系还是 UDP 系协议,可靠的做法是按照可重复的节点测试流程在不同时段分别实测两类协议的节点,而不是依赖单次测速。
TCP 与 UDP 没有绝对优劣:TCP 以延迟换可靠,UDP 以放弃保证换取低开销和灵活性。代理协议的设计者在两者之上各自权衡,理解了这一层,“为什么这个节点快、那个协议稳”之类的日常疑问大多能找到解释。
常见问题
为什么开了代理之后游戏连不上服务器?
在线游戏的对战数据多走 UDP。如果代理客户端未开启 UDP 转发,或所用协议、服务端不支持 UDP 转发,游戏流量就无法进入代理隧道,表现为连不上服务器或延迟异常。可在客户端设置中开启 UDP 转发,并换用明确支持 UDP 的节点测试。
基于 UDP 的代理协议一定比基于 TCP 的快吗?
不一定。Hysteria 2 等 UDP 系协议的优势主要体现在高丢包链路:自定义拥塞控制不会像 TCP 那样遇丢包就大幅降速。在低丢包的优质线路上两者差距很小;而部分运营商对 UDP 流量限速时,UDP 系协议在高峰期反而可能更慢。
QUIC 是 TCP 还是 UDP?
QUIC 建立在 UDP 之上,但在应用层实现了类似 TCP 的可靠、有序传输,并内置 TLS 1.3 加密与多流复用。选择 UDP 是为了绕开操作系统内核 TCP 实现的限制,HTTP/3 与 Hysteria 2 都以 QUIC 为基础。
相关阅读
WebSocket 长连接为什么会中断
分析 WebSocket 长连接在代理传输中断开的常见原因,包括 NAT 与防火墙的空闲超时、心跳缺失、网络切换、运营商干扰与服务端重启,并说明心跳保活原理与缓解方法。
Shadowsocks、Trojan、VLESS 和 Hysteria 2 对比
从传输基础、TLS 依赖、抗干扰思路、性能开销与客户端支持五个维度对比 Shadowsocks、Trojan、VLESS 与 Hysteria 2 四种代理协议,并按使用场景给出选择建议。
节点延迟、抖动、丢包和带宽分别代表什么
解释延迟、抖动、丢包、带宽四个指标的含义、单位与测量方式,说明客户端延迟测试与 ICMP ping 的差别,以及各指标对网页浏览、视频、游戏和语音通话的不同影响。