Comportement des demandes et des réponses pour les origines Amazon S3 Origins

Pour comprendre comment CloudFront traite les demandes et les réponses lorsque vous utilisez Amazon S3 comme origine, consultez les sections suivantes :

Comment CloudFront traiter et transférer les demandes vers votre origine Amazon S3

Découvrez comment CloudFront traite les demandes des spectateurs et les transmet à votre origine Amazon S3.

Table des matières

• Durée de conservation dans le cache et durée de vie minimale

• Adresses IP client

• Demandes GET conditionnelles

• Cookies

• Cross-origin partage de ressources (CORS)

• Demandes GET qui incluent un corps de texte

• Méthodes HTTP

• en-têtes de requête HTTP qui CloudFront suppriment ou mettent à jour

• Longueur maximale d’une demande et longueur maximale d’une URL

• OCSP Stapling

• Protocoles

• Chaînes de requête

• Délai d’attente et tentatives de connexion à l’origine

• Délai de réponse de l’origine

• Demandes simultanées pour le même objet (réduction des demandes)

Durée de conservation dans le cache et durée de vie minimale

Pour contrôler la durée pendant laquelle vos objets restent en CloudFront cache avant de CloudFront transmettre une autre demande à votre origine, vous pouvez :

• Configurer votre origine pour ajouter un Cache-Control ou un champ d’en-tête Expires à chaque objet.

• Spécifiez une valeur pour le TTL minimum dans les comportements CloudFront du cache.

• Utiliser la valeur par défaut de 24 heures.

Pour plus d’informations, consultez Gestion de la durée de conservation de contenu dans le cache (expiration).

Adresses IP client

Si un utilisateur envoie une demande à CloudFront et n'inclut pas d'en-tête de X-Forwarded-For demande, CloudFront il obtient son adresse IP à partir de la connexion TCP, ajoute un X-Forwarded-For en-tête qui inclut l'adresse IP et transmet la demande à l'origine. Par exemple, si CloudFront extrait l'adresse IP 192.0.2.2 de la connexion TCP, il transmet l'en-tête suivant à l'origine :

X-Forwarded-For: 192.0.2.2

Si un utilisateur envoie une demande à CloudFront et inclut un en-tête de X-Forwarded-For demande, CloudFront obtient l'adresse IP du spectateur à partir de la connexion TCP, l'ajoute à la fin de l'X-Forwarded-Foren-tête et transmet la demande à l'origine. Par exemple, si la demande du spectateur inclut X-Forwarded-For: 192.0.2.4,192.0.2.3 et CloudFront obtient l'adresse IP 192.0.2.2 de la connexion TCP, elle transmet l'en-tête suivant à l'origine :

X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2

Note

L’en-tête X-Forwarded-For contient les adresses IPv4 (par exemple, 192.0.2.44) et les adresses IPv6 (par exemple, 2001:0db8:85a3::8a2e:0370:7334).

Lorsque vous analysez des adresses IPv6 dans l'X-Forwarded-Foren-tête, utilisez des bibliothèques d'analyse d'adresses IP standard capables de gérer n'importe quel format IPv6 RFC 4291 valide.

Demandes GET conditionnelles

Lorsqu'il CloudFront reçoit une demande concernant un objet qui a expiré depuis un cache périphérique, il transmet la demande à l'origine Amazon S3 pour obtenir la dernière version de l'objet ou pour obtenir la confirmation d'Amazon S3 que le cache CloudFront périphérique possède déjà la dernière version. Quand Amazon S3 a initialement envoyé l'objet à CloudFront, il a inclus une ETag valeur et une LastModified valeur dans la réponse. Dans la nouvelle demande qui est CloudFront transmise à Amazon S3, ajoutez CloudFront l'un des en-têtes suivants ou les deux :

• Un en-tête If-Match ou If-None-Match qui contient la valeur ETag pour la version expirée de l’objet.

• Un en-tête If-Modified-Since qui contient la valeur LastModified pour la version expirée de l’objet.

Amazon S3 utilise ces informations pour déterminer si l'objet a été mis à jour et, par conséquent, s'il faut renvoyer l'objet entier CloudFront ou uniquement un code d'état HTTP 304 (non modifié).

Cookies

Amazon S3 ne traite pas les cookies. Si vous configurez un comportement de cache pour transférer des cookies vers une origine Amazon S3, CloudFront vous transférez les cookies, mais Amazon S3 les ignore. Toutes les demandes futures pour le même objet, que vous faites varier le cookie ou non, sont servies à partir de l’objet existant dans le cache.

Cross-origin partage de ressources (CORS)

Si vous CloudFront souhaitez respecter les paramètres de partage des ressources entre origines d'Amazon S3, configurez CloudFront pour transférer les en-têtes sélectionnés vers Amazon S3. Pour de plus amples informations, veuillez consulter Mise en cache de contenu basée sur des en-têtes de demandes.

Demandes GET qui incluent un corps de texte

Si une GET demande d'utilisateur inclut un corps, CloudFront renvoie un code d'état HTTP 403 (Interdit) au visualiseur.

Méthodes HTTP

Si vous configurez CloudFront pour traiter toutes les méthodes HTTP qu'il prend en charge, CloudFront accepte les demandes suivantes des spectateurs et les transmet à votre origine Amazon S3 :

• DELETE

• GET

• HEAD

• OPTIONS

• PATCH

• POST

• PUT

CloudFront met toujours en cache les réponses GET et les HEAD demandes. Vous pouvez également configurer CloudFront pour mettre en cache les réponses aux OPTIONS demandes. CloudFront ne met pas en cache les réponses aux demandes qui utilisent les autres méthodes.

Si vous souhaitez utiliser des chargements en plusieurs parties pour ajouter des objets à un compartiment Amazon S3, vous devez ajouter un contrôle CloudFront d'accès à l'origine (OAC) à votre distribution et accorder à l'OAC les autorisations nécessaires. Pour de plus amples informations, veuillez consulter Restriction de l’accès à une origine Amazon S3.

Important

Si vous configurez CloudFront pour accepter et transmettre à Amazon S3 toutes les méthodes HTTP prises CloudFront en charge, vous devez créer un CloudFront OAC pour restreindre l'accès à votre contenu Amazon S3 et accorder à l'OAC les autorisations requises. Par exemple, si vous configurez CloudFront pour accepter et transférer ces méthodes parce que vous souhaitez utiliser la PUT méthode, vous devez configurer les politiques de compartiment Amazon S3 pour gérer les DELETE demandes de manière appropriée afin que les utilisateurs ne puissent pas supprimer les ressources que vous ne souhaitez pas qu'ils suppriment. Pour de plus amples informations, veuillez consulter Restriction de l’accès à une origine Amazon S3.

Pour plus d’informations sur les opérations prises en charge par Amazon S3, consultez la documentation Amazon S3.

en-têtes de requête HTTP qui CloudFront suppriment ou mettent à jour

CloudFront supprime ou met à jour certains en-têtes avant de transmettre les demandes à votre origine Amazon S3. Pour la plupart des en-têtes, ce comportement est le même que pour les origines personnalisées. Pour obtenir la liste complète des en-têtes de requêtes HTTP et la manière dont ils CloudFront sont traités, consultezEn-têtes et CloudFront comportement des requêtes HTTP (origines personnalisées et Amazon S3).

Longueur maximale d’une demande et longueur maximale d’une URL

La longueur maximale d'une demande, y compris le chemin, la chaîne de requête (le cas échéant) et les en-têtes, est de 32 768 octets.

CloudFront construit une URL à partir de la demande. La longueur maximale de cette URL est de 8 192 caractères.

Si une URL dépasse la longueur maximale, CloudFront renvoie le code d'état HTTP 414 (URI trop long) à l'utilisateur. Si une demande dépasse la longueur maximale parce que la taille de l'en-tête est dépassée, CloudFront renvoie le code d'état HTTP 494 au visualiseur. Dans les deux cas, met CloudFront fin à la connexion TCP avec le visualiseur.

OCSP Stapling

Lorsqu'un utilisateur soumet une requête HTTPS pour un objet, CloudFront ou qu'il doit confirmer auprès de l'autorité de certification (CA) que le certificat SSL du domaine n'a pas été révoqué. L'agrafage OCSP accélère la validation des certificats en permettant de valider le certificat et de CloudFront mettre en cache la réponse de l'autorité de certification, de sorte que le client n'a pas besoin de valider le certificat directement auprès de l'autorité de certification.

L'amélioration des performances de l'agrafage OCSP est plus prononcée lors de la CloudFront réception de nombreuses requêtes HTTPS pour des objets du même domaine. Chaque serveur d'un emplacement périphérique CloudFront doit soumettre une demande de validation distincte. Lorsqu'il CloudFront reçoit un grand nombre de requêtes HTTPS pour le même domaine, chaque serveur situé en périphérie reçoit rapidement une réponse de l'autorité de certification indiquant qu'il peut intégrer à un paquet lors de l'établissement de liaison SSL. Lorsque le spectateur est convaincu que le certificat est valide, il CloudFront peut servir l'objet demandé. Si votre distribution ne reçoit pas beaucoup de trafic dans un emplacement périphérique CloudFront , il est plus probable que les nouvelles demandes soient acheminées vers un serveur qui n'a pas encore validé le certificat auprès de l'autorité de certification. Dans ce cas, le visualiseur exécute séparément l'étape de validation et le CloudFront serveur sert l'objet. Ce CloudFront serveur soumet également une demande de validation à l'autorité de certification. Ainsi, la prochaine fois qu'il recevra une demande incluant le même nom de domaine, il recevra une réponse de validation de la part de l'autorité de certification.

Protocoles

CloudFront transmet les requêtes HTTP ou HTTPS au serveur d'origine en fonction du protocole de la demande du spectateur, HTTP ou HTTPS.

Important

Si votre compartiment Amazon S3 est configuré comme point de terminaison de site Web, vous ne pouvez pas le configurer CloudFront pour utiliser le protocole HTTPS pour communiquer avec votre point d'origine, car Amazon S3 ne prend pas en charge les connexions HTTPS dans cette configuration.

Chaînes de requête

Vous pouvez configurer si CloudFront les paramètres de chaîne de requête sont transférés à votre origine Amazon S3. Pour de plus amples informations, veuillez consulter Mise en cache de contenu basée sur les paramètres de chaîne de requête.

Délai d’attente et tentatives de connexion à l’origine

Le délai d'expiration de la connexion à l'origine est le nombre de secondes qui CloudFront s'écoulent lors de la tentative d'établissement d'une connexion avec l'origine.

Les tentatives de connexion à l'origine sont le nombre de CloudFront tentatives de connexion à l'origine.

Ensemble, ces paramètres déterminent la durée pendant CloudFront laquelle vous essayez de vous connecter à l'origine avant de basculer vers l'origine secondaire (dans le cas d'un groupe d'origine) ou de renvoyer une réponse d'erreur à l'utilisateur. Par défaut, CloudFront attend 30 secondes (3 tentatives de 10 secondes chacune) avant de tenter de se connecter à l'origine secondaire ou de renvoyer une réponse d'erreur. Vous pouvez réduire ce délai en spécifiant moins de tentatives, un délai d’attente de connexion plus court, ou les deux.

Pour plus d’informations, consultez Contrôle des délais d’expiration et des tentatives de l’origine.

Délai de réponse de l’origine

Le délai de réponse de l’origine, également appelé délai d’attente des opérations de lecture depuis l’origine ou délai de demande à l’origine, s’applique aux deux valeurs suivantes :

• Durée, en secondes, qui CloudFront attend une réponse après avoir transféré une demande à l'origine.

• Durée, en secondes, qui s'écoule CloudFront entre la réception d'un paquet d'une réponse de l'origine et la réception du paquet suivant.

CloudFront le comportement dépend de la méthode HTTP de la requête du visualiseur :

• GETet HEAD demandes : si l'origine ne répond pas dans les 30 secondes ou cesse de répondre pendant 30 secondes, CloudFront interrompt la connexion. Si le nombre spécifié de tentatives de connexion à l'origine est supérieur à 1, CloudFront essaie à nouveau d'obtenir une réponse complète. CloudFront essaie jusqu'à 3 fois, selon la valeur du paramètre Tentatives de connexion d'origine. Si l'origine ne répond pas lors de la dernière tentative, CloudFront ne réessaie pas tant qu'il ne reçoit pas une autre demande de contenu sur la même origine.

• DELETE,OPTIONS, PATCHPUT, et POST demandes : si l'origine ne répond pas dans les 30 secondes, CloudFront interrompt la connexion et n'essaie pas à nouveau de contacter l'origine. Le client peut soumettre à nouveau la demande si nécessaire.

Vous ne pouvez pas modifier le délai de réponse pour une origine Amazon S3 (un compartiment S3 qui n’est pas configuré avec un hébergement de site web statique).

Demandes simultanées pour le même objet (réduction des demandes)

Lorsqu'un emplacement CloudFront périphérique reçoit une demande pour un objet et que l'objet n'est pas dans le cache ou que l'objet mis en cache a expiré, envoie CloudFront immédiatement la demande à l'origine. Toutefois, s'il existe des demandes simultanées pour le même objet, c'est-à-dire si des demandes supplémentaires pour le même objet (avec la même clé de cache) arrivent à l'emplacement périphérique avant de CloudFront recevoir la réponse à la première demande, CloudFront une pause s'arrête avant de transmettre les demandes supplémentaires à l'origine. Cette brève pause permet de réduire la charge sur l'origine. CloudFront envoie la réponse de la demande d'origine à toutes les demandes qu'il a reçues pendant sa pause. Ce processus se nomme la réduction des demandes. Dans CloudFront les journaux, la première demande est identifiée comme un Miss dans le x-edge-result-type champ, et les demandes réduites sont identifiées comme unHit. Pour plus d'informations sur CloudFront les journaux, consultezCloudFront et journalisation des fonctions Edge.

CloudFront réduit uniquement les requêtes qui partagent une clé de cache. Si les demandes supplémentaires ne partagent pas la même clé de cache parce que, par exemple, vous avez configuré CloudFront la mise en cache en fonction des en-têtes de demande, des cookies ou des chaînes de requête, CloudFront toutes les demandes avec une clé de cache unique sont transmises à votre origine.

Si vous souhaitez empêcher la fusion des demandes, vous pouvez utiliser la politique de cache gérée CachingDisabled, qui empêche également la mise en cache. Pour de plus amples informations, veuillez consulter Utilisation des politiques de cache gérées.

Si vous souhaitez empêcher la fusion des demandes pour certains objets, vous pouvez définir la durée de vie minimale pour le comportement du cache sur 0 et configurer l’origine de sorte à envoyer Cache-Control: private, Cache-Control: no-store, Cache-Control: no-cache, Cache-Control: max-age=0 ou Cache-Control: s-maxage=0. Ces configurations augmenteront la charge sur votre origine et introduiront une latence supplémentaire pour les demandes simultanées qui sont suspendues pendant l' CloudFront attente de la réponse à la première demande.

Comment CloudFront traite les réponses provenant de votre Amazon S3 origin

Découvrez comment CloudFront traite les réponses provenant de votre origine Amazon S3.

Table des matières

• Requêtes annulées

• en-têtes de réponse HTTP qui CloudFront suppriment ou mettent à jour

• Taille de fichier maximale pouvant être mise en cache

• Redirections

Requêtes annulées

Si un objet ne se trouve pas dans le cache périphérique et si un utilisateur met fin à une session (par exemple, ferme un navigateur) après avoir récupéré l'objet depuis votre origine mais avant de pouvoir livrer l'objet demandé, CloudFront ne CloudFront met pas l'objet en cache à l'emplacement périphérique.

en-têtes de réponse HTTP qui CloudFront suppriment ou mettent à jour

CloudFront supprime ou met à jour les champs d'en-tête suivants avant de transmettre la réponse depuis votre origine Amazon S3 au visualiseur :

• X-Amz-Id-2

• X-Amz-Request-Id

• Set-Cookie— Si vous configurez CloudFront pour transférer les cookies, le champ Set-Cookie d'en-tête sera transmis aux clients. Pour de plus amples informations, veuillez consulter Mise en cache de contenu basée sur des cookies.

• Trailer

• Transfer-Encoding— Si votre origine Amazon S3 renvoie ce champ d'en-tête, CloudFront définissez la valeur sur chunked avant de renvoyer la réponse à l'utilisateur.

• Upgrade

• Via— CloudFront définit la valeur suivante dans la réponse au spectateur :

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

  Par exemple, la valeur ressemble à ce qui suit :

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

Taille de fichier maximale pouvant être mise en cache

La taille maximale d'un corps de réponse enregistré CloudFront dans son cache est de 50 Go. Cette taille inclut les réponses de transfert fragmentées qui ne spécifient pas la valeur d’en-tête Content-Length.

Vous pouvez CloudFront utiliser la mise en cache d'un objet dont la taille est supérieure à cette taille en utilisant des requêtes de plage pour demander les objets par parties de 50 Go ou moins chacune. CloudFrontmet ces parties en cache car chacune d'elles fait 50 Go ou moins. Une fois que l’utilisateur a récupéré toutes les parties de l’objet, il peut reconstruire l’objet d’origine plus large. Pour de plus amples informations, veuillez consulter Utiliser les demandes de plage pour mettre en cache de large objets.

Redirections

Vous pouvez configurer un compartiment Amazon S3 pour rediriger toutes les demandes vers un autre nom d’hôte ; il peut s’agir d’un autre compartiment Amazon S3 ou d’un serveur HTTP. Si vous configurez un compartiment pour rediriger toutes les demandes et si le compartiment est à l'origine d'une CloudFront distribution, nous vous recommandons de configurer le compartiment pour rediriger toutes les demandes vers une CloudFront distribution en utilisant soit le nom de domaine de la distribution (par exemple, d111111abcdef8.cloudfront.net) soit un autre nom de domaine (un CNAME) associé à une distribution (par exemple, example.com). Dans le cas contraire, les requêtes du spectateur sont CloudFront contournées et les objets sont servis directement depuis la nouvelle origine.

Note

Si vous redirigez des demandes vers un nom de domaine alternatif, vous devez également mettre à jour le service DNS pour votre domaine en ajoutant un enregistrement CNAME. Pour plus d’informations, consultez Utilisation d’URL personnalisées en ajoutant des noms de domaine alternatifs (CNAME).

Voici ce qui se passe lorsque vous configurez un compartiment pour rediriger toutes les demandes :

1. Un visualiseur (par exemple, un navigateur) demande un objet à CloudFront.

2. CloudFront transmet la demande au compartiment Amazon S3 qui est à l'origine de votre distribution.

3. Amazon S3 renvoie un code de statut HTTP 301 (Déplacé de façon permanente), ainsi que le nouvel emplacement.

4. CloudFront met en cache le code d'état de redirection et le nouvel emplacement, et renvoie les valeurs à l'utilisateur. CloudFront ne suit pas la redirection pour récupérer l'objet depuis le nouvel emplacement.

5. Le visualiseur envoie une autre demande pour l'objet, mais cette fois, il spécifie le nouvel emplacement d'où il a été obtenu CloudFront :

   • Si le compartiment Amazon S3 redirige toutes les demandes vers une CloudFront distribution, en utilisant le nom de domaine de la distribution ou un autre nom de domaine, CloudFront demande l'objet depuis le compartiment Amazon S3 ou le serveur HTTP du nouvel emplacement. Lorsque le nouvel emplacement renvoie l'objet, le CloudFront renvoie au visualiseur et le met en cache dans un emplacement périphérique.

   • Si le compartiment Amazon S3 redirige les demandes vers un autre emplacement, la deuxième demande est ignorée CloudFront. Le compartiment Amazon S3 ou le serveur HTTP du nouvel emplacement renvoie l'objet directement au visualiseur, de sorte que l'objet n'est jamais mis en cache dans un cache CloudFront périphérique.