视频流上的TCP与UDP

我刚从网络编程考试中回来，他们问我们的一个问题是“如果要流式传输视频，您将使用TCP还是UDP？对存储的视频和实时视频流进行解释”。对于这个问题，他们只是希望对存储的视频使用TCP做出简短的回答，对实时视频使用UDP做出简短的回答，但是我在回家的路上就想到了这一点，并且使用UDP传输实时视频是否一定更好？我的意思是，如果您有足够的带宽，并且说您正在直播足球比赛或音乐会，那么您真的需要使用UDP吗？

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

现在，我可以想到一些不是一个好主意的设备，例如视频会议，您需要始终处于视频流的结尾，因为视频聊天过程中的延迟太可怕了，但是在足球比赛或音乐会中，如果您落后于直播，那又有什么关系呢？另外，可以确保您获得所有数据，并且最好保存起来以备以后查看，而不会出现任何错误。

因此，这使我想到了问题。使用TCP进行实时流传输是否有我不知道的缺点？还是真的应该这样，如果您有带宽，那么就应该使用TCP，因为它对网络“更小”（流控制）？

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

1. 通常，实时视频流设备在设计时就没有考虑TCP流。如果使用TCP，则操作系统必须为每个客户端缓冲未确认的段。这是不可取的，特别是在现场活动的情况下；由于事件的奇异性，大概您同时在线的客户列表很长。预先录制的视频广播通常不会带来太大的问题，因为观众会错开其重播活动。因此，TCP更适合重播视频点播。
2. IP多播大大降低了大观众的视频带宽需求；TCP阻止使用IP多播，但是UDP非常适合IP多播。
3. 实时视频通常是从摄像机录制的恒定带宽的流。预先录制的视频流从磁盘中取出。当源流处于恒定带宽时（如实况事件那样），TCP的丢失补偿动态特性使提供实况视频变得更加困难。如果要缓冲摄像机的磁盘空间，请确保有足够的缓冲空间以应对不可预测的网络事件和可变的TCP发送/退避速率。由于UDP不在乎网络传输层丢弃，因此UDP为您提供了对该应用程序的更多控制。

仅供参考，在描述网络时，请勿使用“包装”一词。网络发送“数据包”。

但是在足球比赛或音乐会期间，如果您落后于直播，那又有什么关系呢？

对于一些足球迷来说，相当多。已经指出，由于编码（或其他原因）而导致数字视频流中存在几秒钟的延迟，这很烦人，例如在世界杯比赛等备受瞩目的赛事中，您可以听到家伙们的欢呼声和吟声。在您看到导致他们的游戏动作之前，请先隔壁（他们正在观看不需要的模拟程序）。

我认为，对于一个热衷于体育的人（至少在德国，这些人是最大的数字电视付费用户群体），在直播视频流中落后一分钟是完全不可接受的（因为d切换到您的竞争对手（不会发生这种情况）。

通常，视频流具有一定的容错能力。因此，如果某些包丢失了（例如，由于沿途的某些路由器超载），则它仍将能够显示内容，但质量降低。

如果您的实时流使用的是TCP / IP，那么它将被迫等待那些丢弃的包，然后才能继续处理较新的数据。

这是很糟糕的：

• 重新传输旧数据（可能是因为已经显示的帧，因此毫无价值），并且
• 新数据要等到重新传输旧数据后才能到达

如果您的目标是显示尽可能多的最新信息（对于实时流，即使您的帧看起来有些糟糕，通常也希望获得最新信息），那么TCP将对您不利。

对于已记录的流，情况略有不同：您可能会缓冲更多（可能要花几分钟！），并且宁愿重新传输数据，也不会因为丢失包而产生一些伪像。在这种情况下，TCP是一个很好的匹配（当然，它仍然可以在UDP中实现，但是TCP与实时流情况相比没有很多缺点）。

有一些适用于UDP传输的用例，另一些适用于TCP传输的用例。

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

当使用多播向您的客户交付视频时，则使用UDP。

多播的需求是广播服务器和客户之间昂贵的网络硬件。实际上，这意味着如果您的公司拥有网络基础结构，则可以使用UDP和多播进行实时视频流传输。即使这样，服务质量也可以实现，以标记视频数据包并确定其优先级，因此不会发生数据包丢失。

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

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

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

无法通过Internet启用多播。

为了通过互联网传送视频，必须使用TCP。当使用UDP时，开发人员最终会重新实现数据包的重新传输，例如。Bittorrent p2p实时协议。

“如果使用TCP，则操作系统必须为每个客户端缓冲未确认的段。这是不可取的，尤其是在实时事件中”。

该缓冲区必须以某种形式存在。播放器端的抖动缓冲区也是如此。它被称为“套接字缓冲区”，服务器软件可以知道该缓冲区何时已满，并为实时流丢弃适当的视频帧。最好使用单播/ TCP方法，因为服务器软件可以实现适当的丢帧逻辑。在UDP情况下随机丢失数据包只会带来不良的用户体验。就像这个视频一样：http : //tinypic.com/r/2qn89xz/9

“ IP多播大大降低了大观众的视频带宽需求”

对于专用网络，这是正确的，未通过Internet启用多播。

“请注意，如果TCP丢失太多的数据包，则连接会中断；因此，UDP会为您提供对该应用程序的更多控制权，因为UDP并不关心网络传输层的掉落。”

UDP也不关心丢弃整个帧或帧组，因此它不再提供对用户体验的更多控制。

“通常，视频流具有一定的容错能力”

编码视频不是容错的。当通过不可靠的传输进行传输时，则将前向纠错添加到视频容器中。卫星视频广播中使用的MPEG-TS容器就是一个很好的例子，它可以承载多个音频，视频，EPG等流。这是必需的，因为卫星链路不是双工通信，这意味着接收器无法请求重新传输丢失的数据包。

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

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

数据包丢失的结果就是这样的伪像：

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

我建议您查看新的p2p实时协议Bittorent Live。

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

这取决于。您正在流式传输的内容有多重要？如果关键，请使用TCP。这可能会导致带宽，视频质量（您可能必须使用较低的质量来处理延迟）和延迟方面的问题。但是，如果您需要确保内容能够到达的内容，请使用它。

否则，如果流不是很关键，则UDP应该是好的，因为UDP的开销较小，因此它是首选。

在Internet上传递实时事件的最大问题之一是“规模”，而TCP的规模不好。例如，当您在直播足球比赛时（而不是点播电影播放时），观看人数很容易增加了1000倍。在这种情况下，使用TCP是CDN（内容交付网络）的死刑判决。

TCP伸缩性不好的主要原因有两个：

1. TCP最大的折衷之一是在发送方和接收方之间可以实现吞吐量的可变性。通过Internet流式传输视频时，视频数据包必须通过Internet遍历多个路由器，这些路由器中的每一个都以不同的速度连接。TCP算法从TCP窗口较小开始，然后一直增长直到检测到数据包丢失为止，该数据包丢失被视为拥塞的迹象，TCP会通过大幅度减小窗口大小以避免拥塞来对此做出响应。因此依次降低了有效吞吐量。现在想象一下，使用6-7个路由器跳到客户端的TCP传输网络（一种非常正常的情况），如果任何中间路由器丢失任何数据包，则该链路的TCP将降低传输速率。实际上，路由器之间的流量遵循沙漏形状。总是在中间路由器之一之间上下摇摆。与尽力而为的UDP相比，渲染的有效吞吐量要低得多。

2. 您可能已经知道TCP是基于确认的协议。例如，假设一个发送方在50毫秒之内（即，等待时间缩短了两点）。这意味着将数据包发送到接收方和接收方发送确认所需的时间为100毫秒；因此，与基于UDP的传输相比，最大可能的吞吐量已减半。

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

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

TCP发生数据包丢失。在TCP重新发送数据包以尝试流化数学上完美的数据包时，视频将停止。视频被延迟一分钟，并在丢失的数据包到达目的地后从上次停止的地方继续播放。我们都等待着，但是我们知道我们不会错过任何一个像素。

UDP丢包。在视频流中的一秒钟内，屏幕的一角变得有点模糊。没有人注意到，而且节目一直在寻找丢失的数据包。

任何流都将从UDP中获得最大收益。造成TCP一分钟延迟的数据包丢失不会导致UDP一分钟延迟。考虑到大多数系统使用多种分辨率的流，使得在缺少数据包时情况变得混乱，因此使用UDP更有意义。

流式传输时的UDP FTW。

如果带宽远高于比特率，我建议将TCP用于单播实时视频流。

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

情况2：某些数据包是随机的，经常在网络上丢失。-如果使用TCP，则将立即重新传输这些数据包并使用正确的抖动缓冲区，这不会对视频流质量/延迟产生影响。-如果使用UDP，视频质量会很差。=> TCP好多了

对于视频流，带宽可能是对系统的限制。使用多播可以大大减少所使用的上行带宽。使用UDP，您可以轻松地将数据包多播到所有连接的终端。您也可以使用一种可靠的多播协议，一种称为“实用通用多播（PGM）”，我对此一无所知，而且我猜想它的使用并不广泛。

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

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

所有“使用UDP”答案都假定网络是开放的，并且“尽其所能”。适用于老式的封闭式专用音频/视频网络，这种网络正在消失。

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

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