HTTP长链接短链接以及websockect

HTTP协议与TCP/IP协议的关系

TCP/IP是个协议组，可分为三个层次：网络层、传输层和应用层。

在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。

在传输层中有TCP协议与UDP协议。

在应用层有:TCP包括FTP、HTTP、TELNET、SMTP等协议；UDP包括DNS、TFTP等协议。

HTTP的长链接和短链接本质上是TCP长链接和短链接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。

IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠的传递数据包，使在网络上的另外一端收到发端发出的全部包，而且顺序与发出顺序一致。TCP有 可靠，面向链接的特色。

 

HTTP协议中的长短链接？

http1.0协议里面默认短链接，须要在request里面增长Connection：keep-alive

http1.1协议里面默认长链接

 

短链接的操做步骤是：
创建链接——数据传输——关闭链接…创建链接——数据传输——关闭链接
长链接的操做步骤是：
创建链接——数据传输…（保持链接）…数据传输——关闭链接

http长链接缺点：

基于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长链接的协议？

1. 支持双向通讯，实时性更强。
2. 更好的二进制支持。
3. 较少的控制开销（这个很关键）。链接建立后，ws客户端、服务端进行数据交换时，协议控制的数据包头部较小。在不包含头部的状况下，服务端到客户端的包头只有2~10字节（取决于数据包长度），客户端到服务端的的话，须要加上额外的4字节的掩码。而HTTP协议每次通讯都须要携带完整的头部。

WebSockect创建链接的过程？

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

步骤：

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

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

GET / HTTP/1.1 Host: localhost:8080 Origin: http://127.0.0.1:3000
Connection: Upgrade //表示要升级协议 Upgrade: websocket //表示要升级到websockect Sec-WebSocket-Version: 13 Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw==

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

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

HTTP/1.1 101 Switching Protocols Connection:Upgrade Upgrade: websocket Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=

 

Sec-WebSocket-Key/Accept的做用

主要做用在于提供基础的防御，减小恶意链接、意外链接。

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

 

参考：

https://www.cnblogs.com/chyingp/p/websocket-deep-in.html