我們在前面曾經說過，傳送端可以是一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個位元組全部交給傳送緩衝區才返回。為避免這些情況干擾主程式的邏輯，確保讀寫我們所請求的位元組數，我們實現了兩個包裝函式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
ssize_t readn(
int fd,
void *buf, size_t count)
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)
else
if (nwritten ==
0)continue;
bufp += nwritten;
nleft -= nwritten;
}
return count;
}
需要注意的是一旦在我們的客戶端/伺服器程式中使用了這兩個函式，則每次讀取和寫入的大小應該是一致的，比如設定為1024個位元組，但定長包的問題在於不能根據實際情況讀取資料，可能會造成網路阻塞，比如現在我們只是敲入了幾個字元，卻還是得傳送1024個位元組，造成極大的空間浪費。
此時條目3是比較好的解決辦法，其實也可以算是自定義的一種簡單應用層協議。比如我們可以自定義乙個包體結構
struct packet ;
先接收固定的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)
n = ntohl(recvbuf.len);
ret = readn(conn, recvbuf.buf, n);
if (ret == -
1)err_exit(
"read error");
if (ret
//客戶端關閉
fputs(recvbuf.buf, stdout);
writen(conn, &recvbuf,
4 + n);
}
}
客戶端程式的修改與上類似，不再贅述。
對於條目4，舉例如
如tlv 編譯碼格式
struct
tlv__attribute__((packed));
注意value分配的是0大小，最後乙個成員為可變長的陣列（c99中的柔性陣列），對於tlv（type-length-value）形式的結構，或者其他需要變長度的結構體，用這種方式定義最好。使用起來非常方便，建立時，malloc一段結構體大小加上可變長資料長度的空間給它，可變長部分可按陣列的方式訪問，釋放時，直接把整個結構體free掉就可以了。__attribute__(packed)用來強制不對struct tlv進行4位元組對齊，目的是為了獲取真實的tlv的空間使用情況。
c++ code 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
int main(
void)
TCP協議中的粘包分包問題
使用tcp協議進行網路遊戲開發的時候，有粘包和分包兩個問題。粘包和分包是利用socket在tcp協議下內部的優化機制，在使用tcp協議進行資料的傳輸進行通訊的時候，會出現粘包分包問題的話，是由於優化導致，即內部的資料傳輸機制所導致的。在客戶端呼叫send 方法傳送資料，每傳送的資料稱為包 當傳送資料...
tcp粘包是怎麼產生的？
1 什麼是 tcp 粘包？傳送方傳送的多個資料報，到接收方緩衝區首尾相連，粘成一包，被接收。2 原因 tcp 協議預設使用 nagle 演算法可能會把多個資料報一次傳送到接收方。應用程讀取快取中的資料報的速度小於接收資料報的速度，快取中的多個資料報會被應用程式當成乙個包一次讀取。3 處理方法 傳送方...
tcp粘包問題
什麼是粘包問題 粘包問題的起因是socket的快取機制。簡而言之 粘包問題就是如何將連續的資料按照不同的資料幀截斷，以及如何處理殘包情況。分割資料需要按需分配。處理殘包也很簡單 等 等它發來下一包資料，不管他發來多少資料，先拿來512，接到上次那512後面。湊成完整的資料幀。當然也有可能你發現這次來...