功能強大的ICE（區塊鏈從p2p開始 ）區塊鏈
ICE的全稱為InteractiveConnec-tivityEstablishment,即交互式連接建立.初學者可能會將其與網絡編程的ICE弄混,其實那是不一樣的東西,在網絡編程中。
ICE的全稱為Interactive Connec-tivi ty Establishment,即交互式連接建立.初學者可能會將其與網絡編程的ICE 弄混,其實那是不一樣的東西,在網絡編程中,如C 的ICE庫,都是指Inter-nate Communications Engine, 是一種用于分布式程序設計的網絡通信中間件.我們這里說的只是交互式連接建立.
01
ICE簡介
ICE是一個用于在offer/answ-er模式下的NAT傳輸協議,主要用于UDP下多媒體會話的建立,其使用了STUN協議以及TURN 協議,同時也能被其他實現了offer/answer模型的的其他程序所使用,比如SIP(Se-ssi on Initiation Protocol).
使用offer/answer模型(RFC3264)的協議通常很難在NAT之間穿透,因為其目的一般是建立多媒體數據流,而且在報文中還 攜帶了數據的源IP和端口信息,這在通過NAT時是有問題的.RFC3264還嘗試在客戶端之間建立直接的通路,因此中間就缺少 了應用層的封裝.這樣設計是為了減少媒體數據延遲,減少丟包率以及減少程序部署的負擔.然而這一切都很難通過NAT而完成. 有很多解決方案可以使得這些協議運行于NAT環境之中,包括應用層網關(ALGs),Cla ssic STUN以及Realm Specific IP SDP 協同工作等方法.不幸的是,這些技術都是在某些網絡拓撲下工作很好,而在另一些環境下表現又很差,因此我們需要一個單一的, 可自由定制的解決方案,以便能在所有環境中都能較好工作.
02
ICE工作流程
一個典型的ICE工作環境如下,有兩個端點L和R,都運行在各自的NAT之后(他們自己也許并不知道),NAT的類型和性質也是未知的. L和R通過交換SDP信息在彼此之間建立多媒體會話,通常交換通過一個SIP服務器完成:
ICE的基本思路是,每個終端都有一系列傳輸地址(包括傳輸協議,IP地址和端口)的候選,可以用來和其他端點進行通信. 其中可能包括：
直接和網絡接口聯系的傳輸地址(host address)
經過NAT轉換的傳輸地址,即反射地址(server reflective address)
TURN服務器分配的中繼地址(relay address)
雖然潛在要求任意一個L的候選地址都能用來和R的候選地址進行通信.但是實際中發現有許多組合是無法工作的.舉例來說, 如果L和R都在NAT之后而且不處于同一內網,他們的直接地址就無法進行通信.ICE的目的就是為了發現哪一對候選地址的 組合可以工作,并且通過系統的方法對所有組合進行測試(用一種精心挑選的順序).
為了執行ICE,客戶端必須要識別出其所有的地址候選,ICE中定義了三種候選類型,有些是從物理地址或者邏輯網絡接口繼承 而來,其他則是從STUN或者TURN服務器發現的.很自然,一個可用的地址為和本地網絡接口直接聯系的地址,通常是內網地址, 稱為HOST CANDIDATE,如果客戶端有多個網絡接口,比如既連接了WiFi又插著網線,那么就可能有多個內網地址候選.
其次,客戶端通過STUN或者TURN來獲得更多的候選傳輸地址,即SERV-ER REFLEXIVE CANDIDATES和R-ELAYED CANDIDATES, 如果TURN服務器是標準化的,那么兩種地址都可以通過TURN服務器獲得.當L獲得所有的自己的候選地址之后,會將其 按優先級排序,然后通過signaling通道發送到R.候選地址被存儲在SDP offer報文的屬性部分.當R接收到offer之后, 就會進行同樣的獲選地址收集過程,并返回給L.
這一步驟之后,兩個對等端都擁有了若干自己和對方的候選地址,并將其配對,組成CANDIDATE PAIRS.為了查看哪對組合 可以工作,每個終端都進行一系列的檢查.每個檢查都是一次STUN request/response傳輸,將request從候選地址對的本地 地址發送到遠端地址. 連接性檢查的基本原則很簡單:
以一定的優先級將候選地址對進行排序.
以該優先級順序發送checks請求
從其他終端接收到checks的確認信息
兩端連接性測試,結果是一個4次握手過程:
值的一提的是,STUN request的發送和接收地址都是接下來進多媒體傳輸(如RTP和RTCP)的地址和端口,所以, 客戶端實際上是將STUN協議與RTP/RTCP協議在數據包中進行復用(而不是在端口上復用).
由于STUN Binding request用來進行連接性測試,因此STUN Binding respons e中會包含終端的實際地址, 如果這個地址和之前學習的所有地址都不匹配,發送方就會生成一個新的candidate,稱為PEER RE FLEXIVE CANDIDATE, 和其他candida te一樣,也要通過ICE的檢查測試.
03
連接性檢查
所有的ICE實現都要求與STUN(R-FC5 389)兼容,并且廢棄Classic STU-N(RFC3 489).ICE的完整實現既生成checks(作為STUN client), 也接收checks(作為STUN server),而lite實現則只負責接收checks.這里只介紹完整實現情況下的檢查過程.
1. 為中繼候選地址生成許可(Permissions).
2. 從本地候選往遠端候選發送Binding Request.
在Binding請求中通常需要包含一些特殊的屬性,以在ICE進行連接性檢查的時候提供必要信息：
PRIORITY 和 USE-CANDIDATE
終端必須在其request中包含PRIORITY屬性,指明其優先級,優先級由公式計算而得. 如果有需要也可以給出特別指定的候選(即USE-CANDIDATE屬性).
ICE-CONTROLLED和ICE-CONTROLLING
在每次會話中,每個終端都有一個身份,有兩種身份,即受控方(con-trolled role)和主控方(control-ling role). 主控方負責選擇最終用來通訊的候選地址對,受控方被告知哪個候選地址對用來進行哪次媒體流傳輸, 并且不生成更新過的offer來提示此次告知.發起ICE處理進程(即生成offer)的一方必須是主控方,而另一方則是受控方. 如果終端是受控方,那么在request中就必須加上ICE-CONTROLL-ED屬性,同樣,如果終端是主控方,就需要ICE-CONTROLLING屬性.
生成Credential
作為連接性檢查的Binding Request必須使用STUN的短期身份驗證.驗證的用戶名被格式化為一系列username段 的聯結,包含了發送請求的所有對等端的用戶名,以冒號隔開;密碼就是對等端的密碼.
3. 處理Response.
當收到Binding Response時,終端會將其與Binding Request相聯系,通常通過事務ID.隨后將會將此事務ID與 候選地址對進行綁定。
失敗響應
如果STUN傳輸返回487(Role Conflict)錯誤響應,終端首先會檢查其是否包含了ICE-CONTROLLED或ICE-CONTROLLING 屬性.如果有ICE-CONTROLLED,終端必須切換為controlling role;如果請求包含ICE-CONTROLLING屬性, 則必須切換為controlled role.切換好之后,終端必須使產生487錯誤的候選地址對進入檢查隊列中, 并將此地址對的狀態設置為Waiting.
成功響應,一次連接檢查在滿足下列所有情況時候就被認為成功:
STUN傳輸產生一個Success Response
response的源IP和端口等于Binding Request的目的IP和端口
response的目的IP和端口等于Binding Request的源IP和端口
終端收到成功響應之后,先檢查其map ped address是否與本地記錄的地址對有匹配,如果沒有則生成一個新的候選地址. 即對等端的反射地址.如果有匹配,則終端會構造一個可用候選地址對(valid pair).通常很可能地址對不存在于任何 檢查列表中,檢索檢查列表中沒有被服務器反射的本地地址,這些地址把它們的本地候選轉換成服務器反射地址的基地址, 并把冗余的地址去除掉.
本文中具體工作過程和詳細的屬性描述都未包含,如果需要根據協議來實現具體的應用程序,還需要對RFC的文檔進行仔細閱讀
1.TMT觀察網遵循行業規范，任何轉載的稿件都會明確標注作者和來源；
2.TMT觀察網的原創文章，請轉載時務必注明文章作者和"來源：TMT觀察網"，不尊重原創的行為TMT觀察網或將追究責任；
3.作者投稿可能會經TMT觀察網編輯修改或補充。
