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:
- 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.
- 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.
Comments