技术论坛

 UDP的可靠传输与应用

返回主题列表
作者 主题
宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
楼主    2021-08-28 23:29:00
主题:UDP的可靠传输与应用 精华帖  精编帖 

与TCP对比,UDP没有底层通道维护。也因此带来特点和灵活性。

  • 数据只在变化的时候需要传输,而很多数据的变化没那么频繁。这就为不需要始终维护一个TCP连接提供了理由。网络中充斥大量不可控或无效报文并不好。

  • UDP会带来以太网的底层报文由自己控制而避免拥堵。节省带宽给其它应用。同时有网络抓包分析调试的便利。

  • 数据传输的可靠,在于报文的时间特征和身份特征。在报文中携带一个节点的IP地址和端口号要6个字节,携带一个时间戳要12个字节。需要把本地的profinet接口信息读出来。加入其它根据应用所需的验证和登记机制

  • PLC有连接资源限制,UDP也占资源。但好处就是用同一个UDP连接资源,不用重建,通信对方可以变化、不特定或同时有多个对方。这为同一网段的任意多个PLC相互通信,但又不占用更多连接资源,带来可能。

  • 网络中有多个通信发起方(Master)存在。每个PLC既是Master,又是slave。Master需要2个端口,端口1用于发送命令,端口2用于接收回复。Slave也需要2个端口,端口3用于接收命令,端口4用于发送回复

  • Master维护一个在线节点的列表,有哪些在线,下线,新增了哪些。通过正常通信或空闲心跳可以确认。

  • UDP单包最大1472字节。UDP包含反码求和检验,虽然简单,基本够用。


Zane
版主

经验值:75765
发帖数:19245
精华帖:376
1楼    2021-08-29 10:18:17
精编帖  主题:回复:关于UDP应用

UDP会丟报文,但速度快

Zane 注册自动化系统工程师 Always save before download
yming
至圣

经验值:126309
发帖数:21931
精华帖:822
2楼    2021-08-29 13:03:05
精编帖  主题:回复:关于UDP应用

有一种感觉,感觉UDP应该像流(媒体)传输那样设计。

想想网络多人游戏。如何交互处理的。如何将不同网速的客户端同步的。

服务器、客户端有好多可以借鉴的地方。

学而时习之,不亦说乎?温故而知新,不亦乐乎?
宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
3楼    2021-08-29 20:13:02
精编帖  主题:回复:关于UDP应用

Slave需要回复,往来报文需要有可验证的结构,确认成功或丢包,才可以做到重传,进而知道各节点的在线情况,这是最底层的机制。这之后的数据才是可靠的。然后这种传输机制需要和功能应用层的变化调度做到通用化衔接,基于可靠数据去施展功能,才形成在使用者层面感觉到的稳定靠谱。

宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
5楼    2021-08-30 14:05:50
精编帖  主题:回复:关于UDP应用

现存的基于UDP的可靠传输协议有QUIC、RUDP等。

在PLC中实现UDP的可靠传输,目前FB占工作内存7K。包括了确认机制,超时重传,动态调整RTO,丢包统计、时间分析,单点和组播。发送窗口机制目前用不上。最终封装体现为一个动态的UDP节点队列。

这个节点队列或单个节点,可做为公共资源,封装进设备FB。这个是功能丰富的关键,目前还没做。基于丢包和时间分析,调整设备功能的UDP载荷变化,留待实践成熟。

宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
9楼    2021-09-01 12:40:41
精编帖  主题:回复:关于UDP应用

物理环境造成的丢包对谁都一样,只不过通过代价和开销封装起来,直接看不到罢了。

如果手机在wifi和4G之间切换,基于TCP会掉线,而基于UDP可以做到不掉线。TCP的一些东西有点太老沉重,很多问题。建议了解一下通信的趋势,那些大公司拿UDP在做什么,早已不是陈年的印象了。HTTP/3 是基于UDP,谷歌的Quic,腾讯抖音快手做的一些事情。

UDP是一张白纸,非常单纯的传输层协议。IP是从计算机到计算机,UDP是从端口到端口,非常简洁。很多手段可以在应用层做,可玩性好。

自己做的UDP通信结构已经主体完成,在调试迭代。原本没这个打算,前些日子用UDP跑modbus效果不错,想起来的。

现在采用的Master发命令的UDP报文头是21个字节,后面携带用户数据。Slave应答的报文头是28字节。读、写、心跳都是。

提一嘴,封装UDP报文的时候需要把本地网口IP地址写进去,更多信息如下

其中,MAC地址是排在PN 名称之后,而PN name 的长度是不定的。计算MAC地址起始索引的示意如下。它总是在从1开始的4的倍数+2的位置


宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
10楼    2021-09-01 23:30:29
精编帖  主题:回复:关于UDP应用

测试用的Master端的Retransmisson TimeOut (RTO)设为100ms,RTO可以根据Round-Trip Time (RTT) 动态调整。

重传次数设为2次,首次传送也计入重传数量,做为丢包数据。Slave端同样做重回统计。

节点的丢包统计和RTT统计,用来调整RTO和负荷策略。


每隔一秒钟触发一次UDP通信,Slave不在线



宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
11楼    2021-09-02 15:34:34
精编帖  主题:回复:关于UDP应用

每隔一秒钟触发一次UDP通信,Slave在线。重传次数就为0了



UDP本身的速度是很快的,但是由于收发方都是PLC,所以在PLC之间的通信时间一定受到双方扫描周期的影响、从对RTT的时间统计能看出来。

根据RTT的统计动态调整RTO。当极度压缩RTO,就会开始偶尔出现错误和重传。


读写切换


宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
12楼    2021-09-02 15:59:49
精编帖  主题:回复:关于UDP应用

前面测试只是针对UDP可靠传输本身的。UDP的运用效率取决于设备功能的调度。

由于网络中不存在TCP的大量无效包,在应用层面的合理控制下,即使在干扰环境下,可以完全杜绝数据包阻塞。

TCP由于历史原因,可靠传输这件事被固化进了传输层,用户根本无法更改,无法根据自身的场景,建造灵活的运用方式。


宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
13楼    2021-09-04 00:20:25
精编帖  主题:回复:关于UDP应用

测试UDP读写,以每隔500ms进行。

读写都停止的空闲时间,进行间隔2秒一次的心跳监测,探查所有的在线节点。

如果发现新节点,就加入到节点队列中。如果原本在线的节点掉线了,也标识出来。



宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
14楼    2021-09-04 15:40:57
精编帖  主题:回复:UDP的可靠传输与应用

用Wireshark抓包看看网络中的报文情况。


这正是Slave节点以2秒的间隔在回复Master的心跳扫描。随便查看其中一帧报文的内容如下。用户数据长度是68,这正是自定义的Slave应答报文的长度。


当进行读写操作的时候,触发间隔是500ms,速度就明显加快了。


从抓包可以看出,UDP底层网络报文的内容和时序,直接表达了顶层应用的操作意图。从表层用户工艺,直到物理层面的表达是透明的,这对解决问题是非常实用和简化的。

这在TCP是不可能的。用户无法控制TCP的传输机制,复杂性和大量无关帧会把工程问题隐藏混淆掉。这是尝试这件事的目的之一。


宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
15楼    2021-09-05 09:49:54
精编帖  主题:回复:UDP的可靠传输与应用

1、 用电脑向Master发出无效UDP帧,电脑被Master识别为无效节点并记录。目的是在一定程度上让每个节点能了解网络中的周边状况。


2、向节点的UDP端口密集快速发送大量UDP恶意干扰帧,能把端口堵死,要重建连接。


3、上述测试用的UDP干扰帧是由以太网调试助手发送的。


宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
16楼    2021-09-05 10:49:20
精编帖  主题:回复:UDP的可靠传输与应用

手上网络抓包用的硬件如下。淘宝二十块钱,简单用还可以,不用接电,携带方便。正经玩儿还得是端口镜像的交换机。买了个8口的,淘宝还没到。


宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
17楼    2021-09-06 11:15:20
精编帖  主题:回复:UDP的可靠传输与应用

一个典型的与单个UDP节点,进行一次通信和回复确认的时序分析如下。如果是组播,接收部分有很大不同。


每个UDP节点根据各自的需求,选择做为Master或Slave或两者同时都是。程序自动根据选择创建不同数量的连接。我目前采用的是Master和Slave各自有两个专用端口,一个发一个收。其实收发用一个端口是完全OK的。


当发生网络UDP风暴,端口阻塞的时候,自动重建连接,恢复正常。


UDP单元对外的功能接口是一个UDP节点。启动通信,读写选择,读写数据交互,执行信息,网络通信质量信息都封装在节点中。设备FB可以通过节点接口与UDP通信衔接交互,控制通信调度。


宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
19楼    2021-09-06 13:43:34
精编帖  主题:回复:UDP的可靠传输与应用

目前是在两个1214C之间测试的。

UDP的Master单元占用工作内存13k,这包括FB代码和实例,全局DB、OB等全部在内。扫描周期3-4ms,支持10个在线UDP节点。一次可以传输40个字节用户数据。帧全长61字节,报文头21开销字节。

UDP的Slave单元占用工作内存也是13K,扫描周期2-3ms。帧全长68字节,报文头28字节。

宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
20楼    2021-09-08 03:01:02
精编帖  主题:回复:UDP的可靠传输与应用

PLC采用UDP,与做为UDP Server的串口服务器通信,是为了和串口设备读写信息。

我是把ModbusRTU报文放进UDP数据包,经过串口服务器和485设备进行Modbus通信。这样的UDP通信,UDP Server会自动做出应答,因而可以确认成败,而Modbus的轮询机制等同于重传,所以这也是一种可靠机制。


1、下图中串口服务器的UDP server的端口是 192.168.1.252: 2000。它的485串口连接了2个modbus设备。PLC有5条指令对这两个设备周期轮询。Modbus读报文的长度都是8。从抓包中可以看到5条读取指令周期循环发送。


2、打开标记为黑色一个UDP报文,在它的数据部分会看到modbus协议的内容:从5号站点读取19个寄存器的数据

这5条命令的内容和在串口监控到的报文是完全对应的


3、UDP Server同样循环恢复应答这5条指令。modbus回复报文的长度不等。


4、打开其中标记为黑色的一个UDP应答报文,会看到串口设备回复的modbus报文:5号站回复了19个寄存器的数据,总共38字节,Modbus报文全长43字节。

这和串口监控的5对问答报文都对上。


5、把PLC网线拔掉,UDP没事。2分钟后再插上,设备立刻恢复轮询OK,根本不用重建UDP连接。这就是无连接通信的好处。


宝冬
奇侠

经验值:9837
发帖数:1491
精华帖:29
21楼    2021-09-08 13:23:37
精编帖  主题:回复:UDP的可靠传输与应用

端口镜像交换机快递到了,就测一下。淘宝120元,千兆8口,1口抓7口。

两个PLC之间UDP通信是非常快的。测试抓包回复平均在7ms。


如果是PLC与串口服务器的UDP Server之间,因为串口端(9600)的往返延迟,就慢多了。最短也80ms,读19个寄存器要150ms。


您收到0封站内信:
×
×
信息提示
很抱歉!您所访问的页面不存在,或网址发生了变化,请稍后再试。