【传输协议】TCP粘包处理


注:只有TCP有粘包问题,而UDP永远不会粘包

TCP(transport control protocol,传输控制协议): 面向连接的,面向流的,提供高可靠性服务。收发两端都要有一一成对的socket,因此,发送端为了将多个发往接收端的包,更有效的发到对方,使用了优化方法(Nagle算法),将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包。这样,接收端,就难于分辨出来了,必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。

UDP(user datagram protocol,用户数据报协议): 是无连接的,面向消息的,提供高效率服务。不会使用块的合并优化算法,, 由于UDP支持的是一对多的模式,所以接收端的skbuff(套接字缓冲区)采用了链式结构来记录每一个到达的UDP包,在每个UDP包中就有了消息头(消息来源地址,端口等信息),这样,对于接收端来说,就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。

1. 粘包产生的原因

简单来说,粘包问题主要是因为接收方不知道消息之间的界限,不知道一个消息要提取多少字节的数据所造成的。

发送方引起的粘包是由TCP协议本身造成的,TCP为提高传输效率,发送方往往要收集到足够多的数据后才发送一个TCP段。若连续几次需要send的数据都很少,通常TCP会根据优化算法把这些数据合成一个TCP段后一次发出去,这样接收方就收到了粘包数据。

2. 粘包情况

粘包情况一: 发送端要等缓冲区满才发送出去,如果每次send的数据量少且时间间隔短,就会合到一块去,造成粘包。

服务端代码:

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('127.0.0.1', 8000))
s.listen(5)
conn, addr = s.accept()
rec1 = conn.recv(1024)
rec2 = conn.recv(1024)
print("第一条信息:", str(rec1, 'utf8'))
print("第二条信息:", str(rec2, 'utf8'))
conn.close()
s.close()

客户端代码:

import socket

c = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
c.connect(('127.0.0.1', 8000))
c.send(b'hello')
c.send(b'world')
c.close()

服务端打印的信息是:

第一条信息:helloworld
第二条信息:

粘包情况二: 客户端发送了一段数据,服务端只收了一小部分,服务端下次再收的时候不是从缓冲区拿上次遗留的数据,产生粘包。
服务端代码:

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('127.0.0.1', 8000))
s.listen(5)
conn, addr = s.accept()
rec1 = conn.recv(2)
rec2 = conn.recv(3)
print("第一条信息:", str(rec1, 'utf8'))
print("第二条信息:", str(rec2, 'utf8'))
conn.close()
s.close()

客户端代码不变,服务端打印的信息为:

第一条信息:hel
第二条信息:lo
3. 解决粘包问题

目前比较合理的处理方法是:
为字节流加上一个报头,将这个报告做成字典,字典里包含将要发送的真实数据详细信息。
将这个字典JSON序列化,然后用struck将序列化后的数据长度打包成4个字节(4个字节完全够用)
注:struct是用来将整型的数字转成固定长度的bytes

服务端代码:

import socket
import struct
import json

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('127.0.0.1', 8000))
server.listen(5)

conn, addr = server.accept()
while True:
    try:
        client_cmd = str(conn.recv(1024), 'utf8')
        if client_cmd == 'exit':
            break
        send_data1 = input('输入发送的数据1>>>')
        send_data2 = input('输入发送的数据2>>>')
        #制作报头
        header_dic = {
            "send_data1" : len(send_data1),
            "send_data2" : len(send_data2),
        }
        header_json = json.dumps(header_dic)
        header_bytes = header_json.encode('utf-8')
        #用struct将报头长度转成固定的4字节长度
        header_size = len(header_bytes)
        conn.send(struct.pack('i', header_size))
        #发送报头
        conn.send(header_bytes)
        #发送数据
        conn.send(bytes(send_data1, "utf8"))
        conn.send(bytes(send_data2, "utf8"))
    except ConnectionResetError:
        break
conn.close()
server.close()

客户端代码:

import socket
import json
import struct

client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(('127.0.0.1', 8000))
while True:
    cmd = input('>>:').strip()
    if cmd == 'exit':
        break
    client.send(bytes(cmd,'utf8'))
    #接收报文长度
    header_size = struct.unpack('i', client.recv(4))[0]
    #接收报文
    header_bytes = client.recv(header_size)
    #解析报文
    header_json = header_bytes.decode('utf-8')
    header_dic = json.loads(header_json)
    #获取真实数据的长度
    data1_len = header_dic['send_data1']
    data2_len = header_dic['send_data2']
    #获取数据
    rec_data1 = client.recv(data1_len)
    rec_data2 = client.recv(data2_len)
    print(str(rec_data1, 'utf8'))
    print(str(rec_data2, 'utf8'))
client.close()

注:先运行服务端,再运行客户端。在客户端输入除"exit"以外的任何内容,服务端都可以开始输入要传送的消息。
本例服务端连续回复2条消息,为了测试粘包问题是否真正解决。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1.TCP是流传输,所以本质上不该称之为粘包,发送者和接收者都是自顾自的,要一段一段发得选UDP 现象是,你发出3个2048字节的包,发送时会被优化成4096/2048,或者跟之前的包合并,但是取出时却很随意,除了空载时的首个包,其他有可能拆成1-4096大小若干个包 2.“粘包”和“分包”很头疼,但是只要抓住第一个包,问题就解决了一大半 幸运的是,TCP发出的包不是乱序的,这有点像你按顺序写出字节集一样,只要你抓住头部的定义,就能轻而易举解构数据 为此,发送时,首个包要跟前一段数据流有时间间隔,好让之前的Recv操作完成(当然,条件允许可以Recv完成后反馈,发送端收到反馈消息再继续下一波) 3.定义协议结构,各有各的办法,以下代码仅作参考 .版本 2     pocket = 取空白字节集 (#pk_size)     DataAddr = 取变量指针 (pocket) + 8     pk_sign = 取字节集数据 (到字节集 (“P_KT”), #整数型, )     写数值ptr (DataAddr, #pk_sign, pk_sign)     写数值ptr (DataAddr, #pk_crch, CRC32all)     写数值ptr (DataAddr, #pk_crc32, CRC32all)     写数值ptr (DataAddr, #pk_SN, 集_SN)     写数值ptr (DataAddr, #pk_remain, size)     CRC32pk = CRC32_PTR (DataAddr, #pk_size)     写数值ptr (DataAddr, #pk_crch, CRC32pk) 4.使用哈希表存储分包数据 我认为哈希表存储的方式是线程安全的,客户句柄是唯一的,一个客户甚至分不到一条线程,该句柄对应的数据地址是唯一的,所以不会出现两条线程同时操作一个内存地址的情形 当然,出现碰撞时,插入链表这个操作不是线程安全的,这个以后优化 5.星光极速模块我只稍微改了一下,把原先字节集操作改成指针操作 6.没有选择HP-socket的原因是太庞大了,用来做服务端可以,但是如果作为客户端即使是静态库,编译之后也很大 7.目前涉分包组包的代码不多,其他的运用过程中不断改进 关于哈希表的部分,我专门开了个帖子 https://bbs.125.la/forum.php?mod=viewthreadtid=14659403

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值