Static site — cuma HTML, CSS, dan sedikit JavaScript — seharusnya load instan. Tapi di jaringan mobile Indonesia yang sinyalnya naik-turun, situs statis tetap bisa terasa lambat. Penyebabnya sering bukan ukuran file, melainkan protokolnya: HTTP/2 yang berjalan di atas TCP akan stall total kalau satu paket hilang di tengah handshake, dan kondisi packet loss itu justru umum di koneksi seluler.
Solusinya adalah HTTP/3, yang berjalan di atas QUIC (berbasis UDP, bukan TCP). QUIC menghilangkan head-of-line blocking khas TCP dan membuat koneksi jauh lebih tahan terhadap packet loss — kondisi yang persis terjadi di jaringan mobile Indonesia. Artikel ini tutorial lengkap deploy static site di VPS Ubuntu dengan Nginx yang mendukung HTTP/3/QUIC, dari nol sampai terverifikasi jalan.
Artikel ini disusun berdasarkan dokumentasi resmi Nginx (dukungan QUIC/HTTP/3 tersedia sejak rilis mainline 1.25) dan spesifikasi IETF (RFC 9000 untuk QUIC, RFC 9114 untuk HTTP/3, RFC 7838 untuk mekanisme Alt-Svc). Semua command mengikuti konfigurasi yang diuji pada Ubuntu 24.04 per Juli 2026.
1. Kenapa HTTP/3 dan QUIC Layak Diusahakan
HTTP/3 bukan sekadar "HTTP/2 tapi versi baru" — dia mengganti transport layer dari TCP ke QUIC (UDP). Implikasinya besar untuk pengguna mobile:
- Tidak ada head-of-line blocking — di HTTP/2 (TCP), satu paket hilang menahan semua stream. Di QUIC, stream independen; satu paket hilang tidak mengganggu stream lain.
- Handshake lebih cepat — QUIC menggabungkan handshake transport dan TLS 1.3, sehingga koneksi baru butuh lebih sedikit round-trip. Ada juga 0-RTT resumption untuk koneksi ulang (RFC 9000).
- Connection migration — koneksi QUIC diidentifikasi oleh connection ID, bukan tuple IP+port. Saat user pindah dari WiFi ke data seluler, koneksi tidak putus (RFC 9000, Section 9).
- Lebih tahan packet loss — QUIC tetap responsif saat TCP sudah megap-megap. Ini kondisi khas jaringan mobile Indonesia.
Untuk static site yang mayoritas traffic-nya mobile, manfaat ini nyata — bukan optimasi kosmetik. Riset adopsi industri mencatat HTTP/3 menjadi standar de facto untuk layanan dengan audiens seluler besar mulai 2023-2024, dan browser modern semuanya mendukungnya.
2. HTTP/2 vs HTTP/3: Perbedaan Inti
| Aspek | HTTP/2 (TCP) | HTTP/3 (QUIC/UDP) |
|---|---|---|
| Transport | TCP + TLS 1.2/1.3 | UDP + TLS 1.3 (wajib) |
| Head-of-line blocking | Ada — satu paket hilang menahan semua stream | Tidak ada — stream independen |
| Handshake koneksi baru | 2-3 round-trip (TCP + TLS) | 1 round-trip, 0-RTT untuk koneksi ulang |
| Saat pindah jaringan | Koneksi putus, harus handshake ulang | Connection migration — tidak putus |
| Port | TCP 443 | UDP 443 |
| Perilaku saat packet loss | Seluruh koneksi melambat | Hanya stream yang kena dampak |
Konteks penting: HTTP/3 tidak membuat file lebih kecil atau server lebih cepat memproses. Manfaatnya muncul di lapisan koneksi — terutama di jaringan dengan latensi tinggi dan packet loss, persis profil jaringan mobile Indonesia.
3. Prasyarat
Yang dibutuhkan:
- VPS Ubuntu 22.04 atau 24.04 dengan akses root/sudo. VPS kecil 1 vCPU/1GB RAM sudah lebih dari cukup untuk static site.
- Domain yang sudah diarahkan (A record) ke IP VPS.
- Nginx mainline 1.25+ — repo default Ubuntu (1.24) belum mendukung QUIC native, jadi wajib pakai repo resmi Nginx.
Kalau belum punya VPS, layanan managed VPS murah seperti RackNerd punya paket mulai ~$10/tahun dengan 1 vCPU dan 1GB RAM — cukup untuk static site plus sertifikat TLS gratis. Untuk pengamanan dasar sebelum production, pastikan membaca panduan firewall Ubuntu lengkap (UFW + Fail2Ban) agar port yang dibuka tidak dibiarkan telanjang.
4. Install Nginx Mainline dengan QUIC
Ubuntu 24.04 repo bawaan punya Nginx 1.24 yang belum mendukung QUIC native. Nginx mainline dari repo resmi sudah menyertakan modul HTTP/3 sejak rilis 1.25.0. Tambahkan repo Nginx:
curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/ubuntu noble nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt update
sudo apt install -y nginx
Verifikasi versi dan dukungan modul HTTP/3:
nginx -v
nginx -V 2>&1 | grep -o with-http_v3_module
Kalau output terakhir menampilkan with-http_v3_module, instalasi siap. Nginx dari repo mainline resmi dikompilasi dengan modul ngx_http_v3_module bawaan. Catatan dari dokumentasi resmi: dukungan QUIC/HTTP/3 di Nginx tersedia sejak 1.25, dan statusnya ditandai eksperimental — untuk production tetap aman digunakan dengan fallback TCP yang selalu aktif.
5. Setup Static Site Dasar
Buat direktori untuk file situs dan taruh konten di sana:
sudo mkdir -p /var/www/mysite
echo "<h1>Halo dari HTTP/3</h1>" | sudo tee /var/www/mysite/index.html
sudo chown -R www-data:www-data /var/www/mysite
Untuk static site generator seperti Astro, Hugo, atau Eleventy, copy hasil build (folder dist atau public) ke /var/www/mysite. Pola yang umum dipakai: build di mesin lokal, lalu rsync hasilnya ke VPS — sederhana dan idempotent.
6. Dapatkan Sertifikat TLS dengan Certbot
HTTP/3 wajib memakai TLS 1.3 — QUIC tidak mendukung plaintext. Jadi sertifikat TLS adalah prasyarat mutlak. Pakai Let's Encrypt via certbot:
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d mysite.com -d www.mysite.com
Certbot otomatis mengedit konfigurasi Nginx untuk SSL. Pendekatan certbot + Let's Encrypt ini sama dengan yang didetailkan di panduan TLS Let's Encrypt self-hosted — bedanya di sini lapisan QUIC ditambahkan di atasnya.
7. Konfigurasi Nginx untuk HTTP/3 (QUIC)
Ini inti tutorialnya. Edit server block (/etc/nginx/conf.d/mysite.conf atau yang dibuat certbot). Konfigurasi lengkap dengan strategi dual listener:
server {
listen 80;
listen [::]:80;
server_name mysite.com www.mysite.com;
return 301 https://mysite.com$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name mysite.com www.mysite.com;
ssl_certificate /etc/letsencrypt/live/mysite.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
root /var/www/mysite;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
# HTTP/3 / QUIC listener (UDP 443)
server {
listen 443 quic reuseport;
listen [::]:443 quic reuseport;
http3 on;
server_name mysite.com www.mysite.com;
ssl_certificate /etc/letsencrypt/live/mysite.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite.com/privkey.pem;
ssl_protocols TLSv1.3;
root /var/www/mysite;
index index.html;
# Beri tahu browser bahwa HTTP/3 tersedia di port 443
add_header Alt-Svc 'h3=":443"; ma=86400' always;
location / {
try_files $uri $uri/ =404;
}
}
Poin penting dari konfigurasi ini:
listen 443 quic reuseport— mengaktifkan QUIC di port 443. Flagreuseportpenting untuk performa multi-worker dan cukup ditaruh di satu server block quic.http3 on;— direktif resmi modulngx_http_v3_moduleuntuk mengaktifkan HTTP/3 di server block ini.- Header
Alt-Svc— ini krusial (RFC 7838). Browser tidak akan memakai HTTP/3 kecuali server mengiklankannya via header ini. Header-nya bilang "hei browser, server ini support h3 di port 443". - TLSv1.3 di block QUIC — QUIC mensyaratkan TLS 1.3 (RFC 9001), jadi server block quic cukup dengan TLSv1.3.
Strategi dual listener (TCP untuk HTTP/1.1+HTTP/2, UDP untuk HTTP/3) adalah pendekatan yang direkomendasikan. Browser akan otomatis fallback ke TCP kalau QUIC diblokir — misalnya jaringan korporat atau firewall yang memblokir UDP 443.
8. Buka Port UDP 443 di Firewall
Ini langkah yang paling sering membuat orang bingung "kok HTTP/3 tidak jalan". QUIC memakai UDP port 443, bukan TCP. Kalau firewall hanya membuka TCP 443, HTTP/3 tidak akan pernah connect.
sudo ufw allow 443/tcp
sudo ufw allow 443/udp
sudo ufw reload
sudo ufw status
Pastikan di output ufw status ada kedua baris: 443/tcp ALLOW dan 443/udp ALLOW. Kalau memakai cloud provider dengan security group tambahan (AWS, GCP, atau VPS panel), buka juga UDP 443 di sana. Untuk strategi firewall production yang lebih menyeluruh — termasuk Fail2Ban dan rate limiting — ikuti panduan firewall Ubuntu lengkap.
9. Test dan Reload Nginx
Sebelum reload, selalu test konfigurasi:
sudo nginx -t
sudo systemctl reload nginx
Kalau nginx -t mengembalikan syntax is ok dan test is successful, reload aman dilakukan. Reload (bukan restart) membuat koneksi yang sedang berjalan tidak terputus.
10. Verifikasi HTTP/3 Benar-Benar Jalan
Jangan hanya percaya konfigurasi — verifikasi dari dua arah: dari server (curl) dan dari perspektif eksternal (browser / tool online).
# Cek header Alt-Svc (pakai curl dengan HTTP/2)
curl -sI https://mysite.com | grep -i alt-svc
# Test QUIC langsung (butuh curl dengan dukungan HTTP/3)
curl --http3 -I https://mysite.com
Verifikasi paling meyakinkan: buka situs di Chrome/Firefox, buka DevTools → Network tab, dan lihat kolom Protocol. Kalau situs diakses via HTTP/3, kolom itu menampilkan h3. Load pertama mungkin masih h2 (browser perlu melihat header Alt-Svc dulu), tapi refresh kedua biasanya sudah h3.
Tool online seperti http3check.net atau cdn77 http3 test bisa dipakai untuk verifikasi dari perspektif eksternal. Kesimpulan "HTTP/3 aktif" sebaiknya hanya diambil setelah verifikasi dari dua arah tersebut.
11. Optimasi Tambahan untuk Static Site
Setelah HTTP/3 jalan, optimasi tambahan yang umum diterapkan pada static site:
# Di dalam server block, tambah:
gzip on;
gzip_types text/css application/javascript image/svg+xml application/json;
gzip_min_length 1024;
# Cache untuk aset statis
location ~* \.(css|js|jpg|jpeg|png|webp|svg|woff2)$ {
expires 30d;
add_header Cache-Control "public, immutable";
}
# Security headers
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options DENY always;
add_header Referrer-Policy strict-origin-when-cross-origin always;
Perhatian: add_header di level location menimpa header di level server — termasuk Alt-Svc. Jadi kalau menambah add_header di location tertentu, pastikan Alt-Svc tetap ikut terkirim (pakai always dan sertakan di location yang relevan). Ini bug halus yang sering membuat Alt-Svc hilang dan HTTP/3 berhenti diiklankan.
Untuk memastikan situs tetap up setelah semua perubahan, pasang monitoring. Status page self-hosted dengan Uptime Kuma + Grafana bisa nge-ping situs tiap menit dan alert saat down — murah, self-hosted, dan tanpa biaya langganan.
12. Troubleshooting Umum
- HTTP/3 tidak pernah connect — 90% kasus karena UDP 443 belum dibuka di firewall/security group. Cek
ufw statusdan panel cloud provider. - Browser tetap pakai h2 — header Alt-Svc tidak terkirim. Cek dengan
curl -sI. Biasanya karenaadd_headerdi location menimpa Alt-Svc. nginx -terror "unknown directive http3" — versi Nginx terlalu lama. Pastikan memakai mainline 1.25+ dari repo resmi, bukan repo Ubuntu.- Warning
reuseport— flagreuseporthanya boleh ada di satu server block quic. Taruh di satu tempat saja. - curl tidak mengenal
--http3— curl versi lama. Di Ubuntu 24.04 pakaisudo apt install -y curldari repo update, atau kompilasi curl dengan flag HTTP/3.
13. Kapan HTTP/3 Belum Perlu Jadi Prioritas
Jujur saja: HTTP/3 bukan obat untuk semua masalah performa. Kalau situs lambat karena gambar tidak dikompresi, JavaScript membengkak, atau server under-spec, mengaktifkan QUIC tidak akan banyak membantu. Bereskan dulu fundamental performa — optimasi gambar ke WebP, lazy-load aset, minify CSS/JS, dan pastikan TTFB server rendah. HTTP/3 adalah lapisan penyempurna di atas fondasi yang sudah sehat, bukan pengganti fondasi.
Untuk situs dengan mayoritas user desktop di jaringan stabil, manfaat HTTP/3 lebih kecil dibanding untuk user mobile di jaringan tidak stabil. Tapi karena setup-nya sekarang mudah dan tidak ada downside berarti (ada fallback TCP otomatis), mengaktifkannya tetap worthwhile sebagai future-proofing — investasi murah yang membuat situs siap saat adopsi HTTP/3 semakin meluas.
FAQ Seputar HTTP/3 dan QUIC
Q: Apakah HTTP/3 wajib pakai TLS?
A: Ya. QUIC mengintegrasikan TLS 1.3 di dalam protokolnya (RFC 9001), dan tidak ada mode plaintext untuk HTTP/3. Sertifikat Let's Encrypt gratis via certbot sudah cukup.
Q: Apakah browser atau user lama tetap bisa akses situs?
A: Tentu. Strategi dual listener membuat server tetap melayani HTTP/1.1 dan HTTP/2 via TCP. Browser yang tidak mendukung HTTP/3 atau jaringan yang memblokir UDP 443 otomatis fallback ke TCP.
Q: Apakah Nginx dari repo Ubuntu mendukung QUIC?
A: Tidak. Repo Ubuntu 24.04 menyediakan Nginx 1.24 yang belum memiliki modul HTTP/3. Wajib install mainline 1.25+ dari repo resmi nginx.org.
Q: Berapa pengurangan latency yang realistis?
A: Untuk koneksi baru, handshake turun dari 2-3 RTT menjadi 1 RTT (0-RTT untuk koneksi ulang). Di jaringan stabil manfaatnya kecil; di jaringan dengan packet loss tinggi manfaatnya paling terasa karena tidak ada head-of-line blocking.
Q: Apakah QUIC lebih aman daripada TCP?
A: QUIC mewajibkan TLS 1.3 (versi TLS tertinggi), sementara TCP bisa berjalan dengan TLS 1.2 atau tanpa TLS sama sekali. Dari sisi enkripsi, HTTP/3 sebenarnya lebih ketat standarnya.
Kesimpulan
Deploy static site dengan HTTP/3/QUIC di Nginx tidak sesulit yang dibayangkan — sejak Nginx mainline mendukung QUIC native, tidak perlu lagi patch pihak ketiga. Tiga hal yang sering terlewat: pakai Nginx mainline 1.25+, buka UDP 443 di firewall, dan pastikan header Alt-Svc terkirim. Setelah itu, situs mendapat manfaat koneksi yang lebih cepat dan tahan packet loss — sangat relevan untuk mayoritas user mobile Indonesia.
Mulai dari dual listener (TCP + QUIC) supaya ada fallback, verifikasi dari browser dan curl sebelum menyimpulkan sukses, dan tambah optimasi caching + security headers. Dengan setup ini, static site tidak cuma cepat, tapi juga modern dan siap untuk masa depan web. Kalau butuh VPS murah untuk mencoba setup ini, RackNerd menawarkan paket entry-level yang cukup untuk eksperimen ini.
Sumber dan Validasi
- Nginx: Support for QUIC and HTTP/3 (dokumentasi resmi)
- Nginx: Module ngx_http_v3_module (dokumentasi direktif)
- RFC 9000: QUIC — A UDP-Based Multiplexed and Secure Transport (IETF, 2021)
- RFC 9114: HTTP/3 (IETF, 2022)
- RFC 7838: HTTP Alternative Services / Alt-Svc (IETF, 2016)
Catatan: Artikel ini disusun berdasarkan dokumentasi resmi Nginx dan spesifikasi IETF yang dirujuk di atas. Perintah dan konfigurasi mengikuti perilaku Nginx mainline 1.25+ pada Ubuntu 24.04. Ukuran manfaat HTTP/3 bersifat kontekstual — paling terasa pada jaringan dengan latensi tinggi dan packet loss, dan paling kecil pada jaringan stabil berlatensi rendah.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬