socket的半包,粘包與分包的問題
首先看兩個概念:
短連線:
連線->傳輸資料->關閉連線
HTTP是無狀態的,瀏覽器和伺服器每進行一次HTTP操作,就建立一次連線,但任務結束就中斷連線。
也可以這樣說:短連線是指SOCKET連線後傳送後接收完資料後馬上斷開連線。
長連線:
連線->傳輸資料->保持連線 -> 傳輸資料-> 。。。 ->關閉連線。
長連線指建立SOCKET連線後不管是否使用都保持連線,但安全性較差。
之所以出現粘包和半包現象,是因為TCP當中,只有流的概念,沒有包的概念.
半包
指接受方沒有接受到一個完整的包,只接受了部分,這種情況主要是由於TCP為提高傳輸效率,將一個包分配的足夠大,導致接受方並不能一次接受完。(在長連線和短連線中都會出現)。
粘包與分包
指傳送方傳送的若干包資料到接收方接收時粘成一包,從接收緩衝區看,後一包資料的頭緊接著前一包資料的尾。出現粘包現象的原因是多方面的,它既可能由傳送方造成,也可能由接收方造成。傳送方引起的粘包是由TCP協議本身造成的,TCP為提高傳輸效率,傳送方往往要收集到足夠多的資料後才傳送一包資料。若連續幾次傳送的資料都很少,通常TCP會根據優化演算法把這些資料合成一包後一次傳送出去,這樣接收方就收到了粘包資料。接收方引起的粘包是由於接收方使用者程式不及時接收資料,從而導致粘包現象。這是因為接收方先把收到的資料放在系統接收緩衝區,使用者程式從該緩衝區取資料,若下一包資料到達時前一包資料尚未被使用者程式取走,則下一包資料放到系統接收緩衝區時就接到前一包資料之後,而使用者程式根據預先設定的緩衝區大小從系統接收緩衝區取資料,這樣就一次取到了多包資料。分包是指在出現粘包的時候我們的接收方要進行分包處理。(在長連線中都會出現)
什麼時候需要考慮半包的情況?
從備註中我們瞭解到Socket內部預設的收發緩衝區大小大概是8K,但是我們在實際中往往需要考慮效率問題,重新配置了這個值,來達到系統的最佳狀態。
一個實際中的例子:用mina作為伺服器端,使用的快取大小為10k,這裡使用的是短連線,所有不用考慮粘包的問題。
問題描述:在併發量比較大的情況下,就會出現一次接受並不能完整的獲取所有的資料。
處理方式:
1.通過包頭+包長+包體的協議形式,當伺服器端獲取到指定的包長時才說明獲取完整。
2.指定包的結束標識,這樣當我們獲取到指定的標識時,說明包獲取完整。
什麼時候需要考慮粘包的情況?
1.當時短連線的情況下,不用考慮粘包的情況
2.如果傳送資料無結構,如檔案傳輸,這樣傳送方只管傳送,接收方只管接收儲存就ok,也不用考慮粘包
3.如果雙方建立連線,需要在連線後一段時間內傳送不同結構資料
處理方式:
接收方建立一預處理執行緒,對接收到的資料包進行預處理,將粘連的包分開
注:粘包情況有兩種,一種是粘在一起的包都是完整的資料包,另一種情況是粘在一起的包有不完整的包
備註:
一個包沒有固定長度,乙太網限制在46-1500位元組,1500就是乙太網的MTU,超過這個量,TCP會為IP資料包設定偏移量進行分片傳輸,現在一般可允許應用層設定8k(NTFS系)的緩衝區,8k的資料由底層分片,而應用看來只是一次傳送。windows的緩衝區經驗值是4k,Socket本身分為兩種,流(TCP)和資料包(UDP),你的問題針對這兩種不同使用而結論不一樣。甚至還和你是用阻塞、還是非阻塞Socket來程式設計有關。
1、通訊長度,這個是你自己決定的,沒有系統強迫你要發多大的包,實際應該根據需求和網路狀況來決定。對於TCP,這個長度可以大點,但要知道,Socket內部預設的收發緩衝區大小大概是8K,你可以用SetSockOpt來改變。但對於UDP,就不要太大,一般在1024至10K。注意一點,你無論發多大的包,IP層和鏈路層都會把你的包進行分片傳送,一般區域網就是1500左右,廣域網就只有幾十位元組。分片後的包將經過不同的路由到達接收方,對於UDP而言,要是其中一個分片丟失,那麼接收方的IP層將把整個傳送包丟棄,這就形成丟包。顯然,要是一個UDP發包佷大,它被分片後,鏈路層丟失分片的機率就佷大,你這個UDP包,就佷容易丟失,但是太小又影響效率。最好可以配置這個值,以根據不同的環境來調整到最佳狀態。
send()函式返回了實際傳送的長度,在網路不斷的情況下,它絕不會返回(傳送失敗的)錯誤,最多就是返回0。對於TCP你可以位元組寫一個迴圈傳送。當send函式返回SOCKET_ERROR時,才標誌著有錯誤。但對於UDP,你不要寫迴圈傳送,否則將給你的接收帶來極大的麻煩。所以UDP需要用SetSockOpt來改變Socket內部Buffer的大小,以能容納你的發包。明確一點,TCP作為流,發包是不會整包到達的,而是源源不斷的到,那接收方就必須組包。而UDP作為訊息或資料包,它一定是整包到達接收方。
2、關於接收,一般的發包都有包邊界,首要的就是你這個包的長度要讓接收方知道,於是就有個包頭資訊,對於TCP,接收方先收這個包頭資訊,然後再收包資料。一次收齊整個包也可以,可要對結果是否收齊進行驗證。這也就完成了組包過程。UDP,那你只能整包接收了。要是你提供的接收Buffer過小,TCP將返回實際接收的長度,餘下的還可以收,而UDP不同的是,餘下的資料被丟棄並返回WSAEMSGSIZE錯誤。注意TCP,要是你提供的Buffer佷大,那麼可能收到的就是多個發包,你必須分離它們,還有就是當Buffer太小,而一次收不完Socket內部的資料,那麼Socket接收事件(OnReceive),可能不會再觸發,使用事件方式進行接收時,密切注意這點。這些特性就是體現了流和資料包的區別。
短連線:
連線->傳輸資料->關閉連線
HTTP是無狀態的,瀏覽器和伺服器每進行一次HTTP操作,就建立一次連線,但任務結束就中斷連線。
也可以這樣說:短連線是指SOCKET連線後傳送後接收完資料後馬上斷開連線。
長連線:
連線->傳輸資料->保持連線 -> 傳輸資料-> 。。。 ->關閉連線。
長連線指建立SOCKET連線後不管是否使用都保持連線,但安全性較差。
之所以出現粘包和半包現象,是因為TCP當中,只有流的概念,沒有包的概念.
半包
指接受方沒有接受到一個完整的包,只接受了部分,這種情況主要是由於TCP為提高傳輸效率,將一個包分配的足夠大,導致接受方並不能一次接受完。(在長連線和短連線中都會出現)。
粘包與分包
指傳送方傳送的若干包資料到接收方接收時粘成一包,從接收緩衝區看,後一包資料的頭緊接著前一包資料的尾。出現粘包現象的原因是多方面的,它既可能由傳送方造成,也可能由接收方造成。傳送方引起的粘包是由TCP協議本身造成的,TCP為提高傳輸效率,傳送方往往要收集到足夠多的資料後才傳送一包資料。若連續幾次傳送的資料都很少,通常TCP會根據優化演算法把這些資料合成一包後一次傳送出去,這樣接收方就收到了粘包資料。接收方引起的粘包是由於接收方使用者程式不及時接收資料,從而導致粘包現象。這是因為接收方先把收到的資料放在系統接收緩衝區,使用者程式從該緩衝區取資料,若下一包資料到達時前一包資料尚未被使用者程式取走,則下一包資料放到系統接收緩衝區時就接到前一包資料之後,而使用者程式根據預先設定的緩衝區大小從系統接收緩衝區取資料,這樣就一次取到了多包資料。分包是指在出現粘包的時候我們的接收方要進行分包處理。(在長連線中都會出現)
什麼時候需要考慮半包的情況?
從備註中我們瞭解到Socket內部預設的收發緩衝區大小大概是8K,但是我們在實際中往往需要考慮效率問題,重新配置了這個值,來達到系統的最佳狀態。
一個實際中的例子:用mina作為伺服器端,使用的快取大小為10k,這裡使用的是短連線,所有不用考慮粘包的問題。
問題描述:在併發量比較大的情況下,就會出現一次接受並不能完整的獲取所有的資料。
處理方式:
1.通過包頭+包長+包體的協議形式,當伺服器端獲取到指定的包長時才說明獲取完整。
2.指定包的結束標識,這樣當我們獲取到指定的標識時,說明包獲取完整。
什麼時候需要考慮粘包的情況?
1.當時短連線的情況下,不用考慮粘包的情況
2.如果傳送資料無結構,如檔案傳輸,這樣傳送方只管傳送,接收方只管接收儲存就ok,也不用考慮粘包
3.如果雙方建立連線,需要在連線後一段時間內傳送不同結構資料
處理方式:
接收方建立一預處理執行緒,對接收到的資料包進行預處理,將粘連的包分開
注:粘包情況有兩種,一種是粘在一起的包都是完整的資料包,另一種情況是粘在一起的包有不完整的包
備註:
一個包沒有固定長度,乙太網限制在46-1500位元組,1500就是乙太網的MTU,超過這個量,TCP會為IP資料包設定偏移量進行分片傳輸,現在一般可允許應用層設定8k(NTFS系)的緩衝區,8k的資料由底層分片,而應用看來只是一次傳送。windows的緩衝區經驗值是4k,Socket本身分為兩種,流(TCP)和資料包(UDP),你的問題針對這兩種不同使用而結論不一樣。甚至還和你是用阻塞、還是非阻塞Socket來程式設計有關。
1、通訊長度,這個是你自己決定的,沒有系統強迫你要發多大的包,實際應該根據需求和網路狀況來決定。對於TCP,這個長度可以大點,但要知道,Socket內部預設的收發緩衝區大小大概是8K,你可以用SetSockOpt來改變。但對於UDP,就不要太大,一般在1024至10K。注意一點,你無論發多大的包,IP層和鏈路層都會把你的包進行分片傳送,一般區域網就是1500左右,廣域網就只有幾十位元組。分片後的包將經過不同的路由到達接收方,對於UDP而言,要是其中一個分片丟失,那麼接收方的IP層將把整個傳送包丟棄,這就形成丟包。顯然,要是一個UDP發包佷大,它被分片後,鏈路層丟失分片的機率就佷大,你這個UDP包,就佷容易丟失,但是太小又影響效率。最好可以配置這個值,以根據不同的環境來調整到最佳狀態。
send()函式返回了實際傳送的長度,在網路不斷的情況下,它絕不會返回(傳送失敗的)錯誤,最多就是返回0。對於TCP你可以位元組寫一個迴圈傳送。當send函式返回SOCKET_ERROR時,才標誌著有錯誤。但對於UDP,你不要寫迴圈傳送,否則將給你的接收帶來極大的麻煩。所以UDP需要用SetSockOpt來改變Socket內部Buffer的大小,以能容納你的發包。明確一點,TCP作為流,發包是不會整包到達的,而是源源不斷的到,那接收方就必須組包。而UDP作為訊息或資料包,它一定是整包到達接收方。
2、關於接收,一般的發包都有包邊界,首要的就是你這個包的長度要讓接收方知道,於是就有個包頭資訊,對於TCP,接收方先收這個包頭資訊,然後再收包資料。一次收齊整個包也可以,可要對結果是否收齊進行驗證。這也就完成了組包過程。UDP,那你只能整包接收了。要是你提供的接收Buffer過小,TCP將返回實際接收的長度,餘下的還可以收,而UDP不同的是,餘下的資料被丟棄並返回WSAEMSGSIZE錯誤。注意TCP,要是你提供的Buffer佷大,那麼可能收到的就是多個發包,你必須分離它們,還有就是當Buffer太小,而一次收不完Socket內部的資料,那麼Socket接收事件(OnReceive),可能不會再觸發,使用事件方式進行接收時,密切注意這點。這些特性就是體現了流和資料包的區別。
相關文章
- Socket 粘包和分包問題
- 25. Socket與粘包問題
- java nio解決半包 粘包問題Java
- netty 解決粘包 和 分包的問題Netty
- 詳說tcp粘包和半包TCP
- Netty粘包&半包解決方案Netty
- 粘包問題
- Netty原始碼學習6——netty編碼解碼器&粘包半包問題的解決Netty原始碼
- java nio訊息半包、粘包解決方案Java
- Netty拾遺(七)——粘包與拆包問題Netty
- TCP粘包拆包問題TCP
- Go TCP 粘包問題GoTCP
- Netty2:粘包/拆包問題與使用LineBasedFrameDecoder的解決方案Netty
- Netty中使用MessagePack時的TCP粘包問題與解決方案NettyTCP
- 粘包問題原因和解決方法
- Netty解決粘包和拆包問題的四種方案Netty
- TCP 粘包 - 拆包問題及解決方案TCP
- TCP協議粘包問題詳解TCP協議
- Netty - 粘包與拆包Netty
- 再聊t-io網路程式設計架構的基礎知識:半包和粘包程式設計架構
- 【Socket】解決UDP丟包問題UDP
- 粘包問題、socketserver模組實現併發Server
- 深入學習Netty(5)——Netty是如何解決TCP粘包/拆包問題的?NettyTCP
- 訊息粘包 和 訊息不完整 問題
- Netty 中的粘包和拆包Netty
- TCP的粘包拆包技術TCP
- Netty入門系列(2) --使用Netty解決粘包和拆包問題Netty
- 每次面試都被問TCP粘包問題,今天終於可以說的清清楚楚了面試TCP
- TCP 粘包拆包TCP
- 結合RPC框架通訊談 netty如何解決TCP粘包問題RPC框架NettyTCP
- 粘包/拆包問題一直都存在,只是到TCP就拆不動了。TCP
- BothWin分包與熱更新:安裝與升級,開發者頭疼的問題在此破局
- 揹包問題(01揹包與完全揹包)
- socket程式設計中常見的概念問題!程式設計
- swoole 之 tcp 合包分包TCP
- 粘包拆包及解決方案
- React Native SDK 升級問題及分包方案React Native
- Netty如何解決粘包拆包?(二)Netty