在socket網絡程序中，TCP和UDP分別是面向連接和非面向連接的。因此TCP的socket編程，收發(fā)兩端（客戶端和服務器端）都要有一一成對的socket，因此，發(fā)送端為了將多個發(fā)往接收端的包，更有效的發(fā)到對方，使用了優(yōu)化方法（Nagle算法），將多次間隔較小且數(shù)據(jù)量小的數(shù)據(jù)，合并成一個大的數(shù)據(jù)塊，然后進行封包。這樣，接收端，就難于分辨出來了，必須提供科學的拆包機制。
對于UDP，不會使用塊的合并優(yōu)化算法，這樣，實際上目前認為，是由于UDP支持的是一對多的模式，所以接收端的skbuff(套接字緩沖區(qū)）采用了鏈式結構來記錄每一個到達的UDP包，在每個UDP包中就有了消息頭（消息來源地址，端口等信息），這樣，對于接收端來說，就容易進行區(qū)分處理了
保護消息邊界和流那么什么是保護消息邊界和流呢?
保護消息邊界，就是指傳輸協(xié)議把數(shù)據(jù)當作一條獨立的消息在網上
傳輸,接收端只能接收獨立的消息.也就是說存在保護消息邊界,接收
端一次只能接收發(fā)送端發(fā)出的一個數(shù)據(jù)包.
而面向流則是指無保護消息保護邊界的,如果發(fā)送端連續(xù)發(fā)送數(shù)據(jù),
接收端有可能在一次接收動作中,會接收兩個或者更多的數(shù)據(jù)包.
我們舉個例子來說,例如,我們連續(xù)發(fā)送三個數(shù)據(jù)包,大小分別是2k,
4k , 8k,這三個數(shù)據(jù)包,都已經到達了接收端的網絡堆棧中,如果使
用UDP協(xié)議,不管我們使用多大的接收緩沖區(qū)去接收數(shù)據(jù),我們必須有
三次接收動作,才能夠把所有的數(shù)據(jù)包接收完.而使用TCP協(xié)議,我們
只要把接收的緩沖區(qū)大小設置在14k以上,我們就能夠一次把所有的
數(shù)據(jù)包接收下來.只需要有一次接收動作.
這就是因為UDP協(xié)議的保護消息邊界使得每一個消息都是獨立的.而
流傳輸,卻把數(shù)據(jù)當作一串數(shù)據(jù)流,他不認為數(shù)據(jù)是一個一個的消息.
所以有很多人在使用tcp協(xié)議通訊的時候,并不清楚tcp是基于流的
傳輸,當連續(xù)發(fā)送數(shù)據(jù)的時候,他們時常會認識tcp會丟包.其實不然,
因為當他們使用的緩沖區(qū)足夠大時,他們有可能會一次接收到兩個甚
至更多的數(shù)據(jù)包,而很多人往往會忽視這一點,只解析檢查了第一個
數(shù)據(jù)包,而已經接收的其他數(shù)據(jù)包卻被忽略了.所以大家如果要作這
類的網絡編程的時候,必須要注意這一點.
結論：
根據(jù)以上所說，可以這樣理解，TCP為了保證可靠傳輸，盡量減少額外
開銷（每次發(fā)包都要驗證），因此采用了流式傳輸，面向流的傳輸，
相對于面向消息的傳輸，可以減少發(fā)送包的數(shù)量。從而減少了額外開
銷。但是，對于數(shù)據(jù)傳輸頻繁的程序來講，使用TCP可能會容易粘包。
當然，對接收端的程序來講，如果機器負荷很重，也會在接收緩沖里
粘包。這樣，就需要接收端額外拆包，增加了工作量。因此，這個特
別適合的是數(shù)據(jù)要求可靠傳輸，但是不需要太頻繁傳輸?shù)膱龊希?br style="line-height: 22px; " />兩次操作間隔100ms，具體是由TCP等待發(fā)送間隔決定的，取決于內核
中的socket的寫法）
而UDP，由于面向的是消息傳輸，它把所有接收到的消息都掛接到緩沖
區(qū)的接受隊列中，因此，它對于數(shù)據(jù)的提取分離就更加方便，但是，
它沒有粘包機制，因此，當發(fā)送數(shù)據(jù)量較小的時候，就會發(fā)生數(shù)據(jù)包
有效載荷較小的情況，也會增加多次發(fā)送的系統(tǒng)發(fā)送開銷（系統(tǒng)調用，
寫硬件等）和接收開銷。因此，應該最好設置一個比較合適的數(shù)據(jù)包
的包長，來進行UDP數(shù)據(jù)的發(fā)送。（UDP最大載荷為1472，因此最好能
每次傳輸接近這個數(shù)的數(shù)據(jù)量，這特別適合于視頻，音頻等大塊數(shù)據(jù)
的發(fā)送，同時，通過減少握手來保證流媒體的實時性）
來自: http://hi.baidu.com/chongerfeia/blog/item/b1e572f631dd7e28bd310965.html
TCP無保護消息邊界的解決
針對這個問題，一般有3種解決方案：
(1)發(fā)送固定長度的消息
(2)把消息的尺寸與消息一塊發(fā)送
(3)使用特殊標記來區(qū)分消息間隔
下面我們主要分析下前兩種方法：
1、發(fā)送固定長度的消息
這種方法的好處是他非常容易，而且只要指定好消息的長度，沒有遺漏未未發(fā)的數(shù)據(jù)，我們重寫了一個SendMessage方法。代碼如下：
private static int SendMessage(Socket s, byte[] msg)
{
int offset = 0;
int size = msg.Length;
int dataleft = size;
while (dataleft > 0)
{
int sent = s.Send(msg, offset, SocketFlags.None);
offset += sent;
dataleft -= sent;
}
return offset;
}
簡要分析一下這個函數(shù)：形參s是進行通信的套接字，msg即待發(fā)送的字節(jié)數(shù)組。該方法使用while循環(huán)檢查是否還有數(shù)據(jù)未發(fā)送，尤其當發(fā)送一個很龐大的數(shù)據(jù)包，在不能一次性發(fā)完的情況下作用比較明顯。特別的，用sent來記錄實際發(fā)送的數(shù)據(jù)量，和recv是異曲同工的作用，最后返回發(fā)送的實際數(shù)據(jù)總數(shù)。
有sentMessage函數(shù)后，還要根據(jù)指定的消息長度來設計一個新的Recive方法。代碼如下：
private byte[] ReciveMessage(Socket s, int size)
{
int offset = 0;
int recv;
int dataleft = size;
byte[] msg = new byte[size];
while (dataleft > 0)
{
//接收消息
recv = s.Receive(msg, offset, dataleft, 0);
if (recv == 0)
{
break;
}
offset += recv;
dataleft -= recv;
}
return msg;
}
以上這種做法比較適合于消息長度不是很長的情況。
2、消息長度與消息一同發(fā)送
我們可以這樣做：通過使用消息的整形數(shù)值來表示消息的實際大小，所以要把整形數(shù)轉換為字節(jié)類型。下面是發(fā)送變長消息的SendMessage方法。具體代碼如下：
private static int SendMessage(Socket s, byte[] msg)
{
int offset = 0;
int sent;
int size = msg.Length;
int dataleft = size;
byte[] msgsize = new byte[2];
//將消息尺寸從整形轉換成可以發(fā)送的字節(jié)型
msgsize = BitConverter.GetBytes(size);
//發(fā)送消息的長度信息
sent = s.Send(size);
while (dataleft > 0)
{
sent = s.Send(msg, offset, dataleft, SocketFlags.None);
//設置偏移量
offset += sent;
dataleft -= sent;
}
return offset;
}
下面是接收變長消息的ReciveVarMessage方法。代碼如下：
private byte[] ReciveVarMessage(Socket s)
{
int offset = 0;
int recv;
byte[] msgsize = new byte[2];
//將字節(jié)數(shù)組的消息長度信息轉換為整形
int size = BitConverter.ToInt16(msgsize);
int dataleft = size;
byte[] msg = new byte[size];
//接收2個字節(jié)大小的長度信息
recv = s.Receive(msgsize, 0, 2, 0);
while (dataleft > 0)
{
//接收數(shù)據(jù)
recv = s.Receive(msg, offset, dataleft, 0);
if (recv == 0)
{
break;
}
offset += recv;
dataleft -= recv;
}
return msg;
}