Linux編程之socket:tcp流協議產生的粘包問題及解決方法

首先說明的是發送端可以是一K一K地發送數據，而接收端的應用程序可以兩K兩K地提走數據，當然也有可能一次提走3K或6K數據，或者一次只提走幾個字節的數據，也就是說，應用程序所看到的數據是一個整體，或說是一個流（stream），一條消息有多少字節對應用程序是不可見的，因此TCP協議是面向流的協議，這也是容易出現粘包問題的原因。而UDP是面向消息的協議，每個UDP段都是一條消息，應用程序必須以消息爲單位提取數據，不能一次提取任意字節的數據，這一點和TCP是很不同的。怎樣定義消息呢？可以認爲對方一次性write/send的數據爲一個消息，需要明白的是當對方send一條信息的時候，無論底層怎樣分段分片，TCP協議層會把構成整條消息的數據包排序完成後才呈現在內核緩衝區，所謂粘包問題主要還是因爲接收方不知道消息之間的界限，不知道一次性提取多少字節的數據所造成的。此外，發送方引起的粘包是由TCP協議本身造成的，TCP爲提高傳輸效率，發送方往往要收集到足夠多的數據後才發送一個TCP段。若連續幾次需要send的數據都很少，通常TCP會根據優化算法把這些數據合成一個TCP段後一次發送出去，這樣接收方就收到了粘包數據。

一、粘包問題可以用下圖來表示：

假設主機A send了兩條消息M1和M2各10k給主機B，由於主機B一次接收的字節數是不確定的，接收方收到數據的情況可能是：

• 一次性收到20k 數據
• 分兩次收到，第一次5k，第二次15k
• 分兩次收到，第一次15k，第二次5k
• 分兩次收到，第一次10k，第二次10k
• 分三次收到，第一次6k，第二次8k，第三次6k
• 其他任何可能

二、粘包問題的解決方案

本質上是要在應用層維護消息與消息的邊界（下文的“包”可以認爲是“消息”）
1、定長包
2、包尾加\r\n（ftp）
3、包頭加上包體長度

4、更復雜的應用層協議

對於條目2，缺點是如果消息本身含有\r\n字符，則也分不清消息的邊界。

對於條目1，即我們需要發送和接收定長包。因爲TCP協議是面向流的，read和write調用的返回值往往小於參數指定的字節數。對於read調用（套接字標誌爲阻塞），如果接收緩衝區中有20字節，請求讀100個字節，就會返回20。對於write調用，如果請求寫100個字節，而發送緩衝區中只有20個字節的空閒位置，那麼write會阻塞，直到把100個字節全部交給發送緩衝區才返回。爲避免這些情況干擾主程序的邏輯，確保讀寫我們所請求的字節數，我們實現了兩個包裝函數readn和writen，如下所示。

//readn函數包裝了read函數，用於讀取定長包
ssize_t readn(int fd, void *buf, size_t count)
{
    size_t nleft = count;//所要讀取的字節數
    ssize_t nread;
    char *bufp = (char *)buf;//指向buf緩衝區

    while (nleft > 0)//讀取數據，若讀取到buf的字節與請求的字節相同，則直接返回請求字節數
    {

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

//writen函數包裝了write函數，用於寫入定長包
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)//沒有寫滿buf緩衝區，繼續寫入數據
            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);
    }
}

對於條目4，舉例如 如TLV 編解碼格式

struct TLV
{
    uint8_t tag;
    uint16_t len;
    char value[0];
}__attribute__((packed));

注意value分配的是0大小，最後一個成員爲可變長的數組（c99中的柔性數組），對於TLV（Type-Length-Value）形式的結構，或者其他需要變長

度的結構體，用這種方式定義最好。使用起來非常方便，創建時，malloc一段結構體大小加上可變長數據長度的空間給它，可變長部分可按數組的方式

訪問，釋放時，直接把整個結構體free掉就可以了。__attribute__(packed)用來強制不對struct TLV進行4字節對齊，目的是爲了獲取真實的TLV的

空間使用情況。

int main(void)
{
    char *szMsg = "aaaaaaaaa";
    cout << sizeof(TLV) << endl; //the size of TLV
    uint16_t len = strlen(szMsg) + 1;
    struct TLV *pTLV;
    pTLV = (struct TLV *)malloc(sizeof(struct TLV) + sizeof(char) * len);
    pTLV->tag = 0x2;
    pTLV->len = len;
    memcpy(pTLV->value, szMsg, len);
    cout << pTLV->value << endl;
    free(pTLV);
    pTLV = NULL;
    return 0;
}