我刚从网络编程考试中回到家，他们问我们的一个问题是 "If you are going to stream video, would you use TCP or UDP? Give an explanation for both stored video and live video-streams" . 对于这个问题，他们只是简单地期望存储视频的TCP简短回答和实时视频的UDP，但我在回家的路上想到了这一点，并且使用UDP流媒体直播视频一定更好吗？我的意思是，如果你有足够的带宽，并说你正在播放足球比赛或音乐会，你真的需要使用UDP吗？
让我们说，当你正在流式音乐会或使用TCP的任何东西时，你开始丢失数据包（在你和发送者之间的某些网络中发生了一些不好的事情），并且整整一分钟你都没有得到任何数据包 . 视频流将暂停，一分钟后，数据包开始再次通过（IP为您找到了新的路由） . 然后会发生什么是TCP会在您丢失的那一刻重新传输并继续向您发送实时流 . 假设带宽高于流上的比特率，并且ping不是太高，所以在很短的时间内，丢失的那一分钟将作为流的缓冲区，这样，如果再次发生丢包，您将不会注意到 .
现在，我可以想到一些设备，这不是一个好主意，例如视频 Session ，你总是在流的末尾，因为在视频聊天期间的延迟是可怕的，但在足球比赛或音乐会期间，如果你在流后面一分钟，这有什么关系？此外，您可以保证获得所有数据，最好保存以供日后查看，而不会出现任何错误 .
所以这让我想到了我的问题 . 关于使用TCP进行直播，我不知道有什么缺点吗？或者它应该真的是，如果你有它的带宽你应该去TCP，因为它对网络“更好”（流量控制）？
13 回答
使用TCP进行实时视频的缺点：
通常，实时视频流设备的设计并未考虑TCP流 . 如果使用TCP，则操作系统必须为每个客户端缓冲未确认的段 . 这是不可取的，特别是在直播活动的情况下;据推测，由于事件的特殊性，您的同时客户名单很长 . 预先录制的视频广播通常没有这么多的问题，因为 Spectator 错开了他们的重播活动;因此TCP更适合重播视频点播 .
IP多播大大降低了大量受众的视频带宽需求; TCP阻止使用IP多播，但UDP非常适合IP多播 .
实时视频通常是从相机录制的恒定带宽流;预录制的视频流脱离磁盘 . 当源流处于恒定带宽时（如实况事件会发生的那样），TCP的丢失 - 回退动态使得更难以提供实时视频 . 如果从相机缓冲到磁盘，请确保有足够的缓冲区用于不可预测的网络事件和可变的TCP发送/退避速率 . UDP为此应用程序提供了更多控制，因为UDP不关心网络传输层丢弃 .
仅供参考，在描述网络时请不要使用“包”这个词 . 网络发送“数据包” .
对一些球迷来说，相当多 . 有人指出，由于编码（或其他），数字视频流中存在的几秒钟的延迟可能会非常烦人，因为在世界杯比赛等高调事件中，您可以听到来自这些人的欢呼声和呻吟声 . 隔壁（他们正在观看一个未经处理的模拟程序），然后才能看到引起他们的游戏动作 .
我认为，对于那些关心体育运动的人来说（那些是最大的数字电视付费用户群，至少在德国这里），在现场视频流中落后一分钟是完全不可接受的（如同，他们' d切换到竞争对手，但这不会发生 .
通常视频流有点容错 . 因此，如果某些软件包丢失（例如，由于某些路由器正在过载），那么它仍然能够显示内容，但质量会降低 .
如果您的直播流使用TCP / IP，那么它将被迫等待那些丢弃的包 before 它可以继续处理更新的数据 .
那是双坏的：
旧数据被重新传输（这可能是因为已经显示的帧，因此毫无 Value ） and
新数据在重新传输旧数据之后才能到达
如果您的目标是尽可能显示最新信息（对于实时流，您通常希望是最新的，即使您的帧看起来有点糟糕），那么TCP也会对您不利 .
对于录制的流，情况略有不同：你可能会缓冲更多（可能是几分钟！），并且宁愿重新传输数据而不是由于丢失包而导致的一些工件 . 在这种情况下，TCP是一个很好的匹配（当然，这仍然可以在UDP中实现，但TCP没有与实时流案例一样多的缺点） .
有一些适用于UDP传输的用例和适用于TCP传输的其他用例 .
该用例还规定了视频的编码设置 . 广播足球比赛的重点是质量，视频 Session 的重点是延迟 .
使用多播向您的客户提供视频时，将使用UDP .
对多播的要求是广播服务器和客户之间昂贵的网络硬件 . 实际上，这意味着如果您的公司拥有网络基础设施，您可以使用UDP和多播进行实时视频流 . 即使这样，服务质量也被用于标记视频数据包并对其进行优先级排序，因此不会发生数据包丢失 .
多播将简化广播软件，因为网络硬件将处理向客户分发数据包 . 客户订阅多播信道，网络将重新配置以将数据包路由到新订户 . 默认情况下，所有客户都可以使用所有渠道，并且可以进行最佳路由 .
此工作流程会对授权过程产生不足 . 网络硬件不会将订阅用户与其他用户区分开来 . 授权的解决方案是加密视频内容，并在订阅有效时在播放器软件中启用解密 .
单播（TCP）工作流允许服务器检查客户端的凭据，并且只允许有效的订阅 . 甚至只允许一定数量的同时连接 .
未通过互联网启用多播 .
要通过Internet传送视频，必须使用TCP . 当使用UDP时，开发人员最终重新实现分组重传，例如 . Bittorrent p2p实时协议 .
此缓冲区必须以某种形式存在 . 对于玩家方的抖动缓冲区也是如此 . 它被称为"socket buffer"，服务器软件可以知道此缓冲区何时已满并丢弃实时流的正确视频帧 . 最好使用单播/ TCP方法，因为服务器软件可以实现正确的帧丢弃逻辑 . UDP情况下随机丢失的数据包只会造成糟糕的用户体验 . 喜欢这个视频：http://tinypic.com/r/2qn89xz/9
私有网络也是如此，未通过互联网启用多播 .
UDP也不关心丢弃整个帧或帧组，因此它不再提供对用户体验的控制 .
编码视频不具有容错能力 . 当通过不可靠的传输进行传输时，向视频容器添加前向纠错 . 很好的例子是用于卫星视频广播的MPEG-TS容器，其携带多个音频，视频，EPG等流 . 这是必要的，因为卫星链路不是双工通信，这意味着接收器不能请求重传丢失的数据包 .
当您具有双工通信时，最好只将数据重新传输到具有数据包丢失的客户端，然后在发送到所有客户端的流中包含前向纠错的开销 .
在任何情况下，丢失的数据包都是不可接受的 . 在带宽受阻的特殊情况下，丢帧是可以的 .
丢失数据包的结果是像这样的工件：
一些解码器可以在关键位置中断丢失数据包的流 .
我建议你看看新的p2p live protocol Bittorent Live .
至于流式传输，首先使用UDP更好因为它降低了服务器上的负载，但主要是因为你可以发送带有多播的数据包，它比将它发送到每个连接的客户端更简单 .
这取决于 . 你流媒体的内容有多重要？如果关键使用TCP . 这可能会导致带宽，视频质量问题（您可能必须使用较低的质量来处理延迟）和延迟 . 但是如果您需要保证内容到达那里，请使用它 .
否则UDP应该没有问题，如果流不是关键的并且是首选的，因为UDP往往具有较少的开销 .
在Internet上提供实时事件的最大问题之一是“规模”，TCP不能很好地扩展 . 例如，当您正在为现场足球比赛做准备时 - 与点播电影回放相反 - 观看的人数可以轻松增加1000倍 . 在这种情况下，使用TCP是CDN（内容传递网络）的死刑 .
TCP无法很好地扩展有几个主要原因：
TCP的最大权衡之一是发送方和接收方之间可实现的吞吐量的可变性 . 当通过互联网传输视频时，视频数据包必须通过互联网遍历多个路由器，每个路由器都连接不同的速度连接 . TCP算法从TCP窗口关闭开始，然后增长直到检测到丢包，丢包被认为是拥塞的标志，TCP通过大幅减小窗口大小来响应它，以避免拥塞 . 因此反过来立即降低有效吞吐量 . 现在想象一个使用6-7路由器跳转到客户端的TCP传输网络（非常正常的情况），如果任何中间路由器丢失任何数据包，该链路的TCP将降低传输速率 . 事实上，路由器之间的流量遵循一种沙漏形状;总是在其中一个中间路由器之间上下锣 . 与尽力而为UDP相比，渲染有效通过率低得多 .
您可能已经知道TCP是一种基于确认的协议 . 例如，假设发送者距离50ms（即延迟btw两个点） . 这意味着将数据包发送到接收器所需的时间和接收器发送确认的时间将是100ms;因此，与基于UDP的传输相比，可能的最大吞吐量已经减半 .
TCP不支持多播或多播AMT的新兴标准 . 这意味着CDN没有机会通过复制数据包来减少网络流量 - 当许多客户端正在观看相同的内容时 . 对于CDN（如Akamai或Level3）而言，这本身就是一个足够的理由，不能使用TCP进行直播 .
对于视频流，带宽可能是系统的约束 . 使用多播可以大大减少上游带宽的使用量 . 使用UDP，您可以轻松地将数据包多播到所有连接的终端 . 你也可以使用一个可靠的多播协议，一个称为实用通用多播（PGM），我对它一无所知，我猜它在使用中并不普遍 .
如果带宽远高于比特率，我建议TCP用于单播实时视频流 .
情况1：连续数据包丢失持续几秒钟 . =>无论传输层是什么（TCP或UDP），实时视频都将在客户端停止 . 当网络恢复时： - 如果使用TCP，客户端视频播放器可以选择在第一个数据包丢失（时移）时重新启动流，或者丢弃所有延迟数据包并重启视频流而不进行时移 . - 如果使用UDP，则在客户端没有选择，视频重启没有任何时间转换 . => TCP相等或更好 .
案例2：一些数据包随机丢失，经常在网络上丢失 . - 如果使用TCP，这些数据包将立即重传，并且具有正确的抖动缓冲区，对视频流质量/延迟不会产生任何影响 . - 如果使用UDP，视频质量将会很差 . => TCP好多了
所有'使用UDP'答案都假设一个开放的网络，并且“尽可能多地填充它” . 适用于旧式封闭式花园专用音频/视频网络，这是一种消失的类型 .
在现实世界中，您的传输将通过防火墙（将丢弃多播，有时甚至是udp），网络与其他更重要的（$$$）应用程序共享，因此您希望通过窗口缩放来惩罚滥用者 .
除了所有的其他原因，UDP可以使用组播 . 支持1000个TCP用户都传输相同的数据会浪费带宽 . 但是，使用TCP还有另一个重要原因 .
TCP可以更容易地通过防火墙和NAT . 根据您的NAT和运营商，由于UDP打孔问题，您甚至可能无法接收UDP流 .
在阅读TCP UDP辩论时，我注意到了一个逻辑缺陷 . 导致转换为一分钟缓冲区的一分钟延迟的TCP数据包丢失与UDP相关，并且在经历相同丢失的同时丢弃整整一分钟 . 更公平的比较如下 .
TCP遇到数据包丢失 . TCP重新发送数据包时，视频停止，以尝试流式传输数学上完美的数据包 . 视频延迟一分钟，并在丢失数据包到达目的地后从中断处继续 . 我们都在等，但我们知道我们不会错过任何一个像素 .
UDP遇到丢包 . 在视频流中的一秒钟，屏幕的一角变得有点模糊 . 没有人注意到，节目继续播放，没有找到丢失的数据包 .
任何流都可以从UDP获得最大收益 . 导致TCP延迟一分钟的数据包丢失不会导致UDP延迟一分钟 . 考虑到大多数系统使用多个分辨率流，在使数据包饥饿时会出现问题，因此使用UDP更有意义 .
流式传输时的UDP FTW .
这是事情，它更多的是内容问题，而不是时间问题 . TCP协议要求必须检查，验证和重新传递未传递的数据包 . UDP不使用此要求 . 因此，如果您发送的文件包含使用UDP的数百万个数据包（如视频），如果某些数据包在发送时丢失，则很可能会被忽略 .