networking - 视频流上的 TCP 与 UDP

Question

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

假设当您正在使用 TCP 流式传输这场音乐会或其他任何内容时，您开始丢失数据包(您和发送方之间的某些网络中发生了一些错误)，并且整整一分钟您都没有收到任何数据包。视频流将暂停，一分钟后数据包开始再次通过(IP 为您找到了一条新路由)。然后会发生什么是 TCP 会在您丢失的那一刻重新传输并继续向您发送实时流。假设带宽高于流的比特率，并且 ping 不是太高，所以在短时间内，您丢失的一分钟将作为流的缓冲区，这样，如果再次发生丢包，您将不会注意到。

现在，我可以想到在某些设备上这不是一个好主意，例如视频 session ，您需要始终处于流的末尾，因为延迟在视频聊天期间真是太可怕了，但是在足球比赛或音乐会期间，如果你落后一分钟又有什么关系呢？此外，我们保证您获得了所有数据，最好保存以供日后在数据无误输入时查看。

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

Answer 1

实时视频使用 TCP 的缺点:

1. 如您所述，TCP 会为每个客户端缓冲未确认的数据段。在某些情况下，这是不可取的，例如非常流行的直播事件的 TCP 流:在这种情况下，您的同时客户端列表(和缓冲要求)很大。预先录制的视频广播通常不会有那么大的问题，因为观众往往会错开他们的重播事件。

2. TCP 的交付保证是一种阻塞功能，对交互式对话没有帮助。假设您的网络连接断开 15 秒。当我们漏掉对话的一部分时，我们自然会要求对方重复(或者对方会主动重复，如果你觉得你漏掉了什么)。 UDP 不在乎您是否在最后 15 秒内错过了对话的一部分；它一直在工作，就好像什么也没发生一样。另一方面，应用程序可以设计为 TCP 重放最后 15 秒(另一端的人可能不想或不知道)。 TCP 的这种重播加剧了这个问题，并使与对话中的其他方保持同步变得更加困难。比较 TCP 和 UDP 在丢包时的行为，可以说 UDP 更容易与交互式对话的状态保持同步。

3. IP 组播可显着降低大量观众的视频带宽要求；多播需要 UDP(并且与 TCP 不兼容)。注意 - 多播通常仅限于专用网络。请注意，互联网上的多播并不常见。我还要指出，运行多播网络比运行典型的单播网络更复杂。

仅供引用，在描述网络时请不要使用“包”一词。网络发送“数据包”。