From 48c375ed80e95e1acd1304e066918169bec64195 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Wed, 21 Sep 2022 03:58:12 -0400 Subject: [PATCH 01/10] readd transport content + a section --- content/concepts/transport.md | 73 +++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/content/concepts/transport.md b/content/concepts/transport.md index fd1e6197..78d10828 100644 --- a/content/concepts/transport.md +++ b/content/concepts/transport.md @@ -210,3 +210,76 @@ Following the multiaddress format described earlier, a standard QUIC connection look like: `/ip4/127.0.0.1/udp/65432/quic/`. In this section, we offered an overview of QUIC and how QUIC works in libp2p. + +## WebTransport + +Another transport protocol under development at the IETF is WebTransport. +WebTransport is a new specification that uses QUIC to offer an alternative to +WebSockets. It can be considered WebSockets over QUIC by allowing +browsers to establish a stream-multiplexed and bidirectional +connection to servers. + +The specification can depend on and reuse the QUIC infrastructure in place +to offer WebSockets that take the benefits of UDP and offer streams without +head-of-line blocking. + +Recall that WebSockets are bidirectional, full-duplex communication between two +points over a single-socket connection. WebTransport can be used +like WebSockets, but with the support of multiple streams. + +WebTransport supports reliable streams that can be arbitrary in size. They can be +independent and canceled if needed. The datagrams in a +WebTransport connections are MTU-sized. + +{{% notice "caution" %}} + +There is an experimental WebTransport transport in go-libp2p that is part +of the v0.23 release. The implementation should be used experimentally and is not +recommended for production environments. + +{{% /notice %}} + +For network stacks like libp2p, WebTransport is a pluggable +protocol that fits well with a modular network design. + +For a standard WebSocket connection, the roundtrips required are as follows: + +- 1-RTT for TCP handshake +- 1-RTT for TLS 1.3 handshake +- 1-RTT for WebSocket upgrade +- 1-RTT for multistream security negotiation (Noise or TLS 1.3) +- 1-RTT for security handshake (Noise or TLS 1.3) +- 1-RTT for multistream muxer negotiation (mplex or yamux) + +In total, 6-RTTs. + +WebTransport running over QUIC only requires 4 RTTs, as: + +- 1-RTT for QUIC handshake +- 1-RTT for WebTransport handshake +- 2-RTT for libp2p handshake; one for multistream and one for authentication + (with a Noise handshake) +> With protocol select, the WebTransport handshake and the libp2p handshake +> can run in parallel, bringing down the total round trips to 2. + +### WebTransport in libp2p + +WebTransport multiaddresses are composed of a QUIC multiaddr, followed +by `/webtransport` and a list of multihashes of the node certificates that the server uses. + +For instance, for multiaddress `/ip4/127.0.0.1/udp/123/quic/webtransport/certhash/`, +a standard local QUIC connection is defined up until and including `/quic.` +Then, `/webtransport/` runs over QUIC and the self-signed certificate hash that the +server will use to verify the connection. + +WebTransport requires an HTTPS URL to establish a WebTransport session - +e.g., `https://docs.libp2p.com/webtransport` and the multiaddresses use an HTTP URL +instead. The HTTP endpoint of a libp2p WebTransport servers must be located at +`/.well-known/libp2p-webtransport`. + +For instance, the WebTransport URL of a WebTransport server advertising +`/ip4/1.2.3.4/udp/1234/quic/webtransport/` that is authenticated would be +`https://1.2.3.4:1234/.well-known/libp2p-webtransport?type=noise`. + +In this section, we offered an overview of WebTransport and how WebTransport works +in libp2p. From 37ab428872847f41f862cd7fba78c275d0c768dc Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Thu, 29 Sep 2022 03:42:39 -0400 Subject: [PATCH 02/10] edits --- content/concepts/transport.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/content/concepts/transport.md b/content/concepts/transport.md index 78d10828..570e3f6b 100644 --- a/content/concepts/transport.md +++ b/content/concepts/transport.md @@ -142,7 +142,7 @@ in 2014, and was later standardized by the IETF in firewalls, NATs, proxies, and load balancers. {{% /notice %}} -3. Handshake inefficiency: the 3-way handshake is inefficient, as it spends 1-RTT on verifying +3. Handshake inefficiency: the 3-way handshake is inefficient, as it spends 1 RTT on verifying the client’s address. {{% notice "info" %}} @@ -165,7 +165,7 @@ A web browser connection typically entails the following (TCP+TLS+HTTP/2): - TCP provides a reliable, bidirectional connection between two end systems. 2. Secure communication layer: A TLS handshake runs on top of TCP to, establishing an encrypted and authenticated connection. - - Standard TLS over TCP requires 3-RTT. A typical TLS 1.3 handshake takes 1-RTT. + - Standard TLS over TCP requires 3 RTT. A typical TLS 1.3 handshake takes 1 RTT. 3. Application layer: HTTP runs on a secure transport connection to transfer information and applies a stream muxer to serve multiple requests. - Application data starts to flow. @@ -244,20 +244,20 @@ protocol that fits well with a modular network design. For a standard WebSocket connection, the roundtrips required are as follows: -- 1-RTT for TCP handshake -- 1-RTT for TLS 1.3 handshake -- 1-RTT for WebSocket upgrade -- 1-RTT for multistream security negotiation (Noise or TLS 1.3) -- 1-RTT for security handshake (Noise or TLS 1.3) -- 1-RTT for multistream muxer negotiation (mplex or yamux) +- 1 RTT for TCP handshake +- 1 RTT for TLS 1.3 handshake +- 1 RTT for WebSocket upgrade +- 1 RTT for multistream security negotiation (Noise or TLS 1.3) +- 1 RTT for security handshake (Noise or TLS 1.3) +- 1 RTT for multistream muxer negotiation (mplex or yamux) -In total, 6-RTTs. +In total, 6 RTTs. WebTransport running over QUIC only requires 4 RTTs, as: -- 1-RTT for QUIC handshake -- 1-RTT for WebTransport handshake -- 2-RTT for libp2p handshake; one for multistream and one for authentication +- 1 RTT for QUIC handshake +- 1 RTT for WebTransport handshake +- 2 RTT for libp2p handshake; one for multistream and one for authentication (with a Noise handshake) > With protocol select, the WebTransport handshake and the libp2p handshake > can run in parallel, bringing down the total round trips to 2. From 30765e6bda77fcc9f81ef3e50f182f76971494d9 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Thu, 29 Sep 2022 03:44:22 -0400 Subject: [PATCH 03/10] Apply suggestions from code review Co-authored-by: Marten Seemann --- content/concepts/transport.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/content/concepts/transport.md b/content/concepts/transport.md index 570e3f6b..6b4bbe72 100644 --- a/content/concepts/transport.md +++ b/content/concepts/transport.md @@ -215,7 +215,7 @@ In this section, we offered an overview of QUIC and how QUIC works in libp2p. Another transport protocol under development at the IETF is WebTransport. WebTransport is a new specification that uses QUIC to offer an alternative to -WebSockets. It can be considered WebSockets over QUIC by allowing +WebSocket. It can be considered WebSocket over QUIC by allowing browsers to establish a stream-multiplexed and bidirectional connection to servers. @@ -223,9 +223,7 @@ The specification can depend on and reuse the QUIC infrastructure in place to offer WebSockets that take the benefits of UDP and offer streams without head-of-line blocking. -Recall that WebSockets are bidirectional, full-duplex communication between two -points over a single-socket connection. WebTransport can be used -like WebSockets, but with the support of multiple streams. +While WebSocket provides a bidirectional, full-duplex communication between a browser and a server over a TCP connection, WebTransport exposes the streams of a QUIC connection to the browser.`` WebTransport supports reliable streams that can be arbitrary in size. They can be independent and canceled if needed. The datagrams in a @@ -259,8 +257,7 @@ WebTransport running over QUIC only requires 4 RTTs, as: - 1 RTT for WebTransport handshake - 2 RTT for libp2p handshake; one for multistream and one for authentication (with a Noise handshake) -> With protocol select, the WebTransport handshake and the libp2p handshake -> can run in parallel, bringing down the total round trips to 2. +In principle, the WebTransport protocol would even allow running the WebTransport handshake and the Noise handshake at the same time. However, this is currently not possible in Chrome due to a bug in its WebTransport implementation. ### WebTransport in libp2p From 57b780d317a5d47ff2826422ba7c4b1ff9af1477 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Thu, 29 Sep 2022 03:54:27 -0400 Subject: [PATCH 04/10] incorporate remaining PR feedback --- content/concepts/transport.md | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/content/concepts/transport.md b/content/concepts/transport.md index 6b4bbe72..422cc689 100644 --- a/content/concepts/transport.md +++ b/content/concepts/transport.md @@ -223,17 +223,30 @@ The specification can depend on and reuse the QUIC infrastructure in place to offer WebSockets that take the benefits of UDP and offer streams without head-of-line blocking. -While WebSocket provides a bidirectional, full-duplex communication between a browser and a server over a TCP connection, WebTransport exposes the streams of a QUIC connection to the browser.`` +WebTransports allows us to connect to any libp2p browser node with any server node +because the protocol supports certificate verification via certificate hash, whereas +for WebSocket, it is necessary that the TLS certificate is signed by a trusted CA +(certificate authority). -WebTransport supports reliable streams that can be arbitrary in size. They can be -independent and canceled if needed. The datagrams in a -WebTransport connections are MTU-sized. +While WebSocket provides a bidirectional, full-duplex communication between a +browser and a server over a TCP connection, WebTransport exposes the streams of a +QUIC connection to the browser. + +Therefore, WebTransport exhibits all the advantages of QUIC over TCP, that being +faster handshakes, no HoL blocking, and being future-proof. {{% notice "caution" %}} There is an experimental WebTransport transport in go-libp2p that is part -of the v0.23 release. The implementation should be used experimentally and is not -recommended for production environments. +of the [v0.23 release](https://github.com/libp2p/go-libp2p/releases/tag/v0.23.0). +The implementation should be used experimentally and is not recommended for production +environments. + +js-libp2p also plans to release +[WebTransport support](https://github.com/libp2p/js-libp2p-webtransport) relatively soon. + +There are currently no concrete plans to support WebTransport beyond the Go and JS +implementations. {{% /notice %}} From 525b11f3f0750da788800108e4cd8446bd733e61 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Thu, 29 Sep 2022 03:56:23 -0400 Subject: [PATCH 05/10] incorporate remaining PR feedback --- content/concepts/transport.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/concepts/transport.md b/content/concepts/transport.md index 422cc689..4678ccf2 100644 --- a/content/concepts/transport.md +++ b/content/concepts/transport.md @@ -270,7 +270,10 @@ WebTransport running over QUIC only requires 4 RTTs, as: - 1 RTT for WebTransport handshake - 2 RTT for libp2p handshake; one for multistream and one for authentication (with a Noise handshake) -In principle, the WebTransport protocol would even allow running the WebTransport handshake and the Noise handshake at the same time. However, this is currently not possible in Chrome due to a bug in its WebTransport implementation. + +In principle, the WebTransport protocol would even allow running the WebTransport +handshake and the Noise handshake at the same time. However, this is currently not +possible in Chrome due to a bug in its WebTransport implementation. ### WebTransport in libp2p From f6ba9fe3fb48b55fe975ebe5ddf6289d9bfde791 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Thu, 29 Sep 2022 05:43:44 -0400 Subject: [PATCH 06/10] incorporate remaining PR feedback --- content/concepts/transport.md | 38 +++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 17 deletions(-) diff --git a/content/concepts/transport.md b/content/concepts/transport.md index 4678ccf2..e057341b 100644 --- a/content/concepts/transport.md +++ b/content/concepts/transport.md @@ -215,22 +215,29 @@ In this section, we offered an overview of QUIC and how QUIC works in libp2p. Another transport protocol under development at the IETF is WebTransport. WebTransport is a new specification that uses QUIC to offer an alternative to -WebSocket. It can be considered WebSocket over QUIC by allowing -browsers to establish a stream-multiplexed and bidirectional -connection to servers. +WebSocket. Conceptually, it can be considered WebSocket over QUIC. +It allows browsers to establish a stream-multiplexed and bidirectional connection +to servers. -The specification can depend on and reuse the QUIC infrastructure in place -to offer WebSockets that take the benefits of UDP and offer streams without -head-of-line blocking. +While WebSocket provides a bidirectional, full-duplex communication between a +browser and a server over a TCP connection, WebTransport exposes the streams of a +QUIC connection to the browser. WebTransports allows us to connect to any libp2p browser node with any server node because the protocol supports certificate verification via certificate hash, whereas for WebSocket, it is necessary that the TLS certificate is signed by a trusted CA (certificate authority). -While WebSocket provides a bidirectional, full-duplex communication between a -browser and a server over a TCP connection, WebTransport exposes the streams of a -QUIC connection to the browser. +When connecting to a WebSocket server, browsers require the server to present a +TLS certificate signed by a trusted CA (certificate authority). Few nodes have such +a certificate, which is the reason that WebSocket never saw widespread adoption in the +libp2p network. libp2p WebTransport offers a browser API that includes a way to +accept the server's certificate by checking the (SHA-256) hash of the certificate +(using the [`serverCertificateHashes` option](https://www.w3.org/TR/webtransport/#dom-webtransportoptions-servercertificatehashes)), even if the certificate is "just" +a self-signed certificate. This allows us to connect any browser node to any server node, +as long as the browser knows the certificate hash in advance +(see [WebTransport in libp2p](#webtransport-in-libp2p) for how WebTransport addresses +achieve this). Therefore, WebTransport exhibits all the advantages of QUIC over TCP, that being faster handshakes, no HoL blocking, and being future-proof. @@ -243,7 +250,7 @@ The implementation should be used experimentally and is not recommended for prod environments. js-libp2p also plans to release -[WebTransport support](https://github.com/libp2p/js-libp2p-webtransport) relatively soon. +[WebTransport support](https://github.com/libp2p/js-libp2p-webtransport) very soon. There are currently no concrete plans to support WebTransport beyond the Go and JS implementations. @@ -264,15 +271,15 @@ For a standard WebSocket connection, the roundtrips required are as follows: In total, 6 RTTs. -WebTransport running over QUIC only requires 4 RTTs, as: +WebTransport running over QUIC only requires 3 RTTs, as: - 1 RTT for QUIC handshake - 1 RTT for WebTransport handshake -- 2 RTT for libp2p handshake; one for multistream and one for authentication +- 1 RTT for libp2p handshake; one for multistream and one for authentication (with a Noise handshake) In principle, the WebTransport protocol would even allow running the WebTransport -handshake and the Noise handshake at the same time. However, this is currently not +handshake and the Noise handshake in parallel. However, this is currently not possible in Chrome due to a bug in its WebTransport implementation. ### WebTransport in libp2p @@ -282,7 +289,7 @@ by `/webtransport` and a list of multihashes of the node certificates that the s For instance, for multiaddress `/ip4/127.0.0.1/udp/123/quic/webtransport/certhash/`, a standard local QUIC connection is defined up until and including `/quic.` -Then, `/webtransport/` runs over QUIC and the self-signed certificate hash that the +Then, `/webtransport/` runs over QUIC. The self-signed certificate hash that the server will use to verify the connection. WebTransport requires an HTTPS URL to establish a WebTransport session - @@ -293,6 +300,3 @@ instead. The HTTP endpoint of a libp2p WebTransport servers must be located at For instance, the WebTransport URL of a WebTransport server advertising `/ip4/1.2.3.4/udp/1234/quic/webtransport/` that is authenticated would be `https://1.2.3.4:1234/.well-known/libp2p-webtransport?type=noise`. - -In this section, we offered an overview of WebTransport and how WebTransport works -in libp2p. From d696137c3c436da1e1efef33721a74953e7ab35e Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Sat, 8 Oct 2022 07:43:56 -0400 Subject: [PATCH 07/10] Update content/concepts/transport.md Co-authored-by: Marco Munizaga --- content/concepts/transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/concepts/transport.md b/content/concepts/transport.md index e057341b..10e726d6 100644 --- a/content/concepts/transport.md +++ b/content/concepts/transport.md @@ -298,5 +298,5 @@ instead. The HTTP endpoint of a libp2p WebTransport servers must be located at `/.well-known/libp2p-webtransport`. For instance, the WebTransport URL of a WebTransport server advertising -`/ip4/1.2.3.4/udp/1234/quic/webtransport/` that is authenticated would be -`https://1.2.3.4:1234/.well-known/libp2p-webtransport?type=noise`. +`/ip4/1.2.3.4/udp/1234/quic/webtransport/` would be +`https://1.2.3.4:1234/.well-known/libp2p-webtransport?type=noise` (the ?type=noise refers to the authentication scheme using Noise). From 6ac1473b5a5ed99e9b1e695db85ab0bdbd03cdc4 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Wed, 12 Oct 2022 05:31:40 -0400 Subject: [PATCH 08/10] Apply suggestions from code review Co-authored-by: Marten Seemann --- content/concepts/transport.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/concepts/transport.md b/content/concepts/transport.md index 10e726d6..5d6eee23 100644 --- a/content/concepts/transport.md +++ b/content/concepts/transport.md @@ -213,15 +213,15 @@ In this section, we offered an overview of QUIC and how QUIC works in libp2p. ## WebTransport -Another transport protocol under development at the IETF is WebTransport. +While browsers perform HTTP request using HTTP/3, so far they don't offer an API to allow applications to gain access to the underlying QUIC stream. WebTransport is a new specification that uses QUIC to offer an alternative to WebSocket. Conceptually, it can be considered WebSocket over QUIC. It allows browsers to establish a stream-multiplexed and bidirectional connection -to servers. +to servers, and use streams to send and receive application data. -While WebSocket provides a bidirectional, full-duplex communication between a -browser and a server over a TCP connection, WebTransport exposes the streams of a -QUIC connection to the browser. +While WebSocket provides a single bidirectional, full-duplex communication between a +browser and a server over a TCP connection, WebTransport exposes allows the endpoints to use multiple +streams in parallel. WebTransports allows us to connect to any libp2p browser node with any server node because the protocol supports certificate verification via certificate hash, whereas @@ -280,7 +280,7 @@ WebTransport running over QUIC only requires 3 RTTs, as: In principle, the WebTransport protocol would even allow running the WebTransport handshake and the Noise handshake in parallel. However, this is currently not -possible in Chrome due to a bug in its WebTransport implementation. +possible in since the [browser API doesn't allow](https://github.com/w3c/webtransport/issues/409) that yet. ### WebTransport in libp2p From dc6f4ca00f85b11a81ef519b82ea783e30fe8ff2 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Wed, 12 Oct 2022 05:38:05 -0400 Subject: [PATCH 09/10] addr PR feedback + edits --- content/concepts/transport.md | 32 +++++++++++++------------------- 1 file changed, 13 insertions(+), 19 deletions(-) diff --git a/content/concepts/transport.md b/content/concepts/transport.md index 5d6eee23..93767192 100644 --- a/content/concepts/transport.md +++ b/content/concepts/transport.md @@ -213,7 +213,8 @@ In this section, we offered an overview of QUIC and how QUIC works in libp2p. ## WebTransport -While browsers perform HTTP request using HTTP/3, so far they don't offer an API to allow applications to gain access to the underlying QUIC stream. +While browsers perform HTTP request using HTTP/3, so far they don't offer an API to allow applications +to gain access to the underlying QUIC stream. WebTransport is a new specification that uses QUIC to offer an alternative to WebSocket. Conceptually, it can be considered WebSocket over QUIC. It allows browsers to establish a stream-multiplexed and bidirectional connection @@ -223,20 +224,16 @@ While WebSocket provides a single bidirectional, full-duplex communication betwe browser and a server over a TCP connection, WebTransport exposes allows the endpoints to use multiple streams in parallel. -WebTransports allows us to connect to any libp2p browser node with any server node -because the protocol supports certificate verification via certificate hash, whereas -for WebSocket, it is necessary that the TLS certificate is signed by a trusted CA -(certificate authority). - When connecting to a WebSocket server, browsers require the server to present a TLS certificate signed by a trusted CA (certificate authority). Few nodes have such a certificate, which is the reason that WebSocket never saw widespread adoption in the libp2p network. libp2p WebTransport offers a browser API that includes a way to accept the server's certificate by checking the (SHA-256) hash of the certificate -(using the [`serverCertificateHashes` option](https://www.w3.org/TR/webtransport/#dom-webtransportoptions-servercertificatehashes)), even if the certificate is "just" -a self-signed certificate. This allows us to connect any browser node to any server node, -as long as the browser knows the certificate hash in advance -(see [WebTransport in libp2p](#webtransport-in-libp2p) for how WebTransport addresses +(using the +[`serverCertificateHashes` option](https://www.w3.org/TR/webtransport/#dom-webtransportoptions-servercertificatehashes)), +even if the certificate is "just" a self-signed certificate. This allows us to connect +any browser node to any server node, as long as the browser knows the certificate hash in +advance (see [WebTransport in libp2p](#webtransport-in-libp2p) for how WebTransport addresses achieve this). Therefore, WebTransport exhibits all the advantages of QUIC over TCP, that being @@ -280,7 +277,7 @@ WebTransport running over QUIC only requires 3 RTTs, as: In principle, the WebTransport protocol would even allow running the WebTransport handshake and the Noise handshake in parallel. However, this is currently not -possible in since the [browser API doesn't allow](https://github.com/w3c/webtransport/issues/409) that yet. +possible since the [browser API doesn't allow that yet](https://github.com/w3c/webtransport/issues/409). ### WebTransport in libp2p @@ -292,11 +289,8 @@ a standard local QUIC connection is defined up until and including `/quic.` Then, `/webtransport/` runs over QUIC. The self-signed certificate hash that the server will use to verify the connection. -WebTransport requires an HTTPS URL to establish a WebTransport session - -e.g., `https://docs.libp2p.com/webtransport` and the multiaddresses use an HTTP URL -instead. The HTTP endpoint of a libp2p WebTransport servers must be located at -`/.well-known/libp2p-webtransport`. - -For instance, the WebTransport URL of a WebTransport server advertising -`/ip4/1.2.3.4/udp/1234/quic/webtransport/` would be -`https://1.2.3.4:1234/.well-known/libp2p-webtransport?type=noise` (the ?type=noise refers to the authentication scheme using Noise). +WebTransport CONNECT is sent as an HTTPS endpoint. The HTTP endpoint of a libp2p WebTransport server +must be located at `/.well-known/libp2p-webtransport`. For instance, the WebTransport URL of a WebTransport +server advertising `/ip4/1.2.3.4/udp/1234/quic/webtransport/` would be +`https://1.2.3.4:1234/.well-known/libp2p-webtransport?type=noise` +(the ?type=noise refers to the authentication scheme using Noise). From 938202ab47a0ec2f5f9c97392b582ed6f6e91804 Mon Sep 17 00:00:00 2001 From: Danny Salman Date: Wed, 12 Oct 2022 08:03:32 -0400 Subject: [PATCH 10/10] Update content/concepts/transport.md Co-authored-by: Marten Seemann --- content/concepts/transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/concepts/transport.md b/content/concepts/transport.md index a2d54d6d..6a9b967b 100644 --- a/content/concepts/transport.md +++ b/content/concepts/transport.md @@ -296,8 +296,8 @@ a standard local QUIC connection is defined up until and including `/quic.` Then, `/webtransport/` runs over QUIC. The self-signed certificate hash that the server will use to verify the connection. -WebTransport CONNECT is sent as an HTTPS endpoint. The HTTP endpoint of a libp2p WebTransport server -must be located at `/.well-known/libp2p-webtransport`. For instance, the WebTransport URL of a WebTransport +The WebTransport CONNECT request is sent to an HTTPS endpoint. libp2p WebTransport server use +`/.well-known/libp2p-webtransport`. For instance, the WebTransport URL of a WebTransport server advertising `/ip4/1.2.3.4/udp/1234/quic/webtransport/` would be `https://1.2.3.4:1234/.well-known/libp2p-webtransport?type=noise` (the ?type=noise refers to the authentication scheme using Noise).