视频流上的TCP与UDP

Question

我刚从网络编程的考试中回到家，他们问我们的一个问题是“如果要播放视频，你会使用TCP还是UDP？为两个存储的视频提供解释和直播视频流“。对于这个问题，他们只是简单地期望存储视频的TCP简短回答和实时视频的UDP，但我在回家的路上想到了这一点，并且使用UDP流媒体直播视频一定更好吗？我的意思是，如果你有足够的带宽，并说你正在播放足球比赛或音乐会，你真的需要使用UDP吗？

让我们说，当你正在播放这场音乐会或任何使用TCP的音乐会时，你会开始丢失数据包（在你和发送者之间的某个网络中发生了一些不好的事情），并且整整一分钟你都没有得到任何数据包。视频流将暂停，一分钟后，数据包开始再次通过（IP为您找到了新的路由）。然后会发生什么是TCP会在您丢失的那一刻重新传输并继续向您发送实时流。假设带宽高于流上的比特率，并且ping不是太高，所以在很短的时间内，丢失的那一分钟将作为流的缓冲区，这样，如果再次发生丢包，你将不会注意到。

现在，我可以想到一些设备，这不是一个好主意，例如视频会议，你需要总是在流的末尾，因为延迟在视频聊天期间是非常可怕的，但在足球比赛或音乐会期间，如果你在流后面一分钟，那有什么关系呢？此外，您可以保证获得所有数据，最好保存以供日后查看，而不会出现任何错误。

所以这让我想到了我的问题。关于使用TCP进行直播，我不知道有什么缺点吗？或者它应该是真的，如果你有它的带宽你应该去TCP，因为它对网络“更好”（流量控制）？

Answer 1

使用TCP进行实时视频的缺点：

1. 通常，实时视频流设备的设计不考虑TCP流。如果使用TCP，则操作系统必须为每个客户端缓冲未确认的段。这是不可取的，特别是在直播活动的情况下;据推测，由于事件的特殊性，您的同时客户名单很长。预先录制的视频广播通常没有这么多的问题，因为观众错开了他们的重播活动;因此TCP更适合重播视频点播。
2. IP多播大大降低了大量受众的视频带宽需求; TCP阻止使用IP多播，但UDP非常适合IP多播。
3. 直播视频通常是从相机录制的恒定带宽流;预录制的视频流脱离磁盘。当源流处于恒定带宽时（如实况事件会发生的那样），TCP的丢失 - 回退动态使得更难以提供实时视频。如果从相机缓冲到磁盘，请确保有足够的缓冲区用于不可预测的网络事件和可变的TCP发送/退避速率。 UDP为此应用程序提供了更多控制，因为UDP不关心网络传输层丢弃。

仅供参考，在描述网络时请不要使用“包”这个词。网络发送“数据包”。

Answer 2

  

但是在足球比赛期间，或者是   音乐会，如果你有什么关系   在流后面一分钟？

对一些球迷来说，相当多。有人指出，由于编码（或其他），数字视频流中存在的几秒钟的延迟可能会非常烦人，因为在世界杯比赛等高调事件中，您可以听到来自这些人的欢呼声和呻吟声。隔壁（他们正在观看一个未经训练的模拟程序），然后才能看到导致他们的游戏动作。

我认为对于那些关心体育运动的人来说（这是最大的数字电视付费用户群，至少在德国这里），在实时视频流中落后一分钟是完全不可接受的（如，如果没有这种情况，他们会转向你的竞争对手。）

Answer 3

通常视频流有点容错。因此，如果某些软件包丢失（例如，由于某些路由器正在过载），那么它仍然能够显示内容，但质量会降低。

如果你的直播流使用的是TCP / IP，则强制等待之前删除的 它可以继续处理更新的数据。

这是双重的坏事：

• 旧数据被重新传输（可能是已经显示的帧，因此毫无价值）和
• 在重新传输旧数据之后
之前，新数据无法到达

如果您的目标是尽可能显示最新信息（对于直播，您通常希望是最新的，即使您的帧看起来有点糟糕），那么TCP也能正常工作反对你。

对于录制的流，情况略有不同：你可能会缓慢更多（可能是几分钟！），并且宁愿重新传输数据而不是由于丢失包而产生一些工件。在这种情况下，TCP是一个很好的匹配（当然，这仍然可以在UDP中实现，但TCP没有与实时流案例一样多的缺点）。

Answer 4

有一些适用于UDP传输的用例和其他适合TCP传输的用例。

用例还规定了视频的编码设置。广播足球比赛的重点是质量，视频会议的重点是延迟。

使用多播向您的客户提供视频时，会使用UDP。

多播的要求是广播服务器和客户之间昂贵的网络硬件。实际上，这意味着如果您的公司拥有网络基础设施，您可以使用UDP和多播进行实时视频流。即使这样，服务质量也会被用来标记视频数据包并对它们进行优先级排序，以免丢包。

多播将简化广播软件，因为网络硬件将处理向客户分发数据包。客户订阅多播信道，网络将重新配置以将数据包路由到新订户。默认情况下，所有客户都可以使用所有渠道，并且可以进行最佳路由。

此工作流程会对授权过程造成不足。网络硬件不会将订阅用户与其他用户区分开来。授权的解决方案是加密视频内容，并在订阅有效时在播放器软件中启用解密。

单播（TCP）工作流允许服务器检查客户端的凭据，并且只允许有效的订阅。甚至只允许一定数量的同时连接。

未通过互联网启用多播。

要通过互联网传送视频，必须使用TCP。当使用UDP时，开发人员最终重新实现分组重传，例如。 Bittorrent p2p live protocol。

  

＆＃34;如果使用TCP，操作系统必须为每个客户端缓冲未确认的段。这是不可取的，特别是在直播活动的情况下＃34;

此缓冲区必须以某种形式存在。对于玩家方的抖动缓冲区也是如此。它被称为＆＃34;套接字缓冲区＆＃34;和服务器软件可以知道此缓冲区何时已满并丢弃实时流的正确视频帧。最好使用单播/ TCP方法，因为服务器软件可以实现正确的帧丢弃逻辑。 UDP情况下随机丢失的数据包只会造成糟糕的用户体验。就像在这个视频中一样：http://tinypic.com/r/2qn89xz/9

  

＆＃34; IP多播大大降低了大量受众的视频带宽需求。

私有网络也是如此，未通过互联网启用多播。

  

＆＃34;请注意，如果TCP丢失了太多数据包，则连接会中断;因此，UDP可以为此应用程序提供更多控制，因为UDP并不关心网络传输层丢弃。＆＃34;

UDP也不关心丢弃整个帧或帧组，因此它无法再对用户体验进行控制。

  

＆＃34;通常视频流有点容错＆＃34;

编码视频不容错。当通过不可靠的传输进行传输时，向视频容器添加前向纠错。很好的例子是用于卫星视频广播的MPEG-TS容器，其携带多个音频，视频，EPG等流。这是必要的，因为卫星链路不是双工通信，这意味着接收器不能请求重传丢失的分组。

当您有双工通信时，最好只将数据重新传输到丢包的客户端，然后在发送给所有客户端的流中包含前向纠错的开销。

在任何情况下，丢失的数据包都是不可接受的。在带宽受阻的特殊情况下，丢帧是可以的。

丢失数据包的结果是像这样的工件：

某些解码器可能会在关键位置丢失丢失数据包的流。

Answer 5

我建议您查看新的p2p live protocol Bittorent Live。

至于流媒体，最好使用UDP，首先是因为它降低了服务器的负载，但主要是因为你可以发送带有多播的数据包，这比发送到每个连接的客户端更简单。

Answer 6

这取决于。你流媒体的内容有多重要？如果关键使用TCP。这可能会导致带宽，视频质量问题（您可能必须使用较低的质量来处理延迟）和延迟。但如果您需要保证内容到达那里，请使用它。

否则UDP应该没有问题，如果流不是关键的，并且因为UDP往往具有较少的开销而优先使用UDP。

Answer 7

在互联网上提供直播活动的最大问题之一是“规模”，而且TCP不能很好地扩展。例如，当您正在为现场足球比赛做准备时 - 与点播电影回放相反 - 观看的人数可以轻松增加1000倍。在这种情况下，使用TCP是CDN（内容传递网络）的死刑。

TCP无法很好地扩展有几个主要原因：

1. TCP的最大权衡之一是发送方和接收方之间可实现的吞吐量的可变性。当通过因特网流式传输视频时，视频分组必须通过因特网遍历多个路由器，这些路由器中的每一个都连接有不同的速度连接。 TCP算法从TCP窗口关闭开始，然后增长直到检测到丢包，丢包被认为是拥塞的标志，TCP通过大幅减小窗口大小来响应它以避免拥塞。因此反过来立即降低有效吞吐量。现在想象一个使用6-7路由器跳转到客户端的TCP传输网络（非常正常的情况），如果任何中间路由器丢失任何数据包，该链路的TCP将降低传输速率。事实上，路由器之间的流量遵循一种沙漏形状;总是在其中一个中间路由器之间上下锣。与尽力而为的UDP相比，渲染有效通过率低得多。

2. 您可能已经知道TCP是一种基于确认的协议。例如，假设发送者距离50ms（即延迟btw两个点）。这意味着将数据包发送到接收器所需的时间和接收器发送确认的时间将是100ms;因此，与基于UDP的传输相比，最大吞吐量已经减半。

3. TCP不支持多播或多播AMT的新兴标准。这意味着CDN没有机会通过复制数据包来减少网络流量 - 当许多客户端正在观看相同的内容时。这本身就是CDN（如Akamai或Level3）不能使用TCP进行实时流的充分理由。

Answer 8

对于视频流，带宽可能是系统的约束。使用多播可以大大减少上游带宽的使用量。使用UDP，您可以轻松地将数据包多播到所有连接的终端。 你也可以使用一个可靠的多播协议，一个称为实用通用多播（PGM），我对它一无所知，我猜它在使用中并不普遍。

Answer 9

在阅读TCP UDP辩论时，我注意到了一个逻辑缺陷。导致转换为一分钟缓冲区的一分钟延迟的TCP数据包丢失与UDP相关，并且在经历相同丢失的同时丢弃整整一分钟。更公平的比较如下。

TCP遇到数据包丢失。 TCP重新发送数据包时，视频停止，以尝试流式传输数学上完美的数据包。视频延迟一分钟，并在丢失数据包到达目的地后从中断处继续。我们都在等，但我们知道我们不会错过任何一个像素。

UDP遇到数据包丢失。在视频流中的一秒钟，屏幕的一角变得有点模糊。没有人注意到，节目继续播放，没有找到丢失的数据包。

任何流都可以从UDP获得最大收益。导致TCP延迟一分钟的数据包丢失不会导致UDP延迟一分钟。考虑到大多数系统使用多个分辨率流，在使数据包饥饿时会出现问题，因此使用UDP会更有意义。

流式传输时的UDP FTW。

Answer 10

如果带宽远高于比特率，我建议使用TCP进行单播直播视频流。

情况1：连续数据包会在几秒钟内丢失。 =＆GT;无论传输层是什么（TCP或UDP），实时视频都将在客户端停止。当网络恢复时： - 如果使用TCP，客户端视频播放器可以选择在第一个数据包丢失（时移）时重新启动流，或者删除所有延迟数据包并重新启动视频流而不进行时移。 - 如果使用UDP，则在客户端没有选择，视频重启没有任何时间转换。 =＆GT; TCP等于或更好。

案例2：某些数据包随机丢失并经常在网络上丢失。 - 如果使用TCP，这些数据包将立即重传，并且具有正确的抖动缓冲区，对视频流质量/延迟不会产生任何影响。 - 如果使用UDP，视频质量将会很差。 =＆GT; TCP好多了

Answer 11

除了所有其他原因，UDP可以使用多播。支持1000个TCP用户都传输相同的数据会浪费带宽。 但是，使用TCP还有另一个重要原因。

TCP可以更轻松地通过防火墙和NAT。根据您的NAT和运营商，由于UDP打孔问题，您甚至可能无法接收UDP流。

Answer 12

所有'使用UDP'答案都假定一个开放的网络并且“尽可能多地填充它”。适合旧式封闭式花园专用音频/视频网络，这是一种消失的类型。

在现实世界中，您的传输将通过防火墙（将丢弃多播，有时甚至是udp），网络与其他更重要的（$$$）应用共享，因此您想要惩罚有窗口缩放的滥用者。

Answer 13

这就是事情，它更多的是内容问题，而不是时间问题。 TCP协议要求必须检查，验证和重新传递未传递的数据包。 UDP不使用此要求。因此，如果您发送的文件包含使用UDP的数百万个数据包（如视频），如果某些数据包在发送时丢失，则很可能会被忽略。