- Di lingkungan yang memungkinkan 500Mbps~1Gbps atau lebih per koneksi, seperti jaringan kabel berkecepatan tinggi, WiFi 6/7, dan 5G, stack UDP+QUIC+HTTP/3 menunjukkan laju transfer data hingga 45,2% lebih rendah dibanding TCP+TLS+HTTP/2
- Di luar unduhan file sederhana, pada Chrome, Edge, Firefox, Opera serta lingkungan desktop dan mobile, semakin tinggi bandwidth, semakin besar kesenjangan performa antara QUIC dan HTTP/2
- Hasil pelacakan paket serta profiling kernel dan user space menunjukkan bahwa bottleneck lebih dekat ke overhead pemrosesan di sisi penerima daripada sisi pengirim; saat menerima QUIC terjadi lebih banyak paket dan pemrosesan ACK di user space
- Dampak pada aplikasi berujung pada penurunan bitrate hingga 9,8% pada video DASH dan waktu muat halaman 3,0% lebih lama rata-rata untuk 100 situs web representatif
- Mitigasi memerlukan penerapan UDP GRO di sisi penerima, perbaikan GSO/GRO agar lebih ramah QUIC, peningkatan logika penerimaan, dan pemanfaatan beberapa core CPU, tetapi keragaman perangkat klien dan OS membuat realisasinya sulit
Kesenjangan Performa QUIC yang Terlihat di Jaringan Berkecepatan Tinggi
- QUIC adalah protokol transport layer multiplexing di atas UDP, dan telah distandardisasi oleh IETF sebagai basis transport untuk HTTP/3
- Sejak 2013, berbagai perusahaan seperti Google, Akamai, Meta, dan Cloudflare telah menerapkan QUIC secara komersial, dan bersama HTTP/3 QUIC mendapat perhatian sebagai kandidat yang dapat mengubah performa web
- Penelitian performa QUIC sebelumnya memiliki implementasi, lingkungan komputasi, dan kondisi jaringan yang beragam, dan banyak di antaranya berfokus pada kasus penggunaan throughput rendah
- Fokus pengukuran adalah perilaku QUIC pada jaringan berkecepatan tinggi yang mencapai 500Mbps atau lebih atau 1Gbps atau lebih per koneksi, seperti link kabel berkecepatan tinggi, WiFi 6/7, dan 5G
- Objek perbandingannya bukan satu protokol tunggal, melainkan keseluruhan stack
- Sisi QUIC: UDP+QUIC+HTTP/3
- Sisi yang ada: TCP+TLS+HTTP/2
- Dalam ringkasan, masing-masing disebut QUIC dan HTTP/2
Perbedaan yang Dikonfirmasi dalam Eksperimen Unduhan File
- Dalam eksperimen unduhan file sederhana menggunakan cURL dan
quic_clientberbasis Chromium, perbandingan dilakukan dengan menyamakan algoritma congestion control, konfigurasi server, dan kondisi jaringan - Pada bandwidth yang relatif rendah, yaitu di bawah sekitar 600Mbps, performa QUIC dan HTTP/2 serupa, tetapi pada bandwidth yang lebih tinggi throughput QUIC hingga 15,7% lebih rendah daripada HTTP/2
- Semakin besar bandwidth, semakin jelas kesenjangan performanya, dan selama penerimaan paket QUIC menunjukkan penggunaan CPU yang jauh lebih tinggi dibanding HTTP/2 pada host klien modern
- Dalam eksperimen pada browser utama, kesenjangannya menjadi lebih besar
- Browser yang diuji adalah Chrome, Edge, Firefox, Opera
- Di Chrome, saat bandwidth melampaui sekitar 500Mbps, QUIC mulai tertinggal
- Saat bandwidth mencapai 1Gbps, QUIC menjadi 45,2% lebih lambat daripada HTTP/2
- Pada klien yang lebih lemah seperti perangkat mobile, kesenjangannya menjadi lebih besar
Dampak pada Aplikasi Web
- Penurunan performa tidak terbatas pada transfer file berukuran besar, tetapi juga muncul pada aplikasi dengan pola trafik yang intermittent
- Saat chunk video DASH dikirim melalui Ethernet berkecepatan tinggi dan 5G, QUIC menunjukkan bitrate video hingga 9,8% lebih rendah dibanding HTTP/2
- Penurunan QoE ini hanya terlihat ketika bandwidth dasar cukup tinggi
- Pada 4G, dampaknya tertutupi
- Pada 5G, dampaknya terlihat
- Dalam eksperimen browsing web, berdasarkan rata-rata 100 situs web representatif, page load time (PLT) QUIC menjadi 3,0% lebih lama dibanding HTTP/2
- Pada ekor panjang, ada juga kasus ketika kesenjangan waktu muat halaman melebihi 50%
Penyebab Bottleneck: Pemrosesan Sisi Penerima dan ACK di User Space
- Dari pelacakan paket dan data performa, klien QUIC menerima jauh lebih banyak paket dibanding saat mengunduh dengan HTTP/2
- Saat QUIC menerima pada laju transfer data tinggi, latensi antara paket data yang masuk dan paket ACK yang sesuai meningkat, sehingga waktu pemrosesan paket QUIC bertambah
- Kedua observasi ini menunjukkan bahwa penyebab penurunan performa QUIC di internet berkecepatan tinggi berada pada batas kemampuan pemrosesan sisi penerima
- Ada dua alasan sisi penerima ditunjuk sebagai bottleneck
- Server umumnya lebih kuat daripada klien seperti desktop, laptop, dan smartphone
- Dalam desain QUIC, pemrosesan penerimaan data memiliki kesulitan tersendiri
- Dari profiling mendalam, dua penyebab utama dikonfirmasi
- Paket data berlebihan
- Saat mengunduh file yang sama, stack UDP di dalam kernel memicu jauh lebih banyak pembacaan paket
netif_receive_skbdibanding TCP - Tidak ada satu pun implementasi QUIC yang diselidiki menggunakan UDP generic receive offload, yaitu UDP GRO
- UDP GRO adalah metode ketika modul link layer menggabungkan beberapa datagram UDP yang diterima menjadi satu datagram besar sebelum meneruskannya ke transport layer
- Ini kontras dengan kondisi ketika TCP segmentation offload telah diterapkan luas dan GSO, offloading di sisi pengirim UDP, belakangan mendapat penekanan
- Saat mengunduh file yang sama, stack UDP di dalam kernel memicu jauh lebih banyak pembacaan paket
- Pemrosesan ACK di user space
- Di user space, QUIC memiliki overhead lebih tinggi untuk pemrosesan paket yang diterima dan pembuatan respons
- Penyebabnya mencakup paket berlebihan yang diteruskan dari kernel, pemrosesan QUIC ACK di user space, dan ketiadaan sebagian optimasi seperti delayed ACK pada QUIC
- Paket data berlebihan
Pengukuran Awal dan Arah Mitigasi
- Eksperimen awal mengunduh file 1GB di browser Chrome menunjukkan bahwa saat QUIC diaktifkan, waktu unduh kira-kira menjadi dua kali lipat
- Hasil sampel adalah rata-rata dari 10 kali eksekusi
- Desktop Ethernet: HTTP/2 9,32 detik, HTTP/3 18,60 detik, naik 99%, penggunaan CPU naik dari 77,5% menjadi 96,9%
- Pixel 5 low-band 5G: HTTP/2 37,11 detik, HTTP/3 78,65 detik, naik 112%, penggunaan CPU naik dari 121,55% menjadi 161,77%
- Pixel 5 mmWave 5G: HTTP/2 30,10 detik, HTTP/3 63,20 detik, naik 110%, penggunaan CPU naik dari 128,43% menjadi 165,20%
- Penggunaan CPU desktop didasarkan pada layanan jaringan browser, sedangkan pengukuran smartphone didasarkan pada keseluruhan proses browser
- Nilai penggunaan CPU yang melebihi 100% berarti proses browser menggunakan lebih dari satu core pada sistem multicore
- Mitigasi yang diusulkan adalah penerapan UDP GRO di sisi penerima, perbaikan GSO dan GRO agar lebih ramah QUIC, peningkatan logika QUIC di sisi penerima, serta penerimaan data QUIC melalui beberapa core CPU
- Karena host klien terdiri dari PC, perangkat mobile, perangkat embedded, dan beragam OS sehingga lebih heterogen daripada server, realisasi mitigasi memiliki kesulitan praktis
- Data pengukuran dan kode sumber dipublikasikan bersama penelitian tersebut
1 komentar
Komentar Hacker News
Industri ini tampaknya mau melakukan apa saja selain membuat situs yang ringan
Bahkan di akhir 90-an, selama koneksinya cepat, internet terasa instan, halaman-halamannya kecil, dan hampir tidak ada JavaScript
Sekarang pun masih bisa menemukan halaman ringan dan cepat seperti itu, dan rasanya hampir sureal karena halaman sudah selesai dimuat bahkan sebelum tombol mouse dilepas
Kalau pengalaman penggunanya jadi lebih baik mungkin masih bisa dimaklumi, tapi itu pun tidak kita dapatkan
Sekarang jadi lebih cepat dan jauh lebih tangguh, dan ketidaksesuaian state antara frontend dan backend juga hilang
Demi kenyamanan, aku masih menerima JavaScript seminimal mungkin, dan saat ini jumlahnya beberapa ratus baris; rencananya akan kutambah sedikit lagi agar tetap terlihat seperti aplikasi satu halaman
Dengan cara ini, aku bisa menghapus sekitar 40 ribu baris React dan sekitar 20 ribu baris Kotlin, meski harus menulis ulang sekitar 30 ribu baris kode backend
Meski begitu, aku tetap suka hasilnya
Jadi aku memindahkan homepage pribadiku ke versi VUE.JS statis untuk menambah pengalaman, tetapi cara mengikat view dan state dengan meneruskan nama variabel sebagai string terasa aneh, perluasan lingkungan build jadi rumit tanpa alasan, dan semuanya lambat serta harus dilakukan dengan cara tertentu saja
Karena semua orang memakainya, kupikir pasti benar, tapi sekarang aku sudah lepas dari cara pandang itu, dan versi barunya kuselesaikan hanya dengan HTML mentah dan template generator situs statis
Ukuran HTML turun 90%, penggunaan JS turun 97%, dan waktu build berubah dari 20 detik menjadi 2 detik
Pengalaman pengguna juga membaik, dan setelah versi baru dirilis, kunjungan pun naik 30%
Jika web dipakai lebih sedikit, web bisa jadi jauh lebih keren
Bahkan di backend, tren emas akhir-akhir ini adalah menjual microservice lewat produk SaaS headless yang terhubung melalui API, seolah performa pasti akan membaik dengan sendirinya
https://macharchitecture.com/
Kalau orang-orang ingin membeli sekop seperti itu, maka di dunia IT kita pun tidak punya pilihan selain menimbun sekop seperti itu
Blogku adalah situs Hugo yang dirender secara statis, jadi sama sekali tidak ada JS, dan proyek-proyekku berbasis Rails dan HTML server-rendered dengan JS seminimal mungkin hanya untuk fitur tambahan yang enak kalau ada
Tanpa JS pun semuanya tetap berjalan
Mungkin ini karena memang situsku sendiri, tapi pengalamannya jauh lebih baik daripada sebagian besar web lain, dan kita sudah kehilangan terlalu banyak
Google pernah membuat Speedtest berbasis JS murni
Saat itu Ookla masih berbasis Flash sehingga tidak berjalan di Chromebook, dan itu menjadi masalah bagi petugas instalasi saat memverifikasi status pemasangan
Dalam prosesnya, banyak pelajaran didapat tentang bagaimana TCP merespons berbagai faktor
Hasil tulisan ini kurang lebih sesuai perkiraan, karena flow control dipindahkan dari kernel dan mungkin juga adaptor jaringan ke ruang pengguna
TCP memiliki flow control dan jaminan urutan, sedangkan QUIC pada dasarnya membuat kita harus mengelolanya sendiri
Tentu ada alasan yang bagus untuk itu
Kontrol kemacetan TCP terkenal tertinggal dari kecepatan koneksi modern, dan algoritme baru seperti BBR memang muncul, tetapi ada biayanya [1]
Hal penting yang terlalu sering terlewat dalam pengujian jaringan atau aplikasi web adalah latensi
Siapa pun yang tinggal di Asia atau Australia pasti tahu betapa fatalnya latensi pulang-pergi 100ms
Itu bisa mengubah sesuatu yang tadinya sepenuhnya responsif menjadi nyaris tidak bisa dipakai, menurunkan bandwidth yang bisa didukung koneksi karena windowing, serta membuatnya lebih lamban terhadap error dan kontrol kemacetan
Jika Anda menguji jaringan atau aplikasi web, sangat disarankan untuk melakukan pengujian dengan menambahkan latensi 100ms secara acak [2]
Jadi overhead QUIC mungkin sebenarnya tidak terlalu penting
Sebab bandwidth efektif pada satu koneksi TCP atau satu stream QUIC bisa jauh lebih rendah daripada bandwidth mentah sebenarnya
Dengan kata lain, meskipun ada 45% data tambahan, itu tetap bisa menguntungkan jika mengelola kontrol kemacetan secara langsung membuat kecepatan efektif antar dua titik menjadi lebih tinggi
[1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
[2]: https://bencane.com/simulating-network-latency-for-testing-i...
Kalau dipikir-pikir, ini sebenarnya wajar: dengan TCP kita cukup berkata, “kernel, tolong kirim buffer besar ini”, sedangkan UDP bersifat packet-switched sehingga bahkan mengirim 0 pun menimbulkan biaya CPU yang besar di sebagian besar OS dan perangkat keras konsumen karena perpindahan mode
Ada jalan memutar, tetapi tidak mudah, dan menurut pengalaman saya belum cukup matang, serta membatasi pilihan bahasa, library, dan platform yang bisa dipakai
Tambahan lagi, saya melihat throughput turun drastis saat MacBook dipakai dengan baterai, kemungkinan ada kaitannya dengan efficiency core
Kedua, QUIC tidak menangani kontrol kemacetan dengan baik
Saya memakai quic-go, jadi mungkin berbeda tergantung lingkungannya, tetapi penyesuaian apa pun tidak banyak membantu, dan ketika berdampingan dengan stream TCP, TCP mengambil bandwidth yang lebih besar
Ketiga, API-nya terasa aneh
QUIC sendiri memiliki banyak stream, jadi ini bukan pengganti TCP yang bisa langsung disisipkan begitu saja
Namun tampaknya ada niat untuk menjadikan HTTP/3 sebagai pengganti yang bisa langsung disisipkan di lapisan yang lebih tinggi, meski saya belum mencobanya jadi tidak bisa berkomentar
Jika Anda bekerja di level stream, hal ini patut diingat
Kesimpulannya, rasanya cukup seperti kalah, tetapi pada saat yang sama saya jadi makin menghormati optimasi dan ketahanan teman lama kita, TCP
Ini benar-benar teknologi yang luar biasa, dan OS selalu menyediakannya secara gratis
Beberapa masalah utama TCP juga lebih disebabkan default yang konservatif atau warisan lama daripada cacat desain
Misalnya batas buffer di Linux, hal-hal seperti Nagle
Akan bagus jika kita bisa memperbaiki TCP saja ketimbang menemukan kembali roda
[1]: https://payload.app/
Itu memang keputusan yang diperlukan agar QUIC bisa mulai berjalan, tetapi sekarang karena QUIC sudah ada, keputusan itu bisa ditinjau ulang
Tidak ada hambatan teknis untuk mengimplementasikan QUIC di kernel, dan jika keuntungan performanya besar, hampir pasti seseorang akan melakukannya dalam waktu dekat
Bedanya seperti langit dan bumi
Ada preset Slow/Fast 4G dan 3G, dan Anda juga bisa membuat preset kustom untuk menentukan kecepatan unduh/unggah, latensi dalam ms, tingkat packet loss, panjang antrean paket, serta mengaktifkan packet reordering
Beberapa bulan lalu, Daniel Stenberg, pembuat sekaligus maintainer curl, menulis tentang HTTP/3 di curl: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
Salah satu hal yang ia tekankan adalah penggunaan CPU HTTP/3 yang lebih tinggi, sampai-sampai CPU menjadi faktor pembatas throughput
Saya penasaran, seberapa besar ini disebabkan ketidakmatangan implementasi, dan seberapa besar merupakan sifat dari desain QUIC itu sendiri
Rekomendasi ketiga adalah UDP GRO, yaitu memodifikasi kernel, idealnya perangkat keras NIC, agar paket UDP yang diterima dapat digabungkan sehingga pekerjaan per paket berkurang dan berubah menjadi pekerjaan per grup
TCP sudah memilikinya, dan di sisi pengirim juga ada hal serupa seperti TSO dan GSO di Linux
Ini juga terasa seperti masalah ketidakmatangan, tetapi jika mempertimbangkan kemungkinan kurangnya dukungan fitur perangkat keras, mungkin lebih sulit diperbaiki
Abstraknya membahas biaya dari mekanisme ACK di QUIC, tetapi saya belum menelaah klaim itu secara rinci
Fitur lain yang terlihat pada server modern berbasis TCP adalah offload TLS ke perangkat keras
Ini tampak lebih penting pada server yang mengirim banyak stream TCP secara bersamaan
Di Linux, ini dimungkinkan dengan menggunakan user-space networking atau melalui ‘kernel tls’, dan bila memungkinkan akan dioffload ke perangkat keras
Fitur ini juga terkait dengan kemampuan Linux yang agak unik untuk memecah stream TCP menjadi ‘message’ dan mengirimkannya ke thread lain, tetapi saya tidak tahu apakah message yang berada di belakang bisa diteruskan lebih dulu ketika paket sebelumnya hilang
Saya tidak pernah mendapat kesan bahwa tujuannya adalah membuat semua koneksi menjadi lebih cepat
Jika dilihat dari sudut pandang itu, trade-off tersebut masuk akal
Saya bukan ahli, jadi semoga ada yang lebih paham bisa mengoreksi
QUIC dibuat karena sama sekali tidak ada cara untuk membuat semua perangkat keras dan middleware di seluruh internet mendukung standar TCP atau TLS baru
Jadi QUIC adalah solusi elegan untuk menjalankan standar transport baru di atas UDP di atas perangkat keras internet lama
Dalam dunia ideal, kita akan membuat standar TCP dan TLS baru lalu mengganti atau memperbarui semua router internet dan perangkat keras di seluruh dunia untuk mengimplementasikannya dengan penggunaan CPU yang lebih rendah
Dalam pengujian, quiche yang terikat CPU berada di bawah 200MB/s sedangkan nghttp2 melampaui 900MB/s
Saya penasaran apakah CPU-nya mengalami throttling
Jika implementasi HTTP/3 menggunakan CPU 4 kali lebih banyak, itu menarik, tetapi jika nilai absolutnya sejak awal memang sangat rendah, belum tentu itu masalah besar
Bagian inti adalah pernyataan bahwa “pada internet cepat, stack UDP+QUIC+HTTP/3 menurunkan kecepatan data hingga 45,2% dibanding TCP+TLS+HTTP/2”, dan saya memang belum membaca seluruh makalahnya, tetapi dari pendahuluannya tampaknya koneksi di bawah 600Mbit/s dianggap sebagai internet lambat
Jika memakai Cloudflare sebagai contoh, mereka mendukung QUIC hanya antara klien <> edge dan tidak untuk koneksi ke origin
Jika koneksi edge <> origin dapat digunakan ulang, stabil, dan “cepat”, itu masuk akal
https://developers.cloudflare.com/speed/optimization/protoco...
Ini tidak terdengar seperti masalah mendasar pada protokolnya sendiri
Namun, berbeda dengan masalah penggunaan CPU yang membuat CPU melakukan boost, masalah latensi seperti ini tidak terlalu meningkatkan penggunaan baterai
Ini juga bukan masalah untuk komunikasi antarserver
Pada dasarnya ini adalah soal transfer berbandwidth tinggi yang menjadi “lebih lambat” di perangkat pengguna akhir saat memakai koneksi yang sangat cepat, bahkan pada 2024
Kecepatan yang dimaksud di sini bukan kecepatan yang dibeli dari iklan ISP, melainkan kecepatan efektif nyata dari perangkat ke server
Bukan berarti makalah ini tidak berguna; implementasi browser memang perlu diperbaiki, dan makalah ini menunjukkan hal itu dengan baik
Hanya saja judul makalahnya hampir 100% clickbait
Mengganti ke metode transport yang lebih lambat justru saat internet gigabit semakin umum jelas merupakan kesalahan
Dalam 30 tahun ke depan itu akan lebih cepat lagi, dan akan konyol jika demi memanfaatkan penuh kecepatan jalur kita justru harus memakai protokol yang lebih tua
Tulisan yang sama juga pernah muncul pada September: QUIC is not quick enough over fast internet (acm.org)
https://news.ycombinator.com/item?id=41484991 (327 komentar)
Brave/Vivaldi/Opera dan lainnya perlu dipilih secara sadar
Seolah-olah selama iklan sampai lebih cepat, hal lain tidak penting
Ini terdengar sangat aneh
Dengan QUIC+HTTP/3 saja, atau bahkan hanya QUIC, orang sudah pernah mencapai kecepatan 900mbps
Ini terdengar seperti implementasi TLS yang buruk, atau implementasi awal yang belum efisien
Penggunaan CPU sekitar 5% per inti EPYC generasi ke-2, yang terasa cukup normal
Sebagai anekdot, pernah ada masalah saat mengakses wordpress.org
Saat pertama kali memakai Wordpress, saya bisa membaca dokumentasinya dengan baik, tetapi pada suatu titik saya sama sekali tidak bisa mengakses situs webnya
Karena memakai dual boot dengan Linux, jelas ini bukan masalah Windows,
pingjuga berjalan baik, dan hasilnya tetap sama meski saya ganti tiga browserSaat masuk ke situs, halaman membeku dan sama sekali tidak dimuat, atau kadang pemuatan halaman berhenti di tengah jalan
Hari ini saya menemukan solusinya, yaitu mematikan Experimental QUIC Protocol di pengaturan Chrome
Selama beberapa bulan saya mengalami masalah akses ke wordpress.org, dan yang mengkhawatirkan adalah tidak ada tanda sama sekali bahwa penyebabnya adalah QUIC
Saya baru menyadarinya karena sesekali muncul error terkait QUIC di developer tools
Saya jadi bertanya-tanya, ada berapa banyak situs lain yang menjadi tidak bisa diakses karena protokol ini sementara para pengguna tidak tahu penyebabnya
Di sini yang dimaksud internet cepat adalah 500Mbps, dan alasannya tampaknya karena QUIC terlihat terikat CPU di atas kecepatan itu
Saya tidak menelitinya cukup dalam untuk memastikan apakah sistem pengujiannya adalah perangkat konsumen biasa, atau apakah ini masih menjadi masalah bahkan pada desktop berperforma tinggi
Yang lucu, kita diam-diam menerima gagasan seperti QUIC adalah HTTP/2 yang baru hanya karena kita tidak terlalu paham detailnya dan menganggap cepat = bagus
Ini mirip dengan membeli ponsel 5G baru karena katanya beberapa kali lebih cepat daripada 4G
Padahal 1) ponsel 4G saya tidak pernah sekali pun berjalan pada kecepatan maksimum 4G, dan 2) masalah koneksi hampir selalu bukan karena kecepatan jalur internet, melainkan karena server DNS, situs tujuan, atau perangkat multiplexer koneksi di sisi operator yang bermasalah
Tetap saja akhirnya jadi, “tapi ini 5G”
Iklan “fiber broadband” yang menampilkan orang menonton TV sambil rambutnya tertiup angin juga lucu
Kenyataannya tidak bekerja seperti itu
Dulu kita juga sudah streaming dengan koneksi 8Mb, jadi 300Mb mungkin berguna untuk beberapa hal, tetapi saya ragu orang benar-benar akan merasakan perbedaan besar
Saya berharap QUIC punya mode non-TLS
Saat melakukan development lokal, kadang saya hanya ingin melihat apa yang lewat di wire, tetapi ini menambahkan banyak friksi yang tidak perlu
Jadi tanpa itu, protokol ini tidak bisa bekerja