理解websocket连接的原理

背景

Websocket是一个持久化的协议，相对于HTTP这种非持久的无状态协议来说

---

一、问题

http long poll，或者ajax轮询都可以实现实时信息传递，为什么还需要websocket？

二、理解

ajax轮询：浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。
long poll：客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。
总结：

1. 两者都是采用轮询的方式，而long poll是阻塞式的
   ajax轮询 需要服务器有很快的处理速度和资源。（速度）
   long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）
2. 两者都体现了服务器的被动性

websocket的出现：

1. 解决了服务器的被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端。
   理解：只需要经过一次HTTP请求，就可以做到源源不断的信息传送了。（在程序设计中，这种设计叫做回调，即：你有信息了再来通知我，而不是我每次跑来问你）
2. 解决了上面同步有延迟，而且还非常消耗资源的情况
   理解：建立websocket连接后，可以直接跟接线员（Nginx服务器）建立持久连接，有信息的时候客服（Handler）想办法通知接线员，然后接线员在统一转交给客户（客户端）。
   而在传统的方式上，要不断的建立，关闭HTTP协议，由于HTTP是非状态性的，每次都要重新传输identity info（鉴别信息），来告诉服务端你是谁。
   Websocket只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。

---

总结

websocket连接，只需要一次HTTP握手，避免HTTP的无状态性，且服务器可以主动通知，不限次数，直到请求关闭。

拓展

TCP三次握手四次挥手

ACK —— 确认，使得确认号有效。
RST —— 重置连接（经常看到的reset by peer）就是此字段搞的鬼。
SYN —— 用于初如化一个连接的序列号。
FIN —— 该报文段的发送方已经结束向对方发送数据。
SYN和FIN段都是会利用重传进行可靠传输的。

理解：3次握手来建立一个连接，4次挥手来关闭一个连接
一个TCP连接由一个4元组构成，分别是两个IP地址和两个端口号。一个TCP连接通常分为三个阶段：启动、数据传输、退出（关闭）。

三次握手：

客户端和服务端通信前要进行连接，“3次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。

经历了上面的三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的。之后就可以正常通信了。

三次握手的一个重要功能是客户端和服务端交换ISN(Initial Sequence Number), 以便让对方知道接下来接收数据的时候如何按序列号组装数据。

拓展：
DoS攻击-syn flood：
恶意的向某个服务器端口发送大量的SYN包，则可以使服务器打开大量的半开连接，分配TCB（Transmission Control Block）, 从而消耗大量的服务器资源，同时也使得正常的连接请求无法被相应。
防攻击方法：连接队列

四次挥手：

TCP连接是双向传输的对等的模式，就是说双方都可以同时向对方发送或接收数据。
当有一方要关闭连接时，会发送指令告知对方，我要关闭连接了。这时对方会回一个ACK，此时一个方向的连接关闭。但是另一个方向仍然可以继续传输数据，等到发送完了所有的数据后，会发送一个FIN段来关闭此方向上的连接。接收方发送ACK确认关闭连接。注意，接收到FIN报文的一方只能回复一个ACK, 它是无法马上返回对方一个FIN报文段的，因为结束数据传输的“指令”是上层应用层给出的，我只是一个“搬运工”，我无法了解“上层的意志”。