HTTP的长连接和短连接

一、什么是长连接

      HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。

       在HTTP/1.0中，默认使用的是短连接。浏览器和服务器每进行一次HTTP操作就建立一次连接，然后请求结束就直接中断连接。

     在实际使用中，HTTP头部有了Keep-Alive这个值并不代表一定会使用长连接，客户端和服务器端都可以无视这个值，也就是不按标准来，譬如我自己写的HTTP客户端多线程去下载文件，就可以不遵循这个标准，并发的或者连续的多次GET请求，都分开在多个TCP通道中，每一条TCP通道，只有一次GET，GET完之后，立即有TCP关闭的四次握手，这样写代码更简单，这时候虽然HTTP头有Connection: Keep-alive，但不能说是长连接。正常情况下客户端浏览器、web服务端都有实现这个标准，因为它们的文件又小又多，保持长连接减少重新开TCP连接的开销很有价值。

二、长连接的过期时间

     客户端的长连接不可能无限期的拿着，会有一个超时时间，服务器有时候会告诉客户端超时时间，譬如：

 

      上图中的Keep-Alive: timeout=20，表示这个TCP通道可以保持20秒（Web服务器端的Socket连接并不会立即释放）。另外还可能有max=XXX，表示这个长连接最多接收XXX次请求就断开。对于客户端来说，如果服务器没有告诉客户端超时时间也没关系，服务端可能主动发起四次握手断开TCP连接，客户端能够知道该TCP连接已经无效；另外TCP还有心跳包来检测当前连接是否还活着，方法很多，避免浪费资源。

三、长连接的数据传输完成识别

      使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1是判断传输数据是否达到了Content-Length指示的大小；2动态生成的文件没有Content-Length，它是分块传输（chunked），这时候就要根据chunked编码来判断，chunked编码的数据在最后有一个空chunked块，表明本次传输数据结束。

四、并发连接数的数量限制

      在web开发中需要关注浏览器并发连接的数量，RFC文档说，客户端与服务器最多就连上两通道，但服务器、个人客户端要不要这么做就随人意了，有些服务器就限制同时只能有1个TCP连接，导致客户端的多线程下载（客户端跟服务器连上多条TCP通道同时拉取数据）发挥不了威力，有些服务器则没有限制。浏览器客户端就比较规矩，知乎这里有分析，限制了同域名下能启动若干个并发的TCP连接去下载资源。并发数量的限制也跟长连接有关联，打开一个网页，很多个资源的下载可能就只被放到了少数的几条TCP连接里，这就是TCP通道复用（长连接）。如果并发连接数少，意味着网页上所有资源下载完需要更长的时间（用户感觉页面打开卡了）；并发数多了，服务器可能会产生更高的资源消耗峰值。浏览器只对同域名下的并发连接做了限制，也就意味着，web开发者可以把资源放到不同域名下，同时也把这些资源放到不同的机器上，这样就完美解决了。

五、容易混淆的概念——TCP的keep alive和HTTP的Keep-alive

    TCP的keep alive是检查当前TCP连接是否活着；HTTP的Keep-alive是要让一个TCP连接活久点。它们是不同层次的概念。

     TCP keep alive的表现： 当一个连接“一段时间”没有数据通讯时，一方会发出一个心跳包（Keep Alive包），如果对方有回包则表明当前连接有效，继续监控。

六、HTTP长连接的优点

       我们使用了HTTP长连接后，可以省去很多TCP建立和关闭的步骤，节省了时间。而且因为服务器同时打开的连接减少了，可以降低网络阻塞，提高了资源请求的速度，因为后续请求无需再建立连接，减少了三次握手。例如在静态资源服务器中，一个页面往往有很多静态资源如图片、css、js等，那么在Web服务器上开启长连接，可以提高页面的打开速度。

七、HTTP长连接的缺点

       长连接真的就一定好吗？长连接的状态下，一个Socket的存在时间是建立连接时间+ keepalive_timeout时间+ TIME_WAIT时间。那么如果在高并发的场景下，我们的Web服务器要同时保持大量的Socket连接，那么肯定是占用系统的资源。那么这个时候就要根据实际的情况来修改keepalive_timeout的值，直到一个合理的范围，那么这个需要根据自己的业务特点进行调整。