Ablauf einer HTTP-Anfrage?

2 Antworten

iQa1x
Von gutefrage auf Grund seines Wissens auf einem Fachgebiet ausgezeichneter Nutzer
Computer
10.06.2024, 19:30

Ich möchte die Super Antwort von Suiram1 noch um ein Paar Punkte ergänzen:

  • Ich würde HTTP/1.1 statt Version 2 in den Beispielen nehmen, da du die HTTP 2 Erweiterungen hier sowieso nicht erklärst und als Quelle RFC 2616 angeben
  • Eine Folie vorher über den grundsätzlichen Netzwerkptotokollstack evtl. hinzufügen, also IP->TCP->TLS (nur bei https)->HTTP , da evtl. auch die Serverports 80 und 443 erwähnen
  • Evtl. noch eine Folie, wie sich eine URL zusammensetzt (RFC 3986), ich würde das aber auf https://[benuzter[:passwort]@example.com[:Port]/pfad/zu/dokument[?Abfrageparameter][#anker] beschränken und erläutern, wo die Bestandteile "landen"

Dann den Ablauf anhand der URL (Beispiel https://example.com/, für http siehe Klammern) erläutern

  1. Kurze Erklärung der URL Bestandteile mit Beispiel-URL (Benutzer/Passwort in der URL wird so selten verwendet, kann man weglassen)
  2. Ermitteln der IP des Servers example.com per DNS Abfrage -> 104.21.27.71
  3. Verbindungsaufbau über TCP zu dieser IP auf Port 443 (80) oder zum angegebenen Port
  4. Austausch der Zertifikate und Erstellen des Sitzungsschlüssels, weitere Kommunikation wird danach transparent verschlüsselt (entfällt bei http)
  5. Senden der Anfrage (deine erste Folie), evtl. noch die verschiedenen HTTP-Anfragetypen ergänzend zu GET (siehe oben)
  6. Antwort des Servers (deine 2. Folie), ggf. Erläuterung des Statuscodes
  7. Browser stellt die Seite dar, wenn ein Anker angegeben ist wird dieser auf der Seite gesucht und zu diesem gescrollt (oder ein clientseitiges Javascript wertet den aus)
  8. Irgendwo noch sagen, dass dies für jedes einzelne referenzierte Element der Webseite (Bilder, CSS, Javascript, etc.) wiederholt wird

Falls du noch ein Beispiel für den SSL-Handshake brauchst, ein Beispiel (gekürzte Ausgabe von openssl bei https://example.com/ , kannst du dir das wichtigste rauskopieren)

# openssl s_client --connect example.com:443
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1
verify return:1
depth=0 C = US, ST = California, L = Los Angeles, O = Internet\C2\A0Corporation\C2\A0for\C2\A0Assigned\C2\A0Names\C2\A0and\C2\A0Numbers, CN = www.example.org
verify return:1
---
Certificate chain
 0 s:C = US, ST = California, L = Los Angeles, O = Internet\C2\A0Corporation\C2\A0for\C2\A0Assigned\C2\A0Names\C2\A0and\C2\A0Numbers, CN = www.example.org
   i:C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1
 1 s:C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHbjCCBlagAwIBAgIQB1vO8waJyK3fE+Ua9K/hhzANBgkqhkiG9w0BAQsFADBZ
[...]
iBfcQnFg4+1zMEKcqS87oniOyG+60RMM0MdejBD7AS43m9us96Gsun/4kufLQUTI
FfnzxLutUV++3seshgefQOy5C/ayi8y1VTNmujPCxPCi6Q==
-----END CERTIFICATE-----
subject=C = US, ST = California, L = Los Angeles, O = Internet\C2\A0Corporation\C2\A0for\C2\A0Assigned\C2\A0Names\C2\A0and\C2\A0Numbers, CN = www.example.org

issuer=C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3821 bytes and written 719 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 8C1C3C2C03EB2BDB6096F39A6639C8FBB567E5C9E9D182267EB78E7D27FB5504
    Session-ID-ctx:
    Resumption PSK: 26CB92E79172C5E6134760785050F7256006983B0AA90A6A6DEBB6579C1DA9A7DE2354813428CFE57FF84D8F30E51F59
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 53 f1 be 83 e4 e6 ab f7-2d 78 c0 64 bd 1b 8c b7   S.......-x.d....
[...]
    00c0 - 49 89 f7 46 25 84 61 84-d5 62 87 e5 8a ed 33 8e   I..F%.a..b....3.

    Start Time: 1718039904
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 7878DB35954C06522486E105A4E53AAF9CE69B3C4B295E21C436EEFDDC42F0AE
    Session-ID-ctx:
    Resumption PSK: 4B8086A4CCFB0773256C99FE041BDBFBC156442ED6A631C3A8B800C34CC89557F44C2AA7494B11EEF8CBDC865E126665
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 53 f1 be 83 e4 e6 ab f7-2d 78 c0 64 bd 1b 8c b7   S.......-x.d....
[...]
    00c0 - da d3 eb a0 30 9b 71 ff-09 13 1d e1 dd 12 ea 08   ....0.q.........

    Start Time: 1718039904
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Age: 340623
Cache-Control: max-age=604800
Content-Type: text/html; charset=UTF-8
Date: Mon, 10 Jun 2024 17:18:43 GMT
Etag: "3147526947+gzip+ident"
Expires: Mon, 17 Jun 2024 17:18:43 GMT
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Server: ECAcc (dcd/7D73)
Vary: Accept-Encoding
X-Cache: HIT
Content-Length: 1256

<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">
    body {
        background-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;

    }
    div {
        width: 600px;
        margin: 5em auto;
        padding: 2em;
        background-color: #fdfdff;
        border-radius: 0.5em;
        box-shadow: 2px 3px 7px 2px rgba(0,0,0,0.02);
    }
    a:link, a:visited {
        color: #38488f;
        text-decoration: none;
    }
    @media (max-width: 700px) {
        div {
            margin: 0 auto;
            width: auto;
        }
    }
    </style>
</head>

<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents. You may use this
    domain in literature without prior coordination or asking for permission.</p>
    <p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>

Und wenn die Folie zu den HTTP Statuscodes nicht zu trocken werden soll, schaue mal bei http://http.cat :)
Woher ich das weiß:Studium / Ausbildung – Informatiker
cleanercode  11.06.2024, 08:48

Ich persönlich liebe diese Antwort - aber etwas zu techie für Schüler :)

0
Von Experte iQa1x bestätigt
Suiram1
10.06.2024, 17:28

Wichtige Korrektur ist bei der 2. Folie das es nicht Content.type heißt sondern Content-Type. Ansonsten wäre vllt. noch wichtig zu erwähnen das die HTTP-Anfrage über eine TCP-Verbindung und seit HTTP/3 mit dem QUIC-Protokoll.

Du könntest auch noch hinzufügen das es verschiedene Anfrage Methoden gibt.

  1. GET Anfragen werden genutzt um nur anhand von Pfad und Headern Daten abzufragen.
  2. POST Anfragen werden oft für Formulare genutzt bei dehnen im Body der Anfrage der Inhalt gesendet wird.
  3. PUT wird nur von Apis genutzt. PUT hat kann dasselbe wie POST, allerdings wird in Apis POST weist für das hinzufügen von Daten und PUT für das aktualisieren dieser genutzt.
  4. DELETE wird ebenfalls nur von Apis genutzt und ist wie der Name sagt dafür zuständig Daten zu löschen.

Das sind nur die (meiner Meinung nach) 4 Grundlegenden Methoden, allerdings gibt es noch weitere. Aber für 'normale' Anfragen sind nur GET und POST wichtig.

POST und PUT besitzen außerdem noch in der Anfrage ähnlich wie bei der Antwort einen Inhalt der zum Server gesendet wird.

Sonst könntest du noch hinzufügen das bei den Statuscodes vom Server man diese in 5 Kategorien einordnen kann.

  1. 1xx Codes sind informations Codes die Informationen über aktuellen Status informieren. Der meist genutzte Code dabei ist 101 - Switching Protokolls
  2. 2xx Codes informieren über den Erfolg der Anfrage. Der bekannteste dabei ist (wie du schon hast) 200 - OK der nur aussagt das die Anfrage erfolgreich war.
  3. 3xx Codes sind Weiterleitungen die den Client dazu Anweisen die selbe Anfrage an die neu Url zu senden. Wie genau hängt dabei vom Code ab.
  4. 4xx Code sind Anfragefehler die Aussagen das etwas mit der Anfrage vom Client nicht stimmt oder die Daten ungültig sind. Der bekannteste hier ist 404 - Not Found der aussagt das die angegebene Ressource nicht gefunden werden konnte.
  5. 5xx Code stellen interne Serverfehler dar.

Als Übergang/Zusammenhang zu dem Part mit den Cookies könnte man bei den Anfrage Headern noch den Cookie-Header und bei den Antwort Headern den Set-Cookie-Header nutzen.

Ist zwar reine Formsache, aber an sich wäre es 'besser' wenn der teil der die reine HTTP Anfrage und Antwort beinhaltet nicht zentriert wäre sondern Linkbündig wäre.

Ansonsten ist als Dokumentation für HTTP die von mdn sehr gut.
Woher ich das weiß:Hobby