眠子子子做网络通信和工控上位机这几年，我被问得最多的问题就是“TCP和UDP到底有什么区别”。很多人拿到的是教科书答案：TCP可靠、UDP不可靠，TCP慢、UDP快。但真到了现场，设备连不上、数据总丢、延迟忽高忽低的时候，光背这两句话一点用都没有。真正要搞清楚的是：三次握手为什么存在、头部每个字段是干什么的、抓包和压测工具报出来的数据怎么解读、Modbus TCP和FINS UDP这种工业协议为什么分这么细，以及那些看起来莫名其妙的报错到底是谁在捣鬼。
这篇文章我就把TCP和UDP从头到脚拆一遍，从可靠性原理、速度差异、头部结构，到抓包工具使用、带宽测试方法，再到工业现场和物联网场景的选型经验，最后整理一份我自己踩过无数次坑之后的避坑清单。适合刚入门的网络开发、嵌入式开发、上位机工程师，也适合在现场被设备通信折腾到头大的运维和调试人员。
1. TCP和UDP不是“好坏”，是两套完全不同的取舍
先说结论：TCP和UDP不是谁比谁高级，它们解决的是两类不同需求。TCP把自己做成一个“靠谱的邮局”，保证信件不丢、不乱、不重复；UDP把自己做成一个“尽力而为的快递员”，能送就送，路上丢了概不负责。两种设计各有代价，选错代价更大。
1.1 三次握手到底在做什么
TCP建立连接前必须走三次握手。第一次客户端发一个SYN包，告诉服务端“我想建立连接，我的初始序列号是x”；第二次服务端回SYN+ACK，意思是“收到你的请求，我的初始序列号是y，确认收到你的x”；第三次客户端回ACK，确认收到服务端的序列号，连接才建立。
很多人问为什么要三次，两次不行吗？关键原因有两个。一是双方都要确认对方的收发能力正常，同步初始序列号。二是为了防止历史失效连接请求突然到达服务端，白白占用资源。我第一次写Socket程序的时候，天真地以为调个connect就完了，后来抓包看到SYN重传才知道建立连接这个过程背后有这么多讲究。实际工作中，connect超时十有八九出在这个阶段，后面我会细说。
1.2 四次挥手和TIME_WAIT这个绕不过去的话题
断开连接要四次挥手，套路是：A发FIN，B回ACK，B再发FIN，A再回ACK。为什么中间要插一步？因为TCP是全双工的，A说“我发完了”，但B可能还有数据要传给A，所以B先确认A的FIN，等自己数据发完了再发FIN，关闭自己的发送方向。
最后一次ACK发完之后，主动关闭方会进入TIME_WAIT状态，等2MSL（报文最大生存时间，Linux默认60秒左右）才彻底释放端口。这个状态非常坑，尤其是你自己做压测或者写服务端的时候，大量连接一会儿关一会儿开，会堆积大量TIME_WAIT。最典型的现象就是新服务重启的时候报“端口被占用”，其实不是被谁恶意占着，就是上一批连接还没凉透。分布式微服务或者高并发网关里，TIME_WAIT数量过大是个很经典的调优点。
1.3 无连接的UDP：能发就发，别谈感情
UDP没有握手过程，没有确认应答，没有重传机制。把数据报往网络上一扔就完事。好处是延迟低、开销小、吞吐量可以打得很高；坏处是数据可能丢、可能乱序、可能重复到达。
我见过不少初学者第一次用UDP通信，写完代码跑起来发现偶尔收不到数据，第一反应是代码写错了。其实很可能就是UDP在某个环节丢包了。UDP的设计哲学是“我不保证你能收到，但我保证我发送的成本最低”，所以它把可靠性问题留给了上层应用。你必须自己判断哪些数据不能丢、丢了怎么补、乱序怎么排，这个思路和TCP完全不一样。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 头部结构对比：20字节和8字节的背后是两套设计哲学
光说“TCP复杂、UDP简单”太空洞，看头部字段才是硬核理解方式。TCP标准头部20字节，UDP固定8字节。这12字节的差距，藏着一整套可靠性机制。
2.1 TCP包头里的每个字段为什么存在
TCP头部分为几块。前4字节是源端口和目的端口，各占16位，所以端口范围是0到65535。紧接着是32位序列号，这是TCP可靠传输的基石。TCP不是按“包”编号，而是按“字节”编号，每个TCP包里的数据都携带着这段数据的第一个字节在整个字节流里的位置，接收方靠这个把数据拼回原始顺序。
确认号字段表示“我期望收到对方的下一个字节的序号”，也就是告诉对方，之前的数据我都收到了。序列号和确认号配合，才实现了去重、排序、重传确认。接下来是数据偏移、保留位和6个标志位：URG、ACK、PSH、RST、SYN、FIN。SYN用来建立连接，FIN用来释放连接，RST用来异常重置连接，ACK用来确认，PSH提示接收方尽快交给应用层，URG表示有紧急数据。
窗口字段是流量控制的关键。它表示接收方当前还能接收多少字节，发送方根据窗口大小调整发送量。这就是为什么TCP不会把接收方撑爆。计算校验和时，TCP头会带上一个伪头，这个伪头包含源IP、目的IP和协议号，目的是检查数据有没有被路由到错误的目的地。紧急指针在实际业务中用得很少，完整TCP头部可以到60字节，多出来的部分是各种选项字段，比如MSS、时间戳、SACK。
2.2 UDP包头：8个字节里有什么
UDP头部极其精简：源端口16位、目的端口16位、长度16位、校验和16位。长度字段是整个UDP报文（头部加数据）的字节数，最小值是8，也就是只有头没有数据的心跳包。
校验和字段在IPv4下是可选的，但在IPv6下是强制的。UDP校验和同样会覆盖伪头（IP头和协议号），所以就算UDP不做数据完整性保证，它至少能检查出网络传输过程中数据有没有被改坏。但注意，它只能查错，不能纠错，发现错了这个包就丢弃了。
2.3 从UDP包头看它为什么快
UDP没有序列号、没有确认号、没有窗口、没有标志位。这意味着它不需要维护连接状态，不需要等确认，不需要处理重传队列。数据到了直接交给IP层发出去。少了这些环节，处理延迟自然低。而且UDP没有拥塞控制的限制，想打多少带宽就打多少，所以很多人做高吞吐率传输时会倾向于UDP，但代价就是网络一旦拥塞，丢包率飙升，接收方体验会直线下降。
3. 工作中常见的工具实操场景与指标解读
区别讲再多，落到工具上才是真的。很多人卡在抓包和压测工具使用上，我这里把最常见的几个坑一次说清楚。
3.1 Wireshark：为什么加了udp过滤还抓到ICMP
先说结论：Wireshark显示过滤器里输入udp，理论上只会显示UDP报文，不会显示ICMP报文。如果抓包列表里仍然出现ICMP，多半是过滤条件没有真正生效。
我见过有人把“捕获过滤器”和“显示过滤器”搞混了。捕获过滤器是在抓包之前设置，用BPF语法，比如udp或者port 53，它在驱动层面就把非目标包丢弃了。显示过滤器是在抓完包之后再筛选显示内容，只影响你看什么，不影响抓包结果。如果你在显示的过滤栏里输入udp，点右键“应用为显示过滤器”，是不会混入ICMP的。如果还是看到ICMP，检查一下是不是过滤栏里实际输入的是udp or icmp，或者之前的过滤器没有清除干净。
还有一种情况：抓包时开了混杂模式，你看到的是网卡上所有流量，但显示过滤器仍然是生效的。真正排查网络问题的时候，我建议同时抓两把：一把只抓UDP，一把只抓ICMP，看目标主机是不是在发“端口不可达”的ICMP错误。这个错误恰恰能解释一个现象：UDP数据发过去了，但目标端口没进程监听，于是对方内核回了ICMP Port Unreachable，发送方如果开了ICMP监听，会发现UDP数据石沉大海。
3.2 用iperf3做UDP打流：到底该看Sender还是Receiver
iperf3默认用TCP测试，加-u参数就切到UDP。典型命令：服务端iperf3 -s，客户端iperf3 -c 192.168.1.100 -u -b 100M -t 10，意思是向服务器打100Mbps的UDP流量，持续10秒。
测完之后终端会分别打印Sender和Receiver两段结果。只看Sender是很危险的。Sender显示“我发出去100Mbps”，Receiver显示“我只收到85Mbps”，中间的15Mbps就是丢掉的。有人只看Sender那一栏，以为带宽达标，实际接收端早就漏成筛子了。排查链路质量问题，对比两边的速率才是关键。如果Sender和Receiver速率差距很大，优先检查中间交换机端口速率、双工模式、防火墙限制，以及是不是网卡本身处理不过来。
3.3 UDP测试工具和网络调试助手怎么选
UDP不像TCP有明确的连接状态，调试起来很抽象。我习惯用网络调试助手之类工具，一边开UDP监听端口，一边从另一台机器发数据。要注意UDP没有握手，抓包工具里看不到“连接建立”，只能靠收发的数据流判断通信是否正常。
很多调试工具发送的是十六进制报文，这正好匹配工业协议调试场景。比如FINS UDP报文就是十六进制格式，工具里直接填目标IP和端口9600，写好报文，点发送，再看回包。调试UDP时还有个坑：双向通信有时候需要双方都绑定固定端口，否则对端回的数据会发到默认随机端口上。我见过有人在代码里只写了发送方的端口没写接收方的绑定端口，结果回包收不到，还以为是路由器问题。
4. 场景选型：工业、音视频、物联网到底怎么选
平时被问最多的其实是场景选型。很多项目不是“哪个协议先进就选哪个”，而是取决于设备和协议的兼容性、实时性要求、以及现场的调试习惯。
4.1 工业现场最常见的几个协议
Modbus TCP是基于TCP的工业协议，默认端口502。它把Modbus报文套在TCP里面，报头多了一个MBAP头，包含事务ID、协议ID、长度、单元ID。有人问“Modbus TCP怎么实现又读又写”，其实Modbus TCP报文里可以有不同功能码，比如03读保持寄存器、16写多个寄存器。在同一条TCP连接上，请求和响应之间靠事务ID匹配，所以你完全可以在一个连接上交替发读请求和写请求，只要事务ID不冲突就行。
FINS UDP则是欧姆龙PLC常用的方式。它走UDP端口9600，报文自带FINS头，无连接、速度快，但也意味着丢包要应用层自己兜底。用C#、C++或者LabVIEW做上位机时，FINS UDP的典型处理是发送后启动超时定时器，一定时间内没收到回包就重发，重发次数到了就报警。这个“超时+重发”逻辑就是自己实现UDP可靠性。
昆仑通态（MCGS）触摸屏支持TCP自由协议，信捷PLC可以作为Modbus TCP服务器和海康相机通信。这个场景下，PLC做服务器监听502端口，相机或上位机做客户端去连接。要注意的是，海康相机的SDK和PLC的寄存器映射通常是两套东西，实际工程里一般通过相机SDK拿到图像数据，再用上位机从PLC读取状态和控制信号，两边分工明确，而不是PLC直接处理图像数据。
4.2 音视频、游戏和物联网为什么偏爱UDP
音视频通话和实时游戏多数用UDP或者基于UDP改造的协议（比如QUIC），因为这类场景对“实时性”要求高于“绝对可靠”。视频通话里丢一帧画面，最多卡顿一下，但是如果为了补帧等重传，整个通话延迟就会失控。游戏同理，你更不希望按一下W，角色等几百毫秒才动。
物联网场景更复杂。ESP01S这类Wi-Fi模块做TCP连接时，手机端如果没有真正监听端口，或者路由器隔离了客户端之间通信，TCP连接根本建立不起来。UDP则随便发，服务器收不收得到另说，但至少调试门槛低。还要注意Zigbee、LoRa这些无线链路经常出现丢包和抖动，如果应用对数据完整性要求高，就算底层用UDP，应用层也必须设计确认和重传机制。
4.3 WebSocket和TCP的关系
很多人问“TCP和WS有什么区别”。它们不是同一个层次的东西。TCP是传输层协议，WebSocket是应用层协议，WebSocket建立在TCP之上。普通的HTTP是“请求-响应”模式，服务器没法主动向客户端推送数据。WebSocket通过HTTP完成握手后，升级成一条持久化的双向通道，这时候底层的TCP连接一直在，数据可以随时双向流动。
所以“TCP和WS二选一”是不成立的。选的是“用裸TCP自己设计协议，还是用WebSocket复用现成的消息边界和浏览器生态”。在浏览器里做实时通信，WebSocket几乎是唯一选择；在嵌入式设备之间通信，裸TCP更常见，因为开销更小、控制力更强。
5. 真金白银换来的踩坑避坑清单
这一节是我最想写的部分。很多问题本身不复杂，但看不出问题的时候，极其耗时间。
5.1 端口占用：bind错误的几种可能
有次我在本地起服务，怎么都起不来，报错信息是listen tcp 127.0.0.1:11434: bind: only one usage of each socket address，第一反应是端口被占用。排查顺序很简单：先看进程，Windows下netstat -ano | findstr 11434，Linux下ss -lntp | grep 11434，找到占用端口的进程ID，再决定是杀进程还是换端口。
但还有一种隐蔽情况，服务确实退出很久了，端口还是报占用。这就是我之前说的TIME_WAIT或者CLOSE_WAIT状态残留。在Windows上尤其常见，频繁重启服务端程序，端口会被留在TIME_WAIT状态60到120秒。如果程序支持SO_REUSEADDR，可以缓解这个问题。Docker也经常踩这个坑，报ports are not available: exposing port tcp 0.0.0.0:xxxx，大概率是宿主机端口被别的进程占了，列出宿主机端口占用情况，把容器端口映射换掉就好。
5.2 connection reset和connect超时
curl: (35) tcp connection reset by peer是很多后端开发都见过的报错。这个错误意味着TCP连接建立后，服务端直接回了RST包把连接掐断。原因最常见的有几个：服务端口根本没有进程监听，对端的内核会回RST；服务端应用层主动关闭连接；中间防火墙拦截并发送RST；协议版本不兼容导致对端拒绝处理。
还有一个高频报错是docker拉镜像时出现dial tcp ... i/o timeout，这是connect超时。TCP的SYN包发出去了，但对端一直没有回SYN+ACK。通常不是代码问题，而是网络路径上丢包，或者目标IP/端口被防火墙静默丢弃。排查时先ping对端IP，能通再telnet对应端口，一步步缩小范围。
5.3 TCP粘包和UDP丢包乱序
TCP是字节流协议，没有消息边界。发送方调用一次send，接收方不一定正好一次recv就收到同样的数据，可能把两条消息拼在一个包里（粘包），也可能一条消息被拆成几次读（拆包）。解决办法就三招：定长消息、分隔符、长度前缀。我最推荐长度前缀，通用性好，比如前4字节存消息体长度，后面跟实际内容，收的时候先收4字节，再根据长度收剩余部分。
UDP虽然保留了消息边界，不会有粘包问题，但丢包和乱序是它的常态。测试时最直观的方法是每个包编一个序列号，接收方记录收到哪些序号，最终就能算出丢包率和乱序情况。另外UDP报文最大长度受MTU影响，以太网环境下建议数据部分别超过1472字节。非要发更大的包，IP层会分片，但分片包在网络上很容易被丢弃，应用性能反而下降。
5.4 系统缓存区和连接数调优
Windows下UDP系统缓存区默认比较小，高吞吐场景需要手动调大。做法可以修改注册表里的全局UDP缓冲区参数，也可以在代码里用Socket.ReceiveBufferSize和SendBufferSize来增大，但要注意实际生效值受系统上限约束。Linux上则是调/proc/sys/net/core/rmem_default、rmem_max、wmem_default、wmem_max，然后应用层再配合setsockopt设置SO_RCVBUF。
C#做TCP服务端时，连接数量往往受制于系统端口范围、内存和线程模型。几千个连接和高并发请求是两回事，连接建立起来后不活跃，占用的资源很低，只要别用“一个连接一个线程”的老模型就行。用异步Socket编程或者SocketAsyncEventArgs，可以支撑比较大的连接规模。如果发现大量TIME_WAIT，可以调小MSL时间，或者开启连接复用。
而tcp connect超时这类问题，很多时候也是因为端口范围没调大。短连接请求量大的时候，客户端端口不够用，connect就可能一直失败。
做网络通信开发时间长了，最大的感受就是：TCP和UDP不是背概念，而是要根据业务场景和现场环境做权衡。TCP帮你解决了可靠性，你就要接受它的握手时延和头部开销；UDP把控制权交给你，你就要自己承担丢包、乱序、重传这些责任。工具和报错只是表象，真正有用的是你脑子里那套“数据从应用层到网线、再回到应用层”的完整图景。如果你看完这篇文章，能自己定位出一个报错、看懂一张抓包图、选对一次协议，那这篇总结就没白写。