WebSocket总结
IM通讯项目中用到了WebSocket建立连接，这里做一个简单地整理总结：
一句话总结一下 WebSocket：
WebSocket 是 HTML5 开始提供的一种独立在单个 TCP 连接上进行全双工通讯的有状态的协议(它不同于无状态的 HTTP)，并且还能支持二进制帧、扩展协议、部分自定义的子协议、压缩等特性。
一、Socket简介
Socket又称‘套接字‘，应用程序通常通过‘套接字‘向网络发出请求或者应答网络请求。Socket可以实现应用程序间网络通信。
Socket可以使用TCP／IP协议或者UDP协议
TCP／IP协议
TCP／IP协议是目前最为广泛的协议，是构成Internet国际互联网协议的最为基础的协议，由TCP和IP协议组成。
TCP协议：是面向连接的，可靠的、基于字节流的传输层通信协议，负责数据的可靠性传输问题。
IP协议：用于报文交换网络的一种面向数据的协议，主要负责给每台网络设备一个网络地址，保证数据传输到正确的目的地。
UDP协议
无连接、不可靠、基于报文的传输层协议，优点是发送后不用管，速度比TCP快。
二、WebSocket简介与消息推送
B／S架构的系统多使用HTTP协议
HTTP协议的特点
1无状态协议
2用于通过Internet发送请求消息和响应消息
3使用端口接收和发送消息，默认端口80
HTTP协议决定了服务器与客户端之间的连接方式，无法直接实现双向通信与消息推送，一些变相的解决办法：
轮询polling：客户端定时向服务器发送Ajax请求，服务器接到请求后马上返回响应信息并关闭连接。请求中大半是无用的，浪费带宽和服务器资源。
长轮训Long polling：客户端定时向服务器发送Ajax请求，服务器接到请求后Hold住连接，直到有消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求。在无消息的情况下不会频繁的请求，耗资少，但是服务器hold住连接会消耗资源，返回数据无保障。
长连接：在页面里嵌入一个隐蔵iframe，将这个隐蔵iframe的src属性设为对一个长连接的请求或是采用xhr请求，服务器端就能源源不断地往客户端输入数据。 优点：消息即时到达，不发无用请求；管理起来也相对便。 缺点：服务器维护一个长连接会增加开销。 实例：Gmail聊天
WebSocket：是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。依靠这种技术可以实现客户端和服务器端的长连接，双向实时通信。
特点:
事件驱动
异步
使用ws或者wss协议的客户端socket
能够实现真正意义上的推送功能
缺点：
少部分浏览器不支持，浏览器支持的程度与方式有区别。
WebSocket与Socket的关系
Socket其实并不是一个协议，而是为了方便使用TCP或UDP而抽象出来的一层，是位于应用层和传输控制层之间的一组接口。
Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。
当两台主机通信时，必须通过Socket连接，Socket则利用TCP/IP协议建立TCP连接。TCP连接则更依靠于底层的IP协议，IP协议的连接则依赖于链路层等更低层次。
WebSocket则是一个典型的应用层协议。
区别
Socket是传输控制层协议，WebSocket是应用层协议。
三、WebSocket客户端
websocket允许通过JavaScript建立与远程服务器的连接，从而实现客户端与服务器间双向的通信。在websocket中有两个方法：
1、send() 向远程服务器发送数据
2、close() 关闭该websocket链接
websocket同时还定义了几个监听函数
1、onopen 当网络连接建立时触发该事件
2、onerror 当网络发生错误时触发该事件
3、onclose 当websocket被关闭时触发该事件
4、onmessage 当websocket接收到服务器发来的消息的时触发的事件，也是通信中最重要的一个监听事件。msg.data
websocket还定义了一个readyState属性，这个属性可以返回websocket所处的状态：
1、CONNECTING(0) websocket正尝试与服务器建立连接
2、OPEN(1) websocket与服务器已经建立连接
3、CLOSING(2) websocket正在关闭与服务器的连接
4、CLOSED(3) websocket已经关闭了与服务器的连接
websocket的使用：
websocket的url开头是ws，如果需要ssl加密可以使用wss，当我们调用websocket的构造方法构建一个websocket对象（new WebSocket(url)）的之后，就可以进行即时通信了。
在项目实际开发中我们往往使用SpringMVC提供的对WebSocket封装，如下：
public class ImSellerController extends TextWebSocketHandler {
并且重写下边这些方法：
@Override
public void afterConnectionEstablished(WebSocketSession session) throws Exception {....} @Override
public void afterConnectionClosed(WebSocketSession session, CloseStatus status) throws Exception {...}
@Override
protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {....}
}
四、WebSocket建立连接过程
客户端开始建立WebSocket连接时要发送一个header标记了 Upgrade的HTTP请求，表示请求协议升级。所以服务器端做出响应的简便方法是，直接在现有的HTTP服务器软件和现有的端口上实现WebSocket协议，然后再回一个状态码为101的HTTP响应完成握手，再往后发送数据时就没 HTTP的事了。也就是说WebSocket只是使用HTTP协议来完成一部分握手。
通过HTTP握手
-
Browser与WebSocket服务器通过TCP三次握手建立连接，如果这个建立连接失败，那么后面的过程就不会执行，Web应用程序将收到错误消息通知。
-
在TCP建立连接成功后，Browser/UA通过http协议传送WebSocket支持的版本号，协议的字版本号，原始地址，主机地址等等一些列字段给服务器端。
握手部分的设计目的就是兼容现有的基于HTTP的服务端组件（web服务器软件）或者中间件（代理服务器软件）。这样一个端口就可以同时接受普通的HTTP请求或则WebSocket请求了。为了这个目的，WebSocket客户端的握手是一个 HTTP升级版的请求（HTTP Upgrade request）：
客户端发送一个请求
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
这段类似HTTP协议的握手请求中多了以下几个东西
Upgrade: websocket
Connection: Upgrade是告诉服务器我想升级为websocket协议
Sec-WebSocket-Key是一个Base64加密的密钥Sec-WebSocket-Protocol是用于标识客户端想和服务端使用哪一种子协议（都是应用层的协议，比如 chat 表示采用 “聊天” 这个应用层协议）。Sec-WebSocket-Version是告诉服务器所使用的协议版本OriginOrigin可以预防在浏览器中运行的脚本，在未经 WebSocket 服务器允许的情况下，对其发送跨域的请求。浏览器脚本在使用浏览器提供的 WebSocket 接口对一个 WebSocket 服务发起连接请求时，浏览器会在请求的 Origin 中标识出发出请求的脚本所属的源，然后 WebSocket 在接受到浏览器的连接请求之后，就可以根据其中的源去选择是否接受当前的请求。
比如我们有一个 WebSocket 服务运行在 http://websocket.example.com，然后你打开一个网页 http://another.example.com，在个 another 的页面中，有一段脚本试图向我们的 WebSocket 服务发起链接，那么浏览器在其请求的头中，就会标注请求的源为 http://another.example.com，这样我们就可以在自己的服务中选择接收或者拒绝该请求。
服务端响应
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat上面提到了这个101是状态码，websocket是使用 HTTP 协议的101状态码进行协议切换。
Sec-WebSocket-Accept这个值表示服务器同意握手建立连接，是客户端传输过来的Sec-WebSocket-Key跟“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”拼接后，用SHA-1加密，并进行BASE-64编码得来的,Sha1(Sec-WebSocket-Key+258EAFA5-E914-47DA-95CA-C5AB0DC85B11)。
客户端收到Sec-WebSocket-Accept后，将本地的Sec-WebSocket-Key进行同样的编码，然后比对。
五、socket中TCP的三次握手建立连接详解
我们知道tcp建立连接要进行“三次握手”，即交换三个分组。大致流程如下：
- 客户端向服务器发送一个SYN J
- 服务器向客户端响应一个SYN K，并对SYN J进行确认ACK J+1
- 客户端再想服务器发一个确认ACK K+1
只有就完了三次握手，但是这个三次握手发生在socket的那几个函数中呢？请看下图：
图1、socket中发送的TCP三次握手
从图中可以看出，当客户端调用connect时，触发了连接请求，向服务器发送了SYN J包，这时connect进入阻塞状态；服务器监听到连接请求，即收到SYN J包，调用accept函数接收请求向客户端发送SYN K ，ACK J+1，这时accept进入阻塞状态；客户端收到服务器的SYN K ，ACK J+1之后，这时connect返回，并对SYN K进行确认；服务器收到ACK K+1时，accept返回，至此三次握手完毕，连接建立。
为什么需要三次握手，而非两次
TCP 协议为了实现可靠传输， 通信双方需要判断自己已经发送的数据包是否都被接收方收到， 如果没收到， 就需要重发。 为了实现这个需求， 很自然地就会引出序号（sequence number） 和 确认号（acknowledgement number） 的使用。
为了实现可靠传输，发送方和接收方始终需要同步( SYNchronize )序号。 需要注意的是， 序号并不是从 0 开始的， 而是由发送方随机选择的初始序列号 ( Initial Sequence Number, ISN )开始 。 由于 TCP 是一个双向通信协议， 通信双方都有能力发送信息， 并接收响应。 因此， 通信双方都需要随机产生一个初始的序列号， 并且把这个起始值告诉对方。
于是， 这个过程就变成了下面这样。
四、socket中TCP的四次握手释放连接详解
上面介绍了socket中TCP的三次握手建立过程，及其涉及的socket函数。现在我们介绍socket中的四次握手释放连接的过程，请看下图：
图2、socket中发送的TCP四次握手
图示过程如下：
-
某个应用进程首先调用close主动关闭连接，这时TCP发送一个FIN M；
-
另一端接收到FIN M之后，执行被动关闭，对这个FIN进行确认。它的接收也作为文件结束符传递给应用进程，因为FIN的接收意味着应用进程在相应的连接上再也接收不到额外数据；
-
一段时间之后，接收到文件结束符的应用进程调用close关闭它的socket。这导致它的TCP也发送一个FIN N；
-
接收到这个FIN的源发送端TCP对它进行确认。
这样每个方向上都有一个FIN和ACK。