WebSocket的动机是什么？
目前的Web通信使用的是HTTP协议，HTTP协议是基于TCP协议的应用层协议，HTTP协议的工作模式是request/response模式。在一次通信中，必须首先由client向server发起TCP连接，然后server接受该TCP连接请求，在TCP连接建立之后，首先由client发起HTTP request，然后server再发出HTTP response。
因此，在这种标准HTTP工作模式的约定下，server是不被允许发起一个TCP请求的，因此也就不被允许在未收到HTTP request的情况下，发送一个HTTP response给client。在这种约束下，为了能够不断的随时从server发送内容到client端，就必须保证server端随时都有一个待响应的request（注意这与persistent connection不是同一个概念，persistent connection是用来复用HTTP之下的TCP连接）。
如何在现有的HTTP框架内，来获得这么一个时刻存在于server端的待响应请求呢？这就是COMET技术，具体说有2种方式：
- 多个HTTP请求不断接力（long polling）
- 单个HTTP请求不终止 （HTTP streaming）
但是，如果我们回过头来仔细想一下HTTP协议的细节，HTTP其实是建立在TCP之上的，所以当我们在进行HTTP通信时，client和server之间已经建立起了一个TCP连接，而任何TCP连接（从程序员角度来说，就是一个Berkeley socket）都是可以用来双向通信的，那么为什么不直接利用这个现成的TCP连接来实现client和server的双向通信呢？
没错！这就是WebSocket所做的事情！
WebSocket连接如何建立
我们建立WebSocket通信的过程是这样的：
- Step 1 建立TCP连接（这一步是一切的基础，和HTTP一样）
- Step 2 通过TCP连接，发送HTTP Get 请求，其中包含关键的Upgrade: websocket header。
- Step 3 Server收到HTTP请求后，会把Step 1的TCP连接的用户层协议从HTTP转变为WebSocket。至此，HTTP部分就退出舞台了，WebSocket开始接管一切。
如何理解WebSocket可以和HTTP共享80端口？
准确的说，应该是WebSocket可以分享HTTP正在使用的端口，不一定是80。原因是WebSocket的initial handshake是一个valid HTTP request，所以除非我们自己重写一套解析HTTP handshake的逻辑，否则必须发送到现有的HTTP端口来解析。而仅仅发送到HTTP端口还是不够的，我们还需要在server实现中添加关于WebSocket的逻辑。然后，server根据HTTP协议解析了initial handshake request之后，由server来进行协议切换，把HTTP换成WebSocket。
所以，这里可以看出，HTTP协议自己并不需要了解WebSocket什么，也不需要知道它何时应该让位于WebSocket协议，HTTP协议只是规定了HTTP的通信格式（比如WebSocket所使用的custom header），是server根据HTTP协议规定的格式，发觉了WebSocket的连接请求，然后再进行协议切换，server是协议切换逻辑的载体和执行者，当我们要实现一个WebSocket server，就必须在server代码中加入以下逻辑：
- 识别HTTP格式的WebSocket 请求
- 协议切换
- WebSocket的协议模块
参考
- http://stackoverflow.com/questions/28516962/how-websocket-server-handles-multiple-incoming-connection-requests
- RFC6455 – WebSocket Protocol
- RFC6202 – Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
- WebSockets – Stable and Ready for Developers: https://msdn.microsoft.com/en-us/hh969243.aspx
- Comet: Low Latency Data for the Browser: http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/