So the room is full today, thank you for coming so we are going to start so I'd like
to welcome one of my colleague, Max from Berlin, who is going to talk about WebTonSpof.
Thank you very much, thanks for so many people showing up here, it seems to be a very
popular topic, appreciate all your attention, it's wonderful.
Okay, I want to give an introduction to WebTonSpof and I want to post this as a question
whether it's going to be the next WebSockets in the Web.
I'm Max from a software developer at Mozilla, I'm working on Firefox's networking stack,
and within the Firefox networking stack I mostly focus on HTTP theory and quick, and
we'll have plenty of talking points here about HTTP theory and quick, I'd do it you all
in with a phrase a WebTonSpof, we're really what I'm going to talk about here is quick
in HTTP 3 and all the properties that we can then pass up to the higher levels.
And very much a level of transport person, so be with me, I love it here.
If you want to learn more about me, this is my home page, obviously reach out to me, I'm going
to be here, I don't think I'm going to take the whole time, so I'm going to be here
for questions in the room, I'm also going to do questions afterwards outside, so if you
would be free to find me there, or send me an email or anything, but like, okay, before
we can talk about the next WebSockets, let's first talk about WebSockets itself, and
quick show of hands, who here has used WebSockets, all right, let's need one, who has programmed
against WebSockets as an operating, some kind of WebSocket like service, okay, wonderful,
okay, three years heard about WebTransport, who is using WebTransport?
Wow, brave soul, all right, and so, back to WebSockets, it's a very established Web API today
that as a Web application gives you a single reliable, bi-directional, ordered by stream
from the client to the server, as in from the web context in the browser, you can then communicate
to the server, and basically can do with that or whatever you want, started off on
HP1, in December 2011 that was standardized as was a tier RC6455, so quite early, and
what it gives you on HP1, HP1 is built on top of TCP, we'll go a little bit into that,
it gives you a single session, so it upgrades the whole TCP connection to a WebSocket stream.
Yeah, later on, we got HP2, great, wonderful, HP2 has streaming in there, right, you can
have multiple streams, and so then also came WebSockets on top of HP2, that was in 2018,
and it gives you the ability to run many WebSockets connections over one HP2 connection,
or many WebSockets, let's call them sessions.
Later on, we got X4 lucky and got HP3, and that's the thing I'm very excited about, and
folks also standardized WebSockets on top of HP3, now great, we get multiple streams,
we get very mechanism against takeoff line blocking, wonderful, turns out no one really
implemented, I'm not aware of any major deployment out there, nor am I aware of any browser
engine implementing it, if you have plans around that, please reach out to me, I'm interested
to chat about it, so yeah, we have two ways to run WebSockets on HP1, HP2, HP3, not really.
Where are we in the internet stack when we're talking about WebSockets, all of you are
currently familiar with IPv4, IPv6, then we have the two pillars on the left, both running
on top of TCP, we have some kind of security layer, so TLS 1.3 preferably, and then we
have HP1, HP2 running on top of that, that gives us HP semantics, so get post-put, and so on,
and then with those HP semantics, we can then do the upgrade of going from a standard
HTTP connection to a WebSockets stream, we can do that on HP1, HP2, as I said, there's
the standard for HP3, but I'm not aware of any deployments out there, so not really
usable there.
So we are very much constrained to whatever TCP gives us, on higher level, we cannot get
anything more than what our lower levels make available to us, and this is very much where
a lot of downsides come from for WebSockets, and I want to walk through through the various
downsides here, you already have one on the screen, and then later on, well, we are of course
going to compare that to WebTransport, so first thing, very WebSockets specific, the WebSockets
upgrade, you see this pattern a lot, when you look at various web implementations, usually
you have a one-round-trip upgrade mechanism, so on the very left here you see the HP upgrade
to WebSockets, the client is requesting it, the server says one-on-one switching protocol,
all good, let's go, and then you have a bidirectional stream, but this unfortunately
costs you a whole round trip, right, as in, let's say you have a 30 millisecond round trip
time, then you're already paying for a round trip on TCP, you're already paying for a round
trip on TLS 1.3, and now you're paying for another round trip just to get your WebSockets
session going. There is the trick of doing this a little bit more optimistically, support differs
across platforms, so what we could do is send the upgrade token, already optimistically send
data on the WebSockets session, saying like, I'm sure the server will accept this, and then
the server says one-on-one switching protocol is great, and then it's also sending responses to
whatever you send earlier. So this saves you on a round trip, but you're having this optimistic
pattern in there, if the server says, nope, not talking WebSockets to you, then in the HP2 case,
the whole thing fails, you send data that was never useful, and in the HP1 case that is actually
a potential security attack, where if you don't control what, if you have an entrusted
client that can put anything into the optimistic data, the server after rejecting your initial
upgrade request will then interpret the optimistic data, potentially it's an HTTP request,
so your attacker could put anything in there and then take control in some way of the connection.
So in the default case, as I said earlier, one RTT mostly, there is the optimization around
doing this optimistically, but it's not implemented everywhere. From here, the major thing
of WebSockets, and that's very much WebSockets suffering from what it is running on top of,
is head of line blocking. For those not familiar with this, I will go a little bit into this.
So imagine you have a B-directional communication substrate, whatever it is, it might be
TCP connection, WebSockets, anything out there, and so it's a single larger stream where you put
multiple streams inside, so you have one packet for stream 1, stream 2, stream as sorry,
stream 1, and then later on stream 2, so stream 2 is behind all of this, and you're sending this
over the wire, and it makes it to the receiver, but unfortunately the first one doesn't.
So now stream 2 is independent of stream 1, as in the receiver could already consume stream 2,
like the data in it, but given that TCP is always ordered, you cannot consume whatever is in stream 2.
It's not available to you. So you will have a retransmit of this one packet on stream 1,
and only then the receiver can then read all of the frames for stream 1, and then later on stream 2.
So this is not ideal. In general, the idea of head of line blocking, you see this everywhere in the
web is the idea that independent data is blocked because something at the head of the queue
is not yet ready to be read. And we have this problem both on the session level in WebSockets,
and on the TCP stream level, as in like if you have different kind of things that you send over
the single WebSocker connection, the receiver can only read that in order. If you have
independent things that you send on one TCP connection, the receiver can only read that in order.
If the head is delayed, everything behind that is delayed. That's very much problematic.
Next, given that we're running on TCP, as I said, WebSockets is using HB1, HB2, both running on
to TCP, there is no such thing as unreliable delivery. TCP will always give you reliable delivery.
Now don't get me wrong, that's a good idea. Don't implement your own transport protocol just
to get this. But it is a problem in some cases where you want unreliable delivery. Say, for example,
you have a life stream, let's say a packet is lost. Given that it's a life stream, you probably
don't care whether that packet is retransmitted. Because the life stream is moving on, if that
one packet is gone, you don't really care. You don't want that retransmitted. Because that retransmitted
would take up bandwidth, you would throw it away anyways, that the receiver side. And it is
competing with the other traffic that might be more important on that connection.
So WebSockets, unfortunately, no unreliable delivery. Next one, connection migration. Here you see
my big emoji game. Let's imagine you're in the house and you see the bus. You're on your
phone, you are, again, say life streaming, something over your Wi-Fi. Now you run to the bus,
and you exit the house, exit the reach of your Wi-Fi, and you're switching to your cellular,
or your phone does that automatically. So you're switching networks. Now what's going to happen?
Well, your source IP address is going to change. Your source IP address is going to change from your
home source IP to your cellular source IP. You don't have your own that is knitted, but
over all you can think that way. So what's the problem here for TCP? TCP always operates on the
fortible. So on source IP, source port, source destination IP, destination port. If the source IP
changes, your TCP connection breaks. Now there are tricks, very tricks, but those are not very,
very widely deployed. So very much your TCP connection breaks. And that also means everything that
you run on top of it also breaks. So for example, if you have a life stream running while you run
to your bus, then that life stream is also running break. Not great. So on WebSockets, given that
it's only running on TCP, we don't have connection migration. And then lastly, this is more
informational here. Browse the support, as I mentioned, HB1, HB2. There are a lot of benefits
of HB3 beyond what I just listed. And that's a bummer, WebSockets right now, not supported beyond that.
That's enough about WebSockets. Now let's talk a little bit about WebSransport,
as in the successor to WebSockets. WebSransport is very much a new API on the web. It's an
ongoing effort, both at the ITF and the W3C being standardized there. I will have a slide to go more
a little bit into detail on the standard's bodies. The focus is very much on HB3. And you can see
later that all the properties that are listed are mostly solved actually at the lower level HB3,
not so much by redesigning WebSockets to WebSransport. So focus is on HB3, but HB3 is not possible
everywhere in the web. Nor is it deployed everywhere in the web, so there's also being developed
fallback to HB2 in case HB3 is not available. In the major big step of WebSransport is
very fine-grained flow control, per session, and per stream, which for example gives us independent
reliable streams, so reliable delivery similar to TCP streams, but also unreliable delivery similar to
UDP datagrams. And with these various mechanisms, we can entirely work around the problem of
headline-bocking, the thing that I showed earlier was stream 1 and stream 2 were stream 2
weights on anything in stream 1. So this is basically one of the big goals of WebSransport.
Cool, let's walk into some use cases first and then into the lower levels. I'm just listing a
couple of things here, those are not mine. For example, let's say you want to implement a cloud game,
and you want the sending of the user input to be very reliable as in every click you do.
Well, at the same time, you want to push video frames back from the server, and you don't really
care about whether individual frames are lost, right? It's life after all, so if they're lost,
you definitely don't want them to be retrospective, you want this to happen in an unreliable fashion.
Other ideas, like life-streaming, very similar to that, imagine collaborative editing.
You definitely don't want a change to be lost, right? As in you want that to be retransmitted,
but a cursor update of your colleague, if it gets lost, you don't really need it. Retransmitted,
the next cursor update will just update you. You have ideas of internal things where you have
many streams of events that you want to consume, or you can imagine a financial ticker,
where always the latest packet that they just update on the price matters, but if one later on gets
dropped, you just wait for the next one. A lot of use cases, would you right now not perfect
for a web socket and where web transfer very much targets to be the protocol in need?
Where do we place web transport? This is exactly the same graphic as before, just the upper layer
changed. We have IP at the bottom, then TCP, of course, in UDP. We have the three pillars,
HB1, HB2, and HB3, and here on the top right, you see web transport, very much targeting HB3,
so that's the main playground we're trying to be in. Then we have a fallback on web transport
over HB2, and there are efforts to design web transport over HB1, even though that is very
difficult, so I'm not sure how successful that's going to be. As I said, this is actually
not a web transport talk, but actually I just want to talk a lot about my favorite protocol
quick and HB3. Now we're getting to that part. This I want to focus now on the third pillar,
so HB3 and quick, because a lot of those properties then bubble up into web transport and make
web transport, so what is quick and HB3? The most notable thing is instead of HB1 and HB2 being
based on TCP, we're now basing everything on top of UDP. So we don't have the reliable guarantees,
and the various congestion controllers available that we would have on TCP, but hey,
we can roll out on, and that is basically all idea. So quick is very much a journal for a
best transport protocol, you can think of it as TCP2 with TLS tightly integrated. It is on top of UDP,
it encrypts a lot of its metadata. So obviously we want to encrypt the actual user data,
right, that we have been doing for a very long time, but now we also want to move that encryption
down to the lower protocol layers to, for example, encrypt more of the handshake of quick.
We'll go, I think, a little bit into connection establishment. Maybe quick connections can be
established in one RTT. I mentioned earlier TCP costs an RTT then TLS also costs an RTT,
so you always have two on HB1 and HB2. On the other hand, HB3 merges the transport handshake
and the security handshake and thus you get that in one RTT. That is huge for the web, right?
As in, let's say you have 30 milliseconds around trip time. Imagine you can optimize your page
load by 30 milliseconds. That is very big. On consecutive connections, quick goes even further,
because it integrates the transport handshake and the cryptographic handshake together, it can
do various tricks where on consecutive connections we can reuse some of the cryptographic material
from the previous connection and actually do the whole connection establishment in zero RTT.
As in, we can send our get requests right away with zero latency for the setup.
Given that we are on top of UDP, we can play around with reliability guarantees. As I said,
TCP only gives us reliable delivery. UDP gives us unreliable delivery. Quick is our reliability
layer if we want it. If we don't want it, we can actually send things unreliable.
And with those new mechanisms, streams being independent and we have unreliable delivery,
we can then work around the various problems around head-of-line blocking, both within
for example web transport session, but also lower layer on the transport layer.
I mentioned earlier, connection migration will go a little bit into that, and then all of this
is a new shiny protocol. There's very much built to last well designed, and given that most of
it is encrypted, boxes in the middle of the internet cannot mess as much with the quick protocol.
Just an anecdote, after the quick handshake, all quick packets actually have only two bits
that are encrypted. Everything else is encrypted in those packets. So any middle box would
actually need the TLS key to mess with any of it, and thus hopefully middle box will not
ossify the internet as much as today. It's currently like you can't roll out TCP2,
because simply the middle box is still nowhere to this, and thus they're going to break.
Okay, so I mentioned this earlier, the connection establishment, it's huge on HTTP3.
Here you basically see that HTTP3 is twice as fast as HTTP2 in terms of setup time. Note these are
observational data. As in maybe the whole internet, all the fast servers just use HTTP3,
and all the slow servers just use HTTP2, maybe unlikely. I would bet that this has to do
to the fact that we have one RTT connection establishment, and sometimes zero RTT connections
establishment. In terms of adoption, and this is very much relevant for web transport, right?
As I said, web transport focuses on HTTP3, so if HTTP3 is not available everywhere, that's a
difficult story for web transport. HTTP3 adoption, we currently see around 20 to 30 percent,
the file box traffic using HTTP3. There's great other players in the internet see way more,
as in it is possible to run HTTP3 across the web. Some other players see up to 95 percent.
We have various tricks, maybe some of you out of happy I go of HTTP3, which we will soon be
lending in file box to actually increase that HTTP3 share. Okay, with that, we have the lower level,
and we know what quick an HTTP3 is, what does that mean for web transport? Well, first off,
the web transport upgrade. It can be done in zero RTT. As in, we can do that optimistic
dense that we also had earlier with HTTP2 and web sockets. As in, I sent both the upgrade request
and already sent data. But instead of single reliable byte stream, I can actually start multiple
streams already, and I can, for example, send the data gram already. And then when the server responds
with a 200, they can already react to all of the stuff I already sent.
In terms of head of line blocking, given that we're running on top of UDP instead of TCP,
we don't have one single reliable byte stream as in things in the back, get delayed by the things
in the front. Instead, the stack can reach UDP data grams one after the next and then propagate them up.
So, for example, in the stream 1 stream 2 use case, if stream 1 gets delayed, that doesn't matter
for stream 2. Stream 2 data can already be bubbled up. As in in your web transport session,
if your stream 1 has a packet loss, your stream 2 doesn't need to be delayed due to this.
So, we get the head of line blocking. We get unreliable delivery. Previously, we were running on TCP.
There is no unreliability on TCP. Now, we're running on quick, which has UDP and does unreliable
data grams actually as a feature building to quick, and we can leverage that on the higher level
in web transport where we can say, hey, this piece of data, I'll send it to the server. If it doesn't
make it there, please don't retransmit it. I just needed a time if it doesn't make it retransmission
is useless. We have things like connection migration. Again, here, me running to the bus,
quick will notice that the connection is migrating from one path over to another,
and thus has a past challenge to validate that the new path is valid and will then switch over.
It is not dependent on the source IP staying static. And lastly, browser support, as I said,
it's very much the focus on HTTP3 and there is upcoming HTTP support as well.
Support across browsers. You've already seen similar slides a lot today in this room.
We do have a web transport support on Chrome Edge 5X Opera. Safari, you still see here in red.
They I believe have like a developer flag, which you can enable and then use web transport
in Safari as well. And I heard it is shipping soon as in basic web transport support in Safari,
which is very exciting because then we have it in all of these.
Status at the standard bodies at the W3C, it is going to wider review for candidate
recommendation soon. So that's a very good step. So most more of the APIs are being standardized.
And then at the ITF, we're currently on HTTP3 to separate drafts, actually for the two versions,
on draft number 14 and the other one draft number 13. I'm not so much involved with the W3C.
I am involved in the ITF and I don't see major changes, but yeah, you never know before the RC is published.
In terms of users, yeah, adoption is low. That's the big problem.
There, I'm not aware of any major deployments today using web transport.
Though there is a larger working group at the ITF trying to pull more and more of media streaming
and the like over two to web transport. So in case you're interested in that,
definitely follow the media of a quick working group. You can take it and try it out.
There are various test websites. I uploaded these slides so you can just click the link there.
One test website, I linked here. If you want to play around this with this yourself,
I really like the web transport goal implementation that's very helpful. And then on the browser side,
is it easy as opening a web transport connection, waiting it for it to be ready. And then,
hey, you can send unreliable datagrams in the browser. Isn't that always what you wanted?
Note, the API changed slightly on the draft side. This is still what all major browser's implement.
So if you want to get going, that's the one. If you want to follow the latest spec,
which we will update in the browser soon, then this changed slightly, but not too much.
That's it for my end. If you have questions, I think we have a couple more minutes.
One question. I will be outside after this talk. So if you want to talk to me, just find me there.
Help us build all of this, right? It's not us alone in building and healthy internet as all of us.
Yeah, and if you want to reach out to me, this may email address. And I do have stickers of my most favorite
protocol, called Quick. So if you want some of those, yeah, find me somewhere.
Cool. Thank you.
You