IM即時通信實現原理 （轉）

即時通信（Instant  Messenger，簡稱IM）軟件可能是基於TCP/IP和UDP進行通信的，TCP/IP和UDP都是創建在更低層的IP協議上的兩種通信傳輸協議。前 者是以數據流的形式，將傳輸數據經分割、打包後，經過兩臺機器之間創建起的虛電路，進行連續的、雙向的、嚴格保證數據正確性的文件傳輸協議。然後者是以數 據報的形式，對拆分後的數據的前後到達順序不作要求的文件傳輸協議。

QQ就是使用UDP協議進行發送和接收消息的。當你的機器安裝了OICQ之後，實際上，你既是服務端（Server），又是客戶端（Client）。當你登陸OICQ時，你的OICQ做爲Client鏈接到騰訊公司的主服務器上，當你看誰在線時，你的OICQ又一次做爲Client從QQ  Server上讀取在線網友名單。當你和你的OICQ夥伴進行聊天時，若是你和對方的鏈接比較穩定，你和他的聊天內容都是以UDP的形式，在計算機之間傳 送。若是你和對方的鏈接不是很穩定，QQ服務器將爲大家的聊天內容進行中轉。其餘的即時通訊軟件原理與此大同小異。

 

通常的步驟：

 

首先，用戶A輸入本身的用戶名和密碼登陸即時通信服務器，服務器經過讀取用戶數據庫來驗證用戶身份，若是用戶名、密碼都正確，就登記用戶A的IP地址、IM客戶端軟件的版本號及使用的TCP/UDP端口號， 而後返回用戶A登陸成功的標誌，此時用戶A在 IM系統中的狀態爲在線（Online Presence）。

 

其次，根據用戶A存儲在IM服務器上的好友列表 （Buddy List），服務器將用戶A在線的相關信息發送到也同時在線的即時通信好友的PC機，這些信息包括在線狀態、IP地址、  IM客戶端使用的TCP端口（Port）號等，即時通信好友PC機上的即時通信軟件收到此信息後將在PC桌面上彈出一個小窗口予以提示。

 

第三步，即時通信服務器把用戶A存儲在服務器上的好友列 表及相關信息回送到他的PC機，這些信息包括也在線狀態、IP地址、IM客戶端使用的TCP端口（Port）號等信息，用戶A的PC機上的IM客戶端收到 後將顯示這些好友列表及其在線狀態。

 

接下來，若是用戶A想與他的在線好友用戶B聊天，他將直接經過服務器發送過來的用戶B的IP地址、TCP端口號等信息，直接向用戶B的PC機發出聊天信息，用戶B的IM客戶端軟件收到後顯示在屏幕上，而後用戶B再直接回復到用戶A的PC機，這樣雙方的即時文字消息就不經過 IM服務器中轉，而是經過網絡進行點對點的直接通信，這稱爲對等通信方式（Peer  To Peer） 。在商用即時通信系統中，若是用戶A與用戶B的點對點通信因爲防火牆、網絡速度等緣由難以創建或者速度很慢，  IM服務器還提供消息中轉服務，即用戶A和用戶B的即時消息所有先發送到IM服務器，再由服務器轉發給對方。早期的IM系統，在IM客戶端和IM服務器之間通信採用採用UDP協議，UDP協議是不可靠的傳輸協議，而在  IM客戶端之間的直接通信中，採用具有可靠傳輸能力的TCP協議。隨着用戶需求和技術環境的發展，目前主流的即時通信系統傾向於在即時通信客戶端之間、即時通信客戶端和即時通信服務器之間都採用TCP協議 。

 

S——C1             |             | C1每次想和C2通訊，先向S遞一個申請，而後S贊成，把信息轉交C2,　 之後每次通訊都這樣 C2

 

S——C1             |             | C1第一次想和C2通訊，向S遞一個申請，S贊成，告訴C1,C2,而後 C1和 C2之間創建了一條鏈接，能夠直接通訊，無需通過S.             C2

 

第 一種，對服務器的性能要求比較高，要求服務器能夠同時處理很高的鏈接數，由於全部信息都要經過服務器進行傳遞，同時，它能夠對所傳遞的信息進行控制。

 

第二種，僅僅是用戶登錄或下線時與服務器進行鏈接，平時進行通訊時，是用戶之間直接進行點對點的鏈接，這種實現更合理一 些。

 

 

QQ聊天信息是在兩個用戶間直接通訊的,而MSN要通過服務器中轉.

QQ當用戶登錄時，用戶須要首先與qq服務器進行鏈接進行登陸，服務器會向客戶返回一些信息，好比你的好有的在線狀況以及ip的信息，而後客戶能夠與你所請求的朋友進行點對點鏈接，二者互相通訊。

            那 若是 c1和c2都在私網內，要經過路由器作NAT才能出去的話，他們之間的socket是如何創建的呢？             看一下下面的協議.

Simple Traversal of User  Datagram Protocol (UDP) Through Network             Address Translators (NATs) (STUN)。

STUN，是爲了實現透明的穿透NAT，而定義的一套協 議。他使本地的內網的機器，具備取得，可以得知他的NAT網關的IP，NAT類型的能力。

爲何須要STUN：

由於NAT雖然解決了IP地址稀少的問題，可是也帶來了不少的問題。好比全部P2P應用，像文件SHARE，多媒體，和在線遊戲等等. 爲了解決這個問題，有人將 Application Layer Gateways (ALGs) 放到了NAT中， ALGs 也有嚴重的問題，好比跟不上速度太塊的CLIENT，每個應用都須要單獨的實現。             跟不上應用的發展。             爲了克服ALGS的問題，又提出了the Middlebox Communications (MIDCOM)  protocol 中間合協議。但是MIDBOX協議使 ，一些CLIENT能夠控制NAT/防火牆的行爲，經過這個             把應用協議和NAT部分分開，把ALGS從基本NAT裏面處理開。不過由於要處理MIDBOX，那麼             全部的NAT或者防火牆都要升級，

由於上面種種緣由： The protocol described here, Simple Traversal of UDP Through NAT             (STUN), allows entities behind a NAT to first discover the  presence             of a NAT and the type of NAT, and then to learn the  addresses             bindings allocated by the NAT. STUN requires no changes to  NATs, and             works with an arbitrary(任意) number of NATs in tandem between the             application entity and the public Internet.

要想穿透NAT，首先知道NAT的一些特性： NAT分爲4種（加上防火牆的話，多幾種狀況）： 1.徹底透明NAT(Full Cone NAT): 從相同內部主機(IN IPX) +端口(IN PORTX)發送的數據MAPING爲相同的IP(OUT IP  X)和端口(OUT PORT X)發送帶外網. 而且 從另外一個服務器(Y)，若是直連到MAPING的IP(OUT IP X)和端口(OUT PORT X  )上，數據將會被轉發到內部主機上. (IN IPX), (IN PORTX).             //也就是說進內部網的數據包的SPORT，SPORT不受限制 2．受限NAT(Restricted Cone), 從相同內部主機IN IPX) +端口((IN PORTX))發送的數據MAPING爲相同的IP（X）和端口發送帶外網. 和徹底NAT不一樣的是，只有當爲X時，外部機器的的請求就被轉發到主機IN IPX) +端口((IN PORTX)。             也就是說進內部網的數據包的，SPORT不受限制，SIP受限制，只能爲NAT MAP數據的IP             3，端口受限NAT(Port Restricted Cone:) 和受限NAT不一樣的是，只有當外部主動請求的的源IP和端口，等於內部網發送的請求的目的IP和端口。 4．對稱NAT(Symmetric) 若是發送的包的目的IP AND PORT，那麼MAPPING IP AND PORT，將相同。             內部網同一臺機器，同一個端口 若是目的地址不一樣，那麼MAPPING的端口也不一樣，             因此只有他主動連的服務器纔可能知道他的MAPPING後端口，別的服務器若是想             連他只能靠猜想端口。             總結：             前面3重NAT，MAPING PORT 和 IP，是根據發送包的的內部網的IP和端口決定的。             若是數據的內網IP和端口相同，那麼MAPPING後的端口和地址是固定。             這個功能爲咱們的穿越提供了很好條件。             第4種NAT，打洞後的MAPPING 地址和端口將變地不可靠。很難穿越。             注意SERVERA，和SERVERB是兩個公網地址，而不是兩臺機器，

STUN 的簡單操做過程：             發送請求。請求分爲兩種 1． Binding Requests, sent over UDP, 用來發現是否NAT，用來發現NAT的公網地址，和MAPPING後的端口 2.Binding Response, 服務器產生Binding Response，並把獲得的MAPPINGIP 和端口，返回到客戶端，  客戶端比較MAPPING地址是否 和本機地址相同，若是是說明是本機也是公網，不然判斷NAT的類型(判斷方法：client uses additional STUN Binding Requests)             3.Binding Error， 4.Shared Secret Requests, sent over TLS [2] over TCP. 這個請求要求服務器返回一臨時用戶名和密碼，用來下一步的Binding Requests/  Response,用來驗證信息的完整性 5.Shared Secret Response,             6 Shared Secret Error Response。 STUN 信息結構 STUN 由之後數據結構構成：STUN頭+STUN有效載荷 STUN頭結構以下： 存儲的值都是以網絡順序存放             字段類型 STUN message type Short int 消息類型 Length Short int 有效載荷長度,不包含頭長度 transaction ID octet[16] 鏈接的ID值，檢查Request, 和Response

STUN的有效載荷 SHUN的有效載荷 是一些STUN的屬性構成，屬性的類型由信息的類型來決定。 STUN的屬性是定義好了的，屬性列表（attribute）以下： MAPPED-ADDRESS 必選 用在Binding Response，（添入MAPING IP 和PORT） RESPONSEADDRESS 可選 用在Binding Request,指定Response,發送到哪裏             若是沒有指定，Response發送到MAPING IP 和 PORT             CHANGE-REQUEST 可選 用在Binding  Request。用來決定，CLIENT的NAT類型是限制NAT，仍是端口限制NAT，（命令服務器從不一樣的源端口/IP，Response請求） CHANGED-ADDRESS 可選 用在Binding Responses告訴Client改變的端口和IP             SOURCE-ADDRESS 必選 只用在Binding Responses，標記信息的源PORT HE IP             USERNAME 可選 Shared Secret Response/ Binding Requests             PASSWORD, 必選 SharedSecret Response             ESSAGEINTEGRITY 可選 用在Binding Responses, Binding  Request記錄信息的完整性 ERROR-CODE Binding Error Response and Shared Secret Error  Response.             UNKNOWN-ATTRIBUTES             REFLECTED-FROM Binding Responses.用於追溯和防止DDOS

穿透的方法和過程             注意SERVER1，和SERVER2是兩個公網地址，而不是兩臺機器.

 

附錄:

1、IM技術概念

IM技術全稱Instant  Messaging，中文翻譯「即時通信」，它是一種令人們能在網上識別在線用戶並與他們實時交換消息的技術，是電子郵件發明以來迅速崛起的在線通信方 式。

IM的出現和互聯網有着密不可分的關係，IM徹底基於 TCP/IP網絡協議族實現，而TCP/IP協議族則是整個互聯網得以實現的技術基礎。 最先出現即時通信協議是IRC（Internet Relay  Chat），可是惋惜的是它僅能單純的使用文字、符號的方式經過互聯網進行交談和溝通。隨着互連網變得高度發達，即時通信也變得遠不止聊天這麼簡單，自 1996年第一個IM產品ICQ發明後，IM的技術和功能也開始基本成型，語音、視頻、文件共享、短信發送等高級信息交換功能均可以在IM工具上實現，於 是功能強大的IM軟件便足以搭建一個完整的通訊交流平臺。目前最具表明性的幾款的IM通信軟件有MSN、Google  Talk、Yahoo、Messenger 、騰訊QQ等。

 

2、IM技術原理和工做方式

典型的IM工做方式以下：登錄IM通信中心（IM通信服務器），獲取一個自創建的歷史的交流對象列表（好友列表），而後自身標誌爲在線狀態，當好友列表中的某人在任什麼時候候登陸上線並試圖經過你的計算機聯繫你 時，IM系統會發一個消息提醒你，而後你能與他創建一個聊天會話通道進行各類消息如鍵入文字、經過語音等的交流.

從技術上來講，IM的基本技術原理以下：

經過IM服務器登錄或註銷             用戶A經過列表找到B，用戶B得到消息並與之交談             經過IM服務器指引創建與B單獨的通信通道

 

第一步，用戶A輸入本身的用戶名和密碼登陸IM服務器， 服務器經過讀取用戶數據庫來驗證用戶身份，若是驗證經過，登記用戶A的IP地址、IM客戶端軟件的版本號及使用的TCP/UDP端口號，而後返回用戶A登陸成功的標誌，此時用戶A在IM系統中的狀態爲在線（Online Presence）。

 

第二步，根據用戶A存儲在IM服務器上的好友列表 （Buddy  List），服務器將用戶A在線的相關信息發送給也同時在線的IM好友的PC機，這些信息包括在線狀態、IP地址、IM客戶端使用的TCP端口 （Port）號等，IM好友的客戶端收到此信息後將在予以提示。

 

第三步是IM服務器把用戶A存儲在服務器上的好友列表及 相關信息回送到他的客戶端機，這些信息包括也在線狀態、IP地址、IM客戶端使用的TCP端口（Port）號等信息，用戶A的IM客戶端收到後將顯示這些好友列表及其在線狀態。

 

3、IM通信方式

1.在線直接通信              若是用戶A想與他的在線好友用戶B聊天，他將直接經過服務器發送過來的用戶B的IP地址、TCP端口號等信息，直接向用戶B的PC機發出聊天信息，用戶B 的IM客戶端軟件收到後顯示在屏幕上，而後用戶B再直接回復到用戶A的PC機，這樣雙方的即時文字消息就再也不IM服務器中轉，而是直接經過網絡進行點對點 的通信，即對等通信方式（Peer To Peer）。

2.在線代理通信              用戶A與用戶B的點對點通信因爲防火牆、網絡速度等緣由難以創建或者速度很慢，IM服務器將會主動提供消息中轉服務，即用戶A和用戶B的即時消息所有先發 送到IM服務器，再由服務器轉發給對方。

3.離線代理通信              用戶A與用戶B因爲各類緣由不能同時在線的時候，如此時A向B發送消息，IM服務器能夠主動寄存A用戶的消息，到B用戶下一次登錄的時候，自動將消息轉發 給B。

4.擴展方式通信              用戶A能夠經過IM服務器將信息以擴展的方式傳遞給B，如短信發送方式發送到B的手機，傳真發送方式傳遞給B的電話機，以email的方式傳遞給B的電子郵箱等。

             早期的IM系統，在IM客戶端和IM服務器之間通信採用UDP協議，UDP協議是不可靠的傳輸協議，而在IM客戶端之間的直接通信中，採用具有可靠傳輸能 力的TCP協議。隨着用戶需求和技術環境的發展，目前主流的IM系統傾向於在IM客戶端之間、IM客戶端和IM服務器之間都採用TCP協議。

             即時通信相對於其餘通信方式如電話、傳真、email等的最大優點就是消息傳達的即時性和精確性，只要消息傳遞雙方均在網絡上能夠互通，使用即時通信軟件傳遞消息，傳遞延時僅爲1秒種.

 

4、興起的嵌入式IM工具。

傳統的IM在統治了互聯網即時通信領域長達十年之久，以其日趨穩定的定能，與較強的用戶黏着度，至今仍統治着這個巨大的市場。然而，軟件行業的技術精英們，並不知足於此。他們厚積薄發，一直致力於開發出性能更 爲優越的即時通信工具。固然，在功能上的不斷完善，天然是一個必然的發展方向，在Web2.0時代，如何大力加強用戶對網站的黏着度，而不只僅是對於IM 的擁附，已經成爲他們的主攻方向了。因而，嵌入式IM工具，應運而生了。

相對以往的傳統的即便溝通工具，它們須要用戶下載軟件包，須要用戶進行安裝。對於擁有IM產品的網站而言，用戶在登錄網站後，不能直接使用其IM工具，對於流量與用戶的黏着度，都是有必定影響的。所以在IM 與網站相互依存的今天，沒有哪家網絡公司，願意將IM工具孤立開來。

因而，目前，一種新型的嵌入式IM工具就應運而生了。這種IM工具，不須要下載安裝，當用戶登錄網頁後，該IM直接嵌套在網頁中，能夠直接使用。

而在功能上，則一點也不輸於傳統的IM，不管是傳統的文字溝通的速度與效率，仍是近年來愈來愈成爲IM工具必備的音頻/視頻功能，這種嵌入式IM都能提供很是穩定的傳輸。更值得一提的是，由於嵌入式IM是嵌套 在網頁上的，軟件供應商，能夠根據網站需求，設計出適合網站風格的IM產品。而不是像傳統的IM工具，千篇一概，毫無個性可言。

目前，這類嵌入式IM在社區、交友、社團及協做等類型的 網站上，應用已經較爲普遍。在Web2.0時代，將發揮愈來愈重要的做用。