這兩天看csdn有一些關(guān)于socket粘包，socket緩沖區(qū)設(shè)置的問題，發(fā)現(xiàn)自己不是很清楚，所以查資料了解記錄一下：

一兩個(gè)簡(jiǎn)單概念長(zhǎng)連接與短連接：
1.長(zhǎng)連接

??? Client方與Server方先建立通訊連接，連接建立后不斷開， 然后再進(jìn)行報(bào)文發(fā)送和接收。

2.短連接

??? Client方與Server每進(jìn)行一次報(bào)文收發(fā)交易時(shí)才進(jìn)行通訊連接，交易完畢后立即斷開連接。此種方式常用于一點(diǎn)對(duì)多點(diǎn)
通訊，比如多個(gè)Client連接一個(gè)Server.

二 什么時(shí)候需要考慮粘包問題?

1:如果利用tcp每次發(fā)送數(shù)據(jù)，就與對(duì)方建立連接，然后雙方發(fā)送完一段數(shù)據(jù)后，就關(guān)閉連接，這樣就不會(huì)出現(xiàn)粘包問題（因?yàn)橹挥幸环N包結(jié)構(gòu),類似于http協(xié)議）。關(guān)閉連接主要要雙方都發(fā)送close連接（參考tcp關(guān)閉協(xié)議）。如：A需要發(fā)送一段字符串給B，那么A與B建立連接，然后發(fā)送雙方都默認(rèn)好的協(xié)議字符如"hello give me sth abour yourself"，然后B收到報(bào)文后，就將緩沖區(qū)數(shù)據(jù)接收,然后關(guān)閉連接，這樣粘包問題不用考慮到，因?yàn)榇蠹叶贾朗前l(fā)送一段字符。
2：如果發(fā)送數(shù)據(jù)無結(jié)構(gòu)，如文件傳輸，這樣發(fā)送方只管發(fā)送，接收方只管接收存儲(chǔ)就ok，也不用考慮粘包
3：如果雙方建立連接，需要在連接后一段時(shí)間內(nèi)發(fā)送不同結(jié)構(gòu)數(shù)據(jù)，如連接后，有好幾種結(jié)構(gòu)：
1)"hello give me sth abour yourself"
2)"Don't give me sth abour yourself"
?? 那這樣的話，如果發(fā)送方連續(xù)發(fā)送這個(gè)兩個(gè)包出去，接收方一次接收可能會(huì)是"hello give me sth abour yourselfDon't give me sth abour yourself" 這樣接收方就傻了，到底是要干嘛？不知道，因?yàn)閰f(xié)議沒有規(guī)定這么詭異的字符串，所以要處理把它分包，怎么分也需要雙方組織一個(gè)比較好的包結(jié)構(gòu)，所以一般可能會(huì)在頭加一個(gè)數(shù)據(jù)長(zhǎng)度之類的包，以確保接收。

三 粘包出現(xiàn)原因：在流傳輸中出現(xiàn)，UDP不會(huì)出現(xiàn)粘包，因?yàn)樗邢⑦吔?參考Windows 網(wǎng)絡(luò)編程)
1 發(fā)送端需要等緩沖區(qū)滿才發(fā)送出去，造成粘包
2 接收方不及時(shí)接收緩沖區(qū)的包，造成多個(gè)包接收

解決辦法：
為了避免粘包現(xiàn)象，可采取以下幾種措施。一是對(duì)于發(fā)送方引起的粘包現(xiàn)象，用戶可通過編程設(shè)置來避免，TCP提供了強(qiáng)制數(shù)據(jù)立即傳送的操作指令push，TCP軟件收到該操作指令后，就立即將本段數(shù)據(jù)發(fā)送出去，而不必等待發(fā)送緩沖區(qū)滿；二是對(duì)于接收方引起的粘包，則可通過優(yōu)化程序設(shè)計(jì)、精簡(jiǎn)接收進(jìn)程工作量、提高接收進(jìn)程優(yōu)先級(jí)等措施，使其及時(shí)接收數(shù)據(jù)，從而盡量避免出現(xiàn)粘包現(xiàn)象；三是由接收方控制，將一包數(shù)據(jù)按結(jié)構(gòu)字段，人為控制分多次接收，然后合并，通過這種手段來避免粘包。

以上提到的三種措施，都有其不足之處。第一種編程設(shè)置方法雖然可以避免發(fā)送方引起的粘包，但它關(guān)閉了優(yōu)化算法，降低了網(wǎng)絡(luò)發(fā)送效率，影響應(yīng)用程序的性能，一般不建議使用。第二種方法只能減少出現(xiàn)粘包的可能性，但并不能完全避免粘包，當(dāng)發(fā)送頻率較高時(shí)，或由于網(wǎng)絡(luò)突發(fā)可能使某個(gè)時(shí)間段數(shù)據(jù)包到達(dá)接收方較快，接收方還是有可能來不及接收，從而導(dǎo)致粘包。第三種方法雖然避免了粘包，但應(yīng)用程序的效率較低，對(duì)實(shí)時(shí)應(yīng)用的場(chǎng)合不適合。


相關(guān)文章截取：

一個(gè)包沒有固定長(zhǎng)度，以太網(wǎng)限制在46－1500字節(jié)，1500就是以太網(wǎng)的MTU，超過這個(gè)量，TCP會(huì)為IP數(shù)據(jù)報(bào)設(shè)置偏移量進(jìn)行分片傳輸，現(xiàn)在一般可允許應(yīng)用層設(shè)置8k（NTFS系）的緩沖區(qū)，8k的數(shù)據(jù)由底層分片，而應(yīng)用看來只是一次發(fā)送。windows的緩沖區(qū)經(jīng)驗(yàn)值是4k,Socket本身分為兩種，流(TCP)和數(shù)據(jù)報(bào)(UDP)，你的問題針對(duì)這兩種不同使用而結(jié)論不一

樣。甚至還和你是用阻塞、還是非阻塞Socket來編程有關(guān)。

1、通信長(zhǎng)度，這個(gè)是你自己決定的，沒有系統(tǒng)強(qiáng)迫你要發(fā)多大的包，實(shí)際應(yīng)該根據(jù)需求和網(wǎng)絡(luò)狀況來決定。對(duì)于TCP，這個(gè)長(zhǎng)度可以大點(diǎn)，但要知道，Socket內(nèi)部默認(rèn)的收發(fā)緩沖區(qū)大小大概是8K，你可以用SetSockOpt來改變。但對(duì)于UDP，就不要太大，一般在1024至10K。注意一點(diǎn)，你無論發(fā)多大的包，IP層和鏈路層都會(huì)把你的包進(jìn)行分片發(fā)送，一般局域網(wǎng)就是1500左右，廣域網(wǎng)就只有幾十字節(jié)。分片后的包將經(jīng)過不同的路由到達(dá)接收方，對(duì)于UDP而言，要是其中一個(gè)分片丟失，那么接收方的IP層將把整個(gè)發(fā)送包丟棄，這就形成丟包。顯然，要是一個(gè)UDP發(fā)包佷大，它被分片后，鏈路層丟失分片的幾率就佷大，你這個(gè)UDP包，就佷容易丟失，但是太小又影響效率。最好可以配置這個(gè)值，以根據(jù)不同的環(huán)境來調(diào)整到最佳狀態(tài)。

send()函數(shù)返回了實(shí)際發(fā)送的長(zhǎng)度，在網(wǎng)絡(luò)不斷的情況下，它絕不會(huì)返回(發(fā)送失敗的)錯(cuò)誤，最多就是返回0。對(duì)于TCP你可以字節(jié)寫一個(gè)循環(huán)發(fā)送。當(dāng)send函數(shù)返回SOCKET_ERROR時(shí)，才標(biāo)志著有錯(cuò)誤。但對(duì)于UDP，你不要寫循環(huán)發(fā)送，否則將給你的接收帶來極大的麻煩。所以UDP需要用SetSockOpt來改變Socket內(nèi)部Buffer的大小，以能容納你的發(fā)包。明確一點(diǎn)，TCP作為流，發(fā)包是不會(huì)整包到達(dá)的，而是源源不斷的到，那接收方就必須組包。而UDP作為消息或數(shù)據(jù)報(bào)，它一定是整包到達(dá)接收方。

2、關(guān)于接收，一般的發(fā)包都有包邊界，首要的就是你這個(gè)包的長(zhǎng)度要讓接收方知道，于是就有個(gè)包頭信息，對(duì)于TCP，接收方先收這個(gè)包頭信息，然后再收包數(shù)據(jù)。一次收齊整個(gè)包也可以，可要對(duì)結(jié)果是否收齊進(jìn)行驗(yàn)證。這也就完成了組包過程。UDP，那你只能整包接收了。要是你提供的接收Buffer過小，TCP將返回實(shí)際接收的長(zhǎng)度，余下的還可以收，而UDP不同的是，余下的數(shù)據(jù)被丟棄并返回WSAEMSGSIZE錯(cuò)誤。注意TCP，要是你提供的Buffer佷大，那么可能收到的就是多個(gè)發(fā)包，你必須分離它們，還有就是當(dāng)Buffer太小，而一次收不完Socket內(nèi)部的數(shù)據(jù)，那么Socket接收事件(OnReceive)，可能不會(huì)再觸發(fā)，使用事件方式進(jìn)行接收時(shí)，密切注意這點(diǎn)。這些特性就是體現(xiàn)了流和數(shù)據(jù)包的區(qū)別。


相關(guān)參考文章：
http://www.cnblogs.com/alon/archive/2009/04/16/1437600.html

本文來自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/binghuazh/archive/2009/05/28/4222516.aspx

解決TCP網(wǎng)絡(luò)傳輸“粘包”問題

當(dāng)前在網(wǎng)絡(luò)傳輸應(yīng)用中，廣泛采用的是TCP/IP通信協(xié)議及其標(biāo)準(zhǔn)的socket應(yīng)用開發(fā)編程接口（API）。TCP/IP傳輸層有兩個(gè)并列的協(xié)議：TCP和UDP。其中TCP（transport control protocol，傳輸控制協(xié)議）是面向連接的，提供高可靠性服務(wù)。UDP（user datagram protocol，用戶數(shù)據(jù)報(bào)協(xié)議）是無連接的，提供高效率服務(wù)。在實(shí)際工程應(yīng)用中，對(duì)可靠性和效率的選擇取決于應(yīng)用的環(huán)境和需求。一般情況下，普通數(shù)據(jù)的網(wǎng)絡(luò)傳輸采用高效率的udp，重要數(shù)據(jù)的網(wǎng)絡(luò)傳輸采用高可靠性的TCP。

在應(yīng)用開發(fā)過程中，筆者發(fā)現(xiàn)基于TCP網(wǎng)絡(luò)傳輸?shù)膽?yīng)用程序有時(shí)會(huì)出現(xiàn)粘包現(xiàn)象（即發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時(shí)粘成一包）。針對(duì)這種情況，我們進(jìn)行了專題研究與實(shí)驗(yàn)。本文重點(diǎn)分析了TCP網(wǎng)絡(luò)粘包問題，并結(jié)合實(shí)驗(yàn)結(jié)果提出了解決該問題的對(duì)策和方法，供有關(guān)工程技術(shù)人員參考。

一、TCP協(xié)議簡(jiǎn)介

　　TCP是一個(gè)面向連接的傳輸層協(xié)議，雖然TCP不屬于iso制定的協(xié)議集，但由于其在商業(yè)界和工業(yè)界的成功應(yīng)用，它已成為事實(shí)上的網(wǎng)絡(luò)標(biāo)準(zhǔn)，廣泛應(yīng)用于各種網(wǎng)絡(luò)主機(jī)間的通信。

　　作為一個(gè)面向連接的傳輸層協(xié)議，TCP的目標(biāo)是為用戶提供可靠的端到端連接，保證信息有序無誤的傳輸。它除了提供基本的數(shù)據(jù)傳輸功能外，還為保證可靠性采用了數(shù)據(jù)編號(hào)、校驗(yàn)和計(jì)算、數(shù)據(jù)確認(rèn)等一系列措施。它對(duì)傳送的每個(gè)數(shù)據(jù)字節(jié)都進(jìn)行編號(hào)，并請(qǐng)求接收方回傳確認(rèn)信息（ack）。發(fā)送方如果在規(guī)定的時(shí)間內(nèi)沒有收到數(shù)據(jù)確認(rèn)，就重傳該數(shù)據(jù)。數(shù)據(jù)編號(hào)使接收方能夠處理數(shù)據(jù)的失序和重復(fù)問題。數(shù)據(jù)誤碼問題通過在每個(gè)傳輸?shù)臄?shù)據(jù)段中增加校驗(yàn)和予以解決，接收方在接收到數(shù)據(jù)后檢查校驗(yàn)和，若校驗(yàn)和有誤，則丟棄該有誤碼的數(shù)據(jù)段，并要求發(fā)送方重傳。流量控制也是保證可靠性的一個(gè)重要措施，若無流控，可能會(huì)因接收緩沖區(qū)溢出而丟失大量數(shù)據(jù)，導(dǎo)致許多重傳，造成網(wǎng)絡(luò)擁塞惡性循環(huán)。TCP采用可變窗口進(jìn)行流量控制，由接收方控制發(fā)送方發(fā)送的數(shù)據(jù)量。

　　TCP為用戶提供了高可靠性的網(wǎng)絡(luò)傳輸服務(wù)，但可靠性保障措施也影響了傳輸效率。因此，在實(shí)際工程應(yīng)用中，只有關(guān)鍵數(shù)據(jù)的傳輸才采用TCP，而普通數(shù)據(jù)的傳輸一般采用高效率的udp。

二、粘包問題分析與對(duì)策

　　TCP粘包是指發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時(shí)粘成一包，從接收緩沖區(qū)看，后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾。

　　出現(xiàn)粘包現(xiàn)象的原因是多方面的，它既可能由發(fā)送方造成，也可能由接收方造成。發(fā)送方引起的粘包是由TCP協(xié)議本身造成的，TCP為提高傳輸效率，發(fā)送方往往要收集到足夠多的數(shù)據(jù)后才發(fā)送一包數(shù)據(jù)。若連續(xù)幾次發(fā)送的數(shù)據(jù)都很少，通常TCP會(huì)根據(jù)優(yōu)化算法把這些數(shù)據(jù)合成一包后一次發(fā)送出去，這樣接收方就收到了粘包數(shù)據(jù)。接收方引起的粘包是由于接收方用戶進(jìn)程不及時(shí)接收數(shù)據(jù)，從而導(dǎo)致粘包現(xiàn)象。這是因?yàn)榻邮辗较劝咽盏降臄?shù)據(jù)放在系統(tǒng)接收緩沖區(qū)，用戶進(jìn)程從該緩沖區(qū)取數(shù)據(jù)，若下一包數(shù)據(jù)到達(dá)時(shí)前一包數(shù)據(jù)尚未被用戶進(jìn)程取走，則下一包數(shù)據(jù)放到系統(tǒng)接收緩沖區(qū)時(shí)就接到前一包數(shù)據(jù)之后，而用戶進(jìn)程根據(jù)預(yù)先設(shè)定的緩沖區(qū)大小從系統(tǒng)接收緩沖區(qū)取數(shù)據(jù)，這樣就一次取到了多包數(shù)據(jù)（圖1所示）。

?
圖1

?
圖2

?
圖3

　　粘包情況有兩種，一種是粘在一起的包都是完整的數(shù)據(jù)包（圖1、圖2所示），另一種情況是粘在一起的包有不完整的包（圖3所示），此處假設(shè)用戶接收緩沖區(qū)長(zhǎng)度為m個(gè)字節(jié)。

　　不是所有的粘包現(xiàn)象都需要處理，若傳輸?shù)臄?shù)據(jù)為不帶結(jié)構(gòu)的連續(xù)流數(shù)據(jù)（如文件傳輸），則不必把粘連的包分開（簡(jiǎn)稱分包）。但在實(shí)際工程應(yīng)用中，傳輸?shù)臄?shù)據(jù)一般為帶結(jié)構(gòu)的數(shù)據(jù)，這時(shí)就需要做分包處理。

　　在處理定長(zhǎng)結(jié)構(gòu)數(shù)據(jù)的粘包問題時(shí)，分包算法比較簡(jiǎn)單；在處理不定長(zhǎng)結(jié)構(gòu)數(shù)據(jù)的粘包問題時(shí)，分包算法就比較復(fù)雜。特別是如圖3所示的粘包情況，由于一包數(shù)據(jù)內(nèi)容被分在了兩個(gè)連續(xù)的接收包中，處理起來難度較大。實(shí)際工程應(yīng)用中應(yīng)盡量避免出現(xiàn)粘包現(xiàn)象。

　　為了避免粘包現(xiàn)象，可采取以下幾種措施。一是對(duì)于發(fā)送方引起的粘包現(xiàn)象，用戶可通過編程設(shè)置來避免，TCP提供了強(qiáng)制數(shù)據(jù)立即傳送的操作指令push，TCP軟件收到該操作指令后，就立即將本段數(shù)據(jù)發(fā)送出去，而不必等待發(fā)送緩沖區(qū)滿；二是對(duì)于接收方引起的粘包，則可通過優(yōu)化程序設(shè)計(jì)、精簡(jiǎn)接收進(jìn)程工作量、提高接收進(jìn)程優(yōu)先級(jí)等措施，使其及時(shí)接收數(shù)據(jù)，從而盡量避免出現(xiàn)粘包現(xiàn)象；三是由接收方控制，將一包數(shù)據(jù)按結(jié)構(gòu)字段，人為控制分多次接收，然后合并，通過這種手段來避免粘包。

　　以上提到的三種措施，都有其不足之處。第一種編程設(shè)置方法雖然可以避免發(fā)送方引起的粘包，但它關(guān)閉了優(yōu)化算法，降低了網(wǎng)絡(luò)發(fā)送效率，影響應(yīng)用程序的性能，一般不建議使用。第二種方法只能減少出現(xiàn)粘包的可能性，但并不能完全避免粘包，當(dāng)發(fā)送頻率較高時(shí)，或由于網(wǎng)絡(luò)突發(fā)可能使某個(gè)時(shí)間段數(shù)據(jù)包到達(dá)接收方較快，接收方還是有可能來不及接收，從而導(dǎo)致粘包。第三種方法雖然避免了粘包，但應(yīng)用程序的效率較低，對(duì)實(shí)時(shí)應(yīng)用的場(chǎng)合不適合。

　　一種比較周全的對(duì)策是：接收方創(chuàng)建一預(yù)處理線程，對(duì)接收到的數(shù)據(jù)包進(jìn)行預(yù)處理，將粘連的包分開。對(duì)這種方法我們進(jìn)行了實(shí)驗(yàn)，證明是高效可行的。

三、編程與實(shí)現(xiàn)

　　1．實(shí)現(xiàn)框架

　　實(shí)驗(yàn)網(wǎng)絡(luò)通信程序采用TCP/IP協(xié)議的socket api編程實(shí)現(xiàn)。socket是面向客戶機(jī)/服務(wù)器模型的。TCP實(shí)現(xiàn)框架如圖4所示。


圖4

　　2．實(shí)驗(yàn)硬件環(huán)境：

　　服務(wù)器：pentium 350 微機(jī)

　　客戶機(jī)：pentium 166微機(jī)

　　網(wǎng)絡(luò)平臺(tái)：由10兆共享式hub連接而成的局域網(wǎng)

　　3．實(shí)驗(yàn)軟件環(huán)境：

　　操作系統(tǒng)：windows 98

　　編程語言：visual c++ 5.0

　　4．主要線程

　　編程采用多線程方式，服務(wù)器端共有兩個(gè)線程：發(fā)送數(shù)據(jù)線程、發(fā)送統(tǒng)計(jì)顯示線程。客戶端共有三個(gè)線程：接收數(shù)據(jù)線程、接收預(yù)處理粘包線程、接收統(tǒng)計(jì)顯示線程。其中，發(fā)送和接收線程優(yōu)先級(jí)設(shè)為thread_priority_time_critical（最高優(yōu)先級(jí)），預(yù)處理線程優(yōu)先級(jí)為thread_priority_above_normal（高于普通優(yōu)先級(jí)），顯示線程優(yōu)先級(jí)為thread_priority_normal（普通優(yōu)先級(jí)）。

　　實(shí)驗(yàn)發(fā)送數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)如圖5所示：

?

圖5

　　5．分包算法

　　針對(duì)三種不同的粘包現(xiàn)象，分包算法分別采取了相應(yīng)的解決辦法。其基本思路是首先將待處理的接收數(shù)據(jù)流（長(zhǎng)度設(shè)為m）強(qiáng)行轉(zhuǎn)換成預(yù)定的結(jié)構(gòu)數(shù)據(jù)形式，并從中取出結(jié)構(gòu)數(shù)據(jù)長(zhǎng)度字段，即圖5中的n，而后根據(jù)n計(jì)算得到第一包數(shù)據(jù)長(zhǎng)度。

　　1)若n<m，則表明數(shù)據(jù)流包含多包數(shù)據(jù)，從其頭部截取n個(gè)字節(jié)存入臨時(shí)緩沖區(qū)，剩余部分?jǐn)?shù)據(jù)依此繼續(xù)循環(huán)處理，直至結(jié)束。

　　2)若n=m，則表明數(shù)據(jù)流內(nèi)容恰好是一完整結(jié)構(gòu)數(shù)據(jù)，直接將其存入臨時(shí)緩沖區(qū)即可。

　　3)若n>m，則表明數(shù)據(jù)流內(nèi)容尚不夠構(gòu)成一完整結(jié)構(gòu)數(shù)據(jù)，需留待與下一包數(shù)據(jù)合并后再行處理。

　　對(duì)分包算法具體內(nèi)容及軟件實(shí)現(xiàn)有興趣者，可與作者聯(lián)系。

四、實(shí)驗(yàn)結(jié)果分析

　　實(shí)驗(yàn)結(jié)果如下：

　　1．在上述實(shí)驗(yàn)環(huán)境下，當(dāng)發(fā)送方連續(xù)發(fā)送的若干包數(shù)據(jù)長(zhǎng)度之和小于1500b時(shí)，常會(huì)出現(xiàn)粘包現(xiàn)象，接收方經(jīng)預(yù)處理線程處理后能正確解開粘在一起的包。若程序中設(shè)置了“發(fā)送不延遲”：（setsockopt (socket_name，ipproto_tcp，tcp_nodelay，(char *) &on，sizeof on) ，其中on=1），則不存在粘包現(xiàn)象。

　　2．當(dāng)發(fā)送數(shù)據(jù)為每包1kb～2kb的不定長(zhǎng)數(shù)據(jù)時(shí)，若發(fā)送間隔時(shí)間小于10ms，偶爾會(huì)出現(xiàn)粘包，接收方經(jīng)預(yù)處理線程處理后能正確解開粘在一起的包。

　　3．為測(cè)定處理粘包的時(shí)間，發(fā)送方依次循環(huán)發(fā)送長(zhǎng)度為1.5kb、1.9kb、1.2kb、1.6kb、1.0kb數(shù)據(jù)，共計(jì)1000包。為制造粘包現(xiàn)象，接收線程每次接收前都等待10ms，接收緩沖區(qū)設(shè)為5000b，結(jié)果接收方收到526包數(shù)據(jù)，其中長(zhǎng)度為5000b的有175包。經(jīng)預(yù)處理線程處理可得到1000包正確數(shù)據(jù)，粘包處理總時(shí)間小于1ms。

　　實(shí)驗(yàn)結(jié)果表明，TCP粘包現(xiàn)象確實(shí)存在，但可通過接收方的預(yù)處理予以解決，而且處理時(shí)間非常短（實(shí)驗(yàn)中1000包數(shù)據(jù)總共處理時(shí)間不到1ms），幾乎不影響應(yīng)用程序的正常工作。

?