> “[For HTTP/2], we just need to make sure that both requests are placed in a single packet (e.g. by writing both to the socket at once)“ And then looking at th

> “[For HTTP/2], we just need to make sure that both requests are placed in a single packet (e.g. by writing both to the socket at once)“ And then looking at the order of the packages when they get back. It's not that simple however: What most web servers will do do when getting HTTP/2 HEADERS frame is initiating new "requests" and setting up associated request handlers. Those are often a bunch heap allocated objects and callbacks, but you could also have individual threads for each request. Those will then all be scheduled in a more or less independent fashion. E.g. in a Go based webserver each request which serves a HTTP/2 stream is still an independent Goroutine, which gets scheduled indpendent from all other HTTP/2 streams. Now even if all the request handler is doing a returning a static "hello world" response, it would still not guaranteed that the response for request B which was sent behind request A would immediatly follow response A - there could still be other requests handled in between - or they could be handled in reverse order. Chances of ordering being maintained are highest with a rather primitive singlethreaded webserver. The next thing is however that most webservers will perform some kind of useful work which prevents them from responding immediately - they will wait for an upstream webserver, database, or just for a filesystem operation to complete. These will all introduce time variations that are rather high.