Ringkasan Load Balancer Aplikasi Eksternal

Dokumen ini memperkenalkan konsep yang perlu Anda pahami untuk mengonfigurasi Load Balancer Aplikasi eksternal.

Load Balancer Aplikasi eksternal adalah load balancer Lapisan 7 berbasis proxy yang memungkinkan Anda menjalankan dan menskalakan layanan di balik satu alamat IP eksternal. Load Balancer Aplikasi eksternal mendistribusikan traffic HTTP dan HTTPS ke backend yang dihosting di berbagaiGoogle Cloud platform (seperti Compute Engine, Google Kubernetes Engine (GKE), dan Cloud Storage), serta backend eksternal yang terhubung melalui internet atau melalui konektivitas hibrida. Untuk mengetahui detailnya, lihat Ringkasan Load Balancer Aplikasi: Kasus penggunaan.

Mode operasi

Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal dalam mode berikut:

• Load Balancer Aplikasi eksternal global. Load balancer ini adalah load balancer global yang diimplementasikan sebagai layanan terkelola di Google Front Ends (GFE). Layanan ini menggunakan proxy Envoy open source untuk mendukung kemampuan pengelolaan traffic lanjutan seperti pencerminan traffic, pemisahan traffic berbasis bobot, dan transformasi header berbasis permintaan atau berbasis respons.
• Load Balancer Aplikasi Klasik. Ini adalah Load Balancer Aplikasi eksternal klasik yang bersifat global dalam Paket Premium, tetapi dapat dikonfigurasi agar bersifat regional dalam Paket Standar. Load balancer ini diterapkan di Google Front End (GFE). GFE didistribusikan secara global dan beroperasi bersama menggunakan jaringan global dan bidang kontrol Google.
• Load Balancer Aplikasi eksternal regional. Ini adalah load balancer regional yang diimplementasikan sebagai layanan terkelola di proxy Envoy open source. Fitur ini mencakup kemampuan pengelolaan traffic lanjutan seperti pencerminan traffic, pemisahan traffic berbasis bobot, dan transformasi header berbasis permintaan atau respons.

Mengidentifikasi mode

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

Arsitektur

Resource berikut diperlukan untuk deployment Load Balancer Aplikasi eksternal:

• Khusus untuk Load Balancer Aplikasi eksternal regional, subnet khusus proxy digunakan untuk mengirim koneksi dari load balancer ke backend.

• Aturan penerusan eksternal menentukan alamat IP eksternal, port, dan proxy HTTP(S) target. Klien menggunakan alamat IP dan port untuk terhubung ke load balancer.

• Proxy HTTP(S) target menerima permintaan dari klien. Proxy HTTP(S) mengevaluasi permintaan menggunakan peta URL untuk membuat keputusan perutean traffic. Proxy juga dapat mengautentikasi komunikasi dengan menggunakan sertifikat SSL.

  • Untuk load balancing HTTPS, proxy HTTPS target menggunakan sertifikat SSL untuk membuktikan identitasnya kepada klien. Proxy HTTPS target mendukung hingga jumlah sertifikat SSL yang didokumentasikan.

• Proxy HTTP(S) menggunakan peta URL untuk membuat penentuan perutean berdasarkan atribut HTTP (seperti jalur permintaan, cookie, atau header). Berdasarkan keputusan pemilihan rute, proxy meneruskan permintaan klien ke layanan backend atau bucket backend tertentu. Peta URL dapat menentukan tindakan tambahan, seperti mengirim pengalihan ke klien.

• Layanan backend mendistribusikan permintaan ke backend yang sehat. Load Balancer Aplikasi eksternal global juga mendukung bucket backend. Satu atau beberapa backend harus terhubung ke layanan backend atau bucket backend.

• Health check secara berkala memantau kesiapan backend Anda. Tindakan ini mengurangi risiko permintaan dikirim ke backend yang tidak dapat melayani permintaan.

• Aturan firewall untuk backend Anda agar menerima pemeriksaan health check. Load Balancer Aplikasi eksternal regional memerlukan aturan firewall tambahan untuk mengizinkan traffic dari subnet khusus proxy menjangkau backend.

Global

Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi eksternal global. Arsitektur ini berlaku untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik di Paket Premium.

Regional

Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi eksternal regional.

Subnet khusus proxy

Subnet khusus proxy hanya diperlukan untuk Load Balancer Aplikasi eksternal regional.

Subnet khusus proxy menyediakan serangkaian alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Anda harus membuat satu subnet khusus proxy di setiap region jaringan VPC tempat Anda menggunakan Load Balancer Aplikasi eksternal regional. Flag --purpose untuk subnet khusus proxy ini ditetapkan ke REGIONAL_MANAGED_PROXY. Semua load balancer berbasis Envoy regional di region dan jaringan VPC yang sama berbagi kumpulan proxy Envoy dari subnet khusus proxy yang sama. Selanjutnya:

• Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
• VM atau endpoint backend dari semua Load Balancer Aplikasi eksternal regional di region dan jaringan VPC menerima koneksi dari subnet khusus proxy.
• Alamat IP Load Balancer Aplikasi eksternal regional tidak berada di subnet khusus proxy. Alamat IP load balancer ditentukan oleh aturan penerusan terkelola eksternalnya, yang dijelaskan di bawah.

Jika sebelumnya Anda membuat subnet khusus proxy dengan --purpose=INTERNAL_HTTPS_LOAD_BALANCER, migrasikan tujuan subnet ke REGIONAL_MANAGED_PROXY sebelum Anda dapat membuat load balancer berbasis Envoy lainnya di region yang sama dengan jaringan VPC.

Aturan penerusan dan alamat IP

Aturan penerusan merutekan traffic menurut alamat IP, port, dan protokol ke konfigurasi load balancing yang terdiri dari proxy target, peta URL, dan satu atau beberapa layanan backend.

Spesifikasi alamat IP. Setiap aturan penerusan menyediakan satu alamat IP yang dapat digunakan dalam catatan DNS untuk aplikasi Anda. Tidak diperlukan load balancing berbasis DNS. Anda dapat menentukan alamat IP yang akan digunakan atau membiarkan Cloud Load Balancing menetapkannya untuk Anda.

Spesifikasi port. Setiap aturan penerusan untuk Load Balancer Aplikasi dapat mereferensikan satu port dari 1-65535. Untuk mendukung beberapa port, Anda harus mengonfigurasi beberapa aturan penerusan. Anda dapat mengonfigurasi beberapa aturan penerusan untuk menggunakan alamat IP eksternal (VIP) yang sama dan mereferensikan proxy HTTP(S) target yang sama selama kombinasi alamat IP, port, dan protokol secara keseluruhan unik untuk setiap aturan penerusan. Dengan cara ini, Anda dapat menggunakan satu load balancer dengan peta URL bersama sebagai proxy untuk beberapa aplikasi.

Jenis aturan penerusan, alamat IP, dan skema load balancing yang digunakan oleh Load Balancer Aplikasi eksternal bergantung pada mode load balancer dan Tingkat Layanan Jaringan tempat load balancer berada.

Untuk mengetahui daftar lengkap protokol yang didukung oleh aturan penerusan Load Balancer Aplikasi eksternal dalam setiap mode, lihat Fitur load balancer.

Aturan penerusan dan jaringan VPC

Bagian ini menjelaskan cara aturan penerusan yang digunakan oleh Load Balancer Aplikasi eksternal dikaitkan dengan jaringan VPC.

Proxy target

Proxy target menghentikan koneksi HTTP(S) dari klien. Satu atau beberapa aturan penerusan mengarahkan traffic ke proxy target, dan proxy target berkonsultasi dengan peta URL untuk menentukan cara merutekan traffic ke backend.

Jangan mengandalkan proxy untuk mempertahankan huruf besar/kecil nama header permintaan atau respons. Misalnya, header respons Server: Apache/1.0 mungkin muncul di klien sebagai server: Apache/1.0.

Tabel berikut menentukan jenis proxy target yang diperlukan oleh Load Balancer Aplikasi eksternal.

Selain header yang ditambahkan oleh proxy target, load balancer menyesuaikan header HTTP lainnya dengan cara berikut:

• Untuk Load Balancer Aplikasi eksternal global, header permintaan dan respons dapat dikonversi menjadi huruf kecil.

  Satu-satunya pengecualian untuk hal ini adalah saat Anda menggunakan backend NEG internet global dengan HTTP/1.1. Untuk mengetahui detail tentang cara header HTTP/1.1 diproses dengan NEG internet global, lihat ringkasan NEG internet.

• Untuk Load Balancer Aplikasi klasik, header permintaan dan respons dikonversi menjadi huruf kecil, kecuali saat Anda menggunakan HTTP/1.1. Dengan HTTP/1.1, header ditulis dengan huruf kapital yang tepat. Huruf pertama kunci header dan setiap huruf setelah tanda hubung (-) dikapitalisasi untuk mempertahankan kompatibilitas dengan klien HTTP/1.1. Misalnya, user-agent diubah menjadi User-Agent, dan content-encoding diubah menjadi Content-Encoding.

• Beberapa header digabungkan. Jika ada beberapa instance dari kunci header yang sama (misalnya, Via), load balancer akan menggabungkan nilainya menjadi satu daftar yang dipisahkan koma untuk satu kunci header. Hanya header yang nilainya dapat direpresentasikan sebagai daftar yang dipisahkan koma yang digabungkan. Header lain, seperti Set-Cookie, tidak pernah digabungkan.

Header host

Saat membuat permintaan HTTP, load balancer mempertahankan header Host permintaan asli.

Header X-Forwarded-For

Load balancer menambahkan dua alamat IP ke header X-Forwarded-For, yang dipisahkan oleh satu koma, dalam urutan berikut:

1. Alamat IP klien yang terhubung ke load balancer
2. Alamat IP aturan penerusan load balancer

Jika permintaan masuk tidak menyertakan header X-Forwarded-For, header yang dihasilkan adalah sebagai berikut:

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Jika permintaan masuk sudah menyertakan header X-Forwarded-For, load balancer akan menambahkan nilainya ke header yang ada:

X-Forwarded-For: <existing-value>,<client-ip>,<load-balancer-ip>

Menghapus nilai header yang ada menggunakan header permintaan kustom

Anda dapat menghapus nilai header yang ada menggunakan header permintaan kustom di layanan backend. Contoh berikut menggunakan flag --custom-request-header untuk membuat ulang header X-Forwarded-For dengan menggunakan variabel client_ip_address dan server_ip_address. Konfigurasi ini menggantikan header X-Forwarded-For masuk hanya dengan alamat IP klien dan load balancer.

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

Cara software proxy terbalik backend dapat mengubah header X-Forwarded-For

Jika backend load balancer Anda menjalankan software reverse proxy HTTP, software tersebut dapat menambahkan satu atau kedua alamat IP berikut ke akhir header X-Forwarded-For:

1. Alamat IP GFE yang terhubung ke backend. Alamat IP GFE berada dalam rentang 130.211.0.0/22 dan 35.191.0.0/16.

2. Alamat IP sistem backend itu sendiri.

Akibatnya, sistem upstream mungkin melihat header X-Forwarded-For yang disusun sebagai berikut:

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

Dukungan Cloud Trace

Trace tidak didukung dengan Load Balancer Aplikasi. Load Balancer Aplikasi global dan klasik menambahkan header X-Cloud-Trace-Context jika tidak ada. Load Balancer Aplikasi eksternal regional tidak menambahkan header ini. Jika header X-Cloud-Trace-Context sudah ada, header tersebut akan melewati load balancer tanpa diubah. Namun, tidak ada rekaman aktivitas atau rentang yang diekspor oleh load balancer.

Peta URL

Peta URL menentukan pola pencocokan untuk perutean berbasis URL dari permintaan ke layanan backend yang sesuai. Peta URL memungkinkan Anda membagi traffic dengan memeriksa komponen URL untuk mengirim permintaan ke berbagai set backend. Layanan default ditentukan untuk menangani permintaan yang tidak cocok dengan aturan host atau aturan pencocokan jalur yang ditentukan.

Dalam beberapa situasi, seperti contoh load balancing multi-region, Anda mungkin tidak menentukan aturan URL apa pun dan hanya mengandalkan layanan default.

Peta URL mendukung beberapa fitur pengelolaan traffic lanjutan seperti pengarahan traffic berbasis header, pemisahan traffic berbasis bobot, dan pencerminan permintaan. Untuk informasi selengkapnya, lihat referensi berikut:

• Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global

• Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal regional

Tabel berikut menentukan jenis peta URL yang diperlukan oleh Load Balancer Aplikasi eksternal di setiap mode.

Sertifikat SSL

Load Balancer Aplikasi Eksternal yang menggunakan proxy HTTPS target memerlukan kunci pribadi dan sertifikat SSL sebagai bagian dari konfigurasi load balancer.

• Google Cloud menyediakan dua metode konfigurasi untuk menetapkan kunci pribadi dan sertifikat SSL ke proxy HTTPS target: sertifikat SSL Compute Engine dan Certificate Manager. Untuk mengetahui deskripsi setiap konfigurasi, lihat Metode konfigurasi sertifikat di ringkasan sertifikat SSL.

• Google Cloud menyediakan dua jenis sertifikat: Dikelola sendiri dan Dikelola Google. Untuk mengetahui deskripsi setiap jenis, lihat Jenis sertifikat di ringkasan sertifikat SSL.

Jenis Load Balancer Aplikasi eksternal (global, regional, atau klasik) menentukan metode konfigurasi dan jenis sertifikat yang didukung. Untuk mengetahui detailnya, lihat Sertifikat dan load balancer di ringkasan sertifikat SSL. Google Cloud

Kebijakan SSL

Kebijakan SSL menentukan serangkaian fitur SSL yang digunakan load balancer saat menegosiasikan SSL dengan klien. Google Cloud

Secara default, Load Balancing HTTPS menggunakan serangkaian fitur SSL yang memberikan keamanan yang baik dan kompatibilitas yang luas. Beberapa aplikasi memerlukan kontrol yang lebih besar atas versi dan cipher SSL yang digunakan untuk koneksi HTTPS atau SSL mereka. Anda dapat menentukan kebijakan SSL untuk menentukan serangkaian fitur SSL yang digunakan load balancer saat menegosiasikan SSL dengan klien. Selain itu, Anda dapat menerapkan kebijakan SSL tersebut ke proxy HTTPS target.

Tabel berikut menentukan dukungan kebijakan SSL untuk load balancer di setiap mode.

Layanan backend

Layanan backend memberikan informasi konfigurasi ke load balancer sehingga load balancer dapat mengarahkan permintaan ke backend-nya—misalnya, grup instance Compute Engine atau grup endpoint jaringan (NEG). Untuk mengetahui informasi selengkapnya tentang layanan backend, lihat Ringkasan layanan backend.

Untuk contoh yang menunjukkan cara menyiapkan load balancer dengan layanan backend dan backend Compute Engine, lihat Menyiapkan Load Balancer Aplikasi eksternal dengan backend Compute Engine.

Cakupan layanan backend

Tabel berikut menunjukkan resource dan cakupan layanan backend yang digunakan oleh Load Balancer Aplikasi eksternal:

Protokol ke backend

Layanan backend untuk Load Balancer Aplikasi harus menggunakan salah satu protokol berikut untuk mengirim permintaan ke backend:

• HTTP, yang menggunakan HTTP/1.1 dan tidak ada TLS
• HTTPS, yang menggunakan HTTP/1.1 dan TLS
• HTTP/2, yang menggunakan HTTP/2 dan TLS (HTTP/2 tanpa enkripsi tidak didukung).
• H2C, yang menggunakan HTTP/2 melalui TCP. TLS tidak diperlukan. H2C tidak didukung untuk Load Balancer Aplikasi klasik.

Load balancer hanya menggunakan protokol layanan backend yang Anda tentukan untuk berkomunikasi dengan backend-nya. Load balancer tidak melakukan failover ke protokol lain jika tidak dapat berkomunikasi dengan backend menggunakan protokol layanan backend yang ditentukan.

Protokol layanan backend tidak harus cocok dengan protokol yang digunakan oleh klien untuk berkomunikasi dengan load balancer. Misalnya, klien dapat mengirim permintaan ke load balancer menggunakan HTTP/2, tetapi load balancer dapat berkomunikasi dengan backend menggunakan HTTP/1.1 (HTTP atau HTTPS).

Bucket backend

Bucket backend mengarahkan traffic masuk langsung ke bucket Cloud Storage. Untuk contoh yang menunjukkan cara menambahkan bucket ke Load Balancer Aplikasi eksternal, lihat Menyiapkan load balancer dengan bucket backend. Untuk informasi umum tentang Cloud Storage, lihat Apa itu Cloud Storage?

Backend

Tabel berikut menentukan backend dan fitur terkait yang didukung oleh Load Balancer Aplikasi eksternal di setiap mode.

Backend dan jaringan VPC

Batasan lokasi backend dapat berada bergantung pada jenis load balancer.

Untuk backend Load Balancer Aplikasi eksternal global, hal berikut berlaku:

• Instance backend (untuk backend grup instance) dan endpoint backend (untuk backend NEG) dapat berada di jaringan VPC mana pun dalam organisasi yang sama. Jaringan VPC yang berbeda tidak perlu terhubung menggunakan Peering Jaringan VPC karena GFE berkomunikasi langsung dengan backend di jaringan VPC masing-masing.

• Bucket Cloud Storage tidak dikaitkan dengan jaringan VPC. Resource ini dapat berada di project mana pun dalam organisasi yang sama.

  Load Balancer Aplikasi eksternal global juga mendukung lingkungan VPC Bersama tempat Anda dapat berbagi jaringan VPC dan resource terkaitnya di seluruh project. Namun, untuk Load Balancer Aplikasi eksternal global, Anda tidak perlu mengonfigurasi VPC Bersama agar dapat mereferensikan layanan backend atau bucket backend dari project lain di organisasi Anda.

Untuk backend Load Balancer Aplikasi klasik, hal berikut berlaku:

• Semua instance backend dari backend grup instance dan semua endpoint backend dari backend NEG harus berada di project yang sama. Namun, backend grup instance atau NEG dapat menggunakan jaringan VPC yang berbeda dalam project tersebut. Jaringan VPC yang berbeda tidak perlu dihubungkan menggunakan Peering Jaringan VPC karena GFE berkomunikasi langsung dengan backend di jaringan VPC masing-masing.

• Bucket Cloud Storage tidak dikaitkan dengan jaringan VPC. Namun, backend harus berada dalam project yang sama dengan load balancer.

Untuk backend Load Balancer Aplikasi eksternal regional, hal berikut berlaku:

• Untuk grup instance, NEG zonal, dan NEG konektivitas hibrida, semua backend harus berada di project dan region yang sama dengan layanan backend. Namun, load balancer dapat mereferensikan backend yang menggunakan jaringan VPC yang berbeda dalam project yang sama dengan layanan backend. Konektivitas antara jaringan VPC load balancer dan jaringan VPC backend dapat dikonfigurasi menggunakan Peering Jaringan VPC, tunnel Cloud VPN, lampiran VLAN Cloud Interconnect, atau framework Network Connectivity Center.

  Definisi jaringan backend

  • Untuk NEG zonal dan NEG hybrid, Anda secara eksplisit menentukan jaringan VPC saat membuat NEG.
  • Untuk grup instance terkelola, jaringan VPC ditentukan dalam template instance.
  • Untuk grup instance tidak terkelola, jaringan VPC grup instance ditetapkan agar cocok dengan jaringan VPC antarmuka nic0 untuk VM pertama yang ditambahkan ke grup instance.

  Persyaratan jaringan backend

  Jaringan backend Anda harus memenuhi salah satu persyaratan jaringan berikut:

  • Jaringan VPC backend harus sama persis dengan jaringan VPC aturan penerusan.

  • Jaringan VPC backend harus terhubung ke jaringan VPC aturan penerusan menggunakan Peering Jaringan VPC. Anda harus mengonfigurasi pertukaran rute subnet untuk mengizinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh instance atau endpoint backend.

• Jaringan VPC backend dan jaringan VPC aturan penerusan harus berupa spoke VPC yang terhubung ke hub Network Connectivity Center yang sama. Filter impor dan ekspor harus mengizinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh instance atau endpoint backend.

• Untuk semua jenis backend lainnya, semua backend harus berada di region dan jaringan VPC yang sama.

  Load Balancer Aplikasi eksternal regional juga mendukung lingkungan VPC Bersama tempat Anda dapat berbagi jaringan VPC dan resource terkaitnya di seluruh project. Jika Anda ingin layanan backend dan backend Load Balancer Aplikasi eksternal regional berada di project yang berbeda dari aturan penerusan, Anda harus mengonfigurasi load balancer di lingkungan VPC Bersama dengan referensi layanan lintas project.

Backend dan antarmuka jaringan

Jika Anda menggunakan backend grup instance, paket akan selalu dikirimkan ke nic0. Jika Anda ingin mengirim paket ke antarmuka non-nic0 (baik vNIC atau Antarmuka Jaringan Dinamis), gunakan backend NEG.

Jika Anda menggunakan backend NEG zonal, paket akan dikirim ke antarmuka jaringan apa pun yang diwakili oleh endpoint di NEG. Endpoint NEG harus berada di jaringan VPC yang sama dengan jaringan VPC yang ditentukan secara eksplisit oleh NEG.

Health check

Setiap layanan backend menentukan health check yang secara berkala memantau kesiapan backend untuk menerima koneksi dari load balancer. Hal ini mengurangi risiko permintaan dapat dikirim ke backend yang tidak dapat melayani permintaan. Health check tidak memeriksa apakah aplikasi itu sendiri berfungsi.

Untuk pemeriksaan health check, Anda harus membuat aturan firewall masuk yang mengizinkan pemeriksaan health check menjangkau instance backend Anda. Biasanya, pemeriksaan health check berasal dari mekanisme pemeriksaan kondisi terpusat Google.

Load Balancer Aplikasi eksternal regional yang menggunakan backend NEG hibrida adalah pengecualian terhadap aturan ini karena health check-nya berasal dari subnet khusus proxy. Untuk mengetahui detailnya, lihat Ringkasan NEG hibrida.

Protokol health check

Meskipun tidak wajib dan tidak selalu memungkinkan, sebaiknya gunakan health check yang protokolnya cocok dengan protokol layanan backend. Misalnya, health check HTTP/2 paling akurat menguji konektivitas HTTP/2 ke backend. Sebaliknya, Load Balancer Aplikasi eksternal regional yang menggunakan backend NEG hybrid tidak mendukung health check gRPC. Untuk mengetahui daftar protokol health check yang didukung, lihat Fitur load balancing.

Tabel berikut menentukan cakupan health check yang didukung oleh Load Balancer Aplikasi eksternal dalam setiap mode.

Untuk mengetahui informasi selengkapnya tentang pemeriksaan kondisi, lihat artikel berikut:

• Ringkasan health check
• Membuat health check

Aturan firewall

Load balancer memerlukan aturan firewall berikut:

• Untuk Load Balancer Aplikasi eksternal global, aturan izinkan masuk untuk mengizinkan traffic dari Google Front End (GFE) menjangkau backend Anda. Untuk Load Balancer Aplikasi eksternal regional, aturan izinkan masuk untuk mengizinkan traffic dari subnet khusus proxy menjangkau backend Anda.
• Aturan izin masuk untuk mengizinkan traffic dari rentang pemeriksaan health check. Untuk mengetahui informasi selengkapnya tentang pemeriksaan health check dan alasan perlunya mengizinkan traffic dari pemeriksaan tersebut, lihat Aturan firewall dan rentang IP pemeriksaan.

Aturan firewall diterapkan di tingkat instance VM, bukan di proxy GFE. Anda tidak dapat menggunakan aturan firewall Google Cloud untuk mencegah traffic mencapai load balancer. Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, Anda dapat menggunakan Google Cloud Armor untuk melakukannya.

Port untuk aturan firewall ini harus dikonfigurasi sebagai berikut:

• Izinkan traffic ke port tujuan untuk health check setiap layanan backend.

• Untuk backend grup instance: Tentukan port yang akan dikonfigurasi dengan pemetaan antara port bernama layanan backend dan nomor port yang terkait dengan port bernama tersebut di setiap grup instance. Nomor port dapat bervariasi di antara grup instance yang ditetapkan ke layanan backend yang sama.

• Untuk backend NEG GCE_VM_IP_PORT: Izinkan traffic ke nomor port endpoint.

Tabel berikut merangkum rentang alamat IP sumber yang diperlukan untuk aturan firewall:

Dukungan GKE

GKE menggunakan Load Balancer Aplikasi eksternal dengan cara berikut:

• Gateway eksternal yang dibuat menggunakan pengontrol Gateway GKE dapat menggunakan mode Load Balancer Aplikasi eksternal apa pun. Anda mengontrol mode load balancer dengan memilih GatewayClass. Pengontrol GKE Gateway selalu menggunakan backend NEG zonal GCE_VM_IP_PORT.

• Ingress eksternal yang dibuat menggunakan pengontrol Ingress GKE selalu berupa Load Balancer Aplikasi klasik. Pengontrol GKE Ingress lebih memilih menggunakan backend NEG zonal GCE_VM_IP_PORT, meskipun backend grup instance juga didukung.

• Anda dapat menggunakan NEG zonal GCE_VM_IP_PORT yang dibuat dan dikelola oleh Layanan GKE sebagai backend untuk Load Balancer Aplikasi atau Load Balancer Jaringan Proxy. Untuk mengetahui informasi selengkapnya, lihat Load balancing berbasis container melalui NEG zona mandiri.

Arsitektur VPC Bersama

Load Balancer Aplikasi eksternal mendukung jaringan yang menggunakan VPC Bersama. VPC Bersama memungkinkan organisasi menghubungkan resource dari beberapa project ke jaringan VPC umum sehingga resource tersebut dapat berkomunikasi satu sama lain secara aman dan efisien menggunakan alamat IP internal dari jaringan tersebut. Jika Anda belum memahami VPC Bersama, baca Ringkasan VPC Bersama.

Ada banyak cara untuk mengonfigurasi Load Balancer Aplikasi eksternal dalam jaringan VPC Bersama. Terlepas dari jenis deployment, semua komponen load balancer harus berada di organisasi yang sama.

Meskipun Anda dapat membuat semua komponen load balancing dan backend di project host VPC Bersama, jenis deployment ini tidak memisahkan tanggung jawab administrasi jaringan dan pengembangan layanan.

Semua komponen dan backend load balancer dalam project layanan

Diagram arsitektur berikut menunjukkan deployment VPC Bersama standar dengan semua komponen load balancer dan backend berada dalam project layanan. Jenis deployment ini didukung oleh semua Load Balancer Aplikasi.

Komponen load balancer dan backend harus menggunakan jaringan VPC yang sama.

Backend serverless di lingkungan VPC Bersama

Untuk load balancer yang menggunakan backend NEG serverless, layanan Cloud Run atau Cloud Run Functions backend harus berada dalam project yang sama dengan NEG serverless.

Selain itu, untuk Load Balancer Aplikasi eksternal regional yang mendukung referensi layanan lintas project, layanan backend, NEG serverless, dan layanan Cloud Run harus selalu berada dalam project layanan yang sama.

Referensi layanan lintas project

Referensi layanan lintas project adalah model deployment yang menempatkan frontend dan peta URL load balancer di satu project, serta layanan backend dan backend load balancer di project yang berbeda.

Referensi layanan lintas project memungkinkan organisasi mengonfigurasi satu load balancer pusat dan merutekan traffic ke ratusan layanan yang didistribusikan di beberapa project yang berbeda. Anda dapat mengelola semua aturan dan kebijakan perutean traffic secara terpusat dalam satu peta URL. Anda juga dapat mengaitkan load balancer dengan satu set nama host dan sertifikat SSL. Oleh karena itu, Anda dapat mengoptimalkan jumlah load balancer yang diperlukan untuk men-deploy aplikasi, serta menurunkan kemudahan pengelolaan, biaya operasional, dan persyaratan kuota.

Dengan memiliki project yang berbeda untuk setiap tim fungsional, Anda juga dapat mencapai pemisahan peran dalam organisasi. Pemilik layanan dapat berfokus pada pembuatan layanan dalam project layanan, sementara tim jaringan dapat menyediakan dan memelihara load balancer dalam project lain, dan keduanya dapat terhubung menggunakan referensi layanan lintas project.

Pemilik layanan dapat mempertahankan otonomi atas eksposur layanan mereka dan mengontrol pengguna mana yang dapat mengakses layanan mereka dengan menggunakan load balancer. Hal ini dicapai dengan peran IAM khusus yang disebut peran Compute Load Balancer Services User (roles/compute.loadBalancerServiceUser).

Dukungan referensi layanan lintas project berbeda-beda berdasarkan jenis load balancer:

• Untuk Load Balancer Aplikasi eksternal global: frontend dan peta URL load balancer Anda dapat mereferensikan layanan backend atau bucket backend dari project mana pun dalam organisasi yang sama. Tidak ada batasan jaringan VPC yang berlaku. Meskipun Anda dapat menggunakan lingkungan VPC Bersama untuk mengonfigurasi deployment lintas project seperti yang ditunjukkan dalam contoh ini, hal ini bukan persyaratan.

• Untuk Load Balancer Aplikasi eksternal regional: Anda harus membuat load balancer di lingkungan VPC Bersama. Frontend dan peta URL load balancer harus berada di project host atau layanan, dan layanan backend serta backend load balancer dapat didistribusikan di project host atau layanan dalam lingkungan VPC Bersama yang sama.

Untuk mempelajari cara mengonfigurasi VPC Bersama untuk Load Balancer Aplikasi eksternal regional—dengan dan tanpa referensi layanan lintas project—lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan VPC Bersama.

Catatan penggunaan untuk referensi layanan lintas project

• Referensi layanan lintas project dapat digunakan dengan grup instance, NEG tanpa server, dan sebagian besar jenis backend lain yang didukung. Namun, batasan berikut berlaku:

  • Dengan Load Balancer Aplikasi eksternal global, Anda tidak dapat mereferensikan layanan backend lintas project jika layanan backend memiliki backend NEG serverless dengan App Engine.

  • Dengan Load Balancer Aplikasi eksternal regional, Anda tidak dapat mereferensikan layanan backend lintas project jika layanan backend memiliki backend NEG internet regional.
• Referensi layanan lintas project tidak didukung untuk Load Balancer Aplikasi klasik.
• Google Cloud tidak membedakan resource (misalnya, layanan backend) yang menggunakan nama yang sama di beberapa project. Oleh karena itu, saat Anda menggunakan referensi layanan lintas project, sebaiknya Anda menggunakan nama layanan backend yang unik di seluruh project dalam organisasi Anda.
• Jika Anda melihat error seperti "Referensi lintas project untuk resource ini tidak diizinkan", pastikan Anda memiliki izin untuk menggunakan resource tersebut. Administrator project yang memiliki resource harus memberi Anda peran Pengguna Layanan Load Balancer Compute (roles/compute.loadBalancerServiceUser). Peran ini dapat diberikan di tingkat project atau di tingkat resource. Untuk contoh, lihat Memberikan izin kepada Admin Load Balancer Compute untuk menggunakan layanan backend atau bucket backend.

Contoh 1: Frontend dan backend load balancer di project layanan yang berbeda

Berikut adalah contoh deployment VPC Bersama di mana frontend dan peta URL load balancer dibuat di project layanan A dan peta URL mereferensikan layanan backend di project layanan B.

Dalam hal ini, Admin Jaringan atau Admin Load Balancer di project layanan A memerlukan akses ke layanan backend di project layanan B. Admin project layanan B memberikan peran Compute Load Balancer Services User (roles/compute.loadBalancerServiceUser) kepada Admin Load Balancer di project layanan A yang ingin mereferensikan layanan backend di project layanan B.

Contoh 2: Frontend load balancer di project host dan backend di project layanan

Berikut adalah contoh deployment VPC Bersama tempat frontend dan peta URL load balancer dibuat di project host, serta layanan backend (dan backend) dibuat di project layanan.

Dalam kasus ini, Admin Jaringan atau Admin Load Balancer di project host memerlukan akses ke layanan backend di project layanan. Admin project layanan memberikan peran Compute Load Balancer Services User (roles/compute.loadBalancerServiceUser) kepada Admin Load Balancer di project host A yang ingin mereferensikan layanan backend di project layanan.

Contoh 3: Frontend dan backend load balancer dalam project yang berbeda

Berikut adalah contoh deployment tempat frontend dan peta URL Load Balancer Aplikasi eksternal global dibuat di project yang berbeda dari layanan backend dan backend load balancer. Jenis deployment ini tidak menggunakan VPC Bersama dan hanya didukung untuk Load Balancer Aplikasi eksternal global.

Untuk mempelajari lebih lanjut penyiapan ini, lihat Menyiapkan referensi layanan lintas project dengan layanan backend dan bucket backend.

Ketersediaan tinggi dan failover

Ketersediaan tinggi dan failover di Load Balancer Aplikasi eksternal dapat dikonfigurasi di tingkat load balancer. Hal ini ditangani dengan membuat Load Balancer Aplikasi eksternal regional cadangan di region mana pun yang memerlukan pencadangan.

Tabel berikut menjelaskan perilaku failover.

Dukungan HTTP/2

HTTP/2 adalah revisi besar protokol HTTP/1. Ada 2 mode dukungan HTTP/2:

• HTTP/2 melalui TLS
• HTTP/2 Cleartext melalui TCP

HTTP/2 melalui TLS

HTTP/2 melalui TLS didukung untuk koneksi antara klien dan Load Balancer Aplikasi eksternal, serta untuk koneksi antara load balancer dan backend-nya.

Load balancer otomatis menegosiasikan HTTP/2 dengan klien sebagai bagian dari handshake TLS menggunakan ekstensi TLS ALPN. Meskipun load balancer dikonfigurasi untuk menggunakan HTTPS, klien modern secara default menggunakan HTTP/2. Hal ini dikontrol di klien, bukan di load balancer.

Jika klien tidak mendukung HTTP/2 dan load balancer dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan instance backend, load balancer mungkin masih menegosiasikan koneksi HTTPS atau menerima permintaan HTTP yang tidak aman. Permintaan HTTPS atau HTTP tersebut kemudian diubah oleh load balancer untuk memproksi permintaan melalui HTTP/2 ke instance backend.

Untuk menggunakan HTTP/2 melalui TLS, Anda harus mengaktifkan TLS di backend dan menetapkan protokol layanan backend ke HTTP2. Untuk mengetahui informasi selengkapnya, lihat Enkripsi dari load balancer ke backend.

Streaming serentak maksimum HTTP/2

Setelan HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS menjelaskan jumlah maksimum aliran yang diterima endpoint, yang dimulai oleh peer. Nilai yang diiklankan oleh klien HTTP/2 ke load balancerGoogle Cloud pada dasarnya tidak berarti karena load balancer tidak memulai streaming ke klien.

Jika load balancer menggunakan HTTP/2 untuk berkomunikasi dengan server yang berjalan di VM, load balancer akan mematuhi nilai SETTINGS_MAX_CONCURRENT_STREAMS yang diiklankan oleh server. Jika nilai nol diiklankan, load balancer tidak dapat meneruskan permintaan ke server, dan hal ini dapat menyebabkan error.

Batasan HTTP/2

• HTTP/2 antara load balancer dan instance dapat memerlukan koneksi TCP yang jauh lebih banyak ke instance daripada HTTP atau HTTPS. Penggabungan koneksi, pengoptimalan yang mengurangi jumlah koneksi ini dengan HTTP atau HTTPS, tidak tersedia dengan HTTP/2. Akibatnya, Anda mungkin melihat latensi backend yang tinggi karena koneksi backend dibuat lebih sering.
• HTTP/2 antara load balancer dan backend tidak mendukung menjalankan Protokol WebSocket melalui satu aliran koneksi HTTP/2 (RFC 8441).
• HTTP/2 antara load balancer dan backend tidak mendukung push server.
• Volume permintaan dan rasio error gRPC tidak terlihat di Google Cloud API atau konsol Google Cloud . Jika endpoint gRPC menampilkan error, log load balancer dan data pemantauan akan melaporkan kode status HTTP 200 OK.

HTTP/2 teks biasa melalui TCP (H2C)

HTTP/2 cleartext melalui TCP, juga dikenal sebagai H2C, memungkinkan Anda menggunakan HTTP/2 tanpa TLS. H2C didukung untuk kedua koneksi berikut:

• Koneksi antara klien dan load balancer. Tidak diperlukan konfigurasi khusus.

• Koneksi antara load balancer dan backend-nya.

  Untuk mengonfigurasi H2C untuk koneksi antara load balancer dan backend-nya, Anda menetapkan protokol layanan backend ke H2C.

Dukungan H2C juga tersedia untuk load balancer yang dibuat menggunakan pengontrol Gateway GKE dan Cloud Service Mesh.

H2C tidak didukung untuk Load Balancer Aplikasi klasik.

Dukungan HTTP/3

HTTP/3 adalah protokol internet generasi berikutnya. HTTP/3 dibangun di atas IETF QUIC, sebuah protokol yang dikembangkan dari protokol Google QUIC asli. HTTP/3 didukung antara Load Balancer Aplikasi eksternal, Cloud CDN, dan klien.

Secara khusus:

• IETF QUIC adalah protokol lapisan transport yang menyediakan kontrol kemacetan dan keandalan yang serupa dengan TCP, menggunakan TLS 1.3 untuk keamanan, dan performa yang lebih baik.
• HTTP/3 adalah lapisan aplikasi yang dibangun di atas IETF QUIC, dan bergantung pada QUIC untuk menangani multiplexing, kontrol kemacetan, deteksi kehilangan, dan transmisi ulang.
• HTTP/3 memungkinkan inisiasi koneksi klien yang lebih cepat, menghentikan pemblokiran head-of-line di stream multipleks, dan mendukung migrasi koneksi saat alamat IP klien berubah.
• HTTP/3 didukung untuk koneksi antara klien dan load balancer, bukan koneksi antara load balancer dan backend-nya.
• Koneksi HTTP/3 menggunakan algoritma kontrol kemacetan BBR.

HTTP/3 di load balancer Anda dapat meningkatkan waktu pemuatan halaman web, mengurangi buffering ulang video, dan meningkatkan throughput pada koneksi latensi yang lebih tinggi.

Tabel berikut menentukan dukungan HTTP/3 untuk Load Balancer Aplikasi eksternal di setiap mode.

Cara negosiasi HTTP/3

Jika HTTP/3 diaktifkan, load balancer akan mengiklankan dukungan ini kepada klien, sehingga klien yang mendukung HTTP/3 dapat mencoba membuat koneksi HTTP/3 dengan load balancer HTTPS.

• Klien yang diimplementasikan dengan benar selalu melakukan penggantian ke HTTPS atau HTTP/2 jika tidak dapat membuat koneksi HTTP/3.
• Klien yang mendukung HTTP/3 menggunakan pengetahuan sebelumnya yang di-cache tentang dukungan HTTP/3 untuk menghemat perjalanan pulang pergi yang tidak perlu di masa mendatang.
• Karena penggantian ini, mengaktifkan atau menonaktifkan HTTP/3 di load balancer tidak mengganggu kemampuan load balancer untuk terhubung ke klien.

Dukungan diiklankan di header respons HTTP Alt-Svc. Jika HTTP/3 diaktifkan, respons dari load balancer mencakup nilai header alt-svc berikut:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

Jika HTTP/3 telah ditetapkan secara eksplisit ke DISABLE, respons tidak menyertakan header respons alt-svc.

Jika Anda telah mengaktifkan HTTP/3 di load balancer HTTPS, beberapa situasi dapat menyebabkan klien Anda melakukan penggantian ke HTTPS atau HTTP/2, bukan melakukan negosiasi HTTP/3. Contoh ini meliputi:

• Saat klien mendukung versi HTTP/3 yang tidak kompatibel dengan versi HTTP/3 yang didukung oleh load balancer HTTPS.
• Saat load balancer mendeteksi bahwa traffic UDP diblokir atau dibatasi lajunya dengan cara yang mencegah HTTP/3 berfungsi.
• Klien tidak mendukung HTTP/3 sama sekali, sehingga tidak mencoba menegosiasikan koneksi HTTP/3.

Saat koneksi kembali ke HTTPS atau HTTP/2, kami tidak menghitungnya sebagai kegagalan load balancer.

Sebelum mengaktifkan HTTP/3, pastikan perilaku yang dijelaskan sebelumnya dapat diterima untuk beban kerja Anda.

Mengonfigurasi HTTP/3

NONE (default) dan ENABLE mengaktifkan dukungan HTTP/3 untuk load balancer Anda.

Jika HTTP/3 diaktifkan, load balancer akan mengiklankannya kepada klien, sehingga klien yang mendukungnya dapat melakukan negosiasi versi HTTP/3 dengan load balancer. Klien yang tidak mendukung HTTP/3 tidak melakukan negosiasi koneksi HTTP/3. Anda tidak perlu menonaktifkan HTTP/3 secara eksplisit kecuali jika Anda telah mengidentifikasi penerapan klien yang rusak.

Load Balancer Aplikasi Eksternal menyediakan tiga cara untuk mengonfigurasi HTTP/3 seperti yang ditunjukkan dalam tabel berikut.

Untuk mengaktifkan (atau menonaktifkan) HTTP/3 secara eksplisit, ikuti langkah-langkah berikut.

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

Dukungan WebSocket

Load balancer berbasis HTTP(S) mendukung protokol websocket saat Anda menggunakan HTTP atau HTTPS sebagai protokol ke backend.Google Cloud Load balancer tidak memerlukan konfigurasi apa pun untuk memproksi koneksi websocket.

Protokol websocket menyediakan saluran komunikasi full-duplex antara klien dan load balancer. Untuk mengetahui informasi selengkapnya, lihat RFC 6455.

Protokol websocket berfungsi sebagai berikut:

1. Load balancer mengenali permintaan websocket Upgrade dari klien HTTP atau HTTPS. Permintaan berisi header Connection: Upgrade dan Upgrade: websocket, diikuti dengan header permintaan terkait websocket lainnya yang relevan.
2. Backend mengirim respons websocket Upgrade. Instance backend mengirimkan respons 101 switching protocol dengan header Connection: Upgrade dan Upgrade: websocket serta header respons terkait websocket lainnya.
3. Load balancer memproksi traffic dua arah selama durasi koneksi saat ini.

Jika instance backend menampilkan kode status 426 atau 502, load balancer akan menutup koneksi.

Afinitas sesi untuk websocket berfungsi sama seperti untuk permintaan lainnya. Untuk mengetahui informasi selengkapnya, lihat Afinitas sesi.

Dukungan gRPC

gRPC adalah framework open source untuk remote procedure call. gRPC didasarkan pada standar HTTP/2. Kasus penggunaan untuk gRPC mencakup hal berikut:

• Sistem terdistribusi yang berlatensi rendah dan sangat skalabel
• Mengembangkan klien seluler yang berkomunikasi dengan server cloud
• Merancang protokol baru yang harus akurat, efisien, dan tidak bergantung pada bahasa
• Desain berlapis untuk mengaktifkan ekstensi, autentikasi, dan logging

Untuk menggunakan gRPC dengan aplikasi Google Cloud , Anda harus mem-proxy permintaan end-to-end melalui HTTP/2. Untuk melakukannya, Anda membuat Load Balancer Aplikasi dengan salah satu konfigurasi berikut:

• Untuk traffic tidak terenkripsi end-to-end (tanpa TLS): Anda membuat load balancer HTTP (dikonfigurasi dengan proxy HTTP target). Selain itu, Anda mengonfigurasi load balancer untuk menggunakan HTTP/2 untuk koneksi yang tidak dienkripsi antara load balancer dan backend-nya dengan menyetel protokol layanan backend ke H2C.

• Untuk traffic terenkripsi end-to-end (dengan TLS): Anda membuat load balancer HTTPS (dikonfigurasi dengan proxy HTTPS target dan sertifikat SSL). Load balancer menegosiasikan HTTP/2 dengan klien sebagai bagian dari handshake SSL menggunakan ekstensi TLS ALPN.

  Selain itu, Anda harus memastikan bahwa backend dapat menangani traffic TLS dan mengonfigurasi load balancer untuk menggunakan HTTP/2 untuk koneksi terenkripsi antara load balancer dan backend-nya dengan menyetel protokol layanan backend ke HTTP2.

  Load balancer mungkin masih melakukan negosiasi HTTPS dengan beberapa klien atau menerima permintaan HTTP yang tidak aman pada load balancer yang dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan instance backend. Permintaan HTTP atau HTTPS tersebut diubah oleh load balancer untuk memproksi permintaan melalui HTTP/2 ke instance backend.

Jika Anda ingin mengonfigurasi Load Balancer Aplikasi menggunakan HTTP/2 dengan Ingress Google Kubernetes Engine atau menggunakan gRPC dan HTTP/2 dengan Ingress, lihat HTTP/2 untuk load balancing dengan Ingress.

Jika Anda ingin mengonfigurasi Load Balancer Aplikasi eksternal menggunakan HTTP/2 dengan Cloud Run, lihat Menggunakan HTTP/2 di balik load balancer.

Untuk mengetahui informasi tentang cara memecahkan masalah HTTP/2, lihat Memecahkan masalah HTTP/2 ke backend.

Untuk mengetahui informasi tentang batasan HTTP/2, lihat Batasan HTTP/2.

Dukungan TLS

Secara default, proxy target HTTPS hanya menerima TLS 1.0, 1.1, 1.2, dan 1.3 saat menghentikan permintaan SSL klien.

Jika menggunakan HTTPS sebagai protokol layanan backend, Load Balancer Aplikasi klasik dapat melakukan negosiasi TLS 1.0, 1.1, 1.2, atau 1.3 ke backend.

Dukungan TLS bersama

TLS timbal balik, atau mTLS, adalah protokol standar industri untuk autentikasi timbal balik antara klien dan server. mTLS membantu memastikan bahwa klien dan server saling mengautentikasi dengan memverifikasi bahwa masing-masing memegang sertifikat valid yang dikeluarkan oleh otoritas sertifikat (CA) tepercaya. Tidak seperti TLS standar, yang hanya mengautentikasi server, mTLS mengharuskan klien dan server untuk memberikan sertifikat, yang mengonfirmasi identitas kedua pihak sebelum komunikasi dilakukan.

Semua Load Balancer Aplikasi mendukung mTLS. Dengan mTLS, load balancer meminta klien mengirimkan sertifikat untuk mengautentikasi dirinya sendiri selama handshake TLS dengan load balancer. Anda dapat mengonfigurasi trust store Certificate Manager yang kemudian digunakan load balancer untuk memvalidasi rantai kepercayaan sertifikat klien.

Untuk mengetahui informasi selengkapnya tentang mTLS, lihat Autentikasi TLS bersama.

Dukungan data awal TLS 1.3

Data awal TLS 1.3 didukung di proxy HTTPS target dari Load Balancer Aplikasi eksternal berikut untuk HTTPS melalui TCP (HTTP/1.1, HTTP/2) dan HTTP/3 melalui QUIC:

• Load Balancer Aplikasi eksternal global
• Load Balancer Aplikasi Klasik

TLS 1.3 ditentukan dalam RFC 8446 dan memperkenalkan konsep data awal, yang juga dikenal sebagai data zero-round-trip time (0-RTT), yang dapat meningkatkan performa aplikasi untuk koneksi yang dilanjutkan sebesar 30 hingga 50%.

Dengan TLS 1.2, dua perjalanan pulang pergi diperlukan sebelum data dapat ditransmisikan dengan aman. TLS 1.3 mengurangi hal ini menjadi satu round trip (1-RTT) untuk koneksi baru, sehingga klien dapat mengirim data aplikasi segera setelah respons server pertama. Selain itu, TLS 1.3 memperkenalkan konsep data awal untuk sesi yang dilanjutkan, sehingga memungkinkan klien mengirim data aplikasi dengan ClientHello awal, sehingga mengurangi waktu perjalanan pulang pergi yang efektif menjadi nol (0-RTT). Data awal TLS 1.3 memungkinkan server backend mulai memproses data klien sebelum proses handshake dengan klien selesai, sehingga mengurangi latensi; namun, tindakan pencegahan harus dilakukan untuk memitigasi risiko serangan replay.

Karena data awal dikirim sebelum handshake selesai, penyerang dapat mencoba mengambil dan memutar ulang permintaan. Untuk memitigasi hal ini, server backend harus mengontrol penggunaan data awal dengan cermat, membatasi penggunaannya pada permintaan idempotensi. Metode HTTP yang dimaksudkan agar bersifat idempoten, tetapi dapat memicu perubahan non-idempoten—seperti permintaan GET yang mengubah database—tidak boleh menerima data awal. Dalam kasus tersebut, server backend harus menolak permintaan dengan header HTTP Early-Data: 1 dengan menampilkan kode status HTTP 425 Too Early.

Permintaan dengan data awal memiliki header HTTP Early-Data yang ditetapkan ke nilai 1, yang menunjukkan kepada server backend bahwa permintaan telah disampaikan dalam data awal TLS. Header ini juga menunjukkan bahwa klien memahami kode status HTTP 425 Too Early.

Mode data awal TLS (0-RTT)

Anda dapat mengonfigurasi data awal TLS menggunakan salah satu mode berikut pada resource proxy HTTPS target load balancer.

• STRICT. Hal ini memungkinkan data awal TLS 1.3 untuk permintaan dengan metode HTTP yang aman (GET, HEAD, OPTIONS, TRACE), dan permintaan HTTP yang tidak memiliki parameter kueri. Permintaan yang mengirim data awal yang berisi metode HTTP non-idempotent (seperti POST atau PUT) atau dengan parameter kueri ditolak dengan kode status HTTP 425.

• PERMISSIVE. Hal ini memungkinkan data awal TLS 1.3 untuk permintaan dengan metode HTTP yang aman (GET, HEAD, OPTIONS, TRACE). Mode ini tidak menolak permintaan yang menyertakan parameter kueri. Pemilik aplikasi harus memastikan bahwa data awal aman digunakan untuk setiap jalur permintaan, terutama untuk endpoint tempat pemutaran ulang permintaan dapat menyebabkan efek samping yang tidak diinginkan, seperti update database atau logging yang dipicu oleh permintaan GET.

• DISABLED. Early data TLS 1.3 tidak diiklankan, dan setiap upaya (tidak valid) untuk mengirim early data akan ditolak. Jika aplikasi Anda tidak dilengkapi untuk menangani permintaan data awal dengan aman, Anda harus menonaktifkan data awal. TLS 1.3 early data dinonaktifkan secara default.

• UNRESTRICTED (tidak direkomendasikan untuk sebagian besar beban kerja). Hal ini memungkinkan data awal TLS 1.3 untuk permintaan dengan metode HTTP apa pun, termasuk metode non-idempoten, seperti POST. Mode ini tidak menerapkan batasan lain. Mode ini dapat berguna untuk kasus penggunaan gRPC. Namun, sebaiknya Anda tidak menggunakan metode ini kecuali jika Anda telah mengevaluasi postur keamanan dan memitigasi risiko serangan replay menggunakan mekanisme lain.

Mengonfigurasi data awal TLS

Untuk mengaktifkan atau menonaktifkan data awal TLS secara eksplisit, lakukan hal berikut:

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

Setelah mengonfigurasi data awal TLS, Anda dapat mengeluarkan permintaan dari klien HTTP yang mendukung data awal TLS. Anda dapat mengamati latensi yang lebih rendah untuk permintaan yang dilanjutkan.

Jika klien yang tidak mematuhi RFC mengirimkan permintaan dengan metode yang tidak bersifat idempoten atau dengan parameter kueri, permintaan akan ditolak. Anda melihat kode status HTTP 425 Early di log load balancer dan respons HTTP berikut:

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

Batasan

• Load balancer HTTPS tidak mengirimkan close_notifypenutupan peringatan saat menghentikan koneksi SSL. Artinya, load balancer menutup koneksi TCP alih-alih melakukan penonaktifan SSL.

• Load balancer HTTPS hanya mendukung karakter huruf kecil dalam domain di atribut nama umum (CN) atau atribut nama alternatif subjek (SAN) sertifikat. Sertifikat dengan karakter huruf besar di domain hanya ditampilkan jika ditetapkan sebagai sertifikat primer di proxy target.

• Load balancer HTTPS tidak menggunakan ekstensi Server Name Indication (SNI) saat terhubung ke backend, kecuali untuk load balancer dengan backend NEG Internet. Untuk mengetahui informasi selengkapnya, lihat Enkripsi dari load balancer ke backend.

• Google Cloud tidak menjamin bahwa koneksi TCP yang mendasarinya dapat tetap terbuka selama durasi nilai waktu tunggu layanan backend. Sistem klien harus menerapkan logika percobaan ulang, bukan mengandalkan koneksi TCP agar tetap terbuka dalam jangka waktu yang lama.

• Saat Anda membuat Load Balancer Aplikasi eksternal regional di Paket Premium menggunakan konsolGoogle Cloud , hanya region yang mendukung Paket Standar yang tersedia di konsol Google Cloud . Untuk akses ke region lain, gunakan gcloud CLI atau API.

• Proxy GFE yang digunakan oleh Load Balancer Aplikasi global dan klasik tidak mendukung respons awal 200 OK yang dikirim sebelum payload POST permintaan diproxy sepenuhnya ke backend. Mengirim respons 200 OK awal menyebabkan GFE menutup koneksi ke backend.

  Backend Anda harus merespons dengan respons 100 Continue setelah header permintaan diterima, lalu menunggu hingga payload POST permintaan di-proxy sepenuhnya sebelum merespons dengan kode respons 200 OK akhir.

• Saat menggunakan Load Balancer Aplikasi eksternal regional dengan Cloud Run di lingkungan VPC Bersama, jaringan VPC mandiri di project layanan dapat mengirim traffic ke layanan Cloud Run lainnya yang di-deploy di project layanan lain dalam lingkungan VPC Bersama yang sama. Ini adalah masalah umum.

• Cloud CDN memungkinkan Anda memaksa objek atau sekumpulan objek diabaikan oleh cache dengan meminta invalidasi cache. Saat Anda menggunakan Load Balancer Aplikasi eksternal global dengan referensi layanan lintas project VPC Bersama, secara default, admin project layanan tidak akan memiliki izin yang diperlukan untuk meminta pembatalan validasi cache. Hal ini karena pembatalan cache dikonfigurasi di project frontend (yaitu, project yang memiliki aturan penerusan, proxy target, dan peta URL load balancer). Oleh karena itu, pembatalan validasi cache hanya dapat dilakukan oleh akun utama yang memiliki peran IAM untuk mengonfigurasi resource terkait load balancer di project frontend (misalnya, peran Compute Network Admin). Admin layanan, yang mengontrol penyediaan layanan backend di project terpisah, harus berkoordinasi dengan administrator load balancer project frontend untuk mengeluarkan pembatalan cache bagi layanan lintas project mereka.

Langkah berikutnya

• Untuk mempelajari cara Load Balancer Aplikasi eksternal menangani koneksi, merutekan traffic, dan mempertahankan afinitas sesi, lihat Distribusi permintaan untuk Load Balancer Aplikasi eksternal.

• Untuk mempelajari cara men-deploy Load Balancer Aplikasi eksternal global, lihat Menyiapkan Load Balancer Aplikasi eksternal dengan backend Compute Engine.

• Untuk mempelajari cara men-deploy Load Balancer Aplikasi eksternal regional, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan backend Compute Engine.

• Jika Anda adalah pengguna Load Balancer Aplikasi klasik, pastikan Anda meninjau Ringkasan migrasi saat merencanakan deployment baru dengan Load Balancer Aplikasi eksternal global.

• Untuk mempelajari cara mengotomatiskan penyiapan Load Balancer Aplikasi eksternal dengan Terraform, lihat Contoh modul Terraform untuk Load Balancer Aplikasi eksternal.

• Untuk mempelajari cara mengonfigurasi kemampuan pengelolaan traffic lanjutan yang tersedia dengan Load Balancer Aplikasi eksternal global, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal global.

• Untuk mempelajari cara mengonfigurasi kemampuan pengelolaan traffic lanjutan yang tersedia dengan Load Balancer Aplikasi eksternal regional, lihat Ringkasan pengelolaan traffic untuk Load Balancer Aplikasi eksternal regional.

• Untuk mempelajari cara menayangkan situs, lihat Menayangkan situs.

• Untuk menemukan lokasi PoP Google, lihat Lokasi GFE.

• Untuk mempelajari pengelolaan kapasitas, lihat tutorial Pengelolaan kapasitas dengan load balancing dan Pengoptimalan kapasitas aplikasi dengan load balancing global.

• Untuk mempelajari cara menggunakan Certificate Manager untuk menyediakan dan mengelola sertifikat SSL, lihat Ringkasan Certificate Manager.

• Untuk menyisipkan logika kustom ke jalur data load balancing, konfigurasi plugin atau callout Ekstensi Layanan.

• Khusus untuk Load Balancer Aplikasi eksternal regional, Anda dapat mencoba menggunakan Penemuan API Shadow Apigee untuk menemukan API shadow (juga dikenal sebagai API yang tidak terdokumentasi) di infrastrukturGoogle Cloud yang ada. Pastikan Anda membaca batasan terkait sebelum mengaktifkan Penemuan Shadow API.