Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Support Proxy Protocol for gRPC and Remoting server #6957

Closed
dingshuangxi888 opened this issue Jun 28, 2023 · 0 comments · Fixed by #6958
Closed

[Feature] Support Proxy Protocol for gRPC and Remoting server #6957

dingshuangxi888 opened this issue Jun 28, 2023 · 0 comments · Fixed by #6958

Comments

@dingshuangxi888
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant