LiteSpeed

Tag: developers corner

Learn about what LiteSpeed is working on currently, from the point of view of our developers. Explore exciting cutting-edge technologies right along with us. Get a peek behind-the-scenes at some of the decision-making processes that go into creating good software. Our mission is to accelerate the internet, and with this series, you get a glimpse into how we do it.

  • Developer’s Corner: Why Use LiteSpeed QUIC Library

    Developer’s Corner: Why Use LiteSpeed QUIC Library

    Projects and individuals have expressed interest in having a standalone QUIC library. The newly-released LiteSpeed Client Library is a good choice for many applications.

    When it comes to selecting a working QUIC library, one has few choices:

    • lsquic — standalone QUIC client library;
    • proto-quic — standalone QUIC client and server library; and
    • quic-go — standalone client and server library.

    quic-go may be inconvenient to incorporate if you do not use the Go programming language and I will not comment upon this library further in this post.

    Since the time it was first released in April of last year, proto-quic has been utilized in some projects. Now that Google no longer maintains proto-quic, these projects have a choice to make: maintain proto-quic, or their derivative thereof, themselves or switch to the newly-released LiteSpeed Client Library. For those that have not yet decided which QUIC library they want to use, I list the arguments in favor of the LiteSpeed implementation below:

    LSQUIC Is Actively Maintained

    The LSQUIC Client Library is maintained, whereas proto-quic is not. Integrating Chromium’s QUIC code into your program requires extracting the relevant bits from Chromium and updating them as new QUIC versions appear. On the other hand, the LSQUIC Client Library is a standalone component that we plan to maintain going forward.

    LSQUIC Is Future-Proof

    We use this code ourselves in our own products. We will continue to support the current line of QUIC versions (Google QUIC) and add support for the upcoming IETF versions of QUIC. We are not abandoning this code.

    LSQUIC Is C, proto-quic is C++

    LSQUIC is written in C99, proto-quic in C++11. The LSQUIC Client Library is easy to integrate into both C and C++ projects.

    LSQUIC Offers Versatile APIs

    Not tied to an event loop

    Our QUIC library is not tied to any specific event loop. In fact, it is not tied to an event loop at all — you do not have to use an event loop to drive the library.

    BYO networking code

    LSQUIC does not do its own networking. Instead, it provides a simple “packets in / packets out” interface. This makes the library quite flexible. And portable, too.

    LSQUIC Consumes Fewer Resources

    proto-quic consumes more CPU and memory than the LSQUIC Client Library. This is mainly due to two factors:

    1. proto-quic is part of Chromium, the market-leading browser. As a user application, its job is to provide features to the user (usually just one user on the machine); resource use is a secondary consideration. The LSQUIC Client Library, on the other hand, is born from LiteSpeed’s implementation of QUIC on the server side. We designed the library with scalability in mind.
    2. Pioneering — and experimental — work on QUIC implementation takes place in Chromium. proto-quic code is full of special cases for various experiments and options that are not used in production. The LSQUIC Client Library implements features and options strictly as required by the protocol.

    LSQUIC Codebase Is Small

    The LSQUIC Client Library is approximately 74,000 lines of code (with the core functionality only about 36,000 lines), as counted by wc(1), while Chromium’s QUIC code size is 156,000 lines of code.

    I hope this was convincing. All that’s left is to do this:

    git clone https://github.com/litespeedtech/lsquic-client.git

    From the cutting edge, until next time,

    LiteSpeed QUIC Team.

  • Developer’s Corner: QUIC v39 Added

    Developer’s Corner: QUIC v39 Added

    LiteSpeed is glad to announce support for QUIC1 v39. This is the QUIC version used in Chrome 62, currently available in the Chrome Dev Release Channel.

    The switch from little-endian to big-endian representation in the packet and frame formats was the biggest change with regard to the amount of code that had to be modified. Because we need to support both little-endian (such as QUIC v37 used in Chrome 60) and big-endian QUIC versions, we could not simply replace all instances of the former with the latter. Some modules had to be reorganized and new interfaces were added. While this is a lot of work, I like this sort of refactoring: One is forced to think more clearly about module responsibilities and relationships, and the end result is better code.

    On the protocol side, QUIC v39 introduces a couple of improvements in the way packets are acknowledged, making QUIC more efficient.

    When the next Chrome release becomes stable, our customers will be ready to serve the next version of QUIC.

    From the cutting edge, until next time,

    LiteSpeed QUIC Team.

    —
    1. Technically, the correct way to write it now is Google QUIC, or gQUIC. This differentiates it from IETF QUIC. The IETF QUIC is to become a standard, at which point it will be referred to simply as QUIC.