I could be inclined to believe it but I'd like to know by which factor, in which circumstances, with real examples and numbers.
Start with QUIC vs. TCP. Same OS, same client/server software.
Edit: since the system says "I'm posting too quickly, slow down" despite not posting for an hour because they don't use accurate error messages here, let me say :
I find it ironic that so many keystrokes below are used in a meta-discussion about the quality of comments here, when others are posed a legitimate question about the topic. Nevermind the article they seem to defend gets the order of a TCP 3 way handshake wrong.
And since I can't respond to them, I can only d*wnv*te or fl*g them.
So really, is it faster? Does it reduce the amount of load on network devices? Does it allow a server to serve more connections more quickly than the equivalent HTTP/2.0 stack? Does it make my web app faster?
I mean, for 99% of Wordpress sites the problem is Wordpress, not the transport protocol. For a lot of the web the problem is client-side rendering issues.
QUIC may solve a problem, but is it a problem in real life or a thought experiment that got folded into a standard?
This is not a goal of QUIC: Ideally, network devices between two TCP hosts don't do anything to TCP segments that they wouldn't also do to UDP datagrams, so there shouldn't be much difference.
> I mean, for 99% of Wordpress sites the problem is Wordpress, not the transport protocol.
Addressing Wordpress problems or rendering issues is also not really a stated goal of QUIC.
It does solve some real TCP inefficiencies though, especially when used on older OS/kernel versions that'll probably never be updated to make use of some of the newer developments there (Bufferbloat avoidance is a big one, for example).
These might not be very high on your list, but they absolutely are on someone's. And as long as you don't host your own webserver, you don't need to do anything to benefit from the results, since your hoster/CDN/proxy will just transparently provide them for you.
Latency was exceptionally improved. Web pages felt like the loaded faster and at the very least, users could not tell that they were using an encrypted connection.
The protocol essentially worked using a fast-ACK protocol that would preemptively request retransmits (and was occasionally wrong). This enabled it to use connectionless UDP protocol as the underlying transport mechanism. There is, of course, a cost for reduced latency. That cost was slightly higher bandwidth utilization on the network. This was suboptimal for long-lived streams (media and other downloads) so we tried to fault over to ordinary TCP in these instances.
I have no clue why it's built on UDP though, do we just accept that the time has passed for truly new network protocols?
I mean I get why you'd tunnel it through a UDP connection, since replacing every single router on the planet no longer seems feasible, but if you want to call it a transport level protocol that's kind of what you'd have to do.
Yes. According to my research, the Internets middleboxes are ossified and if they see a packet that’s not UDP or TCP they will silently drop it. SCTP was an past attempt to introduce a new protocol AFAIK https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...