Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision Both sides next revision
quic_makes_quicker [2017/08/14 20:53]
Lisa Clarke General proofreading
quic_makes_quicker [2017/08/14 20:02] (current)
Eric Leu [Measure the latency]
Line 1: Line 1:
-====== How QUIC makes the web quicker ====== +====== How QUIC makes web quicker ====== 
-===== Why QUIC===== +===== 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.+QUIC function is running on the UDP, and it improves http transmission efficiency. One of the improvements ​is avoiding TCP head-of-line blocking. ​In 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. The TCP connection needs to wait on that TCP packet before it can continue to send other packets. UDP 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. 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.+More and more people use mobile devices and they constantly switch between WiFi and LTE. It means that if IP changes, a new TCP connection needs to be created, which could cost up to 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 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.  ​+LiteSpeed Web Server ​support QUIC function after version ​5.2.  ​
  
 =====Let’s do a simple experiment===== =====Let’s do a simple experiment=====
 ====Server Settings:​==== ​ ====Server Settings:​==== ​
-LiteSpeed Web ServerQUIC default should be set to ''​ON''​. A non-self-signed ​certificate is required. +LiteSpeed Web Server ​default ​QUIC is `on`, require setup non self-signed ​certificatesMore detail requirments please follow **[[https://​www.litespeedtech.com/​support/​wiki/​doku.php/​litespeed_wiki:​config:​enable_quic#​requirements | QUIC Requierments]]*
-  ​For more detailed requirements,​ please see [[https://​www.litespeedtech.com/​support/​wiki/​doku.php/​litespeed_wiki:​config:​enable_quic#​requirements | QUIC Requirements]]+If you are looking for different QUIC level settings ​please follow **[[https://​www.litespeedtech.com/​support/​wiki/​doku.php/​litespeed_wiki:​config:​enable_quic#​understanding_the_priority_of_the_settings QUIC | Levels Settings]]**  
-  ​* If you are looking for different QUIC level settings, see [[https://​www.litespeedtech.com/​support/​wiki/​doku.php/​litespeed_wiki:​config:​enable_quic#​understanding_the_priority_of_the_settings QUIC | Levels Settings]] ​ +If you are using control panels ​please follow **[[https://​www.litespeedtech.com/​support/​wiki/​doku.php/​litespeed_wiki:​config:​enable_quic#​methods_for_enabling_quic | QUIC Setup Method]]**
-  ​* If you are using control panels, see [[https://​www.litespeedtech.com/​support/​wiki/​doku.php/​litespeed_wiki:​config:​enable_quic#​methods_for_enabling_quic | QUIC Setup Method]]+
 ====Client browser QUIC Supports and Settings: ==== ====Client browser QUIC Supports and Settings: ====
-  * For Chrome, ​set ''​<​nowiki>​chrome://​flags/#​enable-quic</​nowiki>​''​ to ''​Enabled''/''​Disabled''​  +For Chrome, ​check ''​chrome://​flags/#​enable-quic'' ​set to ''​Enabled''/''​Disabled''​ 
-  ​* ​For Opera, ​set ''​<​nowiki>​opera://​flags/#​enable-QUIC</​nowiki>​''​ to ''​Enabled''/''​Disabled''​+For Opera, ​check ''​opera://​flags/#​enable-QUIC'' ​set to ''​Enabled''/''​Disabled''​
 ====Verify QUIC is working==== ====Verify QUIC is working====
-Install ​an indicator to verify QUIC is functioning. +  * Install indicator to verify QUIC function, please follow **[[https://​www.litespeedtech.com/​support/​wiki/​doku.php/​litespeed_wiki:​config:​enable_quic#​how_to_verify_quic_is_enabled | Verify ]]**  
-  ​See [[https://​www.litespeedtech.com/​support/​wiki/​doku.php/​litespeed_wiki:​config:​enable_quic#​how_to_verify_quic_is_enabled | QUIC Verify ]]. +  * Or you can use wireshark with filter ''​quic'' ​to verify QUIC is working or not
-  * Or you can use wireshark with filter ''​quic''​:+
     * When QUIC disabled or browser not support, you can not capture any packets     * When QUIC disabled or browser not support, you can not capture any packets
-    * When QUIC is working, you will capture packets ​like this \\ {{:​quic_wireshark.png?​500|}}+    * When QUIC is working, you will cature packates ​like this \\ {{:​quic_wireshark.png?​400|}}
 ====Measure the latency==== ====Measure the latency====
-Use the ''​ping'' ​command\\ {{:​ping_latency.png?​500|}} +  * Use ping command \\ {{:​ping_latency.png?​400|}} 
-====Load page testing steps==== +Load page testing steps 
-===Testing ​page speed with QUIC Disabled (TCP)=== +  * When testing ​page speed with QUIC Disabled (TCP). <br> 
-When you open our blog site, will see an ESTABLISHED connection though ​the following command: +When you open our blog site, will see an ESTABLISHED connection though ​cmd \\ <​code>​netstat -a -n -p tcp -o | findstr ESTABLISHED | findstr your_server_IP </​code> ​\\ {{:​netstat.png?​400|}} 
-<​code>​netstat -a -n -p tcp -o | findstr ESTABLISHED | findstr your_server_IP </​code>​ +    * When testing page Load time, make sure connection status has been non-Established every time, you only need to wait around 10-15s. \\ {{:​str_empty.png?​400|}} 
-{{:​netstat.png?​500|}} +    * Or just restart all browsers every time  
-  * When testing page Load time, make sure connection status has been non-Established every time, you only need to wait around 10-15s. \\ {{:​str_empty.png?​500|}} +  * When testing ​page speed with QUIC Enabled (UDP) 
-  * Or just restart all browsers every time  +    * Make sure QUIC is working ​by following “Verify QUIC is working”
-===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 ​   * Open browser dev tool through ''​Ctrl + Shift + i'',​ make sure ''​Disable cache''​ enabled ​
-  ​* Record **Load** time +    ​* Record **Load** time \\ {{:​quic-dev.png?​400|}}
-  ​{{:​quic-dev.png?​500|}}+
  
-====Results==== +Scenario 1: Low Latency(<​1ms),​ QUIC reduces **Load** time by almost 25%.\\ {{:​low_latency.png?​500|}}
-Scenario 1: Low Latency(<​1ms),​ QUIC reduces **Load** time by almost ​**25%**.\\ {{:​low_latency.png?​500|}}+
  
-Scenario 2: Normal high Latency(80ms) When latency is normal, QUIC reduces **Load** time by almost ​**37%**.\\ {{:​nj-latency.png?​500|}}+Scenario 2: Normal high Latency(80ms) When latency is normal, QUIC reduces **Load** time by almost 37%.\\ {{:​nj-latency.png?​500|}}
  
-====Test Environment====+Test Environment
   * Server under test: CentOS7 + LiteSpeed Enterprise 5.2 + LSCache + WordPress   * Server under test: CentOS7 + LiteSpeed Enterprise 5.2 + LSCache + WordPress
-  * Server Location: ​Scenario1-LAN, Scenario2-Cloud ​+  * Server Location: ​Senario1-LAN, Senario2-Cloud ​
   * Server URL: https://​blog.litespeedtech.com/​   * Server URL: https://​blog.litespeedtech.com/​
   * Client Device: Win10 NB, Chrome v60.0.3112   * Client Device: Win10 NB, Chrome v60.0.3112
   * Client Hardware: Intel Core i7-4500 CPU, 8 GB RAM   * Client Hardware: Intel Core i7-4500 CPU, 8 GB RAM
  
-The higher the latency, ​the better ​QUIC performs. +Along with latency ​higher, QUIC performs ​more clear.  
-Now, why don’t ​//you// try it? +Now, why don’t you try it now
-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**+Check our blog site Loading ​time with dev tool, you will see QUIC more quicker by Enabling QUIC function. You can also start your experiment on your site.  
 + 
 +We welcome your feedback on our **[[https://​www.litespeedtech.com/​support/​forum/​ | forum]]** 
 + 
 + 
 + 
 + 
 + 
  
-We welcome your feedback on our [[https://​www.litespeedtech.com/​support/​forum/​ | forum]]. 
  
  • Admin
  • Last modified: 2017/08/14 20:53
  • by Lisa Clarke