Perilaku permintaan dan respons untuk asal Amazon S3

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

Cara CloudFront memproses dan meneruskan permintaan ke asal Amazon S3 Anda

Pelajari cara CloudFront memproses permintaan penampil dan meneruskan permintaan ke asal Amazon S3 Anda.

Daftar Isi

• Durasi caching dan TTL minimum

• Alamat IP Klien

• Permintaan GET bersyarat

• Cookie

• Berbagi sumber daya lintas asal (CORS)

• Permintaan GET yang menyertakan tubuh

• Metode HTTP

• Header permintaan HTTP yang CloudFront menghapus atau memperbarui

• Lama maksimum panjang permintaan dan lama maksimum URL

• Pemasangan OCSP

• Protokol

• String pertanyaan

• Waktu habis dan upaya koneksi tempat asal

• Waktu habis untuk respons asal

• Permintaan simultan untuk objek yang sama (permintaan runtuh)

Durasi caching dan TTL minimum

Untuk mengontrol berapa lama objek Anda berada dalam CloudFront cache sebelum CloudFront meneruskan permintaan lain ke asal Anda, Anda dapat:

• Konfigurasi asal Anda untuk menambahkan Cache-Control atau Expires pada setiap objek.

• Tentukan nilai untuk TTL Minimum dalam perilaku CloudFront cache.

• Gunakan nilai default selama 24 jam.

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

catatan

X-Forwarded-ForHeader berisi IPv4 alamat (seperti 192.0.2.44) dan IPv6 alamat (seperti 2001:0 db 8:85 a3: :8a2e: 0370:7334).

Permintaan GET bersyarat

Ketika CloudFront menerima permintaan untuk objek yang telah kedaluwarsa dari cache tepi, ia meneruskan permintaan ke asal Amazon S3 untuk mendapatkan versi terbaru dari objek atau untuk mendapatkan konfirmasi dari Amazon S3 bahwa CloudFront cache edge sudah memiliki versi terbaru. Ketika Amazon S3 awalnya mengirim objek ke CloudFront, itu termasuk ETag nilai dan LastModified nilai dalam respons. Dalam permintaan baru yang CloudFront diteruskan ke Amazon S3 CloudFront , tambahkan satu atau kedua header berikut:

• Header If-Match atau If-None-Match yang memuat ETag untuk versi objek yang kedaluwarsa.

• Header If-Modified-Since yang memuat LastModified untuk versi objek yang kedaluwarsa.

Amazon S3 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

Amazon S3 tidak memproses cookie. Jika Anda mengonfigurasi perilaku cache untuk meneruskan cookie ke asal Amazon S3, CloudFront teruskan cookie, tetapi Amazon S3 mengabaikannya. Semua permintaan di masa mendatang untuk objek yang sama, terlepas jika Anda mengubah cookie, dilayani dari objek yang ada di dalam cache.

Berbagi sumber daya lintas asal (CORS)

Jika Anda CloudFront ingin menghormati setelan berbagi sumber daya lintas asal Amazon S3, konfigurasikan CloudFront untuk meneruskan header yang dipilih ke Amazon S3. Untuk informasi selengkapnya, lihat Konten cache berdasarkan header permintaan.

Permintaan GET yang menyertakan tubuh

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

Metode HTTP

Jika Anda mengonfigurasi CloudFront untuk memproses semua metode HTTP yang didukungnya, CloudFront terima permintaan berikut dari pemirsa dan teruskan ke asal Amazon S3 Anda:

• DELETE

• GET

• HEAD

• OPTIONS

• PATCH

• POST

• PUT

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

Jika Anda ingin menggunakan unggahan multi-bagian untuk menambahkan objek ke bucket Amazon S3, Anda harus menambahkan CloudFront kontrol akses asal (OAC) ke distribusi Anda dan memberikan OAC izin yang diperlukan. Untuk informasi selengkapnya, lihat Batasi akses ke asal Amazon Simple Storage Service.

penting

Jika Anda mengonfigurasi CloudFront untuk menerima dan meneruskan ke Amazon S3 semua metode HTTP yang CloudFront mendukung, Anda harus membuat CloudFront OAC untuk membatasi akses ke konten Amazon S3 Anda dan memberikan OAC izin yang diperlukan. Misalnya, jika Anda mengonfigurasi CloudFront untuk menerima dan meneruskan metode ini karena Anda ingin menggunakan PUT metode ini, Anda harus mengonfigurasi kebijakan bucket Amazon S3 untuk menangani DELETE permintaan dengan tepat sehingga pemirsa tidak dapat menghapus sumber daya yang tidak Anda inginkan. Untuk informasi selengkapnya, lihat Batasi akses ke asal Amazon Simple Storage Service.

Untuk informasi tentang operasi yang didukung oleh Amazon S3, lihat Dokumentasi Amazon S3.

Header permintaan HTTP yang CloudFront menghapus atau memperbarui

CloudFront menghapus atau memperbarui beberapa header sebelum meneruskan permintaan ke asal Amazon S3 Anda. Untuk sebagian besar header, perilaku ini sama dengan untuk asal kustom. Untuk daftar lengkap header permintaan HTTP dan cara CloudFront memprosesnya, lihatHeader dan CloudFront perilaku permintaan HTTP (asal kustom dan Amazon S3).

Lama maksimum panjang permintaan dan lama maksimum URL

Lama maksimum permintaan, termasuk alur, string query (jika ada), dan header, adalah 20.480 byte.

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

Jika permintaan atau URL melebihi panjang maksimum, CloudFront mengembalikan kode status HTTP 413 (Permintaan Entitas Terlalu Besar), ke penampil, dan kemudian mengakhiri koneksi TCP ke penampil.

Pemasangan OCSP

Saat penampil mengirimkan permintaan HTTPS untuk suatu objek, CloudFront atau penampil harus mengonfirmasi dengan otoritas sertifikat (CA) bahwa sertifikat SSL untuk domain tersebut 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 kinerja stapling OCSP lebih terasa ketika CloudFront menerima banyak permintaan HTTPS untuk objek dalam domain yang sama. Setiap server di CloudFront lokasi edge harus menyerahkan permintaan validasi terpisah. Ketika CloudFront menerima banyak permintaan HTTPS untuk domain yang sama, setiap server di lokasi edge segera memiliki respons dari CA yang dapat dijadikan staple ke paket dalam jabat tangan SSL. Ketika pemirsa puas bahwa sertifikat valid, CloudFront dapat melayani objek yang diminta. Jika distribusi Anda tidak terlalu banyak CloudFront lokasi tepian, permintaan baru lebih mungkin 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, jadi lain kali menerima permintaan yang menyertakan nama domain yang sama, ia memiliki respons validasi dari CA.

Protokol

CloudFront meneruskan permintaan HTTP atau HTTPS ke server asal berdasarkan protokol permintaan penampil, baik HTTP atau HTTPS.

penting

Jika bucket Amazon S3 Anda dikonfigurasi sebagai titik akhir situs web, Anda tidak dapat mengonfigurasi CloudFront untuk menggunakan HTTPS untuk berkomunikasi dengan asal Anda karena Amazon S3 tidak mendukung koneksi HTTPS dalam konfigurasi tersebut.

String pertanyaan

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

Waktu habis dan upaya koneksi tempat asal

Batas waktu koneksi asal adalah jumlah detik yang CloudFront menunggu ketika mencoba membuat koneksi ke asal.

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

Bersama-sama, pengaturan ini menentukan berapa lama CloudFront mencoba untuk terhubung ke asal sebelum gagal ke asal sekunder (dalam kasus grup asal) atau mengembalikan respons kesalahan ke penampil. Secara default, CloudFront tunggu selama 30 detik (3 upaya masing-masing 10 detik) sebelum mencoba terhubung 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:

• Jumlah waktu, dalam hitungan detik, yang CloudFront menunggu respons setelah meneruskan permintaan ke asal.

• Jumlah waktu, dalam hitungan detik, yang CloudFront menunggu setelah menerima paket respons dari asal dan sebelum menerima paket berikutnya.

CloudFront perilaku tergantung pada metode HTTP dari permintaan penampil:

• GET dan HEAD permintaan – Jika asal tidak merespons dalam waktu 30 detik atau berhenti merespons selama 30 detik, CloudFront akan membuat koneksi terputus. Jika jumlah upaya koneksi asal yang ditentukan lebih dari 1, CloudFront coba lagi untuk mendapatkan respons lengkap. CloudFront mencoba hingga 3 kali, sebagaimana ditentukan oleh nilai pengaturan upaya koneksi asal. Jika asal tidak merespons selama percobaan terakhir, CloudFront tidak mencoba lagi hingga menerima permintaan konten lain di tempat yang sama.

• DELETE,OPTIONS, PATCHPUT,, dan POST permintaan — Jika asal tidak merespons dalam 30 detik CloudFront , lepaskan koneksi dan tidak mencoba lagi untuk menghubungi asal. Klien dapat mengirim ulang permintaan jika perlu.

Anda tidak dapat mengubah waktu respons untuk asal Amazon S3 (wadah S3 yang tidak dikonfigurasi dengan hosting situs web statis).

Permintaan simultan untuk objek yang sama (permintaan runtuh)

Ketika lokasi CloudFront tepi menerima permintaan untuk objek dan objek tidak dalam cache atau objek yang di-cache kedaluwarsa, CloudFront segera kirim 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 titik asal. CloudFront mengirimkan respons dari permintaan asli ke semua permintaan yang diterimanya saat dijeda. Ini disebut request collapsing. Dalam CloudFront log, permintaan pertama diidentifikasi sebagai Miss di x-edge-result-type bidang, dan permintaan yang diciutkan 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 CloudFront mengonfigurasi cache berdasarkan header permintaan atau cookie atau string kueri, CloudFront teruskan semua permintaan dengan kunci cache unik ke asal 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 keruntuhan permintaan 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 sementara CloudFront menunggu respons terhadap permintaan pertama.

penting

Saat ini, CloudFront tidak mendukung keruntuhan permintaan jika Anda mengaktifkan penerusan cookie dalam kebijakan cache, kebijakan permintaan asal, atau pengaturan cache lama.

Bagaimana CloudFront memproses tanggapan dari asal Amazon S3 Anda

Pelajari cara CloudFront memproses respons dari asal Amazon S3 Anda.

Daftar Isi

• Permintaan dibatalkan

• Header respons HTTP yang CloudFront menghapus atau memperbarui

• Ukuran file cache maksimum

• Mengalihkan

Permintaan dibatalkan

Jika suatu objek tidak berada 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 men-cache objek di lokasi tepi.

Header respons HTTP yang CloudFront menghapus atau memperbarui

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

• X-Amz-Id-2

• X-Amz-Request-Id

• Set-Cookie— Jika Anda mengonfigurasi CloudFront untuk meneruskan cookie, itu akan meneruskan bidang Set-Cookie header ke klien. Untuk informasi selengkapnya, lihat Konten cache berdasarkan cookie.

• Trailer

• Transfer-Encoding— Jika asal Amazon S3 Anda mengembalikan bidang header ini, CloudFront tetapkan nilainya chunked sebelum mengembalikan respons ke penampil.

• Upgrade

• Via— CloudFront menetapkan nilai sebagai berikut dalam respons terhadap penampil:

  Via: http-version alphanumeric-string.cloudfront.net (CloudFront)

  Misalnya, nilainya adalah seperti berikut:

  Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)

Ukuran file cache maksimum

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

Anda dapat CloudFront menggunakan cache objek yang lebih besar dari ukuran ini dengan menggunakan permintaan rentang untuk meminta objek di bagian yang masing-masing 50 GB atau lebih kecil. CloudFrontcache bagian-bagian ini karena masing-masing dari mereka adalah 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.

Mengalihkan

Anda dapat mengonfigurasi bucket Amazon S3 untuk mengalihkan semua permintaan ke nama host lain; ini dapat berupa bucket Amazon S3 lain atau server HTTP. Jika Anda mengonfigurasi bucket untuk mengalihkan semua permintaan dan jika bucket adalah asal untuk CloudFront distribusi, sebaiknya Anda mengonfigurasi bucket untuk mengalihkan semua permintaan ke distribusi menggunakan nama domain untuk CloudFront distribusi (misalnya, d111111abcdef8.cloudfront.net) atau nama domain alternatif (CNAME) yang dikaitkan dengan distribusi (misalnya, example.com). Jika tidak, pemirsa meminta bypass CloudFront, dan objek disajikan langsung dari asal baru.

catatan

Jika Anda mengarahkan permintaan ke nama domain alternatif, Anda juga harus memperbarui layanan DNS untuk domain Anda dengan menambahkan catatan CNAME. Untuk informasi selengkapnya, lihat Gunakan kustom URLs dengan menambahkan nama domain alternatif (CNAMEs).

Inilah yang terjadi saat Anda mengonfigurasi keranjang untuk mengalihkan semua permintaan:

1. Penampil (misalnya, browser) meminta objek dari CloudFront.

2. CloudFront meneruskan permintaan ke bucket Amazon S3 yang merupakan asal distribusi Anda.

3. Amazon S3 mengembalikan kode status HTTP 301 (Moved Permanently) serta lokasi baru.

4. CloudFront cache kode status pengalihan dan lokasi baru, dan mengembalikan nilai ke penampil. CloudFront tidak mengikuti pengalihan untuk mendapatkan objek dari lokasi baru.

5. Penampil mengirimkan permintaan lain untuk objek tersebut, tetapi kali ini penampil menentukan lokasi baru yang CloudFront didapatnya:

   • Jika bucket Amazon S3 mengalihkan semua permintaan ke CloudFront distribusi, menggunakan nama domain untuk distribusi atau nama domain alternatif, CloudFront meminta objek dari bucket Amazon S3 atau server HTTP di lokasi baru. Saat lokasi baru mengembalikan objek, CloudFront mengembalikannya ke penampil dan menyimpannya di lokasi tepi.

   • Jika bucket Amazon S3 mengalihkan permintaan ke lokasi lain, permintaan kedua akan melewati. CloudFront Bucket Amazon S3 atau server HTTP di lokasi baru mengembalikan objek langsung ke penampil, sehingga objek tidak pernah di-cache di cache tepi. CloudFront