c51ce3387f
- [API Change] Sendfile-like functionality is gone. The stream no longer opens files and deals with file descriptors. (Among other things, this makes the code more portable.) Three writing functions are provided: lsquic_stream_write lsquic_stream_writev lsquic_stream_writef (NEW) lsquic_stream_writef() is given an abstract reader that has function pointers for size() and read() functions which the user can implement. This is the most flexible way. lsquic_stream_write() and lsquic_stream_writev() are now both implemented as wrappers around lsquic_stream_writef(). - [OPTIMIZATION] When writing to stream, be it within or without the on_write() callback, place data directly into packet buffer, bypassing auxiliary data structures. This reduces amount of memory required, for the amount of data that can be written is limited by the congestion window. To support writes outside the on_write() callback, we keep N outgoing packet buffers per connection which can be written to by any stream. One half of these are reserved for the highest priority stream(s), the other half for all other streams. This way, low-priority streams cannot write instead of high-priority streams and, on the other hand, low-priority streams get a chance to send their packets out. The algorithm is as follows: - When user writes to stream outside of the callback: - If this is the highest priority stream, place it onto the reserved N/2 queue or fail. (The actual size of this queue is dynamic -- MAX(N/2, CWND) -- rather than N/2, allowing high-priority streams to write as much as can be sent.) - If the stream is not the highest priority, try to place the data onto the reserved N/2 queue or fail. - When tick occurs *and* more packets can be scheduled: - Transfer packets from the high N/2 queue to the scheduled queue. - If more scheduling is allowed: - Call on_write callbacks for highest-priority streams, placing resulting packets directly onto the scheduled queue. - If more scheduling is allowed: - Transfer packets from the low N/2 queue to the scheduled queue. - If more scheduling is allowed: - Call on_write callbacks for non-highest-priority streams, placing resulting packets directly onto the scheduled queue The number N is currently 20, but it could be varied based on resource usage. - If stream is created due to incoming headers, make headers readable from on_new. - Outgoing packets are no longer marked non-writeable to prevent placing more than one STREAM frame from the same stream into a single packet. This property is maintained via code flow and an explicit check. Packets for stream data are allocated using a special function. - STREAM frame elision is cheaper, as we only perform it if a reset stream has outgoing packets referencing it. - lsquic_packet_out_t is smaller, as stream_rec elements are now inside a union. |
||
---|---|---|
docs | ||
include | ||
src | ||
test | ||
CHANGELOG | ||
CMakeLists.txt | ||
Dockerfile | ||
dox.cfg | ||
EXAMPLES.txt | ||
LICENSE | ||
LICENSE.chrome | ||
README.md |
LiteSpeed QUIC (LSQUIC) Client Library README
Description
LiteSpeed QUIC (LSQUIC) Client Library is an open-source implementation of QUIC functionality for clients. It is released in the hope to speed the adoption of QUIC. Most of the code in this distribution is used in our own products: LiteSpeed Web Server and ADC. We think it is free of major problems. Nevertheless, do not hesitate to report bugs back to us. Even better, send us fixes and improvements!
Currently supported QUIC versions are Q035, Q037, Q038, Q039, and Q041. Support for newer versions will be added soon after they are released. The version(s) specified by IETF QUIC WG will be added once the IETF version of the protocol settles down a little.
Documentation
The documentation for this module is admittedly sparse. The API is
documented in include/lsquic.h. If you have doxygen, you can run
doxygen dox.cfg
or make docs
. The example program is
test/http_client.c: a bare-bones, but working, QUIC client. Have a look
in EXAMPLES.txt to see how it can be used.
Requirements
To build LSQUIC, you need CMake, zlib, and BoringSSL. The example program uses libevent to provide the event loop.
Building BoringSSL
BoringSSL is not packaged; you have to build it yourself. The process is
straightforward. You will need go
installed.
- Clone BoringSSL by issuing the following command:
git clone https://boringssl.googlesource.com/boringssl
cd boringssl
- Check out stable branch:
git checkout chromium-stable
- Compile the library
cmake . && make
If you want to turn on optimizations, do
cmake -DCMAKE_BUILD_TYPE=Release . && make
- Install the library
This is the manual step. You will need to copy library files manually.
LSQUIC client library needs two: ssl/libssl.a
and crypto/libcrypto.a
.
To install these in /usr/local/lib
, you should do the following:
BORINGSSL_SOURCE=$PWD
cd /usr/local/lib
sudo cp $BORINGSSL_SOURCE/ssl/libssl.a .
sudo cp $BORINGSSL_SOURCE/crypto/libcrypto.a .
If you do not want to install the library (or do not have root), you can do this instead:
BORINGSSL_SOURCE=$PWD
mkdir -p $HOME/tmp/boringssl-libs
cd $HOME/tmp/boringssl-libs
ln -s $BORINGSSL_SOURCE/ssl/libssl.a
ln -s $BORINGSSL_SOURCE/crypto/libcrypto.a
Building LSQUIC Client Library
LSQUIC's http_client
and the tests link BoringSSL libraries statically.
Following previous section, you can build LSQUIC as follows:
- Get the source code
git clone https://github.com/litespeedtech/lsquic-client.git
cd lsquic-client
- Compile the library
cmake -DBORINGSSL_INCLUDE=$BORINGSSL_SOURCE/include \
-DBORINGSSL_LIB=$HOME/tmp/boringssl-libs .
make
- Run tests
make test
Building with Docker
The library and http_client example can be built with Docker.
docker build -t lsquic-client .
Then you can use the http_client example from the command line.
docker run -it --rm lsquic-client http_client -H www.google.com -s 74.125.22.106:443 -p /
Platforms
The client library has been tested on the following platforms:
- Linux
- x86_64
- ARM (Raspberry Pi 3)
- FreeBSD
- i386
- MacOS
- x86_64
Have fun,
LiteSpeed QUIC Team.
Copyright (c) 2017 LiteSpeed Technologies Inc