Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan origin

Media CDN memungkinkan Anda mengambil konten dari infrastruktur origin, baik konten dihosting dalam Google Cloud, di cloud lain, maupun di lokal.

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

Origins 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 dienkripsi.
Perilaku percobaan ulang dan failover dikonfigurasi per origin, dan dapat memungkinkan layanan melakukan failover pada error berat (seperti kegagalan konektivitas) atau mencoba ulang berdasarkan respons HTTP 404 Not Found atau HTTP 429 Too Many Requests.
Resource pribadi di dalam Google Cloud atau di lokasi dapat dijangkau dengan mengonfigurasi Load Balancer Aplikasi eksternal sebagai asal di belakang Media CDN.
Perilaku mengikuti pengalihan dikonfigurasi per origin. Anda dapat mengaktifkan Media CDN untuk mengikuti pengalihan ke server origin lain.

Persyaratan asal

Agar Media CDN dapat meng-cache respons origin yang lebih besar dari 1 MiB, origin harus menyertakan hal 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 Anda hanya mendukung HTTP/1.1, Anda dapat menetapkan kolom protokol secara eksplisit untuk setiap origin.

Pelindung origin

Media CDN menyediakan infrastruktur edge bertingkat yang komprehensif yang dirancang untuk secara aktif meminimalkan pengisian cache jika memungkinkan.

Ada tiga lapisan utama infrastruktur penyimpanan dalam cache:

Cache deep edge, yang menyalurkan sebagian besar traffic dan melakukan off-load dalam jaringan penyedia layanan.
Edge peering Google, yang terhubung ke ribuan ISP dan berfungsi sebagai cache tingkat menengah untuk cache edge, dan untuk kasus saat cache tersebut tidak ada dalam ISP tertentu, cache yang ditampilkan kepada pengguna.
Cache longtail dalam jaringan Google yang diisi cache downstream lainnya sebelum origin. Cache ini mendukung fan-in yang signifikan, memiliki kapasitas penyimpanan cache yang substansial, dan berfungsi sebagai perisai asal.

Ringkasan topologi ini ditampilkan di sini:

Semua lapisan dukungan penyimpanan dalam cache meminta penggabungan (atau penggabungan) untuk lebih mengurangi beban origin. Berdasarkan beban kerja dunia nyata yang diamati dalam skala besar:

> 95% pengisian cache menggunakan node cache longtail khusus dalam region, untuk mengurangi biaya dan latensi pengisian cache.
Pengisian cache antara origin dan infrastruktur edge Google sendiri dilakukan sepenuhnya melalui jaringan backbone pribadi global Google, yang mengurangi latensi pengisian cache dan meningkatkan keandalan—keduanya adalah manfaat aktif untuk beban kerja live streaming.
Cache melakukan pengisian silang satu sama lain jika menguntungkan untuk melakukannya, sehingga meningkatkan rasio pengisian cache.
Media CDN memiliki kapasitas penyimpanan yang signifikan di seluruh cache, yang meminimalkan rasio penghapusan bahkan untuk konten longtail yang kurang populer.

Pelanggan mungkin melihat tarif penghapusan yang berbeda bergantung pada konfigurasi cache, beban pengguna, beban kerja (seperti live versus on-demand), distribusi pengguna, dan jumlah konten longtail (total ukuran korpus) yang mereka tayangkan kepada pengguna di seluruh wilayah.

Meminta penggabungan

Pengelompokan permintaan secara aktif menggabungkan beberapa permintaan pengisian cache yang didorong pengguna untuk kunci cache yang sama menjadi satu permintaan origin, per node edge.

Dikombinasikan dengan perlindungan origin, hal ini akan lebih mengurangi beban origin dan kebutuhan bandwidth keluar, serta merupakan perilaku default untuk Media CDN.

Permintaan yang diciutkan memiliki permintaan yang ditampilkan kepada klien dan permintaan pengisian cache (diciutkan) yang dicatat ke dalam log. Pemimpin sesi yang diciutkan digunakan untuk membuat permintaan pengisian origin, yang berarti origin hanya melihat header (termasuk User-Agent) 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 Anda dapat mengautentikasi permintaan.

Origin dan protokol yang didukung

Media CDN secara langsung mendukung endpoint HTTP yang dapat dijangkau secara publik sebagai origin, termasuk hal 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 Version 4
Penyimpanan objek lain yang tersedia secara publik, 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.

Protokol	Didukung	SSL (TLS) diperlukan
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) valid yang tepercaya secara publik. Sertifikat yang valid adalah sertifikat yang belum habis masa berlakunya, ditandatangani oleh Otoritas Sertifikat publik, dan memiliki Subject Alternative Name yang cocok dengan nama host yang dikirim ke asal.

Catatan:

Jika origin tidak mendukung HTTP/2, Anda dapat menetapkan protokol secara eksplisit (berdasarkan per origin) ke HTTP (HTTP/1.1) atau HTTPS (HTTP/1.1 melalui TLS).
Saat mengonfigurasi HTTPS atau HTTP/1.1 sebagai protokol origin, Media CDN tidak menegosiasikan protokol alternatif (seperti HTTP/2). Demikian pula, saat mengonfigurasi HTTP/2, koneksi tidak kembali ke HTTP/1.1, agar perilaku koneksi asal menjadi 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 / TLS SNI di origin
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 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 origin karena nilai header host alternatif tidak didukung oleh bucket Cloud Storage. Header host ditetapkan secara otomatis berdasarkan nama bucket.

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

Untuk informasi tentang cara menulis ulang header host untuk konfigurasi per rute, lihat Mengonfigurasi rute layanan. Untuk 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 berapa lama Media CDN menunggu untuk terhubung ke origin Anda atau untuk merespons permintaan.
Percobaan ulang: Menentukan apakah Media CDN mencoba ulang permintaan HTTP origin ke origin Anda, dan dalam kondisi apa.
Failover: Menentukan apakah Media CDN mencoba terhubung ke origin failover jika origin pertama tidak tersedia atau menampilkan kode status tertentu.

Waktu tunggu origin

Waktu tunggu memungkinkan Anda mengonfigurasi kapan perilaku percobaan ulang dan failover origin dipicu 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 menentukan apakah akan menggunakan pengalihan atau failover. connectTimeout berlaku secara independen untuk setiap upaya origin, sedangkan maxAttemptsTimeout mencakup waktu yang diperlukan untuk terhubung di semua upaya origin, termasuk pengalihan dan failover. Mengikuti pengalihan dihitung sebagai upaya tambahan untuk terhubung ke origin, dan dihitung sebagai bagian dari maxAttempts yang ditetapkan untuk origin yang dikonfigurasi.

Saat Media CDN mengalami respons non-pengalihan, seperti dari origin pengalihan atau 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 berapa lama respons streaming dapat dilakukan. Setelah Media CDN menentukan bahwa CDN akan menggunakan respons upstream, connectTimeout maupun maxAttemptsTimeout tidak akan berpengaruh. Pada tahap ini, readTimeout dan responseTimeout akan diterapkan.

Media CDN melakukan maksimal empat upaya origin 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 setiap percobaan.

Tabel berikut menjelaskan kolom waktu tunggu:

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

Perhatikan contoh berikut:

Origin A cocok dengan permintaan ke "/segments/" dan memiliki nilai maxAttemptsTimeout 5s, nilai maxAttempts 1, dan nilai failover_origin Origin B. Nilai connectTimeout berada pada nilai defaultnya, yaitu 5s. Jika Anda mencoba terhubung ke Origin A, dan gagal dalam waktu 1 detik karena sertifikat TLS tidak valid, Anda memiliki waktu tersisa ~4 detik untuk membuat koneksi yang berhasil ke Origin B.
Origin C cocok dengan permintaan ke "/manifests/*, memiliki nilai maxAttemptsTimeout 10s, nilai maxAttempts 3, dan failover_origin tidak dikonfigurasi. Nilai connectTimeout berada pada nilai default 5s. CDN Media mencoba terhubung ke Origin C hingga tiga kali, yang memungkinkan hingga 10 detik (batas maxAttemptsTimeout) untuk membuat koneksi yang berhasil.

Mencoba lagi permintaan origin

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

Media CDN mencoba menjangkau origin utama hingga nilai maxAttempts yang dikonfigurasi, yang secara default adalah 1.
Media CDN mencoba ulang koneksi origin hingga maksimum tiga kali sebelum gagal dan menampilkan error 502 Bad Gateway HTTP kepada pengguna. Hal ini mencakup koneksi origin failover, yang dihitung dalam batas tiga.
Saat mengonfigurasi resource origin, Anda dapat mengonfigurasi origin utama dengan menggunakan kolom originAddress, lalu failoverOrigin opsional. failoverOrigin mengarah ke resource origin lain.

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

Kondisi	Default	Deskripsi
CONNECT_FAILURE	✔️	Percobaan ulang saat terjadi kegagalan mencakup error perutean, DNS, dan TLS handshake, serta waktu tunggu TCP/UDP habis.
HTTP_5XX		Mencoba lagi pada kode status `5xx` HTTP.
GATEWAY_ERROR		Mirip dengan `5xx`, tetapi hanya berlaku untuk kode status `502`, `503`, atau `504`.
RETRIABLE_4XX		Mencoba lagi untuk kode status `4xx` yang dapat dicoba lagi, termasuk `409` dan `429`.
NOT_FOUND		Mencoba lagi pada kode status `404` HTTP.
FORBIDDEN		Mencoba lagi pada kode status `403` HTTP.

Jika Anda memerlukan health check aktif, round-robin, atau pemilihan rute berbasis beban di seluruh origin, Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal sebagai origin utama.

Perilaku failover

Tabel berikut menjelaskan cara kerja failover, dan respons yang akan diamati klien:

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

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 origin percobaan ulang dan failover berikutnya terus gagal, error HTTP 502 Bad Gateway akan ditampilkan ke klien setelah upaya origin habis.

Praktik terbaik untuk failover origin

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

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