Enable or Disable QUIC and HTTP/3¶

Enabling QUIC and HTTP/3¶

LiteSpeed Web Server supports HTTP/3. In fact, LiteSpeed was the first to introduce production-grade HTTP/3 web server support. And, as the new protocol continues to be defined, we are there at every step, keeping our implementation current and cutting-edge.

HTTP/3 is the newest version of the Hypertext Transfer Protocol, formerly referred to as "HTTP over QUIC," and is the successor to HTTP/2.

QUIC was originally a Google effort to improve HTTP/2 by transporting it encrypted over UDP. In 2016, the IETF began working to standardize the protocol. Part of that process involved splitting QUIC into the transport protocol (QUIC) and the application protocol (HTTP/3). To learn more about it, please see our HTTP/3 FAQ.

It is easy to start using QUIC and HTTP/3 with LiteSpeed Web Server. Simply open UDP port 443. QUIC is on by default, and HTTP/3 connections will automatically be made with browsers that support it. There is no configuration change required.

Required:

• HTTPS with trusted certificate
• UDP port 443 open at the firewall

Open UDP Port 443 at the Firewall¶

QUIC runs a stream-multiplexing protocol over Transport Layer Security (TLS) on top of UDP instead of TCP. Be sure you've enabled the port with both TCP and UDP. Most of the time, TCP 443 is already enabled.

You can quickly check to make sure it is listening by running

netstat -lupn | grep 443

udp        0      0 127.0.0.1:443         0.0.0.0:*                               18918/litespeed (ls
udp        0      0 x.x.x.x:443           0.0.0.0:*                               18918/litespeed (ls 
udp        0      0 :::443                :::*                                    18918/litespeed (ls

QUIC itself should auto listen on UDP port 443, but any firewall that is running must be configured so that port 443 is open.

You will need to identify which firewall is running, such as firewalld, iptables, csf, or other external firewalls.

When Using CSF¶

If CSF is used, you need to enable it at the CSF level. Navigate to ConfigServer Security & Firewall > csf - ConfigServer Firewall > Firewall Configuration > IPv4 Port Settings > and add 443 to the lists in UDP_IN and UDP_OUT.

Also make sure that UDPFLOOD is set to Off 0.

When Using iptables¶

Enable port 443 with the following command:

iptables -I INPUT -p udp --dport 443 -j ACCEPT
/sbin/service iptables save
/sbin/service iptables restart

Testing Incoming and Outgoing UDP Connections¶

Although you have enabled UDP on 443 on your server, it may be blocked by the data center at the route, switch, or firewall level. To verify this, you can test using the following method:

Step 1: Use any other server which has UDP 443 Port open to send a 1 byte UDP packet to your server where your website is hosted.

    nc -z -v -u YOUR_SERVER_IP 443  

    tcpdump -i eth0 -A -s0 port 443 and udp

The output on the Step 2 should look like this if the packet is recieved correctly -

    listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    09:09:57.124659 IP client-hostname.38227 > server-hostname.https: UDP, length 1
    E.....@.6...3S..3M@..S...   ....................

Verifying QUIC and HTTP/3 are Enabled¶

You can test your own site, or any site on the Internet, with the free HTTP/3 Check tool. Enter a URL, and HTTP/3 Check will tell you whether QUIC or HTTP/3 are supported by that site. Detailed connection information, including HTTP header and QLOG output are provided as well. (Please check out our video tutorial, if needed.)

Another option is the HTTP Indicator extension for Chrome or Mozilla. It displays a lightning bolt in the Chrome toolbar. Blue indicates HTTP/2 is enabled, and orange indicates HTTP/3. Alternatively, you can hover over the lightning bolt to see a tool tip that displays the protocol in use.

Troubleshooting Checklist¶

If QUIC is not working for you, keep these requirements in mind:

• Must have QUIC enabled in GUI/conf
• Must use either Chrome or Opera with QUIC enabled
• Must not use self-signed certificates only trusted certificates will work
• Must configure SSL Settings correctly
• Must have UDP Port 443 open at the firewall
• QUIC will not work with a proxy front end like CloudFlare
• QUIC will only applied to HTTPS, not HTTP
• QUIC can be enabled at the server level, listener level or virtual host level
• QUIC won't work with LSWS 5.2.8 anymore as Chrome only speaks "quic/43", while LSWS 5.2.8 only supports up to "quic/39"

Three Levels of QUIC Control¶

QUIC can be enabled or disabled at three different levels: Virtual Host, Listener, and Server. It's important to understand how these settings affect each other. If QUIC is not explicitly turned off at any level, then priority for enabling QUIC is given at the most specific level: Virtual Host, then Listener, then Server. If QUIC is explicity turned off at any level, then none of the more specific levels may turn it on. In other words, if QUIC is turned off at the Server level, then it cannot be turned on at the Listener level or at the Virtual Host level.

Put another way:

For a particular Virtual Host, QUIC will be ON if:

• Virtual Host Level = ON or is not set AND
• Listener Level = ON or is not set AND
• Server Level = ON or is not set.

For a particular Virtual Host, QUIC will be OFF if:

• Virtual Host Level = OFF OR
• Listener Level = OFF OR
• Server Level = OFF.

Here is an example setup:\

If QUIC is enabled, HTTP/3 will be used automatically to serve requests to browsers that support it.

Disabling QUIC¶

Server Level¶

For EA4: Add following lines to /etc/apache2/conf.d/includes/pre_main_global.conf

<IfModule LiteSpeed>
  QuicEnable off
</IfModule>

Virtual Host Level¶

For EA4: Create a quic_vhosts.conf file in the /etc/apache2/conf.d/userdata/str/2_4/user/domain/ then add following lines.

<IfModule LiteSpeed>
  QuicEnable off
</IfModule>

For an SSL website, create quic_vhosts.conf in /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain>.

If you want to disable QUIC for an account you can create quic_vhosts.conf in /etc/apache2/conf.d/userdata/ssl/2_4/<user>.

After these changes are made, rebuild Apache conf with the following command:

/usr/local/cpanel/scripts/rebuildhttpdconf

Finally, restart LiteSpeed Web Server.

Controlling HTTP/3 via Apache Config¶

You can enable and disable a variety of protocols in httpd.conf, using the SpdyEnabled directive.

<IfModule LiteSpeed>
SpdyEnabled off
</IfModule>

<IfModule LiteSpeed>
SpdyEnabled http2 http3
</IfModule>

HTTP protocols are enabled by default, while SPDY protols are disabled by default.

Why QUIC?¶

The QUIC function is running on top of UDP, which improves HTTP transmission efficiency. One of the ways it does so is by avoiding TCP head-of-line blocking. With TCP, packets need to arrive in the correct order. If a packet is lost on its way to the server, it needs to be retransmitted, and the TCP connection needs to wait on that TCP packet before it can continue to send other packets. UDP, on the other hand, is not dependent on the order packets are received. While it's still possible for packets to get lost during transmission, they will only impact individual resources, e.g. the site's CSS file, and will not block the entire connection.

More and more people use mobile devices and they constantly switch between WiFi and LTE. Under TCP, when the IP changes, a new connection needs to be created, which could cost up to 200ms: 50ms*(handshake*3+tls*1)=200ms. QUIC has implemented its own identifier for unique connections called the Connection UUID. It's possible to switch between WiFi and LTE and still keep your connection's UUID. Therefore, renegotiating the connection is no longer needed, and your previous connection is still valid.

QUIC is supported in LiteSpeed Web Server versions 5.2 and up.

Enable HTTP/2¶

LiteSpeed Web Server has supported HTTP/2 out of the box since Enterprise Version 5.0. HTTP/2 and SPDY are enabled by default for SSL listeners.

Some things to keep in mind:

• If using a front-end SSL proxy server, enabling SPDY or HTTP/2 on LiteSpeed Web Server will have no effect, as front-end SSL proxies are not capable of forwarding SPDY and HTTP/2 requests.
• HTTP/2 requires OpenSSL 1.0.2 as minimum. OpenSSL versions less than 1.0.2 will force HTTP/2 connections to HTTP/1. However, LiteSpeed Enterprise Web Server is staticly linked with latest OpenSSL 1.0.2 release and does not depend on the OpenSSL version installed in the system.
• HTTP/2 should work out of box for all HTTPS sites with LiteSpeed. Although HTTP/2 specification does not require TLS, TLS is required by browser implementations.

You can enable HTTP/2 with the SpdyEnabled directive in the httpd.conf configuration file, or via the WebAdmin Console.

Via Configuration File¶

In httpd.conf, use the SpdyEnabled http2 directive to enable HTTP/2, like so:

<IfModule LiteSpeed>
SpdyEnabled http2
</IfModule>

Other valid parameters are spdy2, spdy3, http3 and off.

All protocols are enabled by default. As such, if you wish to use SPDY, HTTP/2, and HTTP/3, there is no need for a SpdyEnabled directive at all.

When you use this directive to explicitly enable one or more protocols, anything not selected will be disabled. For example, SpdyEnabled http2 will enable HTTP/2, while SPDY and HTTP/3 will be disabled.

Via WebAdmin Console¶

In the WebAdmin Console, you can find the Enable SPDY/HTTP2/HTTP3 option in the SSL tab for both Listeners and Virtual Hosts. Select the HTTP/2 option to enable HTTP/2.

Verifying HTTP/2 is enabled¶

Though you can use the third party web tools to check, the most common and easy way to check is through browser's developer tools. h2 and http/2 mean HTTP/2 has been enabled for your server.

If you use third-party web tools, it could show as the following:

Troubleshooting¶

You're using a reverse proxy CDN like Cloudflare¶

Cloudflare and other CDNs like it may support QUIC connections on the client side, but as of this writing, no CDN (aside from QUIC.cloud) supports QUIC connections to backend servers. As a result, you cannot use or test your LSWS QUIC connection with a service like Cloudflare in front. Please disable your reverse proxy CDN in order to use QUIC with LiteSpeed.

Possibly Google Chrome has not enabled QUIC by default¶

At some point we noticed that Google Chrome decided to temporarily disable QUIC by default. Some users explicitly have to enable QUIC under chrome://flags. This may not be the case for you, but it's a good idea to check whether QUIC is enabled in Chrome.

Possibly bad cached SSL certificates¶

Sometimes, especially when the site in question has encountered an SSL/TLS error before, Chrome will save the certificate in cache and cause QUIC to be unable to establish a connection. In this case, it can simply be fixed by clearing the browser cache.

UDP rate limiting option in CSF should be disabled¶

If CSF is used, the UDP rate-limiting option is normally disabled by default. You should see UDPFLOOD = "0". However, if you have enabled it somehow, please disable it before running any QUIC checker, such as http3check.net.

# Outgoing UDP Flood Protection. This option limits outbound UDP packet floods.
# These typically originate from exploit scripts uploaded through vulnerable
# web scripts. Care should be taken on servers that use services that utilise
# high levels of UDP outbound traffic, such as SNMP, so you may need to alter
# the UDPFLOOD_LIMIT and UDPFLOOD_BURST options to suit your environment
#
# We recommend enabling User ID Tracking (UID_INTERVAL) with this feature
UDPFLOOD = "0"
UDPFLOOD_LIMIT = "100/s"
UDPFLOOD_BURST = "500"
# This is a list of usernames that should not be rate limited, such as "named"
# to prevent bind traffic from being limited.
#
# Note: root (UID:0) is always allowed
UDPFLOOD_ALLOWUSER = "named"

LF_SPI needs to be turned off when CSF is used¶

LF_SPI in CSF should be turned off (set LF_SPI = 0).

According to CFS, LF_SPI option configures CSF iptables as a Stateful Packet Inspection (SPI) firewall as the default (which means LF_SPI = 1). If the server has a broken stateful connection tracking kernel then this setting can be set to 0 to configure CSF iptables to be a Static firewall, though some funtionality and security will be inevitably lost.