Netty源碼分析——拆包器之LineBasedFrameDecoder

基于Netty源代碼版本:netty-all-4.1.33.Final

前言

什么是粘包、拆包
粘包、拆包是Socket編程中最常遇見的一個問題,本文來研究一下Netty是如何解決粘包、拆包的,首先我們從什么是粘包、拆包開始說起:

TCP是個"流"協議,所謂流,就是沒有界限的一串數據,TCP底層并不了解上層業務的具體含義,它會根據TCP緩沖區的實際情況進行包的劃分,所以在業務上:</pre>

  • 一個完整的包可能會被TCP拆分為多個包進行發送(拆包)
  • 多個小的包也有可能被封裝成一個大的包進行發送(粘包)
    這就是所謂的TCP粘包與拆包

下圖演示了粘包、拆包的場景:


基本上有四種情況:

  • Data1、Data2都分開發送到了Server端,沒有產生粘包與拆包的情況
  • Data1、Data2數據粘在了一起,打成了一個大的包發送到了Server端,這種情況就是粘包
  • Data1被分成Data1_1與Data1_2,Data1_1先到服務端,Data1_2與Data2再到服務端,這種情況就是拆包
  • Data2被分成Data2_1與Data2_2,Data1與Data2_1先到服務端,Data2_2再到服務端,同上,這也是一種拆包的場景

粘包、拆包產生的原因
上面我們詳細了解了TCP粘包與拆包,那么粘包與拆包為什么會發生呢,大致上有三種原因:

  • 應用程序寫入的字節大小大于Socket發送緩沖區大小
  • 進行MSS大小的TCP,MSS是最大報文段長度的縮寫,是TCP報文段中的數據字段最大長度,MSS=TCP報文段長度-TCP首部長度
  • 以太網的Payload大于MTU,進行IP分片,MTU是最大傳輸單元的縮寫,以太網的MTU為1500字節

粘包、拆包解決策略
由于底層的TCP無法理解上層的業務數據,所以在底層是無法保證數據包不被拆分和重組的,這個問題只能通過上層的應用協議棧設計來解決,根據業界的主流協議的解決方案,可以歸納如下:

  • 消息定長,例如每個報文的大小固定為200字節,如果不夠空位補空格
  • 包尾增加回車換行符進行分割,例如FTP協議
  • 將消息分為消息頭和消息體,消息頭中包含表示長度的字段,通常涉及思路為消息頭的第一個字段使用int32來表示消息的總長度
  • 更復雜的應用層協議

Netty中內置了多個編解碼器,可以很簡單的處理包界限問題。典型的幾個:

  • LengthFieldBasedFrameDecoder
    通過在包頭增加消息體長度的解碼器,解析數據時首先獲取首部長度,然后定長讀取socket中的數據。
  • LineBasedFrameDecoder
    換行符解碼器,報文尾部增加固定換行符rn,解析數據時以換行符作為報文結尾。
  • DelimiterBasedFrameDecoder
    分隔符解碼器,使用特定分隔符作為報文的結尾,解析數據時以定義的分隔符作為報文結尾
  • FixedLengthFrameDecoder
    定長解碼器,這個最簡單,消息體固定長度,解析數據時按長度讀取即可

本文介紹 LineBasedFrameDecoder,換行符解碼器。

行拆包器

下面,以一個具體的例子來看看業netty自帶的拆包器是如何來拆包的

這個類叫做 LineBasedFrameDecoder,基于行分隔符的拆包器,TA可以同時處理 \n以及\r\n兩種類型的行分隔符,核心方法都在繼承的 decode 方法中

@Override
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 中自帶的拆包器都是如上這種模板,我們來看看decode(ctx, in);

public class LineBasedFrameDecoder extends ByteToMessageDecoder {
    protected Object decode(ChannelHandlerContext ctx, ByteBuf buffer) throws Exception {
        final int eol = findEndOfLine(buffer);
        if (!discarding) {
            if (eol >= 0) {
                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;
            } else {
                final int length = buffer.readableBytes();
                if (length > maxLength) {
                    discardedBytes = length;
                    buffer.readerIndex(buffer.writerIndex());
                    discarding = true;
                    offset = 0;
                    if (failFast) {
                        fail(ctx, "over " + discardedBytes);
                    }
                }
                return null;
            }
        } else {
            if (eol >= 0) {
                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);
                }
            } else {
                discardedBytes += buffer.readableBytes();
                buffer.readerIndex(buffer.writerIndex());
                // We skip everything in the buffer, we need to set the offset to 0 again.
                offset = 0;
            }
            return null;
        }
    }

    private int findEndOfLine(final ByteBuf buffer) {
        int totalLength = buffer.readableBytes();
        int i = buffer.forEachByte(buffer.readerIndex() + offset, totalLength - offset, ByteProcessor.FIND_LF);
        if (i >= 0) {
            offset = 0;
            if (i > 0 && buffer.getByte(i - 1) == '\r') {
                i--;
            }
        } else {
            offset = totalLength;
        }
        return i;
    }
}

public interface ByteProcessor {
    /**
     * Aborts on a {@code LF ('\n')}.
     */
    ByteProcessor FIND_LF = new IndexOfProcessor(LINE_FEED);
}

找到換行符位置

public class LineBasedFrameDecoder extends ByteToMessageDecoder {
    protected Object decode(ChannelHandlerContext ctx, ByteBuf buffer) throws Exception {
        final int eol = findEndOfLine(buffer);
        ......
    }

    private int findEndOfLine(final ByteBuf buffer) {
        int totalLength = buffer.readableBytes();
        int i = buffer.forEachByte(buffer.readerIndex() + offset, totalLength - offset, ByteProcessor.FIND_LF);
        if (i >= 0) {
            offset = 0;
            if (i > 0 && buffer.getByte(i - 1) == '\r') {
                i--;
            }
        } else {
            offset = totalLength;
        }
        return i;
    }
}

public interface ByteProcessor {
    /**
     * Aborts on a {@code LF ('\n')}.
     */
    ByteProcessor FIND_LF = new IndexOfProcessor(LINE_FEED);
}

for循環遍歷,找到第一個 \n 的位置,如果\n前面的字符為\r,那就返回\r的位置

非discarding模式的處理
接下來,netty會判斷,當前拆包是否屬于丟棄模式,用一個成員變量來標識

/** 
 * True if we're discarding input because we're already over maxLength.  
 */
private boolean discarding;

第一次拆包不在discarding模式

非discarding模式下找到行分隔符的處理

if (!discarding) {
    if (eol >= 0) {
        // 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,即解析出來的包包含分隔符,默認為不包含分隔符

非discarding模式下未找到分隔符的處理

沒有找到對應的行分隔符,說明字節容器沒有足夠的數據拼接成一個完整的業務數據包,進入如下流程處理

final int length = buffer.readableBytes();
if (length > maxLength) {
    discardedBytes = length;
    buffer.readerIndex(buffer.writerIndex());
    discarding = true;
    offset = 0;
    if (failFast) {
        fail(ctx, "over " + discardedBytes);
    }
}
return null;

首先取得當前字節容器的可讀字節個數,接著,判斷一下是否已經超過可允許的最大長度,如果沒有超過,直接返回null,字節容器中的數據沒有任何改變,否則,就需要進入丟棄模式

使用一個成員變量 discardedBytes 來表示已經丟棄了多少數據,然后將字節容器的讀指針移到寫指針,意味著丟棄這一部分數據,設置成員變量discarding為true表示當前處于丟棄模式。如果設置了failFast,那么直接拋出異常,默認情況下failFast為false,即安靜得丟棄數據

discarding模式
如果解包的時候處在discarding模式,也會有兩種情況發生

discarding模式下找到行分隔符

在discarding模式下,如果找到分隔符,那可以將分隔符之前的都丟棄掉

if (eol >= 0) {
    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);
    }
}

計算出分隔符的長度之后,直接把分隔符之前的數據全部丟棄,當然丟棄的字符也包括分隔符,經過這么一次丟棄,后面就有可能是正常的數據包,下一次解包的時候就會進入正常的解包流程

discarding模式下未找到行分隔符

這種情況比較簡單,因為當前還在丟棄模式,沒有找到行分隔符意味著當前一個完整的數據包還沒丟棄完,當前讀取的數據是丟棄的一部分,所以直接丟棄

discardedBytes += buffer.readableBytes();
buffer.readerIndex(buffer.writerIndex());
// We skip everything in the buffer, we need to set the offset to 0 again.
offset = 0;

特定分隔符拆包

這個類叫做 DelimiterBasedFrameDecoder,可以傳遞給TA一個分隔符列表,數據包會按照分隔符列表進行拆分,讀者可以完全根據行拆包器的思路去分析這個DelimiterBasedFrameDecoder

參考:
https://www.cnblogs.com/java-chen-hao/p/11445297.html

https://www.cnblogs.com/xrq730/p/8724391.html

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,818評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,185評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,656評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,647評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,446評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,951評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,041評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,189評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,718評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,602評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,800評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,316評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,045評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,419評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,671評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,420評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,755評論 2 371

推薦閱讀更多精彩內容