您好,登錄后才能下訂單哦!
這篇文章給大家介紹利用TCP進行通信出現丟包如何解決,內容非常詳細,感興趣的小伙伴們可以參考借鑒,希望對大家能有所幫助。
如果通信中發現缺少數據或者丟包,那么,最大的可能在于程序發送的過程或者接收的過程出現問題。
例如服務器給客戶端發大量數據,Send的頻率很高,那么就有可能在Send時發生錯誤(原因可能是又多種,可能是程序處理邏輯問題,多線程同步問題,緩沖區溢出問題等等),如果沒有對Send失敗做處理重發數據,那么客戶端收到的數據就會比理論應該收到的少,就會造成丟數據,丟包的現象。
這種現象,其實本質上來說不是丟包,也不是丟數據,只是因為程序處理有錯誤,導致有些數據沒有成功地被socket發送出去。
常用的解決方法如下:拆包、加包頭、發送,組合包,如果客戶端、服務端掉線,常采用心跳測試。
tcp是一個“流”的協議,一個完整的包可能會被TCP拆分成多個包進行發送,也可能把小的封裝成一個大的數據包發送,這就是所謂的TCP粘包和拆包問題。
粘包、拆包問題說明
假設客戶端分別發送數據包D1和D2給服務端,由于服務端一次性讀取到的字節數是不確定的,所以可能存在以下4種情況。
1.服務端分2次讀取到了兩個獨立的包,分別是D1,D2,沒有粘包和拆包;
2.服務端一次性接收了兩個包,D1和D2粘在一起了,被成為TCP粘包;
3.服務端分2次讀取到了兩個數據包,第一次讀取到了完整的D1和D2包的部分內容,第二次讀取到了D2包的剩余內容,這被稱為拆包;
4.服務端分2次讀取到了兩個數據包,第一次讀取到了部分D1,第二次讀取D1剩余的部分和完整的D2包;
如果此時服務端TCP接收滑動窗非常小,而數據包D1和D2都很大,很有可能發送第五種可能,即服務端多次才能把D1和D2接收完全,期間多次發生拆包情況。(TCP接收滑動窗:是接收端的大小,隨著流量大小而變化,如果我的解釋還不明確,請讀者自行百度,或者查閱《計算機網絡》、《TCP/IP》中TCP的內容)
粘包問題的解決策略
由于底層的TCP無法理解上層的業務邏輯,所以在底層是無法確保數據包不被拆分和重組的,這個問題只能通過上層的應用協議棧設計來解決,根據業界的主流協議的解決方案,歸納如下:
1.消息定長,例如每個報文的大小為固定長度200字節,如果不夠,空位補空格;
2.在包尾增加回車換行符進行分割,例如FTP協議;
3.將消息分為消息頭和消息體,消息頭中包含表示消息總長度(或者消息體長度)的字段,通常設計思路是消息頭的第一個字段用int來表示消息的總長度;(我之前linux C開發,就用的這種)。
4.更復雜的應用層協議;
關于利用TCP進行通信出現丟包如何解決就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。