Protocole de transfert hypertexte

Un article de Wikipédia, l'encyclopédie libre
Aller à la navigation Aller à la recherche
Les utilisateurs rencontrent souvent l'abréviation, par ex. B. au début d'une adresse Web dans la ligne d'adresse du navigateur

Le protocole de transfert hypertexte (HTTP) est un protocole sans état introduit en 1991 pour la transmission de données au niveau de la couche application sur un réseau informatique . Il est principalement utilisé pour charger des pages Web (documents hypertextes) du World Wide Web (WWW) dans un navigateur Web . Cependant, il ne se limite pas à cela en principe et est également très courant en tant que protocole général de transfert de fichiers.

HTTP a été normalisé par l' Internet Engineering Task Force (IETF) et le World Wide Web Consortium (W3C). La version actuelle est HTTP/2, qui a été publiée en tant que RFC 7540 le 15 mai 2015. La poursuite du développement est organisée par le groupe de travail HTTP de l'IETF (HTTPbis). Il existe des normes qui complètent et s'appuient sur HTTP, telles que HTTPS pour le chiffrement du contenu transmis ou le protocole de transmission WebDAV .

Les caractéristiques

Selon les modèles de couche établis pour classer les protocoles réseau selon leurs tâches les plus fondamentales ou les plus abstraites, HTTP est affecté à ce que l'on appelle la couche application. Ceci est traité par les programmes d'application , dans le cas de HTTP, il s'agit généralement d'un navigateur Web. Dans le modèle de couche ISO/OSI , la couche application correspond à la 7ème couche.

HTTP est un protocole sans état . Les informations des demandes précédentes sont perdues. Un entraînement fiable des données de session ne peut être mis en œuvre sur la couche application que par une session utilisant un identifiant de session . Cependant, les applications qui peuvent attribuer des informations d'état (entrées d'utilisateurs, paniers d'achat) peuvent être mises en œuvre via des cookies dans les informations d'en-tête. Cela active les applications qui nécessitent des propriétés d'état ou de session . L' authentification des utilisateurs est également possible. Normalement, les informations transmises via HTTP peuvent être utilisées sur tous les ordinateurs et routeurspeuvent être lus, qui sont parcourus dans le réseau . Cependant, la transmission peut être cryptée via HTTPS .

Étendant ses méthodes de requête, ses informations d' en-tête et ses codes d'état, HTTP ne se limite pas à l' hypertexte , mais est de plus en plus utilisé pour échanger n'importe quelle donnée, et il est également à la base du protocole WebDAV , spécialisé dans le transfert de fichiers . HTTP s'appuie sur un protocole de transport fiable pour la communication , pour lequel TCP est utilisé dans presque tous les cas .

Il existe actuellement deux principales versions de protocole utilisées, HTTP/1.0 et HTTP/1.1. De plus, les nouvelles versions des navigateurs Web courants tels que Chromium , Chrome , Opera , Firefox , Edge et Internet Explorer sont déjà compatibles avec la nouvelle version 2 de HTTP (HTTP/2)

Construction

Les unités de communication en HTTP entre client et serveur sont appelées messages , dont il existe deux types différents : la requête ( demande en anglais ) du client au serveur et la réponse ( réponse en anglais ) en réaction à celle-ci du serveur. au client.

Chaque message se compose de deux parties, l' en-tête du message ( également appelé en -tête HTTP ) et le corps du message . L'en-tête du message contient des informations sur le corps du message, telles que les encodages utilisés ou le type de contenu, afin qu'il puisse être correctement interprété par le destinataire ( voir article principal : Liste des champs d'en-tête HTTP ). Enfin, le corps du message contient les données de l'utilisateur.

Fonctionnalité

Exemple de transaction effectuée à l'aide de Telnet

Si le lien vers l'URL http://www.example.net/infotext.html est activé dans un navigateur Web , une requête est envoyée à l'ordinateur avec le nom d'hôte www.example.net pour renvoyer la ressource /infotext.html .

Le nom www.example.net est d'abord converti en adresse IP à l'aide du protocole DNS . Pour la transmission, une requête HTTP GET est envoyée via TCP au port standard 80 du serveur HTTP.

Demande:

GET /infotext.html HTTP/1.1
Host: www.example.net

Si le lien contient des caractères qui ne sont pas autorisés dans la requête, ils sont codés % . Des informations supplémentaires telles que des informations sur le navigateur, la langue souhaitée, etc. peuvent être transmises via l' en-tête (lignes d'en-tête) dans chaque communication HTTP. Le champ "Hôte" peut être utilisé pour distinguer différents noms DNS sous la même adresse IP. Il est facultatif sur HTTP/1.0 mais obligatoire sur HTTP/1.1. Dès que l'en-tête se termine par une ligne vide (ou deux fins de ligne consécutives), l'ordinateur exécutant un serveur Web (sur le port 80) renvoie une réponse HTTP. Il se compose des informations d'en-tête du serveur, d'une ligne vierge et du contenu réel du message, c'est-à-dire le contenu du fichier dufichier infotext.html . Les fichiers sont généralement transférés dans des langages de description de page tels que ( X ) HTML et tous leurs ajouts, par exemple des images, des feuilles de style ( CSS ), des scripts ( JavaScript ), etc., qui sont généralement liés entre eux par un navigateur dans un format lisible. représentation. En principe, n'importe quel fichier peut être transféré dans n'importe quel format, le "fichier" pouvant également être généré dynamiquement et n'ayant pas besoin d'être présent sur le serveur en tant que fichier physique (par exemple lors de l'utilisation de CGI , SSI , JSP , PHP ou ASP. NET ). Chaque ligne de l'en-tête est séparée par leRetour à la ligne < CR >< LF > terminé. La ligne vide après l'en-tête ne peut être constituée que de <CR><LF>, sans espaces clos .

Réponse:

HTTP/1.1 200 OK
Server: Apache/1.3.29 (Unix) PHP/4.3.4
Content-Length: 123456 (taille de infotext.html en octets )
Content-Language: de (selon RFC 3282 et RFC 1766 )
Connection: close
Content-Type: text/html

(contenu de infotext.html)

Le serveur renvoie un message d'erreur et un code d'erreur si les informations ne peuvent pas être envoyées pour une raison quelconque, mais les codes d'état sont utilisés même si la demande a réussi, auquel cas (généralement) 200 OK. Le flux exact de ce processus (demande et réponse) est défini dans la spécification HTTP.

histoire

Sir Tim Berners-Lee est considéré comme le fondateur du Web et a également contribué au développement de HTTP.

À partir de 1989, Tim Berners-Lee et son équipe du CERN , le centre européen de recherche nucléaire en Suisse, ont développé le protocole de transfert hypertexte, ainsi que les concepts d ' URL et de HTML , jetant les bases du World Wide Web. Le premier résultat de ces efforts fut la version HTTP 0.9 en 1991. [1]

HTTP/1.0

La requête publiée en mai 1996 sous le nom de RFC 1945 ( Request for Comments No. 1945) est devenue HTTP/1.0. Avec HTTP/1.0, une nouvelle connexion TCP est établie avant chaque requête et refermée par le serveur après transmission de la réponse. Par exemple, si dix images sont incorporées dans un document HTML, un total de onze connexions TCP sont nécessaires pour ouvrir la page sur un navigateur compatible avec les graphiques.

HTTP/1.1

En 1999, une deuxième exigence a été publiée en tant que RFC 2616 , reflétant la norme HTTP/1.1. [2] Avec HTTP/1.1, un client peut utiliser une entrée d'en-tête supplémentaire ( keepalive ) pour exprimer le souhait de ne pas terminer la connexion afin de pouvoir utiliser à nouveau la connexion (connexion persistante). Cependant, la prise en charge côté serveur est facultative et peut entraîner des problèmes liés aux proxys. En utilisant le pipeline HTTP , la version 1.1 peut envoyer plusieurs requêtes et réponses par connexion TCP. Une seule connexion TCP est nécessaire pour le document HTML avec dix images. Étant donné que la vitesse des connexions TCP augmente initialement en utilisant le démarrage lentest assez faible, le temps de chargement de la page entière est considérablement réduit. De plus, avec HTTP/1.1, les transmissions interrompues peuvent être poursuivies.

Une façon d'utiliser HTTP/1.1 dans les chats consiste à utiliser le type MIME multipart/replace , dans lequel le navigateur, après avoir envoyé un code limite et un nouveau champ d'en-tête Content-Length et un nouveau champ d'en -tête Content-Type , remplace le contenu de le reconstruit la fenêtre du navigateur.

Avec HTTP/1.1, il est non seulement possible de récupérer des données mais également de transférer des données vers le serveur. Avec l'aide de la méthode PUT , les concepteurs Web peuvent publier leurs pages directement via le serveur Web via WebDAV et avec la méthode DELETE, ils peuvent supprimer des données du serveur. De plus, HTTP/1.1 fournit une méthode TRACE qui peut être utilisée pour tracer le chemin vers le serveur Web et vérifier que les données y sont correctement envoyées. Cela permet de déterminer le chemin d'accès au serveur Web à travers les différents proxys , un traceroute au niveau de l'application .

En raison de divergences et d'ambiguïtés, un groupe de travail a été créé en 2007 pour améliorer la spécification. Le but ici était seulement une formulation plus claire, de nouvelles fonctions n'ont pas été installées. Ce processus s'est terminé en 2014 et a abouti à six nouvelles RFC :

  • RFC 7230 - HTTP/1.1 : syntaxe et routage des messages
  • RFC 7231 - HTTP/1.1 : sémantique et contenu
  • RFC 7232 - HTTP/1.1 : requêtes conditionnelles
  • RFC 7233 - HTTP/1.1 : requêtes de plage
  • RFC 7234 - HTTP/1.1 : mise en cache
  • RFC 7235 - HTTP/1.1 : Authentification

HTTP/2

En mai 2015, l'IETF a approuvé HTTP/2 comme successeur de HTTP/1.1. La norme est spécifiée par RFC 7540 et RFC 7541 . [3] Le développement a été largement piloté par Google ( SPDY ) et Microsoft (HTTP Speed+Mobility) [4] , chacun avec ses propres propositions. Un premier projet, largement basé sur SPDY, a été publié en novembre 2012 et a depuis été adapté en plusieurs étapes.

Avec HTTP/2, la transmission devrait être accélérée et optimisée. [5] Cependant, la nouvelle norme devrait être entièrement rétrocompatible avec HTTP/1.1.

De nouvelles opportunités importantes sont

  • la possibilité de cumuler plusieurs demandes,
  • autres options de compression de données ,
  • la transmission codée binaire du contenu et
  • Transferts de données initiés par le serveur (méthode push),
  • les flux individuels peuvent être hiérarchisés.

L'accélération résulte principalement de la nouvelle possibilité de combiner ( multiplexer ) plusieurs requêtes afin de pouvoir les traiter via une seule connexion. La compression des données peut désormais également inclure des données d'en-tête (à l'aide d'un nouvel algorithme spécial appelé HPACK [6] ). Le contenu peut être transmis en code binaire. Afin de ne pas avoir à attendre des requêtes de suivi du client prévisibles côté serveur, les transferts de données peuvent être partiellement initiés par le serveur (méthode push). En utilisant HTTP/2, les opérateurs de sites Web peuvent réduire la latence entre le client et le serveur et soulager le matériel réseau. [sept]

L'option initialement prévue selon laquelle HTTP/2 utilise TLS par défaut n'a pas été implémentée. Cependant, les fabricants de navigateurs Google et Mozilla ont annoncé que leurs navigateurs Web ne prendraient en charge que les connexions HTTP/2 cryptées. Pour cela, ALPN est une extension de chiffrement qui nécessite TLSv1.2 ou une version plus récente. [8ème]

HTTP/2 est pris en charge par la plupart des navigateurs, y compris Google Chrome (y compris Chrome sur iOS et Android) à partir de la version 41, Mozilla Firefox à partir de la version 36, [9] Internet Explorer 11 sur Windows 10, Opera à partir de la version 28 (et Opera Mobile à partir de version 24) et Safari à partir de la version 8.

HTTP/3

Pile de protocole HTTP-2 vs HTTP-3.svg

En novembre 2018, l' IETF a décidé que HTTP/3 devrait utiliser QUIC . [dix]

Google travaille depuis 2012 sur une alternative appelée QUIC . QUIC ne repose plus sur TCP orienté connexion , mais sur le protocole de datagramme utilisateur (UDP) sans connexion. Les flux de données sont également traités séparément dans le HTTP/3 qui est basé sur cela. Si un paquet est perdu en cours de route, cela n'affecte plus tous les flux de données, comme c'est le cas avec TCP. Avec HTTP/3, le flux affecté attendra l'arrivée du paquet manquant. HTTP/3 est généralement crypté et promet des avantages de vitesse significatifs. [11] [12]

À la mi-2019, Google Chrome Canary était le premier navigateur disponible à prendre en charge expérimentalement #QUIC et HTTP/3. cURL a rapidement suivi. Depuis avril 2021, les versions préliminaires de Firefox (nightly et bêta) essaient automatiquement d'utiliser HTTP/3 s'il est proposé par le serveur Web (actuellement, par exemple Google ou Facebook ). Les serveurs Web peuvent annoncer la prise en charge à l'aide de l'en -tête de réponse Alt-Svc ou annoncer la prise en charge HTTP/3 avec un enregistrement DNS HTTPS . Le client et le serveur doivent avoir le même QUIC- et prend en charge la version brouillon HTTP/3 pour pouvoir se connecter. Par exemple, Firefox prend actuellement en charge les brouillons de spécifications 27 à 32, de sorte que le serveur doit signaler la prise en charge de l'une de ces versions (par exemple, "h3-32") dans l'entrée alt-svc ou https pour que Firefox tente QUIC et HTTP / 3 à utiliser avec ce serveur. Lors de la visite d'un tel site Web, les informations de demande de réseau doivent indiquer que HTTP/3 est utilisé.

En juin 2022, HTTP/3 a été normalisé en tant que RFC 9114 . [13]

Méthodes de requête HTTP

OBTENIR
est la méthode la plus courante. Il est utilisé pour demander une ressource (par exemple un fichier) au serveur en spécifiant un URI . Le contenu peut également être transféré au serveur sous forme d'arguments dans l'URI, mais selon la norme, une requête GET ne doit récupérer que des données et n'avoir aucun autre effet (comme des modifications de données sur le serveur ou une déconnexion). (voir ci- dessous )
PUBLIER
envoie des données (par exemple le contenu d'un fichier) au serveur pour un traitement ultérieur, celles-ci sont transmises en tant que contenu du message et peuvent consister en des paires nom-valeur provenant d'un formulaire HTML, par exemple. De cette façon, de nouvelles ressources peuvent être créées sur le serveur ou celles existantes peuvent être modifiées. Les données POST ne sont généralement pas mises en cache par des caches . De plus, avec ce type de transmission, les données peuvent également être attachées à l'URI, comme dans la méthode GET. (voir ci- dessous )
TÊTE
demande au serveur d'envoyer les mêmes en-têtes HTTP que GET, mais pas le corps du message contenant le contenu réel du document. Par exemple, la validité d'un fichier dans le cache du navigateur peut être rapidement vérifiée et la taille des fichiers peut être Content-Lengthrécupérée à l'avance et lue par ligne.
METTRE
est utilisé pour télécharger une ressource (par exemple un fichier) sur un serveur Web, en spécifiant l'URI cible. Si une ressource existe déjà sous l'URI cible spécifié, elle sera remplacée, sinon une nouvelle sera créée.
CORRECTIF
Modifie un document existant sans le remplacer complètement, comme avec PUT. A été spécifié par RFC 5789 .
EFFACER
supprime la ressource donnée sur le serveur.
TRACE
renvoie la requête telle que le serveur l'a reçue. De cette manière, il est possible de vérifier si et comment la demande a été modifiée sur le chemin du serveur - utile pour déboguer les connexions.
OPTIONS
renvoie une liste des méthodes et fonctionnalités prises en charge par le serveur.
RELIER
mis en œuvre par des serveurs proxy capables de fournir des tunnels SSL .

Les services Web RESTful utilisent les différentes méthodes de demande pour implémenter les services Web . En particulier, les méthodes de requête HTTP GET, POST, PUT/PATCH et DELETE sont utilisées pour cela.

WebDAV ajoute les méthodes PROPFIND , PROPPATCH , MKCOL , COPY , MOVE , LOCK et UNLOCK à HTTP.

transmission d'arguments

Souvent, un utilisateur souhaite envoyer des informations à un site Web. En principe, HTTP propose deux options pour cela :

HTTP OBTENIR
Les données font partie de l'URL et sont donc conservées lorsque le lien est enregistré ou transmis. Ils doivent être encodés en URL , c'est-à-dire que les caractères réservés doivent être représentés par "%< valeur hexadécimale >" et les espaces par "+".
POSTE HTTP
Transmission des données avec un type de demande spécialement conçu dans le corps du message HTTP afin qu'elles ne soient pas visibles dans l'URL.

HTTP OBTENIR

Ici, les paires de valeurs de paramètre sont introduites par le caractère ?dans l' URL . Cette procédure est souvent choisie pour transmettre une liste de paramètres que la station distante doit prendre en compte lors du traitement d'une requête. Cette liste se compose souvent de paires de valeurs, qui &sont séparées les unes des autres par le caractère. Les paires de valeurs respectives sont structurées sous la forme nom du paramètre=valeur du paramètre . Le caractère est utilisé moins fréquemment ;pour séparer les entrées de la liste. [14]

Un exemple : Sur la page d'accueil de Wikipédia, vous saisissez « chats » dans le champ de recherche et cliquez sur le bouton « Article ». Le navigateur envoie la requête suivante ou similaire au serveur :

GET /wiki/Special:Search?search=Chats&go=Article HTTP/1.1
Hébergeur : de.wikipedia.org
...

Deux couples de valeurs sont passés au serveur Wikipédia :

Ces paires de valeurs sont sous la forme

Parameter1=Wert1&Parameter2=Wert2

?ajouté à la page demandée avec le préfixe .

Cela indique au serveur que l'utilisateur souhaite voir l'article Chats . Le serveur traite la requête, mais au lieu d'envoyer un fichier, il redirige le navigateur vers la bonne page avec un en-tête de localisation, comme ceci :

HTTP / 1.0  302  Trouvé 
Date :  ven. 13 janvier 2006 15:12:44 GMT 
Lieu :  http://de.wikipedia.org/wiki/Katzen 

Le navigateur suit cette instruction et envoie une nouvelle requête basée sur les nouvelles informations, quelque chose comme :

GET  /wiki/Cats  HTTP / 1.1 
Hôte :  de.wikipedia.org 

Et le serveur répond et imprime l'article Cats , quelque chose comme :

HTTP / 1.1  200  OK 
Date :  Fri, 13 Jan 2006 15:12:48 GMT 
Last-Modified :  Tue, 10 Jan 2006 11:18:20 GMT 
Content-Language :  de 
Content-Type :  text/html; jeu de caractères=utf-8

Les chats (Felidae) sont une famille de l'ordre des carnivores (Carnivora)
au sein de la superfamille des félins (Feloidea).
...

La partie données est généralement plus longue, seul le protocole doit être considéré ici.

L'inconvénient de cette méthode est que les paramètres spécifiés sont généralement enregistrés avec l'URL dans l'historique du navigateur et que des données personnelles peuvent être enregistrées involontairement dans le navigateur. Au lieu de cela, vous devez utiliser la méthode POST dans ce cas.

POSTE HTTP

Étant donné que les données ne se trouvent pas dans l'URL, de grandes quantités de données, telles que des images, peuvent être transférées via POST.

L'exemple suivant demande à nouveau l'article Catsmethod="POST" , mais cette fois le navigateur utilise une requête POST à ​​cause d'un code HTML modifié ( ). Les variables ne se trouvent pas dans l'URL, mais séparément dans la partie du corps, par exemple :

POST  /wiki/Special:Search  HTTP / 1.1 
Host :  de.wikipedia.org 
Content-Type :  application/x-www-form-urlencoded 
Content-Length :  24

search=Chats&go=Articles

Le serveur le comprend également et répond par le texte suivant, par exemple :

HTTP / 1.1  302  Trouvé 
Date :  ven. 13 janvier 2006 15:32:43 GMT 
Emplacement :  http://de.wikipedia.org/wiki/Katzen 

Codes d'état HTTP

L'erreur 404 est la plus courante rencontrée par les internautes

Chaque requête HTTP est répondue par le serveur avec un code d'état HTTP. Par exemple, il indique si la demande a été traitée avec succès ou, en cas d'erreur, indique au client, c'est-à-dire au navigateur, où (par exemple, redirection) ou comment (par exemple, avec authentification) il a obtenu les informations souhaitées (si possible). peut obtenir.

1xx - Informations
La demande est toujours en cours de traitement malgré la réponse. Une telle réponse intermédiaire est parfois nécessaire, car de nombreux clients supposent automatiquement après un certain laps de temps ( timeout ) qu'une erreur s'est produite dans la transmission ou le traitement de la requête et abandonnent avec un message d'erreur.
2xx - Opération réussie
La demande a été traitée et la réponse est renvoyée au demandeur.
3xx – Redirection
Pour garantir le succès du traitement de la demande, d'autres étapes sont nécessaires de la part du client. C'est le cas, par exemple, si un site Web a été repensé par l'opérateur de sorte qu'un fichier souhaité se trouve maintenant à un endroit différent. Avec la réponse du serveur, le client découvre dans l'en- tête Location où se trouve maintenant le fichier.
4xx - Erreur client
Une erreur s'est produite lors du traitement de la demande, qui est de la responsabilité du client. Un 404 se produit, par exemple, lorsqu'un document a été demandé qui n'existe pas sur le serveur. Un 403 indique au client qu'il n'est pas autorisé à récupérer le document en question. Par exemple, il peut s'agir d'un document confidentiel ou d'un document uniquement accessible via HTTPS .
5xx - Erreur de serveur
Une erreur s'est produite qui est causée par le serveur. Par exemple, 501 signifie que le serveur ne dispose pas des capacités requises (c'est-à-dire des programmes ou d'autres fichiers, par exemple) pour traiter la demande.

En plus du code d'état, l'en-tête de réponse du serveur contient une description de l'erreur en langage clair . Par exemple, une erreur 404 peut être reconnue par l'en-tête suivant :

HTTP / 1.1  404  Introuvable 

Authentification HTTP

Authentification HTTP

Si le serveur Web détermine qu'un nom d'utilisateur ou un mot de passe est requis pour un fichier demandé, il le signale au navigateur avec le code d'état 401 Non autorisé et l'en-tête WWW-Authenticate . Celui-ci vérifie si les informations sont disponibles ou présente à l'utilisateur une boîte de dialogue dans laquelle le nom et le mot de passe doivent être saisis et les transmet au serveur. Si les données sont correctes, la page correspondante est envoyée au navigateur. Selon la RFC 2617 , une distinction est faite entre :

Authentification de base
L'authentification de base est le type d'authentification HTTP le plus courant. Le serveur Web demande une authentification, le navigateur recherche alors le nom d'utilisateur/mot de passe pour ce fichier et invite l'utilisateur si nécessaire. Il envoie ensuite l'authentification au serveur avec l'en-tête Authorization sous la forme username:password encodé en Base64 . Base64 n'offre aucune protection cryptographique, donc cette méthode ne peut être considérée comme sécurisée que lors de l'utilisation de HTTPS .
Authentification d'accès au résumé
Avec l'authentification d'accès digest, le serveur envoie également une chaîne de caractères aléatoires spécialement générée ( nonce ) avec l'en-tête WWW-Authenticate . Le navigateur calcule le code de hachage de l'ensemble des données (nom d'utilisateur, mot de passe, chaîne reçue, méthode HTTP et URI demandé ) et le renvoie au serveur dans l'en-tête d'autorisation avec le nom d'utilisateur et la chaîne aléatoire, qui le compare avec le soi -la somme de contrôle calculée compare L'écoute clandestine de la communication n'est ici d'aucune utilité pour un attaquant, car les données ne peuvent pas être reconstituées à partir du code de hachage en raison de la fonction de hachage cryptologique utilisée et est différente pour chaque requête.

Compression HTTP

Pour réduire la quantité de données transférées, un serveur HTTP peut compresser ses réponses . Lors de la demande, un client doit indiquer les méthodes de compression qu'il peut traiter. L'en-tête Accept-Encoding est utilisé pour cela ( par exemple Accept-Encoding: gzip , deflate ). Le serveur peut alors compresser la réponse à l'aide d'une méthode prise en charge par le client et spécifie la méthode de compression utilisée dans l'en-tête Content-Encoding .

La compression HTTP permet d'économiser des quantités considérables de données, en particulier avec des données textuelles (HTML, XHTML, CSS, code Javascript, XML, JSON), car celles-ci peuvent être facilement compressées. Pour les données déjà compressées (par exemple, les formats courants pour les images, l'audio et la vidéo), la (re)compression est inutile et n'est donc généralement pas utilisée.

Dans le cadre d'une communication chiffrée avec TLS , cependant, la compression conduit à l' exploit BREACH , qui peut casser le chiffrement.

Applications sur HTTP

HTTP en tant que protocole basé sur du texte n'est pas seulement utilisé pour transmettre des sites Web, il peut également être utilisé dans des applications indépendantes, les services Web . Les commandes HTTP telles que GET et POST sont toujours utilisées pour les opérations CRUD . Cela présente l'avantage qu'aucun protocole séparé pour la transmission de données ne doit être développé. Ceci est utilisé avec REST comme exemple .

HTTP contre protocole QUIC

HTTP s'appuie sur le protocole TCP ( Transmission Control Protocol ). TCP accuse réception de chaque paquet de données. Cela signifie que si un paquet est perdu, tous les autres paquets doivent attendre que le paquet perdu soit retransmis si le cache du récepteur déborde ( blocage de tête de ligne [15] ) .

Dans son ensemble, le protocole QUIC est destiné à permettre d'envoyer plus rapidement des paquets de données via l' UDP sans connexion . Les fonctionnalités qui manquent à UDP - telles que les accusés de réception - doivent être fournies par le protocole global. QUIC régule lui-même le contrôle de la connexion. Dans une connexion de données, l'expéditeur et le destinataire n'échangent le certificat et la clé que lors de la première poignée de main, ce qui réduit la latence. Pour d'autres transmissions, QUIC "se souvient" de la connexion qui existait dans le passé et accède aux données stockées. TLS version 1.3 est actuellement utilisé comme protocole de chiffrement . Il y a aussi la possibilité de multiplexage dans le protocole QUIC. Plusieurs flux de données peuvent être transmis simultanément via une connexion client-serveur, ce qui réduit encore considérablement le temps de chargement. [16]

Voir également

liens web

Commons : Hypertext Transfer Protocol  - collection d'images, de vidéos et de fichiers audio

les détails

  1. Tim Berners-Lee : Le HTTP original tel que défini en 1991 . Dans : w3.org , consulté le 13 novembre 2010.
  2. RFC 2616 Protocole de transfert hypertexte - HTTP/1.1
  3. RFC pour HTTP/2 spécifié et écrit . iX , reportage du 15 mai 2015 14h23
  4. Christian Kirsch : Microsoft a sa propre proposition pour HTTP 2. heise.de, 29 mars 2012, récupéré le 4 avril 2012 .
  5. Christian Kirsch : SPDY de Google devrait accélérer le web . heise.de, 13 novembre 2009 ; Récupéré le 4 avril 2012
  6. Projet de spécification de HPACK (l'algorithme de compression d'en-tête pour HTTP/2). Groupe de travail HTTP de l'IETF
  7. HTTP/2 - navigation plus rapide avec la nouvelle version du protocole. pcwelt.de, 30 janvier 2016, consulté le 21 février 2018 .
  8. M Belshe, R Peon, M Thomson : Protocole de transfert hypertexte version 2, Utilisation des fonctionnalités TLS. Consulté le 10 février 2015 .
  9. Firefox 36 implémente HTTP/2
  10. IETF : HTTP sur Quic devient HTTP/3. 12 novembre 2018, récupéré le 27 avril 2019 .
  11. Kim Rixecker : HTTP/3 : Nous expliquons la prochaine version du protocole de transfert hypertexte. Dans : revue t3n. 13 août 2021 , récupéré le 19 août 2021 .
  12. Tonino Jankov : Qu'est-ce que HTTP/3 ? - Informations générales sur le nouveau protocole rapide basé sur UDP. Dans : Kinsta. 18 mai 2021 , récupéré le 19 août 2021 .
  13. IETF raises HTTP/3 to RFC , sur heise.de, récupéré le 13 juin 2022
  14. Annexe B : Performances, mise en œuvre et notes de conception . Dans : World Wide Web Consortium [W3C] (éd.) : Spécification HTML 4.01 . 24 décembre 1999, B.2.2 : Esperluette dans les valeurs d'attribut URI ( w3.org ).
  15. Qu'est-ce que HTTP ? Consulté le 25 mars 2021 .
  16. QUIC : C'est derrière le protocole expérimental de Google. Consulté le 25 mars 2021 .