1. 从一个真实的翻车现场说起
去年帮一个做智慧农业的朋友排查数据采集系统的问题，场景很典型：大棚里部署了120多台以太网温湿度记录仪，上位机用轮询方式每秒采集一轮数据，跑了大半年一直挺稳。后来大棚扩建，设备数量加到300多台，问题就来了——上位机界面上的温度曲线开始出现断点，湿度数据偶尔跳变成0或者65535这种明显异常值。朋友第一反应是传感器坏了，换了几个探头还是老样子；又怀疑是交换机端口不够，换了两台工业级交换机，依然没解决。
我过去抓了两轮包，问题很快就定位了：丢包。而且丢包不是均匀分布的，是集中在轮询周期末尾那几十毫秒里，典型的并发压力下协议栈处理不过来导致的丢包。这时候就引出一个老生常谈但每次都要重新吵一遍的问题：这种高并发轮询场景，到底该用UDP还是TCP？
这个问题没有标准答案，但有一个靠谱的答案——用数据说话。我后来专门搭了一套基准测试环境，把UDP和TCP在同样的硬件、同样的轮询频率、同样的设备数量下跑了一遍，记录丢包率、延迟分布、CPU占用这些指标。这篇文章就把整个测试的设计思路、实操过程、踩过的坑和最终结论完整分享出来。不管你是做工业数据采集、物联网网关开发，还是单纯想搞清楚UDP和TCP在真实高并发场景下的表现差异，这篇内容都能直接拿去参考。
2. 测试方案的整体设计与选型考量
2.1 为什么不能拍脑袋选协议
很多人选协议的逻辑是这样的：TCP可靠，那就用TCP；UDP快，那就用UDP。这种二选一的思路在实际项目里很容易翻车，因为可靠和快并不是非此即彼的关系，关键在于你的业务能容忍什么样的失败模式。
温湿度记录仪这个场景有几个特点需要先想清楚。第一，数据是周期性采集的，每秒或者每几秒来一个点，单个数据点丢失对整体趋势影响不大，因为下一个周期马上就有新数据补上。第二，设备数量多，300台设备轮询一轮，如果串行处理，每台设备分配到的处理时间窗口非常窄。第三，温湿度数据本身变化缓慢，温度一分钟内波动通常不超过0.5度，所以偶尔丢一两个包完全可以接受，只要不是持续丢包导致曲线断裂就行。
基于这三点，UDP其实是有天然优势的——没有连接建立和维护开销，没有重传机制带来的延迟抖动，协议栈处理路径短。但UDP的问题也很明显：它不保证顺序，不保证到达，甚至不保证不重复。如果应用层不做任何处理，丢包就是丢了，你连丢了都不知道。
TCP呢？可靠传输、有序到达、自动重传，听起来很美好。但在高并发轮询场景下，TCP的三次握手、滑动窗口、拥塞控制、Nagle算法这些机制反而可能成为负担。尤其是当设备端TCP协议栈实现比较简陋的时候，大量并发连接可能导致设备端响应变慢，进而触发上位机的超时重试，形成恶性循环。
所以我的测试设计思路是：不预设结论，把两种协议放在同一套基准下跑，用丢包率、延迟、CPU占用三个维度来量化对比。
2.2 测试环境的搭建与参数设定
测试环境我尽量模拟真实工业现场，但做了简化以便控制变量。硬件方面，上位机用一台Intel N100的小主机，4核4线程，16G内存，跑Ubuntu 22.04；交换机用一台普通的千兆非管理型交换机；设备端用ESP32-S3模组模拟温湿度记录仪，每台设备跑一个简单的Modbus TCP或Modbus UDP服务端，寄存器里放模拟的温湿度数据。
为什么用ESP32-S3而不是真实的温湿度记录仪？因为真实设备往往封闭，没法改协议栈参数，也没法精确控制响应时间。ESP32-S3的以太网和WiFi协议栈都是开源的，我可以精确控制每个环节，而且成本低，300台设备的模拟成本远低于买300台真实记录仪。
轮询频率设定为每秒一轮，每轮向所有在线设备发送读取请求。设备数量从50台开始，逐步增加到100、200、300、400台，观察丢包率的变化趋势。每次测试持续10分钟，取稳定后的5分钟数据做统计。
这里有个细节需要注意：Modbus TCP和Modbus UDP的报文格式不一样。Modbus TCP有7字节的MBAP头，包含事务标识符、协议标识符、长度字段和单元标识符；Modbus UDP虽然也常用类似的封装，但很多实现会简化掉部分字段。为了公平对比，我在应用层统一了数据载荷，只让传输层协议不同。
2.3 丢包率的定义与测量方法
丢包率怎么算，这个得先说清楚，不然数据没法对比。我定义了两个指标：请求丢包率和响应丢包率。
请求丢包率是指上位机发出的请求报文中，没有收到任何响应的比例。这个指标反映了从上位机到设备端这条路径的可靠性。响应丢包率是指设备端确实收到了请求并发出了响应，但上位机没有收到的比例。这个指标反映了从设备端到上位机这条路径的可靠性。
测量方法上，UDP侧我在应用层加了序列号，每个请求带一个递增的seq，设备端响应时把seq原样带回，上位机收到响应后检查seq连续性。TCP侧因为本身有序号机制，我直接统计应用层事务标识符的连续性。
这里有个坑：UDP的丢包可能发生在多个环节——上位机网卡发送失败、交换机拥塞丢弃、设备端网卡接收失败、设备端协议栈缓冲区满丢弃、设备端应用层处理不过来丢弃。要精确定位是哪一环丢的，需要在每个环节加计数器。我在ESP32-S3的固件里加了协议栈接收计数和应用层处理计数，在上位机侧加了发送计数和接收计数，这样就能把丢包环节拆开看。
3. UDP与TCP在高并发下的核心差异解析
3.1 协议栈处理路径的差异
要理解丢包率为什么不同，得先看协议栈是怎么处理报文的。UDP的处理路径非常短：网卡收到帧，驱动交给协议栈，协议栈检查校验和，然后直接投递给应用层socket的接收缓冲区。如果缓冲区满了，报文就被丢弃，协议栈不会通知发送方，也不会重传。
TCP的处理路径就长得多：网卡收到帧，驱动交给协议栈，协议栈要维护连接状态、处理序号、发送ACK、调整滑动窗口、可能触发拥塞控制算法。如果接收缓冲区满了，TCP会通过窗口字段告诉发送方“我这边满了，你先别发”，发送方就会暂停发送，等窗口打开再继续。这个机制叫流量控制，是TCP可靠性的重要保障，但在高并发场景下也可能导致发送方被“卡住”。
我实测过一个极端情况：300台设备同时用TCP轮询，上位机开300个socket，每个socket一个线程。结果发现CPU的软中断占用率飙升到40%以上，因为每个TCP报文都要触发协议栈的完整处理流程，包括ACK的生成和发送。而同样数量的UDP轮询，软中断占用率只有15%左右。
这不是说TCP不好，而是说TCP的可靠性是有代价的，这个代价在高并发场景下会被放大。
3.2 连接管理开销的量化对比
TCP是面向连接的，每个设备都要维护一个连接。连接建立需要三次握手，断开需要四次挥手，中间还要定期发Keep-Alive保活报文。这些开销在设备数量少的时候可以忽略，但设备数量上去之后就很可观了。
我做了个简单的计算：假设300台设备，每台设备每30秒发一次Keep-Alive，那么每秒就有10个Keep-Alive报文。这些报文不携带业务数据，但会占用协议栈处理资源和网络带宽。如果Keep-Alive间隔设得更短，比如5秒，那每秒就是60个报文，开销更大。
UDP没有连接的概念，每个报文都是独立的，不需要握手，不需要保活，不需要维护连接状态。设备端只需要一个socket就能处理所有请求，上位机也只需要一个socket就能向所有设备发请求。这种无状态的特性在高并发场景下优势非常明显。
但无状态也有代价：你没法知道设备是否在线。TCP连接断了，你能立刻感知；UDP没有连接，设备离线了你可能还在傻傻地发请求。所以UDP方案通常需要应用层自己做心跳机制，比如设备定期主动上报状态，或者上位机定期发探测报文并等待响应。
3.3 丢包后的恢复机制对比
TCP丢包后会重传，这是它的核心优势。但重传的时机和策略很关键。TCP的重传超时（RTO）是根据往返时间（RTT）动态计算的，初始值通常是1秒，最小200毫秒左右。如果设备端响应慢，RTT大，RTO也会变大，重传等待时间就长。
在轮询场景下，如果某个设备响应慢，TCP会等它，导致整个轮询周期被拉长。如果轮询周期是1秒，而某个设备的RTO是1.5秒，那这一轮就超时了，上位机可能直接跳过这个设备进入下一轮。这时候TCP的重传其实没起到作用，因为应用层已经放弃了。
UDP丢包后不重传，应用层要么接受丢包，要么自己实现重传。自己实现重传的好处是可以控制重传策略：比如只对关键数据重传，非关键数据丢了就丢了；或者设置更短的重传超时，比如100毫秒，快速重试一次，不行就放弃。
我实测下来，在温湿度采集这个场景下，UDP加应用层轻量重传的方案，综合表现比纯TCP好。因为温湿度数据对实时性有一定要求，但又不是强实时，允许偶尔丢包，应用层重传一次就能把丢包率压到可接受范围。
4. 基准测试的实操过程与关键数据
4.1 测试工具链的搭建
上位机侧我用Python写了一个轮询客户端，核心逻辑是用asyncio做异步IO，UDP用loop.create_datagram_endpoint，TCP用asyncio.open_connection。为什么用asyncio而不是多线程？因为多线程在300个并发连接时线程切换开销很大，asyncio的单线程事件循环更适合这种IO密集型场景。
设备端ESP32-S3的固件用ESP-IDF开发，UDP服务端用recvfrom阻塞接收，TCP服务端用accept接受连接后每个连接一个任务。为了模拟真实设备的处理延迟，我在应用层加了0到5毫秒的随机延迟，模拟传感器采样和数据处理的时间。
网络抓包用tcpdump，在上位机和交换机镜像端口同时抓，方便对比两端看到的报文差异。统计分析用Python的pandas和matplotlib，丢包率、延迟分布、CPU占用都做成图表。
这里有个实操细节：ESP32-S3的WiFi和以太网不能同时用，我测试的是以太网模式，因为工业现场通常用有线以太网，稳定性比WiFi好。ESP32-S3通过RMII接口接一个LAN8720 PHY芯片，跑100Mbps全双工。虽然理论带宽足够，但实际测试中发现PHY芯片的接收缓冲区比较小，高并发时容易溢出。
4.2 UDP轮询的测试过程与数据
UDP测试从50台设备开始，逐步加到400台。每轮测试发10000个请求，统计丢包率和延迟。
50台设备时，丢包率几乎为0，平均延迟0.8毫秒，P99延迟2.1毫秒。这个结果很正常，50台设备每秒50个请求，对千兆网络来说毫无压力。
100台设备时，丢包率0.02%，平均延迟0.9毫秒，P99延迟2.5毫秒。丢包开始出现，但还在可接受范围。
200台设备时，丢包率0.15%，平均延迟1.2毫秒，P99延迟4.8毫秒。丢包率上升了一个数量级，P99延迟也明显增加。
300台设备时，丢包率0.8%，平均延迟1.8毫秒，P99延迟12毫秒。这个丢包率已经比较明显了，10分钟内大约有480个请求丢失。
400台设备时，丢包率2.3%，平均延迟2.5毫秒，P99延迟25毫秒。丢包率超过2%，曲线开始出现肉眼可见的断点。
我抓包分析了一下300台设备时的丢包分布，发现丢包主要集中在每轮轮询的最后50毫秒。原因是上位机发送请求的速度快于设备端处理的速度，设备端的接收缓冲区在轮询后期被填满，新到的报文被丢弃。ESP32-S3的UDP接收缓冲区默认是5760字节，大约能存4个最大长度的UDP报文，缓冲区满了之后协议栈直接丢包。
4.3 TCP轮询的测试过程与数据
TCP测试同样的设备数量梯度，但结果和UDP很不一样。
50台设备时，丢包率0%，平均延迟1.2毫秒，P99延迟3.5毫秒。TCP的延迟比UDP高，因为多了连接维护和ACK处理的开销。
100台设备时，丢包率0%，平均延迟1.5毫秒，P99延迟5.2毫秒。TCP没有丢包，因为流量控制机制在起作用。
200台设备时，丢包率0%，平均延迟2.1毫秒，P99延迟8.7毫秒。延迟继续增加，但依然没有丢包。
300台设备时，丢包率0.05%，平均延迟3.5毫秒，P99延迟18毫秒。开始出现少量丢包，但远低于UDP的0.8%。
400台设备时，丢包率0.3%，平均延迟5.2毫秒，P99延迟35毫秒。丢包率0.3%，虽然比UDP的2.3%低很多，但延迟已经很高了。
这里有个关键发现：TCP的丢包不是协议栈丢的，而是应用层超时导致的。上位机设置了500毫秒的超时，超过就认为丢包。300台设备时，部分设备的响应时间超过了500毫秒，被上位机判定为丢包。实际上这些响应最终还是到了，只是来晚了。
4.4 数据对比与关键结论
把两组数据放在一起对比，结论就很清晰了。
| 设备数量 | UDP丢包率 | TCP丢包率 | UDP P99延迟 | TCP P99延迟 | UDP CPU占用 | TCP CPU占用 |
|---|---|---|---|---|---|---|
| 50 | 0% | 0% | 2.1ms | 3.5ms | 3% | 5% |
| 100 | 0.02% | 0% | 2.5ms | 5.2ms | 5% | 9% |
| 200 | 0.15% | 0% | 4.8ms | 8.7ms | 9% | 16% |
| 300 | 0.8% | 0.05% | 12ms | 18ms | 14% | 28% |
| 400 | 2.3% | 0.3% | 25ms | 35ms | 21% | 42% |
从数据可以看出几个规律。第一，UDP的丢包率随设备数量增长呈指数上升，而TCP的丢包率增长相对平缓。第二，TCP的延迟始终高于UDP，而且差距随设备数量增加而扩大。第三，TCP的CPU占用几乎是UDP的两倍，因为协议栈处理更复杂。
但这里有个重要的补充：UDP的丢包可以通过应用层重传来弥补。我在UDP方案里加了一个简单的重传机制：如果100毫秒内没收到响应，就重传一次，最多重传两次。加上重传后，300台设备时的有效丢包率从0.8%降到了0.05%，和TCP持平，但延迟依然比TCP低，CPU占用也只有TCP的一半左右。
5. 实操中的常见问题与排查技巧
5.1 UDP丢包的快速定位方法
UDP丢包排查的核心思路是分段计数。在上位机发送侧、交换机镜像口、设备接收侧分别统计报文数量，就能定位丢包发生在哪一段。
如果发送侧计数正常，镜像口计数少了，说明是上位机网卡或者驱动丢的。这种情况通常是发送缓冲区满了，可以调大SO_SNDBUF。如果镜像口计数正常，设备接收侧少了，说明是网络传输或者设备网卡丢的。检查网线质量、交换机端口错误计数、设备PHY芯片的接收错误计数。
如果设备接收侧计数正常，但应用层处理计数少了，说明是设备协议栈缓冲区满导致的丢包。ESP32-S3可以调大CONFIG_LWIP_UDP_RECVMBOX_SIZE，默认是6，可以加到16或者32。但要注意，调大缓冲区会增加内存占用，ESP32-S3的内存有限，不能无限调大。
还有一个容易被忽略的点：UDP校验和。有些设备端的UDP校验和计算有bug，导致校验和错误的报文被协议栈丢弃。可以在设备端临时关闭UDP校验和检查来验证，如果关闭后丢包消失，那就是校验和的问题。
5.2 TCP连接数过多的性能瓶颈
TCP方案在设备数量超过200台后，上位机的CPU占用明显上升。用perf top看了一下，大部分时间花在tcp_v4_rcv和tcp_ack上，也就是TCP报文的接收和ACK处理。
优化方向有几个。第一，开启TCP快速打开（TFO），减少三次握手的开销。但TFO需要设备端也支持，ESP32-S3的lwIP协议栈默认不支持TFO，需要自己改。第二，调整TCP_NODELAY，禁用Nagle算法，减少小报文的延迟。第三，增大TCP接收缓冲区，让协议栈能缓存更多报文，减少应用层处理不及时导致的丢包。
但最有效的优化其实是减少连接数。如果设备支持Modbus TCP的单元标识符，可以用一个TCP连接轮询多个设备，而不是每个设备一个连接。Modbus TCP的MBAP头里有单元标识符字段，可以区分不同设备。这样300台设备只需要一个TCP连接，协议栈开销大幅降低。
我实测过这种方案，300台设备用一个TCP连接轮询，CPU占用从28%降到了8%，P99延迟从18毫秒降到了6毫秒。但缺点是串行化了，一个设备响应慢会阻塞后面的设备。所以这种方案适合设备响应时间比较均匀的场景。
5.3 交换机与网络配置的隐藏坑
工业现场的网络环境比实验室复杂得多，有几个坑我踩过好几次。
第一个坑是交换机风暴抑制。有些工业交换机默认开启了广播风暴抑制，阈值设得很低，比如每秒1000个广播报文。UDP轮询如果用了广播地址，很容易触发抑制，导致报文被丢弃。解决方案是改用单播，或者调高风暴抑制阈值。
第二个坑是交换机端口隔离。有些交换机默认开启了端口隔离，设备之间不能直接通信，只能和上行口通信。如果上位机接在另一个交换机上，可能收不到设备响应。这个坑很隐蔽，因为ping得通，但UDP/TCP报文就是过不去。检查交换机的端口隔离配置，关闭或者把上位机端口加入隔离例外。
第三个坑是网线质量。工业现场电磁干扰大，劣质网线的误码率很高。TCP有重传机制，误码导致的丢包会被重传弥补，但UDP没有重传，误码直接表现为丢包。我遇到过一根网线导致某台设备丢包率高达10%，换了屏蔽网线后降到0.1%以下。
5.4 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| UDP丢包集中在轮询末尾 | 设备接收缓冲区满 | 检查设备协议栈接收计数 | 调大接收缓冲区，降低轮询频率 |
| TCP延迟随设备数线性增长 | 连接数过多，协议栈开销大 | perf top看CPU热点 | 减少连接数，用单元标识符复用连接 |
| 丢包率突然飙升 | 网络中有广播风暴 | 抓包看广播报文比例 | 改用单播，检查风暴抑制配置 |
| 部分设备始终丢包 | 网线或端口故障 | 换端口、换网线测试 | 更换屏蔽网线，检查端口错误计数 |
| UDP校验和错误丢包 | 设备端校验和计算bug | 关闭校验和检查验证 | 修复设备端校验和计算代码 |
| TCP连接频繁断开重连 | Keep-Alive超时太短 | 抓包看Keep-Alive间隔 | 调大Keep-Alive超时，检查网络稳定性 |
6. 最终方案选型与落地建议
6.1 什么场景选UDP，什么场景选TCP
经过这一轮测试，我的结论是：没有绝对的好坏，只有适不适合。
选UDP的场景：设备数量多（超过200台），轮询频率高（每秒一轮或更快），数据允许偶尔丢失（温湿度、光照、土壤湿度这类缓变数据），设备端资源有限（MCU内存小，跑不动完整TCP协议栈）。UDP方案需要应用层自己做序列号、重传、心跳，但这些逻辑不复杂，几百行代码就能搞定。
选TCP的场景：设备数量少（100台以内），轮询频率低（几秒一轮），数据不允许丢失（电表读数、流量计累积量这类需要精确统计的数据），设备端资源充足（能跑完整TCP协议栈）。TCP方案开发简单，不需要自己处理重传和顺序，但要注意连接数过多带来的性能问题。
还有一个折中方案：UDP加应用层可靠传输。用UDP传输，但在应用层实现确认和重传机制，相当于在UDP上做一个轻量级的可靠层。这个方案兼顾了UDP的低开销和TCP的可靠性，但开发工作量比纯UDP大，需要仔细设计重传策略和超时参数。
6.2 高并发轮询的参数调优清单
不管你选UDP还是TCP，下面这些参数都值得调一遍。
UDP侧：SO_RCVBUF和SO_SNDBUF调到系统允许的最大值，Linux默认的接收缓冲区是212992字节，可以调到几兆。设备端的协议栈接收缓冲区也要调大，ESP32-S3的CONFIG_LWIP_UDP_RECVMBOX_SIZE从6调到16。轮询间隔不要设得太短，给设备端留出处理时间，实测下来500毫秒到1秒比较合适。
TCP侧：TCP_NODELAY设为1，禁用Nagle算法。SO_KEEPALIVE设为1，但Keep-Alive间隔不要设太短，60秒比较合适。TCP_FASTOPEN如果设备端支持就开启，能减少握手开销。连接数尽量控制在200以内，超过就用单元标识符复用连接。
网络侧：交换机开启IGMP Snooping（如果用了组播），关闭不必要的风暴抑制，端口速率和双工模式强制设为100M全双工，不要用自动协商。网线用Cat5e以上屏蔽线，长度不要超过80米。
6.3 我踩过的坑和最后的经验总结
最后分享几个我在实际项目中踩过的坑，希望能帮你少走弯路。
第一个坑是过度追求低丢包率。一开始我非要做到零丢包，调了半天参数，最后发现温湿度数据丢一两个包根本不影响业务，曲线用插值补一下就行。后来我把丢包率目标定在1%以内，参数调优的工作量少了一大半。
第二个坑是忽略设备端的处理能力。上位机性能再强，设备端处理不过来照样丢包。ESP32-S3跑UDP服务端，单核处理300个请求每秒已经是极限了，再高就得换更强的MCU或者用多核。选型的时候一定要把设备端的处理能力算进去。
第三个坑是测试环境和现场环境差异太大。实验室里跑得好好的，到现场就翻车。现场有电磁干扰、有温度变化、有交换机配置差异，这些都会影响丢包率。所以测试一定要留足余量，实验室跑300台没问题，现场就按200台设计。
第四个坑是忘了考虑网络抖动。UDP对网络抖动很敏感，交换机队列满了会直接丢包。TCP有拥塞控制，会自适应调整发送速率。如果现场网络质量不稳定，TCP反而更稳。所以选协议之前，先测一下现场的网络抖动情况。
我个人在实际操作中的体会是：先用UDP跑一遍，如果丢包率能接受就用UDP，省事省资源；如果丢包率超标，再考虑TCP或者UDP加可靠层。不要一上来就纠结选哪个，先跑数据，数据会告诉你答案。另外，不管选哪个协议，应用层都要做超时和重试，这是最后的兜底保障。
