1.基于流，数据流，机械性能消耗大。
2.阻塞，服务器开了一个端口，只要没有客户端连接，它一直处于阻塞状态。
多线程方案，来一个客户端，就给他开个线程单独处理，产生了线程开销很大。
3.读和写并没有完全分离，读和写一定是在同一个线程完成的，读和写一定一起。
NIO解决问题：
1.基于管道，先把通讯的道路修好，轮询处理。
2.非阻塞（好像默认是阻塞，可以设定非阻塞），提高处理效率。
3.读写可以分离的，大大提高通讯效率，
缓冲区做成两个，一个专门读一个专门写
对NIO操作，非常繁琐，读写分离还得分配两个缓冲区，
得开管道，一个比较繁琐的过程，来一个客户端要开一个线程。
这种前提下，我们的NIO框架就产生了。
为解决大家一个操作繁琐的过程，对NIO操作进行封装。
Netty，不仅仅对NIO封装
socket基本通信原理：
第一次，建立连接握手。
知道对方IP地址通不通，要知道对方端口能不能访问。
第二次，开始发送信息
服务端跟客户端，就相当于是进行实际的交互了。
第三次，服务端，要给客户端反馈。
第四次，通信完毕，连接断开或关闭
通信机制：
上层开发：做上层开发的话，是很少直接基础到底层协议的。
底层协议：
规范：
http协议：再熟悉不过
FTP协议：文件传输协议
MAIL协议：又见协议SMTP协议
Netty 封装了很多RPC
RMI就是RPC的一种 RPC>RMI
webService:基于soap这种协议规范，xml里面规定了传输对象类型，
调用方法名，传输到我们调用端的时候还得需要对xml进行解析，解析xml又非常的繁琐。
RMI：协议，字节流协议 序列化（客户端）和反序列化(服务器端)
字节流操作还需要转化成java对象 （socket）,
对象的class字节码保存起来，classLoader反射
性能非常低下，
webService，RMI最终都转化成了二进制。
Netty
1.提高通信的性能。
2.对RPC操作进行的封装，使得我们操作简单化。
Dubbo dubbo：// 基于Netty进行封装，类似于RMI
小结：
1.NIO操作进行了封装
2.RPC进行了封装
二.Netty能做什么？
IO框架，只要做网络之间通信，Netty都能做。
三.Netty下的网络协议：
工作原理：
master主线程
work从线程
四：代码：
问题思考 netty为什么没有使用AIO
https://github.com/netty/netty/issues/2515