這兩天看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
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/binghuazh/archive/2009/05/28/4222516.aspx
解決TCP網絡傳輸“粘包”問題
當前在網絡傳輸應用中，廣泛采用的是TCP/IP通信協議及其標準的socket應用開發編程接口（API）。TCP/IP傳輸層有兩個并列的協議：TCP和UDP。其中TCP（transport control protocol，傳輸控制協議）是面向連接的，提供高可靠性服務。UDP（user datagram protocol，用戶數據報協議）是無連接的，提供高效率服務。在實際工程應用中，對可靠性和效率的選擇取決于應用的環境和需求。一般情況下，普通數據的網絡傳輸采用高效率的udp，重要數據的網絡傳輸采用高可靠性的TCP。
在應用開發過程中，筆者發現基于TCP網絡傳輸的應用程序有時會出現粘包現象（即發送方發送的若干包數據到接收方接收時粘成一包）。針對這種情況，我們進行了專題研究與實驗。本文重點分析了TCP網絡粘包問題，并結合實驗結果提出了解決該問題的對策和方法，供有關工程技術人員參考。
一、TCP協議簡介
TCP是一個面向連接的傳輸層協議，雖然TCP不屬于iso制定的協議集，但由于其在商業界和工業界的成功應用，它已成為事實上的網絡標準，廣泛應用于各種網絡主機間的通信。
作為一個面向連接的傳輸層協議，TCP的目標是為用戶提供可靠的端到端連接，保證信息有序無誤的傳輸。它除了提供基本的數據傳輸功能外，還為保證可靠性采用了數據編號、校驗和計算、數據確認等一系列措施。它對傳送的每個數據字節都進行編號，并請求接收方回傳確認信息（ack）。發送方如果在規定的時間內沒有收到數據確認，就重傳該數據。數據編號使接收方能夠處理數據的失序和重復問題。數據誤碼問題通過在每個傳輸的數據段中增加校驗和予以解決，接收方在接收到數據后檢查校驗和，若校驗和有誤，則丟棄該有誤碼的數據段，并要求發送方重傳。流量控制也是保證可靠性的一個重要措施，若無流控，可能會因接收緩沖區溢出而丟失大量數據，導致許多重傳，造成網絡擁塞惡性循環。TCP采用可變窗口進行流量控制，由接收方控制發送方發送的數據量。
TCP為用戶提供了高可靠性的網絡傳輸服務，但可靠性保障措施也影響了傳輸效率。因此，在實際工程應用中，只有關鍵數據的傳輸才采用TCP，而普通數據的傳輸一般采用高效率的udp。
二、粘包問題分析與對策
TCP粘包是指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩沖區看，后一包數據的頭緊接著前一包數據的尾。
出現粘包現象的原因是多方面的，它既可能由發送方造成，也可能由接收方造成。發送方引起的粘包是由TCP協議本身造成的，TCP為提高傳輸效率，發送方往往要收集到足夠多的數據后才發送一包數據。若連續幾次發送的數據都很少，通常TCP會根據優化算法把這些數據合成一包后一次發送出去，這樣接收方就收到了粘包數據。接收方引起的粘包是由于接收方用戶進程不及時接收數據，從而導致粘包現象。這是因為接收方先把收到的數據放在系統接收緩沖區，用戶進程從該緩沖區取數據，若下一包數據到達時前一包數據尚未被用戶進程取走，則下一包數據放到系統接收緩沖區時就接到前一包數據之后，而用戶進程根據預先設定的緩沖區大小從系統接收緩沖區取數據，這樣就一次取到了多包數據（圖1所示）。
?
圖1
?
圖2
?
圖3
粘包情況有兩種，一種是粘在一起的包都是完整的數據包（圖1、圖2所示），另一種情況是粘在一起的包有不完整的包（圖3所示），此處假設用戶接收緩沖區長度為m個字節。
不是所有的粘包現象都需要處理，若傳輸的數據為不帶結構的連續流數據（如文件傳輸），則不必把粘連的包分開（簡稱分包）。但在實際工程應用中，傳輸的數據一般為帶結構的數據，這時就需要做分包處理。
在處理定長結構數據的粘包問題時，分包算法比較簡單；在處理不定長結構數據的粘包問題時，分包算法就比較復雜。特別是如圖3所示的粘包情況，由于一包數據內容被分在了兩個連續的接收包中，處理起來難度較大。實際工程應用中應盡量避免出現粘包現象。
為了避免粘包現象，可采取以下幾種措施。一是對于發送方引起的粘包現象，用戶可通過編程設置來避免，TCP提供了強制數據立即傳送的操作指令push，TCP軟件收到該操作指令后，就立即將本段數據發送出去，而不必等待發送緩沖區滿；二是對于接收方引起的粘包，則可通過優化程序設計、精簡接收進程工作量、提高接收進程優先級等措施，使其及時接收數據，從而盡量避免出現粘包現象；三是由接收方控制，將一包數據按結構字段，人為控制分多次接收，然后合并，通過這種手段來避免粘包。
以上提到的三種措施，都有其不足之處。第一種編程設置方法雖然可以避免發送方引起的粘包，但它關閉了優化算法，降低了網絡發送效率，影響應用程序的性能，一般不建議使用。第二種方法只能減少出現粘包的可能性，但并不能完全避免粘包，當發送頻率較高時，或由于網絡突發可能使某個時間段數據包到達接收方較快，接收方還是有可能來不及接收，從而導致粘包。第三種方法雖然避免了粘包，但應用程序的效率較低，對實時應用的場合不適合。
一種比較周全的對策是：接收方創建一預處理線程，對接收到的數據包進行預處理，將粘連的包分開。對這種方法我們進行了實驗，證明是高效可行的。
三、編程與實現
1．實現框架
實驗網絡通信程序采用TCP/IP協議的socket api編程實現。socket是面向客戶機/服務器模型的。TCP實現框架如圖4所示。
圖4
2．實驗硬件環境：
服務器：pentium 350 微機
客戶機：pentium 166微機
網絡平臺：由10兆共享式hub連接而成的局域網
3．實驗軟件環境：
操作系統：windows 98
編程語言：visual c++ 5.0
4．主要線程
編程采用多線程方式，服務器端共有兩個線程：發送數據線程、發送統計顯示線程。客戶端共有三個線程：接收數據線程、接收預處理粘包線程、接收統計顯示線程。其中，發送和接收線程優先級設為thread_priority_time_critical（最高優先級），預處理線程優先級為thread_priority_above_normal（高于普通優先級），顯示線程優先級為thread_priority_normal（普通優先級）。
實驗發送數據的數據結構如圖5所示：
?
圖5
5．分包算法
針對三種不同的粘包現象，分包算法分別采取了相應的解決辦法。其基本思路是首先將待處理的接收數據流（長度設為m）強行轉換成預定的結構數據形式，并從中取出結構數據長度字段，即圖5中的n，而后根據n計算得到第一包數據長度。
1)若n<m，則表明數據流包含多包數據，從其頭部截取n個字節存入臨時緩沖區，剩余部分數據依此繼續循環處理，直至結束。
2)若n=m，則表明數據流內容恰好是一完整結構數據，直接將其存入臨時緩沖區即可。
3)若n>m，則表明數據流內容尚不夠構成一完整結構數據，需留待與下一包數據合并后再行處理。
對分包算法具體內容及軟件實現有興趣者，可與作者聯系。
四、實驗結果分析
實驗結果如下：
1．在上述實驗環境下，當發送方連續發送的若干包數據長度之和小于1500b時，常會出現粘包現象，接收方經預處理線程處理后能正確解開粘在一起的包。若程序中設置了“發送不延遲”：（setsockopt (socket_name，ipproto_tcp，tcp_nodelay，(char *) &on，sizeof on) ，其中on=1），則不存在粘包現象。
2．當發送數據為每包1kb～2kb的不定長數據時，若發送間隔時間小于10ms，偶爾會出現粘包，接收方經預處理線程處理后能正確解開粘在一起的包。
3．為測定處理粘包的時間，發送方依次循環發送長度為1.5kb、1.9kb、1.2kb、1.6kb、1.0kb數據，共計1000包。為制造粘包現象，接收線程每次接收前都等待10ms，接收緩沖區設為5000b，結果接收方收到526包數據，其中長度為5000b的有175包。經預處理線程處理可得到1000包正確數據，粘包處理總時間小于1ms。
實驗結果表明，TCP粘包現象確實存在，但可通過接收方的預處理予以解決，而且處理時間非常短（實驗中1000包數據總共處理時間不到1ms），幾乎不影響應用程序的正常工作。
?