WebRTC 之ICE浅谈
前言
ICE全稱Interactive Connectivity Establishment：交互式連通建立方式。
ICE參照RFC5245建議實現，是一組基于offer/answer模式解決NAT穿越的協議集合。
它綜合利用現有的STUN，TURN等協議，以更有效的方式來建立會話。
客戶端側無需關心所處網絡的位置以及NAT類型，并且能夠動態的發現最優的傳輸路徑。
Classic STUN（RFC3489）的劣勢:
Classic STUN 有著諸多局限性，例如:
STUN（RFC5389）協議
RFC5389是RFC3489的升級版
?
ICE利用STUN（RFC5389） Binding Request和Response，來獲取公網映射地址和進行連通性檢查。同時擴展了STUN的相關屬性:
TURN協議
ICE使用TURN（RFC 5766）協議作為STUN的輔助，在點對點穿越失敗的情況下，借助于TURN服務的轉發功能，來實現互通。端口與STUN保持一致
?
TURN消息都遵循 STUN 的消息格式，除了ChannelData消息。
?
?
TURN的流程:
client 使用allocation transaction創建relay 端口，并在allocation的響應中回復給client。
當allocation創建后需要使用refresh request來保活，默認lifetime為10分鐘。
?
由allocation創建Permission，每個Permission 由 IP 地址 和lifetime組成。
有兩種方法來創建和刷新Permission
?
?
ICE介紹
分為 controlling和controlled。
Offer 一方為controlling角色，answer一方為controlled角色。
?
分為FULL ICE和Lite ICE：
FULL ICE:是雙方都要進行連通性檢查，完成的走一遍流程。
Lite ICE: 在FULL ICE和Lite ICE互通時，只需要FULL ICE一方進行連通性檢查， Lite一方只需回應response消息。這種模式對于部署在公網的設備比較常用。
?
媒體傳輸的候選地址，組成candidate pair做連通性檢查，確定傳輸路徑，有如下屬性：
?
- Type 類型有：
Host/Srvflx/Relay/Prflx
?
- Componet ID
??傳輸媒體的類型,1代表RTP;2代表 RTCP。
??WebRTC采用Rtcp-mux方式，也就是RTP和RTCP在同一通道內傳輸，減少ICE的協商和通道的保活。
?
- Priority
Candidate的優先級。
如果考慮延時，帶寬資源，丟包的因素，Type優先級高低一般建議如下順序：
host > srvflx > prflx > relay
?
- Base
是指candidate 的基礎地址。
Srvflx address 的base 是本地host address。
host address和?relayed address 的base 是自身。
?
?
?? 由本端和遠端candidate組成的pair，有自己的優先級。????????????? ???
pair優先級的計算是取決candidate的priority。
?
priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
G:controlling candidate 優先級
D:controlled candidate 優先級
?
ICE選擇高優先級的candidate pair。
?
由candidate pair生成按優先級排序的鏈表,用于ICE連通性檢查。
?
由連通性檢查成功的candidate pair按優先級排序的鏈表,用于ICE提名和選擇最終路徑。
ICE過程
根據Componet ID:
- 獲取本機host address.
- 從STUN服務器獲取 srvflx address.
- 從TURN服務器獲取 relay address.
- 同時生成foundation。
?
收集地址完成后，需要去掉重復的candidate，如果兩個candidate的地址一樣，并且Base地址也一樣，則刪除它。
?
ICE 使用offer/answer方式，雙方通過SDP協商交換candidate信息.
Candidate信息包括type,foundation,base,component id,transport
SDP a行格式如下:
“a=candidate:1 1 UDP 9654321 212.223.223.223 12345 typ srflx raddr 10.216.33.9 rport 54321”
?
表示 foundation為1，媒體是RTP，采用UDP協議，公網映射地址為212.223.223.223:12345，優先級為9654321，type為srflx，base地址為10.216.33.9:54321
?
在本端收到遠端candidates后，將Component ID和transport protocol相同的candidates組成pair。
修整candidate pair，如果是srvflx地址，則需要用其base地址替換。
對端也是同樣的流程。
?
將candidate pairs按照優先級排序，生成checklist，供連通性檢查使用。
?
Ordinary checks 兩端都按照各自checklist分別進行檢查。
Triggered checks 收到對端的檢查時，也在對應的candidate pair上發起連通性檢查，以提高效率
?
如果checklist里有relay candidate，則必須首先為relay candidate創建permission。
?
ICE 使用STUN binding request/response，包含Fingerprint檢驗校驗機制。
?
??????? ?如果A收到B的response，則代表連通性檢查成功，否則需要進行重傳直到超 時。
??????? 在建立連接時，如果沒有響應，則會以RTO時間進行重傳，每次翻倍，直到最大重傳次數。
?
STUN請求 采用STUN short-term credential方式認證，
STUN USERNAME屬性 ”RemoteUsername：localUsername”
兩端在SDP協商時交換ice-pwd和ice-ufrag，以得對端用戶名和密碼。
?
STUN 檢查請求中需要檢查地址的對稱性，請求的源地址是響應的目的地址，請求的目的地址是響應的源地址，否則都設置狀態為 Failed。
?
?
將連通性檢查成功的candidate pair并按優先級排序加入validlist，這時本地candidate填寫的是公網映射地址，remote candidate填寫的是對端發送的STUN binding request地址。
?
由controlling來提名哪對candidate pair為valid pair
?? ?提名方式又分為普通提名和進取型提名
普通提名方式會做兩次連通性檢查，在第一次做連通性檢查時不會帶上USE-CANDIDATE屬性，而是在生成的validlist里選擇pair再進行一次連通性檢查，這時會帶上USE-CANDIDATE屬性，并且置位nominated flag。
?
進取型方式則是每次發送連通性檢查時都會帶上USE-CANDIDATE屬性，并且置位nominated flag，不會再去做第二次連通性檢查。
?
ICE在提名的valid pair里選擇優先級最高那對作為本次ICE流程傳輸地址。
ICE狀態
ICE保活
?
ICE角色沖突解決
?
結束語
隨著WebRTC的應用越來越普遍，無論是Native端還是Web端，由于廣泛的適應 ??????能力以及對未來網絡的支持，ICE作為一種綜合的解決方案將有著非常廣闊的應用前景。
網易云信翻譯了W3C推薦標準WebRTC 1.0: Real-time CommunicationBetween Browsers，并提供《WebRTC1.0: 瀏覽器間實時通訊》中文版免費下載。
- 對于WebRTC初學者，本文檔可以作為學習教程，幫助你快速對WebRTC有全面且詳細的了解，學習相關API的使用，其附帶的示例代碼也是很好的學習資料；
- 對于WebRTC資深開發者，本文檔可以作為開發中的使用手冊，根據所提供的函數調用鏈或是算法流程進行開發或bug定位；
- 對于高階玩家，也可通過閱讀本文檔對WebRTC工作組反饋改進意見。
?
限時免費下載，WebRTC開發者必備。
總結
以上是生活随笔為你收集整理的WebRTC 之ICE浅谈的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 互联网1分钟 | 0327 华为P30系
- 下一篇： 互联网1分钟 | 0328 阿里巴巴收购