• Will WebTransport Replace WebRTC in Near Future?
  • Charuka E Bandara
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Usualminds
  • Proofreader: Zhuzilin

Will WebTransport replace WebRTC in the near future?

Video and audio conferencing over the web is very popular these days. In the past, audio and video conferencing often required an intermediate server to transfer data between the two parties. Because the transmission process is slow and the picture quality is rough, there have been many innovations to improve the underlying technology to address the limitations of audio and video transmission.

Beginning in 2010, Google engineers introduced WebRTC to solve these problems. Today, we use it in many places.

Introduction of WebRTC

WebRTC, or Web Real-time Communication, is a protocol (API collection) that allows browsers to communicate directly with each other. These apis support the transfer of files, information, or any data. Sounds like WebSockets. But that’s not the case.

As we mentioned, communication takes place between browsers and does not require direct server involvement. However, the server needs to get the IP address of the peer through the browser at the initial stage. Still, it’s much faster than communicating through the server.

Now, you might be wondering, why do we need a new protocol? That’s because over time and as technology has evolved, we’ve come to see the limitations of WebRTC delivery.

What are the limitations of WebRTC?

TCP layer queue header blocking (HOL)

This is the same problem we had with the HTTP/2 protocol. When using the HTTP/2 protocol, multiple requests are encapsulated as streams and sent to the server. Therefore, in a given instance, multiple requests will use a single TCP connection.

Suppose you have two GET requests, each with six packets. When sending a GET request, if a packet is corrupted or lost in transit, the TCP flow makes the entire stream wait until the packet is retransmitted and received by the server. So TCP HOL happens.

Don’t confuse TCP with HTTP HOL. These are two different questions. Only TCP HOL causes WebRTC transport problems here.

Since WebRTC is built on top of the HTTP/2 protocol, this problem can be triggered in any scenario, from file transfers to video conferencing.

WebRTC must be connected by the client

In this case, the limitations of transport become apparent because the client must initiate the connection to avoid network problems or security issues. And so it is. The challenge for WebRTC is that no one can send a message without authorization from the client.

However, HTTP push attempts to solve this problem by creating new data streams. Here, the server creates a new stream and pushes the content to the client. But it didn’t work. So Google recently removed this method from Chrome.

So, to solve these problems, use the new WebTransport.

What is WebTransport?

WebTransport is a pluggable client-server communication protocol built on HTTP/2, HTTP/3 and QUIC protocols. It is designed to replace WebSockets and move towards the “native QUIC protocol”.

You can think of it as WebRTC, but optimized for the 80/20 rule.

QUIC is a Web API that uses the QUIC protocol over two-way non-HTTP transport to provide services over UDP, similar to a stand-alone TCP, greatly reducing the latency associated with TCP establishing connections. The main feature is two-way communication between the Web client and the QUIC server using the Steam API.

In addition, WebTransport supports multiple data streams, one-way data streams, unordered transport, reliable and unreliable transport.

WebTransport overcomes these challenges

WebTransport is based on the QUIC protocol

WebTransport is an interface that can communicate with protocols based on HTTP/2, HTTP/3, and QUIC. Therefore, it has the advantage that both HTTP and non-HTTP traffic can share the same network port.

In addition, because QUIC is udP-based, each of its data flows is independent. One of its advantages is the use of UDP, which avoids TCP’s queue header blocking problem. Therefore, any missing packet will only cause the stream it’s in to pause, while the rest of the stream can still transmit normally.

WebTransport supports multiple protocols

WebTransport supports unidirectional streams (unidirectional unlimited byte streams), bidirectional streams (full-duplex streams), and data packets (small/out-of-order/unreliable messages). Therefore, WebTransport has some key uses:

  • WebTransport can request and receive data reliably and unreliably (reliably and unreliably) over the HTTP protocol, all over the same network connection.
  • WebTransport can send data (reliable and unreliable) to the server using a one-way send stream using the QUIC protocol.
  • WebTransport can use a one-way receive stream to push data from the server.

So in the games industry, WebTransport is going to play a big role because it can receive the data push from the server with minimal latency.

conclusion

In my opinion, WebRTC has done a great job and people have been using it for a long time. Clearly, as the technology world continues to change, even millisecond delays are important in some cases. As we mentioned, an industry like games could benefit significantly from using WebTransport.

Websocket-based WebRTC is no longer the fastest way.

In this case, powerful WebTransport will solve the webrTC-based WebSocket problem. Considering all these advantages, I believe WebTransport will replace WebRTC. It just takes people a while to get used to it.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.