今晚閒來沒事看了這裡 (COdE fr3@K) 的 visitor log, 注意到用 NAT traversal, STUN 以及 NAT endpoint mapping 之類的 keyword 找到這邊的文字的朋友變多了.
有意思的是這些朋友的 source IP 多是國內業界叫得出名字的電子/網路設備公司, 而且大都是把 站內的相關文字 全看了. 這是否意味著 NAT/firewall 穿透這個題材在國內電子業界開始熱起來了?
可是 NAT traversal 明明是個純軟體在 endpoint 上的題目, 且需要與 layer 7 protocol 配套. 怎麼反而是電子公司在感興趣? 是不是這些廠家所生產的 NAT 不符 behave 的規範所以想了解該如何才能符合規範達到 NAT traversal friendly?
[update]
又想到一個可能, 廠商要開發代替 enpoint 執行 NAT traversal 的 Application Level Gateway. 這也是個有趣的 project.
一直想找時間把最新的 draft-ietf-mmusic-ice-16 好好拜讀. 以彌補我從第 7 (還是 8?) 個 draft 就空到現在的空窗. 但總是提不起勁來實踐.
現在無論如何, 我已經決定要利用這個禮拜下班時間與接下來的週末自由的時間來把它 K 完.
續自 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 頻寬與計算能力的損耗.
續自 NAT Traversal, part 1 – NAT Behavior.
STUN 是個非常簡單的 protocol. 就只一種功能性的 request － Binding Request. 可以先簡單想像為 ping, 不同之處在於 server 的 response 會將 client 發出 request 的 source ip:port 放在裡面回應.
NAT (不包含防火牆) 處理 UDP 封包的行為中, 對 p2p 影響最大的兩類為:
根據 wikipedia 的定義, 一個 peer-to-peer (p2p) computer network 是一個主要依賴該網路上參與者 (相對於依賴服務器) 的運算能力與帶寬的網路.
