那些东西的UDP可靠传输（传输）

您有时间去论坛，发现有关udp可靠传输的讨论再次升温. 有人认为udp高效，有人认为udp丢包和重传机制易于控制，还有一些朋友正在进行极限测试. 当然，有些人出售自己的东西，在这里写一些我的个人看法.

udp的可靠传输实际上非常非常简单. 我于2005年首次接触udp的可靠传输，因为当时开发了FtpAnywhere. 由于路由映射和网关nat处理，我认为udp具有固有的优势，因此我开始写. 我自己的udp可靠传输协议似乎在那时已经过udt. 我也查看了源代码，但是我再也看不到了udp如何保证可靠传输，因为它使用了计时器和跨平台处理，这导致了源代码. 无论如何，我看起来很混乱，无法理解完整的逻辑图. 但是原理基本上与tcp相同，没有什么特别的. 后来，我写了我的第一个udp可靠传输类QTUdp，这是最简单的，也就是说，像tcp一样，它实现2点之间的传输，而不是我现在编写的多点之间的无中心p2p. 传输，效率很高，但是当时我还没有养成当前的编码习惯，从目前的角度来看，很多数据定义（例如DWORD），包括包的定义，都失败了，但是至少它是实用的，并且已集成到FtpAnywhere软件中. 在调试和运行过程中，会慢慢找到udp数据包传输的统计信息和发现，影响最大的部分以及其他一些细节. 后来的ut 1.x多点传输协议是基于QTUdp开发的，直到现在ut 2.x，phoenix 2.x都实现了几次飞跃.

请相信可靠的udp传输永远不会等同于高效可靠的传输. 影响传输效率的最重要因素是sendto函数一次只能传送一个mtu长度的数据包，而频繁的系统调用会极大地影响性能. 在极端性能的情况下，您可以说udp默认情况下可以达到64KB. 您可以交付大包裹. 是的，您可以提供. 但是，由于网络上mtu设备的限制，大型软件包将被拆分为小型软件包. 如果定义的软件包大于mtu，则当任何一个小数据包丢失时，都会导致整个数据包被重新传输. 这种开销非常巨大，尤其是在Internet上，并且使用mtu大小限制内的数据包进行传输. 如果丢失了一个，则只需重新传输. 通过一个要便宜得多. udp可靠传输的自定义验证是另一个限制. 为了避免伪造的udp数据包，我们需要向我们自己的可靠udp数据包中添加自定义验证. 此验证方法也直接影响性能. 最快的crc32检查直接应用. 由于当前的cpu指令集优化了该计算，因此其计算速度几乎是最快的，但代价是人们很容易破解或伪造udp软件包，因为该算法是透明的，并且对过去存在tcp伪造漏洞. 因为其包装组成是透明且开放的，所以唯一的秘密是序列号. 结果，一些系统初始序列号是规则的，这导致安全问题. 最后，发送和接收，因为它是在应用程序层进行的[无论您是否使用api epoll select overlay io，最终执行是在应用程序层]，所以此发送确认过程是因为应用程序层与tcp不同/ ip协议栈它可能以内核模式运行，因此可能会有延迟. 但是，当前CPU内核的数量和频率. 在工业应用（互联网等）中，这种影响几乎可以忽略不计，唯一的影响是在本地极限性能测试中. TCP的效率高于UDP可靠传输的效率，因为它的发送功能几乎每次都可以复制数十KB. 当然，您可以将缓冲区调整得非常大，例如数百KB或MB，但是默认值为几十KB就足够了. 我想调用udp sendto数十次，而tcp只需要调用一次. 其次，tcp数据包处理是在内核状态下执行的，确认也处于内核状态，这足以可靠地与应用程序层udp进行传输. 开放的距离，更不用说硬件层的优化. 因此，您可能会想，为什么书中说udp性能很好？实际上，这是用于不可靠的udp传输，例如，它是大型的Intranet程序包

char buffs [32 * 1024];

memset（buffs，0,32 * 1024）;

sendto（s，buffs，32 * 1024，....不论传输后，是否丢包

如果发送这样的数据包，效率将超过tcp，但主要区别在于数据包报头的大小.

使用udp可靠传输的目的是其灵活性. 在许多协议传输中，例如，远程视频流，jrtlib，通常将其分为关键帧和普通帧. 关键帧的丢失将导致普通帧的丢失. 功能上，这次需要使用udp的可靠传输+不可靠传输，实现方法是先以可靠的方式交付关键帧，关键帧处理完成后，剩下的时间用来交付udp的普通帧. 不可靠模式，每隔指定时间重复一次此过程. 如果使用tcp，则效果不佳，因为网络带宽太大，带宽变化很大，所有关键帧和普通帧都被可靠地传输，这可能会导致流利性，网络拥塞等.

关于udp的穿透能力，即传说中的打孔，这完全是伪命题. 仍然有人在那里进行测试，并说他们已经通过了4种nat模型. 您认为有可能吗？有人用端口猜测的方法允许打孔的方法，可以用在工业上吗？ udp的渗透实际上完全取决于路由[网关]的配置，家庭或soho均已针对p2p进行了调整，但是您使用的设备（例如cisco）来看看该设备. 为了保护安全性对于用户，一般管理员已设置了高度安全性和不透明性. 通常，即使是同一台内部计算机，相同的udp端口，并且将其发送到不同的目标IP数据包，路由也会是随机的. 重新分配端口不会成功. 因此，如果您使用udp进行nat处理，建议您放弃并直接使用tcp + upnp.

关于udp可靠传输的性能，有人说使用epoll，overlay io等比使用select模型更有效. 根据我近年来的开发经验和测试结果，可以在验证模式，交付模式以及相同的数据处理逻辑下，在多核CPU平台下，本地效率差距不超过1％，并且如果在Internet上使用，效率差距将无限接近0. 现在是CPU剩余的时代，在linux Windows的调度下，如果没有内核模式操作，那么将从等待线程中选择一个. 您不应认为从内核模式切换到用户模式不需要任何开销. 此开销也非常大，并且频繁的调度也会影响性能，尽管它不是您的代码包含在系统开销中. 当然，如果您需要同时在linux系统中运行apache之类的Web服务，则效率差距将更加明显，因为进程和线程太多，并且您无法获得第一次调度.

关于可靠udp传输下缓冲区的大小，老实说，这是我的第一次经验. 最简单的点对点udp可靠传输是有人打开了数百KB的缓冲区. 缓冲是一件好事. 通常，缓冲区越大，效率越高. 更高，因为一次传送的数据包数量很多，IO性能也很高，但是Internet上不主张这样做，我不知道此实现是否经过严格的网络数据包丢失和负载测试，并且用于家庭路由的带宽很小在上载模式下，如果有多个人或多个网络程序使用带宽，则此延迟参数会非常频繁地更改udp如何保证可靠传输，并且不必要的重传率将非常高. 最简单的测试方法是找到一个铜包层铝网线并使用1 1对应. 这种非标准的连接器方法是，一端连接计算机，另一端连接路由，然后在Internet上与远程端进行测试. 据估计，丢包和重传的可能性将令人恐惧.

Udp可靠传输比TCP的慢启动好吗？我认为不一样. 我仍然使用上面的网络电缆进行测试. 如果使用快速启动，则在丢包严重的网络环境中，带宽的浪费太可笑了. 我调整自己. udp可靠传输启动方法已经使用了很多次，我觉得tcp的启动很慢是很合理的. 尽管恢复速度很慢，但是由于错误重传而造成的带宽浪费非常小. 当然，如果考虑到这一点，仍然可以快速调整性能.

关于udp可靠传输的文件传输效率，这是一个伪命题. 此限制是由硬件本身引起的. 首先，普通的udp可靠传输效率肯定高于普通硬盘的读写速度，也就是说，使用内存映射技术文件执行速度仍然无法跟上udp本身的速度. 其次，文件传输协议会影响传输效率. 什么是最快的模式？就像流式传输[FTP数据连接HTTP]一样，它是从头到尾直接发送文件，这是最快的，但是通常为了避免数据错误，文件传输的内容将以块的形式传输，并且验证已添加. 这影响了传输效率. 您说公交车从头到尾都快吗？还是快停一站？显然，第一个假设偏离了现实.

关于udp可靠传输和cpu之间的关系，在哪里？当然，但是在普通应用下，基本上没有影响. 仅当达到极限时（例如本地测试，2G +光学焊接网络等），才会产生重大影响. 但是，问题是，如果您的服务器[计算机]连接到2G +光学焊料，则您的硬件配置是什么服务器需要吗？在一般应用中，CPU和内存开销以及不正确的数据包丢失和重传是头等大事. . 如果要可靠地传输udp，则它必须在100mbps网络下具有Intel piii 1Ghz或更高版本，因此在此基础上开发的应用程序可能比当前的计算机游戏更为残酷. 如果不是多对多[因为此逻辑比普通点对点udp可靠传输太复杂]，则普通点对点udp可靠传输到一些先前的测试数据QtUdp，环境是Pentium M 1.7G [单核]，Ati xpress主板768m ddr2 533 [单通道]，机器仿真当时传输的数据约为78MB / s，MTU = 1380，缓冲区为17 * MTU. ，CPU开销大约为75％，如果使用当前的双核，则估计可以翻倍. 您可能会认为此数字太低，但是请注意当时的硬件环境，该速度比udt好得多. 最基本的点对点UDP可靠传输，标准crc32验证，具有当前的硬件环境，i74内核，DDR3 1600，再加上我们的特殊封装处理技术之一，UDP小数据包[1400]的可靠传输限制该机器的速度约为270MB / s. 如果需要改进，估计它只能与MS IIS相同. 编写了网络驱动程序，但是x86处理器和内存速度始终在提高. 也许明天主频率会加倍...

事实上，我转向UDP可靠传输的一个非常重要的原因是IPV6取消了传输中ip层的数据验证，这导致tcp层完全承担了数据验证任务. TCP数据仍然像IPV4一样吗？可靠，您需要添加一个问号. 尽管IP层本身的错误率非常低，但是直接取消验证的风险尚未通过实践评估，ipv6实验网络获得的理论结果是，也许有一天会有突破IPV6 TCP伪造技术. 如果您使用udp可靠传输，因为udp本身具有检查功能，加上我们自己设计的校验和序列号，那么此可靠性级别将完全超过IPV4 TCP，更不用说IPV6下的TCP.

Udp可靠的传输实际上非常简单. 只要您有tcp / ip的基础，最简单的点对点Udp可靠传输就很容易编写. 它只不过是数据包，检查，发送，确认，重新分组，并且接口可以模仿tcp的多种功能，困难之一是判断是否需要重新传输它. 这需要根据前一包的确认时间来推断. 如果不想太复杂，也可以使用经验编号（不适合从网通到电信），第一次重传时间为750毫秒，第二次重传时间为1600，之后的每次重传时间为2000. 不科学的是，使用此延迟数可以保证您有足够的传输效率[即使丢包的可能性很小]，也不会产生很多重传，当然，最好的方法是从先前数据包的延迟中得出.

简而言之，udp可靠的传输并不是那么复杂和神秘，它非常简单，其效率也没有您想象的那么高，可能会让每个人失望，但是，它很可爱，您可以随意塑造自己包，以实现各种扩展，明智的选择就在其中.

发件人:

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-243004-1.html