不同內網的兩臺主機之間的通訊
阿新 • • 發佈：2019-01-25
若是兩臺主機分別處於兩個不同內網，他們之間要通訊，兩邊都無法主動發出連線請求，誰也不知道誰的公網地址，那該如何做呢？
這時就得需要一箇中介來聯絡這兩個內網主機。 現在我們來看看一個P2P軟體的流程，以下圖為例：
首先，Client A登入伺服器，NAT A為這次的Session分配了一個埠60000，那麼Server S收到的Client A的地址是202.187.45.3:60000，這就是Client A的外網地址了。
同樣，Client B登入Server S，NAT B給此次Session分配的埠是40000，那麼Server S收到的B的地址是187.34.1.56:40000。 此時，Client A與Client B都可以與Server S通訊了。
如果Client A此時想直接傳送資訊給Client B，那麼他可以從Server S那兒獲得B的公網地址187.34.1.56:40000，是不是Client A向這個地址傳送資訊Client B就能收到了呢？
答案是不行，因為如果這樣傳送資訊，NAT B會將這個資訊丟棄（因為這樣的資訊是不請自來的，為了安全，大多數NAT都會執行丟棄動作）。現在我們需要的是在NAT B上打一個方向為202.187.45.3（即Client A的外網地址）的洞，那麼Client A傳送到187.34.1.56:40000的資訊，Client B就能收到了。這個打洞命令由誰來發呢，呵呵，當然是Server S。
好了，現在總結一下這個過程：如果Client A想向Client B傳送資訊，那麼Client A傳送命令給Server S，請求Server S命令Client B向Client A方向打洞。然後Client A就可以通過Client B的外網地址與Client B通訊了。
哈，很繞口，不過想一想就很清楚了。
還有一點要注意：以上過程只適合於Cone NAT的情況，如果是Symmetric NAT，那麼當Client B向Client A打洞的埠已經重新分配了，Client B將無法知道這個埠。
這時就得需要一箇中介來聯絡這兩個內網主機。 現在我們來看看一個P2P軟體的流程，以下圖為例：
首先，Client A登入伺服器，NAT A為這次的Session分配了一個埠60000，那麼Server S收到的Client A的地址是202.187.45.3:60000，這就是Client A的外網地址了。
同樣，Client B登入Server S，NAT B給此次Session分配的埠是40000，那麼Server S收到的B的地址是187.34.1.56:40000。 此時，Client A與Client B都可以與Server S通訊了。
如果Client A此時想直接傳送資訊給Client B，那麼他可以從Server S那兒獲得B的公網地址187.34.1.56:40000，是不是Client A向這個地址傳送資訊Client B就能收到了呢？
答案是不行，因為如果這樣傳送資訊，NAT B會將這個資訊丟棄（因為這樣的資訊是不請自來的，為了安全，大多數NAT都會執行丟棄動作）。現在我們需要的是在NAT B上打一個方向為202.187.45.3（即Client A的外網地址）的洞，那麼Client A傳送到187.34.1.56:40000的資訊，Client B就能收到了。這個打洞命令由誰來發呢，呵呵，當然是Server S。
好了，現在總結一下這個過程：如果Client A想向Client B傳送資訊，那麼Client A傳送命令給Server S，請求Server S命令Client B向Client A方向打洞。然後Client A就可以通過Client B的外網地址與Client B通訊了。
哈，很繞口，不過想一想就很清楚了。
還有一點要注意：以上過程只適合於Cone NAT的情況，如果是Symmetric NAT，那麼當Client B向Client A打洞的埠已經重新分配了，Client B將無法知道這個埠。