un — Proksi & Asal

un

tamu

1 / ?

kembali ke pelajaran

Apa yang Berdiri di Depan Setiap Layanan Web

Selamat Datang

Jika Anda mengetik example.com ke browser, Anda hampir tidak pernah mencapai mesin yang benar-benar menjalankan aplikasi. Anda mencapai mesin yang meneruskan permintaan ke satu yang benar-benar melakukannya. Mesin tersebut yang mengirimkan permintaan tersebut ke yang lain dan disebut proksi balik.

Les ini mengajarkan apa yang dilakukan proksi balik, mengapa hampir setiap layanan web publik mengunci di baliknya, dan apa yang dilakukan tiga pekerjaan lapisan edge secara bersamaan.

Setelah pelajaran ini, Anda akan memahami:

- Perbedaan antara klien, proksi, dan asal

- Mengapa proksi di depan asal melindungi, menggandakan, dan memungkinkan Anda untuk mengganti bagian-bagian tanpa seseorang mengetahuinya

- Tiga pekerjaan yang dijalankan oleh proksi balik secara bersamaan: mengunci asal, menutup TLS, dan mendistribusikan beban ke atas replika

- Bagaimana permintaan berjalan dari browser ke proksi ke atas dan kembali, langkah demi langkah

Setelah pelajaran ini, Anda akan berpikir dengan percaya diri tentang penempatan proksi, pemisahan kepentingan di edge, dan mengapa lapisan proksi yang tidak berubah banyak sambil menjaga satu asal tidak.

Proksi Depan vs Proksi Belakang

Dua Arah Proksi

Kedua jenis proksi berdiri di antara dua pihak dan mengirimkan lalu lintas. Mereka berbeda dalam pihak yang mereka wakili.

Proksi Depan: berdiri di depan kelompok klien. Klien tahu tentang proksi; server luar melihat alamat proksi, bukan alamat klien. Proksi keluaran perusahaan, filter konten, dan proksi SOCKS sesuai dengan pola ini.

Proksi Balik: berdiri di depan kelompok server. Dunia luar (klien) berbicara dengan alamat proksi; klien tidak tahu server nyata yang bersembunyi di baliknya. Hampir setiap layanan web publik menggunakan satu.

Mnemonic: proksi depan mengunci klien dari server. Proksi balik mengunci server dari klien.

Mengapa harus peduli tentang arahnya? Tugas, mode kegagalan, dan batas keamanan semuanya berbeda. Proksi depan khawatir tentang siapa yang dihubungi pengguna; proksi balik khawatir tentang siapa yang menghubungi servernya.

Klien yang mengirimkan lalu lintas melalui kedua jenis tersebut perjalanan: client -> forward_proxy -> internet -> reverse_proxy -> origin.

Perusahaan kecil yang menjalankan aplikasi obrolan. Mereka ingin setiap pengguna luar mengirim permintaan ke mesin yang mengunci server obrolan yang sebenarnya di baliknya. Jenis proksi apa yang mereka butuhkan, dan ke mana pengguna luar sebenarnya terhubung?

Mengapa Banyak Hal yang Berada di Pinggir

Layer Pinggir Menghasilkan Penghasilannya

Sebuah reverse proxy melakukan tiga pekerjaan secara bersamaan. Satu dari mereka cukup untuk mengjustifikasi lapisan; ketika semua tiga berada di alamat yang sama, ini adalah alasan mengapa hampir setiap arsitektur web produksi terlihat bentuk yang sama di depan.

Pekerjaan 1: Mengaburkan asal. Proxy ini menjawab di IP publik. Backend berada di IP pribadi yang tidak dapat dijangkau oleh internet. Seorang penyerang yang ingin menghantam asal harus pertama kali mengompromikan proxy.

Pekerjaan 2: Menghentikan TLS. Proxy ini memegang sertifikat untuk example.com dan menguraikan permintaan HTTPS masuk. Backend berbicara HTTP sederhana (atau TLS internal yang lebih sederhana) ke proxy di atas segment jaringan yang dipercaya. Kebijakan putar ulang sertifikat, perpanjangan, dan kebijakan sandi semua ada di satu tempat.

Pekerjaan 3: Mengedarkan beban. Proxy ini memilih backend yang akan menghandle setiap permintaan. Backend di belakang satu proxy membentuk kolam; proxy memilih satu per permintaan menggunakan strategi (putar-putar, terendah-koneksi, hash pada header). Menambahkan kapasitas berarti menambahkan backend ke kolam, bukan memberi tahu setiap klien alamat baru.

Setiap pekerjaan adalah program kecil. Bersama-sama, mereka menjelaskan mengapa satu lapisan sebesar 'Caddy di depan aplikasi Python' membawa lebih banyak bobot desain daripada aplikasi Python itu sendiri.

Reverse proxy yang mengangkut tiga pekerjaan: mengaburkan asal, menghentikan TLS, mengedarkan beban

Mengatur Semua Tiga

Tim Anda menjalankan API kecil di satu proses Python yang mendengarkan di port 8000 di satu VM tunggal. Traffic telah tumbuh cukup banyak sehingga satu VM tidak dapat melanjutkan, dan ulasan keamanan mengindikasikan bahwa VM memiliki IP publik dan menjalankan sertifikat TLSnya sendiri.

Anda memutuskan untuk memasang reverse proxy di depan. Gambarlah tata letak: di mana DNS menunjuk, di mana sertifikat hidup, bagaimana beban mencapai backend, dan apa yang berubah tentang VM asli?

Lalui arsitektur baru. Aliri semua empat potongan: target DNS, lokasi penghentian TLS, strategi distribusi beban, dan apa yang VM asli tetap atau kehilangan.

Tukar Komponen Tanpa Seseorang Melihat

Indirect Membeli Kemerdekaan

Sebuah pranala lama dalam ilmu komputer berbunyi: setiap masalah dapat diatasi dengan menambahkan lapisan indikasi (kecuali masalah terlalu banyak lapisan indikasi). Reverse proxy adalah salah satu indikasi paling berguna dalam sistem terdistribusi.

Apa yang Anda beli:

- Backend yang dapat diubah. Pindahkan aplikasi dari Python ke Go? Migrasi dari satu data center ke data center lain? Rilis versi baru dengan downtime nol? Semua itu terjadi di belakang alamat publik stabil. Tidak ada perubahan bagi pengguna.

- Skalabilitas independen. Tiers proxy skalabel pada bandwidth & CPU di lapisan TLS. Tier backend skalabel pada pekerjaan aplikasi. Keduanya tumbuh di sumbu yang berbeda karena mereka hidup di mesin yang berbeda.

- Pengandungan kesalahan. Deploy buruk di backend tidak menggagalkan alamat publik. Proxy tetap stabil; Anda push perbaikan atau rollback; dunia terhubung kembali saat backend pulih.

- Keselarasan lintas di satu tempat. Pengendalian kecepatan, blokir geo, logging permintaan, pengubahan header, caching, kompresi respons: semua hidup di proxy. Kode backend tetap fokus pada aplikasi.

Tanpa proxy setiap salah satu masalah harus hidup di dalam proses aplikasi. Dengan proxy mereka hidup di satu lapisan yang satu tim miliki.

Biaya: lapisan lain untuk dioperasikan. Tim yang matang menerima biaya karena proxy tier itu sendiri berjalan tanpa state & skalabel horizontal; menggantikan satu proxy dengan dua tidak membutuhkan koordinasi.

Deploy Biru/Green Melalui Proxy

Tim Anda menjalankan versi 1 API di tiga VM backend (kolam biru) di belakang reverse proxy. Anda ingin menggelar versi 2 dengan kemampuan untuk mundur dalam kurun waktu kurang dari tiga puluh detik jika ada masalah.

Anda meluncurkan tiga VM backend baru (kolam hijau) yang menjalankan versi 2, berdampingan dengan kolam biru, tetapi Anda belum mengarahkan traffic ke mereka.

Jelaskan bagaimana reverse proxy memungkinkan Anda untuk beralih dari biru ke hijau & mundur cepat jika ada masalah, & jelaskan apa yang tidak mungkin jika aplikasi langsung terpapar kepada klien tanpa proxy.

Dari Browser ke Backend & Kembali

Ikuti Permintaan HTTPS Sejak Awal Hingga Akhir

Ikuti satu permintaan HTTPS https://api.example.com/users/42 melalui proxy balik di depan sebuah kolam backend.

Langkah 1: Resolusi DNS. Browser bertanya kepada resolver untuk api.example.com. Resolver mengembalikan IP publik proxy (misalnya, 203.0.113.10). Browser membuka koneksi TCP ke 203.0.113.10:443.

Langkah 2: Tangan Gentas TLS. Proxy menampilkan sertifikatnya untuk api.example.com. Browser memvalidasi sertifikat, dua pihak setuju pada kunci sesi, & saluran enkripsi dibuka.

Langkah 3: Permintaan HTTP di dalam TLS. Browser mengirim GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Proxy mengenkripsi byte permintaan.

Langkah 4: Pemilihan Backend. Proxy mengonsultasikan kolam upstream-nya untuk api.example.com & memilih satu backend (misalnya 10.0.0.21:8000) menggunakan strategi load balancing-nya.

Langkah 5: Permintaan Upstream. Proxy membuka (atau menggunakan kembali) koneksi HTTP yang sederhana ke 10.0.0.21:8000 & mengirim permintaan. Proxy mungkin menulis ulang kepala sepanjang jalan: tambahkan X-Forwarded-For: <client-ip>, set Host: dengan benar, menghapus kepala yang dijumpai secara bergantian seperti Connection.

Langkah 6: Pengolahan Backend. Aplikasi backend membaca permintaan, mengakses basis data, dan membangun respons JSON.

Langkah 7: Respons Upstream. Backend mengirim respons kembali ke proxy sebagai HTTP yang sederhana.

Langkah 8: Respons Tepi. Proxy mungkin menulis ulang atau mengompres respons, mengenkripsikannya kembali melalui sesi TLS, & mengirimkannya ke browser.

Langkah 9: Siklus Koneksi. Sesi TLS biasanya tetap terbuka untuk permintaan berikutnya (HTTP/2 menggabungkan banyak permintaan pada satu koneksi). Koneksi proxy-to-backend seringkali mengumpulkan kembali untuk digunakan kembali.

Setiap layanan web publik mengikuti variasi dari bentuk ini. Mengetahui langkah-langkah memungkinkan Anda berpikir tentang di mana latency mengumpul, di mana logging berada, & di mana kegagalan dapat tersembunyi.

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

Dimana Waktu Hilang?

Seorang pengguna mengeluh API terasa lambat. Anda mengukur dan menemukan permintaan memakan waktu 850 ms dari ujung ke ujung. Log server di backend menunjukkan aplikasi memenuhi permintaan dalam 40 ms. Log proxy menunjukkan proxy menghabiskan 50 ms di sisi pekerjaannya (tangan salam TLS + routing + menulis respons).

Dimana 760 ms lainnya pergi? Namai setidaknya dua calon yang hidup di luar proxy dan waktu pengolahan backend, dan jelaskan bagaimana setiap satunya akan muncul dalam pengukuran.

Merancang Edge Minimal untuk Layanan Baru

Sinopsis

Anda telah belajar perbedaan antara forward dan reverse proxy, tiga pekerjaan yang dilakukan reverse proxy sekaligus, mengapa mengunci asal membayar hasil setiap kali Anda perlu mengubah sesuatu, dan bagaimana permintaan mengalir hop per hop melalui edge.

Sekarang aplikasikan.

Sebuah tim kecil merencanakan peluncuran layanan baru yang disebut notes.example.com. Pengguna akan membaca dan menulis catatan pribadi. Tim mereka akan menjalankan dua VM backend pada peluncuran dan diharapkan akan berkembang menjadi sepuluh dalam setahun. Mereka ingin HTTPS untuk pengguna, peluncuran bertahap untuk versi baru, dan tidak ingin ekspos terbuka untuk IP backend.

Rancang arsitektur edge untuk notes.example.com. Alamat: di mana DNS menunjuk, di mana sertifikat TLS hidup, bagaimana permintaan mencapai backend, apa yang berubah saat mereka tumbuh dari dua hingga sepuluh backend, dan satu kekhawatiran lintas potong (pengendalian kecepatan, logging, pengubahan header, dll) yang Anda tambahkan di edge daripada di dalam aplikasi.

Di Mana Pelajaran Ini Berikutnya

Pelajaran ini menetapkan bentuk lapisan edge. Empat pelajaran lain dalam kursus ini membangun pada itu:

- Skalabilitas Horizontal Tanpa Negara: mengapa suatu lapisan proxy (& backend di baliknya) dapat bertambah secara murah, & mengapa perhitungan jumlah replika di bawah lonjakan sangat penting.

- Pemisahan Ingress / Egress: mengapa kotak proxy tunggal yang menghandle traffic masuk & keluar akhirnya gagal dalam cara yang tidak terduga, & bagaimana cara memisahkan lapisan.

- Mode Gagal & Jangkauan Ledakan: bagaimana perubahan konfigurasi yang satu ini menyebar menjadi outage, & bagaimana menulis item tindakan yang tidak menyalahkan untuk mencegah ulangan.

- Otomatisasi & Kapasitas: apa yang harus diukur di tepi untuk mengetahui bahwa sesuatu rusak sebelum pengguna melakukannya.

Setiap pelajaran bisa berdiri sendiri. Dibandingkan, mereka memberikan model mental tentang armada skala web.

Pelajaran Tambahan: geometry_of_proxies_and_origins merekam segalanya dalam pelajaran ini sebagai grafik terarah & menjelajahi apa yang teori grafik katakan tentang jalur permintaan.

Baik sekali. Terus maju.