长连接、短连接，长轮询、短轮询
一、长连接、短连接
我们经常会听到“HTTP长连接与短连接”、“HTTP连接分为长连接与短连接”，但其实这样的说法是不严谨的，所以我这里标题不以HTTP的长连接、短连接这样来写，以免误导
我们回顾一下HTTP协议的工作模式，是基于响应/请求的模式，即客服端发起请求，服务端返回响应，那么一次完整的HTTP请求就结束了。HTTP协议是应用层协议，主要的工作不是管理通信双方的连接，这个工作是由传输层的协议来做（这也是为什么会有网络分层模型，各层相互独立、只需关注自己的工作，高层不需要了解底层的具体实现），HTTP协议是建立在TCP连接的基础上，所以本质上，HTTP的长连接、短连接指的是TCP的长连接、短连接——通信双方遵循TCP协议建立起一个TCP连接（一个双向的通信通道，这个通道可以长时间保持不关闭），我们在这个连接通道上发送HTTP请求、响应数据，所以HTTP并没有长连接、短连接的概念；
短连接（非持久连接）
何谓短连接？——HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接，也就是说浏览器和服务器每进行一次HTTP操作，就要建立一个TCP连接，任务结束就断开连接，HTTP/1.0默认使用短连接，那么随着现在的Web应用越来越复杂，现在我们打开一个网页，基本上都要加载一些额外的CSS、JS、图片、视频等等资源，那么每一个资源都需要一个HTTP请求去加载，就需要连接几个甚至几十个TCP连接，每次的请求都会造成无谓的TCP连接建立和断开，非常消耗服务器资源、浪费带宽
（可以看到打开我的CSDN首页需要加载非常多的资源）
——因此这就需要长连接这么个机制，使得多个HTTP请求可以复用一个TCP连接，这对于一些频繁请求的操作，可以节省很大的消耗
长连接（持久连接）
怎样实现长连接？——服务器和客户端都需要设置Connection为keep-alive，就可以通过HTTP协议来规定的方式实现这个TCP连接长久保持，我们现在大多使用的HTTP/1.1，HTTP/1.1默认使用持久连接
（可以看到请求头中Connection首部字段为keep-alive）
长连接下只要任意一端没有明确提出断开连接，则会保持TCP连接状态，但长连接并不是要永久连接，因为一个服务器的TCP连接数是有限的，一直不关闭，随着TCP连接将会越来越多，很容易顶满服务器的上限，一般情况下，客户端不会主动断开连接，所以要设置一个超时时间（在header当中进行设置），当服务端侦测到再没有客户端的请求发生，超过了一定时间，服务器就会断开这个连接；另外，服务端也可以通过配置，以客户端机器为颗粒度，限制每个客户端的最大连接数；
————总的来说，即客户端发送HTTP请求时，在头部字段添加Connection:keep-alive，来告诉服务器我想要长连接，若服务器的确支持长连接，也会在响应头部添加“Connection:Keep-Alive”，来告诉浏览器“我的确也支持，那我们建立长连接吧”。同时服务器还可以通过 Keep-Alive:timeout=10, max=100 的头部告诉浏览器“我希望 10 秒算超时时间，最长不能超过 100 秒”。
长连接与短连接没有绝对的好坏，只有适用的场景，例如对于静态内容的网页，keep-alive功能起到了很大的作用，但是对于负担较重的网页服务器，本来可以立即释放的连接仍旧保持，也占用了资源、影响性能
二、Tomcat中配置长连接、最大连接数
现如今市场上的大部分Web服务器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive，以下以Apache-Tomcat8为例：
HTTP/1.1中默认支持长连接，因此tomcat中若是http/1.1则默认支持长连接，tomcat的server.xml文件元素中的配置项与长连接有关的属性为两个：keepAliveTimeout、maxKeepAliveRequests，单位是milliseconds
keepAliveTimeout： 即keep-alive的超时时间，下一次请求与上一次的请求未超过这个时间，则一直保持连接，默认值与tomcat元素中的connectionTimeout值相同
maxKeepAliveRequests： 表示该长连接最大支持的请求数。超过该请求数的socket连接会被强制关闭（此时就会返回一个Connection: close头给客户端），默认值为100，若设置为1，则会禁用keep-alive，若设置为小于 0 的数，则Keep Alive 的最大请求数将没有限制
tomcat中默认支持长连接
若想要自定义配置
三、长轮询、短轮询
这里顺便说一下长轮询、短轮询，长短轮询不同于长短连接这样的网络概念，轮询指的是业务处理逻辑及服务端的处理方式，无论长短轮询，对于客户端来说都是同一个动作，在一段时间内不停地一个一个地发送HTTP请求
我们一般说的轮询（Polling）即为短轮询，长轮询为（Long Polling）
短轮询：
客户端中实现了一个死循环，不停地向服务端发送HTTP请求，目的是去实时地查询某个数据的最新值更新过来，服务端每一次收到请求，无论数据是否有更新都立即返回响应；这种情况下，就可能会出现同时有几千个、几万个用户不停地去轮询服务器这样地窘境
长轮询：
对于客户端来说还是不停地去请求，区别在于服务器。在长轮询中，服务器不会盲目地立即返回响应，而是首先会判断数据是否有更新，若实际没有更新，则会将请求挂起，客户端没有收到响应就不会继续下一次请求，同时服务器挂起请求时也会设置一个超时时间，若数据更新了则会立即返回，若数据一直没更新，则超过了这个超时时间，也会返回响应，这样一来客户端的请求频率被降低了，节省了网络流量
但是长轮询也有缺点：服务端每挂起一个请求，就会挂起一个相应的线程去侦测数据是否更新，挂起的数量越来越多，也会占用很多服务端资源
————无论长轮询、短轮询，因为都是基于HTTP的请求/响应模式，两者都是属于“被动型的服务”，服务器不会主动推送信息，短轮询考验服务端的响应速度，长轮询则考验服务器的并发处理能力，都存在一定缺陷，更好的是“主动型的服务”，数据发生更新，服务端主动推送给客户端——>如WebSocket（后面再详解）