It should be noted that IP fragmentation is quite limited and often buggy. IPv6 only requires receivers to re-assemble an IP packet that is at most 1500 bytes, so sending a 65KB TCP segment is quite likely to just result in dropped packets.
Alternatively, the 1500 limit is not a hard limit, and depends entirely on your link. Jumbo frames (~9000 bytes) and even beyond are possible if all the devices are configured in the right way. Additionally, IPv6 actually supports packets up to ~4GiB in size (so called "jumbograms", with an additional header), though I think it would be truly hard to find any network which uses this feature.
BTW, you don’t have to rent servers on opposite sides of the planet just to increase network latency for testing.
tc qdisc add dev eth0 root netem delay 200msSo, is this a DoS technique or what? Or trying to avoid TCP side transmission rate limits, which anyway should be implemented IP side?
This technique is briefly discussed in chapter 5.3.1 in the master thesis "Exploiting Race Conditions in Web Applications with HTTP/2" - https://ntnuopen.ntnu.no/ntnu-xmlui/handle/11250/2781157
The same paper is also referenced to by James Kettle in his research.
I assume with HTTP/1.1 this would be less useful, since each synchronized request would require another socket, thus hitting potential firewalls limiting SYN/SYN-ACK rate and/or concurrent connections from the same IP.
In some respects this is abusing the exact reason we got HTTP/3 to replace HTTP/2 – it's a deliberate Head-of-Line (HoL) blocking.
This title is about as apt as my username
"Its not clear why TCP settled on such an oddly specific number"
Please don’t correct the title, it’s delightful as it is.