--- theme: channing-cyan highlight: vs2015 --- ### 前置知识 #### TCP与UDP ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4aef647a381b4835bf603b710f4865c1~tplv-k3u1fbpfcp-watermark.image#?w=1372\&h=1860\&s=494464\&e=png\&b=f7ece4) ##### TCP **HTTP是运行于TCP之上的，是万维网的运转的基础** > TCP是可靠的传输协议，可以保证数据在传输过程中不丢失，不乱序(不抖动)，对于大多数的网络应用程序，TCP为传输提供了非常好的网络质量，满足日常需求 * 缺点 * 为了实现较高的可靠性牺牲了实时性，且不可预估，延迟具有累计的效果 * 工作原理 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/df20f0b019c242d980dacf53308d2b17~tplv-k3u1fbpfcp-watermark.image#?w=1422\&h=1780\&s=518658\&e=png\&b=fefefe) * `发送` → `确认` → `丢包` → `重传` * 为了增加网络吞吐量，采用了延迟确认和Nagle算法 - TCP延迟的根本原因 * Nagle算法：将多个小包组成一个大包发送，组合包的大小不超过网络最大传输单元(MTU:Maximum Transmission Unit) * MTU：以太网的数据链路层对网络层数据包的长度有一个限制，最大默认值是1500字节，这个1500字节数据长度是针对网络层的，不包含链路层的头部和尾部 * 为了增加网络吞吐量，接收端不必每收到一个包就确认一次，而是对一段时间内的所有数据集体确认一次即可 * 接收端：启动一个计时器，一般为200ms，即每隔200ms确认一次接收到的数据 - TCP延迟确认机制 * 发送端：启动一个计时器，用来判定是否有丢包的情况，发送端定时器的时长为一个RTO，当在该时间段内还是没有收到确认消息，则认为包丢失了，需要发送端重新发送丢失的包 - TCP丢包重传机制 * RTO(Retransmission Timeout)，重传超时时长，其值约等于RTT的平均值，每次超时后以指数级别增长； * RTT：表示一个数据包从发送端到接收端然后再回到发送端所用时长 ##### UDP > UDP是不可靠的数据传输协议，在数据传输时不保证数据可靠到达，也不保证有序性，唯一最大的特点就是快；\ > webRTC为了解决UDP的丢包和抖动问题，给出了通过NACK、FEC、JitterBuffer以及NetEQ技术既可以解决丢包问题和抖动问题，又不会产生影响服务质量的时延 * TCP与UDP的特点 * TCP是面向连接的，UDP是无连接的 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4aa5ae07284a49edb718f9997715c97a~tplv-k3u1fbpfcp-watermark.image#?w=1009\&h=568\&s=127075\&e=png\&b=fefefe) * TCP是面向字节流的，实际上是TCP把连接传输的数据看成一连串无结构的字节流；UDP是面向报文的 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e933468f0ad84744b5f88df7f3a76419~tplv-k3u1fbpfcp-watermark.image#?w=1254\&h=539\&s=169213\&e=png\&b=fffefe) * 对于UDP，发送和接收方应用层只给UDP传输层发送或接收报文，而UDP除了传输外的处理只是对应用层报文添加或摘除UDP首部，保留的应用层的报文 * TCP只是将应用层传递下来的无结构字节流存入缓存并根据策略构建TCP报文进行发送，而接收方TCP只提取数据载荷部分存入缓存，同时将缓存的字节流交给应用层 * TCP是不保证双方应用层的发送和接收数据具有大小对应的关系的，这也是TCP实现流量控制和拥塞控制的基础(TCP是面向字节流的) * TCP提供可靠传输，也就是说TCP连接传输的数据不会丢失，没有重复，且按顺序到达；UDP提供不可靠传输 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3f3052c7b767412994d176d9ff4e66c9~tplv-k3u1fbpfcp-watermark.image#?w=1120\&h=433\&s=255712\&e=png\&b=fffcfc) * UDP在传输数据时如果发生了丢包，发送方是不做任何处理的，接收方在校验首部时发现错误同样也是不做任何处理的；因此说UDP向上提供的是不可靠无连接的服务 * TCP在数据传输时，如果发生了丢包或者接收方检测出了错误(此时接收方会丢弃数据)，接收方不会回确认报文，导致触发了接收方超时重传重发的机制，因此TCP通过其策略保证其传输过程中无论发生什么情况接收方都可以正确的收到数据包，因此说TCP是向上提供面向连接的可靠服务 * WebRTC在信令控制方面采用了可靠的TCP，但是在音视频数据传输上，使用了UDP作为传输层协议 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9c1bfeb74c7c48eeaab7c603fb9c15fe~tplv-k3u1fbpfcp-watermark.image#?w=1600\&h=831\&s=303505\&e=png\&b=f5e9e8) ### 协议简单分类 > WebRTC同时支持传输`音视频数据`、`自定义应用数据`。这其中涉及了多种协议，包括RTP/SRTP、RTCP/SRTCP、UDP、DTLS、SCTP，简单总结分类为：传输音视频数据相关协议(UDP、DTLS、RTP/SRTP)和传输自定义应用数据相关协议(UDP、DTLS、SCTP)；\ > 在webRTC中的JitterBuffer就是用来实现UDP的发送和接受缓冲的 #### 加密信道建立：UDP、DTLS > 对于WebRTC应用来说，不管是音视频数据还是自定义应用数据，都要求基于`加密的信道`进行传输。DTLS有点类似TLS，在UDP的基础上实现信道的加密； ##### DTLS主要用途 * 让通信双方协商密钥，用来对数据进行加解密 * 通信双方：通过`DTLS握手`，协商生成一对`密钥` * 发送方：对数据进行`加密` * 发送方：通过`UDP传输`加密数据 * 接收方：对加密数据进行`解密` #### 音视频概念解析 * 音视频编码格式和压缩手段 * 常见的编码格式：mpeg-2、mpeg-4、h.163、h.264、RV40等 * 压缩手段 * 在封装格式里的视频可以用不同的编码格式，在编码格式上进行压缩处理，编码格式可以简单理解为用特定的压缩技术对视频做相应的处理 * 在容器里进行数据的压缩处理 * 音视频封装格式 * 封装格式就是将已经编码封装好的视频、音频按照一定的规范放到一起 * 同一种封装格式可以放不同编码的视频 * 一种视频容器一般只支持某几类编码格式的视频 * 适合媒体串流中的媒体封装格式 * FLV(Flash Video) * FLV格式的流中，每个音视频数据都被封装成了时间戳消息头的数据包，在播放器拿到这些数据包后就会解析时间戳然后将该数据包和之前已经到达的音视频数据进行拼接起来，进而实现连续播放的功能 * 传统的MP4、MKV等都需要拿到完整的音视频文件才能播放，因为内部的单个音视频数据块不带有时间戳信息，播放器无法将不带时间戳信息的数据连续起来，所以不能实时的解码播放 * TS(Transport Stream) * 全称是MPEG2-TS，TS主要是用于实时传输的场景，TS流由固定长度(188字节)的TS包组成，TS包是具有同一时间基准的一个或多个PES包复合合成的 * TS流的后缀一般是.ts、.mpg、.mpeg，多数播放器是支持这种格式的数据流的，HLS协议就是基于TS流实现的； * TS文件码流可以分为三层 * ES层：就是音视频数据 * PES层：是在音视频数据上加了时间戳等对数据帧的说明信息 * TS层：就是在PES层上加入了数据流识别和传输的必要信息 * 其特点是多个TS片段可以被播放器无缝拼接进行播放，无需等待重新载入；其要求从视频流的任一片段开始都是可以独立解码的 * 浏览器支持的格式 * 对于video标签来说，浏览器支持的视频播放的封装格式有：MP4、WebM和Ogg * MP4格式的音视频编码组合 * h.264编码的视频和acc编码的音频 * WebM格式的音视频编码组合 * VP8视频编解码器和Vorbis音频编解码器 * Ogg格式的音视频编码组合 * 使用Theora视频编解码器和Vorbis音频编解码器 #### 音视频数据传输：RTP/SRTP、RTCP/SRTCP * 音视频中的一个视频帧数据需要多个包来传输，并且在接收端组合成对应的帧，真确还原出视频信号，至少需要做到以下两点 * 检测出对应的顺序，并保持采样和播放之间的同步关系 * 需要在接收端检测出分组的丢失 * 传统的UDP是没有这个能力的，因此在音视频传输中，并不直接使用UDP，而是需要RTP作为实时音视频中的应用层协议 * RTP(Real-time Transport Protocol)实时传输协议，用来实时传输`音视频数据` * RTCP：RTP传输控制协议，主要用来`监控`传输数据的`质量`，并给予数据发送方`反馈` #### 自定义应用数据传输：SCTP > SCTP(Stream Control Transmission Protocol)流控制传输协议，STCP依赖DTLS建立的加密信道，对于自定义应用数据的发送，流程如下 * 通信双方：通过`DTLS握手`，协商生成一对`密钥` * 数据发送方：将自定义应用数据，通过密钥进行`加密`，生成SCTP包 * 数据发送方：通过`UDP传输`SCTP包 #### 音视频数据发送过程概括 * 通信双方：通过`DTLS握手`，协商生成一对`密钥` * 数据发送方：将音视频数据封装成`RTP包`，将控制数据封装成`RTCP包` * 数据发送方：利用加密协议，对RTP包，RTCP包进行`加密`，生成SRTP包、SRTCP包 * 数据发送方：通过`UDP传输S`RTP包，SRTCP包 > WebRTC在传递媒体流到对等端时，涉及到`媒体信息协商`、`网络建立协商`、`网络传输`等技术，这些技术不仅用于WebRTC底层，也广泛用于其他流媒体领域。 > WebRTC使用安全实时传输协议(Secure Real-time Transport Protocol，SRTP)对RTP数据进行加密，`消息认证`和`完整性`以及重播攻击保护。 > ![WebRTC基础传输技术架构.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/96f5f4a672874d059722f2cd8c0db1d4~tplv-k3u1fbpfcp-watermark.image#?w=1148\&h=594\&s=197516\&e=png\&b=fefefe) ### UDP和TCP的选择 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/82818755dd974ee9ab1c4e48cf374ebe~tplv-k3u1fbpfcp-watermark.image#?w=1324\&h=1834\&s=542654\&e=png\&b=f7ede5) #### 选择依据浅析 > 在TCP/IP四层结构中，网络传输层是最为重要的一层协议，该层中包含了两种协议：TCP和UDP； ##### TCP浅析 * TCP是`可靠`传输协议，可以保证数据在传输过程中不丢失、不乱序、不抖动； * TCP的缺点是`实时性差` * 其可靠性是以`牺牲实时性`为代价的 * 按照TCP的原理，当出现极端的网络情况时，每个包的延时将达到秒级以上，而且是`不断叠加`的，对于音视频实时通信来说是不可接受的； * TCP原理 - 缺点的原因 * 为了实现数据传输的`可靠性`，采用的是`发送→确认→丢包→重传`的机制 * 而且为了`增加网络吞吐量`，还采用了`延迟确认`和`Nagle算法`，这套机制是导致TCP产生延迟的根本原因 * Nagle算法，将多个`小包`组成一个`大包`发送，组合包的大小不超过网络最大传输单元(最大数据单元是用来通知对方所能接受数据服务单元的最大尺寸) ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1269811abf9a4551a8772d0714f324d3~tplv-k3u1fbpfcp-watermark.image#?w=1332\&h=1762\&s=506627\&e=png\&b=ffffff) * 延迟确认机制 * 为了增加吞吐量，接收端不必每个包都进行一次确认，而是对一段时间内收到的所有数据`集体确认`一次即可 * 其原理就是在TCP在`接收端`启动一个`定时器`，一般为`200ms`，即每隔200ms确认一次接收到的数据 * 丢包重传机制 * TCP会在发送端也启动一个`定时器`，该定时器只是用来判别是否有丢包的情况，时长一般为一个`RTO`，如果在定时器超时后还是没有收到包的确认信息，则认为包丢失了，需要发送端重新发送丢失的包； * RTO（Retransmission Timeout），重传超时时长。其值约等于`RTT的平均值`，每次超时后以指数级增长。`RTT表示一个数据包从发送端到接收端，然后再回到发送端所用的时长`。 * 上述两种机制存在的问题 * 接收端发出的确认消息丢失后发送端并不会时时得到反馈，而是得等到发送端定时器超时后才可以进行将未确认的包重传； * 而另一种情况时接收端都接收到数据了，但是接收端发出的确认消息丢失了，这样还是会导致发送端出现上述的问题 * 这两种情况在TCP传输中的时延要`累加`很多，且`不可控` * TCP在极端的网络情况下，不能控制传输的延时大小，所以实时通信传输时首选UDP ##### UDP浅析 > UDP属于`不可靠传输协议`，在数据传输过程中，不能保证数据能可靠到达，也不保证数据有序，但他的最大优点就是传输速度`”快“` * UDP没有像TCP那样的一套保证数据可靠、有序的控制逻辑，因此`实时性最高` * 解决UDP的丢包和抖动问题 * WebRTC通过`NACK`、`FEC`、`JitterBuffer`以及`NetEQ技术`既可以解决丢包和抖动的问题，又不会产生影响服务质量的延时问题 * 延时宽带预测算法步骤 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6a923841588a4d328a86e24e796a8ec7~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=674\&h=236\&s=75029\&e=png\&b=fefdfd) ![码控.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fc828fd84c6e44aab675fe991f4c939f~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=2754\&h=1458\&s=400298\&e=png\&b=fef8f8) * 计算一组RTP包的发送时长和接收时长，并计算延时 * 一个组的判断标准： * 当前组的第一个数据和最后一个数据的发送时差不大于5ms，否则认为是新组的开始 * UDP中会存在乱序到达的情况，这种数据可以进行忽略操作 * 需要根据当前延时和历史延时来计算延时变化的趋势 * 根据延时变化趋势判断网络状况 * 根据网络状况调整更新预测的带宽值 ### RTP ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/185a30a85bd24ec082fbe1c76a987fb0~tplv-k3u1fbpfcp-watermark.image#?w=1238\&h=1286\&s=438074\&e=png\&b=f6ebe1) > UDP在传输一些有前后逻辑关系的数据时，会显得捉襟见肘，而音视频正是这样的数据，为了解决这些问题，在传输音视频数据时，通常在UDP之上加一个新协议，即RTP；\ > RTP属于应用层传输协议的一种，与HTTP/HTTPS处于同一级别；RTP的设计基于应用层框架和集成层处理的基本原理。它提供源和负载类型的标识，流同步、丢包和重新排序以及媒体流监控。 #### 简介 **RTP包包含两个部分：第一个是RTP头(携带的一些额外的信息)，另一个是RTP有效载荷(视频流数据载体)** > RTP(Real-time Transport Protocol，实时传输协议)，通过IP网络实时传输音频和视频。RTP常用于`流媒体服务`的通信系统，如电话会议、视频会议、电话服务等；\ > RTP是专门为流媒体的端到端实时传输设计的，更关注信息的`实时性`，而为了避免因网络传输导致的质量下降的问题，可以使用合适的`纠错算法`使得用户无感知；\ > 大多数RTP应用都是`基于UDP`创建的，并提供额外`抖动补偿`、`包丢失检测`和`无序传递检测`的功能；当然RTP也支持TCP，但是因为TCP是注重可靠性而不是实时性，所以很少使用TCP #### 解决的问题 > 我们在进行实时通信的时候，一般是将原始数据进行编码压缩后，再将编码流传输到接收端；而在传输的时候不会直接将编码数据进行传输，而是先将码流打包成一个个的RTP包再进行发送，打包成RTP包的原因是：因为接收端要能够正确的使用这些音视频编码数据，不仅仅需要原始的编码码流，还需要一些额外的额信息如当前视频码流是哪种视频编码标准、解码后的码流需要什么播放速度播放视频等等信息都需要进行封装到RTP包中进行告知到接收端 * 定位丢的数据包 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/abcae31cecc04ad78c9645e643bfe30b~tplv-k3u1fbpfcp-watermark.image#?w=1314\&h=914\&s=302287\&e=png\&b=fcf9f9) * 希望在使用RTP传输音视频数据时，一旦有数据丢失，可以`快速的定位`到是哪个数据包丢失了 * 在发送端，每产生一个RTP包，其`Sequence Number`字段中的值就被自动加一，以保证每个包的编号`唯一且连续` * 在接收端接收到RTP包时会对Sequence Number字段进行检查，当该字段`不连续`时就认为`丢失`或者`乱序`了 * 区分同一个端口传输的不同类型的数据 * 在网络应用中，通常会在`同一个端口`传输`不同类型`的数据，如音视频数据但接收端是如何进行区分的呢；RTP在`协议头`中设置了`PT(PayloadType)`字段，接收端可以依据该字段区分出具体的数据类型来； * 同理`同一个端口`不仅可以同时传输不同类型的数据包，还可以传输`同一类型`的`不同源`的数据包，如流媒体服务就可以将多个不同源的视频通过同一个端口转发给客户端，而客户端通过RTP中的另一个字段`SSRC`进行区分(每个源的SSRC必须是`唯一`的) #### 需要提供的能力 * 实时数据的端到端传输 * 序号(用于丢包和重排序检) * 时间戳(时间同步校对和分发监控) * 载荷的定义类型(用于说明数据的编码格式) * 不包括的点 * 及时发送 * 质量保证 * 送达(可能丢失) * 时序(到达顺序) #### 主要特点 * 本身没有提供按时发送机制或其他服务质量(QoS)保证，因此RTP还需要有一套配套协议为其服务质量提供保证，即RTCP(Real-time Control Protocol)协议 * RTP标准定义了两个子协议，RTP和RTCP * 在传输音视频时的丢包、乱序、抖动等情况，WebRTC底层都做了相应的处理策略，但是如何将这些传输时的「网络质量信息」实时传递给对方，就是RTCP的作用，对于RTP来说，RTCP所占用的宽带非常小，通常只有5% * 具有较`低延时` - 基于UDP，UDP注重实时性 * 数据包在传输过程中可能会`丢失`，且到达对等端的`顺序`可能也会发生变化，所以对等端收到RTP数据包后需要根据数据包的`序列号`和`时间戳`进行`重新排列`； * 支持`多播(multicast)`，适合于海量用户通话的场景 * 可用于除音视频通话之外的场景，如`实时数据流`、`状态实时更新`、`控制消息传输`等连续数据的场景 * RTP的定位是`低延时`数据传输，本身并没有提供服务质量保障功能(Quality of Service，QoS)，所以在WebRTC中，`RTP需要和RTCP结合使用` * RTP会为每个媒体流创建一个会话，即视频和音频使用单独的RTP会话，这样接收端可以`选择性的接收`媒体流 * RTP使用的UDP端口号为`偶数`，每个关联的RTCP端口为下一个`较高的奇数`，端口范围为`1024~65535` #### RTP配置文件和载荷 > RTP在设计之初就考虑到了在不修改标准的情况下携带多种媒体格式并允许使用新格式，所以，RTP标头数据中不包含媒体格式信息，而是在单独的`RTP配置文件`（profile）和`有效载荷`（payload）格式中提供，这种方式提供了更好的`可扩展性`;\ > RTP对每类应用(如音频和视频)都定义了`一个配置文件`和`至少一个有效载荷格式`； * RTP配置文件包括以下三种 * 音频和视频会议的RTP配置文件(RPC 3551) * 定义了一组静态有效载荷类型分配以及使用会话描述协议（SDP）在有效载荷格式和PT值之间进行映射的动态机制。 * SRTP(RPC 3771) * 定义了一个RTP配置文件，该配置文件提供用于传输有效载荷数据的加密服务，WebRTC用的就是SRTP * 实验性控制数据配置文件 * 用于机器对机器通信的RTP ### RTCP > 当应用建立一个RTP会话时，应用程序将确定一对目的传送地址，目的传送地址由一个网络地址和一对端口组成，两个端口一个是给RTP包、一个是给RTCP包，RTP数据发向偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口，这样就构成了一个UDP端口对，大致流程是： * 传输协议层面上的整个流程 * RTP协议从上层接收流媒体信息码流，封装成RTP数据包 * RTCP从上层接收控制信息，封装成RTCP控制包 * RTP将RTP 数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口 **RTP通常在偶数UDP端口上发送，而RTCP消息将在写一个更高的奇数端口上发送** #### 简介 > RTCP(RTP Control Protocol)是实时传输协议(RTP)的姊妹协议和`控制协议`，RTCP可以对RTP进行`丢包等控制`，其基本功能和数据包结构在RFC 3550中定义；\ > RTCP主要功能是定期发送数据包计数、丢失数据包的信息、丢包率、数据包延迟变化以及往返延迟时间等统计信息，向媒体参与者提供媒体分发中的服务质量保障，应用程序在收到这些消息后，可以通过`限制流量`或`更换编解码器`格式的方式提升服务质量，同时RTCP的流量占用是很小的； > RTCP报告间隔是随机的，最小报告时间间隔为`5s`，通常发送RTCP报告的频率不应该低于`5s/次`； #### RTCP支持的数据包 ##### 发送者报告(SR) > 活跃发送者在会议中定期发送报告，报告该时间内发送的所有RTP数据包额发送和接收信息，发送者报告包含绝对时间戳，用于帮助接收方同步RTP消息 ##### 接受者报告(RR) > 适用于不发送RTP数据包的被动参与者，用于通知发送者和其他接受者服务质量；此报告包含当前的`丢包比率`，接收到的`最高序列号`，并有助于`计算往返时间` ##### 源描述(SDES) > 用于将CNAME项发送给会话参与者，也可以用于提供其他信息 ##### 关闭流(BYE) > 源发送BYE消息以关闭流，允许端点(endpoint)宣布即将离开会议 **Wireshark是一个强大的网络数据包分析软件，可以详细的展示网络数据包的交换过程，同样的也可以很方便的抓包来还原RTP包和RTCP报文的真面目** #### RTP和RTCP关联 > RTP协议用来封装传输音视频数据且带上一些基本信息，而RTCP协议是用来统计这些RTP包的传输情况，RTP和RTCP一般是使用UDP协议，但是UDP协议没有实现拥塞控制算法； ### RTMP和HTTP-FLV #### RTMP **可以理解为是使用FLV的封装，并使用TCP进行传输** > RTMP(Real Time Messaging Protocol 实时信息控制协议)是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议，该协议在国内直播平台中较为普遍；\ > RTMP是一种基于TCP进行实时流媒体通信的网络协议(默认使用端口是1935)，主要用于在Flash平台和支持RTMP协议的流媒体服务器之间进行音视频和数据通信，RTMP所支持的媒体格式是FLV，在浏览器里是不支持RTMP协议的，只能通过Flash插件进行处理；\ > 在RTMP协议下，可以用来拉流和推流操作 * 简介 * RTMP是一个二进制协议，在流媒体服务器和流媒体播放器之间使用专用链接，从而确保了更快的视频流，且不太可能被缓冲中断 * 目前RTMP主要用于流式传输实时视频，播放可以非常流畅，还支持动态播放控制，允许用户跳转播放 * RTMP的变体 * RTMP在默认情况下使用TCP，端口号是1935 * RTMPS：类似于RTMPT，增加了TLS/SSL的安全功能，即通过TLS/SSL连接的RTMP * RTMPE：是使用Adobe自己的安全机制进行RTMP加密的，在RTMP基础上增加了加密功能 * RTMPT：封装在HTTP请求中以穿越防火墙，RTMPT经常使用TCP端口80和443上的明文请求来绕过大多数公司的流量过滤 * RTMFP：实时媒体流协议，一种通过网络进行通信的安全传输协议 * 工作流程 * 一般分为四个步骤 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/55d72a4966d94a82ab2208e61c1edb29~tplv-k3u1fbpfcp-watermark.image#?w=1385\&h=655\&s=235229\&e=png\&b=ffffff) * 相机捕捉PAW视频 * RTMP编码器将此PAW视频转成数字视频，并将其发送到Flowplayer等在线视频主机 * 在线视频主机接收编码的视频并通过HLS协议将其传送到观众的设备 * 观看设备以最小的延迟实时播放实时视频 * 数据传输步骤(使用TCP传输数据) ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e0ba83d019c84561af679b7717c86aba~tplv-k3u1fbpfcp-watermark.image#?w=1285\&h=659\&s=246036\&e=png\&a=1\&b=c8e6cb) * 握手：客户端的Flash Player连接媒体服务器来打通他们之间的RTMP连接 * 连接：客户端发送特定视频流的连接请求 * 流：服务器收到请求后，会将原始数据转换为SWF，即小型的Web格式，服务器通过RTMP将流发送到目标端口 * RTMP流式传输步骤 * 观看端向看直播或点播视频时，媒体播放器会向流媒体服务器发送请求、然后服务器会使用RTMP协议直接与媒体播放器建立连接 * 一旦媒体播放器与服务器建立连接后，服务器就会将编码的多媒体数据发送到媒体播放器 * 解码过程和播放都发生在Flash播放器或其他媒体播放器中 * 优劣势分析 * 优势 * 实时性高 * RTMP的实时性在3s之内，即使经过了多层CDN分发实时性也在3s之内，常规的HTTP流的时延一般在10s以上； * 低延迟 * 采用独占的1935端口，无需缓冲，基于TCP连接稳定，这样可以实现观众端断网重连之后还可以接着上一次断开的进度继续观看 * 通过减小数据包的大小并减少协议的开销来实现的 * RTMP也可以用于`实时流媒体解决方案`和视频点播(VOD) * 易于集成 * RTMP可以集成整合文本、视频和音频 * 也可以支持MP3和AAC音频流、MP4、FLV和F4V视频流 * 支持加密 * RTMPE和RTMPS为加密协议，在PC平台上Flash对RTMPE和RTMPS支持度还是不错滴，另外基本所有的编码器(摄像头之类)都支持RTMP的输出 * 稳定性高 * 稳定性大多体现在集群分发、服务器管理、设备切换。客户端支持上，当然服务端的稳定性也是较重要的 * 另外在Flash播放RTMP流时可以实现长时间的不断流、不出问题的情况 * 缺点 * RTMP不支持高分辨率视频和VP9、AV1等视频压缩方法 * 设备兼容性方面，大多设备都不再接受RTMP直播(需要借助外挂第三方解码器)，某些网络默认阻止了RTMP的1935端口，需要特殊处理进行解决 * 会有数据丢失的情况，网络状况对其影响较大 * 有累积延迟，RTMP基于TCP不会丢包，当网络状况较差时，服务器会将包缓存起来，导致累积的延迟，当网络恢复后就会一起发送给客户端，对应的解决方案就是当缓冲区很大时，就断开重连 * 大部分的视频流服务商都提供了远程编码的功能，流推上去后会自动编码成RTMP和HLS，想给APP用就使用RTMP，想给网页用就采用HLS(包括有的厂商推出的优化后的HLS+) * 选择方案推荐 * PC/Phone+直播+实时性要求高：使用flash播放RTMP * PC/Phone+直播+没有实时性要求：使用RTMP或者HLS均可 * PC/Phone+点播：使用HTTP或者HLS * Phone+WEB+直播：HLS * 推荐文献 * [RTMP](https://juejin.cn/post/7125796278214066207) #### RTSP(Real Time Streaming Protocol：实时流传输协议) [RTSP协议详解](https://blog.csdn.net/qq_25330791/article/details/127285875) ![RTSP请求流程图.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cd31a3c51abc4985931b0f5ae486e28d~tplv-k3u1fbpfcp-watermark.image#?w=1060\&h=650\&s=342155\&e=png\&b=ffffff) > RTSP是`TCP/IP协议`体系中的一个`应用层协议`，使用的是554端口，在体系结构上位于RTP和RTCP之上，使用TCP或UDP完成数据传输，其定义了`一对多应用程序`如何有效的通过`IP网络`传输多媒体数据，提供了一个可拓展框架，数据源可以包括实时数据与已有的存储的数据；\ > RTSP可以是双向的，客户端和服务端都可以发出请求，不同于HTTP的单项，只能由客户端发请求； ##### 特点 * RTSP是一种网络控制协议，用于控制多媒体数据的流式传输方式 * 状态性 * RTSP是有状态的，其命令总是按照顺序来发送，其中某个命令可能需要总在另一个命令之前要发送 * HTTP是无状态的，协议在发送一个命令之后就断开连接了，且命令之间是没有依赖性的 > 现在好多摄像头、监控设备厂商，其设备提供的就是RTSP流，如果想要将监控视频接到Web端，就需要单独的技术来实现了； #### HTTP-FLV > 该协议主要是为了让原本只能在RTMP中进行传输的FLV音视频流也可以在HTTP下进行传输。主要是用于FLV可以在浏览器中进行播放，由于HTML的video不支持FLV格式的音视频，所以在早期需要再网页中加入Flash插件才可以播放，目前大量的流媒体服务器Media Server都支持了将FLV格式的流通过HTTP-FLV的形式对外界进行开放 [如何在html中播放.flv格式的视频](https://blog.csdn.net/weixin_45316326/article/details/99053910) ### SRTP/SRTCP **WebRTC使用的就是SRTP，因为RTP没有内置安全机制** > 对于未加密的实时通信应用，可能会遇到多种形式的安全风险，如在传输途中可能会被第三方`拦截窃取`，RTP没有内置任何安全机制，因此不能保证数据的安全性，需要依靠`外部机制`进行加密 #### 简介 > SRTP是RTP的一个配置文件，旨在为单播和多播应用程序中的RTP数据提供`加密`、消息`身份验证`和`完整性`以及重放`攻击保护`等安全功能。SRTP有一个姊妹协议：安全RTCP（SRTCP），它提供了与RTCP相同的功能，并增强了安全性。\ > 使用SRTP或SRTCP时必须启用`消息身份验证`功能，其他功能自选；SRTP和SRTCP默认的加密算法是`AES`，攻击者虽然无法解密数据，但可以伪造或重放以前发送的数据。因此，SRTP标准还提供了确保数据完整性和安全性的方法 ### TLS/DTLS #### 简介 > 安全套接层（Secure Socket Layer，SSL）是为网络通信提供安全保证及数据完整性的一种`安全协议`。SSL由网景公司（Netscape）研发，用于确保互联网连接安全，保护两个系统之间发送的敏感数据，防止网络犯罪分子读取和篡改传输信息。\ > IETF对SSL 3.0进行了标准化，并添加了一些机制，经过标准化的SSL更名为TLS（Transport Layer Security，安全传输层）协议。所以，可以将TLS理解为SSL标准化后的产物; > 由于TLS是`基于TCP`，不能保证UDP上传输的数据的安全性，因此在TLS协议架构上进行了扩展，提出DTLS（Datagram Transport Layer Security，数据包传输层安全性）协议，使之`支持UDP`，DTLS即成为TLS的一个支持数据包传输的版本。DTLS使用`非对称加密`方法，对数据身份验证和消息身份验证提供`完全加密`。 > DTLS协议内置在WebRTC的标准化协议中，并且是在Web浏览器、电子邮件和VoIP平台中始终使用的协议，这意味着基于Web的应用程序无须提前设置。 ### SDP #### 简介 > SDP(Session Description Protocol)用于描述`媒体信息`的协议，以文本格式描述终端功能(各端支持的音视频编解码器)和首选项。SDP只包含终端的`媒体元数据`，不包含媒体数据内容，建立连接的双方通过交换SDP获取彼此的媒体信息，SDP广泛用于会话启动协议(SIP)、RTP和实时流协议(RSP) * SDP包含的内容 * 会话属性 * 会话活动时间 * 会话包含的媒体信息 * 媒体编解码器 * 媒体地址和端口号 * 网络宽带信息 * SDP字段含义及格式 ![SDP字段含义及格式.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ad38fa6bab34493d8ae1f55fd495fbe0~tplv-k3u1fbpfcp-watermark.image#?w=1552\&h=1072\&s=603275\&e=png\&b=fcfcfc) #### SDP示例 ```js v=0 // 会话由用户jdoe创建发起会话的源地址为10.47.16.5 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 //会话名称是SDP Seminar s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) // 指明了目标的IP地址为224.2.17.12 地址的TTL是127 c=IN IP4 224.2.17.12/127 // 指明了会话在2个小时内有效 t=2873397496 2873404696 a=recvonly // 表明只接收数据 //两个m字段指明都使用RTP音视频配置：第一个音频媒体流使用端口49170，载荷类型是0；第二个视频媒体流使用端口51372，载荷类型是99。 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 // 指明了类型99使用的编码格式是h263-1998，编码时钟频率是90kHz a=rtpmap:99 h263-1998/90000 //表示 Payload 类型为 111 的数据是 OPUS 编码的音频数据，并且它的采样率是 48000，使用双声道。 /2不传则是单声道 // a=rtpmap:111 opus/48000/2 ``` #### 交换SDP - 双方取交集 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a55bf745c1954ad4a6c4c3ab2fe5a482~tplv-k3u1fbpfcp-watermark.image#?w=743\&h=363\&s=72016\&e=png\&b=fefdfd) #### SDP规范 ##### 标准规范 **标准SDP规范主要包括SDP描述格式和SDP结构** * SDP的格式 * SDP格式由多个`=`的表达式组成的，其中``和``都是一个字符，且`=`两边都不能有空格 ```js v=0 o=- 7017624586836067756 2 IN IP4 127.0.0.1 s=- t=0 0 // ... ``` * SDP由一个会话级描述(session level description)和多个媒体级描述组成(media level description) * 会话级：作用域是整个会话，其位置是从v=行开始到第一个媒体描述为止 * 媒体级：是对单个的媒体流进行描述，其位置是从m=行开始到下一个媒体描述(即下一个m=)为止 ```js v=0 o=- 7017624586836067756 2 IN IP4 127.0.0.1 s=- t=0 0 // ------ 会话级结束 // 下面 m= 开头的两行，是两个媒体流：一个音频，一个视频 m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126 m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 // ------ 媒体级结束 ``` **SDP结构由会话描述和媒体信息描述两部分组成** * SDP结构 * 会话描述 * v=（protocol version，必选）：表示SDP版本号，不包括旧=历史版本号 * o=（owner/creator and session identifier，必选）：会话描述，例如`o=

` * s=（session name，必选）`例：s=`，表示一个会话，在整个SDP中有且仅有一个会话，即只能有一个s= * t=（time the session is active，必选）`例：t= `：描述了会话的开始时间和结束时间。NTP 时间，单位是秒，当均为0时，表示持久会话 * 媒体消息描述 * 媒体类型、媒体格式、传输协议、传输的IP和端口 * m=（media name and transport address，可选）`例：m= ` > SDP是由`一个会话层`和`多个媒体层`组成，而对每个媒体层，webRTC又将其细化为四部分，即`媒体流`、`网络描述`、`安全描述`和`服务质量描述`； > webRTC按功能将SDP分为五部分，即`会话元数据`、`网络描述`、`流描述`、`安全描述`和`服务质量描述`，其中会话元数据其实就是SDP标准规范中的`会话层描述`， ```js //======= 安全描述 ============ // 一方面是进行网络连通性检测时，对用户身份进行认证； // 另一方面是收发数据时，对用户身份的认证，以免受到对方的攻击 a=ice-ufrag:1uEe // 进入连通性检测的用户名 a=ice-pwd:RQe+y7SOLQJET+duNJ+Qbk7z// 密码，这两个是用于连通性检测的凭证 a=fingerprint:sha-256 35:6F:40:3D:F6:9B:BA:5B:F6:2A:7F:65:59:60:6D:6B:F9:C7:AE:46:44:B4 //======== 服务质量描述保证音视频质量========= a=rtcp-mux a=rtcp-rsize a=rtpmap:96 VP8/90000 a=rtcp-fb:96 goog-remb // 使用 google 的带宽评估算法 a=rtcp-fb:96 transport-cc // 启动防拥塞 a=rtcp-fb:96 ccm fir // 解码出错，请求关键帧 a=rtcp-fb:96 nack // 启用丢包重传功能 a=rtcp-fb:96 nack pli // 与 fir 类似 ``` ### 推荐文献 [WebRTC攻略-传输协议](https://juejin.cn/post/6952849597148430344)