Netty框架技術(shù)原理實(shí)踐講解_第1頁(yè)
Netty框架技術(shù)原理實(shí)踐講解_第2頁(yè)
Netty框架技術(shù)原理實(shí)踐講解_第3頁(yè)
Netty框架技術(shù)原理實(shí)踐講解_第4頁(yè)
Netty框架技術(shù)原理實(shí)踐講解_第5頁(yè)
已閱讀5頁(yè),還剩27頁(yè)未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

NettyNettyprojectNetty一個(gè)異步的網(wǎng)絡(luò)應(yīng)用開(kāi)發(fā)框架目錄什么是Netty?為什么使用Netty?如何使用Netty?總結(jié)1234還不快學(xué)起來(lái)什么是Netty?PARTONENetty是一個(gè)基于NIO的客戶、服務(wù)器端的編程框架,使用Netty可以確保你快速和簡(jiǎn)單的開(kāi)發(fā)出一個(gè)網(wǎng)絡(luò)應(yīng)用,例如實(shí)現(xiàn)了某種協(xié)議的客戶、服務(wù)端應(yīng)用。Netty相當(dāng)于簡(jiǎn)化和流線化了網(wǎng)絡(luò)應(yīng)用的編程開(kāi)發(fā)過(guò)程,例如:基于TCP和UDP的socket服務(wù)開(kāi)發(fā)。“快速”和“簡(jiǎn)單”并不用產(chǎn)生維護(hù)性或性能上的問(wèn)題。Netty是一個(gè)吸收了多種協(xié)議(包括FTP、SMTP、HTTP等各種二進(jìn)制文本協(xié)議)的實(shí)現(xiàn)經(jīng)驗(yàn),并經(jīng)過(guò)相當(dāng)精心設(shè)計(jì)的項(xiàng)目。最終,Netty成功的找到了一種方式,在保證易于開(kāi)發(fā)的同時(shí)還保證了其應(yīng)用的性能,穩(wěn)定性和伸縮性。

Nettyis

anasynchronousevent-drivennetworkapplicationframeworkforrapiddevelopmentofmaintainablehighperformanceprotocolservers&clients.什么是Netty?Netty能做什么?為什么使用Netty?NIO可以做的事情,使用Netty都可以做并且更好。Netty主要用來(lái)做網(wǎng)絡(luò)通信

:作為RPC框架的網(wǎng)絡(luò)通信工具

:我們?cè)诜植际较到y(tǒng)中,不同服務(wù)節(jié)點(diǎn)之間經(jīng)常需要相互調(diào)用,這個(gè)時(shí)候就需要RPC框架了。不同服務(wù)節(jié)點(diǎn)之間的通信是如何做的呢?可以使用Netty來(lái)做。比如我調(diào)用另外一個(gè)節(jié)點(diǎn)的方法的話,至少是要讓對(duì)方知道我調(diào)用的是哪個(gè)類(lèi)中的哪個(gè)方法以及相關(guān)參數(shù)實(shí)現(xiàn)一個(gè)即時(shí)通訊系統(tǒng)

:使用Netty我們可以實(shí)現(xiàn)一個(gè)可以聊天類(lèi)似微信的即時(shí)通訊系統(tǒng),這方面的開(kāi)源項(xiàng)目還蠻多的,可以自行去Github找一找。實(shí)現(xiàn)消息推送系統(tǒng)

:市面上有很多消息推送系統(tǒng)都是基于Netty來(lái)做的。現(xiàn)在物聯(lián)網(wǎng)的應(yīng)用無(wú)處不在,大量的項(xiàng)目都牽涉到應(yīng)用傳感器和服務(wù)器端的數(shù)據(jù)通信,Netty作為基礎(chǔ)通信組件、能夠輕松解決之前有較高門(mén)檻的通信系統(tǒng)開(kāi)發(fā)?!璑orman

MaurerNetty目前的項(xiàng)目leader是德國(guó)人NormanMaurer(之前在Redhat,全職開(kāi)發(fā)Netty),也是《NettyinAction》的作者,目前是蘋(píng)果公司高級(jí)工程師。TrustinLeeNetty的創(chuàng)始人是韓國(guó)人TrustinLee,他現(xiàn)在韓國(guó)line公司工作,早前應(yīng)用較多的Mina也是這他的作品。開(kāi)發(fā)者Trustin

Lee

And

Norman

Maurer什么是Netty?1JBoss

在4.0之前屬于JBoss,在包命名管理上可以看出Netty

4.0之后在Netty社區(qū)進(jìn)行管理從歸屬組織上看發(fā)展22004年6月Netty2發(fā)布;聲稱(chēng)Java社區(qū)中第一個(gè)基于事件驅(qū)動(dòng)的易用網(wǎng)絡(luò)框架2008年10月Netty3發(fā)布2013年7月Netty4發(fā)布2013年12月發(fā)布5.0.0.Alpha12015年1月廢棄5.0.0;沒(méi)有證明有明顯性能優(yōu)勢(shì)維護(hù)不過(guò)來(lái)……從版本演變上看發(fā)展什么是Netty?Netty的發(fā)展史

02還不快用起來(lái)為什么使用Netty?PARTTWO數(shù)據(jù)庫(kù):Cassandra大數(shù)據(jù)處理:Spark、Hadoop消息隊(duì)列:RocketMQ檢索:Elasticsearch框架:gRPC、ApacheDubbo、Spring5分布式協(xié)調(diào)器:Zookeeper……采用者為什么使用Netty??jī)?yōu)點(diǎn)使用簡(jiǎn)單功能強(qiáng)大性能強(qiáng)悍特點(diǎn)高并發(fā):基于NIO(Non-blockingIO,非阻塞IO)開(kāi)發(fā),對(duì)比于BIO(BlockingI/O,阻塞IO),他的并發(fā)性能得到了很大提高傳輸快:傳輸依賴于零拷貝特性,盡量減少不必要的內(nèi)存拷貝,實(shí)現(xiàn)了更高效率的傳輸封裝好:封裝了NIO操作的很多細(xì)節(jié),提供了易于使用調(diào)用接口優(yōu)勢(shì)使用簡(jiǎn)單:封裝了NIO的很多細(xì)節(jié),使用更簡(jiǎn)單;功能強(qiáng)大:預(yù)置了多種編解碼功能,支持多種主流協(xié)議;擴(kuò)展性強(qiáng):可以通過(guò)ChannelHandler對(duì)通信框架進(jìn)行靈活地?cái)U(kuò)展;性能優(yōu)異:通過(guò)與其他業(yè)界主流的NIO框架對(duì)比,Netty的綜合性能最優(yōu);運(yùn)行穩(wěn)定:Netty修復(fù)了已經(jīng)發(fā)現(xiàn)的所有NIO的bug,讓開(kāi)發(fā)人員可以專(zhuān)注于業(yè)務(wù)本身;社區(qū)活躍:Netty是活躍的開(kāi)源項(xiàng)目,版本迭代周期短,bug修復(fù)速度快。高性能IO線程模型:同步非阻塞,用最少的資源做更多的事;內(nèi)存零拷貝:盡量減少不必要的內(nèi)存拷貝,實(shí)現(xiàn)了更高效率的傳輸;內(nèi)存池設(shè)計(jì):申請(qǐng)的內(nèi)存可以重用,主要指直接內(nèi)存。串形化處理讀寫(xiě):避免使用鎖帶來(lái)的性能開(kāi)銷(xiāo);5)高性能序列化協(xié)議:支持protobuf等高性能序列化協(xié)議。為什么使用Netty?支持常用應(yīng)用層協(xié)議(如http),無(wú)需再過(guò)多考慮編解碼的實(shí)現(xiàn);解決TCP層傳輸問(wèn)題:粘包、半包現(xiàn)象支持流量整形(流量控制,黑白名單等)完善的斷連、Idle等異常處理NettyVSJDKNIO為什么使用Netty?做的更多做的更好規(guī)避JDKNIObug異常喚醒空轉(zhuǎn)導(dǎo)致CPU100%API更友好更強(qiáng)大JDK的NIO一些API不夠友好,功能薄弱。如ByteBuffer->Netty’sByteBuf除NIO外,也提供了其它一些增強(qiáng):ThreadLocal->Netty’sFastThreadLocal隔離變化、屏蔽細(xì)節(jié)隔離JDKNIO的實(shí)現(xiàn)變化:nio->nio2(aio)->…屏蔽JDKNIO的實(shí)現(xiàn)細(xì)節(jié)JDKNIO缺點(diǎn)NIO的類(lèi)庫(kù)和API繁雜,學(xué)習(xí)成本高,你需要熟練掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。需要熟悉Java多線程編程。這是因?yàn)镹IO編程涉及到Reactor模式,你必須對(duì)多線程和網(wǎng)絡(luò)編程非常熟悉,才能寫(xiě)出高質(zhì)量的NIO程序。臭名昭著的epollbug。它會(huì)導(dǎo)致Selector空輪詢,最終導(dǎo)致CPU100%。直到JDK1.7版本依然沒(méi)得到根本性的解決。同步異步關(guān)心的是“消息通知機(jī)制”。比如打電話去書(shū)店問(wèn)這里有沒(méi)有某某書(shū)。同步的做法是,老板會(huì)說(shuō)讓你等一下,我找找。這時(shí)整個(gè)通信過(guò)程會(huì)在一次通話中完成。異步的做法是,老板說(shuō)我找一下,遲點(diǎn)在回復(fù)你。此時(shí)通信過(guò)程分成兩次通話完成。經(jīng)典的三種I/O模型為什么使用Netty?同步與異步-數(shù)據(jù)就緒后,數(shù)據(jù)操作誰(shuí)完成?阻塞與非阻塞-數(shù)據(jù)就緒前要不要等待?而阻塞非阻塞關(guān)心的是“程序在等待調(diào)用結(jié)果(消息,返回值)時(shí)的狀態(tài)”。同樣是上面的例子。阻塞的做法是你打電話問(wèn)了之后,就一直拿著電話在等老板的回復(fù),等待期間其他什么都不干。而非阻塞則是你先放下電話,等老板來(lái)回復(fù)才回來(lái)繼續(xù)這個(gè)通話。一個(gè)連接一個(gè)線程,客戶端有連接請(qǐng)求時(shí)服務(wù)器端就需要啟動(dòng)一個(gè)線程進(jìn)行處理,線程開(kāi)銷(xiāo)大。經(jīng)典的三種I/O模型為什么使用Netty?BIO-同步阻塞NIO-同步非阻塞一個(gè)請(qǐng)求一個(gè)線程,客戶端發(fā)送的連接請(qǐng)求會(huì)注冊(cè)到多路復(fù)用器上,多路復(fù)用器輪詢到該連接有I/O請(qǐng)求時(shí)才啟動(dòng)一個(gè)線程進(jìn)行處理。AIO-異步非阻塞一個(gè)有效請(qǐng)求一個(gè)線程,客戶端的I/O請(qǐng)求都是由OS先完成了再通知服務(wù)器應(yīng)用去啟動(dòng)線程進(jìn)行處理。JAVANIO核心部分Channel:Channel是雙向的通道,既可以用來(lái)進(jìn)行讀操作,又可以用來(lái)進(jìn)行寫(xiě)操作Buffer:緩沖區(qū)(Buffer)就是在內(nèi)存中預(yù)留指定大小的存儲(chǔ)空間用來(lái)對(duì)輸入/輸出(I/O)的數(shù)據(jù)作臨時(shí)存儲(chǔ),這部分預(yù)留的內(nèi)存空間就叫做緩沖區(qū)Selector:一般稱(chēng)為選擇器

,當(dāng)然你也可以翻譯為

多路復(fù)用器

。它是JavaNIO核心組件中的一個(gè),用于檢查一個(gè)或多個(gè)NIOChannel(通道)的狀態(tài)是否處于可讀、可寫(xiě)。如此可以實(shí)現(xiàn)單線程管理多個(gè)channels,也就是可以管理多個(gè)網(wǎng)絡(luò)鏈接。為什么使用Netty?Netty對(duì)三種I/O模型的支持NotfasterthanNIO(epoll)onunixsystems(whichistrue)

Thereisnodaragramsuppport

Unnecessarythreadingmodel(toomuchabstractionwithoutusage)。Windows實(shí)現(xiàn)成熟,但是很少用來(lái)做服務(wù)器;Linux常用來(lái)做服務(wù)器,但是AIO實(shí)現(xiàn)不夠成熟;Linux下AIO相比較NIO的性能提升不明顯;為什么使用Netty?Reactor模式基于面向?qū)ο蟮乃枷?,?duì)I/O多路復(fù)用作了一層封裝,讓使用者不用考慮底層網(wǎng)絡(luò)API的細(xì)節(jié),只需要關(guān)注應(yīng)用代碼的編寫(xiě)。Reactor模式也叫Dispatcher模式,這個(gè)名字更貼合該模式的含義,即I/O多路復(fù)用監(jiān)聽(tīng)事件,收到事件后,根據(jù)事件類(lèi)型分配(Dispatch)給某個(gè)線程。Reactor是非阻塞同步網(wǎng)絡(luò)模式,感知的是就緒可讀寫(xiě)事件。在每次感知到有事件發(fā)生(比如可讀就緒事件)后,就需要應(yīng)用進(jìn)程主動(dòng)調(diào)用read方法來(lái)完成數(shù)據(jù)的讀取,也就是要應(yīng)用進(jìn)程主動(dòng)將socket接收緩存中的數(shù)據(jù)讀到應(yīng)用進(jìn)程內(nèi)存中,這個(gè)過(guò)程是同步的,讀取完數(shù)據(jù)后應(yīng)用進(jìn)程才能處理數(shù)據(jù)Reactor和Proactor的區(qū)別Proactor是異步網(wǎng)絡(luò)模式,感知的是已完成的讀寫(xiě)事件。在發(fā)起異步讀寫(xiě)請(qǐng)求時(shí),需要傳入數(shù)據(jù)緩沖區(qū)的地址(用來(lái)存放結(jié)果數(shù)據(jù))等信息,這樣系統(tǒng)內(nèi)核才可以自動(dòng)幫我們把數(shù)據(jù)的讀寫(xiě)工作完成,這里的讀寫(xiě)工作全程由操作系統(tǒng)來(lái)做,并不需要像Reactor那樣還需要應(yīng)用進(jìn)程主動(dòng)發(fā)起read/write來(lái)讀寫(xiě)數(shù)據(jù),操作系統(tǒng)完成讀寫(xiě)工作后,就會(huì)通知應(yīng)用進(jìn)程直接處理數(shù)據(jù)。Reactor可以理解為「來(lái)了事件操作系統(tǒng)通知應(yīng)用進(jìn)程,讓?xiě)?yīng)用進(jìn)程來(lái)處理」Proactor可以理解為「來(lái)了事件操作系統(tǒng)來(lái)處理,處理完再通知應(yīng)用進(jìn)程」。為什么使用Netty?單Reactor單線程模式Reactor通過(guò)select監(jiān)聽(tīng)客戶端請(qǐng)求事件,收到事件之后通過(guò)dispatch進(jìn)行分發(fā)如果事件是建立連接的請(qǐng)求事件,則由Acceptor通過(guò)accept處理連接請(qǐng)求,然后創(chuàng)建一個(gè)Handler對(duì)象處理連接建立后的后續(xù)業(yè)務(wù)處理。如果事件不是建立連接的請(qǐng)求事件,則由Reactor對(duì)象分發(fā)給連接對(duì)應(yīng)的Handler處理。Handler會(huì)完成read-->業(yè)務(wù)處理-->send的完整處理流程。優(yōu)點(diǎn):模型簡(jiǎn)單,沒(méi)有多線程、進(jìn)程通信、競(jìng)爭(zhēng)的問(wèn)題,一個(gè)線程完成所有的事件響應(yīng)和業(yè)務(wù)處理。缺點(diǎn):存在性能問(wèn)題,只有一個(gè)線程,無(wú)法完全發(fā)揮多核CPU的性能。Handler在處理某個(gè)連接上的業(yè)務(wù)時(shí),整個(gè)進(jìn)程無(wú)法處理其他連接事件,很容易導(dǎo)致性能瓶頸;存在可靠性問(wèn)題,若線程意外終止,或者進(jìn)入死循環(huán),會(huì)導(dǎo)致整個(gè)系統(tǒng)通信模塊不可用,不能接收和處理外部消息,造成節(jié)點(diǎn)故障。為什么使用Netty?單Reactor多線程模式1)Reactor對(duì)象通過(guò)select監(jiān)聽(tīng)客戶端請(qǐng)求事件,收到事件后通過(guò)dispatch進(jìn)行分發(fā)。2)如果事件是建立連接的請(qǐng)求事件,則由Acceptor通過(guò)accept處理連接請(qǐng)求,然后創(chuàng)建一個(gè)Handler對(duì)象處理連接建立后的后續(xù)業(yè)務(wù)處理。3)如果事件不是建立連接的請(qǐng)求事件,則由Reactor對(duì)象分發(fā)給連接對(duì)應(yīng)的Handler處理。Handler只負(fù)責(zé)響應(yīng)事件,不做具體的業(yè)務(wù)處理,Handler通過(guò)read讀取到請(qǐng)求數(shù)據(jù)后,會(huì)分發(fā)給后面的Worker線程池來(lái)處理業(yè)務(wù)請(qǐng)求。4)Worker線程池會(huì)分配獨(dú)立線程來(lái)完成真正的業(yè)務(wù)處理,并將處理結(jié)果返回給Handler。Handler通過(guò)send向客戶端發(fā)送響應(yīng)數(shù)據(jù)。這種模式的優(yōu)點(diǎn)是可以充分的利用多核cpu的處理能力,缺點(diǎn)是多線程數(shù)據(jù)共享和控制比較復(fù)雜,Reactor處理所有的事件的監(jiān)聽(tīng)和響應(yīng),在單線程中運(yùn)行,面對(duì)高并發(fā)場(chǎng)景還是容易出現(xiàn)性能瓶頸。為什么使用Netty?主從Reactor多線程模式Reactor主線程MainReactor對(duì)象通過(guò)select監(jiān)聽(tīng)客戶端連接事件,收到事件后,通過(guò)Acceptor處理客戶端連接事件。當(dāng)Acceptor處理完客戶端連接事件之后(與客戶端建立好Socket連接),MainReactor將連接分配給SubReactor。(即:MainReactor只負(fù)責(zé)監(jiān)聽(tīng)客戶端連接請(qǐng)求,和客戶端建立連接之后將連接交由SubReactor監(jiān)聽(tīng)后面的IO事件。)SubReactor將連接加入到自己的連接隊(duì)列進(jìn)行監(jiān)聽(tīng),并創(chuàng)建Handler對(duì)各種事件進(jìn)行處理。當(dāng)連接上有新事件發(fā)生的時(shí)候,SubReactor就會(huì)調(diào)用對(duì)應(yīng)的Handler處理。Handler通過(guò)read從連接上讀取請(qǐng)求數(shù)據(jù),將請(qǐng)求數(shù)據(jù)分發(fā)給Worker線程池進(jìn)行業(yè)務(wù)處理。Worker線程池會(huì)分配獨(dú)立線程來(lái)完成真正的業(yè)務(wù)處理,并將處理結(jié)果返回給Handler。Handler通過(guò)send向客戶端發(fā)送響應(yīng)數(shù)據(jù)。針對(duì)單Reactor多線程模型中,Reactor在單個(gè)線程中運(yùn)行,面對(duì)高并發(fā)的場(chǎng)景易成為性能瓶頸的缺陷,主從Reactor多線程模式讓Reactor在多個(gè)線程中運(yùn)行(分成MainReactor線程與SubReactor線程)。為什么使用Netty?Netty組件Bootstrap意思是引導(dǎo),一個(gè)Netty應(yīng)用通常由一個(gè)Bootstrap開(kāi)始,主要作用是配置整個(gè)Netty程序,串聯(lián)各個(gè)組件,Netty中Bootstrap類(lèi)是客戶端程序的啟動(dòng)引導(dǎo)類(lèi),ServerBootstrap是服務(wù)端啟動(dòng)引導(dǎo)類(lèi)。Bootstrap、ServerBootstrapFuture、ChannelFuture在Netty中所有的IO操作都是異步的,不能立刻得知消息是否被正確處理,但是可以過(guò)一會(huì)等它執(zhí)行完成或者直接注冊(cè)一個(gè)監(jiān)聽(tīng),具體的實(shí)現(xiàn)就是通過(guò)Future和ChannelFutures,他們可以注冊(cè)一個(gè)監(jiān)聽(tīng),當(dāng)操作執(zhí)行成功或失敗時(shí)監(jiān)聽(tīng)會(huì)自動(dòng)觸發(fā)注冊(cè)的監(jiān)聽(tīng)事件。ChannelNetty網(wǎng)絡(luò)通信的組件,能夠用于執(zhí)行網(wǎng)絡(luò)I/O操作。Channel為用戶提供:當(dāng)前網(wǎng)絡(luò)連接的通道的狀態(tài)(例如是否打開(kāi)?是否已連接?)網(wǎng)絡(luò)連接的配置參數(shù)(例如接收緩沖區(qū)大小)提供異步的網(wǎng)絡(luò)I/O操作(如建立連接,讀寫(xiě),綁定端口),異步調(diào)用意味著任何I/O調(diào)用都將立即返回,并且不保證在調(diào)用結(jié)束時(shí)所請(qǐng)求的I/O操作已完成。調(diào)用立即返回一個(gè)ChannelFuture實(shí)例,通過(guò)注冊(cè)監(jiān)聽(tīng)器到ChannelFuture上,可以I/O操作成功、失敗或取消時(shí)回調(diào)通知調(diào)用方。支持關(guān)聯(lián)I/O操作與對(duì)應(yīng)的處理程序?yàn)槭裁词褂肗etty?Netty組件NioEventLoop中維護(hù)了一個(gè)線程和任務(wù)隊(duì)列,支持異步提交執(zhí)行任務(wù),線程啟動(dòng)時(shí)會(huì)調(diào)用NioEventLoop的run方法,執(zhí)行I/O任務(wù)和非I/O任務(wù):I/O任務(wù)即selectionKey中ready的事件,如accept、connect、read、write等,由processSelectedKeys方法觸發(fā)。非IO任務(wù)添加到taskQueue中的任務(wù),如register0、bind0等任務(wù),由runAllTasks方法觸發(fā)。NioEventLoopNioEventLoopGroupNioEventLoopGroup,主要管理eventLoop的生命周期,可以理解為一個(gè)線程池,內(nèi)部維護(hù)了一組線程,每個(gè)線程(NioEventLoop)負(fù)責(zé)處理多個(gè)Channel上的事件,而一個(gè)Channel只對(duì)應(yīng)于一個(gè)線程。ChannelHandlerChannelHandler是一個(gè)接口,處理I/O事件或攔截I/O操作,并將其轉(zhuǎn)發(fā)到其ChannelPipeline(業(yè)務(wù)處理鏈)中的下一個(gè)處理程序。ChannelHandler本身并沒(méi)有提供很多方法,因?yàn)檫@個(gè)接口有許多的方法需要實(shí)現(xiàn),方便使用期間,可以繼承它的子類(lèi):ChannelInboundHandler用于處理入站I/O事件ChannelOutboundHandler用于處理出站I/O操作為什么使用Netty?Netty組件ChannelPipline保存ChannelHandler的List,用于處理或攔截Channel的入站事件和出站操作。ChannelPipeline實(shí)現(xiàn)了一種高級(jí)形式的攔截過(guò)濾器模式,使用戶可以完全控制事件的處理方式,以及Channel中各個(gè)的ChannelHandler如何相互交互。為什么使用Netty?Netty的模樣為什么使用Netty?TCP粘包/拆包TCP是一個(gè)“流”協(xié)議,所謂流,就是沒(méi)有界限的一長(zhǎng)串二進(jìn)制數(shù)據(jù)。TCP作為傳輸層協(xié)議并不不了解上層業(yè)務(wù)數(shù)據(jù)的具體含義,它會(huì)根據(jù)TCP緩沖區(qū)的實(shí)際情況進(jìn)行數(shù)據(jù)包的劃分,所以在業(yè)務(wù)上認(rèn)為是一個(gè)完整的包,可能會(huì)被TCP拆分成多個(gè)包進(jìn)行發(fā)送,也有可能把多個(gè)小的包封裝成一個(gè)大的數(shù)據(jù)包發(fā)送,這就是所謂的TCP粘包和拆包問(wèn)題。Netty自帶的拆包器固定長(zhǎng)度的拆包器FixedLengthFrameDecoder如果應(yīng)用層協(xié)議非常簡(jiǎn)單,每個(gè)數(shù)據(jù)包的長(zhǎng)度都是固定的,比如固定100長(zhǎng)度,Netty會(huì)把一個(gè)個(gè)長(zhǎng)度為100的數(shù)據(jù)包(ByteBuf)

拆分出來(lái)行拆包器LineBasedFrameDecoder發(fā)送端發(fā)送數(shù)據(jù)包的時(shí)候,每個(gè)數(shù)據(jù)包之間以換行符作為分隔,接收端通過(guò)LineBasedFrameDecoder將粘過(guò)的ByteBuf拆分成一個(gè)個(gè)完整的應(yīng)用層數(shù)據(jù)包。分隔符拆包器DelimiterBasedFrameDecoderDelimiterBasedFrameDecoder是行拆包器的通用版本,只不過(guò)我們可以自定義分隔符?;陂L(zhǎng)度域拆包器LengthFieldBasedFrameDecoder是最通用的一種拆包器,只要你的自定義協(xié)議中包含長(zhǎng)度域字段,均可以使用這個(gè)拆包器來(lái)實(shí)現(xiàn)應(yīng)用層拆包。為什么使用Netty?TCP粘包/拆包TCP是一個(gè)“流”協(xié)議,所謂流,就是沒(méi)有界限的一長(zhǎng)串二進(jìn)制數(shù)據(jù)。TCP作為傳輸層協(xié)議并不不了解上層業(yè)務(wù)數(shù)據(jù)的具體含義,它會(huì)根據(jù)TCP緩沖區(qū)的實(shí)際情況進(jìn)行數(shù)據(jù)包的劃分,所以在業(yè)務(wù)上認(rèn)為是一個(gè)完整的包,可能會(huì)被TCP拆分成多個(gè)包進(jìn)行發(fā)送,也有可能把多個(gè)小的包封裝成一個(gè)大的數(shù)據(jù)包發(fā)送,這就是所謂的TCP粘包和拆包問(wèn)題。Netty自帶的拆包器固定長(zhǎng)度的拆包器FixedLengthFrameDecoder如果應(yīng)用層協(xié)議非常簡(jiǎn)單,每個(gè)數(shù)據(jù)包的長(zhǎng)度都是固定的,比如固定100長(zhǎng)度,Netty會(huì)把一個(gè)個(gè)長(zhǎng)度為100的數(shù)據(jù)包(ByteBuf)

拆分出來(lái)行拆包器LineBasedFrameDecoder發(fā)送端發(fā)送數(shù)據(jù)包的時(shí)候,每個(gè)數(shù)據(jù)包之間以換行符作為分隔,接收端通過(guò)LineBasedFrameDecoder將粘過(guò)的ByteBuf拆分成一個(gè)個(gè)完整的應(yīng)用層數(shù)據(jù)包。分隔符拆包器DelimiterBasedFrameDecoderDelimiterBasedFrameDecoder是行拆包器的通用版本,只不過(guò)我們可以自定義分隔符?;陂L(zhǎng)度域拆包器LengthFieldBasedFrameDecoder是最通用的一種拆包器,只要你的自定義協(xié)議中包含長(zhǎng)度域字段,均可以使用這個(gè)拆包器來(lái)實(shí)現(xiàn)應(yīng)用層拆包。為什么使用Netty?Netty心跳機(jī)制在TCP保持長(zhǎng)連接的過(guò)程中,可能會(huì)出現(xiàn)斷網(wǎng)等網(wǎng)絡(luò)異常出現(xiàn),異常發(fā)生的時(shí)候,client與server之間如果沒(méi)有交互的話,它們是無(wú)法發(fā)現(xiàn)對(duì)方已經(jīng)掉線的。為了解決這個(gè)問(wèn)題,我們就需要引入心跳機(jī)制

。心跳機(jī)制的工作原理是:在client與server之間在一定時(shí)間內(nèi)沒(méi)有數(shù)據(jù)交互時(shí),即處于idle狀態(tài)時(shí),客戶端或服務(wù)器就會(huì)發(fā)送一個(gè)特殊的數(shù)據(jù)包給對(duì)方,當(dāng)接收方收到這個(gè)數(shù)據(jù)報(bào)文后,也立即發(fā)送一個(gè)特殊的數(shù)據(jù)報(bào)文,回應(yīng)發(fā)送方,此即一個(gè)PING-PONG交互。所以,當(dāng)某一端收到心跳消息后,就知道了對(duì)方仍然在線,這就確保TCP連接的有效性.TCP實(shí)際上自帶的就有長(zhǎng)連接選項(xiàng),本身是也有心跳包機(jī)制,也就是TCP的選項(xiàng):SO_KEEPALIVE。但是,TCP協(xié)議層面的長(zhǎng)連接靈活性不夠。所以,一般情況下我們都是在應(yīng)用層協(xié)議上實(shí)現(xiàn)自定義心跳機(jī)制的,也就是在Netty層面通過(guò)編碼實(shí)現(xiàn)。通過(guò)Netty實(shí)現(xiàn)心跳機(jī)制的話,核心類(lèi)是IdleStateHandler

。為什么使用Netty?Netty零拷貝在OS層面上的Zero-copy通常指避免在用戶態(tài)(User-space)與內(nèi)核態(tài)(Kernel-space)之間來(lái)回拷貝數(shù)據(jù)。而在Netty層面,零拷貝主要體現(xiàn)在對(duì)于數(shù)據(jù)操作的優(yōu)化使用Netty提供的Com

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論