feat(vanilla-io_uring): add json-tls (epoll+kTLS TLS listener on :8081)#955
Open
enghitalo wants to merge 1 commit into
Open
feat(vanilla-io_uring): add json-tls (epoll+kTLS TLS listener on :8081)#955enghitalo wants to merge 1 commit into
enghitalo wants to merge 1 commit into
Conversation
The lib's io_uring backend has no TLS, so json-tls is served on a second
server bound to :8081 using the lib's epoll backend — the same TLS 1.3 +
kTLS path that vanilla-epoll uses (after the Mbed TLS handshake the kernel
does record AES-128-GCM via TLS_TX/TLS_RX where the `tls` module is present;
clean userspace fallback otherwise). The io_uring server keeps serving the
non-TLS profiles on :8080. Same dual-server pattern as vanilla-epoll.
main.v
- Stateless request_handler on the :8081 epoll server that serves ONLY /json
(404 elsewhere — minimal TLS surface), reusing the existing allocation-free
write_json_response (read-only: dataset + prefixes). It captures `sh` and
never touches the DB/caches, so it runs safely alongside the io_uring
workers. TLS_PORT (default 8081) for local runs; spawned before the blocking
io_uring server.run().
- load_tls_config: reads /certs/server.{crt,key} (TLS_CERT/TLS_KEY overridable),
fails loud if the cert is present but the key isn't, self-signs when no cert
is mounted.
Dockerfile
- Bump the vanilla lib pin to main @b189036 (includes kTLS, enghitalo/vanilla#79).
- Build Mbed TLS 4.1.0 from source with MBEDTLS_THREADING_C/PTHREAD (the TLS
workers share Mbed TLS's global PSA key store), compile with -d vanilla_tls,
carry the shared libs at runtime + ldconfig, EXPOSE 8081.
meta.json: add "json-tls".
Validated locally (no `tls` module here → userspace fallback): both servers
coexist (io_uring :8080 + epoll-TLS :8081), the 3 json-tls validate pairs pass
(schema + total==price*quantity*m), ALPN http/1.1, cipher pinned to
AES-128-GCM. On the bench host kTLS engages (same code that took vanilla-epoll
json-tls to 1.50M).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
|
/benchmark -f vanilla-io_uring |
Contributor
|
👋 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds the json-tls profile to
vanilla-io_uring. The lib's io_uring backend has no TLS, so the json-tls listener runs on a second server bound to :8081 using the lib's epoll backend — the same TLS 1.3 + kTLS path that landed forvanilla-epoll(PR #952). The io_uring server keeps serving the non-TLS profiles on :8080. Same dual-server pattern.After the Mbed TLS handshake the kernel does record AES-128-GCM via
TLS_TX/TLS_RXwhere thetlsmodule is present (clean userspace fallback otherwise), so the steady-state read/write are plainrecv/sendwith no per-record userspace crypto.Why this shape
The io_uring backend would need a TLS handshake driven by io_uring completions — a sizable lib project. json-tls is a separate port (8081), so the pragmatic, low-risk move is to reuse the proven epoll+kTLS listener there and keep io_uring for the hot non-TLS paths. (Pure io_uring TLS is a possible future follow-up.)
How
main.vrequest_handleron the :8081 epoll server serving only/json(404 elsewhere), reusing the existing allocation-freewrite_json_response(read-only: dataset + prefixes). It capturesshand never touches the DB/caches, so it runs safely alongside the io_uring workers.TLS_PORT(default 8081) for local runs; spawned before the blocking io_uringserver.run().load_tls_config: reads/certs/server.{crt,key}(TLS_CERT/TLS_KEYoverridable); fails loud if the cert is present but the key isn't; self-signs when no cert is mounted.Dockerfile@b189036(includes kTLS, perf(tls): kTLS record offload (TX+RX) after the Mbed TLS handshake enghitalo/vanilla#79).MBEDTLS_THREADING_C/PTHREAD(the TLS workers share Mbed TLS's global PSA key store), compile with-d vanilla_tls, carry the shared libs at runtime +ldconfig,EXPOSE 8081.meta.json: add"json-tls".Validation (local; this box has no
tlskernel module → userspace fallback):8080+ epoll-TLS:8081. Plaintext/jsonon 8080 → 200.total == price*quantity*m.http/1.1, cipher pinned toTLS_AES_128_GCM_SHA256, one-time[ktls] fallbacklog fires (no module here).On the bench host kTLS engages — the same epoll+kTLS code that took
vanilla-epolljson-tls to 1.50M rps. Expect a similar number here (the TLS listener is byte-identical; the difference vs vanilla-epoll is only the :8080 backend).🤖 Generated with Claude Code