netty tcp udp nio bio

在这里插入图片描述

udp效率高 不需要三次握手 但是肯能会导致数据丢失
在这里插入图片描述

三次挥手 传输数据之前
四次挥手。关闭链接时候 客户端与服务端
长链接 短链接

服务器端在没有链接的时候 会一直阻塞

服务器端是 没有接收到客户端数据会一直阻塞
在这里插入图片描述
在这里插入图片描述


Tcp 必须先和服务器链接上 才会发送数据
所以会有2种阻塞
Udp 可以直接给服务器发送消息。所以只会有 没有接收到客户端数据阻塞。

长链接 可能会非常耗占服务器资源。因为一个链接建立链接之后 不会立马关闭。
可以做一个超时时间 长链接最长保持时间
1分钟后 服务器端可以主动关闭链接

长链接类似 线程池

同步 单线程
异步 多线程。线程运行在cpu上。1个cpu同一时间只能运行一个线程。
优化;mq 异步形式 代替多线程。

阻塞

非阻塞

在这里插入图片描述

===============================
2020.10.29

1个cpu同一时间只能运行一个线程。


大项目建议用mq


没有建立三次握手 会一直阻塞

三次握手成功时候 客户端对服务端没有发送数据。线程会一直阻塞


零拷贝

唤醒 内核空间 拷贝 到 用户空间


nio
同步非阻塞
-1 没有读到数据
client.read()




Nio cpu减少消耗资源

Udp 不必三次握手


Select O(n)
没有读到数据的情况下 坑能会有这么空数据

epoll事件通知回调方式。避免空轮训
O(1)
比如有1万个链接。不是会进行1万次遍历。只有连接中有数据才会进行遍历 避免空轮训

redis官网没有windows版本 大牛人物 改写redis源码 redis在windows 上是select 可能会有空轮训。 bio阻塞模型 前面2个线程建立链接 空数据 建立的线程一直在耗占资源 新来的第3个线程 三次握手后 传入服务端数据 新建线程 服务端读取客户端数据。 原来的2个线程会一直耗占资源 不会释放 除非客户端主动关闭 或者 服务端设置关闭 属于bio弊端