An Introduction to WebTransport

We used websockets to have a connection oriented real time communication between client and server for the past couple of years. Javascript libraries as https://socket.io/ are solid examples that shows a wonderful ecosystem of the technology.

But, humans were never satisfied right?

As our applications became more complex, our requirements started challenging existing systems. We don’t stop at building one-to-one chat interfaces in web interfaces in 2026. Collaborative applications, multiplayer games and live-streaming applications are some examples.

Websockets did an amazing job bringing real time communication to the web. But does it mean it is the perfect soup for everything?

An sneak peek of WebSockets

Before we jump to WebTransport, let’s understand how WebSockets work.

Normally, when a browser communicates with a server, it uses HTTP. The browser sends a request, the server responds, and that is the end of the interaction.

But, think we are building a chat application.

Imagine two users, Alice and bob (stereotypically), chatting with each other. If we only use traditional HTTP requests, Alice’s browser would have to repeatedly ask the server:

“Hey, do I have any new messages? “

Even when there are no new messages, the browser keeps checking. This technique is called Polling.

WebSockets solve this problem by allowing the browser and server to maintain a persistent, two-way communication channel.

You can see after establishing the connection, until you disconnect deliberately, you can send messages to both directions without any hassle.

The problem with WebSockets

Who the hell said WebSockets are bad?

It is not bad, and WebTransport was not invented because WebSockets failed.

WebSockets are actually pretty good at what they were designed to do.

When we establish a WebSocket connection, we get a reliable, ordered communication channel between the client and the server.

That means if we send three messages:

Message 1 → Message 2 → Message 3

The receiving application gets them in the same order.

Pretty useful, isn't it?

But what happens if a network packet containing part of Message 1 gets lost during transmission?

Since WebSockets rely on TCP (if you’re a reader who remember OSI 7 layer model), missing data needs to be retransmitted before subsequent data can be delivered in order.

Even if layer packets have already arrived, they might have to wait until the missing data is recovered.

This is called Head of Line Blocking

For something like a chat applications, this is usually acceptable but imagine we are developing a multiplayer game. We don’t want to to see players moving out of order right?

The power house of WebTransport: QUIC

Before understanding the real advantages of WebTransport, we should talk about QUIC.

QUIC is a modern user-space transport layer protocol which uses UDP behind the scenes but combines features as reliability, encryption, congestion control and most importantly multiplexed streams.

Unlike TCP, QUIC allows multiple independent streams to exist within a single connection. Just like multiple channels on a single satellite TV connection.

This attribute of QUIC is useful in building real time multiplayer applications which needs to transmit three different types of information. As examples:

• Player movements
• Chat messages
• Game events

With a traditional WebSocket connection, all these messages share one ordered communication channel but with WebTransport, we can use different streams for different types of data, while also using datagrams for updates that don’t necessarily need reliable delivery.

This way, a lost movement update doesn’t necessarily have to delay our chat messages or other independent streams. And that is one of the biggest advantage of WebTransport.

Reliable streams vs unreliable datagrams

One of the most interesting things about WebTransport is that it gives developers control over how data should be delivered.

Instead of treating every message in exactly the same way, WebTransport supports multiple communication mechanisms.

1. Reliable streams

Reliable streams are useful when we need to make sure data arrives correctly and in order.

WebTransport supports both bidirectional and unidirectional streams.

Bidirectional streams allow the client and server to send and receive data through the same stream.

Unidirectional streams allow data to flow in only one direction.

The important part is that multiple streams can operate independently.

If data is lost on one stream, the application can still receive available data from another stream without waiting for that lost data to be recovered.

2. Unreliable datagrams

Now things get even more interesting.

WebTransport also supports datagrams as shown above in the diagram.

Unlike reliable streams, datagrams don't guarantee that every message will arrive, or that messages will arrive in the same order they were sent.

At first, this might sound like a disadvantage.

Why would anyone want to send data without guaranteeing delivery?

Well, think about our multiplayer game again.

Suppose we send a player's position 30 times per second.

If one position update gets lost, the next update could be more useful than retransmitting the old one.

In this situation, getting the latest data quickly is more important than receiving every single update.

That's exactly the kind of scenario where datagrams can help.

WebSockets vs WebTransport

Now that we have a basic understanding of WebTransport, let's compare it with WebSockets.

Will WebTransport replace WebSockets?

This is probably the question that brought you here in the first place.

And my answer is: not completely, at least not anytime soon.

WebSockets already have a mature ecosystem, excellent library support, and a relatively simple programming model.

For most typical real-time applications, they are more than capable of getting the job done.

Think about applications such as chat systems, notification services, dashboards, and collaborative tools.

Do we really need unreliable datagrams and multiple independent streams for every one of these use cases?

Probably not.

However, WebTransport becomes particularly interesting when we're building latency-sensitive applications where different types of information have different delivery requirements.

Challenges to WebTransport

Even though most browsers has stable support for WebTransport as of now server side ecosystem and infrastructure support from serverless environments are not universally established as those of WebSockets.

Another important consideration is that WebTransport is a lower level API. Developers need to make more decisions about streams, datagrams, error handling, and message delivery.

With great flexibility comes great responsibility

Final Thoughts

WebTransport is an exciting development for the web platform.

For years, WebSockets gave us a straightforward way to build real-time applications. And they will continue to be useful for years to come.

But the web is evolving.

We're no longer building only websites and simple CRUD applications. We are building increasingly sophisticated, real-time experiences directly inside our browsers.

And technologies like WebTransport open up new possibilities for how these applications communicate.