最近研究Netty網路程式設計，以前專案中也遇到過資料接收過程中資料質量太差問題，很可能是TCP傳輸過程中問題，特此記錄。

問題產生
一個完整的業務可能會被TCP拆分成多個包進行傳送，也有可能把多個小的包封裝成一個大的資料包傳送，這個就是TCP的拆包和封包問題。

下面可以看一張圖，是客戶端向服務端傳送包：

上圖中第三中情況有誤，TCP為有序傳輸，順序應該是Data2_2 Data2_1 Data1

1. 第一種情況，Data1和Data2都分開發送到了Server端，沒有產生粘包和拆包的情況。

2. 第二種情況，Data1和Data2資料粘在了一起，打成了一個大的包傳送到Server端，這個情況就是粘包。

3. 第三種情況，Data2被分離成Data2_1和Data2_2，並且Data2_1在Data1之前到達了服務端，這種情況就產生了拆包。

由於網路的複雜性，可能資料會被分離成N多個複雜的拆包/粘包的情況，所以在做TCP伺服器的時候就需要首先解決拆包/粘包的問題。

TCP粘包和拆包產生的原因
1. 應用程式寫入資料的位元組大小大於套接字傳送緩衝區的大小

1. 進行MSS大小的TCP分段。MSS是最大報文段長度的縮寫。MSS是TCP報文段中的資料欄位的最大長度。資料欄位加上TCP首部才等於整個的TCP報文段。所以MSS並不是TCP報文段的最大長度，而是：MSS=TCP報文段長度-TCP首部長度

2. 乙太網的payload大於MTU進行IP分片。MTU指：一種通訊協議的某一層上面所能通過的最大資料包大小。如果IP層有一個數據包要傳，而且資料的長度比鏈路層的MTU大，那麼IP層就會進行分片，把資料包分成若干片，讓每一片都不超過MTU。注意，IP分片可以發生在原始傳送端主機上，也可以發生在中間路由器上。

TCP粘包和拆包的解決策略
1. 訊息定長。例如100位元組。

1. 在包尾部增加回車或者空格符等特殊字元進行分割，典型的如FTP協議

2. 將訊息分為訊息頭和訊息尾。

3. 其它複雜的協議，如RTMP協議等。