Transmission Control Protocol/Prüfsumme: Unterschied zwischen den Versionen
Die Seite wurde neu angelegt: „== TCP-Prüfsumme und TCP-Pseudo-Header == Der Pseudo-Header ist eine Zusammenstellung von Header-Teilen eines TCP-Segments und Teilen des Headers des einkapselnden IP-Pakets. Es ist ein Modell, an dem sich die Berechnung der TCP-Prüfsumme ({{enS|''checksum''}}) anschaulich beschreiben lässt. Falls IP mit TCP eingesetzt wird, ist es wünschenswert, den Header des IP-Pakets mit in die Sicherung von TCP aufzunehmen. Dadurch ist die Zuver…“ |
Keine Bearbeitungszusammenfassung |
||
Zeile 123: | Zeile 123: | ||
Der Grund für dieses komplizierte Verfahren liegt darin, dass sich Teile des IP-Headers während des Routings im IP-Netz verändern. Das TTL-Feld wird bei jedem IP-Hop um eins dekrementiert. Würde das TTL-Feld in die Prüfsummenberechnung einfließen, würde IP die Sicherung des Transports durch TCP zunichtemachen. Deshalb wird nur ein Teil des IP-Headers in die Prüfsummenberechnung einbezogen. Die Prüfsumme ist zum einen wegen ihrer Länge von nur 16 Bit und wegen der einfachen Berechnungsvorschrift anfällig für nicht erkennbare Fehler. Bessere Verfahren wie [[CRC-32]] wurden zur Zeit der Definition als zu aufwendig angesehen. | Der Grund für dieses komplizierte Verfahren liegt darin, dass sich Teile des IP-Headers während des Routings im IP-Netz verändern. Das TTL-Feld wird bei jedem IP-Hop um eins dekrementiert. Würde das TTL-Feld in die Prüfsummenberechnung einfließen, würde IP die Sicherung des Transports durch TCP zunichtemachen. Deshalb wird nur ein Teil des IP-Headers in die Prüfsummenberechnung einbezogen. Die Prüfsumme ist zum einen wegen ihrer Länge von nur 16 Bit und wegen der einfachen Berechnungsvorschrift anfällig für nicht erkennbare Fehler. Bessere Verfahren wie [[CRC-32]] wurden zur Zeit der Definition als zu aufwendig angesehen. | ||
[[Kategorie:Transmission Control Protocol]] |
Version vom 20. März 2023, 09:11 Uhr
TCP-Prüfsumme und TCP-Pseudo-Header
Der Pseudo-Header ist eine Zusammenstellung von Header-Teilen eines TCP-Segments und Teilen des Headers des einkapselnden IP-Pakets. Es ist ein Modell, an dem sich die Berechnung der TCP-Prüfsumme () anschaulich beschreiben lässt.
Falls IP mit TCP eingesetzt wird, ist es wünschenswert, den Header des IP-Pakets mit in die Sicherung von TCP aufzunehmen. Dadurch ist die Zuverlässigkeit seiner Übertragung garantiert. Darum bildet man den IP-Pseudo-Header. Er besteht aus IP-Absender und -Empfängeradresse, einem Null-Byte, einem Byte, das angibt, zu welchem Protokoll die Nutzdaten des IP-Pakets gehören und der Länge des TCP-Segments mit TCP-Header. Da es sich im Fall des Pseudo-Headers immer um IP-Pakete handelt, die TCP-Segmente transportieren, ist dieses Byte auf den Wert 6 gesetzt. Der Pseudo-Header wird für die Berechnung der Prüfsumme vor den TCP-Header gelegt. Anschließend berechnet man die Prüfsumme. Die Summe wird im Feld „checksum“ abgelegt und das Fragment versendet. Kein Pseudo-Header wird je versendet.
Bit offset | Bit 0–3 | 4–7 | 8–15 | 16–31 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | IP-Absenderadresse | |||||||||||||||||||||||||||||||
32 | IP-Empfängeradresse | |||||||||||||||||||||||||||||||
64 | 00000000 | 6 (=TCP) | TCP-Länge | |||||||||||||||||||||||||||||
96 | Quellport | Zielport | ||||||||||||||||||||||||||||||
128 | Sequenznummer | |||||||||||||||||||||||||||||||
160 | ACK-Nummer | |||||||||||||||||||||||||||||||
192 | Datenoffset | Reserviert | Flags | Window | ||||||||||||||||||||||||||||
224 | Prüfsumme | Urgent pointer | ||||||||||||||||||||||||||||||
256 | Options (optional) | |||||||||||||||||||||||||||||||
256/288+ | Daten |
Die Berechnung der Prüfsumme für IPv4 ist in RFC 793 definiert:
Die Prüfsumme ist das 16-Bit-Einerkomplement der Einerkomplement-Summe aller 16-Bit-Wörter im Header und der Nutzdaten des unterliegenden Protokolls. Wenn ein Segment eine ungerade Anzahl Bytes enthält, wird ein Padding-Byte angehängt. Das Padding wird nicht übertragen. Während der Berechnung der Prüfsumme wird das Prüfsummenfeld selbst mit Nullen gefüllt.
Abweichend hiervon sieht bei IPv6 der Pseudo-Header gemäß RFC 2460 wie folgt aus:
Bit offset | 0–7 | 8–15 | 16–23 | 24–31 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | Quelladresse | |||||||||||||||||||||||||||||||
32 | ||||||||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||||||||
128 | Zieladresse | |||||||||||||||||||||||||||||||
160 | ||||||||||||||||||||||||||||||||
192 | ||||||||||||||||||||||||||||||||
224 | ||||||||||||||||||||||||||||||||
256 | TCP-Länge | |||||||||||||||||||||||||||||||
288 | Nullwerte | Nächster Header | ||||||||||||||||||||||||||||||
320 | Quellport | Zielport | ||||||||||||||||||||||||||||||
352 | Sequenznummer | |||||||||||||||||||||||||||||||
384 | ACK-Nummer | |||||||||||||||||||||||||||||||
416 | Datenoffset | Reserviert | Flags | Window | ||||||||||||||||||||||||||||
448 | Prüfsumme | Urgent pointer | ||||||||||||||||||||||||||||||
480 | Options (optional) | |||||||||||||||||||||||||||||||
480/512+ | Daten |
Der Empfänger erstellt ebenfalls den Pseudo-Header und führt anschließend dieselbe Berechnung aus, ohne das Checksum-Feld auf Null zu setzen. Dadurch sollte das Ergebnis FFFF (Hexadezimal) sein. Ist dies nicht der Fall, so wird das TCP-Segment ohne Nachricht verworfen. Dies hat zur Folge, dass der RTT-Timer beim Absender abläuft und das TCP-Segment noch einmal abgeschickt wird.
Der Grund für dieses komplizierte Verfahren liegt darin, dass sich Teile des IP-Headers während des Routings im IP-Netz verändern. Das TTL-Feld wird bei jedem IP-Hop um eins dekrementiert. Würde das TTL-Feld in die Prüfsummenberechnung einfließen, würde IP die Sicherung des Transports durch TCP zunichtemachen. Deshalb wird nur ein Teil des IP-Headers in die Prüfsummenberechnung einbezogen. Die Prüfsumme ist zum einen wegen ihrer Länge von nur 16 Bit und wegen der einfachen Berechnungsvorschrift anfällig für nicht erkennbare Fehler. Bessere Verfahren wie CRC-32 wurden zur Zeit der Definition als zu aufwendig angesehen.