Transportprotokolle für IP

Via IP werden diverse Transportprotokolle genutzt. Die geläufigsten darunter sind UDP und TCP, wobei auch QUIC mit HTTP/3 an Aufwind gewinnt.

ICMP

ICMP, kurz für Internet Control Message Protocol, ist im RFC 792 (ICMPv4) bzw. RFC 4443 (ICMPv6) als ein unterstützendes Protokoll des Internet Protocol Suites definiert und operiert somit im Layer 3 des OSI 7-Schichten-Modells, auch wenn die Header und das Payload die Bedingungen für ein Layer 4 Protokoll erfüllen. Es kann zwar zum Transport von Daten verwendet werden, dennoch liegt der eigentliche Einsatzzweck bei der Diagnose oder Kontrolle.

ICMP Datagramm

Aufbau

0 - 7	8 - 15	16 - 31
Typ	Code	Checksum (Prüfsumme)

Rest of Header

• Type: ICMP-Typ
• Code: ICMP-Subtyp
• Checksum: 16-Bit Prüfsumme über die ICMP Header und Payload, bzw. auch Pseudo-Header
• Rest of Header: Inhalt variiert je nach ICMP-Typ

ICMPv4 Typen

Typ	Bezeichnung	Code	Beschreibung
0	Echo Reply	0	Echo Reply (pong) zum ping
8	Echo Request	0	Echo Request (ping)
9	Router Advertisement	0	Ankündigung des Routers im Netz (LAN)
10	Router Solicitation	0	Nachfrage nach einem Router im Netz (LAN)
11	Time Exceeded	0	TTL is abgelaufen
11	Time Exceeded	1	Fragment-Zutsammensetzungszeit abgelaufen
3	Destination Unreachable	0	Zielnetz nicht erreichbar
3	Destination Unreachable	1	Zielhost nicht erreichbar
3	Destination Unreachable	2	Zielprotokoll nicht erreichbar
3	Destination Unreachable	3	Zielport nicht erreichbar
3	Destination Unreachable	4	Trotz DF-Bit Fragmentierung erforderlich
3	Destination Unreachable	5	Quell-Route fehlgeschlagen
3	Destination Unreachable	6	Zielnetz unbekannt
3	Destination Unreachable	7	Zielhost unbekannt

ICMPv6 Typen

Typ	Bezeichnung	Code	Beschreibung
128	Echo Request	0	Echo Request (ping)
129	Echo Reply	0	Echo Reply (pong) zum ping
133	Router Solicitation	0	Nachfrage nach einem RA (NDP)
134	Router Advertisement (RA)	0	Ankündigung des Routers (NDP)
135	Neighbor Solicitation	0	Neighbor Solicitation (via NDP)
136	Neighbor Advertisement	0	Neighbor Advertisement (NDP)
3	Time Exceeded	0	TTL is abgelaufen
3	Time Exceeded	1	Fragment-Zutsammensetzungszeit abgelaufen
1	Destination Unreachable	0	keine Route zum Ziel
1	Destination Unreachable	1	Kommunikation mit dem Ziel administrativ verboten
1	Destination Unreachable	3	Adresse nicht erreichbar
1	Destination Unreachable	4	Zielport nicht erreichbar
1	Destination Unreachable	6	Route zum Ziel abgewiesen (bspw. Firewall)

UDP

UDP, kurz für User Datagram Protocol, ist ein (Layer 4) Transportprotokoll der Internetprotokollfamilie.Es hat folgende Eigenschaften:

• unzuverlässig:
• • unklar, ob das Paket beim Empfänger ankommt
• • die Empfangsreihenfolge kann variieren
• verbindungslos: Es wird keine Verbindung oder Session auf- und abgebaut.
• paketvermittelt: Daten werden in Paketen über eine geteilte Leitung übertragen

UDP Datagramm

Ein Datagramm ist laut RFC 1594 "eine in sich geschlossene, unabhängige Dateneinheit, die genügend Informationen enthält, um vom Quell- zum Zielcomputer weitergeleitet zu werden, ohne auf einen früheren Austausch zwischen diesem Quell- und Zielcomputer und dem transportierenden Netz angewiesen zu sein".

Der Begriff "UDP Paket" wird oftmals synonym zu "UDP Datagramm" genutzt, auch wenn sich Pakete und Datagramme in den Feinheiten unterscheiden. So werden UDP Datagramme zu UDP Paketen, sobald sie mit den IP-Headern versehen werden. Im Sinne diesen Artikels sind die Unterschiede jedoch nicht relevant. Sie können aber hier eingesehen werden: Definition of Network Units: Packet, Fragment, Frame, Datagram, and Segment

Aufbau

0 - 15	16 - 31
Quell-Port	Ziel-Port
Länge	Checksum (Prüfsumme)

Daten (Payload)

• Quell-Port: Port-Nummer des sendenden Prozesses
• Ziel-Port: Port-Nummer des EMpfängerprozesses
• Länge: Länge des Datagramms inkl. der IP Header (max. 2¹⁶-1 Bytes)
• Checksum: 16-Bit Prüfsumme über die Pseudo-Header, UDP Header und die Daten
• Datenfeld: Die zu übertragenden Nutzdaten (oft bis zu 65.507 Bytes via IPv4, 65.487 Bytes via IPv6)

Pseudo-Header

UDP Datagramme werden als UDP Pakete via IP übertragen. IP setzt dabei vor dem UDP Paket einen weiteren Header, in dem sich die von IP benötigten Daten befinden. Für die Erzeugung der Prüfsumme werden Teile des IP-Headers in einen Pseudo-Header eingesetzt. Der Pseudo-Header wird jedoch nur zur Erzeugung der Prüfsumme genutzt und wird nicht als Teil des UDP Pakets übertragen.

IPv4

Der IPv4 Pseudo-Header hat eine Größe von 12 Bytes (96 Bits) und ist wie folgt aufgebaut:

0 - 31	32 - 63	64 - 71	72 - 79	80 - 95
Quell-IP	Ziel-IP	Leerfeld	Protokoll-ID	UDP-Datagramm-Länge
X	X	0000 0000	0001 0001	X

IPv6

Bei einem Transport via IPv6 hat der Pseudo-Header eine Größe von 40 Bytes (320 Bits) und ist wie folgt aufgebaut:

0 - 127	128 - 255	256 - 287	288 - 311	312 - 319
Quell-IP	Ziel-IP	UDP-Datagramm-Länge	Leerfeld	Next Header
X	X	X	0x000000	X

TCP

TCP, kurz für Transmission Control Protocol, ist ein (Layer 4) Transportprotokoll der Internetprotokollfamilie. Es hat folgende EIgenschaften:

• zuverlässig: durch Sequenznummern und Empfangsbestätigungen (ACK)
• • Alle gesendeten Daten kommen an
• • Die Daten kommen in der richtigen Reihenfolge an
• • Es gibt keine Duplikate
• verbindungsorientiert: Es wird eine Verbindung (Connection) bzw. Session aufgebaut und nach erfolgter Übertragung abgebaut
• paketvermittelt: Daten werden in Paketen über eine geteilte Leitung übertragen, d.h. mehrere Verbindungen gleichzeitig sind möglich

Paketaufbau

TCP Segment Header

Offsets		0								1								2								3
Octet	Bit	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
0	0	Source port																Destination port
4	32	Sequence number
8	64	Acknowledgment number (if ACK set)
12	96	Data offset				Reserved 0 0 0 0				CWR	ECE	URG	ACK	PSH	RST	SYN	FIN	Window Size
16	128	Checksum																Urgent pointer (if URG set)
20	160	Options (if data offset > 5. Padded at the end with "0" bits if necessary.)
⋮	⋮
56	448

• Sequenznummer:
• • Falls SYN = 1: initiale Sequenznummer des ersten Datenbytes und des darauf zu folgenden ACK
• • Falls SYN = 0: die akkumulierte Sequenznummer des ersten Datenbytes im Paket
• ACK Nummer:
• • Falls ACK = 1: Nächste Sequenznummer, die der Absender des ACK erwartet. Ein ACK bestätigt den Empfang aller bis dahin erhaltenen Pakete
• Data Offset: Größe des TCP Headers in 32-Bit-Wörtern
• Flags: 8 Kontroll-Bits
• • CWR: Congestion Window Reduced, informiert, dass zuvor vom jetzigen Empfänger das ECE Flag gesetzt wurde und nun Congestion Control Mechanismen greifen
• • ECE: ECN-Echo
• • • SYN = 1: TCP Peer ist ECN-fähig (Ende zu Ende Congestion Hinweise zu empfangen)
• • • SYN = 0: Indikator für ein bestehendes oder anstehendes Network Congestion
• • URG: besagt, dass Pointer auf das Urgent-Feld ist signifikant ist
• • ACK: besagt, dass das ACK-Feld relevant ist. Außer beim initialen SYN Paket, sollte dieses FLag immer gesetzt sein
• • PSH: Push Hinweis. Fragt an, dass die Pakete im Puffer an die Anwendung weitergegeben werden
• • RST: Reset
• • SYN: Snychronisierung von Sequenznummern (bei initialem Verbindungsaufbau)
• • FIN: indiziert, dass es das letzte Paket ist und der Sender danach nichts mehr sendet

aus: Transmission Control Protocol, Wikipedia the free encyclopedia, abg. am 14.12.2023

TCP-Verbindung

Eine TCP-Verbindung wird stets mittels 3-Wege-Handshake aufgebaut und mittels 4-Wege-Handshake terminiert:

aus: crocus.kr, abg. am 14.12.2023

Congestion Control

TCP implementiert zudem ein Congestion Control Mechanismus, also eine Überlastungskontrolle. Dazu gehört die Slow Start Strategie mit einem Congestion Window (CWND) von 1, 2, 4 oder 10 Maximaler Segmentgröße (MSS). Mit jedem erfolgreich erhaltenen ACK steigt der CWND Wert. Die maximale Übertragunsrate wird anschließend nach und nach erhöht bis entweder ein Paketverlust erfolgt, oder der empfängerseitig festgelegte Window Size (rwnd) erreicht ist.

QUIC

QUIC ist ein modernes Layer 4 Transportprotokoll standartisiert unter RFC 9000. Der Fokus liegt dabei im Transport von verbindungsorientierten Web-Applikationen, die bis Dato TCP verwenden. Dazu werden zwischen zwei Endgeräten mehrere Verbindungen gleichzeitig via UDP aufgebaut. Durch Verwendung von UDP im Unterbau sinken zudem die Latenzen und die genutzte Bandbreite. Congestion Control werden dabei nicht auf der Kernel-Ebene sondern in der Nutzer-Ebene implementiert. Dies vereinfacht etwaige QUIC Implementationen auch auf bestehenden Systemen auszurollen. Außerdem ist das Protokoll flexibel aufgebaut, sodass Erweiterungen zu QUIC möglich werden.

QUIC verbindet zudem die Funktion von TLS over TCP. Dadurch sinkt das Overhead in einer verschlüsselten HTTPS-Verbindung. Alleine das Handshake für den Verbindungsaufbau wird deutlich kürzer:

(C) CC BY-SA 4.0, Sedrubal, Wikimedia Foundation. URL: Verbinsungsaufbau von QUIC im Vergleich zu TCP

Packet-Loss-Handling

Auch hier werden wie in TCP ACKs geschickt, um den Erhalt eines Pakets zu bestätigen. Dabei gilt:

• Nur ACK erfordernde Pakete führen zum Versand eines ACK Frames innerhalb des Maxmimum ACK Delay
• Andere Pakete werden nur dann per ACK bestätigt, sobald ein ACK Frame aus einem anderen Grund versandt wird
• Wenn ein neues Paket gesendet wird, wird auch ein ACK Frame hinzugefügt, sofern ein ACK-Versand noch aussteht

Dadurch erzielt man Folgendes:

• Vermeidung des Versands purer ACK-Pakete ohne Payload
• Die zeitintensive Packet-Loss-Ermittlung wird entlasten

Kommt es zu einem Paketverlust, wird das Paket nicht eigenständig erneut versendet. Stattdessen wird es in Frames zerlegt und nach und nach als Frames innerhalb der anstehenden Paketen mitversandt. Sobald ein Paket, dass die versandten Informationen enthält, mit einem ACK beantwortet wurde, findet der erneute Versand auch nicht mehr statt.

Anwendungsfälle

• HTTP/3: grundsätzlich HTTP/2 over QUIC
• DNS-over-QUIC: wie DNS-over-TLS aber mit QUIC
• SMB over QUIC: bislang falls SMB via TCP fehlschlägt
• Tunneling: cloudflared & go-tun z.B. nutzen QUIC