Neutron社区每周记(12.5-12.9)| 长连接是什么东西?HAProxy 又是如何使用长连接的?

—背景介绍—

HTTP Keep Alive 指的是 HTTP 的长连接,HTTP 的长连接和短连接本质上是 TCP 的长连接和短连接。HTTP 属于应用层协议,在传输层使用 TCP 协议,在网络协议层使用 IP 协议。那么,什么是长连接,短连接呢?在 HTTP / 1.0 中默认使用短连接,也就是说,客户端和服务端之间没进行一次 HTTP 连接,就会建立一次连接,在任务结束后中断连接,当客户端访问 Web 资源时,每遇到这样一个 Web 资源,客户端就会重新建立一个 HTTP 会话(包括 TCP 连接和 HTTP 连接)。

从 HTTP / 1.1 起,默认使用长连接。使用长连接的 HTTP 协议,会在响应头中添加如下代码:Connection: keep-alive

在使用长连接的情况下,当完成一次 HTTP 请求后,客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭,当客户端再次方位这个服务器时,会继续使用这一条已经建立的可连接。Keep-Alive 不会永久保持这个连接,一般都有一个保持时间,在不同的服务器中可以设定这个时间。

我们使用 NGINX 作为后端服务器,通过 NGINX 配置文件的 http 选项中添加:keepalive_timeout  65; // 设置 65 秒维持的长连接时间将 NGINX 配置成 Keep Alive 形式。

—HTTP长连接—

我们可以利用 『ab』软件发送 HTTP 请求,在 NGINX 服务器上抓包进行分析。『ab』通过 『-k』参数使用 HTTP 长连接特性,在发送 10 个 HTTP 请求。例如:ab -n 10 -c 1 -k http://10.10.10.12:222/

在 NGINX 服务器上抓包如下:

640

上图中,10.10.10.12 为 NGINX 服务器,客户端 IP 为 10.10.10.9 ,通过上图我们可以看出,只建立了一条 TCP 连接,在这条 TCP 连接上又建立了 10 条 HTTP 连接,我们可以通过 wireshark 会话功能查看 TCP 流:

1

可以看确实只建立了一条 TCP 流。

—HTTP短连接—

我们继续使用 『ab』软件发送 10 个 HTTP 请求,但是不使用 HTTP Keep Alive 功能。使用如下命令发送请求(10 个 HTTP 请求):ab -n 10 -c 1 http://10.10.10.12:222/

在 NGINX 服务器上抓包如下:

2

由于包量较多,只截取了一部分图,如上。我们可以看出,在建立每个 HTTP 之前,都会建立一个 HTTP 连接,使用 wireshark 的会话功能,如下:

3

可以看出确实有十条 TCP 连接。

—HAProxy 中的 HTTP 长连接和短连接—

HAProxy 默认使用了 HTTP 的 Keep Alive 功能,当然是在后端 Real Server 支持了 HTTP Keep Alive的情况下,一般情况下,一些 Web 服务器(Apache 、NGINX 等)都可以配置该特性,但是比较简单的Web 服务,比如使用 python 自带的 SimpleHTTPServer 不支持 HTTP 的 Keep Alive,因此我们在做测试时最好选择一些标准的 Web 服务器作为 Real Server。

那么,我们如何测试呢?

—测试拓扑—

基于 Neutron LBaaS 现有的拓扑结构,我们创建一个 Loadbalancer ,并且绑定 FIP 2.2.0.15,我们可以进行如下扩展:

4

在上面的拓扑结构中,qlbaas qrouter 均为 namespace,此外,我们还另外创建了两个 namespace —— user netns 和 netns proxy。user netns 中两个端口,一个端口上配置和 Neutron 外部网络相同的 IP 地址——2.2.0.111,配置完成后并测试通过(能否 ping 通 fip 2.2.0.15)。创建一对 veth 设备,分别连接到 user netns 和 netns proxy 中,在两个 netns 中分别配置 IP 地址。

配置完成后,我们进入 netns proxy 中,设置默认路由为 veth 另一端的 IP 地址,设置完成后,以 ping 通fip 2.2.0.15 为准来测试网络链路是否正常。

另外,HAProxy 的配置文件如下:

5

在网络测试正常后,我们进入 netns proxy 中,使用 『ab』软件在使用 HTTP Keep Alive 情况下,发送一些 HTTP 请求:ab -n 10 -c 1 -k http://2.2.0.15:2222/

在后端 NGINX 服务器上抓包,可以看到如下情况:

6

TCP 会话如下:

7

可以看到只建立了一条 TCP 连接,建立了 10 条 HTTP 连接,因此确实是 HTTP 的长连接。

HAProxy 通过 option httpclose 选项控制是否在一次 HTTP 连接后断开此 HTTP 连接。此参数在监听器(frontend)和资源池(backend)中都可配置,分别可控制客户端和 HAProxy,HAProxy 和 Real Server 的 HTTP 连接情况。

那么,在监听器和资源池中都添加了 option httpclose 参数后,再进行测试是怎样的情况呢?

由于在监听器中也添加了 option httpclose ,那么在 ab 的命令行中就不能再使用 -k 参数了,那么进行如下测试:ab -n 10 -c 1 http://2.2.0.15:2222/

在后端 NGINX 服务器中,抓包情况如下:

8

TCP 会话如下:

9

可以看出是 10 条 TCP 连接。

—长连接和短连接的优点和缺点—

从上面我们的测试中可以看出,长连接可以省去较多的 TCP 建立和关闭的操作,减少浪费,节省时间。因此对于频繁请求资源的客户来说,适用长连接。但是存在的问题是,由于 HTTP 长连接存活功能的探测周期太长,随着客户端连接越来越多,后端 Real Server 早晚有扛不住的时候,从而造成了资源的浪费。

因此,长连接和短连接的选择要对具体的使用场景进行合适的配置。(作者:苌智,UnitedStack有云)

订阅本站 打印文章

发表评论