2017-06-19

基于 TCP UDP 协议的实时流媒体的实时性分析

Views: 1827 | 2 Comments

直播,电话通话,视频聊天都是实时流媒体的范畴。无论使用 TCP 还是 UDP,都会有延时。有个过时的观点是 UDP 更实时,但我不认为是这样。

实时流媒体的延时主要有几个因素:发送方缓冲,接收方缓冲,网络延时。缓冲包括网络缓冲,录制缓和冲播放缓冲。假设发送方缓冲是 10ms,接收方缓冲都是 50ms,网络延时是 100ms,那么就有至少 160ms 的播放延时。接收方缓冲比发送方多,是为了解决所谓的 jitter,网络延时不均匀导致的播放断续。

如果使用 UDP,如果丢包,那么接收方的缓冲就从 50ms 变为 40ms,交互延时变小,随着继续丢包变为 0 时,网络延时不旦不均匀就会发生 jitter 了。这时开始缓冲,一共花 50ms,所以信号中断最多 50ms,也即接收方缓冲。

如果使用 TCP,丢包会导致 TCP 重传,因为网络 rtt 是 200ms,到 50ms 时,接收方的缓冲已经没有数据了,只能等待网络传输,然后再等 150 ms(也即信号中断 150 ms),突然一次收到 110ms 的数据到接收方缓冲中。为了保证低延时,主动丢弃最早的 60ms 数据。使用 TCP,信号中断时时长是 150 ms,也即网络 rtt 减去接收方缓冲。因为 TCP 最坏情况要重传3次,所以是 3*rtt 减去接收方缓冲。

上面的例子,如果我们把接收缓冲加大,或者网络延时减小,那么两者的信号中断时长会变得更接近。目前,中国南北的网络 rtt 一般在 100ms,我没找到资料,但感觉语音通话的延时在 500ms 以内人应该是感觉不到的。所以我们可以增加接收方缓冲,这时最好没有信号中断。这时,UDP 因为丢包导致的好效应就没那么诱人了。

总结一下,UDP 开始丢包会导致好的效应,能让延时越来越小,小到只有发送缓冲时长和网络延时,累积丢包导致信号中断时长最多为接收方缓冲的时长。TCP 的延时保持不变,任何丢包都会导致信号中断,而且信号中断时长可能会更长,但加大缓冲区可以减少信号中断出现的概率。

Related posts:

  1. OS X 屏幕录制视频转 GIF 动画
  2. P2P与即时消息(IM)
  3. iOS流式布局UI框架CocoaUI开源
  4. Master-Workers 模式处理高负载
  5. SIP报文Via和Contact的区别
Posted by ideawu at 2017-06-19 20:31:58 Tags: ,

2 Responses to "基于 TCP UDP 协议的实时流媒体的实时性分析"

  • emmm……
    但是放到场景上(比如看视频),如果tcp发生了丢包,这种延时是会被累积下去的吧…… Reply
  • 1、如果没有丢包,两种方式效果基本一致;
    2、一旦有丢包,TCP发送带宽降得快升得慢(为保证公平性);
    3、使用UDP可以尽量尝试快发多发,从而获得比TCP更好的带宽传输资源;
    4、早些年流行的下载软件采用多线程同时下载一个文件比较快也就是这个原理(非限速情况下)。 Reply

Leave a Comment