I'm a bit confused about this architecture. On one of the projects I'm working on, Unicorn was chosen as a Rails server. And it is put behind Nginx web server. As I understand Unicorn is fully functional web server and we don't plan to host any other Rails applications on the same server instance.
So my question would be: what are the benefits of having additional layer in chain:
client -> nginx -> unicorn -> unicorn worker
Unicorn was not designed to handle "slow clients". You can read more about this in the PHILOSOPHY help file:
Most benchmarks we’ve seen don’t tell you this, and unicorn doesn’t care about slow clients… but you should.
A “slow client” can be any client outside of your datacenter. Network traffic within a local network is always faster than traffic that crosses outside of it. The laws of physics do not allow otherwise.
Persistent connections were introduced in HTTP/1.1 reduce latency from connection establishment and TCP slow start. They also waste server resources when clients are idle.
Persistent connections mean one of the unicorn worker processes (depending on your application, it can be very memory hungry) would spend a significant amount of its time idle keeping the connection alive and not doing anything else. Being single-threaded and using blocking I/O, a worker cannot serve other clients while keeping a connection alive. Thus unicorn does not implement persistent connections.
If your application responses are larger than the socket buffer or if you’re handling large requests (uploads), worker processes will also be bottlenecked by the speed of the client connection. You should not allow unicorn to serve clients outside of your local network.
来源：https://stackoverflow.com/questions/9096533/is-it-necessary-to-put-unicorn-behind-nginx-or-apache