socket傳輸過程中產生的粘包拆包問題

2021-08-27 20:31:02 字數 746 閱讀 1595

我們在之前一篇部落格    說的是socket套接字底層資料傳輸。

這篇部落格中就出現了socket傳輸過程中的粘包拆包問題。就是因為socket傳送的是無界線的資料流。所以當多個包的大小不一,並且傳送出去的時候,緩衝區的大小不一樣,會導致包與包之間和合併和包的拆分問題。

對於上圖粘包、拆包問題的場景:

客戶端和伺服器建立乙個連線,客戶端傳送一條訊息,客戶端關閉與服務端的連線。客戶端與服務端的連線建立成功之後,服務端不斷讀取客戶端傳送過來的資料,當客戶端與服務端連線斷開之後,服務端知道已經讀完了一條訊息,然後進行解碼和後續處理

客戶端和伺服器簡歷乙個連線,客戶端連續傳送兩條訊息,客戶端關閉與服務端的連線。對於第二種情況,如果按照上面相同的處理邏輯來處理,那麼服務端在解析這個資料報的時候就肯定要按照組包時候的規則去解析包,不然肯定會出現解析資料不正確問題。

這篇部落格解釋了dubbo對粘包拆包問題的解釋及解決方案,其實這方面也確實體現了協議的重要性,如http協議,我們傳送乙個或者多個http協議,雖然發生了粘包和拆包問題,其實我們解析的時候直接按照協議的組包過程反向解析就好了。dubbo的話是按照dubbo棧,作為乙個包去解決拆包粘包問題,dubbo棧滿了就是乙個協議包。這樣把無界限的資料流解析出來乙個個的協議包。然後給伺服器去處理。

這裡也是tomcat和netty的不同之處,tomcat只支援http協議,而netty支援各種協議。

socket傳輸過程

連線過程 根據連線啟動的方式以及本地 套接字要連線的目標,套接字之間的連線過程可以分為三個步驟 伺服器監聽,客戶端請求,連線確認。1 伺服器監聽 是伺服器端套接字並不定位具體的客戶端套接字,而是處於等待連線的狀態,實時監控網路狀態。2 客戶端請求 是指由客戶端的套接字提出連線請求,要連線的目標是伺服...

socket傳輸過程

連線過程 根據連線啟動的方式以及本地套接字要連線的目標,套接字之間的連線過程可以分為三個步驟 伺服器監聽,客戶端請求,連線確認。1 伺服器監聽 是伺服器端套接字並不定位具體的客戶端套接字,而是處於等待連線的狀態,實時監控網路狀態。2 客戶端請求 是指由客戶端的套接字提出連線請求,要連線的目標是伺服器...

TCP資料傳輸過程中資料粘包的產生與處理

tcp資料傳輸過程中資料粘包的處理 自定義tcp傳送接收訊息的協議,訊息傳送前進行字串的拼接,接收時則執行字串拆分,例如 想要傳送的內容為 jiajiage 傳送前先進行字串拼接,拼接成ajiajiage 接收時再執行字串拆分,判斷字串首字元是否為a,如果是a那麼就從a後面進行分割,a jiajia...