视频流上的 TCP 与 UDP
我刚从网络编程考试回来，他们问我们的问题之一是“如果你要传输视频，你会使用 TCP 还是 UDP？请解释一下存储视频和实时视频-流”。对于这个问题，他们只是希望得到一个简短的答案：TCP 用于存储视频，UDP 用于实时视频，但我在回家的路上想到了这一点，使用 UDP 传输实时视频是否一定更好？我的意思是，如果您有足够的带宽，并且您正在直播一场足球比赛或音乐会，您真的需要使用 UDP 吗？
假设当您使用 TCP 流式传输这场音乐会或其他任何内容时，您开始丢失数据包（您和发送者之间的某个网络中发生了一些不好的事情），并且整整一分钟您都没有收到任何数据包。视频流将暂停，一分钟过去后，数据包开始再次通过（IP 为您找到了一条新路由）。然后会发生的情况是 TCP 会在您丢失的那一刻重新传输并继续向您发送实时流。假设带宽高于流的比特率，并且 ping 不太高，因此在很短的时间内，您丢失的一分钟将充当流的缓冲区，这样，如果再次发生丢包，您不会注意到。
现在，我可以想到一些设备，这不是一个好主意，例如视频会议，您需要始终处于流的末尾，因为视频期间存在延迟-聊天实在是太糟糕了，但在足球比赛或音乐会期间，如果您落后直播一分钟又有什么关系呢？另外，您可以保证获得所有数据，并且最好保存下来以便以后在没有任何错误的情况下查看。
这让我想到了我的问题。使用 TCP 进行直播有什么我不知道的缺点吗？或者，如果您有足够的带宽，您应该选择 TCP，因为它对网络“更好”（流量控制）？
I just came home from my exam in network-programming, and one of the question they asked us was "If you are going to stream video, would you use TCP or UDP? Give an explanation for both stored video and live video-streams". To this question they simply expected a short answer of TCP for stored video and UDP for live video, but I thought about this on my way home, and is it necessarily better to use UDP for streaming live video? I mean, if you have the bandwidth for it, and say you are streaming a soccer match, or concert for that matter, do you really need to use UDP?
Lets say that while you are streaming this concert or whatever using TCP you start losing packets (something bad happened in some network between you and the sender), and for a whole minute you don't get any packets. The video-stream will pause, and after the minute is gone packets start to get through again (IP found a new route for you). What would then happen is that TCP would retransmit the minute you lost and continue sending you the live stream. As an assumption the bandwidth is higher than the bit-rate on the stream, and the ping is not too high, so in a short amount of time, the one minute you lost will act as a buffer for the stream for you, that way, if packet-loss happens again, you won't notice.
Now, I can think of some appliances where this wouldn't be a good idea, like for instance video-conferences, where you need to always be at the end of the stream, because delay during a video-chat is just horrible, but during a soccer-match, or a concert what does it matter if you are a single minute behind the stream? Plus, you are guaranteed that you get all the data and it would be better to save for later viewing when it's coming in without any errors.
So this brings me to my question. Are there any drawbacks that I don't know of about using TCP for live-streaming? Or should it really be, that if you have the bandwidth for it you should go for TCP given that it is "nicer" to the network (flow-control)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
使用 TCP 进行实时视频的缺点：
正如您所提到的，TCP 会为每个客户端缓冲未确认的段。在某些情况下，这是不希望的，例如非常流行的实时事件的 TCP 流：在这种情况下，并发客户端列表（和缓冲要求）很大。预先录制的视频广播通常不会有太大问题，因为观众往往会错开重播活动。
TCP 的传送保证是一种阻塞功能，对交互式对话没有帮助。假设您的网络连接中断 15 秒。当我们错过谈话的一部分时，我们自然会要求对方重复（或者如果对方看起来你错过了什么，对方会主动重复）。 UDP 并不关心您是否在最后 15 秒内错过了部分对话；它继续工作，就像什么都没发生一样。另一方面，应用程序可以设计为让 TCP 重播最后 15 秒（而另一端的人可能不希望或不知道这一点）。 TCP 的这种重播会加剧问题，并使与对话中的其他方保持同步变得更加困难。比较 TCP 和 UDP 在丢包时的行为，可以说 UDP 更容易与交互式会话的状态保持同步。
IP组播显着降低了大量观众的视频带宽需求；多播需要 UDP（并且与 TCP 不兼容）。注意 - 多播通常仅限于专用网络。请注意，互联网上的多播并不常见。我还要指出，操作多播网络比操作典型的单播网络更复杂。
仅供参考，在描述网络时请不要使用“包”一词。网络发送“数据包”。
Drawbacks of using TCP for live video:
As you mentioned, TCP buffers the unacknowledged segments for every client. In some cases this is undesirable, such as TCP streaming for very popular live events: your list of simultaneous clients (and buffering requirements) are large in this case. Pre-recorded video-casts typically don't have as much of a problem with this because viewers tend to stagger their replay activity.
TCP's delivery guarantees are a blocking function which isn't helpful in interactive conversations. Assume your network connection drops for 15 seconds. When we miss part of a conversation, we naturally ask the person to repeat (or the other party will proactively repeat if it seems like you missed something). UDP doesn't care if you missed part of a conversation for the last 15 seconds; it keeps working as if nothing happened. On the other hand, the app could be designed for TCP to replay the last 15 seconds (and the person on the other end may not want or know about that). Such a replay by TCP aggravates the problem, and makes it more difficult to stay in sync with other parties in the conversation. Comparing TCP and UDP’s behavior in the face of packet loss, one could say that it’s easier for UDP to stay in sync with the state of an interactive conversation.
IP multicast significantly reduces video bandwidth requirements for large audiences; multicast requires UDP (and is incompatible with TCP). Note - multicast is generally restricted to private networks. Please note that multicast over the internet is not common. I would also point out that operating multicast networks is more complicated than operating typical unicast networks.
FYI, please don't use the word "packages" when describing networks. Networks send "packets".
对于一些足球迷来说，相当多。有人指出，在世界杯比赛等备受瞩目的活动中，您可以听到人们的欢呼声和呻吟声，由于编码（或其他原因），数字视频流中即使出现几秒钟的延迟也会非常烦人。在你看到引起他们的游戏动作之前，隔壁（他们正在观看一个不真实的模拟节目）。
我认为，对于那些非常关心体育的人（这些人是数字电视付费客户的最大群体，至少在德国是这样），在直播视频流中落后一分钟是完全不可接受的（例如，他们'如果不会发生这种情况，请切换到您的竞争对手）。
To some soccer fans, quite a bit. It has been remarked that delays of even a few seconds present in digital video streams due to encoding (or whatever) can be very annoying when, during high-profile events such as world cup matches, you can hear the cheers and groans from the guys next door (who are watching an undelyed analog program) before you get to see the game moves that caused them.
I think that to someone caring a lot about sports (and those are the biggest group of paying customers for digital TV, at least here in Germany), being a minute behind in a live video stream would be completely unacceptable (As in, they'd switch to your competitor where this doesn't happen).
通常视频流具有一定的容错能力。因此，如果某些包裹丢失（例如，由于沿途某些路由器过载），它仍然能够显示内容，但质量会降低。
如果您的直播流使用 TCP/IP，则被迫等待那些丢弃的包然后才能继续处理更新的数据。
这是双重糟糕的：
如果您的目标是尽可能显示最新的信息（对于实时流，您通常希望是最新的，即使您的帧看起来有点差），那么 TCP 就可以工作反对你。
对于录制的流，情况略有不同：您可能会缓冲更多时间（可能是几分钟！），并且宁愿重新传输数据，也不愿因丢失包而产生一些工件。在这种情况下，TCP 是一个很好的匹配（当然，这仍然可以在 UDP 中实现，但 TCP 没有像直播流情况那样的缺点）。
Usually a video stream is somewhat fault tolerant. So if some packages get lost (due to some router along the way being overloaded, for example), then it will still be able to display the content, but with reduced quality.
If your live stream was using TCP/IP, then it would be forced to wait for those dropped packages before it could continue processing newer data.
That's doubly bad:
If your goal is to display as up-to-date information as possible (and for a live-stream you usually want to be up-to-date, even if your frames look a bit worse), then TCP will work against you.
For a recorded stream the situation is slightly different: you'll probably be buffering a lot more (possibly several minutes!) and would rather have data re-transmitted than have some artifacts due to lost packages. In this case TCP is a good match (this could still be implemented in UDP, of course, but TCP doesn't have as much drawbacks as for the live stream case).
有些用例适合 UDP 传输，有些用例适合 TCP 传输。
用例还规定了视频的编码设置。转播足球比赛时，重点是质量，而视频会议的重点是延迟。
当使用多播向客户传送视频时，将使用 UDP。
多播的要求是广播服务器和客户之间昂贵的网络硬件。实际上，这意味着如果您的公司拥有网络基础设施，您可以使用 UDP 和多播进行实时视频流传输。即使这样，也实现了服务质量来标记视频数据包并对其进行优先级排序，这样就不会发生数据包丢失的情况。
组播将简化广播软件，因为网络硬件将负责向客户分发数据包。客户订阅多播频道，网络将重新配置以将数据包路由到新订阅者。默认情况下，所有通道均可供所有客户使用，并且可以进行最佳路由。
此工作流程给授权过程带来了困难。网络硬件不区分订阅用户和其他用户。授权的解决方案是对视频内容进行加密，并在订阅有效时在播放器软件中启用解密。
单播 (TCP) 工作流程允许服务器检查客户端的凭据并仅允许有效的订阅。甚至只允许一定数量的同时连接。
未通过 Internet 启用多播。
为了通过互联网传输视频，必须使用 TCP。当使用 UDP 时，开发人员最终会重新实现数据包重传，例如。 Bittorrent p2p 实时协议。
该缓冲区必须以某种形式存在。播放器端的抖动缓冲区也是如此。它被称为“套接字缓冲区”，服务器软件可以知道该缓冲区何时已满，并丢弃实时流的正确视频帧。最好使用单播/TCP 方法，因为服务器软件可以实现适当的丢帧逻辑。 UDP 情况下随机丢失数据包只会造成糟糕的用户体验。就像这个视频一样：http://tinypic.com/r/2qn89xz/9
专用网络来说确实如此，但互联网上不启用多播。
UDP 也不关心丢弃整个帧或帧组，因此它不会对用户体验提供更多控制。
编码视频不容错。当通过不可靠的传输方式传输时，前向纠错会添加到视频容器中。很好的例子是卫星视频广播中使用的 MPEG-TS 容器，它携带多个音频、视频、EPG 等流。这是必要的，因为卫星链路不是双工通信，这意味着接收器无法请求重新传输丢失的数据包。
当您有可用的双工通信时，最好仅向丢失数据包的客户端重新传输数据，然后在发送到所有客户端的流中包含前向纠错的开销。
无论如何，丢失数据包都是不可接受的。在带宽受到阻碍的特殊情况下，丢帧是可以的。
丢失数据包的结果是这样的工件：
某些解码器可能会因关键位置丢失数据包而中断流。
There are some use cases suitable to UDP transport and others suitable to TCP transport.
The use case also dictates encoding settings for the video. When broadcasting soccer match focus is on quality and for video conference focus is on latency.
When using multicast to deliver video to your customers then UDP is used.
Requirement for multicast is expensive networking hardware between broadcasting server and customer. In practice this means if your company owns network infrastructure you can use UDP and multicast for live video streaming. Even then quality-of-service is also implemented to mark video packets and prioritize them so no packet loss happens.
Multicast will simplify broadcasting software because network hardware will handle distributing packets to customers. Customers subscribe to multicast channels and network will reconfigure to route packets to new subscriber. By default all channels are available to all customers and can be optimally routed.
This workflow places dificulty on authorization process. Network hardware does not differentiate subscribed users from other users. Solution to authorization is in encrypting video content and enabling decryption in player software when subscription is valid.
Unicast (TCP) workflow allows server to check client's credentials and only allow valid subscriptions. Even allow only certain number of simultaneous connections.
Multicast is not enabled over internet.
For delivering video over internet TCP must be used. When UDP is used developers end up re-implementing packet re-transmission, for eg. Bittorrent p2p live protocol.
This buffer must exist in some form. Same is true for jitter buffer on player side. It is called "socket buffer" and server software can know when this buffer is full and discard proper video frames for live streams. It is better to use unicast/TCP method because server software can implement proper frame dropping logic. Random missing packets in UDP case will just create bad user experience. like in this video: http://tinypic.com/r/2qn89xz/9
This is true for private networks, Multicast is not enabled over internet.
UDP also doesn't care about dropping entire frames or group-of-frames so it does not give any more control over user experience.
Encoded video is not fault tolerant. When transmitted over unreliable transport then forward error correction is added to video container. Good example is MPEG-TS container used in satellite video broadcast that carry several audio, video, EPG, etc. streams. This is necessary as satellite link is not duplex communication, meaning receiver can't request re-transmission of lost packets.
When you have duplex communication available it is always better to re-transmit data only to clients having packet loss then to include overhead of forward-error-correction in stream sent to all clients.
In any case lost packets are unacceptable. Dropped frames are ok in exceptional cases when bandwidth is hindered.
The result of missing packets are artifacts like this one:
Some decoders can break on streams missing packets in critical places.
我建议您查看新的 p2p 实时协议 Bittorent Live。
至于流式传输，最好使用 UDP，首先是因为它可以降低服务器的负载，但主要是因为您可以通过多播发送数据包，这比将其发送到每个连接的客户端更简单。
I recommend you to look at new p2p live protocol Bittorent Live.
As for streaming it's better to use UDP, first because it lowers the load on servers, but mostly because you can send packets with multicast, it's simpler than sending it to each connected client.
这取决于。您正在流式传输的内容有多重要？如果关键使用 TCP。这可能会导致带宽、视频质量（您可能必须使用较低的质量来处理延迟）和延迟方面的问题。但如果您需要保证内容到达目的地，请使用它。
否则，如果流不重要，则 UDP 应该没问题，并且会是首选，因为 UDP 的开销往往较小。
It depends. How critical is the content you are streaming? If critical use TCP. This may cause issues in bandwidth, video quality (you might have to use a lower quality to deal with latency), and latency. But if you need the content to guaranteed get there, use it.
Otherwise UDP should be fine if the stream is not critical and would be preferred because UDP tends to have less overhead.
在互联网上传送现场活动的最大问题之一是“规模”，而 TCP 的规模并不大。例如，当您直播足球比赛时（与点播电影播放相反），观看人数很容易就会增加 1000 倍。在这种情况下，使用 TCP 对 CDN（内容分发网络）来说就是死刑。
TCP 不能很好地扩展有几个主要原因：
您可能已经知道 TCP 是一种基于确认的协议。举例来说，假设发送者距离 50 毫秒（即两点之间的延迟）。这意味着将数据包发送到接收方以及接收方发送确认所需的时间将为 100 毫秒；因此，与基于 UDP 的传输相比，可能的最大吞吐量已经减半。
TCP 不支持多播或新兴的多播 AMT 标准。这意味着当许多客户端观看相同的内容时，CDN 没有机会通过复制数据包来减少网络流量。这本身就是 CDN（如 Akamai 或 Level3）不使用 TCP 进行实时流传输的一个足够大的理由。
One of the biggest problems with delivering live events on Internet is 'scale', and TCP doesn’t scale well. For example when you are beaming a live football match -as opposed to an on demand movie playback- the number of people watching can easily be 1000 times more. In such a scenario using TCP is a death sentence for the CDNs (content delivery networks).
There are a couple of main reasons why TCP doesn't scale well:
One of the largest tradeoffs of TCP is the variability of throughput achievable between the sender and the receiver. When streaming video over the Internet the video packets must traverse multiple routers over the Internet, each of these routers is connected with different speed connections. The TCP algorithm starts with TCP window off small, then grows until packet loss is detected, the packet loss is considered a sign of congestion and TCP responds to it by drastically reducing the window size to avoid congestion. Thus in turn reducing the effective throughput immediately. Now imagine a network with TCP transmission using 6-7 router hops to the client (a very normal scenario), if any of the intermediate router looses any packet, the TCP for that link will reduce the transmission rate. In-fact The traffic flow between routers follow an hourglass kind of a shape; always gong up and down in-between one of the intermediate routers. Rendering the effective through put much lower compared to best-effort UDP.
As you may already know TCP is an acknowledgement-based protocol. Lets for example say a sender is 50ms away (i.e. latency btw two points). This would mean time it takes for a packet to be sent to a receiver and receiver to send an acknowledgement would be 100ms; thus maximum throughput possible as compared to UDP based transmission is already halved.
The TCP doesn’t support multicasting or the new emerging standard of multicasting AMT. Which means the CDNs don’t have the opportunity to reduce network traffic by replicating the packets -when many clients are watching the same content. That itself is a big enough reason for CDNs (like Akamai or Level3) to not go with TCP for live streams.
在阅读 TCP UDP 辩论时，我注意到一个逻辑缺陷。 TCP 数据包丢失导致一分钟的延迟（转换为一分钟的缓冲区）与 UDP 丢失一整分钟但经历相同的丢失没有关联。更公平的比较如下。
TCP 出现数据包丢失。当 TCP 重新发送数据包以尝试传输数学上完美的数据包时，视频会停止。视频延迟一分钟，并在丢失的数据包到达目的地后从中断处继续播放。我们都在等待，但我们知道我们不会错过任何一个像素。
UDP 出现数据包丢失。在视频流播放过程中，有一秒钟屏幕的一角变得有点模糊。没有人注意到，节目继续进行，而没有寻找丢失的数据包。
任何流式传输都可以从 UDP 中获益最多。丢包导致 TCP 延迟一分钟，不会导致 UDP 延迟一分钟。考虑到大多数系统使用多个分辨率流，当数据包匮乏时，事情会变得阻塞，因此使用 UDP 更有意义。
流式传输时的 UDP FTW。
While reading the TCP UDP debate I noticed a logical flaw. A TCP packet loss causing a one minute delay that's converted into a one minute buffer cant be correlated to UDP dropping a full minute while experiencing the same loss. A more fair comparison is as follows.
TCP experiences a packet loss. The video is stopped while TCP resend's packets in an attempt to stream mathematically perfect packets. Video is delayed for one minute and picks up where it left off after missing packet makes its destination. We all wait but we know we wont miss a single pixel.
UDP experiences a packet loss. For a second during the video stream a corner of the screen gets a little blurry. No one notices and the show goes on without looking for the lost packets.
Anything that streams gains the most benefits from UDP. The packet loss causing a one minute delay to TCP would not cause a one minute delay to UDP. Considering that most systems use multiple resolution streams making things go blocky when starving for packets, makes even more sense to use UDP.
UDP FTW when streaming.
如果带宽远高于比特率，我会推荐 TCP 进行单播直播视频流。
情况1：连续丢包数秒。 =>无论传输层是什么（TCP 或 UDP），实时视频都会在客户端停止。当网络恢复时：
- 如果使用 TCP，客户端视频播放器可以选择在第一个数据包丢失（时移）时重新启动流，或者丢弃所有迟到的数据包并在没有时移的情况下重新启动视频流。
- 如果使用UDP，客户端没有选择，视频重新开始直播，没有任何时移。
=> TCP 等于或更好。
情况2：一些数据包是随机的并且经常在网络上丢失。
- 如果使用 TCP，这些数据包将立即重新传输，并且具有正确的抖动缓冲区，不会对视频流质量/延迟产生影响。
- 如果使用UDP，视频质量会很差。
=> TCP 好多了
If the bandwidth is far higher than the bitrate, I would recommend TCP for unicast live video streaming.
Case 1: Consecutive packets are lost for a duration of several seconds. => live video will stop on the client side whatever the transport layer is (TCP or UDP). When the network recovers:
- if TCP is used, client video player can choose to restart the stream at the first packet lost (timeshift) OR to drop all late packets and to restart the video stream with no timeshift.
- if UDP is used, there is no choice on the client side, video restart live without any timeshift.
=> TCP equal or better.
Case 2: some packets are randomly and often lost on the network.
- if TCP is used, these packets will be immediately retransmitted and with a correct jitter buffer, there will be no impact on the video stream quality/latency.
- if UDP is used, video quality will be poor.
=> TCP much better
除了所有其他原因之外，UDP 还可以使用多播。支持数千个 TCP 用户传输相同的数据会浪费带宽。
然而，使用 TCP 还有另一个重要原因。
TCP 可以更轻松地穿过防火墙和 NAT。根据您的 NAT 和运营商，您甚至可能由于 UDP 打洞问题而无法接收 UDP 流。
Besides all the other reasons, UDP can use multicast. Supporting 1000s of TCP users all transmitting the same data wastes bandwidth.
However, there is another important reason for using TCP.
TCP can much more easily pass through firewalls and NATs. Depending on your NAT and operator, you may not even be able to receive a UDP stream due to problems with UDP hole punching.
对于视频流，带宽可能是系统的限制。使用多播可以大大减少上行带宽的使用量。使用 UDP，您可以轻松地将数据包组播到所有连接的终端。
您还可以使用可靠的多播协议，一种称为实用通用多播（PGM），我对它一无所知，而且我猜它的使用并不广泛。
For video streaming bandwidth is likely the constraint on the system. Using multicast you can greatly reduce the amount of upstream bandwidth used. With UDP you can easily multicast your packets to all connected terminals.
You could also use a reliable multicast protocol, one is called Pragmatic General Multicast (PGM), I don't know anything about it and I guess it isn't widespread in its use.
所有“使用 UDP”答案都假设开放网络并“尽可能多地填充”方法。适合老式封闭式专用音频/视频网络，这是一种消失的网络。
在现实世界中，您的传输将穿过防火墙（这将丢弃多播，有时还会丢弃 udp），网络与其他更重要的（$$$）应用程序共享，因此您想要通过以下方式惩罚滥用者窗口缩放。
All the 'use UDP' answers assume an open network and 'stuff it as much as you can' approach. Good for old-style closed-garden dedicated audio/video networks, which are a vanishing sort.
In the actual world, your transmission will go through firewalls (that will drop multicast and sometimes udp), the network is shared with others more important ($$$) apps, so you want to punish abusers with window scaling.
事情就是这样，与其说是时间问题，不如说是内容问题。 TCP 协议要求必须检查、验证并重新传送未传送的数据包。 UDP 不使用此要求。因此，如果您使用 UDP 发送包含数百万个数据包的文件（例如视频），如果某些数据包在传送时丢失，那么它们很可能不会丢失。
This is the thing, it is more a matter of content than it is a time issue. The TCP protocol requires that a packet that was not delivered must be check, verified and redelivered. UDP does not use this requirement. So if you sent a file which contains millions of packets using UDP, like a video, if some of the packets are missing upon delivery, they will most likely go unmissed.