TCP粘包、拆包與通信協議詳解
在TCP編程中，我們使用協議(protocol)來解決粘包和拆包問題。本文將詳解TCP粘包和半包產生的原因，以及如何通過協議來解決粘包、拆包問題。讓你知其然，知其所以然。
1 TCP粘包、拆包圖解
由于TCP傳輸協議面向流的，沒有消息保護邊界。一方發送的多個報文可能會被合并成一個大的報文進行傳輸，這就是粘包;也可能發送的一個報文，可能會被拆分成多個小報文，這就是拆包。
下圖演示了粘包、拆包的過程，client分別發送了兩個數據包D1和D2給server，server端一次讀取到字節數是不確定的，因此可能可能存在以下幾種情況：
關于這幾種情況說明如下：
server端分兩次讀取到了兩個獨立的數據包，分別是D1和D2，沒有粘包和拆包
server一次接受到了兩個數據包，D1和D2粘合在一起，稱之為TCP粘包
server分兩次讀取到了數據包，第一次讀取到了完整的D1包和D2包的部分內容，第二次讀取到了D2包的剩余內容，這稱之為TCP拆包
Server分兩次讀取到了數據包，第一次讀取到了D1包的部分內容D1_1，第二次讀取到了D1包的剩余部分內容D1_2和完整的D2包。
由于發送方發送的數據，可能會發生粘包、拆包的情況。這樣，對于接收端就難于分辨出來了，因此必須提供科學的機制來解決粘包、拆包問題，這就是協議的作用。
在介紹協議之前，我們先了解一下粘包、拆包產生的原因。
2 粘包、拆包產生的原因
粘包、拆包問題的產生原因筆者歸納為以下3種：
- socket緩沖區與滑動窗口
- MSS/MTU限制
- Nagle算法
2.1 socket緩沖區與滑動窗口
每個TCP socket在內核中都有一個發送緩沖區(SO_SNDBUF )和一個接收緩沖區(SO_RCVBUF)，TCP的全雙工的工作模式以及TCP的滑動窗口便是依賴于這兩個獨立的buffer的填充狀態。
SO_SNDBUF：
進程發送的數據的時候假設調用了一個send方法，最簡單情況(也是一般情況)，將數據拷貝進入socket的內核發送緩沖區之中，然后send便會在上層返回。換句話說，send返回之時，數據不一定會發送到對端去(和write寫文件有點類似)，send僅僅是把應用層buffer的數據拷貝進socket的內核發送buffer中。
SO_RCVBUF：
把接受到的數據緩存入內核，應用進程一直沒有調用read進行讀取的話，此數據會一直緩存在相應socket的接收緩沖區內。再啰嗦一點，不管進程是否讀取socket，對端發來的數據都會經由內核接收并且緩存到socket的內核接收緩沖區之中。read所做的工作，就是把內核緩沖區中的數據拷貝到應用層用戶的buffer里面，僅此而已。
滑動窗口：
TCP連接在三次握手的時候，會將自己的窗口大小(window size)發送給對方，其實就是SO_RCVBUF指定的值。之后在發送數據的時，發送方必須要先確認接收方的窗口沒有被填充滿，如果沒有填滿，則可以發送。
每次發送數據后，發送方將自己維護的對方的window size減小，表示對方的SO_RCVBUF可用空間變小。
當接收方處理開始處理SO_RCVBUF 中的數據時，會將數據從socket 在內核中的接受緩沖區讀出，此時接收方的SO_RCVBUF可用空間變大，即window size變大，接受方會以ack消息的方式將自己最新的window size返回給發送方，此時發送方將自己的維護的接受的方的window size設置為ack消息返回的window size。
此外，發送方可以連續的給接受方發送消息，只要保證對方的SO_RCVBUF空間可以緩存數據即可，即window size>0。當接收方的SO_RCVBUF被填充滿時，此時window size=0，發送方不能再繼續發送數據，要等待接收方ack消息，以獲得最新可用的window size。
2.2 MSS/MTU分片
MTU (Maxitum Transmission Unit,最大傳輸單元)是鏈路層對一次可以發送的最大數據的限制。MSS(Maxitum Segment Size,最大分段大小)是TCP報文中data部分的最大長度，是傳輸層對一次可以發送的最大數據的限制。
要了解MSS/MTU，首先需要回顧一下TCP/IP五層網絡模型模型。
數據在傳輸過程中，每經過一層，都會加上一些額外的信息：
- 應用層：只關心發送的數據DATA，將數據寫入socket在內核中的緩沖區SO_SNDBUF即返回，操作系統會將SO_SNDBUF中的數據取出來進行發送。
- 傳輸層：會在DATA前面加上TCP Header(20字節)
- 網絡層：會在TCP報文的基礎上再添加一個IP Header，也就是將自己的網絡地址加入到報文中。IPv4中IP Header長度是20字節，IPV6中IP Header長度是40字節。
- 鏈路層：加上Datalink Header和CRC。會將SMAC(Source Machine，數據發送方的MAC地址)，DMAC(Destination Machine，數據接受方的MAC地址 )和Type域加入。SMAC+DMAC+Type+CRC總長度為18字節。
- 物理層：進行傳輸
在回顧這個基本內容之后，再來看MTU和MSS。MTU是以太網傳輸數據方面的限制，每個以太網幀最大不能超過1518bytes。刨去以太網幀的幀頭(DMAC+SMAC+Type域)14Bytes和幀尾(CRC校驗)4Bytes，那么剩下承載上層協議的地方也就是Data域最大就只能有1500Bytes這個值 我們就把它稱之為MTU。
MSS是在MTU的基礎上減去網絡層的IP Header和傳輸層的TCP Header的部分，這就是TCP協議一次可以發送的實際應用數據的最大大小。
- MSS = MTU(1500) -IP Header(20 or 40)-TCP Header(20)
由于IPV4和IPV6的長度不同，在IPV4中，以太網MSS可以達到1460byte;在IPV6中，以太網MSS可以達到1440byte。
發送方發送數據時，當SO_SNDBUF中的數據量大于MSS時，操作系統會將數據進行拆分，使得每一部分都小于MSS，也形成了拆包，然后每一部分都加上TCP Header，構成多個完整的TCP報文進行發送，當然經過網絡層和數據鏈路層的時候，還會分別加上相應的內容。
另外需要注意的是：對于本地回環地址(lookback)不需要走以太網，所以不受到以太網MTU=1500的限制。linux服務器上輸入ifconfig命令，可以查看不同網卡的MTU大小，如下：
上圖顯示了2個網卡信息：
- eth0需要走以太網，所以MTU是1500;
- lo是本地回環，不需要走以太網，所以不受1500的限制。
2.3 Nagle算法
TCP/IP協議中，無論發送多少數據，總是要在數據(DATA)前面加上協議頭(TCP Header+IP Header)，同時，對方接收到數據，也需要發送ACK表示確認。
即使從鍵盤輸入的一個字符，占用一個字節，可能在傳輸上造成41字節的包，其中包括1字節的有用信息和40字節的首部數據。這種情況轉變成了4000%的消耗，這樣的情況對于重負載的網絡來是無法接受的。稱之為"糊涂窗口綜合征"。
為了盡可能的利用網絡帶寬，TCP總是希望盡可能的發送足夠大的數據。(一個連接會設置MSS參數，因此，TCP/IP希望每次都能夠以MSS尺寸的數據塊來發送數據)。Nagle算法就是為了盡可能發送大塊數據，避免網絡中充斥著許多小數據塊。
Nagle算法的基本定義是任意時刻，最多只能有一個未被確認的小段。 所謂“小段”，指的是小于MSS尺寸的數據塊，所謂“未被確認”，是指一個數據塊發送出去后，沒有收到對方發送的ACK確認該數據已收到。
Nagle算法的規則：
- 如果SO_SNDBUF中的數據長度達到MSS，則允許發送;
- 如果該SO_SNDBUF中含有FIN，表示請求關閉連接，則先將SO_SNDBUF中的剩余數據發送，再關閉;
- 設置了TCP_NODELAY=true選項，則允許發送。TCP_NODELAY是取消TCP的確認延遲機制，相當于禁用了Negale 算法。正常情況下，當Server端收到數據之后，它并不會馬上向client端發送ACK，而是會將ACK的發送延遲一段時間(假一般是40ms)，它希望在t時間內server端會向client端發送應答數據，這樣ACK就能夠和應答數據一起發送，就像是應答數據捎帶著ACK過去。當然，TCP確認延遲40ms并不是一直不變的，TCP連接的延遲確認時間一般初始化為最小值40ms，隨后根據連接的重傳超時時間(RTO)、上次收到數據包與本次接收數據包的時間間隔等參數進行不斷調整。另外可以通過設置TCP_QUICKACK選項來取消確認延遲。
- 未設置TCP_CORK選項時，若所有發出去的小數據包(包長度小于MSS)均被確認，則允許發送;
- 上述條件都未滿足，但發生了超時(一般為200ms)，則立即發送。
3 通信協議
在了解了粘包、拆包產生的原因之后，現在來分析接收方如何對此進行區分。道理很簡單，如果存在不完整的數據(拆包)，則需要繼續等待數據，直至可以構成一條完整的請求或者響應。
通過定義通信協議(protocol)，可以解決粘包、拆包問題。協議的作用就定義傳輸數據的格式。這樣在接受到的數據的時候：
如果粘包了，就可以根據這個格式來區分不同的包
如果拆包了，就等待數據可以構成一個完整的消息來處理。
3.1 定長協議
定長協議：顧名思義，就是指定一個報文的必須具有固定的長度。例如，我們規定每3個字節，表示一個有效報文，如果我們分4次總共發送以下9個字節：
- +---+----+------+----+
- | A | BC | DEFG | HI |
- +---+----+------+----+
那么根據協議，我們可以判斷出來，這里包含了3個有效的請求報文，如下：
- +-----+-----+-----+
- | ABC | DEF | GHI |
- +-----+-----+-----+
在定長協議中：
- 發送方，必須保證發送報文長度是固定的。如果報文字節長度不能滿足條件，如規定長度是1024字節，但是實際需要發送的內容只有900個字節，那么不足的部分可以補充0。因此定長協議可能會浪費帶寬。
- 接收方，每讀取到固定長度的內容時，則認為讀取到了一個完整的報文。
提示：Netty中提供了FixedLengthFrameDecoder，支持把固定的長度的字節數當做一個完整的消息進行解碼
3.2 特殊字符分隔符協議
在包尾部增加回車或者空格符等特殊字符進行分割 。例如，按行解析，遇到字符\n、\r\n的時候，就認為是一個完整的數據包。對于以下二進制字節流：
- +--------------+
- | ABC\nDEF\r\n |
- +--------------+
那么根據協議，我們可以判斷出來，這里包含了2個有效的請求報文
- +-----+-----+
- | ABC | DEF |
- +-----+-----+
在特殊字符分隔符協議中：
- 發送方，需要在發送一個報文時，需要在報文尾部添加特殊分割符號;
- 接收方，在接收到報文時，需要對特殊分隔符進行檢測，直到檢測到一個完整的報文時，才能進行處理。
在使用特殊字符分隔符協議的時候，需要注意的是，我們選擇的特殊字符，一定不能在消息體中出現，否則可能會出現錯誤的拆包。例如，發送方希望把”12\r\n34”，當成一個完整的報文，如果是按行拆分，那么就會錯誤的拆分為2個報文。一種解決策略是，發送方對需要發送的內容預先進行base64編碼，由于base64編碼只包含64個字符：0-9、a-z、A-Z、+、/，我們可以選擇這64個字符之外的特殊字符作為分隔符。
提示：netty中提供了DelimiterBasedFrameDecoder根據特殊字符進行解碼。事實上，我們熟悉的的緩存服務器redis，也是通過換行符來區分一個完整的報文。
3.3 變長協議
將消息區分為消息頭和消息體，在消息頭中，我們使用一個整形數字，例如一個int，來表示消息體的長度。而消息體實際實際要發送的二進制數據字節。以下是一個基本格式：
- header body
- +--------+----------+
- | Length | Content |
- +--------+----------+
在變長協議中：
- 發送方，發送數據之前，需要先獲取需要發送內容的二進制字節大小，然后在需要發送的內容前面添加一個整數，表示消息體二進制字節的長度。
- 接收方，在解析時，先讀取內容長度Length，其值為實際消息體內容(Content)占用的字節數，之后必須讀取到這么多字節的內容，才認為是一個完整的數據報文。
提示：Netty中提供了LengthFieldPrepender給實際內容Content進行編碼添加Length字段，接受方使用LengthFieldBasedFrameDecoder解碼。
3.4 序列化
序列化本質上已經不是為了解決粘包和拆包問題，而是為了在網絡開發中可以更加的便捷。在變長協議中，我們看到可以在實際要發送的數據之前加上一個length字段，表示實際要發送的數據的長度。這實際上給我們了一個很好的思路，我們完全可以將一個對象轉換成二進制字節，來進行通信，例如使用一個Request對象表示請求，使用一個Response對象表示響應。
序列化框架有很多種，我們在選擇時，主要考慮序列化/反序列化的速度，序列化占用的體積，多語言支持等。下面列出了業界流行的序列化框架：
提示：xml、json也屬于序列化框架的范疇，上面的表格中并沒有列出。
一些網絡通信的RPC框架通常會支持多種序列化方式，例如dubbo支持hessian、json、kyro、fst等。在支持多種序列化框架的情況下，在協議中通常需要有一個字段來表示序列化的類型，例如，我們可以將上述變長協議的格式改造為：
- +--------+-------------+------------+
- | Length | serializer | Content |
- +--------+-------------+------------+
這里使用1個字節表示Serializer的值，使用不同的值代表不同的框架。
發送方，選擇好序列化框架后編碼后，需要指定Serializer字段的值。
接收方，在解碼時，根據Serializer的值選擇對應的框架進行反序列化;
3.5 壓縮
通常，為了節省網絡開銷，在網絡通信時，可以考慮對數據進行壓縮。常見的壓縮算法有lz4、snappy、gzip等。在選擇壓縮算法時，我們主要考慮壓縮比以及解壓縮的效率。
我們可以在網絡通信協議中，添加一個compress字段，表示采用的壓縮算法：
- +--------+-----------+------------+------------+
- | Length | serializer| compress | Content |
- +--------+-----------+------------+------------+
通常，我們沒有必要使用一個字節，來表示采用的壓縮算法，1個字節可以標識256種可能情況，而常用壓縮算法也就那么幾種，因此通常只需要使用2~3個bit來表示采用的壓縮算法即可。
另外，由于數據量比較小的時候，壓縮比并不會太高，沒有必要對所有發送的數據都進行壓縮，只有再超過一定大小的情況下，才考慮進行壓縮。如rocketmq，producer在發送消息時，默認消息大小超過4k，才會進行壓縮。因此，compress字段，應該有一個值，表示沒有使用任何壓縮算法，例如使用0。
3.6 查錯校驗碼
一些通信協議傳輸的數據中，還包含了查錯校驗碼。典型的算法如CRC32、Adler32等。java對這兩種校驗方式都提供了支持，java.util.zip.Adler32、java.util.zip.CRC32。
- +--------+-----------+------------+------------+---------+
- | Length | serializer| compress | Content | CRC32 |
- +--------+-----------+------------+------------+---------+
這里并不對CRC32、Adler32進行詳細說明，主要是考慮，為什么需要進行校驗?
有人說是因為考慮到安全，這個理由似乎并不充分，因為我們已經有了TLS層的加密，CRC32、Adler32的作用不應該是為了考慮安全。
一位同事的觀點，我非常贊同：二進制數據在傳輸的過程中，可能因為電磁干擾，導致一個高電平變成低電平，或者低電平變成高電平。這種情況下，數據相當于受到了污染，此時通過CRC32等校驗值，則可以驗證數據的正確性。
另外，通常校驗機制在通信協議中，是可選的配置的，并不需要強制開啟，其雖然可以保證數據的正確，但是計算校驗值也會帶來一些額外的性能損失。如Mysql主從同步，雖然高版本默認開啟CRC32校驗，但是也可以通過配置禁用。
3.7 小結
本節通過一些基本的案例，講解了在TCP編程中，如何通過協議來解決粘包、拆包問題。在實際開發中，通常我們的協議會更加復雜。例如，一些RPC框架，會在協議中添加唯一標識一個請求的ID，一些支持雙向通信的RPC框架，如sofa-bolt，還會添加一個方向信息等。當然，所謂復雜，無非是在協議中添加了某個字段用于某個用途，只要弄清楚這些字段的含義，也就不復雜了。
