你好，我是看山。
一直听别人说 HTTP 长连接，只知道长连接比短连接更节省资源、更快捷，但是并不真的知道原因。知其然不知其所以然，对于技术来说，这种状态是比较危险的。所以，还是要挖一下原理，即使挖的比较浅，也要迈出这一步。
HTTP 是应用层协议，传输层使用的是 TCP 协议，网络层使用的是 IP 协议。
IP 协议主要解决网络路由和寻址问题，TCP 协议主要解决如何在 IP 层之上可靠的传递数据包，使在网络上的另一端收到发送端发出的所有包，并且顺序与发出顺序一致，HTTP 协议主要基于 TCP 协议完成数据传递。
首先说下 TCP 连接与断开。
TCP 的生命周期被戏称为三次握手和四次挥手，每次握手（挥手）都需要通信双方交互数据，所以 TCP 连接传输数据是比较耗费资源的，也就是通常所说的成本较高。
然后，HTTP 协议是无状态的、面向连接的，即协议本身不具备记忆能力，两次不同的 HTTP 请求之间没有任何联系。
在 HTTP/1.1 之前，一个网页加载资源的时候，每需要加载一个资源，就需要进行一次 HTTP 请求，建立一次连接，请求结束就断开连接，而每次连接（TCP 连接）都需要耗费资源（时间资源、网络资源等）。
所以后来在 HTTP/1.1 中引入持久连接（persistent connection），即 TCP 连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive，也就是常说的长连接。
这里所说的长连接，其实本身是 TCP 长连接。比如发起一次 HTTP 请求时，客户端与服务端创建 TCP 连接，在得到响应结果后，不进行 TCP 的四次挥手断开连接，而是会保持一段时间的 TCP 连接。此时，如果又有一次 HTTP 请求相同的服务端，就会继续使用这一个 TCP 连接。这样，节省了 TCP 连接的消耗。
当然，为了资源的有效利用，在一段时间（超时时间，请求头中Keep-alive: timeout=10进行设置）没有活动时，客户端或服务端会主动断开 TCP 连接。建议的做法是，在客户端最后一次请求时，请求头中发送Connection: close，明确要求关闭 TCP 连接。
补充下 TCP 三次握手、四次挥手的知识。
三次握手建立连接：
第一次握手：客户端发送 SYN 包 (seq=x) 到服务器，并进入 SYN_SEND 状态，等待服务器确认；
第二次握手：服务器收到 SYN 包，必须确认客户的 SYN（ACK=x+1），同时自己也发送一个 SYN 包（seq=y），即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态；
第三次握手：客户端收到服务器的 SYN＋ACK 包，向服务器发送确认包 ACK(ACK=y+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP 连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。
四次挥手断开连接
第一次挥手：主动关闭方发送一个 FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了（当然，在 FIN 包之前发送出去的数据，如果没有收到对应的 ACK 确认报文，主动关闭方依然会重发这些数据），但此时主动关闭方还可以接受数据。
第二次挥手：被动关闭方收到 FIN 包后，发送一个 ACK 给对方，确认序号为收到序号+1（与 SYN 相同，一个 FIN 占用一个序号）。
第三次挥手：被动关闭方发送一个 FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
第四次挥手：主动关闭方收到 FIN 后，发送一个 ACK 给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。
注意：中断连接端可以是 Client 端，也可以是 Server 端。
详细的状态说明
SYN_SEND：客户端尝试链接服务端，通过 open 方法。也就是 TCP 三次握手中的第 1 步之后，注意是客户端状态
SYN_RECEIVED： 服务接受创建请求的 SYN 后，也就是 TCP 三次握手中的第 2 步，发送 ACK 数据包之前。注意是服务端状态，一般 15 个左右正常，如果很大，怀疑遭受 SYN_FLOOD 攻击
ESTABLISHED：客户端接受到服务端的 ACK 包后的状态，服务端在发出 ACK 在一定时间后即为 ESTABLISHED
FIN_WAIT1：主动关闭的一方，在发出 FIN 请求之后，也就是在 TCP 四次挥手的第 1 步
CLOSE_WAIT：被动关闭的一方，在接受到客户端的 FIN 后，也就是在 TCP 四次挥手的第 2 步
FIN_WAIT2：主动关闭的一方，在接受到被动关闭一方的 ACK 后，也就是 TCP 四次挥手的第 2 步。可以设定被动关闭方返回 FIN 后的超时时间，有效回收链接，避免 syn-flood.
LASK_ACK：被动关闭的一方，在发送 ACK 后一段时间后（确保客户端已收到），再发起一个 FIN 请求。也就是 TCP 四次挥手的第 3 步
TIME_WAIT：主动关闭的一方，在收到被动关闭的 FIN 包后，发送 ACK。也就是 TCP 四次挥手的第 4 步
