If we did not have to deal with the two problems you identify (direct communication peer to peer - effectively the NAT problem with IPv4 - and current firewall practice), then SCTP would be worth a look. I'm not a low-level network expert, and I haven't looked at QUIC in detail, but from the article it seems that SCTP addresses the issues raised in the article. It is a transport protocol on the same level as TCP and UDP, and originally devised for telecoms to transport SS7 signalling information. It's a very good fit to SIP, which is where I came across it.
A long-term connection is established between peers, as for TCP, but this can use multiple redundant paths rather than a single path. Within that connection, multiple independent streams with reliable transmission can exist - which relates to the RPC problem raised in the article, and to situations such as requesting parts of a web page in parallel.
NAT might not be a huge problem, as the protocol does have source and destination ports. One could also envision a proxy on a client device to translate HTTP/TCP to HTTP/SCTP for browsers not yet using SCTP directly. However home routers would probably be an insurmountable obstacle to widespread adoption, and neither Windows nor MacOS currently support SCTP.
My understanding here is that some of why QUIC is built the way it is (on top of UDP) is in somewhat direct response to lessons learned from SCTP, including and especially how hard it is route SCTP in practice on today's internet.
Comments
If we did not have to deal with the two problems you identify (direct communication peer to peer - effectively the NAT problem with IPv4 - and current firewall practice), then SCTP would be worth a look. I'm not a low-level network expert, and I haven't looked at QUIC in detail, but from the article it seems that SCTP addresses the issues raised in the article. It is a transport protocol on the same level as TCP and UDP, and originally devised for telecoms to transport SS7 signalling information. It's a very good fit to SIP, which is where I came across it.
A long-term connection is established between peers, as for TCP, but this can use multiple redundant paths rather than a single path. Within that connection, multiple independent streams with reliable transmission can exist - which relates to the RPC problem raised in the article, and to situations such as requesting parts of a web page in parallel.
NAT might not be a huge problem, as the protocol does have source and destination ports. One could also envision a proxy on a client device to translate HTTP/TCP to HTTP/SCTP for browsers not yet using SCTP directly. However home routers would probably be an insurmountable obstacle to widespread adoption, and neither Windows nor MacOS currently support SCTP.
My understanding here is that some of why QUIC is built the way it is (on top of UDP) is in somewhat direct response to lessons learned from SCTP, including and especially how hard it is route SCTP in practice on today's internet.