HTTP/3 is supposed to handle lost packets better than HTTP/2. I set up two machines far apart, sent real bid traffic between them, and added packet loss to measure the difference. How big that gap gets is set entirely by the path.
HTTP is how a browser and a server talk: a request goes out, a response comes back. HTTP/3, from 2022, changed the plumbing underneath. Older versions run on TCP, which hands over the data in the exact order it was sent. HTTP/3 runs on something newer, called QUIC. HTTP/2 sends many requests down one shared line at the same time. Because TCP keeps everything in order, if one packet goes missing, everything behind it has to wait for it to be resent, even the requests that already arrived. HTTP/3 gives each request its own lane, so a lost packet only holds up that one request and the rest keep moving.
That is the theory. I wanted real numbers. So I set up a mocked exchange and a bidder far apart, with their traffic going over the public internet instead of a clean line. The exchange sent real bid requests, and the bidder replied with a real bid on 1 in 100 and skipped the rest, the way a real one does. Then I added packet loss a little at a time, running the same traffic over both HTTP/2 and HTTP/3.
I put the two far apart on purpose, so even with no loss both land around 100 milliseconds, the round trip for that distance. At that baseline the two behave exactly the same. Loss is where they split, and it hits the slow requests first. Look at the slowest 1 in 20 requests. With HTTP/3 they stayed between 100 and 104 milliseconds however much loss I added, so 19 out of 20 responses were basically unaffected. With HTTP/2 those same requests climbed steadily: about 150 milliseconds at half a percent loss, 175 at one percent, and 200 at two percent. One lost packet holds up a whole batch at once.
Compare that to a bidder running inside Index Exchange’s Index Cloud datacenter, right next to the auction. Packets get lost out on the open internet, where traffic crosses many congested hops between different networks and overloaded routers drop what they cannot queue. A few meters across the datacenter’s own wiring crosses none of that, so the round trip stays under a millisecond and almost nothing is dropped. HTTP/3’s whole advantage is recovering from lost packets, and here there are almost none, which is why my test showed no gap at all with the loss switched off.
HTTP/3 is a real answer to the packet loss of the open internet, and the far-apart numbers earn it. Its benefit rises and falls with how much the path loses. Put the bidder next to the auction, and there is almost nothing left for it to fix.
