TCP可靠UDP不可靠？拆解协议选型与可靠传输的工程真相

先提一个反直觉的问题：如果你说“TCP是可靠的，UDP是不可靠的”，在日常技术交流里，基本不会有人反对。这句话几乎成了网络编程的入门共识，面试题里也常拿它当标准答案。但如果我这几年调过跨地域专线、做过弱网环境下的视频传输、盯过Wi-Fi环境下的TCP重传统计，我得提醒你：这句话在原理层面是对的，在工程层面却是一个过于简化、甚至会误导人的“hoax”（伪命题）。

不是说TCP不好，也不是说UDP神奇地变可靠了。而是“可靠”这个词的边界被大家下意识地模糊了。TCP确实提供了可靠的字节流传输，但这种可靠是有前提的，是需要路径上所有环节配合的，甚至在某些极端场景下，TCP表现出的“不可靠”一点都不比UDP少。反过来，UDP虽然不承诺可靠交付，但工程界早就发展出一整套在UDP之上建立可靠性的方案，从游戏同步到WebRTC视频通话，大家都在“不可靠”的UDP之上交付了可靠的业务。

这篇文章我想把这个话题拆开聊透。既不捧TCP，也不贬UDP，而是从协议设计目标、真实网络环境、以及一堆我实际踩过的坑出发，讲清楚“可靠”到底是由谁定义的，什么情况下TCP的可靠会失效，什么情况下UDP反而更适合业务，以及我们做技术选型时到底该信哪句话。

1. 内容整体设计与思路拆解

1.1 “可靠”这个词，被TCP和UDP都说烂了

要聊清楚TCP可靠、UDP不可靠这个论断，第一步得回到协议的原始设计目标上。TCP（Transmission Control Protocol）在设计之初，想的就非常清楚：要在不可靠的IP层之上，向上层提供一个看起来像“本地文件读写”一样可信的字节流通道。为了实现这个目标，TCP在协议栈里塞了一整套保障机制——序列号、确认应答、重传超时、滑动窗口、拥塞控制、流量控制。这些机制组合起来，保证了这样一个性质：只要连接还在，应用层把数据交给TCP，TCP就确保这些数据以正确的顺序、完整地到达对端。

这个性质听起来很硬核，但它有一个隐含前提：路径上不能有设备主动切断连接，物理链路不能持续恶化到无法维持连接的程度，端到端的缓冲区不能长期溢出。一旦这些前提被打破，TCP所谓的“可靠”就变成了有条件的可靠——而条件到底是什么，大部分做应用开发的人其实是说不清的。

UDP（User Datagram Protocol）的设计哲学则完全相反。它不承诺可靠性，不承诺顺序，不承诺不重复，甚至不承诺对端一定在线。它只做一件事：把应用层给的报文原样塞进IP层，然后就撒手不管。这种设计常被认为是缺陷，但换个角度看，UDP不承诺可靠，恰恰意味着它没有为“可靠”付出任何代价——没有连接状态、没有重传、没有头部开销之外的额外负担、没有拥塞控制的约束，这些特性让UDP在实时性优先的场景里变得异常好用。

1.2 两个协议的设计目标对比

要真正理解TCP和UDP的差异，不能只看“可靠”和“不可靠”这个二元标签，而要看它们各自为达成目标付出了什么。我整理过一个对比表，能比较直观地看出两者的分工逻辑：

这张表背后的逻辑很清晰：TCP把可靠性相关的复杂度全部收敛到了协议栈内部，应用层几乎不需要关心数据会不会丢；UDP把这一切复杂度全部留给了应用层，协议栈只管透传。换句话说，TCP替应用层承担了可靠性责任，UDP把可靠性责任交还给了应用层。所以UDP不是不能可靠，只是它不负责可靠，可靠与否完全取决于上层怎么用它。

1.3 这个“hoax”是怎么在工程里被放大的

那么问题来了：为什么“TCP可靠 / UDP不可靠”这句话会成为一种直觉，并且在实际工程里带来误导？

我觉得至少有三个层面的原因。第一，教科书和面试题把这句话简化成了一个判断标准，没有带上前置条件。久而久之，很多人就默认TCP等于不会丢数据，UDP等于一定会丢数据。第二，大部分人在局域网、本地回环环境下测试，网络条件太好了，TCP的可靠性机制几乎从不触发，UDP的丢包也几乎为零，测试结果反而让“TCP稳、UDP不稳”这个印象更固化。第三，一旦换到公网、移动网络、跨地域链路，TCP的重传、拥塞控制、队头阻塞这些问题会集中爆发，表现出的“不可靠”与教科书描述严重不符，但很少有人回头质疑那句口号本身的边界。

我的观点很明确：“可靠”不是协议的属性，而是工程的成果。TCP提供了实现可靠性所需要的机制和框架，UDP提供了实现可靠性所需要的自由和灵活性。两者都只是工具，最终是否可靠，取决于你如何理解网络、如何设计应用。

2. TCP的“可靠”在真实网络中是如何失效的

2.1 校验和：TCP的可靠性审计并非完美

很多人不知道，TCP的可靠性保证里有一环是“校验和”，但TCP校验和的设计强度其实一般。TCP头部的校验和字段只有16位，虽然覆盖了TCP头和整个数据块，但16位的校验和面对随机比特翻转、尤其是连续多位错误时，漏检率并非为零。以太网帧和IP层还有各自的校验机制兜底，但链路层的FCS（帧校验序列）同样不是绝对可靠，Wi-Fi环境下偶发的静默损坏是真实存在的。

说个我实际碰到过的案例。有一次排查一个跨机房的文件传输损坏问题，两端都是TCP连接，传输过程中没有任何重传和报错，但最终落盘文件的哈希值跟源文件不一致。当时排查下来，就是交换机链路上的偶发误码没有被TCP的校验和捕获，数据被“可靠地”传错了。这个案例非常珍贵，因为它让我意识到：TCP的可靠是一个概率上的高可靠，不是数学上的绝对可靠。对于极端重要的数据，应用层加一层完整的校验和摘要再做比对，永远是值得的。

2.2 重传风暴与延迟放大：重传机制的另一面

TCP的可靠依赖重传，但重传本身就是一把双刃剑。在丢包率较高的链路上，TCP的行为是超时等待，然后重传数据，同时指数退避。这个过程带来的直接后果是：数据虽然最终能送达，但延迟可能从几十毫秒飙升到几秒，甚至几十秒。

举个例子，我在一次跨地域专线调优中看到过这样的现象：链路往返时延RTT本来约30ms，但因为线路偶尔丢包，TCP进入重传退避后，单次数据传输的实际耗时可以达到数秒。对文件传输来说，最终成功也算可接受；但对实时交互业务，比如远程操作、实时协作编辑、行情推送，这种延迟放大是致命的。业务要求的是“尽量快”，TCP却为了保证“最终到”付出了巨大的时间代价。这时候UDP反而好控制，丢了就丢，应用层自己决定是重发还是跳过，至少不会让整条链路被一个丢失的包拖死。

2.3 队头阻塞与连接级故障：可靠传输的代价

TCP的第三个问题，是队头阻塞（Head-of-Line Blocking）。因为TCP保证有序交付，所以一旦某个报文丢失，后续已经到达的报文都卡在接收缓冲区里，必须等丢失的报文重传成功之后，才能一并交给应用层。这在丢包环境下特别要命。

我做过一个HTTP/1.1和HTTP/2的对比测试，在模拟1%丢包的链路上，HTTP/2多路复用的优势几乎被队头阻塞吃掉，因为底层那条TCP连接一旦丢包，所有复用的流都得等着。这也是后来HTTP/3直接换用UDP+CUDP（即QUIC）的根本原因——与其在TCP的字节流里做多路复用，不如在UDP的报文之上自己做独立的可靠流，这样一条流的丢包不会阻塞另一条流。

除了队头阻塞，TCP的连接级故障也不可忽视。TCP的可靠性是建立在连接之上的，但连接本身会断。服务器进程崩溃、网络设备重置、NAT会话超时、运营商RST注入，任何一个环节都可能让看似“可靠”的连接瞬间失效。连接断了之后，TCP并不会帮你把数据“续传”，应用层如果不能感知并恢复，数据的丢失就是实实在在的。这时候你回头看那句“TCP是可靠的”，会觉得很讽刺：TCP保证的只是连接存活期间的可靠，连接本身可能是脆弱的。

2.4 内核缓冲区与背压：被忽略的静默丢数据点

还有一个容易被人忽略的细节：TCP的可靠是针对“已提交给协议栈的数据”而言的，但数据从应用层到对端应用层之间要经过多次内核缓冲区的拷贝和排队。任何一个缓冲区满了，行为就会变得微妙。

说一个具体场景。接收端的接收缓冲区如果因为应用层读取不及时而被填满，TCP的流量控制机制会通过缩小窗口来阻止发送端继续发送，这是TCP的优雅处理方式。但如果因为拥塞控制或某些实现细节，内核丢掉了入队的数据且没有反馈，TCP的重传机制通常会在之后补上。真正的问题是，很多应用层代码假设“send成功=数据到了对端”，这个假设在TCP上也不完全成立。send只是把数据放进了内核发送缓冲区，真正到达对端还要经历网络传输和对端接收处理。如果对端进程崩溃，TCP连接会以RST或超时结束，发送端那些“send成功”的数据，对端一个都没收到。

所以我在团队内部一直强调一个原则：TCP的可靠是传输层的可靠，不是应用层的可靠。应用层需要关心对端到底有没有处理成功，需要自己的确认机制，不能把一切寄托在“TCP不会丢数据”上。

3. UDP的“不可靠”如何被工程实践改造成可靠

3.1 先认清UDP到底丢在哪儿

要说UDP不可靠，首先得承认这个论断有其现实基础。UDP报文在传递过程中，确实有可能因为中间设备缓冲满、链路拥塞、MTU分片丢失等原因被丢弃。在公网环境下，UDP丢包率通常比TCP高，这也不是错觉。

但同时也得看清另一面：UDP的丢包并不是均匀发生的，也不是不可避免的。在我做过的局域网和公网对比测试里，局域网环境下的UDP丢包率常常是零，公网环境下的丢包也往往集中在特定链路、特定时段。换句话说，UDP的“不可靠”更像是一种“上限风险”，而不是“必然命运”。这跟TCP的重传放大延迟问题放在一起看，有意思的地方就出来了：丢包率低的网络里，UDP的体验远好于TCP，因为省掉了连接管理和ACK反馈的往返开销；丢包率高的网络里，TCP有重传兜底，UDP裸用则惨不忍睹。所以，UDP是否“不能可靠”，取决于你愿不愿意在应用层补上TCP那一套机制。

3.2 应用层可靠性设计：在UDP之上重建秩序

既然TCP的可靠是一套机制堆出来的，那这套机制的理论是可以复用的——只是换成应用层来实现。经典的RUDP（Reliable UDP）思路就是干这件事的：在UDP报文上增加序列号、ACK、重传、超时、乱序缓冲区，把TCP的核心机制移植到应用层。

我实现过一个简化版的设计，核心要素包括：

• 每个应用数据包附带一个自增的序列号；
• 接收端收到数据后，周期性返回ACK，带上已收到的最小连续序列号；
• 发送端维护一个发送缓冲区，超过一定时间未确认的包就重发；
• 接收端维护一个乱序缓冲区，序列号不连续的包先缓存，等前序包到达后再按序提交给上层。

这套机制写起来不难，真正麻烦的是处理各种边界情况，比如ACK本身丢失导致的重发风暴、重复包的去重、接收缓冲区的上限管理、带宽估算与发送速率控制。做一圈下来，你会非常深刻地理解一句话：TCP把苦活累活都干完了，而“在UDP上重建可靠”就是把TCP的苦活累活重新做一遍，只不过这次你能按业务需求做定制。

实际工程里，这种定制是有价值的。比如游戏同步场景，业务关心最新状态的及时送达，旧状态丢了无所谓，所以发送策略往往是“只保留最新状态”，而不是TCP那样按序重传所有数据。再比如音视频通话，视频帧之间有关联，但迟到的帧再补发已无意义，所以应用层会选择“跳过重传”而不是“死等重传”。这些业务诉求是TCP那个二元的“可靠”模型根本无法满足的——TCP认为所有数据同等重要，但业务知道有些数据过期即是垃圾。

3.3 QUIC：把可靠流嵌进UDP的现代答案

如果要在今天的工程语境里谈“UDP之上建可靠”，QUIC是无法绕开的名字。QUIC本质上是一个运行在UDP之上的传输协议，它保留了TCP的可靠性语义——序列号、确认、重传、流量控制、拥塞控制，同时又把可靠性拆成了多流并行的模型，每个流独立确认、独立重传，从根本上规避了TCP队头阻塞的问题。

用QUIC做传输层的好处，我在实际部署中感受很深。首先是连接建立耗时大幅降低，TCP+TLS的握手通常需要一个RTT以上，QUIC可以在首个RTT内同时完成传输和加密协商。其次是在弱网环境下的表现，QUIC对丢包的处理更加细粒度，单流的丢包不会拖累整个会话。再加上连接迁移能力——IP地址变了连接还在，这对移动端网络切换的帮助极大。

我还得说一个细节：QUIC虽然用了UDP，但它对可靠性的实现比很多TCP实现还要严谨。它的数据包有完整的前向纠错和重传编号，它的拥塞控制可以适应不同链路，它的接收缓冲管理比传统TCP栈更精细。这个事实本身就是对“UDP不等于不可靠”的最好注脚——不可靠的只是裸UDP，可靠与否取决于你往UDP之上堆了多少协议智慧。

3.4 面向消息的设计：UDP天然免粘包

还有一个常被忽略的点：UDP的报文边界让它在做消息通信时比TCP更干净。TCP是字节流，没有消息边界，应用层必须自行处理粘包与半包——这就是“tcp粘包处理”成为热门关键词的原因。而UDP一个报文就是一个完整消息，应用层收一次就是完整包，天然没有粘包烦恼。

我做过高并发日志上报系统，当时面临的选择就是TCP还是UDP。如果选TCP，就得在应用层设计完整的分帧协议：魔数、长度、序号、校验。如果选UDP，每条日志一个报文，直接带个序列号和校验就发出去，接收端按序列号做乱序整理和去重，反而代码量更少。最后我选了UDP，加上简单可靠机制，跑了大半年稳定得很。这件事也让我更坚定了一个想法：可靠性不是传输协议的专利，而是整体设计的产物。TCP只是提供了一种实现可靠性的现成框架，不代表它适合所有业务。

4. 实操过程与核心环节实现

4.1 一步步做一个TCP与UDP的对比实验

光讲理论不过瘾，我建议你亲手做一个实验：在同一台机器上，用TCP和UDP同时向同一个接收端发送10万条消息，然后在人为制造丢包的情况下对比两者的表现。这个实验能非常直观地打破“TCP绝对可靠”的印象。

实验环境可以选择Linux虚拟机或者云服务器，我用的是两台云主机，中间网络有轻微丢包。发送端用同一个数据生成器产生10万条带序号的消息，TCP侧把所有消息按字节流发给接收端，UDP侧每条消息封装为一个报文。接收端分别统计：收到的消息数、乱序数、按序完整率、耗时。

实验的关键是控制变量：两条路径并发，同样的数据源，同样的网络。TCP侧因为要建立连接，实际耗时必然包含握手时间；UDP侧因为没有连接管理，纯传输耗时更短。如果网络上完全没有丢包，TCP和UDP在数据完整性上的区别为零，唯一区别是耗时和开销。如果加上丢包，TCP会表现为“总耗时变长但最终完整”，UDP会表现为“耗时稳定但数据残缺”——这时候你就能亲眼看到，TCP的可靠是用延迟换来的，UDP的不可靠是以牺牲完整性换来的。

4.2 工具实测：iperf3、Wireshark与tcpdump的使用经验

光有自己的小实验还不够，要想深入理解TCP和UDP在网络中的真实行为，有几个工具是绕不开的。

iperf3是最经典的打流工具。我以前专门测过一个跨机房链路，命令大致是这么用的：

服务端：

iperf3 -s

客户端打TCP流量：

iperf3 -c <服务器IP> -t 60 -i 5

客户端打UDP流量并指定带宽：

iperf3 -c <服务器IP> -u -b 100M -t 60 -i 5

这个测试的价值在于能看到TCP和UDP在相同链路下的吞吐和丢包对比。TCP会自动适应带宽，跑满链路不在话下；UDP如果指定的发送速率超过链路能力，就会产生大量丢包，而且会拖累整个链路的稳定性。我在一次测试中发现，一个UDP打满带宽的会话，能让同链路上的TCP吞吐掉一半——原因就是UDP抢占带宽导致TCP的拥塞控制不断误判丢包而退避。用UDP打流一定要控制速率，不能无脑全速发，否则会制造网络风暴。

Wireshark是分析TCP行为的神器。抓包后重点看几个字段：TCP Retransmission（重传）、TCP Dup ACK（重复确认）、TCP Zero Window（窗口零）。这三个信号分别对应丢包重传、乱序触发快速重传、接收端处理不过来。我排查线上问题时的经验是，先把这三类事件的分布情况拉出来，基本就能判断问题出在链路层还是应用层。

tcpdump是命令行下的抓包利器，在服务器上排查问题时比Wireshark更实用：

tcpdump -i eth0 'tcp port 8080' -w tcp.pcap tcpdump -i eth0 'udp port 8000' -w udp.pcap

抓完包之后可以带回本地用Wireshark分析，也可以直接用tcpdump的统计模式看汇总情况。实际工作中，很多TCP的“灵异现象”——比如连接明明建立却发不出去数据，或者收到一堆重复ACK——都能在抓包里现出原形。

4.3 Python实测代码与核心结论

这里我贴一个简化版的对比实验代码，你可以直接拿去跑，数据量可以根据网络情况调整。

发送端主要逻辑：

import socket import time def tcp_send(host, port, total=100000): # 接入业务约定的帧格式，实际中先发4字节长度再发包体，避免粘包 buf = b'' for i in range(total): buf += f'msg-{i}-'.encode() + b'x' * 64 with socket.create_connection((host, port)) as s: t0 = time.time() s.sendall(buf) s.shutdown(socket.SHUT_WR) t1 = time.time() print(f"TCP total: {total}, bytes: {len(buf)}, cost: {t1 - t0:.3f}s") def udp_send(host, port, total=100000): # UDP每条消息独立报文，attach序号供对端校验 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) t0 = time.time() for i in range(total): payload = f'msg-{i}-'.encode() + b'x' * 64 s.sendto(payload, (host, port)) t1 = time.time() print(f"UDP total: {total}, cost: {t1 - t0:.3f}s")

接收端主要逻辑：

import socket def tcp_recv(port): # 需要按自定义格式分割字节流，但这里简化按缓冲收集后切分 lsock = socket.socket() lsock.bind(('0.0.0.0', port)) lsock.listen(5) conn, _ = lsock.accept() chunks = [] while True: data = conn.recv(8192) if not data: break chunks.append(data) payload = b''.join(chunks) msgs = payload.split(b'msg-') # 解析序号，统计完整 print(f"TCP recv total: {len(msgs) - 1}") def udp_recv(port, expect=100000): s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.bind(('0.0.0.0', port)) found = set() while len(found) < expect: data, _ = s.recvfrom(2048) # 提取序号 try: start = data.find(b'msg-') end = data.find(b'-', start + 4) idx = int(data[start + 4:end]) found.add(idx) except Exception: pass print(f"UDP recv total: {len(found)}")

这段代码的价值不在于多么完善，而在于暴露了最核心的差异：TCP的接收端要解析字节流，必须处理半包和粘包；UDP的接收端每个包都是完整的。如果网络有丢包，TCP发送端的耗时会明显增加，因为重传要等超时；UDP发送端的耗时几乎不变，但接收端能收到的包数会明显少于发送数。

我在一个有1%丢包的网络里跑过一次，结论是TCP最终收到了全部的10万条数据，但耗时比无丢包环境增加了差不多3倍，且连接里出现了大量重传和窗口收缩；UDP耗时基本没变，但只收到了98300多条数据，缺失接近1700条。这就是那句话的具象化版本：TCP慢而全，UDP快而缺。选择哪个，取决于业务更需要“全”还是更需要“快”。

4.4 可靠UDP的最小实现方案

如果你需要在UDP之上做可靠传输，又不打算直接用现成的QUIC库，我给你一个最小可行方案的设计框架。

核心思路是ACK+序号+超时重传。发送端为每条数据分配一个16位序号，数据放入发送队列，等待对应ACK。接收端收到数据后，立即返回ACK，带上已收到的序号。发送端为每条数据启动一个定时器，超过500毫秒（这个值可以根据网络的RTT调整）仍未收到ACK则重发。接收端维护一个乱序表，序号连续的提交给应用，不连续的暂存，同时通过ACK里的信息告知发送端还需要哪些序号。

伪代码级别的实现大致是：

发送端：

# 每条消息: seq(4字节) + payload inflight = {} seq = 0 last_ack = 0 def send(udp_sock, peer, payload): nonlocal seq msg = struct.pack('H', seq) + payload udp_sock.sendto(msg, peer) inflight[seq] = (time.time(), payload) seq += 1 def on_ack(ack_seq): # 连续确认可以滑窗推进 for i in range(seq): if i <= ack_seq: inflight.pop(i, None) def retransmit(udp_sock, peer): now = time.time() for seq_id, (t, payload) in inflight.items(): if now - t > 0.5: msg = struct.pack('H', seq_id) + payload udp_sock.sendto(msg, peer)

接收端：

recv_buf = {} expected = 0 def on_recv(data): nonlocal expected seq_id = struct.unpack('H', data[:2])[0] payload = data[2:] recv_buf[seq_id] = payload while expected in recv_buf: deliver(recv_buf.pop(expected)) expected += 1 send_ack(expected - 1) # 连续序号前的都确认

这套代码非常轻量，但已经具备了可靠传输的骨架。要上生产还有几个细节要处理：ACK的间隔合并以避免洪泛、乱序缓冲的上限与淘汰策略、重复包的去重、拥塞控制的粗略估算。做完整之后你会发现，你其实是在造一个私有版的TCP——但因为你控制着每一条策略，可以按业务需求做取舍，这正是UDP最迷人的地方。

5. 常见问题与故障排查实录

5.1 TCP场景下的坑

现象一：TCP连接建上了，但发不出去，也没报错。这种问题我排查过好几次，最常见的元凶是接收端的接收缓冲区满了，内核通告了零窗口，发送端即使有数据也只能等窗口恢复。如果发送端的应用层对超时没有感知，就会表现出“既不成功也不失败”的卡死状态。排查方法是用netstat看发送队列和接收窗口：

netstat -ant | grep 8080 ss -ant | grep -E 'Send-Q|Recv-Q'

输出里如果Send-Q持续不为零，说明数据积压在本地发送缓冲区，大概率是对端没读走或者窗口为零。

现象二：TCP连接频繁断开重连，但应用层没逻辑问题。这种常见于跨地域长连接，比如手机App与服务器保持的推送通道。原因通常是NAT会话超时把映射表项清掉了，TCP连接被迫中断。解决方式一般是调短保活周期，或者直接用支持连接迁移的协议。如果你还在用TCP，比较实用的做法是在应用层做一个心跳，心跳间隔小于NAT超时时间，通常取30到60秒。

现象三：TCP传输速度上不去，明明带宽很大。这里最常见的原因是接收缓冲区太小或者窗口缩放没生效，导致链路无法填满。可以用iperf3确认打到哪个吞吐量，再用sysctl调大内核参数：

sysctl -w net.core.rmem_max=134217728 sysctl -w net.core.wmem_max=134217728

同时确认TCP窗口缩放选项在两端都开启。还有一个我以前踩过的坑是MTU问题，一旦路径上存在MTU黑洞，TCP会频繁降MSS重传，吞吐量自然上不去。

5.2 UDP场景下的坑

现象一：UDP发送没有报错，但对端就是收不到。排查第一步永远是确认对端的socket有没有绑定正确的端口和IP，以及防火墙有没有拦截UDP流量。第二步是抓包，看发送端出去的包是否真的达到了对端主机。很多UDP“丢包”其实是防火墙规则挡掉的，不是网络丢的。第三步才是怀疑真正的丢包，比如发送速率超过链路带宽导致中间设备主动丢弃。

现象二：UDP接收端出现“unknown error code=10054”（Windows环境常见）。这个错误其实是ICMP端口不可达消息导致的，说明对端根本没在监听你发过去的UDP端口，或者通信过程中对端进程退出了。排查办法是对端确认UDP服务是否还在跑，以及检查接收缓冲是否溢出。这个错误的本质是ICMP反馈，但UDP本身是不保证反馈的，所以它更像一个附带情报。

现象三：UDP缓冲区溢出导致大量丢包，应用层无感知。这是一个特别隐蔽的问题。UDP的接收端如果处理速度跟不上数据到达速度，数据会在内核接收队列里排队。队列满了之后，新到的UDP报文会被内核直接丢弃，应用层完全不知道。TCP在这种情况下会通过流量控制让发送端减速，UDP没有这种机制，所以只能在应用层努力——加大缓冲区：

sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.rmem_default=26214400

同时让接收线程尽快把数据从内核队列里读走。如果还不行，就得考虑在应用层做丢包统计和反馈机制，让发送端降速。

5.3 选型建议：别再背“TCP可靠、UDP不可靠”的口诀了

聊了这么多，最后聊选型。我自己的判断框架是，从这几个维度看业务需求：

对应到具体场景：文件同步、消息推送、数据库复制，选TCP；音视频通话、游戏位置同步、实时控制指令，选UDP；如果你既要可靠又要低时延，可以选QUIC或者自己实现RUDP，而不是硬扛TCP或裸UDP。

物联网领域还有个常见的组合模式——控制指令走TCP，数据上报走UDP。控制指令数量少、对可靠性要求高，TCP的重传机制能确保指令送达；传感器数据量大、时效性强、允许少量丢点，UDP的高效透传正合适。

这篇文章里我没有想说服你放弃TCP或者拥抱UDP，我只想拆掉那句话——“TCP可靠、UDP不可靠”本身就是一个简化到失真，甚至有点误导的“hoax”。可靠从来不是协议单方面承诺的，而是网络环境、协议机制、应用层设计三者共同作用的结果。TCP给了你一套现成的可靠框架，也把连接状态、排队延迟、队头阻塞这些负担一并给了你；UDP把可靠性还给了你，也把设计空间和全部责任同时交给你。

我个人这几年的体感是：遇到传输问题，最不应该做的就是拿这句话出来贴标签。先看数据，再看丢包，再抓包分析，最后根据业务要什么，选择TCP、选择UDP加自己造轮子，或者选择直接在UDP上跑QUIC。真正的可靠，是在理解了“可靠有条件、可靠有代价”之后，还能为业务选对协议、设计对机制的工程能力。