网络夺命连环问3--谈下你对 HTTP 长连接和短连接的理解？分别应用于哪些场景？

谈下你对 HTTP 长连接和短连接的理解？

在 HTTP/1.0 中默认使用短连接，客户端每次发起HTTP请求时创建TCP连接（三次握手），请求完毕时关闭连接（四次挥手） 适用与只用请求一次的情况。

短链接缺点： 传输效率低，时间都用在三次握手，四次挥手了，解决方法：长连接

HTTP/1.1 默认启用长连接，客户端发起HTTP请求后，创建的TCP连接不会立即关闭，接下来的HTTP请求复用这个连接。适合有多次请求的情况。

可以在请求头里明确地要求使用长连接机制，使用的字段是 Connection，值是“keep-alive”。
不过不管客户端是否显式要求长连接，如果服务器支持长连接，它总会在响应报文里放一个“Connection: keep-alive”字段，告诉客户端：“我是支持长连接的，接下来就用这个 TCP 一直收发数据吧”。

长连接缺点：TCP连接长时间不关闭，服务器必须在内存中保存它的状态，占用服务器的资源。长连接需在恰当的时间关闭。

解决：
客户端，可以在请求头里加上“Connection: close”字段，告诉服务器：“这次通信后就关闭连接”。
服务器端通常不会主动关闭连接，但也可以使用一些策略。

• 使用“keepalive_timeout”指令，设置长连接的超时时间，如果在一段时间内连接上没有任何数据收发就主动断开连接，避免空闲连接占用系统资源。
• 使用“keepalive_requests”指令，设置长连接上可发送的最大请求次数。

应用场景：

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个 TCP 连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多， 所以每个操作完后都不断开，下次处理时直接发送数据包就 OK 了，不用建立 TCP 连接。例如： 数据库的连接用长连接， 如果用短连接频繁的通信会造成 socket 错误，而且频繁的 socket创建也是对资源的浪费。

而像 WEB 网站的 http 服务一般都用短链接，因为长连接对于服务端来说会耗费一定的 资源，而像 WEB 网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源， 如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连接。

HTTP 如何实现长连接？在什么时候会超时？

通过在头部（请求和响应头）设置 Connection: keep-alive，HTTP1.0协议支持，但是默认关闭，从HTTP1.1协议以后，连接默认都是长连接

1、HTTP 一般会有 httpd 守护进程，里面可以设置 keep-alive timeout，当 tcp 链接闲置超过这个时间就会关闭，也可以在 HTTP 的 header 里面设置超时时间

2、TCP 的 keep-alive 包含三个参数，支持在系统内核的 net.ipv4 里面设置：当 TCP 链接之后，闲置了 tcp_keepalive_time，则会发生侦测包，如果没有收到对方的 ACK，那么会每隔 tcp_keepalive_intvl 再发一次，直到发送了 tcp_keepalive_probes，就会丢弃该链接。

（1）tcp_keepalive_intvl = 15
（2）tcp_keepalive_probes = 5
（3）tcp_keepalive_time = 1800

实际上 HTTP 没有长短链接，只有 TCP 有，TCP 长连接可以复用一个 TCP 链接来发起多次 HTTP 请求，这样可以减少资源消耗，比如一次请求 HTML，可能还需要请求后续的 JS/CSS/图片等

在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？

在 HTTP 中响应体的 Connection 字段指定为 keep-alive

---

加餐部分

队头阻塞

因为“请求 - 应答”模型不能变，所以“队头阻塞”问题在 HTTP/1.1 里无法解决，只能缓解，有什么办法呢？

方案1： “同时对一个域名发起多个长连接，用数量来解决质量的问题。”HTTP 允许客户端使用并发，但不能滥用。
方案2：“域名分片”。HTTP 协议和浏览器不是限制并发连接数量吗？好，那我就多开几个域名，比如 shard1.chrono.com、shard2.chrono.com，而这些域名都指向同一台服务器 www.chrono.com。
方案3：管道pipeline：批量发送HTTP请求，批量响应，类似TCP的滑动窗口，但废弃了。