背景介紹

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