4 ms·

Can someone provide the tradeoffs and benefits of QUIC vs WebSockets vs WebRTC? I know websockets are tcp and WebRTC requires some special tunneling logic but

Can someone provide the tradeoffs and benefits of QUIC vs WebSockets vs WebRTC? I know websockets are tcp and WebRTC requires some special tunneling logic but aside from that I don't particularly know how quic is better or different aside from using udp.

jeffbee 6y ago
That's it. UDP is why it's better. It disintermediates operating system developers and their badly-tuned, slowly-evolving TCP implementations.
- pmlnr 6y ago
  Right, because all we ever need it is more complexity, no backwards compatibility, and more speed in all terms /s Come on. Networks are extremely FAST by now, TCP or not. It's the silly amount of JS computation pushed to the client that is slow, both in download speed and on the client.
  - Spivak 6y ago
    But we have backwards compatibility right now. That's, like, the whole point of the OSI model. Any device that supports UDP can handle QUIC with no fanfare like it was any other application-layer protocol because it is!
    - pmlnr 6y ago
      We have fallbacks, that's not the same as backwards compatibility. They call this HTTP3, and they shouldn't; it's not HTTP.
      - Spivak 6y ago
        That was the case with HTTP2 as well though. The client can negotiate with the server about supported protocols but if a client only spoke HTTP1.1 and the server only spoke HTTP2 they simply couldn't talk. It's just that basically no servers were HTTP2 only.
- dsr_ 6y ago
  The protocol stack is open to contributions on Linux, FreeBSD, OpenBSD and DragonflyBSD; while Microsoft and Apple don't take contributions, their developers do go to the same conferences and InterOps that everybody else goes to. If there's a general tuning problem in TCP implementations, the cycle time for getting it fixed should be around 2 years from discovery to all regularly updated machines getting the fix. Given global impact, that seems pretty reasonable to me.
  - jeffbee 6y ago
    The actual history of "open" contributions to the Linux TCP stack is one of vehement opposition. Basic things like SYN retransmission remain hard-coded to constants that were (arguably) appropriate in the 1970s.
- toast0 6y ago
  Yep, Google won't tune TCP on Android, so they're abandoning it in favor or TCP over UDP.
jjice 6y ago
From what I understand, QUIC is a lower level protocol near TCP and UDP which uses UDP as it's base for transport. Currently, HTTP/2 can multiplex streams, but if one has an error, all must be stopped while TCP fixes it. In QUIC they use UDP, which doesn't do error checking, so QUIC implements the error checking itself. QUIC will handle the error checking while the UDP streams continue to deliver at the same time. This is all based on my brief reading of the QUIC Wikipedia article, so take my knowledge with a grain of salt, but I think that my above summary fits. Wikipedia at relevant anchor: https://en.wikipedia.org/wiki/QUIC#Background https://en.wikipedia.org/wiki/QUIC#Background
- jabart 6y ago
  Error in this context is a missing packet causing a delay and a request for a retransmit blocking the TCP connection at the OS/Kernel while it waits for the missing packet before sending it to the application. UDP packets have checksums, its what network switches use to check before sending the packet on or dropping the packet. Other benefit is UDP doesn't have a window size (buffer). Which is part of the design when computers had ram measured in K instead of GB (Hey my buffer is full, stop). The chatty nature of TCP reduces download speeds across larger physical distances. Its why download managers spin up multiple threads to download part of a file to work around it.
Hamcha 6y ago
The difference is literally using UDP over TCP. The problem QUIC tries to solve is that many of TCP's design decisions were made in a different environment that the one we live today (eg. being able to switch between from 2 internet sources like Wi-Fi and mobile data while retaining connections). Plus, it integrates TLS in it to reduce protocol overhead. IIRC even UDP isn't ideal, the reason for choosing it over making a brand new protocol was to avoid network devices like routers dropping packets that they wouldn't recognize. WebSockets is just an abstraction over a reliable protocol (TCP), therefore, WebSockets could theoretically work over QUIC too.
- chungus_khan 6y ago
  The internet is a large cluster of workarounds for design decisions made in the 1970s, a truly beautiful time. A time before anyone imagined the need for a system to authenticate who is sending mail or from what server. A time when a "network connection" was a big ass permanent wire into a deeply imperfect network. A time where someone intercepting the communications on that wire was an afterthought. A time where even when things were encrypted, DES was considered an acceptable cipher. Unfortunately today's internet has needed to be a continuum of newer stuff that still has to work with the older stuff. Such is life.
- sippingjippers 6y ago
  This is a fairly drastic simplification. There are a bunch of different pieces of QUIC, (not least, sorry I'm not authoritative either) - SSL and "TCP" handshake are collapsed into a single transaction - That transaction is worst case 1 network roundtrip, best case (returning user) 0 roundtrips - Anti-filtering baked in. Quic reveals almost nothing for middleboxes to filter on. There is not yet an accepted solution for encrypting the target server name (SSL SNI) but that's still being worked on AFAIK - "Modern" congestion control approach, where "modern" means "fuck any TCP connections sharing the link"
oscargrouch 6y ago
Not an expert, but.. QUIC is basically HTTP2 (bidi frames and keep-alive connections) over (TCP over UDP) with encryption builtin. The cool thing about QUIC also, is the ability to 'lower down' to the UDP layer and skip the control and encryption protocol if you need it. (I just dont know if they will extend this feature to the application level). WebRTC is SRTP with UDP have hole punching et al. if you want so use UDP but with a whole problems of the UDP approach P2P world already taken care of. WebSockets works over plain TCP. QUIC is the more advanced of the protocols and it will probably "take over the world" with time, but it has yet to prove itself. It probably can be a good fit to the cases where the WebRTC is being used for, but i dont now if Chrome will be ambitious enough to let developers mess with the building blocks of QUIC. If not, it will just become a sink to HTTP3 (a no small feat anyway).

jeffbee 6y ago

That's it. UDP is why it's better. It disintermediates operating system developers and their badly-tuned, slowly-evolving TCP implementations.

pmlnr 6y ago
Right, because all we ever need it is more complexity, no backwards compatibility, and more speed in all terms /s Come on. Networks are extremely FAST by now, TCP or not. It's the silly amount of JS computation pushed to the client that is slow, both in download speed and on the client.
- Spivak 6y ago
  But we have backwards compatibility right now. That's, like, the whole point of the OSI model. Any device that supports UDP can handle QUIC with no fanfare like it was any other application-layer protocol because it is!
  - pmlnr 6y ago
    We have fallbacks, that's not the same as backwards compatibility. They call this HTTP3, and they shouldn't; it's not HTTP.
    - Spivak 6y ago
      That was the case with HTTP2 as well though. The client can negotiate with the server about supported protocols but if a client only spoke HTTP1.1 and the server only spoke HTTP2 they simply couldn't talk. It's just that basically no servers were HTTP2 only.
dsr_ 6y ago
The protocol stack is open to contributions on Linux, FreeBSD, OpenBSD and DragonflyBSD; while Microsoft and Apple don't take contributions, their developers do go to the same conferences and InterOps that everybody else goes to. If there's a general tuning problem in TCP implementations, the cycle time for getting it fixed should be around 2 years from discovery to all regularly updated machines getting the fix. Given global impact, that seems pretty reasonable to me.
- jeffbee 6y ago
  The actual history of "open" contributions to the Linux TCP stack is one of vehement opposition. Basic things like SYN retransmission remain hard-coded to constants that were (arguably) appropriate in the 1970s.
toast0 6y ago
Yep, Google won't tune TCP on Android, so they're abandoning it in favor or TCP over UDP.

jjice 6y ago

From what I understand, QUIC is a lower level protocol near TCP and UDP which uses UDP as it's base for transport. Currently, HTTP/2 can multiplex streams, but if one has an error, all must be stopped while TCP fixes it. In QUIC they use UDP, which doesn't do error checking, so QUIC implements the error checking itself. QUIC will handle the error checking while the UDP streams continue to deliver at the same time. This is all based on my brief reading of the QUIC Wikipedia article, so take my knowledge with a grain of salt, but I think that my above summary fits. Wikipedia at relevant anchor: https://en.wikipedia.org/wiki/QUIC#Background https://en.wikipedia.org/wiki/QUIC#Background

jabart 6y ago
Error in this context is a missing packet causing a delay and a request for a retransmit blocking the TCP connection at the OS/Kernel while it waits for the missing packet before sending it to the application. UDP packets have checksums, its what network switches use to check before sending the packet on or dropping the packet. Other benefit is UDP doesn't have a window size (buffer). Which is part of the design when computers had ram measured in K instead of GB (Hey my buffer is full, stop). The chatty nature of TCP reduces download speeds across larger physical distances. Its why download managers spin up multiple threads to download part of a file to work around it.

Hamcha 6y ago

The difference is literally using UDP over TCP. The problem QUIC tries to solve is that many of TCP's design decisions were made in a different environment that the one we live today (eg. being able to switch between from 2 internet sources like Wi-Fi and mobile data while retaining connections). Plus, it integrates TLS in it to reduce protocol overhead. IIRC even UDP isn't ideal, the reason for choosing it over making a brand new protocol was to avoid network devices like routers dropping packets that they wouldn't recognize. WebSockets is just an abstraction over a reliable protocol (TCP), therefore, WebSockets could theoretically work over QUIC too.

chungus_khan 6y ago
The internet is a large cluster of workarounds for design decisions made in the 1970s, a truly beautiful time. A time before anyone imagined the need for a system to authenticate who is sending mail or from what server. A time when a "network connection" was a big ass permanent wire into a deeply imperfect network. A time where someone intercepting the communications on that wire was an afterthought. A time where even when things were encrypted, DES was considered an acceptable cipher. Unfortunately today's internet has needed to be a continuum of newer stuff that still has to work with the older stuff. Such is life.
sippingjippers 6y ago
This is a fairly drastic simplification. There are a bunch of different pieces of QUIC, (not least, sorry I'm not authoritative either) - SSL and "TCP" handshake are collapsed into a single transaction - That transaction is worst case 1 network roundtrip, best case (returning user) 0 roundtrips - Anti-filtering baked in. Quic reveals almost nothing for middleboxes to filter on. There is not yet an accepted solution for encrypting the target server name (SSL SNI) but that's still being worked on AFAIK - "Modern" congestion control approach, where "modern" means "fuck any TCP connections sharing the link"

oscargrouch 6y ago

Not an expert, but.. QUIC is basically HTTP2 (bidi frames and keep-alive connections) over (TCP over UDP) with encryption builtin. The cool thing about QUIC also, is the ability to 'lower down' to the UDP layer and skip the control and encryption protocol if you need it. (I just dont know if they will extend this feature to the application level). WebRTC is SRTP with UDP have hole punching et al. if you want so use UDP but with a whole problems of the UDP approach P2P world already taken care of. WebSockets works over plain TCP. QUIC is the more advanced of the protocols and it will probably "take over the world" with time, but it has yet to prove itself. It probably can be a good fit to the cases where the WebRTC is being used for, but i dont now if Chrome will be ambitious enough to let developers mess with the building blocks of QUIC. If not, it will just become a sink to HTTP3 (a no small feat anyway).