3. Functional Specification - Part 1 (Funktionale Spezifikation - Teil 1)
Dieser Abschnitt enthält die technische Kernspezifikation von TCP: Header-Format, Terminologie und Sequenznummernmechanismen.
3.1. Header Format (Header-Format)
TCP-Segmente (TCP segments) werden als Internet-Datagramme (internet datagrams) gesendet. Der Internet-Protokoll-Header trägt mehrere Informationsfelder, einschließlich der Quell- und Ziel-Host-Adressen [2]. Ein TCP-Header folgt dem Internet-Header und liefert TCP-protokollspezifische Informationen. Diese Aufteilung ermöglicht die Existenz von Host-Level-Protokollen außer TCP.
TCP-Header-Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP-Header-Format
Hinweis: Ein Teilstrich repräsentiert eine Bitposition
Feldbeschreibungen
Source Port (Quellport): 16 Bits
Die Quellportnummer.
Zweck: Identifiziert den sendenden Prozess auf dem sendenden Host.
Destination Port (Zielport): 16 Bits
Die Zielportnummer.
Zweck: Identifiziert den empfangenden Prozess auf dem empfangenden Host.
Sequence Number (Sequenznummer): 32 Bits
Die Sequenznummer des ersten Daten-Oktetts in diesem Segment (außer wenn SYN vorhanden ist). Wenn SYN vorhanden ist, ist die Sequenznummer die initiale Sequenznummer (Initial Sequence Number, ISN) und das erste Daten-Oktett ist ISN+1.
Wichtige Punkte:
- Jedes Daten-Byte hat eine eindeutige Sequenznummer
- SYN-Segmente verwenden ISN, Daten beginnen bei ISN+1
- Sequenznummernraum: 0 bis 2³² - 1
Acknowledgment Number (Bestätigungsnummer): 32 Bits
Wenn das ACK-Steuerbit gesetzt ist, enthält dieses Feld den Wert der nächsten Sequenznummer, die der Sender des Segments zu empfangen erwartet. Sobald eine Verbindung hergestellt ist, wird dies immer gesendet.
Kumulativer Bestätigungsmechanismus:
- Eine Bestätigungsnummer X zeigt an, dass alle Bytes bis zu X (aber nicht einschließlich X) empfangen wurden
- X selbst ist nicht enthalten
Data Offset (Datenoffset): 4 Bits
Die Anzahl der 32-Bit-Wörter im TCP-Header. Dies zeigt an, wo die Daten beginnen. Der TCP-Header (auch einer mit Optionen) ist eine integrale Anzahl von 32 Bits lang.
Berechnungsformel:
Header-Länge (Bytes) = Data Offset × 4
Mindestwert: 5 (20 Bytes)
Maximalwert: 15 (60 Bytes)
Reserved (Reserviert): 6 Bits
Für zukünftige Verwendung reserviert. MUSS null sein (MUST).
Control Bits (Steuerbits): 6 Bits (von links nach rechts)
| Flag | Vollständiger Name | Bedeutung |
|---|---|---|
| URG | Urgent | Urgent-Pointer-Feld gültig |
| ACK | Acknowledgment | Bestätigungsfeld gültig |
| PSH | Push | Push-Funktion |
| RST | Reset | Verbindung zurücksetzen |
| SYN | Synchronize | Sequenznummern synchronisieren |
| FIN | Finish | Keine weiteren Daten vom Sender |
Flag-Kombinationen:
SYN = 1: Verbindungsaufbauanfrage
SYN + ACK = 1: Verbindungsaufbauantwort
FIN = 1: Verbindungsabbauanfrage
RST = 1: Abnormaler Verbindungsabbruch
PSH = 1: Daten sofort zur Anwendungsschicht pushen
URG = 1: Dringende Daten vorhanden
Window (Fenster): 16 Bits
Die Anzahl der Daten-Oktetts, beginnend mit dem im Bestätigungsfeld angegebenen, die der Sender dieses Segments zu akzeptieren bereit ist.
Flusskontrolle:
- Fenstergröße = 0: Datensendung stoppen
- Fenstergröße > 0: Kann bis zu Fenstergröße Bytes senden
- Maximales Fenster: 65.535 Bytes (kann mit Fensterskalierungsoption erweitert werden)
Beispiel:
ACK = 1000, Window = 5000
→ Kann Daten mit Sequenznummern 1000-4999 empfangen (5000 Bytes)
Checksum (Prüfsumme): 16 Bits
Das Prüfsummenfeld ist das 16-Bit-Einerkomplement der Einerkomplement-Summe aller 16-Bit-Wörter im Header und Text. Wenn ein Segment eine ungerade Anzahl von zu prüfenden Header- und Text-Oktetts enthält, wird das letzte Oktett rechts mit Nullen aufgefüllt, um ein 16-Bit-Wort für Prüfsummenzwecke zu bilden. Die Auffüllung wird nicht als Teil des Segments übertragen. Bei der Berechnung der Prüfsumme wird das Prüfsummenfeld selbst durch Nullen ersetzt.
Pseudo-Header:
Die Prüfsumme deckt auch einen konzeptionell dem TCP-Header vorangestellten 96-Bit-Pseudo-Header ab. Dieser Pseudo-Header enthält Quelladresse, Zieladresse, Protokoll und TCP-Länge. Dies bietet TCP Schutz vor falsch gerouteten Segmenten.
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
PTCL = 6 (TCP-Protokollnummer)
TCP Length = TCP-Header-Länge + Datenlänge (in Oktetts)
Prüfsummenberechnungsschritte:
def calculate_tcp_checksum(pseudo_header, tcp_header, data):
# 1. Prüfsummenfeld auf 0 setzen
# 2. Pseudo-Header, TCP-Header und Daten kombinieren
# 3. Als 16-Bit-Wörter summieren
# 4. Übertrag zu den unteren 16 Bits addieren
# 5. Einerkomplement nehmen
pass
Urgent Pointer (Urgent-Zeiger): 16 Bits
Dieses Feld kommuniziert den aktuellen Wert des Urgent-Zeigers als positiven Offset von der Sequenznummer in diesem Segment. Der Urgent-Zeiger zeigt auf die Sequenznummer des Oktetts nach den dringenden Daten. Dieses Feld wird nur in Segmenten mit gesetztem URG-Steuerbit interpretiert.
Anwendungsfälle:
- Ctrl+C-Unterbrechungssignale
- Telnet-Unterbrechungsbefehle
- Steuerinformationen, die vorrangige Verarbeitung erfordern
Beispiel:
SEG.SEQ = 1000
URG Pointer = 10
→ Dringende Daten enden bei Sequenznummer 1010
→ Sequenznummern 1000-1009 sind dringende Daten
Options (Optionen): variabel
Optionen können Platz am Ende des TCP-Headers einnehmen und sind ein Vielfaches von 8 Bits lang. Alle Optionen sind in der Prüfsumme enthalten. Eine Option kann an jeder Oktett-Grenze beginnen. Es gibt zwei Formate für Optionen:
Fall 1: Ein einzelnes Oktett von option-kind Fall 2: Ein Oktett von option-kind, ein Oktett von option-length und die tatsächlichen option-data-Oktetts
Die option-length zählt die zwei Oktetts von option-kind und option-length sowie die option-data-Oktetts.
Wichtig: TCP MUSS alle Optionen implementieren (MUST).
Derzeit definierte Optionen
| Kind (oktal) | Length | Bedeutung |
|---|---|---|
| 0 | - | Ende der Optionsliste (End of Option List) |
| 1 | - | Keine Operation (No-Operation) |
| 2 | 4 | Maximale Segmentgröße (Maximum Segment Size) |
Optionsdetails
1. End of Option List (Ende der Optionsliste)
+--------+
|00000000|
+--------+
Kind=0
- Dieser Optionscode zeigt das Ende der Optionsliste an
- Dies stimmt möglicherweise nicht mit dem Ende des TCP-Headers gemäß dem Data Offset-Feld überein
- Wird am Ende aller Optionen verwendet, nicht jeder Option
- Nur erforderlich, wenn das Ende der Optionen nicht anderweitig mit dem Ende des TCP-Headers übereinstimmt
2. No-Operation (Keine Operation)
+--------+
|00000001|
+--------+
Kind=1
- Dieser Optionscode KANN zwischen Optionen verwendet werden (MAY)
- Zum Beispiel, um den Beginn einer nachfolgenden Option auf eine Wortgrenze auszurichten
- Es gibt keine Garantie, dass Sender diese Option verwenden werden
- Empfänger MÜSSEN darauf vorbereitet sein, Optionen zu verarbeiten, die nicht an einer Wortgrenze beginnen (MUST)
3. Maximum Segment Size (Maximale Segmentgröße)
+--------+--------+---------+--------+
|00000010|00000100| max seg size |
+--------+--------+---------+--------+
Kind=2 Length=4
Maximum Segment Size Option Data: 16 Bits
- Wenn diese Option vorhanden ist, kommuniziert sie die maximale Empfangssegmentgröße beim TCP, das dieses Segment sendet
- Dieses Feld MUSS nur in der initialen Verbindungsanfrage gesendet werden (MUST) (d.h. in Segmenten mit gesetztem SYN-Steuerbit)
- Wenn diese Option nicht verwendet wird, ist jede Segmentgröße erlaubt
MSS-Hinweise:
- Standard-MSS = 536 Bytes (Internet-Standard)
- Übliches Ethernet-MSS = 1460 Bytes (1500 - 20 IP-Header - 20 TCP-Header)
- MSS bezieht sich nur auf den Datenteil, ausgenommen TCP/IP-Header
Padding (Auffüllung): variabel
Die TCP-Header-Auffüllung wird verwendet, um sicherzustellen, dass der TCP-Header an einer 32-Bit-Grenze endet und Daten an einer 32-Bit-Grenze beginnen. Die Auffüllung besteht aus Nullen.
3.2. Terminology (Terminologie)
Bevor wir die Funktionsweise von TCP diskutieren können, müssen wir einige detaillierte Terminologie einführen. Die Wartung einer TCP-Verbindung erfordert das Speichern mehrerer Variablen. Wir stellen uns vor, dass diese Variablen in einem Verbindungsdatensatz gespeichert werden, der Übertragungssteuerblock (Transmission Control Block, TCB) genannt wird.
Im TCB gespeicherte Variablen
Zu den im TCB gespeicherten Variablen gehören:
- Die lokalen und entfernten Socket-Nummern
- Die Sicherheit und Priorität der Verbindung
- Zeiger auf die Sende- und Empfangspuffer des Benutzers
- Zeiger auf die Neuübertragungswarteschlange und auf das aktuelle Segment
- Mehrere Variablen in Bezug auf die Sende- und Empfangssequenznummern
Sendesequenzvariablen (Send Sequence Variables)
| Variable | Vollständiger Name | Beschreibung |
|---|---|---|
| SND.UNA | Send Unacknowledged | Senden unbestätigt (älteste unbestätigte Sequenznummer) |
| SND.NXT | Send Next | Senden nächste (nächste zu sendende Sequenznummer) |
| SND.WND | Send Window | Sendefenster |
| SND.UP | Send Urgent Pointer | Sende-Urgent-Zeiger |
| SND.WL1 | Segment Sequence Number | Segment-Sequenznummer für letzte Fensteraktualisierung |
| SND.WL2 | Segment Acknowledgment Number | Segment-Bestätigungsnummer für letzte Fensteraktualisierung |
| ISS | Initial Send Sequence Number | Initiale Sendesequenznummer |
Empfangssequenzvariablen (Receive Sequence Variables)
| Variable | Vollständiger Name | Beschreibung |
|---|---|---|
| RCV.NXT | Receive Next | Empfangen nächste (nächste erwartete Sequenznummer) |
| RCV.WND | Receive Window | Empfangsfenster |
| RCV.UP | Receive Urgent Pointer | Empfangs-Urgent-Zeiger |
| IRS | Initial Receive Sequence Number | Initiale Empfangssequenznummer |
Sequenzraum-Diagramme
Sendesequenzraum (Send Sequence Space)
1 2 3 4
----------|----------|----------|----------
SND.UNA SND.NXT SND.UNA
+SND.WND
1 - alte Sequenznummern, die bestätigt wurden
2 - Sequenznummern unbestätigter Daten
3 - Sequenznummern, die für neue Datenübertragung erlaubt sind
4 - zukünftige Sequenznummern, die noch nicht erlaubt sind
Sendefenster: Der Teil des Sequenzraums, der im Diagramm mit 3 bezeichnet ist
Empfangssequenzraum (Receive Sequence Space)
1 2 3
----------|----------|----------
RCV.NXT RCV.NXT
+RCV.WND
1 - alte Sequenznummern, die bestätigt wurden
2 - Sequenznummern, die für neuen Empfang erlaubt sind
3 - zukünftige Sequenznummern, die noch nicht erlaubt sind
Empfangsfenster: Der Teil des Sequenzraums, der im Diagramm mit 2 bezeichnet ist
Aktuelle Segmentvariablen (Current Segment Variables)
Diese Variablen werden aus den Feldern des aktuellen Segments abgeleitet:
| Variable | Beschreibung |
|---|---|
| SEG.SEQ | Segment-Sequenznummer |
| SEG.ACK | Segment-Bestätigungsnummer |
| SEG.LEN | Segmentlänge |
| SEG.WND | Segmentfenster |
| SEG.UP | Segment-Urgent-Zeiger |
| SEG.PRC | Segment-Prioritätswert |
Verbindungszustände (Connection States)
Eine Verbindung durchläuft während ihrer Lebensdauer eine Reihe von Zuständen. Die Zustände sind: LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT und der fiktive Zustand CLOSED.
Zustandsbeschreibungen
| Zustand | Beschreibung |
|---|---|
| LISTEN | Repräsentiert das Warten auf eine Verbindungsanfrage von einem beliebigen entfernten TCP und Port |
| SYN-SENT | Repräsentiert das Warten auf eine übereinstimmende Verbindungsanfrage nach dem Senden einer Verbindungsanfrage |
| SYN-RECEIVED | Repräsentiert das Warten auf eine bestätigende Verbindungsanfrage-Bestätigung nach dem Empfangen und Senden einer Verbindungsanfrage |
| ESTABLISHED | Repräsentiert eine offene Verbindung, empfangene Daten können an den Benutzer geliefert werden. Der normale Zustand für die Datenübertragungsphase der Verbindung |
| FIN-WAIT-1 | Repräsentiert das Warten auf eine Verbindungsabbauanfrage vom entfernten TCP oder eine Bestätigung der zuvor gesendeten Verbindungsabbauanfrage |
| FIN-WAIT-2 | Repräsentiert das Warten auf eine Verbindungsabbauanfrage vom entfernten TCP |
| CLOSE-WAIT | Repräsentiert das Warten auf eine Verbindungsabbauanfrage vom lokalen Benutzer |
| CLOSING | Repräsentiert das Warten auf eine Verbindungsabbauanfrage-Bestätigung vom entfernten TCP |
| LAST-ACK | Repräsentiert das Warten auf eine Bestätigung der zuvor an das entfernte TCP gesendeten Verbindungsabbauanfrage (die eine Bestätigung ihrer Verbindungsabbauanfrage enthält) |
| TIME-WAIT | Repräsentiert das Warten auf genügend Zeit, um sicherzustellen, dass das entfernte TCP die Bestätigung seiner Verbindungsabbauanfrage erhalten hat |
| CLOSED | Repräsentiert überhaupt keinen Verbindungszustand (fiktiver Zustand, da er den Zustand darstellt, wenn kein TCB existiert) |
TCP-Verbindungszustandsdiagramm
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- |
V x V snd FIN V
+---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK|
+---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+ +---------+
TCP-Verbindungszustandsdiagramm
Ereignisse und Zustandsübergänge
Eine TCP-Verbindung schreitet als Reaktion auf Ereignisse von einem Zustand zum anderen fort. Ereignisse umfassen:
- Benutzeraufrufe: OPEN, SEND, RECEIVE, CLOSE, ABORT, STATUS
- Ankommende Segmente: Insbesondere solche mit SYN-, ACK-, RST- und FIN-Flags
- Zeitüberschreitungen: Neuübertragungszeitüberschreitung, TIME-WAIT-Zeitüberschreitung usw.
Hinweis: Das Zustandsdiagramm ist nur eine Zusammenfassung und kann nicht als vollständige Spezifikation allein stehen. Es zeigt nur Zustandsänderungen mit ihren auslösenden Ereignissen und resultierenden Aktionen, zeigt aber weder Fehlerbedingungen noch Aktionen an, die nicht mit Zustandsänderungen verbunden sind.
3.3. Sequence Numbers (Sequenznummern)
Grundkonzepte
Ein grundlegendes Konzept im Design von TCP ist, dass jedes über eine TCP-Verbindung gesendete Daten-Oktett eine Sequenznummer hat. Da jedes Oktett sequenziert ist, kann jedes von ihnen bestätigt werden. Der verwendete Bestätigungsmechanismus ist kumulativ (cumulative), sodass eine Bestätigung der Sequenznummer X anzeigt, dass alle Oktetts bis zu X (aber nicht einschließlich X) empfangen wurden.
Dieser Mechanismus ermöglicht eine einfache Duplikaterkennung bei Vorhandensein von Neuübertragung. Die Nummerierung von Oktetts innerhalb eines Segments ist so, dass das erste Daten-Oktett unmittelbar nach dem Header die niedrigste Nummer hat und die folgenden Oktetts fortlaufend nummeriert werden.
Sequenznummernraum
Wichtige Tatsache: Der tatsächliche Sequenznummernraum ist endlich, obwohl sehr groß. Dieser Raum reicht von 0 bis 2³² - 1.
Modulo-Arithmetik: Da der Raum endlich ist, MUSS alle Arithmetik mit Sequenznummern modulo 2³² durchgeführt werden (MUST). Diese vorzeichenlose Arithmetik bewahrt die Beziehung von Sequenznummern, wenn sie von 2³² - 1 wieder zu 0 zyklieren. Es gibt einige Feinheiten bei der Computer-Modulo-Arithmetik, daher SOLLTE große Sorgfalt beim Programmieren des Vergleichs solcher Werte walten (SHOULD).
Notationskonvention:
- Das Symbol
=<bedeutet "kleiner oder gleich" (modulo 2³²)
Sequenznummernvergleiche
Typische Sequenznummernvergleiche, die TCP durchführen muss, umfassen:
- Feststellen, dass eine Bestätigung sich auf eine gesendete, aber noch nicht bestätigte Sequenznummer bezieht
- Feststellen, dass alle von einem Segment belegten Sequenznummern bestätigt wurden (z.B. um das Segment aus einer Neuübertragungswarteschlange zu entfernen)
- Feststellen, dass ein eingehendes Segment erwartete Sequenznummern enthält (d.h. dass das Segment das Empfangsfenster "überlappt")
Sendesequenznummernverarbeitung
Als Reaktion auf das Senden von Daten empfängt das TCP Bestätigungen. Die folgenden Vergleiche sind erforderlich, um die Bestätigungen zu verarbeiten:
SND.UNA = älteste unbestätigte Sequenznummer
SND.NXT = nächste zu sendende Sequenznummer
SEG.ACK = Bestätigung vom empfangenden TCP (nächste vom empfangenden TCP erwartete Sequenznummer)
SEG.SEQ = erste Sequenznummer eines Segments
SEG.LEN = die Anzahl der von Daten im Segment belegten Oktetts (zählt SYN und FIN)
SEG.SEQ+SEG.LEN-1 = letzte Sequenznummer eines Segments
Akzeptables ACK (Acceptable ACK):
Eine neue Bestätigung (genannt "akzeptables ACK") ist eine, für die die folgende Ungleichung gilt:
SND.UNA < SEG.ACK ≤ SND.NXT
Ein Segment in der Neuübertragungswarteschlange ist vollständig bestätigt, wenn die Summe seiner Sequenznummer und Länge kleiner oder gleich dem Bestätigungswert im eingehenden Segment ist.
Beispiel:
SND.UNA = 1000 (älteste unbestätigte)
SND.NXT = 2000 (nächste zu senden)
Empfange SEG.ACK = 1500
Prüfe: 1000 < 1500 ≤ 2000 ✓ (akzeptabel)
Empfange SEG.ACK = 2500
Prüfe: 1000 < 2500 ≤ 2000 ✗ (nicht akzeptabel, bestätigt nicht gesendete Daten)
Empfangssequenznummernverarbeitung
Beim Empfangen von Daten sind die folgenden Vergleiche erforderlich:
RCV.NXT = nächste erwartete Sequenznummer bei einem eingehenden Segment,
und ist die linke oder untere Kante des Empfangsfensters
RCV.NXT+RCV.WND-1 = letzte erwartete Sequenznummer bei einem eingehenden Segment,
und ist die rechte oder obere Kante des Empfangsfensters
SEG.SEQ = erste vom eingehenden Segment belegte Sequenznummer
SEG.SEQ+SEG.LEN-1 = letzte vom eingehenden Segment belegte Sequenznummer
Segmentakzeptanztest
Ein Segment wird nur dann als akzeptabel beurteilt, wenn es innerhalb des Fensters liegt. Der Test hängt von der Segmentlänge und der Fenstergröße ab:
| Segmentlänge | Fenstergröße | Akzeptanztest |
|---|---|---|
| 0 | 0 | SEG.SEQ = RCV.NXT |
| 0 | >0 | RCV.NXT ≤ SEG.SEQ < RCV.NXT+RCV.WND |
| >0 | 0 | nicht akzeptabel |
| >0 | >0 | RCV.NXT ≤ SEG.SEQ < RCV.NXT+RCV.WND oder RCV.NXT ≤ SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND |
Erklärung:
- Der erste Test für Segmente der Länge Null kann als Test eines Phantomsegments betrachtet werden, das bei SEG.SEQ beginnt und keinen Sequenzraum belegt
- Wenn RCV.WND null ist, werden keine Daten akzeptiert, aber Segmente, die keinen Raum belegen, sind akzeptabel
Praktisches Codebeispiel:
def is_segment_acceptable(seg_seq, seg_len, rcv_nxt, rcv_wnd):
"""Prüft, ob Segment akzeptabel ist"""
if seg_len == 0:
if rcv_wnd == 0:
return seg_seq == rcv_nxt
else:
return rcv_nxt <= seg_seq < rcv_nxt + rcv_wnd
else: # seg_len > 0
if rcv_wnd == 0:
return False
else:
# Entweder Anfang oder Ende des Segments ist im Fenster
start_in_window = rcv_nxt <= seg_seq < rcv_nxt + rcv_wnd
end_in_window = rcv_nxt <= seg_seq + seg_len - 1 < rcv_nxt + rcv_wnd
return start_in_window or end_in_window
Auswahl der initialen Sequenznummer (ISN)
Die Wahl der initialen Sequenznummer (ISN) ist entscheidend. Das TCP MUSS einen taktgesteuerten ISN-Generator verwenden, um zu vermeiden, dass alte Verbindungssegmente als Teil einer neuen Verbindung verwechselt werden (MUST).
ISN-Generierungsempfehlungen:
- ISN SOLLTE alle 4 Mikrosekunden um 1 erhöht werden (SHOULD)
- ISN hat eine Periode von ungefähr 4,55 Stunden
- ISN für neue Verbindungen SOLLTE sich von ISN alter Verbindungen unterscheiden (SHOULD)
Sicherheitserwägungen:
- Moderne Implementierungen SOLLTEN sicherere ISN-Generierungsalgorithmen verwenden (SHOULD) (RFC 6528)
- Sequenznummernvorhersageangriffe verhindern
Zusammenfassung der Kernkonzepte
TCP-Header-Struktur
- Fester 20-Byte-Header: Enthält alle Kernfelder
- Optionen variabler Länge: Bis zu 40 Bytes
- Prüfsumme deckt Pseudo-Header ab: Bietet zusätzliche Fehlererkennung
Sequenznummernmechanismus
- Pro-Byte-Nummerierung: Jedes Daten-Byte hat eine eindeutige Sequenznummer
- Kumulative Bestätigung: Bestätigungsnummer zeigt an, dass alle Bytes darunter empfangen wurden
- Modulo-2³²-Arithmetik: Sequenznummernraum ist zyklisch
Verbindungszustände
- 11 Zustände: Von CLOSED zu ESTABLISHED und zurück zu CLOSED
- Ereignisgesteuert: Benutzeraufrufe, Segmentankünfte, Zeitüberschreitungen lösen Zustandsübergänge aus
- Dreiwege-Handshake: SYN → SYN-ACK → ACK
- Vierwege-Schließen: FIN → ACK → FIN → ACK
TCB-Variablen
- Sendevariablen: SND.UNA, SND.NXT, SND.WND usw.
- Empfangsvariablen: RCV.NXT, RCV.WND usw.
- Fensterverwaltung: Kern der Flusskontrolle
Nächster Abschnitt: 3.4-3.9 Connection Management & Event Processing (Verbindungsverwaltung und Ereignisverarbeitung) - Detaillierte Spezifikationen für Verbindungsaufbau, Schließen, Datenkommunikation und Ereignisverarbeitung