La différence entre http1.0 et 1.1

1. HTTP 1.1 prend en charge PersistentConnection et le traitement du pipeline de requêtes

HTTP 1.0 stipule que les navigateurs et les serveurs ne maintiennent qu'une connexion de courte durée chacun. La requête du navigateur doit établir une connexion TCP avec le serveur. Le serveur déconnecte immédiatement la connexion TCP après avoir terminé le traitement de la requête. Le serveur ne suit pas chaque client et n'enregistre pas les requêtes passées. (Apprentissage recommandé : Tutoriel vidéo frontal Web)

HTTP 1.1 prend en charge la connexion persistante et utilise une connexion persistante par défaut. Plusieurs requêtes et réponses HTTP peuvent se chevaucher et. plusieurs requêtes et réponses peuvent être effectuées simultanément. Plus d'en-têtes de requête et d'en-têtes de réponse (par exemple, HTTP 1.0 n'a pas de champ hôte

En mode Conversation 1.0 :

1. Établir une connexion

2. Envoyer un message de demande

3. Renvoyer un message de réponse

4. Fermer la connexion

Le la connexion persistante de HTTP 1.1 doit également ajouter de nouveaux en-têtes de requête pour y parvenir. Par exemple, lorsque la valeur de l'en-tête de requête de connexion est Keep-Alive, le client demande au serveur de maintenir la connexion après avoir renvoyé le résultat de cette requête ; Connexion Lorsque la valeur de l'en-tête de la requête est close, le client notifie au serveur de fermer la connexion après avoir renvoyé le résultat de cette requête. HTTP 1.1 fournit également des en-têtes de requête et des en-têtes de réponse liés à des mécanismes tels que l'authentification, la gestion de l'état et la mise en cache du cache.

Le traitement en pipeline des requêtes peut transmettre plusieurs requêtes et réponses HTTP sur une connexion TCP, réduisant ainsi la consommation et le délai d'établissement et de fermeture des connexions. Par exemple, plusieurs requêtes et réponses pour un fichier de page Web contenant de nombreuses images peuvent être transmises via une seule connexion, mais les requêtes et réponses pour chaque fichier de page Web individuel doivent toujours utiliser leurs propres connexions. HTTP 1.1 permet également au client d'effectuer la requête suivante sans attendre le résultat de la requête précédente. Cependant, le serveur doit renvoyer les résultats de la réponse dans l'ordre dans lequel la requête du client est reçue pour s'assurer que le client peut. distinguer le contenu de chaque requête.

2. HTTP 1.1 ajoute le champ hôte

Dans HTTP 1.0, on considère que chaque serveur est lié à une adresse IP unique, donc l'URL dans la requête message Le nom d'hôte n'est pas transmis. Cependant, avec le développement de la technologie des hôtes virtuels, plusieurs hôtes virtuels (serveurs Web multi-résidents) peuvent exister sur un serveur physique et partager une adresse IP.

Les messages de requête HTTP1.1 et les messages de réponse doivent prendre en charge le champ d'en-tête Host, et s'il n'y a pas de champ d'en-tête Host dans le message de requête, une erreur (400 Bad Request) sera signalée. De plus, le serveur DEVRAIT accepter les demandes de ressources étiquetées avec des chemins absolus.

3. 100 (Continuer) Statut (économiser la bande passante)

HTTP/1.1 a ajouté un nouveau code d'état 100 (Continuer). Le client envoie à l'avance une demande avec uniquement le champ d'en-tête. Si le serveur rejette la demande en raison d'autorisations, il renverra un code de réponse de 401 (Non autorisé) ; si le serveur reçoit la demande, il renverra un code de réponse ; de 100, et le client peut continuer à envoyer une demande complète à l'entité. L'utilisation du code d'état 100 (Continuer) permet au client d'utiliser l'en-tête de la requête pour tester le serveur avant d'envoyer le corps du message de la requête afin de voir si le serveur souhaite recevoir le corps de la requête, puis de décider s'il doit envoyer le corps de la requête.

4. Le codage de transfert fragmenté a été introduit dans HTTP/1.1 pour résoudre le problème ci-dessus. L'expéditeur divise le message en plusieurs blocs de données de n'importe quelle taille, et chaque bloc de données sera attaché au bloc lors de l'envoi. longueur, et enfin utiliser un bloc de longueur nulle comme signe de la fin du message. Cette approche permet à l'expéditeur de mettre en mémoire tampon uniquement un fragment du message, évitant ainsi la surcharge provoquée par la mise en mémoire tampon de l'intégralité du message.

5. HTTP/1.1 ajoute de nouvelles fonctionnalités de cache sur la base de la version 1.0. Lorsque l'âge de l'objet du cache dépasse Expire, il devient un objet obsolète. Le cache n'a pas besoin de supprimer directement l'objet obsolète. mais communique avec le serveur source. Effectuez une revalidation.

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!