You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the RocketMQ client accesses the RocketMQ server through multiple layers of NAT or TCP proxies, the server is unable to obtain the actual IP address information of the client. In such cases, the HAProxy's Proxy Protocol can be introduced to transparently pass the initial TCP connection information of the client. This allows the server to accurately identify the source of message production and consumption.
The PROXY protocol provides a convenient way to safely transport connection information such as a client's address across multiple layers of NAT or TCP proxies. It is designed to require little changes to existing components and to limit the performance impact caused by the processing of the transported information.
When a RocketMQ client accesses the RocketMQ server through NAT or TCP proxies that support the Proxy Protocol, the RocketMQ server needs to support the recognition and parsing of these packets. Throughout the subsequent processes of message production and consumption, the server should be able to retrieve the client's IP address and other relevant information from these packets. This information should be set in the message's attributes, traces, and logs.
Describe Alternatives You've Considered
For the Remoting protocol, I have incorporated the HAProxyMessageDecoder class provided by Netty and set it in the pipeline of the request. This decoder is used to parse the proxy protocol data transmitted by the client's connection.
For the gRPC protocol, since it does not include Netty's HAProxy package, it need to perform shading and packaging. At the ProtocolNegotiator layer, we can set the HAProxyMessageDecoder in the pipeline of the request to parse the proxy protocol data transmitted by the client's connection.
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Is Your Feature Request Related to a Problem?
When the RocketMQ client accesses the RocketMQ server through multiple layers of NAT or TCP proxies, the server is unable to obtain the actual IP address information of the client. In such cases, the HAProxy's Proxy Protocol can be introduced to transparently pass the initial TCP connection information of the client. This allows the server to accurately identify the source of message production and consumption.
The PROXY protocol provides a convenient way to safely transport connection information such as a client's address across multiple layers of NAT or TCP proxies. It is designed to require little changes to existing components and to limit the performance impact caused by the processing of the transported information.
For more information, you can obtain it from the following link: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt.
Describe the Solution You'd Like
When a RocketMQ client accesses the RocketMQ server through NAT or TCP proxies that support the Proxy Protocol, the RocketMQ server needs to support the recognition and parsing of these packets. Throughout the subsequent processes of message production and consumption, the server should be able to retrieve the client's IP address and other relevant information from these packets. This information should be set in the message's attributes, traces, and logs.
Describe Alternatives You've Considered
For the Remoting protocol, I have incorporated the HAProxyMessageDecoder class provided by Netty and set it in the pipeline of the request. This decoder is used to parse the proxy protocol data transmitted by the client's connection.
For the gRPC protocol, since it does not include Netty's HAProxy package, it need to perform shading and packaging. At the ProtocolNegotiator layer, we can set the HAProxyMessageDecoder in the pipeline of the request to parse the proxy protocol data transmitted by the client's connection.
Additional Context
No response
The text was updated successfully, but these errors were encountered: