TCP和UDP在视频流上

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?

我刚从网络编程的考试中回来，他们问我们的一个问题是“如果你要流视频，你会使用TCP还是UDP?”对存储的视频和实时视频流给出解释。对于这个问题，他们只是简单地期待一个关于存储视频和UDP的简单的视频解决方案，但是我在回家的路上想到了这个问题，是否应该更好地使用UDP来进行视频直播呢?我的意思是，如果你有带宽，并且说你正在播放一场足球比赛，或者是音乐会，你真的需要使用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.

让我们假设当您使用TCP流媒体这个音乐会或其他任何东西时，您开始丢失包(在您和发送方之间的某些网络中发生了一些糟糕的事情)，并且在整整一分钟内您没有得到任何包。视频流将会暂停，当一分钟过去后，数据包又开始通过(IP为你找到了一条新的路径)。然后会发生的是TCP会在丢失的那一分钟重新传输，并继续向您发送实时流。作为一个假设带宽高于流码率,和萍不是太高,所以在很短的时间内,你所失去的一分钟作为流的缓冲区,这样,如果再次发生丢包,你不会注意到。

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)?

这就引出了我的问题。使用TCP进行实时流媒体是否有我不知道的缺点?或者，如果你有足够的带宽，你应该选择TCP，因为它对网络来说更好(流控制)?

13 个解决方案

#1

Drawbacks of using TCP for live video:

实时视频使用TCP的缺点:

Typically live video-streaming appliances are not designed with TCP streaming in mind. If you use TCP, the OS must buffer the unacknowledged segments for every client. This is undesirable, particularly in the case of live events; presumably your list of simultaneous clients is long due to the singularity of the event. Pre-recorded video-casts typically don't have as much of a problem with this because viewers stagger their replay activity; therefore TCP is more appropriate for replaying a video-on-demand.
通常，实时视频流设备在设计时并没有考虑到TCP流。如果使用TCP，操作系统必须为每个客户机缓冲未被确认的段。这是不可取的，特别是在真实事件中;由于事件的奇异性，可能您的并发客户列表很长。预先录制的视频广播通常不会有这么大的问题，因为观众会错开他们的重播活动;因此TCP更适合回放视频点播。
IP multicast significantly reduces video bandwidth requirements for large audiences; TCP prevents the use of IP multicast, but UDP is well-suited for IP multicast.
IP多播显著降低了对大量观众的视频带宽需求;TCP阻止IP组播的使用，但是UDP非常适合IP组播。
Live video is normally a constant-bandwidth stream recorded off a camera; pre-recorded video streams come off a disk. The loss-backoff dynamics of TCP make it harder to serve live video when the source streams are at a constant bandwidth (as would happen for a live-event). If you buffer to disk off a camera, be sure you have enough buffer for unpredictable network events and variable TCP send/backoff rates. Note that if TCP loses too many packets, the connection dies; thus, UDP gives you much more control for this application since UDP doesn't care about networkt transport layer drops.
实时视频通常是用摄像机记录的恒定带宽流;预先录制的视频流来自磁盘。当源流处于固定带宽时(就像发生在实时事件中那样)，TCP的丢失的动态特性使它很难提供实时视频。如果您对相机外的磁盘进行缓冲区，请确保您有足够的缓冲区来处理不可预测的网络事件和可变的TCP发送/备份速率。注意，如果TCP丢失太多的包，连接就会终止;因此，UDP为这个应用程序提供了更多的控制，因为UDP不关心networkt传输层的下降。

FYI, please don't use the word "packages" when describing networks. Networks send "packets".

请注意，在描述网络时，请不要使用“包”这个词。网络发送“包”。

#2

but during a soccer-match, or a concert what does it matter if you are a single minute behind the stream?

但在足球比赛或音乐会中，如果你落后一分钟，那又有什么关系呢?

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.

对一些足球迷来说，有很多。说,甚至几秒钟的延迟出现在数字视频流由于编码(或任何)时可以很烦人,备受瞩目的事件,如世界杯比赛期间,你可以听到隔壁的欢呼和呻吟的人(那些观看undelyed模拟程序)之前,你可以看到游戏导致他们移动。

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).

我认为很多关心体育的人(这是最大的数字电视付费用户,集团至少在德国),被一分钟在视频直播将完全不可接受(如,他们会切换到你的竞争对手,这不会发生)。

#3

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.

如果您的实时流正在使用TCP/IP，那么它将*等待那些丢失的包，然后才能继续处理更新的数据。

That's doubly bad:

这是双重坏:

old data be re-transmitted (that's probably for a frame that was already displayed and therefore worthless) and
旧的数据会被重新传输(这可能是针对已经显示的帧，因此没有价值)
new data can't arrive until after old data was re-transmitted
新数据在旧数据重新传输后才能到达。

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.

如果您的目标是尽可能显示最新的信息(对于实时流来说，您通常希望是最新的，即使您的框架看上去有点糟糕)，那么TCP将对您不利。

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).

对于已记录的流，情况略有不同:您可能需要更多的缓冲(可能需要几分钟)，并且宁愿数据被重新传输，也不愿意由于丢失的包而产生一些工件。在这种情况下，TCP是一个很好的匹配(当然，这仍然可以在UDP中实现，但是TCP没有实时流那么多的缺点)。

#4

There are some use cases suitable to UDP transport and others suitable to TCP transport.

有一些用例适合于UDP传输，还有一些用例适合于TCP传输。

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.

当使用多播向客户传送视频时，使用UDP。

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.

多播的需求是广播服务器和客户之间昂贵的网络硬件。在实践中，这意味着如果您的公司拥有网络基础设施，您可以使用UDP和多播进行实时视频流。即使这样，服务质量也被实现来标记视频数据包并对它们进行优先排序，这样就不会发生包丢失。

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.

该工作流对授权过程进行了模糊处理。网络硬件没有区分订阅用户和其他用户。授权解决方案是对视频内容进行加密，并在订阅有效时在player软件中启用解密。

Unicast (TCP) workflow allows server to check client's credentials and only allow valid subscriptions. Even allow only certain number of simultaneous connections.

单播(TCP)工作流允许服务器检查客户端的凭证，并且只允许有效的订阅。甚至只允许一定数量的同时连接。

Multicast is not enabled over internet.

在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.

必须使用在internet TCP上传输视频。当使用UDP时，开发人员最终会重新实现包的重新传输，例如。bt p2p协议。

"If you use TCP, the OS must buffer the unacknowledged segments for every client. This is undesirable, particularly in the case of live events".

如果使用TCP，操作系统必须为每个客户机缓冲未被确认的段。这是不可取的，尤其是在现场活动的情况下。

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

这个缓冲区必须以某种形式存在。玩家这边的抖动缓冲也是如此。它被称为“套接字缓冲区”，服务器软件可以知道这个缓冲区何时满了，并为实时流丢弃适当的视频帧。最好使用单播/TCP方法，因为服务器软件可以实现合适的帧删除逻辑。在UDP情况下随机丢失数据包只会造成糟糕的用户体验。比如这个视频:http://tinypic.com/r/2qn89xz/9

"IP multicast significantly reduces video bandwidth requirements for large audiences"

“IP多播显著降低了对大量观众的视频带宽要求”

This is true for private networks, Multicast is not enabled over internet.

这对于私有网络是正确的，多播在internet上是不启用的。

"Note that if TCP loses too many packets, the connection dies; thus, UDP gives you much more control for this application since UDP doesn't care about network transport layer drops."

注意，如果TCP丢失了太多的数据包，连接就会终止;因此，UDP为这个应用程序提供了更多的控制，因为UDP不关心网络传输层的下降。

UDP also doesn't care about dropping entire frames or group-of-frames so it does not give any more control over user experience.

UDP也不关心删除整个框架或框架组，因此它不提供对用户体验的更多控制。

"Usually a video stream is somewhat fault tolerant"

"通常视频流是有容错性的"

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.

编码视频不能容忍错误。在传输不可靠的传输时，将错误校正添加到视频容器中。一个很好的例子是MPEG-TS容器，用于卫星视频广播中，其中包含若干音频、视频、EPG等流。这是必要的，因为卫星链路不是双工通信，这意味着接收机不能请求重新传输丢失的数据包。

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.

一些译码器可以在流中中断，在关键位置丢失数据包。

#5

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.

视情况而定。你的流媒体内容有多重要?如果使用TCP至关重要。这可能会导致带宽、视频质量(您可能必须使用较低的质量来处理延迟)和延迟。但是，如果你需要保证内容能够达到目的，那就使用它。

Otherwise UDP should be fine if the stream is not critical and would be preferred because UDP tends to have less overhead.

否则，如果流不重要，那么UDP应该很好，因为UDP的开销较小。

#6

I recommend you to look at new p2p live protocol Bittorent Live.

我建议你看看新的p2p live协议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.

至于流媒体，最好使用UDP，首先是因为它降低了服务器的负载，但主要是因为可以使用多播发送数据包，这比将其发送到每个连接的客户端要简单。

#7

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).

在Internet上交付实时事件的最大问题之一是“规模”，而TCP不能很好地伸缩。例如，当你正在转播一场现场足球比赛——而不是随叫随到的电影回放——观看的人数很容易就会增加1000倍。在这种情况下，使用TCP是对CDNs(内容传递网络)的死刑判决。

There are a couple of main reasons why TCP doesn't scale well:

TCP不能很好地扩展有几个主要原因:

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.

TCP最大的折衷之一是在发送方和接收方之间实现的吞吐量的可变性。当在互联网上传输视频时，视频数据包必须通过互联网上的多个路由器，每个路由器都用不同的速度连接。TCP算法首先从TCP窗口开始，然后逐渐增大，直到检测到数据包丢失，数据包丢失被认为是阻塞的信号，TCP会通过大幅减少窗口大小来响应，以避免阻塞。从而立即减少有效吞吐量。现在想象一个使用6-7路由器传输到客户端的TCP传输网络(一个非常正常的场景)，如果任何一个中间路由器丢失任何数据包，这个链路的TCP会降低传输速率。事实上，路由器之间的流量遵循沙漏形状;在一个中间路由器之间，总是有上下信号。与最努力的UDP相比，使用最有效的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.

您可能已经知道TCP是一个基于确认的协议。例如，假设发送方距离为50ms(即延迟，顺便说一下两点)。这意味着发送一个包到接收方和接收方发送确认的时间为100ms;因此，与基于UDP的传输相比，最大吞吐量已经减半。
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不支持多播或新出现的多播AMT标准。这意味着CDNs没有机会通过复制数据包来减少网络流量——当许多客户端正在观看相同的内容时。这本身就是CDNs(如Akamai或Level3)不使用TCP处理实时流的一个重要原因。

#8

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，你可以轻松地将你的包多播到所有连接的终端。你也可以使用一个可靠的多播协议，一个叫做实用通用多播(PGM)，我对它一无所知，我猜它在使用中并不广泛。

#9

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.

所有的“使用UDP”的答案都假定一个开放的网络，并且“尽可能多地使用它”。适合老式的封闭式花园专用音频/视频网络，它们正在消失。

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.

在现实世界中，您的传输将通过防火墙(将会删除多播，有时还会删除udp)，网络将与其他更重要的应用程序共享($$$)，因此您希望通过窗口扩展来惩罚虐待者。

#10

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.

除了其他原因，UDP还可以使用多播。支持1000s的TCP用户都传输相同的数据会浪费带宽。然而，使用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.

TCP可以更容易地通过防火墙和NATs。根据您的NAT和操作符，您甚至可能无法接收UDP流，因为UDP孔穿孔问题。

#11

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 UDP辩论时，我注意到一个逻辑缺陷。TCP数据包丢失导致一分钟的延迟被转换成一分钟的缓冲区，这与UDP丢失一分钟是不相关的。一个更公平的比较如下。

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.

TCP会发生数据包丢失。当TCP重新发送数据包以尝试传输数学上完美的数据包时，视频被停止。视频会被延迟一分钟，在丢失的数据包到达目的地后，它就会回到原来的位置。我们都在等待，但我们知道我们不会漏掉一个像素。

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.

UDP经历包丢失。在视频中，屏幕的一个角落出现了模糊。没有人会注意到，于是节目继续下去，不去寻找丢失的数据包。

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获得最大的好处。导致TCP延迟一分钟的数据包丢失不会导致UDP延迟一分钟。考虑到大多数系统都使用多个分辨率流，这使得在缺乏包的情况下，事情变得很块，使用UDP就更有意义了。

UDP FTW when streaming.

UDP流时增值。

#12

If the bandwidth is far higher than the bitrate, I would recommend TCP for unicast live video streaming.

如果带宽远高于比特率，我建议TCP支持单播实时视频流。

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.

情形1:连续的数据包丢失持续数秒。无论传输层是什么(TCP或UDP)， >直播视频都将在客户端停止。当网络恢复:-如果使用TCP，客户端视频播放器可以选择在第一个丢失的数据包(移时)重新启动流，或者删除所有延迟的数据包，重新启动视频流而不使用移时。-如果使用UDP，客户端没有选择，视频重新启动，没有任何时间转移。=> TCP =或更好。

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

案例2:有些数据包是随机的，在网络上经常丢失。-如果使用TCP，这些数据包将立即被重新传输，并且使用正确的抖动缓冲区，不会影响视频流的质量/延迟。-如果使用UDP，视频质量会很差。= > TCP好多了

#13

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.

这就是问题所在，与其说是时间问题，不如说是内容问题。TCP协议要求未发送的数据包必须被检查、验证和重新发送。UDP不使用这个需求。因此，如果您发送了一个包含数百万个使用UDP的数据包的文件，比如一个视频，如果在交付时丢失了一些数据包，那么它们很可能不会丢失。

#1