原文地址: http://f543711700.iteye.com/blog/978044
發(fā)送消息的時候是UDP打洞,登陸的時候使用HTTP~因為登陸服務器其實就是一個HTTP服務器,只不過不是常用的那些,那個服務器是騰訊自行開發(fā)的ｉ先浴２男埂！
一夯缺、登錄
QQ客戶端在局域網內休溶，當你打開QQ登錄到QQ服務器時瘪阁，通過外網，你的客戶端與QQ服務器建立了一個長連接邮偎。你可以用netstat -bn 看到此連接的狀態(tài)是 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口狐蜕。（由于你是發(fā)起方，這個數(shù)是變化的卸夕。動態(tài)的）
當有信息給你時层释，QQ服務器只需要發(fā)給防火墻的55579口即可。（這里防火墻作了地址翻譯）
不管UDP還是TCP快集，最終登陸成功之后贡羔，QQ都會有一個TCP連接來保持在線狀態(tài)。這個TCP連接的遠程端口一般是80个初，采用UDP方式登陸的時候乖寒，端口是8000。因此院溺，假如你所在的網絡開放了80端口（80端口是最常用端口楣嘁。。就是通常訪問Web的端口珍逸，禁掉它的話逐虚，你的網絡對你來說價值已經不大了），但沒有屏蔽騰訊的服務器IP谆膳，恭喜你叭爱，你是可以登陸成功QQ的。
二摹量、聊天消息通信
采用UDP協(xié)議涤伐，通過服務器中轉方式。大家都知道缨称，UDP 協(xié)議是不可靠協(xié)議凝果，它只管發(fā)送，不管對方是否收到的睦尽，但它的傳輸很高效器净。但是，作為聊天軟件当凡，怎么可以采用這樣的不可靠方式來傳輸消息呢山害？于是，騰訊采用了上層協(xié)議來保證可靠傳輸：如果客戶端使用UDP協(xié)議發(fā)出消息后沿量，服務器收到該包浪慌，需要使用UDP協(xié)議發(fā)回一個應答包。如此來保證消息可以無遺漏傳輸朴则。之所以會發(fā)生在客戶端明明看到“消息發(fā)送失敗”但對方又收到了這個消息的情況权纤，就是因為客戶端發(fā)出的消息服務器已經收到并轉發(fā)成功，但客戶端由于網絡原因沒有收到服務器的應答包引起的。
因為用戶一般都是在局域網內,地址都為私有IP,騰訊服務器是如何將信息轉發(fā)到用戶的?
首先先介紹一些基本概念：
NAT(Network AddressTranslators)汹想，網絡地址轉換：網絡地址轉換是在IP地址日益缺乏的情況下產生的外邓，它的主要目的就是為了能夠地址重用。NAT分為兩大類古掏，基本的NAT和NAPT(Network Address/Port Translator)损话。
最開始NAT是運行在路由器上的一個功能模塊。
最先提出的是基本的NAT槽唾，它的產生基于如下事實：一個私有網絡（域）中的節(jié)點中只有很少的節(jié)點需要與外網連接（呵呵丧枪，這是在上世紀90年代中期提出的）。那么這個子網中其實只有少數(shù)的節(jié)點需要全球唯一的IP地址夏漱，其他的節(jié)點的IP地址應該是可以重用的豪诲。
因此顶捷，基本的NAT實現(xiàn)的功能很簡單挂绰，在子網內使用一個保留的IP子網段，這些IP對外是不可見的服赎。子網內只有少數(shù)一些IP地址可以對應到真正全球唯一的IP地址葵蒂。如果這些節(jié)點需要訪問外部網絡，那么基本NAT就負責將這個節(jié)點的子網內IP轉化為一個全球唯一的IP然后發(fā)送出去重虑。(基本的NAT會改變IP包中的原IP地址践付，但是不會改變IP包中的端口)
關于基本的NAT可以參看RFC 1631
另外一種NAT叫做NAPT，從名稱上我們也可以看得出缺厉，NAPT不但會改變經過這個NAT設備的IP數(shù)據(jù)報的IP地址永高，還會改變IP數(shù)據(jù)報的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中的某個進程（這個進程創(chuàng)建了一個UDPSocket,這個Socket綁定1234端口）想訪問外網主機18.181.0.31的1235端口久锥，那么當數(shù)據(jù)包通過NAT時會發(fā)生什么事情呢家淤？
首先NAT會改變這個數(shù)據(jù)包的原IP地址，改為155.99.25.11瑟由。接著NAT會為這個傳輸創(chuàng)建一個Session（Session是一個抽象的概念絮重，如果是TCP，也許Session是由一個SYN包開始，以一個FIN包結束绿鸣。而UDP呢疚沐，以這個IP的這個端口的第一個UDP開始，結束呢潮模，呵呵亮蛔，也許是幾分鐘，也許是幾小時擎厢，這要看具體的實現(xiàn)了）并且給這個Session分配一個端口究流，比如62000，然后改變這個數(shù)據(jù)包的源端口為62000动遭。所以本來是（10.0.0.1:1234->18.181.0.31:1235）的數(shù)據(jù)包到了互聯(lián)網上變?yōu)榱耍?55.99.25.11:62000->18.181.0.31:1235）芬探。
一旦NAT創(chuàng)建了一個Session后，NAT會記住62000端口對應的是10.0.0.1的1234端口厘惦，以后從18.181.0.31發(fā)送到62000端口的數(shù)據(jù)會被NAT自動的轉發(fā)到10.0.0.1上偷仿。（注意：這里是說18.181.0.31發(fā)送到62000端口的數(shù)據(jù)會被轉發(fā)，其他的IP發(fā)送到這個端口的數(shù)據(jù)將被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發(fā)送了一個UDP包，那么這個UDP包在通過NAT時會怎么樣呢稼稿？
這時可能會有兩種情況發(fā)生薄榛，一種是NAT再次創(chuàng)建一個Session，并且再次為這個Session分配一個端口號（比如：62001）让歼。另外一種是NAT再次創(chuàng)建一個Session敞恋，但是不會新分配一個端口號，而是用原來分配的端口號62000是越。前一種NAT叫做SymmetricNAT耳舅，后一種叫做ConeNAT。我們期望我們的NAT是第二種倚评，呵呵浦徊，如果你的NAT剛好是第一種，那么很可能會有很多P2P軟件失靈天梧。（可以慶幸的是盔性，現(xiàn)在絕大多數(shù)的NAT屬于后者，即Cone NAT）
好了呢岗，我們看到冕香，通過NAT,子網內的計算機向外連結是很容易的（NAT相當于透明的蛹尝，子網內的和外網的計算機不用知道NAT的情況）。
但是如果外部的計算機想訪問子網內的計算機就比較困難了（而這正是P2P所需要的）悉尾。
那么我們如果想從外部發(fā)送一個數(shù)據(jù)報給內網的計算機有什么辦法呢突那？首先，我們必須在內網的NAT上打上一個“洞”（也就是前面我們說的在NAT上建立一個Session）构眯，這個洞不能由外部來打愕难，只能由內網內的主機來打。而且這個洞是有方向的惫霸，比如從內部某臺主機（比如：192.168.0.10）向外部的某個IP(比如：219.237.60.1)發(fā)送一個UDP包猫缭，那么就在這個內網的NAT設備上打了一個方向為219.237.60.1的“洞”，（這就是稱為UDP HolePunching的技術）以后219.237.60.1就可以通過這個洞與內網的192.168.0.10聯(lián)系了壹店。（但是其他的IP不能利用這個洞）猜丹。
呵呵，現(xiàn)在該輪到我們的正題P2P了硅卢。有了上面的理論射窒，實現(xiàn)兩個內網的主機通訊就差最后一步了：兩邊都無法主動發(fā)出連接請求，誰也不知道誰的公網地址老赤，那我們如何來打這個洞呢轮洋？我們需要一個中間人來聯(lián)系這兩個內網主機制市。
現(xiàn)在我們來看看一個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此時想直接發(fā)送信息給Client B恤溶，那么他可以從ServerS那兒獲得B的公網地址187.34.1.56:40000，是不是Client A向這個地址發(fā)送信息ClientB就能收到了呢帜羊？答案是不行咒程，因為如果這樣發(fā)送信息，NATB會將這個信息丟棄（因為這樣的信息是不請自來的讼育，為了安全帐姻，大多數(shù)NAT都會執(zhí)行丟棄動作）稠集。那該怎么辦呢？ 首先我們假設Server S是219.237.60.1：7000饥瓷，當Clinet A（202.187.45.3：60000）向Server S（219.237.60.1：7000）發(fā)送數(shù)據(jù)包剥纷，Server S是可以正常接收到數(shù)據(jù)，因為它是屬于外型開放的服務器端口呢铆。當Server S收到數(shù)據(jù)包后可以獲知Clinet A（202.187.45.3：60000）對外通信的臨時session信息（這個叫臨時的端口筷畦，假設是60000會過期，具體時間不同刺洒，一般是每30S發(fā)送一個keep住連接以保證端口維持通信連接不斷）Server S此時應將次信息保存起來鳖宾。而同時，Client B (192.168.0.10:40000)也在時刻向
Server S發(fā)送心跳包逆航，Server S就向Client B (192.168.0.10:40000)發(fā)送一個通知鼎文，讓Client B (192.168.0.10:4000) 發(fā)送探測包（這個數(shù)據(jù)包最好發(fā)幾個），Client B (192.168.0.10:4000)在收到通知后在向Server S發(fā)送反饋包因俐，說明以向自己以向Client A (192.168.0.20:60000)發(fā)送了探測包拇惋，Server S在收到反饋之后再向Client A (192.168.0.20:60000)轉發(fā)反饋包，Client A (192.168.0.20:60000)在收到數(shù)據(jù)包之后在向原本要求請求的Client B (192.168.0.10:4000)發(fā)送數(shù)據(jù)包抹剩，此時連接已經打通撑帖，實現(xiàn)穿透。Client B (192.168.0.10:4000)會將數(shù)據(jù)包轉發(fā)給
Client A (192.168.0.20:60000)從而在轉發(fā)給內網內網IP:192.168.0.1澳眷。
對于Symmetric NAPT的情況胡嘿，網上有人說可以通過探測端口的方式，不過成功率并不高钳踊，我建議可用服務器進行中轉衷敌。另外，最好在數(shù)據(jù)包發(fā)送前先檢測是否進行的是同個NAT的情況拓瞪，也就是內網發(fā)內網缴罗，如果是，直接發(fā)送即可祭埂，而無需通過外網再繞回來面氓。
