Share
Dans mon article précédent, nous avons abordé certaines des bases de HTTP, telles que le schéma d'URL, les codes d'état et les en-têtes de requête / réponse. Sur cette base, nous examinerons les aspects plus précis de HTTP, tels que la gestion des connexions, l’authentification et la mise en cache HTTP. Ces sujets sont assez étendus, mais nous allons couvrir les éléments les plus importants.
Une connexion doit être établie entre le client et le serveur avant de pouvoir communiquer entre eux, et HTTP utilise le protocole de transport TCP fiable pour établir cette connexion. Par défaut, le trafic Web utilise le port TCP 80. Un flux TCP est divisé en paquets IP et garantit que ces paquets arrivent toujours dans le bon ordre sans échec. HTTP est un protocole de couche d'application sur TCP, qui est sur IP.
HTTPS est une version sécurisée de HTTP insérant une couche supplémentaire entre HTTP et TCP, appelée TLS ou SSL (Transport Layer Security ou Secure Sockets Layer, respectivement). HTTPS communique par défaut sur le port 443 et nous examinerons plus tard HTTPS dans cet article..
Une connexion HTTP est identifiée par
Le serveur est responsable de toujours répondre avec les en-têtes et les réponses corrects.
Dans HTTP / 1.0, toutes les connexions étaient fermées après une seule transaction. Ainsi, si un client souhaitait demander trois images distinctes au même serveur, il établissait trois connexions distinctes à l'hôte distant. Comme vous pouvez le constater sur le diagramme ci-dessus, cela peut entraîner de nombreux retards sur le réseau, ce qui se traduit par une expérience utilisateur sous-optimale..
Pour réduire les délais d’établissement de connexion, HTTP / 1.1 a été introduit. connexions persistantes, connexions de longue durée qui restent ouvertes jusqu'à ce que le client les ferme. Les connexions persistantes sont définies par défaut dans HTTP / 1.1. Pour établir une connexion unique, le client doit définir Connexion: fermer en-tête de demande. Cela indique au serveur de fermer la connexion après l'envoi de la réponse..
En plus des connexions persistantes, les navigateurs / clients utilisent également une technique appelée connexions parallèles, minimiser les délais réseau. Le concept séculaire de connexions parallèles implique la création d'un pool de connexions (généralement limité à six connexions). Si le client doit télécharger six ressources à partir d'un site Web, il établit six connexions en parallèle pour télécharger ces ressources, ce qui accélère le traitement. Il s'agit d'une énorme amélioration par rapport aux connexions série où le client ne télécharge un actif qu'après le téléchargement d'un actif précédent..
Les connexions parallèles, associées à des connexions persistantes, constituent aujourd'hui la réponse à la réduction des délais réseau et à la création d'une expérience fluide sur le client. Pour un traitement approfondi des connexions HTTP, reportez-vous à la section Connexions de la spécification HTTP..
Le serveur écoute principalement les connexions entrantes et les traite lorsqu'il reçoit une demande. Les opérations impliquent:
Accentsconagua
Connexion: fermer demande en-tête a été trouvéBien entendu, il ne s’agit pas d’une liste exhaustive des opérations. La plupart des applications / sites Web doivent savoir qui fait une demande afin de créer des réponses plus personnalisées. C'est le royaume de identification et authentification.
HTTP est un protocole de couche d'application sur TCP, qui est sur IP.
Il est presque impératif de savoir qui se connecte à un serveur pour suivre l'utilisation d'une application ou d'un site et les schémas d'interaction généraux des utilisateurs. Le principe d’identification est d’adapter la réponse afin de fournir une expérience personnalisée; naturellement, le serveur doit savoir qui est un utilisateur pour fournir cette fonctionnalité.
Un serveur peut collecter ces informations de différentes manières et la plupart des sites Web utilisent une approche hybride:
De, Référant, Agent utilisateur - Nous avons vu ces en-têtes dans la partie 1.Les cookies permettent au serveur de joindre des informations arbitraires pour les réponses sortantes via le Set-Cookie en-tête de réponse. Un cookie est défini avec un ou plusieurs nom = valeur paires séparées par un point-virgule (;), un péché Set-Cookie: session-id = 12345ABC; nom d'utilisateur = nettuts.
Un serveur peut également restreindre les cookies à un domaine et chemin, et il peut les rendre persistants avec un expire valeur. Les cookies sont automatiquement envoyés par le navigateur pour chaque demande adressée à un serveur, et le navigateur garantit que seul le domaine- et chemin-Des cookies spécifiques sont envoyés dans la requête. L'en-tête de la demande Cookie: nom = valeur [; nom2 = valeur2] est utilisé pour envoyer ces cookies au serveur.
Le meilleur moyen d'identifier un utilisateur est de lui demander de s'inscrire et de se connecter, mais l'implémentation de cette fonctionnalité nécessite quelques efforts de la part du développeur, ainsi que de l'utilisateur..
Des techniques telles que OAuth simplifient ce type de fonctionnalité, mais nécessitent toujours l'accord de l'utilisateur pour fonctionner correctement. L’authentification joue ici un rôle important et c’est probablement le seul moyen d’identifier et de vérifier l’utilisateur..
HTTP supporte une forme rudimentaire d’authentification appelée Authentification de base, ainsi que le plus sécurisé Authentification Digest.
Dans l’authentification de base, le serveur refuse initialement la demande du client avec une WWW-Authentifier en-tête de réponse et un 401 non autorisé code d'état. À la vue de cet en-tête, le navigateur affiche une boîte de dialogue de connexion, demandant un nom d'utilisateur et un mot de passe. Cette information est envoyée dans un format codé en base 64 dans le format Authentification en-tête de demande. Le serveur peut maintenant valider la demande et autoriser l'accès si les informations d'identification sont valides. Certains serveurs peuvent aussi envoyer un Authentification-Info en-tête contenant des informations d'authentification supplémentaires.
Un corollaire à l'authentification de base est Authentification proxy. Au lieu d'un serveur Web, le défi d'authentification est demandé par un proxy intermédiaire. Le proxy envoie un Authentification par procuration en-tête avec un 407 non autorisé code d'état. En retour, le client est supposé envoyer les identifiants via le Autorisation de procuration en-tête de demande.
L’authentification Digest est similaire à Basic et utilise la même technique de négociation avec le WWW-Authentifier et Autorisation en-têtes, mais Digest utilise une fonction de hachage plus sécurisée pour chiffrer le nom d'utilisateur et le mot de passe (généralement avec les fonctions de digest MD5 ou KD). Bien que l'authentification Digest soit censée être plus sécurisée que Basic, les sites Web utilisent généralement l'authentification Basic en raison de sa simplicité. Pour atténuer les problèmes de sécurité, l’authentification de base est utilisée conjointement avec SSL..
Le protocole HTTPS fournit une connexion sécurisée sur le Web. Le moyen le plus simple de savoir si vous utilisez HTTPS consiste à vérifier la barre d'adresse du navigateur. Le composant sécurisé de HTTP implique l'insertion d'une couche de cryptage / décryptage entre HTTP et TCP. C’est le protocole SSL (Secure Sockets Layer) ou le protocole TLS (Transport Layer Security) amélioré..
SSL utilise une forme de cryptage puissante utilisant RSA et la cryptographie à clé publique. Les transactions sécurisées étant si importantes sur le Web, un effort d'infrastructure à clé publique (PKI) basé sur des normes omniprésentes est en cours depuis quelque temps.
Les clients / serveurs existants ne doivent pas nécessairement changer la manière dont ils traitent les messages, car la majeure partie du travail pénible s'effectue dans la couche SSL. Ainsi, vous pouvez développer votre application Web à l’aide de l’authentification de base et bénéficier automatiquement des avantages de SSL en basculant vers le https: // protocole. Cependant, pour que l'application Web fonctionne avec HTTPS, vous devez disposer d'un certificat numérique fonctionnel déployé sur le serveur..
Tout comme vous avez besoin de cartes d'identité pour montrer votre identité, un serveur Web a besoin d'un certificat numérique pour s'identifier. Les certificats (ou "certificats") sont émis par une autorité de certification et garantissent votre identité sur le Web. Les CA sont les gardiens de l'ICP. La forme de certificat la plus courante est la norme X.509 v3, qui contient des informations telles que:
Lorsqu'un client effectue une demande via HTTPS, il tente d'abord de localiser un certificat sur le serveur. Si le certificat est trouvé, il tente de le vérifier par rapport à la liste connue des autorités de certification. S'il ne s'agit pas d'une des autorités de certification répertoriées, il est possible qu'une boîte de dialogue s'affiche pour avertir l'utilisateur du certificat du site Web..
Une fois le certificat vérifié, la négociation SSL est terminée et la transmission sécurisée est effective..
Il est généralement admis que faire le même travail deux fois est une perte de temps. C’est le principe directeur du concept de la mise en cache HTTP, un pilier fondamental de l’Infrastructure de réseau HTTP. Comme la plupart des opérations se font sur un réseau, un cache permet de gagner du temps, d’économiser du temps et de la bande passante, tout en offrant une expérience améliorée sur le Web..
Les caches sont utilisés à plusieurs endroits de l'infrastructure réseau, du navigateur au serveur d'origine. Selon l'emplacement où il se trouve, un cache peut être classé comme suit:
Quel que soit l'endroit où se trouve un cache, le processus de maintenance d'un cache est assez similaire:
Bien entendu, il incombe au serveur de toujours répondre avec les en-têtes et les réponses corrects. Si un document n'a pas changé, le serveur doit répondre par un message. 304 non modifié. Si la copie en cache a expiré, elle devrait générer une nouvelle réponse avec des en-têtes de réponse mis à jour et renvoyer avec un 200 OK. Si la ressource est supprimée, elle devrait revenir avec 404 introuvable. Ces réponses permettent d’ajuster le cache et d’éviter que le contenu obsolète ne soit conservé trop longtemps..
Les connexions parallèles, associées à des connexions persistantes, constituent aujourd'hui la réponse à la réduction des délais réseau..
Maintenant que nous avons une idée du fonctionnement d'un cache, il est temps d'examiner les en-têtes de demande et de réponse qui activent l'infrastructure de mise en cache. Maintenir le contenu à jour et à jour est l’une des responsabilités principales du cache. Pour que la copie en cache soit cohérente avec le serveur, HTTP fournit des mécanismes simples, à savoir: Expiration du document et Revalidation du serveur.
HTTP permet à un serveur d'origine d'attacher un date d'expiration à chaque document en utilisant le Cache-Control et Expire réponse en-têtes. Cela aide le client et les autres serveurs de cache à savoir combien de temps un document est valide et actualisé. Le cache peut servir la copie tant que le âge du document est dans la date d'expiration. Une fois le document arrivé à expiration, le cache doit vérifier auprès du serveur une copie plus récente et mettre à jour sa copie locale en conséquence..
Expire est un en-tête de réponse HTTP / 1.0 plus ancien qui spécifie la valeur en tant que date absolue. Cela n'est utile que si les horloges du serveur sont synchronisées avec le client, ce qui est une hypothèse terrible à faire. Cet en-tête est moins utile que le plus récent Cache-Control: max-age = en-tête introduit dans HTTP / 1.1. Ici, max-age est un âge relatif, spécifié en secondes, à partir de la création de la réponse. Ainsi, si un document devait expirer après un jour, l'en-tête d'expiration devrait être Cache-Control: max-age = 86400.
Une fois qu'un document mis en cache a expiré, le cache doit être revalidé avec le serveur pour vérifier si le document a été modifié. C'est appelé revalidation du serveur et sert de mécanisme d'interrogation pour la manque de fraîcheur d'un document. Ce n’est pas parce qu’une copie en cache a expiré que le serveur dispose d’un contenu plus récent. La revalidation est simplement un moyen de s'assurer que le cache reste frais. En raison du délai d'expiration (spécifié dans une réponse précédente du serveur), le cache n'a pas à vérifier auprès du serveur pour chaque requête, ce qui permet d'économiser de la bande passante, du temps et de réduire le trafic réseau..
La combinaison de l'expiration des documents et de la revalidation du serveur est un mécanisme très efficace qui permet aux systèmes distribués de conserver des copies avec une date d'expiration..
Si le contenu change fréquemment, le délai d'expiration peut être réduit, ce qui permet aux systèmes de se synchroniser plus fréquemment..
L'étape de revalidation peut être réalisée avec deux types d'en-tête de requête: Si-Modifié-Depuis et Si-aucun-match. Le premier est destiné à la validation par date, tandis que le dernier utilise des balises Entity (ETags), un hachage du contenu. Ces en-têtes utilisent les valeurs date ou ETag obtenues à partir d'une réponse précédente du serveur. En cas de Si-Modifié-Depuis, la Dernière modification l'en-tête de réponse est utilisé; pour Si-aucun-match, c'est le ETag en-tête de réponse.
La période de validité d'un document doit être définie par le serveur qui génère le document. S'il s'agit d'un site Web de journal, la page d'accueil devrait expirer après une journée (ou parfois même toutes les heures!). HTTP fournit le Cache-Control et Expire en-têtes de réponse pour définir l'expiration des documents. Comme mentionné précédemment, Expire est basé sur des dates absolues et n'est pas une solution fiable pour contrôler le cache.
le Cache-Control header est beaucoup plus utile et a quelques valeurs différentes pour contraindre les clients à mettre en cache la réponse:
De plus, si le serveur n'envoie pas de message Cache-Control En-têtes, le client est libre d’utiliser son propre algorithme d’expiration heuristique pour déterminer la fraîcheur..
La capacité de transport ne se limite pas au serveur. Il peut également être spécifié à partir du client. Cela permet au client d'imposer des contraintes sur ce qu'il est prêt à accepter. Ceci est possible via le même Cache-Control en-tête, mais avec quelques valeurs différentes:
La mise en cache HTTP est en fait un sujet très intéressant et il existe des algorithmes très sophistiqués pour gérer le contenu mis en cache. Pour approfondir ce sujet, reportez-vous à la section Mise en cache de la spécification HTTP..
Notre visite de HTTP a commencé avec la création de schémas d'URL, de codes d'état et d'en-têtes de requête / réponse. En nous basant sur ces concepts, nous avons examiné certaines des zones les plus fines de HTTP, telles que la gestion de connexion, l'identification et l'authentification et la mise en cache. J'espère que cette visite vous a donné un bon goût pour l'ampleur de HTTP et suffisamment d'indicateurs pour explorer plus avant ce protocole..
