問題的表述

問題的背景是這樣的：有一個系統，那有後臺伺服器，也有移動端的客戶端。當客戶端上線時，伺服器會將指定的資料庫的資料傳送給客戶端，客戶端解析後呈現。
但是，有一天客戶端開發跟我反映一個奇怪的問題：之前客戶端一上線就收到伺服器發來的資料，現在客戶端收到了資料，但是解析出問題了。但是前後端的程式碼都沒有改啊，只是要傳送的資料是新新增的，並且比之前的測試資料要大。

原因的剖析

根據他的描述，很明顯問題出在了要傳送的資料上。由於之前是測試資料，並不會放過大的資料到後臺資料庫，現在放上去的是真實資料，要比測試資料大好多。

於是我就重新拾起了塵封已久的tcp/ip協議的書，也試著在網上尋找答案。最終我知道了我們這個問題叫做tcp協議的組包問題。

什麼叫tcp的組包問題呢？簡單的說就是tcp協議把過大的資料包分成了幾個小的包傳輸，客戶端要把同一組的資料包重新組合成一個完整的資料包。

具體點的解釋：

首先我們要知道MTU（最大傳輸單元）。IP分片在乙太網上，由於電氣限制，一幀不能超過1518位元組，除去乙太網幀頭14位元組（mac地址等）和幀尾4位元組校驗，不考慮PPPoE協議（讀者自行了解這是什麼鬼）的8個位元組，還剩1500位元組，這個大小稱為MTU（最大傳輸單元）。
這1500還包含20位元組IP頭，8位元組UDP頭或者20位元組TCP頭。所以真正的一次傳送的資料包，UDP為1500-28=1472位元組，TCP為1500-40=1460位元組。
當然我們要知道tcp是可靠傳輸協議，以位元組流的形式傳輸資料的，什麼意思呢？就是他可以允許超過1452位元組的資料進行傳輸，因為他會把它切分成多個包，然後用序號進行排序，從而表明了這幾個包是同一組資料。
但是UDP是不可靠傳輸，它一次性就只能發那麼多了，超過的他就不允許發了，所以他效率高，傳送一次就是一個完整的資料，接收方直接拿去解析就可以了。（UDP和TCP還有很多不同的優缺點，讀者感興趣可以自行了解）

所以瞭解了這些之後對於上面描述的問題現象也就不難解釋了，由於我們後臺伺服器傳送的資料包過大，比如有5000位元組，那麼tcp協議就會把它分成1460+1460+1460+620位元組，分四個包傳送給客戶端，客戶端單單解析一個數據包得到的資料肯定是不完整的，要是傳輸的資料是帶一定的結構的話就會解析出錯了。

傳送端處理方法

那麼知道了產生這個問題的原因，又該怎麼解決這個問題呢。我在一個網站上看到有如下回答：連結
一 可以每次傳送同樣大小的包,過大的包不予傳送,過小的包,後面部分用固定的字元’\0’進行填充。
二 將流按字元處理,抽出一個字元做轉義字元(通常Java用’\’來做轉義字元,比如”\n”表示換行)。
三 在傳送方傳送一個包的時候,先將這個包的長度傳送給對方(一般是4個位元組表示包長),然後再將包的內容傳送過去.接收方先接收4個位元組,看看包的長度,然後按照長度來接收包。

於是我採用了最後一種解決辦法，伺服器其傳送的資料中，前4個位元組為需要傳送的資料的位元組數，如上所說，這樣的做法其實就是在TCP協議之上又在封裝了一層，只不過很簡單明瞭。

接收端處理方法

因為TCP會對收到的報文段進行重新排序，然後再交給應用層處理，所以可以用以下的邏輯作為接收端的處理方法。

演算法（裝逼專用詞）：

1.設定全域性標量flag最為標識位，初始值為0；設定全域性變數L，初始值為0。
2.取快取區資料包，判斷標識位，若為0，進入步驟3；若為1，傳遞引數L，進入步驟4。
3.解析資料前4個位元組，得到位元組數L後與當前資料塊剩下的位元組數M比較。若相等，執行步驟5。若L>M，則設定標識位為1，暫時儲存這M位元組資料，傳引數L=L-M，執行步驟2。
4.比較L與當前資料包的大小M，若相等，執行步驟5；若L>M，暫時儲存著M位元組資料，傳引數L=L-M，執行步驟2。
5.呼叫解析函式正常解析，設定標識位為0。
流程圖如下：

總結

事實上，tcp傳輸資料中還存在粘包、分包、半包的問題。傳送端的解決辦法還是一樣的，但是接收端的處理邏輯略有不同，這個就等到下一篇博文中再寫吧。