公司的項目底層，是使用的TCP，因為可靠，自動斷線重連，在底層都實現了，但是我記得TCP也會有掉包的問題，所以這文章就誕生了——關於TCP掉包的問題，TCP是基於不可靠的網路實現可靠的傳輸，肯定也會存在掉包的情況。 如果通信中發現缺少數據或者丟包，那麼，最大的可能在於程式發送的過程或者接收的過程出現 ...
公司的項目底層，是使用的TCP，因為可靠，自動斷線重連，在底層都實現了，但是我記得TCP也會有掉包的問題，所以這文章就誕生了——關於TCP掉包的問題，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.更複雜的應用層協議；
