Projektarbeit ” Transmission Control Protocol“

Institut für Informatik
Lehrstuhl für Rechnerorganisation und -kommunikation
bei Dr. Sommer
Spezielle Techniken der Rechnerkommunikation
Projektarbeit Transmission Control
”
Protocol“
Eine Ausarbeitung von
Alexander Keller und Maik Burandt
- 13. Juni 2007 1
Inhaltsverzeichnis
1 Einleitung
1.1 TCP-Stack-Manipulation . . . . . . . . . . . . . . . . . . . . . .
1.1.1 TCP-Stack unter Linux . . . . . . . . . . . . . . . . . . .
1.1.2 TCP-Stack unter Windows . . . . . . . . . . . . . . . . .
4
4
4
5
2 Allgemeines
2.1 Vergleich: TCP/IP-Stack vs. OSI-Stack . . . . . . . . . . . . . .
7
7
3 Der TCP-Frame
10
3.1 TCP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 TCP-Pseudo-Header . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Verbindungen
15
4.1 Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Verbindungsabbau . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Interne Stellgrößen
5.1 Windowsize . . . . . . . .
5.1.1 Manipulation unter
5.1.2 Manipulation unter
5.2 Retransmission Timer . .
5.2.1 Manipulation unter
5.2.2 Manipulation unter
5.3 Keep-Alive Timer . . . . .
5.3.1 Manipulation unter
5.3.2 Manipulation unter
5.4 Persistence Timer . . . . .
. . . . . .
Linux . .
Windows
. . . . . .
Linux . .
Windows
. . . . . .
Linux . .
Windows
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
21
21
22
23
24
24
24
25
25
6 TCP-Algorithmen
27
6.1 Sliding Window-Algorithmus . . . . . . . . . . . . . . . . . . . . 27
6.2 Slow-Start Algorithmus . . . . . . . . . . . . . . . . . . . . . . . 30
6.3 Nagle-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . 31
A Tools
33
A.1 EditTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.1.1 Über das Programm . . . . . . . . . . . . . . . . . . . . 33
A.1.2 Das Hauptfenster . . . . . . . . . . . . . . . . . . . . . . 34
2
A.1.3 Allgemeine Optionen . .
A.1.4 TCP/IP-Einstellungen .
A.1.5 Ändern der Registry . .
A.1.6 Aufbau einer Verbindung
A.2 Wireshark . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
38
39
39
41
B technische Referenz
44
B.1 sonstige Parameter unter Linux . . . . . . . . . . . . . . . . . . 44
B.2 Parameter unter Windows . . . . . . . . . . . . . . . . . . . . . 46
3
1 Einleitung
Im Folgenden werden wir das Transmission Control Protocol (kurz: TCP) der
Transportschicht im TCP/IP Stack beleuchten und insbesondere auf Manipulationsmöglichkeiten unter den Betriebssystemen Windows XP und Linux
(Debian Knoppix 4.0 und Suse 10.2) eingehen.
Wir werden grundlegende Funktionsweisen klären (Verbindungsauf- und abbau und Datenübertragung), auf technische Details eingehen (z.B. Paketaufbau, Timer und deren Berechnung) sowie Algorithmen, die in Verbindung mit
dem TCP-Protokoll auftreten, erläutern.
Unser grundsätzliches Vorgehen orientiert sich an der Klärung theoretischer
Grundlagen eines bestimmten Aspektes mit anschließender praktischer exemplarischer Darlegung, sofern dies für uns möglich ist.
Im Anhang befindet sich zudem eine Referenz, die manipulierbare Parameter
unter Linux und Windows genauer beschreibt.
1.1 TCP-Stack-Manipulation
1.1.1 TCP-Stack unter Linux
Der Vorteil am Linux-Betriebssystem ist, dass Änderungen am TCP-Stack
dynamisch, d.h. zur Laufzeit durchführbar sind. Der Zustand wird in Variablen vermerkt, die sich alle in dem gleichen Verzeichnis befinden (/proc/sys/net/ipv4). Werte von Variablen können behandelt werden wie Dateien und
demnach zum Beispiel mit cat“ oder more“ angezeigt werden.
”
”
Nachteil ist, dass eventuelle Änderungen nach einem Neustart des Systems
verloren gehen und so Skripte erzeugt werden müssen, die bei jedem Start die
Werte ändern, wenn man diese dauerhaft erhalten möchte.
Es gibt zwei Möglichkeiten eine Variablenänderung zu bewirken.1
• Benutzung des echo“ Befehls und Schreiben in die Variable durch Um”
lenkung des Ausgabestroms, z.B.
1
4
in beiden Fällen sind Root-Rechte nötig
$echo "5" > /proc/sys/net/ipv4/tcp_retries1
• Benutzung des Befehls sysctl“ .
”
Mit der Option -a werden alle Werte aller Variablen angezeigt 2 . Geändert
wird ein Wert über die Option -w, wobei zu beachten ist, dass das Wurzelverzeichnis von sysctl“ /proc/sys/ ist. Beispiel:
”
sysctl -w net/ipv4/tcp_retries1=5
(äquivalent zu sysctl -w net.ipv4.tcp_retries=5)
1.1.2 TCP-Stack unter Windows
Windows erlaubt leider keine dynamische Änderung von TCP-Werten. Nach
einer Änderung muss das System neu gestartet werden, dafür bleiben die Änderungen jedoch dauerhaft erhalten. Die Werte stehen in der Windows-Registry
unter dem Schlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Hier befinden sich allgemeine Parameter. Spezielle Parameter sind unter weiteren Subschlüsseln zu finden. Windows erlaubt eine Unterscheidung der verwendeten Netzwerkadapter, die allerdings in der Registry nicht namentlich im
Klartext aufgeführt werden, sondern durch eine ID gekennzeichnet sind. Diese
ID muss vor beabsichtigten Manipulationen in Erfahrung gebracht werden, z.B.
durch Suchen in der Registy unter:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\
Die Registrierung wird mit dem Programm regedit.exe“ bearbeitet, welches
”
unter C:\Windows\ zu finden ist. Es ist zu beachten, dass viele der änderbaren
Parameter nicht standardmäßig in der Registrierung eingetragen sind. Sind die
Schlüssel nicht vorhanden, werden vom Betriebssystem die in den Treibern implementierten Standardwerte genutzt. Möchte man nicht vorhandene Schlüssel
ändern, hilft nur die Konsultation der Dokumentation (www.microsoft.com)
2
Werte anderer Protokolle wie IPv4 oder IPv6 werden ebenfalls angezeigt
5
um die richtigen Registrierungspfade zu ermitteln. Auch muss der richtige Datentyp des Parameters eingestellt werden. Dies ist ebenfalls der Dokumentation
zu entnehmen und ist meist D WORD“ .
”
An dieser Stelle sei auf den Anhang B verwiesen (Anhang B.2, Seite 46). Eine
weitere Möglichkeit zur Manipulation des TCP/IP-Stacks ist das von uns geschriebene Tool EditTCP“, auf welches später noch genauer eingegangen wird
”
(Kapitel A.1, Seite 33).
Für aktuelle Systeme (Windows-Vista, Windows Server Longhorn) wurde
der TCP/IP-Stack neu implementiert, es entstand der Next-GenereationTCP/IP-Stack. Hier ist eine dynamische Änderung der Einstellungen
möglich. [3]
6
2 Allgemeines
Das Transmission Control Protocol (TCP) hat sich über die Zeit hinweg zu
einem der wichtigsten Transportprotokolle in Computernetzwerken entwickelt.
Es ist verbindungsorientiert und vor allem zuverlässig und bildet als Teil der
Internetprotokollfamilie eine Grundlage für das sogennante Internet“ [6].
”
Der Grundstein für TCP wurde im Rahmen der Erforschung von zuverlässigen
und vor allem robusten Rechnernetzwerken 1973 von Robert E. Kahn und Vinton G. Cerf gelegt. Hintergrund hierfür war das große Interesse des Militärs zu
Zeiten des Kalten Krieges“ an Computernetzwerken, die auch nach einem
”
Atomschlag weiter funktionieren würden. Aber auch die Verbindung von verschiedenen Netzen war ein wichtiges Kriterium. Die Entwicklung und Standardisierung des TCP-Protokolls dauerte schließlich bis 1981. Es ging das erste
Request for Comments (RFC) mit der Nummer 793 hervor. Dort enthalten
sind die technischen Details zum TCP-Protokoll (Paket-Aufbau, spezielle Algorithmen, Zusammenarbeit mit anderen Protokollen...) [1]. Im Laufe der Zeit
kamen einige Neuerungen hinzu, die schließlich 1992 im RFC 1323 standadisiert
wurden [11].
Aufgrund der frühen Standardisierung und der besonderen Eigenschaften
von TCP (sichere Datenübertragung, Bidirektionalität, Überlaststeuerung...)
ist dieses Protkoll sehr weit verbreitet und aus der Welt der Computernetzwerke
nicht mehr wegzudenken.
2.1 Vergleich: TCP/IP-Stack vs. OSI-Stack
Das wichtigste theoretische Modell eines Netzwerkstacks ist das 1983 standardisierte OSI-Schichtenmodell (ISO 7498-1), wobei OSI für Open Systems
”
Interconnection“ steht [2]. Es ist ein Referenzmodell zur Beschreibung herstellerunabhängiger Kommunikationssysteme und dient diesen als Grundlage. Das
OSI-Modell spezifiziert sieben Schichten, die vertikal angeordnet sind, wobei
höhere Schichten die Dienste der direkt darunterliegenden Schicht nutzen. Die
Funktion und Aufgabe jeder Schicht ist exakt definiert. Trotz oder gerade wegen seines klaren, aber strengen Schichtenmodelles gibt es in der Realität kaum
1:1-Implementationen des OSI-Referenzmodelles [4].
7
Dem gegenüber steht das TCP/IP-Referenzmodell, welches bereits 1981 standardisiert wurde. Es wurde also unabhängig vom OSI-Modell entwickelt und
hat sich als Quasi-Standard für die Netzwerkkomunikation durchgesetzt. Das
TCP/IP-Modell besteht lediglich aus vier Schichten, die ebenfalls vertikal angeordnet sind. Abbildung 1 zeigt eine Gegenüberstellung der Schichten der beiden
Modelle.
Abbildung 1: OSI-Stack vs. TCP/IP-Stack
Anders als beim OSI-Modell ist es beim TCP/IP-Modell möglich, dass eine
Schicht unter Umgehung zwischenliegender Schichten von einer oberen Schicht
genutzt wird. Dadurch arbeitet das TCP/IP-Protkoll deutlich effizienter, was
ein Grund für dessen große Verbreitung ist. Weiterhin ist auch die genaue
Funktion der einzelnen TCP/IP-Schichten nicht exakt vorgeschrieben. Hier ein
kurzer Überblick über die vier Schichten des TCP/IP-Referenzmodelles:
8
Anwendungsschicht (OSI-Schicht 5 + 6 + 7):
Diese Schicht umfasst sämtliche Protokolle, die von Anwendungsprogrammen genutzt werden.
Transportschicht (OSI-Schicht 4):
Die Transportschicht stellt eine Ende-zu-Ende-Verbiundung her. Auf dieser Ebene ist TCP angesiedelt.
Internetschicht (OSI-Schicht 3):
Diese Schicht ist für das Routing und die Weiterleitung von Paketen verantwortlich. Auf dieser Ebene ist IP angesiedelt.
Netzwerkzugang (OSI-Schicht 1 + 2):
Diese Schicht enthält kein vorgeschriebenes Protokoll und wird entsprechend der Netztechnik gefüllt. In der Praxis ist hier oft Ethernet anzutreffen.
Man kann also sagen, dass das OSI-Modell ein sehr sauberes, gut strukturiertes und durchdachtes Modell ist, welches jedoch häufig nur für theoretische
Überlegungen herangezogen wird. Das TCP/IP-Modell ist dagegen quick and
”
dirty“ entstanden, um den alltäglichen Bedürfnissen gerecht zu werden. OSI
”
ist Ordnung, die niemand will und TCP/IP ist Chaos, das funktioniert!“ ist
ein humorvoll klingender Satz mit wahrem Hintergrund.
9
3 Der TCP-Frame
Ein TCP-Frame besteht aus zwei Teilen, dem sogenannten TCP-Header und
den Nutzdaten, auch Payload genannt. Der TCP-Header enthält wichtige Informationen über das TCP-Frame (Abbildung 2). Im Allgemeinen ist der TCPHeader 20 Byte groß. Diese Angabe kann jedoch aufgrund enventuell vorhandener Optionen in 4-Byte Schritten nach oben variieren.
3.1 TCP-Header
Es soll hier nun kurz der Aufbau dieses Headers und die Bedeutung der einzelnen Segmente gezeigt werden. die angesprochenen Flags (URG, ACK...) sind
gesetzt, wenn ihr Wert 1‘ ist.
’
10
Abbildung 2: Der TCP-Header
Source-Port (Bit 1 - 16)
Dieser Eintrag im TCP-Header enthält die Portnummer des sendenden
Rechners. Jede Portnummer kann auf einem Rechner nur einmal vergeben werden. Somit ist gewährleistet, dass die IP und die Portnummer
eindeutig einen Verbindungsendpunkt eines Computers beschreiben.
Destination-Port (Bit 17-32):
Der Destination-Port ist die Portnummer des empfangenden Rechners,
also der Ziel-Port.
Sequence-Number (Bit 33 - 64):
Die Sequenznummer ist für den Empfänger wichtig, damit er die unter
Umständen in falscher Reihenfolge empfangenen Pakete sortieren kann.
Im Gegensatz zu vielen anderen Protokollen werden bei TCP die einzelnen Bytes des Datenstroms nummeriert und nicht die einzelnen Pakete.
Wichtig ist auch, dass eine Sequenznummer immer eindeutig einer Ver-
11
bindung zugeordnet werden kann, damit Pakete nicht falsch interpretiert
werden. Hierfür gibt es verschiedene Ansätze wie zum Beispiel Abspeichern der zuletzt verwendeten Nummern oder Orientierung an einem Zeitgeber, auf die hier aber nicht näher eingegangen werden soll.
Acknowledgement-Number (Bit 65 - 96):
Mit der Bestätigungsnummer gibt der Empfänger die Sequenznummer
des von ihm als nächsten erwarteten Bytes an. Gleichzeitig wird damit
der Empfang aller Pakete bis zu dieser Sequenznummer - 1 signalisiert.
Voraussetzung für die Bestätigungsnummer ist das gesetzte ACK-Flag.
Data-Offset (Bit 97 - 100)
Das Data-Offset gibt die Position im Paket an, an der die Nutzdaten
beginnen. Diese Zahl ist ein vielfaches von 32 (Bit) und ist nötig, da die
Länge der Optionen variieren kann. Mindestens steht hier jedoch 5‘, was
’
bedeutet, dass der Header 20 Byte lang ist und es somit keine Optionen
gibt.
reserved (Bit 101 - 106)
Diese Bits werden nicht verwendet und müssen Null sein.
URG (Bit 107)
Das Dringlichkeits-Bit signalisiert, ob der Urgent-Pointer (s.u.) ausgewertet werden soll, was bedeutet, ob ein Teil der Daten prioritär behandelt
werden soll. Ist dieses Bit gesetzt, so unterbricht die Anwendung die Abarbeitung des aktuellen TCP-Segementes und verarbeitet zunächst die
dringlichen Daten.
ACK (Bit 108)
Ist dieses Bit gesetzt, so ist die Acknowledgement-Number gültig und es
wird der Empfang von TCP-Segmenten bestätigt. Ist zusätzlich auch das
SYN-Flag gesetzt, so dient dieses Bit zur Bestätigung beim Drei-Wege”
Handshake“. Das Flag ist bei fast allen Übertragungen gesetzt.
PSH (Bit 109)
Das Setzen des Push-Bits sorgt dafür, dass Daten nicht im Puffer des
Empfängers zwischengespeichert werden, sondern direkt an die Anwendung gegeben werden. Somit wird eine Verzögerung der eventuell zeitkritischen Daten verhindert. Der Nagle-Algorithmus (siehe Kapitel 6.3)
wird damit ausgehebelt.
12
RST (Bit 110)
Soll eine Verbindung abgebrochen werden, so ist das Reset-Bit gesetzt.
SYN (Bit 111)
Das SYN-Flag ist gesetzt bei der Synchronisation von Sequenznummern
beim Verbindungsaufbau. Ist es gesetzt, wird der Drei-Wege-Handshake“
”
(siehe Kapitel 4.1) gestartet.
FIN (Bit 112)
Gibt es keine Daten mehr zu senden, so wird die Verbindung abgebaut,
indem von beiden Seiten ein Paket mit gesetztem FIN-Bit gesendet wird.
Window-Size (Bit 113 - 128)
Damit der Empfangspuffer nicht überläuft, sendet der Empfänger hier
die maximale Anzahl an Bytes, die der Sender senden darf (siehe Kapitel
5.1).
Checksum (Bit 129 - 144)
Aus dem TCP-Header, dem TCP-Pseudo-Header (siehe Kapitel 3.2) und
den Daten wird eine Prüfsumme errechnet. Dies soll für eine bessere Zuverlässigkeit (Erkennung von Fehlern) dienen.
Urgent-Pointer (Bit 145 - 160)
Der Dringlichkeits-Zeiger gibt an, wo in dem Datenstrom die dringlichen
Daten anfangen. Er ist nur gültig, wenn das URG-Flag gesetzt ist.
Options (Bit 161 - (160 + n * 32))
Zusätzliche Optionen können hiermit ausgehandelt werden. Die Länge des
Optionen-Feldes muss ein Vielfaches von 32 sein. Ist es kleiner, so wird es
mit Nullen auf diese Größe aufgefüllt. Dies nennt man Padding. Mögliche
Optionen sind beispielsweise, dass Erlauben eines Selective Acknowledge
oder das Window Scaling (siehe Kapitel 5.1).
3.2 TCP-Pseudo-Header
Der TCP-Pseudo-Header wird allein zur Sicherung der Datenintegrität und
zum Schutz vor fehlgeleiteten Segmenten genutzt.
13
Abbildung 3: Der TCP-Pseudo-Header
Beim Sender wird vor Berechnung der Prüfsumme das Feld Checksum“ auf
”
Null gesetzt. Weiterhin wird die Byte-Länge des TCP-Segmentes überprüft.
Sollte sie ungerade sein, so wird den Nutzdaten ein Null-Byte hinzugefügt
(welches nicht übertragen wird) und der Pseudo-Header erzeugt (Abbildung
3). Anschließend werden die gesamten Daten in 16-Bit-Werte zerlegt, ins Einerkomplement überführt und dann addiert. Für diese Summe wird abermals
das Einerkomplement berechnet und dann schließlich als Checksumme im TCPHeader gespeichert. Der TCP-Pseudo-Header wird anschließend verworfen und
nicht übertragen!
Der Empfänger erstellt ebenfalls den Pseudoheader und addiert die 16-BitWerte, nur dass er das Checksum“-Feld nicht auf 0 setzt. Ist sein errechne”
tes Ergebnis FFFF (Hexadezimal), so wurden die Daten korrekt übertragen.
Andernfalls werden die Daten verworfen. Da die Bestätigung beim Sender ausbleibt, wiederholt dieser die Übertragung.
14
4 Verbindungen
4.1 Verbindungsaufbau
Der Verbindungsaufbau wird im TCP-Protokoll eher als eine Synchronisation
von Sender und Empfänger verstanden. Deswegen heißt das hierfür zugehörige
Flag auch SYN“ (siehe Kapitel 3). Das Protokoll benutzt einen sogenann”
ten Three-Way-Handshake“, durch den Datenverlust oder sogar duplizierte
”
Sitzungen vermieden werden können.
Abbildung 4: TCP-Verbindungsaufbau
Wie sich aus dem Namen schon ableiten lässt, besteht der Vorgang im Grunde
genommen aus drei Einzelschritten. Zunächst beginnt der Client(1) ein Paket
15
zu senden, in dem das SYN-Flag (3 und 6) gesetzt ist. Mit diesem schickt er eine
von ihm gewählte Startsequenznummer mit. Der Server(2) schickt seinerseits
eine Startsequenznummer, bestätigt gleichzeitig die Kenntnisnahme der Sequenznummer des Clients und setzt somit in seinem Paket das ACK-Flag und
das SYN-Flag(4). Zum Schluss sendet der Client nocheinmal eine Bestätigung
der Sequenznummer des Servers und kann in diesem Paket bereits die ersten
Daten einfügen(5).
Dieses System ist gegen alle Eventualitäten abgesichert:
• Das erste Paket des Clients geht verloren: Der normale RetransmissionTimer (siehe Kapitel 5.2) läuft ab und das Paket wird erneut gesendet.
• Die Antwort des Servers geht verloren: Der Client vermisst die Antwort
und nach Ablauf des Retransmission-Timers wird erneut gesendet.
• Die Bestätigung der Sequenznummer des Servers durch den Client geht
verloren: auch hier wird das Paket wegen ausbleibender Antwort neu gesendet.
• Ein verzögertes Connection Request vom Client erreicht den Server: der
Server weiß nicht, ob diese Anfrage eine Wiederholung oder tatsächlich
ein falsches Duplikat ist und sendet einfach seine Startsequenznummer
nocheinmal. Der Client erkennt den Fehler an der bereits zuvor einmal
empfangenen Sequenznummer und verwirft das Paket.
• Der Client erhält niemals eine Antwort: Nach endlichen Versuchen wird
der Verbindungsaufbau abgebrochen und an die Anwendungsschicht gemeldet.
4.2 Datenaustausch
Während des Datenaustausches werden zusätzlich zu den bereits beschriebenen
Mechanismen wie Sendewiederholung oder Duplikaterkennung Prinzipien wie
die Flusssteuerung (siehe Kapitel 5.1), Verwendung von Algorithmen (SlowStart (Kapitel 6.2) und Nagle-Algorithmus (Kapitel 6.3)) und weitere Timer
(Keep-Alive Timer (Kapitel 5.3) und Persistence Timer (Kapitel 5.4)) eingesetzt.
16
4.3 Verbindungsabbau
Beim Verbindungsabbau wird durch TCP die verlustlose Datenübertragung garantiert, indem auch hier ein Three-Way-Handshake“ verwendet wird, welches
”
Graceful Close“ genannt wird.
”
Zunächst sendet eine der beiden Seiten das Disconnection Request indem das
FIN-Flag (siehe Kapitel 3) gesetzt wird(1).3 Die andere Seite antwortet dann,
indem sie ebenfalls das FIN-Flag setzt und zusätzlich durch das ACK-Flag das
FIN-Flag des Verbindungspartners bestätigt(2). Zum Schluss wird durch ein
weiteres Paket des Verbindungsabbauinitierers, in dem das ACK-Flag gesetzt
ist, der Verbindungsabbau bestätigt und damit beendet(3).
Auch dieses Verfahren ist sehr sicher und funktioniert analog zu den Verfahren des Verbindungsaufbaus.
3
Im Beispiel ist hier auch das ACK-Flag gesetzt, was in diesem Fall aber lediglich das zuletzt
gesendete Datenpaket bestätigt und hier nur aus Effizienzgründen zusammen mit dem
FIN-Flag gesendet wird.
17
Abbildung 5: TCP-Verbindungsabbau
18
5 Interne Stellgrößen
5.1 Windowsize
Für jede TCP-Verbindung steht ein festgelegter maximaler Speicherbereich für
die empfangenen Pakete zur Verfügung, wobei die tatsächliche Größe des Fensters variabel ist. Die aktuelle Größe wird durch die sogenannte Windowsize
festgelegt, welche immer kleiner als die maximale Windowsize ist [1][11]. Die
Windowsize ist für den Sender der Sendekredit. Sie beschreibt also, wieviele Bytes der Sender schicken darf, bis er spätestens auf eine Antwort warten
muss. Der Empfänger teilt seine Windowsize mit jedem Acknowledgement dem
Sender mit, wobei die Größe davon abhängt, wieviel Speicher seines Empfangsfensters bereits belegt ist (siehe Abbildung 6) und natürlich wie groß das Fenster
maximal ist.
Abbildung 6: Windowsize und maximale Paketgröße ohne Header (MSS)
Der Algorithmus für die Kontrolle des Datenflusses wird Sliding Window“
”
genannt und wird in Kapitel 6.1 auf Seite 27 genauer erläutert.
19
Window Scaling
Die Größe der maximalen Windowsize ist durch die Struktur des TCP-Header
auf 65535 Bytes begrenzt (siehe Kapitel 3.1). In Netzwerken mit einer höheren
Round-Trip-Time und hoher Bandbreite kann der effektive Datendurchsatz
durch eine größere Windowsize verbessert werden [5]. Damit die Fenstergröße
mehr als 65535 Bytes groß sein kann, wurde die Option TCP Window Sca”
le Option (WSopt)“ eingeführt [11]. Es kann nun festgelegt werden ob und
mit welchem Multiplikator (Saklierungsfaktor) Window Scaling genutzt wird.
Der Skalierungsfaktor ist die angegebene Zahl als Exponent zur Basis zwei.
Dies kann im Stack als Shift-Operation ausgeführt werden und wird deshalb in
dem RFC1323 als shift.cnt“ bezeichnet. Damit Window Scaling auch wirklich
”
eingesetzt wird, müssen beide Kommunikationspartner diese Option aktiviert
haben!
Abbildung 7: Windowsize mit Scaling-Option
Die tatsächliche Windowsize wird nun aus dem Produkt der angegebenen
Windowsize eines jeden Paketes und dem im SYN-Paket mitgeteilten Skalierungsfaktor berechnet [11]. In Abbildung 7 ist ein SYN-Paket mit angegebener
Windowsize und Window Scaling Optionen zu sehen. Die tatsächliche Windowsize beträgt vor der Rundung dort 2097152 statt 8192 Byte. Wird die Win-
20
dowsize auf einen Wert über 65535 Bytes gesetzt, so wird der Skalierungsfaktor
nach Rundung automatisch berechnet und mit entsprechender Windowsize im
TCP-Header gesendet.
5.1.1 Manipulation unter Linux
Eine gewünschte Windowsize genau einzustellen ist sehr umständlich unter
Linux. Zunächst ist wichtig zu wissen, dass erstellten Sockets Speicherplatz zugewiesen wird. Dieser Speicherplatz teilt sich in Speicher für die Anwendung
und Speicher für das Fenster.
Mit drei Variablen lässt sich die Windowsize einstellen: tcp_adv_win_scale,
mit der das Verhältnis von Anwendungs- zu Fensterspeicher definiert wird,
tcp_app_win, die die Größe des Anwendungsspeichers auf eine andere Art definiert und tcp_rmem, mit der die Größe des gesamten Empfangspuffers geregelt
wird.
Für genauere Erklärungen siehe Anhang B.1.
5.1.2 Manipulation unter Windows
Für die maximale Größe der Windowsize sind die Werte TcpWindowSize und
GlobalMaxTcpWindowSize verantwortlich. Hier wird die gewünschte Zahl eingetragen, wobei TcpWindowSize für jeden Netzwerkadapter anders sein kann
und maximal gleich GlobalMaxTcpWindowSize sein darf. Die angegebene Windowsize wird beim zweiten Paket automatisch entprechend der genutzten Netzwerktechnologie geändert. Sie wird auf das nächste Vielfache der Maximum
Segment Size (MSS) gerundet. So wird im Ethernet der Wert von 8192 auf
8760 gesetzt (Standard). Um die Option Window Scaling zu aktivieren, muss
der Wert Tcp1323Opts auf 1 oder 3 gesetzt werden (wobei 3 auch Timestamps
aktiviert). Abbildung 7 zeigt ein SYN-Paket ohneWindow Scaling und einer
Windowsize von 17520. Abbildung 6 zeigt ein SYN-Paket mit Window Scaling
und einer Windowsize von 8192 * 256 = 2097152 (was aber noch gerundet
wird).
21
5.2 Retransmission Timer
Der Retransmission Timer ist der wahrscheinlich wichtigste Timer im TCPProtokoll. Er gibt an, nach welcher Zeitspanne ein nicht bestätigtes Paket neu
gesendet werden soll. Die Dauer richtet sich nach bereits erfolgten Misserfolgen
für das spezifische Paket und liegt einem Algorithmus zu Grunde, der meist die
Round-Trip-Time vergangener Pakete, also die Zeit die vom Absenden eines
Paketes bis zum Empfangen der Bestätigung vergangen ist, mit in die Berechnung einbezieht. Es gibt verschiedene Ansätze den Retransmission-Timer zu
berechnen.
Abbildung 8: Retransmission Timeout in einer Linux Implementation von TCP
1. rekursiv über einen gewichteten Mittelwert der Round-Trip-Time: Dieser
Algorithmus wird in der dem TCP Protokoll zugrundeliegenden RFC 793
beschrieben und gliedert sich in zwei Teilgleichungen (1981).
RTTest = a * RTTest + (1 - a) * RTTsamp
mit RTTest = geschätzte Round-Trip-Time, RTTsamp = Round-Trip-Time des letzten Paketes, a = Gewichtungsfaktor (0.8 - 0.9)
Retransmission Time = b * RTTest
mit b = 1,3 - 2,0
2. abhängig von der Standardabweichung D der eintreffenden Acknowledges
(Jacobson 1988)
D = a * D + (1 - a) * abs(RTTest - RTTsamp )
22
3. unabhängig von RTT und Acknowledges, nach immer gleichem Schema
(Karn 1987)
Dass einem ankommenden Acknowledge unter Umständen ein zuvor erfolgtes Neusenden des Paketes vorausgeht, weil der Retransmission Timer
kurz zuvor abgelaufen ist, ist der Nachteil bei Algorithmen, die von der
Round-Trip-Time abhängig sind. Die neue Round-Trip Time wird nun
falsch berechnet, da bei einem Acknowledge nicht unterschieden werden
kann, zu welchem Paket es ursprünglich gehörte.
Abbildung 9: Retransmission Timeout begrenzt auf 4 Wiederholungen
Abhilfe schafft hier der Karn-Algorithmus, der von einer initialen Zeit für
den ersten Paketverlust ausgeht, und dann bei jedem weiteren Verlust diese Zeit einfach verdoppelt. Dies ist auch die bei unserer Implementation
vorherrschende Vorgehensweise (siehe Abbildung 8).
5.2.1 Manipulation unter Linux
Unter Linux ist es möglich, die Anzahl der Wiederholungsversuche zu
beeinflussen. Dies geschieht über die Variable tcp_retries2. Im Beispiel
wurde so die Wiederholungsanzahl auf vier begrenzt (Abbildung 9).
Dies regelt allerdings nur das Wiederholen von Datenpaketen. Zur Steuerung der Anzahl von Verbindungsaufbauversuchen wird dagegen die Variable tcp_syn_retries verwendet. Ebenfalls beeinflusst werden kann
wie oft auf eine eingehende SYN-Anforderung reagiert werden soll, und
zwar mit der Veriable tcp_synack_retries.
23
5.2.2 Manipulation unter Windows
Bei Windows ist der Timer initial auf drei Sekunden gestellt und wird danach automatisch entsprechend der Situation des Netzwerkes angepasst.
Es ist möglich die Anzahl der Wiederholungsversuche zu ändern. Der Parameter TcpMaxConnectRetransmissions gibt dabei die maximale Anzahl an Versuchen für eine Verbindungsanforderung (SYN) an. Ist diese
überschritten, werden die Versuche abgebrochen.
TcpMaxDataRetransmissions regelt hingegen die Sendewiederholungsversuche von Datenpaketen.
5.3 Keep-Alive Timer
Der Keep-Alive Timer wird verwendet, um bei einer bestehenden Verbindung
über die eine gewissen Zeit keine Daten mehr gesendet wurden, ein Test-Paket
abzuschicken, dass zeigen soll, ob der Kommunikationspartner überhaupt noch
erreichbar ist. Falls nicht, wird nach einer gewissen Anzahl von Versuchen die
Verbindung geschlossen. Standardmäßig wird nach zwei Stunden mit dem Versenden von TCP-Keep-Alives begonnen. Dies wird dann alle 75 Sekunden wiederholt (siehe Abbildung 10).
Abbildung 10: Keep-Alive Timeout mit 75 sekündiger Wiederholrate
5.3.1 Manipulation unter Linux
Unter Linux kann man hier sehr flexibel agieren. Mit tcp_keepalive_time
kann bestimmt werden, wann mit dem Versenden von Keep-Alives begonnen
werden soll.
Mit tcp_keepalive_intvl wird die darauf folgende Wiederholrate eingestellt
und mit tcp_keepalive_probes schließlich die Anzahl der Versuche bei NichtAntwort. In unserem Beispiel sind tcp keepalive time = 1 und tcp keepalive probes
= 5 (siehe Abbildung 11).
24
Abbildung 11: Retransmission Timeout mit 5 sekündiger Wiederholrate
5.3.2 Manipulation unter Windows
Unter Windows gibt es zwei Parameter, die für die Keep-Alive-Einstellungen
zuständig sind. Das sind KeepAliveInterval und KeepAliveTime. Der erste
Parameter gibt das Zeitintervall zwischen zwei Keep-Alive-Paketen in Millisekunden an. KeepAliveTime hingegen gibt die Zeit in Millisekunden an, die bei
einer Verbindung im Leerlauf vergeht, bis das erste Keep-Alive-Paket gesendet
wird. Leider konnten wir die Auswirkungen nicht beobachten.
5.4 Persistence Timer
Der Persistence-Timer wird gestartet, sobald ein Kommunikationspartner die
Window-Size des Receiver-Windows auf 0 setzt (siehe Kapitel 5.1). Er soll sicherstellen, dass falls das Paket, dass das Fenster wieder öffnet, verloren geht,
die Kommunikation nicht zum Stillstand kommt. Sollte er ablaufen, so wird
ein Paket mit einer ungültigen Acknowledge-Nummer gesendet, worauf der
Empfänger mit der richtigen Nummer antwortet und nebenläufig die aktuelle Window-Size mitsendet.
Unter Windows wie auch unter Linux ist es uns leider nicht möglich gewesen,
diesen Timer zu verändern. Man kann allerdings beobachten, dass er, zumindest
bei unserem Versuch, serverseitig fast genauso wie der Retransmission Timer
(siehe Kapitel 5.2) berechnet wird (bei kleinerem maximalen Timeout) und als
ungültige Acknowledge-Nummer einfach die erste der Kommunikation gesendet
wird ( 0‘ - siehe Abbildung 12).
’
25
Abbildung 12: Der Persistence-Timer beim TCP
26
6 TCP-Algorithmen
6.1 Sliding Window-Algorithmus
Der Sliding Window-Algorithmus ist ein Datenfluss-Algorithmus. Der Empfänger
steuert damit den Datenfluss, welcher vom Sender stammt (Windowscaling/Windowsize siehe Kapitel 5.1). Der Sender weiß so immer, wieviele Daten er noch
senden kann, bevor der Empfänger diese nicht mehr annimmt. Außerdem muss
der Sender nun nicht mehr auf eine Bestätigung jedes einzelnen Bytes warten, bevor weitere Bytes gesendet werden, was bei großen Umlaufzeiten sehr
negative Auswirkungen auf die Effizienz hätte.
Abbildung 13: Sliding Window: Start (Senden Byte 1 und 2)
Der Sender kann soviele Daten senden, wie er Sendekredit durch den Empfänger
in einem vorherigen ACK-Paket bekommen hat. Der Empfänger kann jedoch
trotzdem jedes einzelne Byte bestätigen, bevor das Empfangsfenster voll ist.
Abbildung 13 zeigt den Initialzustand. Der Sender schickt nun maximal zwei
Bytes mit den Nummern 1 und 2 bevor er auf eine Bestätigung warten muss.
Hat der Empfänger die Daten erhalten und wurden die Sequenznummern noch
nicht empfangen, so setzt er sein Fenster weiter und sendet eine Bestätigung
für die erhaltenen Sequenznummern und wartet auf neue Daten (Abbildung
14). Hierbei teilt der Empfänger der Gegenseite auch wieder einen Sendekredit
mit, der hier jedoch wieder 2‘ ist. Es wurden also alle Bytes verarbeitet. Der
’
Empfänger könnte hier auch nach Erhalt und Verarbeitung des ersten Bytes
das Fenster um eins weiter schieben und so den neuen Sendekredit lediglich auf
1‘ setzen.
’
27
Abbildung 14: Sliding Window: Empfang von Byte 1 und 2
Hat der Sender die Bestätigungen für die Daten erhalten, so setzt er sein
Fenster entsprechend seinem Sendekredit weiter (hier wieder 2‘) und sendet
’
die neuen Daten. Sind jedoch die Bestätigungen für die Bytes verloren gegangen, so schickt der Sender die Daten nach Timer-Ablauf erneut. Der Empfänger
hat jedoch sein Fenster schon verschoben und erkennt die Sequenznummern
als alt. Der Empfänger bestätigt diese erneut (in der Hoffnung, dass die Acknowledgments nun den Sender erreichen). Die Verlustsituation der Daten vom
Sender zum Empfänger wurde hier nicht weiter berücksichtigt, da dies bereits
im Kapitel 5.2 geschehen ist.
Abbildung 15: Sliding Window: Acknowledgment Byte 1 und 2
Ein Problem, welches beim Sliding Window-Algorithmus auftreten kann, ist
das sogenannte Silly Window-Syndrom“. Dieses tritt auf, wenn auf Empfangs”
seite der Speicher voll ist, weil die Anwendung mit der Verarbeitung nicht
28
nachkommt. Der Empfänger teilt dem Sender einen Kredit von 0‘ mit, ein so’
genanntes Zero Window“ (siehe Abbildung 16). Dort ist das Empfangsfenster
”
vollgelaufen.
Abbildung 16: Zero Window
Verarbeitet die Anwendung nun nur sehr wenige Bytes und würde der Sendekredit für den Sender dementsprechend angepasst, so würde dieser nur sehr
wenige Daten verpackt in einem großen Paket (mit Header etc.) verschicken
(siehe Abbildung 17). Dies stellt natürlich einen sehr großen Overhead dar. Ist
dann das Fenster wieder voll, dann wird erneut ein Zero Window geschickt.
Eine Wiederholung dieses Ablaufes mindert natürlich die Effizienz. Um dies zu
verhindern, wartet der Empfänger mindestens so lange mit dem Senden einer
neuen Window Size, bis mindestens die MSS im Speicher frei ist [6].
29
Abbildung 17: Silly Window-Syndrom
6.2 Slow-Start Algorithmus
Der Slow-Start Algorithmus dient dazu weder den Empfänger noch das Netzwerk zu überlasten, wenn noch nicht sichergestellt werden kann, dass beide
Komponenten ausreichend funktionsfähig sind.
TCP verwaltet zusätzlich zum Receiver-Control Fenster (siehe Kapitel 6.1) ein
Sendefenster für den Slow-Start Algorithmus, welches durch ein Segment fester
Größe initialisiert wird. Das tatsächliche Sendefenster wird bestimmt durch das
kleinere dieser beiden. Wie der Name des Algorithmus schon andeutet, wird eine neu aufgebaute Verbindung nur langsam belastet.
Bei erfolgreichen Acknowledges des Kommunikationspartners wird die Fenstergröße solange verdoppelt, bis ein spezifischer Schwellwert erreicht wird, ab dem
es immer um einen festen Wert erhöht wird.
Sollte ein Acknowledge ausbleiben, also ein Retransmission-Timer zuschlagen, so beginnt der Algorithmus erneut mit der initialen Fenstergröße, wobei
allerdings der Schwellwert, der das Fensterwachstum von exponentiell auf linear umschaltet, auf die halbe aktuelle Fenstergröße gesetzt wird.
Dies führt allerdings dazu, dass lang anhaltende Verbindung pumpen“, d.h.
”
das Fenster wird linear erhöht bis die Belastung der Verbindung zu hoch wird,
das Fenster wird zurückgesetzt und dies beginnt von vorn.
Ein weiterer Nachteil dieses Algorithmus ist, dass er stets davon ausgeht, dass
eine ausbleibende Bestätigung auf eine Überlast des Netzwerkes zurückzuführen
ist, obwohl zum Beispiel auch Übertragungsfehler insbesondere in der drahtlosen Übertragung daran Schuld sein können und die Rücksetzung des Fensters
somit unnötig, ja sogar hinderlich ist.
30
6.3 Nagle-Algorithmus
Mit dem Nagle-Algorithmus wird die Netzlast vermindert. Er sorgt dafür, dass
Pakete mit zu kurzem Datenteil gesammelt werden, bevor sie dann zusammen
in einem einzigen Paket verschickt werden. Dieses Verfahren ist allerdings bedenklich, falls prioritäre Daten oder kurze Daten, die auf eine Reaktion warten,
versendet werden. In diesem Fall kann allerdings das Push-Flag“ gesetzt wer”
den (siehe Kapitel 3.1), welches den Nagle-Algorithmus aushebelt und dafür
sorgt, dass Daten direkt zur Anwendung hochgereicht werden.
In unserem Beispiel kann man den Nagle-Algorithmus durch einen Trick zweimal hintereinander angewendet sehen. Aus einer Virtual Machine mit Windows
XP heraus sendeten wir über das Programm EditTCP“ (siehe Anhang A.1)
”
Pakete der Länge 1‘ . In Abbildung 18 ist zu sehen, dass diese bereits innerhalb
’
der Virtual Machine zur Länge 2 zusammengefasst wurden.
Abbildung 18: der Nagle Algorithmus innerhalb der Virtual Machine
Im eigentlichen Betriebssystem (wieder Windows XP) werden diese Pakete der gleichen Verbindung nocheinmal deutlich zusammengefasst, wie in der
Abbildung 19 zu sehen ist.
31
Abbildung 19: der Nagle Algorithmus außerhalb der Virtual Machine
32
A Tools
A.1 EditTCP
A.1.1 Über das Programm
Wir haben dieses C++ - Programm entwickelt, um damit möglichst einfach und
schnell Parameter des TCP/IP-Stacks unter Windows (getestet unter WinXP
Prof. und Vista Home Premium) zu ändern. Es macht ein aufwändiges Suchen
und Editieren der Parameter der einzelnen Netzwerkadapter überflüssig. Weiterhin ist das Speichern der Einstellungen möglich. So können die Einstellungen
sehr bequem auf andere Computer übertragen werden.
Die Registry-Subschlüssel der einzelnen Parameter sind in einer extra Datei
(config.txt) gesichert, so dass es ohne weiteres möglich ist das Programm
auf andere Windows-Versionen zu portieren, bzw. falsche Pfadangaben und
Werttypen zu korrigieren.
Man kann mit diesem Programm auch Verbindungen aufbauen, um darüber
Daten zu übertragen. So ist es möglich die veränderten Einstellungen zu testen
und zum Beispiel mit Wireshark (siehe Kapitel A.2) zu analysieren. Hierfür
kann EditTCP sowohl als Server, als auch als Client fungieren.
Die Datenübertragung geschieht über die Socket-Funktionen accept, bind,
connect, listen, select, recv, send. Genaue Beschreibungen dieser Funktionen und deren Parameter sind leicht im Internet oder in der MSDN von
Microsoft [9] zu finden.
Im Folgenden soll kurz die Oberfläche des Programmes erklärt werden.
33
A.1.2 Das Hauptfenster
Abbildung 20: EditTCP - Das Hauptfenster - Server-Modus
34
Abbildung 21: EditTCP - Das Hauptfenster - Client-Modus
Nummer
1
2
3
4
5
5a
6
7
8
9
10
11
Beschreibung
zeigt die IP des Zielcomputers
zeigt den Port des Zielcomputers
zeigt Anzahl der aufzubauenden Verbindungen
der Status der Winsock
startet das Empfangen
baut die Verbindung(en) auf und startet das
Senden
beendet das Senden oder Empfangen (je nachdem, ob Client oder Server)
legt den Betriebsmodus des Programmes fest
ruft die Einstellungen des Programmes auf
startet den Computer neu (nach Änderungen
der Registry notwendig)
beendet das Programm
zeigt die Verbindungen und ihre Informationen
an
35
A.1.3 Allgemeine Optionen
Abbildung 22: EditTCP - Allgemeine Optionen
36
Nummer
1
2
3
4
5
6
7
8
9
10
11
Beschreibung
legt den Haupt-Registry-Pfad fest
wenn aktiviert, werden in einer Endlosschleife
zwischen 0 und der gewählten Obergrenze gesendet (Client-Modus)
wenn aktiviert, wird die ausgewählte Datei gesendet (Client-Modus)
legt die IP des Zielcomputers fest (ClientModus)
legt den Port des Zielcomputers fest (ClientModus)
legt die Anzahl der aufzubauenden Verbindungen fest (Client-Modus)
legt den zu überwachenden Port fest (ServerModus)
legt die Anzahl der zu überwachenden Verbindungen fest (Server-Modus)
lädt vorhandene Einstellungen
speichert die aktuellen Einstellungen
blendet die Optionen aus
37
A.1.4 TCP/IP-Einstellungen
Abbildung 23: EditTCP - TCP/IP-Einstellungen
Nummer
1
2
3
4
5
38
Beschreibung
Auswahl der vorhandenen Netzwerkadapter
Informationen zum gewählten Adapter
liest die Einstellungen des Adapters aus der Registry
schreibt die Einstellungen des Adapters in die
Registry
Parameter des TCP/IP-Stacks
A.1.5 Ändern der Registry
1. Um die Parameter des TCP/-IP-Stacks zu verändern, startet man EditTCP und klickt auf Einstellungen“. Es öffnet sich das Fenster mit den
”
Optionen.
2. Man wählt nun die Registerkarte TCP-Parameter“, um zu den TCP”
Parametern zu gelangen.
3. Als nächstes wählt man links oben den Netzwerkadapter, den man manipulieren möchten. Es werden nun rechts daneben Informationen zum
gewählten Adapter angezeigt.
4. Nun ist es möglich die Parameter zu ändern. Jedoch kann man auch erst
die aktuellen Parameter des Adapters auslesen, indem man auf Regis”
try auslesen“ klickt. Die Textfelder der Parameter werden entsprechend
gefüllt. Leere Textfelder bedeuten, dass die Schlüssel nicht vorhanden
sind und das System Standardeinstellungen benutzt (siehe 1.1.2, Seite
5). Sollten man diese Schlüssel anlegen, wird das System diese in Zukunft
nutzen.
5. Um die vorgenommenen Änderungen zu sichern, klickt man auf Registry
”
schreiben“. Man beachte unbedingt, dass EditTCP in dieser Version die
gemachten Einstellungen nicht überprüft! Man muss also selbst Sorge für
die korrekten Werte tragen! Genaueres ist im Anhang B ab Seite 46 zu
erfahren.
6. Damit die Einstellungen wirksam werden, klickt man auf Zurück“ und
”
im Hauptfenster auf Windows-Neustart“. Man beachte unbedingt, dass
”
man Daten vorher gespeichert hat, damit sie nicht verloren gehen!
A.1.6 Aufbau einer Verbindung
Für einen Datenaustausch ist es nötig zwei Instanzen von EditTCP zu starten.
Dies kann, muss aber nicht auf unterschiedlichen Computern passieren. Man
muss bei mehreren Computern sicherstellen, dass die IP-Adressen oder der
Hostnamen bekannt sind, da diese Angaben für den Client wichtig sind.
39
Es ist zu beachten, dass einige hier verwendete Socket-Funktionen blockierend sind! Auch wenn EditTCP vorläufig nicht reagiert, heißt dies nicht
zwangsläufig, dass es abgestürzt ist!
Server
1. Sofern man EditTCP gestartet hat, klicken man auf Einstellungen“, um
”
die Parameter für den Verbindungsaufbau festzulegen.
2. Hier findet man unter der Registerkarte Allgemein“ allgemeine Optio”
nen.
3. Hier gibt man unter Server-Modus an, welcher Port auf wieviele einge”
”
hende Verbindungen überwacht werden soll.
4. Nun klickt man auf Zurück“ und wählt im Hauptfenster rechts oben den
”
Modus Server“ aus.
”
5. Nun kann man den Empfang durch klicken auf Empfangen starten“ star”
ten.
6. Sollte kein Fehler auftreten, findet man die empfangenen Daten nach der
Übertragung durchnummeriert im Verzeichnis incomming“ im Anwen”
dungsverzeichnis von EditTCP.
7. Zum vorzeitigen beenden der Transmission klickt man auf Empfangen
”
beenden“. Tut man dies nicht, wird die Übertragung unendlich fortgeführt oder die Datei vollständig gesendet wurde (je nach Betriebsmodus).
Client
1. Sofern man EditTCP gestartet hat, klickt man auf Einstellungen“, um
”
die Parameter für den Verbindungsaufbau festzulegen.
2. Hier findet man unter der Registerkarte Allgemein“ allgemeine Optio”
nen.
3. Hier wählt man unter Daten zu senden“ aus, ob eine unendliche Anzahl
”
von Zahlen oder eine Datei gesendet werden soll.
40
4. Nun legt man unter Client-Modus“ den Zielcomputer fest, indem man
”
den Hostnamen oder die IP-Adresse in das dafür vorgesehene Textfeld
einträgt.
5. Nun man unter Client-Modus“ die Portnummer ein, über welche die
”
Programme kommunizieren sollen. Diese muss unbedingt im Server und
Client gleich sein!
6. Man legt nun unter Client-Modus“ noch fest, wieviele Verbindungen
”
aufgebaut werden sollen. Über alle Verbindungen werden die gleichen
Daten gesendet. Man findet diese nach der Übertragung durchnummeriert
im Verzeichnis incomming“ im Anwendungsverzeichnis des Servers.
”
7. Nun klickt man auf Zurück“ und wählet im Hauptfenster rechts oben
”
den Modus Client“ aus.
”
8. Durch klicken auf Verbindung aufbauen“ werden die Verbindungen zum
”
Server hergestellt.
9. Nun kann man die Übertragung durch klicken auf Senden starten“ star”
ten.
10. Zum vorzeitigen beenden der Transmission klickt man auf Senden be”
enden“. Tut man dies nicht, wird die Übertragung unendlich fortgeführt
oder die Datei vollständig gesendet wurde (je nach Betriebsmodus).
A.2 Wireshark
Wireshark (ehemals Ethereal ) ist wohl eines der bekanntesten und mächtigsten
Tools zur Netzwerkanalyse und soll an dieser Stelle kurz erläutert werden. Das
Programm ist Open-Source und kann hier heruntergeladen werden:
http://www.wireshark.org/
41
Abbildung 24: Wireshark
Wireshark umgeht mit Hilfe einer speziellen Bibliothek bzw. Treiber den
Protokoll-Stack und fängt den Netzwerkverkehr ab [7]. Je nach Betriebssystem ist es die libpcap“ (Linux) oder die WinPcap“ (Windows) Bibliothek,
”
”
die das zur Verfügung stellt. Es ist also möglich mit Wireshark die gesamte
Netzwerkkommunikation mitzuschneiden und zu analysieren. Man kann aus
allen empfangenen Paketen (siehe Abbildung 24, rot hinterlegt) ein einzelnes auswählen und dessen Details betrachten (siehe Abbildung 24, blau und
gelb hinterlegt), wobei Wireshark einmal versucht die Bytes selbst Protokollen
zuzuordnen und einmal alles Empfangene in hexadezimaler Schreibweise darstellt. Weiterhin bietet Wireshark eine Vielzahl von Optionen und Filtern, um
ganz gezielt nach Informationen zu suchen. Auch kann das Programm spezielle
Statistiken (Datendurchsatz...) erstellen. An dieser Stelle sei hiermit auf die
folgende Internetseite verwiesen:
http://www.nwlab.net/tutorials/ethereal/ethereal-tutorial.html
42
Dort findet man ein gutes deutschsprachiges Tutorial, welches den Einstieg
in Wireshark sehr erleichtert.
43
B technische Referenz
B.1 sonstige Parameter unter Linux
Die Beschreibung wurde teilweise von Oskar Andreasson übernommen [10].
1. tcp adv win scale
Wert:
ganze Zahl
Standardwert: 2
Beschreibung: Steuert das Verhältnis von Anwendungs- zu
TCP-Windowspeicher eines Sockets (Gleichung
für positive Werte: 2tcp adv 1win scale , für negative
Werte: 1 − 2−tcp adv1win scale , für 0: keine Reservierung).
2. tcp app win
Wert:
Standardwert:
Beschreibung:
3. tcp fin timeout
Wert:
Standardwert:
Beschreibung:
44
natürliche Zahl
31
Sagt dem Kernel wieviel Speicher für ein spezifisches TCP-Window verwendet werden soll
window
(Gleichung: 2tcp
app win , für 0: keine Reservierung).
natürliche Zahl
60 (Sekunden)
Gibt an wie lange auf ein FIN“ des Kommu”
nikationspartners gewartet werden soll, bis die
eigene Verbindung beendet wird.
4. tcp mem
Wert:
“natürliche Zahl natürliche Zahl natürliche
Zahl
”
Standardwert: keiner
Beschreibung: Gibt den Speicher in Speicherseiten (normalerweise 4kb) an, der dem TCP-Stack zur
Verfügung steht. Der 1.Wert gibt den Speicher
an, der auf jeden Fall zur Verfügung gestellt
werden soll, der 2. die Grenze, ab der versucht
werden soll Speicher durch Kompression zu sparen und der 3. die maximale Grenze.
5. tcp orphan retries
Wert:
natürliche Zahl
Standardwert: 7
Beschreibung: Definiert wie oft versucht werden soll an die Gegenseite ein FIN“ zu senden, bevor bei Misser”
folg die eigene Verbindung schließlich abgebaut
wird.
6. tcp rmem
Wert:
“natürliche Zahl natürliche Zahl natürliche
Zahl
”
Standardwert: keiner
Beschreibung: Setzt den Speicher in Byte für das Empfangsfenster wobei der 1. Wert das Minimum ist, der
2. der default (Startwert) und der 3. das Maximum.
7. tcp wmem
Wert:
“natürliche Zahl natürliche Zahl natürliche
Zahl
”
Standardwert: keiner
Beschreibung: Setzt den Speicher für das Sendefenster und
funktioniert ansonsten genauso wie tcp rmem.
45
B.2 Parameter unter Windows
Im Folgenden werden die veränderbaren TCP-Schlüssel der Windows XP-Registry
beschrieben [5]. Dabei wird jeweils kurz auf die Funktion bzw. Auswirkung des
Keys und seiner Parameter eingegangen. Weiterhin wird die genaue Position
angegeben.
Das Ändern der Registry-Werte kann unter Umständen zu Problemen
führen! Es wird daher dringend empfohlen ein Backup der Registry zu
erstellen, bevor etwas geändert wird. Weiterhin wird für die Richtigkeit
der folgenden Einstellungen keine Garantie übernommen. Es sei hiermit
auf die entsprechende Internetseite http://support.microsoft.com/kb/
314053/de von Microsoft verwiesen. Dort sind noch einige weitere Parameter zu finden (speziell IP-Parameter). Weiterhin gibt es viele TuningSeiten, die weitere Einstellungsmöglichkeiten aufzeigen, die nicht auf der
Microsoft-Seite zu finden sind (Bsp.: [8])!
1. DatabasePath
Schlüssel:
Werttyp:
Wert:
Standardwert:
Beschreibung:
Tcpip\Parameters
Zeichenfolge (REG EXPAND SZ)
gültiger Windows NT-Dateipfad
%SystemRoot%\System32\Drivers\Etc
gibt
Pfad
zu
den
StandardInternetdatenbankdateien
(HOSTS,
LMHOSTS, NETWORKS, PROTOCOLS) an
(wird von der Windows Sockets-Schnittstelle
verwendet)
2. EnableDeadGWDetect
Schlüssel:
Tcpip\Parameters\Interfaces\Adapter-ID
Werttyp:
Boolescher Wert (REG DWORD)
Wert:
0 oder 1 (FALSE oder TRUE)
Standardwert: 1 (TRUE)
Beschreibung: 1: Dead Gateway Detection eingeschaltet
(wechseln auf Reservegateway, wenn Segment
mehrmals ohne Rückmeldung gesendet wurde)
0: Dead Gateway Detection deaktiviert
46
3. EnablePMTUBHDetect
Schlüssel:
Tcpip\Parameters
Werttyp:
Boolescher Wert (REG DWORD)
Wert:
0 oder 1 (FALSE oder TRUE)
Standardwert: 0 (FALSE)
Beschreibung: 1: es wird versucht Black-Hole-Router zu erkennen
0: Black-Hole-Router-Erkennung deaktiviert
4. EnablePMTUDiscovery
Schlüssel:
Tcpip\Parameters
Werttyp:
Boolescher Wert (REG DWORD)
Wert:
0 oder 1 (FALSE oder TRUE)
Standardwert: 1 (TRUE)
Beschreibung: 1: es wird versucht die MTU entlang des Pfads
zu einem Remotehost zu erkennen (mögliche
Fragmentierung kann unterbunden werden)
0: MTU von 576 Byte für alle Verbindungen, die
nicht zu Computern im lokalen Subnetz gehen
5. GlobalMaxTcpWindowSize
Schlüssel:
Tcpip\Parameters
Werttyp:
Zahl (REG DWORD)
Wert:
0 - 65535 (mit Window-Scaling: 1073741823)
Standardwert: 65535 (TRUE)
Beschreibung: dies ist die maximale Windowsize für Verbindungen (TcpWindowSize kann nicht größer als
dieser Parameter sein)
47
6. KeepAliveInterval
Schlüssel:
Tcpip\Parameters
Werttyp:
Zeit
in
Millisekunden
(REG DWORD)(eventuell REG QWORD)
Wert:
1 - 4294967295
Standardwert: 1000 (eine Sekunde)
Beschreibung: gibt das Zeitintervall zwischen KeepaliveNeuübertragungen an
7. KeepAliveTime
Schlüssel:
Tcpip\Parameters
Werttyp:
Zeit
in
Millisekunden
(REG DWORD)(eventuell REG QWORD)
Wert:
1 - 4294967295
Standardwert: 7200000 (zwei Stunden)
Beschreibung: gibt das Zeitintervall nachdem ein KeepalivePakets gesendet wird, wenn Verbindung im
Leerlauf
8. MTU
Schlüssel:
Werttyp:
Wert:
Standardwert:
Beschreibung:
9. Tcp1323Opts
Schlüssel:
Werttyp:
Wert:
Standardwert:
Beschreibung:
48
Tcpip\Parameters\Interfaces\Adapter-ID
Zahl (REG QWORD)
68 - vom Netzwerk unterstützte maximale Paketgröße
4294967295
gibt maximale Paketgröße in Byte an
Tcpip\Parameters\Interfaces\Adapter-ID
Zahl (REG DWORD)
0, 1, 2 oder 3
0
3: aktiviert Window-Scaling und Timestamps
2: aktiviert nur Timestamps
1: aktiviert nur Window-Scaling
0: deaktiviert Window-Scaling und Timestamps
10. TcpMaxConnectRetransmissions
Schlüssel:
Tcpip\Parameters
Werttyp:
Zahl
(REG DWORD)(eventuell
REG QWORD)
Wert:
0 - 4294967295
Standardwert: 2
Beschreibung: gibt Anzahl der Verbindungsanforderung
(SYN) an, bevor der Versuch abgebrochen
wird (Zeitüberschreitungswert wird bei jeder
erneuten Übertragung verdoppelt. Startwert
beträgt drei Sekunden.)
11. TcpMaxDataRetransmissions
Schlüssel:
Tcpip\Parameters
Werttyp:
Zahl
(REG DWORD)(eventuell
REG QWORD)
Wert:
0 - 4294967295
Standardwert: 5
Beschreibung: gibt Anzahl der Übertragungsversuche für einzelne Datensegmente an, bevor die Verbindung
abgebrochen wird (Zeitüberschreitungswert
wird bei jeder erneuten Übertragung verdoppelt. Startwert wird nach Round-Trip Time
ermittelt.)
12. TcpNumConnections
Schlüssel:
Tcpip\Parameters
Werttyp:
Zahl (REG DWORD)
Wert:
0 - 16777214
Standardwert: 16777214
Beschreibung: maximale Anzahl der gleichzeitig geöffneten
Verbindungen
49
13. TcpRecvSegmentSize
Schlüssel:
Tcpip\Parameters
Werttyp:
Zahl (REG DWORD)
Wert:
0 - 16777214
Standardwert: 1460
Beschreibung: Platz, der für die Nutzdaten zur Verfügung
steht
14. TcpSendSegmentSize
Schlüssel:
Tcpip\Parameters
Werttyp:
Zahl (REG DWORD)
Wert:
0 - 16777214
Standardwert: 1460
Beschreibung: Platz, der für die Nutzdaten zur Verfügung
steht
15. TcpTimedWaitDelay
Schlüssel:
Tcpip\Parameters
Werttyp:
Zahl (REG DWORD)
Wert:
30 - 300
Standardwert: 120
Beschreibung: Zeitdauer, die eine Verbindung im TIME
WAIT-Zustand bleibt (Socketpaar kann nicht
neu verwendet)
16. TcpUseRFC1122UrgentPointer
Schlüssel:
Tcpip\Parameters
Werttyp:
Boolescher Wert (REG DWORD)
Wert:
0 oder 1 (FALSE oder TRUE)
Standardwert: 0 (FALSE)
Beschreibung: 1: für dringende Daten die RFC 1122Spezifikation
0: Modus von BSD-abgeleiteten Systemen (Berkeley Software Design)
50
17. TcpWindowSize
Schlüssel:
Werttyp:
Wert:
Standardwert:
Beschreibung:
18. SackOpts
Schlüssel:
Werttyp:
Wert:
Standardwert:
Beschreibung:
Tcpip\Parameters\Interfaces\Adapter-ID
Zahl (REG DWORD)
0 - 65535 (mit Window-Scaling: 1073741823)
16384 (abhängig von Netzwerktyp)
maximale vom System angebotene TCPEmpfangsfenstergröße für eine Verbindung
Tcpip\Parameters
Boolescher Wert (REG DWORD)
0 oder 1 (FALSE oder TRUE)
0 (FALSE)
1: aktiviert Selective Acknowledgements
0: deaktiviert Selective Acknowledgements
Es kann unter Umständen zu Problemen bei den Werttypen
REG DWORD“ kommen, da der Wertebereich eventuell nich aus”
reicht. Sollte dies der Fall sein, so kann der Werttyp REG QWORD“
”
Abhilfe schaffen, da dessen Wertebereich doppelt so groß ist.
51
Literatur
[1] Defense Advanced Research Projects Agency Information
Processing Techniques Office/Information Sciences Institute University of Southern California (Hrsg.): TRANSMISSION
CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL
SPECIFICATION. September 1981. – URL http://tools.ietf.org/
html/rfc793. – Zugriffsdatum: 25.05.2007
[2] ISO/IEC (Hrsg.):
Information Technology - Open Systems Interconnection - Basic Reference Model: The Basic Model. 1994. – URL
http://standards.iso.org/ittf/PubliclyAvailableStandards/
s020269_ISO_IEC_7498-1_1994(E).zip
[3] Microsoft Corporation (Hrsg.): Next Generation TCP/IP-Stack
unter Windows Vista und Windows Server Longhorn. August 2005.
–
URL http://www.microsoft.com/germany/technet/datenbank/
articles/600902.mspx. – Zugriffsdatum: 21.05.2007
[4] Wikipedia (Hrsg.): OSI-Modell. Mai 2007. – URL http://de.
wikipedia.org/wiki/OSI-Referenzmodell. – Zugriffsdatum: 25.05.2007
[5] Microsoft Corporation (Hrsg.):
TCP/IP- und NBTKonfigurationsparameter für Windows XP.
Januar 2007. –
URL
http://support.microsoft.com/kb/314053/de.
–
Zugriffsdatum:
21.05.2007
[6] Wikipedia (Hrsg.): Transmission Transport Protocol. Mai 2007. – URL
http://de.wikipedia.org/wiki/Transmission_Control_Protocol. –
Zugriffsdatum: 24.05.2007
[7] Loris Degioanni: WinPcap: The Windows Packet Capture Library. Januar 2007. – URL http://www.winpcap.org/. – Zugriffsdatum:
30.05.2007
[8] Matt Mathis, Raghu Reddy: Enabling High Performance Data
Transfers. November 2006. – URL http://www.psc.edu/networking/
projects/tcptune/. – Zugriffsdatum: 25.05.2007
[9] Microsoft: Microsoft Developer Network Library. 2005
52
[10] Oskar Andreasson: Ipsysctl tutorial 1.0.4. 2005. – URL http://
ipsysctl-tutorial.frozentux.net/chunkyhtml/tcpvariables.html.
– Zugriffsdatum: 28.05.2007
[11] V. Jacobson LBL R. Braden ISI D. Borman, Cray Research:
TCP Extensions for High Performance. Mai 1992. – URL http://tools.
ietf.org/html/rfc1323. – Zugriffsdatum: 25.05.2007
53
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
54
OSI-Stack vs. TCP/IP-Stack . . . . . . . . . . .
Der TCP-Header . . . . . . . . . . . . . . . . .
Der TCP-Pseudo-Header . . . . . . . . . . . . .
TCP-Verbindungsaufbau . . . . . . . . . . . . .
TCP-Verbindungsabbau . . . . . . . . . . . . .
Windowsize . . . . . . . . . . . . . . . . . . . .
Windowsize mit Scaling-Option . . . . . . . . .
TCP-Retransmission Timeout . . . . . . . . . .
TCP-Retransmission Timeout 2 . . . . . . . . .
TCP-Keep-Alive Timeout . . . . . . . . . . . .
TCP-Keep-Alive-Timeout 2 . . . . . . . . . . .
TCP-PersistenceTimer . . . . . . . . . . . . . .
Sliding Window: Start (Senden Byte 1 und 2) .
Sliding Window: Empfang von Byte 1 und 2 . .
Sliding Window: Acknowledgment Byte 1 und 2
Zero Window . . . . . . . . . . . . . . . . . . .
Silly Window-Syndrom . . . . . . . . . . . . . .
TCP-Nagle Algorithmus1 . . . . . . . . . . . . .
TCP-Nagle Algorithmus2 . . . . . . . . . . . . .
EditTCP - Das Hauptfenster - Server-Modus . .
EditTCP - Das Hauptfenster - Client-Modus . .
EditTCP - Allgemeine Optionen . . . . . . . . .
EditTCP - TCP/IP-Einstellungen . . . . . . . .
Wireshark . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
11
14
15
18
19
20
22
23
24
25
26
27
28
28
29
30
31
32
34
35
36
38
42