这篇文章要聊的TCP和UDP是所有网络通信里绕不开的两个基础协议。不管是浏览器里打开的HTTPS页面还是工厂里那台海康摄像头通过RTSP协议回传的视频流又或者是仓储系统中FX5U PLC通过Modbus TCP上报的运行状态底层跑的都离不开这两个协议族。很多朋友一开始学网络概念都背得滚瓜烂熟——TCP要三次握手、UDP是无连接的——可真到了调试现场就发懵iperf3用UDP打流怎么操作UDP端口能不能像TCP端口那样直接测Java客户端重连怎么老是报“地址已在使用”这篇文章就是把这些问题串起来从原理讲到排障从传输层讲到整个协议家族。适合刚入行的网络工程师、做上位机开发的工控程序员以及所有需要跟网络协议打交道的朋友。全文不会堆术语尽量用大白话把逻辑讲透遇到命令直接给可复制的代码。1. 传输层为什么需要两种模式TCP和UDP的设计初衷1.1 用快递和电话理解TCP与UDP的本质差异先做个思想实验。你寄一封挂号信邮局会给你回执收件人要签字确认中间任何一站丢了快递员会回头去找。这就像TCP——它保证数据一定能到达而且到达的顺序不会乱一个字节都不会少。你打电话也是一样的逻辑先听到“嘟”声对方接起来说“喂”你确认对面有人了才开始说话说完还要说“再见”才挂断。电话和挂号信背后是一套“连接、确认、重传、关闭”的流程代价就是慢每一次传输都有额外开销。再想想发微信语音条或者用对讲机。你把话说出去根本不知道对方有没有听到中间串线了、信号断了你也不知道反正说完就完事。这就是UDP——我不管你到底收没收到我只管把数据报文扔到网络上能多快就多快。用视频会议举个例子如果视频通话走TCP一旦某个画面帧丢了TCP会停下来等重传画面就会卡住、延迟越来越大但走UDP的话丢一帧就跳过去下一帧继续播你看到的效果反而是流畅的。这俩协议没有谁比谁高级只是针对不同问题的两种解法。1.2 端口号、Socket与“连接”的底层语义要理解TCP和UDP必须先搞清楚传输层在TCP/IP协议栈里到底干什么活。网络层IP协议负责把数据从一台主机送到另一台主机它只关心“到哪台机器”。但一台机器上同时跑着几十个程序Web服务器占80端口、数据库占3306、远程桌面占3389数据到了这台机器之后该交给谁这就是传输层的职责——用端口号做进程寻址。端口号是一个0到65535的数字其中0到1023是知名端口比如HTTP的80、HTTPS的443、DNS的53、Modbus TCP的502。一个五元组——源IP、源端口、目的IP、目的端口、传输层协议类型——就能唯一定位一条通信链路。很多人误以为TCP的连接是“拉了一条物理线路”其实不是。TCP的“连接”是通信双方内核里各自维护的一组状态信息包括初始序号ISN、确认号、窗口大小、拥塞控制参数等。三次握手的过程本质上就是双方交换这些初始状态达成一致之后才开始传数据。UDP没有这个过程它不维护任何连接状态发送方拿个端口把数据包扔出去就完事了。这也是为什么UDP常被称为“无连接协议”——不是不能通信而是不需要先建立状态就能通信。2. TCP协议核心机制拆解三次握手、四次挥手与可靠传输2.1 三次握手为什么不多不少正好三次TCP建立连接的过程大家都背过客户端发SYN服务端回SYNACK客户端再回ACK然后连接建立。但很少有人深想为什么是三次而不是两次或者四次。我用一个生活中的场景来类比。假设你要和对面的同事确认协同工作的细节你喊一声“在吗”SYN对方回“在的你那边能听到我吗”SYNACK你回“能听到开始吧”ACK。只有经过这三步双方才能都确认两件事我的发送链路是通的对方的发送链路也是通的。如果只有两次握手客户端发了第一个SYN之后服务端回了一个SYNACK客户端此时能确认自己的发送和接收都正常但服务端无法确认自己发送的数据客户端一定能收到——万一客户端接收有问题服务端就开始发数据就白发了。我再补充一个实际抓包可能会看到的现象。TCP的初始序列号不是从0开始的而是随机生成的这个设计叫ISNInitial Sequence Number随机化。如果ISN固定攻击者可以预测序列号伪造数据注入到连接里。在内核参数里你可以看到这个随机化的逻辑Linux上通过/proc/sys/net/ipv4/tcp_timestamps等参数间接影响。虽然平时做应用层开发不需要直接操作ISN但排查问题时看到seq不是一个简单的1、2、3而是几千万的数字就不用觉得奇怪。三次握手的具体报文序列是这样的客户端发送SYN报文其中seqx。服务端回SYNACK报文其中seqyackx1。客户端发ACK报文其中seqx1acky1。到此连接建立。注意第3步之后客户端其实可以直接在同一个报文里带数据这就是TCP的“捎带数据”特性但不是每次都会出现。2.2 四次挥手与TIME_WAIT状态的真正含义理论考试最爱问“为什么断开连接要四次”。原因很简单TCP连接是双工的数据可以同时双向传输所以关闭也必须两个方向分别关。我们来看实际流程主动关闭方A发送FIN表示“我这边没有数据要发了”。被动关闭方B回ACK表示“收到我也快完了”。B处理完剩余数据后也发FIN表示“我这边也发完了”。A回ACK然后进入TIME_WAIT状态。你会发现第2步和第3步之间往往有间隔因为B可能还有数据要发。这就决定了它没法像三次握手那样把两步合并所以必须四次。有个细节值得展开为什么主动关闭方要等2MSL最长报文段寿命的两倍才进入CLOSED状态MSL就是数据报文在网络上的最大存活时间通常设置为30秒到2分钟。等这个时间有两个目的。第一万一最后一个ACK丢了被动的B会重发FINA必须留着状态能再回一次ACK。第二防止旧连接里的延迟报文出现在新连接里——如果你的连接用了同一个端口旧报文在网络上游荡了一圈突然冒出来内核就会把新连接的数据搞乱。TIME_WAIT就是给网络一个“排空”的时间。实际项目里TIME_WAIT多了会带来麻烦。高并发的服务器上短连接频繁建立和关闭你执行ss -tan会看到大量TIME_WAIT状态的连接占用本地端口。尤其是Java客户端重连时报“地址已在使用”八成就是TIME_WAIT在捣乱我在第5部分会专门展开讲。2.3 重传、快速重传与TCP dup ack机制TCP保证可靠传输的核心手段是“确认重传”。发送方维护一个定时器如果超过重传超时时间RTO还没收到确认就重传数据。但RTO是根据网络往返时延动态计算的如果网络抖动导致某个包延迟到达而不是丢失就会造成不必要的重传白白浪费带宽。所以TCP引入了快速重传机制——不依赖超时而是依靠重复确认来触发。场景是这样的接收方收到seq1和seq3的包中间seq2的包丢了。接收方会发一个ack2的确认意思是“我等的是2”。如果后面又收到了seq4、seq5接收方还是回ack2。当发送方收到3次重复的ack2就立刻知道seq2丢了马上重传它不用等超时。这就是热词里说的“TCP dup ack机制”。抓包的时候你会看到一排ack number相同的TCP ACK报文不用慌张这是TCP正常工作的表现。更常见的现象是TCP重传导致的“网络慢”。有时候应用层感觉很卡抓包一看全是Dup ACK和TCP Retransmission这说明网卡上有丢包、中间交换机缓冲区溢出或者网络里有环路。排查思路一般是先看物理层有没有丢包错误再用netstat -i看接口错误计数最后用抓包确认是单向丢包还是双向丢包。我在第5部分给了完整的排查路径。3. UDP协议实战指南报文结构、iperf3打流与端口探测3.1 UDP报头的8个字节里到底存了什么UDP的报文头简单得让人感动——固定8字节就四个字段源端口2字节、目的端口2字节、报文长度2字节、校验和2字节。相比之下TCP的头至少20字节带选项的话能到60字节。我们掰开揉碎看这几个字段的作用。源端口用来让接收方知道这个包是从哪个程序发来的方便对方原路回复目的端口用来做进程寻址长度字段表示UDP头加上数据的总长度因为IP层已经告诉了我们包的尺寸这个字段其实可以算出来但保留它便于某些情况下做校验校验和用于检测数据在传输过程中有没有损坏。这里有个细节IPv4网络中UDP校验和是可选的IPv6里则是强制的。为什么因为IPv6头没有校验和字段只能靠上层协议来保证完整性。抓包的时候如果看到UDP校验和显示为0x0000不必纠结那可能只是为了减少计算开销。UDP还有一个特性让它比TCP更“轻”没有滑动窗口、没有拥塞控制、没有重传机制。发送方理论上一秒能扔出去几十万个包完全取决于应用层怎么控制节奏。这也是UDP适合实时流媒体的原因——反正我也不指望你确认丢了就丢了下一帧继续。3.2 iperf3使用UDP打流的完整操作网络工程师测试带宽最常用的工具是iperf3。很多人默认用它测TCP因为TCP会自己调整发送速率测出的数值就是实际吞吐量。但如果你想测试网络能承载的极限UDP流量或者想观察网络对UDP的丢包率和抖动就得显式地指定UDP模式。命令很简单# 服务端先跑 iperf3 -s # 客户端UDP打流目标带宽100Mbps持续30秒 iperf3 -c 192.168.1.100 -u -b 100M -t 30-c指定服务端IP-u强制走UDP-b指定目标带宽-t指定持续时间。跑完之后iperf3会输出几项关键数据Jitter抖动即帧间隔的标准差、Lost/Total Datagrams丢了多少个包、总共有多少个包、丢包率百分比。如果丢包率不为0说明链路承载不了你指定的带宽要么降速要么优化网络。还有一个进阶参数值得试试-R表示反向测试客户端变成接收方服务端变成发送方。“双向同时测试”用--bidir两边的流量同时跑。实际排查链路质量时我会建议先在100M带宽下测一轮再在500M、1G下各测一轮对比丢包率。如果丢包率随着带宽上升而明显上升大概率是链路带宽瓶颈如果恒定在高位可能是中间设备转发能力不足。新手容易犯的一个错是忘了UDP测试只反映“尽力传输”的结果它不像TCP那样会自动重传和降速。所以UDP打流测出的丢包率是网络原始质量的直接体现——这也是UDP测试的价值所在。3.3 UDP端口测试方法用nc和tcpdump做探测TCP端口能不能通用一个TCP连接测试就知道了对方会回SYNACK。UDP就没这么方便了——UDP没有握手你发一个包过去对方就算收到了也未必会回任何东西。所以没有万能的“一键测试UDP端口”的命令只能靠一些间接手段。最常用的工具是ncnetcat# 在目标主机上监听UDP端口8888 nc -ul 8888 # 在测试主机上发一条UDP消息给目标端口 echo hello | nc -u -w1 192.168.1.100 8888如果目标主机上用tcpdump能看到包到来就证明UDP端口可达tcpdump -i eth0 udp port 8888还有一种更省事的探测方式是用nmap它对UDP端口做探测会发特殊的UDP报文如果收到ICMP port unreachable回包就说明端口关闭如果收不到任何回包则推测端口是开放的open或filtered。命令是nmap -sU -p 8888 192.168.1.100注意UDP扫描慢、结果不够确定这是UDP协议天生决定的不是工具不够好。我自己的习惯是能直接抓包看就看抓包抓不了包就结合nc -u加应用日志来判断。4. 传输层选型与调试工具箱TCP和UDP怎么用才顺手4.1 选型决策什么场景选TCP什么场景选UDP我做项目这么多年选传输层协议有个朴素的标准——数据丢了能不能接受。如果你传的是文件、数据库写入、HTTP请求任何一个字节丢了都会造成文件损坏或请求失败必须用TCP。如果你传的是音视频帧、游戏人物位置、传感器瞬时采样值丢几个包用户根本没感知而且重传还会引入卡顿就该用UDP。举几个实际案例。MQTT协议用于物联网设备上报数据官方主要运行在TCP之上因为设备状态和控制指令必须可靠到达万一指令丢了灯就没法关这是安全事故。Modbus TCP也是基于TCP的——工控场景里读写PLC寄存器的数据不允许出错Modbus报文本身只有校验和丢了包不会自动补就可能导致产线误判所以依赖TCP的可靠传递。再看RTSP流媒体协议它比较特殊控制信令走TCP媒体数据走UDP或TCP都可以。很多安防厂商在弱网环境下宁可用UDP推流因为视频一帧丢了顶多花屏一下如果是TCP重传整个流都会卡死。一张表帮大家快速决策业务场景推荐协议原因网页浏览、API调用TCPHTTP/HTTPS数据必须完整文件传输、数据库同步TCP字节级可靠性视频会议、直播推流UDP低时延容忍丢帧游戏操作帧同步UDP实时性优先于完整性DNS域名解析UDP一般情况单包请求响应UDP更快设备状态心跳上报UDP丢了下一帧覆盖即可4.2 常用TCP与UDP调试命令速查网上搜“tcp udp调试”会得到一堆零散的命令我整理了一份实测好用的速查表照着敲就行操作Linux命令查看所有TCP监听端口ss -tlnp查看所有UDP监听端口ss -ulnp查看TCP连接状态统计ss -tan查看UDP收发包统计与错误netstat -su测试TCP端口是否通nc -zv 192.168.1.100 80监听TCP端口nc -l 8888监听UDP端口nc -ul 8888抓取指定端口的包tcpdump -i eth0 port 8888抓取指定协议的包tcpdump -i eth0 tcp 或 udp查看UDP丢包计数netstat -su | grep -i drop这些都往熟了记排障时能省一半时间。举个例子服务端端口没起来的时候TCP的nc -zv会立刻告诉你“Connection refused”UDP则不会给你反馈所以要靠tcpdump观察对方有没有发来数据。这种差异本身就是TCP和UDP性格的缩影。4.3 应用层协议背后的传输层选择MQTT、Modbus、RTSP案例分析每次看到有人问“MQTT和TCP有什么关系”我就知道他对协议栈的分层还不太熟。MQTT是应用层协议TCP是传输层协议MQTT的报文是“坐”在TCP报文里传出去的。同样的道理Modbus TCP的数据帧封装在TCP负载里RTSP的消息也可以封装在TCP或UDP负载里。这里特别提一下OPC UA它是工业自动化领域非常重要的通信协议用于连接PLC、传感器、数控机床读取设备运行状态。OPC UA的传输层有两个选择一是UA TCP二进制协议走TCP端口4840二是基于HTTPS暗含TCP。为什么OPC UA要比Modbus复杂那么多因为它的信息模型比Modbus丰富得多要传输复杂的节点结构、报警事件、历史数据可靠性要求极高所以底层必须有一个足够可靠的传输协议来兜底。做工业数据采集的朋友会经常遇到“怎么判断设备是否在线”的需求。上了TCP的协议如Modbus TCP、OPC UA判断的依据就是TCP连接状态——连接断开、超时重连上了UDP的协议比如某些自定义传感器协议判断依据就只能是“连续N个周期没收到数据”。这两种判断逻辑的差异本质上从选协议那一刻就注定了。5. 排障实录TCP与UDP高频问题排查思路5.1 Java TCP客户端重连时“地址已在使用”的完整解法这个坑我前后踩过不下三次。场景是Java写的一个TCP客户端断线之后重新连接明明服务端还在运行客户端却抛异常“java.net.BindException: Address already in use: connect”。网上搜答案十有八九让你设置setReuseAddress(true)但你得先搞清楚这句话是给谁听的。SO_REUSEADDR这个参数默认情况下有个前提条件——它宣称的是“允许重用处于TIME_WAIT状态的本地地址”但Linux上对客户端连接场景还有个限制就是同一个本地端口不能同时绑定到两个不同的远端地址。Java客户端每次new Socket的时候系统会随机分配一个本地端口如果你断线重连非常频繁或者上一次连接的本地端口还没有完全释放还处于TIME_WAIT新连接又恰好随机到同一个端口就会撞上“地址已在使用”。解决办法分两层。最直接的是在连接前设置setReuseAddress(true)Socket socket new Socket(); socket.setReuseAddress(true); socket.connect(new InetSocketAddress(host, port), 3000);但更治本的做法是复用Socket而不是每次都新建。你想想一个长连接应用频繁地断开、重连每一次断开都会产生TIME_WAIT。与其和系统争端口不如维护一个连接池断线只重置当前连接而不是关闭重建。如果服务端也有类似问题可以在服务端listen的socket上设置SO_REUSEADDR这样服务端重启时不会被TIME_WAIT绊住。5.2 TCP dup ack高发背后的隐患排查前文讲了dup ack是TCP快速重传的触发机制但如果你的网络里总是有成片的dup ack就不是正常的“丢包后重传”了。我在一个跨三层设备的数据采集项目里遇到过应用层收到的数据时断时续抓包发现大量重复ACK和Retransmission中间设备的CPU负载高得吓人。排查的步骤我建议按这个顺序走先确认是不是物理链路问题。ethtool -S eth0看rx_errors、tx_errors、rx_dropped字段如果计数在增长先换网线、换光模块。检查交换机端口统计。登录交换机看端口入向/出向有没有丢包——如果接收方向丢包说明上行链路拥塞或交换机缓存不足。查TCP重传的对象。tcpdump抓包里如果重传的是数据包说明发送方向丢包如果重传的是ACK说明返回方向丢包。注意确认是不是网络中间设备比如防火墙、负载均衡器在乱改TCP选项。有些设备会禁用SACK选择性确认导致TCP只能整段重传表现得像大量Dup ACK。说实话这类问题的根源80%都在“链路的某个地方超过带宽极限了”比如流量峰值把交换机缓存塞满。缓解手段很朴素应用层做限速或者在内核调整TCP缓冲区。5.3 UDP丢包率高问题到底出在哪UDP丢包排查有个让人头疼的特点发送方永远不知道自己发的包有没有被丢弃接收方也不会主动上报。我一开始做UDP打流测试的时候也是被这个问题折磨了好一阵。后来总结出一套行之有效的路径。先看接收方操作系统的UDP接收缓冲区有没有溢出netstat -su | grep -i receive buffer errors如果这个数字不断增长说明应用层读取数据的速度跟不上内核接收速度内核直接把新到的UDP报文丢了。解决方法是调大接收缓冲区Linux上可以通过sysctl -w net.core.rmem_max26214400来扩大应用层再用setsockopt设置SO_RCVBUF。再看链路层面。用iperf3的UDP打流测不同带宽档位下的丢包率如果随着-b参数增大丢包率线性上升基本可以判断是链路带宽瓶颈。如果丢包率在低带宽下依然很高就去中间交换机查端口错误计数多半是光模块或者网线问题。还要确认防火墙有没有拦截UDP。很多防火墙默认放行TCP连接但对于UDP只允许特定端口其他一律静默丢弃。用nc -u配合tcpdump一边发UDP包一边看抓包软件里有没有包到达就能快速定位是不是被防火墙拦了。6. 协议家族地图从TCP/IP协议栈拓展到CAN、UART、蓝牙与3GPP6.1 一张分层图看懂TCP/IP协议栈聊到这里我们可以把视野拉高一点看看TCP和UDP在整个协议体系里的位置。经典的TCP/IP四层模型是应用层、传输层、网络层、网络接口层。TCP和UDP都住在传输层下面网络层的IP协议负责寻址和路由上面应用层跑着HTTP、MQTT、Modbus TCP、RTSP这些五花八门的应用协议。很多新手搞不清楚“TCP/IP协议”和“TCP协议”的区别。TCP/IP是一个协议族的总称它包含TCP、UDP、IP、ICMP、ARP等一堆协议而TCP只是其中传输层的一个具体协议。平时说“支持TCP/IP”意思是支持整套互联网通信标准。为什么要先有传输层的TCP/UDP上面才能挂这么多应用协议因为传输层提供统一的“端口”抽象给每个应用一个数字编号让同一台机器上同时跑HTTP和MQTT互不干扰。没有传输层上层每个应用都得自己去处理“多进程复用网络接口”的问题那开发成本就爆炸了。6.2 工业现场总线与硬件接口协议CAN、UART、SPI与Modbus/OPC UA热词里有一大堆跟硬件相关的协议——CAN、UART、SPI、MIPI、CPRI等等初学者容易把它们和TCP/UDP混在一个筐里。实际上这些协议处在完全不同的层级解决的是不同范围的问题。CAN协议是汽车电子和工业控制里最典型的总线协议物理上是一根双绞线属于OSI模型的数据链路层。它传输的是控制报文比如“左前门锁控制”“车门状态反馈”在工厂的锁控板上尤其常见。你通过以太网用Modbus TCP去读一个CAN总线采集器时数据链路可能是这样的传感器数据先走CAN总线到采集器采集器再转成Modbus TCP报文发到上位机。两层协议各司其职。UART是更底层的物理层协议就是串口通信典型的如RS232、RS485。SPI是芯片和芯片之间的板级同步串行总线讲究高速和同步。这些协议跟TCP/UDP没有直接可比性——TCP/UDP解决的是“网络上的两台设备如何可靠通信”而UART/SPI解决的是“芯片引脚上怎么把电平变成字节”。你可以想象成国家级高速公路网和工厂内部传送带的区别不是一个维度的东西。Modbus家族很有意思。Modbus RTU是走串口UART/RS485的Modbus TCP是走以太网的但它们的报文结构基本一样只是承载方式不同。OPC UA则是把设备数据模型化可以跑在TCP上也可以跑在HTTPS上。做工业数据采集项目时最常见的需求就是“用Modbus TCP/OPC UA去读PLC、传感器、数控机床的状态数据”这个“判断设备状态”通常还是要落到TCP连接层面——连接在线就是设备在线连接断了就标记为离线。6.3 移动通信与蓝牙协议栈从3GPP卫星通信到蓝牙Core v5.3再往深走3GPP定义的移动通信协议体系里也有传输层的概念5G核心网里N2、N3接口承载的用户面数据传输本质上也是IP网络上的UDP封装。卫星通信协议同样建立在IP之上协议栈分了控制面、用户面承载方式与TCP/UDP中的UDP天然契合——卫星链路延迟高不适合TCP那种频繁握手确认的方式。蓝牙协议的Core v5.3规范很多人以为蓝牙就是一个简单协议实际它是一整套分层的协议栈。蓝牙BR/EDR和BLE低功耗蓝牙有各自的分层架构上面承载GATT等应用协议底层是射频层、基带层。虽然蓝牙不用TCP/UDP这套体系但它的分层设计思想是一样的链路层负责可靠还是不可靠传输L2CAP层负责分段重组。理解了TCP/UDP再去翻蓝牙协议文档你会发现很多概念是相通的。写到这里我个人的体会是协议的名字可以千变万化但底层的设计逻辑其实高度一致——要么为可靠性牺牲实时性要么为实时性牺牲可靠性中间永远是权衡。我做工控网络最深的感受是一个项目里同时跑Modbus TCP、自定义UDP、CAN总线、蓝牙看起来很复杂但只要心里有一张协议分层地图出了问题就知道该往哪一层去找。下次你抓包看到一堆Dup ACK或者UDP丢包别慌先分清楚是物理层、链路层、还是传输层的问题问题就解决了一半。既然项目里恰好用到了nc -u、iperf3 -u、ss -tan这一组命令建议把这几个命令熟记到肌肉记忆调试网络的时候会顺手很多。