HTTP/3:修订间差异

来自WHY42
Riguz留言 | 贡献
Riguz留言 | 贡献
 
(未显示同一用户的33个中间版本)
第2行: 第2行:


* [https://datatracker.ietf.org/doc/html/rfc9114 RFC9114]
* [https://datatracker.ietf.org/doc/html/rfc9114 RFC9114]
* [https://http3-explained.haxx.se/en/ HTTP3 explained]
* [https://quicwg.org/ QUIC WorkingGroup]
[[Image:HTTP3 changes.webp|600px]]<ref>https://ably.com/topic/http3</ref>


[[Image:HTTP semantics.png|300px]]<ref>https://nestify.io/blog/http-3-everything-you-need-to-know/</ref>
[[Image:HTTP semantics.png|300px]]<ref>https://nestify.io/blog/http-3-everything-you-need-to-know/</ref>
第7行: 第11行:
= Overview =
= Overview =
== HTTP/2 vs HTTP/3 ==
== HTTP/2 vs HTTP/3 ==
[[Image: QUIC vs TCP.webp|600px]]


One of the main touted advantages of HTTP/3 is increased performance, specifically around fetching multiple objects simultaneously. With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking). Because HTTP/3 is UDP-based, if a packet gets dropped that only interrupts that one stream, not all of them.
One of the main touted advantages of HTTP/3 is increased performance, specifically around fetching multiple objects simultaneously. With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking). Because HTTP/3 is UDP-based, if a packet gets dropped that only interrupts that one stream, not all of them.
第17行: 第22行:
== Performance ==
== Performance ==
[[Image:HTTP3 performance.webp|600px]]<ref>https://requestmetrics.com/web-performance/http3-is-fast/</ref>
[[Image:HTTP3 performance.webp|600px]]<ref>https://requestmetrics.com/web-performance/http3-is-fast/</ref>
=Resources =
== cURL with HTTP3==
=== Install build tools ===
<syntaxhighlight lang="bash">
wget http://ftp.gnu.org/gnu/m4/m4-latest.tar.gz
wget http://ftp.gnu.org/gnu/autoconf/autoconf-latest.tar.gz
wget https://ftp.gnu.org/gnu/automake/automake-1.16.5.tar.gz
wget https://ftpmirror.gnu.org/libtool/libtool-2.4.7.tar.gz
cd m4-*
./configure
make && sudo make install
wget https://pkg-config.freedesktop.org/releases/pkg-config-0.29.2.tar.gz
./configure --with-internal-glib
</syntaxhighlight>
=== Build curl===
Ref: https://github.com/curl/curl/blob/master/docs/HTTP3.md
Build nghttp3:
<syntaxhighlight lang="bash">
git clone -b v1.1.0 https://github.com/ngtcp2/nghttp3
cd nghttp3
autoreconf -fi
./configure --enable-lib-only
make && sudo make install
</syntaxhighlight>
Build OpenSSL:
<syntaxhighlight lang="bash">
wget https://www.openssl.org/source/openssl-3.2.0.tar.gz
cd openssl
./config enable-tls1_3
make && sudo make install
</syntaxhighlight>
Build libpsl:
<syntaxhighlight lang="bash">
wget https://github.com/rockdaboot/libpsl/releases/download/0.21.5/libpsl-0.21.5.tar.gz
./configure
make && sudo make install
</syntaxhighlight>
Build curl:
<syntaxhighlight lang="bash">
git clone https://github.com/curl/curl
cd curl
autoreconf -fi
./configure --with-openssl=/usr/local --with-openssl-quic --with-nghttp3=/usr/local
make && sudo make install
</syntaxhighlight>
=== Test HTTP3 pages===
<syntaxhighlight lang="bash">
/usr/local/bin/curl --version
curl 8.6.0-DEV (aarch64-apple-darwin22.6.0) libcurl/8.6.0-DEV OpenSSL/3.2.0 zlib/1.2.11 libpsl/0.21.5 OpenSSL/3.2.0 nghttp3/1.1.0
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTP3 HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets
/usr/local/bin/curl --http3 https://cloudflare-quic.com -I
HTTP/3 200
date: Tue, 23 Jan 2024 07:55:42 GMT
content-type: text/html
content-length: 125959
server: cloudflare
cf-ray: 849e79d4bacf0468-HKG
alt-svc: h3=":443"; ma=86400
</syntaxhighlight>
== HTTP3 test sites ==
* https://cloudflare-quic.com
* https://www.chromium.org/quic
* https://www.greenpeace.org
It's also possile to start a local server:
=== quiche-server ===
<syntaxhighlight lang="bash">
cd quiche
RUST_LOG=trace cargo run --bin quiche-server -- --cert apps/src/bin/cert.crt --key apps/src/bin/cert.key
/usr/local/bin/curl --http3  -I https://127.0.0.1:4433 --insecure
HTTP/3 405
server: quiche
content-length: 0
</syntaxhighlight>
Note: this could not be requested by browser.
=== caddy ===
Download caddy via https://caddyserver.com/download:
<syntaxhighlight lang="bash">
chmod +x caddy_darwin_arm64
sudo mv caddy_darwin_arm64 /usr/local/bin/caddy
</syntaxhighlight>
Caddyfile:
<syntaxhighlight lang="json">
{
servers {
        protocols h1 h2 h3
}
}
localhost:8080 {
    file_server {
        root /Users/riguz/Downloads
        browse
    }
}
</syntaxhighlight><ref>https://caddyserver.com/docs/caddyfile/options#protocols</ref>
<syntaxhighlight lang="bash">
caddy run
# if http3 somehow not working, try restart it
# see: https://caddy.community/t/firefox-not-always-using-http-3/13755
</syntaxhighlight>
[[Image:Caddy-h3.png|600px]]
== Browser support ==
* https://caniuse.com/http3
Chrome/Firefox need to be configured.<ref>https://www.smashingmagazine.com/2021/09/http3-practical-deployment-options-part3/</ref>
Firefox: set <syntaxhighlight lang="bash" inline>network.http.http3.enabled=true</syntaxhighlight> in about:config
Chrome(also need to disable cache):
<syntaxhighlight lang="bash">
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-quic --origin-to-force-quic-on=localhost:443
</syntaxhighlight>
If the scheme is not h3 for a h3-supported site, check it with curl first, might be a firewall problem.
[[Image:h3-curl.png|600px]]
= FAQ =
=== Is HTTP/3 using UDP more reliable than HTTP/2 (etc.) using TCP?===
It isn’t more reliable.
It has quite different performance properties in some ways, mostly lower latency for HTTP requests, and much lower latency for HTTPS session setup.
But the reliability is the same or lower. That’s not the point.<ref>https://www.quora.com/Why-is-HTTP-3-using-UDP-more-reliable-than-HTTP-2-etc-using-TCP</ref>
=== Why is encryption significant in HTTP/3?===
HTTP/3 encrypts connections by default at the transport layer, offering improved security. This differs from previous versions, where encryption occurred separately at the application layer. Encrypting by default helps protect user data, reduces latency, and ensures a safer browsing experience.
===Is HTTP client side connection pooling still valid when QUIC, HTTP/3 is the major/all traffic expected? ===
It's still valid, because<ref>https://stackoverflow.com/questions/66182978/is-http-client-side-connection-pooling-still-valid-when-quic-http-3-is-the-majo</ref>:
* a 0-RTT request is more computentionally expensive on both the client as well as the server side than just reusing the connection, since all private key crypto operations and certificate checks still apply
* 0-RTT requests can introduce security issues due to providing a chance for replay attacks (see https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-34#section-9.2). Without using the 0-RTT feature a QUIC handshake still requires 1-RTT.
However since QUIC already provides multiplexing multiple requests on a stream the client should not be required to keep a full pool of connections around. A single connection is typically sufficient, as long as the server advertises being able to support a high enough number of streams.


[[Category:Network]]
[[Category:Network]]

2024年1月31日 (三) 05:44的最新版本

HTTP/3 is the third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web, complementing the widely-deployed HTTP/1.1 and HTTP/2. Unlike previous versions which relied on the well-established TCP (published in 1974), HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP. On 6 June 2022, IETF published HTTP/3 as a Proposed Standard in RFC 9114.

[1]

[2]

Overview

HTTP/2 vs HTTP/3

One of the main touted advantages of HTTP/3 is increased performance, specifically around fetching multiple objects simultaneously. With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking). Because HTTP/3 is UDP-based, if a packet gets dropped that only interrupts that one stream, not all of them.

In addition, HTTP/3 offers 0-RTT support, which means that subsequent connections can start up much faster by eliminating the TLS acknowledgement from the server when setting up the connection. This means the client can start requesting data much faster than with a full TLS negotiation, meaning the website starts loading earlier.[3]

HTTP2 HTTP3

Performance

[4]

Resources

cURL with HTTP3

Install build tools

wget http://ftp.gnu.org/gnu/m4/m4-latest.tar.gz
wget http://ftp.gnu.org/gnu/autoconf/autoconf-latest.tar.gz
wget https://ftp.gnu.org/gnu/automake/automake-1.16.5.tar.gz
wget https://ftpmirror.gnu.org/libtool/libtool-2.4.7.tar.gz

cd m4-*
./configure
make && sudo make install

wget https://pkg-config.freedesktop.org/releases/pkg-config-0.29.2.tar.gz
./configure --with-internal-glib

Build curl

Ref: https://github.com/curl/curl/blob/master/docs/HTTP3.md

Build nghttp3:

git clone -b v1.1.0 https://github.com/ngtcp2/nghttp3
cd nghttp3
autoreconf -fi
./configure --enable-lib-only
make && sudo make install

Build OpenSSL:

wget https://www.openssl.org/source/openssl-3.2.0.tar.gz
cd openssl
./config enable-tls1_3 
make && sudo make install

Build libpsl:

wget https://github.com/rockdaboot/libpsl/releases/download/0.21.5/libpsl-0.21.5.tar.gz
./configure
make && sudo make install

Build curl:

git clone https://github.com/curl/curl
cd curl
autoreconf -fi
./configure --with-openssl=/usr/local --with-openssl-quic --with-nghttp3=/usr/local
make && sudo make install

Test HTTP3 pages

/usr/local/bin/curl --version
curl 8.6.0-DEV (aarch64-apple-darwin22.6.0) libcurl/8.6.0-DEV OpenSSL/3.2.0 zlib/1.2.11 libpsl/0.21.5 OpenSSL/3.2.0 nghttp3/1.1.0
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTP3 HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets

/usr/local/bin/curl --http3 https://cloudflare-quic.com -I
HTTP/3 200
date: Tue, 23 Jan 2024 07:55:42 GMT
content-type: text/html
content-length: 125959
server: cloudflare
cf-ray: 849e79d4bacf0468-HKG
alt-svc: h3=":443"; ma=86400

HTTP3 test sites

It's also possile to start a local server:

quiche-server

cd quiche
RUST_LOG=trace cargo run --bin quiche-server -- --cert apps/src/bin/cert.crt --key apps/src/bin/cert.key

/usr/local/bin/curl --http3  -I https://127.0.0.1:4433 --insecure
HTTP/3 405
server: quiche
content-length: 0

Note: this could not be requested by browser.

caddy

Download caddy via https://caddyserver.com/download:

chmod +x caddy_darwin_arm64
sudo mv caddy_darwin_arm64 /usr/local/bin/caddy

Caddyfile:

{
	servers {
        protocols h1 h2 h3
	}
}


localhost:8080 {
    file_server {
        root /Users/riguz/Downloads
        browse
    }
}

[5]

caddy run
# if http3 somehow not working, try restart it
# see: https://caddy.community/t/firefox-not-always-using-http-3/13755

Browser support

Chrome/Firefox need to be configured.[6]

Firefox: set network.http.http3.enabled=true in about:config

Chrome(also need to disable cache):

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-quic --origin-to-force-quic-on=localhost:443

If the scheme is not h3 for a h3-supported site, check it with curl first, might be a firewall problem.

FAQ

Is HTTP/3 using UDP more reliable than HTTP/2 (etc.) using TCP?

It isn’t more reliable.

It has quite different performance properties in some ways, mostly lower latency for HTTP requests, and much lower latency for HTTPS session setup.

But the reliability is the same or lower. That’s not the point.[7]

Why is encryption significant in HTTP/3?

HTTP/3 encrypts connections by default at the transport layer, offering improved security. This differs from previous versions, where encryption occurred separately at the application layer. Encrypting by default helps protect user data, reduces latency, and ensures a safer browsing experience.

Is HTTP client side connection pooling still valid when QUIC, HTTP/3 is the major/all traffic expected?

It's still valid, because[8]:

  • a 0-RTT request is more computentionally expensive on both the client as well as the server side than just reusing the connection, since all private key crypto operations and certificate checks still apply
  • 0-RTT requests can introduce security issues due to providing a chance for replay attacks (see https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-34#section-9.2). Without using the 0-RTT feature a QUIC handshake still requires 1-RTT.

However since QUIC already provides multiplexing multiple requests on a stream the client should not be required to keep a full pool of connections around. A single connection is typically sufficient, as long as the server advertises being able to support a high enough number of streams.