做网络传输排查这几年有一个知识点虽然人人都能背两句但真正遇到线上问题时能把“UDP与TCP的发送接收流程差异”讲清楚、用明白的人并不多。前阵子一位同行负责某跨平台系统用UDP推流本地联调一切正常一上生产环境丢包率直奔20%查了半天发现他根本没意识到UDP发送成功和对方真正收到完全是两码事。本文就把这两条链路从头到尾拆开应用层调用、内核缓冲、协议封装、对端接收逐一对比再给你可复现的实验脚本和排障思路。适合刚接触网络编程的初学者也适合正在被粘包、丢包、延迟抖动折磨的服务端开发者。1. 先搞清楚两兄弟的设计哲学可靠连接与尽力而为1.1 生活化类比一个打电话一个寄明信片TCP和UDP的差异用生活里的例子来理解最直接。TCP像打电话先拨号、对方接起、双方确认“能听到吗”然后开始说话你说完一句对方“嗯”一声确保收到说到一半断线了系统会自动重拨或者告诉你链路断了不会让一句关键话凭空消失。整个过程有状态、有顺序、有确认。UDP像寄明信片你把写好内容的明信片丢进邮筒写对地址就行不需要提前和收件人打招呼邮递员怎么走、什么时候到、会不会丢在路上你基本管不着。对方可能一口气收到三张也可能少了一张甚至顺序是乱的。这个类比能解释80%的行为差异剩余20%藏在细节里TCP并不是不丢数据它只是不让你感知到丢数据——通过重传和排序把“丢了”这件事在协议内部消化掉。而UDP是真的不负责丢就丢了应用层想补救得自己来。1.2 协议头对比20字节和8字节的“硬成本”协议头是每一次传输都要额外付出的成本。TCP最小头部20字节UDP固定8字节差距12字节。别小看这12个字节在一个每秒收发百万包的场景里这就是实打实的带宽和CPU开销。TCP头部里塞了源端口、目的端口、序号、确认号、数据偏移、标志位、窗口大小、校验和、紧急指针。序号和确认号是可靠传输的“账本”窗口大小是流控的“阀门”标志位控制连接的管理。每一项都是为了让数据有序、不丢、不重复。UDP头部只有四个字段源端口、目的端口、长度、校验和。没有序号、没有确认号、没有窗口也没有任何标志位。IPv4下校验和甚至是可选的IPv6下强制要求因为设计者认为这种尽力而为的服务不值得为校验花费太多成本。一个极端场景TCP头的20个字节里哪怕只是多加一个时间戳选项头部可能膨胀到32字节而UDP无论怎么折腾头永远是8字节。对要求低延迟、高吞吐的实时音视频场景UDP在包效率上的优势是实打实的。1.3 状态管理TCP从出生到死亡都在记账TCP连接是一个完整的状态机CLOSED、LISTEN、SYN_SENT、SYN_RECEIVED、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、TIME_WAIT……光是状态就十几个。三次握手建立连接、四次挥手断开连接每个状态转换都对应特定的报文。这套机制换来的是“我知道对方一定收到了我的数据”的确定性。发送方维护发送缓冲和已发送未确认的字节范围接收方维护接收缓冲和期望的下一个序号。任何一方都能通过序号精确算出“缺了哪一段”。UDP没有任何状态机。一个UDP服务端在调用recvfrom之前不需要知道谁会发消息给它一个UDP客户端在sendto之后也不需要维护任何关于对端的信息。内核里唯一的“状态”就是socket本身绑定了一个端口以及一个接收队列。做个不严谨但很形象的对比TCP在通信双方之间建立了一条“虚拟管道”数据像水一样从一端流进、另一端流出顺序和完整性由管道保证UDP则是每份数据报都是一封独立的信邮局不保证信件到达顺序也不保证不丢失。2. 发送流程拆解从应用层到网卡的完整旅程2.1 应用层入口send和sendto的调用语义差异先看两个函数。TCP用send/writeUDP用sendto当然TCP也能用sendto但语义不同。调用send时你只需要传入socket和缓冲区数据因为连接已经建立内核知道要把数据往哪条链路上送。整个发送过程是“字节流式”的内核不关心你这次调用传了多少字节、上次传了多少字节它只关心“还有多少字节没发”然后尽可能打包发送。调用sendto时你必须额外传入目标地址和端口哪怕这个socket之前已经给同一个目标发过一万次。因为UDP没有连接内核根本记不住你上一次发给谁了。还有一个关键差异sendto一次调用对应一个完整的数据报这个数据报会以原子单元的方式进入发送路径不会和下一次调用的数据合并。这里有个容易被忽视的隐藏行为TCP的send成功返回只表示数据进了内核发送缓冲绝不表示对端已经收到甚至不表示已经发到网线上。UDP的sendto成功返回含义更弱只表示数据报被内核接收并放入发送队列如果队列没满、报文长度不超过限制基本都会“成功”至于半路是丢了还是被对端拒收发送方完全无感知。2.2 TCP发送缓冲Nagle算法、MSS与滑动窗口TCP发送过程可以简化为四步应用数据拷贝进发送缓冲、TCP按MSS切分成段、交给IP层封装、进入网卡发送队列。真正的精髓在发送缓冲这块。发送缓冲不是无限大的。Linux下默认值通常几十KB到几百KB不等具体可以用setsockopt的SO_SNDBUF查看和修改。当你调用send写入的数据超过发送缓冲剩余空间时在阻塞模式下调用会一直等待直到有空间腾出来在非阻塞模式下直接返回EAGAIN。切分数据时有一个关键参数MSS即最大报文段长度。以太网MTU是1500字节减去IP头20字节、TCP头20字节TCP payload上限就是1460字节。如果你的send一次传入5000字节TCP会先切成四段左右逐段发出而不是拼成一个5000字节的IP包。这也是TCP天然回避IP分片的原因它在TCP层就把大块数据切成适合链路的小段。滑动窗口则负责“限速”。接收方通过TCP头里的窗口字段告诉发送方“我还能收多少字节”发送方严格按这个数值控制未确认数据量。窗口为0时发送方会停止发送数据只发送零窗口探测包直到对方通告窗口恢复。这个机制就是TCP的流控——它保证发送速度永远适配接收方的处理能力。2.3 UDP发送流程一次一个报文没有流控UDP的发送路径简单得多sendto把应用层缓冲区的内容直接封装成UDP报文加上8字节头交给IP层然后从网卡发出去。没有分段、没有确认、没有滑动窗口、没有重传。这意味着三个后果。第一应用层每次sendto的数据报大小直接影响网络行为小于MSS的报文以单包发送大于MSS的报文可能触发IP分片。第二发送缓冲的存在感比TCP弱很多因为UDP不会把多个数据报合并发送每个报文独立入队。第三没有任何机制根据接收方的处理能力来调整发送速度发送方永远“油门踩到底”。UDP发送缓冲区溢出是什么表现大量数据瞬间灌入发送队列来不及清空新的数据报会被直接丢弃sendto可能返回EAGAIN非阻塞模式或者在内核缓冲区里直接丢包。这和TCP的“窗口为0时停下来等待”是本质区别TCP丢的是时间UDP丢的是数据。2.4 发送流程差异对照表对比维度TCPUDP连接前提需要三次握手建立连接无连接直接发送应用层接口send无需每次指定目标sendto必须每次指定目标数据边界字节流无边界数据报保留边界发送缓冲缓冲未确认数据窗口控制流量缓冲待发送报文不进行流控数据切分按MSS切成多个TCP段超MTU时在IP层分片可靠机制序号、确认、重传、乱序重组无发送即不管缓冲满时阻塞等待或返回EAGAIN但不丢数据丢弃新报文数据报丢失发送成功的含义数据进入发送缓冲数据报进入发送队列不保证送达3. 接收流程拆解内核如何把数据交给进程3.1 通用接收路径从网卡中断到socket队列无论是TCP还是UDP数据接收路径的前半段是共通的。网卡收到数据后通过DMA把数据放进内存中的环形缓冲然后触发硬中断唤醒CPU处理。Linux的NAPI机制会把后续中断合并成软中断轮询避免高流量下CPU被中断风暴击穿。软中断处理阶段内核执行协议栈数据链路层校验帧IP层校验地址和分片重组然后根据四元组找到对应的socket把数据放入该socket的接收缓冲区。最后应用进程被唤醒调用recv/recvfrom/read从缓冲区里取走数据。这段通用路径有一个共同点无论TCP还是UDP如果应用进程不及时调用接收接口取走数据数据都会堆积在内核的socket接收队列里。区别只是队列满之后的应对策略完全不同。3.2 TCP接收端排序、确认、按字节流重组TCP接收端要处理三件事校验、排序、确认。收到一个TCP段后内核先检查序号。如果这个段的序号正好是接收方期望的下一个序号就把它放入接收缓冲的可读区域并向前推进期望序号。如果序号比期望的高说明中间缺了一段这个段会被放进乱序队列等待。缺失的数据不确认发送方超时后会自动重传。所有乱序段凑齐后内核把它们按序号拼接成完整的字节流应用层用read/recv读到的就是连贯的字节数据。这里要注意应用层无法感知“刚才有数据乱序了”因为重传和排序都发生在协议栈内部。接收缓冲满时TCP的处理方式是“不确认”。接收方在TCP头的窗口字段中通告一个更小的窗口值甚至通告窗口0发送方接到通告后会立即停止发送无关数据。这就像水库开闸放水到下游下游水库满了就关小闸门但水不会凭空消失只是暂时蓄在上游。TCP用这种方式保证数据不因为接收方处理不及时而丢失。3.3 UDP接收端不排序、不确认、队列满直接丢UDP接收路径是一个“端到端”的简单判定收到一个完整报文校验和通过找到目标socket放入接收队列完事。没有乱序重排没有确认机制也没有任何流量控制。如果接收队列满了怎么办默认情况下新到的报文被直接丢弃老的报文继续留在队列里等应用读取。对实时音视频场景来说这种策略是合理的音频数据晚到几百毫秒就毫无意义了丢旧保新反而能维持体验。由于没有确认和重传UDP的端到端延迟往往更稳定代价则是可靠性完全依赖应用层。如果你用UDP传一个文件中间丢一个包接收方甚至不会告诉你丢了你只能通过自己设计的应用层协议比如给每个数据报加序号来发现缺失然后启动重传流程。3.4 recv与recvfrom的语义差异接收接口的差异同样根植于协议本质。TCP的recv返回的是字节流的读结果。你req一个100字节的缓冲区内核可能只返回50字节因为字节流没有边界本次读到的只是“当前缓冲里的一段”。你必须自己处理数据拼装直到拼出一个完整的业务消息。这就是“粘包/半包”问题的来源。UDP的recvfrom每次返回一个完整的数据报。你用一个65507字节的缓冲区去收最多只可能收到一个报文的数据如果你提供的缓冲区比报文还小多余的数据会被直接截断丢掉Linux下recvfrom返回MSGD_TRUNC标记。这种“一次一个报文”的语义让UDP应用层的代码往往更简单——不需要处理消息边界。接收行为TCPUDP数据单元字节流数据报recv返回当前缓冲里任意长度的字节一个完整报文乱序处理内核重排后交付干什么样是什么样缺丢失包重传补齐直接缺失应用层感知缓冲满策略窗口压制发送方丢弃新报文额外信息无recvfrom可获来源地址和端口4. 实操环节用回射服务验证两种行为4.1 实验环境与项目设定为了直观验证差异我用一个模拟项目X做了回射服务实验。所谓回射服务就是收到什么回什么TCP接到的字节流原样写回UDP收到的数据报原样发给来源地址。这种模型能最快暴露两种协议在“一条消息”和“一段字节流”上的行为差异。实验环境是两台内网虚拟机器一台作为服务端一台作为客户端操作系统LinuxPython版本3.x。先不做任何调优用默认内核参数观察基础行为。4.2 TCP回射服务与客户端字节流切断与粘连TCP服务端核心逻辑用Python表示import socket server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((0.0.0.0, 9000)) server.listen(5) conn, addr server.accept() while True: data conn.recv(1024) if not data: # 对端关闭连接读到空数据 break conn.sendall(data) # 原样回射 conn.close()客户端发送100个长度为20字节的消息服务端回射后客户端这边很可能无法从recv结果中区分哪20字节属于哪条原始消息。因为TCP把100条消息的2000字节做成了一整条“水流”你只能按自己定的规约去切。我在实验里故意把recv缓冲设为2048一次性读走全部数据粘包现象一目了然收到的数据是连续的2000字节根本看不出原边界。这里最容易踩的坑是用sendall发送消息以为对端recv一次就收到同一条消息。事实是对端可能一次recv收到半条也可能收到一条半也可能一次收完两条完全取决于TCP段边界和调度时序。4.3 UDP回射服务与客户端一次报文对应一次回复UDP服务端核心逻辑import socket server socket.socket(socket.AF_INET, socket.SOCK_DGRAM) server.bind((0.0.0.0, 9001)) while True: data, addr server.recvfrom(65535) server.sendto(data, addr) # 原样回射给来源客户端每次sendto一条20字节的消息然后调用recvfrom读取回复。这里必须用同一对sendto/recvfrom函数因为每次都要携带目标地址。实验下来最直观的证据是客户端发送20条消息recvfrom会完整收到20次20字节的报文不会出现“一次收到两条消息”的情况。数据报边界从应用层一路保持到对端应用层这是UDP最典型的特征。另外一个值得实验的现象客户端给服务端发了一条1字节的消息服务端如果直接调用recvfrom的缓冲区是1024字节那么收到的data长度就是1字节。UDP不会“摊薄”你的报文去填充缓冲区收多少是多少。4.4 用抓包验证三次握手与单包交互接收流程的实验还需要抓包配合。我在服务端跑起tcpdump命令大意是tcpdump -i eth0 tcp port 9000能看到三次握手的三个包SYN、SYNACK、ACK。连接建立后每次sendall都可能对应一个或几个TCP数据段而且对端回射的ACK包会紧跟着数据段出现。如果一个段丢失还会看到重传包TCP头里的Seq和Ack值会发生变化这就是协议栈“记账”的直接证据。UDP抓包则清爽得多tcpdump -i eth0 udp port 9001客户端每次sendto对应一个独立的UDP包包长度固定等于数据长度加8字节头部没有三次握手没有ACK没有重传。我在抓包里数了100次交互的包数量正好200个包100个请求加100个回复完全一一对应。TCP在同样场景下很可能超过200个包因为多出握手和ACK的开销。5. 常见问题与排查技巧实录5.1 TCP粘包/半包问题流边界不是业务边界这是TCP开发里出现率最高的问题。症状很简单客户端明明send了一条完整的JSON消息服务端recv到的内容却“多了半个JSON”或者“少了半个JSON”。原因在TCP的字节流语义里。你发的是两条消息内核只把它们当成一串字节对端recv时能读到的长度完全取决于缓冲区和调度跟你的业务消息没有对应关系。解决方案不是改协议栈而是在应用层引入消息边界。最常用的三种方案固定长度、分隔符、长度前缀。我建议优先用长度前缀即每条消息前面加4字节表示长度的整型。收端先读4字节得到长度再循环读取直到凑满该长度。这个方法对二进制和文本都通用而且解析开销小。另一个常用技巧是修改TCP发送行为通过设置TCP_NODELAY关闭Nagle算法避免小包攒着不发导致延迟飙升。但注意这只是解决“延迟”问题不解决“边界”问题别混为一谈。5.2 UDP接收缓冲溢出丢包率飙升怎么查UDP偶发抖动还能接受但如果你发现丢包率长期在1%以上先去查接收端。最典型的坑是应用层进程处理太慢内核接收队列常年堆满新报文被直接丢掉。这种丢包和网络链路没关系是应用侧的瓶颈在“弃旧保新”。排查办法先看UDP收包统计。netstat -su里面如果有大量RcvbufErrors或者丢包计数基本可以判断是接收队列溢出。接下来两件事一是加大socket接收缓冲区int size 4 * 1024 * 1024; setsockopt(fd, SOL_SOCKET, SO_RCVBUF, size, sizeof(size));二是优化应用处理逻辑把“收包”和“处理”解耦收包线程只负责把报文丢进业务队列多个业务线程处理避免收包被慢逻辑卡住。如果应用已经很快还是丢包再考虑链路层问题比如交换机缓存不足或网卡硬件队列丢包。此时去看网卡统计ethtool -S eth0重点看rx_dropped字段如果这个数字在增长说明问题出在内核协议栈入口之前不是socket层的锅。5.3 同一个服务为什么UDP延迟波动更大做过对比实验的人会发现同一链路上UDP报文的端到端延迟往往比TCP更稳定但更高级的统计里UDP“延迟波动”jitter有时反而更大。原因在于UDP没有重传机制丢包直接影响这一帧的到达而TCP丢包后重传应用层看到的是“晚到但完整的数据”延迟曲线会有一个尖刺但不会出现“数据消失”。另一个UDP延迟波动的来源是IP分片。一个超过路径MTU的UDP报文被分成几个IP分片任何一个分片丢失整个报文都会被丢弃。我在模拟项目X里做过实验发1400字节的UDP包延迟平稳发1600字节的包偶尔出现整包丢失表现为应用层“延迟”骤增。排查方式很简单检查所有UDP报文是否都小于路径MTU一般业务上建议限制在1400字节以下给IP头和UDP头留足空间也为中间链路可能更小的MTU留余量。5.4 选型速查与避坑清单需求推荐协议理由文件传输、数据库同步TCP需要可靠有序重传成本划算实时音视频、游戏状态UDP可接受少量丢包延迟优先服务发现、DNS、DHCPUDP一问一答连接管理得不偿失海量小消息广播/组播UDPTCP不支持一对多弱网环境复杂业务UDP应用层可靠协议可控的重传策略比TCP默认行为更优最后整理几条我踩过的坑不要用UDP发送超过路径MTU的大报文。一但触发IP分片丢包概率成倍上升而且定位极难。业务层做好分包限制每个UDP载荷不超过1400字节。不要把TCP的send成功当成发送成功。它只代表数据进了内核缓冲。如果你需要知道对端真正收到必须在应用层设计一个ACK消息或者依赖对端的业务回包。不要一遇到UDP丢包就怀疑网络。优先检查接收队列溢出和应用处理速度这两处问题最容易被“优化网络”的思维带偏。不要试图让UDP变得“像TCP一样可靠”。如果你的需求是严格有序、绝不丢失直接用TCP应用层加上重传、序号、滑动窗口复杂度极高出错概率远超直接使用TCP。我在实际使用中形成了一个原则先问自己一句“如果对方收不到这条消息会发生什么”。收不到也没事选UDP收不到会出大问题选TCP介于两者之间就用UDP加应用层确认和超时重传把可靠性掌握在自己手里。理解发送接收流程的差异之后做这个判断题就会很有底气。 
长河君 · 2026/10/16 10:13:32 · 阅读 1.2k TCP与UDP发送接收流程差异详解：从应用到内核
做网络传输排查这几年有一个知识点虽然人人都能背两句但真正遇到线上问题时能把“UDP与TCP的发送接收流程差异”讲清楚、用明白的人并不多。前阵子一位同行负责某跨平台系统用UDP推流本地联调一切正常一上生产环境丢包率直奔20%查了半天发现他根本没意识到UDP发送成功和对方真正收到完全是两码事。本文就把这两条链路从头到尾拆开应用层调用、内核缓冲、协议封装、对端接收逐一对比再给你可复现的实验脚本和排障思路。适合刚接触网络编程的初学者也适合正在被粘包、丢包、延迟抖动折磨的服务端开发者。1. 先搞清楚两兄弟的设计哲学可靠连接与尽力而为1.1 生活化类比一个打电话一个寄明信片TCP和UDP的差异用生活里的例子来理解最直接。TCP像打电话先拨号、对方接起、双方确认“能听到吗”然后开始说话你说完一句对方“嗯”一声确保收到说到一半断线了系统会自动重拨或者告诉你链路断了不会让一句关键话凭空消失。整个过程有状态、有顺序、有确认。UDP像寄明信片你把写好内容的明信片丢进邮筒写对地址就行不需要提前和收件人打招呼邮递员怎么走、什么时候到、会不会丢在路上你基本管不着。对方可能一口气收到三张也可能少了一张甚至顺序是乱的。这个类比能解释80%的行为差异剩余20%藏在细节里TCP并不是不丢数据它只是不让你感知到丢数据——通过重传和排序把“丢了”这件事在协议内部消化掉。而UDP是真的不负责丢就丢了应用层想补救得自己来。1.2 协议头对比20字节和8字节的“硬成本”协议头是每一次传输都要额外付出的成本。TCP最小头部20字节UDP固定8字节差距12字节。别小看这12个字节在一个每秒收发百万包的场景里这就是实打实的带宽和CPU开销。TCP头部里塞了源端口、目的端口、序号、确认号、数据偏移、标志位、窗口大小、校验和、紧急指针。序号和确认号是可靠传输的“账本”窗口大小是流控的“阀门”标志位控制连接的管理。每一项都是为了让数据有序、不丢、不重复。UDP头部只有四个字段源端口、目的端口、长度、校验和。没有序号、没有确认号、没有窗口也没有任何标志位。IPv4下校验和甚至是可选的IPv6下强制要求因为设计者认为这种尽力而为的服务不值得为校验花费太多成本。一个极端场景TCP头的20个字节里哪怕只是多加一个时间戳选项头部可能膨胀到32字节而UDP无论怎么折腾头永远是8字节。对要求低延迟、高吞吐的实时音视频场景UDP在包效率上的优势是实打实的。1.3 状态管理TCP从出生到死亡都在记账TCP连接是一个完整的状态机CLOSED、LISTEN、SYN_SENT、SYN_RECEIVED、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、TIME_WAIT……光是状态就十几个。三次握手建立连接、四次挥手断开连接每个状态转换都对应特定的报文。这套机制换来的是“我知道对方一定收到了我的数据”的确定性。发送方维护发送缓冲和已发送未确认的字节范围接收方维护接收缓冲和期望的下一个序号。任何一方都能通过序号精确算出“缺了哪一段”。UDP没有任何状态机。一个UDP服务端在调用recvfrom之前不需要知道谁会发消息给它一个UDP客户端在sendto之后也不需要维护任何关于对端的信息。内核里唯一的“状态”就是socket本身绑定了一个端口以及一个接收队列。做个不严谨但很形象的对比TCP在通信双方之间建立了一条“虚拟管道”数据像水一样从一端流进、另一端流出顺序和完整性由管道保证UDP则是每份数据报都是一封独立的信邮局不保证信件到达顺序也不保证不丢失。2. 发送流程拆解从应用层到网卡的完整旅程2.1 应用层入口send和sendto的调用语义差异先看两个函数。TCP用send/writeUDP用sendto当然TCP也能用sendto但语义不同。调用send时你只需要传入socket和缓冲区数据因为连接已经建立内核知道要把数据往哪条链路上送。整个发送过程是“字节流式”的内核不关心你这次调用传了多少字节、上次传了多少字节它只关心“还有多少字节没发”然后尽可能打包发送。调用sendto时你必须额外传入目标地址和端口哪怕这个socket之前已经给同一个目标发过一万次。因为UDP没有连接内核根本记不住你上一次发给谁了。还有一个关键差异sendto一次调用对应一个完整的数据报这个数据报会以原子单元的方式进入发送路径不会和下一次调用的数据合并。这里有个容易被忽视的隐藏行为TCP的send成功返回只表示数据进了内核发送缓冲绝不表示对端已经收到甚至不表示已经发到网线上。UDP的sendto成功返回含义更弱只表示数据报被内核接收并放入发送队列如果队列没满、报文长度不超过限制基本都会“成功”至于半路是丢了还是被对端拒收发送方完全无感知。2.2 TCP发送缓冲Nagle算法、MSS与滑动窗口TCP发送过程可以简化为四步应用数据拷贝进发送缓冲、TCP按MSS切分成段、交给IP层封装、进入网卡发送队列。真正的精髓在发送缓冲这块。发送缓冲不是无限大的。Linux下默认值通常几十KB到几百KB不等具体可以用setsockopt的SO_SNDBUF查看和修改。当你调用send写入的数据超过发送缓冲剩余空间时在阻塞模式下调用会一直等待直到有空间腾出来在非阻塞模式下直接返回EAGAIN。切分数据时有一个关键参数MSS即最大报文段长度。以太网MTU是1500字节减去IP头20字节、TCP头20字节TCP payload上限就是1460字节。如果你的send一次传入5000字节TCP会先切成四段左右逐段发出而不是拼成一个5000字节的IP包。这也是TCP天然回避IP分片的原因它在TCP层就把大块数据切成适合链路的小段。滑动窗口则负责“限速”。接收方通过TCP头里的窗口字段告诉发送方“我还能收多少字节”发送方严格按这个数值控制未确认数据量。窗口为0时发送方会停止发送数据只发送零窗口探测包直到对方通告窗口恢复。这个机制就是TCP的流控——它保证发送速度永远适配接收方的处理能力。2.3 UDP发送流程一次一个报文没有流控UDP的发送路径简单得多sendto把应用层缓冲区的内容直接封装成UDP报文加上8字节头交给IP层然后从网卡发出去。没有分段、没有确认、没有滑动窗口、没有重传。这意味着三个后果。第一应用层每次sendto的数据报大小直接影响网络行为小于MSS的报文以单包发送大于MSS的报文可能触发IP分片。第二发送缓冲的存在感比TCP弱很多因为UDP不会把多个数据报合并发送每个报文独立入队。第三没有任何机制根据接收方的处理能力来调整发送速度发送方永远“油门踩到底”。UDP发送缓冲区溢出是什么表现大量数据瞬间灌入发送队列来不及清空新的数据报会被直接丢弃sendto可能返回EAGAIN非阻塞模式或者在内核缓冲区里直接丢包。这和TCP的“窗口为0时停下来等待”是本质区别TCP丢的是时间UDP丢的是数据。2.4 发送流程差异对照表对比维度TCPUDP连接前提需要三次握手建立连接无连接直接发送应用层接口send无需每次指定目标sendto必须每次指定目标数据边界字节流无边界数据报保留边界发送缓冲缓冲未确认数据窗口控制流量缓冲待发送报文不进行流控数据切分按MSS切成多个TCP段超MTU时在IP层分片可靠机制序号、确认、重传、乱序重组无发送即不管缓冲满时阻塞等待或返回EAGAIN但不丢数据丢弃新报文数据报丢失发送成功的含义数据进入发送缓冲数据报进入发送队列不保证送达3. 接收流程拆解内核如何把数据交给进程3.1 通用接收路径从网卡中断到socket队列无论是TCP还是UDP数据接收路径的前半段是共通的。网卡收到数据后通过DMA把数据放进内存中的环形缓冲然后触发硬中断唤醒CPU处理。Linux的NAPI机制会把后续中断合并成软中断轮询避免高流量下CPU被中断风暴击穿。软中断处理阶段内核执行协议栈数据链路层校验帧IP层校验地址和分片重组然后根据四元组找到对应的socket把数据放入该socket的接收缓冲区。最后应用进程被唤醒调用recv/recvfrom/read从缓冲区里取走数据。这段通用路径有一个共同点无论TCP还是UDP如果应用进程不及时调用接收接口取走数据数据都会堆积在内核的socket接收队列里。区别只是队列满之后的应对策略完全不同。3.2 TCP接收端排序、确认、按字节流重组TCP接收端要处理三件事校验、排序、确认。收到一个TCP段后内核先检查序号。如果这个段的序号正好是接收方期望的下一个序号就把它放入接收缓冲的可读区域并向前推进期望序号。如果序号比期望的高说明中间缺了一段这个段会被放进乱序队列等待。缺失的数据不确认发送方超时后会自动重传。所有乱序段凑齐后内核把它们按序号拼接成完整的字节流应用层用read/recv读到的就是连贯的字节数据。这里要注意应用层无法感知“刚才有数据乱序了”因为重传和排序都发生在协议栈内部。接收缓冲满时TCP的处理方式是“不确认”。接收方在TCP头的窗口字段中通告一个更小的窗口值甚至通告窗口0发送方接到通告后会立即停止发送无关数据。这就像水库开闸放水到下游下游水库满了就关小闸门但水不会凭空消失只是暂时蓄在上游。TCP用这种方式保证数据不因为接收方处理不及时而丢失。3.3 UDP接收端不排序、不确认、队列满直接丢UDP接收路径是一个“端到端”的简单判定收到一个完整报文校验和通过找到目标socket放入接收队列完事。没有乱序重排没有确认机制也没有任何流量控制。如果接收队列满了怎么办默认情况下新到的报文被直接丢弃老的报文继续留在队列里等应用读取。对实时音视频场景来说这种策略是合理的音频数据晚到几百毫秒就毫无意义了丢旧保新反而能维持体验。由于没有确认和重传UDP的端到端延迟往往更稳定代价则是可靠性完全依赖应用层。如果你用UDP传一个文件中间丢一个包接收方甚至不会告诉你丢了你只能通过自己设计的应用层协议比如给每个数据报加序号来发现缺失然后启动重传流程。3.4 recv与recvfrom的语义差异接收接口的差异同样根植于协议本质。TCP的recv返回的是字节流的读结果。你req一个100字节的缓冲区内核可能只返回50字节因为字节流没有边界本次读到的只是“当前缓冲里的一段”。你必须自己处理数据拼装直到拼出一个完整的业务消息。这就是“粘包/半包”问题的来源。UDP的recvfrom每次返回一个完整的数据报。你用一个65507字节的缓冲区去收最多只可能收到一个报文的数据如果你提供的缓冲区比报文还小多余的数据会被直接截断丢掉Linux下recvfrom返回MSGD_TRUNC标记。这种“一次一个报文”的语义让UDP应用层的代码往往更简单——不需要处理消息边界。接收行为TCPUDP数据单元字节流数据报recv返回当前缓冲里任意长度的字节一个完整报文乱序处理内核重排后交付干什么样是什么样缺丢失包重传补齐直接缺失应用层感知缓冲满策略窗口压制发送方丢弃新报文额外信息无recvfrom可获来源地址和端口4. 实操环节用回射服务验证两种行为4.1 实验环境与项目设定为了直观验证差异我用一个模拟项目X做了回射服务实验。所谓回射服务就是收到什么回什么TCP接到的字节流原样写回UDP收到的数据报原样发给来源地址。这种模型能最快暴露两种协议在“一条消息”和“一段字节流”上的行为差异。实验环境是两台内网虚拟机器一台作为服务端一台作为客户端操作系统LinuxPython版本3.x。先不做任何调优用默认内核参数观察基础行为。4.2 TCP回射服务与客户端字节流切断与粘连TCP服务端核心逻辑用Python表示import socket server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((0.0.0.0, 9000)) server.listen(5) conn, addr server.accept() while True: data conn.recv(1024) if not data: # 对端关闭连接读到空数据 break conn.sendall(data) # 原样回射 conn.close()客户端发送100个长度为20字节的消息服务端回射后客户端这边很可能无法从recv结果中区分哪20字节属于哪条原始消息。因为TCP把100条消息的2000字节做成了一整条“水流”你只能按自己定的规约去切。我在实验里故意把recv缓冲设为2048一次性读走全部数据粘包现象一目了然收到的数据是连续的2000字节根本看不出原边界。这里最容易踩的坑是用sendall发送消息以为对端recv一次就收到同一条消息。事实是对端可能一次recv收到半条也可能收到一条半也可能一次收完两条完全取决于TCP段边界和调度时序。4.3 UDP回射服务与客户端一次报文对应一次回复UDP服务端核心逻辑import socket server socket.socket(socket.AF_INET, socket.SOCK_DGRAM) server.bind((0.0.0.0, 9001)) while True: data, addr server.recvfrom(65535) server.sendto(data, addr) # 原样回射给来源客户端每次sendto一条20字节的消息然后调用recvfrom读取回复。这里必须用同一对sendto/recvfrom函数因为每次都要携带目标地址。实验下来最直观的证据是客户端发送20条消息recvfrom会完整收到20次20字节的报文不会出现“一次收到两条消息”的情况。数据报边界从应用层一路保持到对端应用层这是UDP最典型的特征。另外一个值得实验的现象客户端给服务端发了一条1字节的消息服务端如果直接调用recvfrom的缓冲区是1024字节那么收到的data长度就是1字节。UDP不会“摊薄”你的报文去填充缓冲区收多少是多少。4.4 用抓包验证三次握手与单包交互接收流程的实验还需要抓包配合。我在服务端跑起tcpdump命令大意是tcpdump -i eth0 tcp port 9000能看到三次握手的三个包SYN、SYNACK、ACK。连接建立后每次sendall都可能对应一个或几个TCP数据段而且对端回射的ACK包会紧跟着数据段出现。如果一个段丢失还会看到重传包TCP头里的Seq和Ack值会发生变化这就是协议栈“记账”的直接证据。UDP抓包则清爽得多tcpdump -i eth0 udp port 9001客户端每次sendto对应一个独立的UDP包包长度固定等于数据长度加8字节头部没有三次握手没有ACK没有重传。我在抓包里数了100次交互的包数量正好200个包100个请求加100个回复完全一一对应。TCP在同样场景下很可能超过200个包因为多出握手和ACK的开销。5. 常见问题与排查技巧实录5.1 TCP粘包/半包问题流边界不是业务边界这是TCP开发里出现率最高的问题。症状很简单客户端明明send了一条完整的JSON消息服务端recv到的内容却“多了半个JSON”或者“少了半个JSON”。原因在TCP的字节流语义里。你发的是两条消息内核只把它们当成一串字节对端recv时能读到的长度完全取决于缓冲区和调度跟你的业务消息没有对应关系。解决方案不是改协议栈而是在应用层引入消息边界。最常用的三种方案固定长度、分隔符、长度前缀。我建议优先用长度前缀即每条消息前面加4字节表示长度的整型。收端先读4字节得到长度再循环读取直到凑满该长度。这个方法对二进制和文本都通用而且解析开销小。另一个常用技巧是修改TCP发送行为通过设置TCP_NODELAY关闭Nagle算法避免小包攒着不发导致延迟飙升。但注意这只是解决“延迟”问题不解决“边界”问题别混为一谈。5.2 UDP接收缓冲溢出丢包率飙升怎么查UDP偶发抖动还能接受但如果你发现丢包率长期在1%以上先去查接收端。最典型的坑是应用层进程处理太慢内核接收队列常年堆满新报文被直接丢掉。这种丢包和网络链路没关系是应用侧的瓶颈在“弃旧保新”。排查办法先看UDP收包统计。netstat -su里面如果有大量RcvbufErrors或者丢包计数基本可以判断是接收队列溢出。接下来两件事一是加大socket接收缓冲区int size 4 * 1024 * 1024; setsockopt(fd, SOL_SOCKET, SO_RCVBUF, size, sizeof(size));二是优化应用处理逻辑把“收包”和“处理”解耦收包线程只负责把报文丢进业务队列多个业务线程处理避免收包被慢逻辑卡住。如果应用已经很快还是丢包再考虑链路层问题比如交换机缓存不足或网卡硬件队列丢包。此时去看网卡统计ethtool -S eth0重点看rx_dropped字段如果这个数字在增长说明问题出在内核协议栈入口之前不是socket层的锅。5.3 同一个服务为什么UDP延迟波动更大做过对比实验的人会发现同一链路上UDP报文的端到端延迟往往比TCP更稳定但更高级的统计里UDP“延迟波动”jitter有时反而更大。原因在于UDP没有重传机制丢包直接影响这一帧的到达而TCP丢包后重传应用层看到的是“晚到但完整的数据”延迟曲线会有一个尖刺但不会出现“数据消失”。另一个UDP延迟波动的来源是IP分片。一个超过路径MTU的UDP报文被分成几个IP分片任何一个分片丢失整个报文都会被丢弃。我在模拟项目X里做过实验发1400字节的UDP包延迟平稳发1600字节的包偶尔出现整包丢失表现为应用层“延迟”骤增。排查方式很简单检查所有UDP报文是否都小于路径MTU一般业务上建议限制在1400字节以下给IP头和UDP头留足空间也为中间链路可能更小的MTU留余量。5.4 选型速查与避坑清单需求推荐协议理由文件传输、数据库同步TCP需要可靠有序重传成本划算实时音视频、游戏状态UDP可接受少量丢包延迟优先服务发现、DNS、DHCPUDP一问一答连接管理得不偿失海量小消息广播/组播UDPTCP不支持一对多弱网环境复杂业务UDP应用层可靠协议可控的重传策略比TCP默认行为更优最后整理几条我踩过的坑不要用UDP发送超过路径MTU的大报文。一但触发IP分片丢包概率成倍上升而且定位极难。业务层做好分包限制每个UDP载荷不超过1400字节。不要把TCP的send成功当成发送成功。它只代表数据进了内核缓冲。如果你需要知道对端真正收到必须在应用层设计一个ACK消息或者依赖对端的业务回包。不要一遇到UDP丢包就怀疑网络。优先检查接收队列溢出和应用处理速度这两处问题最容易被“优化网络”的思维带偏。不要试图让UDP变得“像TCP一样可靠”。如果你的需求是严格有序、绝不丢失直接用TCP应用层加上重传、序号、滑动窗口复杂度极高出错概率远超直接使用TCP。我在实际使用中形成了一个原则先问自己一句“如果对方收不到这条消息会发生什么”。收不到也没事选UDP收不到会出大问题选TCP介于两者之间就用UDP加应用层确认和超时重传把可靠性掌握在自己手里。理解发送接收流程的差异之后做这个判断题就会很有底气。