Frieden auf localhost und gebrochene Illusionen
Als ich in der Schule war, bestand meine ganze Welt aus localhost. Selbst wenn ich so etwas wie XAMPP installierte und mit PHP ein Bulletin Board erstellte, war es eine Welt, die nur auf meinem Computer lief.
Als ich zum ersten Mal in das Unternehmen eintrat, hatte ich das Glück, hauptsächlich für die Front-End-Wartung verantwortlich zu sein. Es handelte sich um eine auf Quasar (Vue.js) basierende Admin-Seite, und der Schwierigkeitsgrad der Aufgabe war nicht hoch. Ich musste lediglich den Tippfehler korrigieren oder die API aufrufen, die meine Vorgesetzten bereits gut mit axios.get() erstellt hatten, und sie auf dem Bildschirm anzeigen.
Damals war axios für mich wie ein Zauberstab. Obwohl ich die komplizierten Prinzipien nicht kenne, habe ich einfach die URL eingegeben und die Daten wurden schnell abgerufen. Mir kam auch ein frecher Gedanke: „Die Kommunikation zwischen Front-End und Backend ist doch nichts Besonderes, oder?“
Aber der Frieden hielt nicht lange an. Das liegt daran, dass ich ein „lebendiger Full-Stack“-Entwickler in einem kleinen und mittleren Unternehmen war, dem es an Arbeitskräften mangelte.
Bald kam der Moment, in dem ich meine eigene API für eine neue Funktion erstellen musste, anstatt den Bildschirm zu ändern. Ich habe einen Server mit Spring Boot gestartet, was ich schnell von YouTube gelernt habe, und eine Anfrage vom Frontend gesendet. Allerdings erschienen auf meinem Bildschirm nur rote CORS-Fehler und Timeout-Fehler, keine Daten.
„Es hat gut funktioniert, als ich es als lokale Variable übergeben habe, aber warum kann ich nicht einfach das Netzwerk verwenden?“
Variable A in Variable B auf meinem Computer (Localhost) zu verschieben, war eine 100 % garantierte sichere Methode. Doch die Welt außerhalb des LAN-Kabels war anders. Es war wie eine Kreuzung mit einer kaputten Ampel, und meine Daten besagten, dass ein Lastwagen auf dieser gefährlichen Straße fuhr. Die ganze Zeit über habe ich den LKW nur beladen und verschickt, hatte aber keine Ahnung, welche Route der LKW nahm oder wie er aufgeteilt war.
Liefersystem im digitalen Logistikzentrum
Lasst uns unser Weltbild vom „digitalen Logistikzentrum“ erweitern. Jetzt müssen wir die in unserer Fabrik (Computer) hergestellten Artikel (Daten) an weit entfernte Kunden (Server) liefern.
1. Paket: Standardversandkarton
Egal wie groß die Daten sind, die wir senden möchten (z. B. ein 1-GB-Video), sie können nicht alle auf einmal gesendet werden. Das liegt daran, dass die Straßen eng und die Lastwagen klein sind. Also schneiden wir die Daten in sehr kleine Stücke und packen sie in standardisierte Boxen. Dies ist ein „Paket“.
2. IP (Internet Protocol): Adresse und Navigation
Was kann ich tun, wenn ich nur eine Box habe? Sie müssen wissen, wohin Sie gehen müssen.
3. TCP/UDP: Unterschiede in den Übermittlungsmethoden
Jetzt müssen wir entscheiden, an welchen LKW wir die Kartons schicken wollen.
[Code-Verifizierung] Das wahre Gesicht von HTTP ist nur Text
Der von uns üblicherweise verwendete HTTP ist eigentlich nur der „Inhalt des Briefes“, der auf einem Lieferwagen namens TCP transportiert wird. Lassen Sie uns auf die primitivste Weise (Socket) ohne Browser oder Bibliothek mit dem Naver-Server sprechen. Sie werden sehen, wie einfach HTTP ist, nur ein Stück Text.
import socket
# 1. TCP-Socket erstellen (Hoerer abnehmen)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 2. Verbindung zum Naver-Server (223.130.195.200) auf Port 80 (Nummer waehlen)
# Naver IP kann sich aendern (mit nslookup [www.naver.com](https://www.naver.com) pruefen)
target_host = "[www.naver.com](https://www.naver.com)"
target_port = 80
sock.connect((target_host, target_port))
# 3. HTTP-Anfragenachricht erstellen (was sagen)
# Rohstform einer HTTP-Anfrage
request = "GET / HTTP/1.1rnHost: [www.naver.com](https://www.naver.com)rnrn"
# 4. Senden (sprechen)
sock.send(request.encode())
# 5. Antwort empfangen (zuhoeren)
response = sock.recv(4096)
print(response.decode())
# 6. Verbindung beenden (auflegen)
sock.close()
Ausführungsergebnisse (teilweise):
HTTP/1.1 200 OK
Server: NWS
Date: Mon, 01 Jan 2024 00:00:00 GMT
Content-Type: text/html; charset=UTF-8
...
<html>...</html>
Analyse: Das ist alles, was intern passiert, wenn wir axios.get() aufrufen.
HTTP ist keine spezielle Technologie, es ist lediglich ein Versprechen, „Texte über dieses Protokoll (Protokoll) auszutauschen, wenn wir kommunizieren.“
Kompromiss in der Praxis: Zuverlässigkeit oder Geschwindigkeit
In der Praxis, insbesondere bei der Back-End-Entwicklung, kommt der Zeitpunkt, an dem Sie sich zwischen TCP und UDP entscheiden müssen. (Natürlich verwenden die meisten TCP-basiertes HTTP)
HTTP/3, das in aktuellen Interviewfragen häufig gestellt wird, ist das Produkt dieses Kompromisses. Das von uns verwendete Internet (HTTP/1.1, HTTP/2) lief auf TCP. Weil Daten niemals zerstört werden sollten.
Aber die Zeiten haben sich geändert. Die Leute wollen 4K-Videos ohne Unterbrechung ansehen. Der sorgfältige Verifizierungsprozess (Handshake) von TCP und Funktionen wie „In der Schlange stehen (Head of Line Blocking)“ sind mittlerweile frustrierend.
Das dachte sich Google. „Hey, lass uns einfach UDP verwenden. Wir können uns einfach um die Unannehmlichkeiten auf Anwendungsebene kümmern. Es ist wichtig, es schnell zu senden!“
Dies ist das QUIC-Protokoll und die Grundlage von HTTP/3. Es handelt sich um einen Trend der modernen Technologie, der die bedingungslose Stabilität (TCP) aufgibt und sich für überwältigende Geschwindigkeit (UDP) entscheidet, auch wenn dies das Eingehen einiger Risiken mit sich bringt.
Abschluss: Stellen Sie sich eine unsichtbare Straße vor
Jetzt wissen wir, wie die Daten aufgeteilt sind (Pakete) und auf welchem LKW (TCP/UDP) sie transportiert werden.
Wenn eine API-Anfrage im Frontend fehlschlägt, denken Sie nicht nur: „Ist der Server tot?“ wie vorher. „Oh, ist der 3-Wege-Handshake fehlgeschlagen? Wurde das Paket vom Router in der Mitte verworfen? Oder hat DNS die Adresse nicht gefunden?“ Wenn Sie sich eine solche Netzwerkschicht vorstellen können, sind Sie nicht mehr „nur ein Programmierer“
Jetzt ist die Ware aus unserem Werk sicher beim Kunden angekommen. Doch wie erhält ein Kunde diesen Artikel, wie packt er ihn aus und zeigt ihn auf dem Bildschirm? Wie wird der von uns gesendete HTML-Code im Browser angezeigt?
Nächstes Mal werden wir über das endgültige Ziel der Webentwicklung sprechen, die Prinzipien des Browser-Renderings.