我們在前面曾經說過，發送端可以是一K一K地發送數據，而接收端的應用程序可以兩K兩K地提走數據，當然也有可能一 次提走3K或6K數據，或者一次只提走幾個字節的數據，也就是說，應用程序所看到的數據是一個整體，或說是一個流 （stream），在底層通訊中這些數據可能被拆成很多數據包來發送，但是一個數據包有多少字節對應用程序是不可見的，因 此TCP協議是面向流的協議，這也是容易出現粘包問題的原因。而UDP是面向消息的協議，每個UDP段都是一條消息，應用程 序必須以消息為單位提取數據，不能一次提取任意字節的數據，這一點和TCP是很不同的。
一、粘包問題可以用下圖 來表示：
假設主機A發送了兩個數據包M1和M2給主機B，由於主機B一次接收的字節數是不確定的，故可能存在上圖的4種情 況，
1、分兩次接收兩個數據包，一次一個，沒有粘包問題；
2、一次接收了兩個數據包，存在粘包問題；
3、第一個接收了M1和M2的一部分，第二次接收M2的另一部分，存在粘包問題；
4、第一次接收了M1的一部分 ，第二次接收M1的另一部分和M2，存在粘包問題；
當然實際的情況可能不止以上4種，可以得知的是在互聯網上通信 很容易造成粘包問題。
二、粘包問題產生的原因
如下圖所示，產生的原因主要有3個，當應用程序 write 寫入的大小大於套接口發送緩沖區大小時；當進行MSS大小的tcp分段時；當以太網幀的payload大於MTU進行ip分片時 ；都很容易產生粘包問題。
三、粘包問題的解決方案
本質上是要 在應用層維護消息與消息的邊界
1、定長包
2、包尾加\r\n（ftp）
3、包頭加上包體長度
4、更復雜的應用層協議
對於條目2，缺點是如果消息本身含有\r\n字符，則也分不清消息的邊界，條目4不在本文討論范圍內。
對於條目1，即我們需要發送和接收定長包。因為TCP協議是面向流的，read和write調用的返回值往往小於參數指定的字 節數。對於read調用（套接字標志為阻塞），如果接收緩沖區中有20字節，請求讀100個字節，就會返回20。對於write調用 ，如果請求寫100個字節，而發送緩沖區中只有20個字節的空閒位置，那麼write會阻塞，直到把100個字節全部交給發送緩 沖區才返回，但如果socket文件描述符有O_NONBLOCK標志，則write不阻塞，直接返回20。為避免這些情況干擾主程序的邏 輯，確保讀寫我們所請求的字節數，我們實現了兩個包裝函數readn和writen，如下所示。
ssize_t readn(int
fd, void *buf, size_t count)
{
size_t nleft = count;
ssize_t nread;
char *bufp = (char *)buf;
while (nleft > 0)
{
ssize_t readn(int fd, void * buf, size_t count)
{
size_t nleft = count;
ssize_t nread;
char *bufp = (char *)buf;
while (nleft > 0)
{
if ((nread = read(fd, bufp, nleft)) < 0)
{
if (errno == EINTR)
continue;
return -1;
}
else if (nread == 0) //對方關閉或者已經讀到eof
return count - nleft;
bufp += nread;
nleft -= nread;
}
return count;
}
ssize_t writen(int fd, const void * buf, size_t count)
{
size_t nleft = count;
ssize_t nwritten;
char *bufp = (char *)buf;
while (nleft > 0)
{
if ((nwritten = write(fd, bufp, nleft)) < 0)
{
if (errno == EINTR)
continue;
return -1;
}
else if (nwritten == 0)
continue;
bufp += nwritten;
nleft -= nwritten;
}
return count;
}
需要注意的是一旦在我們的客戶端/服務器程序中使用了這兩個函數，則每次讀取和寫入的大小應該是 一致的，比如設置為1024個字節，但定長包的問題在於不能根據實際情況讀取數據，可能會造成網絡阻塞，比如現在我們只 是敲入了幾個字符，卻還是得發送1024個字節，造成極大的空間浪費。
此時條目3是比較好的解決辦法，其實也可以 算是自定義的一種簡單應用層協議。比如我們可以自定義一個包體結構
struct packet {
int len;
char buf[1024];
};
先接收固定的4個字節，從中得知實際數據的長度n，再調用readn 讀 取n個字符，這樣數據包之間有了界定，且不用發送定長包浪費網絡資源，是比較好的解決方案。服務器端在前面的fork程 序的基礎上把do_service函數更改如下：
void do_service(int conn)
{
struct packet recvbuf;
int n;
while (1)
{
memset(&recvbuf, 0, sizeof(recvbuf));
int ret = readn(conn, &recvbuf.len, 4);
if (ret == -1)
ERR_EXIT("read error");
else if (ret < 4) //客戶端關閉
{
printf("client close\n");
break;
}
n = ntohl(recvbuf.len);
ret = readn(conn, recvbuf.buf, n);
if (ret == -1)
ERR_EXIT("read error");
if (ret < n) //客戶端關閉
{
printf("client close\n");
break;
}
fputs(recvbuf.buf, stdout);
writen(conn, &recvbuf, 4 + n);
}
}
客戶端程序的修改與上類似，不再贅述。
