一聚教程网:一个值得你收藏的教程网站

RTP网络传输视频流理解分析

时间:2015-02-09 00:00:00 编辑:简简单单 来源:转载

为何NAT里面的主机可以访问NAT外的WEB服务器,但不能获取RTSP流媒体服务器码流?

原因:

对于 HTTP 这样的协议,客户端与 WEB 服务器建立 socket 连接, 是由 WEB 服务器绑定一个固定的 TCP 端口,在这个端口监听。 位于 NAT 后面的客户端随机选择一个 TCP 端口 connect(2) WEB SERVER。

而对于 RTSP 流媒体服务器,采用 RTP 封装多媒体荷载的话,一般的实现是位于客户端这边的播放器看 UDP 5000 这个端口(也可定义为其他端口, 不过主流的播放器大多是这个端口)是否占用, 未占用则绑定这个端口;如果 UDP 5000 这个端口已经被占用了,则向上检查 UDP 5002(习惯上RTP使用偶数号端口,紧挨着的奇数号端口给RTCP使用)等,直到找到一个未使用的端口。然后请求流媒体码流前通过 RTSP 数据包交互告诉服务器播放器这边接收 RTP 数据包的端口, 流媒体服务器随机选择一个端口发送 RTP 包,并把即将启动的会话信息通过 SDP 格式以 RTSP 封装通知播放器。因此,对于 RTP 通信来说, 真正的服务端是在播放器这边,被动地接收 RTSP 服务器那边发送过来的 RTP 码流。

一般类型的 NAT 允许一个数据包通过的条件是:

    如果这个数据包是从 NAT 里面的设备向外网发送的, 允许通过。NAT 设备会查看这个数据包的源ip地址与端口及目的地址与端口信息,如果没有建立过映射关系就新建一个NAT映射关系: 把源ip与端口映射为NAT地址与一个新分配的端口,根据NAT设备类型的不同,映射关系不同:
        完全锥型、地址受限锥型和端口受限锥型是根据(源IP:源端口)建立一个(NAT地址:端口)的映射,
        对称型NAT把(源IP:源端口,目的IP:目的端口)映射为(NAT IP:NAT 端口)。

    如果这个数据包是从 NAT 外面发送给里面的,看这个数据包的信息能否在NAT映射表里找到对应的映射,找不到则禁止通过;若找的到,不同类型的 NAT 有不同的处理:
        完全锥型: 允许通过。
        地址受限锥型: 如果这个映射对应的NAT内部主机之前发送过数据包给这个外网主机,则允许通过,否则不允许。
        端口受限锥型: 如果这个映射对应的NAT内部主机之前发送过数据包给这个外网主机的端口,则允许通过,否则不允许。
        对称型: 因为映射就包含了源IP、源端口、目的IP、目的端口的所有信息,找到这个映射说明之前NAT里面对应的主机发过包给对应的外网主机,所以允许通过。

因此,位于 NAT 里面的主机可以这样正常的访问外网的 HTTP WEB服务器:发起HTTP请求时, NAT 会为这个会话建立一个映射关系,这样 WEB 服务器回应的包正好匹配这个映射,于是可以被客户端浏览器接收。

但是NAT里面的主机要请求流媒体就不行了:对于 RTSP 来说, 和 HTTP 一样可以正常通信, 关键是对于 RTP 包, 服务端是在 NAT 里面的播放器的,即使 RTSP 知道NAT里面播放器主机的地址以及NAT地址, RTP 包到达 NAT 时,属于上述的2的情况,由于之前没有建立映射关系,这个包将被 NAT 丢弃。

有的流媒体服务器会使用 HTTP 来封装流媒体,可以获取较好的穿透性, 不过需要实现自己的播放器才能解码了。
RTP 丢包的一个原因

用 UDP 封装的 RTP 传输视频码流, 播放出现花屏、马赛克的一个可能原因是丢包严重。UDP 在局域网 丢包不太可能是物理传输中的干扰(一般表现为 UDP 校验出错,可用 netstat -su 查看). 这里说说一个较常见的原因以及表现方式, 从Linux内核的角度来看, 就是 socket 缓存区满, 在播放器读取缓存区之前, 又一个视频码流数据过来, 那么, 这个udp数据包将丢失。

为什么会造成这个socket内核缓存区满呢? 有可能是下面的原因:

    播放器的平均处理数据速度小于流媒体服务器端发包速度;
    播放器平均处理速度大于对端发包速度, 但是发包速度抖动大, 而且内核socket读缓存区设置过小。

文章评论

热门栏目