UNIX網絡編程——內網與外網間通訊

     QQ是一個基於TCP/UDP協議的通信軟件

 

     發送消息的時候是UDP打洞,登錄的時候使用HTTP~由於登錄服務器其實就是一個HTTP服務器,只不過不是經常使用的那些,那個服務器是騰訊自行開發的！！！

1、登陸

     QQ客戶端在局域網內，當你打開QQ登陸到QQ服務器時，經過外網，你的客戶端與QQ服務器創建了一個長鏈接。你能夠用netstat -bn  看到此鏈接的狀態是 establish

     此時，在QQ服務器那面看到的鏈接的IP是大家局域網對外的IP。舉個例子：       
     QQ服務器      IP：121.115.11.81    服務端口：80       
     你的機器在局域網中內部IP：   10.19.9.89       
     你局域網出口InternetIP：  61.183.172.149       
     你的客戶端的請求將經過外網出去，若是防火牆沒有禁止訪問Internet上80端口服務，那麼你的QQ客戶端能夠正常登陸。你看到的鏈接是 （netstat  -bn）       
10.19.9.89:55579           124.115.11.81：80   establish       
      

     這是一個假象。經過QQ服務器看到的鏈接是：       
124.115.11.81：80      61.183.172.149：31234    establish       
      
     這樣，防火牆上的31234口對應的就是你機器的55579口。（因爲你是發起方，這個數是變化的。動態的）       
     當有信息給你時，QQ服務器只須要發給防火牆的55579口便可。（這裏防火牆做了地址翻譯）       
      
     無論UDP仍是TCP，最終登錄成功以後，QQ都會有一個TCP鏈接來保持在線狀態。這個TCP鏈接的遠程端口通常是80，採用UDP方式登錄的時候，端口是8000。所以，假如你所在的網絡開放了80端口（80端口是最經常使用端口。。就是一般訪問Web的端口，禁掉它的話，你的網絡對你來講價值已經不大了），但沒有屏蔽騰訊的服務器IP，恭喜你，你是能夠登錄成功QQ的。

2、聊天消息通訊
    採用UDP協議，經過服務器中轉方式。你們都知道，UDP 協議是不可靠協議，它只管發送，無論對方是否收到的，但它的傳輸很高效。可是，做爲聊天軟件，怎麼能夠採用這樣的不可靠方式來傳輸消息呢？因而，騰訊採用了上層協議來保證可靠傳輸：若是客戶端使用UDP協議發出消息後，服務器收到該包，須要使用UDP協議發回一個應答包。如此來保證消息能夠無遺漏傳輸。之因此會發生在客戶端明明看到「消息發送失敗」但對方又收到了這個消息的狀況，就是由於客戶端發出的消息服務器已經收到並轉發成功，但客戶端因爲網絡緣由沒有收到服務器的應答包引發的。

 

     由於用戶通常都是在局域網內，地址都爲私有IP，騰訊服務器是如何將信息轉發到用戶的？

     首先先介紹一些基本概念：

     NAT(Network AddressTranslators)，網絡地址轉換：網絡地址轉換是在IP地址日益缺少的狀況下產生的，它的主要目的就是爲了可以地址重用。NAT分爲兩大類，基本的NAT和NAPT(Network Address/Port Translator)。
     最開始NAT是運行在路由器上的一個功能模塊。
   
     最早提出的是基本的NAT，它的產生基於以下事實：一個私有網絡（域）中的節點中只有不多的節點須要與外網鏈接（呵呵，這是在上世紀90年代中期提出的）。那麼這個子網中其實只有少數的節點須要全球惟一的IP地址，其餘的節點的IP地址應該是能夠重用的。
     所以，基本的NAT實現的功能很簡單，在子網內使用一個保留的IP子網段，這些IP對外是不可見的。子網內只有少數一些IP地址能夠對應到真正全球惟一的IP地址。若是這些節點須要訪問外部網絡，那麼基本NAT就負責將這個節點的子網內IP轉化爲一個全球惟一的IP而後發送出去。(基本的NAT會改變IP包中的原IP地址，可是不會改變IP包中的端口)
    關於基本的NAT能夠參看RFC 1631
   
     另一種NAT叫作NAPT，從名稱上咱們也能夠看得出，NAPT不但會改變通過這個NAT設備的IP數據報的IP地址，還會改變IP數據報的TCP/UDP端口。基本NAT的設備可能咱們見的很少（呵呵，我沒有見到過），NAPT纔是咱們真正討論的主角。看下圖：
                               Server S1                        
                        18.181.0.31:1235                         
                                     |
          ^  Session 1 (A-S1) ^      | 
          | 18.181.0.31:1235  |      |  
          v 155.99.25.11:62000v      |   
                                     |
                                    NAT
                                155.99.25.11
                                     |
          ^  Session 1(A-S1)  ^      | 
          | 18.181.0.31:1235  |      | 
          v  10.0.0.1:1234    v      | 
                                     |
                                  Client A
                               10.0.0.1:1234
     有一個私有網絡10.*.*.*，ClientA是其中的一臺計算機，這個網絡的網關（一個NAT設備）的外網IP是155.99.25.11(應該還有一個內網的IP地址，好比10.0.0.1)。若是Client A中的某個進程（這個進程建立了一個UDPSocket,這個Socket綁定1234端口）想訪問外網主機18.181.0.31的1235端口，那麼當數據包經過NAT時會發生什麼事情呢？
     首先NAT會改變這個數據包的原IP地址，改成155.99.25.11。接着NAT會爲這個傳輸建立一個Session（Session是一個抽象的概念，若是是TCP，也許Session是由一個SYN包開始，以一個FIN包結束。而UDP呢，以這個IP的這個端口的第一個UDP開始，結束呢，呵呵，也許是幾分鐘，也許是幾小時，這要看具體的實現了）而且給這個Session分配一個端口，好比62000，而後改變這個數據包的源端口爲62000。因此原本是（10.0.0.1:1234->18.181.0.31:1235）的數據包到了互聯網上變爲了（155.99.25.11:62000->18.181.0.31:1235）。

      一旦NAT建立了一個Session後，NAT會記住62000端口對應的是10.0.0.1的1234端口，之後從18.181.0.31發送到62000端口的數據會被NAT自動的轉發到10.0.0.1上。（注意：這裏是說18.181.0.31發送到62000端口的數據會被轉發，其餘的IP發送到這個端口的數據將被NAT拋棄）這樣Client A就與Server S1創建以了一個鏈接。

      呵呵，上面的基礎知識可能不少人都知道了，那麼下面是關鍵的部分了。
   

     看看下面的狀況：
    Server S1                                    Server S2
 18.181.0.31:1235                             138.76.29.7:1235
       |                                            |
       |                                            |
        +----------------------+----------------------+
                              |
   ^  Session 1 (A-S1)  ^     |      ^  Session 2 (A-S2)  ^
   |  18.181.0.31:1235  |     |      |  138.76.29.7:1235  |
   v 155.99.25.11:62000 v     |      v 155.99.25.11:62000 v
                              |
                           Cone NAT
                         155.99.25.11
                              |
   ^  Session 1 (A-S1)  ^     |      ^  Session 2 (A-S2)  ^
   |  18.181.0.31:1235  |     |      |  138.76.29.7:1235  |
   v   10.0.0.1:1234   v      |      v  10.0.0.1:1234    v
                              |
                           Client A
                        10.0.0.1:1234
     接上面的例子，若是Client A的原來那個Socket(綁定了1234端口的那個UDP Socket)又接着向另一個Server S2發送了一個UDP包，那麼這個UDP包在經過NAT時會怎麼樣呢？
     這時可能會有兩種狀況發生：一種是NAT再次建立一個Session，而且再次爲這個Session分配一個端口號（好比：62001）。另一種是NAT再次建立一個Session，可是不會新分配一個端口號，而是用原來分配的端口號62000。前一種NAT叫作SymmetricNAT，後一種叫作ConeNAT。咱們指望咱們的NAT是第二種，呵呵，若是你的NAT恰好是第一種，那麼極可能會有不少P2P軟件失靈。（能夠慶幸的是，如今絕大多數的NAT屬於後者，即Cone NAT）
  
     好了，咱們看到，經過NAT，子網內的計算機向外連結是很容易的（NAT至關於透明的，子網內的和外網的計算機不用知道NAT的狀況）。
     可是若是外部的計算機想訪問子網內的計算機就比較困難了（而這正是P2P所須要的）。
     那麼咱們若是想從外部發送一個數據報給內網的計算機有什麼辦法呢？首先，咱們必須在內網的NAT上打上一個「洞」（也就是前面咱們說的在NAT上創建一個Session），這個洞不能由外部來打，只能由內網內的主機來打。並且這個洞是有方向的，好比從內部某臺主機（好比：192.168.0.10）向外部的某個IP(好比：219.237.60.1)發送一個UDP包，那麼就在這個內網的NAT設備上打了一個方向爲219.237.60.1的「洞」，（這就是稱爲UDP HolePunching的技術）之後219.237.60.1就能夠經過這個洞與內網的192.168.0.10聯繫了。（可是其餘的IP不能利用這個洞）。

     呵呵，如今該輪到咱們的正題P2P了。有了上面的理論，實現兩個內網的主機通信就差最後一步了：兩邊都沒法主動發出鏈接請求，誰也不知道誰的公網地址，那咱們如何來打這個洞呢？咱們須要一箇中間人來聯繫這兩個內網主機。
     如今咱們來看看一個P2P軟件的流程，如下圖爲例：

                      Server S （219.237.60.1）
                                 |
                                 |
   +-----------------------+----------------------+
  |                                            |
 NAT A (外網IP:202.187.45.3)                NAT B (外網IP:187.34.1.56)
   |   (內網IP:192.168.0.1)                     | (內網IP:192.168.0.1)
  |                                            |
Client A (192.168.0.20:60000)            Client B (192.168.0.10:40000)

     首先，Client A登陸服務器，NAT A爲此次的Session分配了一個端口60000，那麼ServerS收到的Client A的地址是202.187.45.3:60000，這就是Client A的外網地址了。一樣，ClientB登陸Server S，NAT B給這次Session分配的端口是40000，那麼ServerS收到的B的地址是187.34.1.56:40000。
     此時，Client A與Client B均可以與ServerS通訊了。若是Client A此時想直接發送信息給Client B，那麼他能夠從ServerS那兒得到B的公網地址187.34.1.56:40000，是否是Client A向這個地址發送信息ClientB就能收到了呢？答案是不行，由於若是這樣發送信息，NAT B會將這個信息丟棄（由於這樣的信息是不請自來的，爲了安全，大多數NAT都會執行丟棄動做）。那該怎麼辦呢？   首先咱們假設Server S是219.237.60.1：7000，當Clinet A（202.187.45.3：60000）向Server S（219.237.60.1：7000）發送數據包，Server S是能夠正常接收到數據，由於它是屬於外型開放的服務器端口。當Server S收到數據包後能夠獲知Clinet A（202.187.45.3：60000）對外通訊的臨時session信息（這個叫臨時的端口，假設是60000會過時，具體時間不一樣，通常是每30S發送一個keep住鏈接以保證端口維持通訊鏈接不斷）Server S此時應將次信息保存起來。而同時，Client B (192.168.0.10:40000)也在時刻向Server S發送心跳包，Server S就向Client B (192.168.0.10:40000)發送一個通知，Client B (192.168.0.10:4000) 發送探測包（這個數據包最好發幾個），Client B  (192.168.0.10:4000)在收到通知後在向Server S發送反饋包，說明以向本身以向Client A  (192.168.0.20:60000)發送了探測包，Server S在收到反饋以後再向ClientA  (192.168.0.20:60000)轉發反饋包，Client A  (192.168.0.20:60000)在收到數據包以後在向本來要求請求的Client B (192.168.0.10:4000)發送數據包，此時鏈接已經打通，實現穿透。Client B  (192.168.0.10:4000)會將數據包轉發給Client A  (192.168.0.20:60000)從而在轉發給內網內網IP:192.168.0.1。

     對於Symmetric NAPT的狀況，網上有人說能夠經過探測端口的方式，不過成功率並不高，我建議可用服務器進行中轉。另外，最好在數據包發送前先檢測是否進行的是同個NAT的狀況，也就是內網發內網，若是是，直接發送便可，而無需經過外網再繞回來。