Socket粘包問題

標籤：

這兩天看csdn有一些關於socket粘包，socket緩衝區設定的問題，發現自己不是很清楚，所以查資料瞭解記錄一下：

 

一兩個簡單概念長串連與短串連：
1.長串連

    Client方與Server方先建立通訊串連，串連建立後不斷開， 然後再進行報文發送和接收。

2.短串連

    Client方與Server每進行一次報文收發交易時才進行通訊串連，交易完畢後立即中斷連線。此種方式常用於一點對多點 
通訊，比如多個Client串連一個Server.

 

二 什麼時候需要考慮粘包問題?

1:如果利用tcp每次發送資料，就與對方建立串連，然後雙方發送完一段資料後，就關閉串連，這樣就不會出現粘包問題（因為只有一種包結構,類似於http協議）。關閉串連主要要雙方都發送close串連（參考tcp關閉協議）。如：A需要發送一段字串給B，那麼A與B建立串連，然後發送雙方都預設好的協議字元如"hello give me sth abour yourself"，然後B收到報文後，就將緩衝區資料接收,然後關閉串連，這樣粘包問題不用考慮到，因為大家都知道是發送一段字元。
2：如果發送資料無結構，如檔案傳輸，這樣發送方只管發送，接收方只管接收儲存就ok，也不用考慮粘包
3：如果雙方建立串連，需要在串連後一段時間內發送不同結構資料，如串連後，有好幾種結構：
 1)"hello give me sth abour yourself" 
 2)"Don‘t give me sth abour yourself" 
   那這樣的話，如果發送方連續發送這個兩個包出去，接收方一次接收可能會是"hello give me sth abour yourselfDon‘t give me sth abour yourself" 這樣接收方就傻了，到底是要幹嘛？不知道，因為協議沒有規定這麼詭異的字串，所以要處理把它分包，怎麼分也需要雙方組織一個比較好的包結構，所以一般可能會在頭加一個資料長度之類的包，以確保接收。
 

三 粘包出現原因：在流傳輸中出現，UDP不會出現粘包，因為它有訊息邊界(參考Windows 網路編程)
1 發送端需要等緩衝區滿才發送出去，造成粘包
2 接收方不及時接收緩衝區的包，造成多個包接收

解決辦法：
為了避免粘包現象，可採取以下幾種措施。一是對於發送方引起的粘包現象，使用者可通過編程設定來避免，TCP提供了強制資料立即傳送的操作指令push，TCP軟體收到該操作指令後，就立即將本段資料發送出去，而不必等待發送緩衝區滿；二是對於接收方引起的粘包，則可通過最佳化程式設計、精簡接收進程工作量、提高接收進程優先順序等措施，使其及時接收資料，從而盡量避免出現粘包現象；三是由接收方控制，將一包資料按結構欄位，人為控制分多次接收，然後合并，通過這種手段來避免粘包。

以上提到的三種措施，都有其不足之處。第一種編程設定方法雖然可以避免發送方引起的粘包，但它關閉了最佳化演算法，降低了網路發送效率，影響應用程式的效能，一般不建議使用。第二種方法只能減少出現粘包的可能性，但並不能完全避免粘包，當發送頻率較高時，或由於網路突發可能使某個時間段資料包到達接收方較快，接收方還是有可能來不及接收，從而導致粘包。第三種方法雖然避免了粘包，但應用程式的效率較低，對即時應用的場合不適合。

相關文章截取：

一個包沒有固定長度，乙太網路限制在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://www.cnblogs.com/alon/archive/2009/04/16/1437600.html

Socket粘包問題