【网络】http、socket、长连接、长轮询

本文仅仅作为查阅手册和学习方向指导，请酌情参考

一、网络基础知识

请求头与响应头

1）请求头

该部分大致看一眼然后往看下，当作参考手册

请求头一般有下面内容：

• Request URL：请求url
• Request Method：请求方式，如GET
• accept：本次请求接收上面返回格式，如text/html,application/xml;image/avif,image/webp,image/apng。这个东西在Spring MVC里可以用于内容协商
• ache-control：常见值为no-cache(不允许缓存), no-store(无论请求还是响应均不允许缓存), max-age(规定可以客户端可以接受多长生命期的数据)
• cookie：表示用户信息的cookie
• Keep-Alive: 使得服务端和客户端的链接长时间有效
• accept-language
• accept-encoding
• user-agent：浏览器的版本信息
• Host: 请求资源的主机IP和端口号
• Range: 请求资源的某一部分
• User-Agent: 发出请求的用户的信息(鉴权)

2）响应头

• content-type:根据请求头里的accept最后协商返回的数据格式，如 text/html; charset=utf-8
• expires: 0
• set-cookie: 要给浏览器里放到cooke信息。如KLBRSID=9d75f8; Path=/
• cache-control
• content-encoding: gzip

HTTP发展史

• HTTP/0.9：1991年发布，极其简单，只有一个get命令；
• HTTP/1.0：1996年5月发布，增加了大量内容；
• HTTP/1.1：1997年1月发布，进一步完善HTTP协议，是目前最流行的版本；
• SPDY ：2009年谷歌发布SPDY协议，主要解决HTTP/1.1效率不高的问题；
• HTTP/2 ：2015年借鉴SPDY的HTTP/2发布。

1）HTTP 1.1

host、请求方式、长连接

HTTP 1.1中也有长连接，那么websocket和HTTP 1.1的长连接是有什么区别呢？

既然说到了这，那先介绍下HTTP 1.1和HTTP吧

HTTP新增的内容：

• 缓存策略：Cache-Control、Etag/If-None-Match等。

• 分块传输：可以通过在请求头处设置range头域，就可以返回请求资源的某一部分（断点续传）,也就是返回码为206(Partial Content)的时候，这对于性能优化很有必要

  • 断点续传不只是指大文件接着传输。例如用户下载大文件时，可以将大文件分割成几部分，每个部分一个进程传输
  • 请求头：Range: bytes=0-801 // 一般请求下载整个文件是bytes=0- 或不用这个头
  • 响应头：Content-Range: bytes 0-800/801 //801:文件总大小

• 新增24个错误码：

  • 409(Conflict)表示: 请求的资源与当前的状态发生冲突
  • 410(Gone)表示服务器上某个资源被永久性的删除了

• host头处理：HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。有了Host字段，就可以将请求发往同一台服务器上的不同网站，为虚拟主机的兴起打下了基础。

  • http1.0中默认每台服务器都绑定唯一的一个IP地址，所以请求消息中url并没有传递主机名，也就是hostName.
  • http1.1中请求消息和响应消息都支持Host头域，而且，如果我们不传这个字段还会报一个400(bad request)的状态码
  • 请求头：
    • Cache-Control: 缓存头域 => 常见值为
      • no-cache(不允许缓存), no-store(无论请求还是响应均不允许缓存), max-age(规定可以客户端可以接受多长生命期的数据)
    • Keep-Alive: 使得服务端和客户端的链接长时间有效
    • Date: 信息发送的时间
    • Host: 请求资源的主机IP和端口号
    • Range: 请求资源的某一部分
    • User-Agent: 发出请求的用户的信息(鉴权)

• 请求方法：

  • HTTP1.0定义了三种请求方法：GET，POST和HEAD方法。
  • HTTP1.1新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE和CONNECT方法。

• 长连接：传统的短链接一次握手之后只请求-响应一次，而长连接握手后可以请求响应多次

  • Connection: keep-alive
  • 客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。

• 管道机制：HTTP/1.1中引入了管道机制（pipelining）,即在同一个TCP连接中，客户端可以同时发送多个请求。

HTTP1.1 的缺陷

• 高延迟 — 队头阻塞(Head-Of-Line Blocking)：队头阻塞是指当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。
  • 浏览器对于同一个域名，同时只能有 6个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。这也是为何一些站点会有多个静态资源 CDN 域名的原因之一。
  • HTTP/1.1 的持久连接和管道机制允许复用TCP连接，在一个TCP连接中，也可以同时发送多个请求，但是所有的数据通信都是按次序完成的，服务器只有处理完一个回应，才会处理下一个回应。比如客户端需要A、B两个资源，管道机制允许浏览器同时发出A请求和B请求，但服务器还是按照顺序，先回应A请求，完成后再回应B请求，这样如果前面的回应特别慢，后面就会有很多请求排队等着，这称为“队头阻塞（Head-of-line blocking）”
• 无状态特性 — 阻碍交互
• 明文传输 — 不安全性
• 不支持服务端推送

2）HTTP 2

HTTP/2协议只在HTTPS环境下才有效，升级到HTTP/2，必须先启用HTTPS

• 二进制分帧：HTTP/1.1的头信息是文本（ASCII编码），数据体可以是文本，也可以是二进制；HTTP/2 头信息和数据体都是二进制，统称为“帧”：头信息帧和数据帧；
• 多路复用(Mutiplexing) : 通过单一的 HTTP/2 连接发起多重的请求-响应消息，即在一个连接里，客户端和浏览器都可以同时发送多个请求和响应，而不用按照顺序一一对应，这样避免了“队头堵塞”。HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。
• header压缩: HTTP 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。HTTP/2 对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息压缩后再发送（SPDY 使用的是通用的DEFLATE 算法，而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法）。；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
• 服务端推送(server push)：HTTP/2 允许服务器未经请求，主动向客户端发送资源。常见场景是客户端请求一个网页，这个网页里面包含很多静态资源。正常情况下，客户端必须收到网页后，解析HTML源码，发现有静态资源，再发出静态资源请求。其实，服务器可以预期到客户端请求网页后，很可能会再请求静态资源，所以就主动把这些静态资源随着网页一起发给客户端了。

HTTP2

HTTPS可以说是安全版的HTTP，HTTPS基于安全SSL/TLS（安全套接层Secure Sockets Layer/安全传输层Transport Layer Security）层，即在传统的HTTP和TCP之间加了一层用于加密解密的SSL/TLS层。HTTP默认使用80端口，HTTPS默认使用443端口。

不使用SSL/TLS的HTTP通信，所有信息明文传播，会带来三大风险：

• 窃听风险：第三方可以获取通信内容；
• 篡改风险：第三方可以修改通信内容；
• 冒充风险：第三方可以冒充他人进行通信。

SSL/TLS协议是为了解决这三大风险而设计的，以期达到：

• 信息加密传输：第三方无法窃听；
• 校验机制：一旦被篡改，通信双方会立刻发现；
• 身份证书：防止身份被冒充。

SSL/TLS的基本思路是公钥加密法：客户端先向服务器索要并验证公钥，然后用公钥加密传输来协商生成“对话秘钥”（非对称加密），双方采用“对话秘钥”进行加密通信（对称加密）。

通信过程如下：

• \1. 客户端发出请求：给出支持的协议版本、支持的加密方法（如RSA公钥加密）以及一个客户端生成的随机数（Client random）；
• \2. 服务端回应：确认双方通信的协议版本、加密方法，并给出服务器证书以及一个服务器生成的随机数（Server random）；
• \3. 客户端回应：客户端确认证书有效，取出证书中的公钥，然后生成一个新的随机数（Premaster secret），使用公钥加密这个随机数，发送给服务端；
• \4. 服务端回应：服务端使用自己的私钥解密客户端发来的随机数（Premaster secret），客户端和服务端根据约定的加密方法，使用三个随机数，生成“对话秘钥”；
• \5. 会话通信：客户端和服务端使用“对话秘钥”加密通信，这个过程完全使用普通的HTTP协议，只不过用“会话秘钥”加密内容。

前四步称为握手阶段，用于客户端和服务端建立连接和交换参数。整个通信过程可用下图所示：

websocket和http的长连接

在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。但是请记住 Request = Response ， 在HTTP中永远是这样，也就是说一个request只能有一个response。而且只有从客户端发起request，服务端才能响应response，不能主动发起。

HTTP协议与其他协议

要使用HTTP协议就少不了其他的协议的辅助。

• TCP
• DNS：域名解析协议

一、长连接/短连接

Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。

• HTTP连接：http连接就是所谓的短连接，即客户端向服务器端发送一次请求，服务器端响应后连接即会断掉；
• socket连接：socket连接就是所谓的长连接，理论上客户端和服务器端一旦建立起连接将不会主动断掉；但是由于各种环境因素可能会是连接断开，比如说：服务器端或客户端主机down了，网络故障，或者两者之间长时间没有数据传输，网络防火墙可能会断开该连接以释放网络资源。所以当一个socket连接中没有数据的传输，那么为了维持连接需要发送心跳消息~~具体心跳消息格式是开发者自己定义的

①TCP连接

要想明白Socket连接，先要明白TCP连接。手机能够使用联网功能是因为手机底层实现了TCP/IP协议，可以使手机终端通过无线网络建立TCP连接。TCP协议可以对上层网络提供接口，使上层网络数据的传输建立在“无差别”的网络之上。

建立起一个TCP连接需要经过“三次握手”：

• 第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态(客户端)，等待服务器确认；
• 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
• 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”（过程就不细写了，就是服务器和客户端交互，最终确定断开）

②HTTP连接

HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

• 1）在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。
• 2）在HTTP 1.1中，可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。尽管HTTP1.1开始支持持久连接，但仍无法保证始终连接。而Socket连接一旦建立TCP三次握手，除非一方主动断开，否则连接状态一直保持。

由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。

一个socket里发送了多个http请求，每个http请求会判断请求头里的connection是否close，是的话处理完关闭socket。

如果是connection:keep-alive，则不会断开。另外tomcat里也有限制同时能同时存在几个活跃的socket，还有一个socket可以处理几个http请求。

socket的概念

套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议、本地主机的IP地址、本地进程的协议端口、远地主机的IP地址、远地进程的协议端口。

现在我们了解到TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。就像操作系统会提供标准的编程接口，比如Win32编程接口一样，TCP/IP也必须对外提供编程接口，这就是Socket。现在我们知道，Socket跟TCP/IP并没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以，Socket的出现只是可以更方便的使用TCP/IP协议栈而已，其对TCP/IP进行了抽象，形成了几个最基本的函数接口。比如create，listen，accept，connect，read和write等等，不同语言都有对应的建立Socket服务端和客户端的库。

长连接：指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接(心跳包)，一般需要自己做在线维持。

短连接：是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接。

比如Http的，只是连接、请求、关闭，过程时间较短,服务器若是一段时间内没有收到请求即可关闭连接。其实长连接是相对于通常的短连接而说的，也就是长时间保持客户端与服务端的连接状态。

• 通常的短连接操作步骤是：连接→数据传输→关闭连接；
• 而长连接通常就是：连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接；

什么时候用长连接，短连接：

• 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理 速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成Socket错误，而且频繁的Socket创建也是对资源的浪费。

HTTP连接与Socket连接的区别：

• HTTP是短连接，Socket(基于TCP协议的)是长连接。尽管HTTP1.1开始支持持久连接，但仍无法保证始终连接。而Socket连接一旦建立TCP三次握手，除非一方主动断开，否则连接状态一直保持。
• HTTP连接服务端无法主动发消息，Socket连接双方请求的发送先后限制。这点就比较重要了，因为它将决定二者分别适合应用在什么场景下。HTTP采用“请求-响应”机制，在客户端还没发送消息给服务端前，服务端无法推送消息给客户端。必须满足客户端发送消息在前，服务端回复在后。Socket连接双方类似peer2peer的关系，一方随时可以向另一方喊话。

3.2 建立socket连接

建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket，另一个运行于服务器端，称为ServerSocket。

套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。

• 服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。
• 客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
• 连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。

*4、SOCKET连接与TCP连接*

创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接（可以对应多个）。

*5、Socket连接与HTTP连接*

由于通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。

而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数据传送给客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求，不仅可以保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。

socket
我们知道两个进程如果需要进行通讯最基本的一个前提能能够唯一的标示一个进程，在本地进程通讯中我们可以使用PID来唯一标示一个进程，但PID只在本地唯一，网络中的两个进程PID冲突几率很大，这时候我们需要另辟它径了，我们知道IP层的ip地址可以唯一标示主机，而TCP层协议和端口号可以唯一标示主机的一个进程，这样我们可以利用ip地址+协议+端口号唯一标示网络中的一个进程。

能够唯一标示网络中的进程后，它们就可以利用socket进行通信了，什么是socket呢？我们经常把socket翻译为套接字，socket是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用已实现进程在网络中通信。

socket起源于UNIX，在Unix一切皆文件哲学的思想下，socket是一种”打开—读/写—关闭”模式的实现，服务器和客户端各自维护一个”文件”，在建立连接打开后，可以向自己文件写入内容供对方读取或者读取对方内容，通讯结束时关闭文件。

socket通信流程：

socket是”打开—读/写—关闭”模式的实现，以使用TCP协议通讯的socket为例，其交互流程大概是这样子的

• 服务器根据地址类型（ipv4,ipv6）、socket类型、协议创建socket
• 服务器为socket绑定ip地址和端口号
• 服务器socket监听端口号请求，随时准备接收客户端发来的连接，这时候服务器的socket并没有被打开
• 客户端创建socket
• 客户端打开socket，根据服务器ip地址和端口号试图连接服务器socket
• 服务器socket接收到客户端socket请求，被动打开，开始接收客户端请求，直到客户端返回连接信息。这时候socket进入阻塞状态，所谓阻塞即accept()方法一直到客户端返回连接信息后才返回，开始接收下一个客户端谅解请求
• 客户端连接成功，向服务器发送连接状态信息
• 服务器accept方法返回，连接成功
• 客户端向socket写入信息
• 服务器读取信息
• 客户端关闭
• 服务器端关闭

浏览器对同一 Host 建立 TCP 连接到数量有没有限制？

假设我们还处在 HTTP/1.1 时代，那个时候没有多路传输，当浏览器拿到一个有几十张图片的网页该怎么办呢？肯定不能只开一个 TCP 连接顺序下载，那样用户肯定等的很难受，但是如果每个图片都开一个 TCP 连接发 HTTP 请求，那电脑或者服务器都可能受不了，要是有 1000 张图片的话总不能开 1000 个TCP 连接吧，你的电脑同意 NAT 也不一定会同意。

所以答案是：有。Chrome最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别。

收到的 HTML 如果包含几十个图片标签，这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？

如果图片都是 HTTPS 连接并且在同一个域名下，那么浏览器在 SSL 握手之后会和服务器商量能不能用 HTTP2，如果能的话就使用Multiplexing 功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个 TCP 连接去获取，但是可以确定的是 Multiplexing 很可能会被用到。

如果发现用不了 HTTP2 呢？或者用不了 HTTPS（现实中的 HTTP2 都是在 HTTPS 上实现的，所以也就是只能使用 HTTP/1.1）。那浏览器就会在一个 HOST 上建立多个 TCP 连接，连接数量的最大限制取决于浏览器设置，这些连接会在空闲的时候被浏览器用来发送新的请求，如果所有的连接都正在发送请求呢？那其他的请求就只能等等了

**轮询：**客户端定时向服务器发送Ajax请求，服务器接到请求后马上返回响应信息并关闭连接。
优点：后端程序编写比较容易。
缺点：请求中有大半是无用，浪费带宽和服务器资源。
实例：适于小型应用。

**长轮询：**客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求。
优点：在无消息的情况下不会频繁的请求，耗费资源小。
缺点：服务器hold连接会消耗资源，返回数据顺序无保证，难于管理维护。
实例：WebQQ、Hi网页版、Facebook IM。

**长连接：**在页面里嵌入一个隐蔵iframe，将这个隐蔵iframe的src属性设为对一个长连接的请求或是采用xhr请求，服务器端就能源源不断地往客户端输入数据。
优点：消息即时到达，不发无用请求；管理起来也相对方便。
缺点：服务器维护一个长连接会增加开销。
实例：Gmail聊天

**Flash Socket：**在页面中内嵌入一个使用了Socket类的 Flash 程序JavaScript通过调用此Flash程序提供的Socket接口与服务器端的Socket接口进行通信，JavaScript在收到服务器端传送的信息后控制页面的显示。
优点：实现真正的即时通信，而不是伪即时。
缺点：客户端必须安装Flash插件；非HTTP协议，无法自动穿越防火墙。
实例：网络互动游戏。

长轮询

Web客户端与服务器之间基于Ajax（http）的常用通信方式，分为短连接与长轮询。

• 短连接：客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。
• 在长轮询机制中，客户端像传统轮询一样从服务器请求数据。然而，如果服务器没有可以立即返回给客户端的数据，则不会立刻返回一个空结果，而是保持这个请求等待数据到来（或者恰当的超时：小于ajax的超时时间），之后将数据作为结果返回给客户端。

长轮询机制如下图所示：

\1. 轮询的建立
建立轮询的过程很简单，浏览器发起请求后进入循环等待状态，此时由于服务器还未做出应答，所以HTTP也一直处于连接状态中。
\2. 数据的推送
在循环过程中，服务器程序对数据变动进行监控，如发现更新，将该信息输出给浏览器，随即断开连接，完成应答过程，实现“服务器推”。
\3. 轮询的终止
轮询可能在以下3种情况时终止：
3.1. 有新数据推送
当循环过程中服务器向浏览器推送信息后，应该主动结束程序运行从而让连接断开，这样浏览器才能及时收到数据。
3.2. 没有新数据推送
循环不能一直持续下去，应该设定一个最长时限，避免WEB服务器超时（Timeout），若一直没有新信息，服务器应主动向浏览器发送本次轮询无新信息的正常响应，并断开连接，这也被称为“心跳”信息。
3.3. 网络故障或异常
由于网络故障等因素造成的请求超时或出错也可能导致轮询的意外中断，此时浏览器将收到错误信息。
\4. 轮询的重建
浏览器收到回复并进行相应处理后，应马上重新发起请求，开始一个新的轮询周期。

长轮询应用场景

apollo
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZaEHFgWY-1631377730926)(https://segmentfault.com/img/remote/1460000024430532)]

有了1s的长连接，为什么还要5s一次的短连接，防止1s长连接的期间，服务器push功能失效，相当于是一个备用机制。

rocketmq也是一样，客户端和服务器建立长连接(也是短时间内的保活长连接)，在每次的长连接期间，服务器如果有数据就主动写数据到客户端。

总结

除了长轮询机制一样，还有注册中心也是一样，apollo和rocketmq都使用了注册中心，其实所有的中间件基本上都是这样，如果要集群(一般多主多从)，就要搞注册中心。

好处

push模型的好处是实时写新的数据到客户端。pull模型的好处是请求/响应模式，完成之后就断开，而不是像push模型一样，一直长连接不断开，如果每个连接都不断开，那么服务器连接数量很快会被耗尽。

长轮询的好处是，既有push模型的服务器实时写数据到客户端，又有pull模型的避免一直长连接。

web客户端代码如下：

//向后台长轮询消息
function longPolling(){
    $.ajax({
        async : true,//异步
        url : 'longPollingAction!getMessages.action', 
        type : 'post',
        dataType : 'json',
        data :{},
        timeout : 30000,//超时时间设定30秒
        error : function(xhr, textStatus, thrownError) {
            longPolling();//发生异常错误后再次发起请求
        },
        success : function(response) {
            message = response.data.message;
            if(message!="timeout"){
                broadcast();//收到消息后发布消息
            }
            longPolling();
        }
    });
}

web服务器端代码如下：

public class LongPollingAction extends BaseAction {
    private static final long serialVersionUID = 1L;
    private LongPollingService longPollingService;
    private static final long TIMEOUT = 20000;// 超时时间设置为20秒

    public String getMessages() {
        long requestTime = System.currentTimeMillis();
        result.clear();
        try {
            String msg = null;

            while ((System.currentTimeMillis() - requestTime) < TIMEOUT) {
                msg = longPollingService.getMessages();
                if (msg != null) {
                    break; // 跳出循环，返回数据
                } else {
                    Thread.sleep(1000);// 休眠1秒
                }
            }
            if (msg == null) {
                result.addData("message", "timeout");// 超时
            } else {
                result.addData("message", msg);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }

        return SUCCESS;
    }

    public LongPollingService getLongPollingService() {
        return longPollingService;
    }

    public void setLongPollingService(LongPollingService longPollingService) {
        this.longPollingService = longPollingService;
    }

}

五、程序设计

1、普通轮询 Ajax方式

客户端代码片段

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8" isELIgnored="false" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
    <head>
        <meta http-equiv="pragma" content="no-cache">
        <meta http-equiv="cache-control" content="no-cache">
        <meta http-equiv="author" content="hoojo & http://hoojo.cnblogs.com">
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <%@ include file="/tags/jquery-lib.jsp"%>
 
        <script type="text/javascript">
            $(function () {
 
                window.setInterval(function () {
 
                    $.get("${pageContext.request.contextPath}/communication/user/ajax.mvc", 
                        {"timed": new Date().getTime()}, 
                        function (data) {
                            $("#logs").append("[data: " + data + " ]<br/>");
                    });
                }, 3000);
 
            });
        </script>
    </head>
 
    <body>
        <div id="logs"></div>
    </body>
</html>

客户端实现的就是用一种普通轮询的结果，比较简单。利用setInterval不间断的刷新来获取服务器的资源，这种方式的优点就是简单、及时。缺点是链接多数是无效重复的；响应的结果没有顺序（因为是异步请求，当发送的请求没有返回结果的时候，后面的请求又被发送。而此时如果后面的请求比前面的请求要先返回结果，那么当前面的请求返回结果数据时已经是过时无效的数据了）；请求多，难于维护、浪费服务器和网络资源。

服务器端代码

@RequestMapping("/ajax")
public void ajax(long timed, HttpServletResponse response) throws Exception {
    PrintWriter writer = response.getWriter();

    Random rand = new Random();
    // 死循环 查询有无数据变化
    while (true) {
        Thread.sleep(300); // 休眠300毫秒，模拟处理业务等
        int i = rand.nextInt(100); // 产生一个0-100之间的随机数
        if (i > 20 && i < 56) { // 如果随机数在20-56之间就视为有效数据，模拟数据发生变化
            long responseTime = System.currentTimeMillis();
            // 返回数据信息，请求时间、返回数据时间、耗时
            writer.print("result: " + i + ", response time: " + responseTime + ", request time: " + timed + ", use time: " + (responseTime - timed));
            break; // 跳出循环，返回数据
        } else { // 模拟没有数据变化，将休眠 hold住连接
            Thread.sleep(1300);
        }
    }

}

服务器端实现，这里就模拟下程序监控数据的变化。上面代码属于SpringMVC 中controller中的一个方法，相当于Servlet中的一个doPost/doGet方法。如果没有程序环境适应servlet即可，将方法体中的代码copy到servlet的doGet/doPost中即可。

服务器端在进行长连接的程序设计时，要注意以下几点：
\1. 服务器程序对轮询的可控性
由于轮询是用死循环的方式实现的，所以在算法上要保证程序对何时退出循环有完全的控制能力，避免进入死循环而耗尽服务器资源。
2. 合理选择“心跳”频率
从图1可以看出，长连接必须由客户端不停地进行请求来维持，所以在客户端和服务器间保持正常的“心跳”至为关键，参数POLLING_LIFE应小于WEB服务器的超时时间，一般建议在10～20秒左右。
3. 网络因素的影响
在实际应用时，从服务器做出应答，到下一次循环的建立，是有时间延迟的，延迟时间的长短受网络传输等多种因素影响，在这段时间内，长连接处于暂时断开的空档，如果恰好有数据在这段时间内发生变动，服务器是无法立即进行推送的，所以，在算法设计上要注意解决由于延迟可能造成的数据丢失问题。
4. 服务器的性能
在长连接应用中，服务器与每个客户端实例都保持一个持久的连接，这将消耗大量服务器资源，特别是在一些大型应用系统中更是如此，大量并发的长连接有可能导致新的请求被阻塞甚至系统崩溃，所以，在进行程序设计时应特别注意算法的优化和改进，必要时还需要考虑服务器的负载均衡和集群技术。

上图是返回的结果，可以看到先发出请求，不一定会最先返回结果。这样就不能保证顺序，造成脏数据或无用的连接请求。可见对服务器或网络的资源浪费。

2、普通轮询 iframe方式

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8" isELIgnored="false" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
    <head>
        <meta http-equiv="pragma" content="no-cache">
        <meta http-equiv="cache-control" content="no-cache">
        <meta http-equiv="expires" content="0">
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <%@ include file="/tags/jquery-lib.jsp"%>
 
        <script type="text/javascript">
            $(function () {
 
                window.setInterval(function () {
                    $("#logs").append("[data: " + $($("#frame").get(0).contentDocument).find("body").text() + " ]<br/>");
                    $("#frame").attr("src", "${pageContext.request.contextPath}/communication/user/ajax.mvc?timed=" + new Date().getTime());
                    // 延迟1秒再重新请求
                    window.setTimeout(function () {
                        window.frames["polling"].location.reload();
                    }, 1000);
                }, 5000);
 
            });
        </script>
    </head>
 
    <body>
        <iframe id="frame" name="polling" style="display: none;"></iframe>
        <div id="logs"></div>
    </body>
</html>

这里的客户端程序是利用隐藏的iframe向服务器端不停的拉取数据，将iframe获取后的数据填充到页面中即可。同ajax实现的基本原理一样，唯一不同的是当一个请求没有响应返回数据的情况下，下一个请求也将开始，这时候前面的请求将被停止。如果要使程序和上面的ajax请求一样也可以办到，那就是给每个请求分配一个独立的iframe即可。下面是返回的结果：

其中红色是没有成功返回请求就被停止（后面请求开始）掉的请求，黑色是成功返回数据的请求。

3、长连接iframe方式

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8" isELIgnored="false" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
    <head>
        <meta http-equiv="pragma" content="no-cache">
        <meta http-equiv="cache-control" content="no-cache">
        <meta http-equiv="author" content="hoojo & http://hoojo.cnblogs.com">
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <%@ include file="/tags/jquery-lib.jsp"%>
 
        <script type="text/javascript">
            $(function () {
 
                window.setInterval(function () {
                    var url = "${pageContext.request.contextPath}/communication/user/ajax.mvc?timed=" + new Date().getTime();
                    var $iframe = $('<iframe id="frame" name="polling" style="display: none;" src="' + url + '"></iframe>');
                    $("body").append($iframe);
 
                    $iframe.load(function () {
                        $("#logs").append("[data: " + $($iframe.get(0).contentDocument).find("body").text() + " ]<br/>");
                        $iframe.remove();
                    });
                }, 5000);
 
            });
        </script>
    </head>
 
    <body>
 
        <div id="logs"></div>
    </body>
</html>

这个轮询方式就是把刚才上面的稍微改下，每个请求都有自己独立的一个iframe，当这个iframe得到响应的数据后就把数据push到当前页面上。使用此方法已经类似于ajax的异步交互了，这种方法也是不能保证顺序的、比较耗费资源、而且总是有一个加载的条在地址栏或状态栏附件（当然要解决可以利用htmlfile，Google的攻城师们已经做到了，网上也有封装好的lib库），但客户端实现起来比较简单。

如果要保证有序，可以不使用setInterval，将创建iframe的方法放在load事件中即可，即使用递归方式。调整后的代码片段如下：

<script type="text/javascript">
    $(function () {
        (function iframePolling() {
            var url = "${pageContext.request.contextPath}/communication/user/ajax.mvc?timed=" + new Date().getTime();
            var $iframe = $('<iframe id="frame" name="polling" style="display: none;" src="' + url + '"></iframe>');
            $("body").append($iframe);
 
            $iframe.load(function () {
                $("#logs").append("[data: " + $($iframe.get(0).contentDocument).find("body").text() + " ]<br/>");
                $iframe.remove();
 
                // 递归
                iframePolling();
            });
        })();    
    });
</script>

这种方式虽然保证了请求的顺序，但是它不会处理请求延时的错误或是说很长时间没有返回结果的请求，它会一直等到返回请求后才能创建下一个iframe请求，总会和服务器保持一个连接。和以上轮询比较，缺点就是消息不及时，但保证了请求的顺序。

4、ajax实现长连接

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8" isELIgnored="false" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
    <head>
        <meta http-equiv="pragma" content="no-cache">
        <meta http-equiv="cache-control" content="no-cache">
        <meta http-equiv="expires" content="0">
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <%@ include file="/tags/jquery-lib.jsp"%>
 
        <script type="text/javascript">
            $(function () {
 
                (function longPolling() {
 
                    $.ajax({
                        url: "${pageContext.request.contextPath}/communication/user/ajax.mvc",
                        data: {"timed": new Date().getTime()},
                        dataType: "text",
                        timeout: 5000,
                        error: function (XMLHttpRequest, textStatus, errorThrown) {
                            $("#state").append("[state: " + textStatus + ", error: " + errorThrown + " ]<br/>");
                            if (textStatus == "timeout") { // 请求超时
                                    longPolling(); // 递归调用
 
                                // 其他错误，如网络错误等
                                } else { 
                                    longPolling();
                                }
                            },
                        success: function (data, textStatus) {
                            $("#state").append("[state: " + textStatus + ", data: { " + data + "} ]<br/>");
 
                            if (textStatus == "success") { // 请求成功
                                longPolling();
                            }
                        }
                    });
                })();
 
            });
        </script>
    </head>
 
    <body>

上面这段代码就是才有Ajax的方式完成长连接，主要优点就是和服务器始终保持一个连接。如果当前连接请求成功后，将更新数据并且继续创建一个新的连接和服务器保持联系。如果连接超时或发生异常，这个时候程序也会创建一个新连接继续请求。这样就大大节省了服务器和网络资源，提高了程序的性能，从而也保证了程序的顺序。

六、总结

现代的浏览器都支持跨域资源共享（Cross-Origin Resource Share，CORS）规范，该规范允许XHR执行跨域请求，因此基于脚本的和基于iframe的技术已成为了一种过时的需要。

把Comet做为反向Ajax的实现和使用的最好方式是通过XMLHttpRequest对象，该做法提供了一个真正的连接句柄和错误处理。当然你选择经由HTTP长轮询使用XMLHttpRequest对象（在服务器端挂起的一个简单的Ajax请求）的Comet模式，所有支持Ajax的浏览器也都支持该种做法。

基于HTTP的长连接技术，是目前在纯浏览器环境下进行即时交互类应用开发的理想选择，随着浏览器的快速发展，html5将为其提供更好的支持和更广泛的应用。在html5中有一个websocket 可以很友好的完成长连接这一技术，网上也有相关方面的资料，这里也就不再做过多介绍。

转载自： https://www.cnblogs.com/AloneSword/p/3517463.html