Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan origin

Dengan Media CDN, Anda dapat mengambil konten dari infrastruktur asal, baik konten dihosting di dalam Google Cloud, di cloud lain, atau secara lokal.

Setiap konfigurasi dapat memiliki satu atau beberapa origin yang terkait dengannya. Konfigurasi origin memberi tahu Media CDN cara terhubung ke infrastruktur Anda, kapan dan bagaimana untuk melakukan failover, mencoba ulang, dan kehabisan waktu, serta protokol apa yang akan digunakan saat membuat koneksi.

Origin memiliki fitur berikut:

Origin dapat ditentukan per host dan per rute, yang memungkinkan satu resource EdgeCacheService dipetakan ke beberapa origin yang berisi, misalnya, manifes, segmen video, dan konten statis lainnya.
Origin dapat dijangkau melalui HTTP/2, HTTPS, dan HTTP/1.1 yang tidak terenkripsi.
Percobaan ulang dan perilaku failover dikonfigurasi per origin, dan dapat memungkinkan layanan untuk mengatasi error berat (seperti kegagalan konektivitas) atau mencoba lagi berdasarkan respons HTTP 404 Not Found atau 429 Too Many Requests HTTP.
Resource pribadi di dalam Google Cloud atau infrastruktur lokal dapat dijangkau dengan mengonfigurasi Load Balancer Aplikasi eksternal sebagai asal di balik Media CDN.
Perilaku pengalihan mengikuti dikonfigurasi per origin. Anda dapat mengaktifkan Media CDN untuk mengikuti pengalihan ke server asal lainnya.

Persyaratan origin

Agar Media CDN dapat menyimpan respons asal yang lebih besar dari 1 MiB dalam cache, origin harus menyertakan kode berikut dalam header respons untuk permintaan HEAD dan GET, kecuali jika ditentukan lain:

Header respons HTTP Last-Modified atau ETag (validator).
Header Date HTTP yang valid.
Header Content-Length yang valid.
Header respons Content-Range, sebagai respons terhadap permintaan Range GET. Header Content-Range harus memiliki nilai yang valid dalam bentuk bytes x-y/z (dengan z adalah ukuran objek).

Protokol origin default adalah HTTP/2. Jika origin hanya mendukung HTTP/1.1, Anda dapat menetapkan kolom protokol secara eksplisit untuk setiap origin.

Perlindungan origin

Media CDN menyediakan infrastruktur edge dengan tingkat yang sangat tinggi yang dirancang untuk secara aktif meminimalkan pengisian cache jika memungkinkan.

Ada tiga lapisan utama infrastruktur penyimpanan dalam cache:

Deep edge cache, yang melayani sebagian besar traffic dan pemindahan beban dalam jaringan penyedia layanan.
Edge peering Google, yang terhubung ke ribuan ISP dan berfungsi sebagai cache tingkat menengah untuk edge cache, dan jika tidak ada dalam ISP tertentu, maka cache yang ditampilkan kepada pengguna.
Cache longtail dalam jaringan Google yang diisi oleh cache downstream lain dari sebelum asalnya. Cache ini mendukung fan-in yang signifikan, memiliki kapasitas penyimpanan cache yang besar, dan berfungsi sebagai perisai origin.

Ringkasan topologi ini ditampilkan di sini:

Penyusunan (atau penggabungan) semua lapisan permintaan dukungan dalam cache untuk mengurangi beban asal lebih lanjut. Berdasarkan pengamatan beban kerja dunia nyata dalam skala besar:

> 95% pengisian cache menggunakan node cache longtail khusus di dalam region tersebut, untuk mengurangi biaya dan latensi pengisian cache.
Pengisian cache antara origin dan infrastruktur edge Google sepenuhnya berada di atas jaringan backbone pribadi global Google, yang mengurangi latensi pengisian cache dan meningkatkan keandalan. Keduanya merupakan manfaat aktif untuk workload live streaming.
Cache akan diisi silang jika bermanfaat untuk melakukannya, sehingga lebih mendorong penurunan rasio pengisian cache.
Media CDN memiliki kapasitas penyimpanan yang signifikan di seluruh cache, yang meminimalkan tingkat penghapusan bahkan untuk konten longtail yang kurang populer.

Pelanggan mungkin melihat kecepatan pengurangan beban yang berbeda, bergantung pada konfigurasi cache, beban pengguna, workload (seperti live versus on demand), distribusi pengguna, dan jumlah konten longtail (total ukuran korpus) yang mereka tayangkan kepada pengguna di seluruh region.

Permintaan diciutkan

Permintaan menciutkan secara aktif beberapa permintaan pengisian cache berbasis pengguna untuk kunci cache yang sama menjadi satu permintaan asal, per node edge.

Jika digabungkan dengan perlindungan origin, hal ini makin mengurangi kebutuhan bandwidth asal dan traffic keluar, serta merupakan perilaku default untuk Media CDN.

Pada permintaan yang diciutkan, permintaan yang ditampilkan kepada klien dan permintaan pengisian cache (diciutkan) akan dicatat ke dalam log. Pemimpin sesi yang diciutkan digunakan untuk membuat permintaan pengisian origin, yang berarti origin akan melihat header (termasuk Agen Pengguna) hanya dari klien tersebut.

Permintaan yang tidak memiliki kunci cache yang sama tidak dapat diciutkan.

Konektivitas origin

Bagian berikut menjelaskan cara Media CDN terhubung ke origin, cara permintaan HTTP dibuat, dan cara mengautentikasi permintaan.

Origin dan protokol yang didukung

Media CDN secara langsung mendukung setiap endpoint HTTP yang dapat dijangkau secara publik sebagai asal, termasuk yang berikut:

Bucket Cloud Storage, termasuk bucket pribadi melalui akun layanan Identity and Access Management
Load Balancer Aplikasi Eksternal
Bucket yang kompatibel dengan Amazon S3, termasuk bucket pribadi yang menggunakan AWS Signature Versi 4
Penyimpanan objek lain yang tersedia untuk umum, seperti Azure Blob Storage
Server web yang tersedia secara publik, seperti VM publik atau host lokal

Konektivitas ke origin dilakukan melalui tunnel aman dan jaringan backbone global Google.

Tabel berikut menjelaskan protokol origin yang didukung.

Protocol	Didukung	Perlu SSL (TLS)
HTTP/2	Ya (default)	Ya
HTTPS (HTTP/1.1 melalui TLS)	Ya	Ya
HTTP/1.1	Ya	Tidak

Media CDN menggunakan HTTP/2 (h2) untuk terhubung ke origin secara default. HTTP/2 dan HTTPS memerlukan sertifikat TLS (SSL) yang valid dan tepercaya secara publik. Sertifikat yang valid adalah sertifikat yang masih berlaku, ditandatangani oleh Certificate Authority publik, dan memiliki Nama Alternatif Subjek yang cocok dengan nama host yang dikirim ke asal.

Catatan:

Jika origin Anda tidak mendukung HTTP/2, Anda dapat secara eksplisit menetapkan protokol (berdasarkan setiap origin) ke HTTP (HTTP/1.1) atau HTTPS (HTTP/1.1 melalui TLS).
Saat mengonfigurasi HTTPS atau HTTP/1.1 sebagai protokol asal, Media CDN tidak menegosiasikan protokol alternatif (seperti HTTP/2). Demikian pula, saat mengonfigurasi HTTP/2, koneksi tidak kembali ke HTTP/1.1, untuk menjelaskan perilaku konektivitas asal secara eksplisit.
Media CDN otomatis menggunakan port yang benar berdasarkan protokol: port 80 untuk HTTP atau port 443 untuk HTTPS dan HTTP/2.

Header permintaan origin

Saat terhubung ke origin, Media CDN menggunakan header Host dari permintaan klien secara default.

Tabel berikut mendokumentasikan apa yang dilihat origin dalam permintaan masuk dalam berbagai skenario konfigurasi:

Permintaan Klien	`EdgeCacheService.hostRewrite`	`EdgeCacheOrigin.hostRewrite`	originAddress	Header host / SNI TLS di asal
media.example.com	Tidak ada	Tidak ada	backend.example.com	media.example.com
media.example.com	service.example.com	Tidak ada	backend.example.com	service.example.com
media.example.com	Tidak ada	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	gs://vod-content-bucket	ditetapkan secara otomatis berdasarkan nama bucket,

Origin utama dan origin failover apa pun akan melihat header host yang sama jika memiliki konfigurasi routeRule atau hostRewrite yang sama.

Semua setelan hostRewrite akan diabaikan saat menggunakan bucket Cloud Storage sebagai asal karena nilai header host alternatif tidak didukung oleh bucket Cloud Storage. Header host akan otomatis ditetapkan berdasarkan nama bucket.

Nilai SNI (Server Name Indication) TLS dalam permintaan (untuk permintaan HTTP/3, HTTP/2, dan HTTPS) disetel ke nilai yang sama dengan header host yang dikirim ke origin.

Untuk mengetahui informasi tentang cara menulis ulang header host untuk konfigurasi per rute, lihat Mengonfigurasi rute layanan. Untuk mengetahui informasi tentang cara menetapkan tindakan penggantian per origin, lihat Failover origin tanpa mengikuti pengalihan.

Failover dan waktu tunggu

Bagian berikut menjelaskan opsi konfigurasi ini:

Waktu tunggu: Menentukan lamanya Media CDN menunggu untuk terhubung ke asal Anda atau untuk merespons permintaan.
Percobaan ulang: Menentukan apakah Media CDN mencoba kembali permintaan HTTP asal ke asal Anda, dan dalam kondisi apa.
Failover: Menentukan apakah Media CDN mencoba terhubung ke asal failover jika yang pertama tidak tersedia atau menampilkan kode status tertentu.

Waktu tunggu origin

Waktu tunggu memungkinkan Anda mengonfigurasi saat percobaan ulang origin dan perilaku failover terpicu dan kapan failover klien berikutnya dapat dipicu.

Berikut ini penjelasan tentang waktu tunggu yang dapat dikonfigurasi yang didukung Media CDN:

connectTimeout dan maxAttemptsTimeout membatasi waktu yang diperlukan Media CDN untuk menemukan respons yang dapat digunakan.

Kedua waktu tunggu tersebut mencakup waktu yang diperlukan origin untuk menampilkan header dan untuk menentukan apakah akan menggunakan failover atau pengalihan. connectTimeout berlaku secara independen untuk setiap upaya origin, sedangkan maxAttemptsTimeout mencakup waktu yang diperlukan untuk terhubung di semua upaya origin, termasuk failover dan pengalihan. Mengikuti pengalihan dihitung sebagai upaya tambahan untuk terhubung ke origin, dan dihitung dalam jumlah maxAttempts yang ditetapkan untuk origin yang dikonfigurasi.

Saat Media CDN menemukan respons non-pengalihan, seperti dari pengalihan atau asal failover, nilai readTimeout dan responseTimeout akan berlaku. Origin yang dialihkan menggunakan nilai connectTimeout, readTimeout, dan responseTimeout yang dikonfigurasi untuk EdgeCacheOrigin yang mengalami pengalihan.
responseTimeout dan readTimeout mengontrol durasi respons yang di-streaming. Setelah Media CDN menentukan bahwa media CDN akan menggunakan respons upstream, connectTimeout atau maxAttemptsTimeout tidak menjadi masalah. Pada tahap ini, readTimeout dan responseTimeout akan diterapkan.

Media CDN melakukan maksimal empat upaya asal di semua origin, terlepas dari maxAttempts yang ditetapkan oleh setiap EdgeCacheOrigin. Media CDN menggunakan nilai maxAttemptsTimeout dari EdgeCacheOrigin utama. Nilai waktu tunggu per percobaan (connectTimeout, readTimeout, dan responseTimeout) dikonfigurasi untuk EdgeCacheOrigin dari setiap percobaan.

Tabel berikut menjelaskan kolom waktu tunggu:

Kolom	Default	Deskripsi
connectTimeout	5 detik	Jumlah waktu maksimum yang dapat dibutuhkan Media CDN dari memulai permintaan ke asal hingga Media CDN menentukan apakah respons dapat digunakan. Dalam praktiknya, `connectTimeout` mencakup waktu yang dimulai dengan membuat permintaan, lalu melakukan pencarian DNS, kemudian melakukan handshake TLS, pembuatan koneksi TCP/QUIC, hingga mendapatkan header respons yang berisi kode status HTTP. Waktu tunggu harus bernilai antara 1 detik dan 15 detik.
maxAttemptsTimeout	15 detik	Waktu maksimum di semua koneksi mencoba ke origin, termasuk origin failover, sebelum menampilkan error ke klien. HTTP 504 akan ditampilkan jika waktu tunggu habis sebelum respons ditampilkan. Waktu tunggu harus bernilai antara 1 detik dan 30 detik. Setelan ini menentukan total durasi untuk semua upaya koneksi origin, termasuk origin failover, untuk membatasi total waktu klien harus menunggu konten untuk memulai streaming. Hanya nilai `maxAttemptsTimeout` pertama yang digunakan, dalam hal ini, nilai pertama ditentukan oleh asal yang dikonfigurasi untuk rute tertentu.
readTimeout	15 detik	Durasi maksimum untuk menunggu antar pembacaan respons HTTP tunggal. `readTimeout` dibatasi oleh `responseTimeout`. Semua pembacaan respons HTTP harus diselesaikan sebelum batas waktu yang ditetapkan oleh `responseTimeout`. Waktu tunggu harus bernilai antara 1 detik dan 30 detik. Jika waktu tunggu ini tercapai sebelum respons selesai, respons akan dipotong dan dicatat dalam log.
responseTimeout	30 seconds	Durasi maksimum yang diizinkan untuk menyelesaikan respons. Waktu tunggu harus bernilai antara 1 detik dan 120 detik. Durasi diukur dari waktu byte tubuh pertama diterima. Jika waktu tunggu ini tercapai sebelum respons selesai, respons akan dipotong dan dicatat dalam log.

Perhatikan contoh berikut:

Origin A mencocokkan permintaan dengan "/segments/" dan memiliki nilai maxAttemptsTimeout sebesar 5s, nilai maxAttempts sebesar 1, dan nilai failover_origin sebesar Origin B. Nilai connectTimeout adalah defaultnya, yaitu 5s. Jika Anda mencoba terhubung ke Origin A, dan gagal dalam 1 detik karena sertifikat TLS yang tidak valid, Anda memiliki sisa waktu sekitar 4 detik untuk membuat koneksi yang berhasil ke Origin B.
Origin C cocok dengan permintaan dengan "/manifes/*, memiliki nilai maxAttemptsTimeout 10s, nilai maxAttempts 3, dan failover_origin tidak dikonfigurasi. Nilai connectTimeout adalah default-nya, yaitu 5s. Media CDN mencoba terhubung ke Origin C hingga tiga kali, sehingga membutuhkan waktu hingga 10 detik (batas maxAttemptsTimeout) untuk membuat koneksi berhasil.

Mencoba ulang permintaan origin

Media CDN mendukung percobaan ulang asal, sehingga permintaan yang gagal ke asal dapat dicoba lagi. Anda dapat menentukan berapa kali origin saat ini dapat dicoba lagi sebelum origin failover (jika dikonfigurasi) dicoba.

Media CDN mencoba menjangkau asal utama hingga nilai maxAttempts yang dikonfigurasi, yang defaultnya adalah 1.
Media CDN mencoba ulang koneksi asal maksimal tiga kali sebelum gagal dan menampilkan error 502 Bad Gateway HTTP kepada pengguna. Hal ini termasuk koneksi asal failover apa pun, yang akan dihitung dalam batas tiga koneksi.
Saat mengonfigurasi resource origin, Anda dapat mengonfigurasi origin utama menggunakan kolom originAddress, lalu failoverOrigin opsional. failoverOrigin menunjuk ke resource asal lainnya.

retryConditions untuk setiap origin menentukan jenis kegagalan yang memicu percobaan ulang:

Kondisi	Default	Deskripsi
CONNECT_FAILURE	✔️	Percobaan ulang kegagalan mencakup pemilihan rute, error handshake DNS dan TLS, dan waktu tunggu TCP/UDP.
HTTP_5XX		Coba lagi pada kode status HTTP `5xx`.
GATEWAY_ERROR		Serupa dengan `5xx`, tetapi hanya berlaku untuk kode status `502`, `503`, atau `504`.
RETRIABLE_4XX		Coba lagi untuk memasukkan kode status `4xx` yang dapat dicoba lagi, termasuk `409` dan `429`.
NOT_FOUND		Coba lagi kode status HTTP `404`.
DILARANG		Coba lagi kode status HTTP `403`.

Jika memerlukan pemeriksaan kesehatan aktif, round-robin, atau pengendalian beban di seluruh asal, Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal sebagai asal utama.

Perilaku failover

Tabel berikut menjelaskan cara operasi failover, dan respons yang akan dilihat klien:

Skenario	Failover dikonfigurasi	Status dilihat pengguna
Media CDN mencoba terhubung ke origin Anda, dan tidak menerima respons HTTP setelah dua kali upaya (default).	Tidak	`502 Bad Gateway` HTTP
Media CDN mencoba terhubung ke asal utama Anda, dan gagal terhubung (TLS handshake error). Upaya dilakukan terhadap origin failover yang dikonfigurasi, yang menampilkan error `404` HTTP.	Ya	`404 Not Found` HTTP
Media CDN mencoba terhubung ke asal utama dan failover Anda, tetapi tidak menerima kode status HTTP.	Ya	`502 Bad Gateway` HTTP

Jika Media CDN menerima kode status yang cocok dengan retryConditions yang dikonfigurasi, seperti error HTTP 404 Not Found atau HTTP 429 Too Many Requests, dan permintaan asal failover dan percobaan ulang berikutnya terus gagal, error 502 Bad Gateway HTTP ditampilkan ke klien setelah upaya origin habis.

Praktik terbaik untuk failover origin

Saat mengonfigurasi beberapa origin untuk failover atau load balancing, pastikan konten media serta perilaku header Vary, ETag, dan Last-Modified konsisten di antara origin Anda.

Sebagai praktik terbaik, konfigurasikan pengalihan origin hanya untuk origin yang Anda percayai dan kontrol. Pastikan Anda memercayai setiap origin dalam rantai pengalihan karena setiap origin menghasilkan konten yang ditayangkan oleh EdgeCacheService Anda.