續自 NAT Traversal, part 2 - STUN.

像是 MSN messenger 等的傳統 IM (Instant Message) 網路, 其 server 只負責少許的任務, 絕大部分的工作都是一個 client 節點與別的 client 節點之間的事情. 即便如此, 在這種網路之中, 每一個 client 還是從頭到尾都是與 server 溝通, 從來不會直接對另一個 client 收發訊息. Server 除了一開始對 client 認證, 後續除了 relay (轉發) 訊息與 data (例如檔案傳輸) 之外, 幾乎就沒別的任務. 對 service provider 來說, 這種架構可說是非常浪費網路資源. 每一個經過 server relay 的封包, 都代表對 service provider 頻寬與計算能力的損耗.

這種應用之所以會採用如上述對 service provider 的 core network 負擔較大的網路架構, 最主要是因為其 client 大都在 NAT 後面, client 與 client 之間無法有效建立直通的連線 (direct connectivity). 在這種網路架構之下, 由於沒有其他明顯缺點, 常會把 signal 通道與 data 通道 multiplex 在一個 connection 裡面.

若一個 application 把 signal 與 data 分開 (如 SIP + RTP), 就可以利用 TURN (STUN relay, formerly known as Traversal Using Relay NAT), 一種泛用 (generic) 的 relay protocol. 早期的 TURN 與 STUN 類似但稍微複雜的 protocol. 在 新版本的 STUN draft 中, 已經把 TURN 納入為 STUN 的一種 usage (可視為一種 extension). 說明了兩種 protocol 之間的血緣關係. 也是 protocol 作者 在發表早期 TURN draft 時, 表明希望可以大量利用 STUN 的基礎, 發揮到最大的一種表現.

TURN 的特點是 TURN client 必須知道對方 (external peer) 使用的 transport parameter (e.g. ip:port). 才能使 TURN server 開始 relay. 假設一個 client 透過某個 signal router 與 Media Server 交換 transport parameter. TURN client, TURN server 與 Media Server (此例的 external peer). 三者的網路架構與互動流程如下圖:

Click to ZOOM or open in a new window.

首先 TURN client 對 TURN server 以 Allocate Request 做 port allocation 的動作 (1~2). 得到了 TURN server 上 allocate 給 client 的 port 之後就可以開始與 Media Server 的 offer/answer (3~6). Offer/answer 完成後 client 會得到 Media Server 的 transport parameter, 然後再藉由 Set Active Destination Request 通知 TURN server 對方的 transport parameter (7~8). 之後 Media Server 發送到 TURN server 特定端口的封包 (9) 都會被 relay 到 TURN client (10).

TURN server 除了 relay 之外, 與 TURN client (建立 TURN session 的 client) 之間仍會用少數的 request/indication/response 溝通. 但對 external peer (另一邊的端點) 卻是 transparent. 換句話說, 對 external peer 來說, TURN server 上的某個特定端點的表現, 就如同是 TURN client 就跑在這個端點上. 即便如此, 一個在 TURN client, 在 NAT 後面的節點, 無法透過 TURN server 變成一個隨意接受第三方 message 的 server. 在 TURN client 還沒有經由 Send Indication 或 Set Active Destination Request 來把某個 external peer 加入 TURN session (on TURN server) 上的 permission list 之前, 這個 external peer 送到 TURN server 的封包都不會被 relay 回 TURN client (i.e. discard).

如果兩邊都使用 TURN, 則兩邊各自都是不同 TURN session 的 client, 與它們對應的 external peer 則是對方使用的 TURN server. 下圖中兩個 client 各自建立了一個 TURN session 來與對方溝通, 對於 Client A 在 TURN (server) A 建立的 session (Session A) 來說, Client A 是這個 session 的 client, TURN (server) B 是 external peer. 反之亦然:

Click to ZOOM or open in a new windows.

這個例子還有個有趣的地方, 在 TURN A 到 Client A 與 TURN B 到 Client B 這兩段跑的是 TURN, 但在兩個 TURN server 中間跑的卻是原本的 data protocol (non-TURN’ed). TURN A 與 TURN B 都不會知道對方是個 TURN server, 它們只當 external peer 就跑在另一個 TURN server 的特定端口上.

TURN 支援在同一個 session 裡面同時對多個 external peer 溝通. 除了 active destination (preferred external peer) 之外, 與不同的 external peer 往來訊息時, 對方發給 TURN client 的封包會被包在 Data Indication 裡. 而 TURN client 則透過 Send Indication 來 encapsulate 發給非 active destination 的封包. 這兩種 indication 都包含了 REMOTE-ADDRESS 這個 attribute, 用以表示 external peer 的位址 (i.e. ip:port). 對 active destination 收發訊息時則不需要經過 encapsulation.

雖然單純採用 TURN 並沒有辦法降低對 core network 整體頻寬與計算能力的消耗, 但可以藉由把 signal routing 與 data relay 分佈在不同的 core network 節點, 達到分散 network I/O 與 computation 的效果.

預告: NAT Traversal, part 4 - ICE.