实时通信基本原理

• 在线教育、音视频会议这类直播属于实时互动直播，主要考虑传输的实时性，因此一般使用 UDP 作为底层传输协议

  • 而娱乐直播对实时性要求不高，更多关注的是画面的质量、音视频是否卡顿等问题，所以一般采用 TCP 作为传输协议

• 编码帧

  • I 帧：关键帧
    • 压缩率低，可以单独解码成一幅完整的图像。
  • P 帧：参考帧
    • 压缩率较高，解码时依赖于前面已解码的数据。
  • B 帧：前后参考帧
    • 压缩率最高，解码时不光依赖前面已经解码的帧，而且还依赖它后面的 P 帧。换句话说就是，B 帧后面的 P 帧要优先于它进行解码，然后才能将 B 帧解码

• 共享桌面原理

  • 对于共享者，每秒钟抓取多次屏幕（可以是 3 次、5 次等），每次抓取的屏幕都与上一次抓取的屏幕做比较，取它们的差值，然后对差值进行压缩。再将压缩后的数据通过传输模块传送到观看端；数据到达观看端后，再进行解码，这样即可还原出整幅图片并显示出来
  • 对于远程控制端，当用户通过鼠标点击共享桌面的某个位置时，会首先计算出鼠标实际点击的位置，然后将其作为参数，通过信令发送给共享端。共享端收到信令后，会模拟本地鼠标，即调用相关的 API，完成最终的操作

实时通信架构

协议

(S)RTP/(S)RTCP协议

• 实时互动直播系统的时候必须使用UDP 协议

  • 因为如果网络不好，TCP的重传算法是指数回退的，极端情况下会导致1分钟以上的传输延迟，这对于实时通信系统是无法接受的

• 在实时互动直播系统传输音视频数据流时，我们并不直接将音视频数据流交给 UDP 传输，而是先给音视频数据加个 RTP 头，然后再交给 UDP 进行传输

  • 因为音视频帧的大小远大于UDP的最大传输单元（1.5KB左右），需要对分帧的包进行标记
    • 例如I帧一般会有几十KB，这样就需要传输几十的UDP包到终点并重新组装成I帧并解码
  • 一般来说需要序号，起始和结束标记这几个字段

• RTP包头字段

  • sequence number：序号，用于记录包的顺序
  • timestamp：时间戳，同一个帧的不同分片的时间戳是相同的
    • 这样就省去了前面所讲的起始标记和结束标记，因为不同帧的时间戳肯定是不一样的
  • PT：Payload Type，数据的负载类型
    • 音频流的 PT 值与视频的 PT 值是不同的，通过它就可以知道这个包存放的是什么类型的数据

• RTCP协议用于确定网络链路质量
  • RTCP 有两个重要的报文：RR（Reciever Report） 和 SR(Sender Report)
  • 通过这两个报文的交换，各端就知道自己的网络质量到底如何了
• RTP/RTCP 协议并没有对它的负载数据进行加密
  • 因此，如果你通过抓包工具，如 Wireshark，将音视频数据抓取到后，通过该工具就可以直接将音视频流播放出来
  • 为了防止这类事情发生，没有直接使用 RTP/RTCP 协议，而是使用了 SRTP/SRTCP 协议 ，即安全的 RTP/RTCP 协议

SDP协议

• SDP就是用文本描述的各端（PC 端、Mac 端、Android 端、iOS 端等）的能力，用来进行媒体协商

  • 这里的能力指的是各端所支持的音频编解码器是什么，这些编解码器设定的参数是什么，使用的传输协议是什么，以及包括的音视频媒体是什么等等
  • 通信双方可以根据各自的能力进行协商，协商出大家认可的音视频编解码器、编解码器相关的参数（如音频通道数，采样率等）、传输协议等信息

• SDP信息的交换是通过信令服务器完成的

  • 通信双方都要先与信令服务器建立websocket连接，之后通过服务器转发

• 通信中断重连时要重新进行媒体协商

• 多方通信时，新用户加入时，可以获得先前加入用户的音视频流，但是老用户无法获取新用户的流