想要了解http協(xié)議，先看http協(xié)議在tcp/ip協(xié)議中的位置以及對應(yīng)java層面io層的數(shù)據(jù)流方式，如上圖所示，http協(xié)議位于應(yīng)用層，在tcp協(xié)議之上；下圖即是java層面幾種通信模型簡介
幾種nio模型
使用BIO方式(同步阻塞IO)
使用ServerSocket綁定IP地址，啟動端口，使用Socket進行握手連接，連接成功后，雙方通過輸入輸出流進行同步阻塞式通信，每當有客戶端的請求后，即啟動一個線程進行處理
使用PAIO(同步阻塞IO)
使用線程池進行處理客戶端的請求，因為在進行read或者write的時候，都是阻塞IO的，所以還是同步阻塞IO，只是線程的資源交由線程池進行控制
使用java.nio包的NIO方式(異步非阻塞IO)
使用NIO方式 異步IO，使用多路復用器關(guān)聯(lián)通道，當通道中有事件時，即通知處理，不用阻塞IO，利用ByteBuffer進行數(shù)據(jù)緩沖，使用Channel進行數(shù)據(jù)傳輸，利用Selector進行通道的輪詢與管理，讀寫均是異步的
使用AIO方式(異步非阻塞IO)
使用AIO方式，異步非阻塞IO，NIO的升級版,通過一系列的回調(diào)策略(CompletionHandler)完成應(yīng)用功能，無需借助于Selector，對應(yīng)于unix的異步IO
上面5種方式的code示例在----https://github.com/undergrowthlinear/netty.git
http request line和response line
了解http request line格式和response line對于后面看各個框架源碼，有很大用處，可以隨意打開chrome的調(diào)試器，看下訪問一個請求對應(yīng)的數(shù)據(jù)格式是否如上圖所說
nettynetty 主從多模型
reactor 主從多線程模型 來源 https://xintu.cnblogs.com/luoxn28/p/11875340.html
大致工作流程如下：當客戶端連接進來。在main線程池進行握手、鑒權(quán)等功能校驗；通過后，將channel通道注冊到io線程池，通過一系列的handler進行處理業(yè)務(wù)數(shù)據(jù)流。
netty邏輯架構(gòu)圖
承接上面的主從多模型，當客戶端注冊到io線程池后，netty使用管道流pipeline的方式，允許開發(fā)者復用框架已有的處理器以及自定義處理器，很多開源框架的網(wǎng)絡(luò)層都是使用netty進行通信，例如rocketmq、dubbo等
netty中對于http協(xié)議支持核心類
HttpObject
HttpContent(大塊對象支持) 、DefaultHttpContent、LastHttpContent(EMPTY_LAST_CONTENT)、HttpMessage(HttpRequest/HttpResponse的通用屬性支持)、 HttpRequest、 DefaultHttpRequest
HttpObjectDecoder
(解析ByteBuf為HttpMessage和HttpContent或者LastHttpContent,取決于內(nèi)容數(shù)據(jù)塊的長度;如果沒有內(nèi)容,則是createMessage創(chuàng)建HttpMessage的子類;如果有固定長度內(nèi)容,且小于maxChunkSize,則DefaultLastHttpContent;最后有很多內(nèi)容的時候,就是DefaultHttpContent、DefaultLastHttpContent)----所以這里有HttpRequest和HttpContent內(nèi)容需要業(yè)務(wù)端分開處理、HttpRequestDecoder()、HttpResponseDecoder(解析ByteBuf為HttpResponse/HttpContent)
HttpObjectEncoder
(將HttpMessage或者HttpContent轉(zhuǎn)換成ByteBuf)，HttpRequestEncoder(HttpRequest/HttpContent轉(zhuǎn)為ByteBuf)、 HttpResponseEncoder(HttpResponse/HttpContent轉(zhuǎn)為ByteBuf)、 io.netty.handler.codec.ByteToMessageDecoder#fireChannelRead----將解析出來的列表元素循環(huán)迭代對后續(xù)的處理器,對于理解http的HttpRequest與HttpContent/LastHttpContent至關(guān)重要
鏈接----https://github.com/netty/netty.git
okhttp流程圖 來源 https://xintu.jianshu.com/p/5b886f851c59
以易用性和性能著稱，上圖的官方描述，支持http2.0、連接池復用、響應(yīng)緩存、流式調(diào)用、支持同步和異步調(diào)用等一系列功能，在很多開源框架中，也經(jīng)?？吹玫剑溄?---https://github.com/square/okhttp.git
apache httpclientapache出品，也是支持阻塞的io模型和非阻塞的nio模型，不過你要是用過okhttp，我估計你不會再用httpclient了，使用上，差距還是很明顯。
HttpURLConnectionjava原生http協(xié)議，apache httpclient就是在其基礎(chǔ)上封裝而來，對開發(fā)者而言，易用性遠不及httpclient和okhttp
Feignfeign 支持特性 來源 https://github.com/OpenFeign/feign
當你對http request line和response line了解后，看feign的注解就會很清楚是什么意思了，注解式開發(fā)，簡化http調(diào)用，spring微服務(wù)核心組件之一，鏈接----https://github.com/OpenFeign/feign.git
Forest國人開源的類似feign的api框架，官方描述如下：
輕量級HTTP客戶端API框架，讓Java發(fā)送HTTP/HTTPS請求不再難。它比OkHttp和HttpClient更高層，是封裝調(diào)用第三方restful api client接口的好幫手，是retrofit和feign之外另一個選擇，鏈接----https://gitee.com/dromara/forest
當然，這也是我所了解過的http開源框架，可能還有更好用的，如果你知道，不妨在評論區(qū)留言，讓我也學習下。程序員的學習之路，逆水行舟，不學你就落后了，落后了就沒高薪水，就沒法買上好的假發(fā)了，持續(xù)學習，加油吧，伙伴們。
掃描二維碼推送至手機訪問。
版權(quán)聲明：本文由信途科技轉(zhuǎn)載于網(wǎng)絡(luò)，如有侵權(quán)聯(lián)系站長刪除。
轉(zhuǎn)載請注明出處http://macbookprostickers.com/xintu/10372.html
