WebRTCTURN協議初識及turnserver實踐

NO IMAGE

作者:廖俊,聲網Agora 資深工程師。

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

WebRTC協議棧

WebRTCTURN協議初識及turnserver實踐

圖一 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進行通信。如圖二所示。

WebRTCTURN協議初識及turnserver實踐

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

Turn協議工作原理

Turn協議的工作原理主要有三個階段,也稱三大機制。分配(Allocation),轉發(Relay)和信道(Channel)。

1.分配機制:

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

WebRTCTURN協議初識及turnserver實踐

圖三 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。

WebRTCTURN協議初識及turnserver實踐

圖四 Relay Mechanism

如上圖所示是B主動給A發消息:“Hello”,A迴應“Hi”的過程。

a) 序號1、2、3、4、5為B的發送請求(藍色箭頭方向);

b) 序號6、7、8、9、10為A的迴應,原路返回(綠色箭頭方向)。

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

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

e) 在4、5過程中,是被STUN協議包裝過的“Hello”,稱之為Data indication。為了能夠讓客戶端A知道這個包是哪個客戶端發來的,所以,STUN 協議對“Hello”進行了重新的包裝,最主要的就是添加了一個XOR-PEER-ADDRESS屬性。

f) 6、7階段為被STUN協議包裝過的“Hi”,稱之為Send indication。為了能夠讓A的relay port知道最終發往哪個客戶端,因此也為“Hi”添加了STUN頭,也是添加了XOR-PEER-ADDRESS屬性。

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

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

3.信道機制:

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

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

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

WebRTCTURN協議初識及turnserver實踐

圖五 Channel Mechanism

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

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

Turnserer實踐

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

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

WebRTCTURN協議初識及turnserver實踐

圖六 WebProxy

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

後記

TURN協議在實時音視頻中是一個比較重要的協議,能很好的保證實時音視頻傳輸中連接的可用性,穩定性和高效性。但是TURN協議對服務器有很高的依賴,服務器在帶寬和集群上有很大的壓力,所以TURN協議通常是當作ICE協議中的一部分來使用。

相關文章

如何通過RESTfulAPI玩轉Agora雲錄製

想快速升級編程技巧?不如邊實踐邊升級

WebRTC入門教程(四)|iOS端如何使用WebRTC

從帶寬擴展到丟包隱藏,實時音頻中的AI