Want to subscribe to topics you're interested in?
Become a Member

WebPerf QUIC - Faster Content Delivery on Layer 4

Discussion in 'All Internet & Web Performance News' started by eva2000, Oct 11, 2019.

  1. eva2000

    eva2000 Administrator Staff Member

    54,315
    12,198
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +18,763
    Local Time:
    1:51 AM
    Nginx 1.27.x
    MariaDB 10.x/11.4+
    [​IMG]
    After HTTP/2, coming up next is QUIC (Quick UDP Internet Connections). Google has been working for quite some time to speed up its network protocols in order to minimize website response times. After HTTP/2 has fulfilled its task of speeding up HTTP(S) and has become the basis for fast TLS connections, QUIC goes one step further by aiming to replace the TCP transport protocol in the Internet.

    Fast UDP with QUIC


    TCP and TLS usually require one or more round trip times (RTTs) during their connection establishment. An RTT is the total time it takes for a request to go from the starting point to the destination and then back to the starting point. Google is hopeful that QUIC can reduce connection costs towards zero RTTs.

    [​IMG]
    Source: Chromium

    TCP ensures that all packets arrive in order, but does so in a somewhat cumbersome manner, which slows down data transmission on the Internet. By contrast, QUIC is based on UDP, which is used for streaming data (hence the name Quick UDP Internet Connections). Unique sequence numbers ensure that no data packet get lost. The other most important component used is the TLS encryption protocol, which has mostly appeared in conjunction with TCP until now. While no corners are cut with regard to security, doing away with handshakes and multiplex transmissions enables faster transmission, even compared to other UDP-based protocols, reportedly.

    From Google’s QUIC FAQ:

    Why can’t you just evolve and improve TCP under SPDY? That is our goal. TCP support is built into the kernel of operating systems. Considering how slowly users around the world upgrade their OS, it is unlikely to see significant adoption of client-side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas, and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.


    Google plans to propose QUIC as an IETF standard.

    QUIC has been in the making since 2013. The protocol has been supported by Chrome since version 29. According to Google, about half of all requests from Chrome to Google web servers are served over QUIC. It can be enabled in Chrome by going to chrome://flags/#enable-quic in the browser address bar.

    [​IMG]

    It can be enabled in Opera by going to opera://flags/#enable-quic in the browser address bar.

    [​IMG]
    QUIC instead of TCP



    Google has found that 75% of all requests are served faster over QUIC and that TCP-based websites as well as streaming media will benefit from it. Especially for video services like YouTube, where users report 30% fewer rebuffers when watching videos over QUIC. As a next step, Google plans to propose QUIC to the IETF, the organization responsible for network protocols, as an Internet standard. If the standard establishes itself and other servers implement it, TCP may soon be superseded on the Web.


    QUIC - the next level of acceleration on the transport layer.

    We currently have no plans when we can make it available on all our edge servers, but we have already started to engineer possible integration scenarios and will keep you updated. You can also join Google’s news group discussion.

    Continue reading...