Netty：

    a.高性能、事件驱动、异步非堵塞

    b.基于NIO的客户端、服务器端编程框架

    c.稳定性和伸缩性

WebSocket如何关闭链接：

1、服务端关闭底层TCP链接

2、客户端发起TCP Close

底层的TCP 正常情况下应该首先由服务器关闭 在异常情况下客户端可以发起TCP Close。

流程：当服务器被指示关闭WebSocket链接时，服务端会发起一个TCP Close操作 客户端等待服务器的TCP Close

WebSocket生命周期：

1、打开事件：端点上建立新链接时，该事件是先于其他任何事件发生之前。该事件发生会产生三部分信息。

1.1、创建WebSocket Session对象：用于表示已经建立好的链接

1.2、配置对象：包含配置端点的信息。

1.3、一组路径参数，打开节点握手时，socket端入栈匹配的URI

2、消息事件：主要是接收WebSocket对话中，另一端发送的消息。链接上的消息将会有三种形式抵达客户端。

2.1、文本消息 用String处理

2.2、二进制消息 用byteBuffer或者byte[]处理

2.3、pong消息 用java中pong.message接口的实例来处理

3、错误事件：WebSocket链接或者端点发生错误时产生。可以处理入栈消息时发生的各种异常。入栈消息可能产生的三种异常。

3.1、WebSocket建立链接时发生错误：SessionException

3.2、WebSocket试图将入栈消息解码成开发人员使用的对象时 EncodeException

3.3、WebSocket端点的其他方法运行时产生的错误

4、关闭时间：WebSocket链接端点关闭，做一些清理工作，可以由参与的任意一个端点发出。

WebSocket建立连接过程：

1、客户端发起握手请求。

2、服务端响应请求。

3、建立链接。

详细流程：

浏览器首先向服务器发送一个特殊的Http请求(携带一些附加头信息)Upgrade:websocket，服务端解析附加头信息，产生应答消息，然后响应给客户端。之后客户端就与服务端建立响应的链接。

服务器可主动传送数据给客户端：

在给定时间，服务器和客户端在任意时刻相互推送信息，浏览器（客户端）和服务器只需要做一个握手的动作。建立连接后，服务器可主动传数据给客户端，客户端也可以随意向服务端传数据。交换数据时所携带的头信息很小。

实时通信：

WebSocket不仅限于Ajax方式通信。ajax方式需要浏览器发起请求。而WebSocket技术 服务端和客户端可以彼此相互推送信息，从而实现实时通信。

WebSocket优点：

节省通信开销：之前WebServer实现通信，都使用轮询（每隔特定时间间隔浏览器自动发送Http请求，去获取服务端的响应）该情况下，需要不停的向服务器发送请求，而HttpRequest的handler很长，请求包含真正的数据可能很小，会占用很多额外的带宽和服务器资源。

什么是WebSocket：是一种H5协议规范

解决客户端与服务端实时通信而产生的技术：WebSocket本质是一种基于TCP协议，先通过Http/Https发一个特殊的Http请求进行握手，握手后会创建一个用于交换数据的TCP链接，之后客户端和服务端使用该TCP链接进行实时通信。当WebSocket的客户端和服务端握手后 建立通信后，就不再需要之前的http请求参与。

客户端的断链 重链 网络闪断 半包读写 失败缓存 网络拥塞 异常码流

AIO：非阻塞异步IO

1、连接注册读写事件和回调函数

2、读写方法异步。

3、主动通知程序。

两种方式获取结果。

1、java.util.concurrent.Future类来保存异步操作的结果，Future get()方法（带或不带超时参数）在异步IO操作完成时获取其结果。

2、在异步操作时，传入回调的handler

该Handler是java.nio.channels.CompletionHandler接口的实现类。

NIO：非阻塞同步IO

1、缓冲区Buffer：读数据是从缓冲区读，写数据也是写入缓冲区。所有的数据都是通过缓冲区处理。

2、通道Channel：双向的，可以读写，或同时读写。流是单向的，只能读或写。

3、多路复用器Selector：Selector一直轮询Channel。当Channel发生读写操作时，该Channel就处于就绪状态，就会被Selector轮询出来。通过Selection.key()就可以获取就绪Channel的集合。之后再进行后续操作。

而由于JDK使用Epoll代替了传统的Selector实现。而且Epoll没有最大链接数的限制。可以接入数万级的客户端。

伪异步IO通信=BIO+线程池 阻塞同步IO

在BIO基础上增加使用线程池管理客户端请求的线程。

当有一个新的客户端请求时，将客户端的WebSocket封装成一个异步任务。交由线程池进行处理。由于线程池中可以设置消息队列(任务)大小。以及最大线程数，所以资源是可控的，无论多少个并发客户端访问，都不出现因资源耗尽而造成的down机的情况。

缺点：当大量客户端接入，并发量很大时，可能会出现线程池线程阻塞等待。

BIO：一请求一应答模型 阻塞同步IO

一个线程去监听客户端链接，当监听到客户端链接时，会为每个客户端创建一个新的线程去进行处理，处理结束，通过输出流返回应答给客户端，最后销毁线程。

缺点：由于会每个客户端请求创建新的线程去处理。所以随着并发量的增加，效率会大大降低。 还有可能出现线程堆栈溢出，创建新线程失败等问题。最终会导致无法提供提供服务。

JDK NIO的BUG，例如臭名昭著的epoll bug，它会导致Selector空轮询，最终导致CPU 100%。官方声称在JDK1.6版本的update18修复了该问题，但是直到JDK1.7版本该问题仍旧存在，只不过该BUG发生概率降低了一些而已，它并没有被根本解决。

h5 握手协议 实时通信

WebSocket生命周期