JustQyx

大道至简

TCP 链路是如何 Keep-Alive 的

| Comments

之前一直没有搞明白,HTTP 链路(即 TCP 链路)是如何 Keep-Alive 的。 这其实只是一个基础知识,只有知道与不知道的区别而已。

如何定义一条 TCP 连接

1
<源IP地址、源端口号、目的IP地址、目的端口号>

这四个值一起唯一地定义了一条连接。两条不同的 TCP 连接不能拥有 4 个完全相同 的地址组件值。

TCP 链路

数据从我们的计算机发出,在到达目标机器之前,需要经过许多其他结点。 这其中的每一个结点,需要维护两个 TCP 连接对象,使其能够与上一个结点和下一个结点通讯, 类似双向链表。

于是,一条链路就这么形成了。

一旦其中某个结点断开了连接,即移除了 TCP 连接对象,那么整条链路也就断开了, 并以主动断开或主动探测或超时断开的机制,对整条链路的 TCP 连接对象进行回收。

TCP 连接是昂贵的

建立 TCP 连接需要首先建立起通讯链路,并完成三次握手,故建立 TCP 连接的操作是昂贵的。 因此,以下依次出现的三种机制,是为了对 TCP 链路资源有更高效率的使用。

Keep-Alive

这是 HTTP/1.0 规范中增加的,但 HTTP/1.1 已经废弃。 为的是在完成 HTTP 事务操作之后保持 TCP 连接不关闭,使得下一个请求发起时,不再需要重新建立 TCP 连接。

Persistent

与 HTTP/1.0+ 的 Keep-Alive 连接不同,HTTP/1.1 的连接在默认情况下是激活的, 除非特别指明,否则 HTTP/1.1 假定所有连接都是持久的。要在事务处理结束之后将 连接关闭,HTTP/1.1 应用程序必须向报文中显示地增加一个 Connection: Close 首部。 这是与以前的 HTTP 协议版本很重要的区别,在以前的版本中,Kepp-Alive 连接要么是可选的, 要么根本就不支持。

管道化连接

HTTP/1.1 允许在持久连接上可选地使用请求管道。这是相对于 Keep-Alive 连接的又一次性能优化。 在响应到达之前,可以将多条请求放入队列。当第一条请求通过网络流向地球另一端的服务器时, 第二条和第三条请求也可以开始发送了。在高时延网络条件下,这样做可以降低网络的环回时间, 提高性能。

无论是 Keep-Alive 还是 Persistent 还是管道,HTTP 客户端都必须做好所有可能出错的情况, 因为在网络的世界里,每个结点都无法保证连接在那一刻是可用的,每个结点都可能随时关闭 TCP 连接。

参考

  • 《HTTP 权威指南》

Comments