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

最新推荐文章于 2025-07-18 22:57:54 发布
转载 最新推荐文章于 2025-07-18 22:57:54 发布 · 2.8k 阅读 · 4
文章标签：

#环形缓冲 #TCP粘包 #RingBuf

本文介绍了一种针对TCP粘包现象的处理方案，利用环形缓冲区存储接收数据，并通过预处理分离粘连的数据包。文章详细解释了环形缓冲区的工作原理及其在不同接收场景下的应用。

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



【网络-编程】使用 Ring Buffer 缓存通信数据
三人行，必有我师，其余为同学。老师好，同学好。
11-05 974
简单介绍 Ring Buffer（环形缓冲区）的概念，并提供一份参考实现代码，以及 Linux 系统中服务端和客户端 TCP 通信测试代码。
环形缓冲区实现类(RingBuffer)
09-01
环形缓冲区实现类(RingBuffer)
环形缓冲区自实现及TCP通信展示该类的用法
05-31
自己实现了一个环形缓冲区的简单类，并且做了一个TCP 服务端对这个类进行了用法演示
TCP粘包处理-RingBuf方法
czydxj的专栏
11-17 1366
TCP粘包处理-RingBuf方法 TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。粘包可能由发送方造成，也可能由接收方造成。TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据，造成多个数据包的粘连。如果接收进程不及时接收数据，已收到的数据就放在系统接收缓冲区，用户进程读取数据时就可能同时读到多个数据包。因为系统传
Linux驱动学习day24(UART子系统)
最新发布
weixin_71568456的博客
07-18 1047
摘要：本文系统介绍了UART串口通信原理及Linux系统中的TTY框架。首先阐述了UART的硬件特性，包括波特率计算、数据传输流程和电平转换；其次分析了Linux TTY子系统架构，解释终端设备节点差异；然后详细讲解了串口应用编程方法，包括行规程设置和GPS数据解析实例；最后深入剖析了UART驱动框架，包括注册过程、数据收发流程及调试方法。全文通过理论分析与代码实例相结合的方式，全面呈现了Linux环境下串口通信的完整技术体系。
tcp服务器信息记录,ringbuffer(tcp流编程,用于记录服务器日志).docx
weixin_39613839的博客
08-10 570
ringbuffer(tcp流编程,用于记录服务器日志)/******************************************************************************* ** * ** ...
socket通信的环形缓冲-TCPQQ
htjx99的专栏
10-15 3372
孙靖      2009.5.5 Email：jing_sun999@126.com QQ：272964426 前段时间实现了一个小型的C/S架构的多人在线即时通信工具，JIGQQ。其中对使用TCP通信有点心得。 记得在我大学时代，就用VB做过TCP的通信。当然那时候是很初级的，发送的数据量也很小的应用。当时就觉得，有时候发送的数据接收端不能接收到，有时候呢觉得一次性没有接受完毕。 前段时间
网络中出现TCP、UDP粘包、分包的两点解决办法
cherish_2012的专栏
12-02 3万+
粘包产生原因： 先说TCP：由于TCP协议本身的机制（面向连接的可靠地协议-三次握手机制）客户端与服务器会维持一个连接（Channel），数据在连接不断开的情况下，可以持续不断地将多个数据包发往服务器，但是如果发送的网络数据包太小，那么他本身会启用Nagle算法（可配置是否启用）对较小的数据包进行合并（基于此，TCP的网络延迟要UDP的高些）然后再发送（超时或者包大小足够）。那么这样的话，服
TCP Socket 分包办法
此去经年
06-04 4961
TCP Socket 分包办法         最近需要APP从服务端（C++）获取数据，协议规定使用TCP，且数据量较大。一半路由器的MTU为1500或者1492，所以必然存在分片，客户端收到的数据也存在粘包现象，这是就需要对数据包进行分包处理。这里采用缓冲数组来解决分，直接上代码，由于电脑不能复制，只能上图片了，有空再敲吧。     这里我用到的是安卓的HandlerThread，来处理数
TCP发送接收缓冲区详细讲解
08-15
很经典很详细的pdf资料整理，让你快速明白tcp内核缓冲机制，不用再为send、recv而担忧
TcpIp数据分包传输
03-24
Tcp数据分包传输（socket数据分包传输），将加载到内存的大文件进行分包传输，解决socket在传输较大数据时候缓冲区空间小于数据流大小时候导致接收时候无法接收全部数据而引起数据流丢失。 传输方式是将内存中的大数据流进行分包传输，不是文件传输 代码采用vs2010 c#编写
服务器正文16：缓冲区设计（ringbuffer、用libevent配合ringbuffer做无锁队列）
谢白羽
06-06 1024
文章目录一、为什么用户层需要设计网络缓冲区二、寿司ringbuffer以及多线程换将下数据安全思考三、libevent中event buffer的设计 一、为什么用户层需要设计网络缓冲区 二、寿司ringbuffer以及多线程换将下数据安全思考 三、libevent中event buffer的设计 https://www.bilibili.com/video/BV1ZL411M7Qz?spm_id_from=333.337.search-card.all.click ...............
分包和粘包
weifc-wei 的博客
02-25 431
文章目录分包和粘包TCP分包TCP 粘包分包和粘包解决方案： 点击我, 到底部 分包和粘包 TCP分包 场景：发送方发送字符串”helloworld”，接收方却分别接收到了两个数据包：字符串”hello”和”world” (举个栗子, 实际并不是这么短的字节长度) 发送端发送了数量较多的数据，接收端读取数据时候数据分批到达，造成一次发送多次读取； 造成分包的原因： TCP是以段（Segment）为单位发送数据的,建立TCP链接后,有一个最大消息长度（MSS）.如果应用层数据包超过MSS,就会把应用层数据
Ringbuffer 范例
yazhouren的专栏
07-09 2239
origin: http://blog.codingnow.com/2012/04/mread.html 前段时间谈到了 ringbuffer 在网络通讯中的应用 。有不少朋友写 email 和我探讨其实现细节。 清明节放假，在家闲着无聊，就实现了一个试试。虽然写起来还是挺繁杂的，好在复杂度还在我的可控范围内，基本上也算是完成了。 设想这样一个需求：程序 bind 并listen
TCP分包和粘包
m0_60529319的博客
04-08 2660
相关的,路由器有一个MTU（ 最大传输单元）一般是1500字节,除去IP头部20字节,留给TCP的就只有MTU-20字节。TCP是以段（Segment）为单位发送数据的,建立TCP链接后,有一个最大消息长度（MSS）.如果应用层数据包超过MSS,就会把应用层数据包拆分,分成两个段来发送.b）服务端：先解析本次数据包，获取数据大小N，再读取N个字节，这N个字节就是一个完整的数据内容。当应用层数据超过1460字节时,TCP会分多个数据包来发送。a）客户端：先发送包表示和长度，再发送数据内容。
一个简单的串行协议的封装
含光左卫的工作笔记集
08-11 1880
所有的软件开发人员都会在他的职业历程中设计一个串行口收发单元。这里展示了一个 基于串行口的协议封装实现。大家可以对比一下自己的实现看看。首先需要对整个软件的结构进行拆分。理论上它应当至少分割为三个大的部分： 1.通讯层。处理bit流的传递。 2.数据帧层。处理frame的析取和打包。 3.应用层。处理各个独立的数据帧。并提供更上层的信息通道。通讯层最先构建，并可进行独立测试。它又按照内部的逻
MCU-串口发送实现
tang0_0
08-02 649
MCU-串口发送实现 例程仓库：https://gitee.com/ll0_0ll/MCU-UART 1.串口发送寄存器为空中断+RingBuff 初始化一段内存空间作循环队列 发送数据时，先将数据放到循环队列中，然后开启发送寄存器为空中断（USART_IT_TXE） 在中断中，判断队列中是否有数据，有数据就发送，没有数据就关闭中断 void uart1_send_bytes(unsigned char *data, unsigned int len) { ringbuf_write(&a
网卡的ring buffer调整
热门推荐
badman250的专栏
12-10 4万+
【互联网后台技术】网卡的ring buffer调整  (2011-10-13 13:57:43) 转载▼ 标签：  网卡   ringbuffer   it 分类： 互联网运维技术 服务器的NIC(eth0)上的RX dropped数量一直在增多时可以考虑试着调整ring busffer看看效果
armLinux解决tcp粘包和拆包
04-12
<think>好的，我现在需要解决用户在ArmLinux环境下遇到的TCP粘包和拆包问题。首先，我得回顾一下TCP的基本特性。TCP是面向流的协议，没有消息边界，所以发送端多次发送的数据可能会被接收端一次性接收，这就是粘包；或者一个大的数据包被拆分成多个小包接收，这就是拆包。这个问题在所有TCP通信中都会存在，ArmLinux环境也不例外。 接下来，我需要整理常见的解决方法。根据引用[1]提到的，定长包和变长包的处理方式。定长包比较简单，每次读取固定大小的数据即可。而变长包通常需要在包头添加长度字段，或者使用分隔符。用户可能是在ArmLinux下进行嵌入式开发，比如使用C或Python进行网络编程，所以需要考虑这些方法在该环境下的具体实现。 然后，结合ArmLinux的特点，可能需要考虑系统调用、缓冲区设置等问题。例如，在C语言中使用read或recv函数时，如何确保读取到完整的数据包。另外，是否涉及到多线程或异步IO处理，这些都可能影响粘包的处理方式。 还要考虑用户的实际应用场景。比如，如果是在高实时性要求的嵌入式系统中，可能需要更高效的解决方案，比如使用固定长度的协议，或者结合硬件特性优化处理流程。此外，是否已经有现有的库或框架可以使用，比如Boost.Asio或者自定义的协议解析库。 然后需要验证这些方法在ArmLinux下的可行性。例如，使用定长包时，如何确保数据对齐；使用包头长度字段时，如何处理字节序的问题（大端小端），这在不同的Arm架构中可能有不同的表现。另外，分隔符的选择也需要考虑数据内容中是否可能包含分隔符，需要进行转义处理。 可能还需要考虑内核参数调整，比如TCP_NODELAY选项，或者调整接收缓冲区的大小，但这通常对粘包问题影响不大，主要还是应用层的处理。 最后，结合引用[3]提到的ArmLinux嵌入式开发经验，可能需要强调在资源受限的环境下如何高效实现这些方法，比如内存管理、避免频繁的内存分配等优化措施。 总结起来，解决步骤应该是：1. 确定数据包的格式（定长或变长）；2. 根据格式设计解析逻辑；3. 在代码中实现相应的读取和解析机制；4. 测试验证在不同网络条件下的可靠性。同时，需要给出代码示例，比如在C语言中使用长度字段的方法，或者在Python中使用分隔符的方式。</think>在ArmLinux环境下解决TCP粘包和拆包问题，需结合协议设计与系统编程技巧。以下是具体方法与实现步骤： --- ### 一、问题根源分析 TCP是面向字节流的协议，数据在传输层会被分片重组，导致： 1. **粘包**：接收方一次读取多个发送包 2. **拆包**：单个发送包被拆分成多次接收 在嵌入式系统中尤为关键，因资源受限需高效处理[^1] --- ### 二、核心解决方案 #### 1. **定长包协议** ```c // C语言示例：读取固定1024字节 #define FIXED_LEN 1024 char buffer[FIXED_LEN]; int read_bytes = 0; while(read_bytes < FIXED_LEN) { int ret = read(sockfd, buffer + read_bytes, FIXED_LEN - read_bytes); if(ret <= 0) break; read_bytes += ret; } ``` *适用场景*：传输固定大小数据块（如传感器采样数据） #### 2. **变长包协议（包头含长度字段）** ```python # Python示例：使用struct处理二进制头 import struct header = sock.recv(4) # 假设前4字节为长度 if len(header) == 4: body_len = struct.unpack('!I', header)[0] body = sock.recv(body_len) ``` **关键点**： - 字节序处理（ARM默认小端序，建议网络传输使用大端序`!I`） - 多次recv补全机制 #### 3. **分隔符法** ```c // C语言示例：使用'\r\n\r\n'作为结束符 char* find_pattern(char* buf, int len) { char* end = buf + len - 3; for(char* p = buf; p <= end; p++) { if(memcmp(p, "\r\n\r\n", 4) == 0) return p; } return NULL; } ``` *注意事项*：需对数据内容中的分隔符进行转义处理 --- ### 三、ArmLinux特有优化 1. **内核参数调整**： ```bash # 修改socket缓冲区大小 sysctl -w net.core.rmem_default=262144 sysctl -w net.core.wmem_default=262144 ``` 2. **非阻塞IO结合状态机**：使用epoll实现高效事件驱动 3. **内存对齐优化**：ARM架构对非对齐访问敏感，建议包头长度字段使用32位对齐 --- ### 四、典型错误场景处理 | 场景 | 解决方法 | |------|----------| | 接收缓冲区半包 | 使用环形缓冲区暂存未处理数据 | | 大端小端转换 | 强制使用网络字节序（`htonl/ntohl`） | | 恶意超长包 | 设置最大包长度阈值 | ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值