可靠的UDP (RUDP):下一个大的流协议?

我们常常回避IP协议的深度，把应用程序供应商，如微软; Wowza媒体系统有限责任公司; RealNetworks公司.; Adobe系统公司.; and others with more specific skills to deal with the dark art of the network layer for us, 而我们只需要输入服务器名, 点击连接, 然后点击开始.

有一点经验的人可能听说过TCP(传输控制协议)和UDP(用户数据报协议). 它们是在IP链路上运行的传输协议, 它们定义了两种不同的方式通过IP网络路径将数据从一个点发送到另一个点. TCP running over IP is written TCP/IP; UDP in the same format is UDP/IP.

TCP有一组指令来确保每个数据包都能到达它的接收者. 在最基本的形式中，它可以与记录递送相媲美. 然而, 乍一看，“确保信息到达目的地”是发送信息给他人的首要任务, 还有一些额外的注意事项必须注意. 如果使用TCP/IP的网络链路注意到数据包的到达顺序不正确, 然后TCP停止传输, 丢弃任何无序转发的数据包, 发送“回到出错的地方”的信息, 然后再次启动变速器.

如果你有充裕的时间，这很好. 把我的工资信息从我的公司转移到我自己, 说实话，我不在乎这花了一微秒还是一小时, 我要把它做好. TCP在这方面非常出色.

在以视频为中心的服务模型中, 然而, 数据实在太多了，如果有几个数据包没有通过链接，那么在某些情况下，我宁愿跳过这些数据包，继续观看视频的整体流，而不是获取原始源的每个细节. 我们的大脑可以为我们想象视频中跳过的部分，只要它不被不稳定的音频和定格视频分散注意力. 在这种情况下, 可以选择从链接的一端及时发送尽可能多的数据到另一端, 不管有多少能准确通过, 显然是可取的. 对于这种类型的应用程序，UDP是最优的. 如果一个包似乎没有到达, 然后接收者等待一会儿，看看它是否到达——可能就在观看者需要看到视频块的那一刻——以及缓冲区是否到达丢失的数据包应该在的地方, 然后它就会继续下去, 应用程序跳过丢失数据所在的点, 继续到下一个数据包，并保持视频的时基. 你可能会看到闪光或一些人工制品, 但这一刻转瞬即逝，你的大脑很可能会填补空白.

如果这个错误发生在TCP下，那么它可以接受TCP 向上3秒重新协商从丢失点重新开始的序列, 丢弃所有后续数据, 哪些必须重新发送. 仅仅一个丢失的数据包就会导致TCP数据的整个“窗口”被重新发送. 这可能是相当多的数据, particularly when the link is known as a Long Fat Network link (LFN or eLeFaNt; it's true -- Google it!).

所有这些都增加了网络开销和使用该链路的两台计算机的操作开销, 因为CPU和网卡的处理单元必须管理应用程序和这些组件之间的所有重传和同步.

由于这个原因，HTTP(通常是TCP传输)通常会引入启动延迟和播放延迟, 由于媒体播放器需要缓冲超过3秒的播放来管理任何丢失的数据包.

事实上, TCP对所谓的窗口大小非常敏感, 并且知道你们中很少有人会在设置直播Flash流编码时调整贡献feed的窗口大小, 我可以估计，除了那些非常少的人之外，所有人都在浪费您的网络链路中的可用容量. 你可能不在乎. 你使用的链接足够好，可以做任何你想做的事情.

在今天的一次性文化中，“使用和丢弃”和“不修理和再利用”,毫无疑问，大多数流媒体工程师只是耸耸肩，认为从互联网连接中获得更多收益的能力超出了你的控制范围.

例如, 您是否知道，如果您设置的最大传输单元(MTU)——最终您的视频数据包大小——太大，那么网络必须在一个称为碎片的过程中将其分成两部分? 由于几个原因，数据包碎片会对网络性能产生负面影响. 首先，路由器必须执行分片——这是一项昂贵的操作. 第二个, 在执行分片的路由器和目的地之间的路径上的所有路由器都必须携带带有必要的附加报头的附加数据包.

也, 在重传的情况下, 如果发生重传，较大的数据包会增加需要重发的数据量.

另外, 如果你设置的MTU太小，那么你可以在任何一个数据包中传输的数据量就会减少，并且相对地增加了信令开销(关于数据发送的数据)的数量, 相当于实际邮递的地址及包裹追踪服务). 如果您将MTU设置为尽可能小的以太网连接, 您可以发现开销接近所有流量的50%.

UDP提供了一些优于TCP的优点. 但是UDP并不是所有视频传输的万灵药.

你在哪里尝试进行大视频文件传输, UDP应该是一个很大的帮助, 但是它的有损特性对于需要绝对文件完整性的工作流阶段来说是很难接受的. 想象一下，电影公司将主编码转移到LOVEFiLM或Netflix进行发行. 如果传输到LOVEFiLM或Netflix播放丢失了数据包，那么这些服务的每个用户都必须接受降级的主副本作为最好的副本. 事实上, 如果UDP在这些后端工作流中使用, 内容会降低用户的体验，就像历史上磁带到磁带以及其他配音和模拟复制过程一样. 数字媒体将失去其成功的核心要素——完美的复制品质.

让我们回到谁想要降低网络容量效率的问题上:工作室, 播出, 新闻部门, 广播电视中心, 编辑套件都希望他们的视频内容完整/无损, 但他们自然希望在机器之间尽可能快地处理这些数据. 让视频编辑一边喝着咖啡，一边把视频从一个地方转移到另一个地方，效率很低(即使咖啡很好)。.

因为它们不能以有损的方式运行, 这些生产设施是否被TCP所困，以及可靠传输带来的所有固有的低效率? 因为TCP保证了所有的数据从点到点的传输，所以它被称为“可靠的”协议. 在UDP的情况下, 这种可靠性是“留给用户的”,因此，其原生形式的UDP被称为“不可靠”协议.

好消息是，确实有各种“可靠的UDP”协议的形式可供选择, 我们将在本文的其余部分讨论这些问题. 一开始有一件事值得注意, 虽然, 如果你想优化你的工作流程中的链接, 你可以选择稍微难一点的方式，并且付出很少的钱, 或者你也可以用简单的方法，花一大笔钱来找到适合你的解决方案.

可靠的UDP传输可以为企业工作流提供理想的情况——具有高容量吞吐量的好处, 最小的开销, 以及尽可能高的“goodput”(一个很少使用但很有用的术语，指的是可以实际用于应用程序数据的吞吐量部分), 不包括其他开销，例如信号). 在互联网工程任务组(IETF)的世界里, 知识产权标准由此产生, 近30年来，人们在开发可靠的数据传输协议方面做了大量的工作. rfc - 908早在1984年，它就是一个很好的例子.

本质上, RDP (reliable data protocol) was proposed as a transport layer protocol; it was positioned in the stack as a peer to UDP and TCP. 它是作为RFC(征求意见)提出的，但它自己的权利并没有成熟到成为标准. 事实上，在20世纪90年代末，RDP似乎已经被RDP所取代可靠UDP协议(Reliable UDP Protocol), 思科和微软都在各自的堆栈中发布了自己的RUDP版本，用于特定的任务. 可能是因为RUDP实现的“特定于任务”的性质, 虽然, RUDP还没有成为正式的标准, 从未超过“草案”状态.

考虑UDP类型的传输如何工作的一种方法是使用一个基本模型，其中所有数据都以UDP格式发送, 每个丢失的包都被编入索引. 一旦主体转移完成, 接收方向发送方发送索引列表，发送方只重发列表上的数据包. 如你所见, 因为它避免了在丢失的数据包之后立即发送的任何窗口的数据的重传, 这个简单的模型效率更高. 然而, 它不能用于实时数据, 即使对于档案，也必须就发送索引的协议达成一致. 它以结构化的方式响应该请求(这可能导致大量随机寻道磁盘访问), 例如, 如果做得不好).

主要供应商实现是特定于任务的原因有很多. 例如, 在哪里可以使用UDP来避免TCP重传错误后, 如果整个数据必须完美地传递给应用程序, 需要真正理解应用程序.

如果应用程序需要发送控制数据, 对于应用程序来说，拥有在任何时候做出决策所需的所有数据是很重要的. 如果RUDP系统(例如)每5分钟只查找并重新请求所有丢失的数据包(!)，那么缺少数据的逻辑操作可能会被搁置，等待重新请求完成. 如果需要在5分钟内做出控制决策，这可能会破坏应用程序的关键功能.

另一方面, 如果数据是一个大的视频存档，被发送到CDN边缘进行说教, 然后，重传请求可能会在上午进行管理. 因此，重传可能会延迟到整个档案发送完毕, 在几次迭代中只跟踪丢失的数据包，直到所有数据都交付. 因此，在这种情况下，流必须具有一些用户确定的和特定于应用程序的控制.

TCP很简单，因为它可以在所有情况下工作，但也因此效率较低. 另一方面, UDP要么需要它的应用程序对丢失具有弹性，要么应用程序开发人员需要编写一个系统来确保丢失/损坏的数据包被重新传输. 这样的系统实际上是专有的RUDP协议.

有很多这样的东西, 既免费又开源, 每个选项我都会看几个(表1). 使用现有流媒体服务器的大多数人将被绑定到您选择的供应商在其应用程序中提供的流媒体协议. 然而, 对于那些正在开发自己的流媒体应用程序的人, 或者自己定制工作流的各个方面, 这个列表应该是您可以考虑的一些协议的良好开端. 对于那些目前正在使用FTP进行非线性工作流的人来说，它也很有用, 由于大多数非线性系统不像线性或实时流基础设施那样具有相同的阶段到阶段的相互依赖关系，因此交换可能相对简单.

让我们把这个列表压缩一下(我说的是压缩). 请注意，这不是一个全面的选择，而纯粹是一个抽样.

在我看来，首先要探索的是UDP-Lite和数据报拥塞控制协议. 这两个已经成为了IETF的标准, 这意味着跨供应商的操作是可能的(所以你不会被锁定在一个特定的供应商).

表1:可靠UDP传输的选择

RUDP表

DCCP

我们来看看 DCCP 第一个. DCCP为那些有兴趣的人提供了初始代码实现. 从一个广播视频工程师的角度来看, 对于低级软件程序员来说，这是非常深奥的技术问题. 然而，如果你碰巧是

(或者只是能够接触到)这种技能水平的工程师，那么DCCP是免费的. 如果您正在使用共享网络基础设施(而不是私有或租用线路连接)，并且希望确保获得UDP所能实现的尽可能多的吞吐量，那么DCCP是一个值得考虑的协议, 同时也要确保你与其他用户“公平竞争”. 值得注意的是，“只是打开UDP”，用UDP数据填充线路，而不考虑线路上的任何其他用户，这会使链路饱和，并有效地使其对其他人不可用. 这就是拥堵, 但DCCP设法尽可能多地填满管道, 同时也允许其他用户使用该线路.

一些关键的DCCP功能包括:

为UDP增加可靠性层
发现正确的MTU大小是协议设计的一部分(因此您可以在填充管道的同时避免碎片)。
拥塞控制

事实上, 引用RFC:“DCCP是为流媒体等应用而设计的，这些应用可以从延迟和可靠的有序交付之间的权衡控制中受益."

UDP-Lite

下一个协议是 UDP-Lite. 也是一个IETF标准, 这个与udp几乎相同的协议在一个关键方面有所不同:它有一个校验和(一个数字，是对所有数据执行逻辑操作的结果), 如果它在传输后不同，则表明数据已损坏)以及该校验和适用的校验和覆盖范围, 而普通UDP——可选在IPv4中, 并且总是在IPv6中——对整个数据报只有一个简单的校验和，如果存在，校验和涵盖了整个有效负载.

让我们简化一下:这意味着在UDP- lite中，您可以将UDP数据报的一部分定义为必须以“完整性”到达的内容," i.e.这是一个必须无差错的部件. 而是数据报的另一部分, 例如，更大的视频数据负载本身, 可能包含错误(对校验和保持未检查)，因为可以假设应用程序(例如, H.264编解码器)具有错误处理或容错功能.

这种UDP-Lite方法非常实用. 在有噪声的网络中链接, 视频数据可能会出现错误，但可能是有效载荷的较大部分, 其中重要的序列号可能只是数据的一小部分(统计上不容易出错). 如果失败，应用程序可以使用UDP-Lite请求重发该数据包. Note that it is up to the application to request the resend; the UDP-Lite protocol simply flags the failure up and the software can prioritize a resend request, 或者，它可以简单地计划解决“丢弃”失败数据的问题. 同样值得注意的是，大多数底层链路层协议，如以太网或类似的基于mac的系统，无论如何都可能丢弃损坏的数据帧，除非有什么东西与那些链路层设备接口. 为了可靠地工作, UDP-Lite需要与网络驱动程序接口来“覆盖”这些帧丢弃. 这增加了部署策略的复杂性，并且很可能使“免费”失去机会.“然而，这从根本上是可能的.

所以我想看看有什么东西是免费的，或者至少是接近免费的. 我去找了一份汇编, 用户友好的, 简单易用的应用程序，具有用户友好的GUI, 考虑到摄像师必须学习所有这些代码和深层数据包的东西，只是为了把视频上传到办公室.

UDPXfer

虽然它本身并不是一个协议，但我发现 UDPXfer，一个非常简单的应用程序，只有UDP“发送”和“侦听器”模式用于文件传输.

我在我的笔记本电脑和一台安装了Amazon EC2的机器上安装了这个软件, 篡改了防火墙, 发送了一个文件. 我对提示5MB UDP文件传输花费2分27秒感到非常兴奋, 然后我在同一个链接上设置了同一个文件的FTP，但令我失望的是，FTP只花了1分50秒——快得多. 然而，当我深入研究时，UDPXfer发送者有一个“每秒数据包”滑块. 然后我把滑块推到最高设置, 但它基本上只有100Kbps的最大值, 比有效的TCP慢得多. 所以我给开发商理查德·斯坦威写了关于天花板的信. 他给我发了一个新版本，可以让我设置每秒1300个数据包的传输速度. 他说这会使我到服务器的IP链路饱和, 在共享网络环境中，更好的方法是调整TCP窗口的大小来实现一些拥塞控制. 他的软件实际上是为了在嘈杂的网络链接上保持弹性而设计的，这会给TCP带来问题.

鉴于我看到这项技术被用在私人线路上, Stanway所关心的有效饱和度在我的企业视频工作流程测试中并不那么重要, 所以我决定试一试新版本. 正如预期的那样，我设法将传输时间降低到1分7秒.

所以，虽然我使用的软件不是通用版本, 显然，实现简单的纯软件UDP传输应用程序是可能的，它可以平衡可靠性和速度，以找到最大的收益.

商业解决方案

但是商业供应商呢? 它们与“免费”的区别是否足以让我把手伸进口袋?

我找到了阿斯帕公司. 和motaama GmbH，我也联系了紫溪. 所有这些软件在最好的情况下也很难获得, 所以遗憾的是，我还没有机会实际使用它们. 也, 供应商不发布费率卡, 所以很难评论他们的定价和价值主张.

粗线在最近的一次亚马逊会议上与我的公司共同展示, 我们有机会深入研究一下它的技术模式. 实际上，aspa在本质上提供了RUDP主题的变体. 它提供了基于这些协议的协议和应用程序，以实现在受控网络链接上的快速文件分发. 在阿斯帕的案例中，它是在背后卖出的亚马逊网络服务直接连接提供最佳的上传速度. 它针对处理大量延迟敏感数据的企业提供了一系列类似的安排. 您可以授权使用该软件或, 通过亚马逊模式, 作为高级AWS服务，按小时付费. 对于偶尔使用的用户来说，这是一个非常灵活的选择.

aspa提供了RUDP主题的变体, 包括fasp 3, 该公司在今年的阿姆斯特丹IBC上推出了这种产品.

我和某公司的首席执行官进行了一次非常有趣的交谈 Motama该公司的产品非常基于家电. 类似rudp的协议(称为RelayCaster流媒体协议或RCSP)被公司内部的设备用于将直播视频从TVCaster发起设备移动到RelayCaster设备. 然后，可以在传统的集线器和辐射式或潜在的其他更复杂的拓扑结构中分层地设置它们. 该软件可以(在许可下)在您选择的服务器平台上运行, 哪种数据中心模型比较好. 他们最近也开始考虑将该协议授权给更广泛的客户端设备, 他们也为自己能买到机顶盒而感到自豪.

Motama

Motama提供了一个基于设备的”方法来实现它的类似rudp的协议, 该协议被称为RelayCaster流媒体协议，可用于机顶盒和CDN许可.

我想说的最后一个参与者是紫溪. 在写这篇文章时，我与紫溪的代表进行了简短的交谈, 我没能在截止日期前好好沟通, 因此，我从该公司的文献资料和一些客户评论中了解到:紫溪提供了一个优化OTT视频传输的平台, 互联网, 以及移动应用程序. 该平台显然提供了比udp优化流媒体更丰富的功能, 它具有P2P协商和传输功能，因此您可以将视频从RTMP等标准转换为MPEG-TS, 就像使用Wowza这样的服务器一样. 在内部, 在自己的生态系统中, 该公司使用自己的混合紫溪协议, 包括前向纠错等功能, 将应用层软件组合在一个名为“广播器”的产品中，该产品看起来像一个具有多个公共互斥器(RTMP)的服务器, HLS, 等.)，其中包括子溪. 如果你有一个编码器与紫溪运行, 然后，您可以使用公司的rudp类型传输直接向服务器提供服务.