Two techniques, even: More requests processed at once, after a very (bandwidth-adjusted) precisely user-controlled starting point. One helps with race conditions in the server, the other helps racing 3rd party requests. Sending a highly-efficient "go" packet for many HTTP requests is sure ruining the fun for all the others awaiting some pre-announced concert ticket / GPU sale to open.

If the website accounting is merely "eventually consistent" between threads/servers and you are able to fire many (large) requests at a precise (determined by small packet) point in time, both techniques work in tandem - could have (one of) your post(s) appear with repeating digits (such as at https://news.ycombinator.com/item?id=42000000) without just seeing "Sorry, we're not able to serve your requests this quickly."

I think it's ultimately about bypassing a TOTP 2FA by exploiting a race condition in the authentication failure backoff timer to submit thousands of possible codes simultaneously. The technique is about abusing the TCP stack and IP fragmentation to load up the stack on the server with as much data as possible before hitting it with a "go" packet that completes the fragments on the head of line blocking data buffer and spills all of the contents into the webserver before a single RTT can be completed.

Many real-world web applications “shockingly” don’t guarantee ACID-style transactional state updates, and thus are vulnerable to race conditions.

Suppose (for instance) that the application tier caches user session information by some internal, reused ID.

If that state is updated transactionally, with an ID assigned to a new session atomically with the insertion of that new session’s data, no problem.

But if the session is assigned a previously used ID a few microseconds before the new session’s data is populated, a racing request could see the old data from a different user.

AFAICS this is about exploiting race condition bugs that require a large number of requests to be processed almost-simultaneously.