TCP与UDP如何选？一文讲透连接、可靠性与性能差异

搞网络排查或者写通信代码的朋友，迟早都会面对同一个问题：TCP 和 UDP 到底该怎么选？面试要背，选型要权衡，出了问题更要靠底层协议知识来定位。这篇文章我不打算给你念课本，而是从一个常年跟 socket、抓包、组网打交道的从业者角度，把 TCP 和 UDP 从连接机制、报文结构、可靠性控制、性能特征到真实场景里的选型逻辑一次讲透。无论你是刚接触 socket 编程的新手，还是被线上丢包、连接超时折腾过的老手，都能在这里找到能直接落地的判断依据。

先说结论：TCP 和 UDP 都跑在传输层，都是在 IP 之上解决“进程到进程”的通信问题，但它俩的哲学完全相反。TCP 是可靠、有序、面向连接，UDP 是尽力而为、无连接、低延迟。这个差异不是哪个更好，而是取舍路径不同。下面我从六个维度把这两兄弟扒开来看，最后再分享几个实测排查经验。

1. 先用一张表看透 TCP 与 UDP 的全貌差异

1.1 七个核心维度的速查对照

在深入细节之前，先给你一张可以直接抄进笔记里的对照表。这张表我按“连接管理、可靠性、传输模式、头部开销、速度特征、典型场景、排错特征”七个维度来组织，基本覆盖日常开发、面试、方案选型所有需要对比的关键点。

这表别看简单，实际定位问题时特别有用。比如用 Wireshark 抓到“TCP Retransmission”和抓到“ICMP port unreachable”的含义完全不同，前者说明 TCP 感知到了丢包正在重传，后者说明 UDP 发到了没人监听的端口，由网络栈代为通知。

1.2 理解差异的关键：两个网络模型视角

看 TCP/UDP 的区别，不能只停留在传输层这一个平面上。得结合两个模型来看：一个是从物理层到应用层的分层视角，懂分层才能定位问题出在哪一层；另一个是端到端视角，发数据的主机和收数据的主机之间发生了什么。

先看分层视角。理论上 OSI 七层模型被提到最多，但实际工作里大家更习惯用 TCP/IP 四层模型来思考：网络接口层、网络层、传输层、应用层。TCP 和 UDP 都工作在传输层，它们的下层是 IP 协议，负责把数据包从一台机器路由到另一台机器；它们的上层是各种应用协议，比如 HTTP、DNS、NTP。换句话说，IP 负责找到主机，TCP/UDP 负责在该主机上找到正确的进程（通过端口号），并决定数据以什么方式交付。

端到端视角更有意思。TCP 像两个人打电话，必须先拨号、对方接听、确认双方在线，才能开始说话；通话中任何一方没听清就得说“再说一遍”；挂断时也要互相确认。UDP 像往邮筒里丢明信片，写个收件地址就扔出去，明信片丢没丢、顺序乱没乱、对方收没收到，发件人一概不管。这也是为什么 TCP 可靠性高但开销大，UDP 轻快但不可依赖。

2. 连接的差异：三次握手与四次挥手背后到底在解决什么问题

2.1 TCP 为什么非要三次握手

TCP 的三次握手大家都会背：SYN、SYN-ACK、ACK。但很多人没想过一个问题：为什么两次不行，四次又多余？

三次握手的本质目的不是简单地“告诉对方我要连接”，而是要同步双方初始序号（ISN）。TCP 是字节流协议，每个字节都有序号，接收方靠序号把数据重组成正确的顺序，也要靠序号告诉发送方“我期望收到哪个字节”。这个序号不是从 1 开始的固定值，而是双方各自随机生成的一个 32 位数。如果只有两次握手，服务器发了自己的 ISN 给客户端后就认为连接建立了，但它不知道客户端有没有收到这个 ISN。万一客户端发的 SYN 在网络中延迟重传，或者旧连接的报文滞留后到达，就可能出现服务器被动建立起一个没有意义的连接，甚至和对端错位同步序号。

举一个实际踩过的坑：A 与 B 之间建立连接，A 发出带序号 100 的 SYN，这个包在网络中堵了很久。A 等不到回应，又发了一个带序号 200 的 SYN。B 如果只回一个 ACK 就建立连接，A 可能已经把 100 那个包当成遗留包丢弃了，双方对序号的认知就错位了。三次握手恰恰用一次 SYN-ACK 的往返，让双方都确认“我知道你知道了”，序号同步彻底打通。

注意一下，在实际排查中你会看到一个现象：SYN 洪水攻击频繁出现在安全日志里，原理就是用大量只发 SYN 不回 ACK 的半连接占满服务器的连接队列。这也是三次握手机制本身引入的风险点之一。

2.2 TCP 四次挥手与 TIME_WAIT 的深意

四次挥手的本质是双向关闭。TCP 连接是全双工的，数据可以同时在两个方向上流动。因此每一方都必须独立地关闭自己的发送通道：A 说“我这边没有数据发了”（FIN），B 回“知道了”（ACK）；之后 B 可能还有数据要发给 A，所以 B 再发完自己的数据后，也要说“我也没有数据发了”（FIN），A 再回“知道了”（ACK）。这才是四次。

这里真正值得关注的是 TIME_WAIT 状态。主动关闭连接的一方（通常是谁先调用 close 谁就是主动方）在收到对方的 FIN 并回应 ACK 后，不会立即进入 CLOSED，而是进入 TIME_WAIT，默认等待 2 个 MSL（报文最大生存时间，通常 2 分钟）。为什么要等？两个原因：一是确保最后一个 ACK 能到达对方，万一这个 ACK 丢了，对方会重发 FIN，此时 TIME_WAIT 状态还能再回应；二是让网络中遗留的旧报文自然消亡，避免它们被新建的连接错误接收。

这正是关键词里那个高频报错的核心原因：error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address。虽然报错字面意思很像“端口被占用”，但很多时候不是别的进程占着不放，而是大量处于 TIME_WAIT 状态的连接还没释放端口，新的监听 socket 就无法复用它。解决方案在后面的排错章节细讲。

2.3 UDP 的“无连接”意味着什么

UDP 不存在握手，自然也没有建立连接和释放连接的概念。调用 sendto() 函数的时候，把目标地址和端口带上，数据就出去了。UDP 协议栈里没有任何连接表，没有状态机，也不维护序号。

但这不代表 UDP 完全没有任何“连接”概念。实际开发中你会遇到一个概念叫“UDP 连接”（connected UDP socket），即调用 connect() 函数绑定对端地址。底层真实发生的事和 TCP 完全不同：UDP 的 connect 不会发任何网络报文，只是在内核里把这个 socket 默认的对端地址记下来，之后 send() 就不用每次都带地址，而且内核只接受来自该地址的报文。它本质是一种本地优化和过滤，不是网络行为。

排查 UDP 问题时还有一点特别容易混淆：当发送 UDP 数据报到一台主机的未监听端口时，发送方往往收不到任何直接的“UDP 错误消息”，而是会收到一个 ICMP Port Unreachable 报文，由内核把这个错误反馈给 socket。如果 socket 没有调用 connect，这个 ICMP 错误甚至不会通知到应用层。这就是为什么 UDP 调试时“发了没反应”很难定位的直接原因——至少先用 netstat -ulnp 确认目标端口有没有进程在听。

3. 从报文头部看本质：8 字节与 20 字节背后的设计取舍

3.1 UDP 头部逐字段拆解

UDP 头部只有 4 个字段，每个字段 2 字节（16 位），总共固定 8 字节。结构极其精简：

• 源端口（16 位）：标识发送进程，可选，不需要回复时可以填 0。
• 目的端口（16 位）：标识接收进程，这是 UDP 分用的核心依据。
• 长度（16 位）：UDP 头部加上数据的总长度。注意这是 UDP 报文本身的长度，不是 IP 包全长，最小值是 8（只有头部没有数据）。
• 校验和（16 位）：覆盖 UDP 头部、数据以及一个“伪首部”（包含源 IP、目的 IP、协议号、UDP 长度）。伪首部不参与传输，只用于计算，目的是防止 IP 地址寻址出错却无法感知。

为什么 UDP 设计得这么简单？因为它的定位就是“极小开销的传输通道”。它不关心序号，因为没有重传和排序需求；它不记录确认号，因为根本没打算收确认；它不需要窗口字段，因为不调整发送速率。UDP 把一切可靠性问题都扔给应用层自己处理，只提供最核心的“端口到端口”数据交付功能。

实际抓包时可以用这个简化头部快速判断：看到 IP 层协议字段是 17，传输层头长度是 8 字节，基本可以确定是 UDP。而如果看到 IP 头后面只有 8 字节且校验和不对，那大概率是硬件校验和分载（checksum offload）的锅，这种问题在抓包分析中非常常见。

3.2 TCP 头部关键字段与可靠性机制的关系

TCP 头部我按功能拆成三组来理解，比死记字段更有用。

第一组：连接与序号字段。源端口、目的端口各 16 位；序号（Sequence Number）32 位，表示当前报文数据第一个字节在字节流中的位置；确认号（Acknowledgment Number）32 位，表示期望收到对方下一个字节的序号。这两个 32 位字段是 TCP 实现有序性和可靠性的基石。有了序号，接收方才可以排序、去重、发现丢包；有了确认号，发送方才能知道哪些字节已经被确认接收。

第二组：控制与状态字段。包括 9 个标志位里最常用的 SYN、ACK、FIN、RST、PSH、URG。SYN 用于握手时同步序号；ACK 表示确认号有效；FIN 用于正常关闭；RST 用于异常中止连接。排错时遇到 connection reset by peer，本质上就是收到一个 RST 置位的报文，绝大多数情况是服务端进程崩溃或者有意拒绝连接。

第三组：流量与拥塞控制字段。窗口大小（Window Size）16 位，是接收方告诉发送方“我还有多少缓冲区能收数据”的流控声明；数据偏移（Header Length）4 位，表示头部有多少个 32 位字，因为 TCP 头部长度在 20 到 60 字节之间浮动。发送方通过窗口大小感知接收方的处理能力，再配合自身的拥塞窗口（cwnd），最终决定每个发送周期能发多少数据——这也是 TCP 与 UDP 在速度特征上差异巨大的根源。

3.3 一个 TCP 头部为什么能有 20 到 60 字节的变化

有人问过：TCP 不是固定 20 字节吗，为什么说最大 60 字节？答案在“选项”（Options）字段。20 字节是没有任何选项的基础头部，而在实际连接中，为了性能优化几乎总要带选项，最常见的几个：

• MSS（最大报文段长度）：告知对方自己能接收的单个 TCP 报文数据部分的最大长度，避免分片。它在握手阶段协商。
• 窗口缩放因子（Window Scale）：因为原始窗口字段只有 16 位，最大 65535 字节，在高速网络上根本不够用，通过缩放因子可以把实际窗口扩大到 1GB 级别。
• SACK（选择性确认）：允许接收方告诉发送方“我只丢了哪些段”，这样发送方只需重传丢掉的段，而不是从丢失位置之后全部重传。在丢包率高的链路上，SACK 对吞吐量的提升非常明显。
• 时间戳（Timestamps）：用于计算 RTT（往返时间）、支持 PAWS（防序号回绕），在高带宽长距离链路上几乎是标配。

这也是头部开销差异带来的连锁反应：TCP 每个报文至少要扛 20 字节的元数据，再加上握手期间的空包，实际有效载荷比例在短连接小报文场景下特别难看。比如一个只有 100 字节业务数据的小包，TCP 头部加 IP 头部已经要 40 字节，开销占比接近 30%。UDP 是 8 字节 UDP 头加 20 字节 IP 头，同样 100 字节业务数据只需要 28 字节开销，占比只有 22% 左右。对于海量高频小报文场景，这个差距会被放大得非常明显。

4. 可靠性与速度的博弈：TCP 的“稳”和 UDP 的“快”从何而来

4.1 TCP 的可靠性闭环：确认、重传、去重、排序

TCP 的可靠性不是某个单一机制的结果，而是一整套闭环：

• 发送方给字节流编上序号，每发出数据后启动一个重传计时器。
• 接收方收到数据后，回送 ACK 确认号，表示“这个字节之前的我都收到了”。
• 发送方如果在超时时间内没等到 ACK，就重传对应数据。
• 接收方如果发现序号不连续，说明中间有丢包，会缓存已到达的后续数据，同时重复发送“期望接收的序号”的 ACK；发送方连续收到 3 个重复 ACK，不等超时就会重传——这就是快速重传机制。

这套闭环看起来完美，但代价是每个报文都要等待确认，网络往返时间（RTT）直接钳制了吞吐上限。经典公式是：最大吞吐率 ≈ 窗口大小 ÷ RTT。想提升吞吐，要么加大窗口，要么降低 RTT。高延迟卫星链路上 TCP 表现不佳的原因就是这么简单。

还有一个容易被忽略的副作用：TCP 是字节流协议，应用层调用 send() 发送的多个数据块可能会被合并进同一个报文（Nagle 算法和延迟确认共同作用），也可能被拆开跨越多个报文。这就是“粘包拆包”问题的由来。解决手段无非四种：定长消息、分隔符、消息头带长度、或者干脆用带消息边界的 UDP 上层协议包装。

4.2 拥塞控制：TCP 知道自己“不能太贪”

TCP 还有一个 UDP 完全没有的机制——拥塞控制。核心思想很简单：网络是共享资源，发送方不能只考虑自己发得快，还要考虑中间路由器会不会被打爆。实现上由慢启动、拥塞避免、快速重传、快速恢复等多个状态机协同工作。

慢启动最容易理解但没有接触过的人容易搞反：它不是刻意慢，而是指数翻倍地探索可用带宽。初始拥塞窗口 cwnd 很小，每收到一个 ACK，cwnd 就翻倍，很快就能探测到网络的真实承受能力。当 cwnd 超过慢启动阈值（ssthresh）或者出现丢包，就转入拥塞避免阶段，以线性方式缓慢增加直到再次丢包，然后减半窗口。这个机制让 TCP 在共享链路上表现得像一个守规矩的司机：前面通畅就提速，一堵车就立刻减速。代价是 TCP 的瞬时速率波动大，不适合对带宽要求极度稳定的实时业务。

4.3 UDP 的“速度为王”和它牺牲掉的东西

UDP 没有窗口、没有拥塞控制、没有确认，发出去的包完全依赖网络设备尽力转发。所以 UDP 的速度上限非常高，但也非常不克制。如果应用层不管控发送速率，一段 1Gbps 的网络几乎可以被一个 UDP socket 瞬间打满，然后大量报文在路由器队列里被丢弃，其他业务全部遭殃。

牺牲的可靠性在特定场景下却变成了优势。比如实时音视频通话，一个视频帧晚到了 500 毫秒，与其重传一个已经没意义的帧，不如丢弃它，让画面短暂卡一下立刻恢复。这种业务追求的是“最新状态”而不是“所有状态”。RTP 协议选 UDP 做底层，正是这个逻辑：迟到数据无价值。游戏行业同理，玩家的位置信息一直产生新数据，如果为了重传一个旧位置包而阻塞后续 10 个位置包，角色就会一直卡在旧坐标上，根本无法玩。

所以我的看法是：TCP 的可靠性和 UDP 的实时性，没有谁绝对好，只有场景合不合适。你需要的不是记住“TCP 可靠 UDP 快”这个结论，而是能根据业务特征判断出“是否需要旧数据重放”这个维度。只要想清楚一个业务对历史数据的依赖程度，选型方向就错不了。

5. 场景选型实战：什么时候死磕 TCP，什么时候大胆用 UDP

5.1 典型业务的协议选择逻辑

经常有人拿着业务场景来问，我觉得可以归纳成三条判断线：

第一条，数据丢了能不能接受？不能接受，选 TCP。比如文件传输、数据库同步、邮件发送、支付交易，任何一条记录丢失都可能造成资损或数据不一致，TCP 的自动重传是底线保障。

第二条，数据迟到有没有价值？完全没价值，优先考虑 UDP。实时音视频、游戏状态同步、金融行情推送、工业设备实时监控，这类场景数据时效性大于完整性，用 TCP 反而会因为重传阻塞造成更大的体验问题。

第三条，报文大小和频率？高频大并发小报文场景，UDP 的低头部开销和消息边界特性更有优势。物联网传感器上报、日志采集，这类业务如果走 TCP，频繁建连握手会浪费大量资源，如果用 UDP 配合应用层幂等校验，往往更轻量。

具体到协议层面举个例子：Modbus TCP 这个名字里有 TCP，但很多人不知道它底层是用 TCP 承载 Modbus 协议，核心原因是工业控制场景对指令传输可靠性要求极高，少传一条写入指令可能导致整个产线状态错乱。而 TFTP、SNMP 这些场景则明确选 UDP，因为它们要么是局域网内一次性读文件，要么是监控类低频查询，偶尔丢一包重试代价很低。

5.2 关于“协议混合”的三个常见误解

做了多年网络开发和排障，你会发现很多业务并不是非黑即白，三个高频误解值得说清楚。

误解一：DNS 只走 UDP。 大多数 DNS 查询确实使用 UDP 53 端口，因为查询报文通常只有几十字节，用 UDP 一个往返就能拿到结果。但 DNS 区域传输（zone transfer）必须走 TCP，因为区域数据可能很大，UDP 承载不了；当 UDP 响应报文被截断（truncated）时，客户端也会自动切换 TCP 重查。抓包时如果发现 53 端口出现 TCP 连接，不要觉得异常。

误解二：HTTP 只能是 TCP 之上。 HTTP/1.1 和 HTTP/2 确实都基于 TCP，但 HTTP/3 已经改用 QUIC，而 QUIC 跑在 UDP 之上。QUIC 在应用层里实现了类似 TCP 的可靠性、有序性、拥塞控制，却解决了 TCP 的队头阻塞问题，还能把握手延迟从 1-RTT 压缩到 0-RTT。现在很多视频流、Web 实时通信已经在用 QUIC，抓包时看到 443 端口是 UDP 包，别慌，它很可能是 HTTP/3 流量。

误解三：UDP 完全不可靠，所以业务不能依赖。 这个说法只说对了一半。UDP 协议本身不保证交付，但应用层完全可以建立一套可靠机制：每个报文带自增序号、接收方定时回批量确认、发送方维护重传队列。很多游戏引擎里的可靠 UDP 通道，本质就是在 UDP 之上自己实现一个轻量版 ARQ（自动重传请求）协议，做到“按需可靠”——重要消息走可靠通道，位置信息走不可靠通道。这种颗粒度的控制能力是 TCP 提供不了的。

5.3 工具链视角：用什么手段观察和验证 TCP/UDP

聊完选型，落到验证和调试。这个部分我结合几个高频工具来说，关键词里提到的 iperf3、Wireshark、网络调试助手之类都有涉及。

iperf3 打流测试是衡量 TCP/UDP 性能最直接的手段。测 TCP 吞吐，服务端跑 iperf3 -s，客户端跑 iperf3 -c 服务器IP，默认会做 10 秒的 TCP 测试并输出带宽、重传率。测 UDP 时必须要手动指定带宽：iperf3 -u -c 服务器IP -b 100M -t 30。注意，不加 -b 的话 iperf3 的 UDP 默认只有 1Mbps，测出来结果完全没有参考意义。还有一点：UDP 测试看结果要注意方向，iperf3 客户端收到的 sender 行展示的是发送端统计，receiver 行展示的是接收端统计，两端数值不一致说明链路中间丢包了。丢包率就是 (sender 发送包数 - receiver 接收包数) / sender 发送包数。

Wireshark 抓包分析是理解 TCP/UDP 底层行为最好的老师。但新手很容易踩一个坑：在过滤器里输入 udp，结果还是能看到 ICMP 包。这其实是因为 Wireshark 的显示过滤器只是“决定哪些包显示出来”，不是“只让这些包进入网卡”。你设置了 udp，等价于要求“只显示 UDP 包”，而抓包文件里本身还有 ICMP 包会被保留在文件中。对关键词里的这个问题，正确的理解方式是：任何过滤器都不会影响抓包过程本身，只影响显示内容。要在抓包阶段就做限制，应该用捕获过滤器，比如 udp or icmp，才是在采集环节就过滤掉其他流量。

TCP 连接状态检查用 netstat -antlp 或 ss -antlp 看。重点关注几个状态：LISTEN 表示有进程在监听；ESTABLISHED 是正常连接；SYN_SENT 表示连接请求发出后没收到回应，通常是对端防火墙拦了 SYN 或者服务端没有监听；TIME_WAIT 大量堆积说明短连接创建频率过高，等待释放的 socket 堵在那里。定位“端口被占用”最直接的办法是 ss -lntp | grep 11434，能看到占用该端口的进程 PID 和名称；如果查到是被 TIME_WAIT 占据（netstat 状态是 TIME_WAIT），那处理思路就不是杀进程而是调整内核参数，比如开启 net.ipv4.tcp_tw_reuse 并配合时间戳选项来复用 TIME_WAIT 连接。

6. 高频报错与排查经验：来自实战一线的记录

6.1 端口绑定失败：不只是“端口被占用”

关键词里的 error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address 非常经典，几乎每周都能在社区和群里看到一次。这个报错的意思是：你尝试把一个套接字绑定到一个已经被占用的地址和端口组合上。

排查思路排个序：

1. 先用 ss -lntp | grep 11434 或者 netstat -lnp | grep 11434 找一个端口，确认是不是有进程占用了 11434。
2. 如果没有进程占用，但报错依然存在，查看 TIME_WAIT 状态。ss -antp | grep 11434，如果看到大量 TIME_WAIT，说明端口还处于内核保留的关闭等待期。
3. 这时候如果确认是服务端程序需要重启监听，可以在 socket 上设置 SO_REUSEADDR（服务端场景很安全，但不要和 SO_REUSEPORT 混淆，后者用于多进程负载均衡）。Go 语音里在 net.Listen 之前通过 net.ListenConfig 的 Control 回调设置。
4. 如果是客户端大量短连接导致 TIME_WAIT 堆积，问题根源在高频连接创建上，优先调整内核参数：设置 net.ipv4.tcp_tw_reuse=1（仅在主动连接方有效）和 net.ipv4.tcp_fin_timeout 调小。

另外要说一句：Windows 上同样会报错 only one usage of each socket address，同样先查端口占用，命令换成 netstat -ano | findstr 11434 和 tasklist。别急着改代码，九成是端口被某个残留进程占着。

6.2 connection reset by peer 的三种常见原因

curl: (35) tcp connection reset by peer 也是高频问题。这个报错发生在 TCP 连接建立或使用过程中，对端发送了 RST 包强制中止连接。常见原因有三个：

第一，服务端根本没有对应端口在监听。TCP 连接请求到达服务器后，内核发现目标端口无进程监听，直接回 RST，客户端就报 connection reset。排查用 ss -lnt 确认端口状态。

第二，服务端进程崩溃或主动 close。进程崩溃后内核会发送 RST 重置所有连接。这时候重点是查服务端日志，看进程为什么退出，而不是在客户端反复重试。

第三，中间网络设备主动 RST。防火墙、负载均衡设备在检测到连接异常或违规流量时会注入 RST。常见于跨地域网络传输时被安全设备拦截，或者长连接长时间无数据，中间设备认为空闲连接无效直接断开，这通常和 keepalive 配置有关。解决方向是应用层加心跳或者配置 TCP keepalive。

排查这个报错有一个经验技巧：不要在客户端只抓一次包就下结论，用 Wireshark 同时抓客户端和服务器两端（或者用 tcpdump -i any port 443 在两端分别抓），对比 RST 包出现在哪里、由谁发出，问题归属立刻清楚。RST 能从哪一端发出，基本就定位到哪一段网络。

6.3 UDP 数据包“发了没反应”的排查清单

UDP 调试比 TCP 更隐蔽，因为“目标端口没监听”这件事发送方默认感知不到。我建议按下面的顺序排查：

1. 用 tcpdump -i eth0 udp port 12345 在接收端抓包，确认报文到底有没有到达目标主机。如果抓不到包，问题在中间网络或发送端路由、防火墙。
2. 如果能抓到包但没有进程接收，用 ss -ulnp | grep 12345 检查端口监听情况。UDP 没有连接状态，LISTEN 就是有 socket 绑定了，应用层有没有调用 recvfrom 是另一回事。
3. 使用 UDP 调试软件时（关键词里提到的网络调试助手一类的工具），注意查看软件是否真的绑定了对应端口，Windows 下杀毒软件可能拦截 UDP 监听，Linux 下检查防火墙规则 iptables -L -n。
4. 如果跨机器通信，确认发送端是否绑定了正确的网卡 IP。多网卡机器上 UDP 默认走路由表，可能从错误网卡发出去了。

另外，Windows 系统上 UDP 数据包发出后如果没有应用监听，会收到 ICMP Port Unreachable，但这个错误属于“异步错误”，通常要 socket 调用了 connect 绑定对端后，recv 才能返回错误码。所以 Windows UDP 调试时最常见的现象就是“发送无响应、还抓不到错误”，这其实不是网络问题，而是编程模型如此。

6.4 性能测试与内核参数调整的两条实操建议

用 iperf3 做 UDP 打流时，发现带宽上不去或者丢包率高，优先检查两点。一是网卡中断绑核是否合理，多队列网卡要把队列分布到不同 CPU 核上，避免单核软中断处理成为瓶颈，这个在 Linux 下可以用 ethtool -L 调整队列数量。二是接收缓冲区是否太小，UDP 报文到达速太快内核 socket 接收队列满了就会丢包。Linux 下查看当前缓冲区上限用 sysctl net.core.rmem_max，调整命令是：

bash复制sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.wmem_max=26214400

Windows 下对应的是注册表项：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters，调整 DefaultReceiveWindow 和 DefaultSendWindow，改成十进制字节数，比如 8192 或 16384，修改后需要重启系统生效。关键词里提到的“修改 Windows 全局 UDP 系统缓存区”大概率就是改这里，实测对高吞吐 UDP 接收有明显改善。

再说一个判断 UDP 丢包的小技巧：用 netstat -su 查看 UDP 层统计，里面的 packets received 表示本机收到的 UDP 数据包数，packets to unknown port 表示发往未监听端口的包数。如果后者数值在持续上涨，说明有程序在不断向一个没有监听的端口发 UDP 数据，这既是排查“发了没反应”的重要线索，也是找广播风暴、错误配置的有效入口。这个统计项在 Linux 的 /proc/net/snmp 里也能看到，一条 Udp: ... 开头的行。

7. 一点个人经验：TCP 与 UDP 选择背后的两句话

做了这么多年网络和通信开发，踩过的坑不计其数，最后总结成两句话送给你。

第一句：选 TCP 之前先问丢包能不能忍，选 UDP 之前先问乱序和丢包能不能靠应用层兜底。 这两句话不是绕口令，而是取舍的核心。TCP 的可靠是一种“默认可靠”，把重传、排序、流控都内置好了，代价是失去对底层行为的精细控制；UDP 的自由是一种“无保障自由”，所有可靠性都需要应用层按需重建，但换来的是低延迟和灵活度。

第二句：排查网络问题永远先分层、再对照、后定位。 分层意思是先确定问题出在应用层、传输层、网络层还是物理层；对照意思是 TCP 要看状态机转换、UDP 要看统计计数器；定位意思是用抓包工具把事实固定下来，用数据而非猜测说话。每次看着对方发来一个 connection reset by peer 就说“网络不稳定”，我一查抓包发现是防火墙在作怪，这种凭经验的低级误判，在大规模系统里危害很大。

关于 TCP 和 UDP，我不建议只把它们当成面试题来背。真正理解两个协议背后设计哲学的开发者，在架构设计时会有一种直觉：哪些业务应该让系统“慢而稳”，哪些业务必须“宁可丢也不等”。这种直觉来自对协议的深层理解，而不是对技术选型表格的死记硬背。希望这篇文章能帮你建立这种直觉，下一次再面对 TCP 还是 UDP 的选择时，心里有谱。