Historically, reverse proxies were invented to manage a large number of slow connections to application servers which were relatively resource intensive. If your application requires N bytes of memory per transaction then the time between the request coming in and the response going out could pin those bytes in memory, as the web server can’t move ahead to the next request until the client confirms it got the whole page.
A reverse proxy can spool in requests from slow clients, when they are complete, then hand them off to the app servers on the backend, the response is generated and sent to the reverse proxy, which can slowly spool the response data out while the app server moves onto the next request.
Historically, reverse proxies were invented to manage a large number of slow connections to application servers which were relatively resource intensive. If your application requires N bytes of memory per transaction then the time between the request coming in and the response going out could pin those bytes in memory, as the web server can’t move ahead to the next request until the client confirms it got the whole page.
A reverse proxy can spool in requests from slow clients, when they are complete, then hand them off to the app servers on the backend, the response is generated and sent to the reverse proxy, which can slowly spool the response data out while the app server moves onto the next request.