linux的Netty服务器端如何自动识别客户端已断开

目前FScoket无法做到感知服务端关闭tcp链接，要做到只能通过两种其他方式：

1，使用BSD socket（建议使用non-blocking mode，因为这样方便终止接收线程）；

2，客户端发送心跳包给服务端，如果没有得到回应则认为关闭。

WebSocket是一种规范，是Html5规范的一部分，websocket解决什么问题呢？解决http协议的一些不足。我们知道，http协议是一种无状态的，基于请求响应模式的协议。

网页聊天的程序（基于http协议的），浏览器客户端发送一个数据，服务器接收到这个浏览器数据之后，如何将数据推送给其他的浏览器客户端呢？

这就涉及到服务器的推技术。早年为了实现这种服务器也可以像浏览器客户端推送消息的长连接需求，有很多方案，比如说最常用的采用一种轮询技术，就是客户端每隔一段时间，比如说2s或者3s向服务器发送请求，去请求服务器端是否还有信息没有响应给客户端，有就响应给客户端，当然没有响应就只是一种无用的请求。

这种长轮询技术的缺点有：

1）响应数据不是实时的，在下一次轮询请求的时候才会得到这个响应信息，只能说是准实时，而不是严格意义的实时。

2）大多数轮询请求的空轮询，造成大量的资源带宽的浪费，每次http请求携带了大量无用的头信息，而服务器端其实大多数都不关注这些头信息，而实际大多数情况下这些头信息都远远大于body信息，造成了资源的消耗。

拓展

比较新的技术去做轮询的效果是Comet。这种技术虽然可以双向通信，但依然需要反复发出请求。而且在Comet中，普遍采用的长链接，也会消耗服务器资源。

WebSocket一种在单个 TCP 连接上进行 全双工通讯 的协议。WebSocket通信协议于2011年被IETF定为标准RFC 6455，并被RFC7936所补充规范。WebSocket API也被W3C定为标准。

WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许 服务端主动向客户端推送数据 。在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

websocket的出现就是解决了客户端与服务端的这种长连接问题，这种长连接是真正意义上的长连接。客户端与服务器一旦连接建立双方就是对等的实体，不再区分严格意义的客户端和服务端。长连接只有在初次建立的时候，客户端才会向服务端发送一些请求，这些请求包括请求头和请求体，一旦建立好连接之后，客户端和服务器只会发送数据本身而不需要再去发送请求头信息，这样大量减少了

网络带宽。websocket协议本身是构建在http协议之上的升级协议，客户端首先向服务器端去建立连接，这个连接本身就是http协议只是在头信息中包含了一些websocket协议的相关信息，一旦http连接建立之后，服务器端读到这些websocket协议的相关信息就将此协议升级成websocket协议。websocket协议也可以应用在非浏览器应用，只需要引入相关的websocket库就可以了。

HTML5定义了WebSocket协议，能更好的节省服务器资源和带宽，并且能够更实时地进行通讯。Websocket使用ws或wss的统一资源标志符，类似于HTTPS，其中wss表示在TLS之上的Websocket。如：

优点

浏览器页面向服务器发送消息，服务器将当前消息发送时间反馈给浏览器页面。

服务器端

服务器端初始化连接

WebSocketServerProtocolHandler ：参数是访问路径，这边指定的是ws，服务客户端访问服务器的时候指定的url是： ws://localhost:8899/ws 。

它负责websocket握手以及处理控制框架（Close，Ping（心跳检检测request），Pong（心跳检测响应））。 文本和二进制数据帧被传递到管道中的下一个处理程序进行处理。

桢 ：

WebSocket规范中定义了6种类型的桢，netty为其提供了具体的对应的POJO实现。

WebSocketFrame：所有桢的父类，所谓桢就是WebSocket服务在建立的时候，在通道中处理的数据类型。本列子中客户端和服务器之间处理的是文本信息。所以范型参数是TextWebSocketFrame。

自定义Handler

页面 ：

启动服务器，然后运行客户端页面，当客户端和服务器端连接建立的时候，服务器端执行 handlerAdded 回调方法，客户端执行 onopen 回调方法

服务器端控制台：

页面：

客户端发送消息，服务器端进行响应，

服务端控制台打印：

客户端也收到服务器端的响应：

打开开发者工具 ：

在从标准的HTTP或者HTTPS协议切换到WebSocket时，将会使用一种升级握手的机制。因此，使用WebSocket的应用程序将始终以HTTP/S作为开始，然后再执行升级。这个升级动作发生的确定时刻特定与应用程序；它可能会发生在启动时候，也可能会发生在请求了某个特定的IURL之后。

参考技术

java web 服务器推送技术--comet4j

Comet：基于 HTTP 长连接的“服务器推”技术

潜在的修复:校园网不能连接到服务器。

浏览器没法连接到网站服务器，简单说就是浏览器无法联网了，这里有很多原因导致，有网络原因，还有浏览器设置原因。

1、首先，我们需要保证网络是通畅的，也就是电脑可以正常联网，如果电脑都不能正常联网，那么，自然浏览器也不能连接到网站服务服务器，出现浏览器couldnotconnect的错误提示啦，所以，首先检查网络是否通畅。

2、其次，是浏览器代理服务器设置，由于IE浏览器或者系统设置了代理服务器，而代理服务器已经关闭或者不存在了，就会无法联网，默认状态下，浏览器都是使用IE浏览器代理服务器或者系统代理服务器的，即便我们没有在我们觉得很好用的浏览器中设置代理服务器，所以，需要检查IE浏览器代理服务器和系统代理服务器设置。

3、如果这些都没有问题的话，可以尝试使用系统自带的IE浏览器或看看是否能够正常上网，是否还出现浏览器Couldnotconnect的错误提示，如果都正常了，这说明，我们的浏览器或者系统防火墙阻止了该浏览器访问网络；我们可以重新安装新版浏览器，并在系统防火墙对该浏览器放行，或者干脆关闭系统防火墙。

Netty提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。 也就是说，Netty 是一个基于NIO的客户，服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty相当简化和流线化了网络应用的编程开发过程，例如，TCP和UDP的socket服务开发。

Netty是一个基于NIO的服务器端（简化TCP/UDP的socket开发）。

java 写道Web Services是由企业发布的完成其特定商务需求的在线应用服务,其他公司或应用软件能够通过Internet来访问并使用这项在线服务。实际上，WebService的主要目标是跨平台的可互操作性。为了达到这一目标，WebService完全基于XML（可扩展标记语言）、XSD（XMLSchema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。由此可以看出，在以下三种情况下，使用WebService会带来极大的好处。

即提供第三方可使用服务（可以基于http/tcp等）。

servlet：是服务器端执行的小应用程序，是一个服务器组件，比如HttpServlet 用于实现对Http请求的处理，接受请求 处理、动态产生响应。

三者关注点不同：

netty 提供一套基于NIO的服务器的框架（简化TCP/UDP的socket开发），类似的还有mina。 比如实现一个web服务器。

web service 重点是web服务，建立一套规则，使得跨平台/跨应用可可访问。比如天气预报接口、google Map接口等。

Netty是由JBOSS提供的基于Java NIO的开源框架，Netty提供异步非阻塞、事件驱动、高性能、高可靠、高可定制性的网络应用程序和工具，可用于开发服务端和客户端。

JAVA原先是采用的是传统的BIO，为什么后来又研发出了NIO呢？

首先看看传统的基于同步阻塞IO（BIO）的线程模型图

BIO主要存在以下缺点：

1从线程模型图中可以看到，一连接一线程，由于线程数是有限的，所以这样的模型是非常消耗资源的，

最终也导致它不能承受高并发连接的需求

2性能低，因为频繁的进行上下文切换，导致CUP利用率低

3可靠性差，由于所有的IO操作都是同步的，即使是业务线程也如此，所以业务线程的IO操作也有可能被阻塞，

这将导致系统过分依赖网络的实时情况和外部组件的处理能力，可靠性大大降低

上面的原因就是导致早期的高性能服务器为什么不选用JAVA开发，而是选用C/C++的重要原因。

为了解决上面的问题，NIO横空出世，下面是NIO的线程模型图

1NIO采用了Reactor线程模型，一个Reactor聚合了一个多路复用器Selector，它可以同时注册、监听和轮询

成百上千个Channel，这样一个IO线程可以同时处理很多个客户端连接，线程模型优化为1：N(N<最大句柄、数)，

或M:N(M通常为CUP核数+1)

2避免了IO线程频繁的上下文切换，提升了CUP的效率

3所有的IO操作都是异步的，所以业务线程的IO操作就不用担心阻塞，系统降低了对网络的实时情况和外部组件

的处理能力的依赖

为什么不直接用JDK原生的NIO而选用Netty框架？

先看看JDK的NIO中服务端和客户端的时序图

服务端：

客户端：

从图中我们可以看到，使用JDK原生NIO的不足之处

1NIO的类库和API相当复杂，使用它来开发，需要非常熟练地掌握Selector、ByteBuffer、ServerSocketChannel、SocketChannel等

2需要很多额外的编程技能来辅助使用NIO,例如，因为NIO涉及了Reactor线程模型，所以必须必须对多线程和网络编程非常熟悉才能写出高质量的NIO程序

3想要有高可靠性，工作量和难度都非常的大，因为服务端需要面临客户端频繁的接入和断开、网络闪断、半包读写、失败缓存、网络阻塞的问题，这些将严重影响我们的可靠性，而使用原生NIO解决它们的难度相当大。

4JDK NIO中著名的BUG--epoll空轮询，当select返回0时，会导致Selector空轮询而导致CUP100%，官方表示JDK16之后修复了这个问题，其实只是发生的概率降低了，没有根本上解决。

那么为什么要用Netty呢？

1API使用简单，更容易上手，开发门槛低

2功能强大，预置了多种编解码功能，支持多种主流协议

3定制能力高，可以通过ChannelHandler对通信框架进行灵活地拓展

4高性能，与目前多种NIO主流框架相比，Netty综合性能最高

5高稳定性，解决了JDK NIO的BUG

6经历了大规模的商业应用考验，质量和可靠性都有很好的验证。

Netty能提供什么服务？

1开发异步非阻塞的TCP网络应用程序

2开发异步非阻塞的UDP网络应用程序

3开发异步文件传输程序

4开发异步HTTP程序的服务端和客户端

5提供多种编解码的集成框架，包括谷歌Protobuf、JBossMarshalling、Java序列化、压缩编解码、XML解码、

字符串编解码等都可以由用户直接使用

6提供形式多样的编解码基础类库，可以方便地进行私有协议栈编解码框架的二次开发

7基于职责链的Pipeline-Handler机制，可以方便地对网络事件进行拦截和定制

8所有的IO操作都是异步的，用户可以通过Future-Listeren机制主动get结果或者等IO线程完成操作之后主动Notify来通知，

用户业务线程不需要同步等待

9基于链路空闲事件监测的心跳机制

10流量控制和整形