背景介紹
有一個遠程監控的需求，正常情況下采用服務器轉發視頻流對服務器要求很高，所以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的限制。