长链接、短链接、长轮询和WebSocket

原文连接：http://caibaojian.com/http-connection-and-websocket.html

 

对这四个概念不太清楚，今天专门搜索了解一下，总结一下：

长链接：在HTTP 1.1，客户端发出请求，服务端接收请求，双方创建链接，在服务端没有返回以前保持链接，当客户端再发送请求时，它会使用同一个链接。这一直继续到客户端或服务器端认为会话已经结束，其中一方中断链接。

优点：减小了链接请求，下降TCP阻塞，减小了延迟，实时性较好。·

劣势：可能会影响性能，由于它在文件被请求以后还保持了没必要要的链接很长时间。

短链接：在HTTP1.0中，客户端发送请求，服务器接收请求，双方创建链接，服务器响应资源，请求结束。

长轮询：（我本身的理解）客户端不断发送请求，获取服务器上的数据。也有人说是长链接的一种，是这样吗？？？

WebSocket：客户端发送一次http websocket请求，服务器响应请求，双方创建持久链接，并进行双向数据传输，后面不进行HTTP链接，而是使用TCP链接。

什么是长链接、短链接？

在HTTP/1.0中默认使用短链接。也就是说，客户端和服务器每进行一次HTTP操做，就创建一次链接，任务结束就中断链接。当客户端浏览器访问的某个HTML或其余类型的web页中包含有其余的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会从新创建一个HTTP会话。

而从HTTP/1.1起，默认使用长链接，用以保持链接特性。使用长链接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive 

在使用长链接的状况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP链接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经创建的链接。Keep-Alive不会永久保持链接，它有一个保持时间，能够在不一样的服务器软件（如Apache）中设定这个时间。实现长链接须要客户端和服务端都支持长链接。

HTTP协议的长链接和短链接，实质上是TCP协议的长链接和短链接。

TCP长链接

咱们再模拟一下长链接的状况：client向server发起链接，server接受client链接，双方创建链接，client与server完成一次请求后，它们之间的链接并不会主动关闭，后续的读写操做会继续使用这个链接。

长链接和短链接的优势和缺点

由上能够看出，长链接能够省去较多的TCP创建和关闭的操做，减小浪费，节约时间。对于频繁请求资源的客户端适合使用长链接。在长链接的应用场景下，client端通常不会主动关闭链接，当client与server之间的链接一直不关闭，随着客户端链接愈来愈多，server会保持过多链接。这时候server端须要采起一些策略，如关闭一些长时间没有请求发生的链接，这样能够避免一些恶意链接致使server端服务受损；若是条件容许则能够限制每一个客户端的最大长链接数，这样能够彻底避免恶意的客户端拖垮总体后端服务。

短链接对于服务器来讲管理较为简单，存在的链接都是有用的链接，不须要额外的控制手段。但若是客户请求频繁，将在TCP的创建和关闭操做上浪费较多时间和带宽。

长链接和短链接的产生在于client和server采起的关闭策略。不一样的应用场景适合采用不一样的策略。

长轮询

长轮询自己不是一种真正的推送技术，而只是传统轮询技术的一个变种。然而，其可以在真正推送技术没法实现时模拟推送机制。

在长轮询机制中，客户端像传统轮询同样从服务器请求数据。然而，若是服务器没有能够当即返回给客户端的数据，则不会马上返回一个空结果，而是保持这个请求等待数据到来（或者恰当的超时），以后将数据做为结果返回给客户端。

例如，BOSH是一个常见的、长久的、在TCP困难或没法实现的状况下（如在使用浏览器的状况下）使用长轮询模拟TCP的技术。这也是一种XMPP中隐含的技术，苹果公司将其用于iCloud推送支持。

WebSocket介绍

WebSocket一种在单个 TCP 链接上进行全双工通信的协议。WebSocket通讯协议于2011年被IETF定为标准RFC 6455，并被RFC7936所补充规范。WebSocket API也被W3C定为标准。

WebSocket 使得客户端和服务器之间的数据交换变得更加简单，容许服务端主动向客户端推送数据。在 WebSocket API 中，浏览器和服务器只须要完成一次握手，二者之间就直接能够建立持久性的链接，并进行双向数据传输。

如今，不少网站为了实现推送技术，所用的技术都是轮询。轮询是在特定的的时间间隔（如每1秒），由浏览器对服务器发出HTTP请求，而后由服务器返回最新的数据给客户端的浏览器。这种传统的模式带来很明显的缺点，即浏览器须要不断的向服务器发出请求，然而HTTP请求可能包含较长的头部，其中真正有效的数据可能只是很小的一部分，显然这样会浪费不少的带宽等资源。

而比较新的技术去作轮询的效果是Comet。这种技术虽然能够双向通讯，但依然须要反复发出请求。并且在Comet中，广泛采用的长连接，也会消耗服务器资源。

在这种状况下，HTML5定义了WebSocket协议，能更好的节省服务器资源和带宽，而且可以更实时地进行通信。

Websocket使用ws或wss的统一资源标志符，相似于HTTPS，其中wss表示在TLS之上的Websocket。如：

//code from http://caibaojian.com/http-connection-and-websocket.html
ws://example.com/wsapi
wss://secure.example.com/

Websocket使用和 HTTP 相同的 TCP 端口，能够绕过大多数防火墙的限制。默认状况下，Websocket协议使用80端口；运行在TLS之上时，默认使用443端口。

WebSocket优势

• 较少的控制开销。在链接建立后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。在不包含扩展的状况下，对于服务器到客户端的内容，此头部大小只有2至10字节（和数据包长度有关）；对于客户端到服务器的内容，此头部还须要加上额外的4字节的掩码。相对于HTTP请求每次都要携带完整的头部，此项开销显著减小了。

• 更强的实时性。因为协议是全双工的，因此服务器能够随时主动给客户端下发数据。相对于HTTP请求须要等待客户端发起请求服务端才能响应，延迟明显更少；即便是和Comet等相似的长轮询比较，其也能在短期内更屡次地传递数据。

• 保持链接状态。于HTTP不一样的是，Websocket须要先建立链接，这就使得其成为一种有状态的协议，以后通讯时能够省略部分状态信息。而HTTP请求可能须要在每一个请求都携带状态信息（如身份认证等）。

• 更好的二进制支持。Websocket定义了二进制帧，相对HTTP，能够更轻松地处理二进制内容。

• 能够支持扩展。Websocket定义了扩展，用户能够扩展协议、实现部分自定义的子协议。如部分浏览器支持压缩等。

• 更好的压缩效果。相对于HTTP压缩，Websocket在适当的扩展支持下，能够沿用以前内容的上下文，在传递相似的数据时，能够显著地提升压缩率。

WebSocket 是独立的、建立在 TCP 上的协议。

Websocket 经过 HTTP/1.1 协议的101状态码进行握手。

为了建立Websocket链接，须要经过浏览器发出请求，以后服务器进行回应，这个过程一般称为“握手”（handshaking）。

WebSocket例子

一个典型的Websocket握手请求以下：

客户端请求

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
Sec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==
Sec-WebSocket-Version: 13

服务器回应

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=
Sec-WebSocket-Location: ws://example.com/

附录知乎一个解释：

做者：异步
连接：https://www.zhihu.com/question/19876749/answer/16448614
来源：知乎

1. 轮询：客户端定时向服务器发送ajax请求，服务器接到请求后立刻返回响应信息并关闭链接。
   优势：后端程序编写比较容易。
   缺点：请求中有大半是无用，浪费带宽和服务器资源。
   实例：适于小型应用。
2. 长轮询：客户端向服务器发送Ajax请求，服务器接到请求后hold住链接，直到有新消息才返回响应信息并关闭链接，客户端处理完响应信息后再向服务器发送新的请求。
   优势：在无消息的状况下不会频繁的请求。
   缺点：服务器hold链接会消耗资源。
   实例：WebQQ、Hi网页版、Facebook IM。

另外，对于长链接和socket链接也有区分：

1. 长链接：在页面里嵌入一个隐蔵iframe，将这个隐蔵iframe的src属性设为对一个长链接的请求，服务器端就能源源不断地往客户端输入数据。
   优势：消息即时到达，不发无用请求。
   缺点：服务器维护一个长链接会增长开销。
   实例：Gmail聊天
2. Flash Socket：在页面中内嵌入一个使用了Socket类的 Flash 程序JavaScript经过调用此Flash程序提供的Socket接口与服务器端的Socket接口进行通讯，JavaScript在收到服务器端传送的信息后控制页面的显示。 优势：实现真正的即时通讯，而不是伪即时。 缺点：客户端必须安装Flash插件；非HTTP协议，没法自动穿越防火墙。 实例：网络互动游戏。