· Netzwerkzugang (OSI-Schicht 1 + 2): Diese Schicht enth˜alt kein vorgeschriebenes Protokoll und...

Institut fur InformatikLehrstuhl fur 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 41.1 TCP-Stack-Manipulation . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 TCP-Stack unter Linux . . . . . . . . . . . . . . . . . . . 41.1.2 TCP-Stack unter Windows . . . . . . . . . . . . . . . . . 5

2 Allgemeines 72.1 Vergleich: TCP/IP-Stack vs. OSI-Stack . . . . . . . . . . . . . . 7

3 Der TCP-Frame 103.1 TCP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 TCP-Pseudo-Header . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Verbindungen 154.1 Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3 Verbindungsabbau . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Interne Stellgroßen 195.1 Windowsize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.1.1 Manipulation unter Linux . . . . . . . . . . . . . . . . . 215.1.2 Manipulation unter Windows . . . . . . . . . . . . . . . 21

5.2 Retransmission Timer . . . . . . . . . . . . . . . . . . . . . . . 225.2.1 Manipulation unter Linux . . . . . . . . . . . . . . . . . 235.2.2 Manipulation unter Windows . . . . . . . . . . . . . . . 24

5.3 Keep-Alive Timer . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3.1 Manipulation unter Linux . . . . . . . . . . . . . . . . . 245.3.2 Manipulation unter Windows . . . . . . . . . . . . . . . 25

5.4 Persistence Timer . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 TCP-Algorithmen 276.1 Sliding Window-Algorithmus . . . . . . . . . . . . . . . . . . . . 276.2 Slow-Start Algorithmus . . . . . . . . . . . . . . . . . . . . . . . 306.3 Nagle-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . 31

A Tools 33A.1 EditTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

A.1.1 Uber das Programm . . . . . . . . . . . . . . . . . . . . 33A.1.2 Das Hauptfenster . . . . . . . . . . . . . . . . . . . . . . 34

2

A.1.3 Allgemeine Optionen . . . . . . . . . . . . . . . . . . . . 36A.1.4 TCP/IP-Einstellungen . . . . . . . . . . . . . . . . . . . 38A.1.5 Andern der Registry . . . . . . . . . . . . . . . . . . . . 39A.1.6 Aufbau einer Verbindung . . . . . . . . . . . . . . . . . . 39

A.2 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

B technische Referenz 44B.1 sonstige Parameter unter Linux . . . . . . . . . . . . . . . . . . 44B.2 Parameter unter Windows . . . . . . . . . . . . . . . . . . . . . 46

3

1 Einleitung

Im Folgenden werden wir das Transmission Control Protocol (kurz: TCP) derTransportschicht im TCP/IP Stack beleuchten und insbesondere auf Mani-pulationsmoglichkeiten unter den Betriebssystemen Windows XP und Linux(Debian Knoppix 4.0 und Suse 10.2) eingehen.

Wir werden grundlegende Funktionsweisen klaren (Verbindungsauf- und ab-bau und Datenubertragung), auf technische Details eingehen (z.B. Paketauf-bau, Timer und deren Berechnung) sowie Algorithmen, die in Verbindung mitdem TCP-Protokoll auftreten, erlautern.

Unser grundsatzliches Vorgehen orientiert sich an der Klarung theoretischerGrundlagen eines bestimmten Aspektes mit anschließender praktischer exem-plarischer Darlegung, sofern dies fur uns moglich ist.

Im Anhang befindet sich zudem eine Referenz, die manipulierbare Parameterunter Linux und Windows genauer beschreibt.

1.1 TCP-Stack-Manipulation

1.1.1 TCP-Stack unter Linux

Der Vorteil am Linux-Betriebssystem ist, dass Anderungen am TCP-Stackdynamisch, d.h. zur Laufzeit durchfuhrbar sind. Der Zustand wird in Varia-blen vermerkt, die sich alle in dem gleichen Verzeichnis befinden (/proc/sys/-net/ipv4). Werte von Variablen konnen behandelt werden wie Dateien unddemnach zum Beispiel mit

”cat“ oder

”more“ angezeigt werden.

Nachteil ist, dass eventuelle Anderungen nach einem Neustart des Systemsverloren gehen und so Skripte erzeugt werden mussen, die bei jedem Start dieWerte andern, wenn man diese dauerhaft erhalten mochte.Es gibt zwei Moglichkeiten eine Variablenanderung zu bewirken.1

• Benutzung des”echo“ Befehls und Schreiben in die Variable durch Um-

lenkung des Ausgabestroms, z.B.

1in beiden Fallen sind Root-Rechte notig

4

$echo "5" > /proc/sys/net/ipv4/tcp_retries1

• Benutzung des Befehls”sysctl“ .

Mit der Option -a werden alle Werte aller Variablen angezeigt 2. Geandertwird ein Wert uber die Option -w, wobei zu beachten ist, dass das Wur-zelverzeichnis von

”sysctl“ /proc/sys/ ist. Beispiel:

sysctl -w net/ipv4/tcp_retries1=5

(aquivalent zu sysctl -w net.ipv4.tcp_retries=5)

1.1.2 TCP-Stack unter Windows

Windows erlaubt leider keine dynamische Anderung von TCP-Werten. Nacheiner Anderung muss das System neu gestartet werden, dafur bleiben die Ander-ungen jedoch dauerhaft erhalten. Die Werte stehen in der Windows-Registryunter dem Schlussel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\

Hier befinden sich allgemeine Parameter. Spezielle Parameter sind unter wei-teren Subschlusseln zu finden. Windows erlaubt eine Unterscheidung der ver-wendeten Netzwerkadapter, die allerdings in der Registry nicht namentlich imKlartext aufgefuhrt werden, sondern durch eine ID gekennzeichnet sind. DieseID 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 anderbarenParameter nicht standardmaßig in der Registrierung eingetragen sind. Sind dieSchlussel nicht vorhanden, werden vom Betriebssystem die in den Treibern im-plementierten Standardwerte genutzt. Mochte man nicht vorhandene Schlusselandern, hilft nur die Konsultation der Dokumentation (www.microsoft.com)

2Werte anderer Protokolle wie IPv4 oder IPv6 werden ebenfalls angezeigt

5

um die richtigen Registrierungspfade zu ermitteln. Auch muss der richtige Da-tentyp des Parameters eingestellt werden. Dies ist ebenfalls der Dokumentationzu entnehmen und ist meist

”D WORD“ .

An dieser Stelle sei auf den Anhang B verwiesen (Anhang B.2, Seite 46). Eineweitere Moglichkeit zur Manipulation des TCP/IP-Stacks ist das von uns ge-schriebene Tool

”EditTCP“, auf welches spater noch genauer eingegangen wird

(Kapitel A.1, Seite 33).

Fur aktuelle Systeme (Windows-Vista, Windows Server Longhorn) wurdeder TCP/IP-Stack neu implementiert, es entstand der Next-Genereation-TCP/IP-Stack. Hier ist eine dynamische Anderung der Einstellungenmoglich. [3]

6

2 Allgemeines

Das Transmission Control Protocol (TCP) hat sich uber die Zeit hinweg zueinem der wichtigsten Transportprotokolle in Computernetzwerken entwickelt.Es ist verbindungsorientiert und vor allem zuverlassig und bildet als Teil derInternetprotokollfamilie eine Grundlage fur das sogennante

”Internet“ [6].

Der Grundstein fur TCP wurde im Rahmen der Erforschung von zuverlassigenund vor allem robusten Rechnernetzwerken 1973 von Robert E. Kahn und Vin-ton G. Cerf gelegt. Hintergrund hierfur war das große Interesse des Militars zuZeiten des

”Kalten Krieges“ an Computernetzwerken, die auch nach einem

Atomschlag weiter funktionieren wurden. Aber auch die Verbindung von ver-schiedenen Netzen war ein wichtiges Kriterium. Die Entwicklung und Standar-disierung des TCP-Protokolls dauerte schließlich bis 1981. Es ging das ersteRequest for Comments (RFC) mit der Nummer 793 hervor. Dort enthaltensind die technischen Details zum TCP-Protokoll (Paket-Aufbau, spezielle Al-gorithmen, Zusammenarbeit mit anderen Protokollen...) [1]. Im Laufe der Zeitkamen einige Neuerungen hinzu, die schließlich 1992 im RFC 1323 standadisiertwurden [11].

Aufgrund der fruhen Standardisierung und der besonderen Eigenschaftenvon TCP (sichere Datenubertragung, Bidirektionalitat, Uberlaststeuerung...)ist dieses Protkoll sehr weit verbreitet und aus der Welt der Computernetzwerkenicht mehr wegzudenken.

2.1 Vergleich: TCP/IP-Stack vs. OSI-Stack

Das wichtigste theoretische Modell eines Netzwerkstacks ist das 1983 stan-dardisierte OSI-Schichtenmodell (ISO 7498-1), wobei OSI fur

”Open Systems

Interconnection“ steht [2]. Es ist ein Referenzmodell zur Beschreibung herstel-lerunabhangiger Kommunikationssysteme und dient diesen als Grundlage. DasOSI-Modell spezifiziert sieben Schichten, die vertikal angeordnet sind, wobeihohere Schichten die Dienste der direkt darunterliegenden Schicht nutzen. DieFunktion und Aufgabe jeder Schicht ist exakt definiert. Trotz oder gerade we-gen seines klaren, aber strengen Schichtenmodelles gibt es in der Realitat kaum1:1-Implementationen des OSI-Referenzmodelles [4].

7

Dem gegenuber steht das TCP/IP-Referenzmodell, welches bereits 1981 stan-dardisiert wurde. Es wurde also unabhangig vom OSI-Modell entwickelt undhat sich als Quasi-Standard fur die Netzwerkkomunikation durchgesetzt. DasTCP/IP-Modell besteht lediglich aus vier Schichten, die ebenfalls vertikal ange-ordnet sind. Abbildung 1 zeigt eine Gegenuberstellung der Schichten der beidenModelle.

Abbildung 1: OSI-Stack vs. TCP/IP-Stack

Anders als beim OSI-Modell ist es beim TCP/IP-Modell moglich, dass eineSchicht unter Umgehung zwischenliegender Schichten von einer oberen Schichtgenutzt wird. Dadurch arbeitet das TCP/IP-Protkoll deutlich effizienter, wasein Grund fur dessen große Verbreitung ist. Weiterhin ist auch die genaueFunktion der einzelnen TCP/IP-Schichten nicht exakt vorgeschrieben. Hier einkurzer Uberblick uber die vier Schichten des TCP/IP-Referenzmodelles:

8

Anwendungsschicht (OSI-Schicht 5 + 6 + 7):Diese Schicht umfasst samtliche Protokolle, die von Anwendungsprogram-men genutzt werden.

Transportschicht (OSI-Schicht 4):Die Transportschicht stellt eine Ende-zu-Ende-Verbiundung her. Auf die-ser Ebene ist TCP angesiedelt.

Internetschicht (OSI-Schicht 3):Diese Schicht ist fur das Routing und die Weiterleitung von Paketen ver-antwortlich. Auf dieser Ebene ist IP angesiedelt.

Netzwerkzugang (OSI-Schicht 1 + 2):Diese Schicht enthalt kein vorgeschriebenes Protokoll und wird entspre-chend der Netztechnik gefullt. In der Praxis ist hier oft Ethernet anzu-treffen.

Man kann also sagen, dass das OSI-Modell ein sehr sauberes, gut struktu-riertes und durchdachtes Modell ist, welches jedoch haufig nur fur theoretischeUberlegungen herangezogen wird. Das TCP/IP-Modell ist dagegen

”quick and

dirty“ entstanden, um den alltaglichen Bedurfnissen gerecht zu werden.”OSI

ist Ordnung, die niemand will und TCP/IP ist Chaos, das funktioniert!“ istein humorvoll klingender Satz mit wahrem Hintergrund.

9

3 Der TCP-Frame

Ein TCP-Frame besteht aus zwei Teilen, dem sogenannten TCP-Header undden Nutzdaten, auch Payload genannt. Der TCP-Header enthalt wichtige In-formationen uber das TCP-Frame (Abbildung 2). Im Allgemeinen ist der TCP-Header 20 Byte groß. Diese Angabe kann jedoch aufgrund enventuell vorhan-dener 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 einzel-nen Segmente gezeigt werden. die angesprochenen Flags (URG, ACK...) sindgesetzt, wenn ihr Wert

’1‘ ist.

10

Abbildung 2: Der TCP-Header

Source-Port (Bit 1 - 16)Dieser Eintrag im TCP-Header enthalt die Portnummer des sendendenRechners. Jede Portnummer kann auf einem Rechner nur einmal verge-ben werden. Somit ist gewahrleistet, dass die IP und die Portnummereindeutig 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 fur den Empfanger wichtig, damit er die unterUmstanden in falscher Reihenfolge empfangenen Pakete sortieren kann.Im Gegensatz zu vielen anderen Protokollen werden bei TCP die einzel-nen 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 interpretiertwerden. Hierfur gibt es verschiedene Ansatze wie zum Beispiel Abspei-chern der zuletzt verwendeten Nummern oder Orientierung an einem Zeit-geber, auf die hier aber nicht naher eingegangen werden soll.

Acknowledgement-Number (Bit 65 - 96):Mit der Bestatigungsnummer gibt der Empfanger die Sequenznummerdes von ihm als nachsten erwarteten Bytes an. Gleichzeitig wird damitder Empfang aller Pakete bis zu dieser Sequenznummer - 1 signalisiert.Voraussetzung fur die Bestatigungsnummer ist das gesetzte ACK-Flag.

Data-Offset (Bit 97 - 100)Das Data-Offset gibt die Position im Paket an, an der die Nutzdatenbeginnen. Diese Zahl ist ein vielfaches von 32 (Bit) und ist notig, da dieLange der Optionen variieren kann. Mindestens steht hier jedoch

’5‘, was

bedeutet, dass der Header 20 Byte lang ist und es somit keine Optionengibt.

reserved (Bit 101 - 106)Diese Bits werden nicht verwendet und mussen Null sein.

URG (Bit 107)Das Dringlichkeits-Bit signalisiert, ob der Urgent-Pointer (s.u.) ausgewer-tet werden soll, was bedeutet, ob ein Teil der Daten prioritar behandeltwerden soll. Ist dieses Bit gesetzt, so unterbricht die Anwendung die Ab-arbeitung des aktuellen TCP-Segementes und verarbeitet zunachst diedringlichen Daten.

ACK (Bit 108)Ist dieses Bit gesetzt, so ist die Acknowledgement-Number gultig und eswird der Empfang von TCP-Segmenten bestatigt. Ist zusatzlich auch dasSYN-Flag gesetzt, so dient dieses Bit zur Bestatigung beim

”Drei-Wege-

Handshake“. Das Flag ist bei fast allen Ubertragungen gesetzt.

PSH (Bit 109)Das Setzen des Push-Bits sorgt dafur, dass Daten nicht im Puffer desEmpfangers zwischengespeichert werden, sondern direkt an die Anwen-dung gegeben werden. Somit wird eine Verzogerung der eventuell zeit-kritischen 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 Sequenznummernbeim 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 uberlauft, sendet der Empfanger hierdie maximale Anzahl an Bytes, die der Sender senden darf (siehe Kapitel5.1).

Checksum (Bit 129 - 144)Aus dem TCP-Header, dem TCP-Pseudo-Header (siehe Kapitel 3.2) undden Daten wird eine Prufsumme errechnet. Dies soll fur eine bessere Zu-verlassigkeit (Erkennung von Fehlern) dienen.

Urgent-Pointer (Bit 145 - 160)Der Dringlichkeits-Zeiger gibt an, wo in dem Datenstrom die dringlichenDaten anfangen. Er ist nur gultig, wenn das URG-Flag gesetzt ist.

Options (Bit 161 - (160 + n * 32))Zusatzliche Optionen konnen hiermit ausgehandelt werden. Die Lange desOptionen-Feldes muss ein Vielfaches von 32 sein. Ist es kleiner, so wird esmit Nullen auf diese Große aufgefullt. Dies nennt man Padding. MoglicheOptionen sind beispielsweise, dass Erlauben eines Selective Acknowledgeoder das Window Scaling (siehe Kapitel 5.1).

3.2 TCP-Pseudo-Header

Der TCP-Pseudo-Header wird allein zur Sicherung der Datenintegritat undzum Schutz vor fehlgeleiteten Segmenten genutzt.

13

Abbildung 3: Der TCP-Pseudo-Header

Beim Sender wird vor Berechnung der Prufsumme das Feld”Checksum“ auf

Null gesetzt. Weiterhin wird die Byte-Lange des TCP-Segmentes uberpruft.Sollte sie ungerade sein, so wird den Nutzdaten ein Null-Byte hinzugefugt(welches nicht ubertragen wird) und der Pseudo-Header erzeugt (Abbildung3). Anschließend werden die gesamten Daten in 16-Bit-Werte zerlegt, ins Ei-nerkomplement uberfuhrt und dann addiert. Fur diese Summe wird abermalsdas Einerkomplement berechnet und dann schließlich als Checksumme im TCP-Header gespeichert. Der TCP-Pseudo-Header wird anschließend verworfen undnicht ubertragen!

Der Empfanger erstellt ebenfalls den Pseudoheader und addiert die 16-Bit-Werte, nur dass er das

”Checksum“-Feld nicht auf 0 setzt. Ist sein errechne-

tes Ergebnis FFFF (Hexadezimal), so wurden die Daten korrekt ubertragen.Andernfalls werden die Daten verworfen. Da die Bestatigung beim Sender aus-bleibt, wiederholt dieser die Ubertragung.

14

4 Verbindungen

4.1 Verbindungsaufbau

Der Verbindungsaufbau wird im TCP-Protokoll eher als eine Synchronisationvon Sender und Empfanger verstanden. Deswegen heißt das hierfur zugehorigeFlag auch

”SYN“ (siehe Kapitel 3). Das Protokoll benutzt einen sogenann-

ten”Three-Way-Handshake“, durch den Datenverlust oder sogar duplizierte

Sitzungen vermieden werden konnen.

Abbildung 4: TCP-Verbindungsaufbau

Wie sich aus dem Namen schon ableiten lasst, besteht der Vorgang im Grundegenommen aus drei Einzelschritten. Zunachst beginnt der Client(1) ein Paket

15

zu senden, in dem das SYN-Flag (3 und 6) gesetzt ist. Mit diesem schickt er einevon ihm gewahlte Startsequenznummer mit. Der Server(2) schickt seinerseitseine Startsequenznummer, bestatigt gleichzeitig die Kenntnisnahme der Se-quenznummer des Clients und setzt somit in seinem Paket das ACK-Flag unddas SYN-Flag(4). Zum Schluss sendet der Client nocheinmal eine Bestatigungder Sequenznummer des Servers und kann in diesem Paket bereits die erstenDaten einfugen(5).

Dieses System ist gegen alle Eventualitaten abgesichert:

• Das erste Paket des Clients geht verloren: Der normale Retransmission-Timer (siehe Kapitel 5.2) lauft ab und das Paket wird erneut gesendet.

• Die Antwort des Servers geht verloren: Der Client vermisst die Antwortund nach Ablauf des Retransmission-Timers wird erneut gesendet.

• Die Bestatigung der Sequenznummer des Servers durch den Client gehtverloren: auch hier wird das Paket wegen ausbleibender Antwort neu ge-sendet.

• Ein verzogertes Connection Request vom Client erreicht den Server: derServer weiß nicht, ob diese Anfrage eine Wiederholung oder tatsachlichein falsches Duplikat ist und sendet einfach seine Startsequenznummernocheinmal. Der Client erkennt den Fehler an der bereits zuvor einmalempfangenen Sequenznummer und verwirft das Paket.

• Der Client erhalt niemals eine Antwort: Nach endlichen Versuchen wirdder Verbindungsaufbau abgebrochen und an die Anwendungsschicht ge-meldet.

4.2 Datenaustausch

Wahrend des Datenaustausches werden zusatzlich zu den bereits beschriebenenMechanismen wie Sendewiederholung oder Duplikaterkennung Prinzipien wiedie Flusssteuerung (siehe Kapitel 5.1), Verwendung von Algorithmen (Slow-Start (Kapitel 6.2) und Nagle-Algorithmus (Kapitel 6.3)) und weitere Timer(Keep-Alive Timer (Kapitel 5.3) und Persistence Timer (Kapitel 5.4)) einge-setzt.

16

4.3 Verbindungsabbau

Beim Verbindungsabbau wird durch TCP die verlustlose Datenubertragung ga-rantiert, indem auch hier ein

”Three-Way-Handshake“ verwendet wird, welches

”Graceful Close“ genannt wird.

Zunachst sendet eine der beiden Seiten das Disconnection Request indem dasFIN-Flag (siehe Kapitel 3) gesetzt wird(1).3 Die andere Seite antwortet dann,indem sie ebenfalls das FIN-Flag setzt und zusatzlich durch das ACK-Flag dasFIN-Flag des Verbindungspartners bestatigt(2). Zum Schluss wird durch einweiteres Paket des Verbindungsabbauinitierers, in dem das ACK-Flag gesetztist, der Verbindungsabbau bestatigt und damit beendet(3).

Auch dieses Verfahren ist sehr sicher und funktioniert analog zu den Verfah-ren des Verbindungsaufbaus.

3Im Beispiel ist hier auch das ACK-Flag gesetzt, was in diesem Fall aber lediglich das zuletztgesendete Datenpaket bestatigt und hier nur aus Effizienzgrunden zusammen mit demFIN-Flag gesendet wird.

17

Abbildung 5: TCP-Verbindungsabbau

18

5 Interne Stellgroßen

5.1 Windowsize

Fur jede TCP-Verbindung steht ein festgelegter maximaler Speicherbereich furdie empfangenen Pakete zur Verfugung, wobei die tatsachliche Große des Fens-ters variabel ist. Die aktuelle Große wird durch die sogenannte Windowsizefestgelegt, welche immer kleiner als die maximale Windowsize ist [1][11]. DieWindowsize ist fur den Sender der Sendekredit. Sie beschreibt also, wievie-le Bytes der Sender schicken darf, bis er spatestens auf eine Antwort wartenmuss. Der Empfanger teilt seine Windowsize mit jedem Acknowledgement demSender mit, wobei die Große davon abhangt, wieviel Speicher seines Empfangs-fensters bereits belegt ist (siehe Abbildung 6) und naturlich wie groß das Fenstermaximal ist.

Abbildung 6: Windowsize und maximale Paketgroße ohne Header (MSS)

Der Algorithmus fur die Kontrolle des Datenflusses wird”Sliding Window“

genannt und wird in Kapitel 6.1 auf Seite 27 genauer erlautert.

19

Window ScalingDie Große der maximalen Windowsize ist durch die Struktur des TCP-Headerauf 65535 Bytes begrenzt (siehe Kapitel 3.1). In Netzwerken mit einer hoherenRound-Trip-Time und hoher Bandbreite kann der effektive Datendurchsatzdurch eine großere Windowsize verbessert werden [5]. Damit die Fenstergroßemehr als 65535 Bytes groß sein kann, wurde die Option

”TCP Window Sca-

le Option (WSopt)“ eingefuhrt [11]. Es kann nun festgelegt werden ob undmit 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 ausgefuhrt werden und wird deshalb indem RFC1323 als

”shift.cnt“ bezeichnet. Damit Window Scaling auch wirklich

eingesetzt wird, mussen beide Kommunikationspartner diese Option aktivierthaben!

Abbildung 7: Windowsize mit Scaling-Option

Die tatsachliche Windowsize wird nun aus dem Produkt der angegebenenWindowsize eines jeden Paketes und dem im SYN-Paket mitgeteilten Skalie-rungsfaktor berechnet [11]. In Abbildung 7 ist ein SYN-Paket mit angegebenerWindowsize und Window Scaling Optionen zu sehen. Die tatsachliche Win-dowsize betragt vor der Rundung dort 2097152 statt 8192 Byte. Wird die Win-

20

dowsize auf einen Wert uber 65535 Bytes gesetzt, so wird der Skalierungsfaktornach Rundung automatisch berechnet und mit entsprechender Windowsize imTCP-Header gesendet.

5.1.1 Manipulation unter Linux

Eine gewunschte Windowsize genau einzustellen ist sehr umstandlich unterLinux. Zunachst ist wichtig zu wissen, dass erstellten Sockets Speicherplatz zu-gewiesen wird. Dieser Speicherplatz teilt sich in Speicher fur die Anwendungund Speicher fur das Fenster.Mit drei Variablen lasst sich die Windowsize einstellen: tcp_adv_win_scale,mit der das Verhaltnis von Anwendungs- zu Fensterspeicher definiert wird,tcp_app_win, die die Große des Anwendungsspeichers auf eine andere Art de-finiert und tcp_rmem, mit der die Große des gesamten Empfangspuffers geregeltwird.Fur genauere Erklarungen siehe Anhang B.1.

5.1.2 Manipulation unter Windows

Fur die maximale Große der Windowsize sind die Werte TcpWindowSize undGlobalMaxTcpWindowSize verantwortlich. Hier wird die gewunschte Zahl ein-getragen, wobei TcpWindowSize fur jeden Netzwerkadapter anders sein kannund maximal gleich GlobalMaxTcpWindowSize sein darf. Die angegebene Win-dowsize wird beim zweiten Paket automatisch entprechend der genutzten Netz-werktechnologie geandert. Sie wird auf das nachste Vielfache der MaximumSegment Size (MSS) gerundet. So wird im Ethernet der Wert von 8192 auf8760 gesetzt (Standard). Um die Option Window Scaling zu aktivieren, mussder Wert Tcp1323Opts auf 1 oder 3 gesetzt werden (wobei 3 auch Timestampsaktiviert). Abbildung 7 zeigt ein SYN-Paket ohneWindow Scaling und einerWindowsize von 17520. Abbildung 6 zeigt ein SYN-Paket mit Window Scalingund einer Windowsize von 8192 * 256 = 2097152 (was aber noch gerundetwird).

21

5.2 Retransmission Timer

Der Retransmission Timer ist der wahrscheinlich wichtigste Timer im TCP-Protokoll. Er gibt an, nach welcher Zeitspanne ein nicht bestatigtes Paket neugesendet werden soll. Die Dauer richtet sich nach bereits erfolgten Misserfolgenfur das spezifische Paket und liegt einem Algorithmus zu Grunde, der meist dieRound-Trip-Time vergangener Pakete, also die Zeit die vom Absenden einesPaketes bis zum Empfangen der Bestatigung vergangen ist, mit in die Berech-nung einbezieht. Es gibt verschiedene Ansatze den Retransmission-Timer zuberechnen.

Abbildung 8: Retransmission Timeout in einer Linux Implementation von TCP

1. rekursiv uber einen gewichteten Mittelwert der Round-Trip-Time: DieserAlgorithmus wird in der dem TCP Protokoll zugrundeliegenden RFC 793beschrieben und gliedert sich in zwei Teilgleichungen (1981).

RTTest = a * RTTest + (1 - a) * RTTsamp

mit RTTest = geschatzte Round-Trip-Time, RTTsamp = Round-Trip-Time des letzten Paketes, a = Gewichtungs-

faktor (0.8 - 0.9)

Retransmission Time = b * RTTest

mit b = 1,3 - 2,0

2. abhangig von der Standardabweichung D der eintreffenden Acknowledges(Jacobson 1988)

D = a * D + (1 - a) * abs(RTTest - RTTsamp)

22

3. unabhangig von RTT und Acknowledges, nach immer gleichem Schema(Karn 1987)Dass einem ankommenden Acknowledge unter Umstanden ein zuvor er-folgtes Neusenden des Paketes vorausgeht, weil der Retransmission Timerkurz zuvor abgelaufen ist, ist der Nachteil bei Algorithmen, die von derRound-Trip-Time abhangig sind. Die neue Round-Trip Time wird nunfalsch berechnet, da bei einem Acknowledge nicht unterschieden werdenkann, zu welchem Paket es ursprunglich gehorte.

Abbildung 9: Retransmission Timeout begrenzt auf 4 Wiederholungen

Abhilfe schafft hier der Karn-Algorithmus, der von einer initialen Zeit furden ersten Paketverlust ausgeht, und dann bei jedem weiteren Verlust die-se Zeit einfach verdoppelt. Dies ist auch die bei unserer Implementationvorherrschende Vorgehensweise (siehe Abbildung 8).


Unter Linux ist es moglich, die Anzahl der Wiederholungsversuche zubeeinflussen. Dies geschieht uber die Variable tcp_retries2. Im Beispielwurde so die Wiederholungsanzahl auf vier begrenzt (Abbildung 9).

Dies regelt allerdings nur das Wiederholen von Datenpaketen. Zur Steue-rung der Anzahl von Verbindungsaufbauversuchen wird dagegen die Va-riable tcp_syn_retries verwendet. Ebenfalls beeinflusst werden kannwie oft auf eine eingehende SYN-Anforderung reagiert werden soll, undzwar mit der Veriable tcp_synack_retries.

23


Bei Windows ist der Timer initial auf drei Sekunden gestellt und wird da-nach automatisch entsprechend der Situation des Netzwerkes angepasst.Es ist moglich die Anzahl der Wiederholungsversuche zu andern. Der Pa-rameter TcpMaxConnectRetransmissions gibt dabei die maximale An-zahl an Versuchen fur eine Verbindungsanforderung (SYN) an. Ist dieseuberschritten, werden die Versuche abgebrochen.TcpMaxDataRetransmissions regelt hingegen die Sendewiederholungs-versuche von Datenpaketen.

5.3 Keep-Alive Timer

Der Keep-Alive Timer wird verwendet, um bei einer bestehenden Verbindunguber die eine gewissen Zeit keine Daten mehr gesendet wurden, ein Test-Paketabzuschicken, dass zeigen soll, ob der Kommunikationspartner uberhaupt nocherreichbar ist. Falls nicht, wird nach einer gewissen Anzahl von Versuchen dieVerbindung geschlossen. Standardmaßig wird nach zwei Stunden mit dem Ver-senden von TCP-Keep-Alives begonnen. Dies wird dann alle 75 Sekunden wie-derholt (siehe Abbildung 10).

Abbildung 10: Keep-Alive Timeout mit 75 sekundiger Wiederholrate


Unter Linux kann man hier sehr flexibel agieren. Mit tcp_keepalive_time

kann bestimmt werden, wann mit dem Versenden von Keep-Alives begonnenwerden soll.Mit tcp_keepalive_intvl wird die darauf folgende Wiederholrate eingestelltund mit tcp_keepalive_probes schließlich die Anzahl der Versuche bei Nicht-Antwort. In unserem Beispiel sind tcp keepalive time = 1 und tcp keepalive probes= 5 (siehe Abbildung 11).

24

Abbildung 11: Retransmission Timeout mit 5 sekundiger Wiederholrate


Unter Windows gibt es zwei Parameter, die fur die Keep-Alive-Einstellungenzustandig sind. Das sind KeepAliveInterval und KeepAliveTime. Der ersteParameter gibt das Zeitintervall zwischen zwei Keep-Alive-Paketen in Millise-kunden an. KeepAliveTime hingegen gibt die Zeit in Millisekunden an, die beieiner Verbindung im Leerlauf vergeht, bis das erste Keep-Alive-Paket gesendetwird. Leider konnten wir die Auswirkungen nicht beobachten.

5.4 Persistence Timer

Der Persistence-Timer wird gestartet, sobald ein Kommunikationspartner dieWindow-Size des Receiver-Windows auf 0 setzt (siehe Kapitel 5.1). Er soll si-cherstellen, dass falls das Paket, dass das Fenster wieder offnet, verloren geht,die Kommunikation nicht zum Stillstand kommt. Sollte er ablaufen, so wirdein Paket mit einer ungultigen Acknowledge-Nummer gesendet, worauf derEmpfanger mit der richtigen Nummer antwortet und nebenlaufig die aktuel-le Window-Size mitsendet.

Unter Windows wie auch unter Linux ist es uns leider nicht moglich gewesen,diesen Timer zu verandern. Man kann allerdings beobachten, dass er, zumindestbei unserem Versuch, serverseitig fast genauso wie der Retransmission Timer(siehe Kapitel 5.2) berechnet wird (bei kleinerem maximalen Timeout) und alsungultige Acknowledge-Nummer einfach die erste der Kommunikation gesendetwird (

’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 Empfangersteuert damit den Datenfluss, welcher vom Sender stammt (Windowscaling/Win-dowsize siehe Kapitel 5.1). Der Sender weiß so immer, wieviele Daten er nochsenden kann, bevor der Empfanger diese nicht mehr annimmt. Außerdem mussder Sender nun nicht mehr auf eine Bestatigung jedes einzelnen Bytes war-ten, bevor weitere Bytes gesendet werden, was bei großen Umlaufzeiten sehrnegative Auswirkungen auf die Effizienz hatte.

Abbildung 13: Sliding Window: Start (Senden Byte 1 und 2)

Der Sender kann soviele Daten senden, wie er Sendekredit durch den Empfangerin einem vorherigen ACK-Paket bekommen hat. Der Empfanger kann jedochtrotzdem jedes einzelne Byte bestatigen, bevor das Empfangsfenster voll ist.Abbildung 13 zeigt den Initialzustand. Der Sender schickt nun maximal zweiBytes mit den Nummern 1 und 2 bevor er auf eine Bestatigung warten muss.Hat der Empfanger die Daten erhalten und wurden die Sequenznummern nochnicht empfangen, so setzt er sein Fenster weiter und sendet eine Bestatigungfur die erhaltenen Sequenznummern und wartet auf neue Daten (Abbildung14). Hierbei teilt der Empfanger der Gegenseite auch wieder einen Sendekreditmit, der hier jedoch wieder

’2‘ ist. Es wurden also alle Bytes verarbeitet. Der

Empfanger konnte hier auch nach Erhalt und Verarbeitung des ersten Bytesdas 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 Bestatigungen fur die Daten erhalten, so setzt er seinFenster entsprechend seinem Sendekredit weiter (hier wieder

’2‘) und sendet

die neuen Daten. Sind jedoch die Bestatigungen fur die Bytes verloren gegan-gen, so schickt der Sender die Daten nach Timer-Ablauf erneut. Der Empfangerhat jedoch sein Fenster schon verschoben und erkennt die Sequenznummernals alt. Der Empfanger bestatigt diese erneut (in der Hoffnung, dass die Ack-nowledgments nun den Sender erreichen). Die Verlustsituation der Daten vomSender zum Empfanger wurde hier nicht weiter berucksichtigt, da dies bereitsim Kapitel 5.2 geschehen ist.

Abbildung 15: Sliding Window: Acknowledgment Byte 1 und 2

Ein Problem, welches beim Sliding Window-Algorithmus auftreten kann, istdas 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 Empfanger 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 wurde der Sen-dekredit fur den Sender dementsprechend angepasst, so wurde dieser nur sehrwenige Daten verpackt in einem großen Paket (mit Header etc.) verschicken(siehe Abbildung 17). Dies stellt naturlich einen sehr großen Overhead dar. Istdann das Fenster wieder voll, dann wird erneut ein Zero Window geschickt.Eine Wiederholung dieses Ablaufes mindert naturlich die Effizienz. Um dies zuverhindern, wartet der Empfanger mindestens so lange mit dem Senden einerneuen 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 Empfanger noch das Netz-werk zu uberlasten, wenn noch nicht sichergestellt werden kann, dass beideKomponenten ausreichend funktionsfahig sind.TCP verwaltet zusatzlich zum Receiver-Control Fenster (siehe Kapitel 6.1) einSendefenster fur den Slow-Start Algorithmus, welches durch ein Segment festerGroße initialisiert wird. Das tatsachliche Sendefenster wird bestimmt durch daskleinere dieser beiden. Wie der Name des Algorithmus schon andeutet, wird ei-ne neu aufgebaute Verbindung nur langsam belastet.Bei erfolgreichen Acknowledges des Kommunikationspartners wird die Fenster-große solange verdoppelt, bis ein spezifischer Schwellwert erreicht wird, ab demes immer um einen festen Wert erhoht wird.

Sollte ein Acknowledge ausbleiben, also ein Retransmission-Timer zuschla-gen, so beginnt der Algorithmus erneut mit der initialen Fenstergroße, wobeiallerdings der Schwellwert, der das Fensterwachstum von exponentiell auf line-ar umschaltet, auf die halbe aktuelle Fenstergroße gesetzt wird.Dies fuhrt allerdings dazu, dass lang anhaltende Verbindung

”pumpen“, d.h.

das Fenster wird linear erhoht bis die Belastung der Verbindung zu hoch wird,das Fenster wird zuruckgesetzt und dies beginnt von vorn.Ein weiterer Nachteil dieses Algorithmus ist, dass er stets davon ausgeht, dasseine ausbleibende Bestatigung auf eine Uberlast des Netzwerkes zuruckzufuhrenist, obwohl zum Beispiel auch Ubertragungsfehler insbesondere in der drahtlo-sen Ubertragung daran Schuld sein konnen und die Rucksetzung des Fensterssomit unnotig, ja sogar hinderlich ist.

30

6.3 Nagle-Algorithmus

Mit dem Nagle-Algorithmus wird die Netzlast vermindert. Er sorgt dafur, dassPakete mit zu kurzem Datenteil gesammelt werden, bevor sie dann zusammenin einem einzigen Paket verschickt werden. Dieses Verfahren ist allerdings be-denklich, falls prioritare 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 dafursorgt, dass Daten direkt zur Anwendung hochgereicht werden.

In unserem Beispiel kann man den Nagle-Algorithmus durch einen Trick zwei-mal hintereinander angewendet sehen. Aus einer Virtual Machine mit WindowsXP heraus sendeten wir uber das Programm

”EditTCP“ (siehe Anhang A.1)

Pakete der Lange’1‘ . In Abbildung 18 ist zu sehen, dass diese bereits innerhalb

der Virtual Machine zur Lange 2 zusammengefasst wurden.

Abbildung 18: der Nagle Algorithmus innerhalb der Virtual Machine

Im eigentlichen Betriebssystem (wieder Windows XP) werden diese Pake-te der gleichen Verbindung nocheinmal deutlich zusammengefasst, wie in derAbbildung 19 zu sehen ist.

31

Abbildung 19: der Nagle Algorithmus außerhalb der Virtual Machine

32

A Tools

A.1 EditTCP

A.1.1 Uber das Programm

Wir haben dieses C++ - Programm entwickelt, um damit moglichst einfach undschnell Parameter des TCP/IP-Stacks unter Windows (getestet unter WinXPProf. und Vista Home Premium) zu andern. Es macht ein aufwandiges Suchenund Editieren der Parameter der einzelnen Netzwerkadapter uberflussig. Wei-terhin ist das Speichern der Einstellungen moglich. So konnen die Einstellungensehr bequem auf andere Computer ubertragen werden.

Die Registry-Subschlussel der einzelnen Parameter sind in einer extra Datei(config.txt) gesichert, so dass es ohne weiteres moglich ist das Programmauf andere Windows-Versionen zu portieren, bzw. falsche Pfadangaben undWerttypen zu korrigieren.

Man kann mit diesem Programm auch Verbindungen aufbauen, um daruberDaten zu ubertragen. So ist es moglich die veranderten Einstellungen zu testenund zum Beispiel mit Wireshark (siehe Kapitel A.2) zu analysieren. Hierfurkann EditTCP sowohl als Server, als auch als Client fungieren.

Die Datenubertragung geschieht uber die Socket-Funktionen accept, bind,connect, listen, select, recv, send. Genaue Beschreibungen dieser Funktio-nen und deren Parameter sind leicht im Internet oder in der MSDN vonMicrosoft [9] zu finden.

Im Folgenden soll kurz die Oberflache des Programmes erklart werden.

33

A.1.2 Das Hauptfenster

Abbildung 20: EditTCP - Das Hauptfenster - Server-Modus

34

Abbildung 21: EditTCP - Das Hauptfenster - Client-Modus

Nummer Beschreibung

1 zeigt die IP des Zielcomputers

2 zeigt den Port des Zielcomputers

3 zeigt Anzahl der aufzubauenden Verbindungen

4 der Status der Winsock

5 startet das Empfangen

5a baut die Verbindung(en) auf und startet dasSenden

6 beendet das Senden oder Empfangen (je nach-dem, ob Client oder Server)

7 legt den Betriebsmodus des Programmes fest

8 ruft die Einstellungen des Programmes auf

9 startet den Computer neu (nach Anderungender Registry notwendig)

10 beendet das Programm

11 zeigt die Verbindungen und ihre Informationenan

35

A.1.3 Allgemeine Optionen

Abbildung 22: EditTCP - Allgemeine Optionen

36

Nummer Beschreibung

1 legt den Haupt-Registry-Pfad fest

2 wenn aktiviert, werden in einer Endlosschleifezwischen 0 und der gewahlten Obergrenze ge-sendet (Client-Modus)

3 wenn aktiviert, wird die ausgewahlte Datei ge-sendet (Client-Modus)

4 legt die IP des Zielcomputers fest (Client-Modus)

5 legt den Port des Zielcomputers fest (Client-Modus)

6 legt die Anzahl der aufzubauenden Verbindun-gen fest (Client-Modus)

7 legt den zu uberwachenden Port fest (Server-Modus)

8 legt die Anzahl der zu uberwachenden Verbin-dungen fest (Server-Modus)

9 ladt vorhandene Einstellungen

10 speichert die aktuellen Einstellungen

11 blendet die Optionen aus

37

A.1.4 TCP/IP-Einstellungen

Abbildung 23: EditTCP - TCP/IP-Einstellungen

Nummer Beschreibung

1 Auswahl der vorhandenen Netzwerkadapter

2 Informationen zum gewahlten Adapter

3 liest die Einstellungen des Adapters aus der Re-gistry

4 schreibt die Einstellungen des Adapters in dieRegistry

5 Parameter des TCP/IP-Stacks

38

A.1.5 Andern der Registry

1. Um die Parameter des TCP/-IP-Stacks zu verandern, startet man EditT-CP und klickt auf

”Einstellungen“. Es offnet sich das Fenster mit den

Optionen.

2. Man wahlt nun die Registerkarte”TCP-Parameter“, um zu den TCP-

Parametern zu gelangen.

3. Als nachstes wahlt man links oben den Netzwerkadapter, den man ma-nipulieren mochten. Es werden nun rechts daneben Informationen zumgewahlten Adapter angezeigt.

4. Nun ist es moglich die Parameter zu andern. Jedoch kann man auch erstdie aktuellen Parameter des Adapters auslesen, indem man auf

”Regis-

try auslesen“ klickt. Die Textfelder der Parameter werden entsprechendgefullt. Leere Textfelder bedeuten, dass die Schlussel nicht vorhandensind und das System Standardeinstellungen benutzt (siehe 1.1.2, Seite5). Sollten man diese Schlussel anlegen, wird das System diese in Zukunftnutzen.

5. Um die vorgenommenen Anderungen zu sichern, klickt man auf”Registry

schreiben“. Man beachte unbedingt, dass EditTCP in dieser Version diegemachten Einstellungen nicht uberpruft! Man muss also selbst Sorge furdie korrekten Werte tragen! Genaueres ist im Anhang B ab Seite 46 zuerfahren.

6. Damit die Einstellungen wirksam werden, klickt man auf”Zuruck“ 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

Fur einen Datenaustausch ist es notig zwei Instanzen von EditTCP zu starten.Dies kann, muss aber nicht auf unterschiedlichen Computern passieren. Manmuss bei mehreren Computern sicherstellen, dass die IP-Adressen oder derHostnamen bekannt sind, da diese Angaben fur den Client wichtig sind.

39

Es ist zu beachten, dass einige hier verwendete Socket-Funktionen blockie-rend sind! Auch wenn EditTCP vorlaufig nicht reagiert, heißt dies nichtzwangslaufig, dass es abgesturzt ist!

Server

1. Sofern man EditTCP gestartet hat, klicken man auf”Einstellungen“, um

die Parameter fur 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 uberwacht werden soll.

4. Nun klickt man auf”Zuruck“ und wahlt 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 derUbertragung 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 Ubertragung unendlich fort-gefuhrt oder die Datei vollstandig gesendet wurde (je nach Betriebsmo-dus).

Client

1. Sofern man EditTCP gestartet hat, klickt man auf”Einstellungen“, um

die Parameter fur den Verbindungsaufbau festzulegen.

2. Hier findet man unter der Registerkarte”Allgemein“ allgemeine Optio-

nen.

3. Hier wahlt 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 dafur vorgesehene Textfeldeintragt.

5. Nun man unter”Client-Modus“ die Portnummer ein, uber welche die

Programme kommunizieren sollen. Diese muss unbedingt im Server undClient gleich sein!

6. Man legt nun unter”Client-Modus“ noch fest, wieviele Verbindungen

aufgebaut werden sollen. Uber alle Verbindungen werden die gleichenDaten gesendet. Man findet diese nach der Ubertragung durchnummeriertim Verzeichnis

”incomming“ im Anwendungsverzeichnis des Servers.

7. Nun klickt man auf”Zuruck“ und wahlet 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 Ubertragung 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 Ubertragung unendlich fortgefuhrtoder die Datei vollstandig gesendet wurde (je nach Betriebsmodus).

A.2 Wireshark

Wireshark (ehemals Ethereal) ist wohl eines der bekanntesten und machtigstenTools zur Netzwerkanalyse und soll an dieser Stelle kurz erlautert werden. DasProgramm 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 denProtokoll-Stack und fangt den Netzwerkverkehr ab [7]. Je nach Betriebssys-tem ist es die

”libpcap“ (Linux) oder die

”WinPcap“ (Windows) Bibliothek,

die das zur Verfugung stellt. Es ist also moglich mit Wireshark die gesamteNetzwerkkommunikation mitzuschneiden und zu analysieren. Man kann ausallen empfangenen Paketen (siehe Abbildung 24, rot hinterlegt) ein einzel-nes auswahlen und dessen Details betrachten (siehe Abbildung 24, blau undgelb hinterlegt), wobei Wireshark einmal versucht die Bytes selbst Protokollenzuzuordnen und einmal alles Empfangene in hexadezimaler Schreibweise dar-stellt. Weiterhin bietet Wireshark eine Vielzahl von Optionen und Filtern, umganz gezielt nach Informationen zu suchen. Auch kann das Programm spezielleStatistiken (Datendurchsatz...) erstellen. An dieser Stelle sei hiermit auf diefolgende Internetseite verwiesen:

http://www.nwlab.net/tutorials/ethereal/ethereal-tutorial.html

42

Dort findet man ein gutes deutschsprachiges Tutorial, welches den Einstiegin Wireshark sehr erleichtert.

43

B technische Referenz

B.1 sonstige Parameter unter Linux

Die Beschreibung wurde teilweise von Oskar Andreasson ubernommen [10].

1. tcp adv win scale

Wert: ganze ZahlStandardwert: 2Beschreibung: Steuert das Verhaltnis von Anwendungs- zu

TCP-Windowspeicher eines Sockets (Gleichungfur positive Werte: 1

2tcp adv win scale , fur negativeWerte: 1− 1

2−tcp adv win scale , fur 0: keine Reservie-rung).

2. tcp app win

Wert: naturliche ZahlStandardwert: 31Beschreibung: Sagt dem Kernel wieviel Speicher fur ein spe-

zifisches TCP-Window verwendet werden soll(Gleichung: window

2tcp app win , fur 0: keine Reservie-rung).

3. tcp fin timeout

Wert: naturliche ZahlStandardwert: 60 (Sekunden)Beschreibung: Gibt an wie lange auf ein

”FIN“ des Kommu-

nikationspartners gewartet werden soll, bis dieeigene Verbindung beendet wird.

44

4. tcp mem

Wert: “naturliche Zahl naturliche Zahl naturlicheZahl

”Standardwert: keinerBeschreibung: Gibt den Speicher in Speicherseiten (norma-

lerweise 4kb) an, der dem TCP-Stack zurVerfugung steht. Der 1.Wert gibt den Speicheran, der auf jeden Fall zur Verfugung gestelltwerden soll, der 2. die Grenze, ab der versuchtwerden soll Speicher durch Kompression zu spa-ren und der 3. die maximale Grenze.

5. tcp orphan retries

Wert: naturliche ZahlStandardwert: 7Beschreibung: Definiert wie oft versucht werden soll an die Ge-

genseite ein”FIN“ zu senden, bevor bei Misser-

folg die eigene Verbindung schließlich abgebautwird.

6. tcp rmem


”Standardwert: keinerBeschreibung: Setzt den Speicher in Byte fur das Empfangs-

fenster wobei der 1. Wert das Minimum ist, der2. der default (Startwert) und der 3. das Maxi-mum.

7. tcp wmem


”Standardwert: keinerBeschreibung: Setzt den Speicher fur das Sendefenster und

funktioniert ansonsten genauso wie tcp rmem.

45

B.2 Parameter unter Windows

Im Folgenden werden die veranderbaren TCP-Schlussel der Windows XP-Registrybeschrieben [5]. Dabei wird jeweils kurz auf die Funktion bzw. Auswirkung desKeys und seiner Parameter eingegangen. Weiterhin wird die genaue Positionangegeben.

Das Andern der Registry-Werte kann unter Umstanden zu Problemenfuhren! Es wird daher dringend empfohlen ein Backup der Registry zuerstellen, bevor etwas geandert wird. Weiterhin wird fur die Richtigkeitder folgenden Einstellungen keine Garantie ubernommen. Es sei hiermitauf die entsprechende Internetseite http://support.microsoft.com/kb/

314053/de von Microsoft verwiesen. Dort sind noch einige weitere Para-meter zu finden (speziell IP-Parameter). Weiterhin gibt es viele Tuning-Seiten, die weitere Einstellungsmoglichkeiten aufzeigen, die nicht auf derMicrosoft-Seite zu finden sind (Bsp.: [8])!

1. DatabasePathSchlussel: Tcpip\Parameters

Werttyp: Zeichenfolge (REG EXPAND SZ)Wert: gultiger Windows NT-DateipfadStandardwert: %SystemRoot%\System32\Drivers\Etc

Beschreibung: gibt Pfad zu den Standard-Internetdatenbankdateien (HOSTS, LM-HOSTS, NETWORKS, PROTOCOLS) an(wird von der Windows Sockets-Schnittstelleverwendet)

2. EnableDeadGWDetectSchlussel: 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 Segmentmehrmals ohne Ruckmeldung gesendet wurde)0: Dead Gateway Detection deaktiviert

46

3. EnablePMTUBHDetectSchlussel: 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 erken-

nen0: Black-Hole-Router-Erkennung deaktiviert

4. EnablePMTUDiscovery

Schlussel: 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 (moglicheFragmentierung kann unterbunden werden)0: MTU von 576 Byte fur alle Verbindungen, dienicht zu Computern im lokalen Subnetz gehen

5. GlobalMaxTcpWindowSize


Werttyp: Zahl (REG DWORD)Wert: 0 - 65535 (mit Window-Scaling: 1073741823)Standardwert: 65535 (TRUE)Beschreibung: dies ist die maximale Windowsize fur Verbin-

dungen (TcpWindowSize kann nicht großer alsdieser Parameter sein)

47

6. KeepAliveInterval


Werttyp: Zeit in Millisekunden(REG DWORD)(eventuell REG QWORD)

Wert: 1 - 4294967295Standardwert: 1000 (eine Sekunde)Beschreibung: gibt das Zeitintervall zwischen Keepalive-

Neuubertragungen an

7. KeepAliveTime


Werttyp: Zeit in Millisekunden(REG DWORD)(eventuell REG QWORD)

Wert: 1 - 4294967295Standardwert: 7200000 (zwei Stunden)Beschreibung: gibt das Zeitintervall nachdem ein Keepalive-

Pakets gesendet wird, wenn Verbindung imLeerlauf

8. MTUSchlussel: Tcpip\Parameters\Interfaces\Adapter-ID

Werttyp: Zahl (REG QWORD)Wert: 68 - vom Netzwerk unterstutzte maximale Pa-

ketgroßeStandardwert: 4294967295Beschreibung: gibt maximale Paketgroße in Byte an

9. Tcp1323Opts

Schlussel: Tcpip\Parameters\Interfaces\Adapter-ID

Werttyp: Zahl (REG DWORD)Wert: 0, 1, 2 oder 3Standardwert: 0Beschreibung: 3: aktiviert Window-Scaling und Timestamps

2: aktiviert nur Timestamps1: aktiviert nur Window-Scaling0: deaktiviert Window-Scaling und Timestamps

48

10. TcpMaxConnectRetransmissions


Werttyp: Zahl (REG DWORD)(eventuellREG QWORD)

Wert: 0 - 4294967295Standardwert: 2Beschreibung: gibt Anzahl der Verbindungsanforderung

(SYN) an, bevor der Versuch abgebrochenwird (Zeituberschreitungswert wird bei jedererneuten Ubertragung verdoppelt. Startwertbetragt drei Sekunden.)

11. TcpMaxDataRetransmissions


Werttyp: Zahl (REG DWORD)(eventuellREG QWORD)

Wert: 0 - 4294967295Standardwert: 5Beschreibung: gibt Anzahl der Ubertragungsversuche fur ein-

zelne Datensegmente an, bevor die Verbindungabgebrochen wird (Zeituberschreitungswertwird bei jeder erneuten Ubertragung verdop-pelt. Startwert wird nach Round-Trip Timeermittelt.)

12. TcpNumConnections


Werttyp: Zahl (REG DWORD)Wert: 0 - 16777214Standardwert: 16777214Beschreibung: maximale Anzahl der gleichzeitig geoffneten

Verbindungen

49

13. TcpRecvSegmentSize


Werttyp: Zahl (REG DWORD)Wert: 0 - 16777214Standardwert: 1460Beschreibung: Platz, der fur die Nutzdaten zur Verfugung

steht

14. TcpSendSegmentSize


Werttyp: Zahl (REG DWORD)Wert: 0 - 16777214Standardwert: 1460Beschreibung: Platz, der fur die Nutzdaten zur Verfugung

steht

15. TcpTimedWaitDelay


Werttyp: Zahl (REG DWORD)Wert: 30 - 300Standardwert: 120Beschreibung: Zeitdauer, die eine Verbindung im TIME

WAIT-Zustand bleibt (Socketpaar kann nichtneu verwendet)

16. TcpUseRFC1122UrgentPointer


Werttyp: Boolescher Wert (REG DWORD)Wert: 0 oder 1 (FALSE oder TRUE)Standardwert: 0 (FALSE)Beschreibung: 1: fur dringende Daten die RFC 1122-

Spezifikation0: Modus von BSD-abgeleiteten Systemen (Ber-keley Software Design)

50

17. TcpWindowSize

Schlussel: Tcpip\Parameters\Interfaces\Adapter-ID

Werttyp: Zahl (REG DWORD)Wert: 0 - 65535 (mit Window-Scaling: 1073741823)Standardwert: 16384 (abhangig von Netzwerktyp)Beschreibung: maximale vom System angebotene TCP-

Empfangsfenstergroße fur eine Verbindung

18. SackOpts


Werttyp: Boolescher Wert (REG DWORD)Wert: 0 oder 1 (FALSE oder TRUE)Standardwert: 0 (FALSE)Beschreibung: 1: aktiviert Selective Acknowledgements

0: deaktiviert Selective Acknowledgements

Es kann unter Umstanden 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 InformationProcessing Techniques Office/Information Sciences Institu-te University of Southern California (Hrsg.): TRANSMISSIONCONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOLSPECIFICATION. September 1981. – URL http://tools.ietf.org/

html/rfc793. – Zugriffsdatum: 25.05.2007

[2] ISO/IEC (Hrsg.): Information Technology - Open Systems Inter-connection - Basic Reference Model: The Basic Model. 1994. – URLhttp://standards.iso.org/ittf/PubliclyAvailableStandards/

s020269_ISO_IEC_7498-1_1994(E).zip

[3] Microsoft Corporation (Hrsg.): Next Generation TCP/IP-Stackunter 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 NBT-Konfigurationsparameter fur Windows XP. Januar 2007. – URLhttp://support.microsoft.com/kb/314053/de. – Zugriffsdatum:21.05.2007

[6] Wikipedia (Hrsg.): Transmission Transport Protocol. Mai 2007. – URLhttp://de.wikipedia.org/wiki/Transmission_Control_Protocol. –Zugriffsdatum: 24.05.2007

[7] Loris Degioanni: WinPcap: The Windows Packet Capture Libra-ry. Januar 2007. – URL http://www.winpcap.org/. – Zugriffsdatum:30.05.2007

[8] Matt Mathis, Raghu Reddy: Enabling High Performance DataTransfers. 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 OSI-Stack vs. TCP/IP-Stack . . . . . . . . . . . . . . . . . . . . 82 Der TCP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Der TCP-Pseudo-Header . . . . . . . . . . . . . . . . . . . . . . 144 TCP-Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . 155 TCP-Verbindungsabbau . . . . . . . . . . . . . . . . . . . . . . 186 Windowsize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Windowsize mit Scaling-Option . . . . . . . . . . . . . . . . . . 208 TCP-Retransmission Timeout . . . . . . . . . . . . . . . . . . . 229 TCP-Retransmission Timeout 2 . . . . . . . . . . . . . . . . . . 2310 TCP-Keep-Alive Timeout . . . . . . . . . . . . . . . . . . . . . 2411 TCP-Keep-Alive-Timeout 2 . . . . . . . . . . . . . . . . . . . . 2512 TCP-PersistenceTimer . . . . . . . . . . . . . . . . . . . . . . . 2613 Sliding Window: Start (Senden Byte 1 und 2) . . . . . . . . . . 2714 Sliding Window: Empfang von Byte 1 und 2 . . . . . . . . . . . 2815 Sliding Window: Acknowledgment Byte 1 und 2 . . . . . . . . . 2816 Zero Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2917 Silly Window-Syndrom . . . . . . . . . . . . . . . . . . . . . . . 3018 TCP-Nagle Algorithmus1 . . . . . . . . . . . . . . . . . . . . . . 3119 TCP-Nagle Algorithmus2 . . . . . . . . . . . . . . . . . . . . . . 3220 EditTCP - Das Hauptfenster - Server-Modus . . . . . . . . . . . 3421 EditTCP - Das Hauptfenster - Client-Modus . . . . . . . . . . . 3522 EditTCP - Allgemeine Optionen . . . . . . . . . . . . . . . . . . 3623 EditTCP - TCP/IP-Einstellungen . . . . . . . . . . . . . . . . . 3824 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

54

· Netzwerkzugang (OSI-Schicht 1 + 2): Diese Schicht enth˜alt kein vorgeschriebenes Protokoll und...

Documents

Transcript of · Netzwerkzugang (OSI-Schicht 1 + 2): Diese Schicht enth˜alt kein vorgeschriebenes Protokoll und...