Zeroserve: server web tanpa konfigurasi yang bisa discrpt dengan eBPF

• zeroserve, server HTTPS yang kecil dan cepat, menerima tarball situs web lalu menyajikannya lewat HTTP/2 dan TLS 1.3, sambil mengeksekusi program eBPF di dalam tarball sebagai middleware sandbox ruang pengguna untuk setiap permintaan
• Tanpa berkas konfigurasi, program eBPF menentukan routing per permintaan, header, autentikasi, pembatasan laju, dan proxy, sehingga menyatukan konfigurasi deklaratif ala nginx·Caddy dan lapisan skrip terpisah menjadi satu
• Situs diindeks sebagai satu berkas tar dan tidak diekstrak ke disk; dengan mengganti tarball dan mengirim SIGHUP, situs·skrip·materi TLS diganti secara atomik tanpa kehilangan koneksi
• Dalam benchmark HTTPS satu inti, zeroserve mencatat 36.681 req/s untuk berkas statis kecil, 46.945 req/s untuk JSON dinamis eBPF 10ms, dan 26.486 req/s untuk proxy kecil, tetapi untuk proxy 100KB nginx unggul dengan 5.882 req/s
• zeroserve menargetkan diri sebagai alternatif nginx dan Caddy dengan menggabungkan deployment tarball tunggal, konfigurasi terprogram, eBPF ruang pengguna, dan TLS modern, tetapi untuk respons proxy besar nginx lebih cocok

---

Ikhtisar

• zeroserve adalah server HTTPS kecil, cepat, dan tanpa konfigurasi yang menyajikan satu tarball situs web melalui HTTP/2 dan TLS 1.3
• Program eBPF yang dimasukkan ke dalam tarball dijalankan pada setiap permintaan sebagai middleware sandbox ruang pengguna, dan dapat menangani penulisan ulang permintaan, autentikasi, pembatasan laju, serta reverse proxy backend
• Ini adalah server yang ditujukan untuk menunjukkan performa lebih tinggi daripada nginx pada sebagian besar beban kerja per inti tunggal, termasuk berkas statis kecil·besar, middleware skrip, dan proxy respons kecil
• Skrip eBPF dikompilasi JIT menjadi kode native dan disandbox di ruang pengguna, dengan target biaya yang cukup rendah untuk dijalankan pada setiap permintaan
• Operasi jaringan dan disk dikirim lewat io_uring melalui runtime monoio
• Mendukung TLS 1.3, HTTP/2, Encrypted Client Hello, pemilihan sertifikat SNI, dan fingerprinting JA4
• Seluruh situs dan materi TLS disajikan dari satu tarball, dan dapat di-hot reload dengan SIGHUP

Model konfigurasi: program adalah konfigurasi

• zeroserve menargetkan diri sebagai alternatif untuk nginx dan Caddy, dan pilihan desain intinya adalah cara konfigurasi
• nginx dan Caddy menyediakan bahasa konfigurasi deklaratif seperti blok location, aturan rewrite, direktif map, dan try_files, lalu ketika mencapai batas mereka menambahkan runtime skrip opsional seperti Lua atau plugin Caddy di sampingnya
• Dalam struktur itu, perilaku terbagi antara lapisan direktif dengan alur kontrolnya sendiri dan lapisan skrip yang berjalan pada titik tertentu dalam siklus hidup permintaan
• zeroserve tidak memiliki berkas konfigurasi; satu program eBPF melihat semua permintaan dan menentukan routing, header, autentikasi, pembatasan laju, dan proxy

Menyajikan satu tarball apa adanya

• Seluruh situs adalah satu berkas tar, dan saat memuat zeroserve membuat peta path -> byte-range lalu menyajikan berkas dengan membaca rentang byte langsung dari tarball itu sendiri
• Karena tidak ada berkas yang diekstrak ke disk, situs hanya ada di dalam satu berkas dan tidak ada document root yang bisa terekspos oleh aturan location yang salah
• Deployment dilakukan dengan penggantian atomik satu berkas; untuk merilis versi baru cukup ganti tarball lalu kirim SIGHUP
• Format pengemasan direktori dan perintah eksekusinya adalah sebagai berikut

zeroserve --pack ./public > site.tar  
zeroserve --addr 0.0.0.0:8080 site.tar  

• Format perintah hot reload adalah sebagai berikut

killall -SIGHUP zeroserve  

• Reload mengganti situs, skrip, dan materi TLS secara atomik di dalam proses yang sama dan berjalan tanpa kehilangan koneksi
• Setiap instance adalah event loop satu thread; ini memang membatasi per proses, tetapi diposisikan sebagai bentuk yang cocok ketika unit skalanya adalah “lebih banyak proses”

Scripting eBPF ruang pengguna

• Semua berkas .c yang ditempatkan di bawah .zeroserve/scripts/ dikompilasi menjadi objek eBPF dengan clang dan llc saat packaging, lalu dijalankan pada setiap permintaan
• eBPF dijalankan di ruang pengguna melalui runtime async-ebpf dalam proses biasa tanpa hak istimewa, tanpa subsistem kernel BPF maupun CAP_BPF
• async-ebpf menyematkan uBPF untuk mengompilasi bytecode secara JIT menjadi kode mesin x86-64 native
• Pointer cage memask semua akses memori dari kode hasil JIT ke arena khusus program, sehingga akses yang salah tetap terkurung di dalam memori skrip
• Skrip berjalan langsung di event loop tunggal zeroserve, dan agar skrip lambat tidak menghentikan koneksi lain, timer dapat menginterupsi kode native hasil JIT di tengah eksekusi dan mengembalikan kontrol ke event loop
• Model pemrogramannya adalah rantai skrip yang dieksekusi menurut urutan nama berkas, dan skrip-skrip tersebut berbagi peta metadata per permintaan
• Jika skrip memanggil zs_respond atau zs_reverse_proxy, rantainya berhenti lebih awal
• Kunci di bawah zs.response.header.* menjadi header untuk semua respons, sedangkan kunci lain digunakan dalam pass templating kecil yang mengganti placeholder seperti <zs-meta>visitor</zs-meta> dalam berkas HTML saat output
• Permukaan helper mendukung pembacaan metode·path·query·header·alamat peer permintaan, penulisan ulang URI, serta pengaturan·penghapusan header
• Helper kriptografi dan encoding menyediakan SHA-256, HMAC-SHA256, base64, hex, dan getrandom
• Helper JSON mendukung parsing body permintaan, pembuatan·modifikasi pohon dokumen, dan respons zs_json_respond
• Pembatasan laju mendukung token bucket berbasis kunci arbitrer seperti IP peer atau API key, dan statusnya tetap dipertahankan bahkan setelah hot reload
• Helper AWS SigV4 mendukung header Authorization bertanda tangan dan presigned URL untuk berkomunikasi dengan S3 dan layanan AWS lainnya
• Login OIDC menyediakan alur relying-party berbasis Authorization Code + PKCE, dan seluruh sesi login disimpan dalam cookie sealed XChaCha20-Poly1305 agar server tetap stateless sambil menempatkan situs statis di balik “Login with Google”
• Endpoint dinamis merespons langsung dari skrip pada path tertentu; dalam contoh, permintaan /health mengembalikan header application/json dan body {"status":"ok"}
• Setiap skrip berjalan dengan batas memori default 256KB, dan runtime melakukan time-slicing untuk skrip yang berjalan lama serta melakukan throttling pada skrip yang runaway
• Skrip dapat saling memanggil dengan zs_call, dan kedalaman pemanggilan dibatasi
• Skrip yang masuk ke loop tak berujung hanya menunda permintaannya sendiri; timer preemptif menginterupsinya sehingga server tetap bisa memproses permintaan lain
• Lapisan TLS hanya mendukung TLS 1.3 dan terminasi dilakukan oleh BoringSSL
• Encrypted Client Hello mencegah SNI sebenarnya muncul dalam plaintext, serta menyediakan pemilihan sertifikat SNI berbasis direktori dan fingerprinting klien JA4 yang diekspos ke skrip
• Mode relay ECH transparan meneruskan handshake yang tak bisa didekripsi apa adanya ke upstream sebenarnya pada level byte, sehingga nama yang dilindungi bisa bercampur di balik nama publik

Performa

• Kondisi benchmark

  • Membandingkan zeroserve, nginx 1.26, dan Caddy 2.11 yang menyajikan HTTPS dengan konten yang sama dan sertifikat self-signed yang sama pada Ryzen 7 3700X 8 inti
  • Karena instance zeroserve menurut desain bersifat single-threaded, basis perbandingannya adalah performa per inti
  • Semua server dipatok ke satu CPU dengan taskset; nginx menggunakan worker_processes 1, Caddy GOMAXPROCS=1, dan zeroserve menggunakan struktur single-thread yang ada
  • Beban dibuat dari inti lain dengan wrk -t4 -c100, dan digunakan median dari 3 kali eksekusi 10 detik
  • Karena wrk menggunakan HTTP/1.1, angka-angka tersebut adalah HTTP/1.1 di atas TLS 1.3, yakni biaya steady-state dari koneksi HTTPS yang sudah terbuka dengan koneksi keep-alive panjang sehingga biaya handshake tersebar

• Berkas statis kecil 174B

  Server	req/s	p99
  zeroserve	36.681	5,4 ms
  nginx	31.226	7,8 ms
  Caddy	12.830	22 ms

  • zeroserve melayani berkas kecil sekitar 17% lebih cepat daripada nginx pada satu inti, dan latensi tail juga lebih rendah
  • Kasus dasar situs statis seperti halaman HTML, JSON kecil, dan CSS adalah target tuning zeroserve

• Berkas statis besar 100KB

  Server	req/s	Throughput	p99
  zeroserve	8.000	782 MB/s	22 ms
  nginx	7.600	773 MB/s	28 ms
  Caddy	6.084	590 MB/s	44 ms

  • Hasil ketiga server berdekatan, dan zeroserve sedikit unggul sekitar 780 MB/s pada satu inti
  • Keunggulan sendfile() nginx untuk berkas besar tidak digunakan di bawah TLS, karena byte harus dienkripsi di ruang pengguna, sehingga ketiganya sama-sama terikat pada enkripsi dan loop penulisan
  • Dengan kernel TLS dimatikan pada ketiga server, jalur baca·tulis io_uring milik zeroserve sedikit lebih cepat

eBPF vs Lua

• Pembanding untuk scripting adalah nginx + LuaJIT ngx_http_lua_module, yaitu cara umum untuk menjalankan kode cepat di dalam server web
• Secara default zeroserve mengatur timer preemptif skrip setiap 2ms; interval yang rapat cepat men-throttle skrip bermasalah tetapi juga menambah biaya pada skrip normal
• Pada default 2ms, untuk respons dinamis sepenuhnya eBPF berada di sekitar 32k req/s, lebih rendah daripada 41k req/s milik nginx Lua
• Jika --preempt-timer-interval-ms dinaikkan ke 10, throughput scripting pulih sekitar 40% dan hasilnya berbalik

• Middleware injeksi header per permintaan

  Engine	req/s	p99
  zeroserve eBPF 10ms	43.709	5,1 ms
  zeroserve eBPF 2ms default	31.334	6,7 ms
  nginx Lua header_filter	28.653	8,4 ms

  • Pada kasus middleware di mana skrip dijalankan tetapi berkas statis tetap disajikan, eBPF 10ms sekitar 50% lebih tinggi daripada nginx Lua dan latensi tail juga lebih rendah

• Respons JSON dinamis sepenuhnya

  Engine	req/s	p99
  zeroserve eBPF 10ms	46.945	4,5 ms
  nginx Lua content_by_lua	41.231	6,4 ms
  zeroserve eBPF 2ms default	32.393	6,7 ms

  • eBPF yang disetel dengan interval 10ms mencatat throughput lebih tinggi daripada content_by_lua milik nginx bahkan untuk respons yang sepenuhnya sintetis
  • Kedua engine sama-sama dikompilasi menjadi kode native; LuaJIT adalah tracing JIT, sedangkan async-ebpf melakukan JIT kompilasi eBPF melalui uBPF
  • Dalam kondisi ketika enkripsi TLS menjadi biaya permintaan bersama, jalur eBPF yang telah disetel unggul dalam throughput
  • Pada default 2ms, eBPF tetap unggul untuk middleware tetapi kehilangan posisi terdepan pada respons sintetis, sehingga 10ms direkomendasikan untuk skrip produksi

Digunakan sebagai reverse proxy

• zeroserve melakukan proxy ke backend ketika skrip memanggil zs_reverse_proxy("http://127.0.0.1:9000";)
• Pool koneksi upstream mendukung hingga 128 koneksi per backend dengan reuse idle selama 30 detik
• Demi perbandingan yang adil, nginx secara eksplisit menggunakan keepalive 128, proxy_http_version 1.1, dan header Connection kosong, mengingat secara default ia cenderung menutup koneksi upstream setiap permintaan
• Caddy menggunakan reuse koneksi sesuai perilaku default-nya
• Tiap proxy melakukan terminasi TLS pada satu inti lalu meneruskan ke backend plaintext bersama, dan backend berada di server 2 inti terpisah yang mempertahankan 100k req/s sendiri, sehingga yang diukur hanya overhead proxy

• Proxy respons kecil 174B

  Proxy	req/s	p50	p99
  zeroserve	26.486	3,3 ms	8 ms
  nginx	21.761	4,2 ms	10,5 ms
  Caddy	7.683	10,3 ms	33 ms

  • Proxy io_uring ber-pooling milik zeroserve unggul sekitar 22% atas nginx dan mencatat throughput sekitar 3,4 kali Caddy
  • Untuk beban proxy umum seperti panggilan API, JSON kecil, dan HTML dari app server, zeroserve melakukan terminasi TLS dan penerusan backend lebih cepat

• Proxy respons 100KB

  Proxy	req/s	Throughput
  nginx	5.882	585 MB/s
  Caddy	4.285	406 MB/s
  zeroserve	3.631	359 MB/s

  • Ketika body proxy membesar, buffering nginx memindahkan byte lebih efisien sehingga unggul, diikuti Caddy, sementara zeroserve tertinggal
  • Jika respons proxy besar, nginx adalah alat yang lebih baik; jika respons kecil dan banyak, zeroserve lebih cepat

Memori

• Satu instance zeroserve saat idle menggunakan sekitar 15MB PSS, lebih besar dari nginx sekitar 6MB tetapi lebih kecil dari Caddy sekitar 60MB
• Yang penting adalah unit eksekusinya berupa seluruh proses; saat menjalankan salinan per inti, biner yang sama dipetakan sehingga halaman kode dibagi bersama
• Proses tambahan hanya menambah sedikit memori di luar working set-nya sendiri

Rilis

• zeroserve adalah proyek open source yang dirilis di GitHub

[GN⁺]

Komentar Hacker News

• Dengan hilangnya benchmark server web TechEmpower, rasanya kesempatan proyek-proyek baru seperti ini untuk membuktikan diri jadi berkurang
  Edit: sepertinya saya yang ketinggalan, dan yang sedang naik daun belakangan ini tampaknya https://www.http-arena.com/leaderboard/ . Semoga berhasil

  • Saya tidak paham maksudnya apa dengan bilang sudah mati. Masih ada di https://www.techempower.com/benchmarks/#section=data-r23, dan benchmark terakhir juga pada Februari 2025
    Hanya saja memang dari awal tidak sering dijalankan, dan kalau melihat riwayat putarannya, dijalankan kurang dari sekali setahun
  • UI/UX LLM sangat buruk. Padahal kalau orang mau meluangkan satu-dua hari di akhir pekan untuk hal seperti ini, pengalaman penggunanya bisa jauh lebih baik, jadi saya tidak paham kenapa itu tidak dilakukan

• Menyenangkan melihat upaya seperti ini muncul karena berkat LLM eksplorasi jadi bisa dilakukan dengan relatif murah dan cepat
  Tapi kesan yang saya dapat di sini justru bahwa nginx itu sendiri cukup mengesankan. Bagian lain yang menonjol adalah penjelasan bahwa proyek ini merupakan alternatif untuk nginx dan Caddy, serta bertaruh pada cara konfigurasi
  nginx dan Caddy menyediakan bahasa konfigurasi deklaratif, lalu ketika mentok pada batasannya, mereka menempelkan runtime skrip seperti Lua atau plugin Caddy di sampingnya, sehingga perilakunya terbelah menjadi dua lapisan
  Namun taruhan itu tampaknya keliru. Orang-orang sudah lama lebih menyukai konfigurasi daripada kode, dan dalam banyak kasus fitur bawaan saja sudah cukup sehingga tidak perlu menulis kode C

  • Sulit untuk yakin soal itu
    Semua format file konfigurasi sepertinya berawal dari sesuatu yang sederhana. YAML pun dasarnya cukup masuk akal, tetapi orang mulai menginginkan hal yang lebih rumit dengan anchor dan alias
    Bahkan GitLab punya format buatannya sendiri yang mirip kondisi dan variabel, dan itu nyaris seperti hack yang hanya bekerja di lokasi tertentu. Apache juga menempuh jalan serupa dengan format konfigurasi berbasis XML
    Pada akhirnya muncullah banyak sekali bahasa pemrograman khusus untuk mengelola konfigurasi. Di lingkungan perusahaan, orang bahkan tidak mengeditnya langsung, melainkan menulis workflow Ansible sebagai skrip untuk melakukan operasi jarak jauh
    Seandainya saja server sejak awal menyematkan interpreter seperti Lua atau Python untuk menangani konfigurasi, seluruh proses itu bisa dilewati, dan itu akan lebih sederhana daripada memperbaiki file konfigurasi khusus dengan program
    Tentu orang bisa berargumen bahwa pendekatan khusus seperti itu lebih optimal untuk kegunaan tertentu dibanding bahasa umum, tetapi klaim seperti itu pada dasarnya hanya cocok untuk cakupan sempit contoh mainan yang sebenarnya tidak memerlukan perangkat semacam itu sejak awal
    Masih ingat file INI di Windows? Itu masa-masa indah ketika kode adalah kode dan data adalah data
  • Dalam 96 jam ke depan, rasanya seseorang bisa membuat alat pembungkus yang mengonversi file konfigurasi nginx atau Caddy dengan LLM menjadi kode yang bisa dipakai zeroserve
    Atau lebih sederhana lagi, bisa membaca semua manifest Ingress di klaster Kubernetes lalu membangun ulang pack
    Intinya, antarmuka antara alat dan konfigurasi juga hanyalah API lain, dan operator sistem sudah mendeskripsikan status sistem melalui konstruksi tingkat yang lebih tinggi, sementara byte konkret yang membentuk konfigurasi hanyalah hasil akhirnya
  • Saya jadi bertanya-tanya bagaimana kalau kompleksitasnya diabstraksikan dan komposisi ala “file konfigurasi” dicapai dengan macro
  • Patut diamati apakah preferensi ini akan berubah ketika AI makin memungkinkan ucapan manusia → efek mesin
    Dari sudut pandang AI, cara itu mungkin lebih mudah ditangani. AI bisa menangani keduanya, jadi mungkin butuh waktu lama sampai pergeseran seperti itu benar-benar dianggap ide yang jelas lebih baik
  • Saya tidak paham kenapa Anda ingin sekali memberi kredit pada LLM. Hanya karena penulisan artikel dibantu LLM, bukan berarti eksperimennya juga dilakukan oleh LLM

• Saya suka idenya
  Hanya saja saya akan merasa lebih tenang jika di direktori eBPF bisa menaruh file .rs alih-alih file .c. Apalagi ini juga sudah merupakan proyek Rust
  Dan entah kenapa saya tadinya mengharapkan server web dengan akselerasi kernel. Kalau itu bisa dilakukan dengan aman memakai eBPF, benar-benar luar biasa
  Lalu ini single-threaded? Di Linux, melakukan fork dan berbagi antrean koneksi masuk itu nyaris sepele, dan di Rust pun mungkin hanya butuh beberapa baris. Dengan SO_REUSEPORT, sisanya ditangani kernel
  Sebagai catatan, kalau ingin mendorong io_uring, menurut saya kTLS juga harus didorong. Jika pemrosesan SSL di user space bisa dihindari setelah handshake, desainnya akan jauh lebih sederhana

  • Terima kasih. Saya memang berencana mengimplementasikan fork + SO_REUSEPORT
    Sampai sekarang saya memakai nftables untuk kebutuhan seperti ini, jadi belum pernah benar-benar membutuhkannya sendiri

• Sangat keren. Saya penasaran apakah ini bisa digabungkan dengan tipe program BPF lain seperti program XDP atau program yang menempel ke socket map, agar fitur HTTP L7 bisa diintegrasikan lebih jauh ke lapisan bawah

• Idenya bagus, tetapi saya tidak yakin apakah fokus pada file statis itu tepat. Sekarang ini jarang ada yang menyalakan server baru khusus untuk tujuan itu

  • Minggu lalu saya melakukan render Ghost menjadi statis dan memang melakukan persis seperti itu, sambil setengah berpikir bukankah satu biner self-contained akan lebih cepat
    Jadi ini terasa seperti dibuat untuk saya, walaupun saya mengakui saya bukan pengguna yang umum
  • Tergantung domainnya. Di berbagai bidang sains, dataset besar disajikan secara efisien dalam format file statis. Contohnya seperti https://zarr.dev/ atau https://parquet.apache.org/

• Terlihat bagus dan fiturnya juga lumayan. Tapi entah kenapa terasa terlalu dibuat-buat, jadi tidak langsung membuat saya tertarik.
  Tidak jelas apakah metriknya palsu, apakah fungsi-fungsi bantu itu benar-benar bekerja, atau apakah sudah ada hardening yang layak.
  Saya masih bisa menerima kalau ini dibuat dengan vibe coding dan bahkan README-nya dibuat otomatis. Tapi sampai postingan blog pengumumannya juga dibuat AI, dan sama sekali tidak ada dasar untuk menilai apakah pemahamannya soal kualitas perangkat lunak sejalan dengan saya.
  Dunia yang aneh. Beberapa tahun lalu, kalau diumumkan tanpa pemberitahuan AI, saya mungkin akan menerimanya tanpa curiga. Sekarang, begitu melihat README yang keren dan parameter command line yang meyakinkan, saya langsung curiga README itu sedang berhalusinasi dan sebenarnya mungkin tidak ada opsi sama sekali.

  • Saya penulisnya. Beberapa bagian inti proyek ini, misalnya async-ebpf, ditulis jauh sebelum agen coding semacam itu muncul.
    Saat membuat zeroserve sendiri saya memang banyak memakai bantuan AI, tetapi output AI saya periksa sendiri dan tanggung jawabnya juga saya yang menanggung.
  • Kalau melihat benchmark-nya, pada file statis kecil 174B, zeroserve mencatat 36.681 req/s dan p99 5,4ms, nginx 31.226 req/s dan p99 7,8ms, Caddy 12.830 req/s dan p99 22ms.
    Artinya, pada satu core zeroserve melayani file kecil sekitar 17% lebih cepat daripada nginx dan tail latency-nya juga lebih sempit. Hal yang cocok untuk zeroserve adalah halaman HTML, JSON kecil, dan CSS.
    Pada file statis besar 100KB, zeroserve mencatat 8.000 req/s, 782 MB/s, p99 22ms; nginx 7.600 req/s, 773 MB/s, p99 28ms; dan Caddy 6.084 req/s, 590 MB/s, p99 44ms.
    Meski begitu, saya tetap akan memilih proyek lama yang sudah diaudit, terbukti di produksi, dan diperkuat, dibanding proyek baru seperti ini. Peningkatannya tidak cukup besar untuk menanggung risikonya.
  • Ini benar-benar situasi yang menyedihkan. Baru-baru ini ada proyek ffmpeg-wasm; saya mencobanya dan memang berjalan. Tapi itu vibe coding AI, dan saya tidak tahan dengan AI. Tetap sama walaupun berfungsi.
    Saya memutuskan untuk tetap tinggal sejauh mungkin di zaman lama. Orang-orang pintar merilis perangkat lunak, dan orang-orang pintar memeliharanya. Mereka tidak butuh AI. Itu ceruk saya.
    Mungkin kami akan menghilang, tapi saya tetap lebih memilih itu. Hanya saja, ada syarat bahwa orang-orang pintar itu menulis dokumentasi. Ada juga banyak orang pintar yang benci menulis dokumentasi.
    Sudah lama saya memutuskan bahwa perangkat lunak tanpa dokumentasi, sehebat apa pun, tidak layak menghabiskan waktu saya. Ini terutama soal aplikasi; saya sendiri hampir tidak pernah melihat dokumentasi Linux, meski orang lain bilang tidak terlalu buruk, jadi saya juga tidak tahu.

• Konsep baru yang menarik, dan saya suka.
  Pertanyaan sesungguhnya adalah dedikasi pengembang dan komunitas. Orang-orang di Caddy dan Nginx sudah lama konsisten mendukung produknya, dan proyek ini juga akan membutuhkan banyak fokus dan perhatian.

• Kenapa tarball?

  • Ini format sederhana yang memudahkan akses resource berdasarkan rentang byte, semua orang punya alatnya, dan yang paling penting, format ini tidak dikompresi.
  • Menurut paragraf pertama di bagian “One tarball, served in place”, seluruh situs adalah satu file tar, dan zeroserve mengindeksnya saat dimuat untuk membuat peta rentang byte dari path, lalu melayani file dengan melakukan pembacaan rentang byte langsung terhadap tarball itu sendiri.
    Tidak ada apa pun yang diekstrak ke disk. Karena seluruh situs sepenuhnya berada di satu file itu, tidak ada document root yang bisa terekspos akibat aturan location yang salah, dan deployment juga cukup menjadi satu penggantian file atomik.
    Meski begitu, penjelasan itu pun bisa saja sekadar pembenaran ala LLM. Di seluruh tulisan ada ungkapan seperti “the right shape” atau “the surface is broad” yang tersebar.