不管怎么说，一定要务必记住，长连接是指的TCP连接，而不是HTTP连接。
一个问题
LZ之前对一件事有点模糊，首先，怎么把HTTP变成长连接，是不是只需要设置Connection为keep-alive？
如果是的话，说明HTTP1.1默认是长连接，观察我们平时开发的web应用的HTTP头，Connection确实是keep-alive的，也就是说我们大部分都使用长连接，但是长连接不是一般用于交互频繁的应用吗？对于我们这种普通的web应用，比如博客园，或者我的个人博客，长连接有什么用呢？
如果有用，有什么用？我们不是那种客户端和服务端频繁交互的应用（毕竟一个网页要打开很久才能打开另一个网页），如果没用，是不是应该保留Connection呢？将 -alive 的标头值更改为短连接？
这个问题在LZ明白了长连接其实是指TCP连接之后就基本明白了。而这个问题正是LZ在“之前的误会”那段中提到的，LZ因为误会一直无法理解的问题。
为什么LZ在解决了上面的误会之后，上面提到的所有问题都看懂了？
因为长连接意味着连接会被重用，毕竟连接是为了重用而保留的。但是如果长连接指的是HTTP，就意味着可以复用HTTP连接，听上去很别扭。之所以觉得别扭，其实是LZ的一种直觉，没有理论依据。而这种尴尬的根源在于，我之前没有感觉到融入感，所以总觉得少了点什么。不过这个疑惑并没有影响到LZ的工作，所以没有去调查。
不过现在明白了，长连接其实是指TCP连接，LZ马上就想明白上面的问题了。
第一个问题是，只要Connection设置为keep-alive，是不是长连接？
当然可以，但同时具有服务器和客户端设置。
第二个问题是，我们通常使用长连接吗？
当然，这是毫无疑问的。（现在基本都是使用HTTP1.1协议，观察一下会发现基本Connection是keep-alive的。在HTTP协议文档中也有提到，HTTP1.1默认为It是长连接，即默认Connection值为keep-alive）
第三个问题是LZ之前最不理解的一个问题，也就是像我们这样的普通web应用（比如博客园、我的个人博客）使用长连接有什么好处？我需要关闭长连接并使用短连接吗？
LZ现在终于明白这个问题了。问题的答案是有没有好处。
有什么好处？
首先，就像我刚才说的，长连接是为了复用，LZ之前理解的。由于长连接是指TCP连接，也就是说复用就是TCP连接。那是一个很好的解释，就是在长连接的情况下，多个HTTP请求可以复用同一个TCP连接，节省了大量的TCP连接建立和断开消耗。
比如你在博客园请求一个网页，这个网页还必须包含CSS、JS等一系列资源。 time)，那么每次打开一个网页基本上都需要建立几个甚至几十个 TCP 连接。浪费了多少资源就不用多说了。
但是如果是长连接，那么这么多的HTTP请求（这些请求包括请求网页内容、CSS文件、JS文件、图片等）实际上都是使用TCP连接的，这样显然可以节省很多消耗。
经过这样的解释，就很清楚了。不知道大家看完这些解释是什么感受。反正LZ想明白了之后，顿时有种豁然开朗的感觉。
另外，关于长连接还有一件事要提一下，那就是长连接不是永久连接。如果在一段时间内（具体的时间长度可以在header中设置单页面做好了,怎么连接到网络，也就是所谓的超时时间），如果连接没有发送HTTP请求，那么长连接就会被断开。
这其实很容易理解，不然的话，TCP连接会越来越多，直到服务器上的TCP连接数爆到上限。现在想想，对于服务器来说，服务器中的这些长连接其实尝起来就像一个数据库连接池。每个人都在努力节省连接重用，对吧？
长轮询和短轮询
基本上LZ已经讲过长连接和短连接了。接下来，我们将讨论长短轮询。今天，LZ顺便研究长短连接，正是为了研究长短轮询。
相信大家不难理解short polling。比如你想在一个电商业务中创建一个产品详情页面，详情界面中有一个字段就是库存（这个相信大家都比较熟悉，打开淘宝或者淘宝就可以找到）京东这样的页面）。并且这个库存需要实时变化，以保持与服务器中的实际库存一致。
这个时候，你会怎么做？
最简单的方法是在JS中写一个无限循环，不断的请求服务器中的库存，然后刷新到这个页面，这实际上叫做短轮询。
这种方法的明显缺点是浪费了服务器和客户端资源。客户端更好。现在PC配置高了，你不停的请求不会杀掉用户的电脑，但是服务器很痛苦。如果 1000 人停留在一个商品详情页上，则意味着会有 1000 个客户端不断请求服务器获取库存，这显然是不合理的。
那我们该怎么办？
此时出现长轮询。实际上，长轮询和短轮询最大的区别在于，当短轮询到服务器查询时，无论库存是否发生变化，服务器都会立即返回结果。但是，长轮询不是。在长轮询中，如果服务器检测到库存没有变化单页面做好了,怎么连接到网络，就会暂停当前请求一段时间（这段时间也称为超时时间，通常为几十秒）。在此期间，服务器会检查库存是否有变化，如果检测到变化则立即返回，否则等待超时。
对于客户端来说，无论是长轮询还是短轮询，客户端的动作都是一样的，就是不停地发出请求，不同的是服务端，在短轮询的情况下如果没有变化，结果将立即退回。在长轮询的情况下，如果有变化，立即返回结果，如果没有变化，直到超时才会立即返回结果给客户端。
这样会大大减少客户端请求的数量（也就是节省网络流量，毕竟每次发送请求都会占用客户端的上传流量和服务器的下载流量），而且也解决了服务器一直很累的问题。在接受请求的困境中。
但是长轮询也是不好的，因为暂停请求也会导致资源的浪费。假设有 1000 人停留在一个商品详情页，很可能有 1000 个线程挂在服务器端，不断运行检测库存水平，这仍然是有问题的。
因此由此可见，无论是长轮询还是短轮询，都不适合客户端太多的情况，因为每个服务器可以承载的TCP连接数是有上限的。很容易通过查询来填充连接数。这个例子的原因只是因为大家肯定会在网上购物，所以这个例子更受欢迎。
即使轮询不能解决获取库存的问题，只要大家明白长短轮询的区别，就足够了。其实根据LZ自己平日的购物观察，库存应该不会发生变化。这个例子纯属LZ个人淫秽，-_-。
长短轮询和长短连接的区别
这里简单介绍一下它们的区别，LZ这里只讲最根本的区别。
第一个区别是决策方式。TCP连接是否为长连接是通过设置HTTP Connection Header来判断的，需要两边都设置才有效。轮询方式是否为长轮询，由服务端的处理方式决定，与客户端无关。
第二个区别是实现方式。连接的长度由协议指定和实现。轮询的长度是通过服务器以编程方式手动挂起请求来实现的。
