Telusuri request dari browser

Pertanyaan

Apa yang terjadi antara user menekan Enter dan halaman muncul, dan di tahap mana waktu serta kegagalan bisa muncul?

Setelah baca ini, kamu bisa nulis linimasa satu request dari browser, ngasih angka kasar buat tiap tahap, dan nyebut tahap mana yang hilang kalau koneksinya dipakai ulang.

Prasyarat dan contoh

Kamu sudah bisa nerjemahin beban kerja jadi request per detik dan nulis target latensi yang ada angkanya (M01.02 sampai M01.04).

User di Surabaya buka https://toko.example/produk/42 lewat 4G. Backend-nya di Jakarta, RTT (round trip time) sekitar 25 ms. Aplikasi butuh 40 ms buat bikin respons. Kalau target p95 kamu 300 ms, pertanyaannya bukan "aplikasinya cukup cepat nggak?" tapi "berapa kali paket harus bolak-balik sebelum 40 ms itu mulai kepakai?"

Mekanisme

Urutannya untuk koneksi baru ke HTTPS:

1. DNS        browser → resolver → (root/TLD/authoritative) → alamat IP
2. TCP        SYN → SYN-ACK → ACK                      1 RTT
3. TLS 1.3    ClientHello → ServerHello + Finished     1 RTT
4. HTTP       request → (aplikasi bekerja) → respons   1 RTT + waktu server

DNS. Browser cek cache sendiri, lalu cache OS, lalu tanya resolver (biasanya milik ISP atau 8.8.8.8). Kalau resolver belum punya jawaban, dia nanya server root, TLD, lalu authoritative. Cache miss bisa makan 20 sampai 120 ms; cache hit hampir 0. Lama cache ditentuin TTL record DNS. TTL 60 detik bikin perpindahan IP cepat tapi cache miss lebih sering. TTL 1 jam sebaliknya.

TCP. Three-way handshake butuh 1 RTT sebelum data aplikasi boleh dikirim. Di RTT 25 ms, itu 25 ms yang nggak ngerjain apa-apa buat user.

TLS. TLS 1.3 nambah 1 RTT. TLS 1.2 butuh 2 RTT. Session resumption bisa ngurangin biaya ini buat koneksi ulang ke server yang sama. Selain RTT, ada kerja CPU buat verifikasi sertifikat dan key exchange, tapi biasanya kecil dibanding RTT di jaringan mobile.

HTTP. Request dikirim, server bekerja, respons balik. Waktu yang diamati user adalah 1 RTT ditambah waktu server. Di HTTP/1.1 satu koneksi ngelayani satu request pada satu waktu. HTTP/2 multiplex banyak request di satu koneksi TCP. HTTP/3 jalan di atas QUIC (UDP) dengan handshake transport dan TLS yang digabung.

Koneksi baru vs dipakai ulang. Penjumlahan buat contoh tadi, koneksi baru, DNS miss:

| Tahap | Waktu | | ------------------------- | -------- | | DNS (miss) | 60 ms | | TCP handshake | 25 ms | | TLS 1.3 handshake | 25 ms | | Request + respons (RTT) | 25 ms | | Waktu aplikasi | 40 ms | | Total sampai byte awal | 175 ms |

Kalau koneksi sudah ada (keep-alive) dan DNS ke-cache, tinggal 25 + 40 = 65 ms. Selisih 110 ms itu murni biaya bikin koneksi, bukan kerja aplikasi.

Respons dan sesudahnya. Setelah byte pertama datang, masih ada waktu download body, parsing HTML, dan request tambahan buat CSS, JS, gambar. Halaman dengan 30 aset dari tiga domain berarti beberapa DNS lookup dan koneksi baru lagi. Pembahasan ini fokus ke request API/HTML, bukan rendering browser.

Titik gagal per tahap. DNS: resolver timeout atau record salah. TCP: SYN ke port tertutup (ditolak cepat) atau di-drop firewall (timeout lama). TLS: sertifikat kedaluwarsa atau nama nggak cocok. HTTP: 5xx dari aplikasi atau timeout di proxy. Tiap tahap punya timeout dan pesan error sendiri, jadi "nggak bisa dibuka" harus dilacak per tahap.

Saat rancangan ini gagal

• Cuma ngukur di server. Latensi di log aplikasi 40 ms, user ngeluh 3 detik. Selisihnya ada di DNS, handshake, jaringan mobile, atau antrean sebelum aplikasi.
• Koneksi dibuat per request. Klien backend yang nggak pakai keep-alive nambah 2 RTT (TCP + TLS) di tiap pemanggilan. Antar-service dengan RTT 1 ms nggak kerasa, antar-region dengan RTT 80 ms jadi 160 ms ekstra.
• TTL DNS terlalu panjang saat failover. Kamu pindahin IP, tapi resolver masih nyimpen IP lama selama TTL. Sebagian user tetap diarahkan ke server mati.
• Anggap RTT konstan. RTT mobile berfluktuasi dan paket bisa hilang. Satu paket SYN yang hilang biasanya baru dikirim ulang setelah 1 detik di banyak implementasi, jadi tail latency punya komponen jaringan yang nggak bisa dibenerin dari kode.

Contoh tandingan: optimasi handshake nggak berguna kalau aplikasinya 2 detik. Hitung dulu tahap mana yang dominan sebelum milih HTTP/3 atau nambah CDN.

Latihan

User di Medan ke server di Jakarta, RTT 40 ms. Aplikasi 80 ms. DNS miss 50 ms. TLS 1.3. Hitung waktu sampai respons lengkap (abaikan waktu transfer body) buat dua kasus: (a) koneksi baru, DNS miss, dan (b) koneksi dipakai ulang, DNS cache hit. Tahap apa yang paling gampang dihilangkan buat pengguna yang sering balik?

Lihat pembahasan+

(a) DNS 50 + TCP 40 + TLS 40 + HTTP 40 (RTT) + aplikasi 80 = 250 ms.

(b) Tinggal HTTP 40 + aplikasi 80 = 120 ms.

Selisih 130 ms berasal dari DNS dan dua handshake. Buat pengguna yang sering balik, yang bisa dihilangkan: DNS lewat cache (dan TTL yang wajar), serta TCP dan TLS lewat keep-alive atau session resumption. Aplikasi 80 ms tetap sama di dua kasus, jadi optimasi kode cuma ngurangin sebagian kecil dari kasus (a).

Jawaban yang bagus juga nyebut batasan: angka di atas nggak masukin transfer body, packet loss, atau rendering, dan kasus (a) bakal lebih parah di TLS 1.2 (tambah 1 RTT = 290 ms).

Terkait

• M01.03 Tentukan sasaran yang berguna soal target p95 yang dibandingin sama linimasa ini.
• M02.02 Pilih transport bahas kenapa HTTP/3 dan gRPC mengubah sebagian tahap di atas.
• M02.06 Jelaskan tail latency nerusin pecahan komponen latensi.
• Lab L02 nunjukin linimasa ini secara interaktif. Belum tersedia.

Catatan

• Asumsi: TLS 1.3, TCP biasa, satu server tujuan, tanpa CDN atau proxy di tengah.
• Angka DNS dan RTT adalah contoh realistis, bukan hasil pengukuran. Ukur di jaringan kamu sendiri.
• Yang nggak dibahas: rendering browser, HSTS preload, TCP Fast Open, dan 0-RTT TLS.
• Terakhir ditinjau: 26 Oktober 2026.