TCP vs. UDP
目录
UDP是GigE Vision标准的选择协议,被所有基于GigE Vision标准的以太网相机所使用。UPD提供了优秀的流性能、低延迟、多播和比TCP更简单的整体设计。UDP是一种无连接协议,在数据传输开始之前,发送设备和接收设备之间不需要握手。它提供了一种更“不干涉”的数据发送方法,因为它没有内置流控制或数据包可靠性。另一方面,TCP是一种面向连接的协议,它必须建立客户端到主机的连接。它还具有内置的可靠性特性,如流控制、包重传和包合并。通常,UDP被设计成专注于速度和简单性,没有TCP的额外特性,而TCP更专注于传输的可靠性。
TCP和UDP概览
TCP | UDP | |
---|---|---|
连接设计 | 面向连接 | 无连接 |
连接握手 | Yes (SYN, SYN-ACK, ACK) | 无, PC机将discovery数据包发送给同一子网内的相机 |
保证帧交付 | Yes | No |
传输方式 | 面向流的 | 数据报 |
数据重传 | Yes(硬件层) | 可选(需要filter driver) |
流控制 | Yes(硬件层) | 可选-包间延迟 |
巨帧 | Yes | Yes |
接收端合并/大包合并 | Yes | No |
Multi-cast | No | Yes |
为什么使用UDP作为GigE Vision标准?
当GigE Vision成立时(2006年),相机供应商选择UDP不仅因为它的高效流性能,而且因为它的简单性。UDP可以快速实现GigE Vision标准,缺失的可靠性特性可以添加到UDP之上,这些特性运行在应用层(运行在软件中,利用主机PC上的CPU资源和相机的固件)。这些可靠性特性对于相机厂商来说也是可选的,如果厂商选择放弃这些特性,那么就更简单了。GigE Vision标准通过定义设备控制、流、发现和特征列表机制,使以太网设备能够使用UDP进行通信:
- GigE视觉控制协议(GVCP)定义了GigE Vision应用程序如何配置和建立对设备的控制。
- GigE视频流协议(GVSP)指定了用于将图像从相机传输到PC的不同数据类型和传输方法,包括一个可选的包重传功能。
- GigE设备发现机制定义了如何在网络中发现设备。
- 一个XML文件包含定义了所有相机功能的GenAPI描述。此描述基于GenICam标准。
相比之下,TCP协议在相机上实现更为复杂,需要更多的相机硬件资源(更大的FPGA空间,更多的板载内存),因为数据包重传等强制性特性必须在硬件层实现。为GigE Vision选择UDP最终允许了相机供应商在他们的以太网相机开发上的灵活性。
10GigE相机使用UDP的挑战
当前在GigE Vision上实现UDP是使用1GigE带宽的想法。如前所述,UDP缺少的可靠性特性被内置到GigE Vision的应用层标准中,这意味着任何使用的可靠性特性都将受到主机上可用CPU资源的数量、相机软件和过滤驱动质量,以及相机的固件在处理额外功能方面有多强大的限制。例如,对于许多相机制造商来说,GigE Vision中的包重传需要在主机PC上有一个专门的软件驱动程序,称为过滤驱动程序,以监视任何丢失的包。当一个丢失的数据包被PC发现时,它向相机发送一个重传请求。然后相机需要解析数据包,这通常发生在相机的固件中,然后从相机的图像缓冲区获取数据包。相机将不得不暂停正常传输,并重新传输所请求的数据包。如果有几个丢失的数据包,散布在整个帧,这可能会加重PC和相机的负担。然而,在1G的速度下,监控和重发丢失数据包所需的CPU和相机资源是很容易获得的。
主机PC处理无序包和丢失包的示例。数据传输由相机制造商提供的过滤驱动程序监控,因为UDP不提供任何内置的可靠性功能。这个驱动程序读取每个包的GVSP头。
LUCID一直致力于优化GigE Vision下的UDP数据传输。我们的过滤驱动程序提供了快速、低延迟和优化的CPU性能,以及所有可选的可靠性特性。为了获得最有效的性能,安装LUCID的过滤驱动程序(LUCIDLwf.sys)可以通过DMA包传输提供快速包监控。例如,在满带宽下同时开流4个Atlas10 10GigE相机只会占用平均8%的CPU资源。
使用LUCID的UDP过滤驱动优化CPU资源,运行多个10GigE Atlas10相机。 这里查看PC规格.
但对于一些10GigE应用程序,特别是那些需要满帧传输为绝对关键的应用程序,GigE Vision UDP技术到达了其极限。10GigE下数据流的巨大增加可能会导致可靠性问题,特别是在主机PC规格不理想的多10GigE相机应用 (请参阅我们的KB文章 “Sample PC Config for Streaming Multiple Atlas10 Cameras”)。由于每个相机要监控的数据多10倍,在一个初始问题导致数据包重传后,主机PC和相机可能会开始陷入挣扎,当CPU太忙而无法处理数据流时,会迫使数据包被丢弃。这将导致坏图或出现图像数据不完整的问题。随着图像传输带宽的增长,丢包的几率也在增加,这就形成了一个恶性循环,因为它不断地从相机请求重发包,CPU占用率也在不断增加。虽然GigE Vision标准在UDP的基础上增加了可靠性特性,但目前使用的UDP和数据包重传可能会导致由于CPU资源耗尽而出现坏图的多米诺效应。
UDP传输下的坏图示例。黑条通常出现在流的开始,因为图像缓冲区还没有被使用(a)。在运动中遭受丢包的场景下将显示前一个图像数据,因为这些是图像缓冲区中的最后一个数据包(b)。
TCP可靠性:从握手开始
与UDP相比,TCP具有内置的可靠性特性,允许以太网相机(包括10GigE相机)保证完整帧传输。请注意,这并不能保证每个帧都被发送,它意味着一个帧(图像)的所有数据包都将被发送。换句话说,应用程序不会遇到损坏的或部分的图像(上面的例子),但如果连接或主机PC出现严重故障,它仍然会遇到丢失的帧。对于需要相机去触发检测的应用,完整的帧交付特别重要。在这些情况下,必须避免丢弃任何可能导致图像损坏的数据包,从而导致OCR误读或目标物检测效果不佳等的问题。与UDP不同,TCP不需要在主机PC上安装过滤驱动程序,并利用网络接口卡(NIC)和相机的FPGA,在硬件级别上管理包重传以及附加的可靠性特性。可靠数据传输的基础始于TCP的三次握手。这个握手创建一个TCP socket连接,预留系统资源,并为数据传输设置TCP窗口大小(缓冲区)。因为它保留了系统资源,所以必须在这些资源用于其他任务之前终止它。
Atlas10 10GigE相机与TCP握手(SYN, SYN-ACK, ACK)建立TCP socket连接,预留系统资源,设置TCP窗口大小(缓冲区)用于数据传输。
一旦在相机和主机PC之间建立了TCP连接,应用程序现在就可以实现更可靠的数据包传输、更高的帧率和始终较低的CPU利用率。这三种优势是通过以下TCP特性实现的:
- TCP流量控制和窗口(硬件级别)
- 包重传(硬件级别)
- 大型接收负载(Linux)和接收端合并(Windows)(两个硬件级别)
TCP流量控制和窗口
TCP流控制
使用TCP,网卡必须向相机发送一个确认包(ACK),以确认它已成功接收到特定数量的数据(字节)。ACK包告诉相机已经接收了多少数据,有多少数据在线路上(在传输中),以及在“滑动窗口”中还有多少空间。ACK帮助相机设置相机的帧率,它可以迫使相机暂停并降低帧率,直到接收到正确的ACK。这被称为流控制,通过将所有积累的数据包存储到TCP滑动窗口和相机的图像缓冲区中,直到网卡准备好,从而提高数据包发送的可靠性。这允许相机和主机PC在硬件级别持续监控连接质量。当网卡被设置为尽量为每个收到的包发送一个ACK时,它可能会根据主机PC的繁忙程度延迟并为多个包发送一个ACK。ACK的发送也不会增加开销或占用相机端的带宽,因为10GigE是全双工。
相机流控制
在相机上,每一帧(图像)在下一帧可以开始卸载到TCP滑动窗口之前,都要从主机PC请求一个ACK。如果主机电脑太忙了,相机上的880MB的Atlas10帧缓冲区会被帧填满,最终相机会掉帧。这会让相机减少数据流,导致帧率变低,直到PC准备好。然而,缺少数据的部分图像将永远不会被发送到主机PC。这是因为相机的帧缓冲区中的最后一帧将会一直被保存,直到相机发送完所有帧的数据包,且主机PC将适当数量的ACK发送回了相机。因为是在相机的FPGA和主机PC的网卡中处理TCP ACK,所以相机的固件不会看到它们。注意,LUCID将TCP ACK频率设置为1,因为这提供了最低的延迟(此设置仅在Windows中可用)。
TCP包重传
TCP包重传与TCP 流控制一起工作,因为它利用ACK来确保包被接收。在主机PC上丢失数据包的情况下,主机将发送三个具有相同确认号的ACK来发起数据包重传。相机也将自动重新发送最后一个数据包,如果“重传计时器”超时后它还没有收到一个ACK的话。主机可以请求TCP窗口中的任何数据。由于包重传由TCP硬件管理,因此不再需要为GigE Vision包重传设置带宽保留(DeviceLinkThroughputReserve)。这将释放大约10%的带宽(使用UDP时LUCID的默认设置),并允许相机达到更高的帧率*(*取决于传感器的最大帧率)。当TCP仍然需要为包重传占用带宽时,带宽的大小由TCP硬件动态调整,不需要用户设置静态的带宽大小。
大接收负载(LRO) /接收端合并(RSC)
Large Receive Offload (LRO, Linux)和Receive Side Coalescing (RSC, Windows)允许网卡将更小的数据包合并成更大的段,从而减少需要由CPU处理的小数据包的数量。当网卡收到数据包时,首先检查它们是否可以合并(正确的顺序、有效的CRC、正确的TCP标志)。如果可以,则保留初始包的报头,但删除接下来包的报头。对于所有进入的数据包,这将持续到中断(中断调节)。包合并不会增加额外的延迟,因为网卡在中断调节时间内合并包。更少但更大的段产生更有效的流。这个概念类似于启用巨型帧和中断调节,这两者都有助于降低CPU利用率。 (见 Tips for reaching maximum frame rate). 数据包合并不可能使用UDP,因为UDP已经定义了每个数据包的开始和结束。但是因为TCP是基于流的,所以没有定义数据的边界。LRO和RSC导致较低的CPU利用率,特别是在10GigE多相机应用程序。这有助于释放CPU资源,允许CPU专注于其他视觉任务,如目标物检测或分类。
上图:Atlas10相机和网卡被设置为16k巨型帧,但由于Linux中的Large Receive Offload,它们被网卡组合成30k(29928)巨帧。这减少了系统需要处理的包段的数量。由于TCP是基于流的,所以只有在TCP中才可能进行包合并。
上图: 4个Atlas10相机以10GigE速度在Ubuntu18.04中运行。在没有LRO开启的情况下,图像采集的CPU占用率为2.2%。
上图: 4个Atlas10相机以10GigE速度在Ubuntu18.04中运行。在LRO开启的情况下,采集图像时CPU占用率约为1.9%。
上图:4个Atlas10相机以10GigE速度在Windows10中运行。在没有RSC开启的情况下,图像采集时CPU占用率约为13%。
上图: 4个Atlas10相机以10GigE速度在Windows10中运行。在RSC开启的情况下,图像采集时CPU占用率约为11%。(See PC specs here.)
结论
LUCID现在在我们的Atlas10 10GigE相机上支持UDP (GigE Vision)和TCP协议。用户可以使用我们的Arena软件开发工具包轻松地在协议之间切换。虽然LUCID的过滤驱动程序极大地优化了UDP以实现快速、低延迟的数据传输,但一些用户可能希望通过选择TCP来优先考虑可靠的完整帧传输。如果在UDP连接下,应用程序正在遭受丢包或较高CPU占用率,TCP可以提供10GigE相机和主机PC之间更可靠的数据传输。TCP的流量控制、包重传和LRO/RSC技术提供了高带宽的图像传输,并保证了完整的帧传输,所有这些都是在硬件级别上操作的。由于LUCID在Atlas10相机上拥有专有的10GigE IP核,LUCID现在支持TCP连接和传统的UDP连接,使用户在构建可靠的10GigE视觉应用程序时有更多的选择。
在ArenaView中从UDP更改为TCP很容易。只要停止获取,改变你的协议,然后重新开始。