gpt4 book ai didi

netty - 由于缺少 PSH 标志,AWS 的代理协议(protocol) v2 中断应用程序

转载 作者:行者123 更新时间:2023-12-05 04:51:49 25 4
gpt4 key购买 nike

我有一个使用 Netty 构建的网络应用程序。该应用程序位于 Amazon 网络负载均衡器之后。

我现在希望能够检索原始客户端 IP 地址,因此我在网络负载平衡器上打开了代理协议(protocol) v2 设置。

不幸的是,这样做会破坏应用程序。

可以使用 nc 或 telnet 之类的终端通过终端与应用程序进行交互。

连接到应用程序后,用户通常会收到欢迎消息,然后提示输入查询以与应用程序交互。

当代理协议(protocol) v2 打开时,在连接时,欢迎消息不再写到客户端,而是客户端看到如下内容:

telnet -4 app.host 43
Trying <IP ADDRESS>...
Connected to some_network_lb.elb.eu-west-1.amazonaws.com.
Escape character is '^]'.

捕获网络数据包时我注意到代理协议(protocol) v2 关闭时(应用程序工作正常)和打开时(应用程序无法正常工作)之间的差异

当代理协议(protocol) v2 关闭时,数据包交互可以总结如下:

No.     Time           Source                Destination           Protocol Length Info                                                            port
1 0.000000 SOURCE-IP DEST-IP TCP 78 57059 → 43 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1158853985 TSecr=0 SACK_PERM=1 43

No. Time Source Destination Protocol Length Info port
2 0.034526 DEST-IP SOURCE-IP TCP 74 43 → 57059 [SYN, ACK] Seq=0 Ack=1 Win=26847 Len=0 MSS=1420 SACK_PERM=1 TSval=3185991482 TSecr=1158853985 WS=128 57059

No. Time Source Destination Protocol Length Info port
3 0.034556 SOURCE-IP DEST-IP TCP 66 57059 → 43 [ACK] Seq=1 Ack=1 Win=132352 Len=0 TSval=1158854019 TSecr=3185991482 43

No. Time Source Destination Protocol Length Info port
4 0.067278 DEST-IP SOURCE-IP TCP 264 43 → 57059 [PSH, ACK] Seq=1 Ack=1 Win=26880 Len=198 TSval=3185991515 TSecr=1158854019 [TCP segment of a reassembled PDU] 57059

No. Time Source Destination Protocol Length Info port
5 0.067301 SOURCE-IP DEST-IP TCP 66 57059 → 43 [ACK] Seq=1 Ack=199 Win=132096 Len=0 TSval=1158854051 TSecr=3185991515 43

而当Proxy protocol v2开启时,数据包交互可以总结如下:

No.     Time           Source                Destination           Protocol Length Info                                                            port
1 0.000000 SOURCE-IP DEST-IP TCP 78 55871 → 43 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1158086997 TSecr=0 SACK_PERM=1 43

No. Time Source Destination Protocol Length Info port
2 0.040204 DEST-IP SOURCE-IP TCP 74 43 → 55871 [SYN, ACK] Seq=0 Ack=1 Win=26847 Len=0 MSS=1420 SACK_PERM=1 TSval=3185217396 TSecr=1158086997 WS=128 55871

No. Time Source Destination Protocol Length Info port
3 0.040227 SOURCE-IP DEST-IP TCP 66 55871 → 43 [ACK] Seq=1 Ack=1 Win=132352 Len=0 TSval=1158087035 TSecr=3185217396 43

从上面可以看出,当Proxy Protocol v2开启时,数据包交换停止在第三次交换,服务器再也没有发送第4次数据包交换,其中包含[PSH, ACK] 当代理协议(protocol) v2 关闭时。

知道为什么会这样吗?为什么当代理协议(protocol) v2 打开时,带有 [PSH, ACK] 标志的数据包从不发送?关于如何解决此问题的任何提示?

最佳答案

我们不得不联系 AWS 支持以帮助设置目标组属性proxy_protocol_v2.client_to_server.header_placement 到 NLB 目标组上的 on_first_ack。

默认情况下尝试设置属性是行不通的。但是一旦 AWS 启用它,更新属性的命令将如下所示:

“aws elbv2 modify-target-group-attributes --target-group-arn arn:aws:elasticloadbalancing:us-east-2*************************** --attributes ‘{“Value”: “on_first_ack”, “Key”: “proxy_protocol_v2.client_to_server.header_placement”}’ ”

对我们来说,这是由于我们的应用程序的性质,在建立连接后客户端不会发送任何数据,而且这不是开箱即用的,因为 header 是延迟推送的。

你可以阅读这个 link有关此行为的更多信息

关于netty - 由于缺少 PSH 标志,AWS 的代理协议(protocol) v2 中断应用程序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/66770798/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com