我們在前面曾經說過,發送端可以是一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); } }
客戶端程序的修改與上類似,不再贅述。