How QUIC makes the web quicker

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.

Server Settings:

LiteSpeed Web Server: QUIC default should be set to ON. A non-self-signed certificate is required.

For more detailed requirements, please see QUIC Requirements.
If you are looking for different QUIC level settings, see Levels Settings
If you are using control panels, see QUIC Setup Method

Client browser QUIC Supports and Settings:

For Chrome, set chrome://flags/#enable-quic to Enabled/Disabled
For Opera, set opera://flags/#enable-QUIC to Enabled/Disabled

Verify QUIC is working

Install an indicator to verify QUIC is functioning.

See QUIC Verify .
Or you can use wireshark with filter quic:
- When QUIC disabled or browser not support, you can not capture any packets
- When QUIC is working, you will capture packets like this

Measure the latency

Use the ping command.

Load page testing steps

Testing page speed with QUIC Disabled (TCP)

When you open our blog site, will see an ESTABLISHED connection though the following command:

netstat -a -n -p tcp -o | findstr ESTABLISHED | findstr your_server_IP

When testing page Load time, make sure connection status has been non-Established every time, you only need to wait around 10-15s.
Or just restart all browsers every time

Testing page speed with QUIC Enabled (UDP)

Make sure QUIC is working, as described above.
Open browser dev tool through Ctrl + Shift + i, make sure Disable cache enabled
Record Load time

Results

Scenario 1: Low Latency(<1ms), QUIC reduces Load time by almost 25%.

Scenario 2: Normal high Latency(80ms) When latency is normal, QUIC reduces Load time by almost 37%.

Test Environment

Server under test: CentOS7 + LiteSpeed Enterprise 5.2 + LSCache + WordPress
Server Location: Scenario1-LAN, Scenario2-Cloud
Server URL: https://blog.litespeedtech.com/
Client Device: Win10 NB, Chrome v60.0.3112
Client Hardware: Intel Core i7-4500 CPU, 8 GB RAM

The higher the latency, the better QUIC performs. Now, why don’t you try it? Use your browser's development tools to check our blog's loading time (or start your experiment on your own site). You will see that QUIC is quicker.

We welcome your feedback on our forum.