你好,我是看山。
一直听别人说 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 步
你好,我是看山,公众号:看山的小屋,10 年老猿,开源贡献者。游于码界,戏享人生。关注我,领取资料。
个人主页:https://www.howardliu.cn
个人博文:HTTP 长连接和短连接
CSDN 主页:http://blog.csdn.net/liuxinghao
CSDN 博文:HTTP 长连接和短连接