Cara Kerja Web Server: Dari URL di Browser sampai Halaman Muncul di Layar

Kamu mengetik sebuah alamat di browser, menekan Enter, dan sepersekian detik kemudian satu halaman penuh sudah terpampang di depanmu. Rasanya instan dan tanpa usaha — justru itulah kenapa hampir tidak ada yang berhenti sejenak untuk bertanya, sebenarnya apa yang terjadi di sela-selanya. Padahal di balik momen singkat itu ada banyak sekali kerja yang tertata rapi, dan sebagian besar dikerjakan oleh satu potong perangkat lunak: web server.

Di artikel ini kita bakal memperlambat semuanya dan menontonnya bingkai demi bingkai. Bukan versi gampangan “browser ngobrol sama server”, tapi urutan langkah sebenarnya yang dilakukan web server, dari detik sebuah permintaan tiba di depan pintunya sampai detik dia mengirim balasan. Begitu kamu bisa membayangkan putaran itu dengan jelas, banyak istilah yang selama ini cuma lewat di telinga — port, request, header, status code — berhenti jadi jargon dan mulai jadi bagian dari sebuah mesin yang kamu pahami.

Sebenarnya web server kerja apa seharian

Sebelum masuk ke langkah-langkahnya, ada baiknya kamu tahu satu tugas utama web server. Web server adalah program yang diam menunggu permintaan lewat jaringan, lalu menjawabnya dengan konten web — halaman HTML, gambar, stylesheet, data JSON, apa pun yang diminta. Cuma itu. Dia tidak mencari-cari kerjaan; dia bereaksi. Permintaan masuk, server menjawab, lalu dia kembali menunggu yang berikutnya.

Perilaku “diam dan menunggu” inilah kunci dari segalanya. Web server adalah proses yang berjalan terus-menerus — dia dinyalakan sekali lalu tetap hidup berhari-hari atau berminggu-minggu, selalu mendengarkan, selalu siap. Ini beda dengan skrip yang kamu jalankan sekali lalu langsung berhenti begitu selesai. Kalau program web server-nya mati, situs kamu ikut tumbang, karena tidak ada lagi yang membukakan pintu.

Persiapan: mendengarkan di sebuah port

Web server tidak bisa menjawab permintaan yang tidak pernah dia dengar, jadi hal pertama yang dia lakukan saat dinyalakan adalah mengikat diri ke sebuah port lalu mulai mendengarkan. Port itu pintu bernomor pada sebuah mesin — bayangkan mesinnya sebagai gedung apartemen dengan satu alamat jalan (IP-nya) dan banyak pintu bernomor. Lalu lintas web umumnya memakai dua di antaranya: port 80 untuk HTTP biasa dan port 443 untuk HTTPS yang terenkripsi.

Ketika server “mendengarkan di port 443”, dia sedang berkata pada sistem operasi: permintaan apa pun yang tiba di mesin ini menuju pintu 443, serahkan ke saya. Sejak saat itu, server terdaftar di OS sebagai program yang bertanggung jawab atas pintu tersebut, dan dia memarkir dirinya dalam sebuah putaran, menunggu.

   MESINNYA (satu alamat IP)
   ┌─────────────────────────────────────┐
   │  port 22  → SSH                      │
   │  port 80  → web server (HTTP)        │
   │  port 443 → web server (HTTPS) ◄──── mendengarkan di sini
   │  port 5432 → database                │
   └─────────────────────────────────────┘

Kalau port dan alamat IP masih terasa samar, artikel sebelumnya tentang alamat IP dan port mengupasnya dengan tuntas. Untuk sekarang, cukup pegang gambaran ini: server adalah program yang berdiri di satu pintu tertentu, menunggu seseorang mengetuk.

Langkah demi langkah: satu permintaan, dari awal sampai akhir

Nah, ini bagian serunya. Mari kita ikuti satu permintaan saat dia melintasi server. Bayangkan browser seorang pengunjung ingin membuka halaman utama ACY Partner Indonesia. Berikut semua yang terjadi, sesuai urutannya.

1. Koneksi tiba

Browser sudah lebih dulu mencari tahu mesin mana yang harus diajak bicara (itu proses pencarian nama domain, yang terjadi bahkan sebelum server terlibat — lihat domain dan DNS kalau penasaran). Sekarang dia membuka koneksi jaringan ke mesin itu di port 443 dan mengirim permintaannya menyeberang.

Sistem operasi menerima koneksi yang masuk dan, karena tadi web server sudah mendaftarkan dirinya untuk port 443, langsung menyerahkannya. Penantian panjang server pun berakhir — dia kedatangan pelanggan.

2. Permintaan dibaca dan dipilah

Yang sebenarnya tiba hanyalah teks, disusun mengikuti aturan HTTP. Permintaan paling sederhana kira-kira begini:

GET / HTTP/1.1
Host: acy-partner.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Connection: keep-alive

Server membaca ini lalu memecahnya jadi bagian-bagian yang bisa dia tindaklanjuti:

• Method-nya (GET) — jenis tindakan yang diinginkan. GET berarti “kasih saya sesuatu”, POST berarti “ini ada data, terima ya”, dan ada beberapa lainnya.
• Path-nya (/) — sumber daya mana yang diminta. / adalah halaman utama; /about berarti halaman about.
• Header-nya (Host, User-Agent, Accept, …) — konteks tambahan soal permintaannya: situs mana yang diinginkan browser, dia program jenis apa, tipe konten apa saja yang bisa dia tangani.

Pembacaan ini mengubah gumpalan teks jadi informasi yang terstruktur. Sampai langkah ini selesai, server belum benar-benar tahu apa yang diminta — setelahnya, baru tahu.

3. Dekripsi (kalau ini HTTPS)

Kalau koneksinya masuk lewat port 443, permintaan tadi terenkripsi selama perjalanan supaya tidak ada yang bisa membacanya di tengah jalan. Sebelum server bisa membaca apa pun, dia harus mendekripsi byte yang masuk memakai sertifikat TLS miliknya, dan saat mengirim balik nanti dia juga akan mengenkripsi jawabannya. Kerja jabat-tangan dan enkripsi inilah yang diam-diam dijanjikan oleh ikon gembok di browser-mu. Prosesnya terjadi di sekitar langkah pembacaan tadi, secara transparan — sisa logika server bekerja sama saja, mau permintaannya terenkripsi atau tidak.

4. Routing: menentukan siapa yang menangani ini

Sekarang server sudah tahu method dan path-nya, jadi dia harus menjawab pertanyaan inti: apa yang seharusnya merespons ini? Keputusan ini disebut routing, dan di sinilah perilaku web server bercabang jadi dua jenis besar.

Kalau path-nya menunjuk ke berkas yang memang sudah ada — misalnya gambar logo di /images/logo.png — server sering kali tinggal menemukan berkas itu di disk lalu mengirimnya apa adanya. Tidak ada yang perlu dihitung; berkas itu sendiri sudah jadi jawabannya. Ini disebut konten statis.

Kalau path-nya butuh sesuatu yang dibangun saat itu juga — halaman yang dipersonalisasi untuk pengguna yang sedang login, hasil pencarian, daftar pesanan hari ini — server tidak bisa cuma membaca berkas. Dia harus mengoper permintaannya ke sebuah program yang menjalankan kode, berbicara dengan database, dan menyusun jawaban yang baru. Ini disebut konten dinamis.

   minta /images/logo.png   →  berkas ada di disk   →  kirim berkasnya  (statis)

   minta /dashboard         →  tidak ada berkas jadi →  jalankan program
                                                         yang menyusun
                                                         halamannya  →  kirim  (dinamis)

5. Menyusun jawaban

Bagaimanapun kontennya dihasilkan — dibaca dari disk atau dibangun oleh sebuah program — server kini punya isi yang harus dikirim balik, dan dia membungkusnya dalam respons HTTP yang benar. Seperti permintaannya, jawaban ini juga teks yang terstruktur (ditambah kontennya sendiri):

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 5120
Cache-Control: max-age=3600

<!DOCTYPE html>
<html> ... halaman aslinya ... </html>

Dua hal pantas kamu perhatikan sebentar:

• Status code-nya (200 OK) — angka tiga digit yang memberi tahu browser bagaimana hasilnya. 200 berarti berhasil. 404 berarti “saya tidak menemukan yang kamu minta”. 500 berarti “ada yang rusak di sisi saya”. 301 berarti “ini sudah pindah, ke sini saja”. Kamu pasti pernah ketemu 404 di alam liar; sekarang kamu tahu dia datang langsung dari langkah ini.
• Header respons-nya (Content-Type, Content-Length, Cache-Control, …) — instruksi untuk browser soal apa yang sedang datang. Content-Type memberi tahu apakah ini harus ditampilkan sebagai halaman web, gambar, atau data mentah. Cache-Control memberi tahu berapa lama browser boleh mengingat jawabannya alih-alih bertanya ulang.

6. Mengirim balik, lalu kembali diam

Server menuliskan jawaban itu ke koneksi yang sama dengan tempat permintaan tadi masuk, dan jawaban itu melintas balik lewat jaringan menuju browser. Browser membaca status code-nya, mengecek header-nya, lalu menampilkan isinya — dan dari sisi pengunjung, halamannya cukup muncul begitu saja.

Bagi server, tugasnya selesai. Tergantung header-nya, dia mungkin membiarkan koneksinya tetap terbuka sejenak kalau-kalau browser meminta lebih (satu halaman biasa menarik puluhan gambar, skrip, dan stylesheet, masing-masing permintaan tersendiri), atau dia menutupnya. Apa pun itu, server kembali ke putarannya dan menunggu ketukan berikutnya.

   BROWSER                              WEB SERVER
      │                                     │  (mendengarkan di :443)
      │  1. buka koneksi, kirim permintaan  │
      │ ──────────────────────────────────► │
      │                                     │  2. baca  3. dekripsi
      │                                     │  4. routing  5. susun jawaban
      │  6. jawaban: 200 OK + halamannya    │
      │ ◄────────────────────────────────── │
      │                                     │
   menampilkan halaman                  kembali menunggu

Seluruh perjalanan bolak-balik itu biasanya rampung jauh di bawah satu detik. Dan server tidak melakukannya sekali saja — dia menjalankan putaran ini untuk setiap pengunjung, sering kali banyak sekaligus, yang membawa kita ke bagian yang membuat web server benar-benar mengesankan.

Menangani banyak permintaan sekaligus

Situs sungguhan tidak kedatangan satu pengunjung yang sopan menunggu giliran. Dia kedatangan ratusan atau ribuan permintaan yang berdatangan dalam gelombang yang saling tumpang tindih. Kalau server cuma bisa menangani satu per satu — menyelesaikan seluruh putaran dulu, baru menerima yang berikutnya — semua orang setelah orang pertama bakal terjebak antrean, dan situsnya bakal terasa membeku.

Maka web server dibangun untuk konkurensi: menangani banyak permintaan dalam rentang waktu yang sama. Tekniknya bermacam-macam, tapi strategi besarnya layak kamu kenali:

• Banyak pekerja. Server menyimpan sekumpulan worker berupa thread atau proses, lalu menyerahkan tiap permintaan yang masuk ke worker yang lagi senggang. Dua puluh worker bisa sibuk melayani dua puluh pengunjung berbeda secara bersamaan.
• Putaran berbasis event. Alih-alih menugaskan satu worker untuk tiap permintaan lalu membiarkannya menganggur sambil menunggu database atau disk yang lambat, server menjuggling ribuan koneksi dalam satu putaran, mengerjakan sedikit demi sedikit pada masing-masing setiap kali ada yang siap. Inilah kenapa sebagian server sanggup menangani koneksi dalam jumlah besar di perangkat keras yang sederhana.

Kamu tidak perlu memilih atau menyetel apa pun dari ini untuk memahami web — tapi mengetahui bahwa server terus-menerus menjalankan banyak percakapan sekaligus menjelaskan bagaimana satu mesin bisa melayani situs yang ramai, dan kenapa “berapa banyak permintaan per detik yang sanggup dia tangani” jadi pertanyaan yang sering muncul ketika orang membahas performa server.

Kenapa memahami putaran ini sepadan dengan usahanya

Begitu siklus minta–baca–routing–jawab jelas di kepalamu, banyak sekali hal di pengembangan web yang berhenti jadi misteri. Saat sebuah halaman mengembalikan 404, kamu tahu langkah routing-nya tidak menemukan path yang cocok dengan apa pun. Saat kamu melihat 500, kamu tahu server memang menemukan rute-nya, tapi kode yang seharusnya menyusun jawaban malah meledak. Saat seorang developer bicara soal “mengatur header” atau “request body”, kamu bisa menempatkan istilah itu tepat di langkah tempat mereka tinggal.

Putaran ini juga menarik garis yang rapi antara dua paruh dunia pengembangan web. Semua yang terjadi di browser — tata letak, klik, animasi — itu front end. Semua yang baru saja kita telusuri — mendengarkan di port, membaca permintaan, routing, menghasilkan jawaban — itu sisi server. Web server adalah engsel di antara keduanya: program yang berdiri di pintu, mengubah setiap “saya mau halaman ini” jadi “ini dia”.

Penutup

Ini seluruh perjalanannya dalam satu tempat:

• Web server adalah program yang berjalan terus-menerus dan bertugas mendengarkan permintaan lewat jaringan lalu menjawabnya dengan konten web.
• Dia mulai dengan mengikat diri ke sebuah port (80 untuk HTTP, 443 untuk HTTPS) dan menunggu koneksi.
• Untuk tiap permintaan dia menjalankan satu putaran: terima koneksi → baca permintaan → dekripsi kalau HTTPS → routing untuk menentukan siapa yang merespons → susun jawaban → kirim balik, lalu kembali menunggu.
• Permintaan membawa method, path, dan header; jawaban membawa status code (200, 404, 500 …), header, dan kontennya sendiri.
• Routing memilih antara konten statis (berkas yang sudah ada, dikirim apa adanya) dan konten dinamis (dibangun saat itu juga, sering oleh program terpisah).
• Server sungguhan menangani banyak permintaan sekaligus lewat kumpulan worker atau putaran berbasis event, dan dijalankan sebagai service yang diawasi supaya tetap hidup.

Berikutnya, ada baiknya kita memperbesar percabangan yang sejak tadi terus kita sentuh sekilas — beda sesungguhnya antara konten statis dan dinamis, dan kenapa hal itu membentuk cara setiap situs dibangun dan di-deploy.