I/O UDP Berkecepatan Tinggi Berbasis Rust di Firefox

 (max-inden.de)
1 poin oleh GN⁺ 2025-09-28 | 1 komentar | Bagikan ke WhatsApp
  • Sekitar 20% trafik HTTP di Firefox menggunakan HTTP/3, yang berjalan di atas QUIC dan UDP
  • Dengan mengganti lapisan I/O jaringan lama NSPR ke quinn-udp berbasis Rust, kinerja dan keamanan memori ditingkatkan
  • System call modern untuk tiap sistem operasi (multi-message, segmentation offloading, dll.) dimanfaatkan secara aktif untuk mengoptimalkan performa
  • Di Windows dan MacOS, beberapa fitur dibatasi oleh kompatibilitas dan masalah driver, tetapi di Linux performa optimal berhasil dicapai
  • Berbagai pengalaman trial-and-error dan perbaikan bug terkait dukungan QUIC ECN dan UDP I/O di banyak platform diperkirakan akan membantu proyek-proyek berikutnya serta ekosistem open source

Motivasi

  • Sekitar 20% trafik HTTP Firefox menggunakan HTTP/3, yang bekerja melalui QUIC, dan pada akhirnya diimplementasikan di atas UDP
  • Secara historis Firefox menggunakan pustaka NSPR untuk I/O jaringan, tetapi fitur terkait UDP I/O sudah tua dan terbatas (fungsi utamanya adalah PR_SendTo, PR_RecvFrom)
  • Sistem operasi belakangan ini menyediakan system call multi-message (mis. sendmmsg, recvmmsg) dan segmentation offload (GSO, GRO) sebagai optimasi jaringan
  • Teknik-teknik ini dapat secara signifikan meningkatkan performa UDP I/O
  • Firefox meneliti apakah bisa memperoleh manfaat tersebut dengan mengganti stack UDP I/O lama dengan system call modern

Gambaran umum

  • Proyek ini dimulai pada pertengahan 2024, dengan tujuan membangun ulang stack QUIC UDP I/O Firefox di semua OS yang didukung menggunakan system call modern
  • Selain peningkatan performa, proyek ini juga menargetkan peningkatan keamanan dengan memanfaatkan Rust yang menjamin keamanan memori untuk UDP I/O
  • QUIC sendiri sudah diimplementasikan dalam Rust, sehingga pengembangan dilakukan di atas pustaka quinn-udp berbasis Rust
  • Perbedaan system call antar-OS meningkatkan tingkat kesulitan pengembangan, tetapi quinn-udp sangat membantu mempercepatnya
  • Hingga pertengahan 2025, penerapan sudah berlangsung untuk sebagian besar pengguna Firefox, dan benchmark performa menunjukkan peningkatan besar hingga 4Gbit/s

Struktur UDP I/O dan pendekatan optimasi modern

Pengiriman datagram tunggal

  • Pendekatan lama menggunakan sendto dan recvfrom, sehingga hanya bisa mengirim dan menerima satu datagram UDP per panggilan
  • Biaya perpindahan antara user space dan kernel space dibayar per datagram, sehingga tidak efisien dalam lingkungan trafik besar
  • Contoh: mengirim paket di bawah 1500 byte pada laju ratusan Mbit per detik menimbulkan overhead yang besar

Pengiriman batch multi-datagram

  • Beberapa OS seperti Linux mendukung system call multi-message seperti sendmmsg dan recvmmsg
  • Dengan mengirim dan menerima banyak datagram sekaligus, overhead dapat dikurangi secara drastis

Datagram besar tunggal yang disegmentasi

  • Teknologi offload seperti GSO (kirim) dan GRO (terima) memungkinkan datagram UDP besar dipecah otomatis oleh OS atau NIC saat transmisi
  • Antarmuka jaringan menangani pemisahan per paket, perhitungan checksum, dan penambahan header
  • Dengan begitu, aplikasi dapat memproses banyak paket nyata hanya dengan satu system call
  • Saat GSO aktif, dukungan analisis paket pada beberapa alat jaringan seperti Wireshark masih kurang memadai

Proses penggantian NSPR di Firefox

  • Langkah awalnya adalah mengganti NSPR dengan quinn-udp pada struktur kirim/terima datagram tunggal
  • Pipeline pemrosesan datagram pada implementasi QUIC kemudian direfaktor agar mendukung batch I/O dan segmentasi
  • Multi-message call dan segmentation offload call sama-sama dimanfaatkan sesuai kondisi
  • Penanganan pengecualian per platform dan berbagai peningkatan I/O turut ditambahkan

Detail per platform

Windows

  • Windows menyediakan WSASendMsg/WSARecvMsg, yang mendukung datagram berukuran MTU tradisional maupun datagram besar yang disegmentasi
  • Padanan USO (kirim) / URO (terima) di Windows setara dengan GSO/GRO di Linux
  • Awalnya tidak ada masalah saat hanya memakai pemanggilan datagram tunggal, tetapi ketika URO diaktifkan, muncul bug kegagalan pemuatan halaman pada lingkungan tertentu (mis. Windows on ARM + WSL) karena panjang paket QUIC tidak bisa ditentukan
  • USO untuk pengiriman juga sempat digunakan, tetapi ditemukan efek samping seperti peningkatan packet loss dan crash driver jaringan pada lingkungan instalasi Firefox di Windows
  • Saat ini Firefox tetap menonaktifkan URO/USO sambil melanjutkan proses debugging

MacOS

  • Di MacOS, quinn-udp diperkenalkan dengan mengganti sendto/recvfrom menjadi sendmsg/recvmsg
  • Fitur segmentation offload tidak diaktifkan
  • Sebagai gantinya, pengiriman batch didukung melalui sendmsg_x/recvmsg_x yang tidak terdokumentasi resmi, dan diterapkan secara tidak resmi ke quinn-udp
  • Karena Apple dapat menghapus pemanggilan tersebut di masa depan, fitur ini hanya diuji tanpa diaktifkan secara default dan tidak dimasukkan ke rilis aktual

Linux

  • sendmmsg/recvmmsg serta GSO/GRO semuanya didukung, dan quinn-udp secara default memprioritaskan GSO saat pengiriman
  • Firefox menggunakan socket UDP terpisah untuk setiap koneksi guna memperkuat privasi (dibedakan berdasarkan 4-tuple)
  • Dalam struktur ini, manfaat segmentation offload dimaksimalkan, sementara keuntungan pengiriman silang dari sendmmsg/recvmmsg menjadi terbatas
  • Selain perubahan kecil seperti sandbox jaringan dan pemeriksaan dukungan GSO saat runtime, adopsinya berhasil tanpa kesulitan berarti

Android

  • Berbeda dari Linux, Android memiliki jalur pemrosesan system call dan filter keamanan (mis. seccomp) yang berbeda
  • Ada berbagai masalah kompatibilitas, termasuk dukungan untuk platform yang sangat lama seperti Android 5 berbasis x86, penghindaran socketcall, dan penanganan error
  • Di beberapa lingkungan, pemanggilan kirim dengan bit ECN aktif memunculkan error (EINVAL), sehingga quinn-udp menerapkan strategi retry dan menonaktifkan opsi tersebut
  • Berkat berbagai perbaikan dari komunitas Quinn, Firefox juga otomatis mendapatkan manfaat peningkatan tersebut

Dukungan ECN (Explicit Congestion Notification)

  • Berkat penerapan system call modern, dukungan kirim/terima ancillary data kini tersedia, sehingga QUIC ECN dapat didukung
  • Meski ada bug kecil, di Firefox Nightly lebih dari separuh koneksi QUIC berjalan melalui jalur outbound ECN
  • Seiring teknologi baru seperti L4S makin mendapat perhatian, pentingnya dan kegunaan dukungan ECN juga meningkat

Ringkasan kesimpulan

  • Lapisan QUIC UDP I/O Firefox diganti dengan implementasi Rust berbasis quinn-udp, sehingga performa dan keamanan tercapai sekaligus
  • Dengan memanfaatkan system call I/O modern untuk tiap OS alih-alih system call lama, throughput meningkat dan dukungan ECN menjadi mungkin
  • Beberapa fitur optimasi di Windows dan platform lain masih memerlukan penyempurnaan tambahan karena masalah kompatibilitas
  • Seiring tingkat penggunaan QUIC terus meningkat, dukungan di level OS dan driver juga kemungkinan akan terus berkembang

Bacaan terkait

1 komentar

 
GN⁺ 2025-09-28
Komentar Hacker News

  • Inti tulisannya tersembunyi di tengah

    Dalam kasus ekstrem, pada benchmark yang dibatasi CPU, performanya meningkat dari < 1Gbit/s menjadi 4 Gbit/s. Pada flamegraph CPU, sebagian besar waktu dihabiskan untuk system call I/O dan kode enkripsi
    Fakta bahwa throughput jaringan meningkat 400% berarti penggunaan CPU untuk lalu lintas jaringan UDP berkurang drastis
    Ini juga sangat mengesankan dari sisi peningkatan efisiensi daya, terutama pada klien portabel seperti ponsel dan laptop
    Memang ada kecenderungan untuk selalu menganggap transisi seperti ini sebagai hal baik, tetapi tulisan ini terasa segar karena benar-benar membuktikannya dengan data nyata

    • Aku penasaran apakah suatu hari message passing yang melintasi konteks antara program pengguna dan sistem akan berjalan dengan akselerasi perangkat keras

  • Peningkatan yang dibahas di sini memang penting untuk kecepatan yang benar-benar sangat tinggi (100Gb/s ke atas), tetapi 4Gb/s sebenarnya bukan angka yang terlalu cepat
    Itu hanya 500MB/s, jadi artinya ada bottleneck serius yang sangat lambat di suatu titik
    Context switch kernel disebut berada di kisaran 1us, yang sebenarnya cukup tinggi untuk system call
    Tapi dengan rata-rata sekitar 500 byte per paket saja, 500MB/s atau 4Gb/s itu sudah bisa tercapai
    Angka 1Gb/s sebelumnya kemungkinan saat ukuran paket lebih kecil, dan sekadar mendorong paket UDP ke buffer NIC seharusnya masih sangat mungkin dicapai bahkan dengan kecepatan salin memori
    Walaupun enkripsi lambat, dalam praktiknya belum tentu begitu
    Misalnya Intel i5-6500 pernah mencatat kecepatan AES-128 GCM sebesar 1729MB/s
    CPU modern sekarang bisa mencapai 3-5GB/s per core, yaitu sekitar 25-40Gb/s, jadi angka 4Gb/s yang dibahas di sini terasa terlalu rendah
    (tautan referensi performa AES-128 GCM)

    • Disebut latensi system call tinggi, dan penyebabnya mungkin langkah mitigasi spectre & meltdown
      TCP punya binding jalur, sedangkan UDP tidak, jadi ada perbedaan besar dalam penyiapan rute
      Pernyataan bahwa enkripsi lambat memang benar untuk PDU (protocol data unit) berukuran kecil
      Kebanyakan optimasi dan benchmark berfokus pada frame TCP berukuran besar, sehingga pada paket kecil biaya penyiapan state justru lebih menonjol
      Kalau menjalankan microbenchmark dalam tight loop, angkanya memang terlihat bagus, tetapi di lingkungan nyata yang lebih acak, efisiensi pemanfaatan cache turun, dan untuk paket di bawah 1KB efisiensinya merosot tajam
      Ditambah lagi ada framing overhead tambahan, validasi data out-of-band, dan hal-hal lain yang cukup mahal
      Memori buffer UDP juga sering bermasalah karena nilai default-nya kurang memadai untuk penggunaan nyata
      Saat menjalankan TCP, ukuran buffer terus diperbesar, tetapi UDP masih tertahan di nilai konservatif era 90-an hingga 00-an
      API yang benar-benar dibutuhkan adalah kemampuan fork fd, dukungan penuh untuk connect(2) dan route binding, lalu dilanjutkan dengan submission queue-based seperti uring, rio, dan sejenisnya
      Dari sisi kriptografi, pendekatan KDF bisa sangat mengurangi biaya state
      Pendekatan PSP diakui oleh sebagian vendor, tetapi banyak ditolak di IETF dan tempat lain sehingga tidak menyebar luas
      Dalam pengujian konkurensi skala besar oleh vendor, hasil scaling-nya jauh lebih tinggi dibanding keluarga TLS lama

    • Sama sekali tidak disebutkan CPU kelas apa yang dipakai untuk benchmark
      Dan overhead enkripsi itu sebenarnya adalah biaya pemrosesan dari protokol QUIC itu sendiri
      QUIC juga masih kurang dalam hal offload enkripsi berbasis perangkat keras dibanding TCP, sementara TCP setidaknya bisa memanfaatkan offload kTLS di NIC sampai tingkat tertentu

  • Konten teknis seperti ini benar-benar memuaskan
    Andai semua materi teknis Mozilla sedalam ini dan ditulis dengan baik oleh engineer praktisi
    Tanpa optimisme kosong ala alegria, ini sangat layak dibaca

  • Aku tidak paham kenapa Android 5 masih didukung
    Sudah lebih dari 10 tahun sejak dirilis, dan pengguna perangkat itu berarti bahkan lebih legacy lagi
    Web modern sekarang terlalu berat, jadi rasanya perangkat setua itu pun sulit dipakai browsing dengan layak; jadi aku penasaran kenapa masih didukung
    Mungkin cuma para peretas yang memperbaiki perangkat lama seperti OnePlus generasi awal, membiarkannya selalu tersambung charger, tidak memasang ROM rakyat seperti LineageOS, lalu mencoba Firefox dari toko aplikasi alternatif
    Secara realistis ini adalah biaya yang memperlambat seluruh kecepatan pengembangan

  • Bagian tentang pelapor isu itu (juga pegawai Mozilla) bolak-balik berkali-kali, lalu akhirnya sampai membeli laptop dengan model dan warna yang sama untuk mereproduksi masalahnya
    Lucu karena itu menggambarkan kegilaan realitas reproduksi masalah jaringan, seperti di XKCD 2259
    (tautan komik xkcd)

    • Aku juga merekomendasikan blog pengembang Factorio berjudul "The map download struggle" karena ada kisah menarik yang berkaitan dengan hal ini
      (tautan tulisan blog terkait)

    • Siapa pun yang pernah benar-benar menangani masalah jaringan pasti akan lebih relate karena adanya mystery packet runts
      Sebagian besar perangkat jaringan tidak bagus dalam menangani paket seperti ini
      Lalu lintas berbasis UDP atau QUIC mudah menjadi sasaran serangan kecuali berada di lingkungan cloud besar di atas skala tertentu
      Karena itu, penyedia hosting kecil atau yang mengelola infrastruktur sendiri makin sulit bertahan, dan yang tersisa hanya pihak yang mampu menangani lalu lintas besar
      Itulah sebabnya di banyak lingkungan LAN, sebagian besar lalu lintas UDP dibuang dan hanya bagian yang diperlukan saja yang diproses dengan rate limit

  • Pelacak bug Mozilla
    Di macOS dan Fedora, aku masih mengalami gejala yang sama saat mengakses situs yang di-host Cloudflare lewat Firefox

  • Baru kali ini aku tahu bahwa Windows dan macOS juga punya fitur mirip GSO/GRO (pemrosesan paket jaringan berukuran besar)
    Sayangnya, katanya fitur itu penuh bug di dunia nyata

    • Aku jadi bertanya-tanya kenapa Microsoft dan Apple tidak sedikit lebih peduli pada kualitas network stack mereka
      Rasanya bukan cuma GSO/GRO saja yang bermasalah

  • Ada yang bisa menjelaskan bagaimana UDP GSO/GRO bekerja secara struktural?
    UDP itu paket tanpa urutan, jadi ketika satu paket QUIC dipecah menjadi beberapa paket UDP, tidak ada informasi urutan di header; lalu bagaimana sisi penerima menyusunnya kembali sesuai urutan?

    • Dari yang kupahami, pada level aplikasi, bahkan saat GRO aktif, kita sebenarnya tidak pernah menerima datagram UDP yang benar-benar digabungkan
      Konsepnya lebih ke kernel menaruh beberapa datagram dalam satu struktur, lalu menyerahkannya sambil tetap mempertahankan batas antar lapisan, misalnya data fragments di dalam sk_buff
      Aku bukan ahli yang tepat, tetapi saat mencoba mencari tahu cara kerjanya, aku merujuk ke tulisan ini

  • Disebutkan bahwa "kami memulai pengembangan di atas quinn-udp, pustaka UDP I/O dari proyek Quinn, dan berkat itu kecepatan pengembangan kami jauh lebih tinggi"
    Jadi aku penasaran apakah mereka juga memberikan dukungan dana kepada proyek Quinn
    (tautan donasi Quinn)

    • Aku bertanya langsung soal dukungan finansial, dan Senior Principal Software Engineer di Mozilla menjawab, "Mozilla tidak punya uang"
      Tapi mereka berkontribusi kode dalam jumlah besar, dan kami sangat berterima kasih untuk itu
      (Aku adalah maintainer utama Quinn)

    • Menanggapi pertanyaan "apakah mereka memberi donasi?", ada pendapat bahwa gaya Mozilla adalah tidak perlu mendanai open source dan lebih baik menghabiskan beberapa juta dolar tambahan untuk gaji CEO
      Bahkan produk flagship mereka, Firefox, pun sedang runtuh

    • Aku penasaran kontribusi lain seperti apa yang mereka berikan selain kode

  • Agak mengejutkan bahwa sendmmsg/recvmmsg disebut sebagai sesuatu yang “modern”
    Padahal system call itu sudah ada cukup lama
    Aku juga berharap io_uring akan disebut dalam pembahasan terkait Linux, tetapi ternyata tidak

    • io_uring tidak punya fitur batching yang benar-benar berarti untuk memproses banyak diagram UDP sekaligus
      Paling maksimal hanya bisa meminta banyak sendmsg atau recvmsg sekaligus
      GSO/GRO adalah jawaban yang tepat
      sendmmsg/recvmmsg sendiri sudah sangat tua, dan ada pengembang kernel yang bahkan ingin menghapusnya sekarang
      (diskusi GitHub terkait)