短连接和长连接：
1.常见的网上说http分为长连接和短连接，其实本质上是说的TCP连接。TCP连接是一个双向的通道，它是可以保持一段时间不关闭的，因此TCP连接才有真正的长连接和短连接这一说法。需要强调的是HTTP协议是基于请求/响应模式的，因此只要服务端给了响应，本次HTTP连接就结束了，或者更准确的说，是本次HTTP请求就结束了，根本没有长连接这一说，那么自然也没用短连接这一说了。HTPP协议是应用层协议，而TCP是传输
层协议，只有负责传输的这一层才需要建立连接。
2.所谓的HTTP支持长连接，其实是基于Keep-Alive请求头约定，从而向下进行长连接发起的一种机制，该连接依然是基于TCP的。
3.大多数人都知道HTTP1.0不支持长连接，知道HTTP1.1支持长连接。所谓HTTP1.1及以上支持长连接，并不是HTTP1.1可以建立长连接，而是它支持以请求头的方式进行长连接发起（并且要求客户端与服务端都要具备 ‘Keep-Alive: true’ ）。
短连接
所谓短连接，及连接只保持在数据传输过程，请求发起，连接建立，数据返回，连接关闭。它适用于一些实时数据请求，配合轮询来进行新旧数据的更替。短连接的流程就是：建立连接->发送数据->断开连接。一次发送之后立即断开连接。
短连接的好处：
既然有长连接了，为什么还需要用短连接的，因为短连接虽然是之前一直使用的，但是长连接保持了连接不被断开，那么如果并发量很好的时候，就会出现问题，所以短连接不用一直占用服务器资源，可以让服务器空出资源来解决其他的连接。
银行一般使用短连接。好像是因为：管理起来比较简单，存在的连接就是有用的。
长连接
长连接便是在连接发起后，在请求关闭连接前客户端与服务端都保持连接，实质是保持这个通信管道，之后便可以对其进行复用。长连接需要注意的是长连接并不是永久连接的。如果一段时间内（具体的时间长短，是可以在header当中进行设置的，也就是所谓的超时时间），这个连接没有HTTP请求发出的话，那么这个长连接就会被断掉。
它适用于涉及消息推送，请求频繁的场景（直播，流媒体）。连接建立后，在该连接下的所有请求都可以重用这个长连接管道，避免了频繁了连接请求，提升了效率。
长连接的好处：
为什么要用长连接呢？长连接最重要的是可以服用TCP连接，这样减少了每次建立连接和断开连接的开销。所以现在大部分都是长连接，例如一个页面有很多文件，JS文件，CSS文件等等，不能每次都要建立一次连接，所以长连接是比较好的解决办法。
长连接不会长时间保持的，如果长时间没有响应，超时会自动断开的。
但是如果都保持连接，那么服务器会爆掉，所以TCP连接数量是有限制的。
使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1是判断传输数据是否达到了Content-Length指示的大小；2动态生成的文件没有Content-Length，它是分块传输（chunked），这时候就要根据chunked编码来判断，chunked编码的数据在最后有一个空chunked块，表明本次传输数据结束。
应用场景区别
- 一般长连接（追求实时性高的场景）用于少数client-end to server-end的频繁的通信，例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
- 而像WEB网站的http服务一般都用短链接（追求资源易回收场景），因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源。
长轮询和短轮询
所谓轮询，即是在一个循环周期内不断发起请求来得到数据的机制。只要有请求的地方，都可以实现轮询，譬如各种事件驱动模型。它的长短是在于请求的返回周期。
短轮询
短轮询指的是在循环周期内，不断发起请求，每一次请求都立即返回结果，根据新旧数据对比决定是否使用这个结果。
具体实现：
前端使用定时器，每间隔一段时间发送请求来获取数据是否更新，这种方式可兼容ie和支持高级浏览器。通常采用 setInterval 或者 setTimeout 实现。
通过递归的方式，在获取到数据后每隔一定时间再次发送请求，这样虽然无法保证两次请求间隔为指定时间，但是获取的数据顺序得到保证。
缺点：
- 页面会出现假死
-setTimeout 在等到每次 EventLoop 时，都要判断是否到指定时间，直到时间到再执行函数，一旦遇到页面有大量任务或者返回时间特别耗时，页面就会出现‘假死’ - 无用的网络传输
-当客户端按固定频率向服务器发起请求，数据可能并没有更新，浪费服务器资源。 - 重复发送Http请求，查询目标事件是否完成，优点：编写简单，缺点：浪费带宽和服务器资源
长轮询
长轮询即是在请求的过程中，若是服务器端数据并没有更新，那么则将这个连接挂起，直到服务器推送新的数据，再返回，然后进入循环周期。
具体实现：
客户端像传统轮询一样从服务端请求数据，服务端会阻塞请求不会立刻返回，直到有数据或超时才返回给客户端，然后关闭连接，客户端处理完响应信息后再向服务器发送新的请求。
长轮询解决了频繁的网络请求浪费服务器，资源可以及时返回给浏览器。
缺点：
- 保持连接会消耗资源
- 服务器没有返回有效数据，程序超时
- 在服务端hold住Http请求（死循环或者sleep等等方式），等到目标时间发生，返回Http响应。优点：在无消息的情况下不会频繁的请求，缺点：编写复杂
对于客户端来说，不管是长轮询还是短轮询，客户端的动作都是一样的，就是不停的去请求，不同的是服务端，短轮询情况下服务端每次请求不管有没有变化都会立即返回结果，而长轮询情况下，如果有变化才会立即返回结果，而没有变化的话，则不会再立即给客户端返回结果，直到超时为止。
这样一来，客户端的请求次数将会大量减少（这也就意味着节省了网络流量，毕竟每次发请求，都会占用客户端的上传流量和服务端的下载流量），而且也解决了服务端一直疲于接受请求的窘境。
但是长轮询也是有坏处的，因为把请求挂起同样会导致资源的浪费，假设还是1000个人停留在某个商品详情页面，那就很有可能服务器这边挂着1000个线程，在不停检测库存量，这依然是有问题的。
因此，从这里可以看出，不管是长轮询还是短轮询，都不太适用于客户端数量太多的情况，因为每个服务器所能承载的TCP连接数是有上限的，这种轮询很容易把连接数顶满。之所以举这个例子，只是因为大家肯定都会网购，所以这个例子比较通俗一点。
长短轮询和长短连接的区别
- 第一个区别是决定的方式，一个TCP连接是否为长连接，是通过设置HTTP的Connection Header来决定的，而且是需要两边都设置才有效。而一种轮询方式是否为长轮询，是根据服务端的处理方式来决定的，与客户端没有关系。
- 第二个区别就是实现的方式，连接的长短是通过协议来规定和实现的。而轮询的长短，是服务器通过编程的方式手动挂起请求来实现的。
