TCP, UDP und Ports

Eine Portnummer hat 16 Bit, reicht also von 0 bis 65535. Webserver mit HTTPS lauschen auf Port 443.

Zuerst zwei Rätsel. In einem Videoanruf geht unterwegs ein kleines Stück der Stimme deiner Freundin verloren. Soll deine App es noch einmal anfordern? Jetzt lädst du eine Hausaufgabendatei herunter, und ein Stück der Datei geht verloren. Dieselbe Frage. Entscheide beide, bevor du weiterliest.

Zwei fehlende Stücke, zwei verschiedene Antworten

Wenn du beim Anruf Nein und bei der Datei Ja gesagt hast, hast du schon zwischen den beiden Transportprotokollen gewählt. Ein Stück Ton, das eine halbe Sekunde zu spät kommt, ist nutzlos. Das Gespräch ist weitergegangen, also überspringt man das Stück besser und spielt das nächste ab. Eine Datei, der ein Stück fehlt, ist kaputt, also lohnt es sich, auf dieses Stück zu warten. Das Internet hat für jeden Fall ein Transportprotokoll: TCP wartet und sendet erneut, UDP sendet und macht weiter. Bevor eines von beiden helfen kann, muss ein Paket aber das richtige Programm erreichen.

Welches Programm bekommt das Paket: Ports

Eine IP-Adresse bringt ein Paket zum richtigen Computer. Aber auf einem Computer laufen viele Programme gleichzeitig: ein Browser mit mehreren Tabs, eine Chat-App, eine Musik-App. Sowohl TCP- als auch UDP-Header tragen einen Quellport und einen Zielport, jeweils eine 16-Bit-Zahl von 0 bis 65535, und der Port sagt, für welches Programm ein Paket bestimmt ist. Ein Serverprogramm lauscht auf einem vereinbarten Port: 80 für einfaches HTTP, 443 für HTTPS, 53 für DNS, 25 für Mail zwischen Servern. RFC 6335 teilt den Bereich in System-Ports 0 bis 1023, User-Ports 1024 bis 49151 und dynamische Ports 49152 bis 65535. Dein Computer wählt für jedes Gespräch einen vorübergehenden Quellport, oft aus dem dynamischen Bereich. Eine Adresse und ein Port zusammen, etwa 198.51.100.20:443, benennen ein Ende eines Gesprächs genau.

TCP hakt jedes Byte ab

TCP (RFC 9293) macht aus einem unzuverlässigen Strom von Paketen etwas wie eine Telefonleitung für Bytes. Zuerst bauen die beiden Seiten mit einem Drei-Wege-Handshake eine Verbindung auf: Der Client sendet SYN, der Server antwortet mit SYN-ACK, und der Client erwidert ACK. Von da an hat jedes Byte eine Sequenznummer. Der Empfänger sendet Bestätigungen (ACKs), die sagen, wie weit er gekommen ist, und bringt Stücke in falscher Reihenfolge wieder an ihren Platz. Hört der Sender innerhalb einer Wartezeit kein ACK, sendet er die Daten erneut. RFC 6298 setzt die erste Wartezeit auf 1 Sekunde und passt sie dann an die gemessene Round-Trip-Zeit an. Außerdem wird TCP langsamer, wenn es Verluste bemerkt, damit eine ausgelastete Verbindung nicht überflutet wird.

UDP sendet und macht weiter

UDP (RFC 768, 1980) tut viel weniger. Sein Header hat nur 8 Byte: zwei Ports, eine Länge und eine Prüfsumme. Es gibt keinen Handshake, keine Sequenznummer und kein erneutes Senden. Für den Videoanruf aus dem ersten Rätsel ist das genau richtig. Auch kurze DNS-Fragen nutzen UDP, weil eine Frage und eine Antwort ohne Handshake schneller gehen. QUIC, das Transportprotokoll unter HTTP/3, läuft auf UDP und baut darauf sein eigenes erneutes Senden auf.

Vier Zahlen halten zwei Tabs auseinander

Vier Zahlen zusammen kennzeichnen eine TCP-Verbindung: Quelladresse, Quellport, Zieladresse und Zielport. So kann ein Server auf Port 443 mit Tausenden Browsern gleichzeitig sprechen, ohne sie zu verwechseln, und so hält dein Laptop zwei Tabs auf derselben Website auseinander, denn die Verbindung jedes Tabs nutzt einen anderen Quellport. Tippe im Simulator auf ein Paket und lies seinen Header. Vor dem Heimrouter ist die Quelle 192.168.0.12, Port 51000. Danach hat NAT beide Zahlen geändert, und der Router merkt sich den Tausch, damit die Antworten zum richtigen Tab zurückgehen.