Menekan Enter setelah mengetik alamat website dapat menghasilkan halaman, pesan kesalahan sertifikat, atau penantian tanpa akhir. Ketiganya terlihat di tempat yang sama, tetapi masalahnya bisa berada pada bagian sistem yang berbeda.
Saya ingin menelusuri perjalanan itu dari alamat sampai tampilan. Contohnya adalah navigasi ke
https://www.example.com/artikel?halaman=2#ringkasan. Kita mulai dari koneksi baru melalui HTTP/1.1 atau HTTP/2, lalu melihat mengapa cache, pemakaian ulang koneksi, dan HTTP/3 membuat alurnya tidak selalu sama.Peta singkat
Bagian | Perannya dalam membuka halaman |
URL | Menentukan skema, host, path, query, dan fragment. |
DNS | Mencari informasi alamat untuk nama host. |
Koneksi | Menyediakan jalur komunikasi ke layanan tujuan. |
TLS | Melindungi komunikasi dan memungkinkan verifikasi identitas layanan. |
HTTP | Membawa permintaan resource dan responsnya. |
Browser | Memproses HTML, mengambil resource pendukung, dan menyusun tampilan. |
1. Browser membaca bagian-bagian URL
Pada contoh tadi,
https adalah skema, www.example.com adalah host, /artikel adalah path, halaman=2 adalah query, dan ringkasan adalah fragment. Struktur komponen URI dijelaskan dalam RFC 3986.Bagian-bagian ini mempunyai tugas berbeda. Nama host digunakan untuk menentukan tujuan, sementara path dan query mengidentifikasi resource yang diminta. Fragment dipisahkan sebelum pengambilan resource; pada dokumen HTML, browser dapat menggunakannya untuk menuju elemen tertentu.
Dengan demikian, DNS tidak menerima seluruh URL. Resolver tidak perlu mengetahui bahwa kita meminta halaman kedua atau ingin menuju bagian ringkasan.
Pemisahan ini juga berguna saat membaca log. Fragment tidak menjadi bagian dari target permintaan HTTP awal, meskipun kode JavaScript di halaman dapat membacanya dan mengirimkannya melalui permintaan lain.
2. DNS mencari informasi alamat host
DNS adalah sistem penamaan terdistribusi. Aplikasi meminta bantuan resolver untuk memperoleh informasi yang diperlukan bagi nama host; hasil yang sudah tersimpan dapat digunakan kembali. RFC 1034 menjelaskan resolver, name server, dan caching.
Jika informasi belum tersedia, resolver dapat mengikuti rujukan menuju server yang mengetahui jawabannya. Untuk nama dalam contoh, prosesnya dapat melibatkan root, pengelola zona
.com, dan server otoritatif bagi example.com. Namun, bukan berarti setiap navigasi selalu mengulang seluruh perjalanan itu.Record mempunyai time to live (TTL) yang membatasi berapa lama hasilnya dapat disimpan dalam cache. Karena itu, perubahan DNS tidak selalu langsung terlihat oleh semua pemakai.
Hasil resolusi juga bukan jaminan aplikasi sehat. Mengetahui alamat tujuan baru menyelesaikan persoalan penamaan; koneksi dan layanan di alamat tersebut masih harus bekerja.
3. Koneksi dibuka atau dipakai kembali
Untuk alur HTTP/1.1 atau HTTP/2 melalui HTTPS, browser membutuhkan koneksi TCP ke tujuan. Jika port tidak ditulis, skema HTTPS menggunakan port default 443 (RFC 7230, bagian 2.7.2).
Pada pembentukan koneksi TCP yang umum, client mengirim SYN, server membalas SYN-ACK, dan client mengirim ACK. Pertukaran ini dikenal sebagai three-way handshake. TCP menyediakan aliran byte yang andal dan berurutan; fondasinya dijelaskan dalam RFC 793.
Koneksi baru tidak diperlukan untuk setiap resource. HTTP/1.1 mendukung koneksi persisten, sehingga beberapa pertukaran dapat memakai koneksi yang sama. RFC 7230 bagian 6 menjelaskan pengelolaan koneksinya.
Ada pengecualian penting pada gambaran TCP ini: HTTP/3 menggunakan QUIC, dengan paket yang dibawa melalui UDP. QUIC sudah distandarkan dalam RFC 9000, sedangkan spesifikasi HTTP/3 sudah disetujui IETF dan sedang menunggu terbit sebagai RFC. Jadi, urutan TCP lalu TLS bukan penjelasan universal untuk semua versi HTTP.
4. TLS membangun komunikasi yang terlindungi
Pada koneksi HTTPS berbasis TCP, tahap berikutnya adalah TLS. Dalam TLS 1.3, handshake menegosiasikan parameter keamanan dan membentuk kunci untuk melindungi pertukaran data. Mekanismenya dijelaskan dalam RFC 8446.
Untuk autentikasi berbasis sertifikat, client perlu memvalidasi sertifikat dan identitas layanan yang dituju. Nama host yang diminta harus sesuai dengan identitas yang diizinkan sertifikat. RFC 6125 membahas verifikasi identitas layanan tersebut.
Misalnya, koneksi berhasil mencapai sebuah server, tetapi server memberikan sertifikat untuk nama lain. Keberhasilan TCP tidak menghapus masalah identitas itu.
Saya memisahkan perlindungan koneksi dari keamanan aplikasi. TLS membantu menjaga kerahasiaan dan integritas komunikasi dengan pihak yang diautentikasi; TLS tidak memeriksa apakah logika aplikasi benar atau apakah isi halaman dapat dipercaya.
5. Browser mengirim permintaan HTTP
Setelah jalur komunikasi tersedia, browser dapat meminta resource. Berikut gambaran sederhana pesan HTTP/1.1 untuk contoh URL tadi, mengikuti sintaks RFC 7230:
GET /artikel?halaman=2 HTTP/1.1
Host: www.example.com
Accept: text/html
Ini contoh minimal untuk membaca strukturnya. Browser dapat menambahkan header lain. HTTP/2 dan HTTP/3 membawa semantik permintaan yang sama melalui format pesan yang berbeda.
Tujuan yang menerima permintaan juga tidak selalu proses aplikasi langsung. RFC 7230 bagian 2.3 menjelaskan perantara seperti proxy dan gateway. Dalam sebuah arsitektur, perantara dapat meneruskan permintaan ke layanan lain.
Server mengembalikan status, header, dan konten bila responsnya mempunyai konten. Contohnya,
200 OK menyatakan permintaan berhasil, 404 Not Found menyatakan resource tidak ditemukan, dan 301 Moved Permanently dapat mengarahkan client ke URI lain.Respons redirect belum merupakan dokumen akhir yang ingin ditampilkan. Jika diikuti, browser melakukan navigasi lanjutan; pergantian host dapat memerlukan resolusi dan koneksi ke tujuan berbeda.
6. HTML mulai menjadi halaman
Menerima HTML belum sama dengan selesai menampilkan halaman. Browser memproses markup menjadi struktur dokumen, lalu menangani resource yang dirujuknya, seperti stylesheet, gambar, dan script. Parsing serta perilaku elemen-elemen itu didokumentasikan dalam HTML Living Standard.
CSS menentukan bagaimana elemen membentuk kotak dan ditempatkan dalam tampilan. Model pemformatan visual CSS 2.1 menjelaskan dasar tata letak tersebut.
JavaScript dapat mengubah dokumen dan memicu permintaan tambahan. Cara script dimuat juga memengaruhi parsing; script biasa,
defer, dan async tidak mempunyai aturan eksekusi yang sama.Karena itu, HTML yang berhasil diterima tidak membuktikan seluruh halaman bekerja. Misalnya, judul artikel dapat terlihat sementara gambarnya gagal dimuat. Saya akan memeriksa permintaan gambar itu secara terpisah, bukan langsung menyimpulkan permintaan dokumen utama gagal.
7. Cache dapat memperpendek perjalanan
Ada dua cache yang perlu dibedakan dalam pembahasan ini: cache DNS menyimpan informasi penamaan, sedangkan cache HTTP menyimpan respons. Keduanya menjawab kebutuhan berbeda.
Menurut RFC 7234, respons yang masih fresh dapat digunakan kembali sesuai aturan cache. Untuk respons yang perlu divalidasi, client dapat mengirim permintaan bersyarat. Respons
304 Not Modified (RFC 7232) memungkinkan penggunaan representasi yang sudah tersimpan.Jadi, membuka halaman tidak selalu berarti mengunduh ulang seluruh isinya. Hasil DNS mungkin tersedia, koneksi mungkin masih terbuka, dan sebagian resource mungkin berasal dari cache.
Saat membandingkan dua pemuatan halaman, saya akan mencatat kondisi itu terlebih dahulu. Kunjungan pertama dan kunjungan ulang dapat melewati pekerjaan yang berbeda, meskipun alamat yang dibuka sama.
Penutup
Untuk mempelajari alurnya, mulai dari satu dokumen HTML sederhana. Bedakan nama host, koneksi, identitas TLS, respons HTTP, dan resource pendukungnya. Setelah itu, amati apa yang berubah ketika halaman dimuat kembali.
Saya memakai pembagian ini sebagai urutan pemeriksaan: apakah nama berhasil diresolusi, koneksi tersedia, identitas layanan valid, respons sesuai, dan dokumen dapat ditampilkan? Setiap jawaban mempersempit bagian yang perlu diperiksa.