今天就跟大家聊聊有關(guān)怎樣分析TCP的粘包、拆包以及解決方案，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)建站堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的沐川網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

TCP的粘包、拆包以及解決方案

TCP的粘包和拆包問題往往出現(xiàn)在基于TCP協(xié)議的通訊中，比如RPC框架、Netty等。如果你的簡歷中寫了類似的技術(shù)或者你所面試的公司使用了相關(guān)的技術(shù)，被問到該面試的幾率會非常高。

TCP的粘包和拆包問題往往出現(xiàn)在基于TCP協(xié)議的通訊中，比如RPC框架、Netty等。如果你的簡歷中寫了類似的技術(shù)或者你所面試的公司使用了相關(guān)的技術(shù)，被問到該面試的幾率會非常高。

今天這篇文章就帶大家詳細(xì)了解一下TCP的粘包和拆包以及解決方案。

什么是粘包?

在學(xué)習(xí)粘包之前，先糾正一下讀音，很多視頻教程中將“粘”讀作“nián”。經(jīng)過調(diào)研，個人更傾向于讀“zhān bāo”。

如果在百度百科上搜索“粘包”，對應(yīng)的讀音便是“zhān bāo”，語義解釋為：網(wǎng)絡(luò)技術(shù)術(shù)語。指TCP協(xié)議中，發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時粘成一包，從接收緩沖區(qū)看，后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾。

TCP是面向字節(jié)流的協(xié)議，就是沒有界限的一串?dāng)?shù)據(jù)，本沒有“包”的概念，“粘包”和“拆包”一說是為了有助于形象地理解這兩種現(xiàn)象。

為什么UDP沒有粘包?

粘包拆包問題在數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層以及傳輸層都有可能發(fā)生。日常的網(wǎng)絡(luò)應(yīng)用開發(fā)大都在傳輸層進(jìn)行，由于UDP有消息保護(hù)邊界，不會發(fā)生粘包拆包問題，因此粘包拆包問題只發(fā)生在TCP協(xié)議中

粘包拆包發(fā)生場景

因?yàn)門CP是面向流，沒有邊界，而操作系統(tǒng)在發(fā)送TCP數(shù)據(jù)時，會通過緩沖區(qū)來進(jìn)行優(yōu)化，例如緩沖區(qū)為1024個字節(jié)大小。

如果一次請求發(fā)送的數(shù)據(jù)量比較小，沒達(dá)到緩沖區(qū)大小，TCP則會將多個請求合并為同一個請求進(jìn)行發(fā)送，這就形成了粘包問題。

如果一次請求發(fā)送的數(shù)據(jù)量比較大，超過了緩沖區(qū)大小，TCP就會將其拆分為多次發(fā)送，這就是拆包。

關(guān)于粘包和拆包可以參考下圖的幾種情況：

粘包/拆包

上圖中演示了以下幾種情況：

• 正常的理想情況，兩個包恰好滿足TCP緩沖區(qū)的大小或達(dá)到TCP等待時長，分別發(fā)送兩個包;

• 粘包：兩個包較小，間隔時間短，發(fā)生粘包，合并成一個包發(fā)送;

• 拆包：一個包過大，超過緩存區(qū)大小，拆分成兩個或多個包發(fā)送;

• 拆包和粘包：Packet1過大，進(jìn)行了拆包處理，而拆出去的一部分又與Packet2進(jìn)行粘包處理。

常見的解決方案

對于粘包和拆包問題，常見的解決方案有四種：

• 發(fā)送端將每個包都封裝成固定的長度，比如100字節(jié)大小。如果不足100字節(jié)可通過補(bǔ)0或空等進(jìn)行填充到指定長度;

• 發(fā)送端在每個包的末尾使用固定的分隔符，例如\r\n。如果發(fā)生拆包需等待多個包發(fā)送過來之后再找到其中的\r\n進(jìn)行合并;例如，F(xiàn)TP協(xié)議;

• 將消息分為頭部和消息體，頭部中保存整個消息的長度，只有讀取到足夠長度的消息之后才算是讀到了一個完整的消息;

• 通過自定義協(xié)議進(jìn)行粘包和拆包的處理。

Netty對粘包和拆包問題的處理

Netty對解決粘包和拆包的方案做了抽象，提供了一些解碼器(Decoder)來解決粘包和拆包的問題。如：

• LineBasedFrameDecoder：以行為單位進(jìn)行數(shù)據(jù)包的解碼;

• DelimiterBasedFrameDecoder：以特殊的符號作為分隔來進(jìn)行數(shù)據(jù)包的解碼;

• FixedLengthFrameDecoder：以固定長度進(jìn)行數(shù)據(jù)包的解碼;

• LenghtFieldBasedFrameDecode：適用于消息頭包含消息長度的協(xié)議(最常用);

基于Netty進(jìn)行網(wǎng)絡(luò)讀寫的程序，可以直接使用這些Decoder來完成數(shù)據(jù)包的解碼。對于高并發(fā)、大流量的系統(tǒng)來說，每個數(shù)據(jù)包都不應(yīng)該傳輸多余的數(shù)據(jù)(所以補(bǔ)齊的方式不可取)，LenghtFieldBasedFrameDecode更適合這樣的場景。

TCP協(xié)議粘包拆包問題是因?yàn)門CP協(xié)議數(shù)據(jù)傳輸是基于字節(jié)流的，它不包含消息、數(shù)據(jù)包等概念，需要應(yīng)用層協(xié)議自己設(shè)計消息的邊界，即消息幀(Message Framing)。如果應(yīng)用層協(xié)議沒有使用基于長度或者基于終結(jié)符息邊界等方式進(jìn)行處理，則會導(dǎo)致多個消息的粘包和拆包。

雖然很多框架中都有現(xiàn)成的解決方案，比如Netty，但底層的原理我們還是要清楚的，而且還要知道有這么回事，才能更好的結(jié)合場景進(jìn)行使。

看完上述內(nèi)容，你們對怎樣分析TCP的粘包、拆包以及解決方案有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

文章名稱：怎樣分析TCP的粘包、拆包以及解決方案
路徑分享：http://chinadenli.net/article26/gpcdcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、網(wǎng)站維護(hù)、服務(wù)器托管、微信公眾號、定制網(wǎng)站、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)