爲什麼WebRTC需要ICE協議來運行？

Question

就我所知，ICE協議用於發現從最終用戶設備到「外部」的節點/設備。

我不明白爲什麼需要它。包路由不是路由器和交換機等網絡設備的責任嗎？他們應該找到從網關到最終用戶設備的最短路徑（實際上，路由器會記住他們以前發現的那些路由）。

此外，NAT協議用於將「內部IP」轉換爲「外部IP」，反之亦然。

因此，
爲什麼其他用戶需要熟悉我的內部網絡設置？

Answer 1

防火牆。他們通常配置爲將來自萬維網的未經請求的流量反彈給您。他們只會批准你啓動與服務器的聯繫，只有這樣服務器才能被允許回傳流量給你，這就是它。除非你的朋友都擁有靜態IP地址（很少有人可以證明這一點），這是一個惡意的對等通信環境。

ICE試圖通過枚舉可能到達另一端的地址和端口並嘗試連接到這些地址，通過在兩端啓動出站請求或者如果其他所有請求都失敗，返回到通信通過TURN服務器，如果指定。

有關更多問題，請參閱此WebRTCHacks article。

爲什麼其他用戶需要熟悉我的內部網絡設置？

因爲其他用戶有時在您的內部網絡上。例如局域網遊戲。

Answer 2

NAT是一種混合物，在IPv6變得無處不在的時候試圖保留IPv4地址，並打破IP承諾的端到端連接。正因爲如此，有些東西通過NAT無法正常工作。有各種各樣的工具來解決NAT混亂，ICE是其中的一部分。這在RFC 5245, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols說明：

1. 簡介

RFC 3264 [RFC3264]定義會話描述 協議的兩相交換（SDP）用於建立 的目的消息[RFC4566]多媒體會議。該提議/回答機制由協議 使用，諸如會話發起協議（SIP）[RFC3261]。

使用offer/answer的協議很難通過Network Address Translators（NAT）進行操作。因爲它們的目的是建立媒體數據包流，所以它們傾向於攜帶其消息中的媒體源和接收器的IP地址和端口 ，這通過NAT [RFC3235]已知爲 問題。該協議還試圖在參與者之間直接創建媒體流，以便它們之間不存在應用層中介。這樣做是爲了減少媒體延遲，減少數據包丟失並降低部署應用程序的運營成本 。不過，這很難通過NAT完成。對此的完整處理原因是 超出本規範的範圍。

已經定義了許多解決方案，允許這些協議通過NAT運行到 。這些包括應用層網關（ALG算法）， 所述中間控制協議[RFC3303]，UDP的原始簡單 穿越通過NAT（STUN）[RFC3489]規範，與境界 特定IP [RFC3102] [RFC3103]與會話描述沿（RTCP）[RFC3605]的會話描述 協議（SDP）[RFC4566]屬性。不幸的是，這些技術都具有優點和缺點，使得每個網絡拓撲中的每一個都是最優的，但是在其他網絡中卻是不好的選擇。結果是，管理員和實施者正在對其網絡中將部署其解決方案的網絡的拓撲進行假設。這引入了系統的複雜性和脆性。我們需要的是一個單一的解決方案，其靈活性足以在所有的 情況下運行良好。

該規範定義 （雖然ICE可以擴展以處理其他的傳輸協議，例如 如TCP [ICE-TCP]）通過所建立的互動式連接建立 （ICE）作爲用於NAT穿越用於基於UDP的媒體的技術流報價/回答模式。 ICE是提供/回答模型的 擴展，並且通過在SDP提供和答案中包括 IP地址和端口的多個IP地址和端口， 然後通過對等連接 檢查連通性。包含在SDP中的IP地址和端口以及使用修訂後的STUN規範 [RFC5389]執行連接性檢查，現在將其重命名爲用於NAT的會話遍歷實用程序。 新名稱和新規範反映了其作爲 與其他NAT穿越技術（即ICE）使用的工具的新角色，而不是 獨立NAT穿越解決方案，因爲原始STUN規範 是。 ICE還利用在NAT周圍使用中繼的遍歷（TURN） [RFC5766]，這是對STUN的擴展。因爲ICE交流IP地址和端口的每個媒體流的多個 ，它也允許對多宿主和雙協議棧的主機 地址選擇，並且爲此原因 它不贊成RFC 4091 [RFC4091]和[RFC4092]。