我刚从网络编程考试回来，他们问我们的问题之一是“如果您要传输视频，您会使用 TCP 还是 UDP？请解释一下存储视频和实时视频流”。对于这个问题，他们只是希望得到一个简短的答案：TCP 用于存储视频，UDP 用于实时视频，但我在回家的路上想到了这一点，使用 UDP 传输实时视频是否一定更好？我的意思是，如果您有足够的带宽，并且您正在直播一场足球比赛或音乐会，您真的需要使用 UDP 吗？
假设当您使用 TCP 流式传输这场音乐会或其他任何内容时，您开始丢失数据包（您和发送者之间的某个网络中发生了一些不好的事情），并且整整一分钟您都没有收到任何数据包。视频流将暂停，一分钟过去后，数据包开始再次通过（IP 为您找到了一条新路由）。然后会发生的情况是 TCP 会在您丢失的那一刻重新传输并继续向您发送实时流。假设带宽高于流的比特率，并且 ping 不太高，因此在很短的时间内，您丢失的一分钟将充当流的缓冲区，这样，如果再次发生丢包，您不会注意到。
现在，我可以想到一些设备，这不是一个好主意，例如视频会议，您可以在其中need始终处于直播的末尾，因为视频聊天期间的延迟实在是太可怕了，但在足球比赛或音乐会期间，如果您落后直播一分钟又有什么关系呢？另外，您可以保证获得所有数据，并且最好保存下来以便以后在没有任何错误的情况下查看。
这让我想到了我的问题。使用 TCP 进行直播有什么我不知道的缺点吗？或者，如果您有足够的带宽，您应该选择 TCP，因为它对网络“更好”（流量控制）？
使用 TCP 进行实时视频的缺点：
-
正如您所提到的，TCP 会为每个客户端缓冲未确认的段。在某些情况下，这是不希望的，例如非常流行的实时事件的 TCP 流：在这种情况下，并发客户端列表（和缓冲要求）很大。预先录制的视频广播通常不会有太大问题，因为观众往往会错开重播活动。
-
TCP 的传送保证是一种阻塞功能，对交互式对话没有帮助。假设您的网络连接中断 15 秒。当我们错过谈话的一部分时，我们自然会要求对方重复（或者如果对方看起来你漏掉了什么，对方会主动重复）。 UDP 并不关心您是否在最后 15 秒内错过了部分对话；它继续工作，就像什么都没发生一样。另一方面，应用程序可以设计为 TCP 重播最后 15 秒（另一端的人可能不希望或不知道这一点）。 TCP 的这种重播会加剧问题，并使与对话中的其他方保持同步变得更加困难。比较 TCP 和 UDP 在丢包时的行为，可以说 UDP 更容易与交互式会话的状态保持同步。
-
IP组播显着降低大量观众的视频带宽需求；多播需要 UDP（并且与 TCP 不兼容）。注意 - 多播通常仅限于专用网络。请注意，互联网上的多播并不常见。我还要指出，操作多播网络比操作典型的单播网络更复杂。
仅供参考，在描述网络时请不要使用“包”一词。网络发送“数据包”。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
