DotNetty網絡通訊框架學習之源碼分析

DotNetty網絡通訊框架學習之源碼分析

有關DotNetty框架，網上的詳細資料不是不少，有很少的幾個博友作了簡單的介紹，也沒有作深刻的探究，我也根據源碼中提供的demo作一下記錄，方便後期查閱。

github地址：https://github.com/Azure/DotNetty

 

源碼的src文件夾中是框架的dll項目，包含如下的內容：

一、DotNetty.Buffers

緩衝區：傳輸數據時通常都會使用一個緩衝區包裝數據，DotNetty衍生於Java的Netty，定義了本身的Buffer。Netty的提供的Buffer至關的強大，用來表示一個字節序列，幫助開發者定義本身的buffer類型。詳細的介紹參考：https://blog.csdn.net/wangjinnan16/article/details/77972113.

buffers中還提供了不少類和接口，其中ByteBufferUtil.cs是一個Bytebuffer的幫助類，可將接收的緩衝區包轉換成須要的數據格式，其中我用到的是：Hexdump，是將buffer轉換成十六進制的字符串，方便在Modbus解析中使用。

 二、DotNetty.Codecs

編解碼器：編解碼器的做用就將原始字節數據與目標程序數據格式之間進行相互轉換。網絡中的數據是字節的數據形式進行傳輸的，經過編碼和解碼來知足對數據的利用。Netty中根據不一樣數據傳輸類型，擴展了不少的解碼規則抽象類。其中包括項目中的Http、Mqtt、Protobuf、Redis等。工做機制大概以下：

Decodes.Http

http協議實現的抽象類，類型以下：

HttpMethod:對method的封裝，包含method序列化的操做。get,put,post等。

HttpVersion:對Version的封裝，包含版本1.0與1.1

HttpHeaders:包含對header的內容進行的封裝及操做。

HttpContent：對httpnbody的封裝，其本質是一個bytebuffer,

HttpRequest:包含對Request Line和Header的組合。

FullHttpRequest:包含對HttpRequest和httpContent 的組合封裝。

request流程處理

基本的處理原理：

 

使用方法:只須要在通道ChannelLine中配置HttpRequestDecoder和HttpObjectAggregator.

 HttpRequest解碼器現將強求通道中的內筒解析成HttpRequest對象，在傳到聚合其中，當聚合器解析完http協議後，再封裝成FullHttpRequest。

response流程處理

原理：

 

使用方法在編碼以前加上HttpContent壓縮機，response先被壓縮後再進行編碼序列化。壓縮只是對Body的壓縮。

 有關Http編解碼器的詳細內容可參考：http://www.javashuo.com/article/p-erwzupgb-dq.html

 Codecs.Mqtt協議編解碼

首先了解一下MQTT協議：根據百度百科的解釋，它的的定義以下：

Mqtt(Message Queuing Telemetry Transport) 消息隊列遙測傳輸，是IBM開發的一個即時通信協議。該協議支持全部的平臺，被普遍用於人工智能，區塊鏈和物聯網等。

 

 MQTT提供了訂閱和發佈兩種消息模式，更爲簡約、輕量、易於使用，特別適用於受限環境中的消息發佈，屬於物聯網的一個標準傳輸協議。

更過的關於MQTT的內容學習可參考：http://www.360doc.com/content/18/0116/05/163747_722273693.shtml

 Netty中提供了MQTT協議的解碼和編碼方法，具體的實踐探索將在後期進行。

Codecs.Protobuf 協議編解碼器

 一樣先得知道Protobuf協議是個什麼東西：

Protobuf(Google Protocol Buffer）：是谷歌開發的一套用於數據存儲，網絡通訊時用於協議編解碼的工具庫，和XML和JSON相似，把數據用某種形式保存起來，惟一不一樣的是它是一種二進制的數據格式，具備更好的傳輸，打包和解包的效率。

DotNetty只是提供了編輯碼協議用的抽象類，並無作進一步的處理，有關協議的詳細使用後期將不斷的探索。更多內容可參考大神博客：https://www.ibm.com/developerworks/cn/linux/l-cn-gpb/index.html   ，http://baijiahao.baidu.com/s?id=1583577904006702816&wfr=spider&for=pc。

有關ProtocolBuf協議的解析過程探索可參考：http://www.javashuo.com/article/p-ktbnsrlb-dv.html

 https://blog.csdn.net/kokjuis/article/details/72845163

https://blog.csdn.net/z69183787/article/details/52980720

Codecs.Redis 協議協議編解碼器

 下面是一段對Redis中協議的介紹：

Redis的客戶端與服務端採用一種叫作 RESP(REdis Serialization Protocol)的網絡通訊協議交換數據。RESP的設計權衡了實現簡單、解析快速、人類可讀這三個因素。Redis客戶端經過RESP序列化整數、字符串、數據等數據類型，發送字符串數組表示參數的命令到服務端。服務端根據不一樣的請求命令響應不一樣的數據類型。除了管道和訂閱外，Redis客戶端和服務端都是以這種簡單的請求-響應模型通訊的。 --------------------- 本文來自 cdai 的CSDN 博客 ，全文地址請點擊：https://blog.csdn.net/dc_726/article/details/46565257?utm_source=copy 

 以」*」消息頭標識總長度，消息內部還可能有」$」標識字符串長度，每行以\r\n結束

• 簡單字符串(Simple String)：以」+」開頭，表示正確的狀態信息，」+」後就是具體信息。許多Redis命令使用簡單字符串做爲成功的響應，例如」+OK\r\n」。但簡單字符串由於不像Bulk String那樣有長度信息，而只能靠\r\n肯定是否結束，因此 Simple String不是二進制安全的，即字符串裏不能包含\r\n。
• 錯誤(Error)：以」-「開頭，表示錯誤的狀態信息，」-「後就是具體信息。
• 整數(Integer)：以」:」開頭，像SETNX, DEL, EXISTS, INCR, INCRBY, DECR, DECRBY, DBSIZE, LASTSAVE, RENAMENX, MOVE, LLEN, SADD, SREM, SISMEMBER, SCARD都返回整數。
• 批量字符串(Bulk String)：以」$」開頭，表示下一行的字符串長度，具體字符串在下一行中，字符串最大能達到512MB。」$-1\r\n」叫作Null Bulk String，表示沒有數據存在。
• 數組(Array)：以」*」開頭，表示消息體總共有多少行（不包括當前行），」*」是具體行數。客戶端用RESP數組表示命令發送到服務端，反過來服務端也能夠用RESP數組返回數據的集合給客戶端。數組能夠是混合數據類型，例如一個整數加一個字符串」*2\r\n:1\r\n$6\r\nfoobar\r\n」。另外，嵌套數組也是能夠的。

 Netty中提供的幾個與Redis有關的Handler爲：

• RedisCommandDecoder：解析Redis協議，將字節數組轉爲Command對象。
• RedisReplyEncoder：將響應寫入到輸出流中，返回給客戶端。
• RedisCommandHandler：執行Command中的命令。

 詳細的有關redis協議的處理將在後期更新，相關內容參考至：https://blog.csdn.net/dc_726/article/details/46565257

 Handler、Transport、TransportLibuv

 這是Netty中核心的東西，包含全部的數據轉換和處理的內容，將在後期的學習中不斷的完善。

 

---

 

 以上內容是參考了不少網上的資源，感謝那些原創做者的貢獻，僅做爲我的學習使用。

更多內容：DotNetty網絡通訊框架學習之源碼分析