TCP vs. UDP

自从基于以太网的网络出现以来,TCP(传输控制协议)传输层就成为当今Internet和网络通信的主要协议之一。然而,GigE Vision相机使用了一种不同的传输层技术,称为UDP(用户数据报协议)。有史以来第一次LUCID将TCP集成到我们的Atlas10 10GigE相机中。虽然TCP和UDP的主要目标是相同的,即通过网络向设备发送数据,但在如何处理这些数据方面存在显著差异。

If you are looking for detailed instructions on setting up TCP for Atlas10 cameras please visit the following KB articles:
• Using TCP with Atlas10 cameras on Windows
• Using TCP with Atlas10 cameras on Linux
Please note you will need Atlas10 firmware v1.10.0.0 or higher and Arena SDK v1.0.31.5 or higher (Windows) or v0.1.59 or higher (Linux). Visit the Downloads page to get the latest files. (Registration / Log in required)

UDP是GigE Vision标准的选择协议,被所有基于GigE Vision标准的以太网相机所使用。UPD提供了优秀的流性能、低延迟、多播和比TCP更简单的整体设计。UDP是一种无连接协议,在数据传输开始之前,发送设备和接收设备之间不需要握手。它提供了一种更“不干涉”的数据发送方法,因为它没有内置流控制或数据包可靠性。另一方面,TCP是一种面向连接的协议,它必须建立客户端到主机的连接。它还具有内置的可靠性特性,如流控制、包重传和包合并。通常,UDP被设计成专注于速度和简单性,没有TCP的额外特性,而TCP更专注于传输的可靠性。

TCP和UDP概览

 TCPUDP
连接设计面向连接无连接
连接握手Yes (SYN, SYN-ACK, ACK)无, PC机将discovery数据包发送给同一子网内的相机
保证帧交付YesNo
传输方式面向流的数据报
数据重传Yes(硬件层)可选(需要filter driver)
流控制Yes(硬件层)可选-包间延迟
巨帧YesYes
接收端合并/大包合并YesNo
Multi-castNoYes

为什么使用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最终允许了相机供应商在他们的以太网相机开发上的灵活性。

尽管选择了UDP,但相机制造商和客户都明白,数据传输的可靠性不能完全被忽视。GigE Vision标准包括与TCP类似的可靠性特性,这些可选特性被添加到每个数据包的头部。 GigE Vision标准包括带有序列信息的GVSP报头,允许帧的数据包无序发送并在交付后重新排列。如果数据包被丢弃,GVSP报头也有助于数据包的重传。

GVSP Frame

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相机

使用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传输下的坏图示例。黑条通常出现在流的开始

UDP传输下的坏图示例。黑条通常出现在流的开始,因为图像缓冲区还没有被使用(a)。在运动中遭受丢包的场景下将显示前一个图像数据,因为这些是图像缓冲区中的最后一个数据包(b)。

TCP可靠性:从握手开始

与UDP相比,TCP具有内置的可靠性特性,允许以太网相机(包括10GigE相机)保证完整帧传输。请注意,这并不能保证每个帧都被发送,它意味着一个帧(图像)的所有数据包都将被发送。换句话说,应用程序不会遇到损坏的或部分的图像(上面的例子),但如果连接或主机PC出现严重故障,它仍然会遇到丢失的帧。对于需要相机去触发检测的应用,完整的帧交付特别重要。在这些情况下,必须避免丢弃任何可能导致图像损坏的数据包,从而导致OCR误读或目标物检测效果不佳等的问题。与UDP不同,TCP不需要在主机PC上安装过滤驱动程序,并利用网络接口卡(NIC)和相机的FPGA,在硬件级别上管理包重传以及附加的可靠性特性。可靠数据传输的基础始于TCP的三次握手。这个握手创建一个TCP socket连接,预留系统资源,并为数据传输设置TCP窗口大小(缓冲区)。因为它保留了系统资源,所以必须在这些资源用于其他任务之前终止它。

当Atlas10设置为TCP模式时,所有的GVSP数据都以TCP方式发送。然而,GVCP数据仍然通过UDP发送。

GVSP Frame

与使用UDP协议的GVSP不同,使用TCP协议的GVSP每帧只插入一次GVSP报头。这样可以减少开销。UDP是在一帧的所有数据包中插入GVSP报头。

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专注于其他视觉任务,如目标物检测或分类。

大接收负载(LRO) /接收端合并(RSC)

上图:Atlas10相机和网卡被设置为16k巨型帧,但由于Linux中的Large Receive Offload,它们被网卡组合成30k(29928)巨帧。这减少了系统需要处理的包段的数量。由于TCP是基于流的,所以只有在TCP中才可能进行包合并。

4x_ATX_TCP_LRO_Off

上图: 4个Atlas10相机以10GigE速度在Ubuntu18.04中运行。在没有LRO开启的情况下,图像采集的CPU占用率为2.2%。

4x_ATX_TCP_LRO_On

上图: 4个Atlas10相机以10GigE速度在Ubuntu18.04中运行。在LRO开启的情况下,采集图像时CPU占用率约为1.9%。

在没有RSC开启的情况下,图像采集时CPU占用率约为13%。

上图:4个Atlas10相机以10GigE速度在Windows10中运行。在没有RSC开启的情况下,图像采集时CPU占用率约为13%。

在RSC开启的情况下,图像采集时CPU占用率约为11%

上图: 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很容易。

在ArenaView中从UDP更改为TCP很容易。只要停止获取,改变你的协议,然后重新开始。

带TCP的Atlas10摄像机

Atlas10 10GigE 摄像机
Scroll Up