網絡編程面向字節流—粘包問題

粘包:通俗的講,在我們買包子的時候,我們可以看到蒸籠中,每個包子之間都隔開了空間,或者是用紙把每個包子都隔離開了,不讓它們粘在一起。如果讓兩個包子之間無縫隙的在粘在一起。當你買包子時,老闆把一個包子裝起來,另個一個包子的皮就會粘到你的這個包子來。兩個包子都多了點,另一個少了點。包子不完整了,外觀不完美了。

同樣的,在我們TCP面向字節流傳輸過程中,我們也會遇到這樣的問題。

粘包中的“包”指的是應用層數據包。

當我們要傳輸數據的時候,傳輸層中會把數據分成有序列號的字段,並存放在發送緩衝區中。根據TCP協議的機制,可靠的發送給了對端接受方。

接受方接收到了數據,並存放在接受緩存區中。每一個字段都是有序號的,但是因爲每時每刻的網絡複雜程度不一樣,所以每次接受到的字段長度都有所不同。

那麼在我們的接受方主機是如果每次都按照一定的長度去讀取接受緩存區中的數據時,就會多讀了下一個字段中的數據,或者少讀了該字段中的額數據。——這就是粘包問題。(不知道從那個部分開始到那個部分是一個完整的數據包)

解決粘包問題:

1.我們可以使用明確的分隔符作爲每個數據包的邊界(應用層協議,只要保證分隔符不和正文衝突)

2.對於定長的包,保證每次都按照固定的大小讀取數據就行了

3.對與變長的包,可以在包頭的位置,約定一個包總長度的字段,從而知道了包的結束位置


對比面向數據報:
我們知道UDP協議是面向數據報的形式傳輸數據的。
UDP協議,如果還沒有上層交付數據,UDP的報文長度任然在,同時是一個一個把數據交付給應用層,就是有很明確的數據邊界。

站在應用層的角度看,使用UDP協議傳輸數據時,要麼對方完整的接受到UDP報文,要麼不收。(不會出現子接受一半的情況)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章