linux網路編程之socket（五）：tcp流協議產生的粘包問題和解決方案

我們在前面曾經說過，發送端可以是一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，如下所示。

 C++ Code 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66

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函數更改如下：

 C++ Code 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

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);     } }

用戶端程式的修改與上類似，不再贅述。

參考：

《Linux C 編程一站式學習》

《TCP/IP詳解 卷一》

《UNP》