Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Perilaku permintaan dan respons untuk asal kustom

Untuk memahami cara CloudFront memproses permintaan dan tanggapan saat Anda menggunakan asal khusus, lihat bagian berikut:

Cara mem CloudFront proses dan meneruskan permintaan ke sumber kustom Anda

Pelajari cara mem CloudFront proses permintaan penampil dan meneruskan permintaan ke sumber kustom Anda.

Autentikasi

Jika Anda meneruskan Authorization header ke asal Anda, Anda kemudian dapat mengonfigurasi server asal Anda untuk meminta otentikasi klien untuk jenis permintaan berikut:

Untuk OPTIONS permintaan, otentikasi klien hanya dapat dikonfigurasi jika Anda menggunakan CloudFront pengaturan berikut:

Untuk informasi selengkapnya, lihat CloudFront Konfigurasikan untuk meneruskan Authorization header.

Anda dapat menggunakan HTTP atau HTTPS untuk meneruskan permintaan ke server asal Anda. Untuk informasi selengkapnya, lihat Gunakan HTTPS dengan CloudFront.

Durasi caching dan TTL minimum

Untuk mengontrol berapa lama objek Anda tetap berada di CloudFront cache sebelum mener CloudFront uskan permintaan lain ke asal Anda, Anda dapat:

Untuk informasi selengkapnya, lihat Mengelola berapa lama konten tetap dalam cache (kedaluwarsa).

Alamat IP Klien

Jika penampil mengirim permintaan ke CloudFront dan tidak menyertakan header X-Forwarded-For permintaan, CloudFront mendapatkan alamat IP penampil dari koneksi TCP, menambahkan X-Forwarded-For header yang menyertakan alamat IP, dan meneruskan permintaan ke asal. Misalnya, jika CloudFront mendapatkan alamat IP 192.0.2.2 dari koneksi TCP, akan meneruskan header berikut ke asalnya:

X-Forwarded-For: 192.0.2.2

Jika penampil mengirim permintaan ke CloudFront dan menyertakan header X-Forwarded-For permintaan, CloudFront mendapatkan alamat IP penampil dari koneksi TCP, menambahkannya ke akhir X-Forwarded-For header, dan meneruskan permintaan ke asal. Misalnya, jika permintaan penampil menyertakan X-Forwarded-For: 192.0.2.4,192.0.2.3 dan CloudFront mendapatkan alamat IP 192.0.2.2 dari koneksi TCP, itu meneruskan header berikut ke asal:

X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2

Beberapa aplikasi, seperti penyeimbang beban (termasuk Elastic Load Balancing), firewall aplikasi web, proxy terbalik, sistem pencegahan intrusi, dan API Gateway, menambahkan alamat IP server CloudFront tepi yang meneruskan permintaan ke ujung header. X-Forwarded-For Misalnya, jika diser CloudFront takan X-Forwarded-For: 192.0.2.2 dalam permintaan yang diteruskan ke ELB dan jika alamat IP server CloudFront tepi adalah 192.0.2.199, permintaan yang diterima instans EC2 Anda berisi header berikut:

X-Forwarded-For: 192.0.2.2,192.0.2.199

Client-side Otentikasi SSL

CloudFront mendukung otentikasi bersama TLS (MTL) di mana klien dan server saling mengotentikasi menggunakan sertifikat. Dengan MTL yang dikonfigurasi, CloudFront dapat memvalidasi sertifikat klien selama jabat tangan TLS dan secara opsional menjalankan CloudFront Functions untuk mengimplementasikan logika validasi kustom.

Untuk asal yang meminta sertifikat sisi klien saat MTL tidak dikonfigurasi, hapus permintaanCloudFront .

Untuk informasi selengkapnya tentang mengonfigurasi MTL, lihatMengaitkan Fungsi CloudFront Koneksi.

CloudFront tidak mendukung otentikasi klien dengan sertifikat SSL sisi klien. Jika asal meminta sertifikat sisi klien, batalkan permintaan CloudFront tersebut.

Kompresi

Untuk informasi selengkapnya, lihat Sajikan file terkompresi.

Permintaan bersyarat

Ketika CloudFront menerima permintaan untuk objek yang telah kedaluwarsa dari cache tepi, itu meneruskan permintaan ke asal baik untuk mendapatkan versi terbaru dari objek atau untuk mendapatkan konfirmasi dari asal bahwa cache CloudFront tepi sudah memiliki versi terbaru. Biasanya, ketika asal terakhir mengirim objek ke CloudFront, itu termasuk ETag nilai, LastModified nilai, atau kedua nilai dalam respons. Dalam permintaan baru yang mener CloudFront uskan ke asal, tambahkan CloudFront salah satu atau kedua hal berikut:

Origin menggunakan informasi ini untuk menentukan apakah objek telah diperbarui dan, oleh karena itu, apakah akan mengembalikan seluruh objek ke CloudFront atau hanya mengembalikan kode status HTTP 304 (tidak dimodifikasi).

Cookie

Anda dapat mengonfigurasi CloudFront untuk meneruskan cookie ke asal Anda. Untuk informasi selengkapnya, lihat Konten cache berdasarkan cookie.

Cross-origin berbagi sumber daya (CORS)

Jika Anda CloudFront ingin menghormati pengaturan berbagi sumber daya lintas asal, konfigurasikan CloudFront untuk meneruskan Origin header ke asal Anda. Untuk informasi selengkapnya, lihat Konten cache berdasarkan header permintaan.

Enkripsi

Anda dapat meminta pemirsa menggunakan HTTPS untuk mengirim permintaan ke CloudFront dan menghar CloudFront uskan untuk meneruskan permintaan ke asal kustom Anda dengan menggunakan protokol yang digunakan oleh penampil. Untuk informasi lebih lanjut, lihat pengaturan distribusi berikut:

CloudFront meneruskan permintaan HTTPS ke server asal menggunakan SSLv3,,, TLSv1.0 TLSv1.1TLSv1.2, dan protokol. TLSv1.3 Untuk asal khusus, Anda dapat memilih protokol SSL yang CloudFront ingin Anda gunakan saat berkomunikasi dengan asal Anda:

Jika asalnya adalah bucket Amazon S3, default CloudFront akan menjadi TLSv1.3.

Untuk informasi selengkapnya tentang menggunakan HTTPS dengan CloudFront, lihatGunakan HTTPS dengan CloudFront. Untuk daftar sandi yang CloudFront mendukung komunikasi HTTPS antara pemirsa dan CloudFront, dan antara CloudFront dan asal Anda, lihat. Protokol dan sandi yang didukung antara pemirsa dan CloudFront

Permintaan GET yang menyertakan tubuh

Jika GET permintaan penampil menyertakan badan, CloudFront mengembalikan kode status HTTP 403 (Dilarang) ke penampil.

Metode HTTP

Jika Anda mengonfigurasi CloudFront untuk memproses semua metode HTTP yang didukungnya, CloudFront menerima permintaan berikut dari pemirsa dan meneruskannya ke sumber kustom Anda:

CloudFront selalu menyimpan tanggapan GET dan HEAD permintaan. Anda juga dapat mengonfigurasi CloudFront untuk menyimpan respons terhadap OPTIONS permintaan. CloudFront tidak menyimpan tanggapan terhadap permintaan yang menggunakan metode lain.

Untuk informasi tentang konfigurasi apakah asal kustom Anda memproses metode ini, lihat dokumentasi untuk asal Anda.

Header dan CloudFront perilaku permintaan HTTP (asal kustom dan Amazon S3)

Tabel berikut mencantumkan header permintaan HTTP yang dapat Anda teruskan ke asal kustom dan juga Amazon S3 (dengan pengecualian yang dicatat). Untuk setiap header, tabel mencakup informasi tentang hal berikut:

Untuk informasi lebih lanjut tentang caching berdasarkan nilai header, lihat Konten cache berdasarkan header permintaan.

Versi HTTP

CloudFront meneruskan permintaan ke asal khusus Anda menggunakan HTTP/1.1.

Lama maksimum panjang permintaan dan lama maksimum URL

Panjang maksimum permintaan, termasuk jalur, string kueri (jika ada), dan header, adalah 32.768 byte.

CloudFront membangun URL dari permintaan. Panjang maksimal URL ini adalah 8192 byte.

Jika URL melebihi panjang maksimum, CloudFront mengembalikan kode status HTTP 414 (URI Terlalu Panjang) ke penampil. Jika permintaan melebihi panjang maksimum karena ukuran header terlampaui, CloudFront mengembalikan kode status HTTP 494 ke penampil. Dalam kedua kasus, CloudFront kemudian menghentikan koneksi TCP ke penampil.

Pemasangan OCSP

Ketika penampil mengirimkan permintaan HTTPS untuk objek, salah satu CloudFront atau penampil harus mengonfirmasi dengan otoritas sertifikat (CA) bahwa sertifikat SSL untuk domain belum dicabut. Stapling OCSP mempercepat validasi sertifikat dengan memungkinkan CloudFront untuk memvalidasi sertifikat dan menyimpan respons dari CA, sehingga klien tidak perlu memvalidasi sertifikat secara langsung dengan CA.

Peningkatan performa stapling OCSP lebih jelas ketika CloudFront menerima banyak permintaan HTTPS untuk objek dalam domain yang sama. Setiap server di lokasi CloudFront tepi harus mengirimkan permintaan validasi terpisah. Saat CloudFront menerima banyak permintaan HTTPS untuk domain yang sama, setiap server di lokasi tepi segera memiliki respons dari CA yang dapat "menempatkan" ke paket dalam handshake SSL; ketika penampil puas bahwa sertifikat valid, CloudFront dapat melayani objek yang diminta. Jika distribusi Anda tidak mendapatkan banyak lalu lintas di lokasi CloudFront tepi, permintaan baru cenderung diarahkan ke server yang belum memvalidasi sertifikat dengan CA. Dalam hal ini, penampil secara terpisah melakukan langkah validasi dan CloudFront server melayani objek. CloudFront Server itu juga mengirimkan permintaan validasi ke CA, sehingga saat berikutnya menerima permintaan yang menyertakan nama domain yang sama, ia memiliki respons validasi dari CA.

Koneksi persisten

Ketika CloudFront mendapat tanggapan dari asal Anda, ia mencoba mempertahankan koneksi selama beberapa detik jika permintaan lain tiba selama periode itu. Mempertahankan koneksi yang persisten menghemat waktu yang diperlukan untuk membangun kembali koneksi TCP dan melakukan handshake TLS lain untuk permintaan berikutnya.

Untuk informasi lebih lanjut, termasuk cara mengonfigurasi durasi koneksi persisten, lihat Keep-alive batas waktu (hanya asal khusus dan VPC) di bagian Semua referensi pengaturan distribusi.

Protokol

CloudFront meneruskan permintaan HTTP atau HTTPS ke server asal berdasarkan hal berikut:

Jika Anda menentukan Hanya HTTP atau Hanya HTTPS, CloudFront meneruskan permintaan ke server asal menggunakan protokol yang ditentukan, terlepas dari protokol dalam permintaan penampil.

Jika Anda menentukan Pen ampil Pen CloudFront cocokan, meneruskan permintaan ke server asal menggunakan protokol dalam permintaan penampil. Perhatikan bahwa CloudFront menyimpan objek hanya sekali jika penampil membuat permintaan menggunakan protokol HTTP dan HTTPS.

Untuk informasi tentang cara memperbarui distribusi menggunakan CloudFront konsol, lihatPerbarui distribusi. Untuk informasi tentang cara memperbarui distribusi menggunakan CloudFront API, buka UpdateDistribution di Referensi CloudFront API Amazon.

String pertanyaan

Anda dapat mengonfigurasi apakah CloudFront meneruskan parameter string kueri ke asal Anda. Untuk informasi selengkapnya, lihat Konten cache berdasarkan parameter string kueri.

Waktu habis dan upaya koneksi tempat asal

Waktu tunggu koneksi asal adalah jumlah detik yang CloudFront menunggu saat mencoba membuat koneksi ke asal.

Upaya koneksi asal adalah berapa kali CloudFront mencoba untuk terhubung ke asal.

Bersama-sama, pengaturan ini menentukan berapa lama CloudFront mencoba untuk terhubung ke asal sebelum gagal beralih ke asal sekunder (dalam kasus grup asal) atau mengembalikan respons kesalahan ke penampil. Secara default, CloudFront menunggu selama 30 detik (3 upaya masing-masing 10 detik) sebelum mencoba menyambung ke asal sekunder atau mengembalikan respons kesalahan. Anda dapat mengurangi waktu ini dengan menentukan waktu koneksi yang lebih singkat, lebih sedikit percobaan, atau keduanya.

Untuk informasi selengkapnya, lihat Kontrol batas waktu dan upaya asal.

Waktu habis untuk respons asal

waktu habis respons asal, juga dikenal sebagai waktu habis baca asal atau waktu habis permintaan asal, berlaku untuk kedua hal berikut:

CloudFront perilaku tergantung pada metode HTTP dari permintaan penampil:

Untuk informasi lebih lanjut, termasuk cara mengonfigurasi waktu habis respons asal, lihat Waktu tunggu respons.

Permintaan simultan untuk objek yang sama (permintaan runtuh)

Ketika lokasi CloudFront tepi menerima permintaan untuk objek dan objek tidak ada di cache atau objek yang di-cache kedaluwarsa, CloudFront segera mengirim permintaan ke asal. Namun, jika ada permintaan simultan untuk objek yang sama—yaitu, jika permintaan tambahan untuk objek yang sama (dengan kunci cache yang sama) tiba di lokasi tepi sebelum CloudFront menerima respons terhadap permintaan pertama— CloudFront berhenti sebelum meneruskan permintaan tambahan ke asal. Jeda singkat ini membantu mengurangi beban pada asal. CloudFront mengirimkan respons dari permintaan asli ke semua permintaan yang diterimanya saat dijeda. Ini disebut permintaan kolaps. Dalam CloudFront log, permintaan pertama diidentifikasi sebagai Miss di x-edge-result-type bidang, dan permintaan yang runtuh diidentifikasi sebagai aHit. Untuk informasi selengkapnya tentang CloudFront log, lihatCloudFront dan logging fungsi tepi.

CloudFront hanya menciutkan permintaan yang berbagi kunci cache. Jika permintaan tambahan tidak berbagi kunci cache yang sama karena, misalnya, Anda mengonfigurasi CloudFront untuk cache berdasarkan header permintaan atau cookie atau string kueri, mener CloudFront uskan semua permintaan dengan kunci cache unik ke sumber Anda.

Jika Anda ingin mencegah semua permintaan runtuh, Anda dapat menggunakan kebijakan cache terkelolaCachingDisabled, yang juga mencegah caching. Untuk informasi selengkapnya, lihat Gunakan kebijakan cache terkelola.

Jika Anda ingin mencegah permintaan runtuh untuk objek tertentu, Anda dapat mengatur TTL minimum untuk perilaku cache ke 0 dan mengonfigurasi asal untuk mengirimCache-Control: private,,, Cache-Control: no-store Cache-Control: no-cacheCache-Control: max-age=0, atau. Cache-Control: s-maxage=0 Konfigurasi ini akan meningkatkan beban pada asal Anda dan memperkenalkan latensi tambahan untuk permintaan simultan yang dijeda CloudFront sementara menunggu respons terhadap permintaan pertama.

Header User-Agent

Jika Anda CloudFront ingin menyimpan versi objek yang berbeda berdasarkan perangkat yang digunakan pengguna untuk melihat konten Anda, sebaiknya Anda mengonfigurasi CloudFront untuk meneruskan satu atau beberapa header berikut ke asal kustom Anda:

Berdasarkan nilai User-Agent header, CloudFront tetapkan nilai header ini ke true atau false sebelum meneruskan permintaan ke asal Anda. Jika perangkat termasuk dalam lebih dari satu kategori, lebih dari satu nilai mungkin true. Misalnya, untuk beberapa perangkat tablet, CloudFront mungkin mengatur keduanya CloudFront-Is-Mobile-Viewer dan CloudFront-Is-Tablet-Viewer ketrue. Untuk informasi selengkapnya tentang CloudFront mengkonfigurasi cache berdasarkan header permintaan, lihatKonten cache berdasarkan header permintaan.

Anda dapat mengonfigurasi CloudFront untuk menyimpan objek berdasarkan nilai di User-Agent header, tetapi kami tidak merekomendasikannya. User-AgentHeader memiliki banyak nilai yang mungkin, dan caching berdasarkan nilai-nilai tersebut akan menyebabkan mener CloudFront uskan lebih banyak permintaan secara signifikan ke asal Anda.

Jika Anda tidak mengonfigurasi CloudFront untuk menyimpan objek berdasarkan nilai di User-Agent header CloudFront , tambahkan User-Agent header dengan nilai berikut sebelum meneruskan permintaan ke asal Anda:

User-Agent = Amazon CloudFront

CloudFront menambahkan header ini terlepas dari apakah permintaan dari penampil menyertakan User-Agent header. Jika permintaan dari penampil menyertakan User-Agent header, mengh CloudFront apusnya.

Cara mem CloudFront proses tanggapan dari sumber kustom Anda

Pelajari cara CloudFront memproses respons dari sumber kustom Anda.

100 Lanjutkan tanggapan

Asal Anda tidak dapat mengirim lebih dari satu tanggapan 100-Lanjutkan ke CloudFront. Setelah respon 100-Lanjutkan pertama, CloudFront mengharapkan respons HTTP 200 OK. Jika asal Anda mengirimkan respons 100-Lanjutkan lagi setelah yang pertama, CloudFront akan mengembalikan kesalahan.

Pembuatan cache

Permintaan dibatalkan

Jika objek tidak ada di cache tepi, dan jika penampil mengakhiri sesi (misalnya, menutup browser) setelah CloudFront mendapatkan objek dari asal Anda tetapi sebelum dapat mengirimkan objek yang diminta, CloudFront tidak menyimpan objek di lokasi tepi.

Negosiasi konten

Jika asal Anda kembali Vary:* dalam respons, dan jika nilai TTL Minimum untuk perilaku cache yang sesuai adalah 0, CloudFront cache objek tetapi tetap meneruskan setiap permintaan berikutnya untuk objek ke asal untuk mengonfirmasi bahwa cache berisi versi terbaru dari objek. CloudFront tidak menyertakan header bersyarat, seperti If-None-Match atauIf-Modified-Since. Akibatnya, asal Anda mengembalikan objek sebagai tang CloudFront gapan atas setiap permintaan.

Jika asal Anda kembali Vary:* dalam respons, dan jika nilai TTL Minimum untuk perilaku cache yang sesuai adalah nilai lain, CloudFront proses Vary header seperti yang dijelaskan dalamHeader respons HTTP yang CloudFront menghapus atau mengganti.

Cookie

Jika Anda mengaktifkan cookie untuk perilaku cache, dan jika asal mengembalikan cookie dengan objek, CloudFront cache objek dan cookie. Perhatikan bahwa ini mengurangi kemungkinan cache untuk sebuah objek. Untuk informasi selengkapnya, lihat Konten cache berdasarkan cookie.

Koneksi TCP yang terhenti

Jika koneksi TCP antara CloudFront dan asal Anda terputus saat asal Anda mengembalikan objek ke CloudFront, CloudFront perilaku tergantung pada apakah asal Anda menyertakan Content-Length header dalam respons:

Kami menyarankan Anda mengonfigurasi server HTTP Anda untuk menambahkan Content-Length header untuk CloudFront mencegah cache objek parSIAL.

Header respons HTTP yang CloudFront menghapus atau mengganti

CloudFront menghapus atau memperbarui bidang header berikut sebelum meneruskan respons dari asal Anda ke penampil:

Ukuran file maksimum yang dapat di-cache

Ukuran maksimum badan respons yang disimpan dalam CloudFront cache-nya adalah 50 GB. Ini termasuk respons transfer yang dipotong yang tidak menyebutkan nilai header Content-Length.

Anda dapat menggunakan CloudFront untuk menyimpan objek yang lebih besar dari ukuran ini dengan menggunakan permintaan rentang untuk meminta objek di bagian yang masing-masing berukuran 50 GB atau lebih kecil. CloudFrontmenyimpan bagian-bagian ini karena masing-masing berukuran 50 GB atau lebih kecil. Setelah penampil mengambil semua bagian objek, ia dapat merekonstruksi objek asli yang lebih besar. Untuk informasi selengkapnya, lihat Gunakan permintaan rentang untuk menyimpan objek besar.

Tempat asal tidak tersedia

Jika server asal Anda tidak tersedia dan CloudFront mendapat permintaan untuk objek yang ada di cache tepi tetapi telah kedaluwarsa (misalnya, karena periode waktu yang ditentukan dalam direktif telah Cache-Control max-age berlalu), CloudFront baik melayani versi objek yang kedaluwarsa atau menyajikan halaman kesalahan khusus. Untuk informasi selengkapnya tentang CloudFront perilaku saat Anda mengonfigurasi halaman kesalahan kustom, lihatCara CloudFront memproses kesalahan saat Anda telah mengonfigurasi halaman kesalahan khusus.

Dalam beberapa kasus, objek yang jarang diminta diusir dan tidak lagi tersedia di cache tepi. CloudFront tidak dapat melayani objek yang telah diusir.

Mengalihkan

Jika Anda mengubah lokasi objek di server asal, Anda dapat mengonfigurasi server web Anda untuk mengalihkan permintaan ke lokasi baru. Setelah Anda mengonfigurasi pengalihan, pertama kali penampil mengirimkan permintaan untuk objek, CloudFront mengirimkan permintaan ke asal, dan asal merespons dengan pengalihan (misalnya,302 Moved Temporarily). CloudFront menyimpan pengalihan dan mengembalikannya ke penampil. CloudFront tidak mengikuti pengalihan.

Anda dapat mengonfigurasi server web untuk mengalihkan permintaan ke salah satu lokasi berikut:

Header Transfer-Encoding

CloudFront hanya mendukung chunked nilai Transfer-Encoding header. Jika asal Anda kembaliTransfer-Encoding: chunked, CloudFront mengembalikan objek ke klien saat objek diterima di lokasi tepi, dan menyimpan objek dalam format potongan untuk permintaan berikutnya.

Jika penampil membuat Range GET permintaan dan asal kembaliTransfer-Encoding: chunked, CloudFront mengembalikan seluruh objek ke penampil alih-alih rentang yang diminta.

Kami sarankan Anda menggunakan pengkodean bertahap jika panjang konten tanggapan Anda tidak dapat ditentukan sebelumnya. Untuk informasi selengkapnya, lihat Koneksi TCP yang terhenti.