Netty笔记之六：Netty对websocket的支持

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 长连接的“服务器推”技术

在网络层有IP协议,ICMP协议,ARP协议,RARP协议和BOOTP协议.

在传输层中有:TCP协议与UDP协议.

在应用层有:通过TCP协议来通信的应用层协议包括FTP,HTTP,TELNET,SMTP协议. 通过UDP协议来通信的应用层协议包括DNS,TFTP等

连接->数据传输->关闭连接

HTTP是无状态的,浏览器和服务器每进行一次HTTP操作,就建立一次连接,单任务结束后就中断连接.也可以这样说:短连接是指Socket连接后发送后接收完数据后马上断开连接.

连接->传输数据->保持连接->传输数据->….->关闭连接

长连接指建立socket连接后不管是否使用都保持连接,但安全性较差.

http的长连接

HTTP也可以建立长连接的,使用Connection:keep-alive,HTTP1.1默认进行持久连接,HTTP1.1和HTTP1.0相比较而言最大的区别就是添加了持久连接支持(貌似最新的http1.0可以显示的指定keep-alive)但还是无状态的,或者说是不可信任的.

长连接多用于操作频繁,点对点的通讯,而且连接数不能太多情况.每个TCP连接都需要三步握手,这需要时间,如果每个操作都是先连接在操作的话那么处理时间会降低很多,所以每个操作完后都不断开,次处理时直接发送数据包就OK了,不用再次建立连接.例如即使通讯环信底层用的就是长连接聊天过程中为了保证消息的实时性,保持长连接进行会话!

而web网站的http服务一般用短连接,因为长连接对于服务端来说会耗费一定的资源,而像web网站这样频繁成千上万甚至上亿客户端的连接用短连接会更省资源,如果用长连接,而且同时有成千上万的用户,如果每个用户都占用一个连接的话,并发数会很大,这样后台服务器有承受很大的压力,所以这种情况小用短连接会比较好.

Socket是应用层与TCP/IP协议通讯的中间软件抽象层,它是一组接口,在设计模式中,socket其实就是一个门面模式,它把复杂的TCP/IP组协议隐藏在了socket接口后面,对用户来说简单的接口就是全部,让socket去组织数据,以符合指定的协议.

主机A的应用程序要和主机B的应用程序进行通信,必须通过socket建立连接,而建立socket连接必须通过底层的TCP/IP协议建立TCP连接,建立TCP连接需要底层IP协议来寻址网络中的主机.我们知道网络中的IP协议可以帮助我们根据IP地址来找到目标主机但是一台主机上可能运行着多个应用程序,如何才能与指定的应用程序通信就要通过TCP和UDP的地址也就是端口号来指定,这样就可以通过socket实例唯一代表一个主机上的一个应用程序的通信链路了.

(1)第一次握手:Client(客户端)将标识位SYN(发起一个新连接)置为1,随机产生一个(序号:发送数据对其标识)seq=J,并将该数据发送给server(服务器),Client(客户端)进入SYN_SENT状态,等待Server确认.

(2)第二次握手:Server收到数据包后由SYN=1知道Client请求建立连接,Server将SYN和ACK都置为1,ack=J+1.随机产生一个seq=k,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态.

(3)第三次握手:Client收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标识位ACK置为1,ack=k+1并将数据包发送给Server,Sever检查ack是否为k+1,ACK是否为1,如果正确则建立连接Client和server进入ESTABLISHED状态,完成三次握手,随后Client和Server之间可以开始传输数据了.

（1）第一次挥手：Client发送一个FIN(释放一个连接)，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

（2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

（3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK(确认序号有效)状态.

（4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

Q1 : HTTP Socket TCP UDP都是什么？

HTTP 全称是超文本传输协议，是一个应用层的协议。用于客户端和服务端之间进行通讯。

TCP/UDP 都是传输层协议。TCP是可靠的，我们常说的三次握手连接，四次握手断开都是说的TCP。而UDP是不可靠的。

Socket 则是从传输层抽象出来的接口层。

Q2 : HTTP连接和Socket连接有什么区别？分别在什么情况下使用？

HTTP 是基于TCP的短连接。需要经过三次握手建立连接，且无法保持始终连接。

Socket 是长连接。基于TCP的Socket连接，一旦建立三次握手，除非一方主动断开，否则连接状态一直保存。也可以基于UDP进行Socket连接。

HTTP连接，服务端无法主动发消息，采用的是'请求-响应'机制。客户端没有发消息给服务端，服务端无法推送消息给客户端。

Socket连接，一方可以随时向另一方发起会话。

双方不需要时刻保持连接在线用HTTP。eg : 客户端资源获取、上传文件等。

即时通讯应用需要用Socket连接。eg : 微信、苹果的APNs等。

Q3 : HTTPS是什么？和HTTP有什么区别？

HTTPS就是HTTP加上SSL/TLS。TLS(Transport Layer Security)传输层安全协议，作用是在传输层对网络连接加密。SSL就是TLS的前身。

HTTP端口是80，是无状态的。HTTPS端口是443，是可以进行加密传输、身份认证的网络协议。

Feign在默认情况下使用的是JDK原生的URLConnection发送HTTP请求，没有连接池，但是对每个地址会保持一个长连接，即利用HTTP的persistence connection 。我们可以用Apache的HTTP Client替换Feign原始的http client, 从而获取连接池、超时时间等与性能息息相关的控制能力。Spring Cloud从Brixtion.SR5版本开始支持这种替换，首先在项目中声明Apache HTTP Client和feign-httpclient依赖

---