跳到正文
研踪PaperTrail
← 研踪 PaperTrail

arXiv:2611.01989 · v1

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

首次提交 2026-11-01 23:25
版本更新 2026-11-01 23:25
雷达观测 2026-11-04 23:43
arXiv ↗PDF ↗

摘要

WebAssembly (Wasm) runs untrusted code in a portable, lightweight sandbox and is increasingly used to host services on shared servers and edge platforms. Running the QUIC transport protocol inside Wasm would let each application choose and update its own transport without changing the host. QUIC, however, encrypts every packet, and Wasm offers neither dedicated AES instructions nor carry-less multiplication; a Wasm QUIC stack has been reported to reach only 17.6% of native goodput, with cryptography as its largest cost. Whether the 128-bit SIMD extension of Wasm (WASM-SIMD) can recover this cost, and what limits a pure-Wasm stack once it does, has remained unclear. Here we show that explicit WASM-SIMD kernels recover much of the cryptographic cost, after which non-cryptographic costs become the limit. On two hosts connected by 10-Gigabit Ethernet, kernels that process eight AES blocks or four ChaCha20 blocks per pass raise receiver goodput over a non-SIMD baseline by 61.34% for AES-128-GCM and 31.55% for ChaCha20-Poly1305, whereas compiler auto-vectorization gains only 1.28% for AES-128-GCM. ChaCha20-Poly1305 still delivers 1.99 times the goodput of AES-128-GCM, confirming end to end the preference that stand-alone cipher benchmarks suggest. Receiver-side profiling combined with Amdahl's law predicts that even native-speed cryptography would leave Wasm at roughly one third of the goodput of the fastest native stack. Cryptographic acceleration is therefore necessary but not sufficient: memory allocation, runtime overhead and per-datagram UDP I/O now bound pure-Wasm transports. We anticipate that this per-category cost breakdown will guide further optimization of Wasm network stacks and the design of system interfaces for batched I/O.

作者备注:A Japanese version of this work has been submitted as a manuscript for presentation at the IEICE Technical Committee on Internet Architecture (IA). The abstract is available at https://ken.ieice.org/ken/paper/202611028cZo/eng/

AI 论文解读

基于摘要 · 非全文审阅

此版本尚未生成 AI 解读。解读由后台任务生成并按论文版本保存,登录后共享已有结果。

版本差异

目前只观测到一个版本,无法比较变化。之后收录新版本时,会在这里对照标题、作者、分类和摘要。

观测到的版本

相邻记录可能跳过中间版本;首次发现 v2 及以上也会标为版本更新。

v1 · 2026-11-01 23:25 · 最新观测版本

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

WebAssembly (Wasm) runs untrusted code in a portable, lightweight sandbox and is increasingly used to host services on shared servers and edge platforms. Running the QUIC transport protocol inside Wasm would let each application choose and update its own transport without changing the host. QUIC, however, encrypts every packet, and Wasm offers neither dedicated AES instructions nor carry-less multiplication; a Wasm QUIC stack has been reported to reach only 17.6% of native goodput, with cryptography as its largest cost. Whether the 128-bit SIMD extension of Wasm (WASM-SIMD) can recover this cost, and what limits a pure-Wasm stack once it does, has remained unclear. Here we show that explicit WASM-SIMD kernels recover much of the cryptographic cost, after which non-cryptographic costs become the limit. On two hosts connected by 10-Gigabit Ethernet, kernels that process eight AES blocks or four ChaCha20 blocks per pass raise receiver goodput over a non-SIMD baseline by 61.34% for AES-128-GCM and 31.55% for ChaCha20-Poly1305, whereas compiler auto-vectorization gains only 1.28% for AES-128-GCM. ChaCha20-Poly1305 still delivers 1.99 times the goodput of AES-128-GCM, confirming end to end the preference that stand-alone cipher benchmarks suggest. Receiver-side profiling combined with Amdahl's law predicts that even native-speed cryptography would leave Wasm at roughly one third of the goodput of the fastest native stack. Cryptographic acceleration is therefore necessary but not sufficient: memory allocation, runtime overhead and per-datagram UDP I/O now bound pure-Wasm transports. We anticipate that this per-category cost breakdown will guide further optimization of Wasm network stacks and the design of system interfaces for batched I/O.

查看此版本解读 →查看此版本原文 ↗