负载均衡关于请求头的那些事
title: 负载均衡关于请求头的那些事
date: 2022/07/21 13:58
本地环境
浏览器/客户端(127.0.0.1)
# 访问 nginx
curl localhost:8002/main/dqPlow/rest/async/req
nginx(192.168.2.43:8002)
server {
listen 8002;
server_name localhost;
location / {
proxy_pass http://192.168.2.50:9999;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
root html;
index index.html index.htm;
}
}
gateway(192.168.2.50:9999)
spring:
cloud:
gateway:
routes:
- id: dqPlow
uri: http://192.168.2.50:8080
predicates:
- Path=/main/dqPlow/**
filters:
- StripPrefix=1
dpPlow(192.168.2.50:8080)
请求头变化
nginx | gateway | 请求头 | nginx 代理后(gateway 接收到的请求头信息) | gateway 代理后(应用服务接收到的请求头信息) |
---|---|---|---|---|
√ | √ | x-forwarded-proto | http | http,http |
√ | √ | x-forwarded-host | localhost:8002 | localhost:8002,192.168.2.50:9999 |
√ | √ | x-forwarded-for | 127.0.0.1 | 127.0.0.1,192.168.2.43 |
√ | √ | x-forwarded-port | 8002 | 8002,9999 |
√ | √ | x-forwarded-prefix | 未配置前缀 | /main |
√ | √ | forwarded | 未配置 | proto=http;host="192.168.2.50:9999";for="192.168.2.43:10593" |
√ | x-real-ip | 127.0.0.1 | 127.0.0.1 | |
√ | √ | host | 192.168.2.50:9999 | 192.168.2.50:8080 |
-
x-forwarded-proto:标识客户端(浏览器或其他负载均衡器)用于连接到负载均衡器的实际协议。
-
x-forwarded-host:【客户端调用服务端所使用的 ip:port】标识客户端(浏览器或其他负载均衡器)用于连接到负载均衡器的 ip:port
-
x-forwarded-for:【客户端 ip】在客户端访问服务器的过程中如果需要经过 HTTP 代理或者负载均衡服务器,可以被用来获取最初发起请求的客户端的 IP 地址。
- 格式:
X-Forwarded-For: <client>, <proxy1>, <proxy2>
-
<client>
:客户端的 IP 地址。 -
<proxy1>, <proxy2>
:如果一个请求经过了多个代理服务器,那么每一个代理服务器的 IP 地址都会被依次记录在内。也就是说,最右端的 IP 地址表示最近通过的代理服务器,而最左端的 IP 地址表示最初发起请求的客户端的 IP 地址。
- 格式:
-
x-forwarded-port:标识客户端(浏览器或其他负载均衡器)用于连接到负载均衡器的端口号。
-
x-forwarded-prefix:负载均衡服务器代理服务的前缀
-
注:上面这几个头部不属于任何一份既有规范,但是他们已经成为事实上的标准;关于负载均衡请求头的标准版本是
Forwarded
. -
forwarded:感觉是一个没用起来的规范
-
注:下面这俩可以用,但是不咋建议用
-
x-real-ip:【nginx 专属】客户端真实 ip,与
x-forwarded-for
中的是一样的 -
host:负载均衡器调用服务使用的 ip:port
?? 请求头难道不区分大小写吗
HTTP报头的名称是不区分大小写,根据RFC 2616:每个标题字段由一个名字后跟一个冒号(“:”)和字段值组成。字段名称不区分大小写(字段值可能区分大小写,也可能不区分大小写)。
注 1:所以 dqPlow 想要获取用户访问的地址的话应该这样拼接:
x-forwarded-proto[0] + :// + x-forwarded-host[0] + x-forwarded-prefix[0...n] + server.servlet.context-path + 拼接自己的路径
注2:如果在 nginx 中不配置那些 header,调用时dqPlow 服务接收到的请求头是这样的。
|-forwarded : proto=http;host="192.168.2.50:9999";for="192.168.2.43:9889"
|-x-forwarded-for : 192.168.2.43
|-x-forwarded-proto : http
|-x-forwarded-prefix : /main
|-x-forwarded-port : 9999
|-x-forwarded-host : 192.168.2.50:9999
注3:在spring体系中,可以使用 ForwardedHeaderFilter 来处理此事务,它是1个 filter 层的过滤器,将会读取 X-Forwarded- 层的头信息,并重新设置在 相应的 request.getXXX 方法上,那么在业务端通过上述这些方法即能拿到正确的数据。 同时,此过滤器也将隐藏X-Forwarded- 这些请求头,请求信息就像直接从浏览器发过来的一样的。这样一方面避免业务端来手动地处理这些请求,另一方面也避免业务端再次读取这些X-头,然后进行二次处理。
ForwardedHeaderFilter 过滤器并没有默认启动,业务端需要显示地进行启用。
需要注意的是,spring容器中有1个组件 UriComponentsBuilder,以及 ServletUriComponentsBuilder,其内部使用了跟 ForwardedHeaderFilter 一样的逻辑,但是随着版本的变更,其实际逻辑可能就跟 ForwardedHeaderFilter 逻辑不一致的。因此,在没有启用 ForwardedHeaderFilter 的场景中,请先确保 spring 的版本与当前业务期望行为一致。如 spring 5.0.X ServletUriComponentsBuilder 会读取 X-Forwarded-Prefix 头,但spring 5.1.X 就不再处理。其在官方的注释上也写得清楚,如下
<p><strong>Note:</strong> As of 5.1, methods in this class do not extract``{@code "Forwarded"} and {@code "X-Forwarded-*"} headers that specify the``client-originated address. Please, use``{@link org.springframework.web.filter.ForwardedHeaderFilter``ForwardedHeaderFilter}, or similar from the underlying server, to extract``and use such headers, or to discard them. <p><strong>注意:</strong>从 5.1 开始,此类中的方法不提取指定客户端发起的地址。请使用``{@link org.springframework.web.filter.ForwardedHeaderFilter``ForwardedHeaderFilter} 或来自底层服务器的类似内容,以提取``并使用此类标头,或丢弃它们。
并且有特定的 https://github.com/spring-projects/spring-hateoas/issues/862 与之挂接.
在实际业务中,如果没有 启用 ForwardedHeaderFilter,但想要拿到正确的请求信息,建议自己参照 ForwardedHeaderFilter中的类 ForwardedHeaderExtractingRequest,处理好信息,产生uri对象之后,再通过 UriComponentsBuilder#fromUri 来拼接地址信息。