libwebsockets features * Provides server and client APIs for RFC6455 v13 ws:// and wss:// websocket protocol, along with http:// and https:// * Can be configured to use OpenSSL, CyaSSL, or WolfSSL to provide fully encrypted client and server links - including client certificate support * Lightweight and fast even at 250K connections per thread and beyond - performance per byte and performance per MIPS many times better than traditional solutions * CMake based project that has been used in a variety of OS contexts including Linux (uclibc and glibc), ARM-based embedded boards, MBED3, MIPS / OpenWRT, Windows, Android, Apple iOS and even Tivo. It's used all over the place including The New York Times customer-facing servers and BMW. * It includes a stub webserver that is enough to deliver your scripts to the browser that open websocket connections back to the same server, so it can solve the entire server side, ws://, wss://, http://, and https:// in one step. Apache, Java or any other server-side support is not needed. * Compliant browsers from the last few years are supported on any platform. * Full-strength SSL suport: A+ on SSLLABS test (this server is powered by lwsws) * Architectural features like nonblockinng event loop, zero-copy for payload data and FSM-based protocol parsers make it ideal for realtime operation on resource-constrained devices * Simple, pure C: user code creates a libwebsockets context with options and a callback, library calls the callback when events occur on the connection - no activity on connections == 0% CPU * Posix poll(), libev (ie, epoll) and libuv event loops supported * Proxy support, including Basic Auth
libwebsockets alternatives and similar libraries
Based on the "Networking" category
5.9 0.0 L4 libwebsockets VS Simple-WebSocket-ServerA very simple, fast, multithreaded, platform independent WebSocket (WS) and WebSocket Secure (WSS) server and client library implemented using C++11, Boost.Asio and OpenSSL. Created to be an easy way to make WebSocket endpoints in C++.
C++ library for creating an embedded Rest HTTP server (and more)
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest. Visit our partner's website for more details.
Do you think we are missing an alternative of libwebsockets or a related project?
Libwebsockets is a simple-to-use, pure C library providing client and server for http/1, http/2, websockets and other protocols in a security-minded, lightweight, configurable, scalable and flexible way. It's easy to build and cross-build via cmake and is suitable for tasks from embedded RTOS through mass cloud serving.
70 independent minimal examples for various scenarios, CC0-licensed (public domain) for cut-and-paste, allow you to get started quickly.
libglib native event loop support
glib's event loop joins libuv, libevent and libev support in lws for both the
lws_context creating and owning the loop object for its lifetime, and for
an already-existing "foreign loop" where the
lws_context is created, attaches,
detaches, and is destroyed without affecting the loop.
This allows direct, lock-free integration of lws functionality with, eg, a GTK app's
GMainLoop / glib
g_main_loop. Just select
-DLWS_WITH_GLIB=1 at cmake
time to enable. The -eventlib minimal examples also support --glib option to
select using the glib loop at runtime.
There's also a gtk example that is built if lws cmake has
lws_system helper for attaching code to a single event loop from another thread
lws_system ops struct now has a member that enables other threads (in the
same process) to request a callback they define from the lws event loop thread
context as soon as possible. From here, in the event loop thread context,
they can set up their lws functionality before returning and letting it
operate wholly from the lws event loop. The original thread calling the
api to request the callback returns immediately.
Improvements on tx credit
H2 clients and servers can now modulate RX flow control on streams precisely, ie, define the size of the first incoming data and hand out more tx credit at timing of its choosing to throttle or completely quench the remote server sending as it likes.
The only RFC-compatible way to acheive this is set the initial tx credit to 0 and set it explicitly when sending the headers... client code can elect to do this rather than automatically manage the credit by setting a new flag LCCSCF_H2_MANUAL_RXFLOW and indicating the initial tx credit for that stream in client connection info member manual_initial_tx_credit. A new public api lws_wsi_tx_credit() allows dynamic get and add to local and estimated remote peer credit for a connection. This api can be used without knowing if the underlying connection is h2 or not.
lws_system: DHCP client
DHCP client is now another network service that can be integrated into lws, with
LWS_WITH_SYS_DHCP_CLIENT at CMake. When enabled, the
is held at
DHCP until at least one registered network interface acquires a
usable set of DHCP information including ip, subnet mask, router / gateway
address and at least one DNS server.
See the api-test-dhcp Minimal Example for how to use.
UDP integration with
UDP support in lws has new helper that allow
lws_retry to be applied for retry,
and the ability to synthesize rx and tx udp packetloss systemwide to confirm
retry strategies. Since multiple transactions may be in flight on one UDP
socket, the support relies on an
lws_sul in the transaction object to manage
the transaction retries individually.
READMEs/README.udp.md for details.
lws_system: system state and notification handlers
Lws now has the concept of systemwide state held in the context... this is to manage that there may be multiple steps that need the network before it's possible for the user code to operate normally. The steps defined are
POLICY_INVALID. OPERATIONAL is the
state where user code can run normally.
User and other parts of lws can hook notifier callbacks to receive and be able to veto system state changes, either definitively or because they have been triggered to perform a step asynchronously and will move the state on themselves when it completes.
By default just after context creation, lws attempts to move straight to OPERATIONAL.
If no notifier interecepts it, it will succeed to do that and operate in a
backwards-compatible way. Enabling various features like lws ntpclient also enable
notifiers that hold progress at the related state until their operation completes
successfully, eg, not able to enter
TIME_VALID until ntpclient has the time.
READMEs/README.lws_system.md for details.
lws_system: HAL ops struct
Lws allows you to define a standardized ops struct at context creation time so your user code can get various information like device serial number without embedding system-specific code throughout the user code. It can also perform some generic functions like requesting a device reboot.
READMEs/README.lws_system.md for details.
Optional lws system service enabled by cmake
TIME_VALID state and performs ntpclient to get the date and time
TIME_VALID. This allows user code to validate tls certificates
correctly knowing the current date and time by the time it reached OPERATIONAL.
Connection Validity tracking
Lws now allows you to apply a policy for how long a network connection may go without seeing something on it that confirms it's still valid in the sense of passing traffic cohernetly both ways. There's a global policy in the context which defaults to 5m before it produces a PING if possible, and 5m10 before the connection will be hung up, user code can override this in the context, vhost (for server) and client connection info (for client).
lws_validity_confirmed(wsi) is provided so user code can indicate
that it observed traffic that must mean the connection is passing traffic in
both directions to and from the peer. In the absence of these confirmations
lws will generate PINGs and take PONGs as the indication of validity.
lws_system: Async DNS support
Master now provides optional Asynchronous (ie, nonblocking) recursive DNS resolving.
-DLWS_WITH_SYS_ASYNC_DNS=1 at cmake. This provides a quite
sophisticated ipv4 + ipv6 capable resolver that autodetects the dns server on
several platforms and operates a UDP socket to its port 53 to produce and parse DNS
packets from the event loop. And of course, it's extremely compact.
It broadly follows the getaddrinfo style api, but instead of creating the results on the heap for each caller, it caches a single result according to the TTL and then provides refcounted const pointers to the cached result to callers. While there are references on the cached result it can't be reaped.
READMEs/README.async-dns.md for detailed information on how it works, along
api-tests/api-test-async-dns minimal example.
You can now opt to measure and store us-resolution statistics on effective
latencies for client operations, and easily spool them to a file in a
format suitable for gnuplot, or handle in your own callback. Enable
-DLWS_WITH_DETAILED_LATENCY=1 in cmake to build it into lws.
If you are concerned about operation latency or potential blocking from user code, or behaviour under load, or latency variability on specific platforms, you can get real numbers on your platform using this.
Timings for all aspects of events on connections are recorded, including the time needed for name resolution, setting up the connection, tls negotiation on both client and server sides, and each read and write.
READMEs/README.detailed-latency.md for how to use it.
Client connection logic rewrite
Lws master now makes much better use of the DNS results for ipv4 and ipv6... it will iterate through them automatically making the best use it can of what's provided and attempting new connections for each potentially usable one in turn before giving up on the whole client connection attempt.
If ipv6 is disabled at cmake it can only use A / ipv4 records, but if ipv6 is enabled, it tries both; if only ipv6 is enabled it promotes ipv4 to ::ffff:126.96.36.199 IPv4-in-IPv6 addresses.
New network helpers for ipv4 and ipv6
An internal union
lws_sockaddr46 that combines
struct sockaddr_in and
struct sockaddr_in6 is now public, and there are helpers that can parse (using
lws_tokenize) any valid numeric representation for ipv4 and ipv6 either
into byte arrays and lengths, or directly to and from
h2 long poll support
Lws now supports the convention that half-closing an h2 http stream may make the stream 'immortal', in terms of not being bound by normal timeouts. For the client side, there's an api that can be applied to the client stream to make it transition to this "read-only" long poll mode.
READMEs/README.h2-long-poll.md for full details, including how to test
it with the minimal examples.
h1 client parser improvements
H1 is not so simple to parse because the header length is not known until it has been fully parsed. The next header, or http body may be directly coalesced with the header as well. Lws has supported bulk h1 parsing from a buffer for a long time, but on clientside due to interactions with http proxying it had been stuck parsing the header bytewise out of the tls buffer. In master, everything now bulk parses from a buffer and uses a buflist to pass leftovers through the event loop cleanly.
lws_sul time refactor
Just before v3.2 there was a big refactor about how lws handles time. It now explicitly schedules anything that may happen in the future on a single, sorted linked-list, at us resolution. When entering a poll wait (or returning to an event lib loop) it checks the interval between now and the earliest event on the list to figure out how long to wait if there are no network events. For the event loop case, it sets a native event lib timer to enforce it.
READMEs/README.lws_sul.md for more details and a handy api where you can
schedule your own arbitrary callbacks using this system.
Master is now MIT-licensed
Libwebsockets master is now under the MIT license. See ./LICENSE.
This is the libwebsockets C library for lightweight websocket clients and servers. For support, visit
and consider joining the project mailing list at
You can get the latest version of the library from git:
Doxygen API docs for master: https://libwebsockets.org/lws-api-doc-master/html/index.html
*Note that all licence references and agreements mentioned in the libwebsockets README section above are relevant to that project's source code only.