these both seem like 100% legit things to do via http
Conversation
Replying to
It was 100% legitimate before WebSockets. HTTP/2 obsoletes WebSockets outside the browser since you can multiplex bidirectional streams over the same persistent connection. WebSockets are now essentially just a workaround for not having access to that from JS in a browser.
2
saying http/2 obsoletes websockets sounds like a bit of a stretch, but look at what people actually used it and pushed others to use it for I can see why that can be a conclusion
2
It has bidirectional binary streams. It essentially has a more flexible equivalent to WebSockets at the protocol level instead of built on top of it. It's a separate thing from the push feature. They essentially built the WebSocket functionality into it.
2
Replying to
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.
2
1
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.
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
Show replies