Ringkasan Load Balancer Aplikasi Eksternal

Dokumen ini memperkenalkan konsep yang perlu Anda pahami tentang cara 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 berbagai platformGoogle Cloud (seperti Compute Engine, Google Kubernetes Engine (GKE), dan Cloud Storage), serta backend eksternal yang terhubung melalui internet atau melalui konektivitas hybrid. Untuk mengetahui detailnya, lihat Ringkasan Load Balancer Aplikasi: Kasus penggunaan.

Mode operasi

Load balancer ini tersedia untuk Anda dalam mode regional, dan selanjutnya disebut sebagai Load Balancer Aplikasi eksternal regional. Load balancer diimplementasikan sebagai layanan terkelola berdasarkan proxy Envoy open source. Gateway ini mencakup kemampuan pengelolaan traffic lanjutan seperti pencerminan traffic, pemisahan traffic berbasis bobot, dan transformasi header berbasis permintaan atau berbasis respons. Mode regional memastikan bahwa semua klien dan backend berada di region yang ditentukan. Gunakan load balancer ini jika Anda ingin menyajikan konten hanya dari satu geolokasi (misalnya, untuk memenuhi peraturan kepatuhan).

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 pemilihan rute traffic. Proxy juga dapat mengautentikasi komunikasi menggunakan sertifikat SSL.

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

• 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 responsif.

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

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

Regional

Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi eksternal regional.

Komponen Load Balancer Aplikasi eksternal regional (klik untuk memperbesar).

Subnet khusus proxy

Subnet khusus proxy menyediakan sekumpulan 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 regional berbasis Envoy 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 backend atau endpoint dari semua Load Balancer Aplikasi eksternal regional di suatu 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.
• Subnet khusus proxy dapat dikonfigurasi dengan jenis stack IPV4_IPV6 atau IPV4_ONLY.

Jika sebelumnya Anda telah 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 jaringan VPC yang sama.

Aturan penerusan dan alamat IP

Pratinjau — Load Balancer Aplikasi lintas region, eksternal regional, dan internal regional mendukung penghentian traffic IPv6

Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Aturan penerusan merutekan traffic berdasarkan 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 data DNS untuk aplikasi Anda. Tidak diperlukan load balancing berbasis DNS. Anda dapat menentukan alamat IPv4 atau IPv6 yang akan digunakan atau mengizinkan 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 merujuk ke proxy HTTP(S) target yang sama, asalkan keseluruhan kombinasi alamat IP, port, dan protokol bersifat 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 Network Service Tier tempat load balancer berada.

Mode load balancer	Network Service Tier	Aturan penerusan, alamat IP, dan skema load balancing	Pemilihan rute dari internet ke frontend load balancer
Load Balancer Aplikasi eksternal regional	Paket Premium	Aturan penerusan eksternal regional Alamat IP eksternal regional Skema load balancing: EXTERNAL_MANAGED	Permintaan mencapai Google Cloud di PoP yang paling dekat dengan klien. Permintaan kemudian dirutekan melalui backbone premium Google Cloudhingga mencapai proxy Envoy di region yang sama dengan load balancer.

Untuk mengetahui daftar lengkap protokol yang didukung oleh aturan penerusan Load Balancer Aplikasi eksternal di 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.

Mode load balancer

Pengaitan jaringan VPC

Load Balancer Aplikasi eksternal regional

Jaringan VPC aturan penerusan adalah jaringan tempat subnet khusus proxy dibuat. Anda menentukan jaringan saat membuat aturan penerusan. Bergantung pada apakah Anda menggunakan alamat IPv4 atau rentang alamat IPv6, selalu ada jaringan VPC eksplisit atau implisit yang terkait dengan aturan penerusan. Alamat IPv4 eksternal regional selalu ada di luar jaringan VPC. Namun, saat membuat aturan penerusan, Anda harus menentukan jaringan VPC tempat subnet khusus proxy telah dibuat. Oleh karena itu, aturan penerusan memiliki pengaitan jaringan yang eksplisit. Rentang alamat IPv6 eksternal regional selalu ada di dalam jaringan VPC. Saat membuat aturan penerusan, Anda harus menentukan subnet tempat rentang alamat IP diambil. Subnet ini harus berada di region dan jaringan VPC yang sama dengan tempat subnet khusus proxy dibuat. Dengan demikian, ada pengaitan jaringan tersirat. Persyaratan jaringan dan subnet. Untuk traffic IPv6, jaringan dan subnet Anda harus memenuhi persyaratan konfigurasi berikut: Jaringan VPC: Anda harus menggunakan jaringan VPC mode kustom yang dikonfigurasi dengan flag --enable-ula-internal-ipv6. Subnet aturan penerusan: subnet ini harus berupa subnet dual-stack (IPv4_IPv6) atau IPV6_ONLY dengan ipv6-access-type ditetapkan ke EXTERNAL. Opsi alokasi alamat IPv6. Aturan penerusan harus merujuk ke rentang alamat IPv6 /96 dari rentang alamat IPv6 eksternal /64 subnet. Batasan. Untuk menentukan alamat IPv6 sementara kustom, Anda harus menggunakan Google Cloud CLI atau API. Konsol Google Cloud tidak mendukung penentuan alamat IPv6 sementara kustom untuk aturan penerusan.

Proxy target

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

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

Catatan: Untuk Grup Endpoint Jaringan (NEG) internet, permintaan dari load balancer berasal dari rentang IP yang berbeda, bergantung pada jenis NEG (global atau regional). Untuk mengetahui informasi selengkapnya, baca bagian Mengautentikasi permintaan.

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

Mode load balancer	Jenis proxy target	Header yang ditambahkan proxy	Header kustom didukung
Load Balancer Aplikasi eksternal regional	HTTP Regional, HTTPS Regional	X-Forwarded-Proto: [http | https] (khusus permintaan) Via: 1.1 google (permintaan dan respons) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (lihat header X-Forwarded-For) (khusus permintaan)	Dikonfigurasi di peta URL

Catatan: Sesuai dengan RFC 2616 , header hop-by-hop berikut tidak disebarkan oleh proxy target: Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding, dan Upgrade.

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

• Beberapa header digabungkan. Jika ada beberapa instance 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 comma separated list yang digabungkan. Header lain, seperti Set-Cookie, tidak pernah digabungkan.

Header host

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

Header X-Forwarded-For

Load balancer menambahkan dua alamat IP ke header X-Forwarded-For, yang dipisahkan dengan 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>

Perhatian: Load balancer tidak memverifikasi alamat IP apa pun yang mendahului <client-ip>,<load-balancer-ip> di header ini. Alamat IP sebelumnya mungkin berisi karakter lain, termasuk spasi.

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 menggunakan variabel client_ip_address dan server_ip_address. Konfigurasi ini mengganti header X-Forwarded-For yang masuk hanya dengan alamat IP klien dan load balancer.

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

Catatan: Pendekatan ini akan menghapus nilai X-Forwarded-For yang ada dari permintaan. Karena Google Cloud tidak mencatat nilai header, nilai ini tidak dapat dipulihkan. Jika perlu mempertahankan konten header asli, Anda dapat menyimpannya di header kustom terpisah.

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

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

1. Alamat IP GFE yang terhubung ke backend. Rentang proxy GFE tercantum dalam dokumen Aturan firewall.

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 trace atau span yang diekspor oleh load balancer.

Peta URL

Peta URL menentukan pola pencocokan untuk perutean permintaan berbasis URL 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 apa pun yang tidak cocok dengan aturan host atau aturan pencocokan jalur yang ditentukan.

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 regional

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

Mode load balancer	Jenis peta URL
Load Balancer Aplikasi eksternal regional	Regional

Sertifikat SSL

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

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

Load Balancer Aplikasi eksternal regional mendukung sertifikat SSL Compute Engine yang dikelola sendiri.

Kebijakan SSL

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

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

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

Mode load balancer	Kebijakan SSL yang didukung
Load Balancer Aplikasi eksternal regional

Layanan backend

Layanan backend memberikan informasi konfigurasi ke load balancer agar 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.

Cakupan layanan backend

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

Mode load balancer	Resource layanan backend
Load Balancer Aplikasi eksternal regional	regionBackendServices (regional)

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 tanpa 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 akan beralih ke protokol lain jika tidak dapat berkomunikasi dengan backend menggunakan protokol layanan backend yang ditentukan.

Protokol layanan backend tidak perlu sama 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).

Backend

Load Balancer Aplikasi eksternal regional mendukung jenis backend berikut:

• Grup instance
• NEG Zona
• NEG Internet

Backend dan jaringan VPC

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

• Untuk grup instance, NEG zona, dan NEG konektivitas hybrid, semua backend harus berada di project dan region yang sama dengan layanan backend. Namun, load balancer dapat mereferensikan backend yang menggunakan jaringan VPC 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, atau lampiran VLAN Cloud Interconnect.

  Definisi jaringan backend

  • Untuk NEG zona 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 memungkinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh backend instance atau endpoint.

  Persyaratan subnet IPv6 backend

  Pratinjau — Load Balancer Aplikasi lintas region, eksternal regional, dan internal regional mendukung penghentian traffic IPv6

  Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

  Versi IP yang digunakan untuk koneksi frontend tidak bergantung pada koneksi backend. Karena subnet khusus proxy adalah dual-stack (IPV4_IPV6), subnet khusus proxy dapat berkomunikasi dengan backend menggunakan IPv4 atau IPv6.

  Jika backend instance Anda menangani traffic IPv6, subnet backend dapat dikonfigurasi dengan jenis stack IPV4_ONLY atau IPV4_IPV6 (stack ganda). Jika jenis stack subnet backend menyertakan IPv6, Anda harus secara eksplisit menetapkan ipv6-access-type subnet ke EXTERNAL.

• Untuk semua jenis backend lainnya, semua backend harus berada di jaringan VPC dan region 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 dengan 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 dikirim ke nic0. Jika Anda ingin mengirim paket ke antarmuka non-nic0 (vNIC atau Dynamic Network Interface), gunakan backend NEG.

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

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 dikirim ke backend yang tidak dapat melayani permintaan tersebut. Health check tidak memeriksa apakah aplikasi itu sendiri berfungsi.

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

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

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 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.

Mode load balancer	Jenis health check
Load Balancer Aplikasi eksternal regional	Regional

Untuk mengetahui informasi selengkapnya tentang health check, lihat referensi berikut:

• Ringkasan health check
• Membuat health check

Aturan firewall

Load balancer memerlukan aturan firewall berikut:

• Untuk Load Balancer Aplikasi eksternal regional, aturan izinkan ingress untuk mengizinkan traffic dari subnet khusus proxy menjangkau backend Anda.
• Aturan izinkan ingress 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 Memeriksa rentang IP dan aturan firewall.

Aturan firewall diterapkan di level instance VM, bukan di proxy GFE. Anda tidak dapat menggunakan Google Cloud aturan firewall untuk mencegah traffic mencapai load balancer.

Port untuk aturan firewall ini harus dikonfigurasi sebagai berikut:

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

• Misalnya backend grup instance: Tentukan port yang akan dikonfigurasi oleh 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.

Penting: Pastikan untuk mengizinkan paket dari rentang health check lengkap. Jika aturan firewall Anda hanya mengizinkan paket dari sebagian rentang, Anda mungkin akan melihat kegagalan health check karena load balancer tidak dapat berkomunikasi dengan backend Anda. Hal ini menyebabkan respons kode status HTTP 502.

Dukungan GKE

GKE menggunakan Load Balancer Aplikasi eksternal dengan cara berikut:

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

  Saat Cloud CDN diaktifkan untuk backend yang dikelola oleh Gateway GKE, caching dikonfigurasi menggunakan filter GCPHTTPFilter GKE yang dilampirkan ke resource HTTPRoute. Untuk mengetahui informasi tentang cara mengonfigurasi caching, lihat Mengonfigurasi Cloud CDN untuk Gateway.

• Anda dapat menggunakan NEG zona GCE_VM_IP_PORT yang dibuat dan dikelola oleh Layanan GKE sebagai backend untuk Load Balancer Aplikasi atau Load Balancer Jaringan Proxy apa pun. 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.

Load balancer	Komponen frontend	Komponen backend
Load Balancer Aplikasi eksternal regional	Buat jaringan dan subnet khusus proxy yang diperlukan di project host VPC Bersama. Alamat IP eksternal regional, aturan penerusan, proxy HTTP(S) target, dan peta URL terkait harus ditentukan dalam project yang sama. Project ini dapat berupa project host atau project layanan.	Anda dapat melakukan salah satu hal berikut: Buat layanan backend dan backend (grup instance, NEG serverless, atau jenis backend lain yang didukung) di project layanan yang sama dengan komponen frontend. Buat layanan backend dan backend (grup instance, NEG serverless, atau jenis backend lain yang didukung) di sebanyak mungkin project layanan yang diperlukan. Satu peta URL dapat mereferensikan layanan backend di berbagai project. Jenis deployment ini dikenal sebagai referensi layanan lintas project. Setiap layanan backend harus ditentukan dalam project yang sama dengan backend yang dirujuknya. Health check yang terkait dengan layanan backend juga harus ditentukan dalam project yang sama dengan layanan backend.

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 dan backend load balancer harus menggunakan jaringan VPC yang sama.

Load Balancer Aplikasi eksternal regional di jaringan VPC Bersama (klik untuk memperbesar).

Referensi layanan lintas project

Referensi layanan lintas project adalah model deployment tempat frontend dan peta URL load balancer berada dalam satu project, sedangkan layanan backend dan backend load balancer berada dalam 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 pemilihan rute 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 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 membangun layanan dalam project layanan, sementara tim jaringan dapat menyediakan dan memelihara load balancer di project lain, dan keduanya dapat dihubungkan menggunakan referensi layanan lintas project.

Pemilik layanan dapat mempertahankan otonomi atas eksposur layanan mereka dan mengontrol pengguna mana yang dapat mengakses layanan mereka 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 bukanlah 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 seluruh project host atau layanan di lingkungan VPC Bersama yang sama.

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

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

• Google Cloud tidak membedakan antara resource (misalnya, layanan backend) yang menggunakan nama yang sama di beberapa project. Oleh karena itu, saat 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 Compute Load Balancer Services User (roles/compute.loadBalancerServiceUser). Peran ini dapat diberikan di level project atau di level resource. Misalnya, 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 tempat frontend dan peta URL load balancer dibuat di project layanan A dan peta URL mereferensikan layanan backend di project layanan B.

Dalam hal ini, Network Admin atau Load Balancer Admin 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.

Frontend dan backend load balancer di project layanan yang berbeda (klik untuk memperbesar).

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, dan layanan backend (dan backend) dibuat di project layanan.

Dalam hal 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.

Frontend load balancer dan peta URL di project host (klik untuk memperbesar).

Contoh 3: Frontend dan backend load balancer di 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.

Frontend dan backend load balancer di berbagai project (klik untuk memperbesar).

Untuk mempelajari penyiapan ini lebih lanjut, 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 level load balancer. Hal ini ditangani dengan membuat Load Balancer Aplikasi eksternal regional cadangan di region mana pun yang memerlukan cadangan.

Tabel berikut menjelaskan perilaku failover.

Mode load balancer

Metode failover

Load Balancer Aplikasi eksternal regional

Gunakan salah satu metode berikut untuk memastikan deployment dengan tingkat ketersediaan tinggi: Anda dapat mengonfigurasi konfigurasi failover aktif-pasif, yang mengalihkan traffic ke Load Balancer Aplikasi eksternal regional cadangan. Anda menggunakan health check untuk mendeteksi pemadaman layanan dan kebijakan pemilihan rute failover Cloud DNS untuk merutekan traffic saat failover dipicu oleh health check yang gagal. Untuk mengetahui detailnya, lihat Failover untuk Load Balancer Aplikasi eksternal. Anda dapat mengonfigurasi konfigurasi failover aktif-aktif dengan men-deploy beberapa Load Balancer Aplikasi eksternal regional individual di region yang Anda tentukan paling mendukung traffic untuk aplikasi Anda. Anda menggunakan kebijakan perutean geolokasi Cloud DNS untuk merutekan traffic ke region yang sesuai berdasarkan asal permintaan klien. Anda juga dapat menggunakan health check untuk mendeteksi pemadaman layanan dan merutekan traffic hanya ke load balancer yang responsif. Untuk mengetahui detailnya, lihat Ketersediaan tinggi untuk Load Balancer Aplikasi eksternal regional.

Dukungan HTTP/2

HTTP/2 adalah revisi besar dari 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 TLS handshake menggunakan ekstensi TLS ALPN. Meskipun load balancer dikonfigurasi untuk menggunakan HTTPS, klien modern akan menggunakan HTTP/2 secara default. 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 backend instance, 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 mem-proxy permintaan melalui HTTP/2 ke backend instance.

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 streaming yang diterima endpoint, yang dimulai oleh peer. Nilai yang diiklankan oleh klien HTTP/2 ke load balancerGoogle Cloud secara efektif 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 mengikuti nilai SETTINGS_MAX_CONCURRENT_STREAMS yang diiklankan oleh server, hingga nilai maksimum 100. Dalam arah permintaan (Google Cloud load balancer → server gRPC), load balancer menggunakan frame SETTINGS awal dari server gRPC untuk menentukan jumlah streaming per koneksi yang dapat digunakan secara bersamaan. Jika server mengiklankan nilai yang lebih tinggi dari 100, load balancer akan menggunakan 100 sebagai jumlah maksimum streaming serentak. Jika nilai nol diiklankan, load balancer tidak dapat meneruskan permintaan ke server, dan hal ini dapat menyebabkan error.

Ukuran tabel header dinamis HTTP/2

HTTP/2 meningkatkan HTTP/1.1 secara signifikan dengan fitur seperti multiplexing dan kompresi header HPACK. HPACK menggunakan tabel dinamis yang meningkatkan kompresi header, sehingga semuanya menjadi lebih cepat. Untuk memahami dampak perubahan ukuran tabel header dinamis di HTTP/2, cara fitur ini dapat meningkatkan performa, dan cara bug tertentu di berbagai library klien HTTP dapat menyebabkan masalah dalam kompresi header HPACK, lihat artikel komunitas.

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 server push.
• Tingkat error gRPC dan volume permintaan 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 melalui TCP cleartext

HTTP/2 melalui TCP cleartext, yang diwakili oleh string "h2c" per RFC 7540, memungkinkan Anda menggunakan HTTP/2 tanpa enkripsi TLS. Fitur ini didukung untuk koneksi berikut:

• Klien ke load balancer: Didukung secara otomatis di Load Balancer Aplikasi eksternal regional; tidak diperlukan konfigurasi khusus.

  Penting: Untuk koneksi klien ke load balancer, H2C tidak didukung di Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik.

• Load balancer ke backend-nya: Didukung dengan menetapkan protokol layanan backend ke H2C.

  Penting: Untuk koneksi load balancer ke backend, H2C tidak didukung di Load Balancer Aplikasi klasik.

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

Dukungan WebSocket

Google Cloud Load balancer berbasis HTTP(S) mendukung protokol WebSocket saat Anda menggunakan HTTP/1.1 (HTTP atau HTTPS) atau HTTP/2 sebagai protokol ke backend. Load balancer tidak memerlukan konfigurasi apa pun untuk mem-proxy koneksi WebSocket.

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

Untuk koneksi HTTP/1.1, protokol WebSocket menggunakan mekanisme Upgrade HTTP/1.1 untuk mentransisikan koneksi TCP dari HTTP ke koneksi WebSocket. Protokol WebSocket melalui HTTP/1.1 berfungsi sebagai berikut:

1. Load balancer mengenali permintaan Upgrade WebSocket dari klien HTTP atau HTTPS. Permintaan berisi header Connection: Upgrade dan Upgrade: websocket, diikuti dengan header permintaan terkait WebSocket lainnya yang relevan.
2. Backend mengirimkan respons Upgrade WebSocket. Respons ini terdiri dari respons 101 Switching Protocols dengan header Connection: Upgrade dan Upgrade: websocket, serta header respons terkait WebSocket lainnya.
3. Load balancer mem-proxy traffic dua arah selama durasi koneksi saat ini.

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

Untuk koneksi HTTP/2, protokol WebSocket menggunakan metode CONNECT yang diperluas bersama dengan kolom pseudo-header (seperti :protocol) untuk membuat tunnel pada satu aliran HTTP/2 yang dapat membawa data untuk WebSockets (RFC 8441). Protokol WebSocket melalui HTTP/2 berfungsi sebagai berikut:

1. Server backend mengirimkan frame SETTINGS HTTP/2 yang berisi parameter SETTINGS_ENABLE_CONNECT_PROTOCOL yang ditetapkan ke 1. Tindakan ini memberi tahu load balancer bahwa backend mendukung metode CONNECT yang diperluas.

2. Setelah menerima setelan ini, load balancer akan mengenalinya dan dapat meneruskan permintaan upgrade WebSocket. Proxy ini mengirimkan permintaan upgrade ke backend menggunakan metode CONNECT yang diperluas. Permintaan berisi pseudo-header :method: CONNECT dan :protocol: websocket, beserta header permintaan terkait WebSocket lainnya yang relevan.

3. Backend mengirimkan respons berhasil WebSocket. Server backend mengirimkan respons 200 OK (bukan respons 101 Switching Protocols yang digunakan di HTTP/1.1) untuk membuat tunnel WebSocket melalui satu aliran koneksi HTTP/2.

4. Load balancer mem-proxy traffic dua arah melalui aliran HTTP/2 yang dibuat.

Jika backend instance menampilkan kode status 426 atau 502, upgrade WebSocket tidak akan terjadi, dan kode status akan disebarkan ke klien.

Waktu tunggu koneksi WebSocket bergantung pada jenis load balancer (global, regional, atau klasik). Untuk mengetahui detailnya, lihat Waktu tunggu layanan backend.

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 sangat skalabel dan berlatensi rendah
• 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, buat Load Balancer Aplikasi dengan salah satu konfigurasi berikut:

• HTTP/2 melalui TLS antara klien dan load balancer serta H2C antara load balancer dan backend: Anda membuat load balancer HTTPS (yang dikonfigurasi dengan proxy HTTPS target dan sertifikat SSL). Selain itu, Anda mengonfigurasi load balancer untuk menggunakan HTTP/2 untuk koneksi yang tidak dienkripsi antara load balancer dan backend-nya dengan menetapkan protokol layanan backend ke H2C.

• Traffic yang dienkripsi secara end-to-end menggunakan HTTP/2 melalui TLS: Anda membuat load balancer HTTPS (yang 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 menetapkan protokol layanan backend ke HTTP2.

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

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 terkait HTTP/2, lihat Memecahkan masalah terkait 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 Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi eksternal regional menggunakan HTTPS sebagai protokol layanan backend, keduanya dapat menegosiasikan TLS 1.2 atau 1.3 ke backend.

Jika Load Balancer Aplikasi klasik menggunakan HTTPS sebagai protokol layanan backend, load balancer tersebut dapat menegosiasikan TLS 1.0, 1.1, 1.2, atau 1.3 ke backend.

Dukungan TLS bersama

Mutual TLS, atau mTLS, adalah protokol standar industri untuk autentikasi bersama antara klien dan server. mTLS membantu memastikan bahwa klien dan server saling mengautentikasi dengan memverifikasi bahwa masing-masing memiliki sertifikat valid yang dikeluarkan oleh certificate authority (CA) tepercaya. Tidak seperti TLS standar, yang hanya mengautentikasi server, mTLS mengharuskan klien dan server untuk menunjukkan sertifikat, yang mengonfirmasi identitas kedua belah pihak sebelum komunikasi terjalin.

Semua Load Balancer Aplikasi mendukung mTLS. Dengan mTLS, load balancer meminta klien mengirim sertifikat untuk mengautentikasi dirinya sendiri selama TLS handshake 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

Catatan: TLS 1.3 early data atau 0-RTT hanya didukung untuk melanjutkan sesi sebelumnya antara klien dan Cloud CDN atau load balancer. Cloud CDN atau load balancer tidak dapat menggunakan data awal TLS saat meneruskan permintaan ke server asal.

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 didefinisikan 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, diperlukan dua perjalanan bolak-balik sebelum data dapat dikirimkan dengan aman. TLS 1.3 mengurangi hal ini menjadi satu perjalanan bolak-balik (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 klien dapat mengirim data aplikasi dengan ClientHello awal, sehingga mengurangi waktu round-trip 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, harus berhati-hati untuk mengurangi risiko replay.

Karena data awal dikirim sebelum handshake selesai, penyerang dapat mencoba menangkap dan memutar ulang permintaan. Untuk mengurangi risiko ini, server backend harus mengontrol penggunaan data awal dengan cermat, sehingga membatasi penggunaannya pada permintaan idempoten. Metode HTTP yang dimaksudkan untuk 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 Early-Data HTTP yang ditetapkan ke nilai 1, yang menunjukkan kepada server backend bahwa permintaan telah disampaikan dalam data awal TLS. Hal 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. Tindakan ini akan mengaktifkan 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-idempoten (seperti POST atau PUT) atau dengan parameter kueri akan ditolak dengan kode status HTTP 425.

• PERMISSIVE. Tindakan ini akan mengaktifkan TLS 1.3 early data 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 yang pemutaran ulang permintaannya dapat menyebabkan efek samping yang tidak diinginkan, seperti pencatatan log atau update database yang dipicu oleh permintaan GET.

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

• UNRESTRICTED (tidak direkomendasikan untuk sebagian besar workload). Tindakan ini akan mengaktifkan data awal TLS 1.3 untuk permintaan dengan metode HTTP apa pun, termasuk metode non-idempoten, seperti POST. Mode ini tidak menerapkan batasan lainnya. Mode ini dapat berguna untuk kasus penggunaan gRPC. Namun, kami tidak merekomendasikan 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:

Konsol

1. Di konsol Google Cloud , buka halaman Load balancing.

   Buka Load balancing

2. Pilih load balancer yang perlu Anda aktifkan early data-nya.

3. Klik Edit.

4. Klik Frontend configuration.

5. Pilih alamat IP dan port frontend yang ingin Anda edit. Untuk mengaktifkan data awal TLS, protokolnya harus HTTPS.

6. Dalam daftar Early data (0-RTT), pilih mode data awal TLS.

7. Klik Done.

8. Untuk memperbarui load balancer, klik Update.

gcloud

1. Konfigurasikan mode data awal TLS di proxy HTTPS target dari Load Balancer Aplikasi.

   gcloud compute target-https-proxies update TARGET_HTTPS_PROXY \
     --tls-early-data=TLS_EARLY_DATA_MODE
   

   Ganti kode berikut:

   • TARGET_HTTPS_PROXY: proxy HTTPS target load balancer Anda
   • TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED, atau UNRESTRICTED

API

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

Ganti kode berikut:

• TARGET_HTTPS_PROXY: proxy HTTPS target load balancer Anda
• TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED, atau UNRESTRICTED
• FINGERPRINT: string berenkode Base64. Sidik jari terbaru harus disediakan untuk mem-patch proxy HTTPS target; jika tidak, permintaan akan gagal dengan kode status HTTP 412 Precondition Failed.

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 mengirim permintaan dengan metode non-idempoten atau dengan parameter kueri, permintaan tersebut akan ditolak. Anda akan 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>
  

Gateway tag Google untuk pengiklan

Gateway tag Google memungkinkan pemilik situs menghosting dan men-deploy tag Google melalui Google Cloud. Tag Google ini membantu Anda menganalisis traffic di situs Anda. Anda dapat menggunakan Load Balancer Aplikasi eksternal global untuk mengarahkan traffic pengukuran di situs Anda melalui domain Anda guna meningkatkan akurasi data pengukuran. Hal ini memberikan data yang lebih andal untuk pengoptimalan kampanye iklan.

Perhatikan bahwa gateway tag Google hanya didukung di Load Balancer Aplikasi eksternal global. Jika Anda menggunakan Load Balancer Aplikasi klasik, migrasikan resource Anda dari Load Balancer Aplikasi klasik ke eksternal global.

Konfigurasi dan pengelolaan gateway tag Google dikelola di luar konsol Google Cloud . Anda harus mengonfigurasi fitur ini menggunakan antarmuka Google Tag Manager.

• Di konsol Google Cloud , halaman Detail load balancer menampilkan indikator visual hanya baca yang menunjukkan bahwa gateway tag Google diaktifkan.
• Anda tidak dapat mengedit atau menghapus konfigurasi gateway tag Google dari konsolGoogle Cloud .

Untuk petunjuk lengkap tentang cara menyiapkan gateway tag Google untuk pengiklan, lihat Menyiapkan gateway tag Google untuk pengiklan.

Meskipun konfigurasi dikelola dengan Google Ads, pemrosesan permintaan dan injeksi tag Google yang dilakukan oleh gateway dicatat dalam logging dan pemantauan Load Balancer Aplikasi eksternal global Anda. Untuk mengetahui informasi selengkapnya, lihat Logging dan pemantauan Load Balancer Aplikasi eksternal global.

Untuk mengetahui informasi tentang cara memecahkan masalah gateway tag Google, lihat Memecahkan masalah penyisipan gateway tag Google.

Jika Anda mengalami masalah selama penyiapan yang tidak dapat diselesaikan oleh dokumentasi, hubungi Dukungan Google Ads.

Batasan

• Load balancer HTTPS tidak mengirim pemberitahuan penutupan close_notify saat menghentikan koneksi SSL. Artinya, load balancer menutup koneksi TCP, bukan melakukan penonaktifan SSL.

• Load balancer HTTPS hanya mendukung karakter huruf kecil di domain dalam atribut nama umum (CN) atau atribut nama alternatif subjek (SAN) dari sertifikat. Sertifikat dengan karakter huruf besar di domain hanya ditampilkan jika ditetapkan sebagai sertifikat utama 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 keseluruhan 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.

Langkah berikutnya

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

• 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.