爲什麼WebRTC需要遠程對等體的本地IP？

Question

當我們向某些STUN服務器發送請求時，當外部服務器看到它時，我們會收到我們的IP：端口對。然後，我們在瀏覽器綁定的本地IP端口對中包含這個「可能連接目標的概率列表」，並通過WebRTC網絡將其發送給遠程客戶端（實際上，我從未完全理解 - 在哪一步或哪一步在那裏用戶ID被解析爲它的IP以及從哪裏知道遠程客戶IP ......）。

但爲什麼我們需要本地IP地址和端口？那麼，對於端口，我的解釋是，一些NAT防火牆可以配置爲將相同的本地端口連接到外部請求（僅重寫IP），然後信息可能很有用，但IP在哪裏需要？

Answer 1

瀏覽器看到的本地IP很可能是一個可行的連接選項。這就是它包含的原因。

評論中提到的鏈接實際上顯示爲連接生成的所有ICE候選項。您的本地IP地址是瀏覽器自己添加的最基本的IP地址。這是您在沒有STUN的情況下運行webRTC時獲得的一個候選人。但是，這個地址很可能是一個真正的IP，或者是本地網絡上私人和可行的。現在，如果它位於NAT後面，瀏覽器無法知道路由器的外部IP - 這是STUN檢測到的連接選項，同時爲連接插入NAT。 （如果這不起作用，也有TURN服務器，這也將顯示爲具有自己的IP的ICE候選人）。

ICE候選人本質上是另一端可能連接到的潛在地址的列表。包含任何可檢測或可能工作的內容，不僅包括STUN響應或本地IP。另一端使用這些來嘗試建立實際的媒體/數據（RTP）連接。

我不確定你的意思是「用戶ID」，但這些ICE候選人必須通過單獨的方法或信令層給予另一個客戶端。這就是實際連接的方式 - 完全如何實現並不是webRTC的一部分，它可以是任何事情。流行的傳輸層是websocket。基本上，這兩個客戶端必須已經以某種形式進行通信，然後才啓動webRTC。