http协议 长连接 短连接服务器,HTTP长连接短连接以及websockect

基于http协议的长连接减少了请求,减少了建立连接的时间,但是每次交互都是由客户端发起的,客户端发送消息,服务端才能返回客户端消息。因为客户端也不知道服务端什么时候会把结果准备好，所以客户端的很多请求是多余的,仅是维持一个心跳,浪费了带宽。

在长连接中一般是没有条件能够判断读写什么时候结束，所以必须要加长度报文头。读函数先是读取报文头的长度，再根据这个长度去读相应长度的报文。

WebSockect就是为了解决长连接这个缺点：

发送 http 请求后服务端如果没有返回则连接是一直连着的，等服务端有东西要“推送”给浏览器时，相当于给之前发送的这个 http 请求回了一个 http 响应。然后这个保持的时间比较长的 http 连接就断了。然后浏览器再次发送一个 http 请求，服务器端再 hold 住不返回，等待有东西需要“推送”给浏览器时，再给这个 http 请求一个响应，然后断开连接。循环往复。一旦浏览器不给服务器发送 http 请求，那么服务器是不能主动给浏览器推送消息的，因为根本没有连着的连接给你推。

WebSocket 则不同，它握手后建立的连接是不会断的(除了意外情况和程序主动掐断)。不需要浏览器在每次收到服务器推送的消息后再发起请求。而且服务器端可以随时给浏览器推送消息，不需要等浏览器发 http 请求，因为 WebSocket 的连接一直在没断。

在段时间内突然发生大量短连接？1s内5000个短连接

(客户端和服务端都可能发生)：率先发生主动关闭的一方所在的操作系统的socket端口和句柄被用尽(TIME-WAIT阶段)，系统无法再发起新的连接，解决方案是可以采用长连接(或者把TIME-WAIT的时间设置的短一点，也可以扩大端口范围)

webSocket对比轮询，长轮询，流？

轮询 ：客户端以一定的时间间隔向服务端发出请求，以频繁请求的方式来保持客户端和服务器端的同步。

缺点：当客户端以固定频率向 服务器发起请求的时候，服务器端的数据可能并没有更新，服务端在没有数据更新的时候也要返回数据，这样会带来很多无谓的网络传输，所以这是一种非常低效的实时方案。

长轮询：长轮询是对定时轮询的改进和提高，目地是为了降低无效的网络传输。当前端向后台发请求，后台数据如果还没有更新则不返回，直到后台数据更新了再返回给前端，前端收到后台返回的数据后才发下一次请求。在无消息的情况下不会频繁的请求。但是请求在后台一直悬挂，连接长时间保持，浪费资源。

这两种模式有一个共同的缺点，就是除了真正的数据部分外，服务器和客户端还要大量交换 HTTP header，信息交换效率很低。(WebSocket就能很好的解决这个问题，无论是在性能还是数据传输量的大小方面)

流 ：技术方案通常就是在客户端的页面使用一个隐藏的窗口向服务端发出一个长连接的请求。服务器端接到这个请求后作出回应并不断更新连接状态以保证客户端和服务 器端的连接不过期。通过这种机制可以将服务器端的信息源源不断地推向客户端。

缺点：这种机制在用户体验上有一点问题，需要针对不同的浏览器设计不同的方案来改进 用户体验，同时这种机制在并发比较大的情况下，对服务器端的资源是一个极大的考验。

WebSockect是什么？

HTML5开始提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议。它基于TCP传输协议，并复用HTTP的握手通道。

它相比HTTP长连接的协议？

支持双向通信，实时性更强。

更好的二进制支持。

较少的控制开销(这个很关键)。连接创建后，ws客户端、服务端进行数据交换时，协议控制的数据包头部较小。在不包含头部的情况下，服务端到客户端的包头只有2~10字节(取决于数据包长度)，客户端到服务端的的话，需要加上额外的4字节的掩码。而HTTP协议每次通信都需要携带完整的头部。

WebSockect建立连接的过程？

WebSocket复用了HTTP的握手通道。具体指的是，客户端通过HTTP请求与WebSocket服务端协商升级协议。协议升级完成后，后续的数据交换则遵照WebSocket的协议。

步骤：

1.客户端：申请协议升级

首先，客户端发起协议升级请求。可以看到，采用的是标准的HTTP报文格式，且只支持GET方法。

GET / HTTP/1.1Host: localhost:8080Origin: http://127.0.0.1:3000

Connection: Upgrade //表示要升级协议

Upgrade: websocket //表示要升级到websockect

Sec-WebSocket-Version: 13Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw==

2、服务端：响应协议升级。

服务端返回内容如下，状态代码101表示协议切换。

HTTP/1.1 101Switching Protocols

Connection:Upgrade

Upgrade: websocket

Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=

Sec-WebSocket-Key/Accept的作用

主要作用在于提供基础的防护，减少恶意连接、意外连接。

Sec-WebSocket-Key/Sec-WebSocket-Accept 的换算，只能带来基本的保障，但连接是否安全、数据是否安全、客户端/服务端是否合法的 ws客户端、ws服务端，其实并没有实际性的保证。

参考：