Networking

Was DNS bei jeder Anfrage wirklich tut Jede Anfrage an example.com beginnt mit einer Abfrage, die mit Ihrer Anwendung nichts zu tun hat: Etwas muss diesen Namen erst in eine IP-Adresse umwandeln, bevor ein einziges TCP-Paket die Maschine verlässt. Diese Übersetzung ist DNS, das Domain Name System, und sie läuft bei jeder Anfrage, egal ob der Client ein Browser, curl oder ein Backend-Dienst ist, der einen anderen über dessen Hostnamen aufruft. ...

Was TLS bei einer HTTPS-Verbindung tatsächlich schützt Laden Sie eine Seite über reines http:// in einem Netz, das Sie nicht kontrollieren, an einem Flughafen oder über den Router eines Cafés, dann läuft alles, was Sie senden, als lesbarer Text mit. Der URL-Pfad, die Cookies, die Formularfelder, das Passwort in einem Login-POST: Jeder in diesem Netz mit einem Paket-Sniffer liest es im Vorbeigehen. TLS, Transport Layer Security, verhindert genau das. Es sitzt zwischen TCP und dem Anwendungsprotokoll, sodass die Verbindung bereits verschlüsselt und an eine verifizierte Server-Identität gebunden ist, wenn HTTP zu sprechen beginnt. HTTPS ist HTTP, das über diese Verbindung läuft statt über eine unverschlüsselte. ...

Was ein CDN mit einer Anfrage tatsächlich macht Ein Nutzer in Tokio, der eine Seite von einem Server in Virginia lädt, bezahlt für diese Distanz zweimal: einmal für den Hinweg der Anfrage, einmal für den Rückweg der Antwort. Glasfaser überträgt mit einem festen Bruchteil der Lichtgeschwindigkeit, und allein diese Strecke kostet etwa 150-200ms Round-Trip-Zeit, bevor der Origin-Server überhaupt etwas getan hat. Kommen noch eine Datenbankabfrage und ein, zwei langsame Hops dazu, fühlt sich eine Seite, die nebenan sofort lädt, auf der anderen Seite des Planeten träge an. ...

Was zwischen Browser und Ihrer App steht Rufen Sie im Browser example.com auf, erreicht die Anfrage nie direkt den Prozess, der Ihren Code ausführt. Sie trifft zuerst auf etwas anderes: einen Server, der die Anfrage liest, entscheidet, welches Backend antworten soll, sie dorthin weiterleitet und die Antwort zurückschickt, als hätte er sie selbst erzeugt. Dieser Server ist ein Reverse Proxy. Nginx, Caddy, Traefik und HAProxy übernehmen alle diese Aufgabe, ebenso der Load Balancer vor einem Kubernetes-Cluster. Das Grundmuster ändert sich nie: Clients sprechen nur mit dem Proxy, mit sonst nichts. Die eigentlichen Server bleiben dahinter, egal wie viele es sind und wo sie laufen. ...

Warum zwei Container auf demselben Host sich standardmäßig nicht erreichen Starten Sie Postgres und Ihre API mit einem einfachen docker run, und die API kommt nicht an die Datenbank heran, obwohl beide Container auf derselben Maschine laufen. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Beide landen auf der Standard-Bridge von Docker, auf der jeder Docker-Container landet, solange Sie nichts anderes angeben. Sie bekommen eine IP-Adresse. Eine Möglichkeit, sich gegenseitig über den Namen zu finden, fehlt jedoch — die API müsste also die interne IP der Datenbank fest eintragen, eine Adresse, die sich bei jedem Neustart des Containers ändert. ...