James Kettle published research on exploiting race conditions more relably by putting things in the same packet. However, the author of this post ran into a limitation of this - the allowed for size of TCP and other size limits. They looked on how to bypass this limitation.
The single packet packet has a 1500 byte limit, each means that only 20-30 requests can be made at a time. This limitation is because of the Ethernet's maximum frame size of 1518 bytes. What's weird though, is that TCP supports 65535, but how? IP fragmentation can be used to divide the original packet into different Ethernet frames but be processed together since the packet won't be processed until all data has been received.
Even with this, the packet size is limited. How else can we expand this? TCP is ordered with a sequence number. By reversing the order of packets to account for this, all packets will be processed at the same time - genius! Using this, we can make packets be infinite in size without worrying about timing issues.
HTTP/2 puts a wrench into this, sadly. There is a maximum amount of concurrent streams open in most settings that is under 250 for Apache, Nginx and Go but unlimited for NodeJs and some others.
How do we configure this stuff to happen? First, they configured their IP tables to not send RST packets. Then, they just wrote their own client to change the ordering of TCP. Using this, it's possible to exploit limit overrun rate limiting issues as well.
The tool is a little rough right now. It doesn't support HTTPs over HTTP, TCP window updating or any proxy tools. Overall, an awesome post to hype up the possibility of race conditions and other issues.