解析TCP/UDP協定的通訊軟體

  QQ是一個基于TCP/UDP協定的通訊軟體 

發送消息的時候是UDP打洞,登陸的時候使用HTTP~因為登陸伺服器其實就是一個HTTP服

務器,隻不過不是常用的那些,那個伺服器是騰訊自行開發的！   一、登入   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           www.2cto.com   這是一個假象。通過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的。     二、聊天消息通信       采用UDP協定，通過伺服器中轉方式。大家都知道，UDP 協定是不可靠協定，它隻管發送，不管對方是否收到的，但它的傳輸很高效。但是，作為聊天軟體，怎麼可以采用這樣的不可靠方式來傳輸消息呢？于是，騰訊采用了上層協定來保證可靠傳輸：如果用戶端使用UDP協定發出消息後，伺服器收到該包，需要使用UDP協定發回一個應答包。如此來保證消息可以無遺漏傳輸。之是以會發生在用戶端明明看到“消息發送失敗”但對方又收到了這個消息的情況，就是因為用戶端發出的消息伺服器已經收到并轉發成功，但用戶端由于網絡原因沒有收到伺服器的應答包引起的。     因為使用者一般都是在區域網路内,位址都為私有IP,騰訊伺服器是如何将資訊轉發到使用者的?     首先先介紹一些基本概念：       NAT(Network AddressTranslators)，網絡位址轉換：網絡位址轉換是在IP位址日益缺乏的情況下産生的，它的主要目的就是為了能夠位址重用。NAT分為兩大類，基本的NAT和NAPT(Network Address/Port Translator)。       最開始NAT是運作在 路由器上的一個功能子產品。         www.2cto.com       最先提出的是基本的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:62000 v     |                                                     |                                                 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.10)。如果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就能收到了呢？答案是不行，因為如果這樣發送資訊，NATB會将這個資訊丢棄（因為這樣的資訊是不請自來的，為了安全，大多數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在收到回報之後再向Client A  (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的情況，也就是内網發内網，如果是，直接發送即可，而無需通過外網再繞回來。