Cara Kerja Server: Dari Permintaan ke Jawaban, Langkah demi Langkah

Kamu sudah tahu gambaran besar soal server: sebuah komputer yang menjawab permintaan dari komputer lain. Itu bagian apa-nya. Artikel ini soal bagaimana-nya — apa yang benar-benar terjadi di dalam mesin itu, dalam sepersekian detik antara sebuah permintaan muncul dan sebuah jawaban meluncur keluar. Begitu kamu bisa membayangkan loop ini, banyak istilah yang kedengarannya bikin pusing (port, koneksi, request, handler) berhenti terasa misterius.

Kita bakal menyusuri seluruh jalurnya bareng-bareng, pelan-pelan, pakai web server sebagai contoh utama karena jenis inilah yang paling sering ditemui orang lebih dulu. Tapi hampir semua hal di sini berlaku untuk server jenis apa pun. Namanya berganti; bentuknya tetap sama.

Gambaran besar: sebuah loop yang tak pernah berhenti

Telanjangi sebuah server sampai ke tulangnya, dan kamu bakal menemukan satu siklus sederhana yang berulang. Programnya menyala, mengklaim sebuah tempat untuk menyimak, lalu masuk ke sebuah loop: tunggu permintaan, tangani, kirim balik jawaban, tunggu yang berikutnya. Dia melakukan ini selama dia berjalan — yang, di server sungguhan, pada dasarnya selamanya.

   menyala
      │
      ▼
  ┌─► tunggu permintaan      ◄── (nganggur, menyimak)
  │        │
  │        ▼
  │   baca & pahami
  │        │
  │        ▼
  │   kerjakan tugasnya
  │        │
  │        ▼
  │   kirim balik jawaban
  │        │
  └────────┘   (loop selamanya)

Itu saja. Selebihnya cuma detail yang mengisi kotak-kotak tadi. Server terasa “selalu nyala” justru karena dia menghabiskan sebagian besar hidupnya duduk di kotak paling pertama — menunggu — nyaris tak memakai sumber daya apa pun sampai ada yang datang. Mari kita buka satu per satu langkahnya.

Langkah 1: server menyimak di sebuah port

Sebelum bisa menjawab siapa pun, server harus mengumumkan di mana dia bisa dihubungi. Sebuah mesin punya alamat (alamat IP-nya), tapi satu mesin bisa menjalankan banyak server sekaligus — web server, mail server, database server. Jadi alamat saja tidak cukup; kamu juga butuh port, semacam pintu bernomor di alamat tersebut.

Saat sebuah web server menyala, dia melakukan yang namanya binding ke sebuah port — biasanya port 80 untuk HTTP biasa atau 443 untuk HTTPS. Sejak saat itu, dia menyimak: memberi tahu sistem operasi, “apa pun yang datang ke alamat ini di port ini, serahkan ke saya.”

        satu mesin (IP 203.0.113.10)
   ┌──────────────────────────────────────┐
   │  port 443 → web server   (menyimak)   │
   │  port 25  → mail server  (menyimak)   │
   │  port 5432→ database     (menyimak)   │
   └──────────────────────────────────────┘

Bayangkan alamat IP sebagai alamat jalan sebuah gedung, dan port sebagai nomor ruangan tertentu di dalamnya. Sebuah surat butuh keduanya supaya sampai ke meja yang tepat. Sampai ada permintaan tiba di pintu yang dijaganya, server cuma menunggu — sabar, nganggur, nyaris tak menyentuh tenaga komputernya sama sekali.

Langkah 2: sebuah client menyambung

Di suatu titik di jaringan, sebuah client — browser-mu, aplikasi ponsel, atau server lain — memutuskan dia mau sesuatu. Dia menjangkau melintasi internet ke alamat-dan-port yang persis itu, lalu meminta untuk membuka sebuah koneksi.

Untuk sebagian besar lalu lintas web, koneksi ini dibangun di atas TCP, sebuah protokol yang seluruh tugasnya adalah menciptakan saluran dua arah yang andal antara dua mesin. Sebelum data sungguhan mengalir, kedua sisi melakukan tarik-ulur singkat untuk sepakat bahwa keduanya ada dan siap — sering disebut handshake. Begitu itu beres, ada pipa terbuka antara client dan server, dan data bisa mengalir ke dua arah lewat pipa itu.

   CLIENT                              SERVER
      │                                   │
      │  "boleh buka koneksi?"            │
      │ ────────────────────────────────► │
      │                                   │
      │  "boleh, siap"                    │
      │ ◄──────────────────────────────── │
      │                                   │
      │  ═══ koneksi terbuka terbentuk ═══│

Server tidak mengurus ini sendirian — sistem operasi yang mengerjakan banyak hal tingkat rendah, lalu menyerahkan koneksi yang sudah jadi ke program server. Dari sudut pandang server, tadinya dia menunggu, dan kini ada client di ujung saluran. Saatnya menyimak apa yang sebenarnya client mau.

Langkah 3: permintaan datang

Sekarang client mengirim permintaan-nya — sebuah pesan terstruktur yang menyatakan persis apa yang dia incar. Untuk web server, ini adalah permintaan HTTP, dan ternyata cukup gampang dibaca. Kira-kira beginilah yang browser-mu kirim saat kamu membuka sebuah halaman:

GET /about HTTP/1.1
Host: blog.acy-partner.com
User-Agent: Mozilla/5.0 ...
Accept: text/html

Ayo kita bedah, karena tiap bagian punya tugas:

• GET adalah method — jenis aksi yang diinginkan. GET berarti “kasih saya sesuatu.” Yang lain yang umum adalah POST (ini ada data buat disimpan), PUT, dan DELETE.
• /about adalah path — hal spesifik mana di server ini yang sedang diminta.
• HTTP/1.1 adalah versi protokol yang dipakai.
• Baris-baris di bawahnya adalah header — konteks tambahan: situs mana (Host), client jenis apa (User-Agent), format apa saja yang bisa dia terima, dan seterusnya.

Server membaca pesan ini dan kini tahu tiga hal penting: aksi apa (GET), atas sumber daya mana (/about), dan dengan konteks tambahan apa (header-nya). Itu sudah cukup untuk memutuskan langkah berikutnya.

Langkah 4: server menangani permintaan

Inilah jantungnya — bagian yang benar-benar berbeda dari satu server ke server lain. Menangani permintaan berarti mencari tahu jawaban yang tepat. Caranya sepenuhnya tergantung pada jenis sumber daya yang diminta, dan percabangan tunggal inilah yang membedakan dua kategori besar konten web.

Kalau client meminta sebuah berkas statis — sebuah gambar, sebuah stylesheet, sebuah halaman HTML yang sudah jadi — kerjaannya ringan. Server mencari berkas itu di disk-nya lalu bersiap mengirimnya balik, kurang lebih apa adanya. Cepat dan sederhana.

Kalau client meminta sesuatu yang dinamis — sebuah halaman yang harus disusun segar, seperti dashboard personalmu atau hasil pencarian — server punya kerjaan beneran. Dia menjalankan kode program, dan kode itu mungkin:

• membaca atau menulis data di sebuah database (mencari seorang pengguna, mengambil daftar artikel),
• menerapkan aturan bisnis (apakah orang ini boleh melihat ini?),
• lalu merakit sebuah jawaban yang benar-benar baru saat itu juga, sering dalam bentuk HTML atau JSON.

   permintaan untuk /about
          │
          ▼
   ┌─────────────────────┐
   │   apakah statis?    │
   └─────────┬───────────┘
       ya    │   tidak
      ┌──────┘   └──────────┐
      ▼                     ▼
  baca sebuah berkas   jalankan kode program
  dari disk            (mungkin query DB,
                        cek aturan, susun
                        halaman saat itu juga)
      └──────────┬──────────┘
                 ▼
          jawaban siap

Ke mana pun jalurnya, tujuannya sama: berakhir dengan sesuatu untuk dikirim balik. Jalur statis cuma sampai lebih cepat karena jawabannya sudah ada; jalur dinamis menghasilkan jawaban yang dibuat khusus untuk permintaan yang persis ini.

Langkah 5: jawaban dikirim balik

Dengan jawaban di tangan, server membungkusnya sebagai sebuah response lalu mengirimnya balik lewat koneksi terbuka yang sama. Sebuah response HTTP punya bentuk yang mirip dengan permintaannya: satu baris status, beberapa header, lalu kontennya yang sesungguhnya.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024

<!doctype html>
<html> ... halamannya ... </html>

Baris pertama membawa sebuah status code, angka kecil dengan makna besar. Kamu pasti pernah melihat ini meski tak tahu namanya:

• 200 OK — sukses, ini yang kamu minta.
• 404 Not Found — server paham maksudmu, tapi tidak ada apa-apa di path itu.
• 500 Internal Server Error — server mencoba menanganinya dan ada yang rusak di sisinya.
• 301/302 — sebuah redirect; yang kamu mau sekarang tinggal di tempat lain.

Sesudah baris status datang header response (ini konten jenis apa, sepanjang apa, petunjuk caching) lalu body-nya — HTML-nya, byte gambarnya, JSON-nya, apa pun yang diminta. Client menerima semua ini, membaca statusnya, lalu bertindak atas kontennya. Untuk sebuah browser, itu berarti melukis halaman di layarmu.

Langkah 6: kembali menunggu (dan melakukan semuanya sekaligus)

Begitu jawaban terkirim, satu pertukaran itu selesai. Server kembali ke puncak loop-nya, siap untuk permintaan berikutnya. Tapi inilah pertanyaan yang sering bikin orang bingung: kalau server terjebak dalam sebuah loop yang menangani satu permintaan dalam satu waktu, bagaimana dia bisa melayani ribuan orang sekaligus?

Jawabannya adalah concurrency — menangani banyak permintaan dalam waktu yang tumpang-tindih, bukan ketat satu-lalu-berikutnya. Server sungguhan tidak membeku menunggu satu permintaan lambat selesai; dia menjuggling banyak permintaan yang sedang berjalan di saat yang sama. Ada beberapa cara umum untuk mewujudkannya:

• Banyak worker — server menjalankan beberapa salinan handler-nya (sebagai proses atau thread terpisah), jadi beberapa permintaan dikerjakan secara paralel.
• Sebuah event loop — satu worker yang, alih-alih membeku menunggu database atau disk, menyisihkan permintaan itu lalu mengambil yang lain, menjalin keduanya.
• Dua-duanya sekaligus — banyak sistem nyata menggabungkan keduanya: beberapa worker, masing-masing menjuggling banyak permintaan.

   permintaan masuk
   ┌──┐ ┌──┐ ┌──┐ ┌──┐
   │R1│ │R2│ │R3│ │R4│
   └─┬┘ └─┬┘ └─┬┘ └─┬┘
     ▼    ▼    ▼    ▼
   ┌────────────────────┐
   │  server menjuggling │  ← semua "berjalan" bareng,
   │  mereka bersamaan   │     tak ada yang menghambat lain
   └────────────────────┘

Kamu tidak perlu menguasai concurrency untuk memahami server — cukup tahu bahwa loop sederhana yang kita gambar di awal tadi, dalam kenyataannya, berjalan berkali-kali lipat secara paralel. Itulah yang membuat satu mesin terasa instan bagi ribuan pengunjung di saat yang sama.

Menyatukan seluruh perjalanan

Mari kita putar ulang seluruh perjalanan dalam satu gambar, persis seperti alirannya saat kamu memuat sebuah halaman:

  1. server menyimak di port 443
  2. browser-mu membuka koneksi
  3. browser mengirim:  GET /about
  4. server menanganinya (berkas statis ATAU jalankan kode + DB)
  5. server mengirim:   200 OK + halamannya
  6. browser menampilkan halaman; server menunggu yang berikutnya

Enam langkah, dari awal sampai akhir, biasanya jauh di bawah satu detik. Kalikan dengan tiap klik, tiap gambar, tiap panggilan API yang aplikasimu lakukan, dan jadilah dengungan aktivitas tanpa henti yang menjaga web tetap hidup. Mesin yang kamu pakai membaca ini barusan melakukan persis tarian ini, beberapa kali, untuk menaruh kata-kata ini di layarmu.

Penutup

Ini semuanya dalam satu tempat:

• Sebuah server menjalankan loop tanpa akhir: simak, terima, tangani, balas, ulangi.
• Dia pertama-tama binding ke sebuah port lalu menyimak — sebuah alamat ditambah nomor port adalah “pintu” yang diketuk client.
• Sebuah client membuka sebuah koneksi (biasanya lewat TCP) lalu mengirim sebuah permintaan yang menyatakan method (GET, POST…), path, dan header.
• Server menangani permintaan — menyajikan sebuah berkas statis langsung, atau menjalankan kode dan mungkin sebuah query database untuk menyusun jawaban dinamis.
• Dia mengirim balik sebuah response berisi sebuah status code (200, 404, 500…), header, dan body, lalu kembali menunggu.
• Server sungguhan melakukan semua ini secara concurrent, menjuggling banyak permintaan sekaligus supaya mesin terasa instan bagi semua orang.

Kalau kamu mau menambatkan ini ke ide yang lebih besar dulu, ada baiknya menengok kembali apa itu server sebenarnya — artikel ini pada dasarnya adalah definisi itu yang diperlihatkan dalam gerak lambat. Dari sini, pertanyaan yang wajar berikutnya adalah soal di mana semua ini terjadi: bedanya menjalankan server di mesinmu sendiri versus di luar sana untuk dunia, dan bagaimana alamat serta port benar-benar bekerja.