Introduction et compréhension approfondie du protocole HTTP

Résume ma compréhension de certains contenus liés au protocole http que j'ai rencontré dans des scénarios de travail réels.

Demande et réponse

Format de demande

GET /api/index.json HTTP/1.1

Par exemple : Accepter : */*; User-Agent : Mozilla/4.0;……

[] Par exemple : id=1×tamp=xxxxxx

Format de réponse

Par exemple : Content-Type : application/json;......

[

Code de statut

Il existe près de 60 codes de statut http. J'enregistre principalement certains codes de statut courants générés. dans des circonstances anormales, nous le rencontrerons plus ou moins dans les applications quotidiennes, ce qui nous aide à comprendre et à découvrir les problèmes.

206 - Utilisé lors d'un téléchargement avec points d'arrêt. Le client a demandé une partie du contenu et le serveur lui a renvoyé avec succès cette partie du contenu. Ce statut est utilisé à ce moment-là.

301 - Saut permanent, l'adresse d'origine n'existe plus, et l'url pointe vers une autre adresse. Ceci est principalement lié aux moteurs de recherche et affecte le comportement de récupération du robot.

302 - Saut temporaire, le serveur renverra une nouvelle URL au client, et le client pourra continuer à accéder à cette URL pour obtenir du contenu.

304 - La ressource n'a pas changé. Le client peut utiliser le contenu mis en cache localement, ce qui est courant dans l'accès au contenu statique.

413 - L'entité de requête est trop grande. Une situation courante consiste à télécharger un fichier volumineux, mais à dépasser la limite du serveur (comme nginx). Ou l'en-tête de la requête ou le corps de la requête dépasse les paramètres du serveur back-end (tel que Tomcat) (par exemple, il y a trop de cookies sous le nom de domaine actuel, dépassant la limite de l'en-tête de la requête)

416 - lié à la reprise du point d'arrêt, demande du client La plage dépasse la taille du fichier sur le serveur.

500 - Erreur interne du serveur, impossible de renvoyer des résultats normaux. Par exemple, l’application la plus courante génère une exception de pointeur nul qui n’est pas gérée.

502 - Erreur de passerelle. Une situation courante est que le serveur backend proxy inverse (tel que resin ou Tomcat) n'est pas démarré.

503 - Service indisponible. Par exemple, la charge du serveur est trop élevée ou le serveur a arrêté de servir.

504 - Délai d'expiration de la passerelle. Par exemple, la durée de la requête dépasse le temps limite de réponse du serveur.

En-têtes

Les en-têtes HTTP sont divisés en deux catégories : l'en-tête de requête et l'en-tête de réponse. Voici quelques en-têtes que nous utilisons souvent.

1. Contrôle du cache

Dans les applications de sites Web Internet, les caches sont presque partout. Dans les services basés sur http, nous pouvons également contrôler certains contenus qui ne le sont pas. les modifications fréquentes sont mises en cache côté client, de sorte que le contenu mis en cache puisse être réutilisé lors de plusieurs visites, accélérant ainsi l'accès et améliorant l'expérience utilisateur. Le protocole http stipule certains en-têtes http pour le contrôle du cache :

Cache-Control(HTTP/1.1)/Pragma(HTTP/1.0) : indique si le client met en cache et combien de temps le temps de cache est long. La valeur par défaut est privée, ce qui signifie que le contenu est mis en cache dans l'espace privé de l'utilisateur. Par exemple : Cache-Control : max-age=86400, must-revalidate, cela indique au client que la ressource demandée est mise en cache pendant un jour (l'unité d'âge maximum est en secondes, temps relatif) et doit être revérifiée après l'expiration.

Expire : Spécifiez combien de temps le client (si aucune actualisation forcée n'est requise) peut lire directement le cache local sans envoyer de requête au serveur.

Remarque :

Priorité : Cache-Control > Expires ;

Description détaillée du paramètre : http://condor.depaul.edu/dmumaugh/readings/handouts/ SE435. /HTTP/node24.html

Les différents comportements des différents navigateurs (actualisation, retour, saisie dans la barre d'adresse, etc.) peuvent avoir des différences d'implémentation

Last-Modified/If- ; Modified -Since : Last-Modified est l'horodatage de la dernière modification de la ressource renvoyé par le serveur au client. De cette manière, le client apportera le paramètre If-Modified-Since pour vérifier si la ressource a été mise à jour lors de la prochaine requête. (comme l'actualisation forcée). Non En cas de mise à jour, le serveur renverra un code d'état 304 et le client accédera directement aux ressources mises en cache localement. À l’heure actuelle, il n’y a qu’une surcharge de requêtes et aucune surcharge de transmission réseau. Remarque : L'horodatage doit être l'heure moyenne de Greenwich (GMT), par exemple : Last-Modified : Sam, 19 Oct 2013 09:20:15 GMT

ETag/If-None-Match : ETag est basé sur le fichier. attributs L'identifiant de ressource généré via un certain algorithme est également utilisé pour déterminer si la ressource demandée par le client a été mise à jour. Si le serveur renvoie une valeur ETag au client, la prochaine fois que le client la demandera, il apportera le paramètre If-None-Match pour vérifier si la ressource est mise à jour. Si elle n'est pas mise à jour, un code d'état 304 sera renvoyé. . (L'effet est fondamentalement le même que Last-Modified)

Remarque :

ETag doit être calculé, ce qui est une consommation pour les serveurs avec des ressources informatiques limitées, donc certains sites Web n'utilisent pas ETag directement;

Si le serveur est derrière un équilibreur de charge, les requêtes pour la même ressource peuvent être distribuées sur différentes machines backend. Étant donné que le calcul de l'ETag dépend des attributs des fichiers, les fichiers ayant le même contenu sur différentes machines peuvent générer des ETags différents, ce qui peut. Échec de la vérification ETag pour les fichiers dont le contenu d'origine n'a pas changé. Il existe deux solutions ici : l'une est que le calcul de l'etag ne dépend pas de la machine locale, comme le calcul direct de la valeur md5 du contenu du fichier ; l'autre consiste à distribuer la même requête URL à la même machine back-end lors du chargement ; balancier.

Dans notre scénario commercial actuel, la mise en cache http a de grandes utilisations :

Utilisez pleinement les ressources du client, telles que certains fichiers statiques auxquels le client doit accéder fréquemment. comme le LOGO, les images publicitaires, etc., peuvent être mis en cache localement sur le client. Cela peut réduire les requêtes réseau, accélérer l'affichage des clients et réduire la pression sur les requêtes du serveur.

Lorsque certains de nos contenus statiques, tels que les actualités, les blogs, etc., sont explorés par les robots des moteurs de recherche, en contrôlant les paramètres du cache, nous pouvons réduire la fréquence d'exploration du robot et réduire le gaspillage inutile de ressources.

Si nos ressources statiques utilisent CDN, la configuration du cache http peut enregistrer un fichier sur le nœud CDN, réduisant ainsi le nombre de retours CDN aux origines, le délai du réseau et la pression du serveur d'origine.

2. Demande de point d'arrêt

Accept-Ranges : lorsque le serveur prend en charge le téléchargement du point d'arrêt, il renvoie cet en-tête de réponse au client. Lorsque le client le sait, il peut envoyer une demande de point d'arrêt. .

Content-Length : La longueur des informations de réponse, indiquant au client la quantité de données renvoyées par la requête en cours. Il convient de noter ici que lors de la soumission d'une demande à l'aide de la méthode head, aucune donnée spécifique ne sera renvoyée, mais Content-Length renverra la taille des données complètes.

Range/Content-Range : le client soumet un en-tête nommé Range lors de la demande, indiquant au serveur quelle partie des données il souhaite demander. Par exemple : Range: bytes=0-1023 signifie demander les octets 0 à 1023. Ensuite, le serveur renvoie le contenu de ces 1024 octets au client, et Content-Range sera inclus dans l'en-tête de réponse. C'est-à-dire : Content-Range : octets 0-1023/4096, ce 4096 est la taille totale du fichier. La requête suivante du client peut commencer à partir du 1024ème octet, plage : bytes=1024-xxxx

　3. Encodage

Accept-Encoding/Content-Encoding : le premier est pris en charge par le client Message reçu type de codage. La valeur par défaut est l'identité, les valeurs facultatives incluent gzip, compress, etc. Ce dernier est le type de codage de contenu des informations de réponse côté serveur, et la compression est couramment utilisée. Les avantages de la compression sont évidents : elle peut réduire considérablement le coût de la transmission réseau. Par rapport à la consommation CPU provoquée par la compression côté serveur, la réduction de la transmission réseau est évidemment plus pratique. Formes courantes : Content-Encoding : gzip, deflate, compress. Habituellement, nous pouvons compresser et transmettre les résultats de réponse tels que html, js, css, xml et json.

Transfer-Encoding : en-tête de réponse. Le type de codage de transfert du message de réponse spécifie la forme de transmission réseau. Généralement, il se présente sous la forme suivante : Transfer-Encoding : chunked. Lorsque le serveur génère du contenu dynamique et ne connaît pas la longueur spécifique des informations de réponse, il peut le transmettre via ce bloc désigné et renvoyer autant de données qu'il traite, il n'est donc pas nécessaire d'attendre que les données soient prêtes et de les renvoyer. tout à coup. Combiné avec le codage de contenu ci-dessus, tel que gzip, il peut être compressé en blocs et transmis. De plus, veuillez noter que lorsque vous utilisez cet encodage pour transmettre, nous ne pouvons pas voir la longueur du contenu car le contenu n'a pas été entièrement généré.

　4.Autres

X-Forward-For : en-tête de requête Utilisé pour identifier la véritable IP de l'utilisateur, notamment lors de l'accès au serveur via un proxy (forward ou reverse) ou lorsque le serveur est en mode proxy. sous charge Égalisez la situation derrière l'appareil. Format : X-forward-For : client,proxy1,proxy2,...L'adresse IP la plus à gauche est la plus proche du client.

User-Agent : en-tête de requête. L'en-tête de requête utilisé par le serveur pour identifier les informations de base du client. Généralement, cela est utile pour identifier les robots de recherche. Dans certains scénarios, cela peut également être utilisé pour effectuer certaines statistiques client.

Referer : en-tête de requête. Lorsque le client accède au serveur, ce Referer précise la source de la requête, par exemple le site Web à partir duquel il est lié. Nous l'utilisons souvent dans certaines statistiques. De plus, une autre utilisation importante consiste à filtrer les sources de requêtes illégales dans des scénarios qui nécessitent un anti-hotlinking des ressources (cependant, ce référent peut être falsifié par le client).

Location : en-tête de réponse. Cet en-tête Location sera inclus dans l'en-tête de réponse du code d'état 301/302 pour indiquer au client d'utiliser la nouvelle adresse pour accéder aux ressources requises.

Connexion : en-tête de requête/réponse. Dans http/1.1, le client et le serveur conservent la connexion par défaut, c'est-à-dire Connexion : conserver la connexion. Si l'une des parties ne souhaite pas conserver la connexion, vous pouvez le faire. put this La valeur est définie sur close. Par défaut, le client et le serveur maintiendront une longue connexion, afin que le client puisse utiliser cette connexion pour envoyer plusieurs requêtes http, réduisant ainsi la consommation causée par la création fréquente de connexions. Pour ce paramètre, davantage de paramètres peuvent être requis côté serveur, tels que le temps de maintien de la connexion et certains paramètres réseau du noyau du serveur (pour TCP).

Session et Cookie

Les requêtes HTTP sont des requêtes sans état, mais dans nos applications Internet, il est souvent nécessaire d'identifier les informations sur l'état de l'utilisateur pour effectuer certaines opérations interactives. Par exemple, l'authentification de l'utilisateur doit enregistrer l'état de connexion de l'utilisateur et les applications de panier d'achat doivent se souvenir de l'utilisateur. sélections. Les produits, les applications publicitaires doivent enregistrer le comportement de navigation historique des utilisateurs, etc. La session et les cookies seront utilisés ici.

session : fait référence à l'état d'interaction entre le client et le serveur pendant le processus de requête-réponse http. Ces informations sont stockées côté serveur, comme la mémoire, la base de données, etc. Chaque session possède un identifiant unique, qui est généré par le serveur. Cet identifiant doit également être enregistré sur le client, afin que le client puisse apporter cet identifiant lors de la prochaine requête pour permettre au serveur de déterminer le statut du client.

Support client pour les sessions :

Enregistrez l'identifiant de session via des cookies et envoyez-le au serveur lors de la demande.

Communiquez avec le serveur en portant l'identifiant de session dans les paramètres de l'url.

Communiquez avec le serveur en portant l'identifiant de session dans le champ caché du formulaire.

Problème de partage de session :

Dans les applications distribuées, notre serveur http est généralement placé derrière un proxy inverse ou un périphérique d'équilibrage de charge, qui sera confronté à un problème de partage de session. C'est-à-dire que plusieurs requêtes du même utilisateur peuvent être distribuées sur plusieurs machines différentes. Si nous enregistrons la session dans la mémoire locale de la machine, nous ne pouvons pas partager la session de l'utilisateur entre plusieurs machines. De manière générale, on peut résoudre ce problème de deux manières :

Stocker la session dans une mémoire distribuée (ex : memcached) ou un stockage centralisé (ex : base de données).

Distribuez les requêtes du même utilisateur sur la même machine sur le proxy inverse ou le périphérique d'équilibrage de charge (le problème de la redistribution des requêtes après la panne de la machine doit être traité ici).

Cookie : conserve des informations dynamiques sur le client. Chaque contenu de cookie appartient à un domaine (domaine) et à un chemin (chemin) spécifiques. Pour des raisons de sécurité, les cookies de différents domaines ou chemins ne peuvent pas être partagés.

Cookie de session : Aucun délai d'expiration n'est précisé, il est stocké en mémoire et expirera après la fermeture du navigateur.

Cookie persistant : précise le délai d'expiration et est enregistré localement dans le navigateur.

Pour plus de détails, veuillez vous référer à : http://en.wikipedia.org/wiki/HTTP_cookie

Il convient de noter que les cookies auront certains problèmes de sécurité.

Ici, je viens de résumer ma compréhension de certains contenus liés au protocole http que j'ai rencontré au travail. Il y a encore beaucoup de choses à explorer dans le protocole http, et nous devons également continuer à explorer et à explorer. comprendre le protocole http. Cela apportera une grande commodité à nos applications de développement.

Enfin, je recommande deux outils de débogage http très NB : fiddler (windows) et charles (mac) ont une fonction proxy http. Pour les applications http qui ne sont pas basées sur un navigateur (comme les applications mobiles), vous pouvez utiliser. ces deux-là Un outil pour surveiller les requêtes http.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!