黏包問題的成因與解決方案

原文連接地址：http://www.javashuo.com/article/p-syjpvrrd-nb.html

1、黏包成因

tcp協議的拆包機制

當發送端緩衝區的長度大於網卡的MTU時，tcp會將此次發送的數據拆成幾個數據包發送出去。 
MTU是Maximum Transmission Unit的縮寫。意思是網絡上傳送的最大數據包。MTU的單位是字節。大部分網絡設備的MTU都是1500。
若是本機的MTU比網關的MTU大，大的數據包就會被拆開來傳送，這樣會產生不少數據包碎片，增長丟包率，下降網絡速度

面向流的通訊特色和Nagle算法

TCP（transport control protocol，傳輸控制協議）是面向鏈接的，面向流的，提供高可靠性服務。
收發兩端（客戶端和服務器端）都要有一一成對的socket，所以，發送端爲了將多個發往接收端的包，更有效的發到對方，使用了優化方法（Nagle算法），將屢次間隔較小且數據量小的數據，合併成一個大的數據塊，而後進行封包。
這樣，接收端，就難於分辨出來了，必須提供科學的拆包機制。 即面向流的通訊是無消息保護邊界的。 
對於空消息：tcp是基於數據流的，因而收發的消息不能爲空，這就須要在客戶端和服務端都添加空消息的處理機制，防止程序卡住，而udp是基於數據報的，即使是你輸入的是空內容（直接回車），也能夠被髮送，udp協議會幫你封裝上消息頭髮送過去。 
可靠黏包的tcp協議：tcp的協議數據不會丟，沒有收完包，下次接收，會繼續上次繼續接收，己端老是在收到ack時纔會清除緩衝區內容。數據是可靠的，可是會粘包。

總結：

黏包有兩種：

一種是由於發送數據包時，每次發送的包小，由於系統進行優化算法，就將兩次的包放在一塊兒發送，減小了資源的重複佔用。屢次發送會經歷屢次網絡延遲，一塊兒發送會減小網絡延遲的次數。所以在發送小數據時會將兩次數據一塊兒發送，而客戶端接收時，則會一併接收。#即出現屢次send會出現黏包

第二種是由於接收數據時，又屢次接收，第一次接收的數據量小，致使數據還沒接收完，就停下了，剩餘的數據會緩存在內存中，而後等到下次接收時和下一波數據一塊兒接收。

2、黏包的解決方案

1，問題的根源在於，接收端不知道發送端將要傳送的字節流的長度，因此解決粘包的方法就是圍繞，如何讓發送端在發送數據前，把本身將要發送的字節流總大小讓接收端知曉，而後接收端來一個死循環接收完全部數據。

server

client

2.使用time模塊，在每次send的時候加入一個time.sleep(0.01),這種方法能夠有效地隔開兩次send，斷開系統的優化，此種方法雖然能夠解決黏包問題，可是會形成發送數據時間長

server

client

3，先讀取文件的大小，而後將文件的大小發送給接收端，這樣接收端就能夠以文件大小來寫入數據。

server

client

 

 

 

爲何會出現黏包問題？

首先只有在TCP協議中才會出現黏包現象

是由於TCP協議是面向流的協議

在發送的數據傳輸的過程當中海油緩存機制來避免數據丟失

由於在連續發送小數據的時候、以及接收大小不符的時候都容易出現黏包現象

本質仍是由於咱們在接收數據的時候不知道發送的數據的長短

 

解決黏包問題

在傳輸大量數據以前先告訴數據量的大小。

4,使用struct解決黏包