> WebSockets lack flow control (backpressure) and multiplexing, so if you need them you either roll your own or use something similar to RSocket.

Yes, head of line blocking is an issue, but TCP provides flow control, and if you're not using that, you're going over HTTP3.

> WebTransport addresses these and also solves head of line blocking. But I'm concerned that we might run into a similar problem as we had with going from Python2 to Python3 and IPv6. Too easy for people to keep using the old version, and too little (perceived) benefit to upgrading.

At one time or another, one could have said the same thing about TLS transport, HTTP3, or XHR itself. Because of the comparatively huge domination of a few key browser engines, it's much easier to roll out new browser capabilities & protocols.

> As long as browsers still work with TCP, some networks will continue to block UDP (and thus HTTP3/WebTransport) outright.

By that logic, as long as browsers still work with HTTP 1.1 without TLS, some networks will continue to block HTTP 2 and TLS. While that's not entirely incorrect, the broad adoption of HTTP2 and TLS in particular suggests it's less of a problem than you think.

> Yes, head of line blocking is an issue, but TCP provides flow control

Unfortunately, the way browsers implement WebSocket it undermines TCP's flow control. It's trivial to crash a browser tab by opening a (larger than RAM) file and trying to stream it to a server using a tight loop sending on a WebSocket. WebSocket.bufferedAmount exists, but as of 2019 I failed to use it to solve this problem and had to implement application-level backpressure.

> At one time or another, one could have said the same thing about TLS transport, HTTP3, or XHR itself. Because of the comparatively huge domination of a few key browser engines, it's much easier to roll out new browser capabilities & protocols.

> By that logic, as long as browsers still work with HTTP 1.1 without TLS, some networks will continue to block HTTP 2 and TLS. While that's not entirely incorrect, the broad adoption of HTTP2 and TLS in particular suggests it's less of a problem than you think.

HTTP3 actually falls under my concern. There are still networks that block HTTP3, because it has really nice fallback to HTTP2/1.1, so there's no obvious impact on users.

So I guess the real question is will QUIC be an HTTP/2 or an IPv6, or something in between? Was HTTP/2 ever actively blocked the way UDP is? If so that certainly gives us hope.

The reason I care is that I'm currently developing a protocol that WebTransport is an excellent fit for. But I can't assume WebTransport will work because UDP might be blocked, so I'm having to implement WebSocket support as well, which is a lot more work.

HTTP/2 traffic was looking essentially the same as HTTP/1.1 + TLS.

It wasn't particularly interesting to block to begin with. UDP if blocked, then it's blocked in a name of Security.

> Unfortunately, the way browsers implement WebSocket it undermines TCP's flow control. It's trivial to crash a browser tab by opening a (larger than RAM) file and trying to stream it to a server using a tight loop sending on a WebSocket. WebSocket.bufferedAmount exists, but as of 2019 I failed to use it to solve this problem and had to implement application-level backpressure.

Before you were saying, "WebSockets lack flow control (backpressure) and multiplexing, so if you need them you either roll your own or use something similar to RSocket.", and now you're saying you can't roll your own? ;-)

> HTTP3 actually falls under my concern. There are still networks that block HTTP3, because it has really nice fallback to HTTP2/1.1, so there's no obvious impact on users.

Erm, HTTP2 & HTTP 1.1 have their own problems, some of which you yourself have identified. We actually rolled back from HTTP2 to HTTP 1.1 because of problems with HTTP2, particularly with mobile performance.

Our migration to HTTP3 has been all win so far. While UDP might be blocked for security reasons, there are security reasons to move to HTTP3.

That said, there are cases where only HTTP/1.0 is supported.

> The reason I care is that I'm currently developing a protocol that WebTransport is an excellent fit for. But I can't assume WebTransport will work because UDP might be blocked, so I'm having to implement WebSocket support as well, which is a lot more work.

I feel your pain. I've been using WebRTC, and the vast majority of the time UDP doesn't seem to be blocked anymore. That said, adoption of HTTP3 seems to be about half that of HTTP2 right now. Not bad for a brand new protocol, but I'd say we still have a significant amount of time to go before HTTP3 is the dominant protocol. I think the path forward is going to require some toil by the likes of you to support both, but no reason you can't support HTTP3 better! ;-)

> Before you were saying, "WebSockets lack flow control (backpressure) and multiplexing, so if you need them you either roll your own or use something similar to RSocket.", and now you're saying you can't roll your own? ;-)

You can, but you need to do it at the application level, which is a lot more involved. It would be nice if it were as simple as checking if bufferAmount > some threshold and then waiting on a promise before attempting to send again. That's essentially what you get with ReadableStream and WritableStream, which are provided by WebTransport.

> Erm, HTTP2 & HTTP 1.1 have their own problems, some of which you yourself have identified. We actually rolled back from HTTP2 to HTTP 1.1 because of problems with HTTP2, particularly with mobile performance.

Not sure if we're actually disagreeing here. In any case, we can both agree HTTP2 is not a panacea, and actually worse than HTTP/1.1 in some cases.

> That said, adoption of HTTP3 seems to be about half that of HTTP2 right now. Not bad for a brand new protocol, but I'd say we still have a significant amount of time to go before HTTP3 is the dominant protocol.

Here here. Overall I'm bullish on HTTP3 in the long run. I really just hope random enterprise networks don't decide to block it. In any case, it's going to be a big win for the places where it works.

This library allows for using Streams in SSE

https://github.com/rexxars/eventsource-parser

> As long as browsers still work with TCP, some networks will continue to block UDP (and thus HTTP3/WebTransport) outright.

I keep hearing it, but I've never actually seen such a network. There are many things that run on UDP. I can see it being closed in some tiny offices (but those usually lack brain power to accomplish it) or some dystopian corporate offices you can only see in a movie.

I really don't see how the fact that some networks might ban UDP has anything to do with it. Some networks ban google.com and wikipedia.com, you don't see them failing.

In their excellent article on NAT traversal[0], Tailscale mentions that the UC Berkeley guest wifi blocks all outbound UDP except DNS.

EDIT: According to this[1] issue, Berkeley guest wifi allows port 443, which would solve HTTP3/WebTransport. That's certainly hopeful, and I hope all networks are like this in the future. It's just not a forgone conclusion yet.

[0]: https://tailscale.com/blog/how-nat-traversal-works#have-you-...

[1]: https://github.com/danderson/natlab/issues/1

That's a case of shipping it 'broken' for those people.

If it works literally everywhere else, and the product is valuable, they'll change.

Not a traditional network, but Tor doesn't support UDP.

> As long as browsers still work with TCP, some networks will continue to block UDP (and thus HTTP3/WebTransport) outright.

HTTP2 should still work in that scenario then you don't need to worry about multiplexing.

You can't use HTTP2 directly in the browser. Or are you referring to something else?

All browsers released since the end of 2015 support HTTP2. If the server supports it the browser will use it. Unlike HTTP3 this is all TCP.

If you connect to a WebSocket over an HTTP2 connection then you don't need to worry about multiplexing since you can rely on the browser doing it for you - HTTP2 connections support over 200 concurrent streams.

I think we're talking about different types of multiplexing. Are you referring to the browser domain connection limit? HTTP/2 does essentially solve that.

I'm referring to opening multiple data streams on a single connection, which is very useful in a number of contexts. This is supported by HTTP/2 and HTTP/3, but it's only exposed directly to the browser runtime through WebTransport.

HTTP 1.1 did not support multiplexing and browsers limited you to six connections per domain. That made opening multiple WebSockets prohibitive so you would generally need to implement your own multiplexing of logical data streams on top of a single WebSocket.

HTTP2 and HTTP3 connections support the multiplexing of hundreds of streams across a single TCP or QUIC connection. Each stream can be a request or WebSocket. So now you can just open a WebSocket per logical data stream and leave the multiplexing to the browser.

So now you will have a single transport level network connection whether you use multiple WebSockets or implement multiplexing yourself atop a a single WebSocket.

Yeah we're talking about different things. Imagine you had a process in the browser that can respond to many concurrent long-running requests from the server. In order to handle this with WebSockets, you need to implement your own multiplexing, because a) the server can't initiate a new WebSocket connection to the browser and b) opening a new WebSocket connect for each request doesn't fit the paradigm of request-response very well.

Note that WebTransport handles this for you, because the server can initiate new streams.

If you're sending lots of data, you also need per-stream backpressure.

WebSocketStream is about to ship in Chrome, which adds backpressure: https://chromestatus.com/feature/5189728691290112

Are Firefox and Safari planning to support it?

I suppose many use libraries built on top the native APIs, e.g. socket.io, so for them the change is nothing more than a bump in the lib version.

There is better approach to base64: binary-sse (https://github.com/luciopaiva/binary-sse)