• HTTP 事务模型
    • HTTP close 模式
    • Keep-alive 模式
    • pipelining 模式

    HTTP 事务模型

    HTTP close 模式

    HTTP 是一个事务驱动式的协议,所以一个 HTTP 请求有且仅有一个响应。传统上,客户端和服务端之间会创建一个 TCP 连接,客户端通过这个连接发送一个请求,服务端发送一个响应,然后这个连接会被关闭:

    [建立连接 1] [请求 1] … [响应 1] [关闭连接 1] [建立连接 2] [请求 2] … [响应 2] [关闭连接 2] …

    这种模式称为HTTP close模式,有多少 HTTP 事务就建立多少连接。当服务端响应并关闭连接后,客户端便无须关心传输内容的长度。

    Keep-alive 模式

    鉴于 HTTP 协议的事务模型性质,优化它、避免后续传输时的连接闭成为可能,因而产生了一种新的工作模式:Keep-alive

    在这种工作模式下,服务端被强制要求告知客户端传输数据的内容长度,避免客户端无限的等待。这一切都通过一个特定的 HTTP 头Content-length来实现:

    [建立连接] [请求 1] … [响应 1] [请求 2] … [响应 2] [关闭连接]

    这种模式的好处是减少了传输时的时延,降低了服务端处理时的资源消耗。

    一般情况下这种模式优于HTTP close模式, 但并不绝对,因为很多客户端的并发连接数都设置得较小。

    pipelining 模式

    另一种优化方式称为pipelining模式,它基于Keep-alive,但客户端不会等服务端响应后才发送下一个请求。这在获取一个由大量图片构成的页面时显得非常有用:

    [建立连接] [请求 1] [请求 2] … [响应 1] [响应 2] [关闭连接]

    这种模式抵消了双方传输时的网络延迟,显著提高了网络性能。但当前许多 HTTP 代理仍不支持此模式,因为没有办法将请求和响应一一对应起来,鉴于此,服务端会被强制要求顺序响应请求。

    HAProxy 为了保持连接,默认会工作于Keep-alive模式:为每个连接处理相应的请求和响应,处理完后将连接置于空闲状态,等待处理下一个请求和响应。

    HAProxy 支持 5 种连接模式:

    模式说明
    keep-alive(默认)所有请求和响应都会被处理,没有请求和响应时保持连接
    tunnel第一个请求和响应会被处理,其余的仅作转发
    passive close和 tunnel 模式类似,但会在请求和响应的头部添加Connection: close,使对方主动关闭连接
    server close接收到后端服务器的响应后主动关闭连接,保持与客户端的连接
    forced close每一次接收到对方响应后就关闭连接