DotNetty網路通信框架學習之源碼分析

DotNetty網路通信框架學習之源碼分析有關DotNetty框架，網上的詳細資料不是很多，有不多的幾個博友做了簡單的介紹，也沒有做深入的探究，我也根據源碼中提供的demo做一下記錄，方便後期查閱。 github地址：https://github.com/Azure/DotNetty 源碼的src ...

DotNetty網路通信框架學習之源碼分析

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

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

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

1、DotNetty.Buffers

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

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

2、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編解碼器的詳細內容可參考：https://www.cnblogs.com/chris-oil/p/6098258.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協議的解析過程探索可參考：https://www.cnblogs.com/Binhua-Liu/p/5577622.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為：