3、TCP/IP协议栈精讲:四层模型、IP地址与子网划分、三次握手与四次挥手、UDP与TCP选型、工业场景优化

各位好,我是老张。今天咱们聊聊TCP/IP协议栈。说实话,这玩意儿在工业网络里,就像人的骨架一样——平时看不见,但少了它绝对不行。很多搞数控的兄弟觉得协议栈是IT的事,其实不然。你调试一台五轴机床,数据传着传着就断了,十有八九是协议栈没配好。

我个人的习惯是,不管项目多急,先把协议栈理清楚。否则后面排查问题,你会想砸电脑的。

3.1 TCP/IP四层模型:别被七层吓到

很多人一听到OSI七层模型就头大。其实在工业现场,我们真正打交道的是TCP/IP四层模型。说白了,它就是简化版的OSI,把会话层、表示层、应用层合并了。

四层分别是:

  • 应用层:你写的Modbus TCP、PROFINET、EtherCAT报文,都在这一层。我见过有人把应用层数据直接塞到链路层,结果设备根本不认。
  • 传输层:TCP和UDP的老家。负责数据可靠传输,或者快速传输。
  • 网络层:IP协议在这里。它决定数据包从哪到哪,就像快递的分拣中心。
  • 网络接口层:网卡、网线、交换机。说白了就是物理介质。
我的经验:调试时如果数据不通,先从底层往上查。先看网口灯亮不亮,再看IP能不能ping通,最后才抓包分析应用层。这个顺序能省你半天时间。

3.2 IP地址与子网划分:别让地址冲突坑了你

IP地址,说白了就是设备的门牌号。IPv4是32位,分四段,每段0-255。比如192.168.1.100。但这里有个坑——子网掩码。

子网掩码决定了哪些设备在同一个局域网里。比如掩码是255.255.255.0,那前三位相同(192.168.1.x)的设备才能直接通信。我曾经在一条生产线上,把PLC和HMI配成了不同子网,结果折腾了一下午才发现。

子网划分的核心公式:

网络地址 = IP地址 & 子网掩码
广播地址 = 网络地址 | (~子网掩码)
可用主机数 = 2^(32-掩码位数) - 2

举个例子:IP 192.168.1.100,掩码255.255.255.0(/24)。网络地址是192.168.1.0,广播地址是192.168.1.255,可用主机254个。

避坑指南:我曾经在调试时,把PLC的IP设成了广播地址(比如192.168.1.255),结果整个网络都瘫痪了。记住:广播地址不能分配给设备,网络地址也不能用。

工业场景下,我建议把数控系统、PLC、伺服驱动器放在同一个子网,比如192.168.1.x/24。上位机和MES系统可以放在另一个子网,比如192.168.2.x/24,通过路由器连接。这样既隔离了广播风暴,又保证了实时性。

3.3 TCP三次握手与四次挥手:建立连接的那些事

TCP是面向连接的协议。说白了,就是通信前先打个招呼,确认双方都在线。

三次握手:

  1. 客户端发SYN(同步序列号),说“我要连你”。
  2. 服务器回SYN+ACK,说“收到,我也准备好了”。
  3. 客户端发ACK,说“好,开始传数据”。

为什么是三次?不是两次?你想想看,如果只有两次,服务器发了SYN+ACK后,就认为连接建立了。但客户端可能没收到,或者客户端根本没想连。这样服务器就白等了。三次握手能防止“已失效的连接请求”被服务器误接受。

四次挥手:

  1. 客户端发FIN,说“我发完了”。
  2. 服务器回ACK,说“知道了,但我还有数据要发”。
  3. 服务器发FIN,说“我也发完了”。
  4. 客户端回ACK,说“好,断开”。

这里有个关键点:TIME_WAIT状态。客户端在发完最后一个ACK后,会等待2MSL(最大报文生存时间)才关闭。为什么?因为怕最后一个ACK丢了,服务器会重发FIN。我在项目中遇到过,频繁建立和断开TCP连接时,端口被占满,导致新连接失败。解决办法是调整TIME_WAIT参数,或者用长连接。

工业场景建议:数控系统与上位机之间,尽量用长连接。避免频繁握手挥手,浪费带宽和CPU。我见过一个项目,每100ms就建立一次TCP连接,结果CPU占用率飙到80%。

3.4 UDP与TCP的选型对比:实时性 vs 可靠性

TCP可靠,但慢。UDP快,但可能丢包。在工业现场,怎么选?

特性 TCP UDP
连接方式 面向连接 无连接
可靠性 高(重传、确认) 低(尽力而为)
实时性 低(有延迟) 高(无握手)
适用场景 参数配置、文件传输 实时控制、传感器数据

我个人习惯是:控制类数据用UDP,配置类数据用TCP。比如伺服驱动器的位置指令,必须用UDP,因为延迟超过1ms,机床就可能抖动。而PLC的梯形图下载,用TCP,丢一个字节程序就废了。

但UDP有个问题——没有拥塞控制。如果网络拥堵,UDP会疯狂发包,把带宽占满。我建议在应用层做简单的流量控制,比如每100ms发一包,不要连续发。

3.5 工业场景下的协议优化:让数据跑得更稳

工业网络和办公网络不一样。办公网络丢一个包,网页刷新一下就行。工业网络丢一个包,机床可能撞刀。所以必须优化。

优化点一:调整TCP参数

  • TCP_NODELAY:禁用Nagle算法。Nagle会把小包合并成大包再发,但工业控制需要小包实时发送。我建议在数控系统里开启这个选项。
  • TCP_QUICKACK:快速确认。减少ACK延迟,提高响应速度。
  • 调整缓冲区大小:默认的缓冲区可能太小。我一般设成64KB或更大,避免数据溢出。

优化点二:使用UDP时加应用层确认

UDP不可靠,但你可以自己实现可靠机制。比如每个数据包加一个序列号,接收方收到后回复ACK。如果超时没收到ACK,发送方重传。这就是所谓的“RUDP”(可靠UDP)。我在一个机器人项目中用过,效果不错。

优化点三:避免广播风暴

工业网络里,很多设备会发广播包(比如ARP、DHCP)。如果设备太多,广播包会占满带宽。我建议用VLAN隔离,或者限制广播域大小。一个子网里不要超过50台设备。

我的经验:有一次现场网络卡顿,抓包发现一台交换机在疯狂发STP(生成树协议)报文。原来是环路导致广播风暴。拔掉一根网线,问题解决。所以,网络拓扑一定要设计成树形,避免环路。

优化点四:使用工业以太网协议

标准的TCP/IP协议栈,实时性不够。工业场景常用PROFINET RT、EtherCAT、EtherNet/IP等协议。它们对TCP/IP做了优化,比如:

  • PROFINET RT:使用UDP,但优先级高,延迟小于1ms。
  • EtherCAT:直接修改以太网帧头,跳过TCP/IP,实现微秒级同步。

如果你用标准TCP/IP做实时控制,我建议把网卡中断绑定到特定CPU核心,减少调度延迟。

好了,这一章就讲到这里。TCP/IP协议栈是工业网络的基石,你花时间把它吃透了,后面调试会轻松很多。下一章我们聊聊工业交换机的选型与配置,那又是另一个坑了。