背景介绍
有一个远程监控的需求，正常情况下采用服务器转发视频流对服务器要求很高，所以p2p看似是一个比较好的方案，但是p2p打洞却不是一件容易的事情，所以打算分析下海康萤石摄像机远程监控的机制，是否采用了p2p的方式。
初步分析结果
少废话，先说结果：对称型nat的p2p打洞是一个比较困难的技术问题，萤石摄像机并没有很好的解决对称型p2p打洞的问题，而是采用服务器转发的方式实现远程监控。
注：由于测试环境比较单一，不能完全确认萤石不能打通对称型nat网络。
萤石摄像机远程监控的处理流程
萤石摄像机在跨公网的远程在线预览时，首先为了保证用户体验，预览起初会采用服务器对视频流进行转发，保证用户尽快的看到视频监控画面。
同时会尝试进行p2p打洞，采用端口累加的算法尝试打洞，非常遗憾的是在进行了10次左右的测试中，p2p打洞一直没能成功，在尝试p2p打洞几分钟后，确认一直打不通后，则放弃p2p方式，后续一直采用服务器转发的模式。
测试环境：
- ipc设备架设在A处，通过中国移动网络接入公网，接入的公网ip为：223.95.81.70。
- 客户端架设在B处，通过中国电信网络接入公网。
- 经检测以上两种宽带接入，都是对称型nat网络。
测试过程：
- 通过客户端进行视频远程预览，同时进行抓包。
测试结果分析
Frame 2261: 284 bytes on wire (2272 bits), 284 bytes captured (2272 bits) on interface 0
Ethernet II, Src: IntelCor_83:03:74 (24:77:03:83:03:74), Dst: TendaTec_5a:b1:a0 (c8:3a:35:5a:b1:a0)
Internet Protocol Version 4, Src: 192.168.0.119, Dst: 223.95.81.70
User Datagram Protocol, Src Port: 10103 (10103), Dst Port: 10009 (10009)
Data (242 bytes)Frame 3018: 284 bytes on wire (2272 bits), 284 bytes captured (2272 bits) on interface 0
Ethernet II, Src: IntelCor_83:03:74 (24:77:03:83:03:74), Dst: TendaTec_5a:b1:a0 (c8:3a:35:5a:b1:a0)
Internet Protocol Version 4, Src: 192.168.0.119, Dst: 223.95.81.70
User Datagram Protocol, Src Port: 10105 (10105), Dst Port: 10010 (10010)
Data (242 bytes)Frame 4770: 284 bytes on wire (2272 bits), 284 bytes captured (2272 bits) on interface 0
Ethernet II, Src: IntelCor_83:03:74 (24:77:03:83:03:74), Dst: TendaTec_5a:b1:a0 (c8:3a:35:5a:b1:a0)
Internet Protocol Version 4, Src: 192.168.0.119, Dst: 223.95.81.70
User Datagram Protocol, Src Port: 10107 (10107), Dst Port: 10011 (10011)
Data (242 bytes)从抓到的数据包可以看到客户端会向223.95.81.70地址（ipc设备所在网络的公网ip）发送长度为284字节的udp打洞包，并调整源端口和目的端口进行端口预测。
打洞持续一段时间后，没有打通，则放弃p2p，后续一直采用服务转发的方式进行远程预览。
萤石视频流的转发应该是通过私有协议，而p2p标准定义了turn协议实现音视频数据的转发，不知道为什么对于这种常见的音视频传输，在监控领域并没有一个标准的协议出现。
疑惑
对称型nat的打洞是十分困难的，虽然有不少预测算法声称可以将打洞成功率提高到90%，不过从萤石相机的表现看效果不是很好，但是不知道迅雷，bt，电驴这类软件是如何实现p2p分享下载的，感觉这方面的水还是很深的。
另外优酷之前推出的可以赚钱的路由宝，貌似原理就是将个人的路由器做成能够分享的小型服务器，这样可以利用个人宽带的资源，节省自身的带宽。不过路由宝要能够用来分享，也是需要进行些设置，通过搜索感觉也是为了穿透nat的限制。
