Today I went on an archeological expedition of Unix v7.

It’s tricky to correctly mentally model the behavior of HTTP request timeouts in most HTTP libraries. You may specify a certain “timeout” on your HTTP GET request, e.g. 5 seconds, and expect that by doing so you have a guarantee it will succeed or fail within 5 seconds. This isn’t a correct model though, in actuality your total time could reach into the hours for a timeout of “5” seconds in the Python requests library, as well as many other HTTP client libraries. This one timeout passed to requests is only one piece of what is needed to constrain the response time in a noisy network environment. I want to share a more comprehensive model of all the other timeouts in plan in the network stack, how they interact with each other, and how to control them, so that you can build an accurate mental model of how long differently configured requests can take, and can wrest full control over your run time.