Nous vous présentons une description des principaux aspects du protocole HTTP - un protocole réseau qui, du début des années 90 à nos jours, permet à votre navigateur de charger des pages Web. Cet article est écrit pour ceux qui commencent tout juste à travailler avec réseaux informatiques et développer des applications réseau, et qui ont encore du mal à lire seuls les spécifications officielles.

HTTP- un protocole de transfert de données largement utilisé, initialement destiné au transfert de documents hypertextes (c'est-à-dire des documents pouvant contenir des liens permettant de naviguer vers d'autres documents).

L'abréviation HTTP signifie Protocole de transfert hypertexte, "Protocole de transfert hypertexte". Selon la spécification OSI, HTTP est un protocole de couche d'application (supérieure, 7e). Actuel sur ce moment la version du protocole, HTTP 1.1, est décrite dans la spécification RFC 2616.

Le protocole HTTP implique l'utilisation d'une structure de transfert de données client-serveur. L'application client génère une requête et l'envoie au serveur, après quoi le logiciel serveur traite cette demande, génère une réponse et la renvoie au client. L'application cliente peut alors continuer à envoyer d'autres requêtes, qui seront traitées de la même manière.

Une tâche traditionnellement résolue à l'aide du protocole HTTP est l'échange de données entre application utilisateur qui accède aux ressources Web (généralement un navigateur Web) et à un serveur Web. À l’heure actuelle, c’est grâce au protocole HTTP que fonctionne le World Wide Web.

HTTP est également souvent utilisé comme protocole de transfert d'informations pour d'autres protocoles. niveau d'application tels que SOAP, XML-RPC et WebDAV. Dans ce cas, le protocole HTTP est dit utilisé comme « transport ».

L'API de nombreux produits logiciels implique également l'utilisation de HTTP pour le transfert de données - les données elles-mêmes peuvent être dans n'importe quel format, par exemple XML ou JSON.

Généralement, le transfert de données HTTP s'effectue via des connexions TCP/IP. Dans ce cas, le logiciel serveur utilise généralement le port TCP 80 (et, si le port n'est pas spécifié explicitement, le logiciel client utilise généralement le port 80 par défaut pour ouvrir les connexions HTTP), bien qu'il puisse en utiliser n'importe quel autre.

Comment envoyer une requête HTTP ?

Le moyen le plus simple de comprendre le protocole HTTP est d'essayer d'accéder manuellement à certaines ressources Web. Imaginez que vous êtes un navigateur et que vous avez un utilisateur qui souhaite vraiment lire les articles d'Anatoly Alizar.

Disons qu'il a entré ce qui suit dans la barre d'adresse :

Http://alizar.habrahabr.ru/

En conséquence, en tant que navigateur Web, vous devez maintenant vous connecter au serveur Web à l'adresse alizar.habrahabr.ru.

Pour ce faire, vous pouvez utiliser n'importe quel utilitaire approprié ligne de commande. Par exemple, telnet :

Telnet alizar.habrahabr.ru 80

Permettez-moi de préciser tout de suite que si vous changez soudainement d'avis, appuyez sur Ctrl + «]» puis entrez - cela vous permettra de fermer la connexion HTTP. En plus de telnet, vous pouvez essayer nc (ou ncat) – selon vos goûts.

Après vous être connecté au serveur, vous devez envoyer une requête HTTP. D'ailleurs, c'est très simple : les requêtes HTTP peuvent comprendre seulement deux lignes.

Afin de générer une requête HTTP, vous devez composer une ligne de départ et également définir au moins un en-tête - il s'agit de l'en-tête Host, qui est obligatoire et doit être présent dans chaque requête. Le fait est que la conversion d'un nom de domaine en adresse IP s'effectue côté client et, par conséquent, lorsque vous ouvrez une connexion TCP, alors serveur distant ne dispose d'aucune information sur l'adresse exacte utilisée pour la connexion : il peut s'agir, par exemple, de l'adresse alizar.habrahabr.ru, habrahabr.ru ou m.habrahabr.ru - et dans tous ces cas, la réponse peut être différente . Cependant, en fait connexion réseau dans tous les cas il s'ouvre avec le noeud 212.24.43.44, et même si initialement lors de l'ouverture de la connexion ce n'est pas cette adresse IP qui a été précisée, mais certaines Nom de domaine, le serveur n'en est en aucun cas informé - et c'est pourquoi cette adresse doit être transmise dans l'en-tête Host.

La ligne de requête de départ (initiale) pour HTTP 1.1 est composée selon le schéma suivant :

Par exemple (une telle ligne de départ peut indiquer que vous demandez page d'accueil site):

Et bien sûr, n’oubliez pas que toute technologie devient beaucoup plus simple et claire lorsque vous commencez réellement à l’utiliser.

Bonne chance et apprentissage fructueux !

Balises : Ajouter des balises

Le principal protocole pour les pages sur Internet est HTTP. Ce protocole est utilisé à chaque fois que vous visitez un nouveau site, lorsqu'un texte ou une image s'affiche sur le site, lorsque vous cliquez sur des liens.

L’ensemble d’Internet est basé sur HTTP, même si la plupart des utilisateurs n’ont aucune idée de la popularité de HTTP dans leur vie quotidienne.

HTTP est le protocole utilisé pour transférer l'hypertexte (HyperText Transfer Protocol).

L'interaction entre votre navigateur et le serveur avec les informations est basée sur ce protocole. Grâce à sa simplicité, le navigateur et le serveur se connectent très rapidement. Mais nous n’avons pas besoin d’entrer dans tous les détails du fonctionnement du protocole ; nous nous contenterons d’expliquer principe de base ses œuvres.

Il existe de nombreux protocoles que vous pouvez utiliser sur Internet, HTTP n'est qu'un parmi tant d'autres, qui a ses propres tâches et objectifs.

Tout est si simple que vous le connaissez déjà logiciel requis pour travailler avec HTTP est votre navigateur.

Quel que soit le nom du navigateur, le nom du protocole est toujours ajouté par défaut dans la barre d'adresse : « http:// ». Vous ne verrez peut-être pas ce texte si le navigateur le cache. Mais il vous suffit de copier le nom du site, ainsi que celui-ci dans dans la bonne place Le protocole HTTP sera également inséré.

- Que signifie le préfixe « http:// » devant le nom du site ?
- Cela signifie que vous accédez à la ressource via le protocole HTTP.

Pourquoi le protocole HTTP a-t-il été créé ?

Avec son aide, sont transmis des documents hypertextes, ou, plus simplement, des pages sur les sites dont nous avons besoin.

Le client (navigateur) reçoit les pages Web et le serveur envoie les pages. Cette technologie est appelée technologie client-serveur.

Grâce au HTTP, il est devenu possible de transmettre des pages Web sur Internet. Mais que contiennent les pages elles-mêmes que le serveur nous envoie ? Code HTML ordinaire qui entre dans le navigateur, qui ne peut qu'interpréter correctement les informations reçues et vous montrer le site terminé.

En 2006, près de la moitié du trafic HTTP Amérique du Nord consistait en streaming audio et vidéo.

Comment fonctionne HTTP

1. Le navigateur envoie une requête demandant page souhaitée serveur.
2. Le serveur reçoit la demande et commence à rechercher la page.
3. Le navigateur reçoit une réponse du serveur avec les résultats de la requête :
   • Code de la page demandée et informations de service - si la page est trouvée.
   • Code d'erreur et informations de service en cas de panne.

Lorsque le navigateur fait une requête pour un fichier, la requête contient équipe spéciale HTTP. Si le fichier demandé existe réellement sur le serveur, le fichier est envoyé. Mais la page de réception doit décider si elle souhaite afficher le fichier à l'écran, l'enregistrer sur le disque ou faire autre chose avec le résultat.

Pour identifier les ressources sur le réseau, le protocole HTTP utilise des URI globaux. La différence entre HTTP et les autres protocoles est qu’il ne sauvegarde pas son état. Autrement dit, l’état entre la paire requête-réponse n’est pas enregistré.

HTTP n'est pas le seul protocole utilisé sur Internet. Également utilisé :

• FTP ( Transfert de fichier Protocole) - protocole de transfert de fichiers.
• POP (Post Office Protocol) et SMTP (Simple Mail Transport Protocol) - pour échanger des messages électroniques.
• SHTTP (Secure Hypertext Transfer Protocol) est une version cryptée de HTTP. Les informations transmises via ce protocole sont cryptées. En règle générale, la sécurité est importante lorsque des données sensibles sont échangées.

Et d'autres protocoles qui ont une bonne propriété : ils fonctionnent tous inaperçus pour vous et moi.

Mars 1991 - Tim Berners-Lee propose d'utiliser HTTP.

C'est Berners-Lee qui a développé tous les premiers éléments liés à Internet : le navigateur, le serveur, les hyperliens, le premier site Internet (info.cern.ch). Vous pouvez voir à quoi ressemblait le premier site Internet en suivant le lien.

Les versions HTTP s'améliorent avec le temps ; HTTP 1.1 est devenu populaire, ce qui permet pendant longtemps laisser la connexion entre le serveur et le navigateur ouverte, ce qui rendait le protocole plus efficace.

En 2015 est apparu HTTP/2, devenu binaire, et la manière de fragmenter l’information a changé.

Sécurité HTTP

HTTP lui-même n'implique pas le cryptage des informations. Mais il existe une extension pour le protocole qui peut regrouper les données dans Protocole SSL ou TLS.

HTTPS (S - Secure) est une solution populaire qui ne permet pas l'interception des informations transmises et protège les informations contre les attaques MITM « man-in-the-middle » ou les attaques man-in-the-middle.

MITM est essentiellement un téléphone corrompu dans lequel les informations sont délibérément modifiées. Ni le client ni le serveur ne sont au courant de la substitution.

En quoi consiste HTTP ?

Nous avons souvent mentionné que le serveur et le client envoient et reçoivent des requêtes. Alors, que contiennent ces demandes ? Chaque message HTTP se compose de trois parties :

1. La ligne de départ, qui spécifie le type de message.
2. En-têtes qui caractérisent le corps du message.
3. Le corps du message, qui contient déjà les données nécessaires.

Grâce aux fonctionnalités de HTTP, nous avons pu créer moteurs de recherche, forums, boutiques en ligne. Le commerce est arrivé sur Internet, des fournisseurs Internet et d'autres sociétés dont les activités se déroulent sur Internet ont commencé à apparaître. Et tout cela grâce au protocole HTTP, que vous connaissez désormais très bien.

Bientôt, Internet passera au protocole HTTP/2, ce qui optimisera considérablement le fonctionnement des sites, et le monde entier passera à de nouvelles normes de travail sur le réseau mondial, de nouvelles normes de sécurité et, à terme, des normes de vitesse de transfert d'informations. Tout cela est assuré par le protocole HTTP/2 - une version améliorée du protocole http classique, sur lequel fonctionne encore la quasi-totalité de l'Internet mondial. Description d'un nouvel algorithme de transmission de données sur le Réseau.

Qu'est-ce que c'est et pourquoi est-ce nécessaire

HTTP, ou HyperText Transfer Protocol, ou HyperText Transfer Protocol– un ensemble de règles et de protocoles selon lesquels il fonctionne aujourd'hui Internet mondial. Il forme les règles de transmission fichiers graphiques, des messages texte, fichiers sonores et multimédias - en d'autres termes, les règles de présentation visuelle des informations sur Internet. HTTP/2 est une nouvelle génération de ces protocoles, car HTTP/1.1 est utilisé depuis 1999 et depuis lors, la plupart des sites modernes ne peuvent plus se contenter de prendre en charge une technologie HTTP obsolète. Aller à nouvelle version ne vous fait pas attendre.

Quelle est la différence entre http/2 et http ?

Le développement d'une nouvelle version du protocole est associé à des performances, une sécurité et une facilité d'utilisation améliorées. Tout cela est réalisé en réduisant le délai de traitement par le navigateur des opérations de production de base sur Internet. Des fonctionnalités telles que le contrôle de flux, qui permet de contrôler la vitesse de transfert des données, ou la gestion des erreurs, aident lors du développement.

En même temps, HTTP/2 n’est qu’une extension de HTTP1, dont le remplacement n’est pas encore prévu. La deuxième version du protocole sera compatible avec la première version. Tous les avantages de la nouvelle version ne feront que être complétés et améliorés au fil du temps, des modifications seront apportées régulièrement, HTTP/2 évoluera constamment. Le protocole mis à jour contiendra l'algorithme pour toutes les options de cryptage disponibles avec ancienne version, mais au fil du temps, de meilleures options de cryptage seront certainement découvertes.

Il faut comprendre que beaucoup de temps s'est écoulé depuis l'avènement de HTTP1.1, le web a subi d'énormes changements et s'est énormément développé, il est donc nécessaire de colmater tous ces trous qui sont apparus sur une période de plus de dix ans depuis le développement de la première version.

Possibilités

Ce protocole optimise sérieusement le fonctionnement des sites web grâce à plusieurs avantages :

• connexions persistantes: Auparavant, demander une URL individuelle nécessitait la création de connexions TCP distinctes. Il existe désormais une connexion pour tout ;
• priorités des fils de discussion: vous pouvez définir des priorités sur les serveurs - quelles ressources sont les plus importantes pour vous ;
• compression d'en-tête: la taille de l'en-tête HTTP peut être compressée ;
• envoi de données push: le serveur est capable de vous envoyer certaines données avant même la requête.

Multiplexage

Le multiplexage est une technique en HTTP2, avec lequel il est possible d'envoyer plusieurs requêtes à la fois, tandis que les réponses sont reçues de manière asynchrone via une seule connexion. Le multiplexage est le cœur du protocole http2. Il vous permet d'envoyer plusieurs requêtes en même temps sans démarrer une connexion distincte pour chacune.

Lorsque vous travaillez avec http1, lors du chargement d'une page, la page HTML est chargée, le système voit qu'elle a besoin de certains fichiers : CSS, images, javascript, etc. Votre navigateur charge d'abord la page, puis fait une requête pour le CSS. Après cela, le script est demandé. Puis une photo et ainsi de suite. Vous ne pouvez travailler qu'avec un seul d'entre eux à la fois.

Après l'envoi d'une requête, le système attend qu'une réponse soit reçue. Ce n'est pas un problème de navigateur, mais un problème avec le protocole lui-même, puisque le navigateur n'a pas besoin d'attendre une réponse à toutes ces requêtes, et cela prend du temps. Par conséquent, l'un des principaux problèmes d'Internet aujourd'hui est la lenteur du réseau lors du contact entre le serveur et le client lui-même. Le temps dans ce cas peut être de quelques millisecondes, ce qui n'est peut-être pas beaucoup, mais une fois additionnés, ils ralentissent généralement le navigateur - d'autant plus que la structure des sites devient de plus en plus complexe et que l'accès à Internet devient de plus en plus mobile ( avec moins de latence par rapport à l'Internet classique).

HTTP/2 permet d'envoyer plusieurs requêtes à la fois dans le même sens, en ignorant toute cette séquence. Toutes ces requêtes transitent via Internet vers le serveur en parallèle. Le serveur répond à chacun puis revient.

IMPORTANT : HTTP/1.1 contient ce que l'on appelle le traitement pipeline, qui permet également d'envoyer plusieurs requêtes en même temps. Mais c'est beaucoup moins fonctionnel que le multiplexage.

Priorité

La possibilité de prioriser est une autre innovation de HTTP/2. Chaque demande peut désormais se voir attribuer une priorité. Il existe deux manières d'attribuer une priorité : en fonction du poids ou en fonction de la dépendance.

Dans le premier concept, chaque fil se voit attribuer un poids. En fonction de ce poids, le serveur redistribue la charge entre les threads.

La deuxième et principale approche HTTP/2 implique que le navigateur demande d'abord au serveur de renvoyer un contenu spécifique en fonction du type ; par exemple, le navigateur peut d'abord demander Fichiers CSS ou JS, puis HTML, puis images.

Dans HTTP/2, la priorisation n'est pas obligatoire, mais elle est préférable car le multiplexage ne fonctionnera pas comme prévu. Les téléchargements peuvent même être plus lents qu'en HTTP/1.1. Les ressources les moins prioritaires seront monopolisées débit, ce qui réduit les performances.

Qu'apporte la priorisation :

• Une mise en réseau plus efficace.
• Réduire les coûts de temps.
• Accélérez les temps de chargement des pages Web.
• Optimiser le transfert de données entre le serveur et le client.

Compression d'en-tête

Aujourd'hui, les pages Web sont avant tout une combinaison d'un grand nombre divers éléments: images, java-script, CSS, etc. Chaque fois que le navigateur demande l'un de ces éléments, il envoie l'en-tête HTTP correspondant. Le serveur ajoute ensuite un en-tête aux éléments demandés. Cela consomme des ressources importantes.

En HTTP/2, les en-têtes sont compressés. Cela réduit la quantité d'informations échangées entre le serveur et le navigateur. Au lieu des algorithmes gzip/deflate, HPACK est utilisé comme l’approche la plus pratique et la plus simple pour la compression d’en-tête. Cela réduit également la vulnérabilité aux attaques BREACH. L'utilisation de HPACK présente de nombreux avantages :

• Suppression de la charge supplémentaire et de la consommation de ressources.
• Réduction de la taille individuelle des données transmises après réduction de l'en-tête.
• Invulnérabilité aux attaques de sécurité.

Poussée du serveur

HTTP/2 Server Push est l'une des fonctionnalités de performances incluses dans la version 2 du protocole HTTP. Cela permet au serveur Web de fournir au client à l'avance (avant même la demande) les informations qu'il pourrait demander à l'avenir. HTTP/2 Server Push est basé sur le fait qu'un client qui nécessite telle ou telle information en demandera d'autres dans le futur. En d’autres termes, le jeu n’est pas en avance sur son temps.

Comment fonctionne Push à titre d'exemple : Votre navigateur demande une page web (index.html dans notre exemple), et le serveur vous renvoie trois objets : index.html, ainsi que deux objets supplémentaires : scripts.js et styles.css, qui sont stockés dans un cache spécial réservé à cet effet. Le client analyse ensuite index.html et se rend compte que trois objets sont nécessaires pour charger la page : scripts.js, styles.css et image.jpg. Les deux premiers sont déjà dans le cache du navigateur puisqu'ils ont été enregistrés par le serveur, il suffit donc au client de demander image.jpg au serveur pour afficher la page.

Cette fonction présente de nombreux avantages :

• Les ressources client sont stockées dans le cache.
• Les ressources enregistrées peuvent être réutilisées sur d’autres sites Web.
• Le client peut toujours renoncer à ses ressources pour préserver l'efficacité du stockage en cache, ou désactiver complètement la fonction du serveur push.

Le protocole multiplexe et priorise le flux de données intégré, afin de rendre le transfert de données plus efficace et productif, ce qui est évident si l'on considère d'autres flux requête-réponse.

SSL et cryptage

Passer à HTTPS/2, vous passez automatiquement en HTTPS, c'est-à-dire en mode protégé sur le réseau. Cependant, c'est le seul mode dans lequel le navigateur Web fonctionnera. HTTPS cryptera absolument tout le trafic Internet et nécessitera un certificat (aujourd'hui, vous pouvez trouver un certificat DV classique sans dépenser un centime, par exemple via le certificat SSL WoSign, ou via Lets Encrypt, bien que Google puisse cesser de faire confiance à leurs certificats à tout moment, donc Vous devez prêter une attention particulière à l’ordre du jour.)

Binaire

HTTP/2 est un protocole binaire. Les protocoles binaires sont plus efficaces pour analyser et réduire les erreurs que les protocoles basés sur du texte, dans lesquels les utilisateurs écrivent des requêtes manuellement via TELNET. Le binaire accélère le transfert de données et impose moins de charge au client, ce qui facilite grandement la mise en œuvre des tâches.

La binarité de la nouvelle version du protocole est nécessaire afin de simplifier la formation des paquets, ainsi que leur reconnaissance. Les jours de HTTP/1.1 étaient comptés à bien des égards car il est devenu évident que déterminer le début et la fin d’un paquet prenait trop de temps. Profitant des avantages et des innovations de ce protocole, nous évitons les répétitions et les enregistrements interminables de la même chose, optimisant ainsi notre propre travail.

De plus, il est désormais possible de séparer très simplement la partie associée au protocole lui-même et le paquet de données, contrairement à l'ancien HTTP1, où tout était spontanément mélangé.

Voici donc les principaux avantages du protocole binaire:

• Très peu de surcoût lors de l’analyse des données.
• Beaucoup moins sujet aux erreurs par rapport à la version précédente du protocole.
• Une plus grande facilité de maîtrise de l’espace réseau.
• Une plus grande efficacité dans l’utilisation des ressources du réseau.
• Élimination de toutes les failles de sécurité et de chiffrement ainsi que des attaques régulières associées au fait que HTTP/1.1 est basé sur du texte.
• Par nos propres moyens des opportunités uniques HTTP/2, comme le push, le multiplexage, la priorisation, le contrôle de flux et l'optimisation du réseau.
• Simplifiez le traitement et la mise en œuvre des commandes.
• Accélération du transfert de données entre client et serveur.
• Latence du réseau considérablement réduite et débit accru.

Prise en charge du navigateur

Aujourd'hui, la majorité absolue navigateurs actuels: à la fois ordinateur de bureau et mobile, prend en charge la technologie HTTP/2. Les premiers d'entre eux étaient des géants tels que Google Chrome et Mozzila Firefox, qui prennent en charge ce protocole depuis de nombreuses années. Plus tard, suivant apparemment leur exemple, Apple a ajouté un support technologique à son navigateur Safari en 2014. Après cela, moins principaux navigateurs a commencé à travailler dans cette direction. Dans ce cas, le navigateur IE Explorer nécessite Versions Windows au moins 8 pour travailler avec ce protocole.

Les navigateurs mobiles ne sont pas en reste et ont déjà connecté le protocole à la plupart des plateformes existantes. Ceci s'applique au navigateur Android, Chrome pour Android et iOS, Safari, à partir d'iOS 8 - données navigateurs mobiles prend déjà en charge HTTP/2. Dans le même temps, avec le passage du temps et la pénétration de la technologie dans la vie quotidienne, la zone de distribution est également en constante expansion.

Optimisation des moteurs de recherche (SEO)

Bien sûr, la plupart de ceux qui possèdent ou ont déjà possédé leur propre ressource comprendront. L’un des facteurs les plus importants permettant de classer les sites dans les moteurs de recherche est la vitesse moyenne de chargement des sites.

Ainsi, les ressources fonctionnant sur la nouvelle version du protocole HTTP recevront un bonus de classement précisément en raison de la vitesse de chargement du site, car . Un autre avantage est que lorsque vous passez à http2, vous passez automatiquement à HTTPS et, par conséquent, vous obtenez également un bonus de classement. moteurs de rechercheégalement l'utilisation de HTTPS.

Optimisation du site Web

Pour la version précédente Le protocole a utilisé diverses optimisations - cela était nécessaire pour contourner les lacunes et les limitations qui existent dans HTTP/1. Certaines de ces solutions d'optimisation peuvent également fonctionner dans Version mise à jour protocole, mais beaucoup devront être abandonnés, ou du moins modifiés. Même si certains d’entre eux ne seront tout simplement pas nécessaires, la nouvelle version du protocole n’étant qu’une extension de l’ancienne version, les sites fonctionneront dans tous les cas avec toutes les anciennes optimisations. Voici ceux auxquels vous devez prêter attention :

1. Combiner des images dans des sprites CSS. Dans la première version du protocole, il est efficace de combiner des images petites et moyennes en un seul sprite, car une seule connexion est requise. Mais s’il n’y a qu’une seule image, vous devrez charger complètement le sprite. En HTTP2, grâce au multiplex, il est possible de faire plusieurs requêtes et il est plus pratique de télécharger plusieurs petites images en même temps. Bien que parfois, il soit toujours recommandé de combiner des images dans un sprite pour améliorer la qualité de compression et la capacité de chargement.
2. Possibilité d'intégrer des images dans le corps de la page à l'aide de données : URI. Il s'agit d'une autre solution courante au problème des requêtes multiples dans l'ancienne version du protocole : les images étaient intégrées en CSS via les données : URI. La taille du fichier peut augmenter sensiblement, mais moins de connexions seront nécessaires. En HTTP2 cette approche peut toujours être pertinent, mais n’améliorera pas les performances.
3. Combiner des fichiers JS et CSS dans un seul fichier . De cette façon, lorsque la page se charge, les feuilles de style et le code javascript sont chargés immédiatement. De plus, le navigateur met en cache l'intégralité de ce fichier et même des modifications minimes du code nécessiteront un rechargement de l'intégralité du fichier. Le multiplexage résout complètement ce problème et élimine cet inconvénient.
4. Partage de domaine. Dans l'ancienne version de http, le nombre de connexions ouvertes est limité. Si vous devez télécharger plusieurs ressources à la fois, vous pouvez souvent les obtenir à partir de différents domaines ou sous-domaines du domaine principal. HTTP/2 crée la possibilité de créer autant de ressources que vous le souhaitez, éliminant essentiellement le besoin de cette fonctionnalité, mais le partage de domaine a un impact négatif sur les performances en raison des nombreuses connexions TCP ouvertes.

Comment se connecter

Pour mettre le protocole en service, vous n'aurez rien besoin de changer dans l'espace de travail habituel : vous n'aurez pas besoin de modifier les URL des pages, d'effectuer des redirections, de modifier les liens, de faire des balises ou de saisir des données supplémentaires pour la protection. Lors de la connexion HTTP2 au site, il vous suffit d'activer HTTPS et effectuez toutes les démarches nécessaires, rien de plus, de cette façon le cryptage sera activé et le site sera protégé.

Pour vérifier la prise en charge du navigateur pour le protocole HTTP2 vous pouvez utiliser des extensions spéciales pour les navigateurs Mozzila Firefox et Google Chrome, et également utiliser l'outil de contrôle de vitesse sur le site Airi.rf : après vérification, l'un des voyants doit s'allumer - si le navigateur prend en charge le protocole HTTP2, alors un vert lumière [HTTP/ 2.0]. Il existe d'autres services Internet permettant de vérifier la prise en charge du protocole modernisé, l'un d'eux est le service http2.pro.

Conclusion

Une nouvelle ère dominée par HTTP/2 est presque à nos portes : le protocole est déjà supporté par de nombreux navigateurs. L'ère du nouveau Web sera beaucoup plus rapide, plus sûre et très confortable à utiliser ; nous pouvons d'ores et déjà accepter que http2 soit la norme par laquelle nous voyagerons sur le réseau mondial dans un avenir proche.

6.1 Service WWW

Le service WWW (World Wide Web) est destiné à l'échange d'informations hypertextes.

Le projet a été proposé en 1989. Le premier navigateur est apparu en 1993.

WWW est construit selon le schéma client-serveur.

Navigateur(Internet Explorer, Opera...) est un client multiprotocole et un interpréteur HTML. Et comme un interpréteur typique, le client exécute diverses fonctions en fonction des commandes (balises). Ces fonctions incluent non seulement le placement de texte sur l'écran, mais aussi l'échange d'informations avec le serveur au fur et à mesure de l'analyse du texte HTML reçu, ce qui se produit le plus clairement lors de l'affichage d'images graphiques intégrées dans le texte.

Serveur HTTP(Apeche, IIS...) gère les requêtes des clients pour obtenir un fichier (dans le cas le plus simple).

Interaction entre client et serveur via le protocole HTTP.

Au départ, le service WWW reposait sur trois standards :

HTML (HyperText Markup Langage) - langage balisage hypertexte documents;

URL (Localisateur de ressources universel) - méthode universelle adresser les ressources sur le réseau ;

HTTP (HyperText Transfer Protocol) est un protocole d'échange d'informations hypertextes.

CGI (Common Gateway Interface) est une interface de passerelle universelle. Créé pour l'interaction entre un serveur HTTP et d'autres programmes installés sur le serveur (par exemple, un SGBD).

6.2 Protocole HTTP

Le premier document (mais pas une norme) est la RFC1945 (Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk mai 1996)

Quelques fonctionnalités du programme :

définir la profondeur d'analyse du site, et Liens externes

en spécifiant le type de fichier (extension) à télécharger, par exemple, vous pouvez télécharger uniquement des graphiques.

définir une limite de taille de fichier.

scanner les cartes graphiques.

définition d'un horaire de travail, planificateur intégré.

en spécifiant le nom du client, s'il existe une restriction pour certains clients.

définir le nombre de fichiers téléchargés simultanément.

HTTP est un protocole de transfert d'hypertexte entre systèmes distribués. Essentiellement, http est l'élément fondamental Web moderne. En tant que développeurs Web qui se respectent, nous devrions en savoir le plus possible à ce sujet.

Examinons ce protocole à travers le prisme de notre profession. Dans la première partie, nous passerons en revue les bases et examinerons les demandes/réponses. Dans le prochain article, nous examinerons des fonctionnalités plus détaillées, telles que la mise en cache, le traitement des connexions et l'authentification.

Également dans cet article, je ferai principalement référence à la norme RFC 2616 : Hypertext Transfer Protocol -- HTTP/1.1.

Bases du HTTP

HTTP permet la communication entre plusieurs hôtes et clients et prend en charge une gamme de paramètres réseau.

Fondamentalement, TCP/IP est utilisé pour la communication, mais ce n'est pas le seul variante possible. Par défaut, TCP/IP utilise le port 80, mais d'autres peuvent être utilisés.

La communication entre l'hôte et le client se déroule en deux étapes : demande et réponse. Les formulaires clients Requête HTTP, en réponse à quoi le serveur donne une réponse (message). Un peu plus tard, nous examinerons ce schéma de travail plus en détail.

La version actuelle du protocole HTTP est la 1.1, dans laquelle quelques nouvelles fonctionnalités ont été introduites. À mon avis, les plus importants d'entre eux sont : la prise en charge d'une connexion constamment ouverte, un nouveau mécanisme de transfert de données, un codage de transfert fragmenté, de nouveaux en-têtes pour la mise en cache. Nous en examinerons certains dans la deuxième partie de cet article.

URL

Le cœur de la communication Web est la requête, qui est envoyée via l'Uniform Resource Locator (URL). Je suis sûr que vous savez déjà ce qu'est une URL, mais par souci d'exhaustivité, j'ai décidé de dire quelques mots. La structure de l'URL est très simple et se compose des éléments suivants :

Le protocole peut être soit http pour des connexions régulières, soit https pour un échange de données plus sécurisé. Le port par défaut est 80. Il est suivi du chemin d'accès à la ressource sur le serveur et d'une chaîne de paramètres.

Méthodes

À l'aide d'une URL, nous définissons le nom exact de l'hôte avec lequel nous voulons communiquer, mais l'action que nous devons effectuer ne peut être communiquée qu'en utilisant la méthode HTTP. Bien entendu, il existe plusieurs types d’actions que nous pouvons entreprendre. HTTP implémente les plus nécessaires, adaptés aux besoins de la plupart des applications.

Méthodes existantes :

OBTENIR: Accédez à une ressource existante. L'URL répertorie toutes les informations nécessaires pour que le serveur puisse trouver et renvoyer la ressource demandée en réponse.

POSTE: Utilisé pour créer une nouvelle ressource. Une requête POST contient généralement tous information nécessaire pour créer une nouvelle ressource.

METTRE: Mettre à jour la ressource actuelle. La requête PUT contient les données à mettre à jour.

SUPPRIMER: Utilisé pour supprimer une ressource existante.

Ces méthodes sont les plus populaires et sont le plus souvent utilisées par divers outils et frameworks. Dans certains cas, les requêtes PUT et DELETE sont envoyées via envoi du POST, dont le contenu indique l'action à effectuer avec la ressource : créer, mettre à jour ou supprimer.

HTTP prend également en charge d'autres méthodes :

TÊTE: Similaire à GET. La différence est qu'avec ce type de requête aucun message n'est transmis. Le serveur ne reçoit que les en-têtes. Utilisé, par exemple, pour déterminer si une ressource a été modifiée.

TRACER: lors de la transmission, la requête transite par de nombreux points d'accès et serveurs proxy, dont chacun saisit ses propres informations : IP, DNS. En utilisant cette méthode, vous pouvez voir toutes les informations intermédiaires.

OPTIONS: utilisé pour définir les capacités, les paramètres et la configuration du serveur pour une ressource spécifique.

Codes d'état

En réponse à une demande du client, le serveur envoie une réponse, qui contient également un code d'état. Ce code a une signification particulière afin que le client puisse mieux comprendre comment interpréter la réponse :

1xx : Messages d'information

Un ensemble de ces codes a été introduit dans HTTP/1.1. Le serveur peut envoyer une requête de la forme : Expect : 100-continue, ce qui signifie que le client envoie toujours le reste de la requête. Les clients exécutant HTTP/1.0 ignorent ces en-têtes.

2xx : messages de réussite

Si le client a reçu un code de la série 2xx, la demande a été envoyée avec succès. L'option la plus courante est 200 OK. À Requête OBTENIR, le serveur envoie la réponse dans le corps du message. Il existe également d'autres réponses possibles :

• 202 Accepté: La requête est acceptée, mais ne peut pas contenir la ressource dans la réponse. Ceci est utile pour les requêtes asynchrones côté serveur. Le serveur détermine s'il doit envoyer la ressource ou non.
• 204 Aucun contenu: Il n'y a aucun message dans le corps de la réponse.
• 205 Réinitialiser le contenu: Demande au serveur de réinitialiser la présentation du document.
• 206 Contenu partiel: La réponse ne contient qu'une partie du contenu. Des en-têtes supplémentaires déterminent la longueur totale du contenu et d'autres informations.

3xx : redirection

Une sorte de message au client sur la nécessité d'entreprendre une action supplémentaire. Le cas d'utilisation le plus courant consiste à rediriger le client vers une autre adresse.

• 301 Déménagé Définitivement: La ressource peut désormais être trouvée à une URL différente.
• 303 Voir Autre: La ressource peut temporairement être trouvée à une URL différente. L'en-tête Location contient une URL temporaire.
• 304 Non modifié: Le serveur détermine que la ressource n'a pas été modifiée et le client doit utiliser la version mise en cache de la réponse. Pour vérifier l'identité des informations, ETag (Entity Tag hash) est utilisé ;

4xx : erreurs client

Cette classe de message est utilisée par le serveur s'il décide que la demande a été envoyée par erreur. Code le plus courant : 404 Pas trouvé. Cela signifie que la ressource n'a pas été trouvée sur le serveur. Autres codes possibles :

• 400 requêtes incorrectes: La question a été mal formulée.
• 401 Non autorisé: Une authentification est requise pour faire une demande. Les informations sont transmises via l’en-tête Authorization.
• 403 Interdit: Le serveur n'a pas autorisé l'accès à la ressource.
• Méthode 405 non autorisée: Une méthode HTTP non valide a été utilisée pour accéder à la ressource.
• 409 Conflit: le serveur ne peut pas traiter entièrement la requête car essaie de modifier une version plus récente d'une ressource. Cela arrive souvent avec les requêtes PUT.

5xx : erreurs de serveur

Une série de codes utilisés pour détecter une erreur de serveur lors du traitement d'une demande. Le plus courant : 500 Serveur interne Erreur. Autres options:

• 501 Non mis en œuvre: Le serveur ne prend pas en charge la fonctionnalité demandée.
• 503 Service Indisponible: Cela peut arriver si le serveur a une erreur ou est surchargé. Habituellement, dans ce cas, le serveur ne répond pas et le délai imparti pour la réponse expire.

Formats de message de demande/réponse

Dans l'image suivante, vous pouvez voir un processus schématique d'envoi d'une requête par le client, de traitement et d'envoi d'une réponse par le serveur.

Regardons la structure d'un message transmis via HTTP :

Message = *() CRLF [ ] = Ligne de demande | Ligne d'état = Nom du champ ":" Valeur du champ

Il doit y avoir une ligne vide entre l'en-tête et le corps du message. Il peut y avoir plusieurs rubriques :

Le corps de la réponse peut contenir informations complètes ou une partie de celui-ci, si la fonctionnalité correspondante est activée (Transfer-Encoding: chunked). HTTP/1.1 prend également en charge l'en-tête Transfer-Encoding.

Rubriques générales

Voici plusieurs types d’en-têtes utilisés à la fois dans les requêtes et les réponses :

En-tête général = Cache-Control | Connexion | Dates | Pragma | Remorque | Transfert-Encodage | Mise à niveau | Par | Avertissement

Nous avons déjà abordé certaines choses dans cet article, certaines seront abordées plus en détail dans la deuxième partie.

L'en-tête via est utilisé dans une requête TRACE et est mis à jour par tous les serveurs proxy.

L'en-tête Pragma est utilisé pour répertorier les en-têtes personnalisés. Par exemple, Pragma : no-cache est identique à Cache-Control : no-cache. Nous en parlerons davantage dans la deuxième partie.

L'en-tête Date est utilisé pour stocker la date et l'heure de la demande/réponse.

L'en-tête Upgrade est utilisé pour modifier le protocole.

Transfer-Encoding est destiné à diviser la réponse en plusieurs morceaux à l'aide de Transfer-Encoding: chunked. Il s'agit d'une nouvelle fonctionnalité dans HTTP/1.1.

En-têtes d'entité

Les en-têtes d'entité transmettent des méta-informations sur le contenu :

En-tête d'entité = Autoriser | Encodage de contenu | Contenu-Langage | Longueur du contenu | Emplacement du contenu | Contenu-MD5 | Gamme de contenu | Type de contenu | Expire | Dernière modification

Tous les en-têtes préfixés par Content- fournissent des informations sur la structure, l'encodage et la taille du corps du message.

L'en-tête Expires contient l'heure et la date d'expiration de l'entité. La valeur « n'expire jamais » signifie le temps + 1 code à partir du moment actuel. Last-Modified contient l'heure et la date dernier changement essence.

A l'aide de ces en-têtes, vous pouvez préciser les informations nécessaires à vos tâches.

Format de demande

La requête ressemble à ceci :

Ligne de requête = Méthode SP URI SP HTTP-Version Méthode CRLF = "OPTIONS" | "TÊTE" | "OBTENIR" | "POST" | "METTRE" | "SUPPRIMER" | "TRACER"

SP est le séparateur entre les jetons. La version HTTP est spécifiée dans HTTP-Version. La requête réelle ressemble à ceci :

GET /articles/http-basics HTTP/1.1 Hôte : www.articles.com Connexion : keep-alive Cache-Control : no-cache Pragma : no-cache Accepter : text/html,application/xhtml+xml,application/xml; q=0,9,*/*;q=0,8

Liste des en-têtes de requête possibles :

En-tête de requête = Accepter | Accepter-Charset | Accepter-Encodage | Accepter-Langue | Autorisation | Attendez-vous | De | Hôte | Si-Match | Si-Modifié-Depuis | Si aucune correspondance | Si-Plage | Si-non modifié-depuis | Max-Forwards | Autorisation par procuration | Gamme | Référent | TE | Agent utilisateur

L'en-tête Accept spécifie les types MIME, la langue et le codage de caractères pris en charge. Les en-têtes From, Host, Referer et User-Agent contiennent des informations sur le client. Les préfixes If- sont destinés à créer des conditions. Si la condition ne répond pas, une erreur 304 Not Modified se produira.

Format de réponse

Le format de réponse ne diffère que par le statut et le nombre d'en-têtes. Le statut ressemble à ceci :

Ligne d'état = Version HTTP SP Code d'état SP Raison-Phrase CRLF

• Version HTTP
• Code d'état
• Message d'état lisible par l'homme

L'état normal ressemble à ceci :

HTTP/1.1 200 OK

Les en-têtes de réponse peuvent être les suivants :

En-tête de réponse = Accept-Ranges | Âge | Etag | Localisation | Authentification par proxy | Réessayer après | Serveur | Varier | WWW-Authentifier

• L'âge est le temps en secondes pendant lequel le message a été créé sur le serveur.
• ETag Entités MD5 pour vérifier les changements et modifications de la réponse.
• L'emplacement est utilisé pour la redirection et contient la nouvelle URL.
• Serveur spécifie le serveur sur lequel la réponse a été générée.

Je pense que c'est assez de théorie pour aujourd'hui. Jetons maintenant un coup d'œil aux outils que nous pouvons utiliser pour surveiller les messages HTTP.

Outils de détection du trafic HTTP

Il existe de nombreux outils pour surveiller le trafic HTTP. En voici quelques-uns :

Les outils de développement Chrome les plus couramment utilisés sont :

Si nous parlons d'un débogueur, vous pouvez utiliser Fiddler :

Pour surveiller le trafic HTTP, vous aurez besoin de curl, tcpdump et tshark.

Bibliothèques pour travailler avec HTTP - jQuery AJAX

Étant donné que jQuery est si populaire, il dispose également d'outils pour gérer les réponses HTTP pour les requêtes AJAX. Des informations sur jQuery.ajax (paramètres) sont disponibles sur le site officiel.

En passant un objet settings et en utilisant la fonction de rappel beforeSend, nous pouvons définir les en-têtes de requête à l'aide de la méthode setRequestHeader().

$.ajax(( url : "http://www.articles.com/latest", tapez : "GET", beforeSend : function (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language", "en-US,en "); ) ));

Si vous souhaitez traiter le statut de la demande, vous pouvez le faire comme ceci :

$.ajax(( statusCode: ( 404: function() ( alert("page not found"); ) ) ));

Conclusion

Le voici, un tour des bases du protocole HTTP. Il y en aura encore plus dans la deuxième partie faits intéressants et des exemples.