阿里云 slb 的一些行为

[inetfuture]

引言

了解阿里云 slb 的一些行为可以帮助后端服务性能调优。

下文的示例中：

• slb IP 为 116.62.90.87 。
• slb 后端 ecs IP 为 192.168.1.155，简称 155 。
• 同一网络内还有一台 ecs ，公网 IP 116.62.63.160 ，内网 IP 192.168.1.156，简称 156，这个并没有加到 slb 的后端列表，用来作为客户端。
• 100 开头的 IP 都是 slb 的。

七层负载均衡

请求路径：156 => slb => 155，155 上就是一个简单的 nginx 。

slb 到 ecs 是长连接还是短连接

健康检查和请求代理都是短连接（Connection: close），连接由服务端主动关闭。

下图是健康检查的抓包：

注意，健康检查是 HEAD 请求，而且是 HTTP 1.0 ，HTTP 1.0 是不支持长连接的（至少规范没有明确定义），所以响应给的是 Connection: close。

下图是请求代理的抓包：

请求里明确带了 Connection: close （HTTP 1.1 中的默认值是 keep-alive）。这个与客户端是怎么请求 slb 的无关，slb 都是以此种方式请求后端服务的。

另外，可以看到请求的 X-Forwarded-For header 里携带了客户端的 IP 。

slb 是一台机器吗

不是，是一个集群，如下图，IP 是在变的：

客户端到 slb 是长连接还是短连接

slb 遵守 HTTP 规范，所以取决于客户端如何请求。

例如，在 156 上使用 curl http://116.62.90.87/test1 http://116.62.90.87/test2 测试，抓包如下：

可以看到客户端没有使用 Connection header ，根据规范，默认值是 keep-alive ，所以 slb 返回了 Connection: keep-alive ，并保持连接打开，第二个请求重用了 TCP 连接。最后 curl 命令退出，客户端主动关闭了连接。

四层负载均衡

TCP 包到后端用的谁的 IP

客户端的，非 slb 的。

抓包如下图：

slb 会抹掉 TCP 包的 timestamp 吗

不会，抓包如下：

在客户端抓的，请求包的 timestamp 为 46264167 。

在后端 ecs 抓的，可以看到 timestamp 跟上面一样，没有发生变化。

参考资料

• https://help.aliyun.com/knowledge_detail/39455.html?spm=5176.doc52268.2.3.X0RHNU