Ein frei kopier- und anpassbares Lehrmittel von eduskript.org

Built with Eduskript
Lernziele
  • Sie können die zwei Hauptprobleme beschreiben, die TCP löst: eine stabile Verbindung aufbauen und die richtige Anwendung am Zielcomputer adressieren.
Was nicht Prüfungsstoff ist
  • Sie müssen das OSI-Modell nicht auswendig lernen.
  • Sie müssen keine Port-Nummern auswendig lernen.
  • HTTPS, DNS, DHCP sind Beispiele — Sie müssen ihre internen Abläufe nicht auswendig können.

Das Wichtigste zuerst: was TCP löst

Mit dem Internet-Protokoll (IP) können wir bereits Pakete um die halbe Welt schicken. Aber drei Probleme bleiben offen:

  1. Wie bauen wir eine Verbindung auf, die über viele Pakete hinweg bestehen bleibt?
  2. Wenn eine Datei in Pakete zerstückelt wird — wie merken wir, dass am Ziel alle Teile ankommen?
  3. Wenn mehrere Programme gleichzeitig Daten austauschen — wie landet jedes Paket beim richtigen Programm?

Das löst das Transmission Control Protocol (TCP) auf der Transportschicht. Die Schichten bauen aufeinander auf: Jede höhere verlässt sich darauf, dass die darunter ihre Arbeit erledigt.

Problem 1: eine stabile Verbindung — der TCP-Handshake

Ein Browser (Client) will sich mit einem Webserver verbinden. Das geschieht in drei Schritten:

  1. SYN — Der Client sendet ein SYN-Paket («Synchronize») mit einer zufälligen Sequenznummer A: «Ich möchte eine Verbindung.»
  2. SYN-ACK — Der Server antwortet mit eigener Sequenznummer B und bestätigt A (A+1): «Einverstanden — und ich auch.»
  3. ACK — Der Client bestätigt B (B+1): «Alles klar.»

Nach diesem TCP-Handshake steht die Verbindung, und beide Seiten sind sicher, dass sie wirklich miteinander reden. Danach zählen sie mit SYN/ACK-Nummern mit, wie viele Bytes gesendet und bestätigt wurden — so merken sie auch, wenn unterwegs etwas verloren geht.

Problem 2: die richtige Tür — Ports

Mit der IP-Adresse haben wir das richtige Haus (Gerät) gefunden. Aber im Haus wohnen viele Programme — welches soll das Paket bekommen? Dafür nutzt TCP Ports: 2-Byte-Nummern (0 bis 65'535), die wie verschiedene Türen am Gerät funktionieren. Ein Programm «stellt sich in eine Tür» und reserviert den Port.

Beim Surfen verbinden Sie sich automatisch mit Webservern auf Port 443 (HTTPS) (unverschlüsselt: Port 80, HTTP). Den Port kann man auch von Hand angeben, mit Doppelpunkt nach der IP:

  • https://192.168.1.4 → Standardport 443
  • http://192.168.1.4 → Standardport 80
  • http://192.168.1.4:3000 → Port 3000

Grobe Regeln: Ports 0–1023 sind für etablierte Dienste reserviert (HTTPS, E-Mail, SSH …), 1024–49151 für Server-Apps, 49152–65535 für Client-Apps (z.B. Ihr Browser greift sich beim Verbinden einfach einen freien).

Versuch

Ich lasse auf meinem Laptop einen HTTP-Webserver auf Port 8080 laufen. Meine IP-Adresse nenne ich in der Lektion — versuchen Sie, die Seite aufzurufen!

🐍 Jetzt sind Sie dran

🐍 Übung 1: URL zerlegen (mittel)

Ihr Browser macht das ständig: Aus http://192.168.1.4:3000 liest er Protokoll, IP und Port heraus. Fehlt der Port, setzt er den Standard ein — 80 für http, 443 für https.

Schreiben Sie parse_url(url), das ein Tripel (protokoll, ip, port) zurückgibt. Der Port soll eine Zahl sein, kein String.

PythonLoading editor…
def parse_url(url):
    # 1) Trenne Protokoll und Rest am "://".
    protokoll, rest = url.split("://")
    # 2) Hat der Rest einen Doppelpunkt? Dann steht dahinter der Port.
    #    Sonst: Standardport setzen (http -> 80, https -> 443).
    #    Tipp:  ":" in rest  prüft, ob ein Doppelpunkt vorkommt.
    ...
    return (protokoll, ip, port)

print(parse_url("http://192.168.1.4"))        # ('http', '192.168.1.4', 80)
print(parse_url("https://192.168.1.4"))       # ('https', '192.168.1.4', 443)
print(parse_url("http://192.168.1.4:3000"))   # ('http', '192.168.1.4', 3000)

Die Anwendungsschicht: wie eine Webseite geladen wird

Die unteren Schichten erledigen die ganze Verbindungslogik — die Anwendung muss nur noch definieren, welche Infos sie austauscht. Beim Surfen ist das HTTP(S) («Hypertext Transfer Protocol», das S steht für Secure/verschlüsselt).

Wenn Sie informatikgarten.ch eingeben, läuft grob das ab:

  1. DNS-Auflösung: Der Browser fragt einen DNS-Server, welche IP-Adresse zu informatikgarten.ch gehört (DNS ist das «Telefonbuch» des Internets: Name → IP).
  2. TCP-Handshake mit dieser IP (bei HTTPS zusätzlich ein TLS-Handshake für die Verschlüsselung).
  3. HTTP-Request: Der Browser fragt das HTML-Dokument an; der Server antwortet mit Statuscode (z.B. 200 OK) und dem HTML.
  4. Parsen & Nachladen: Der Browser liest das HTML und entdeckt weitere Ressourcen (CSS, JavaScript, Bilder) — für jede beginnt das Spiel (DNS → TCP → HTTP) von vorne, oft parallel zu vielen Servern.
  5. Rendern: Layout berechnen, zeichnen, fertig — meist in Sekundenbruchteilen.

Erinnern Sie sich ans Hobbiton-Bild der ersten Lektion? Genau hier passiert es: Für dieses eine Bild baut Ihr Browser eine eigene Verbindung zu einem Server in Neuseeland auf — DNS, TCP-Handshake, HTTP-Request, und die Bilddaten reisen durch Unterseekabel zurück.

✏️ Übung 2: In welcher Reihenfolge? (einfach)

Sie tippen informatikgarten.ch ein. Was passiert zuerst?

Vertiefung (nicht Prüfungsstoff)

UDP — verbindungslos und schnell

UDP ist die einfachere Alternative zu TCP: kein Handshake, keine Bestätigung, keine garantierte Reihenfolge. Dafür sehr schnell — ideal für Live-Streaming oder Online-Spiele, wo Tempo wichtiger ist als Vollständigkeit. UDP kennt nur Ports und eine einfache Fehlererkennung.

Server vs. Client

Ein Server-Programm läuft immer und wartet auf Verbindungen (z.B. ein Webserver auf Port 443). Ein Client-Programm (Ihr Browser) läuft nur bei Bedarf, greift sich einen freien Client-Port und verbindet sich. «Server» kann auch den Computer meinen, auf dem so ein Programm dauerhaft läuft.

DHCP — woher kommt überhaupt meine IP?

Hängen Sie ein Gerät neu ans Netz, hat es noch keine IP. Über die Broadcast-Adresse (255.255.255.255) und UDP ruft es ins Netz: «Wer gibt mir eine IP?» («Discover»). Ein DHCP-Server antwortet mit einem Angebot («Offer»: IP, Subnetmaske, Gateway, DNS), das Gerät beansprucht sie («Request»), der Server bestätigt («Ack»). Darum bekommen Sie in fremden WLANs automatisch eine Adresse.

Als Nächstes: Wir haben das Paket von ganz oben (Anwendung) bis zur Verbindung verfolgt. Eine Frage bleibt: Wie kommt das Paket physisch aus Ihrem Gerät heraus — durchs Kabel oder die Luft? Das klärt die letzte Lektion: WiFi & Ethernet.