為什麼要粘包拆包
為什麼要粘包
首先你得了解一下TCP/IP協議，在使用者資料量非常小的情況下，極端情況下，一個位元組，該TCP資料包的有效載荷非常低，傳遞100位元組的資料，需要100次TCP傳送，100次ACK，在應用及時性要求不高的情況下，將這100個有效資料拼接成一個資料包，那會縮短到一個TCP資料包，以及一個ack，有效載荷提高了，頻寬也節省了
非極端情況，有可能兩個資料包拼接成一個資料包，也有可能一個半的資料包拼接成一個資料包，也有可能兩個半的資料包拼接成一個資料包
為什麼要拆包
拆包和粘包是相對的，一端粘了包，另外一端就需要將粘過的包拆開，舉個栗子，傳送端將三個資料包粘成兩個TCP資料包傳送到接收端，接收端就需要根據應用協議將兩個資料包重新組裝成三個資料包
還有一種情況就是使用者資料包超過了mss(最大報文長度)，那麼這個資料包在傳送的時候必須拆分成幾個資料包，接收端收到之後需要將這些資料包粘合起來之後，再拆開
拆包的原理
在沒有netty的情況下，使用者如果自己需要拆包，基本原理就是不斷從TCP緩衝區中讀取資料，每次讀取完都需要判斷是否是一個完整的資料包
1.如果當前讀取的資料不足以拼接成一個完整的業務資料包，那就保留該資料，繼續從tcp緩衝區中讀取，直到得到一個完整的資料包 2.如果當前讀到的資料加上已經讀取的資料足夠拼接成一個資料包，那就將已經讀取的資料拼接上本次讀取的資料，夠成一個完整的業務資料包傳遞到業務邏輯，多餘的資料仍然保留，以便和下次讀到的資料嘗試拼接
netty中拆包的基類
netty 中的拆包也是如上這個原理，內部會有一個累加器，每次讀取到資料都會不斷累加，然後嘗試對累加到的資料進行拆包，拆成一個完整的業務資料包，這個基類叫做 ByteToMessageDecoder，下面我們先詳細分析下這個類
累加器
ByteToMessageDecoder 中定義了兩個累加器
public static final Cumulator MERGE_CUMULATOR = ...;
public static final Cumulator COMPOSITE_CUMULATOR = ...;
複製程式碼預設情況下，會使用 MERGE_CUMULATOR
private Cumulator cumulator = MERGE_CUMULATOR;
複製程式碼MERGE_CUMULATOR 的原理是每次都將讀取到的資料通過記憶體拷貝的方式，拼接到一個大的位元組容器中，這個位元組容器在 ByteToMessageDecoder中叫做 cumulation
ByteBuf cumulation;
複製程式碼下面我們看一下 MERGE_CUMULATOR 是如何將新讀取到的資料累加到位元組容器裡的
public ByteBuf cumulate(ByteBufAllocator alloc, ByteBuf cumulation, ByteBuf in) {
ByteBuf buffer;
if (cumulation.writerIndex() > cumulation.maxCapacity() - in.readableBytes()
|| cumulation.refCnt() > 1) {
buffer = expandCumulation(alloc, cumulation, in.readableBytes());
} else {
buffer = cumulation;
}
buffer.writeBytes(in);
in.release();
return buffer;
}
複製程式碼netty 中ByteBuf的抽象，使得累加非常簡單，通過一個簡單的api呼叫 buffer.writeBytes(in); 便將新資料累加到位元組容器中，為了防止位元組容器大小不夠，在累加之前還進行了擴容處理
static ByteBuf expandCumulation(ByteBufAllocator alloc, ByteBuf cumulation, int readable) {
ByteBuf oldCumulation = cumulation;
cumulation = alloc.buffer(oldCumulation.readableBytes() + readable);
cumulation.writeBytes(oldCumulation);
oldCumulation.release();
return cumulation;
}
複製程式碼擴容也是一個記憶體拷貝操作，新增的大小即是新讀取資料的大小
拆包抽象
累加器原理清楚之後，下面我們回到主流程，目光集中在 channelRead 方法，channelRead方法是每次從TCP緩衝區讀到資料都會呼叫的方法，觸發點在AbstractNioByteChannel的read方法中，裡面有個while迴圈不斷讀取，讀取到一次就觸發一次channelRead
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
if (msg instanceof ByteBuf) {
CodecOutputList out = CodecOutputList.newInstance();
try {
ByteBuf data = (ByteBuf) msg;
first = cumulation == null;
if (first) {
cumulation = data;
} else {
cumulation = cumulator.cumulate(ctx.alloc(), cumulation, data);
}
callDecode(ctx, cumulation, out);
} catch (DecoderException e) {
throw e;
} catch (Throwable t) {
throw new DecoderException(t);
} finally {
if (cumulation != null && !cumulation.isReadable()) {
numReads = 0;
cumulation.release();
cumulation = null;
} else if (++ numReads >= discardAfterReads) {
numReads = 0;
discardSomeReadBytes();
}
int size = out.size();
decodeWasNull = !out.insertSinceRecycled();
fireChannelRead(ctx, out, size);
out.recycle();
}
} else {
ctx.fireChannelRead(msg);
}
}
複製程式碼方法體不長不短，可以分為以下幾個邏輯步驟
1.累加資料 2.將累加到的資料傳遞給業務進行業務拆包 3.清理位元組容器 4.傳遞業務資料包給業務解碼器處理
###1 累加資料
如果當前累加器沒有資料，就直接跳過記憶體拷貝，直接將位元組容器的指標指向新讀取的資料，否則，呼叫累加器累加資料至位元組容器
ByteBuf data = (ByteBuf) msg;
first = cumulation == null;
if (first) {
cumulation = data;
} else {
cumulation = cumulator.cumulate(ctx.alloc(), cumulation, data);
}
複製程式碼2 將累加到的資料傳遞給業務進行拆包
到這一步，位元組容器裡的資料已是目前未拆包部分的所有的資料了
CodecOutputList out = CodecOutputList.newInstance();
callDecode(ctx, cumulation, out);
複製程式碼callDecode 將嘗試將位元組容器的資料拆分成業務資料包塞到業務資料容器out中
protected void callDecode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {
while (in.isReadable()) {
// 記錄一下位元組容器中有多少位元組待拆
int oldInputLength = in.readableBytes();
decode(ctx, in, out);
if (out.size() == 0) {
// 拆包器未讀取任何資料
if (oldInputLength == in.readableBytes()) {
break;
} else {
// 拆包器已讀取部分資料，還需要繼續
continue;
}
}
if (oldInputLength == in.readableBytes()) {
throw new DecoderException(
StringUtil.simpleClassName(getClass()) +
".decode() did not read anything but decoded a message.");
}
if (isSingleDecode()) {
break;
}
}
}
複製程式碼我將原始程式碼做了一些精簡，在解碼之前，先記錄一下位元組容器中有多少位元組待拆，然後呼叫抽象函式 decode 進行拆包
protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception;
複製程式碼netty中對各種使用者協議的支援就體現在這個抽象函式中，傳進去的是當前讀取到的未被消費的所有的資料，以及業務協議包容器，所有的拆包器最終都實現了該抽象方法
業務拆包完成之後，如果發現並沒有拆到一個完整的資料包，這個時候又分兩種情況
1.一個是拆包器什麼資料也沒讀取，可能資料還不夠業務拆包器處理，直接break等待新的資料 2.拆包器已讀取部分資料，說明解碼器仍然在工作，繼續解碼
業務拆包完成之後，如果發現已經解到了資料包，但是，發現並沒有讀取任何資料，這個時候就會丟擲一個Runtime異常 DecoderException，告訴你，你什麼資料都沒讀取，卻解析出一個業務資料包，這是有問題的
3 清理位元組容器
業務拆包完成之後，只是從位元組容器中取走了資料，但是這部分空間對於位元組容器來說依然保留著，而位元組容器每次累加位元組資料的時候都是將位元組資料追加到尾部，如果不對位元組容器做清理，那麼時間一長就會OOM
正常情況下，其實每次讀取完資料，netty都會在下面這個方法中將位元組容器清理，只不過，當傳送端傳送資料過快，channelReadComplete可能會很久才被呼叫一次
public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
numReads = 0;
discardSomeReadBytes();
if (decodeWasNull) {
decodeWasNull = false;
if (!ctx.channel().config().isAutoRead()) {
ctx.read();
}
}
ctx.fireChannelReadComplete();
}
複製程式碼這裡順帶插一句，如果一次資料讀取完畢之後(可能接收端一邊收，傳送端一邊發，這裡的讀取完畢指的是接收端在某個時間不再接受到資料為止），發現仍然沒有拆到一個完整的使用者資料包，即使該channel的設定為非自動讀取，也會觸發一次讀取操作 ctx.read()，該操作會重新向selector註冊op_read事件，以便於下一次能讀到資料之後拼接成一個完整的資料包
所以為了防止傳送端傳送資料過快，netty會在每次讀取到一次資料，業務拆包之後對位元組位元組容器做清理，清理部分的程式碼如下
if (cumulation != null && !cumulation.isReadable()) {
numReads = 0;
cumulation.release();
cumulation = null;
} else if (++ numReads >= discardAfterReads) {
numReads = 0;
discardSomeReadBytes();
}
複製程式碼如果位元組容器當前已無資料可讀取，直接銷燬位元組容器，並且標註一下當前位元組容器一次資料也沒讀取
如果連續16次（discardAfterReads的預設值），位元組容器中仍然有未被業務拆包器讀取的資料，那就做一次壓縮，有效資料段整體移到容器首部
discardSomeReadBytes之前，位元組累加器中的資料分佈
+--------------+----------+----------+
| readed | unreaded | writable |
+--------------+----------+----------+
複製程式碼discardSomeReadBytes之後，位元組容器中的資料分佈
+----------+-------------------------+
| unreaded | writable |
+----------+-------------------------+
複製程式碼這樣位元組容器又可以承載更多的資料了
4 傳遞業務資料包給業務解碼器處理
以上三個步驟完成之後，就可以將拆成的包丟到業務解碼器處理了，程式碼如下
int size = out.size();
decodeWasNull = !out.insertSinceRecycled();
fireChannelRead(ctx, out, size);
out.recycle();
複製程式碼期間用一個成員變數 decodeWasNull 來標識本次讀取資料是否拆到一個業務資料包，然後呼叫 fireChannelRead 將拆到的業務資料包都傳遞到後續的handler
static void fireChannelRead(ChannelHandlerContext ctx, CodecOutputList msgs, int numElements) {
for (int i = 0; i < numElements; i ++) {
ctx.fireChannelRead(msgs.getUnsafe(i));
}
}
複製程式碼這樣，就可以把一個個完整的業務資料包傳遞到後續的業務解碼器進行解碼，隨後處理業務邏輯
行拆包器
下面，以一個具體的例子來看看業netty自帶的拆包器是如何來拆包的
這個類叫做 LineBasedFrameDecoder，基於行分隔符的拆包器，TA可以同時處理 \n以及\r\n兩種型別的行分隔符，核心方法都在繼承的 decode 方法中
protected final void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
Object decoded = decode(ctx, in);
if (decoded != null) {
out.add(decoded);
}
}
複製程式碼netty 中自帶的拆包器都是如上這種模板，其實可以加一層，把這這層模板抽取出來的，不知道為什麼netty沒有這麼做，我們接著跟進去，程式碼比較長，我們還是分模組來剖析
###1 找到換行符位置
final int eol = findEndOfLine(buffer);
private static int findEndOfLine(final ByteBuf buffer) {
int i = buffer.forEachByte(ByteProcessor.FIND_LF);
if (i > 0 && buffer.getByte(i - 1) == '\r') {
i--;
}
return i;
}
ByteProcessor FIND_LF = new IndexOfProcessor((byte) '\n');
複製程式碼for迴圈遍歷，找到第一個 \n 的位置,如果\n前面的字元為\r，那就返回\r的位置
###2 非discarding模式的處理 接下來，netty會判斷，當前拆包是否屬於丟棄模式，用一個成員變數來標識
private boolean discarding;
複製程式碼第一次拆包不在discarding模式（ 後面的分支會講何為非discarding模式），於是進入以下環節
####2.1 非discarding模式下找到行分隔符的處理
// 1.計算分隔符和包長度
final ByteBuf frame;
final int length = eol - buffer.readerIndex();
final int delimLength = buffer.getByte(eol) == '\r'? 2 : 1;
// 丟棄異常資料
if (length > maxLength) {
buffer.readerIndex(eol + delimLength);
fail(ctx, length);
return null;
}
// 取包的時候是否包括分隔符
if (stripDelimiter) {
frame = buffer.readRetainedSlice(length);
buffer.skipBytes(delimLength);
} else {
frame = buffer.readRetainedSlice(length + delimLength);
}
return frame;
複製程式碼1.首先，新建一個幀，計算一下當前包的長度和分隔符的長度（因為有兩種分隔符）
2.然後判斷一下需要拆包的長度是否大於該拆包器允許的最大長度(maxLength)，這個引數在建構函式中被傳遞進來，如超出允許的最大長度，就將這段資料拋棄，返回null
3.最後，將一個完整的資料包取出，如果構造本解包器的時候指定 stripDelimiter為false，即解析出來的包包含分隔符，預設為不包含分隔符
####2.2 非discarding模式下未找到分隔符的處理 沒有找到對應的行分隔符，說明位元組容器沒有足夠的資料拼接成一個完整的業務資料包，進入如下流程處理
final int length = buffer.readableBytes();
if (length > maxLength) {
discardedBytes = length;
buffer.readerIndex(buffer.writerIndex());
discarding = true;
if (failFast) {
fail(ctx, "over " + discardedBytes);
}
}
return null;
複製程式碼首先取得當前位元組容器的可讀位元組個數，接著，判斷一下是否已經超過可允許的最大長度，如果沒有超過，直接返回null，位元組容器中的資料沒有任何改變，否則，就需要進入丟棄模式
使用一個成員變數 discardedBytes 來表示已經丟棄了多少資料，然後將位元組容器的讀指標移到寫指標，意味著丟棄這一部分資料，設定成員變數discarding為true表示當前處於丟棄模式。如果設定了failFast，那麼直接丟擲異常，預設情況下failFast為false，即安靜得丟棄資料
###3 discarding模式 如果解包的時候處在discarding模式，也會有兩種情況發生
####3.1 discarding模式下找到行分隔符
在discarding模式下，如果找到分隔符，那可以將分隔符之前的都丟棄掉
final int length = discardedBytes + eol - buffer.readerIndex();
final int delimLength = buffer.getByte(eol) == '\r'? 2 : 1;
buffer.readerIndex(eol + delimLength);
discardedBytes = 0;
discarding = false;
if (!failFast) {
fail(ctx, length);
}
複製程式碼計算出分隔符的長度之後，直接把分隔符之前的資料全部丟棄，當然丟棄的字元也包括分隔符，經過這麼一次丟棄，後面就有可能是正常的資料包，下一次解包的時候就會進入正常的解包流程
3.2discarding模式下未找到行分隔符
這種情況比較簡單，因為當前還在丟棄模式，沒有找到行分隔符意味著當前一個完整的資料包還沒丟棄完，當前讀取的資料是丟棄的一部分，所以直接丟棄
discardedBytes += buffer.readableBytes();
buffer.readerIndex(buffer.writerIndex());
複製程式碼特定分隔符拆包
這個類叫做 DelimiterBasedFrameDecoder，可以傳遞給TA一個分隔符列表，資料包會按照分隔符列表進行拆分，讀者可以完全根據行拆包器的思路去分析這個DelimiterBasedFrameDecoder，這裡不在贅述，有問題可以留言
總結
netty中的拆包過程其實是和你自己去拆包過程一樣，只不過TA將拆包過程中邏輯比較獨立的部分抽象出來變成幾個不同層次的類，方便各種協議的擴充套件，我們平時在寫程式碼過程中，也必須培養這種抽象能力，這樣你的coding水平才會不斷提高，完。
如果你想系統地學Netty，我的小冊《Netty 入門與實戰：仿寫微信 IM 即時通訊系統》可以幫助你
如果你想系統學習Netty原理，那麼你一定不要錯過我的Netty原始碼分析系列視訊：Java 讀原始碼之 Netty 深入剖析
