- 后台传输。非实时的媒体传输，比如上传下载等。

P2P原理_NAT穿透

NAT（Network Address Translation，网络地址转换），也叫做网络掩蔽或者IP掩蔽。NAT是一种网络地址翻译技术，主要是将内部的私有IP地址（private IP）转换成可以在公网使用的公网IP（public IP）。

网络地址转换，就是替换IP报文头部的地址信息。NAT通常部署在一个组织的网络出口位置，通过将内部网络IP地址替换为出口的IP地址提供公网可达性和上层协议的连接能力。那么，什么是内部网络IP地址？

[RFC1918](https://datatracker.ietf.org/doc/rfc1918/)规定了三个保留地址段落：10.0.0.0-10.255.255.255；172.16.0.0-172.31.255.255；192.168.0.0-192.168.255.255。这三个范围分别处于A,B,C类的地址段，不向特定的用户分配，被IANA作为私有地址保留。这些地址可以在任何组织或企业内部使用，和其他Internet地址的区别就是，仅能在内部使用，不能作为全球路由地址。这就是说，出了组织的管理范围这些地址就不再有意义，无论是作为源地址，还是目的地址。对于一个封闭的组织，如果其网络不连接到Internet，就可以使用这些地址而不用向IANA提出申请，而在内部的路由管理和报文传递方式与其他网络没有差异。

对于有Internet访问需求而内部又使用私有地址的网络，就要在组织的出口位置部署NAT网关，在报文离开私网进入Internet时，将源IP替换为公网地址，通常是出口设备的接口地址。一个对外的访问请求在到达目标以后，表现为由本组织出口设备发起，因此被请求的服务端可将响应由Internet发回出口网关。出口网关再将目的地址替换为私网的源主机地址，发回内部。这样一次由私网主机向公网服务端的请求和响应就在通信两端均无感知的情况下完成了。依据这种模型，数量庞大的内网主机就不再需要公有IP地址了。

那么，NAT与此同时也带来一些弊端：首先是，NAT设备会对数据包进行编辑修改，这样就降低了发送数据的效率；此外，各种协议的应用各有不同，有的协议是无法通过NAT的（不能通过NAT的协议还是蛮多的），这就需要通过穿透技术来解决。我们后面会重点讨论穿透技术。

**虽然实际过程远比这个复杂，但上面的描述概括了NAT处理报文的几个关键特点：**

- 1）网络被分为私网和公网两个部分，NAT网关设置在私网到公网的路由出口位置，双向流量必须都要经过NAT网关；

- 2）网络访问只能先由私网侧发起，公网无法主动访问私网主机；

- 3）NAT网关在两个访问方向上完成两次地址的转换或翻译，出方向做源信息替换，入方向做目的信息替换；

- 4）NAT网关的存在对通信双方是保持透明的；

- 5）NAT网关为了实现双向翻译的功能，需要维护一张关联表，把会话的信息保存下来。

简单的背景了解过后，下面介绍下NAT实现的主要方式，以及NAT都有哪些类型。

- 静态NAT: 就是静态地址转换。是指一个公网IP对应一个私有IP，是一对一的转换，同时注意，这里只进行了IP转换，而没有进行端口的转换。

- NAPT： 端口多路复用技术。与静态NAT的差别是，NAPT不但要转换IP地址，还要进行传输层的端口转换。具体的表现形式就是，对外只有一个公网IP，通过端口来区别不同私有IP主机的数据。

- 邮箱 ：charon.chui@gmail.com

- Good Luck!

**编码器将多张图像进行编码后生产成一段一段的 GOP ( Group of Pictures ) ， 解码器在播放时则是读取一段一段的 GOP 进行解码后读取画面再渲染显示。**GOP ( Group of Pictures) 是一组连续的画面，由一张 I 帧和数张 B / P 帧组成，是视频图像编码器和解码器存取的基本单位，它的排列顺序将会一直重复到影像结束。I 帧是内部编码帧（也称为关键帧），P帧是前向预测帧（前向参考帧），B 帧是双向内插帧（双向参考帧）。简单地讲，I 帧是一个完整的画面，而 P 帧和 B 帧记录的是相对于 I 帧的变化。如果没有 I 帧，P 帧和 B 帧就无法解码。

在H.264压缩标准中I帧、P帧、B帧用于表示传输的视频画面。

我们在做直播的时候，想要能达到秒开的效果，因为I帧是能不依赖其他帧独立完成解码的，这就意味着当播放器接收到I帧就能立马渲染出来，而接收到P、B帧则需要等待依赖的帧而不能立马完成解码和渲染，这个期间就会黑屏，所以可以在服务端通过缓存GOP，保证播放端在接入直播时能先获取到I帧马上渲染出画面，从而提高起播速度。在直播服务器中，支持设置一个cache，用于存放GOP，直播服务器缓存了当前的GOP序列，当播放端请求数据的时候，CDN会从I帧返回给客户端，从而保证客户端可以快速进行播放。当然由于缓存的是之前的视频信息，当音频数据到达播放端后，为了音视频同步播放器会进行视频的快进处理。

编码器将多张图像进行编码后生产成一段一段的 GOP ，解码器在播放时则是读取一段一段的GOP进行解码后读取画面再渲染显示。

- IDR（Instantaneous Decoding Refresh）--即时解码刷新。

I帧:帧内编码帧是一种自带全部信息的独立帧，无需参考其它图像便可独立进行解码，视频序列中的第一个帧始终都是I帧。

I和IDR帧都是使用帧内预测的。它们都是同一个东西而已,在编码和解码中为了方便，要首个I帧和其他I帧区别开，所以才把第一个首个I帧叫IDR，这样就方便控制编码和解码流程。 IDR帧的作用是立刻刷新,使错误不致传播,从IDR帧开始,重新算一个新的序列开始编码。而I帧不具有随机访问的能力，这个功能是由IDR承担。 IDR会导致DPB（DecodedPictureBuffer 参考帧列表——这是关键所在）清空，而I不会。IDR图像一定是I图像，但I图像不一定是IDR图像。一个序列中可以有很多的I图像，I图像之后的图像可以引用I图像之间的图像做运动参考。一个序列中可以有很多的I图像，I图像之后的图象可以引用I图像之间的图像做运动参考。

对于IDR帧来说，在IDR帧之后的所有帧都不能引用任何IDR帧之前的帧的内容，与此相反，对于普通的I-帧来说，位于其之后的B-和P-帧可以引用位于普通I-帧之前的I-帧。从随机存取的视频流中，播放器永远可以从一个IDR帧播放，因为在它之后没有任何帧引用之前的帧。但是，不能在一个没有IDR帧的视频中从任意点开始播放，因为后面的帧总是会引用前面的帧 。

收到 IDR 帧时，解码器另外需要做的工作就是：把所有的 PPS 和 SPS 参数进行更新。

对IDR帧的处理(与I帧的处理相同)：(1) 进行帧内预测，决定所采用的帧内预测模式。(2) 像素值减去预测值，得到残差。(3) 对残差进行变换和量化。(4) 变长编码和算术编码。(5) 重构图像并滤波，得到的图像作为其它帧的参考帧。

多参考帧情况下， 举个例子 ：有如下帧序列： IPPPP I P PPP ……。按照 3 个参考帧编码。

因为“按照 3 个参考帧编码”，所以参考帧队列长度为 3 。

遇到第二个 I 时，并不清空参考帧队列，把这个 I 帧加入参考帧队列（当然 I 编码时不用参考帧。）。再检测到其后面的 P 帧时，用到之前的 PPI 三帧做参考了。

【为什么会有PTS和DTS的概念】

通过上面的描述可以看出：P帧需要参考前面的I帧或P帧才可以生成一张完整的图片，而B帧则需要参考前面I帧或P帧及其后面的一个P帧才可以生成一张完整的图片。这样就带来了一个问题：在视频流中，先到来的 B 帧无法立即解码，需要等待它依赖的后面的 I、P 帧先解码完成，这样一来播放时间与解码时间不一致了，顺序打乱了，那这些帧该如何播放呢？这时就引入了另外两个概念：DTS 和 PTS。

【PTS和DTS】

先来了解一下PTS和DTS的基本概念：

DTS（Decoding Time Stamp）：即**解码时间戳**，这个时间戳的意义在于告诉播放器该在什么时候解码这一帧的数据。

PTS（Presentation Time Stamp）：即**显示时间戳**，这个时间戳用来告诉播放器该在什么时候显示这一帧的数据。

虽然 DTS、PTS 是用于指导播放端的行为，但它们是在编码的时候由编码器生成的。

在视频采集的时候是录制一帧就编码一帧发送一帧的，在编码的时候会生成 PTS，这里需要特别注意的是 frame（帧）的编码方式，在通常的场景中，编解码器编码一个 I 帧，然后向后跳过几个帧，用编码 I 帧作为基准帧对一个未来 P 帧进行编码，然后跳回到 I 帧之后的下一个帧。编码的 I 帧和 P 帧之间的帧被编码为 B 帧。之后，编码器会再次跳过几个帧，使用第一个 P 帧作为基准帧编码另外一个 P 帧，然后再次跳回，用 B 帧填充显示序列中的空隙。这个过程不断继续，每 12 到 15 个 P 帧和 B 帧内插入一个新的 I 帧。P 帧由前一个 I 帧或 P 帧图像来预测，而 B 帧由前后的两个 P 帧或一个 I 帧和一个 P 帧来预测，因而编解码和帧的显示顺序有所不同

预加载能减少首次缓冲时间，但是预加载不能和当前播放的视频抢下载带宽，需要达到一个合适的阈值再开始下载。

HTTP

HTTP 视频协议是在互联网普及之后在互联网上看视频的需求下形成的。最初的 HTTP 视频协议，没有任何特别之处，就是通用的 HTTP 文件渐进式下载，但是在这种情况下，视频无法快进或者跳转到文件尚未被下载到的部分，这就对 HTTP 协议提出了范围请求（Range Request）的要求，目前几乎所有 HTTP 服务器都支持范围请求。所谓范围请求指的是请求文件的部分数据，这可以在 HTTP 请求头中通过 Range 字段设置偏移量来实现。

这种方式应用于视频点播还可以，用于直播的话实时性较差，延迟也很高，于是，苹果公司又在 HTTP 协议的基础上推出了 HTTP Live Streaming（简称 HLS）这个流媒体传输协议。