1、引言
溝通是人類的最基本需求，復雜多變的溝通內容、溝通方式，正是人類文明之所以如此璀璨的關鍵所在。
在自然界中，要完成一件事情的溝通，我們可以直接通過聲音傳遞給對方，這是再平常不過的事了（靠“吼”就能解決）。
隨著計算機的普及，互聯網改變了我們的生活，甚至改變了我們的溝通方式。現在，“有什么事微信或QQ上找我”已經是很多的人口頭禪了。
那么，作為不懂技術的普通人，有沒有想過，你每次使用QQ或微這種IM聊天應用時，你所發送的消息，是如何被計算機送達給對方的？（這顯然不可能靠“吼”解決 ^_^）
本文將從非技術人員的視角，為你講解一下IM聊天應用中的聊天消息是怎么發送的。
學習交流：
- 即時通訊/推送技術開發交流4群：101279154[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-2433-1-1.html）
2、關于作者
鞏鵬軍：專注移動開發十多年，熱愛即時通訊技術。個人微信公眾號：“鞏鵬軍”。
3、閱讀對象
本文適合非技術背景的讀者閱讀，如您喜歡本文，則下列文章您也可能喜歡：
《技術往事：微信估值已超5千億，雷軍曾有機會收編張小龍及其Foxmail》
《QQ和微信兇猛成長的背后：騰訊網絡基礎架構的這些年》
《閑話即時通訊：騰訊的成長史本質就是一部QQ成長史》
《騰訊開發微信花了多少錢？技術難度真這么大？難在哪？》
《技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》
《開發往事：深度講述2010到2015，微信一路風雨的背后》
《開發往事：記錄微信3.0版背后的故事（距微信1.0發布9個月時）》
《微信七年回顧：歷經多少質疑和差評，才配擁有今天的強大》
《前創始團隊成員分享：盤點微信的前世今生——微信成功的必然和偶然》
《QQ的成功，遠沒有你想象的那么順利和輕松》
《[技術腦洞] 如果把14億中國人拉到一個微信群里技術上能實現嗎？》
《QQ和微信止步不前，意味著即時通訊社交應用創業的第2春已來？》
《那些年微信開發過的雞肋功能，及其帶給我們的思考》
《為什么說即時通訊社交APP創業就是一個坑？》
《即時通訊創業必讀：解密微信的產品定位、創新思維、設計法則等》
《老羅最新發布了“子彈短信”這款IM，主打熟人社交能否對標微信？》
《盤點和反思在微信的陰影下艱難求生的移動端IM應用》
《QQ現狀深度剖析：你還認為QQ已經被微信打敗了嗎？
《那些年微信開發過的雞肋功能，及其帶給我們的思考》
《漸行漸遠的人人網：十年親歷者的互聯網社交產品復盤和反思》
《中國互聯網社交二十年：全民見證的互聯網創業演義》
《IM熱門功能討論：為什么微信里沒有消息“已讀”功能？》
《讀懂微信：從1.0到7.0版本，一個主流IM社交工具的進化史》
《王欣回應微信封禁，解釋為何取名“馬桶MT”》
《同為IM社交產品中的王者，QQ與微信到底有什么區別》
《還原真實的騰訊：從最不被看好，到即時通訊巨頭的草根創業史》
如果您是專業技術人員，則跟本文相關的專業技術知識等，可以以下文章中找到：
《從客戶端的角度來談談移動端IM的消息可靠性和送達機制》
《移動端IM中大規模群消息的推送如何保證效率、實時性？》
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”？》
《IM群聊消息如此復雜，如何保證不丟不重？》
《完全自已開發的IM該如何設計“失敗重試”機制？》
好了，費話不多說，我們開始正文部分。。。
4、在微信里，我們發送一條聊天消息是如此簡單
李雷在手機上打開微信（IM客戶端），在聊天輸框中輸入“Hello!”，點擊發送。幾乎是瞬間，韓梅梅手機上的微信（IM客戶端）就會顯示李雷的頭像后面跟著“Hello!”。
整個過程如下圖所示：
從上面的圖示可以看到，整個過程涉及三大部分：
1）李雷手機上的IM客戶端（微信）；
2）IM服務端；
3）韓梅梅手機上的IM客戶端（微信）。
下面，我們逐一介紹每個部分的具體工作原理。
5、消息發送者：發送端是怎么工作的？
先看看發送端，李雷手機上的IM客戶端中發生了什么？
從上圖可以看出，發送一條信息經過三個步驟：
1）消息編輯：
李雷操作鍵盤輸入要發送的文字，點擊“發送”按鈕。這一切都發生在IM客戶端的界面模塊中。類似用筆在信紙上寫信，鍵盤就是筆，聊天框就是信紙；
2）消息入庫：
IM客戶端中的數據模塊會先將聊天內容“Hello!”加上誰發給誰等信息，按標準格式打包為一條IM消息，并存入本地數據庫。這類似信紙裝入信封，填寫地址，投入郵箱的過程。一條IM消息就是一封信，本地數據庫就是李雷家的郵箱；
3）消息發送：
IM客戶端中的網絡模塊通過長連接將IM消息發給IM服務端。這類似郵遞員將信件匯總發往郵政局。網絡模塊就是郵遞員，IM服務端就是郵政局。（長連接是IM客戶端跟IM服務端一直保持的網絡鏈路）。
6、消息“中轉站”：IM服務端是怎么工作的？
擔負“郵政局”職責的IM服務端是IM世界中全知全能的神，它認識所有人，經手所有消息，跟每個人都一直保持聯系（長連接）。
每條消息在IM服務端中都要至少經過以下處理：
1）消息接收：
長連接服務從和李雷的長連接接收到“Hello!”的IM消息。IM服務端跟所有登錄的IM客戶端保持長連接（一條一直活躍的網絡鏈路，每個客戶端一條），長連接上定時會有心跳消息來監測客戶端的在線離線狀態，心跳消息就像郵遞員每天都會在郵政局和郵箱之間巡回一樣；
2）消息驗證：
用戶服務查詢IM消息的目標人韓梅梅，以及發送人李雷和目標人韓梅梅是否好友關系，確保韓梅梅是真實存在而非虛構的，并且韓梅梅愿意接收李雷的消息，否則會給李雷退信。（一般IM服務端會將IM消息的副本存入數據庫中備份）；
3）消息轉發：
在長連接服務中找到跟韓梅梅手機上IM客戶端保持的長連接，并將消息發送給韓梅梅。
7、消息接收者：接收端又是怎么工作的呢？
下面看看韓梅梅手機上發生了什么？
韓梅梅手機上的IM客戶端和李雷（發送者）的是一樣的，但處理步驟是不同的：
1）消息接收：
網絡模塊通過跟IM服務端保持的長連接接收IM消息；
2）消息入庫：
網絡模塊會將IM消息存入本地數據庫，即信件投入了韓梅梅家的郵箱。網絡模塊就是郵遞員，本地數據庫就是韓梅梅家的郵箱；
3）消息展示：
界面模塊獲取發送人頭像，和消息內容一起顯示在聊天界面上。
經過上述過程，韓梅梅在自己手機上就看到了李雷發過來的“Hello!”，因為李雷和韓梅梅都是一直和服務器保持長連接，所以上述過程是瞬間完成的，李雷和韓梅梅感覺就像面對面聊天一樣方便。這也是Instant Messaging名字的來歷。
（本文同步發布于：http://www.52im.net/thread-2433-1-1.html）