The Zero-Syscall Network: WASM-to-WASM Tunneling für Nano-Services
The Zero-Syscall Network: WASM-to-WASM Tunneling für Nano-Services
Jede Inter-Service-Nachricht, die Ihre Anwendung heute sendet, nimmt einen Umweg durch den Kernel des Betriebssystems — ein Umweg, der in Mikrosekunden gemessen wird und bei großem Maßstab still und leise Ihr Latenzbudget auffrisst. Für die neue Generation von Nano-Services, die auf WebAssembly basieren, gibt es jetzt einen anderen Weg: den Kernel vollständig zu umgehen, über gemeinsam genutzten Speicher zu kommunizieren und mit Geschwindigkeiten zu arbeiten, die den traditionellen Netzwerk-Stack wie einen Postdienst aussehen lassen. Dieser Artikel erklärt, wie es funktioniert, wie die zugrunde liegende Technologie im Jahr 2026 aussieht und wo die ehrlichen Grenzen dieses Ansatzes derzeit liegen.
Die Kosten des traditionellen Netzwerk-Stacks
Wenn zwei Dienste auf demselben physischen Knoten über einen Loopback-Socket kommunizieren, bewegt sich die Daten nicht die kurze Strecke, die man sich vorstellen könnte. Stattdessen durchlaufen sie eine mehrstufige Reise durch den Kernel:
- Die sendende Anwendung serialisiert ihre Nutzlast — typischerweise in JSON, MessagePack oder Protocol Buffers — und schreibt sie in einen Puffer in ihrem eigenen Speicherraum.
- Die Laufzeit führt einen Systemaufruf (
sendmsgauf Linux) aus, was einen CPU-Kontextwechsel vom User-Space in den Kernel-Space auslöst. - Der Kernel reserviert Socket-Kernelpuffer (SKBs), schiebt das Paket durch den vollständigen TCP/IP-Stack, wendet Firewall- oder eBPF-Regeln an und routet es an die Loopback-Schnittstelle.
- Ein zweiter Kontextwechsel weckt den empfangenden Prozess.
- Die empfangende Anwendung kopiert die Daten aus dem Kernel-Space in ihren eigenen Speicher und deserialisiert.
+-----------------------------------------------------------------------+ | USER SPACE | | +------------------------+ +------------------------+ | | | Sending Application | | Receiving Application | | | +-----------+------------+ +-----------^------------+ | | | (Serialization) | (Deserialization) +--------------|----------------------------------------|---------------+ | v [Syscall: sendmsg] | [Syscall: recv] | +--------+--------+ +--------+--------+ | | | Context Switch | | Context Switch | | | +--------+--------+ +--------+--------+ | | | ^ | | v | | | +-----------+----------------------------------------+------------+ | | | Kernel Buffer (SKB) - TCP/IP Stack - Loopback / Network Card | | | +-----------------------------------------------------------------+ | | KERNEL SPACE | +-----------------------------------------------------------------------+
Für Mikroservices, die Datenbank-Round-Trips in Zehntel- oder Hundertstelsekunden messen, ist dieser Overhead vernachlässigbar. Für Nano-Services — eng gekoppelte, zweckorientierte Ausführungseinheiten, bei denen die Geschäftslogik selbst in Mikrosekunden abgeschlossen ist — kann der Overhead des Netzwerk-Stacks die Rechenzeit leicht übersteigen. Genau dieses Problem löst die Shared-Memory-Architektur von WebAssembly direkt.
Was WebAssembly tatsächlich bietet: Softwarebasierte Fehlerisolierung
Das architektonische Prinzip des Zero-Syscall-Netzwerks basiert auf einer Kern-Sicherheitsfunktion von WebAssembly namens Software-Based Fault Isolation (SFI). Ein WebAssembly-Binärprogramm läuft innerhalb einer streng sandboxed Laufzeit (Wasmtime, Wasmer oder WasmEdge). Die Laufzeit garantiert, dass ein kompiliertes Modul keinen Zugriff auf Speicher außerhalb seines explizit zugewiesenen linearen Speicherbereichs hat — und diese Grenze wird statisch während der Wasm-Kompilierung und Verifikation durchgesetzt.
Das bedeutet, die Laufzeit kann mehrere unterschiedliche Anwendungen innerhalb desselben OS-Prozessraums isolieren, ohne auf OS-Seiten-Tabellen oder Hardware-Ring-Grenzen zu setzen. Zwei Wasm-Komponenten, die im selben Prozess laufen, sind durch die Laufzeit voneinander isoliert, nicht durch den Kernel.
Die direkte Konsequenz: Wenn die Laufzeit einen bestimmten Speicherbereich zwischen zwei Wasm-Komponenten teilt, können diese direkt darin lesen und schreiben, ohne dass eine Komponente die private Speicherregion der anderen oder den Speicher des Host-Systems sehen kann. Dies ist die Grundlage des Zero-Syscall-Tunnels.
In einem direkten WASM-zu-WASM-Kommunikationspfad reserviert die Host-Laufzeit einen gemeinsamen Bereich des linearen Speichers und mappt ihn in beide Module. Wenn Komponente A Daten an Komponente B senden möchte, schreibt sie direkt in den gemeinsamen Ringpuffer. Komponente B liest daraus. Die Daten verlassen nie den User-Space, lösen keinen Kontextwechsel aus und durchlaufen keinen Kernel-Speicher-Kopie.
+-----------------------------------------------------------------------+
| EINZELNER USER-SPACE-PROZESS |
| |
| +---------------------+ +---------------------+ |
| | Wasm-Komponente A | | Wasm-Komponente B | |
| | (Lineares Memory) | | (Lineares Memory) | |
| +----------+----------+ +----------^----------+ |
| | | |
| | +-------------------------+ | |
| +-------| Gemeinsamer Ringpuffer |--------+ |
| [Direktes Schreiben] | (Gemeinsames lineares Memory) | [Direktes Lesen] |
| +-------------------------+ |
| |
| WebAssembly-Laufzeit (Wasmtime) |
+-----------------------------------------------------------------------+
| KERNEL SPACE |
| (VOLLSTÄNDIG UMGEHEN / UNBERÜHRT) |
+-----------------------------------------------------------------------+
Die Standards 2025–2026, die dies ermöglichten
Das Konzept der speicherabbildbasierten Interprozesskommunikation ist jahrzehntealt. Neu ist die Fähigkeit, dies sicher in polyglotten Softwareumgebungen umzusetzen, mit starken Isolationsgarantien, unter Verwendung eines standardisierten und portablen Binärformats. Drei Spezifikations-Meilensteine haben dies praktikabel gemacht.
WebAssembly 3.0 (September 2025)
WebAssembly 3.0 wurde am 17. September 2025 vom W3C finalisiert. Es ist ein bedeutendes Update — das größte seit dem ursprünglichen MVP — das mehrere Funktionen bündelt, die seit sechs bis acht Jahren in Entwicklung sind. Für den Zero-Syscall-Tunnel relevant sind insbesondere zwei Fähigkeiten:
Memory64 erweitert den Adressraum von Wasm-Anwendungen von den bisherigen 4 GB (durch 32-Bit-Adressierung) auf theoretisch 16 Exabytes, mit 64-Bit-Adressierung. Damit entfällt eine harte Obergrenze, die für speicherintensive Workloads zunehmend zum Problem wurde.
Multi-Memory erlaubt es einer einzelnen Wasm-Komponente, mehrere unabhängige Speicherblöcke gleichzeitig zu instanziieren und zu referenzieren. Früher hatte ein Modul nur einen linearen Speicher. Mit Multi-Memory kann eine Komponente ihren primären privaten Speicher beibehalten, während sie gleichzeitig einen sekundären, isolierten Speicher für den gemeinsamen Ringpuffer nutzt. Das ist genau der Mechanismus, der sicheres Tunneling ermöglicht: Der private Zustand der Komponente und der gemeinsame Kommunikationspuffer sind separate Speicherobjekte, die durch die Laufzeit mit eigenen Grenzen geschützt sind.
Stand Anfang 2026 unterstützen alle großen Browser WebAssembly 3.0-Features inklusive GC, Memory64, Exception Handling und SIMD. Standalone-Laufzeiten wie Wasmtime und Wasmer verfolgen die Spezifikation eng.
WASIp3 / WASI 0.3 — Native Asynchronität (RC, Ende 2025)
WASI 0.2, veröffentlicht im Januar 2024, führte das Component Model und WIT-Interface-Typen neben Netzwerkunterstützung ein — eine echte architektonische Verbesserung. WASI 0.3, allgemein als WASIp3 bezeichnet, geht den nächsten Schritt, indem es native asynchrone Primitive direkt in die ABI integriert.
Frühere WASI-Versionen handhabten asynchrones I/O durch synchrone Blockierungsaufrufe oder simulierte Poll-Schleifen. WASIp3 führt First-Class-future- und stream-Typen ein. Das bedeutet, dass eine Wasm-Komponente, die aus einem Netzwerk-gedachten Speicher-Tunnel liest, nicht-blockierende gleichzeitige Ereignisse über Komponenten-Grenzen hinweg handhaben kann, ohne auf sprachspezifische async-Laufzeiten angewiesen zu sein, die in OS-Kernel-Threads eingehängt werden.
Die erste Release-Kandidat-Unterstützung wurde im Fermyon Spin v3.5 im November 2025 implementiert. Wasmtime 37.0.0 lieferte experimentelle, optionale Unterstützung für WASIp3 mit nativen async-I/O-Features zur gleichen Zeit. Der API-Status ist noch im Release-Candidate-Stadium — API-Namen könnten sich vor der finalen Version noch ändern. WASI 1.0, das stabile, unternehmensgerechte Stabilitätsgarantien bieten soll, ist derzeit für Ende 2026 oder Anfang 2027 geplant.
Das WebAssembly Component Model und WIT
Das Component Model bietet einen standardisierten Rahmen für die Zusammenstellung unabhängiger Wasm-Module — möglicherweise geschrieben in Rust, Go, Python, C++, Kotlin oder jeder anderen Sprache mit Ziel WebAssembly — zu einer kohäsiven Anwendung. Kommunikationsschnittstellen zwischen Komponenten werden mit WebAssembly Interface Types (WIT) definiert, einer sprachunabhängigen Schnittstellensprache.
Anstatt eine Datenstruktur in JSON-Bytes zu serialisieren, definiert das Canonical ABI des Component Models genau, wie komplexe Typen über Komponenten-Grenzen hinweg durch “Lowering”- und “Lifting”-Operationen transformiert werden. Beim Übergang eines Records von einer Rust-Komponente zu einer Go-Komponente mappt die Laufzeit Felder direkt über gemeinsame Speicherzeiger, wodurch CPU-Zyklen für Textparsing und Objektinitialisierung eingespart werden.
Das Component Model befindet sich aktuell in den Phasen der W3C-Spezifikation und wird voraussichtlich parallel oder nach der Veröffentlichung von WASI 0.3 oder 1.0 weiterentwickelt.
Der Shared Ring Buffer: Wie der Tunnel tatsächlich funktioniert
Die Mechanik des Zero-Syscall-Tunnels basiert auf einer lock-freien kreisförmigen Warteschlange — einem Ringpuffer — der vollständig durch atomare Speicheroperationen implementiert ist. Keine Kernel-Mutexes. Keine Kontextwechsel.
Initialisierung
Die Host-Laufzeit reserviert einen Speicherblock für den Datentransfer. Über das Ressourcenfähigkeitssystem des Component Models injiziert sie dieses Speichersegment als gemeinsamen Handle in beide Wasm-Instanzen (Producer und Consumer). Jede Komponente erhält Zugriff auf den gemeinsamen Bereich durch ihren zweiten, unabhängigen Speicher (aktiviert durch WebAssembly 3.0 Multi-Memory), während ihr primärer Speicher vollständig privat bleibt.
Schreiben von Daten (Producer)
Wenn die Producer-Komponente eine Nachricht senden muss, prüft sie, ob der Ringpuffer nicht voll ist, indem sie den write_index mit dem read_index vergleicht. Dann schreibt sie die Nutzlast direkt in den richtigen Speicherplatz mit atomaren CPU-Anweisungen (i32.atomic.rmw.add in WebAssembly-Threading-Primitiven) und erhöht den write_index atomar.
Lesen von Daten (Consumer)
Der Consumer überwacht den write_index. Wenn dieser den read_index überholt, verarbeitet er die rohen Bytes direkt aus dem Speicherplatz — kein Kopieren notwendig — und erhöht den read_index.
Gemeinsames linearer Speicherbereich
+---------------------------------------------------------+
| Slot 0 | Slot 1 | Slot 2 | Slot 3 | Slot 4 | ... |Slot N|
+---------------------------------------------------------+
^ ^
| |
[Read Index] [Write Index]
(Verarbeitender Consumer) (Anwender, der Daten anhängt)
Vermeidung von Busy-Waiting
Um zu verhindern, dass der Consumer CPU-Zyklen in einer unendlichen Polling-Schleife verbrennt, wenn der Kanal idle ist, nutzt das Nano-Network die nativen Aussetzungsmöglichkeiten von WebAssembly: memory.atomic.wait32 und memory.atomic.notify.
Wenn der Ringpuffer leer ist, wird der Thread des Consumers vom Runtime in einen Ruhezustand versetzt. Wenn der Producer ein neues Paket schreibt, feuert er memory.atomic.notify. Das Runtime weckt den Consumer sofort. Dieser gesamte Handshake findet innerhalb der Runtime-Umgebung statt, ohne ein OS-Thread-Signal zu senden oder einen Linux-Kernel-Kontextwechsel auszulösen.
Ein praktischer Code-Blueprint
Das Schnittstellen-Contract (tunnel.wit)
package local:networking;
interface tunnel-types {
record packet {
stream-id: u32,
timestamp: u64,
payload: list<u8>,
}
}
world nano-network-bridge {
use tunnel-types.{packet};
/// Exportiert eine Methode, um externe Komponenten Daten in den Speicher-Tunnel zu schicken
export transmit-packet: func(data: packet) - result; // Ergebnis: string, string
/// Importiert einen asynchronen Stream-Handler für eingehende Edge-Pakete
import receive-stream: func() - list<packet>;
}
Das Rust-Component (main.rs)
// Generiere die nativen Bindings aus unserer WIT-Weltbeschreibung
wit_bindgen::generate!({ world: "nano-network-bridge" });
use exports::local::networking::tunnel_types::Packet;
struct TelemetryProcessor;
impl Guest for TelemetryProcessor {
fn transmit_packet(data: Packet) - Result<String, String> {
if data.payload.is_empty() {
return Err("Leere Nutzlast abgelehnt".to_string());
}
let stream_id = data.stream_id;
let byte_len = data.payload.len();
// Zero-Copy-Schreiben in den sekundären gemeinsamen Speicherblock (Multi-Memory)
// gemountet an einem separaten linearen Speicherindex durch die Host-Laufzeit.
// Im Produktivbetrieb wird dieser Zeiger durch einen Capability-Handle aufgelöst,
// der beim Instanziieren injiziert wird — kein hartkodierter Address.
unsafe {
let buffer_ptr = 0x4000_0000 as *mut u8;
std::ptr::copy_nonoverlapping(data.payload.as_ptr(), buffer_ptr, byte_len);
}
Ok(format!(
"Weitergeleitet {} Bytes via Memory-Tunnel ID: {}",
byte_len, stream_id
))
}
}
export!(TelemetryProcessor);
Sicherheit: Capability-basierte Isolation
Eine berechtigte Sorge bei direkter Speicherabbildung zwischen Anwendungen ist die Sicherheit. Wenn Komponenten in gemeinsam genutzten Speicher schreiben können, was verhindert Buffer Overflows oder unbefugte Lesezugriffe?
Das Sicherheitsmodell basiert auf WASI’s Capability-based Architecture. WebAssembly-Komponenten haben standardmäßig keine Rechte. Sie können kein Dateisystem öffnen, keine Netzwerkendpunkte öffnen oder irgendeinen Systemspeicher einsehen, es sei denn, der Host-Laufzeit gewährt explizit eine Capability beim Instanziieren.
Für den speziellen Shared-Tunnel gelten die folgenden drei Eigenschaften:
Strikte räumliche Grenzen. Das gemeinsame Speichersegment ist in eine unveränderbare Capability-Grenze eingebunden. Wenn eine Komponente versucht, auch nur ein Byte außerhalb des vorgesehenen Ringpuffers zu lesen oder zu schreiben, löst die Laufzeit sofort eine irreversible Ausführungsfalle aus und beendet die betreffende Komponente.
Granulare Zugriffskontrollen. WIT-Deklarationen erlauben es, Schnittstellen als read-only oder write-only zu typisieren. Ein telemetry-sammelnder Nano-Service kann eine Memory-Tunnel-Capability erhalten, die Schreiboperationen strukturell verbietet, und so die Datenintegrität auf der virtuellen Hardware-Ebene durchsetzen, anstatt im Anwendungscode.
Kein Pointer-Leakage. WebAssembly nutzt einen isolierten linearen Speicherindex anstelle roher Host-Pointer. Eine kompromittierte Komponente kann den Speicherraum anderer Komponenten oder des Host-OS nicht rückentwickeln oder abbilden.
Performance: Was die Zahlen tatsächlich zeigen
Der Geschwindigkeitsvorteil der Zero-Syscall-Kommunikation zwischen Komponenten ist real und messbar. Mehrere unabhängige Datenpunkte belegen die Größenordnung der Verbesserung in verschiedenen Dimensionen:
| Performance-Metrik | Traditioneller Container-Tunnel | WASM-zu-WASM Memory-Tunnel | Verbesserung |
|---|---|---|---|
| Latenz innerhalb des Knotens | ~2.500 Nanosekunden (Loopback-Socket) | 12–15 Nanosekunden | ~160x |
| Cold-Start-Overhead | 100 ms – 1,2 Sekunden (Docker) | < 0,5 ms (native Wasm-Laufzeit) | > 1.000x |
| Speicherverbrauch | 150MB – 400MB pro Instanz | 2MB – 5MB pro Instanz | ~75x |
| Syscalls pro Nachricht | 4 – 6 Syscalls | 0 Syscalls | Totale Eliminierung |
Hinweis zu Cold Starts: Die Sub-Millisekunden-Zahl gilt speziell für native Wasm-Laufzeiten wie Wasmtime und Spin. Auf der SUSECON 2025 demonstrierte Fermyon Cold-Starts unter 0,5 ms für Wasm-Funktionen auf Kubernetes im Vergleich zu Hunderten Millisekunden bei AWS Lambda. Das Ausführen von Wasm innerhalb von Docker-Containern fügt jedoch 65–325 ms Overhead hinzu — man erhält also nicht beide Vorteile gleichzeitig. Der Geschwindigkeitsvorteil erfordert native Runtime-Deployment.
Reale Adoption im Jahr 2026
Edge-Plattformen, die auf WebAssembly basieren, bewältigen ernsthaften Produktionsverkehr. Fermyon’s Edge-Netzwerk, 2025 von Akamai übernommen und jetzt Teil des CNCF Sandbox, verarbeitet etwa 75 Millionen Anfragen pro Sekunde. Fastly Compute@Edge hat mehr als 10.000 aktive Nutzer. Cloudflare Workers, gebaut auf einer V8-Isolat-Architektur, die eng mit Wasm-Sandboxing verwandt ist, operiert von Hunderten von Point of Presence weltweit.
American Express hat eine interne FaaS-Plattform auf wasmCloud aufgebaut, die das Shared-Memory-Komponentenmuster in der Praxis demonstriert. In Finanzdaten-Pipelines ermöglicht die Co-Lokation eines ingress-Wasm-Komponenten und eines Verarbeitungs-Wasm-Komponenten auf demselben Edge-Host — verbunden durch einen Ringpuffer — die Einhaltung von Latenzbudgets unterhalb von Millisekunden, ohne dass eine Komponente das Host-Netzwerk-Stack berührt.
Daten vom Chrome Platform Status zeigen, dass WebAssembly im Jahr 2026 etwa 5,5 % der Chrome-Seitenladevorgänge ausmacht, gegenüber 4,5 % im Vorjahr. Figma, Adobe Photoshop im Web, AutoCAD Web und Google Meet’s Videoverarbeitung laufen alle auf Wasm.
Die aufkommende eBPF-Frontier
Der nächste architektonische Schritt nach dem WASM-to-WASM-Tunneling ist eine Pipeline, die am physischen Netzwerkschnittstellen-Card beginnt. Die Proxy-Wasm-Spezifikation erlaubt bereits, Wasm-Filter in Envoy und ähnlichen Proxies laufen zu lassen. Das aufkommende Muster kombiniert dies mit eBPF-Paketverarbeitung — die Pakete am NIC-Ebene abfängt und direkt in einen Speicherbereich kopiert, den eine Wasm-Komponente liest, wodurch eine Zero-Syscall-Pipeline vom physischen NIC bis zur Sandbox-Logik entsteht. Kein Kernel-TCP/IP-Stack. Keine Socket-Puffer. Keine Kontextwechsel im Datenpfad.
Ehrliche Grenzen und ungelöste Fragen
Die oben beschriebenen Muster werden an realer, produktiver Software entwickelt — Wasmtime, Spin, WasmEdge — aber einige der mächtigsten Primitive befinden sich noch im Stabilisierungsprozess. Es ist wichtig, die aktuellen Lücken genau zu kennen.
WASIp3 Async ist noch im Release-Candidate-Status. Die nativen future- und stream-Typen, die eine saubere, nicht-pollende asynchrone Kommunikation zwischen Komponenten ermöglichen, könnten sich vor der finalen Version noch ändern. Für den produktiven Einsatz sollten Teams die LTS-Releases von Wasmtime verfolgen.
Threading ist auf Serverseite noch unvollständig. Die Unterstützung für Threads außerhalb des Browsers ist ungeklärt. Das Shared-Memory-Thread-Modell erfordert Sicherheitsgarantien, an denen die Systems-Community noch arbeitet. Es gibt kein konkretes Veröffentlichungsdatum Mitte 2026. Das schließt ganze Kategorien paralleler Rechen-Workloads vorerst aus.
WASI 1.0 ist noch nicht verfügbar. Die vollständige Spezifikationsstabilität, die Unternehmen für den produktiven Einsatz benötigen, ist für Ende 2026 oder Anfang 2027 geplant. Die WASI 0.x-Reihe hat API-Namen zwischen Versionen gewechselt, Teams, die auf Preview 1 setzen, mussten für Preview 2 erheblich aktualisieren. Das ist eine berechtigte Sorge bei der Evaluierung des Stacks.
Observability-Tools erfordern bewusste Anstrengung. Da keine Netzwerkpakete auf der Leitung sind und keine Syscalls in Kernel-Logs erscheinen, liefern herkömmliche Tools — tcpdump, wireshark, strace — keine brauchbaren Ergebnisse. Wasm-Workloads unter WASIp3-Hosts geben nicht immer Gast-Spans aus. Instrumentierung ist möglich, erfordert aber expliziten Aufwand, der bei containerbasierten Workloads eher automatisch erfolgt.
WAN-Verbindungen sind noch durch Physik begrenzt. Das Nano-Network eliminiert lokale Verarbeitungs-Overhead und Kernel-Engpässe, aber die Überbrückung über weite Entfernungen erfordert robuste Transportprotokolle. Die praktische Architektur ist hybrid: Zero-Copy-Memory-Ringpuffer innerhalb von Clustern und lokalen Knoten, mit QUIC-basierten Tunneln für WAN-Transport.
Was man anstreben sollte
Sobald WASIp3 stabil ist und Threading unterstützt wird, wird die Kombination aus nativen asynchronen Streams für nicht-blockierende Inter-Component-Kommunikation, Shared-Memory-Ringpuffern für Zero-Copy-Datenübertragung, WIT-Interface-Definitionen für sprachunabhängige Verträge und SFI-Isolation für Sicherheit ohne Kernel-Overhead es ermöglichen, co-lokalisierte Wasm-Nano-Services zu einer echten Alternative für latenzkritische Workloads zu machen. Heute sind die Muster umsetzbar und nachweislich schnell. Die stabile Grundlage für eine produktive Plattform liegt etwa zwölf bis achtzehn Monate in der Zukunft.
Die Zukunft des Edge ist nicht nur serverlos. Für eine wachsende Anzahl von Anwendungsfällen wird sie socketless.
Quellen und weiterführende Literatur
- WebAssembly 3.0 Spezifikation — webassembly.org (17. September 2025)
- Bytecode Alliance Component Model Dokumentation — component-model.bytecodealliance.org
- WASI Roadmap — wasi.dev
- Wasmtime Dokumentation und Release Notes — docs.wasmtime.dev
- Fermyon Spin v3.5 Release Notes (WASIp3 RC, November 2025)
- “WebAssembly in 2026: Three Years of Almost Ready” — Java Code Geeks (April 2026)
- “The State of WebAssembly 2025 and 2026” — Uno Platform Blog (Januar 2026)
- “State of WebAssembly 2026” — devnewsletter.com (Februar 2026)
- Fermyon SUSECON 2025 Cold-Start-Benchmark (sub-0.5ms vs Lambda)
- “The Zero-Syscall Network” — InstaTunnel / Medium (April 2026)
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.