原文部落格地址：http://blog.csdn.net/zhangxinrun/article/details/6721495

TCP粘包分析

這兩天看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軟體收到該操作指令後，就立即將本段資料傳送出去，而不必等待發送緩衝區滿；二是對於接收方引起的粘包，則可通過優化程式設計、精簡接收程序工作量、提高接收程序優先順序等措施，使其及時接收資料，從而儘量避免出現粘包現象；三是由接收方控制，將一包資料按結構欄位，人為控制分多次接收，然後合併，通過這種手段來避免粘包。

以上提到的三種措施，都有其不足之處。第一種程式設計設定方法雖然可以避免傳送方引起的粘包，但它關閉了優化演算法，降低了網路傳送效率，影響應用程式的效能，一般不建議使用。第二種方法只能減少出現粘包的可能性，但並不能完全避免粘包，當傳送頻率較高時，或由於網路突發可能使某個時間段資料包到達接收方較快，接收方還是有可能來不及接收，從而導致粘包。第三種方法雖然避免了粘包，但應用程式的效率較低，對實時應用的場合不適合。
載自：http://blog.csdn.net/binghuazh/archive/2009/05/28/4222516.aspx
====================================================================

網路通訊的封包和拆包 收藏

對於基於TCP開發的通訊程式,有個很重要的問題需要解決,就是封包和拆包.

一.為什麼基於TCP的通訊程式需要進行封包和拆包.

TCP是個"流"協議,所謂流,就是沒有界限的一串資料.大家可以想想河裡的流水,是連成一片的,其間是沒有分界線的.但一般通訊程式開發是需要定義一個個相互獨立的資料包的,比如用於登陸的資料包,用於登出的資料包.由於TCP"流"的特性以及網路狀況,在進行資料傳輸時會出現以下幾種情況.
假設我們連續呼叫兩次send分別傳送兩段資料data1和data2,在接收端有以下幾種接收情況(當然不止這幾種情況,這裡只列出了有代表性的情況).
A.先接收到data1,然後接收到data2.
B.先接收到data1的部分資料,然後接收到data1餘下的部分以及data2的全部.
C.先接收到了data1的全部資料和data2的部分資料,然後接收到了data2的餘下的資料.
D.一次性接收到了data1和data2的全部資料.

對於A這種情況正是我們需要的,不再做討論.對於B,C,D的情況就是大家經常說的"粘包",就需要我們把接收到的資料進行拆包,拆成一個個獨立的資料包.為了拆包就必須在傳送端進行封包.

另:對於UDP來說就不存在拆包的問題,因為UDP是個"資料包"協議,也就是兩段資料間是有界限的,在接收端要麼接收不到資料要麼就是接收一個完整的一段資料,不會少接收也不會多接收.

二.為什麼會出現B.C.D的情況.
"粘包"可發生在傳送端也可發生在接收端.
1.由Nagle演算法造成的傳送端的粘包:Nagle演算法是一種改善網路傳輸效率的演算法.簡單的說,當我們提交一段資料給TCP傳送時,TCP並不立刻傳送此段資料,而是等待一小段時間,看看在等待期間是否還有要傳送的資料,若有則會一次把這兩段資料傳送出去.這是對Nagle演算法一個簡單的解釋,詳細的請看相關書籍.象C和D的情況就有可能是Nagle演算法造成的.
2.接收端接收不及時造成的接收端粘包:TCP會把接收到的資料存在自己的緩衝區中,然後通知應用層取資料.當應用層由於某些原因不能及時的把TCP的資料取出來,就會造成TCP緩衝區中存放了幾段資料.

三.怎樣封包和拆包.
   最初遇到"粘包"的問題時,我是通過在兩次send之間呼叫sleep來休眠一小段時間來解決.這個解決方法的缺點是顯而易見的,使傳輸效率大大降低,而且也並不可靠.後來就是通過應答的方式來解決,儘管在大多數時候是可行的,但是不能解決象B的那種情況,而且採用應答方式增加了通訊量,加重了網路負荷. 再後來就是對資料包進行封包和拆包的操作.
    封包:
封包就是給一段資料加上包頭,這樣一來資料包就分為包頭和包體兩部分內容了(以後講過濾非法包時封包會加入"包尾"內容).包頭其實上是個大小固定的結構體,其中有個結構體成員變量表示包體的長度,這是個很重要的變數,其他的結構體成員可根據需要自己定義.根據包頭長度固定以及包頭中含有包體長度的變數就能正確的拆分出一個完整的資料包.
    對於拆包目前我最常用的是以下兩種方式.
    1.動態緩衝區暫存方式.之所以說緩衝區是動態的是因為當需要緩衝的資料長度超出緩衝區的長度時會增大緩衝區長度.
    大概過程描述如下:
    A,為每一個連線動態分配一個緩衝區,同時把此緩衝區和SOCKET關聯,常用的是通過結構體關聯.
    B,當接收到資料時首先把此段資料存放在緩衝區中.
    C,判斷快取區中的資料長度是否夠一個包頭的長度,如不夠,則不進行拆包操作.
    D,根據包頭資料解析出裡面代表包體長度的變數.
    E,判斷快取區中除包頭外的資料長度是否夠一個包體的長度,如不夠,則不進行拆包操作.
    F,取出整個資料包.這裡的"取"的意思是不光從緩衝區中拷貝出資料包,而且要把此資料包從快取區中刪除掉.刪除的辦法就是把此包後面的資料移動到緩衝區的起始地址.

這種方法有兩個缺點.1.為每個連線動態分配一個緩衝區增大了記憶體的使用.2.有三個地方需要拷貝資料,一個地方是把資料存放在緩衝區,一個地方是把完整的資料包從緩衝區取出來,一個地方是把資料包從緩衝區中刪除.第二種拆包的方法會解決和完善這些缺點.

前面提到過這種方法的缺點.下面給出一個改進辦法, 即採用環形緩衝.但是這種改進方法還是不能解決第一個缺點以及第一個資料拷貝,只能解決第三個地方的資料拷貝(這個地方是拷貝資料最多的地方).第2種拆包方式會解決這兩個問題.
環形緩衝實現方案是定義兩個指標,分別指向有效資料的頭和尾.在存放資料和刪除資料時只是進行頭尾指標的移動.

2.利用底層的緩衝區來進行拆包
由於TCP也維護了一個緩衝區,所以我們完全可以利用TCP的緩衝區來快取我們的資料,這樣一來就不需要為每一個連線分配一個緩衝區了.另一方面我們知道recv或者wsarecv都有一個引數,用來表示我們要接收多長長度的資料.利用這兩個條件我們就可以對第一種方法進行優化.
     對於阻塞SOCKET來說,我們可以利用一個迴圈來接收包頭長度的資料,然後解析出代表包體長度的那個變數,再用一個迴圈來接收包體長度的資料.
相關程式碼如下:
  
char PackageHead[1024];
char PackageContext[1024*20];

int len;
PACKAGE_HEAD *pPackageHead;
while( m_bClose == false )
{
memset(PackageHead,0,sizeof(PACKAGE_HEAD));
len = m_TcpSock.ReceiveSize((char*)PackageHead,sizeof(PACKAGE_HEAD));
if( len == SOCKET_ERROR )
{
    break;
}
if(len == 0)
{
    break;
}
pPackageHead = (PACKAGE_HEAD *)PackageHead;
memset(PackageContext,0,sizeof(PackageContext));
if(pPackageHead->nDataLen>0)
{
len = m_TcpSock.ReceiveSize((char*)PackageContext,pPackageHead->nDataLen);
}
        }

m_TcpSock是一個封裝了SOCKET的類的變數,其中的ReceiveSize用於接收一定長度的資料,直到接收了一定長度的資料或者網路出錯才返回.

int winSocket::ReceiveSize( char* strData, int iLen )
{
if( strData == NULL )
return ERR_BADPARAM;
char *p = strData;
int len = iLen;
int ret = 0;
int returnlen = 0;
while( len > 0)
{
ret = recv( m_hSocket, p+(iLen-len), iLen-returnlen, 0 );
if ( ret == SOCKET_ERROR || ret == 0 )
{

return ret;
}

len -= ret;
returnlen += ret;
}

return returnlen;
}
對於非阻塞的SOCKET,比如完成埠,我們可以提交接收包頭長度的資料的請求,當 GetQueuedCompletionStatus返回時,我們判斷接收的資料長度是否等於包頭長度,若等於,則提交接收包體長度的資料的請求,若不等於則提交接收剩餘資料的請求.當接收包體時,採用類似的方法.

載自： http://blog.csdn.net/fjcailei/archive/2009/06/17/4276463.aspx
======================================================================
幾個問題：http://www.qqgb.com/Program/VC/VCJQ/Program_200509.html
這個問題產生於程式設計中遇到的幾個問題： 
1、使用TCP的Socket傳送資料的時候，會出現傳送出錯，WSAEWOULDBLOCK，在TCP中不是會保證傳送的資料能夠安全的到達接收端的嗎？也有視窗機制去防止傳送速度過快，為什麼還會出錯呢？ 

2、TCP協議，在使用Socket傳送資料的時候，每次傳送一個包，接收端是完整的接受到一個包還是怎麼樣？如果是每發一個包，就接受一個包，為什麼還會出現粘包問題，具體是怎麼執行的？ 

3、關於Send，是不是隻有在非阻塞狀態下才會出現實際傳送的比指定傳送的小？在阻塞狀態下會不會出現實際傳送的比指定傳送的小，就是說只能出現要麼全傳送，要麼不傳送？在非阻塞狀態下，如果之傳送了一些資料，要怎麼處理，呼叫了Send函式後，發現返回值比指定的要小，具體要怎麼做？ 

4、最後一個問題，就是TCP/IP協議和Socket是什麼關係？是指具體的實現上，Socket是TCP/IP的實現？那麼為什麼會出現使用TCP協議的Socket會發送出錯（又回到第一個問題了，汗一個） 

實在是有點暈了，如果我的問題有不清楚的地方，或者分數有問題，歡迎指出，謝謝

這個問題第1個回答：
1 應該是你的緩衝區不夠大, 
2 tcp是流,沒有界限.也就所所謂的包. 
3 阻塞也會出現這種現象,出現後繼續傳送沒傳送出去的. 
4 tcp是協議,socket是一種介面,沒必然聯絡.錯誤取決於你使用介面的問題,跟tcp沒關係.

這個問題第2個回答：
1 應該是你的緩衝區不夠大, 
2 tcp是流,沒有界限.也就無所謂包. 
3 阻塞也會出現這種現象,出現後繼續傳送沒傳送出去的. 
4 tcp是協議,socket是一種介面,沒必然聯絡.錯誤取決於你使用介面的問題,跟tcp沒關係.

這個問題第3個回答：
1、應該不是緩衝區大小問題，我試過設定緩衝區大小，不過這裡有個問題，就是就算我把緩衝區設定成幾G，也返回成功，不過實際上怎麼可能設定那麼大、、、 

3、出現沒傳送完的時候要手動傳送吧，有沒有具體的程式碼實現？ 

4、當選擇TCP的Socket傳送資料的時候，TCP中的視窗機制不是能防止傳送速度過快的嗎？為什麼Socket在出現了WSAEWOULDBLOCK後沒有處理？

這個問題第4個回答：
1.在使用非阻塞模式的情況下，如果系統傳送緩衝區已滿，並示及時傳送到對端，就會產生該錯誤，繼續重試即可。 
3.如果沒有發完就繼續傳送後續部分即可。

這個問題第5個回答：
1、使用非阻塞模式時，如果當前操作不能立即完成則會返回失敗，錯誤碼是WSAEWOULDBLOCK，這是正常的，程式可以先執行其它任務，過一段時間後再重試該操作。 
2、傳送與接收不是一一對應的，TCP會把各次傳送的資料重新組合，可能合併也可能拆分，但傳送次序是不變的。 
3、在各種情況下都要根據send的返回值來確定傳送了多少資料，沒有傳送完就再接著發。 
4、socket是Windows提供網路程式設計介面，TCP/IP是網路傳輸協議，使用socket是可以使用多種協議，其中包括TCP/IP。

這個問題第6個回答：
up

這個問題第7個回答：
傳送的過程是：傳送到緩衝區和從緩衝區傳送到網路上 
WSAEWOULDBLOCK和粘包都是出現在傳送到緩衝區這個過程的