Apache httpd has one timeout knob, TimeOut which deals with timing out TCP send and receive actions if the client is not sending data to the server in a timely manner (and a few other things). This is provided at second granularity and defaults to 300 seconds. What this won't do is timeout a request that takes, say 5 seconds to process locally.
The only queue in httpd is the ListenBacklog for requests that sit on the socket listen backlog waiting to be picked up by a currently busy httpd worker thread/child. Their "Time" according to Apache doesn't start until they are picked up by a worker. You could use a small ListenBacklog setting so new requests are refused when your server starts going slow. Actually, if your clients are ending the connection after 200ms this probably doesn't matter as the backlog requests will never get started properly as http requests.
Connections only get onto the backlog when you have MaxClients or ServerLimit / ThreadLimit / TheadsPerChild connections currently in use. You may be able to tune these down to a level where your service is able to survive better.
Otherwise requests are being handled by a httpd worker child/thread and are not producing a http response in < 200ms which I suspect is what you are running into. If the response is all dealt with "in process" in httpd there's not much you can do other than fix whatever triggers the problem. If you have an application running on top of httpd producing the responses, how would it react if httpd cuts off the connection? How does the database, if one is underneath, deal with the cut off connection? Usually they carry on unbeknownst to complete the request until they try and write data back to a socket at the end. Dealing with timeouts is something that needs to be handled in your stack at each level so it works end to end.
At the levels you are talking I think you would need something wholly different to httpd to achieve your requirements. Maybe Mongrel2 with it's queue based work distribution could handle the front end timeouts more easily? Maybe a custom event based http server could handle the timeouts?. As David mentions, even TCP could struggle to deliver at the levels you are asking. The TCP component of the request doesn't even count towards server side application level timeouts you implement unless you have some smarts built in that calculate round trip times (which http doesn't).
