视频流网络透传分析

最近在翻看以前写的文档，把这篇word文档复制下来，保留一下。

 

序号	版本	作者	描述
1	V0.1	YJ.Yan	初始版本
2	V0.2	YJ.Yan	添加方案细节描述以及可参考方案

 

1.      基本概念

a)       NAT

网络地址转换(NAT,Network AddressTranslation)属接入广域网(WAN)技术，是一种将私有（保留）地址转化为合法IP地址的转换技术，它被广泛应用于各种类型Internet接入方式和各种类型的网络中。原因很简单，NAT不仅完美地解决了IP地址不足的问题，而且还能够有效地避免来自网络外部的攻击，隐藏并保护网络内部的计算机。

家庭用路由器就是采用这种技术。NAT还分4种类型：

（1）       Full Cone

这种NAT内部的机器A连接过外网机器C后，NAT会打开一个端口.然后外网的任何发到这个打开的端口的UDP数据报都可以到达A。不管是不是C发过来的。如图所示：

（2）       Address Restricted Cone

这种NAT内部的机器A连接过外网的机器C后，NAT打开一个端口。然后C可以用任何端口和A通信。其他的外网机器不行。如图：

（3）       Port Restricted Cone

这种NAT内部的机器A连接过外网的机器C后，NAT打开一个端口。然后C可以用原来的端口和A通信，其他的外网机器不行。如图：

（4）       Symmetric（对称形）

对于这种NAT。连接不同的外部Server，NAT打开的端口会变化。也就是内部机器A连接外网机器B时，NAT会打开一个端口，连接外网机器C时又会打开另外一个端口。

b)       打洞（穿越）

如上面NAT类型的描述，因为只有A主动连接了C，C才可以透过NAT发送数据到A。如果两个处在NAT环境中的主机要相互连接并传输数据（透传）的时候，就需要一个中间人的角色：Server。所以打洞的过程如图所示：

       主要流程是这样的：

（1）如果A想与B通信；

（2）A首先连接C，C得到A的外网NAT A的地址和端口；

（3）B也要连接C，C得到B的外网NAT B的地址和端口；

（4）A告诉C说我要和B通讯；

（5）C通过NAT B发信息给B，告诉B A的外网NAT A的地址和端口；

（6）B向NAT A发数据包（肯定会被NAT A丢弃，因为NAT A上并没有 A->NAT B 的合法session），但是NAT B上就建立了有B->NAT A的合法session了；

（7）B发数据包给C，让 C 通知 A，我已经把洞打好了；

（8）A接受到通知后向 B 的外网发NB数据包，这样就不会被丢弃掉了。因为对于NAT B来说，它看到的是A的外网NAT A的地址，而通过第6步，B已经让NAT A成为NAT B的合法通信对象了。所以当NAT A发数据包给NAT B时，NAT B就会接收并转发给B；

c)       STUN

STUN的全称是Simple Traversal of UDP Through NAT，即UDP对NAT的简单穿越方式。应用程序（即STUN CLIENT）向NAT外的STUN SERVER通过UDP发送请求STUN 消息询问自身的转换后地址，STUN SERVER收到请求消息，产生响应消息，响应消息中携带请求消息的源端口，即STUN CLIENT在NAT上对应的外部端口。然后响应消息通过NAT发送给STUN CLIENT，STUN CLIENT通过响应消息体中的内容得知其在NAT上对应的外部地址，并且将其填入以后呼叫协议的UDP负载中，告知对端，同时还可以在终端注册时直接注册这个转换后的公有IP地址，这样就解决了穿越NAT的通信建立问题以及作为被叫时的问题。本端的接收地址和端口号为NAT外的地址和端口号。由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项，故媒体流可顺利穿越NAT。

PS:从RFC5389开始，STUN不再是RFC3489那样作为一个NAT穿越的完全解决方案了。

STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC3489), which presented STUN as a complete solution.

d)       TURN

TURN方式解决NAT问题的思路与STUN相似，也是私网中的客户端通过某种机制预先得公网上的服务地址，不同的地方在于：STUN方式得到的地址为出口NAT上外部地址，TURN方式得到地址为TURN Server上的公网地址，然后在报文净载中所要求的地址信息就直接填写该公网地址。

TURN的全称为Traversal Using Relay NAT，即通过Relay方式穿越NAT。TURN解决了STUN应用无法穿透对称NAT（Symmetric　NAT）的问题，但是所有报文都必须经过TURN Server转发，所以又增大了包的延迟和丢包的可能性。

2.      天猫魔盒家庭监控APK分析

a)       抓包分析

天猫魔盒的IP为：

抓包过程为：启动家庭监控——>关闭家庭监控

此时手机端和天猫魔盒不属于同一个网段。

网络包的靠前部分为：

除去TCP的握手过程，可以清晰的看到STUN协议的包，经过查询42.156.208.7是阿里巴巴的服务器IP，所以可以断定该服务器是STUN服务器。

再仔细观察这个包，其中的NONCE字段，表明了他们采用了RFC5389的STUN协议，而CHANNEL-NUMBER则进一步表明了他们使用的是TURN协议来进行网络透传的。

              接下去让我们再继续看传输视频流的包：

所有的ChannelData包都是以0x2080开头的，通过和手机端的抓包（这里不再贴图）对比，发现0x2080就是他们视频流的网络封包。所以，这里可以断定他们是使用TURN协议来进行网络透传的。

虽然有经过服务器中转，但是视频的实时性还是不错的，实际测试中，延时大概在1S左右。

 

我们再来看一看手机端和天猫魔盒属于同一网段时候，手机端的抓包：

魔盒的IP是131，手机的是134，如上可以看出，当两者处于同一网段的时候，他们不再通过TURN中转，而是直接以UDP点对点的方式进行视频流传输，视频流网络包也是以0x2080开头，从而验证了上面所说的0x2080包头属于视频流的猜想。

 

综上所述：对于天猫魔盒和阿里TV助手配合实现的家庭监控方案，我们得到了如下分析：

（1）NAT穿透方面，采用的是STUN+TURN的方式，对于视频流采用服务器中转。

（2）内网直接采用UDP方式进行视频流传输。

b)       APK反编译分析

使用apktool对阿里TV助手（Remote.apk）进行反编译之后，有如下文件：

      

在AndroidManifest.xml中，关于家庭监控有如下内容：

       其中safehome与家庭监控模块的有关，所以我们先开始查看与safehome相关的smali目录“smali\com\yunos\safehome”（smali是apktool反编译出来的伪代码）：

       在monitor/ VideoMonitorActivity.smali的伪代码中，有如下片段：

       其中可以发现，视频方面是采用mmpc/avengine/video/目录中的方法。

       接下去让我们看看mmpc中的内容：

       从这个目录中，我们不难看出，avengine与视频相关，netengine与网络相关。现在分别贴出avengine和netengine的目录结构：

                 

目录结构已经验证了我们的猜想。在VideoEngine.smali以及P2PConnector.smali中，我们都看到这么一句伪代码：

       在mmp/util/LoadLibraryUtil的LoadMmpc()函数中，我们又可以看到如下伪代码：

所以，我们可以推断，libmmpc.so是这些模块的关键库，接下去，我们就将libs/libmmpc.so通过nm命令将其中的函数打印出来。

其中我们可以看到很多关于RTP/RTCP、VideoEngine、P2PTransport等等与网络传输以及视频编解码相关的函数名。

综上所述，我们可以推出天猫手机端APK的几个技术点：

（1）采用RTP传输视频流

（2）采用so库进行视频编解码和NAT穿透

（3）对STUN/TURN协议的实现是自己组包的

3.      初定方案

（1）实时视频流采集

方案一：在Camera中对setPreviewCallback实现onPreviewFrame接口，实时截取每一帧视频流数据。

    通过试验，传输一帧数据比较大，对网络质量要求高。

方案二：使用MediaRecorder，在SetoutputFile函数中绑定LocalSocket实现

    使用LocalSocket可以获取硬件编码后的视频流，但是不是实时视频流，需要在视频流中添加SPS和PPS重新编码并通过RTP打包发送出去。

方案三：流媒体服务器方式，利用ffmpeg或GetStreamer等获取Camera视频

（2）压缩编码

方案一：不编码，直接通过Socket传输原始YUV420SP视频帧

方案二：JPEG编码，将原始YUV420SP视频帧压缩转换为JPEG格式，JPEG传输

方案三：H.264/AVC.将原始YUV420SP视频帧压缩成H.264再传输

方案四：MPEG4.将原始YUV420SP视频帧压缩成MPEG4再传输

（3）数据传输

方案一：Socket传输

方案二：HTTP传输

方案三：RTP/RTSP传输

方案四：流媒体服务器方式，如live555等

    Live555可以将已有的视频文件编码成可播放的RTP视频流，但是对于实时视频流的编码是否支持还未知。

（4）NAT穿透

方案一：使用STUN+TURN方式进行NAT穿透（可以使用restund开源方案搭建STUN/TURN服务器）

（5）解码与播放

方案一：使用VLC/JAVACV等第三方库解码后使用SurfaceView进行播放。

方案二：直接使用MediaPlayer（需要底层芯片支持解码）

4.      可参考开源方案以及第三方库

（1）DroidIPCam（采用了libjingle库）

    http://code.google.com/p/ipcamera-for-android/

（2）spydroid-ipcamera

    http://code.google.com/p/spydroid-ipcamera/

（3）libjingle

https://code.google.com/p/webrtc/source/browse/#svn%2Ftrunk%2Ftalk