Netty 通訊協議設計概要

1. 前言

上節內容，我們主要介紹了 Netty 的粘包和拆包問題，并且大致介紹了 Netty 提供的常見拆包器，分別是固定長度拆包器、行拆包器、分隔符拆包器、基于長度域拆包器，但是它們只是相對簡單的協議，也就是說無法滿足復雜的業務場景，因此，我們可以通過自定義協議的方式去解決 TCP 的粘包和拆包問題。

2. 了解什么是協議

首先，我們大概了解什么是協議，協議可以把它認為是一種規則而不是技術，約束客戶端和服務端之間通訊，數據組裝和拆分的一種規范?？蛻舳税惭b某種規范去組裝數據，把數據傳輸給服務端，服務端再安裝這種規范拆解數據，那么這就是一種協議，可以根據實際業務區指定符合自身的協議，其實基于 Netty 去制定的私有協議，我個人接觸過的是傳輸車輛 GPS 數據的 809 協議，在和 GPS 服務器通訊時，必須按照該協議去進行封裝和解析數據，否則通訊異常。

其實，類似的規則還有很多，從開發的角度來說，都是各種規則和約束，比如說：前面提到的序列化技術，序列化其實就是把數據按照某種規則去轉換成 byte 數字，而反序列化就是按照這種規則再去把字節流轉換成對應的類型數據。這些都是基于某種規則的基礎上，使用技術的手段去封裝的結果。

3. 通訊協議

3.1 協議架構

思路架構圖：

首先，我們先來了解協議在整個通訊當中的扮演的角色，如下圖所示：

如上圖所示，客戶端和服務端之間的通訊流程：

客戶端發送數據

1. 客戶端先把一個對象序列化成字節流；
2. 然后把字節流根據協議把字節流組裝好；
3. 最后轉換成二進制傳輸到網絡。

服務端接受數據

1. 從網絡中讀取二進制數據到本地的緩沖區；
2. 根據協議的規則讀取指定數據，并且識別是否是完整的數據包；
3. 如果是完整的數據包，則轉換成實體對象。

由此可見，協議主要是管理字節流格式的一種規則，如果把協議環節去掉，那么服務端就無法知道字節流的結束位置。

3.2 協議設計

協議介紹：

1. 協議標識符，以一個固定數作為標識符，占用 4 個字節，主要目的是用來識別協議的開頭，只要是以該標識開頭的協議則進行處理，否則不處理。主要目的是提高處理性能問題，如果隨便一個請求都需要進行處理，但是最終處理起來發現協議格式不對，拋異常，肯定會影響系統性能；
2. 數據長度，占用 4 個字節，標識數據的真實長度，獲取到該值后，往后讀取指定長度的數據即可。主要目的是防止粘包和拆包安全性問題；
3. 指令，協議是某個應用所有的業務公用的一種規則，那么應該如何區分是哪種業務呢？這里主要通過指令來進行區分；
4. 數據，這部分存儲的是真實的數據。

這算是比較簡單，并且常用的設計思路，主要和 Netty 內置的基于長度域拆包器類似，基本上都是有一個字段是用來存儲真實的數據長度，這樣才能準確的讀取數據的完整內容。當然，還可以在該設計基礎上加上更多的字段，比如：使用的序列號技術、協議版本號等等。

3.3 技術棧說明

相信到這里，大家對協議基本上有一個簡單的認識了，其實協議并不難，它只是一個約束而已，那么我們如何通過技術的實現，讓協議生效呢？主要的核心思想如下：

1. 序列化和發序列話技術，這個在 Netty 的編解碼的時候已經講過，序列化可以把對象轉化成字節流，反序列化可以把字節流轉換成對象；
2. 字節容器（字節緩沖區），必須按照協議的字段順序往字節容器里面存放對應的字節內容，然后把整個容器寫到網絡當中。這樣數據才能按照順序進行傳輸，服務端才能按照順序進行數據的讀取和處理。

4. 小結

本節主要介紹協議的思想，它就是一種規則，客戶端和服務端必須需要遵守的規則，才能保證數據的安全性。其次，講解了協議在客戶端和服務端通訊當中所扮演的角色，如果沒有協議，那么服務端一直讀取字節流，根本無法知道數據的完整性。最后，大概介紹了協議設計的大概思想，主要核心字段有四個，分別是協議標識符、數據長度、指令、數據，這四個字段是滿足協議的基本元素，可以根據實際業務再進行擴展字段。