斜體部分為讀者提問：

為什麼p2p模式的tunnel底層通常用udp而不是tcp？

為了更好地解釋這個問題，先來科普一下什麼是隧道(Tunnel)。

當打開一個沒有加密的網頁時，客戶端與伺服器端交互報文的封裝格式通常為：

IP/TCP/http

加密的網頁的封裝格式為：

IP/TCP/TLS/http

通過FTP下載文件時的封裝格式為：

IP/TCP/ftp

當域名/IP地址解析時，封裝格式為：

IP/UDP/dns

上述的應用，同學們每天都在自己的電腦上操作過，這些封裝格式為「非隧道」模式。

「非隧道」模式

無論採用IP/TCP組合傳輸，還是使用IP/UDP組合傳輸，被傳輸的貨物本身不包含任何IP頭。

比如「http」、 「tls/http」、 「ftp」、「dns」作為貨物，自身都沒有包含IP封裝。這是識別是否隧道模式的關鍵要素。

但上文的「非隧道」模式，用於訪問Internet上的資源是非常合適的。但往往不便於訪問私有資源。

舉個例子

一公司在伺服器(10.0.0.8/24)上提供文件共享服務，員工可以公司內部自由地訪問，但Internet上的用戶無法訪問10.0.0.8。

員工希望在外出差或在家辦公也可以訪問10.0.0.8這台文件伺服器，如何能夠做到？

這個技術就是隧道！

員工在公司內部的封裝格式為：

IP/TCP/SMB

隧道的核心思想，就是希望在「IP/TCP/SMB」的添加必要的外層(outside)IP頭信息，把用戶的「IP/TCP/SMB」當作貨物來運輸。

既然這些貨物需要在Internet上運輸，自然需要使用Internet上可路由的公網IP才可以對嗎？

假定公司的公網IP = 2.2.2.2，用戶的公網IP =3.3.3.3

那麼就使用這兩個IP來在用戶(3.3.3.3)與公司(2.2.2.2)之間運輸貨物，先來看看是怎麼運輸的：

Outside IP / IP/TCP/SMB

其中outsideIP的源、目的IP分別是 3.3.3.3、2.2.2.2。

這種隧道模式即為「IPIP」類型。

有這種隧道類型嗎？

有的，但是這種類型非常不便於穿越NAT，因為在用戶與公司之間的NAT總是存在的，而不同NAT設備的NAT實現也各不相同。最最最樂觀的情況下，一台NAT設備後只能有一個用戶可以隧道連接公司。

為了避免由於NAT的差異而造成通信故障，一般不使用IPIP隧道。

通常會使用UDP隧道，封裝格式為：

Outside IP /UDP /IP /TCP/SMB

使用UDP封裝的最大的好處是，可以使用不同的UDP埠來區分不同的用戶隧道，那麼一個NAT設備後理論上可以支持65K 個用戶隧道連接。

接下來的問題是，用戶的inside IP是多少？是誰給分配的？

另外，用戶的「IP /TCP/SMB」數據在Internet上裸奔，沒有安全加密，也是無法接受的，需要有安全加密的保護。

寫到這裡，不得不非常痛苦地介紹一下控制協議，之所以痛苦是因為一切來的太突然。。。這個控制協議的名字叫IKE (Internet Key Exchange)。

Outside IP /UDP/IKE做了很多工作，主要可以概括為：

協商加密、校驗、認證演算法

交換密鑰

認證雙方

分配IP參數

假定用戶被分配的IP = 10.0.0.100

做完以上工作，用戶的「IP /TCP/SMB」就可以這樣來傳輸了。

Outside IP /UDP/ESP/ IP /TCP/SMB

用戶IP= 10.0.0.100，伺服器的IP = 10.0.0.8，分別為inside IP的源、目的IP。

通常稱 「Outside IP /UDP/IKE」為控制連接， 稱「OutsideIP /UDP /ESP/ IP /TCP/SMB」用戶數據連接。

控制連接、數據連接都採用UDP 4500埠運輸，那麼接收方如何區分裡面的貨物是控制連接報文，還是用戶數據報文？

協議是人設計的，想怎麼區分都可以，人類是這麼來區分的。

如果OutsideIP /UDP 的後面緊跟著連續的「00 00 00 00」，接收方則默認為控制連接；否則，為用戶數據！

簡單嗎？

上文的outside IP 源、目的IP，用於在Internet上路由。

Inside IP 源、目的IP，用於在公司內部路由。

為何TCP隧道不好？

讓我們再來近距離地觀賞一下「Outside IP /UDP /ESP/ IP /TCP/SMB」，所有的底層傳輸協議，只有一個狀態點/控制點，它就是TCP，雖然只有一個控制點，但依然可以保證雙方通信的可靠傳輸。其它的封裝頭部都是無狀態的(Stateless)。

假設外層使用TCP封裝，那麼就變成「Outside IP / TCP /ESP/ IP/TCP/SMB」，這裡就出現了兩個控制點/狀態點，兩個TCP頭都會對網路行為進行控制，多了一層控制，增大了數據傳輸的延遲（多了一次TCP連接），同時20位元組的TCP報文頭，相比8位元組的UDP頭，相當於用戶的數據少傳輸12個位元組。

一山難容二虎，除非一男與一女!

UDP隧道，所有底層封裝都不對用戶的數據進行控制，所有的控制都留給用戶控制，這樣可以給用戶最大的靈活空間。

用戶用UDP隧道來傳輸UDP報文，呈現的是UDP特徵。

用戶用UDP隧道來傳輸TCP報文，呈現的是TCP特徵。

TCP隧道，底層的TCP封裝會對用戶數據進行控制，用戶將失去了靈活的空間。

用戶用TCP隧道來傳輸UDP報文，呈現的是TCP特徵。

用戶用TCP隧道來傳輸TCP報文，呈現的還是TCP特徵。

TCP隧道難道一無是處？

UDP報文不需建立連接即可發送，經常被用來做攻擊報文，所以UDP報文頻頻遭清洗，UDP隧道也會被牽連到。

為了克服此種情況，可以使用TCP隧道封裝。儘管有種種的劣勢，但至少可以通信，畢竟通總比不通要好，對嗎？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！