magic_chao1
这个作者很懒,什么都没留下…
展开
-
6. 源码解析(启动服务)
整体流程。原创 2024-04-26 17:47:00 · 9 阅读 · 0 评论 -
5. nio与netty代码展示
【代码】5. nio与netty代码展示。原创 2024-04-26 15:37:59 · 11 阅读 · 0 评论 -
4.keepalive 与 Idle 监测
• 一般你会稍微等待一定的时间,在这个时间内看看对方还会不会说话(Idle 检测),如果还不说,认定对方存在问题(Idle),于是开始发问“你还在么?当启用(默认关闭)keepalive 时,TCP 在连接没有数据通过的7200秒后发送 keepalive 消息,当探测没有确认时,按75秒的重试频率重发,一直发 9 个探测包都没有确认,就认定连接失效。假设你开了一个饭店,别人电话来订餐,电话通了后,订餐的说了一堆订餐要求,说着说着,对方就不讲话了。如果不会,那你一般怎么去做?”,如果对方没有回复,挂机。原创 2024-04-25 15:35:18 · 32 阅读 · 0 评论 -
3.常用的“二次”编解码方式
这是因为json中那些特有的分隔符,即使在UTF-8中也是用一个byte来存储的,这样我们在读取数据的过程中,可以通过读取的byte值和json的分隔符进行比较,从而来确定json中不同对象的界限。那么我们在项目中,除了可选的的压缩解压缩之外,还需要一层解码,因为一次解码的结果是字节,需要和项目中所使用的对象做转化,方便使用,这层解码器可以称为“二次解码器”,相应的,对应的编码器是为了将 Java 对象转化成字节流方便存储或传输。假设我们把解决半包粘包问题的常用三种解码器叫一次解码器。原创 2024-04-23 17:23:42 · 66 阅读 · 0 评论 -
2.TCP 粘包、半包 Netty 全搞定
粘包的主要原因:• 发送方每次写入数据 < 套接字缓冲区大小• 接收方读取套接字缓冲区数据不够及时半包的主要原因:• 发送方写入数据 > 套接字缓冲区大小• 发送的数据大于协议的 MTU(Maximum Transmission Unit,最大传输单元),必须拆包换个角度看:• 收发一个发送可能被多次接收,多个发送可能被一次接收• 传输一个发送可能占用多个传输包,多个发送可能公用一个传输包根本原因:TCP 是流式协议,消息无边界。原创 2024-04-23 17:03:23 · 25 阅读 · 0 评论 -
1. netty的介绍
阻塞:没有数据传过来时,读会阻塞直到有数据;缓冲区满时,写操作也会阻塞。数据就绪后需要自己去读是同步,数据就绪直接读好再回调给程序是异步。非阻塞遇到这些情况,都是直接返回。原创 2024-04-23 15:36:43 · 12 阅读 · 0 评论