Mise à jour du livre

Livre en ligne en cours d'écriture par Zenn "Introduction à l'application Web Python auto-conçue pour l'ingénieur Web de 3e année qui est lent" Le a été mis à jour

Chapitre "Qu'est-ce que HTTP?" a été mis à jour.

Si vous voulez en savoir plus, veuillez "aimer" ou "me suivre" dans Book ;-)

Ce qui suit est un extrait du contenu du livre.

En savoir plus sur HTTP

D'ailleurs, jusqu'au chapitre précédent, j'ai créé un "serveur Web Ese" en imitant Apache et Chrome. Je voudrais faire évoluer cela en un "serveur web minimum décent", mais qu'est-ce qu'un "serveur web minimum décent"?

Je dois expliquer ** HTTP ** pour continuer à partir d'ici, alors restez en contact avec moi à nouveau.

Si vous sortez d'ici, vous vous sentirez comme, "Le reste n'est que l'écriture!"

Qu'est-ce que HTTP?

Jusqu'au chapitre précédent, vous avez découvert TCP. (Pour récapituler, TCP était une règle d'envoi "sans omissions et dans l'ordre".)

Être capable d'envoyer "dans l'ordre sans omission" garantit que le message envoyé sera transmis à l'autre partie tel quel, mais vous pouvez alors utiliser ce TCP pour transmettre ** "quoi" (= quel message). N'est-ce pas? ** **

Considérez maintenant lorsqu'un client envoie une demande à un serveur pour un service Web appelé Google. Ce que vous voulez transmettre dans la demande est Je veux rechercher le mot «hoge. Cookie utilise hoge. '' Disons. (Les cookies seront expliqués en détail plus loin dans ce livre)

Le serveur est en difficulté si chaque client transmet ces informations sous la forme qu'il souhaite.

Par exemple

Client 1) Japonais mixte ... Cookieはfugaね、今回はwww.google.com/searchで検索ワードはhoge

Client 2) Le délimiteur est une virgule, un nombre, un deux-points ... 1.www 2.google 3.com 4.search, word:: hoge, cookie=fuga

Si une demande est envoyée dans un format différent à chaque fois, le serveur ne saura pas quelle partie de la demande indique quelles informations.

Par conséquent, une convention (= protocole) a été établie dans le monde entier. ** "Lorsque vous utilisez un service Web, utilisez TCP et envoyez un message dans ce format." ** C'est une promesse.

Dans le cas de la demande client précédente

GET /search?q=hoge HTTP/1.1
Cookie: fuga

Est censé être envoyé.

Si vous savez que tous les clients du monde enverront dans ce format, même si vous ne vous connaissez pas, le côté serveur Web peut correctement analyser (décomposer) le message et récupérer les informations.

Cette convention est appelée ** HTTP (HyperText Transfer Protocol) **.

::: détails Colonne: protocole de couche transport et protocole de couche application Le protocole pour «quoi dire» dépend du service que vous souhaitez offrir. La raison en est que ce que vous devez dire à l'autre partie dépend du service.

Par exemple, ** service d'envoi de courrier **

--Mon adresse email

Adresse e-mail de destination --Titre
Texte

Vous devrez le dire à l'autre partie.

De même, s'il s'agit de ** Web Service **,

--URL de la page Web que vous demandez

Type de demande (si vous voulez voir la page Web, envoyer les données du formulaire rempli, etc.)
Que ce soit pour utiliser HTTP ou HTTPS
Quelle est la valeur du cookie (le cookie sera expliqué en détail plus loin dans ce document)

Il est nécessaire d'en informer l'autre partie.

Bien sûr, le service d'envoi de courrier et le service Web délivreront le message à l'autre partie dans différents formats, ce qui signifie que le protocole changera. (D'ailleurs, lors de l'envoi de courrier, le protocole SMTP est utilisé, et lors de la réception de courrier, le protocole POP est utilisé.)

Cependant, HTTP, SMTP et POP sont toutes des conventions concernant le format des messages, et c'est une prémisse majeure que les messages arrivent «dans l'ordre sans omission» à la fois du côté de l'envoi et de la réception. En d'autres termes, HTTP, SMTP et POP sont ** des protocoles qui supposent une communication TCP **.

La structure est telle qu'il y a d'abord un protocole «comment envoyer», puis il y a un protocole «quoi envoyer».

Un modèle bien connu de la structure hiérarchique de ces protocoles est le [modèle de référence OSI](https://ja.wikipedia.org/wiki/OSI%E5%8F%82%E7%85%A7%E3%83]. Il y a% A2% E3% 83% 87% E3% 83% AB).

Dans le modèle de référence OSI, le protocole pour «comment envoyer» est appelé ** couche de transport **, et le protocole pour «quoi envoyer» est appelé ** couche application **.

Donc l'ingénieur senior "Est-ce un problème avec la couche de transport?" Si tu le dis, "Je n'ai pas parlé du contenu de la réponse ou de la commande, mais je parle du mécanisme de livraison des messages dans l'ordre sans omission." Cela signifie que · · ·

Être capable de comprendre la signification de ces mots immédiatement et avec précision sera l'un des facteurs qui séparera les utilisateurs intermédiaires et avancés.

On dit que le modèle de référence OSI est maintenant ancien, et il est difficile d'appliquer tous les protocoles utilisés sur Internet ces jours-ci aux couches du modèle de référence OSI, mais les protocoles ont une structure hiérarchique. Apprenons seulement l'idée :::

Où sont écrites les règles HTTP?

Cette règle HTTP, utilisée dans le monde entier, est adoptée par une organisation appelée IETF.

L'organisation IETF a établi de nombreux protocoles et spécifications liés à la technologie Internet autres que HTTP, et des spécifications et explications détaillées se trouvent dans le document RFC. Est émis comme.

Les RFC sont faciles à rechercher en ligne et peuvent être lues par n'importe qui.

Par exemple, vous pouvez lire RFC2616, qui décrit les bases de HTTP dans RFC, depuis ici.

L'image entière de HTTP est écrite dans ce RFC2616, alors lisons et étudions ici.

Cependant, je pense que la personne qui a ouvert le lien RFC lui a immédiatement brisé le cœur.

Le RFC est un document à un niveau qui fonctionne comme une loi, qui est la base de la technologie Internet dans le monde entier, et il résume systématiquement le contexte, le but et les spécifications détaillées du protocole. C'est difficile à comprendre.

Tout d'abord, tout est en anglais et c'est un peu serré.

Cependant, ces références peuvent être étonnamment compréhensibles si vous prenez un moment pour les lire après avoir obtenu un aperçu.

** Comprendre la source principale est une compétence très importante pour améliorer votre niveau d'ingénieur. ** ** Que vous sachiez ou non lire correctement la référence officielle pour savoir comment utiliser les frameworks et les bibliothèques, pas seulement RFC, peut être considéré comme une compétence essentielle pour passer au niveau avancé.

Ainsi, dans ce qui suit, j'expliquerai les grandes lignes de HTTP dans mes propres mots, puis je lirai de temps en temps la partie pertinente de la RFC.

De plus, lorsque vous vous référez à la RFC, par souci de simplicité, utilisez le site de traduction japonais suivant au lieu du texte original. https://triple-underscore.github.io/rfc-others/RFC2616-ja.html

Merci, Hidehiko Hashimoto.

Deux types de messages en HTTP

Dans le protocole HTTP, différentes règles (formats) sont définies pour chaque requête et réponse. Jetons un coup d'œil à chacun de ces deux formats à tour de rôle.

D'ailleurs, quand on dit simplement «demande», cela signifie généralement «message du client au serveur (quel que soit le format ou la méthode de communication)», mais parmi eux, le message envoyé selon les règles HTTP est ** HTTP. Demande appelée **. De même, pour "réponse", la réponse qui suit les règles HTTP est appelée ** réponse HTTP **.

Continuez sur Book!

Veuillez consulter la suite de ici.