首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏后端码事

    TCP 粘

    一、什么是粘? 粘是TCP协议传输中一种现象概念。TCP是传输层协议,他传输的是“流”式数据,TCP并不知道传输是哪种业务数据,或者说,并不关心。 在这个前提下,就有可能发生发生同一个业务数据被分割程多个数据,或者多个业务数据被打包到同一个数据进行发送。但是对于业务数据接收方,则必须拥有能够重新拆解或者组装完整业务数据的能力。 这个现象,我们称之为TCP粘。 ? 如上图,三个业务数据A、B、C被打包成一个数据进行传输;D被分割为连个数据进行传输。 所以综上,影响粘发生的原因: ? 关于MTU MSS相关知识可以参照:MTU(Maximum transmission unit) 最大传输单元 二、怎么处理粘? 传输层是业务无感知的,因此粘只能由业务层处理。

    1.9K20发布于 2020-09-11
  • 来自专栏面向offer编程

    TCP 粘

    问题 在 TCP 这种字节流协议上做应用层分包是网络编程的基本需求。 因此,“粘问题”是个伪命题 短连接分包 对于短连接的 TCP 服务,分包不是一个问题,只要发送方主动关闭连接,就表示一个消息发送完毕,接收方 read() 返回0,从而知道消息的结尾 TCP 发送机制

    1.9K00发布于 2019-05-01
  • 来自专栏全栈程序员必看

    netty_http粘

    的原理 基本原理,简单来说: 接收端应用层不断从底层的TCP 缓冲区中读取数据。 每次读取完,判断一下是否为一个完整的应用层数据。如果是,上层应用层数据读取完成。 Netty 中的这个工作,Netty 已经为大家备好了很多不同的器。本着不重复发明轮子的原则,我们直接使用Netty现成的器。 Netty 中的器大致如下: 固定长度的器 FixedLengthFrameDecoder 每个应用层数据的都拆分成都是固定长度的大小,比如 1024字节。 基于数据长度的器 LengthFieldBasedFrameDecoder 将应用层数据的长度,作为接收端应用层数据的拆分依据。按照应用层数据的大小,之前的消息包装 在使用LengthFieldBasedFrameDecoder 器之前 ,在发送端需要对protobuf 的消息进行一轮包装。

    1.3K10编辑于 2022-09-22
  • 来自专栏JavaEE

    TCP粘

    举个例子:客户端要发送原信息是A和B两个数据,服务端接收到之后,可能出现如下情况: 正常情况:读取到了A和B两个数据; 粘:A和B两个数据一起读取了; :读取了A数据的一部分,A的另一部分和 B数据一起读取了; 由于TCP是没有消息保护边界的,也就是上面的消息,没有边界,服务端并不知道hello的o是一个边界,hello是一个单词,所以我们就得中服务端处理边界问题。 这也就是粘问题。 二、Netty中的粘如何解决 使用自定义协议 + 编解码器来解决。说人话就是:服务端你不是不知道消息的长度吗? bys = msg.getBytes("utf-8"); int len = msg.getBytes("utf-8").length; // 创建协议

    1.6K30发布于 2020-08-17
  • 来自专栏正则

    React Native

    找到了react-native启动bundle server的入口,即runServer函数,它的定义为:

    1.3K20编辑于 2022-01-13
  • 来自专栏落叶飞翔的蜗牛

    Netty与TCP粘

    Netty如何解决TCP粘的问题? TCP粘/ TCP协议是个流协议,所谓流,就是指没有界限的一串数据。河里的流水,是连成一片的,没有分界线。 TCP粘问题。 粘说明 现在假设客户端向服务端连续发送了两个数据,用packet1和packet2来表示,那么服务端收到的数据可以分为三种,现列举如下: 第一种情况,接收端正常收到两个数据,即没有发生和粘的现象 粘发生原因 1.要发送的数据大于TCP发送缓冲区剩余空间大小,将会发生即应用程序写入数据的字节大小大于套接字发送缓冲区的大小。 2.进行MSS大小的TCP分段。 TCP粘的解决策略 由于底层的TCP无法理解上层的业务数据,所以在底层是无法保证数据不被和重组的,这样问题需要通过上层的应用协议栈设计来解决。 1. 消息定长。例如100字节。

    1.2K40发布于 2021-01-14
  • 来自专栏Liusy01

    Netty之TCP粘

    一、何为TCP粘/? TCP会根据缓冲区的实际大小情况进行包的拆分和合并,所谓粘,就是将多个小的封装成一个大的进行发送。,即是将一个超过缓冲区可用大小的拆分成多个进行发送。 二、粘/包产生的原因 1、写入的字节大小大于套接字的发送缓存区大小。 、将消息分成消息头和消息体两部分,消息头记录的消息的总长度 四、未考虑TCP粘/的案例 服务端: public class Server {     private int port; 五、加入Netty的TCP粘/解决方案。 的方案。

    1.6K10发布于 2020-08-31
  • 来自专栏Java项目实战

    什么是TCP粘

    TCP的原因和表现TCP指的是发送方在发送数据时,将一个逻辑上独立的数据拆分成多个小的数据发送,导致接收方在接收时无法正确地组装这些数据。 TCP的原因主要是由于发送方发送数据的速度过快,接收方处理数据的速度没有跟上。TCP的表现形式有两种:一个数据包被拆分成多个小的数据,接收方无法正确地组装这些数据。 一个数据包被拆分成多个小的数据,但是在接收端可以正确地解析出每个数据。TCP粘的解决方式为了解决TCP粘的问题,我们可以采用以下几种方式:1. TCP的原因和表现TCP指的是发送方在发送数据时,将一个逻辑上独立的数据拆分成多个小的数据进行发送,导致接收方在接收时无法正确地组装这些数据。 一个数据包被拆分成多个小的数据进行传输,但是接收方无法正确地组装这些数据。解决TCP粘的方式为了解决TCP粘的问题,我们可以采取以下几种方式:1.

    1.8K10编辑于 2023-07-04
  • 来自专栏ytao

    Netty中粘处理

    这就是 TCP 协议的粘/概念。 II 为粘情况, 123和 abc封装成了一个。 III 为情况,图中的描述是将 123拆分成了 1和 23,并且 1和 abc一起传输。 123和 abc也可能是 abc进行。 Netty 粘/问题 为突出 Netty 的粘/问题,这里通过例子进行重现问题,以下为突出问题的主要代码: 服务端: /** * 服务端网络事件的读写操作类 * * Created by 上图中可以看到 【】中 167的数据被拆分为了两部分(图中画绿线数据),该情况为(粘/示意图中的情况 III)。 Netty 解决粘/问题 LineBasedFrameDecoder 换行符处理 Netty 的强大,方便,简单使用的优势,在粘/问题上也提供了多种编解码解决方案,并且很容易理解和掌握。

    1.3K20发布于 2020-06-04
  • 来自专栏码农沉思录

    Netty中粘处理

    这就是 TCP 协议的粘/概念。 本文基于 Netty5 进行分析 粘/描述 假设当前有 123和 abc两个数据,那么他们传输情况示意图如下: ? Netty 粘/问题 为突出 Netty 的粘/问题,这里通过例子进行重现问题,以下为突出问题的主要代码: 服务端: /** * 服务端网络事件的读写操作类 * * Created by 但是 【】中为 37和 38的出现了粘情况(粘/示意图中的情况 II),两条数据粘合在一起。 ? 上图中可以看到 【】中 167的数据被拆分为了两部分(图中画绿线数据),该情况为(粘/示意图中的情况 III)。 Netty 解决粘/问题 LineBasedFrameDecoder 换行符处理 Netty 的强大,方便,简单使用的优势,在粘/问题上也提供了多种编解码解决方案,并且很容易理解和掌握。

    2.2K20发布于 2019-12-27
  • 来自专栏Web技术布道师

    php - tcp 粘实例

    tcp 长链接模式下,使用固定消息头长度的方式进行消息 ,解决 粘 问题。 组 <? $bar; 粘 // send // 传输 $package 由 $foo $bar 两条消息组成 模拟粘包场景 // receive <? php // 解析第1条消息 取前 2bytes 按 n 解包 $fooLen = unpack("n", substr($package, 0, 2))[1]; // 使用消息体长度定义读取消息体 但如果是 短连接多个消息 或 长链接模式 下,就可能会发生粘,客户端不关闭服务端无法通过 EOL 确定消息读取完毕的问题。这就需要定义协议和

    1.2K31发布于 2019-07-10
  • 来自专栏技术客栈

    Netty TCP解决粘

    然而在接收端,数据可能以不同的方式到达,就比如正常、粘。 2.1、现象描述 假设客户端发送2个连续的数据到服务器,数据用packet1,packet2分别表示,则服务器接收到的数据可以分为3种情况: 情况1: 服务器接收到2个数据,没有,也没有粘问题 在这种情况,接收者并不知道2个原生的界限,因此接收者很难处理; 情况3: 接收者接收到2个冗余或不完整的数据(粘问题同时发生) 接收者接收到2个数据,但这2个数据要么不完整,要么掺杂了其他数据的部分数据 在这种情况下,粘同时发生。 接收缓冲区读取数据,也会发生粘; 2、原因: 发送的数据大小 大于 TCP发送缓冲区,就会发生; 发送的数据大小 大于 报文最大长度,也会; 4、粘解决方法 解决粘的关键在于

    84220编辑于 2023-10-28
  • 来自专栏TPlus

    Netty 私有协议粘实例

    接下来,采用 Java + Netty 模拟该组件的功能,以演示私有协议下 netty 的粘/的实现。 2. 运行结果 下面是代码运行后的截图,可以看出 TCP 报文被 Netty 正确的进行了粘处理。 image.png image.png

    1.2K10编辑于 2022-03-27
  • 来自专栏猿天地

    Netty粘解决方案

    入门篇 高性能NIO框架Netty-对象传输 高性能NIO框架Netty-整合kryo高性能数据传输 高性能NIO框架Netty-整合Protobuf高性能数据传输 Netty4自带编解码器详解 TCP黏 TCP作为传输层协议并不不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行数据的划分,所以在业务上认为是一个完整的,可能会被TCP拆分成多个进行发送,也有可能把多个小的封装成一个大的数据发送 ,这就是所谓的TCP粘问题。 DelimiterBasedFrameDecoder(特殊分隔符分包) FixedLengthFrameDecoder(固定长度报文来分包) LengthFieldBasedFrameDecoder(自定义长度来分包) 制造粘问题 为了验证我们的解码器能够解决这种粘带来的问题,首先我们就制造一个这样的问题,以此用来做对比。

    1.7K70发布于 2018-04-03
  • 来自专栏前端二次元

    体积太大,怎么?--vite

    Vite 默认策略刚刚我们说到了为什么要进行,实际上 Vite 中已经内置了一份的策略,接下来让我们来看看 Vite 默认的模式是怎样的。 Vite 2.9 及以后的版本策略会有所不同,后文会介绍。 的大小已经达到 500 KB 以上,显然是有进一步的优化空间的,这个时候我们就需要用到 Rollup 中的 API ——manualChunks 了。 自定义策略针对更细粒度的,Vite 的底层打包引擎 Rollup 提供了manualChunks,让我们能自定义策略,它属于 Vite 配置的一部分,示例如下:// vite.config.tsexport 终极解决方案尽管上述的解决方案已经能帮我们正常进行产物,但从实现上来看,还是显得略微繁琐,那么有没有开箱即用的方案,能让我们直接用到项目中呢?

    6.1K100编辑于 2023-11-14
  • 来自专栏简栈文化

    TCP粘及解决方法

    问题是处于网络比较底层的问题,在数据链路层、网络层以及传输层都有可能发生。 我们日常的网络应用开发大都在传输层进行,由于UDP有消息保护边界,不会发生粘问题,因此粘问题只发生在TCP协议中。 什么是粘? 接收端收到了两个数据,但是这两个数据要么是不完整的,要么就是多出来一块,这种情况即发生了和粘。这两种情况如果不加特殊处理,对于接收端同样是不好处理的。 img img 为什么会发生TCP粘? 发生TCP粘主要是由于下面一些原因: 应用程序写入的数据大于套接字缓冲区大小,这将会发生。 接收方法不及时读取套接字缓冲区数据,这将发生粘。 粘解决办法 TCP本身是面向流的,作为网络服务器,如何从这源源不断涌来的数据流中拆分出或者合并出有意义的信息呢?

    2.8K10发布于 2021-11-04
  • 来自专栏波波烤鸭

    Netty解决TCP粘的问题

    什么是TCP粘/   首先要明确, 粘问题中的 “”, 是指应用层的数据.在TCP的协议头中, 没有如同UDP一样的 “报文长度” 字段,但是有一个序号字段.    如图所示,假设客户端分别发送两个数据D1和D2给服务器端,由于服务器端一次读取到的字节数是不确定的,所以可能存在以下几种情况: 服务端分两次读取到了两个独立的数据,分别是D1和D2,这种情况没有粘 服务端一次接收到了两个数据,D1和D2粘合在一起,被称为TCP粘 服务端分两次读取到了两个数据,第一次读取到了完整的D2和D1的部分内容,第二次读取到了D1剩余的内容,这被称为TCP 和第3中情况相反,也是 如果服务端的TCP接收滑窗非常小,而数据D1和D2比较大,那么服务器要分多次才能将D1和D2完全接收完,期间发生了多次 未考虑TCP粘案例   上面我们介绍了TCP粘的原因 ,现在我们通过Netty案例来实现下不考虑TCP粘问题而造成的影响。

    1.3K30发布于 2019-04-19
  • 来自专栏CBeann的博客

    Netty(三)之数据之粘

    数据的粘 在上面的的例子基础之上的TimeClient上修改 我们的本意是发送三条您好 //发送数据 f.channel().writeAndFlush(Unpooled.copiedBuffer ("您好".getBytes())); //Thread.sleep(1000);//防止TCP粘 f.channel().writeAndFlush( writeAndFlush(Unpooled.copiedBuffer("您好".getBytes())); //Thread.sleep(1000); 数据粘在一起了,就是数据的粘 f.channel().writeAndFlush(Unpooled.copiedBuffer("您好".getBytes())); Thread.sleep(1000);//防止TCP粘

    33210编辑于 2023-12-25
  • 来自专栏java技术爱好者

    Netty进阶之粘问题

    一、什么是粘 TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。(来自百度百科) 发送端为了将多个发给接收端的数据,更有效地发送到接收端,会使用Nagle算法。 所谓的粘问题,就是因为TCP消息无保护边界导致的。 1.1 图解粘 ? 正常发送消息是三次发送三个数据,这种情况没有问题。 粘,则是其中有多个数据包合并成一个数据进行发送,也就是上图的第二种情况。 ,则是其中一个数据包被拆成了多段,发送的数据只包含了一个完整数据的一部分。也就是上图的第三种情况。 粘的问题就轻松得到解决。 注意点:数据末尾一定是分隔符,分隔符后面不要再加上数据,否则会当做下一条数据的开始部分。 2.3.3 分析Protocol的粘 实际上直接使用Protocol编解码器还是存在粘问题的。

    1.5K20发布于 2020-09-22
  • 来自专栏python教程

    socket网络编程(五)——粘问题

    今天和大家讲一下socket网络编程中粘的问题。 2、粘的几种情况 这个问题在socket网络编程中非常的常见,数据不仅会粘,还会被,就是一段数据被拆成两部分。 那么、粘问题产生的原因都有哪些呢 要发送的数据大于TCP发送缓冲区剩余空间大小,将会发生。 待发送数据大于MSS(最大报文长度),TCP在传输前将进行。 3、处理粘的方法 处理、粘问题的方法: 那么最关键的就是我们该怎么处理粘问题呢? 第1种和第2种方法都会存在一些误差,没有办法很好处理好粘,所以一般的方法都是采用第3种。以下我先给出代码,然后再结合代码分析第3种粘的处理方式。

    61310编辑于 2024-01-10
领券