视频流上的 TCP 与 UDP
我刚从网络编程考试回来，他们问我们的一个问题是“如果你要流式传输视频，你会使用 TCP 还是 UDP？解释存储的视频和实时视频流” .对于这个问题，他们只是期望 TCP 用于存储视频和 UDP 用于实时视频的简短答案，但我在回家的路上想到了这一点，使用 UDP 流式传输实时视频是否一定更好？我的意思是，如果你有足够的带宽，并且说你正在流式传输足球比赛或音乐会，你真的需要使用 UDP 吗？
可以说，当您使用 TCP 流式传输此音乐会或其他任何内容时，您开始丢失数据包（在您和发送者之间的某个网络中发生了一些不好的事情），并且整整一分钟您都没有收到任何数据包。视频流将暂停，一分钟后数据包开始再次通过（IP 为您找到了新路由）。然后会发生的是 TCP 会在您丢失的那一刻重新传输并继续向您发送实时流。假设带宽高于流的比特率，并且 ping 不是太高，所以在很短的时间内，你丢失的一分钟将作为你流的缓冲区，这样，如果再次发生丢包，您将不会注意到。
现在，我可以想到一些设备，这不是一个好主意，例如视频会议，您需要始终处于流的末尾，因为视频聊天期间的延迟非常可怕，但是在足球比赛或音乐会期间，如果您落后于溪流一分钟，这有什么关系？另外，您可以保证获得所有数据，并且最好保存以供以后查看，而不会出现任何错误。
所以这让我想到了我的问题。使用 TCP 进行直播有什么我不知道的缺点吗？或者真的应该是，如果你有足够的带宽，你应该选择 TCP，因为它对网络“更好”（流量控制）？
使用 TCP 进行实时视频的缺点：
正如您所提到的，TCP 会为每个客户端缓冲未确认的段。在某些情况下，这是不可取的，例如非常流行的实时事件的 TCP 流：在这种情况下，您的同时客户端列表（和缓冲要求）很大。预先录制的视频广播通常不会有太大的问题，因为观众倾向于错开他们的重播活动。 TCP 的传递保证是一种阻塞功能，对交互式对话没有帮助。假设您的网络连接中断 15 秒。当我们错过对话的一部分时，我们自然会要求对方重复（或者如果您似乎错过了什么，对方会主动重复）。 UDP 不在乎您是否在过去 15 秒内错过了对话的一部分；它继续工作，好像什么都没发生一样。另一方面，可以为 TCP 设计应用程序以重播最后 15 秒（而另一端的人可能不想或不知道这一点）。 TCP 的这种重放使问题更加严重，并且使与对话中的其他方保持同步变得更加困难。比较 TCP 和 UDP 在丢包时的行为，可以说 UDP 更容易与交互式对话的状态保持同步。 IP 组播显着降低了大量观众的视频带宽需求；多播需要 UDP（并且与 TCP 不兼容）。注意 - 多播通常仅限于专用网络。请注意，互联网上的多播并不常见。我还要指出，操作多播网络比操作典型的单播网络更复杂。
仅供参考，请不要在描述网络时使用“包”一词。网络发送“数据包”。
但是在足球比赛或音乐会期间，如果您落后于溪流一分钟，那又有什么关系呢？
对于一些足球迷来说，相当多。有人指出，由于编码（或其他原因）在数字视频流中出现的甚至几秒钟的延迟都可能非常烦人，因为在世界杯比赛等高调活动中，您可以听到这些家伙的欢呼声和呻吟声在你看到导致他们的游戏动作之前，隔壁的人（他们正在观看一个未经处理的模拟节目）。
我认为对于非常关心体育运动的人（他们是最大的数字电视付费客户群体，至少在德国是这样），在直播视频流中落后一分钟是完全不能接受的（就像他们' d 在没有发生这种情况的情况下切换到您的竞争对手）。
通常，视频流具有一定的容错性。因此，如果某些包丢失（例如，由于沿途的某些路由器过载），那么它仍然能够显示内容，但质量会降低。
如果您的实时流使用 TCP/IP，那么它将被迫等待那些丢弃的包，然后才能继续处理更新的数据。
这是双重糟糕的：
旧数据被重新传输（这可能是一个已经显示的帧，因此一文不值）和
直到旧数据重新传输后才能到达新数据
如果您的目标是尽可能地显示最新信息（并且对于实时流，您通常希望是最新的，即使您的帧看起来有点糟糕），那么 TCP 将不利于您。
对于记录的流，情况略有不同：您可能会缓冲更多（可能是几分钟！）并且宁愿重新传输数据而不是由于丢失包而产生一些工件。在这种情况下，TCP 是一个很好的匹配（当然，这仍然可以在 UDP 中实现，但 TCP 没有直播流案例那么多的缺点）。
有一些适用于 UDP 传输的用例和其他适用于 TCP 传输的用例。
用例还规定了视频的编码设置。广播足球比赛的重点是质量，而视频会议的重点是延迟。
当使用多播向您的客户传送视频时，会使用 UDP。
多播的要求是广播服务器和客户之间的昂贵网络硬件。在实践中，这意味着如果您的公司拥有网络基础设施，您可以使用 UDP 和多播进行实时视频流传输。即使这样，服务质量也被实施以标记视频数据包并对其进行优先级排序，因此不会发生数据包丢失。
多播将简化广播软件，因为网络硬件将处理向客户分发数据包。客户订阅多播频道，网络将重新配置以将数据包路由到新订阅者。默认情况下，所有客户都可以使用所有渠道，并且可以进行最佳路由。
这个工作流程给授权过程带来了困难。网络硬件不区分订阅用户和其他用户。授权的解决方案是在订阅有效时加密视频内容并在播放器软件中启用解密。
单播 (TCP) 工作流程允许服务器检查客户端的凭据并仅允许有效订阅。甚至只允许一定数量的同时连接。
未通过 Internet 启用多播。
为了通过 Internet 传送视频，必须使用 TCP。当使用 UDP 时，开发人员最终会重新实现数据包重传，例如。 Bittorrent p2p 实时协议。
“如果您使用 TCP，操作系统必须为每个客户端缓冲未确认的段。这是不可取的，尤其是在实时事件的情况下”。
这个缓冲区必须以某种形式存在。播放器端的抖动缓冲区也是如此。它被称为“套接字缓冲区”，服务器软件可以知道该缓冲区何时已满并丢弃适当的视频帧以用于实时流。最好使用单播/TCP 方法，因为服务器软件可以实现适当的丢帧逻辑。 UDP 情况下随机丢失的数据包只会造成糟糕的用户体验。喜欢这个视频：http://tinypic.com/r/2qn89xz/9
“IP 多播显着降低了大量观众的视频带宽需求”
这适用于专用网络，未通过 Internet 启用多播。
“请注意，如果 TCP 丢失太多数据包，连接就会中断；因此，UDP 为您提供了对该应用程序的更多控制，因为 UDP 不关心网络传输层丢失。”
UDP 也不关心丢弃整个帧或帧组，因此它不会对用户体验提供更多控制。
“通常视频流有点容错”
编码的视频不是容错的。当通过不可靠的传输传输时，前向纠错被添加到视频容器中。一个很好的例子是用于卫星视频广播的 MPEG-TS 容器，它携带多个音频、视频、EPG 等流。这是必要的，因为卫星链路不是双工通信，这意味着接收器无法请求重新传输丢失的数据包。
当您有可用的双工通信时，最好只将数据重新传输给有数据包丢失的客户端，然后在发送给所有客户端的流中包含前向纠错的开销。
在任何情况下，丢失的数据包都是不可接受的。在带宽受阻的特殊情况下，丢帧是可以的。
https://i.stack.imgur.com/8ij1A.png
一些解码器可能会在关键位置中断丢失数据包的流。
我建议您查看新的 p2p 实时协议 Bittorent Live。
至于流式传输，最好使用 UDP，首先因为它降低了服务器的负载，但主要是因为您可以使用多播发送数据包，这比将其发送到每个连接的客户端更简单。
这取决于。您正在流式传输的内容有多重要？如果关键使用 TCP。这可能会导致带宽、视频质量（您可能必须使用较低质量来处理延迟）和延迟方面的问题。但是，如果您需要保证到达那里的内容，请使用它。
否则，如果流不是关键的，那么 UDP 应该没问题，并且会被首选，因为 UDP 往往具有较少的开销。
在 Internet 上提供实时事件的最大问题之一是“规模”，而 TCP 不能很好地扩展。例如，当您播放现场足球比赛时 - 与点播电影播放相反 - 观看的人数可以轻松增加 1000 倍。在这种情况下，使用 TCP 是对 CDN（内容交付网络）的死刑判决。
TCP 不能很好地扩展有几个主要原因：
TCP 最大的权衡之一是发送方和接收方之间可实现的吞吐量的可变性。当通过 Internet 流式传输视频时，视频数据包必须通过 Internet 上的多个路由器，这些路由器中的每一个都以不同的速度连接。 TCP 算法从小的 TCP 窗口开始，然后增长直到检测到丢包，丢包被认为是拥塞的标志，TCP 通过大幅减小窗口大小来响应它以避免拥塞。从而反过来立即降低有效吞吐量。现在想象一个使用 6-7 个路由器跳到客户端的 TCP 传输网络（非常正常的场景），如果任何中间路由器丢失任何数据包，该链路的 TCP 将降低传输速率。事实上，路由器之间的流量遵循沙漏形状；总是在中间路由器之一之间上下移动。与尽力而为的 UDP 相比，有效的吞吐量要低得多。您可能已经知道 TCP 是一种基于确认的协议。例如，假设发送者距离 50 毫秒（即延迟 btw 两点）。这意味着将数据包发送到接收器和接收器发送确认所需的时间将是 100 毫秒；因此，与基于 UDP 的传输相比，可能的最大吞吐量已经减半。 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 还可以使用多播。支持数千个 TCP 用户都传输相同的数据会浪费带宽。但是，使用 TCP 还有另一个重要原因。
TCP 可以更容易地通过防火墙和 NAT。根据您的 NAT 和运营商，由于 UDP 打孔问题，您甚至可能无法接收 UDP 流。
对于视频流带宽可能是对系统的限制。使用多播可以大大减少使用的上行带宽量。使用 UDP，您可以轻松地将数据包多播到所有连接的终端。您还可以使用可靠的多播协议，一种称为实用通用多播 (PGM)，我对此一无所知，我猜它的使用并不广泛。
所有“使用 UDP”的答案都假设一个开放的网络并“尽可能多地填充它”的方法。适合老式的封闭式专用音频/视频网络，这是一种正在消失的类型。
在现实世界中，您的传输将通过防火墙（会丢弃多播，有时会丢弃 udp），网络与其他更重要的 ($$$) 应用程序共享，因此您希望通过窗口缩放来惩罚滥用者。
事情就是这样，与其说是时间问题，不如说是内容问题。 TCP 协议要求必须检查、验证和重新传递未传递的数据包。 UDP 不使用此要求。因此，如果您使用 UDP 发送包含数百万个数据包的文件，例如视频，如果某些数据包在交付时丢失，它们很可能不会丢失。
