快捷導(dǎo)航

基于TCP通信丟包原因總結(jié)(推薦)

更新時(shí)間：2017年08月02日 08:02:27 投稿：jingxian

下面小編就為大家?guī)硪黄赥CP通信丟包原因總結(jié)(推薦)。小編覺得挺不錯(cuò)的，現(xiàn)在就分享給大家，也給大家做個(gè)參考。一起跟隨小編過來看看吧

公司的項(xiàng)目底層，是使用的TCP，因?yàn)榭煽浚詣?dòng)斷線重連，在底層都實(shí)現(xiàn)了，但是我記得TCP也會(huì)有掉包的問題，所以這文章就誕生了——關(guān)于TCP掉包的問題，TCP是基于不可靠的網(wǎng)絡(luò)實(shí)現(xiàn)可靠的傳輸，肯定也會(huì)存在掉包的情況。

如果通信中發(fā)現(xiàn)缺少數(shù)據(jù)或者丟包，那么，最大的可能在于程序發(fā)送的過程或者接收的過程出現(xiàn)問題。

例如服務(wù)器給客戶端發(fā)大量數(shù)據(jù)，Send的頻率很高，那么就有可能在Send時(shí)發(fā)生錯(cuò)誤（原因可能是又多種，可能是程序處理邏輯問題，多線程同步問題，緩沖區(qū)溢出問題等等），如果沒有對(duì)Send失敗做處理重發(fā)數(shù)據(jù)，那么客戶端收到的數(shù)據(jù)就會(huì)比理論應(yīng)該收到的少，就會(huì)造成丟數(shù)據(jù)，丟包的現(xiàn)象。

這種現(xiàn)象，其實(shí)本質(zhì)上來說不是丟包，也不是丟數(shù)據(jù)，只是因?yàn)槌绦蛱幚碛绣e(cuò)誤，導(dǎo)致有些數(shù)據(jù)沒有成功地被socket發(fā)送出去。

常用的解決方法如下：拆包、加包頭、發(fā)送，組合包，如果客戶端、服務(wù)端掉線，常采用心跳測(cè)試。

tcp是一個(gè)“流”的協(xié)議，一個(gè)完整的包可能會(huì)被TCP拆分成多個(gè)包進(jìn)行發(fā)送，也可能把小的封裝成一個(gè)大的數(shù)據(jù)包發(fā)送，這就是所謂的TCP粘包和拆包問題。

粘包、拆包問題說明

假設(shè)客戶端分別發(fā)送數(shù)據(jù)包D1和D2給服務(wù)端，由于服務(wù)端一次性讀取到的字節(jié)數(shù)是不確定的，所以可能存在以下4種情況。

1.服務(wù)端分2次讀取到了兩個(gè)獨(dú)立的包，分別是D1,D2,沒有粘包和拆包；

2.服務(wù)端一次性接收了兩個(gè)包，D1和D2粘在一起了，被成為TCP粘包;

3.服務(wù)端分2次讀取到了兩個(gè)數(shù)據(jù)包，第一次讀取到了完整的D1和D2包的部分內(nèi)容,第二次讀取到了D2包的剩余內(nèi)容，這被稱為拆包；

4.服務(wù)端分2次讀取到了兩個(gè)數(shù)據(jù)包，第一次讀取到了部分D1，第二次讀取D1剩余的部分和完整的D2包；

如果此時(shí)服務(wù)端TCP接收滑動(dòng)窗非常小,而數(shù)據(jù)包D1和D2都很大，很有可能發(fā)送第五種可能，即服務(wù)端多次才能把D1和D2接收完全，期間多次發(fā)生拆包情況。（TCP接收滑動(dòng)窗：是接收端的大小，隨著流量大小而變化，如果我的解釋還不明確，請(qǐng)讀者自行百度，或者查閱《計(jì)算機(jī)網(wǎng)絡(luò)》、《TCP/IP》中TCP的內(nèi)容）

粘包問題的解決策略

由于底層的TCP無法理解上層的業(yè)務(wù)邏輯，所以在底層是無法確保數(shù)據(jù)包不被拆分和重組的，這個(gè)問題只能通過上層的應(yīng)用協(xié)議棧設(shè)計(jì)來解決，根據(jù)業(yè)界的主流協(xié)議的解決方案，歸納如下：

1.消息定長(zhǎng)，例如每個(gè)報(bào)文的大小為固定長(zhǎng)度200字節(jié),如果不夠，空位補(bǔ)空格；

2.在包尾增加回車換行符進(jìn)行分割，例如FTP協(xié)議；

3.將消息分為消息頭和消息體，消息頭中包含表示消息總長(zhǎng)度（或者消息體長(zhǎng)度）的字段，通常設(shè)計(jì)思路是消息頭的第一個(gè)字段用int來表示消息的總長(zhǎng)度；（我之前l(fā)inux C開發(fā)，就用的這種）。

4.更復(fù)雜的應(yīng)用層協(xié)議；

以上這篇基于TCP通信丟包的原因總結(jié)(推薦)就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。