视频流上的 TCP 与 UDP [英] TCP vs UDP on video stream

查看:54
本文介绍了视频流上的 TCP 与 UDP的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我刚刚结束网络编程考试回家,他们问我们的一个问题是如果您要流式传输视频,您会使用 TCP 还是 UDP?请解释一下两种存储的视频和实时视频流".对于这个问题,他们只是希望对存储的视频使用 TCP,对实时视频使用 UDP,但我在回家的路上想到了这一点,使用 UDP 传输实时视频是否一定更好?我的意思是,如果您有足够的带宽,并且说您正在流式传输足球比赛或音乐会,那么您真的需要使用 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 流式传输此音乐会或其他任何内容时,您开始丢失数据包(在您和发送者之间的某个网络中发生了一些不好的事情),并且整整一分钟您都没有收到任何数据包.视频流将暂停,一分钟过去后,数据包又开始通过(IP 为您找到了新路由).然后会发生的是 TCP 会重新传输您丢失的那一分钟并继续向您发送实时流.假设带宽高于流上的比特率,并且 ping 不会太高,因此在很短的时间内,您丢失的一分钟将为您充当流的缓冲区,这样, 如果再次发生丢包,您不会注意到.

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.

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

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 进行实时视频的缺点:

Drawbacks of using TCP for live video:

  1. 正如您所提到的,TCP 会为每个客户端缓冲未确认的段.在某些情况下,这是不可取的,例如非常流行的实时事件的 TCP 流:在这种情况下,您的并发客户端列表(和缓冲要求)很大.预先录制的视频广播通常不会有太大的问题,因为观众往往会错开重播活动.

  1. 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 的交付保证是一种阻塞功能,在交互式对话中没有帮助.假设您的网络连接中断了 15 秒.当我们错过对话的一部分时,我们自然会要求对方重复(或者如果您似乎错过了什么,另一方会主动重复).UDP 不在乎您是否在最后 15 秒内错过了部分对话;它继续工作,好像什么也没发生一样.另一方面,该应用程序可以设计为让 TCP 重播最后 15 秒(而另一端的人可能不想要或不知道这一点).TCP 的这种重播加剧了问题,并使与对话中的其他方保持同步变得更加困难.比较 TCP 和 UDP 在丢包情况下的行为,可以说 UDP 更容易与交互式对话的状态保持同步.

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 多播显着降低了大量观众的视频带宽需求;多播需要 UDP(并且与 TCP 不兼容).注意 - 多播通常仅限于专用网络.请注意,互联网上的多播并不常见.我还要指出,操作多播网络比操作典型的单播网络更复杂.

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

这篇关于视频流上的 TCP 与 UDP的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆