Lesson 0002 · System Design · Modul Fondasi · ±20 menit

Perjalanan request: client-server, DNS, HTTP

Apa yang terjadi antara user menekan Enter dan server mulai bekerja, berapa round trip yang dibutuhkan, dan kenapa HTTP stateless penting untuk skala

Target lesson ini: Anda bisa menyusun perjalanan request pertama (DNS → TCP → TLS → HTTP), menghitung berapa round trip yang terjadi sebelum server mulai bekerja, dan menjelaskan kenapa sifat stateless HTTP memungkinkan request dibagi ke banyak server.

Sebelumnya, di lesson 0001: desain v1 adalah client → app server → database. Lesson ini memperbesar panah pertama: apa saja yang terjadi di antara client dan app server.

1. Client, server, dan HTTP yang stateless

HTTP adalah protokol client/server. Client (browser, aplikasi mobile, atau service lain) membuka koneksi dan mengirim request; server menerima koneksi dan mengirim response. Peran ini relatif: program yang sama bisa jadi server untuk satu koneksi dan client untuk koneksi lain, misalnya app server yang menjadi client bagi database. ^[1]

HTTP juga stateless: makna setiap request bisa dipahami sendiri, tanpa bergantung pada request sebelumnya di koneksi yang sama. RFC 9110 menyebut akibatnya langsung: banyak implementasi bergantung pada sifat ini untuk "dynamically load balance requests across multiple servers". ^[1] Simpan kalimat ini. Di lesson 0005 ia menjadi alasan kenapa app server harus stateless supaya bisa ditambah jumlahnya.

2. Empat langkah sebelum server mulai bekerja

DNS: nama → IP→ TCP handshake→ TLS handshake→ HTTP request → response

DNS. Browser hanya tahu nama (shop.example.com), jaringan butuh alamat IP. Resolver adalah program yang mengambil jawaban dari name server atas permintaan client. ^[2] Setiap jawaban DNS membawa TTL (time to live, dalam detik): berapa lama jawaban itu boleh disimpan di cache sebelum dibuang. ^[2] Jadi kebanyakan request tidak benar-benar bertanya ke DNS; jawabannya sudah ada di cache.
TCP handshake. TCP adalah protokol yang menjamin data sampai utuh dan berurutan. Koneksi dibuka dengan three-way handshake ^[3]: client mengirim SYN, server menjawab SYN-ACK, client mengirim ACK. Biayanya satu round trip sebelum data apa pun bisa dikirim.
TLS handshake. TLS adalah lapisan yang mengenkripsi koneksi dan membuktikan bahwa server memang pemilik nama domain itu (lewat sertifikat). Inilah "S" di HTTPS. Di TLS 1.3, handshake penuh butuh satu round trip; RFC 8446 menyebutnya "1-RTT handshake". ^[4]
HTTP request → response. Satu round trip lagi, ditambah waktu server bekerja (query database, dan seterusnya). Di HTTP/1.1 koneksi bersifat persistent secara default: banyak request dan response bisa lewat satu koneksi yang sama, jadi langkah 1–3 tidak diulang. ^[5]

3. Hitung round trip-nya

Round trip time (RTT) adalah waktu paket pergi ke server dan jawabannya kembali. RTT bergantung pada jarak: di dalam satu datacenter sekitar 0,5 ms, sedangkan California → Belanda → California sekitar 150 ms. ^[6]

Request	Round trip sebelum response	User di benua lain (RTT 150 ms)
Pertama (DNS sudah di cache)	TCP 1 + TLS 1 + HTTP 1 = 3 RTT	±450 ms + waktu server
Berikutnya di koneksi yang sama	HTTP 1 = 1 RTT	±150 ms + waktu server

Tiga hal yang bisa langsung disimpulkan, dan semuanya kembali di lesson berikutnya:

Jarak adalah latency yang tidak bisa dioptimasi dengan kode. Server tercepat pun tidak bisa mengalahkan 450 ms kalau user ada di benua lain. Solusinya mendekatkan konten ke user, yaitu CDN (lesson 0007).
Memakai ulang koneksi itu murah dan berdampak besar. Dari 3 RTT menjadi 1 RTT tanpa menambah server. Ini contoh perubahan termurah dari prinsip inti.
TTL DNS adalah trade-off. TTL panjang berarti lebih sedikit lookup, tapi kalau IP server berubah, sebagian user masih memakai IP lama sampai cache mereka kedaluwarsa.

Latihan 1 — Susun perjalanan request pertama

Susun dari user menekan Enter sampai halaman tampil. Ucapkan setiap langkah dengan suara keras saat memindahkannya.

User mengetik https://shop.example.com dan menekan Enter
Browser meminta IP ke resolver DNS (atau memakai jawaban di cache selama TTL)
TCP three-way handshake: SYN → SYN-ACK → ACK
TLS handshake: sertifikat diperiksa, kunci enkripsi disepakati
Browser mengirim HTTP request GET /
Server memproses request (mis. query database) dan mengirim response
Request berikutnya memakai koneksi yang sama tanpa handshake ulang

IP harus diketahui sebelum koneksi dibuka. TCP harus terbuka sebelum TLS bisa berjalan di atasnya, dan TLS harus selesai sebelum HTTP request terenkripsi dikirim. Request pertama membayar 3 RTT (TCP + TLS + HTTP); request berikutnya di koneksi persistent hanya 1 RTT.

Latihan 2 — Round trip dan DNS

Latihan 3 — HTTP stateless

Latihan lisan — Jawab lisan

Pasang timer, jawab dengan suara keras, baru buka jawaban contoh. Soal ini juga ada di bank soal dan bisa ditarik review 0012.

"Apa yang terjadi sejak user mengetik URL dan menekan Enter sampai server menerima request? Fokus ke hal yang memengaruhi latency." (90 detik)

Bandingkan dengan jawaban contoh dan checklist-nya

"Pertama browser butuh IP dari nama domain lewat DNS. Biasanya jawabannya sudah di cache, karena setiap jawaban DNS punya TTL yang menentukan berapa lama boleh disimpan. Lalu browser membuka koneksi TCP dengan three-way handshake, SYN, SYN-ACK, ACK, itu satu round trip. Di atasnya TLS handshake untuk enkripsi dan verifikasi sertifikat server; di TLS 1.3 itu satu round trip lagi. Baru HTTP request dikirim, satu round trip plus waktu server bekerja. Jadi request pertama sekitar 3 RTT. Kalau user di benua lain dengan RTT 150 ms, itu sudah sekitar 450 ms sebelum server berbuat apa-apa. Request berikutnya memakai koneksi persistent, jadi cukup 1 RTT. Dua cara murah menurunkan latency: pakai ulang koneksi, dan dekatkan konten ke user dengan CDN."

Checklist: apakah Anda menyebut…

DNS mengubah nama menjadi IP, dan jawabannya di-cache sesuai TTL?
TCP three-way handshake (SYN, SYN-ACK, ACK) = 1 RTT?
TLS handshake untuk enkripsi dan sertifikat, 1 RTT di TLS 1.3?
request pertama ±3 RTT sebelum response, termasuk HTTP request itu sendiri?
contoh angka: RTT antarbenua ±150 ms membuat request pertama ±450 ms?
koneksi persistent (pakai ulang koneksi) atau CDN sebagai cara murah mengurangi latency?

Lulus kalau minimal 4 dari 6.

Bacaan utama RFC 9110 bagian 3 "Terminology and Core Concepts", terutama 3.3 (client, server, stateless) dan 3.7 (intermediaries). ±10 menit. Opsional, tidak dihitung dalam durasi.

Berikutnya, lesson 0003: Anda sudah melihat angka 0,5 ms dan 150 ms. Angka mana lagi yang perlu dihafal, dan kenapa rata-rata latency bisa menyesatkan?

Ada yang belum jelas? Tanyakan ke agent. Agent adalah guru Anda di track ini.

Istilah: GLOSSARY.md (bagian "Fondasi") · Sumber: RESOURCES.md

Sumber: [1] RFC 9110 HTTP Semantics, §3.3 · [2] RFC 1034 DNS Concepts, §2.4 dan §3.6 · [3] RFC 9293 TCP, §3.5 · [4] RFC 8446 TLS 1.3, §2.3 · [5] RFC 9112 HTTP/1.1, §9.3 · [6] Jeff Dean, LADIS 2009 ("Numbers Everyone Should Know")