Teknologi QUIC yang Tidak Cukup Cepat Bahkan di Internet Cepat

 (arxiv.org)
2 poin oleh GN⁺ 2024-10-20 | 1 komentar | Bagikan ke WhatsApp

QUIC tidak cukup cepat di internet cepat

  • Latar belakang penelitian

    • QUIC diharapkan memainkan peran penting dalam meningkatkan performa aplikasi web.
    • Makalah ini menyelidiki performa QUIC secara sistematis di jaringan berkecepatan tinggi.

  • Temuan utama

    • Di internet berkecepatan tinggi, stack UDP+QUIC+HTTP/3 menunjukkan penurunan kecepatan transfer data hingga 45,2% dibandingkan TCP+TLS+HTTP/2.
    • Seiring meningkatnya bandwidth dasar, kesenjangan performa antara QUIC dan HTTP/2 makin melebar.
    • Masalah ini memengaruhi berbagai aplikasi, bukan hanya transfer file tetapi juga streaming video (penurunan bitrate video hingga 9,8%) dan penjelajahan web.

  • Metode analisis

    • Akar penyebab masalah diidentifikasi melalui analisis packet trace serta profiling kernel dan ruang pengguna.
    • Overhead pemrosesan di sisi penerima tinggi, terutama karena paket data yang berlebihan dan ACK QUIC di ruang pengguna.

  • Rekomendasi perbaikan

    • Makalah ini menyajikan rekomendasi konkret untuk mengurangi masalah performa yang diamati.

Ringkasan GN⁺

  • Makalah ini menganalisis masalah performa QUIC di lingkungan jaringan berkecepatan tinggi dan memberikan insight penting yang dapat berkontribusi pada peningkatan performa aplikasi web.
  • Dengan mengidentifikasi penyebab penurunan performa QUIC sebagai overhead pemrosesan di sisi penerima dan mengusulkan langkah-langkah konkret untuk mengatasinya, makalah ini memberikan informasi yang berguna bagi insinyur jaringan dan pengembang.
  • Protokol lain dengan fungsi serupa adalah HTTP/2, dan perbandingan performa dengannya menunjukkan arah perbaikan bagi QUIC.

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-20
Komentar Hacker News

  • Industri tampaknya mencoba segala hal kecuali membuat situs web yang ringan. Pada akhir 90-an, jika Anda punya koneksi internet cepat, halamannya kecil dan hampir tanpa JavaScript. Bahkan hari ini pun masih bisa ditemukan halaman ringan yang memuat cepat seperti itu, dan pengalamannya terasa nyaris surealis. Kalau pengalaman pengguna memang lebih baik, mungkin ini akan lebih bisa ditoleransi.

  • Saya pernah mengerjakan Speedtest berbasis JS murni di Google. Waktu itu Ookla berbasis Flash, jadi tidak berjalan di Chromebook. Saya belajar banyak tentang bagaimana TCP bereaksi terhadap berbagai faktor. Melihat artikel ini, hasilnya terasa sesuai dugaan. Alasannya karena flow control didorong dari kernel ke ruang pengguna. TCP punya flow control dan sequencing. QUIC membuat semua itu harus dikelola sendiri. Kontrol kemacetan TCP memang tidak cocok dengan kecepatan koneksi modern sehingga perlu algoritme baru seperti BRR, tetapi itu ada biayanya. Pelajaran terbesarnya adalah jangan meremehkan pentingnya latensi dalam pengujian jaringan. Orang yang tinggal di Asia atau Australia pasti tahu betapa mematikannya latensi RTT 100 ms. Overhead QUIC mungkin pada praktiknya tidak terlalu penting, karena bandwidth nyata melalui satu koneksi TCP atau stream QUIC bisa jauh lebih rendah daripada bandwidth mentah.

  • Daniel Stenberg, pencipta dan pemelihara Curl, pernah menulis di blog tentang HTTP/3. Ia menyoroti tingginya penggunaan CPU pada HTTP/3 dan menyebut bahwa CPU bisa menjadi pembatas throughput. Saya penasaran apakah ini karena implementasinya belum matang, atau memang karena desain QUIC seperti itu.

  • Disebutkan bahwa pada internet cepat, stack UDP+QUIC+HTTP/3 bisa menurunkan kecepatan transfer data hingga 45,2% dibanding TCP+TLS+HTTP/2. Saya belum membaca seluruh makalahnya, tetapi di sini 600 Mbit/s ke bawah dianggap sebagai "internet lambat".

  • Katanya QUIC tidak cukup cepat untuk internet cepat. Mereka mencapai kecepatan 900mbps dengan quic+http3, dan saya bertanya-tanya apakah implementasi TLS-nya yang buruk, atau implementasi awalnya memang tidak efisien. Penggunaan CPU rata-ratanya sekitar 5% pada core gen 2 epyc.

  • Di sini yang dimaksud "internet cepat" adalah 500Mbps, dan penyebabnya disebut karena quic bergantung pada CPU. Saya belum mengecek apakah sistem pengujiannya adalah sistem konsumen biasa atau apakah ini juga menjadi masalah pada desktop berperforma tinggi.

  • Saya kira QUIC dioptimalkan untuk latensi. Ia dioptimalkan untuk memuat banyak paket kecil pada halaman web dan video game. Kalau yang diukur hanya throughput total, mungkin hasilnya memang kurang bagus. Saya penasaran apakah pada level protokol bisa dideteksi transfer file besar atau streaming video berbandwidth tinggi lalu beralih ke sesuatu yang tidak terlalu intensif CPU. Saya juga penasaran apakah QUIC memang kurang dioptimalkan di level hardware/OS dibanding TCP.

  • Saya berharap QUIC punya mode tanpa TLS. Saat mengembangkan secara lokal, kadang saya ingin bisa melihat apa yang dikirimkan, dan ini menambah friksi yang tidak perlu.