文章目錄

• 一：面向字節流
• 二：粘包（應用層數據包）問題
• 三：TCP異常情況

一：面向字節流

經過前面的敘述，現在我們對TCP面向字節流的理解就更加深刻了。

創建一個TCP的socket，就會在內核中創建一個發送緩沖區和一個接受緩沖區。主要有以下這么幾點：

• 調用write接口，數據會先寫入發送緩沖區
• 如果發送的字節數太長，會被拆分成多個TCP的數據包發出
• 如果發送的字節數太短，會在緩沖區內等待，等待緩沖區長度差不多了，或者在其他合適的時機將其發送出去
• 接受數據的時候，數據也是從網卡驅動程序到達內核的接受緩沖區的
• 應用層可以調用read從接受緩沖區中拿取數據

TCP的一個連接，既有發送緩沖區也有接受緩沖區，所以對于這一個連接，既可以讀取數據也可以寫入數據——全雙工

二：粘包（應用層數據包）問題

TCP協議中是沒有同UDP一樣的“報文長度”的字段，因此站在應用層角度來看，看到的只是一串連續的字節數，因此應用程序就無法分清數據的界限，有可能會產生粘包問題。

如果避免呢？關鍵就在于：應用層的協議應該要明確兩個包的邊界

• 對于定長的包，保證每次都按固定大小讀取即可。例如Request，那么就從緩沖區從頭開始按照sizeof(Request)大小依次讀取即可
• 對于變長的包，可以在包頭的位置，約定一個包總長度的字段，從而就知道了包的結束位置（比如HTTP協議中conten-length）；同時還可以在包與包之前使用特殊的分隔符（比如HTTP協議中的空行）

三：TCP異常情況

我們都知道運行中的程序會由于各種各樣的原因崩潰，對于非網絡程序來說并沒有什么大的問題，不過對于網絡應用程序由于它還涉及連接問題，所以它不能簡單單的拍屁股走人

所以在客戶端應用程序崩潰或死亡時，接收端會認為連接還在，一旦接收端有寫入操作，接收端發現連接不在了，就會進行reset。即使沒有寫入操作，TCP自己也會內置一個保活定時器即使詢問對方是否還在，如果不在就會釋放連接。最經典的就是QQ了。

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的4-10：TCP协议之面向字节流和粘包问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。