1、引言
說道“心跳”這個詞大家都不陌生,當然不是指男女之間的心跳,而是和長連接相關(guān)的。顧名思義就是證明是否還活著的依據(jù)。
什么場景下需要心跳呢?目前我們接觸到的大多是一些基于長連接的應(yīng)用需要心跳來“保活”。
由于在長連接的場景下,客戶端和服務(wù)端并不是一直處于通信狀態(tài),如果雙方長期沒有溝通則雙方都不清楚對方目前的狀態(tài),所以需要發(fā)送一段很小的報文告訴對方“我還活著”。
同時還有另外幾個目的:
1)服務(wù)端檢測到某個客戶端遲遲沒有心跳過來可以主動關(guān)閉通道,讓它下線;
2)客戶端檢測到某個服務(wù)端遲遲沒有響應(yīng)心跳也能重連獲取一個新的連接。
本文正好借著在CIM系統(tǒng)中有這樣兩個需求(CIM是本文作者從零開發(fā)的一個學習性質(zhì)的IM系統(tǒng),詳見《拿起鍵盤就是干:跟我一起徒手開發(fā)一套分布式IM系統(tǒng)》),正好來聊一聊我是如何理解IM長連接的心跳及重連機制,以及又是怎么踩坑已及填坑的。
本文配套的CIM源碼地址:
閱讀本文需要一定的網(wǎng)絡(luò)編程以及Netty方面的知識。
有關(guān)網(wǎng)絡(luò)編程基礎(chǔ)知識,請閱讀以下資料:
《TCP/IP詳解 - 第11章·UDP:用戶數(shù)據(jù)報協(xié)議》
《TCP/IP詳解 - 第17章·TCP:傳輸控制協(xié)議》
《通俗易懂-深入理解TCP協(xié)議(上):理論基礎(chǔ)》(推薦)
有關(guān)Netty框架方面的知識,請閱讀以下資料:
《Netty源碼在線閱讀版》(推薦)
《Netty API文檔在線版》(推薦)
《新手入門:目前為止最透徹的的Netty高性能原理和框架架構(gòu)解析》
《寫給初學者:Java高性能NIO框架Netty的學習方法和進階策略》
學習交流:
- 即時通訊/推送技術(shù)開發(fā)交流5群:215477170[推薦]
- 移動端IM開發(fā)入門文章:《新手入門一篇就夠:從零開發(fā)移動端IM》
(本文同步發(fā)布于:http://www.52im.net/thread-2799-1-1.html)
2、關(guān)于作者
crossoverJie(陳杰): 90后,畢業(yè)于重慶信息工程學院,現(xiàn)供職于重慶豬八戒網(wǎng)絡(luò)有限公司。
作者的博客:https://crossoverjie.top
作者的Github:https://github.com/crossoverJie
本文作者的其它文章:
《拿起鍵盤就是干:跟我一起徒手開發(fā)一套分布式IM系統(tǒng)》
《技術(shù)干貨:從零開始,教你設(shè)計一個百萬級的消息推送系統(tǒng)》
3、相關(guān)文章
? 有關(guān)網(wǎng)絡(luò)心跳保活方面的理論文章:
《為何基于TCP協(xié)議的移動端IM仍然需要心跳保活機制?》
《微信團隊原創(chuàng)分享:Android版微信后臺保活實戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》
《移動端IM實踐:實現(xiàn)Android版微信的智能心跳機制》
《移動端IM實踐:WhatsApp、Line、微信的心跳策略分析》
? 有關(guān)網(wǎng)絡(luò)心跳保活方面的實踐文章:
《MobileIMSDK——一套開源的原創(chuàng)移動端即時通訊框架(有完整的心跳保活邏輯和代碼實現(xiàn))》
《一種Android端IM智能心跳算法的設(shè)計與實現(xiàn)探討(含樣例代碼)》
《手把手教你用Netty實現(xiàn)網(wǎng)絡(luò)通信程序的心跳機制、斷線重連機制》
《適合新手:從零開發(fā)一個IM服務(wù)端(基于Netty,有完整源碼)》
4、心跳實現(xiàn)方式
心跳其實有兩種實現(xiàn)方式:
1)TCP 協(xié)議實現(xiàn)(keepalive 機制,詳見《TCP/IP詳解 卷1:協(xié)議-第23章 TCP的保活定時器》);
2)應(yīng)用層自己實現(xiàn)。
由于 TCP 協(xié)議過于底層,對于開發(fā)者來說維護性、靈活度都比較差同時還依賴于操作系統(tǒng)(詳見:《為何基于TCP協(xié)議的移動端IM仍然需要心跳保活機制?》)。
所以我們這里所討論的都是應(yīng)用層的實現(xiàn):
如上圖所示,在應(yīng)用層通常是由客戶端發(fā)送一個心跳包 ping 到服務(wù)端,服務(wù)端收到后響應(yīng)一個 pong 表明雙方都活得好好的。一旦其中一端延遲 N 個時間窗口沒有收到消息則進行不同的處理。
5、客戶端自動重連
先拿客戶端來說吧,每隔一段時間客戶端向服務(wù)端發(fā)送一個心跳包,同時收到服務(wù)端的響應(yīng)。
常規(guī)的實現(xiàn)應(yīng)當是:
1)開啟一個定時任務(wù),定期發(fā)送心跳包;
2)收到服務(wù)端響應(yīng)后更新本地時間;
3)再有一個定時任務(wù)定期檢測這個“本地時間”是否超過閾值;
4)超過后則認為服務(wù)端出現(xiàn)故障,需要重連。
這樣確實也能實現(xiàn)心跳,但并不友好。
在正常的客戶端和服務(wù)端通信的情況下,定時任務(wù)依然會發(fā)送心跳包;這樣就顯得沒有意義,有些多余。所以理想的情況應(yīng)當是客戶端收到的寫消息空閑時才發(fā)送這個心跳包去確認服務(wù)端是否健在。
好消息是 Netty 已經(jīng)為我們考慮到了這點,自帶了一個開箱即用的 IdleStateHandler 專門用于心跳處理。
來看看 cim 中的實現(xiàn):
在 pipeline 中加入了一個 10秒沒有收到寫消息的 IdleStateHandler,到時他會回調(diào) ChannelInboundHandler 中的 userEventTriggered 方法。
所以一旦寫超時就立馬向服務(wù)端發(fā)送一個心跳(做的更完善應(yīng)當在心跳發(fā)送失敗后有一定的重試次數(shù))。
這樣也就只有在空閑時候才會發(fā)送心跳包。但一旦間隔許久沒有收到服務(wù)端響應(yīng)進行重連的邏輯應(yīng)當寫在哪里呢?
先來看這個示例:
當收到服務(wù)端響應(yīng)的 pong 消息時,就在當前 Channel 上記錄一個時間,也就是說后續(xù)可以在定時任務(wù)中取出這個時間和當前時間的差額來判斷是否超過閾值。
超過則重連。
同時在每次心跳時候都用當前時間和之前服務(wù)端響應(yīng)綁定到 Channel 上的時間相減判斷是否需要重連即可。
也就是 heartBeatHandler.process(ctx); 的執(zhí)行邏輯。
偽代碼如下:
@Override
public void process(ChannelHandlerContext ctx) throws Exception {
longheartBeatTime = appConfiguration.getHeartBeatTime() * 1000;
Long lastReadTime = NettyAttrUtil.getReaderTime(ctx.channel());
longnow = System.currentTimeMillis();
if(lastReadTime != null&& now - lastReadTime > heartBeatTime){
reconnect();
}
}
6、IdleStateHandler 誤區(qū)
一切看起來也沒毛病,但實際上卻沒有這樣實現(xiàn)重連邏輯。最主要的問題還是對 IdleStateHandler 理解有誤。
我們假設(shè)下面的場景:
1)客戶端通過登錄連上了服務(wù)端并保持長連接,一切正常的情況下雙方各發(fā)心跳包保持連接;
2)這時服務(wù)端突入出現(xiàn) down 機,那么理想情況下應(yīng)當是客戶端遲遲沒有收到服務(wù)端的響應(yīng)從而 userEventTriggered 執(zhí)行定時任務(wù);
3)判斷當前時間 - UpdateWriteTime > 閾值 時進行重連。
但卻事與愿違,并不會執(zhí)行 2、3兩步。
因為一旦服務(wù)端 down 機、或者是與客戶端的網(wǎng)絡(luò)斷開則會回調(diào)客戶端的 channelInactive 事件。
IdleStateHandler 作為一個 ChannelInbound 也重寫了 channelInactive() 方法。
這里的 destroy() 方法會把之前開啟的定時任務(wù)都給取消掉。所以就不會再有任何的定時任務(wù)執(zhí)行了,也就不會有機會執(zhí)行這個重連業(yè)務(wù)。
7、靠譜實現(xiàn)
因此我們得有一個單獨的線程來判斷是否需要重連,不依賴于 IdleStateHandler。
于是 cim 在客戶端感知到網(wǎng)絡(luò)斷開時就會開啟一個定時任務(wù):
之所以不在客戶端啟動就開啟,是為了節(jié)省一點線程消耗。網(wǎng)絡(luò)問題雖然不可避免,但在需要的時候開啟更能節(jié)省資源。
在這個任務(wù)重其實就是執(zhí)行了重連,限于篇幅具體代碼就不貼了,感興趣的可以自行查閱。
同時來驗證一下效果:
啟動兩個服務(wù)端,再啟動客戶端連接上一臺并保持長連接。這時突然手動關(guān)閉一臺服務(wù),客戶端可以自動重連到可用的那臺服務(wù)節(jié)點。
啟動客戶端后服務(wù)端也能收到正常的 ping 消息:
利用 :info 命令查看當前客戶端的鏈接狀態(tài)發(fā)現(xiàn)連的是 9000端口。
:info 是一個新增命令,可以查看一些客戶端信息。
這時我關(guān)掉連接上的這臺節(jié)點:
1kill-9 2142
這時客戶端會自動重連到可用的那臺節(jié)點。這個節(jié)點也收到了上線日志以及心跳包。
8、服務(wù)端自動剔除離線客戶端
現(xiàn)在來看看服務(wù)端,它要實現(xiàn)的效果就是延遲 N 秒沒有收到客戶端的 ping 包則認為客戶端下線了,在 cim 的場景下就需要把他踢掉置于離線狀態(tài)。
有關(guān)消息發(fā)送誤區(qū):
這里依然有一個誤區(qū),在調(diào)用 ctx.writeAndFlush() 發(fā)送消息獲取回調(diào)時。
其中是 isSuccess 并不能作為消息發(fā)送成功與否的標準:
也就是說即便是客戶端直接斷網(wǎng),服務(wù)端這里發(fā)送消息后拿到的 success 依舊是 true。這是因為這里的 success 只是告知我們消息寫入了 TCP 緩沖區(qū)成功了而已。
和我之前有著一樣錯誤理解的不在少數(shù),這是 Netty 官方給的回復(fù):
相關(guān) issue:https://github.com/netty/netty/issues/4915
所以我們不能依據(jù)此來關(guān)閉客戶端的連接,而是要像上文一樣判斷 Channel 上綁定的時間與當前時間只差是否超過了閾值。
以上則是 cim 服務(wù)端的實現(xiàn),邏輯和開頭說的一致,也和 Dubbo 的心跳機制有些類似。
于是來做個試驗:正常通信的客戶端和服務(wù)端,當我把客戶端直接斷網(wǎng)時,服務(wù)端會自動剔除客戶端。
9、本文小結(jié)
這樣就實現(xiàn)了文初的兩個要求:
1)服務(wù)端檢測到某個客戶端遲遲沒有心跳過來可以主動關(guān)閉通道,讓它下線;
2)客戶端檢測到某個服務(wù)端遲遲沒有響應(yīng)心跳也能重連獲取一個新的連接。
同時也踩了兩個誤區(qū),坑一個人踩就可以了,希望看過本文的都有所收獲避免踩坑。
本文所有相關(guān)代碼都在此處,感興趣的可以自行查看:
主要鏡像:https://github.com/crossoverJie/cim
備用鏡像:https://github.com/52im/cim
附錄:更多參考資料匯總
[1] IM代碼實踐(適合新手):
《自已開發(fā)IM有那么難嗎?手把手教你自擼一個Andriod版簡易IM (有源碼)》
《一種Android端IM智能心跳算法的設(shè)計與實現(xiàn)探討(含樣例代碼)》
《手把手教你用Netty實現(xiàn)網(wǎng)絡(luò)通信程序的心跳機制、斷線重連機制》
《微信本地數(shù)據(jù)庫破解版(含iOS、Android),僅供學習研究 [附件下載]》
《Java NIO基礎(chǔ)視頻教程、MINA視頻教程、Netty快速入門視頻 [有源碼]》
《輕量級即時通訊框架MobileIMSDK的iOS源碼(開源版)[附件下載]》
《開源IM工程“蘑菇街TeamTalk”2015年5月前未刪減版完整代碼 [附件下載]》
《微信本地數(shù)據(jù)庫破解版(含iOS、Android),僅供學習研究 [附件下載]》
《NIO框架入門(一):服務(wù)端基于Netty4的UDP雙向通信Demo演示 [附件下載]》
《NIO框架入門(二):服務(wù)端基于MINA2的UDP雙向通信Demo演示 [附件下載]》
《NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰(zhàn) [附件下載]》
《NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通信實戰(zhàn) [附件下載]》
《用于IM中圖片壓縮的Android工具類源碼,效果可媲美微信 [附件下載]》
《高仿Android版手機QQ可拖拽未讀數(shù)小氣泡源碼 [附件下載]》
《一個WebSocket實時聊天室Demo:基于node.js+socket.io [附件下載]》
《Android聊天界面源碼:實現(xiàn)了聊天氣泡、表情圖標(可翻頁) [附件下載]》
《高仿Android版手機QQ首頁側(cè)滑菜單源碼 [附件下載]》
《開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《分享java AMR音頻文件合并源碼,全網(wǎng)最全》
《微信團隊原創(chuàng)Android資源混淆工具:AndResGuard [有源碼]》
《一個基于MQTT通信協(xié)議的完整Android推送Demo [附件下載]》
《高仿手機QQ的Android版鎖屏聊天消息提醒功能 [附件下載]》
《高仿iOS版手機QQ錄音及振幅動畫完整實現(xiàn) [源碼下載]》
《Android端社交應(yīng)用中的評論和回復(fù)功能實戰(zhàn)分享[圖文+源碼]》
《Android端IM應(yīng)用中的@人功能實現(xiàn):仿微博、QQ、微信,零入侵、高可擴展[圖文+源碼]》
《仿微信的IM聊天時間顯示格式(含iOS/Android/Web實現(xiàn))[圖文+源碼]》
《Android版仿微信朋友圈圖片拖拽返回效果 [源碼下載]》
《適合新手:從零開發(fā)一個IM服務(wù)端(基于Netty,有完整源碼)》
《拿起鍵盤就是干:跟我一起徒手開發(fā)一套分布式IM系統(tǒng)》
《正確理解IM長連接的心跳及重連機制,并動手實現(xiàn)(有完整IM源碼)》
>> 更多同類文章 ……
[2] 網(wǎng)絡(luò)編程基礎(chǔ)資料:
《TCP/IP詳解 - 第11章·UDP:用戶數(shù)據(jù)報協(xié)議》
《TCP/IP詳解 - 第17章·TCP:傳輸控制協(xié)議》
《技術(shù)往事:改變世界的TCP/IP協(xié)議(珍貴多圖、手機慎點)》
《通俗易懂-深入理解TCP協(xié)議(上):理論基礎(chǔ)》
《通俗易懂-深入理解TCP協(xié)議(下):RTT、滑動窗口、擁塞處理》
《理論經(jīng)典:TCP協(xié)議的3次握手與4次揮手過程詳解》
《理論聯(lián)系實際:Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖(中文珍藏版)》
《P2P技術(shù)詳解(一):NAT詳解——詳細原理、P2P簡介》
《P2P技術(shù)詳解(二):P2P中的NAT穿越(打洞)方案詳解》
《P2P技術(shù)詳解(三):P2P技術(shù)之STUN、TURN、ICE詳解》
《通俗易懂:快速理解P2P技術(shù)中的NAT穿透原理》
《高性能網(wǎng)絡(luò)編程(一):單臺服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》
《高性能網(wǎng)絡(luò)編程(二):上一個10年,著名的C10K并發(fā)連接問題》
《高性能網(wǎng)絡(luò)編程(三):下一個10年,是時候考慮C10M并發(fā)問題了》
《高性能網(wǎng)絡(luò)編程(四):從C10K到C10M高性能網(wǎng)絡(luò)應(yīng)用的理論探索》
《高性能網(wǎng)絡(luò)編程(五):一文讀懂高性能網(wǎng)絡(luò)編程中的I/O模型》
《高性能網(wǎng)絡(luò)編程(六):一文讀懂高性能網(wǎng)絡(luò)編程中的線程模型》
《不為人知的網(wǎng)絡(luò)編程(一):淺析TCP協(xié)議中的疑難雜癥(上篇)》
《不為人知的網(wǎng)絡(luò)編程(二):淺析TCP協(xié)議中的疑難雜癥(下篇)》
《不為人知的網(wǎng)絡(luò)編程(三):關(guān)閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網(wǎng)絡(luò)編程(四):深入研究分析TCP的異常關(guān)閉》
《不為人知的網(wǎng)絡(luò)編程(五):UDP的連接性和負載均衡》
《不為人知的網(wǎng)絡(luò)編程(六):深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡(luò)編程(七):如何讓不可靠的UDP變的可靠?》
《不為人知的網(wǎng)絡(luò)編程(八):從數(shù)據(jù)傳輸層深度解密HTTP》
《不為人知的網(wǎng)絡(luò)編程(九):理論聯(lián)系實際,全方位深入理解DNS》
《網(wǎng)絡(luò)編程懶人入門(一):快速理解網(wǎng)絡(luò)通信協(xié)議(上篇)》
《網(wǎng)絡(luò)編程懶人入門(二):快速理解網(wǎng)絡(luò)通信協(xié)議(下篇)》
《網(wǎng)絡(luò)編程懶人入門(三):快速理解TCP協(xié)議一篇就夠》
《網(wǎng)絡(luò)編程懶人入門(四):快速理解TCP和UDP的差異》
《網(wǎng)絡(luò)編程懶人入門(五):快速理解為什么說UDP有時比TCP更有優(yōu)勢》
《網(wǎng)絡(luò)編程懶人入門(六):史上最通俗的集線器、交換機、路由器功能原理入門》
《網(wǎng)絡(luò)編程懶人入門(七):深入淺出,全面理解HTTP協(xié)議》
《網(wǎng)絡(luò)編程懶人入門(八):手把手教你寫基于TCP的Socket長連接》
《網(wǎng)絡(luò)編程懶人入門(九):通俗講解,有了IP地址,為何還要用MAC地址?》
《技術(shù)掃盲:新一代基于UDP的低延時網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》
《讓互聯(lián)網(wǎng)更快:新一代QUIC協(xié)議在騰訊的技術(shù)實踐分享》
《現(xiàn)代移動端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié):請求速度、弱網(wǎng)適應(yīng)、安全保障》
《聊聊iOS中網(wǎng)絡(luò)編程長連接的那些事》
《移動端IM開發(fā)者必讀(一):通俗易懂,理解移動網(wǎng)絡(luò)的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二):史上最全移動弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
《IPv6技術(shù)詳解:基本概念、應(yīng)用現(xiàn)狀、技術(shù)實踐(上篇)》
《IPv6技術(shù)詳解:基本概念、應(yīng)用現(xiàn)狀、技術(shù)實踐(下篇)》
《從HTTP/0.9到HTTP/2:一文讀懂HTTP協(xié)議的歷史演變和設(shè)計思路》
《腦殘式網(wǎng)絡(luò)編程入門(一):跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網(wǎng)絡(luò)編程入門(二):我們在讀寫Socket時,究竟在讀寫什么?》
《腦殘式網(wǎng)絡(luò)編程入門(三):HTTP協(xié)議必知必會的一些知識》
《腦殘式網(wǎng)絡(luò)編程入門(四):快速理解HTTP/2的服務(wù)器推送(Server Push)》
《腦殘式網(wǎng)絡(luò)編程入門(五):每天都在用的Ping命令,它到底是什么?》
《腦殘式網(wǎng)絡(luò)編程入門(六):什么是公網(wǎng)IP和內(nèi)網(wǎng)IP?NAT轉(zhuǎn)換又是什么鬼?》
《以網(wǎng)游服務(wù)端的網(wǎng)絡(luò)接入層設(shè)計為例,理解實時通信的技術(shù)挑戰(zhàn)》
《邁向高階:優(yōu)秀Android程序員必知必會的網(wǎng)絡(luò)基礎(chǔ)》
《全面了解移動端DNS域名劫持等雜癥:技術(shù)原理、問題根源、解決方案等》
《美圖App的移動端DNS優(yōu)化實踐:HTTPS請求耗時減小近半》
《Android程序員必知必會的網(wǎng)絡(luò)通信傳輸層協(xié)議——UDP和TCP》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(一):通信交換技術(shù)的百年發(fā)展史(上)》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(二):通信交換技術(shù)的百年發(fā)展史(下)》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(三):國人通信方式的百年變遷》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(四):手機的演進,史上最全移動終端發(fā)展史》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(五):1G到5G,30年移動通信技術(shù)演進史》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(六):移動終端的接頭人——“基站”技術(shù)》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(七):移動終端的千里馬——“電磁波”》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(八):零基礎(chǔ),史上最強“天線”原理掃盲》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(九):無線通信網(wǎng)絡(luò)的中樞——“核心網(wǎng)”》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十):零基礎(chǔ),史上最強5G技術(shù)掃盲》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十一):為什么WiFi信號差?一文即懂!》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十二):上網(wǎng)卡頓?網(wǎng)絡(luò)掉線?一文即懂!》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十三):為什么手機信號差?一文即懂!》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十四):高鐵上無線上網(wǎng)有多難?一文即懂!》
《IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十五):理解定位技術(shù),一篇就夠》
《百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(一):DNS優(yōu)化篇》
《百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(二):網(wǎng)絡(luò)連接優(yōu)化篇》
《百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(三):移動端弱網(wǎng)優(yōu)化篇》
《技術(shù)大牛陳碩的分享:由淺入深,網(wǎng)絡(luò)編程學習經(jīng)驗干貨總結(jié)》
《可能會搞砸你的面試:你知道一個TCP連接上能發(fā)起多少個HTTP請求嗎?》
《知乎技術(shù)分享:知乎千萬級并發(fā)的高性能長連接網(wǎng)關(guān)技術(shù)實踐》
>> 更多同類文章 ……
[3] NIO異步網(wǎng)絡(luò)編程資料:
《Java新一代網(wǎng)絡(luò)編程模型AIO原理及Linux系統(tǒng)AIO介紹》
《有關(guān)“為何選擇Netty”的11個疑問及解答》
《開源NIO框架八卦——到底是先有MINA還是先有Netty?》
《NIO框架入門(一):服務(wù)端基于Netty4的UDP雙向通信Demo演示》
《NIO框架入門(二):服務(wù)端基于MINA2的UDP雙向通信Demo演示》
《NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰(zhàn)》
《NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通信實戰(zhàn)》
《Netty 4.x學習(二):Channel和Pipeline詳解》
《Apache Mina框架高級篇(一):IoFilter詳解》
《Apache Mina框架高級篇(二):IoHandler詳解》
《Apache MINA2.0 開發(fā)指南(中文版)[附件下載]》
《MINA、Netty的源代碼(在線閱讀版)已整理發(fā)布》
《解決MINA數(shù)據(jù)傳輸中TCP的粘包、缺包問題(有源碼)》
《實踐總結(jié):Netty3.x升級Netty4.x遇到的那些坑(線程篇)》
《實踐總結(jié):Netty3.x VS Netty4.x的線程模型》
《Twitter:如何使用Netty 4來減少JVM的GC開銷(譯文)》
《絕對干貨:基于Netty實現(xiàn)海量接入的推送服務(wù)技術(shù)要點》
《Netty干貨分享:京東京麥的生產(chǎn)級TCP網(wǎng)關(guān)技術(shù)實踐總結(jié)》
《新手入門:目前為止最透徹的的Netty高性能原理和框架架構(gòu)解析》
《寫給初學者:Java高性能NIO框架Netty的學習方法和進階策略》
《少啰嗦!一分鐘帶你讀懂Java的NIO和經(jīng)典IO的區(qū)別》
《史上最強Java NIO入門:擔心從入門到放棄的,請讀這篇!》
《手把手教你用Netty實現(xiàn)網(wǎng)絡(luò)通信程序的心跳機制、斷線重連機制》
>> 更多同類文章 ……
(本文同步發(fā)布于:http://www.52im.net/thread-2799-1-1.html)
作者:Jack Jiang (點擊作者姓名進入Github)
出處:http://www.52im.net/space-uid-1.html
交流:歡迎加入即時通訊開發(fā)交流群 215891622
討論:http://www.52im.net/
Jack Jiang同時是【原創(chuàng)Java
Swing外觀工程BeautyEye】和【輕量級移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。
本博文
歡迎轉(zhuǎn)載,轉(zhuǎn)載請注明出處(也可前往 我的52im.net 找到我)。