un: Proksi & Origin

un

tamu

1 / ?

kembali ke pelajaran

Apa yang Berada di Depan Hampir Setiap Layanan Web

Selamat Datang

Jika Anda mengetik example.com ke dalam browser, Anda hampir tidak pernah mencapai mesin yang sebenarnya menjalankan aplikasi tersebut. Anda mencapai mesin yang meneruskan permintaan ke mesin yang melakukannya. Mesin penerus itu memiliki nama: sebuah reverse proxy.

Pelajaran ini mengajarkan apa yang dilakukan reverse proxy, mengapa hampir setiap layanan web publik bersembunyi di baliknya, & apa tiga tugas yang ditangani oleh lapisan edge pada saat yang sama.

Pada akhirnya, Anda akan memahami:

- Perbedaan antara klien, proxy, & origin

- Mengapa proxy di depan origin melindungi, menskalakan, & memungkinkan Anda mengganti komponen tanpa ada yang menyadarinya

- Tiga tugas yang ditangani proxy reverse sekaligus: menyembunyikan origin, mengakhiri TLS, & mendistribusikan beban di antara replika

- Bagaimana permintaan berjalan dari browser ke proxy ke upstream & kembali, lompatan demi lompatan

Pada akhirnya, Anda akan dapat bernalar dengan percaya diri tentang penempatan proxy, pemisahan kekhawatiran di edge, & mengapa tier proxy stateless dapat diperbanyak secara murah sementara origin tunggal tidak.

Proxy Forward vs Proxy Reverse

Dua Arah Proxy

Kedua jenis proxy berdiri di antara dua pihak & menerlalu lalu lintas. Mereka berbeda dalam pihak mana yang mereka wakili.

Proksi maju (Forward proxy): berdiri di depan sekelompok klien. Klien mengetahui keberadaan proksi; server eksternal melihat alamat proksi, bukan alamat klien. Proksi egress perusahaan, filter konten, & proksi SOCKS cocok dengan pola ini.

Proksi terbalik (Reverse proxy): berdiri di depan sekelompok server. Dunia luar (klien) berkomunikasi dengan alamat proksi; klien tidak memiliki ide bahwa ada server asli yang tersembunyi di baliknya. Hampir setiap layanan web publik menggunakan satu proksi ini.

Mnemonik: proksi maju menyembunyikan klien dari server. Proksi terbalik menyembunyikan server dari klien.

Mengapa peduli arah mana? Tugas, mode kegagalan, & batas keamanan semuanya berbeda. Proksi maju khawatir tentang siapa yang dihubungi oleh penggunanya; proksi terbalik khawatir tentang siapa yang menghubungi servernya.

Klien yang mengirim lalu lintas melalui kedua jenis sekaligus akan menempuh perjalanan: client -> forward_proxy -> internet -> reverse_proxy -> origin.

Sebuah perusahaan kecil menjalankan aplikasi obrolan. Mereka ingin setiap permintaan dari pengguna luar mendarat di mesin yang menyembunyikan server obrolan sebenarnya di baliknya. Jenis proksi apa yang mereka butuhkan, & apa yang sebenarnya dihubungkan oleh pengguna luar?

Mengapa Banyak Hal Terletak di Edge

Lapisan Edge Membuktikan Kegunaannya

Reverse proxy menjalankan tiga tugas secara bersamaan. Salah satu dari tugas tersebut saja sudah cukup untuk membenarkan keberadaan lapisan ini; menjalankan ketiganya pada alamat yang sama menjelaskan mengapa hampir setiap arsitektur web produksi terlihat memiliki bentuk yang sama di bagian depan.

Tugas 1: Sembunyikan origin. Proxy menjawab pada IP publik. Backend berada di IP privat yang tidak dapat dijangkau oleh internet. Penyerang yang ingin menyerang origin harus terlebih dahulu berhasil menembus proxy.

Tugas 2: Mengakhiri TLS. Proksi memegang sertifikat untuk example.com & mengenkripsi ulang (mendekripsi) permintaan HTTPS yang masuk. Backend berkomunikasi menggunakan HTTP polos (atau TLS internal yang lebih sederhana) dengan proksi melalui segmen jaringan yang tepercaya. Rotasi, perpanjangan, & kebijakan cipher sertifikat semuanya berada di satu tempat.

Tugas 3: Mendistribusikan beban. Proksi memilih backend mana yang menangani setiap permintaan. Backend di belakang satu proksi membentuk sebuah pool; proksi memilih satu per permintaan menggunakan strategi (round-robin, least-connections, hash pada header). Menambah kapasitas berarti menambah backend ke dalam pool, bukan memberi tahu setiap klien alamat baru.

Setiap tugas adalah program kecil. Bersama-sama, mereka menjelaskan mengapa lapisan sesederhana 'Caddy di depan aplikasi Python' membawa bobot desain yang lebih besar daripada aplikasi Python itu sendiri.

Proksi terbalik yang membawa tiga tugas: menyembunyikan asal, mengakhiri TLS, mendistribusikan beban

Merancang untuk Ketiganya

Tim Anda menjalankan API kecil pada satu proses Python yang mendengarkan port 8000 di satu VM. Lalu lintas telah tumbuh cukup sehingga satu VM tidak dapat mengimbangi, & tinjauan keamanan menandai bahwa VM tersebut memiliki IP publik & menjalankan sertifikat TLS-nya sendiri.

Anda memutuskan untuk menempatkan proksi terbalik di depan. Gambarlah tata letaknya: ke mana DNS menunjuk, di mana sertifikat berada, bagaimana beban mencapai backend, & apa yang berubah pada VM asli?

Telusuri arsitektur baru. Tangani keempat bagian: target DNS, lokasi pengakhiran TLS, strategi distribusi beban, & apa yang dipertahankan atau hilang oleh VM asli.

Ganti Komponen Tanpa Ada yang Menyadari

Indireksi Membeli Kebebasan

Sebuah pepatah lama dalam ilmu komputer menyatakan: setiap masalah dapat diselesaikan dengan menambahkan lapisan indirection (kecuali masalah terlalu banyak lapisan indirection). Reverse proxy adalah salah satu indirection yang paling berguna dalam sistem terdistribusi.

Apa yang Anda dapatkan:

- Backend yang dapat diganti. Pindahkan aplikasi dari Python ke Go? Migrasi dari satu datacenter ke datacenter lain? Rilis versi baru dengan nol downtime? Masing-masing terjadi di balik alamat publik yang stabil. Tidak ada yang berubah bagi pengguna.

- Skala yang independen. Lapisan proxy berskala berdasarkan bandwidth & CPU pada lapisan TLS. Lapisan backend berskala berdasarkan beban aplikasi. Masing-masing tumbuh pada sumbunya sendiri karena mereka berada di mesin yang berbeda.

- Pencegahan kegagalan. Deploy yang buruk di backend tidak akan mematikan alamat publik. Proxy tetap aktif; Anda mendorong perbaikan atau melakukan roll back; dunia terhubung kembali ketika backend pulih.

- Kekhawatiran lintas-cutting di satu tempat. Pembatasan laju (rate limiting), pemblokiran geografis, pencatatan permintaan (request logging), penulisan ulang header, penampungan (caching), kompresi respons: semuanya berada di proxy. Kode backend tetap fokus pada aplikasi.

Tanpa proxy, setiap masalah ini harus berada di dalam proses aplikasi. Dengan proxy, mereka berada di satu lapisan yang dimiliki oleh satu tim.

Biayanya: satu lapisan lagi untuk dioperasikan. Tim yang matang menerima biaya ini karena lapisan proxy itu sendiri berjalan tanpa status (stateless) & berskala secara horizontal; mengganti satu proxy dengan dua tidak memerlukan koordinasi.

Deploy Biru/Hijau Melalui Proxy

Tim Anda menjalankan versi 1 dari API di tiga VM backend (pool biru) di belakang reverse proxy. Anda ingin mendeploy versi 2 dengan kemampuan untuk melakukan rollback dalam waktu kurang dari tiga puluh detik jika terjadi masalah.

Anda meluncurkan tiga VM backend baru (pool hijau) yang menjalankan versi 2, berdampingan dengan pool biru, tetapi Anda belum mengalihkan lalu lintas apa pun ke mereka.

Jelaskan bagaimana reverse proxy memungkinkan Anda untuk beralih dari biru ke hijau & melakukan rollback dengan cepat, & jelaskan apa yang tidak akan mungkin dilakukan jika aplikasi tersebut langsung terpapar ke klien tanpa proxy.

Dari Browser ke Backend & Kembali

Ikuti Satu Permintaan dari Awal hingga Akhir

Telusuri satu permintaan HTTPS GET https://api.example.com/users/42 melalui proksi terbalik (reverse proxy) di depan kumpulan backend (backend pool).

Lompatan 1: Resolusi DNS. Browser meminta resolver untuk api.example.com. Resolver mengembalikan IP publik proksi (misalnya, 203.0.113.10). Browser membuka koneksi TCP ke 203.0.113.10:443.

Lompatan 2: Handshake TLS. Proksi menyajikan sertifikatnya untuk api.example.com. Browser memvalidasi sertifikat, kedua pihak menyepakati kunci sesi, & kanal terenkripsi terbuka.

Lompatan 3: Permintaan HTTP di dalam TLS. Browser mengirim GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Proksi mendekripsi byte permintaan tersebut.

Hop 4: Pemilihan backend. Proxy berkonsultasi dengan pool upstream-nya untuk api.example.com & memilih satu backend (misalnya 10.0.0.21:8000) menggunakan strategi load-balancing-nya.

Hop 5: Permintaan upstream. Proxy membuka (atau menggunakan kembali) koneksi HTTP biasa ke 10.0.0.21:8000 & meneruskan permintaan tersebut. Proxy dapat menulis ulang header di sepanjang jalan: menambahkan X-Forwarded-For: <client-ip>, mengatur Host: dengan benar, dan menghapus header hop-by-hop seperti Connection.

Hop 6: Pemrosesan backend. Aplikasi backend membaca permintaan, menanyakan ke basis datanya, dan membangun respons JSON.

Hop 7: Respons upstream. Backend mengirim kembali respons ke proxy sebagai HTTP biasa.

Hop 8: Respons edge. Proxy dapat menulis ulang atau mengompresi respons, mengenkripsinya kembali melalui sesi TLS, & mengirimnya ke browser.

Hop 9: Siklus hidup koneksi. Sesi TLS biasanya tetap terbuka untuk permintaan berikutnya (HTTP/2 memultiplex banyak permintaan pada satu koneksi). Koneksi proxy-ke-backend sering kali dipool untuk digunakan kembali.

Setiap layanan web publik mengikuti beberapa variasi dari bentuk ini. Mengetahui hop-hop tersebut memungkinkan Anda untuk bernalar tentang di mana latensi terakumulasi, di mana logging seharusnya berada, & di mana kegagalan dapat tersembunyi.

Siklus hidup permintaan: browser, DNS, proxy, TLS, upstream, backend, respons

Ke Mana Waktu Tersebut Hilang?

Seorang pengguna mengeluh bahwa API terasa lambat. Anda mengukur & menemukan bahwa permintaan memakan waktu 850 ms dari awal hingga akhir. Log server di backend menunjukkan bahwa aplikasi melayani permintaan tersebut dalam 40 ms. Log proxy menunjukkan bahwa proxy menghabiskan 50 ms untuk pekerjaannya di sisi proxy (handshake TLS + routing + penulisan respons).

Ke mana 760 ms lainnya pergi? Sebutkan setidaknya dua kandidat yang berada di luar waktu pemrosesan proxy & backend, & jelaskan bagaimana masing-masing akan terlihat dalam pengukuran.

Rancang Edge Minimal untuk Layanan Baru

Sintesis

Anda telah mempelajari perbedaan antara forward & reverse proxy, tiga tugas yang ditangani sekaligus oleh reverse proxy, mengapa menyembunyikan origin memberikan keuntungan setiap kali Anda perlu melakukan perubahan, & bagaimana permintaan mengalir lompat demi lompat melalui edge.

Sekarang terapkan ilmunya.

Sebuah tim kecil berencana meluncurkan layanan baru bernama notes.example.com. Pengguna akan membaca & menulis catatan pribadi. Tim tersebut akan menjalankan dua VM backend saat peluncuran & mengharapkan peningkatan skala menjadi sepuluh dalam satu tahun ke depan. Mereka menginginkan HTTPS untuk pengguna, peluncuran bertahap untuk versi baru, & tidak ada paparan publik IP backend.

Rancang arsitektur *edge* untuk notes.example.com. Tanggapi: ke mana DNS menunjuk, di mana sertifikat TLS berada, bagaimana permintaan mencapai *backend*, apa yang berubah saat mereka tumbuh dari dua menjadi sepuluh *backend*, & satu kekhawatiran lintas-cutting (*cross-cutting concern*) (pembatasan laju, *logging*, penulisan ulang header, dll) yang akan Anda tambahkan di *edge* alih-alih di dalam aplikasi.

Ke Mana Arah Kursus Ini Selanjutnya

Pelajaran ini menetapkan bentuk dari lapisan edge. Empat pelajaran lagi dalam kursus ini dibangun di atasnya:

- Skala Horizontal Tanpa State: mengapa lapisan proxy (& backend di baliknya) dapat digandakan secara murah, & matematika untuk menentukan jumlah replika di bawah lonjakan.

- Pemisahan Ingress / Egress: mengapa satu kotak proxy yang menangani lalu lintas masuk & keluar akhirnya gagal dengan cara yang mengejutkan, & bagaimana cara memisahkan lapisan-lapisan tersebut.

- Mode Kegagalan & Radius Ledakan: bagaimana satu perubahan konfigurasi dapat berantai menjadi gangguan layanan, & bagaimana menulis item tindakan tanpa menyalahkan (blameless) untuk mencegah terulangnya insiden.

- Observabilitas & Kapasitas: apa yang harus diukur di edge agar Anda mengetahui ada yang rusak sebelum pengguna menyadarinya.

Setiap pelajaran berdiri sendiri. Jika digabungkan, semuanya memberikan model mental yang berfungsi untuk armada berskala web.

Pelajaran pendamping: geometry_of_proxies_and_origins membingkai ulang semua materi dalam pelajaran ini sebagai graf berarah & mengeksplorasi apa yang diajarkan teori graf tentang jalur permintaan.

Bagus. Lanjutkan.