2023年下旬，OpenAI與Livekit的合作[1]在科技圈引起了不小的轟動(dòng)。這兩家公司聯(lián)手，通過(guò)WebRTC技術(shù)和大型語(yǔ)言模型（LLM）的結(jié)合，使AI模型具有了看、聽(tīng)和說(shuō)話的能力[2]。這一舉動(dòng)不僅彰顯了WebRTC在現(xiàn)代通信技術(shù)中的重要地位，也為我們揭示了AI與實(shí)時(shí)通信融合的無(wú)限可能。WebRTC技術(shù)在大流行后再一次進(jìn)入技術(shù)人的視野，恰好在我們今年打造的產(chǎn)品中，WebRTC也是技術(shù)棧的核心。

WebRTC端到端實(shí)時(shí)通信的效果主要取決于兩個(gè)重要因素，一個(gè)通信質(zhì)量，一個(gè)是音視頻編解碼質(zhì)量。對(duì)于入門(mén)類文章來(lái)說(shuō)，改進(jìn)通信質(zhì)量或音視頻編解碼質(zhì)量還為時(shí)尚早，我們亟需了解的是其背后的原理。

在這篇文章以及后續(xù)的幾篇文章中，我們先來(lái)關(guān)注一下“WebRTC網(wǎng)絡(luò)通信”。我們會(huì)先了解一下WebRTC網(wǎng)絡(luò)架構(gòu)，然后對(duì)WebRTC中的難點(diǎn)，諸如NAT打洞、基于信令與ICE的建連等做深入分析。

在這篇文章中，我們先來(lái)學(xué)習(xí)NAT的工作原理，探討不同類型的NAT網(wǎng)絡(luò)行為是如何影響點(diǎn)對(duì)點(diǎn)通信的，為后續(xù)理解WebRTC的NAT打洞(也稱為NAT穿透)和端到端建連做準(zhǔn)備。

1. WebRTC網(wǎng)絡(luò)架構(gòu)

我們知道WebRTC（Web Real-Time Communication）是一種支持網(wǎng)頁(yè)瀏覽器/應(yīng)用進(jìn)行端到端實(shí)時(shí)語(yǔ)音對(duì)話或視頻對(duì)話的技術(shù)，其中支持端到端建立連接和后續(xù)數(shù)據(jù)傳輸?shù)木W(wǎng)絡(luò)架構(gòu)是十分重要的，這也是理解WebRTC技術(shù)棧的一個(gè)重點(diǎn)。下面是WebRTC網(wǎng)絡(luò)架構(gòu)圖的示意圖：

圖片

這個(gè)架構(gòu)包含以下主要組件：

• 瀏覽器/App：這是進(jìn)行WebRTC的端(Peer)，可以是瀏覽器，也可以是App。WebRTC API在瀏覽器中實(shí)現(xiàn)，使得web應(yīng)用能夠直接訪問(wèn)媒體設(shè)備和建立點(diǎn)對(duì)點(diǎn)連接。App也可以利用WebRTC的實(shí)現(xiàn)(比如Pion[4])與對(duì)端進(jìn)行RTC通信。
• 信令服務(wù)器(Signaling Server）：雖然不是WebRTC標(biāo)準(zhǔn)的一部分，但對(duì)于WebRTC建立連接至關(guān)重要，任何non-trivial的基于WebRTC的系統(tǒng)都會(huì)有專屬的信令服務(wù)器，它會(huì)幫助通信雙方交換會(huì)話描述協(xié)議（SDP）信息和ICE候選地址。這個(gè)在使用Go和WebRTC data channel實(shí)現(xiàn)端到端實(shí)時(shí)通信[5]一文中介紹過(guò)，在后續(xù)的文章中還會(huì)有系統(tǒng)說(shuō)明。
• STUN服務(wù)器（Session Traversal Utilities for NAT）：該服務(wù)器可以幫助客戶端發(fā)現(xiàn)自己的公網(wǎng)IP地址和端口，這個(gè)服務(wù)器是NAT打洞時(shí)所必須的。
• TURN服務(wù)器（Traversal Using Relays around NAT）：當(dāng)通過(guò)常規(guī)方式點(diǎn)對(duì)點(diǎn)連接失敗時(shí)(通常是NAT打洞失敗)，可以使用TURN服務(wù)器作為媒體數(shù)據(jù)的中繼服務(wù)器使用。兩端發(fā)送的數(shù)據(jù)都會(huì)要通過(guò)TURN的中繼才能轉(zhuǎn)發(fā)給對(duì)端。
• ICE框架（Interactive Connectivity Establishment）：綜合使用各種NAT打洞技術(shù)來(lái)協(xié)助兩端建立連接，這個(gè)我們會(huì)在后面文章中系統(tǒng)說(shuō)明。

我們看到這個(gè)架構(gòu)略有些復(fù)雜，但該架構(gòu)允許WebRTC應(yīng)用在復(fù)雜的網(wǎng)絡(luò)環(huán)境中建立直接的點(diǎn)對(duì)點(diǎn)連接，即使客戶端位于NAT或防火墻后面。

2. 網(wǎng)絡(luò)世界的真相：我們都在NAT后面

在理想的網(wǎng)絡(luò)世界中，每個(gè)設(shè)備都有一個(gè)唯一的公網(wǎng)IP地址，可以直接相互連接和通信。這種理想狀態(tài)下，網(wǎng)絡(luò)是完全開(kāi)放和對(duì)等的，沒(méi)有任何障礙阻止設(shè)備之間的直接交互。

但現(xiàn)實(shí)情況卻很骨感，出于IPv4地址空間的限制(IPv4地址的數(shù)量不夠了)、網(wǎng)絡(luò)管理以及網(wǎng)絡(luò)安全的考慮，大多數(shù)設(shè)備都隱藏在NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換)后面。

NAT（網(wǎng)絡(luò)地址轉(zhuǎn)換）技術(shù)于1994年由Egevang等人在RFC 1631[6]中提出，旨在作為緩解IPv4地址不足問(wèn)題的臨時(shí)技術(shù)方案。通過(guò)將私有IP地址和端口映射到公共IP地址和端口，NAT使得在私有網(wǎng)絡(luò)中的設(shè)備可以使用公共地址(共享一個(gè)或多個(gè))訪問(wèn)互聯(lián)網(wǎng)。

NAT轉(zhuǎn)換示意圖(來(lái)自維基百科)

這種技術(shù)的出現(xiàn)大大緩解了IPv4地址的緊張狀況，并成為當(dāng)時(shí)乃至現(xiàn)在(IPv6的推廣與使用未及預(yù)期)網(wǎng)絡(luò)地址管理的重要手段。不過(guò)，NAT技術(shù)的廣泛應(yīng)用也意味著大部分設(shè)備只有私網(wǎng)IP，無(wú)法從外網(wǎng)直接訪問(wèn)，這一定程度上限制了端到端的直接通信。另外，由于不同類型的NAT行為有所不同，進(jìn)一步增加了端到端網(wǎng)絡(luò)連接的復(fù)雜性。

注：私網(wǎng)IP地址是指在局域網(wǎng)（LAN）中使用的IP地址，這些地址不能在公共互聯(lián)網(wǎng)(公網(wǎng))中被路由。私網(wǎng)IP地址主要用于內(nèi)部網(wǎng)絡(luò)中設(shè)備之間的通信，通常用于家庭、企業(yè)或組織的網(wǎng)絡(luò)。根據(jù)IETF的標(biāo)準(zhǔn)，私網(wǎng)IP地址的范圍包括(以CIDR（無(wú)類域間路由）格式表示)：10.0.0.0/8、172.16.0.0/12和192.168.0.0/16。

于是便有了NAT打洞技術(shù)(NAT hole punching)。NAT打洞技術(shù)為在NAT環(huán)境中實(shí)現(xiàn)設(shè)備間直接通信提供了一種有效的解決方案，它允許位于不同NAT后面的設(shè)備建立直接的點(diǎn)對(duì)點(diǎn)（P2P）連接，而無(wú)需手工配置端口轉(zhuǎn)發(fā)。在P2P文件共享、VoIP通信、在線游戲、即時(shí)通信以及視頻會(huì)議系統(tǒng)等領(lǐng)域，NAT打洞都有著廣泛的應(yīng)用。

不過(guò)，要理解NAT打洞，我們需要要先得弄清楚NAT的工作原理、主要的NAT類型以及它們的行為差異。

3. NAT的工作原理與主要類型的行為差異

我們先來(lái)看看NAT工作原理。

3.1 NAT的工作原理

網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）的核心工作原理還是比較好理解的，就是在請(qǐng)求數(shù)據(jù)包通過(guò)NAT設(shè)備時(shí)修改其源IP和源端口信息。以下圖為例，即將內(nèi)網(wǎng)主機(jī)通過(guò)X1:x1發(fā)往外網(wǎng)主機(jī)Y1:y1的網(wǎng)絡(luò)請(qǐng)求中的源IP和源端口從X1:x1修改為X1':x1'后，再發(fā)給目的端點(diǎn)(Y1:y1)。NAT設(shè)備會(huì)維護(hù)一個(gè)映射表(也叫會(huì)話表)，記錄X1:x1與X1':x1'的映射關(guān)系。當(dāng)請(qǐng)求的應(yīng)答包回來(lái)時(shí)(Y1:y1 -> X1':x1')，NAT設(shè)備將根據(jù)映射表將X1':x1'再替換回X1:x1，這樣應(yīng)答包就可以正?；氐絏1:x1了。

圖片

為了管理資源(每個(gè)NAT的對(duì)外端口數(shù)量有限)，NAT設(shè)備會(huì)內(nèi)置超時(shí)機(jī)制，它會(huì)為每個(gè)會(huì)話/映射設(shè)置一個(gè)生存時(shí)間（TTL）。如果在TTL內(nèi)沒(méi)有新的數(shù)據(jù)包，這個(gè)映射會(huì)被刪除。

隨著NAT技術(shù)的演進(jìn)，同時(shí)考慮到網(wǎng)絡(luò)管理和網(wǎng)絡(luò)安全因素，NAT設(shè)備出現(xiàn)了不同的映射表管理方式，與之相對(duì)應(yīng)的就出現(xiàn)了不同的NAT類型與行為特征。接下來(lái)，我們就來(lái)看看NAT的主要類型、映射表的管理方式以及它們的行為差異。

注：NAT打洞的主流方式是通過(guò)UDP包，因此下面的關(guān)于NAT類型和行為的描述都是基于UDP的。UDP是面向數(shù)據(jù)報(bào)的傳輸層協(xié)議，相對(duì)于面向連接的TCP，它更加靈活，延遲更低，在實(shí)時(shí)性要求更高的場(chǎng)景，比如視頻會(huì)議、語(yǔ)音通信等。

3.2 NAT的主要類型

根據(jù)2003年RFC 3489[7]中對(duì)市面上NAT實(shí)現(xiàn)類型的歸納，NAT可以分為完全錐形(Full Cone)、受限錐形(Restricted Cone)、端口受限錐形(Port Restricted Cone)和對(duì)稱型(Symmetric)四種主要類型。下面我們分別來(lái)說(shuō)一下這四種類型的NAT映射表構(gòu)成以及行為特征。

3.2.1 完全錐型NAT

完全錐型是最寬松的NAT類型，它在NAT映射表中只存儲(chǔ)了一個(gè)四元組：(內(nèi)網(wǎng)ip(internal_ip), 內(nèi)網(wǎng)端口(internal_port), 映射ip(external_ip), 映射端口(external_port))。我們看下圖中的完全錐形類型的NAT：：

圖片

在上圖中，內(nèi)部地址X1:x1被映射到了外部地址E:x1'，所有從X1:x1發(fā)到外部的數(shù)據(jù)都由E:x1'向外發(fā)送。相應(yīng)的外部應(yīng)答(比如: Y1:y1 -> E:x1')的流量會(huì)在NAT設(shè)備上被轉(zhuǎn)換回到X1:x1的流量。

那么為什么這個(gè)類型的NAT會(huì)被稱為完全錐形呢？這就要從NAT設(shè)備對(duì)外部流量的限制來(lái)說(shuō)了。對(duì)于NAT設(shè)備來(lái)說(shuō)，一旦建立了X1:x1->E:x1'的映射規(guī)則，就好比X1在該NAT設(shè)備上“打了一個(gè)洞”，內(nèi)部來(lái)自X1:x1的流量可以從該洞發(fā)送出去，但NAT設(shè)備是否允許外部流量從該洞回到X1:x1以及允許哪些流量從該洞返回到X1:x1就決定了該NAT的類型。

如果任何外部主機(jī)都可以通過(guò)上面的洞E:x1'向內(nèi)部主機(jī)X1:x1發(fā)送數(shù)據(jù)包，那么這個(gè)NAT就是完全錐形。我們?cè)儆靡桓笔疽鈭D來(lái)說(shuō)明一下完全錐形NAT的行為特點(diǎn)：

圖片

這里故意將右側(cè)的外部主機(jī)排列成像圓錐的形狀，位于錐子范圍內(nèi)的所有主機(jī)都能通過(guò)圖中的“洞”將數(shù)據(jù)包發(fā)到內(nèi)部主機(jī)X1:x1上。

很顯然完全錐形NAT雖然管理簡(jiǎn)單，也具有很好的開(kāi)放性，但它在安全性上較弱，外部很容易利用NAT上的洞向內(nèi)部主機(jī)上的服務(wù)發(fā)起攻擊。

為此，后面的幾種NAT都是為了增強(qiáng)NAT安全性的，而且一個(gè)比一個(gè)更嚴(yán)格，我們先來(lái)看受限錐形NAT。

3.2.2 受限錐型NAT

受限錐形NAT又被稱為IP受限錐型NAT，它在完全錐形NAT的映射表的基礎(chǔ)上，增加了“IP白名單(如下圖中的allowed_external_ips)”，下面是受限錐形NAT的示意圖：

圖片

我們看到：X1主機(jī)通過(guò)X1:x1在向Y1:y1和Y2:y2分別發(fā)起請(qǐng)求后，NAT設(shè)備上便有了一條映射規(guī)則(一個(gè)洞)：X1:x1被映射到了外部地址E:x1'，但映射表也記錄了兩個(gè)請(qǐng)求的目標(biāo)主機(jī)的IP，記錄在規(guī)則的allowed_external_ips中。

規(guī)則中的這個(gè)allowed_external_ips對(duì)后續(xù)外部主機(jī)通過(guò)E:x1'向X1:x1發(fā)送數(shù)據(jù)包會(huì)做出限制，如下圖：

圖片

我們看到：只有在“白名單”中的IP對(duì)應(yīng)的主機(jī)（如Y1、Y2）才可以在“洞”建立后，通過(guò)E:x1'向內(nèi)部主機(jī)X1:x1成功發(fā)送數(shù)據(jù)包，其它主機(jī)發(fā)送的數(shù)據(jù)包都會(huì)被攔截和丟棄。

我們看到上述的限制是限制是基于IP地址的，而位于Y1和Y2上的服務(wù)，可以使用任意端口向E:x1'成功發(fā)送數(shù)據(jù)包，這顯然也是一個(gè)安全隱患。于是便有了下面限制更為嚴(yán)格的端口受限錐形NAT。

3.2.3 端口受限錐型NAT

端口受限錐型NAT在受限錐形NAT映射表的基礎(chǔ)上，又進(jìn)一步限制了端口，通過(guò)allowed_external_endpoints實(shí)現(xiàn)對(duì)外部端點(diǎn)的限制，如面示意圖：

注：IP:port合在一起稱為一個(gè)端點(diǎn)(endpoint)。

圖片

我們看到：X1主機(jī)通過(guò)X1:x1在向Y1:y1和Y2:y2分別發(fā)起請(qǐng)求后，NAT設(shè)備上便有了一條映射規(guī)則(一個(gè)洞)：X1:x1被映射到了外部地址E:x1'，映射表同時(shí)記錄了兩個(gè)請(qǐng)求的目標(biāo)主機(jī)的端點(diǎn)(ip:port)，記錄在規(guī)則的allowed_external_endpoints中。

規(guī)則中的這個(gè)allowed_external_pointss對(duì)后續(xù)外部主機(jī)通過(guò)E:x1'向X1:x1發(fā)送數(shù)據(jù)包會(huì)做出更嚴(yán)格的限制，如下圖：

圖片

我們看到：只有在“allowed_external_endpoints”中的端點(diǎn)（如Y1:y1、Y2:y2）發(fā)起的請(qǐng)求才可以在“洞”建立后，通過(guò)E:x1'向內(nèi)部主機(jī)X1:x1成功發(fā)送數(shù)據(jù)包，其它主機(jī)或Y1、Y2上其他端口發(fā)送的數(shù)據(jù)包都會(huì)被攔截和丟棄。

下面我們?cè)賮?lái)看看最嚴(yán)格的NAT類型：對(duì)稱型NAT。

3.2.4 對(duì)稱型NAT

和上面由X1:x1發(fā)出的數(shù)據(jù)包(無(wú)論目的端點(diǎn)是什么)在NAT上只建立一條映射規(guī)則不同，在對(duì)稱型NAT中，由X1:x1向不同端點(diǎn)發(fā)送數(shù)據(jù)會(huì)在NAT上建立多條映射規(guī)則，如下圖所示：

圖片

我們看到每條規(guī)則中還包含了目的端點(diǎn)的信息(dest_ip和dest_port)，也正因?yàn)槿绱?，?duì)稱型NAT對(duì)外部請(qǐng)求的限制也是最嚴(yán)格的，如下圖所示：

圖片

我們看到：只有來(lái)自規(guī)則中dest_ip和dest_port組成的端點(diǎn)的數(shù)據(jù)包才能進(jìn)入內(nèi)部，即只有那些收到數(shù)據(jù)的外部主機(jī)才能夠“順原路返回”地回送數(shù)據(jù)。

3.3 新的分類

上面提到的四種NAT類型是stun的RFC在早期對(duì)NAT實(shí)現(xiàn)的分類(基于UDP傳輸)，一直沿用至今，也是目前使用最多的一種分類方法。不過(guò)這種分類方法將NAT的兩個(gè)正交的行為混在一起說(shuō)了，即分配行為Assignment Behavior和過(guò)濾行為Filtering Behavior。其實(shí)我們更多關(guān)注的使其過(guò)濾行為的特征。

在較新的RFC 4787[8]中，NAT的行為被細(xì)分為兩個(gè)獨(dú)立的維度：分配行為（Assignment Behavior）和過(guò)濾行為（Filtering Behavior）。這兩種行為的各自分類描述了NAT在處理映射和過(guò)濾時(shí)的不同方式。以下是這兩種行為的分類及其對(duì)應(yīng)的早期NAT類型的對(duì)照。

3.3.1 分配行為（Assignment Behavior）

分配行為定義了NAT設(shè)備如何為內(nèi)網(wǎng)設(shè)備的流量分配外部端口和地址。RFC 4787將其分為三類：

• Endpoint-Independent Mapping（端點(diǎn)獨(dú)立映射）

不管內(nèi)網(wǎng)設(shè)備與哪個(gè)外部設(shè)備通信，只要內(nèi)網(wǎng)設(shè)備使用同一個(gè)源IP和源端口，NAT都會(huì)為其分配相同的外部IP和端口。這意味著內(nèi)網(wǎng)設(shè)備的源IP和源端口在外部網(wǎng)絡(luò)上呈現(xiàn)為固定的外部IP和端口組合，獨(dú)立于目標(biāo)設(shè)備的地址和端口，即獨(dú)立于目標(biāo)設(shè)備的端點(diǎn)。

端點(diǎn)獨(dú)立映射這種類別對(duì)應(yīng)的早期NAT類型是完全錐形NAT（Full Cone NAT），前面我們講過(guò)，在完全錐形NAT中，無(wú)論內(nèi)網(wǎng)設(shè)備的通信目標(biāo)是什么，NAT設(shè)備都會(huì)使用相同的外部端口映射，因此完全符合端點(diǎn)獨(dú)立映射的定義。

• Address-Dependent Mapping（地址依賴映射）

在地址依賴映射中，內(nèi)網(wǎng)設(shè)備的外部端口是根據(jù)其通信的目標(biāo)IP地址來(lái)分配的。如果內(nèi)網(wǎng)設(shè)備改變了目標(biāo)IP地址，即使源IP和源端口不變，NAT設(shè)備也會(huì)為其分配一個(gè)新的外部端口。

在分配行為上，我們似乎無(wú)法找到與早期分類一模一樣的類型，它有些類似于對(duì)稱NAT，但對(duì)稱NAT不僅考慮目標(biāo)IP，還考慮目標(biāo)端口。

• Address and Port-Dependent Mapping（地址和端口依賴映射）

在這種映射行為中，內(nèi)網(wǎng)設(shè)備的外部端口是根據(jù)其通信的目標(biāo)IP地址和目標(biāo)端口組合來(lái)分配的。如果內(nèi)網(wǎng)設(shè)備改變了目標(biāo)IP或端口，即使源IP和源端口不變，NAT設(shè)備仍會(huì)分配一個(gè)新的外部端口。該類型對(duì)應(yīng)的是早期NAT類型中的對(duì)稱NAT（Symmetric NAT）。對(duì)稱NAT的行為正是基于目標(biāo)IP和端口的組合來(lái)分配外部端口，因此它完全符合地址和端口依賴映射的定義。

3.3.2 過(guò)濾行為（Filtering Behavior）

過(guò)濾行為描述了NAT設(shè)備如何決定是否允許外部設(shè)備通過(guò)NAT與內(nèi)網(wǎng)設(shè)備通信。RFC 4787將其分為三類：

• Endpoint-Independent Filtering（端點(diǎn)獨(dú)立過(guò)濾）

這種類型的NAT設(shè)備不考慮外部設(shè)備的地址或端口，只要內(nèi)網(wǎng)設(shè)備先發(fā)起了一個(gè)會(huì)話，任何外部設(shè)備都可以通過(guò)NAT設(shè)備與內(nèi)網(wǎng)設(shè)備的相同源IP和源端口通信。這和早期NAT類型中的完全錐形NAT完全契合。

• Address-Dependent Filtering（地址依賴過(guò)濾）

這種類型的NAT設(shè)備只允許內(nèi)網(wǎng)設(shè)備已經(jīng)與之通信的外部IP地址與其通信。換句話說(shuō)，只有內(nèi)網(wǎng)設(shè)備先與某個(gè)特定的外部IP地址通信后，該外部IP地址的設(shè)備才能通過(guò)NAT與內(nèi)網(wǎng)設(shè)備通信。這和早期NAT類型中的限制錐形NAT（Restricted Cone NAT）在過(guò)濾行為的特征上是一致的。

• Address and Port-Dependent Filtering（地址和端口依賴過(guò)濾）

這種類型的NAT設(shè)備要求外部設(shè)備的IP地址和端口都與內(nèi)網(wǎng)設(shè)備已經(jīng)建立連接的目標(biāo)IP地址和端口匹配，才能允許通信。這意味著，只有內(nèi)網(wǎng)設(shè)備先與某個(gè)特定的外部IP和端口組合通信后，該組合才能與內(nèi)網(wǎng)設(shè)備通信。這與早期NAT類型中的端口限制錐形NAT（Port Restricted Cone NAT）以及對(duì)稱NAT的行為特征是一致的。

可以看出，RFC 4787中的分類方法更為細(xì)致地將NAT的分配行為和過(guò)濾行為分開(kāi)討論，使得對(duì)NAT的行為理解更加明確。這種分類不僅幫助理解了不同NAT類型的工作機(jī)制，也為更精確地描述NAT行為提供了標(biāo)準(zhǔn)化的術(shù)語(yǔ)。

當(dāng)然對(duì)于NAT打洞來(lái)說(shuō)，我們更關(guān)心的顯然是過(guò)濾行為。

4. 小結(jié)

好了，這篇文章到這里就告一段落了。

在這篇文章中，我們探討了WebRTC網(wǎng)絡(luò)架構(gòu)和NAT的工作原理。

我們首先了解了WebRTC的網(wǎng)絡(luò)架構(gòu)，包括信令服務(wù)器、STUN服務(wù)器、TURN服務(wù)器和ICE框架等組件和其作用。

然后，我們討論了為什么需要NAT，包括解決IPv4地址短缺、提高安全性和簡(jiǎn)化網(wǎng)絡(luò)管理等原因。

接著，我們?cè)敿?xì)解釋了NAT的工作原理，以及完全圓錐型、受限圓錐型、端口受限圓錐型和對(duì)稱型這四種主要的早期NAT類型。

最后，我們介紹了RFC 4787中對(duì)NAT行為的新分類方法，將NAT行為分為分配行為和過(guò)濾行為兩個(gè)維度。

了解WebRTC網(wǎng)絡(luò)架構(gòu)以及NAT工作原理是理解NAT打洞機(jī)制以及WebRTC端到端建立連接過(guò)程的前提，在后續(xù)文章中，我們會(huì)繼續(xù)WebRTC網(wǎng)絡(luò)部分的內(nèi)容，比如NAT打洞以及端到端建連過(guò)程。

5. 參考資料

• How NAT traversal works[9] - https://tailscale.com/blog/how-nat-traversal-works
• Implementing NAT Hole Punching with QUIC[10] - https://arxiv.org/abs/2408.01791
• Network Address Translation (NAT) Behavioral Requirements for Unicast UDP[11] - https://tools.ietf.org/html/rfc4787
• WebRTC 1.0: Real-time Communication Between Browsers[12] - https://www.w3.org/TR/webrtc/
• Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal[13] - https://tools.ietf.org/html/rfc8445
• Session Traversal Utilities for NAT (STUN)[14] - https://datatracker.ietf.org/doc/html/rfc5389
• Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)[15] - https://datatracker.ietf.org/doc/html/rfc5766
• Traditional IP Network Address Translator (Traditional NAT)[16] - https://datatracker.ietf.org/doc/html/rfc3022
• IP Network Address Translator (NAT) Terminology and Considerations[17] - https://datatracker.ietf.org/doc/html/rfc2663

參考資料

[1] OpenAI與Livekit的合作: https://blog.livekit.io/open-source-realtime-multimodal-ai/

[2] 使AI模型具有了看、聽(tīng)和說(shuō)話的能力: https://openai.com/index/chatgpt-can-now-see-hear-and-speak/

[3] 使用Go和WebRTC data channel實(shí)現(xiàn)端到端實(shí)時(shí)通信: https://tonybai.com/2023/09/23/p2p-rtc-implementation-with-go-and-webrtc-data-channel

[4] Pion: https://github.com/pion/webrtc

[5] 使用Go和WebRTC data channel實(shí)現(xiàn)端到端實(shí)時(shí)通信: https://tonybai.com/2023/09/23/p2p-rtc-implementation-with-go-and-webrtc-data-channel

[6] RFC 1631: https://datatracker.ietf.org/doc/html/rfc1631

[7] RFC 3489: https://datatracker.ietf.org/doc/html/rfc3489

[8] RFC 4787: https://datatracker.ietf.org/doc/html/rfc4787

[9] How NAT traversal works: https://tailscale.com/blog/how-nat-traversal-works

[10] Implementing NAT Hole Punching with QUIC: https://arxiv.org/abs/2408.01791

[11] Network Address Translation (NAT) Behavioral Requirements for Unicast UDP: https://tools.ietf.org/html/rfc4787

[12] WebRTC 1.0: Real-time Communication Between Browsers: https://www.w3.org/TR/webrtc/

[13] Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal: https://datatracker.ietf.org/doc/html/rfc8445

[14] Session Traversal Utilities for NAT (STUN): https://datatracker.ietf.org/doc/html/rfc5389

[15] Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN): https://datatracker.ietf.org/doc/html/rfc5766

[16] Traditional IP Network Address Translator (Traditional NAT): https://datatracker.ietf.org/doc/html/rfc3022

[17] IP Network Address Translator (NAT) Terminology and Considerations: https://datatracker.ietf.org/doc/html/rfc2663