Reverse proxy: why isn't sending a response a bottleneck?
When a reverse proxy is used primarily for load balancing, it is obvious why routing requests to a pool of N proxies should help balance the load.
However, once the server computation for the requests is complete and it is time to send the responses back to their clients, why does a single reverse proxy never become the bottleneck?
My intuitive understanding of the reverse proxy concept tells me,
-
that a reverse proxy that proxies N origin servers behind it will obviously NOT bottleneck as easily or already with a setup using the single server equivalent of N proxies, BUT that too will bottleneck at some point because everything responses from N proxies go through it.
-
to delay the aforementioned kind of bottleneck (from reaching) even further, the N proxies must actually send responses directly to the client "somehow", instead of doing it through the single reverse proxy sitting in front of them.
Where am I going wrong with my understanding of the reverse proxy concept? Maybe point # 2 is NOT by definition the reverse proxy setting, but keeps the definitions aside, why is # 2 not popular over the reverse proxy option?
source to share
The reverse proxy used for load balancing proxies all traffic to the origin server pool. This means that the client's TCP connection ends at the LB (reverse proxy) and the LB initiates a new TCP connection to one of the origin nodes on behalf of the client. Now the node, after processing the request, cannot directly communicate with the client because the client's TCP connection is open to the Load Balancer's IP address. Client expects a response from LB, not any other random dude or random IP(-: from some node. So the response usually flows the same way as the request through LB. Also, you don't want to expose the IP address of the node to the client. This usually scales very well for request-response systems. So my answer to # 1: LB usually scales well for system challenge-response, if at all needed, more LBs can be added to create redundancy behind the VIP.
Now that said, it still makes sense to bypass LB for writing answers if your answers are huge . For example, if you stream a video in response, then you probably don't want you to suppress your LB with huge responses. In such a scenario, Direct Server Return LB can be configured . This is essentially what you think of in # 2. It allows you to respond to streams directly from origin servers, bypassing LBs and still hiding host IPs from clients. This is accomplished by configuring ARP in a special way so that responses written by origin nodes have the IP address LB. It is not easy to set up and normal LB proxy mode is fine for most use cases.
source to share