Webrick is a single-thread, single-process web server.
Webrick will keep the router's connection open until it has downloaded the entirety of the request from the router. The router then will move on to the next request. Webrick server will then take the request, run the application code and send back the response to the router.
During the all of time, your host is busy, and will not accept connections from other routers. If the router attemps to connect to this host while the request is being processed, the router will wait until the host is ready.
The problem with Webrick are exaggerated with slow requests and uploads. If someone is trying to upload a big file, Webrick is going to sit there and wait while the request downloads, and will not download anything in the meantime, and it also will not accept any requests.
Webrick can't deal well with slow client request or slow application responses.
Thin is an event-driven, single-process web server.
Thin uses EventMachine under the hood, which gives you some benefits, in theory. Thin opens a connection with the router and starts accepting parts of the request. But, if suddenly that request slows down or data stops coming in through the socket, Thin will go off and do something else. No matter how a slow client is, Thin can go off and receive other connections from other routers in the meantime.
Only when a request is fully downloaded will Thin pass the request to application. In fact, Thin will write very large request (like uploads) to a temporary file on the disk
Thin is multi-thread, not multi-process. Thin can't accept other request while waiting for I/O in the application code to finish. For example - if your application code POSTs to a payments service for credit card authorization, Thin cannot accept new requests while waiting for that I/O operation to complete by default.
Unicorn is a single-threaded, multi-processes web server.
Unicorn spawns up a number of "worker processes" (app instances) and those processes all sit and listen on a single Unix socket, coordinated by "master process".
So, when a connection request comes in from a a host, it doesn't go to master process, but instead directly to the Unicorn socket where all of the worker processes are waiting and listening.
A worker process (only listening on the socket because it's not processing a request) accept the request from the socket. It waits on the socket until the request is fully downloaded and then stop listening on the socket to go process the request. After it's done processing the request and sending the response, it listens on the socket again.
While downloading the request off the socket, Unicorn workers can't accept any new connection and that worker become unavailable.
Basically, you can only serve many slow requests as you have Unicorn workers. For example, if you have 3 Unicorn workers and 4 slow requests that take 3000 ms to download, the fourth request will have to sit and wait while other requests are processed.