长链接、短链接、长轮询、短轮询、WebSocket释疑

看到一篇不错的文章，特地转载过来，原文地址： 长链接、短链接、长轮询、短轮询、WebSocket

1、短链接和长链接

短链接：每次Http请求都会创建Tcp链接，管理容易

长链接：只须要创建一次Tcp链接，之后Http请求重复使用同一个Tcp链接，管理难

HTTP1.1规定了默认保持长链接（HTTP persistent connection ，也有翻译为持久链接），数据传输完成了保持TCP链接不断开（不发RST包、不四次挥手），等待在同域名下继续用这个通道传输数据；相反的就是短链接
若是服务器没有告诉客户端超时时间也不要紧，服务端可能主动发起四次挥手断开TCP链接，客户端可以知道该TCP链接已经无效；另外TCP还有心跳包来检测当前链接是否还活着，方法不少，避免浪费资源。

在长链接的应用场景下，client端通常不会主动关闭它们之间的链接，Client与server之间的链接若是一直不关闭的话，会存在一个问题，随着客户端链接愈来愈多，server迟早有扛不住的时候，这时候server端须要采起一些策略，如关闭一些长时间没有读写事件发生的链接，这样能够避免一些恶意链接致使server端服务受损；若是条件再容许就能够以客户端机器为颗粒度，限制每一个客户端的最大长链接数，这样能够彻底避免某个蛋疼的客户端连累后端服务。

长链接和短链接的产生在于client和server采起的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择

应用场景区别：

通常长链接（追求实时性高的场景）用于少数client-end to server-end的频繁的通讯，例如：数据库的链接用长链接， 若是用短链接频繁的通讯会形成socket错误，并且频繁的socket 建立也是对资源的浪费。
而像WEB网站的http服务通常都用短连接（追求资源易回收场景），由于长链接对于服务端来讲会耗费必定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的链接用短链接会更省一些资源。

2、短轮询和长轮询

和短链接和长链接有本质区别。长、短链接是客户端与服务端创建和保持TCP链接的机制；而长、短轮询是指客户端请求服务端，服务端给予应答的方式。

短轮询：重复发送Http请求，查询目标事件是否完成，优势：编写简单，缺点：浪费带宽和服务器资源

长轮询：在服务端hold住Http请求（死循环或者sleep等等方式），等到目标时间发生(保持这个请求等待数据到来或者恰当的超时)，返回Http响应。优势：在无消息的状况下不会频繁的请求，缺点：编写复杂

3、WebSocket

WebSocket和HTTP长链接区别

• HTTP1.1经过使用Connection:keep-alive进行长链接，HTTP 1.1默认进行持久链接。在一次 TCP 链接中能够完成多个 HTTP 请求，可是对每一个请求仍然要单独发 header，Keep-Alive不会永久保持链接，它有一个保持时间，能够在不一样的服务器软件（如Apache）中设定这个时间。
• websocket的长链接，是一个真的全双工，第一次tcp链路创建以后，后续数据能够双方都进行发送，不须要发送请求头，而且这个链接会持续存在直到客户端或者服务器端的某一方主动关闭链接，与HTTP长链接不一样，WebSocket能够更灵活的控制链接关闭的时机，而不是HTTP协议的Keep-Alive一到，服务端立马就关闭（这样很不人性化）。

WebSocket链接创建

创建WebSocket链接时，须要经过客户端或者浏览器发出握手请求，请求消息示例如图：

服务端返回给客户端的应答消息如图：

为了创建一个WebSocket链接，客户端浏览器首先要向服务器发起一个HTTP请求，这个请求和一般的HTTP请求不一样，包含了一些附加头信息，其中附加头信息“Upgrade: WebSocket”代表这是一个申请协议升级的HTTP请求。服务器端解析这些附加的头信息，而后生成应答信息返回给客户端，客户端和服务器端的WebSocket链接就创建起来了，双方能够经过这个链接通道自由地传递信息，而且这个链接会持续存在直到客户端或者服务器端的某一方主动关闭链接。

请求消息中的“Sec-WebSocket-Key”是随机的，服务器端会用这些数据来构造出一个SHA-1的信息摘要，把“Sec-WebSocket-Key”加上一个魔幻字符串“258EAFA5-E914- 47DA-95CA-C5AB0DC85B11”。使用SHA-1加密，而后进行BASE-64编码，将结果作为“Sec-WebSocket-Accept”头的值，返回给客户端。

---

注：本文为转载，原文地址：长链接、短链接、长轮询、短轮询、WebSocket