[mueslix]

Instead of making sites that try to predict the unpredictable, I'd rather ask the question if TCP is still the right tool to use.

There shouldn't be a reason for a big page with many resources to not load - it should just be slower. Yet I can make the same observations as soon as my mobile signal drops to EDGE: the internet is essentially unusable as soon as there's packet loss involved and the roundtrip-times increase. Interestingly mosh often still works beautifully in such scenarios. So instead of focusing on HTTP2 or AMP (and other hacks) to make the net faster for the best-case scenario, I'd rather see improvements to make it work much more reliably in less than perfect conditions. Maybe it's time for TCP2 with sane(r) defaults for our current needs.

[Uristqwerty]

Rather than a "TCP2" that, based on name alone, would be far too likely to aim for semi-backwards compatibility but tweak a few things to be slightly better in general but mostly just better for the specific use cases of the one or three top contributing companies, why not just push for the adoption of one of the existing alternative transport layer protocols?

For example, there's SCTP. From what little I've read about it, it seems as if it has most of the benefits of both TCP and UDP, with the main downside that some firewalls and routers may need to be upgraded. Being an existing protocol, however, there are already working implementations and some amount of network support. Maybe it's even fully usable as-is today!

[tepmoc]

SCTP can't go through NAT (there is ietf draft in works for that). But SCTP already exist in your favorite browser Chrome, Firefox both use usrsctplib (https://github.com/sctplab/usrsctp) to provide sctp over udp for webrtc signaling.

But there also need to be sctp over udp over dtls (or just sctp over dtls) happen as you can't use TLS with SCTP unordered mode or multihoming.

SCTP slowly gain traction in userspace besides being only in mobile operator networks (lte)