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 种连接模式：