http:长连接与短连接

1.3次握手与4次挥手

2.长连接与短链接

 

1.关闭长连接

因为 TCP 连接长时间不关闭，服务器必须在内存里保存连接的状态，其实就是占用了服务器的资源。如果有大量的空闲长连接只连不发，就会很快耗尽服务器的资源。
所以，长连接需要[ 在恰当的时间 ]关闭 。关闭长连接，这在客户端或者服务器都能做到。
在客户端侧，可以在请求头里加上"Connection: close"字段，告诉服务器：“这次通信完成后就关闭tcp连接”。服务器看到这个字段，就知道客户端要主动关闭连接，于是在响应报文里也加上这个"Connection: close"字段，响应发送完毕后则调用Socket API关闭该TCP连接。

2.策略

服务器端通常不会主动关闭tcp连接，但具备一些关闭长连接的策略。拿 Nginx 这种服务器来举例，它有两种方式：

使用"keepalive_timeout"指令，设置长连接的超时时间，如果在一段时间内tcp连接上没有任何数据流动则主动断开该tcp连接，从而避免空闲tcp连接占用服务器资源。
使用"keepalive_requests"指令，设置一个长连接上可发送的最大http请求次数。比如设置成 N，那么当 Nginx 在这个连接上处理了 N个请求后，也会主动断开该长连接。

3.连接的相关头字段

HTTP/1.1中的连接都会默认启用长连接。客户端不需要用头字段指定，只要向服务器发送了第一次请求，后续的http请求都会重复利用第一次打开的TCP连接，直到这个TCP连接被关闭。当然，也可在请求头里明确地要求使用长连接机制，使用的头字段是Connection: “keep-alive”。不过不管客户端是否显式要求长连接，如果服务器支持长连接，它总会在响应报文里放一个Connection: "keep-alive"头字段，告诉客户端: “我服务器是支持长连接的，接下来的http请求就复用这个TCP连接。”

4.长连接缺点

但长连接不是万能的，它存在队头阻塞问题。

队头阻塞

如果仅仅使用一个连接，它需要发起请求、等待响应，之后才能发起下一个请求。在请求应答过程中，如果出现任何状况，剩下所有的工作都会被阻塞在那次请求应答之后。这就是“队头阻塞”，它会阻碍网络传输和Web页面渲染，直至失去响应。为了防止这种问题，现代浏览器会针对单个域名开启6个连接，通过各个连接分别发送请求。它实现了某种程度上的并行，但是每个连接仍会受到“队头阻塞”的影响。

pipline

为解决队头阻塞这个问题，提出了pipline方案。虽然在一个tcp通道中实现了多个http并发，但因为该方案有缺陷，大部分浏览器默认是关闭pipeline的。

其一是因为返回的时候是会阻塞的，谁先到达，谁先返回，顺序绝对不能乱。另一个pipeline限制是，只能是幂等请求（get、head等）才能应用pipeline，