Das Buch wurde aktualisiert

Online-Buch von Zenn "Einführung in eine selbst erstellte Python-Webanwendung für einen trägen Webingenieur im 3. Jahr" Das wurde aktualisiert

Kapitel "Was ist HTTP?" wurde aktualisiert.

Wenn Sie mehr lesen möchten, "mögen" oder "folgen Sie mir" in Buch ;-)

Das Folgende ist ein Auszug aus dem Inhalt des Buches.

Erfahren Sie mehr über HTTP

Übrigens habe ich bis zum vorherigen Kapitel einen "Ese-Webserver" erstellt, indem ich Apache und Chrome imitiert habe. Ich würde dies gerne zu einem "Minimum anständigen Webserver" entwickeln, aber was genau ist ein "Minimum anständiger Webserver"?

Ich muss ** HTTP ** erklären, um von hier fortzufahren. Bitte bleiben Sie erneut mit mir in Kontakt.

Wenn Sie hier rauskommen, werden Sie das Gefühl haben: "Der Rest schreibt nur!"

Was ist HTTP?

Bis zum vorherigen Kapitel haben Sie etwas über TCP gelernt. (Zusammenfassend war TCP eine Regel für das Senden "ohne Auslassungen und in Ordnung".)

Wenn Sie "in der richtigen Reihenfolge ohne Auslassung" senden können, wird garantiert, dass die gesendete Nachricht unverändert an die andere Partei übertragen wird. Mit diesem TCP können Sie jedoch ** "was" (= welche Nachricht) übermitteln. Oder nicht? ** ** **

Überlegen Sie nun, wann ein Client eine Anfrage an einen Server für einen Webdienst namens Google sendet. Was Sie in der Anfrage vermitteln möchten, ist Ich möchte nach dem Wort "hoge" suchen. Cookie verwendet Hoge. `` Sagen wir. (Cookies werden später in diesem Buch ausführlich erklärt.)

Der Server ist in Schwierigkeiten, wenn jeder Client diese Informationen in der gewünschten Form übermittelt.

Zum Beispiel

Kunde 1) Japanisch gemischt ... Cookieはfugaね、今回はwww.google.com/searchで検索ワードはhoge

Client 2) Das Trennzeichen ist ein Komma, eine Zahl, ein Doppelpunkt ... 1.www 2.google 3.com 4.search, word:: hoge, cookie=fuga

Wenn eine Anfrage jedes Mal in einem anderen Format gesendet wird, weiß der Server nicht, welcher Teil der Anfrage welche Informationen angibt.

Daher wurde weltweit eine Konvention (= Protokoll) festgelegt. ** "Wenn Sie einen Webdienst verwenden, verwenden Sie TCP und senden Sie eine Nachricht in diesem Format." ** Es ist ein Versprechen.

Im Fall der vorherigen Kundenanfrage

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

Soll gesendet werden.

Wenn Sie wissen, dass alle Clients auf der Welt in diesem Format senden, auch wenn Sie sich nicht kennen, kann die Webserverseite die Nachricht ordnungsgemäß analysieren (zerlegen) und die Informationen abrufen.

Diese Konvention heißt ** HTTP (HyperText Transfer Protocol) **.

::: details Spalte: Transportschichtprotokoll und Anwendungsschichtprotokoll Das Protokoll für "Was zu sagen ist" hängt von dem Service ab, den Sie anbieten möchten. Der Grund ist, dass das, was Sie der anderen Partei mitteilen müssen, vom Service abhängt.

Zum Beispiel ** Mail-Versanddienst **

--Meine Email-Adresse

Ziel-E-Mail-Adresse --Titel
Text

Sie müssen es der anderen Partei mitteilen.

Ebenso, wenn es ** Web Service ** ist,

--URL der von Ihnen angeforderten Webseite

Anfragetyp (ob Sie die Webseite sehen, die Daten des ausgefüllten Formulars senden usw.)
Ob HTTP oder HTTPS verwendet werden soll --Was ist der Wert von Cookie (Cookie wird später in diesem Dokument ausführlich erläutert)

Es ist notwendig, die andere Partei zu informieren.

Natürlich senden der E-Mail-Versanddienst und der Webdienst die Nachricht in verschiedenen Formaten an die andere Partei, was bedeutet, dass sich das Protokoll ändert. (Übrigens wird beim Senden von E-Mails das Protokoll "SMTP" verwendet, und beim Empfangen von E-Mails wird das Protokoll "POP" verwendet.)

HTTP, SMTP und POP sind jedoch alle Konventionen in Bezug auf das Format von Nachrichten, und es ist eine wichtige Voraussetzung, dass Nachrichten sowohl auf der sendenden als auch auf der empfangenden Seite "in der richtigen Reihenfolge ohne Auslassung" eintreffen. Mit anderen Worten, HTTP, SMTP und POP sind ** Protokolle, die TCP-Kommunikation voraussetzen **.

Die Struktur ist so, dass es zuerst ein "How to Send" -Protokoll und dann ein "What to Send" -Protokoll gibt.

Ein bekanntes Modell der hierarchischen Struktur solcher Protokolle ist das [OSI-Referenzmodell](https://ja.wikipedia.org/wiki/OSI%E5%8F%82%E7%85%A7%E3%83]. Es gibt% A2% E3% 83% 87% E3% 83% AB).

Im OSI-Referenzmodell wird das Protokoll für "Senden" als ** Transportschicht ** und das Protokoll für "Senden" als ** Anwendungsschicht ** bezeichnet.

Also der leitende Ingenieur "Ist das ein Problem mit der Transportschicht?" Wenn du sagst, "Ich habe nicht über den Inhalt der Antwort oder der Bestellung gesprochen, aber ich spreche über den Mechanismus für die Zustellung von Nachrichten in der richtigen Reihenfolge ohne Auslassung." Es bedeutet, dass · · ·

In der Lage zu sein, die Bedeutung dieser Wörter sofort und genau zu verstehen, ist ein Faktor, der fortgeschrittene und fortgeschrittene Benutzer voneinander trennt.

Es wird gesagt, dass das OSI-Referenzmodell jetzt alt ist und es schwierig ist, alle heutzutage im Internet verwendeten Protokolle auf die Schichten des OSI-Referenzmodells anzuwenden, aber die Protokolle haben eine hierarchische Struktur. Lernen wir nur die Idee :::

Wo sind die HTTP-Regeln geschrieben?

Diese weltweit verwendete HTTP-Regel wird von einer Organisation namens IETF erlassen.

Die IETF-Organisation hat viele andere Protokolle und Spezifikationen für die Internet-Technologie als HTTP erstellt. Detaillierte Spezifikationen und Erklärungen finden Sie im Dokument RFC. Wird ausgegeben als.

RFCs sind einfach online zu suchen und können von jedem gelesen werden.

Zum Beispiel können Sie "RFC2616", das die Grundlagen von HTTP in RFC beschreibt, von [hier] lesen (https://tools.ietf.org/html/rfc2616).

Das ganze Bild von HTTP ist in diesem RFC2616 geschrieben, also lasst uns hier lesen und studieren.

Ich denke jedoch, dass die Person, die den RFC-Link geöffnet hat, sofort sein Herz gebrochen hat.

Der RFC ist ein Dokument auf einer Ebene, die wie ein Gesetz funktioniert und die Grundlage der Internet-Technologie auf der ganzen Welt bildet. Er fasst systematisch den Hintergrund, den Zweck und die detaillierten Spezifikationen des Protokolls zusammen. Es ist schwer herauszufinden.

Zuallererst ist alles auf Englisch und es ist ein wenig eng.

Diese Referenzen können jedoch überraschend verständlich sein, wenn Sie sich einen Moment Zeit nehmen, um sie zu lesen, nachdem Sie sich einen Überblick verschafft haben.

** Das Verständnis der Primärquelle ist eine sehr wichtige Fähigkeit, um Ihr Niveau als Ingenieur zu verbessern. ** ** ** Ob Sie die offizielle Referenz richtig lesen können, um herauszufinden, wie Frameworks und Bibliotheken verwendet werden, und nicht nur RFC, kann als wesentliche Fähigkeit für den Aufstieg auf fortgeschrittenes Niveau bezeichnet werden.

Im Folgenden werde ich den Umriss von HTTP in eigenen Worten erläutern und dann von Zeit zu Zeit den relevanten Teil von RFC lesen.

Wenn Sie sich der Einfachheit halber auf den RFC beziehen, verwenden Sie anstelle des Originaltextes die folgende japanische Übersetzungssite. https://triple-underscore.github.io/rfc-others/RFC2616-ja.html

Vielen Dank, Hidehiko Hashimoto.

Zwei Arten von Nachrichten in HTTP

Im HTTP-Protokoll werden für jede Anforderung und Antwort unterschiedliche Regeln (Formate) definiert. Schauen wir uns nacheinander jedes dieser beiden Formate an.

Übrigens, wenn wir einfach "Anfrage" sagen, meinen wir im Allgemeinen "Nachricht vom Client zum Server (unabhängig von Format oder Kommunikationsmethode)", aber unter diesen ist die Nachricht, die gemäß den HTTP-Regeln gesendet wird, ** HTTP. Angerufene Anfrage **. In ähnlicher Weise wird für "Antwort" die Antwort, die den HTTP-Regeln folgt, ** HTTP-Antwort ** genannt.

Weiter buchen!

Bitte lesen Sie die Fortsetzung von hier.