Network traffic forwarding over grpc port - grpc

I have a requirement where I need to forward all the request from different sources to another network by grpc.
Request Server<-> Grpc Client <-> Internet <-> Grpc Server <-> Resource Server.
Request server and grpc client on same network.
Resource server and grpc server are on same network .
How to do I forward request server request to port that is sending data to grpc server ?
MY grpc server and client are in java so using grpc-java interface.


It sounds like you want a grpc-java-based proxy. "Grpc Client" in your diagram could be any HTTP/2 proxy. But you could use grpc-java to implement it.
I made an example generic proxy a while back. It does not need any information about the methods it is proxying. You basically just create a new outbound RPC for each inbound RPC and plug the inputs of one to the outputs of the other and vise versa.

Related

I need http port forward proxy server golang

I need http port forward proxy server golang
Be able to provide Rest http api
Kind of like
PortForward Traffic Forwarding
Please tell me the program that can be used directly.
thanks

Proxying gRPC calls to REST calls

I have a usecase in which i need to call an HTTP server, the client only supports gRPC traffic. So i need a proxy in between the server and client which can convert this gRPC traffic to HTTP.

Why can HTTP/HTTPS proxy and Socks proxy work on one single port?

Many proxy soft provides multiple protocol over one port.
1.
Is there any byte (above or in TCP/UDP package) reserved to mark which protocol client is using?
As I know, HTTP protocol is just carried by TCP's data segment, and there is no any other mark.
So how proxy software tell the protocol when received a request?
(By guessing the first one or two bytes received? It doesn't sounds a good idea)
2.
What's the difference between HTTP proxy and HTTPS proxy?
Here are my guesses
"HTTP proxy" only means a service that can provide proxy for HTTP protocol, And a "HTTPS proxy" can provides service for HTTPS protocol? (means the only difference is whether they can deal HTTP CONNECT method) So the HTTPS proxy is just a functionally enhanced HTTP proxy
Or
HTTPS proxy offers extra security layer between client and proxy server? (to protect the HTTP CONNECT method headers?) So the communication process is quite different between HTTP proxy and HTTPS
proxy, and both HTTP proxy and HTTPS proxy can service HTTP/HTTPS protocol ?

Is there any byte (above or in TCP/UDP package) reserved to mark which protocol client is using?
It is not a single byte, but a HTTP request is clearly distinguishable from a SOCKS request, as a look at the respective standards (RFC 7230, RFC 1928) would show. It isn't the case that all protocols can be easily distinguished, but it is true for SOCKS and HTTP.
What's the difference between HTTP proxy and HTTPS proxy?
A HTTPS proxy is a HTTP proxy used for https:// requests. This is done by using the CONNECT method to create a tunnel through the proxy to the final server and then doing end-to-end HTTPS (TLS+HTTP) inside this tunnel.
... Or HTTPS proxy offers extra security layer between client and proxy server?
This exists too, but it is usually called "HTTP proxy over TLS", "HTTP proxy over HTTPS", "encrypted proxy connection" or similar, but not "HTTPS proxy".

Dispatching grpc requests to multiple servers via Nginx

Having a grpc client and server and they are exchanging messages in grpc unary mode. I want to log all the messages the client sends to the server without changing a single line of code in both client or server. I came across to Nginx with its new graceful grpc support. Is it possible to route grpc messages from client to server via Nginx while sending a copy of them to a remote logging service? If No, please let me know if there are any other tools out there that do the same stuff.

Why are HTTP proxies able to support protocols like IRC and FTP?

I understand that a SOCKS proxy only establishes a connection at the TCP level while an HTTP proxy interprets traffic at HTTP level. Thus a SOCKS proxy can work for any kind of protocol while an HTTP Proxy can only handle HTTP traffic. But why does an HTTP Proxy like Squid can support protocol like IRC, FTP ? When we use an HTTP Proxy for an IRC or FTP connection, what does specifically happen? Is there any metadata added to the package when it is sent to the proxy over the HTTP protocol?

HTTP proxy is able to support high level protocols other than HTTP if it supports CONNECT method, which is primarily used for HTTPS connections, here is description from Squid wiki:
The CONNECT method is a way to tunnel any kind of connection through an HTTP proxy. By default, the proxy establishes a TCP connection to the specified server, responds with an HTTP 200 (Connection Established) response, and then shovels packets back and forth between the client and the server, without understanding or interpreting the tunnelled traffic
If client software supports connection through 'HTTP CONNECT'-enabled (HTTPS) proxy it can be any high level protocol that can work with such a proxy (VPN, SSH, SQL, version control, etc.)

As others have mentioned, the "HTTP CONNECT" method allows you to establish any TCP-based connection via a proxy. This functionality is needed primarily for HTTPS connections, since for HTTPS connections, the entire HTTP request is encrypted (so it appears to the proxy as a "meaningless" TCP connection). In other words, an HTTPS session over a proxy, or a SSH/FTPS session over a proxy, will both appear as "encrypted sessions" to the proxy, and it won't be able to tell them apart, so it has to either allow them all or none of them.
During normal operation, the HTTP proxy receives the HTTP request, and is "smart enough" to understand the request to be able to do high level things with it (e.g. search its cache to see if it can serve the response without going to the destination server, or consults a whitelist/blacklist to see if this URL is allowed, etc.). In "CONNECT" mode, none of this happens. The proxy establishes a TCP connection to the destination server, and simply forwards all traffic from the client to the destination server and all traffic from the destination server to the client. That means any TCP protocol can work (HTTPS, SSH, FTP - even plain HTTP)

Resources