粘包問題

目錄

• 1、什麼是粘包？
• 2、TCP發送數據的四種狀況
• 3、粘包的兩種狀況
  • 3.1 服務端
  • 3.2 客戶端
  • 3.3 服務端
  • 3.4 客戶端
• 4、補充問題一：爲什麼TCP是可靠傳輸，udp是不可靠傳輸
• 5、補充問題二：send(字節流)和recv(1024)及sendall

1、什麼是粘包？

注意：只有TCP有粘包現象，UDP永遠不會粘包，爲什麼，且聽我娓娓道來。

首先須要掌握一個socket收發消息的原理

發送端能夠是一K一K地發送數據，而接收端的應用程序能夠兩K兩K地提走數據，固然也有可能一次提走3K或6K數據，或者一次只提走幾個字節的數據，也就是說，應用程序所看到的數據是一個總體，或說是一個流（stream），一條消息有多少字節對應用程序是不可見的，所以TCP協議是面向流的協議，這也是容易出現粘包問題的緣由。而UDP是面向消息的協議，每一個UDP段都是一條消息，應用程序必須以消息爲單位提取數據，不能一次提取任意字節的數據，這一點和TCP是很不一樣的。怎樣定義消息呢？能夠認爲對方一次性write/send的數據爲一個消息，須要明白的是當對方send一條信息的時候，不管底層怎樣分段分片，TCP協議層會把構成整條消息的數據段排序完成後才呈如今內核緩衝區。

例如基於TCP的套接字客戶端往服務端上傳文件，發送時文件內容是按照一段一段的字節流發送的，在接收方看了，根本不知道該文件的字節流從何處開始，在何處結束。

所謂粘包問題主要仍是由於接收方不知道消息之間的界限，不知道一次性提取多少字節的數據所形成的。

此外，發送方引發的粘包是由TCP協議自己形成的，TCP爲提升傳輸效率，發送方每每要收集到足夠多的數據後才發送一個TCP段。若連續幾回須要send的數據都不多，一般TCP會根據優化算法把這些數據合成一個TCP段後一次發送出去，這樣接收方就收到了粘包數據。

• TCP（transport control protocol，傳輸控制協議）是面向鏈接的，面向流的，提供高可靠性服務。收發兩端（客戶端和服務器端）都要有一一成對的socket，所以，發送端爲了將多個發往接收端的包，更有效的發到對方，使用了優化方法（Nagle算法），將屢次間隔較小且數據量小的數據，合併成一個大的數據塊，而後進行封包。這樣，接收端，就難於分辨出來了，必須提供科學的拆包機制。 即面向流的通訊是無消息保護邊界的。

• UDP（user datagram protocol，用戶數據報協議）是無鏈接的，面向消息的，提供高效率服務。不會使用塊的合併優化算法，, 因爲UDP支持的是一對多的模式，因此接收端的skbuff(套接字緩衝區）採用了鏈式結構來記錄每個到達的UDP包，在每一個UDP包中就有了消息頭（消息來源地址，端口等信息），這樣，對於接收端來講，就容易進行區分處理了。 即面向消息的通訊是有消息保護邊界的。

• TCP是基於數據流的，因而收發的消息不能爲空，這就須要在客戶端和服務端都添加空消息的處理機制，防止程序卡住，而udp是基於數據報的，即使是你輸入的是空內容（直接回車），那也不是空消息，udp協議會幫你封裝上消息頭，實驗略

udp的recvfrom是阻塞的，一個recvfrom(x)必須對惟一一個sendinto(y),收完了x個字節的數據就算完成,如果y>x數據就丟失，這意味着udp根本不會粘包，可是會丟數據，不可靠

TCP的協議數據不會丟，沒有收完包，下次接收，會繼續上次繼續接收，己端老是在收到ack時纔會清除緩衝區內容。數據是可靠的，可是會粘包。

2、TCP發送數據的四種狀況

假設客戶端分別發送了兩個數據包D1和D2給服務端，因爲服務端一次讀取到的字節數是不肯定的，故可能存在如下4種狀況。

1. 服務端分兩次讀取到了兩個獨立的數據包，分別是D1和D2，沒有粘包和拆包；

2. 服務端一次接收到了兩個數據包，D1和D2粘合在一塊兒，被稱爲TCP粘包；

3. 服務端分兩次讀取到了兩個數據包，第一次讀取到了完整的D1包和D2包的部份內容，第二次讀取到了D2包的剩餘內容，這被稱爲TCP拆包；

4. 服務端分兩次讀取到了兩個數據包，第一次讀取到了D1包的部份內容D1_1，第二次讀取到了D1包的剩餘內容D1_2和D2包的整包。

特例：若是此時服務端TCP接收滑窗很是小，而數據包D1和D2比較大，頗有可能會發生第五種可能，即服務端分屢次才能將D1和D2包接收徹底，期間發生屢次拆包。

3、粘包的兩種狀況

1.發送端須要等緩衝區滿才發送出去，形成粘包（發送數據時間間隔很短，數據了很小，會合到一塊兒，產生粘包）

3.1 服務端

# _*_coding:utf-8_*_
__author__ = 'nickchen121'
from socket import *
ip_port = ('127.0.0.1', 8080)

TCP_socket_server = socket(AF_INET, SOCK_STREAM)
TCP_socket_server.bind(ip_port)
TCP_socket_server.listen(5)

conn, addr = TCP_socket_server.accept()

data1 = conn.recv(10)
data2 = conn.recv(10)

print('----->', data1.decode('utf-8'))
print('----->', data2.decode('utf-8'))

conn.close()

3.2 客戶端

# _*_coding:utf-8_*_
__author__ = 'nickchen121'
import socket
BUFSIZE = 1024
ip_port = ('127.0.0.1', 8080)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
res = s.connect_ex(ip_port)

s.send('hello'.encode('utf-8'))
s.send('feng'.encode('utf-8'))

2.接收方不及時接收緩衝區的包，形成多個包接收（客戶端發送了一段數據，服務端只收了一小部分，服務端下次再收的時候仍是從緩衝區拿上次遺留的數據，產生粘包）

3.3 服務端

# _*_coding:utf-8_*_
__author__ = 'nickchen121'
from socket import *
ip_port = ('127.0.0.1', 8080)

TCP_socket_server = socket(AF_INET, SOCK_STREAM)
TCP_socket_server.bind(ip_port)
TCP_socket_server.listen(5)

conn, addr = TCP_socket_server.accept()

data1 = conn.recv(2)  # 一次沒有收完整
data2 = conn.recv(10)  # 下次收的時候,會先取舊的數據,而後取新的

print('----->', data1.decode('utf-8'))
print('----->', data2.decode('utf-8'))

conn.close()

3.4 客戶端

# _*_coding:utf-8_*_
__author__ = 'nickchen121'
import socket
BUFSIZE = 1024
ip_port = ('127.0.0.1', 8080)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
res = s.connect_ex(ip_port)

s.send('hello feng'.encode('utf-8'))

4、補充問題一：爲什麼TCP是可靠傳輸，udp是不可靠傳輸

• 基於TCP的數據傳輸請參考個人另外一篇文章http://www.javashuo.com/article/p-ypkvyppo-dg.html，TCP在數據傳輸時，發送端先把數據發送到本身的緩存中，而後協議控制將緩存中的數據發往對端，對端返回一個ack=1，發送端則清理緩存中的數據，對端返回ack=0，則從新發送數據，因此TCP是可靠的

• udp發送數據，對端是不會返回確認信息的，所以不可靠

5、補充問題二：send(字節流)和recv(1024)及sendall

• recv裏指定的1024意思是從緩存裏一次拿出1024個字節的數據

• send的字節流是先放入己端緩存，而後由協議控制將緩存內容發往對端，若是待發送的字節流大小大於緩存剩餘空間，那麼數據丟失，用sendall就會循環調用send，數據不會丟失