如果让我选一个被误解最深的网络常识榜单TCP是可靠的UDP是不可靠的绝对能进前三。它出现在几乎所有教材的练习册里也是网络岗位面试几乎必问的送分题。我入行前几年也把它奉为金科玉律重要的数据走TCP实时数据走UDP以为协议选对了可靠性就自动到手了。直到我在真实项目里因为TCP的可靠反复掉链子又在另一个项目里用UDP扛起了核心业务数据才慢慢意识到这句话就像一句没说完的缩略语——可靠不可靠不是协议名字一锤定音的而是要看你站在哪一层、用什么机制、在什么前提下去兑现这些词。1. TCP可靠、UDP不可靠这句话为什么会坑人1.1 一个面试标准答案引发的工程翻车先讲两个我亲历的案例。第一个是移动端日志上报系统核心链路用的TCP长连接。按TCP可靠的直觉日志文件老老实实传上去总没错结果一到弱网环境问题就来了TCP发现丢包后启动重传后续所有日志字节都在排队等着那个重传包被确认缓冲区越积越多用户感知就是后台任务半天传不完。业务方跑来问不是说TCP可靠吗怎么传个日志比登天还难第二个案例是某实时对战同步模块。最初为了保证不丢消息选了TCP结果某个玩家网络抖动导致一个包重传服务端和这个玩家的后续所有状态更新全部卡在队头其他玩家看到他的角色在漂移瞬移。后来我们把位置同步改成UDP自研了一套带序号和超时重传的轻量确认机制关键控制消息重传、位置消息丢了就算了反而稳定得多。这两件事让我开始反思TCP确实在传输层做了很多事但可靠是需要前提和代价的。当业务对延迟极度敏感时TCP的过度可靠反而是负资产。1.2 可靠到底是个什么层面的承诺要理解TCP可靠、UDP不可靠这句话错在哪得先拆解可靠这个词的三个限定维度。第一个维度是对谁可靠。日常说的可靠传输通常指三个指标不丢失、不重复、乱序后能恢复顺序。TCP在连接存续期间通过序列号、确认号、重传机制确实能做到这三点。第二个维度是在哪一层可靠。TCP的可靠承诺发生在传输层意味着它保证的是应用层写入的字节流能有序不重不漏地投递到对端传输层。第三个维度是在什么前提下可靠。前提包括连接还活着、对端程序没崩溃、中间路径没有持续不可达。只要这个前提被破坏TCP的可靠立刻就失效了。所以更准确的说法应该是TCP在连接存续期间、在传输层这个范围内用一整套机制去兑现不丢不重有序的承诺。而UDP只是没有做这些承诺它不保证送达不保证顺序也不管重传。注意这里的区别是没承诺和专门搞破坏把这两者混为一谈才是这句hoax真正误导人的地方。2. TCP为可靠付出的代价以及它根本管不到的地方2.1 拿什么来兑现可靠三次握手、确认、重传、滑窗、拥塞控制TCP为了兑现自己的承诺在协议栈里塞进了一整套精密到有点啰嗦的机制。最经典的三次握手解决的是序列号同步问题。客户端发SYN服务端回SYNACK客户端再回ACK。为什么非得是三次而不是两次关键在防历史连接误入如果客户端第一个SYN在网络里滞留了很久之后又发起一个新连接服务端收到旧SYN后如果直接建立连接就会把过期的连接请求当成有效请求。三次握手让客户端有能力在一个往返内确认服务端确实收到了我的新序列号双方都确认了各自的收发能力连接才算建立。这也是为什么四次挥手比握手多一次——TCP支持半关闭一方发送完数据后可以只关闭发送方向另一方还得单独关闭所以挥手要各来一轮FIN和ACK。连接建立之后序列号和确认号开始工作接收方告诉发送方我期望的下一个字节序号是多少发送方据此知道哪些字节已经被确认。如果超时没收到确认就触发超时重传如果收到三次重复ACK就认为某个包丢了触发快速重传不用傻等超时。滑动窗口用来做流量控制接收方在报文里通告自己的可用缓冲区大小发送方不能一口气塞爆对端。拥塞控制则管理着另一件事发送方不能因为自己带宽够就把网络灌瘫痪所以要有慢启动、拥塞避免、快速恢复这些状态机。这一大套东西做下来TCP确实在绝大多数正常工作条件下做到了数据不丢不重不乱序。但这些机制不是免费的它们带来了重传延迟、队头阻塞、连接状态维护成本和相对复杂的协议行为。2.2 TCP可靠性的三个边界第一连接边界。TCP只知道这个连接理论上还活着它不会主动感知对端断电、进程崩溃或者中间路由设备把连接状态清空。对端突然断电时发送方收不到RST重置报文只能等TCP重传超时一轮一轮退避。Linux默认重传上限是15次极端情况下要等十几分钟才能确认连接死亡而这段时间内应用层调用send()往往还是返回成功因为数据只是进了本机内核缓冲区根本没送到对端。第二语义边界。TCP保证的是字节流到达对端socket缓冲区不保证对端应用一定正确消费这些数据。对端进程可能崩溃、可能缓冲区堆积导致应用迟迟不读、可能业务逻辑解包出错。在一个订单系统里TCP把支付请求字节流送到服务器了服务器解析失败TCP并不会替你重试这笔业务。所以核心交易系统必须做业务层的幂等、确认和对账这些可靠性和TCP半毛钱关系没有。第三性能边界。TCP的按序交付遵循队头阻塞策略如果一个包丢了接收方缓冲区里后续已经到达的乱序包必须等重传补齐后才能一起交给应用。这在HTTP/1.1时代问题不大但在多路复用和高实时场景下就成了致命伤。你体验到的TCP很卡往往不是丢包本身而是TCP为了维持有序而付出的排队等待。2.3 在TCP之上你依然要做的可靠性工作明白了边界再看那些在热搜里反复出现的问题就很好理解了。粘包拆包是TCP应用开发里最经典的一道坎——因为TCP只提供字节流它不帮你切消息业务层必须自己定义消息边界。常见做法是固定长度、长度前缀或者分隔符我在实际项目里最推荐长度前缀消息体简单高效C、C#、Python都好实现。心跳保活也是必须在应用层补的功课。TCP自带的Keep-Alive默认两个多小时才开始探测很多长连接场景根本等不起。业务心跳一般是每隔几秒发一个探测包连续几个无响应就判定连接已死主动断开重连。此外还有写失败检测二次写操作返回EPIPE/ECONNRESET时立刻认为连接不可用不要继续傻写。你会发现一个很讽刺的现象真正生产级的TCP应用没有哪个是只靠TCP就拿到可靠性的大家都得自己在应用层补心跳、补超时、补消息边界、补业务确认。既然TCP之上还要做这么多那TCP可靠四个字的说服力是不是就打折了3. 拆开UDP它并没有那么脆弱只是没给你承诺书3.1 UDP提供了什么底线能力很多人一说UDP就联想到裸奔其实它不是完全没有底线的。UDP头部只有8字节包含源端口、目的端口、长度和校验和。IPv4下校验和是可选字段但几乎所有主流实现默认都开启到了IPv6UDP校验和已经是强制要求了。也就是说UDP至少能帮你发现传输过程中比特翻转的问题发现不了就会丢给上层——这已经比完全裸奔强了一点。UDP真正不做的是连接状态管理。它没有握手没有序列号没有确认没有重传没有拥塞控制。发送端做的事情只有一件把数据报交给IP层然后转头去干别的。接收端收到就收到收不到也没有任何反馈机制。这个特点带来的就是大家常说的不可靠。但请注意UDP的不可靠不等于数据会被故意扔掉。它只是个不设防的投递员路上会不会丢、会不会乱它管不了也不负责。也就是说UDP存在丢包和乱序的可能性但并不等于在实际网络里天天丢。3.2 无连接在很多场景里其实是优势无连接意味着没有握手开销、没有连接表、没有保活定时器这在两个方向上都有巨大价值。一个是低延迟。TCP建立连接要一次RTT往返时间如果应用特别在意首包延迟比如DNS查询或NTP校时用UDP一包一发省掉握手时间体验完全不同。TCP还有Nagle算法和延迟确认的组合拳小包在发送端或接收端可能被额外滞留40ms甚至更久UDP完全没有这些为可靠而加的等待。另一个是多播和广播能力。UDP天然支持一对多、多对多的通信模型IP组播、广播、DHCP、SSDP设备发现、mDNS等服务发现全部靠UDP。设备做局域网自动发现服务器给一批PLC广播下去这种一群人同时收的场景TCP根本做不了——它天生只支持一对一。热搜里的西门子1200 udp组播就属于这一类PLC把状态包组播到网内组态软件和各终端各自订阅无连接特性反而成了刚需。3.3 我们把账算错了丢包通常不是UDP的错实际网络中丢包的主因是路由器、交换机在拥塞时直接丢弃报文或者无线链路信号抖动导致帧出错。这些包如果走的是TCP一样会丢区别只是TCP在丢包之后会重传UDP不会。换句话说UDP没有让网络丢包它只是没有掩盖丢包。把这一点想明白以后UDP的不可靠反而变成了一种特性因为不重传所以不会把旧数据反复送来因为不保证有序所以应用层可以自己决定哪些乱序包可以直接丢弃、哪些需要缓存等待。例如实时视频一个迟到300ms的视频帧对画面渲染毫无价值重传它只会让画面更花丢了它下一帧马上补上人眼根本察觉不到。这种按需可靠的灵活性恰恰是TCP给不了的。4. 亲手把UDP变成可靠传输从零搭建一个迷你可靠协议4.1 可靠是策略不是协议属性如果你现在以为我要说所以UDP永远不可靠只能忍那就又掉进另一个误区了。实际上可靠性是机制的组合不是协议栈里不可外传的魔法。TCP能做到的事你在UDP之上完全可以用应用层代码复刻一遍。最有力的证据就是QUIC。它底层走UDP但在用户态实现了连接建立、加密、可靠有序、重传、流量控制、多路复用每个数据流独立有序一个流丢包不影响其他流彻底解决了TCP的队头阻塞问题。HTTP/3跑在QUIC上可以说UDP承载了你最核心的Web流量。游戏开发圈很熟悉的KCP也是基于UDP实现可靠传输平均延迟比TCP能低30%到40%左右因为它的重传策略更激进、更针对实时场景。还有面向高带宽音视频的SRT、UDT全都是在UDP之上做可靠性。自研可靠UDP的最大价值在于你可以为不同的消息定制不同级别的可靠性关键控制消息用确认加重传普通状态消息丢了就丢了不需要像TCP那样一视同仁地保证所有数据。4.2 一个最小可用的可靠UDP协议设计假设我要在局域网里做一套自己的可靠消息通道最小方案可以这样设计。协议头固定9字节4字节的序列号、4字节的确认号、1字节的标志位。标志位里用bit0表示ACKbit1表示DATA。发送端逻辑给每个数据包编一个递增seq发出后启动超时定时器收到对端ACK且确认号等于当前seq才算发送成功超时了还没确认就重传最多重传N次。接收端逻辑收到DATA包后返回一个ACK包确认号填收到的seq如果有缓存能力就处理乱序没有就先按顺序到达最简单的方式。下面是发送端的核心Python代码逻辑已经足够在真实工程里跑通小流量场景import socket import struct FLAG_ACK 0x01 FLAG_DATA 0x02 def make_packet(seq, ack, flags, payloadb): return struct.pack(!IIB, seq, ack, flags) payload def send_reliable(sock, addr, payload, timeout0.8, max_retry6): seq 20240001 # 应用自行维护的起始序号 packet make_packet(seq, 0, FLAG_DATA, payload) for retry in range(max_retry): sock.sendto(packet, addr) sock.settimeout(timeout) try: data, _ sock.recvfrom(128) rseq, rack, rflags struct.unpack(!IIB, data[:9]) if rflags FLAG_ACK and rack seq: return True except socket.timeout: continue return False对应的接收端循环def recv_loop(sock, expect_seq): while True: data, addr sock.recvfrom(2048) seq, ack, flags struct.unpack(!IIB, data[:9]) payload data[9:] if flags FLAG_DATA and seq expect_seq: # 按序到达交付给上层并回ACK sock.sendto(make_packet(0, seq, FLAG_ACK), addr) expect_seq 1 yield payload else: # 乱序或重复包先回ACK防止发送端反复重传 # 如果要支持乱序恢复需要在这块做缓存和排序 sock.sendto(make_packet(0, seq, FLAG_ACK), addr)这段代码只有几十行但已经再现了TCP的序列号、确认、超时重传三件套。实际生产里当然不能只做停等协议要想吞吐高还得引入滑动窗口并发发送多个包但原理骨架就是这些。很多人看完会说这不就是把TCP又造了一遍吗对可靠机制本来就是这些你完全可以按自己的业务需求裁剪——这正是自研的价值用UDP时你拥有对帧纪律的完全控制权。4.3 上生产前先看看成熟方案自研可靠UDP很有意思但如果不想从零造轮子业界已经有很多经过验证的方案。方案特点典型场景QUIC多路复用、0-RTT、连接迁移解决队头阻塞HTTP/3、移动长连接KCPARQ模型、快速重传、低延迟游戏同步、对战平台SRT高吞吐、丢包恢复、AES加密直播、广电级视频传输UDT面向高带宽广域网的高性能传输大数据文件传输WebRTCRTP/RTCP、NACK、FEC、JitterBuffer一整套实时音视频通话选型建议很直接如果只是游戏服务器内部模块通信KCP够轻量如果是做Web服务QUIC由浏览器和服务端天然支持如果是传输高清视频流SRT的丢包恢复和加密机制比你自己写稳定得多。自研可靠UDP只推荐给有非常特殊的消息可靠性分级需求或者纯学习目的。5. 工程里的选型现实什么时候该用TCP什么时候该用UDP5.1 TCP的舒适区在哪里TCP依然是我日常项目里默认的第一选择。Web API、数据库连接、消息队列、文件传输、Modbus TCP、OPC UA这类指令式和事务式通信全部适合TCP。这些场景的共同特点是数据绝对不能丢乱序几乎不能忍消息量不大延迟多几十毫秒可以接受。TCP的好处在于你不需要重复发明确认和重传机制协议栈已经帮你处理好了网络层的大部分脏活累活。但请注意选TCP不等于选省心。去翻一下热搜里的asio库如何做tcp server和c语言写一个tcp通信demo就知道围绕TCP的开发问题永远绕不开两个核心消息边界怎么切、连接生命周期怎么管。用Boost.Asio写TCP服务器时你要自己处理async_read要读满多少个字节、粘包时多余数据怎么缓存、对端半关闭时EOF怎么处理这些全是应用层的工作。TCP只是保证了这些字节一定按序到达至于你读出来是什么业务含义它不负责。还有一个典型场景OpenCvSharp配置RTSP流为TCP。RTP媒体流默认走UDP但公网环境下UDP包经常被防火墙直接丢弃视频花屏甚至完全打不开所以很多拉流实现会把RTSP的传输模式从UDP手动切成TCP让TCP承载RTP包。结果就是画面稳定了很多但在带宽不足或重传频繁时延迟会明显上升——这就是在实时和可靠之间做选择的一个活生生的例子。你用TCP保护了不丢帧就得接受它偶尔卡顿。5.2 UDP的舒适区在哪里UDP适合的场景一句话概括能接受少量丢弃、更在意实时性或者天然需要多目标通信。DNS、NTP、DHCP是教科书级的UDP应用一次请求一个应答超时了就重发根本不需要复杂连接状态。操作系统的服务发现、交换机的组播配置、西门子S7-1200的UDP组播靠的都是UDP的多播能力。实时音视频WebRTC、游戏的位置状态同步更是UDP的天下一个玩家的坐标发出去了对端收到就渲染没收到就等下一个包旧坐标对渲染没有任何保留价值重传反而让画面更扭曲。工业物联网领域我也见过不少遥测系统直接选UDP。传感器每秒钟上报10次温湿度、振动数据这丢一次有什么关系下一秒的数据马上就到。反而如果用TCP某次网络抖动触发重传后续高频数据全在缓冲区排队等恢复后突然灌过来一手是旧的一手是新的整个时间序列乱掉。无状态、低开销、不排队这才是UDP在高频数据下的真实价值。5.3 混合架构才是最成熟的方案真实工程里很少有什么都得二选一的死结更多时候是TCP和UDP各扛一半职责。常见的混合架构是控制通道走TCP媒体或状态通道走UDP。比如视频会议系统信令层一定用TCP或HTTPS保证指令可靠音视频流走UDP/SRTP保证实时。游戏的房间服务也类似匹配、登录、Chat走TCP连接对局内位置同步走UDP。另一个思路是全UDP但分层处理视频场景用FEC前向纠错恢复一部分丢失再给关键帧加应用层重传普通帧丢了就丢——WebRTC就是这么干的发送端根据RTCP反馈动态决定是重传还是生成新的冗余包。我在做一个远程操控类项目时也踩过这个分界。控制命令用TCP一旦网络抖动操作者感觉机器人反应迟钝后来改成UDP应用层确认控制命令带序号和去重网络抖动时宁可丢掉某个指令包也要保证最新的指令尽快到达手感瞬间好了一个量级。核心业务数据最后还有一层本地缓存落盘和事务对账确保即使UDP链路偶尔抽风最终数据仍然能对齐。这套牺牲局部可靠、保证整体实时再靠上层对账兜底的思路比死守必须用TCP灵活得多。6. 从热搜里的真实问题看可靠/不可靠的另一面6.1 TCP侧的假可靠翻车现场热搜词里有一串TCP相关的开发问题仔细看你会发现几乎每个问题都指向同一个结论TCP的可靠是内层可靠不等于业务层可靠。TCP粘包问题排在开发者困扰前列本质就是TCP流式传输造成的消息边界丢失。你以为发送端两次send是两条消息接收端可能一次recv全收到或者收到半条必须自己识别边界。网上大量tcp粘包处理的代码都是围绕长度前缀或分隔符在做文章。这算不算TCP不可靠不算但它足以戳破用了TCP业务就稳了的幻觉。lwIP tcp断连是嵌入式场景的高频痛点。lwIP栈在处理对端异常掉线时应用层往往要等很久才发现连接已死因为只有在重试发送数据并且失败、或者TCP重传次数达到上限后协议栈才会向应用抛错。很多嵌入式设备因此死等一个永远不会来的响应。我自己的处理习惯是应用层主动维护心跳超过预期时间就主动重连千万别指望lwIP替你做健康检查。半开连接同样阴魂不散。对端路由器断电重启TCP连接状态被中间设备清空但两端socket都还以为连接活着。直到某一方尝试发送数据对端回一个RST才能真正断开。所以稍微严谨一点的TCP应用一定会做发送-验证-确认周期而不是把数据一股脑丢给内核就完事。6.2 UDP侧的伪不可靠造成的误会UDP侧的问题同样有一堆而且不少都被错误归结为UDP不可靠。最有迷惑性的就是Windows下read udp: unknown error (code10054)。这个错码的完整含义是WSAECONNRESET通常出现在你向某个UDP端口发包而那个端口根本没有进程监听对端主机会返回一个ICMP端口不可达报文Windows系统把这个反馈映射为一个错误让你的UDP套接字在recvfrom时收到10054。这不是UDP丢数据恰恰相反它是网络在对你说我明确拒绝了别发了。遇到它先检查对端端口有没有监听比盲目换协议更有意义。UDP大包和IP分片也是个常见的坑。单个UDP数据报超过路径MTU时IP层会把它分片传输任何一个分片丢失整个数据报在接收端都无法重组现象就是发出去2000字节的UDP包偶尔整个消失。热搜里的udp划分ip数据报片和C# UDP发送分包组包都是这个问题的变体。稳妥做法是应用层把大数据拆成不超过MTU通常按1400字节算的分片给每个分片编号接收端做重组或者直接不要发超大UDP包。UDP组播需要理解的则是另一套敏感点IGMP组管理、交换机二层组播过滤、三层路由的组播转发任何一环没配好组播报文就可能到不了接收端。这不是UDP协议不可靠而是你选了一个需要网络基础设施配合的技术路线。排查这类问题时要从组播组成员关系查起先确认主机确实加入到了组再去查交换机和路由器的组播表项。6.3 用工具看清可靠性的真相很多争论在工具面前会变得毫无意义。我强烈建议每个做网络开发的人都学会用Wireshark和iperf3观察真实数据而不是靠口诀猜。用Wireshark抓一次TCP传输你会看到重传Retransmission、快速重传、乱序Out-of-Order、重复ACK在拥塞时频繁出现——TCP并不是一个不丢包的协议它只是丢完之后努力补。用iperf3做UDP打流时iperf3 -u -b 800m -l 1400 -t 30这样的命令很快就能暴露链路带宽上限和丢包率。如果你发现UDP在特定带宽下丢包率飙升说明链路已经拥塞这时换TCP也不会让带宽凭空变大只会用更多的重传把延迟拉高而已。所以判断一个选型是否合理永远要看业务指标延迟、丢包率、带宽、连接稳定性综合起来评估而不是抱着可靠/不可靠两个词贴标签。把这一圈看下来TCP可靠、UDP不可靠这句话在我心里已经完全从技术结论降级成了教学口诀。它适合帮初学者记住两种协议的大方向但不适合直接拿来当工程决策依据。现在我设计系统时的习惯是先问自己这个链路上什么能丢、什么不能丢、延迟预算多少然后再决定这层用TCP、用UDP、还是在UDP之上自己做一部分可靠。可靠性最终是端到端的系统设计数据幂等、消息去重、超时重传、状态对账这些事在哪一层做、怎么做远比协议名更重要。