消息粘包 和 消息不完整 问题-元一软件
消息粘包 和 消息不完整 问题消息粘包 和 消息不完整问题 其实都是应用层会带来的问题和TCP 没关系TCP 是能够保证消息的顺序 和 完整性的本篇只是简单说明一下 什么是 消息粘包 和 消息不完整问题1.复现消息粘包 和 消息不完成 问题先来看看 出现了什么问题导致 需要去处理 消息粘包 和 消息完整 问题 前面通过NIO改造了聊天室的案例中我们开复现一下 消息粘包 和 消息不完整1.1 复现 消息粘包问题Client端发送多条数据代码还是原来的Client端代码 只是在发送数据的时候 一次性发了100条public static void connectServer(ServerInfo serverInfo){try{// 开启 tcp 连接 socketnew Socket(Inet4Address.getByName(serverInfo.getIp()), serverInfo.getPort());// 开启 线程 异步 读取 server message clientReadHandlernew ClientReadHandler(socket.getInputStream(), ClientConnectTcp::close);clientReadHandler.start();// 监听 键盘写入 system.in systemInReadernew BufferedReader(new InputStreamReader(System.in));clientWriteHandlernew ClientWriteHandler(socket.getOutputStream());do{String messagesystemInReader.readLine();// 异步发送 到 serverif(message!null){//把读取到的message 发送100次 并且后面添加上i标识for(int i0;i100;i){clientWriteHandler.sendMsg(message : i);}}if(CommonConstants.BYE_FLAG.equals(message)){close();}}while(!doReadFlag);}catch(IOException e){log.error(【建立tcp 连接异常{}】, e.getMessage());}finally{close();}}Server端 接受到的消息可以看到 出现了严重的粘包问题原本我们希望 消息是一条一条处理如下receiveAsync message:abcdefg:0receiveAsync message:abcdefg:1receiveAsync message:abcdefg:210:12:21.721[read-io-executors1]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:abcdefg:0 abcdefg:1 abcdefg:2 abcdefg:3 abcdefg:4 abcdefg:5 abcdefg:6 abcdefg:7 abcdefg:8 abcdefg:9 abcdefg:10 abcdefg:11 abcdefg:12 abcdefg:13 abcdefg:14 abcdefg:15 abcdefg:16 abcdefg:17 abcdefg:18 abcdefg:19 abcdefg:20 abcdefg:21 abcdefg:22 abcdefg:23 a10:12:21.722[read-io-executors2]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:cdefg:24 abcdefg:25 abcdefg:261.2 复现 消息不完整问题修改Server 服务器端的 IoArgs 的 ByteBuffer的 缓冲区大小Slf4j Data public class IoArgs{//缓冲区大小 从256个字节 改成4个字节 private ByteBuffer byteBufferByteBuffer.allocate(4);其他代码省略...}Client客户端还是如下 发送100条数据do{String messagesystemInReader.readLine();// 异步发送 到 serverif(message!null){for(int i0;i100;i){clientWriteHandler.sendMsg(message : i);}}if(CommonConstants.BYE_FLAG.equals(message)){close();}}while(!doReadFlag);Server端 接受到的消息可以看到 原本一条消息 abcdefg 被拆开成了 很多子消息了。。出现了 严重的 消息不完整问题10:19:38.754[read-io-executors1]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:abc10:19:38.754[read-io-executors2]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:efg10:19:38.755[read-io-executors3]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:0 a10:19:38.755[read-io-executors4]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:cde10:19:38.756[read-io-executors1]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:g:110:19:38.756[read-io-executors2]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:abc10:19:38.756[read-io-executors3]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:efg10:19:38.756[read-io-executors4]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:2 a10:19:38.756[read-io-executors1]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:cde10:19:38.757[read-io-executors2]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:g:310:19:38.757[read-io-executors3]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:abc10:19:38.757[read-io-executors4]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:efg10:19:38.757[read-io-executors1]INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:42. 消息粘包 和 消息不完成 问题概述在socket网络编程中都是端到端通信由客户端端口服务端端口客户端IP服务端IP传输协议组成的五元组可以明确的标识一条连接。在TCP的socket编程中发送端和接收端都有成对的socket。发送端为了将多个发往接收端的包更加高效的的发给接收端于是采用了优化算法Nagle算法将多次间隔较小、数据量较小的数据合并成一个数据量大的数据块然后进行封包。那么这样一来接收端就必须使用高效科学的拆包机制来分辨这些数据。2.1 什么是TCP粘包问题TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包从接收缓冲区来看后一包数据的头紧接着前一包数据的尾出现粘包的原因是多方面的可能是来自发送方也可能是来自接收方。2.2 造成TCP粘包的原因发送方原因TCP默认使用Nagle算法主要作用减少网络中报文段的数量而Nagle算法主要做两件事只有上一个分组得到确认才会发送下一个分组收集多个小分组在一个确认到来时一起发送Nagle算法造成了发送方可能会出现粘包问题接收方原因TCP接收到数据包时并不会马上交到应用层进行处理或者说应用层并不会立即处理。实际上TCP将接收到的数据包保存在接收缓存里然后应用程序主动从缓存读取收到的分组。这样一来如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度多个包就会被缓存应用程序就有可能读取到多个首尾相接粘到一起的包。什么时候需要处理粘包现象如果发送方发送的多组数据本来就是同一块数据的不同部分比如说一个文件被分成多个部分发送这时当然不需要处理粘包现象如果多个分组毫不相干甚至是并列关系那么这个时候就一定要处理粘包现象了2.3 如何处理粘包现象发送方对于发送方造成的粘包问题可以通过关闭Nagle算法来解决使用TCP_NODELAY选项来关闭算法接收方接收方没有办法来处理粘包现象只能将问题交给应用层来处理。应用层应用层的解决办法简单可行不仅能解决接收方的粘包问题还可以解决发送方的粘包问题。1.固定包长度的数据包2.以指定字符串为包的结束标志 如换行符 \n3.包头 包体格式 这种格式的包一般分为两部分即包头和包体包头是固定大小的且包头中必须含有一个字段来说明接下来的包体有多大。总结

相关新闻

基于Python与AI的视频处理流水线:从语音识别到智能剪辑

基于Python与AI的视频处理流水线:从语音识别到智能剪辑

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/11/13 9:37:48 阅读更多 →
梦幻西游帮派联赛周五未完成对局处理与反向开无间战术详解

梦幻西游帮派联赛周五未完成对局处理与反向开无间战术详解

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/11/13 9:37:48 阅读更多 →
全栈开源外卖系统“食刻”部署与核心业务调试实战指南

全栈开源外卖系统“食刻”部署与核心业务调试实战指南

简介:这是一套面向外卖平台创业者、中小型技术团队及全栈开发者的完整开源外卖系统解决方案,覆盖用户下单、商户管理、骑手配送、多端协同等核心业务闭环,助力快速搭建可商用的本地化外卖服务平台。资源包共2000个文件,含1266个PH…

2026/11/6 5:34:49 阅读更多 →

最新新闻

Electron桌面应用开发实战:从环境搭建到打包发布全流程

Electron桌面应用开发实战:从环境搭建到打包发布全流程

做前端这些年,我大部分时间都在跟浏览器标签页打交道,直到第一次把桌面应用跑起来,才发现原来自己一直被限制在地址栏和刷新按钮围起来的框框里。Electron这个词,最开始是在某段时间频繁出现在同事的讨论里,一个用HTML…

2026/11/13 5:13:25 阅读更多 →
滑盖智能锁T109深度解析:结构原理、安装调试与故障排查

滑盖智能锁T109深度解析:结构原理、安装调试与故障排查

简介:亚太天能T109滑盖智能锁产品说明书是一份PDF格式的官方技术文档,主要面向智能锁安装人员、终端用户及售后维护者,帮助快速掌握产品安装、配置与常见故障处理。全包仅1个PDF文件,大小4.37MB,内容结构清晰&#xff…

2026/11/13 5:13:25 阅读更多 →
PMSM弱磁控制原理与Simulink建模:高速AGV驱动系统设计指南

PMSM弱磁控制原理与Simulink建模:高速AGV驱动系统设计指南

上个月我在调试一台高速AGV的驱动系统,整车要求空载跑到8m/s,电机转速已经拉到额定点,驱动器的输出电压也顶到了母线电压极限附近。再往上踩速度指令,转速纹丝不动,三相电流反而开始震荡。那会儿我的第一反应就是&…

2026/11/13 5:13:25 阅读更多 →
C++核心知识点:从内存管理到STL的实战指南

C++核心知识点:从内存管理到STL的实战指南

C 这门语言我前前后后折腾了十几年,用它写过嵌入式驱动、做过游戏服务端,也搭过基础组件库。每次看到新人一头扎进"C 核心知识点"这个搜索词,我其实挺感慨的——这门语言的难点从来不是语法多,而是知识点之间的耦合太深…

2026/11/12 18:22:26 阅读更多 →
T109滑盖智能锁怎么装?安装调试与故障排查全攻略

T109滑盖智能锁怎么装?安装调试与故障排查全攻略

简介:亚太天能T109滑盖智能锁产品说明书以PDF格式发布,适合智能锁用户、安装人员与售后维修人员阅读。内容围绕T109系列指纹密码刷卡锁展开,先介绍前面板、后面板、锁体、机械钥匙、电池盒盖等部件名称与功能,再给出完整安装步骤&…

2026/11/12 18:22:25 阅读更多 →
LLM知识降熵:从信息垄断到理解权下放

LLM知识降熵:从信息垄断到理解权下放

你有没有过这种经历:翻开源码注释、论文摘要或者一份专业报告,每个字都认识,连在一起却像天书。想找人聊聊,身边要么没人懂,要么懂的懒得跟你解释。后来我试着把同一段内容丢给一个大语言模型,几秒钟之后&a…

2026/11/13 5:13:25 阅读更多 →

日新闻

周新闻

月新闻