SCTP sockets, sure, since it's a message-based protocol. HTTP/2 isn't actually a good implementation of this for real-time use due to being implemented on top of TCP. It's awkward. HTTP/3 fixes it by moving to a more modern take on SCTP with baseline authenticated encryption.
Conversation
Yes, HTTP/3 is basically HTTP/2 via QUIC with messages/streams in higher level protocol mapping to the lower-level ones.
WebRTC was built on top of SCTP over DTLS over UDP and QUIC is basically a more modern replacement for that with improved congestion control, encryption, etc.
1
2
They'll be able to update WebRTC to use QUIC instead of that homegrown protocol. They couldn't use SCTP directly and if you have to reinvent it on top of UDP you might as well apply all the things we've learned about congestion control, multiplexing, transport encryption, etc.
1
how do you mean homegrown? last time I played around with it WebRTC was, just SCTP over DTLS, which are both as far as my understanding goes quite well defined.
haven't read up onto QUIC yet, but wondering how it would do in a p2p situation
2
It's not real SCTP since that's not broadly supported and it's not SCTP-over-UDP since it has authenticated encryption and they added that below the SCTP layer rather than having the SCTP layer unencrypted and sending the encrypted traffic over that. It wasn't an existing thing.
1
1
aah like so, I just see DTLS as a transport layer since from the application side it doesn't really matter if you have a raw or dtls stream the protoco stays the same
e.g. how https is still http but just over a tls layer
the only big difference with webrtc is the rtp muxing
1
QUIC ended up just using DTLS but it's actually properly aware of it, unlike SCTP, and it doesn't end up with a separate layer of buffering/framing, etc.
QUIC actually started out with a much simpler, stripped down replacement for TLS but TLS 1.3 made TLS much less bad anyway.
1
1
They ended up just going with TLS 1.3 (DTLS variant) which is still a lot more complicated than the original QUIC encryption for Google's variant of it rather than the IETF variant. It's the main thing they changed as part of the standardization and not really for the better.
2
1
It's better if you view it as better to avoid introducing a new protocol. It's worse if you look at it in isolation in terms of TLS still having a lot of unnecessary complexity. They greatly simplified the possible states.
TLS 1.3 is simplified but not as much as QUIC did it.
2
1
It's hard for them to simplify TLS much more than they already have because of middleboxes being aware of it and doing stupid things. ECH (Encrypted Client Hello) would help enable further simplifications but that's not at all designed / meant for universal adoption.
You have to use an HTTPS record for ECH and stick your ech public keys in there so the client can get the keys needed to encrypt the connection. It's separate encryption so you can still have something like nginx.org/en/docs/stream without terminating TLS, just terminating ECH.
1
1
HTTPS records also provide an equivalent to HSTS via DNSSEC rather than it only working properly via HSTS preload lists. I find it a bit weird that they made HTTPS records as part of a SVCB/HTTPS record meant to replace SRV or even CNAME records.
1
1
Show replies