数据接收之环形缓冲 TCP粘包处理-RingBuf方法

最新推荐文章于 2025-04-02 08:53:00 发布
最新推荐文章于 2025-04-02 08:53:00 发布
阅读量2.8k 收藏 4
点赞数 2
分类专栏： Network 文章标签： 环形缓冲 TCP粘包 RingBuf

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。粘包可能由发送方造成，也可能由接收方造成。TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据，造成多个数据包的粘连。如果接收进程不及时接收数据，已收到的数据就放在系统接收缓冲区，用户进程读取数据时就可能同时读到多个数据包。因为系统传输的数据是带结构的数据，需要做分包处理。

为了适应高速复杂网络条件，我们设计实现了粘包处理模块，由接收方通过预处理过程，对接收到的数据包进行预处理，将粘连的包分开。为了方便粘包处理，提高处理效率，在接收环节使用了环形缓冲区来存储接收到的数据。其结构如表1所示。

                                                            表1 环形缓冲结构

字段名

类型

含义

CS

CRITICAL_SECTION

保护环形缓冲的临界区

pRingBuf

UINT8*

缓冲区起始位置

pRead

UINT8*

当前未处理数据的起始位置

pWrite

UINT8*

当前未处理数据的结束位置

pLastWrite

UINT8*

当前缓冲区的结束位置

环形缓冲跟每个TCP套接字绑定。在每个TCP的SOCKET_OBJ创建时，同时创建一个PRINGBUFFER结构并初始化。这时候，pRingBuf指向环形缓冲区的内存首地址，pRead、pWrite指针也指向它。pLastWrite指针在这时候没有实际意义。初始化之后的结构如图1所示。

TCP粘包处理-RingBuf方法 - 辉煌至芯 - 辉煌至芒

图1 初始化后的环形缓冲区

在每次投递一个TCP的接收操作时，从RINGBUFFER获取内存作接收缓冲区，一般规定一个最大值L1作为可以写入的最大数据量。这时把pWrite的值赋给BUFFER_OBJ的buf字段，把L1赋给bufLen字段。这样每次接收到的数据就从pWrite开始写入缓冲区，最多写入L1字节，如图 2。

TCP粘包处理-RingBuf方法 - 辉煌至芯 - 辉煌至芒

图2 分配缓冲后的环形缓冲

如果某次分配过程中，pWrite到缓冲区结束的位置pEnd长度不够最小分配长度L1，为了提高接收效率，直接废弃最后一段内存，标记pLastWrite为pWrite。然后从pRingBuf开始分配内存，如图 3。

TCP粘包处理-RingBuf方法 - 辉煌至芯 - 辉煌至芒

图 3 使用到结尾的环形缓冲

特殊情况下，如果处理包速度太慢，或者接收太快，可能导致未处理包占用大部分缓冲区，没有足够的缓冲区分配给新的接收操作，如图4。这时候直接报告错误即可。

TCP粘包处理-RingBuf方法 - 辉煌至芯 - 辉煌至芒

图 4没有足够接收缓冲的环形缓冲

当收到一个长度为L数据包时，需要修改缓冲区的指针。这时候已经写入数据的位置变为（pWrite+L），如图 5。

TCP粘包处理-RingBuf方法 - 辉煌至芯 - 辉煌至芒

图 5收到长度为L的数据的环形缓冲

分析上述环形缓冲的使用过程，收到数据后的情况可以简单归纳为两种：pWrite>pRead，接收但未处理的数据位于pRead到pWrite之间的缓冲区；pWrite<pRead，这时候，数据位于pRead到pLastWrite和pRingbuf到pWrite之间。这两种情况分别对应图6、图 7。

首先分析图6。此时，pRead是一个包的起始位置，如果L1足够一个包头长度，就获取该包的长度信息，记为L。假如L1>L，就说明一个数据包接收完成，根据包类型处理包，然后修改pRead指针，指向下一个包的起始位置（pRead+L）。这时候仍然类似于之前的状态，于是解包继续，直到L1不足一个包的长度，或者不足包头长度。这时退出解包过程，等待后续的数据到来。

TCP粘包处理-RingBuf方法 - 辉煌至芯 - 辉煌至芒

图 6有未处理数据的环形缓冲（1）

TCP粘包处理-RingBuf方法 - 辉煌至芯 - 辉煌至芒

图 7有未处理数据的环形缓冲（2）

图 8稍微复杂。首先按照上述过程处理L1部分。存在一种情况，经过若干个包处理之后，L1不足一个包，或者不足一个包头。如果这时（L1+L2）足够一个包的长度，就需要继续处理。另外申请一个最大包长度的内存区pTemp，把L1部分和L2的一部分复制到pTemp，然后执行解包过程。

经过上述解包之后，pRead就转向pRingBuf到pWrite之间的某个位置，从而回归情况图 6，继续按照图 6部分执行解包。

感谢 http://hi.baidu.com/guangbinw/blog/item/c42ccdf4baf1d7e27609d79c.html



（十一）深入浅出TCPIP之TCP粘包问题
网易搬砖头
11-05 737
目录 粘包和拆包问题 保护消息边界和流 粘包、拆包场景 为什么会发生TCP粘包、拆包呢？ 如何处理粘包、拆包问题？ 怎样封包和拆包？ 其他问题 TCP为什么引入接受缓存这个数据结构？ 专栏其他文章： 理论篇： （一）深入浅出TCPIP之理解TCP报文格式和交互流程 (二）深入浅出TCPIP之再识TCP，理解TCP三次握手（上） (三）深入浅出TCPIP之再识TCP，理解TCP四次挥手（上） (四）深入浅出TCPIP之TCP三次握手和四次挥手（下）的抓包分析 ...
TCP粘包问题分析和解决（全）
彼岸花
12-16 2万+
TCP通信粘包问题分析和解决（全） 在socket网络程序中，TCP和UDP分别是面向连接和非面向连接的。因此TCP的socket编程，收发两端（客户端和服务器端）都要有成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小、数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包
环形缓冲区自实现及TCP通信展示该类的用法
05-31
自己实现了一个环形缓冲区的简单类，并且做了一个TCP 服务端对这个类进行了用法演示
TCP粘包处理-RingBuf方法
czydxj的专栏
11-17 1344
TCP粘包处理-RingBuf方法 TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。粘包可能由发送方造成，也可能由接收方造成。TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据，造成多个数据包的粘连。如果接收进程不及时接收数据，已收到的数据就放在系统接收缓冲区，用户进程读取数据时就可能同时读到多个数据包。因为系统传
Linux UART 驱动开发全解析：从原理到实战
最新发布
Interview_TC的博客
04-02 1136
UART 是一种异步串行通信协议，通过 TX（发送）和 RX（接收）两根数据线进行数据传输。波特率（Baud Rate）：如 9600、115200 等，代表每秒传输的符号数；数据位（Data Bits）：常为 8 位；校验位（Parity Bit）：可选，支持奇偶校验；停止位（Stop Bit）：通常为 1 位或 2 位。| 起始位（Start Bit） | 数据位（8位） | 校验位 | 停止位 |UART 通信无需时钟同步，适用于点对点、低速通信，具有电路简单、开销低的特点。
tcp服务器信息记录,ringbuffer(tcp流编程,用于记录服务器日志).docx
weixin_39613839的博客
08-10 544
ringbuffer(tcp流编程,用于记录服务器日志)/******************************************************************************* ** * ** ...
【网络-编程】使用 Ring Buffer 缓存通信数据
三人行，必有我师，其余为同学。老师好，同学好。
11-05 846
简单介绍 Ring Buffer（环形缓冲区）的概念，并提供一份参考实现代码，以及 Linux 系统中服务端和客户端 TCP 通信测试代码。
socket通信的环形缓冲-TCPQQ
htjx99的专栏
10-15 3347
孙靖      2009.5.5 Email：jing_sun999@126.com QQ：272964426 前段时间实现了一个小型的C/S架构的多人在线即时通信工具，JIGQQ。其中对使用TCP通信有点心得。 记得在我大学时代，就用VB做过TCP的通信。当然那时候是很初级的，发送的数据量也很小的应用。当时就觉得，有时候发送的数据接收端不能接收到，有时候呢觉得一次性没有接受完毕。 前段时间
golang tcp粘包处理
jank1369的博客
10-23 2359
go
智能公交调度系统中-粘包-问题解决方案
11-14
3. 接收方的缓冲区管理：接收方应该有高效的缓冲区管理策略，比如使用环形缓冲区，合理地从缓冲区读取数据，尽量避免长时间停留在缓冲区导致的数据包合并问题。 4. 使用应用层协议：在应用层设计上，可以设计一套...
C#环形缓冲区（队列）完全实现
09-01
在C#中，环形缓冲区的实现可以方便地用于数据的存储和读取，尤其是在处理大数据流时，例如串口通信和TCP通信中的封包、拆包、粘包和校验等问题。 在上述C#的环形缓冲区实现中，`RingBufferManager`类是核心，它提供...
环形缓冲区实现类(RingBuffer)
09-01
环形缓冲区实现类(RingBuffer)
TCP发送接收缓冲区详细讲解
08-15
很经典很详细的pdf资料整理，让你快速明白tcp内核缓冲机制，不用再为send、recv而担忧
拆包粘包解决之道
07-18
拆包粘包解决之道
TcpIp数据分包传输
03-24
Tcp数据分包传输（socket数据分包传输），将加载到内存的大文件进行分包传输，解决socket在传输较大数据时候缓冲区空间小于数据流大小时候导致接收时候无法接收全部数据而引起数据流丢失。 传输方式是将内存中的大数据流进行分包传输，不是文件传输 代码采用vs2010 c#编写
网络中出现TCP、UDP粘包、分包的两点解决办法
热门推荐
cherish_2012的专栏
12-02 3万+
粘包产生原因： 先说TCP：由于TCP协议本身的机制（面向连接的可靠地协议-三次握手机制）客户端与服务器会维持一个连接（Channel），数据在连接不断开的情况下，可以持续不断地将多个数据包发往服务器，但是如果发送的网络数据包太小，那么他本身会启用Nagle算法（可配置是否启用）对较小的数据包进行合并（基于此，TCP的网络延迟要UDP的高些）然后再发送（超时或者包大小足够）。那么这样的话，服
服务器正文16：缓冲区设计（ringbuffer、用libevent配合ringbuffer做无锁队列）
谢白羽
06-06 960
文章目录一、为什么用户层需要设计网络缓冲区二、寿司ringbuffer以及多线程换将下数据安全思考三、libevent中event buffer的设计 一、为什么用户层需要设计网络缓冲区 二、寿司ringbuffer以及多线程换将下数据安全思考 三、libevent中event buffer的设计 https://www.bilibili.com/video/BV1ZL411M7Qz?spm_id_from=333.337.search-card.all.click ...............
聊聊TCP协议的粘包、拆包以及http是如何解决的？
cj_eryue的博客
06-05 1万+
TCP协议的粘包、拆包以及http是如何解决的
ctcp 拆包组包粘包
03-22
<think>好的，用户想了解CTCP协议中如何处理拆包、组包和粘包的问题。首先，我需要确认CTCP协议的具体定义，但根据提供的引用，可能是指TCP协议中的相关问题，或者是某种定制化的TCP实现。由于引用中提到了Cisco Packet Tracer和TCP协议的分析，这里假设CTCP可能是指TCP，或者是用户笔误。 接下来，拆包、组包和粘包是TCP通信中常见的问题。拆包（Packet Splitting）指的是应用层的数据包被TCP分成多个报文传输；组包（Packet Combining）是接收方将多个TCP报文重组为完整的数据包；粘包（Sticky Packet）则是指接收方收到的数据包粘连在一起，无法区分边界。 根据引用中的内容，引用[3]提到了应用层包Packet的设计，可能需要继承Packet类并处理消息体的编码。这里可能涉及自定义包头来标记数据长度，以解决粘包问题。例如，固定长度的消息头（HEADER_LENGTH = 4）可能用于存储消息体的长度，接收方根据该长度进行拆包和组包。 另外，引用[2]提到通过配置和分析TCP连接来理解其过程，包括连接建立、数据传输等。TCP本身是面向流的协议，不保留消息边界，因此应用层需要自己处理消息的分界。常见的方法包括使用固定长度、分隔符或长度字段。 解决方案方面，需要结合应用层协议设计，比如在包头添加长度信息，或者使用特定的分隔符。例如，在引用[3]的示例中，消息头长度是4字节，可能用来存储消息体的长度，这样接收方可以先读取头部的4字节，解析出长度后再读取对应长度的消息体，避免粘包问题。 此外，用户可能需要具体的实现步骤或代码示例。根据引用中的代码结构，可以展示如何定义包含长度头的Packet类，并实现拆包和组包的逻辑。同时，需要注意缓冲区管理和数据读取的完整性，防止数据不完整或多余的数据影响后续处理。 最后，生成相关问题时要围绕TCP协议处理、应用层设计、具体实现技术等方面，帮助用户深入理解解决方案。</think>关于CTCP协议中拆包、组包及粘包问题的解决方法，结合网络协议栈实现原理和应用层设计，具体解决方案如下： ### 一、粘包问题的本质 TCP作为面向字节流的传输层协议，不保留应用层报文边界[^2]。当应用层连续发送$N$字节和$M$字节数据时，接收端可能收到$N+M$字节的粘连数据，这种现象称为粘包。需要应用层协议自行定义报文边界。 ### 二、CTCP协议的解决方案 #### 1. 固定长度包头法（推荐方案） ```java // 引用[3]中Packet设计的改进实现 public class CTCPPacket extends Packet { // 固定4字节报文头存储body长度 public static final int HEADER_LENGTH = 4; private byte[] body; // 组包时先写入body长度 public byte[] toBytes() { ByteBuffer buffer = ByteBuffer.allocate(HEADER_LENGTH + body.length); buffer.putInt(body.length); buffer.put(body); return buffer.array(); } } ``` 此方法通过$$L_{header} = \lceil \log_{256}(MaxBodySize) \rceil$$计算头部长度，保证能表示最大报文长度[^3] #### 2. 特殊分隔符法 在报文尾部添加特定分隔符如`\r\n`，但需确保分隔符不出现在数据内容中： $$Packet = Body_{data} + Delimiter_{symbol}$$ #### 3. 动态缓冲区管理 接收端维护环形缓冲区实现拆包： ```python class BufferManager: def __init__(self): self.buffer = bytearray() def append(self, data): self.buffer.extend(data) def extract_packet(self): if len(self.buffer) >= 4: length = int.from_bytes(self.buffer[:4], 'big') if len(self.buffer) >= 4 + length: packet = self.buffer[4:4+length] self.buffer = self.buffer[4+length:] return packet return None ``` ### 三、性能优化要点 1. **滑动窗口机制**：通过TCP窗口大小动态调整传输速率，避免发送过快导致缓冲区溢出 2. **Nagle算法控制**：在实时性要求高的场景禁用该算法（设置`TCP_NODELAY`选项） 3. **MTU适配**：确保单个报文不超过网络最大传输单元，典型值为： $$MTU_{以太网} = 1500\ bytes$$ ### 四、异常处理机制 1. 超时重传：设置RTO(Retransmission Timeout)应对丢包 2. 校验和验证：通过CRC32或MD5校验报文完整性 3. 序号确认：采用SEQ/ACK序列号保证有序性
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值