7 ms·

So this is QUIC, right?

by shmoe 3y ago

markdog12 3y ago
Well, HTTP 3 is standardized off the initial QUIC implementation (UDP), yes. Update: I guess, technically, HTTP 3 is the protocol built on top of the QUIC protocol.
- jupp0r 3y ago
  Exactly, it uses QUIC as the transport layer. You can do more with QUIC, there are beta implementations to use it for WebRTC data channels[1] and there have been experiments to use it for for WebRTC media transport, for example[2]. [1] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/... [2] https://www.w3.org/2011/04/webrtc/wiki/images/6/69/Media_over_QUIC_At_WebRTC_TPAC_2018.pdf https://www.w3.org/2011/04/webrtc/wiki/images/6/69/Media_ove...
  - still_grokking 3y ago
    WebRTC? I'm not sure WebRTC has a bright future. AFAIK nobody ever implemented WebRTC on top of QUIC. The new kid on the block is called WebTransport. WebTransport could be described in short as "WebRTC / WebSocket, the good parts". It's way simpler than WebRTC and solves some issues with WebSocket like the lack of low-latency unreliable transport (WebTransport can send Datagrams without having to use a reliable connection channel for that). A big difference to WebRTC is: All the STUN / TURN complexity is gone. WebTransport gives you at the end more or less almost "raw" QUIC streams or datagrams. It's almost like a socket interface for web user agents, only with all the features of QUIC. Given you have already HTTP/3 (which implies you have also QUIC) WebTransport is a pretty simple and slim addition on top: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/ https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht... (The only thing I'm missing is client authentication. It would be really good to do this in-band, and for example allow to send client certs with the WebTransport CONNECT request. For some reason this was left out on purpose. Only that I did not find out why actually.) What I'm not sure about is who good WebTransport would be in a P2P scenario. But given libp2p implemented WebTransport it would seem that it's good for that also. (So could replace WebRTC completely.)
    - jackewiehose 3y ago
      > A big difference to WebRTC is: All the STUN / TURN complexity is gone but STUN / TURN is there for a reason. I always thought of the P2P scenario as the main use case for WebRTC.
      - still_grokking 3y ago
        I don't know about any significant use case of WebRTC in the P2P space. OTOH, like mentioned, libp2p implemented WebTransport. So WT seems to be also adequate for the P2P use case. (No clue about the details there, though. So maybe they had to jump loops to make it happen. But it doesn't look like there would be major show stoppers.)
        jackewiehose 3y ago
        It looks like STUN/TURN can be integrated with QUIC so you don't need additional ports, but I wouldn't say "the complexity is gone" ;-) https://w3c.github.io/p2p-webtransport/ https://w3c.github.io/p2p-webtransport/ > This specification extends the WebRTC [WEBRTC], ORTC [ORTC] and WebTransport [WEBTRANSPORT] APIs to enable peer-to-peer operation using QUIC [RFC9000]. This specification supports the exchange of arbitrary data with remote peers using NAT-traversal technologies such as ICE, STUN, and TURN. As specified in [RFC7983bis], QUIC can be multiplexed on the same port as RTP, RTCP, DTLS, STUN and TURN, allowing the API defined in this specification to be utilized along with the functionality defined in [WEBRTC] and [ORTC] including communication using audio/video media and SCTP data channels.
        still_grokking 3y ago
        Oh, that's cool! :-D It implements the missing parts on top of WebTransport. I was especially sad that WT doesn't do client authentication. You can't send credentials with a CONNECT request. But this thingy adds exactly this. Great! Also having some standardized way to open QUIC Streams through NAT sounds nice. (Even I think the proper fix for this issues would just be IPv6.) Frankly it's very early days. It's not implemented, and not even considered currently. > It is not a W3C Standard nor is it on the W3C Standards Track. But as I'm currently into implementing a WebTransport lib maybe I should try to add the features form this draft. Would be funny to have a P2P ready WT lib. Only that NAT traversal part I would leave out for now, I guess, as I'm not sold on the idea that this complexity is strictly needed. NAT just needs to die finally…
superkuh 3y ago
Essentially. It's HTTP semantics on top of QUIC on top of UDP. Google and Microsoft open-washed their implementions designed for mega-corp use cases through the IETF and now it's called HTTP/3. One special feature of HTTP/3 as implemented that's really good for for-profit use cases but terrible for human person use cases is that it cannot establish a connection to a non-CA TLS endpoint. That is, you want a random internet visitor to be able to visit your HTTP/3 website, you have to get continued approval from a third party incorporated CA. This makes it pretty much useless for things like IoT and human uses at home. But it's great for things involving money.
- still_grokking 3y ago
  Could you please stop spreading uninformed FUD? > it cannot establish a connection to a non-CA TLS endpoint That's plain wrong. Self signed certificates and internal CAs work just fine. The whole point of HTTP/3 is: You can't establish an unencrypted connection. And that's a very good idea! I'm running at the very moment a HTTP/3 development server on this machine here. I did not have to ask anybody for allowance to do so. (Actually I'm right now building a WebTransport server. WebTransport has even more strict rules for certificates but even there it's still possible to connect to an endpoint that uses a self-signed cert that isn't signed by any CA cert.)
  - superkuh 3y ago
    > Could you please stop spreading uninformed FUD? Inform me then. Did you compile boringssl or openssl+quic or whatever TLS lib yourself and enable the proper flags so you could do this? You and I both know that doesn't count. You certainly can't if you're using a binary distributed browser made by Microsoft, Google, Apple, or even Mozilla. If you look at the traffic you're sending it's probably hitting the HTTP/1.1 endpoint first then going to http/3 for further traffic. Internal CAs work but that's internal and irrelevant to being able to host a visitable website to a random persons. >You can't establish an unencrypted connection. And that's a very good idea! That's a very good idea for incorporated persons and their websites that involve transfers of money and other private details. The trade-off is that the entire system is more fragile and complex and needs continous constant updating and approval from a third party corporation. These are very bad traits for making a personal website that can last more than a few years. It's bad for the longevity of the web and so it's health.

So this is QUIC, right?

by shmoe 3y ago

So this is QUIC, right?

Well, HTTP 3 is standardized off the initial QUIC implementation (UDP), yes. Update: I guess, technically, HTTP 3 is the protocol built on top of the QUIC protocol.

jupp0r 3y ago
Exactly, it uses QUIC as the transport layer. You can do more with QUIC, there are beta implementations to use it for WebRTC data channels[1] and there have been experiments to use it for for WebRTC media transport, for example[2]. [1] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/... [2] https://www.w3.org/2011/04/webrtc/wiki/images/6/69/Media_over_QUIC_At_WebRTC_TPAC_2018.pdf https://www.w3.org/2011/04/webrtc/wiki/images/6/69/Media_ove...
- still_grokking 3y ago
  WebRTC? I'm not sure WebRTC has a bright future. AFAIK nobody ever implemented WebRTC on top of QUIC. The new kid on the block is called WebTransport. WebTransport could be described in short as "WebRTC / WebSocket, the good parts". It's way simpler than WebRTC and solves some issues with WebSocket like the lack of low-latency unreliable transport (WebTransport can send Datagrams without having to use a reliable connection channel for that). A big difference to WebRTC is: All the STUN / TURN complexity is gone. WebTransport gives you at the end more or less almost "raw" QUIC streams or datagrams. It's almost like a socket interface for web user agents, only with all the features of QUIC. Given you have already HTTP/3 (which implies you have also QUIC) WebTransport is a pretty simple and slim addition on top: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/ https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht... (The only thing I'm missing is client authentication. It would be really good to do this in-band, and for example allow to send client certs with the WebTransport CONNECT request. For some reason this was left out on purpose. Only that I did not find out why actually.) What I'm not sure about is who good WebTransport would be in a P2P scenario. But given libp2p implemented WebTransport it would seem that it's good for that also. (So could replace WebRTC completely.)
  - jackewiehose 3y ago
    > A big difference to WebRTC is: All the STUN / TURN complexity is gone but STUN / TURN is there for a reason. I always thought of the P2P scenario as the main use case for WebRTC.
    - still_grokking 3y ago
      I don't know about any significant use case of WebRTC in the P2P space. OTOH, like mentioned, libp2p implemented WebTransport. So WT seems to be also adequate for the P2P use case. (No clue about the details there, though. So maybe they had to jump loops to make it happen. But it doesn't look like there would be major show stoppers.)
      - jackewiehose 3y ago
        It looks like STUN/TURN can be integrated with QUIC so you don't need additional ports, but I wouldn't say "the complexity is gone" ;-) https://w3c.github.io/p2p-webtransport/ https://w3c.github.io/p2p-webtransport/ > This specification extends the WebRTC [WEBRTC], ORTC [ORTC] and WebTransport [WEBTRANSPORT] APIs to enable peer-to-peer operation using QUIC [RFC9000]. This specification supports the exchange of arbitrary data with remote peers using NAT-traversal technologies such as ICE, STUN, and TURN. As specified in [RFC7983bis], QUIC can be multiplexed on the same port as RTP, RTCP, DTLS, STUN and TURN, allowing the API defined in this specification to be utilized along with the functionality defined in [WEBRTC] and [ORTC] including communication using audio/video media and SCTP data channels.
        still_grokking 3y ago
        Oh, that's cool! :-D It implements the missing parts on top of WebTransport. I was especially sad that WT doesn't do client authentication. You can't send credentials with a CONNECT request. But this thingy adds exactly this. Great! Also having some standardized way to open QUIC Streams through NAT sounds nice. (Even I think the proper fix for this issues would just be IPv6.) Frankly it's very early days. It's not implemented, and not even considered currently. > It is not a W3C Standard nor is it on the W3C Standards Track. But as I'm currently into implementing a WebTransport lib maybe I should try to add the features form this draft. Would be funny to have a P2P ready WT lib. Only that NAT traversal part I would leave out for now, I guess, as I'm not sold on the idea that this complexity is strictly needed. NAT just needs to die finally…

superkuh 3y ago

Essentially. It's HTTP semantics on top of QUIC on top of UDP. Google and Microsoft open-washed their implementions designed for mega-corp use cases through the IETF and now it's called HTTP/3. One special feature of HTTP/3 as implemented that's really good for for-profit use cases but terrible for human person use cases is that it cannot establish a connection to a non-CA TLS endpoint. That is, you want a random internet visitor to be able to visit your HTTP/3 website, you have to get continued approval from a third party incorporated CA. This makes it pretty much useless for things like IoT and human uses at home. But it's great for things involving money.

still_grokking 3y ago
Could you please stop spreading uninformed FUD? > it cannot establish a connection to a non-CA TLS endpoint That's plain wrong. Self signed certificates and internal CAs work just fine. The whole point of HTTP/3 is: You can't establish an unencrypted connection. And that's a very good idea! I'm running at the very moment a HTTP/3 development server on this machine here. I did not have to ask anybody for allowance to do so. (Actually I'm right now building a WebTransport server. WebTransport has even more strict rules for certificates but even there it's still possible to connect to an endpoint that uses a self-signed cert that isn't signed by any CA cert.)
- superkuh 3y ago
  > Could you please stop spreading uninformed FUD? Inform me then. Did you compile boringssl or openssl+quic or whatever TLS lib yourself and enable the proper flags so you could do this? You and I both know that doesn't count. You certainly can't if you're using a binary distributed browser made by Microsoft, Google, Apple, or even Mozilla. If you look at the traffic you're sending it's probably hitting the HTTP/1.1 endpoint first then going to http/3 for further traffic. Internal CAs work but that's internal and irrelevant to being able to host a visitable website to a random persons. >You can't establish an unencrypted connection. And that's a very good idea! That's a very good idea for incorporated persons and their websites that involve transfers of money and other private details. The trade-off is that the entire system is more fragile and complex and needs continous constant updating and approval from a third party corporation. These are very bad traits for making a personal website that can last more than a few years. It's bad for the longevity of the web and so it's health.