剛畢業參加工作的時候， 我對計算機網路和網路程式設計一無所知。 當時要負責一個客戶端介面軟體的維護和開發， 而另一個“同事”要離職， 哎， 扯遠了。

         我當時在程式碼中讀到一個註釋， 其中有“粘包”二字， 當時比較納悶： 不都說tcp是好東西嗎？ 怎麼會粘包呢？ 可見， 我確實對網路一無所知。 後來， 我發現， 這個客戶端居然真的能和服務端通訊， 很顯然啊， 不然也不會存在這麼久。 於是， 我對網路程式設計有點興趣了。

         試用期， 師傅叫我搞tcp客戶端、服務端程式， udp客戶端服務端程式， 我七拼八湊地搞了， 後來師傅在review我的程式碼時， 不斷問我每個函式和引數的含義， 怎麼除錯。 總之， 問得我啞口無言， 一問三不知。 師傅看出了， 我是直接“參考”了網路上的程式， 而且沒有搞懂。於是， 我下定決定搞網路程式設計， 哎，又扯遠了， 跑題了。

         話說， 當時看到粘包， 不知道啥意思， 也沒有仔細瞭解。 後來到了另外一家公司， 我偶然地被一個問題卡住了： 對端回包OK,  但我的程式解包失敗。 我開始懷疑是不是buffer不夠， 後來排除了這個原因。 這個問題必須要解決， 怎麼辦呢？ 那就看封裝的網路庫的原始碼吧， 發現有個函式的指標為NULL了， 於是我就參考其他地方的呼叫方法， 對函式指標進行了賦值， 結果就OK了， 於是我記住了， 這裡要賦值。

         後來， 我看到了tcp粘包， 就想了解一下， 原來， 當時的解包錯誤是因為粘包導致包切割的長度不對。 於是， 我就懂了， 為什麼要對那個函式指標進行初始化， 因為這個函式指標對應函式就是用來檢驗包的完整性的， 這樣可以解決粘包問題。

         最近呢？ 某哥收到包後， 解包會失敗， 後來證實發現， 也是粘包問題。

         最近又發現， 某同學手包低概率性失敗， 經查， 是收到的時候， 沒有進行包的完整性判斷， 導致了粘包問題。

         後來， 另外一個某哥說， 他曾經寫過一個程式， 沒有進行粘包檢測， 結果跑了很久沒有問題， 後來終於出問題了， 呵呵噠。

         TCP粘包就是這麼有意思。 至於Tcp的粘包原因和解決方法， 我之前已經說過了， 就不再贅述了。