原文地址：http://www.shnenglu.com/lapcca/archive/2010/09/10/126329.html

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

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

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

2.短連接

    Client方與Server每進行一次報文收發(fā)交易時才進行通訊連接，交易完畢后立即斷開連接。此種方式常用于一點對多點
通訊，比如多個Client連接一個Server.

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

1:如果利用tcp每次發(fā)送數(shù)據(jù)，就與對方建立連接，然后雙方發(fā)送完一段數(shù)據(jù)后，就關閉連接，這樣就不會出現(xiàn)粘包問題（因為只有一種包結(jié)構,類似于http協(xié)議）。關閉連接主要要雙方都發(fā)送close連接（參考tcp關閉協(xié)議）。如：A需要發(fā)送一段字符串給B，那么A與B建立連接，然后發(fā)送雙方都默認好的協(xié)議字符如"hello give me sth abour yourself"，然后B收到報文后，就將緩沖區(qū)數(shù)據(jù)接收,然后關閉連接，這樣粘包問題不用考慮到，因為大家都知道是發(fā)送一段字符。

2：如果發(fā)送數(shù)據(jù)無結(jié)構，如文件傳輸，這樣發(fā)送方只管發(fā)送，接收方只管接收存儲就ok，也不用考慮粘包

3：如果雙方建立連接，需要在連接后一段時間內(nèi)發(fā)送不同結(jié)構數(shù)據(jù)，如連接后，有好幾種結(jié)構：
1)"hello give me sth abour yourself"
2)"Don't give me sth abour yourself" 

 那這樣的話，如果發(fā)送方連續(xù)發(fā)送這個兩個包出去，接收方一次接收可能會是"hello give me sth abour yourselfDon't give me sth abour yourself" 這樣接收方就傻了，到底是要干嘛？不知道，因為協(xié)議沒有規(guī)定這么詭異的字符串，所以要處理把它分包，怎么分也需要雙方組織一個比較好的包結(jié)構，所以一般可能會在頭加一個數(shù)據(jù)長度之類的包，以確保接收。

三 粘包出現(xiàn)原因：在流傳輸中出現(xiàn)，UDP不會出現(xiàn)粘包，因為它有消息邊界(參考Windows 網(wǎng)絡編程)
1 發(fā)送端需要等緩沖區(qū)滿才發(fā)送出去，造成粘包
2 接收方不及時接收緩沖區(qū)的包，造成多個包接收

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

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

解決粘包問題：http://www.vckbase.com/document/viewdoc/?id=1203

在socket 文件傳輸中，獲取某個目錄下的所有文件，如果一個文件名傳輸一次通訊的話，127.0.0.1上測試沒有什么問題，當在局域網(wǎng)中傳輸2次以上，就會出現(xiàn)包丟失問題。我猜這個問題跟粘包有點相似。