Vom Browser zum Server: Wie das Internet wirklich funktioniert
DNS, IP-Adressen, Routing, TCP, TLS und HTTP verständlich erklärt – und wie diese Grundlagen direkt in modernen Cloud-Architekturen auf AWS wiederkehren.

Wir geben eine Webadresse in den Browser ein, drücken Enter – und wenige Augenblicke später erscheint eine Website. Für uns ist das selbstverständlich. Technisch passiert in dieser kurzen Zeit jedoch erstaunlich viel: Der Computer muss den Domainnamen auflösen, eine IP-Adresse finden, den Netzwerkweg zum Ziel bestimmen, eine Verbindung aufbauen, die Kommunikation verschlüsseln und schließlich eine Anfrage an den Webserver senden.
In diesem Artikel verfolgen wir eine Anfrage einmal vom Browser bis zum Server – Schritt für Schritt, verständlich erklärt.
Der erste Schritt: Aus einem Namen wird eine Adresse
Nehmen wir an, wir geben https://eyedia.de in den Browser ein. Für uns Menschen ist das eine lesbare, merkbare Adresse. Ein Computer kann damit aber nicht direkt etwas anfangen – er braucht eine numerische IP-Adresse, um eine Verbindung herzustellen.
Das System, das Domainnamen in IP-Adressen übersetzt, heißt DNS – Domain Name System. Es funktioniert wie ein riesiges, weltweit verteiltes Telefonbuch. Statt eine Nummer selbst nachzuschlagen, fragt unser Computer einen DNS-Server nach der IP-Adresse von eyedia.de - und bekommt sie zurück.
IP-Adressen: Jedes Gerät braucht eine Adresse
Eine IPv4-Adresse sieht beispielsweise so aus: 192.168.1.20. Sie besteht aus vier Zahlenblöcken zwischen 0 und 255. Das klingt nach viel – tatsächlich gibt es rund 4,3 Milliarden mögliche Adressen. Klingt nach genug, bis man bedenkt, dass heute Milliarden von Smartphones, Computern, Smart-TVs und Servern gleichzeitig im Netz sind.
Deshalb gibt es seit Jahren einen Nachfolger: IPv6. IPv6-Adressen sind länger und komplexer, ermöglichen aber eine nahezu unbegrenzte Anzahl von Adressen. In der Praxis laufen viele Systeme heute parallel auf beiden Versionen.
Private und öffentliche Adressen
Nicht jedes Gerät im Internet hat eine eigene, weltweit eindeutige IP-Adresse. Im Heimnetz oder Büronetzwerk werden sogenannte private IP-Adressen vergeben – Adressen, die nur innerhalb dieses Netzwerks gelten. Der Router übersetzt dann zwischen dem privaten Netzwerk und dem Internet.
Das erklärt, warum zu Hause viele Geräte gleichzeitig im Internet surfen können, obwohl der Internetanbieter nur eine einzige öffentliche IP-Adresse zuteilt. Der Router verwaltet das im Hintergrund – völlig unsichtbar für den Nutzer.
Routing: Wie findet ein Paket seinen Weg?
Das Internet ist kein einzelnes großes Netzwerk. Es ist ein Zusammenschluss von Tausenden einzelner Netzwerke – von Internetanbietern, Unternehmen, Universitäten und Rechenzentren. Datenpakete wandern dabei von Netzwerk zu Netzwerk, bis sie ihr Ziel erreichen.
Diesen Weg bestimmen Router. Jeder Router kennt seine unmittelbare Umgebung und weiß, an wen er ein Paket weiterleiten soll. Kein einzelner Router kennt das gesamte Internet – das Netz funktioniert durch das Zusammenspiel vieler solcher Weiterleitungsentscheidungen. Wie ein Brief, der von Postamt zu Postamt weitergegeben wird, bis er ankam.
DNS: Mehr als ein digitales Telefonbuch
DNS ist hierarchisch aufgebaut. An der Spitze stehen die sogenannten Root-Nameserver – sie kennen nicht jede Website der Welt, aber sie wissen, welche Server für .de, .com oder .org zuständig sind. Von dort geht die Anfrage weiter zum TLD-Nameserver für .de, der wiederum den zuständigen Server für eyedia.de kennt.
Am Ende dieser Kette steht der authoritative Nameserver der Domain – er kennt die tatsächliche IP-Adresse. Dieser gesamte Ablauf passiert in Millisekunden, meist ohne dass wir irgendetwas davon bemerken.
Damit nicht bei jeder Anfrage die gesamte Kette neu abgefragt werden muss, speichern DNS-Resolver Ergebnisse zwischen – das nennt sich Caching. Wie lange ein Eintrag gültig bleibt, legt der Domaininhaber über den TTL-Wert fest. Wer eine Domain auf einen neuen Server umzieht, muss deshalb manchmal ein paar Stunden warten, bis alle DNS-Server weltweit die neue Adresse kennen.
Ports: Welcher Dienst soll angesprochen werden?
Angenommen, der Browser kennt jetzt die IP-Adresse. Ist damit alles klar? Fast. Ein Server kann gleichzeitig viele verschiedene Dienste anbieten – zum Beispiel eine Website, einen Mailserver und eine Datenbank. Ports sorgen dafür, dass die Anfrage beim richtigen Dienst ankommt.
Port 80 ist traditionell für HTTP zuständig, Port 443 für HTTPS, Port 22 für SSH-Verbindungen. Wenn wir https://eyedia.de aufrufen, verbindet der Browser automatisch mit Port 443 – auch wenn wir das nie explizit eingegeben haben.
TCP: Zuverlässiger Transport
Daten reisen durchs Internet nicht als ein zusammenhängender Block, sondern in kleinen Paketen. TCP – das Transmission Control Protocol – sorgt dafür, dass alle Pakete ankommen, in der richtigen Reihenfolge zusammengesetzt werden und verlorene Pakete erneut angefordert werden.
Daneben gibt es UDP, ein schlankeres Protokoll ohne diese Sicherheitsmechanismen. UDP eignet sich für Anwendungen, bei denen Geschwindigkeit wichtiger ist als Vollständigkeit – etwa bei Videoanrufen oder Online-Spielen. Wenn dort mal ein Paket verloren geht, ist ein kurzes Ruckeln akzeptabler als eine Verzögerung durch Nachforderung.
HTTPS und TLS: Die verschlüsselte Verbindung
Das kleine S in https:// steht für Secure – und dahinter steckt TLS, Transport Layer Security. Bevor Browser und Server auch nur ein einziges Datenbyte austauschen, handeln sie eine verschlüsselte Verbindung aus. Der Server weist dabei seine Identität durch ein Zertifikat nach.
Das bedeutet: Wer die Verbindung zwischen Browser und Server abfängt – im WLAN, beim Internetanbieter oder irgendwo auf dem Weg –, sieht nur unlesbaren verschlüsselten Datenstrom. HTTPS ist heute Standard und wird von allen modernen Browsern als Mindestanforderung behandelt.
Die komplette Reise auf einen Blick
Wenn wir https://eyedia.de eingeben, passiert in wenigen hundert Millisekunden Folgendes: Der Browser fragt einen DNS-Resolver nach der IP-Adresse. Der Resolver holt sie sich – falls nicht gecacht – von Root-, TLD- und authoritative Nameserver. Mit der IP-Adresse baut der Browser eine TCP-Verbindung auf. TLS verschlüsselt die Verbindung und verifiziert den Server. Über HTTPS schickt der Browser die eigentliche Anfrage. Der Webserver verarbeitet sie und schickt die Website zurück.
Das klingt nach viel – aber jeder dieser Schritte ist eine eigenständige, saubere Aufgabe. Kein Teil des Systems muss wissen, wie die anderen Teile intern funktionieren. Genau diese Modularität macht das Internet so stabil und skalierbar.
Was das mit Cloud Engineering zu tun hat
Wer heute mit AWS oder anderen Cloud-Plattformen arbeitet, begegnet all diesen Konzepten in neuer Verpackung: Eine VPC ist ein privates Netzwerk in der Cloud. Subnetze trennen öffentliche und interne Systeme. Ein Internet Gateway ist der Übergang zum öffentlichen Internet. Ein NAT Gateway erlaubt privaten Systemen den Zugang nach außen, ohne selbst erreichbar zu sein. Route Tables entsprechen den Routing-Entscheidungen klassischer Router.
Das sind keine neuen Erfindungen – es sind bewährte Netzwerkprinzipien, die in der Cloud als verwaltete Dienste bereitgestellt werden. Wer die Grundlagen versteht, findet sich in AWS-Architekturen schnell zurecht, weil er nicht einzelne Dienste auswendig lernt, sondern versteht, welches Problem jeder Baustein löst.
Fazit
Hinter einem einfachen Enter-Drücken steckt ein ausgeklügeltes Zusammenspiel aus DNS, IP, Routing, TCP, TLS und HTTP. Kein Einzelteil davon ist übermäßig kompliziert – aber erst im Zusammenspiel entsteht das, was wir als selbstverständlich erleben: eine schnelle, zuverlässige, sichere Verbindung zu jedem Server der Welt.
Und genau dieses Verständnis ist die Grundlage, um moderne Webanwendungen, Cloud-Architekturen und KI-Systeme nicht nur zu benutzen – sondern wirklich zu durchschauen und richtig zu bauen.
Weitere Artikel
KIAWS Bedrock vs. SageMaker: Welcher AWS-Service passt zu deinem KI-Projekt?
Amazon Bedrock oder SageMaker? Der entscheidende Unterschied: Abstraktion vs. Kontrolle. Eine klare Entscheidungshilfe für moderne KI-Architekturen auf AWS.
KIKI-Chatbot für Restaurants: Reservierungen & Anfragen automatisieren
Wie Restaurants und Cafés mit einem KI-Chatbot Reservierungen entgegennehmen, Speisekarten zeigen und Gäste binden — rund um die Uhr.
KIAWS, Azure oder Google Cloud? Der ehrliche Vergleich für den Mittelstand (2026)
AWS vs. Azure vs. Google Cloud: Welcher Anbieter passt zu welchem Unternehmen? Vergleich zu Kosten, DSGVO, KI und Lock-in – mit klarer Entscheidungshilfe für den Mittelstand.