Cloudflare resmi meluncurkan fitur Origin Range Requests untuk seluruh tingkatan paket layanannya. Pembaruan ini merombak total cara jaringan edge mendistribusikan berkas berukuran besar dengan menggantikan sistem pembagian rentang berbasis NGINX lama ke arsitektur koordinator cache baru di atas Pingora, server proxy berbasis Rust buatan Cloudflare sendiri.
Langkah ini menyasar salah satu masalah paling mendasar pada jaringan pengiriman konten (CDN): bagaimana melayani permintaan sebagian isi berkas tanpa membebani server origin atau membuang bandwidth secara sia-sia.
Dalam protokol web, HTTP byte-range request memungkinkan klien meminta potongan tertentu dari sebuah berkas alih-alih mengunduh seluruh isinya dari awal. Klien mengirimkan header Range dengan batasan byte tertentu, dan server yang mendukung fitur tersebut akan membalas dengan status 206 Partial Content disertai header Content-Range. Mekanisme ini merupakan tulang punggung bagi pemutar video saat pengguna melompat ke durasi tertentu, pengelola unduhan berkas yang mendukung fitur resume setelah terputus, repositori paket kode, hingga beban kerja kecerdasan buatan modern yang sering kali perlu mengekstrak sebagian bobot model (model weights) atau metadata checkpoint tanpa menarik file biner raksasa secara utuh.
Namun, menangani cache untuk range request di skala jaringan global selalu menyimpan jebakan arsitektur. Selama bertahun-tahun, Cloudflare mengandalkan pendekatan cache slicing bawaan NGINX yang membagi berkas menjadi blok-blok berukuran tetap yang dikonfigurasi secara manual per zona domain.
Pendekatan statis tersebut menciptakan kompromi performa yang tidak seimbang. Jika administrator menyetel ukuran rentang terlalu besar, katakanlah puluhan megabyte, permintaan klien yang hanya membutuhkan beberapa kilobyte dapat memicu edge untuk menarik 64 MiB hingga 128 MiB data dari server origin. Data sebesar itu kemudian dialirkan melintasi tingkatan cache (tiered cache) dan beberapa pusat data sekaligus, bahkan ketika pengunjung situs telah berpindah halaman sebelum data tiba. Sebaliknya, jika rentang disetel terlalu kecil, server origin akan dihujani ratusan permintaan parsial berurutan yang menumpuk beban antrean dan memori di server edge.
Kelemahan lain dari sistem lama adalah ketidakmampuan NGINX menggabungkan caching rentang parsial dengan concurrent streaming—kemampuan di mana beberapa klien membaca berkas dari cache saat berkas tersebut masih dalam proses penulisan dari origin. Pada konfigurasi lama, permintaan bersamaan yang jatuh pada blok yang sama akan saling mengunci (blocking). Setiap blok harus selesai diunduh secara penuh sebelum klien mana pun dapat membacanya, memaksa berkas-berkas populer memicu tarikan origin terpisah untuk setiap rentang byte yang diminta.
Peralihan bertahap Cloudflare dari NGINX ke Pingora membuka peluang untuk menyelesaikan masalah ini dari tingkat penyimpanan disk. Pingora secara alami menyimpan seluruh berkas cache di media penyimpanan lokal dalam bentuk blok berukuran tetap (fixed-size chunks) agar unduhan yang terputus dapat dilanjutkan dengan cepat.
Arsitektur Origin Range Requests yang baru memanfaatkan karakteristik tersebut secara langsung. Alih-alih menuntut pengguna menentukan angka rentang sendiri, edge memperlakukan blok disk Pingora sebagai unit acuan.
Ketika permintaan rentang byte masuk, koordinator cache di edge terlebih dahulu memeriksa ketersediaan blok data yang diminta di media penyimpanan lokal atau aliran memori. Jika sebagian byte belum tersedia, edge hanya mengambil blok origin yang sejajar (aligned) dengan batas blok disk Pingora. Apabila terdapat proses unduhan lain yang sedang berjalan untuk blok yang sama, permintaan kedua akan otomatis menempel (attach) pada aliran data tersebut. Hasil akhirnya digabungkan menjadi satu respons tunggal yang rapi, dengan status dan header yang hanya memuat rentang byte pesanan klien.
Koordinator cache ini juga menyertakan lapisan validasi ketat untuk mencegah anomali data. Penggabungan byte hanya diizinkan jika seluruh potongan berasal dari representasi berkas yang identik. Sistem memeriksa kestabilan ukuran berkas dan mencocokkan validator entitas (ETag) di seluruh sub-permintaan. Jika klien menyertakan header If-Range dan representasi berkas telah berubah di origin, edge akan mengirimkan berkas versi baru secara utuh alih-alih mencampur potongan byte dari dua versi yang berbeda. Cloudflare juga menonaktifkan penggabungan rentang untuk respons yang akan didekompresi secara dinamis demi mencegah ketidaksesuaian offset byte.
Sebelum dibuka untuk publik, arsitektur baru ini diuji pada beban kerja terberat di jaringan internal Cloudflare: layanan penyimpanan objek Cloudflare R2. Pada implementasi lama, R2 dikonfigurasi dengan ukuran rentang 64 MiB, yang kerap kali memicu transfer data 128 MiB antar-pusat data untuk pembacaan kecil.
Hasil penerapan koordinator Pingora pada R2 menunjukkan peningkatan performa yang signifikan: - Penurunan latensi p99 Time to First Byte (TTFB) hingga sekitar 50 persen di seluruh kawasan penyimpanan R2, baik pada kondisi cache hit maupun cache miss. - Penurunan lalu lintas jaringan pada tiered cache sebesar 6 persen secara mingguan untuk R2 dan beban kerja sejenis, yang memangkas pergerakan petabyte data antar-pusat data setiap harinya.
Fitur Origin Range Requests kini sudah dapat diaktifkan langsung oleh pengguna di semua paket melalui menu Cache Rules di dashboard Cloudflare, atau diprogram melalui API dengan konfigurasi origin_range_requests: { "mode": "on" }. Pengguna tidak perlu lagi menebak ukuran byte atau menyesuaikan ekstensi berkas secara manual.
Informasi teknis selengkapnya dipublikasikan oleh teknisi Cloudflare Matthew Gumport melalui [pengumuman resmi di Cloudflare Blog](https://blog.cloudflare.com/origin-range-requests/).