WebRTC TURN協議初識及turnserver實踐

做者：廖俊，聲網Agora 資深工程師。

本文主要爲初步接觸 WebRTC 的開發者介紹 WebRTC turnserver 的原理機制，以及 Agora 在此方面的部分經驗。如遇到疑問，能夠點擊這裏，與做者直接交流。

WebRTC協議棧

圖一 WebRTC stack

TURN的全稱爲Traversal Using Relays around NAT，是STUN/RFC5389的一個拓展，主要添加了Relay功能。如圖一所示，TURN協議是創建在UDP協議之上的一個應用層協議。若是一臺主機處於NAT後面，那麼在必定條件下（NAT穿透失敗）兩臺主機沒法之間進行通信。在這種條件下，那麼使用中繼服務提供通信是有必要的。TURN協議容許一臺主機使用中繼服務與對端進行報文傳輸。TURN協議也是ICE（交互式鏈接創建）協議的組成部分，也能夠單獨使用。若是TURN使用於ICE協議中，relay地址會做爲一個候選，由ICE在多個候選中進行評估，選取最合適的通信地址。通常來講中繼的優先級都是最低的。

TURN和其餘中繼協議的不一樣之處在於，它容許客戶端使用同一個中繼地址（relay address）與多個不一樣的peer進行通訊。如圖二所示。

圖二 同一個中繼地址和多個peer通訊

Turn協議工做原理

Turn協議的工做原理主要有三個階段，也稱三大機制。分配（Allocation），轉發（Relay）和信道（Channel）。

1.分配機制：

客戶端想要使用中繼功能，須要在中繼服務器上申請一箇中繼地址。客戶端發送分配請求(Allocate request)到服務器，服務器爲用戶開啓一個relay端口而後返回分配成功響應，幷包含了分配的地址。

圖三 Allocation Mechanism

a) 客戶端A向STUN Port發送Allocate請求(圖中綠色部分)。

b) STUN服務器接收到客戶端A的Allocate請求，服務器一看是Allocate請求，則根據relay端口分配策略爲A分配一個端口。

c) 服務器發送response成功響應。在該response中包含XOR-RELAYED-ADDRESS屬性。該屬性值就是A的relay端口。

d) 客戶端接收到response後，就知道了本身的relay地址。該relay地址是個公網地址，能夠看做是客戶端A在公網上的一個代理，任何想要聯繫A的客戶端，只要將數據發送到A的relay地址就能夠了。

2.轉發機制：

任何想要聯繫客戶端A的人，只要知道客戶端A的relay地址就能夠了。

client和peer之間有兩種方法經過中繼服務器交換數據。第一種是使用relay，第二種使用channel。兩種方法都經過某種方式告知服務器哪一個peer應該接收數據，以及服務器告知client數據來自哪一個peer。

Relay Mechanism使用了Send和Data指令(Indication)。其中Send指令用來把數據從client發送到server，而Data指令用來把數據從server發送到client。

圖四 Relay Mechanism

如上圖所示是B主動給A發消息：「Hello」，A迴應「Hi」的過程。

a) 序號一、二、三、四、5爲B的發送請求(藍色箭頭方向)；

b) 序號六、七、八、九、10爲A的迴應，原路返回（綠色箭頭方向）。

c) 一、2階段時，發送的是裸的UDP數據。

d) 第3階段是：從A的relay端口收到數據，添加STUN頭後，最後從STUN Port 發出的過程。

e) 在四、5過程當中，是被STUN協議包裝過的「Hello」，稱之爲Data indication。爲了可以讓客戶端A知道這個包是哪一個客戶端發來的，因此，STUN 協議對「Hello」進行了從新的包裝，最主要的就是添加了一個XOR-PEER-ADDRESS屬性。

f) 六、7階段爲被STUN協議包裝過的「Hi」，稱之爲Send indication。爲了可以讓A的relay port知道最終發往哪一個客戶端，所以也爲「Hi」添加了STUN頭，也是添加了XOR-PEER-ADDRESS屬性。

g) 第8階段是：從STUN Port 接收到帶STUN 頭的數據，去掉STUN頭，最後從A的relay端口發出的過程。

h) 九、10是裸的UDP數據。

3.信道機制：

對於一些應用程序，好比VOIP，在Send/Data Indication中多加的36字節格式信息會加劇客戶端和服務端之間的帶寬壓力。爲改善這種狀況，TURN提供了第二種方法來讓client和peer交互數據.該方法使用另外一種數據包格式，即ChannelData message，信道數據報文。

ChannelData message不使用STUN頭部，而使用一個4字節的頭部，包含了一個稱之爲信道號的值(channel number)，每個使用中的信道號都與一個特定的peer綁定，即做爲對等端地址的一個記號。

要將一個信道與對等端綁定，客戶端首先發送一個信道綁定請求(ChannelBind Request)到服務器，而且指定一個未綁定的信道號以及對等端的地址信息。

圖五 Channel Mechanism

如圖五所示，中繼服務器將數據封裝成channel message發送給peer。對比圖四，其實就是講4/5/6/7的indication換成channel message。

在音視頻的傳輸應用中，使用信道機制會大大減小包頭長度，節省帶寬佔用，提升傳輸效率。

Turnserer實踐

部分政府、企業客戶會部署有防火牆將辦公環境與外網隔離開來，並且其防火牆一般會有很嚴格的ip和port限制，因此點對點傳輸基本沒法進行。此時，Turn協議就是一個很好的選擇。Turnserver具備固定的公網ip，固定的端口，只需在防火牆上開通其白名單，就能夠搭建通訊信道。

Agora在Web端提供了很好的解決方案：WebProxy。

圖六 WebProxy

如圖六所示，WebProxy包含信令和數據兩個中繼服務器，Turnserver主要負責音視頻數據的傳輸。Turnserver爲用戶開放一個TCP和一個UDP的端口，用戶經過這兩個端口建立中繼地址，後端服務經過中繼地址和內網的用戶進行數據傳輸。

後記

TURN協議在實時音視頻中是一個比較重要的協議，能很好的保證明時音視頻傳輸中鏈接的可用性，穩定性和高效性。可是TURN協議對服務器有很高的依賴，服務器在帶寬和集羣上有很大的壓力，因此TURN協議一般是看成ICE協議中的一部分來使用。