Rheinisch-WestfalischeTechnischeHochschuleAachenLehrstuhlfur Informatik IVProf.Dr. rer. nat.OttoSpaniol

TCP/UDP und Varianten

Seminar:Kommunikationsprotokolle SS02

Dirk SabathMatrikelnummer:228752

Betreuung: MarkusFidlerLehrstuhlfur Informatik IV, RWTH Aachen

Inhaltsverzeichnis

1 Einleitung 3

2 Grundlagen 3

3 UserDatagram Protocol 4

3.1 DerUDP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 FragmentierungdurchIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 TransmissionControl Protocol 7

4.1 DerTCP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.2 Verbindungsaufbau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.3 Verbindungsabbau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.3.1 VerbindungsabbauperHalf Close . . . . . . . . . . . . . . . . . . . . . . . 10

4.3.2 SimultanerVerbindungsabbau. . . . . . . . . . . . . . . . . . . . . . . . . 11

4.3.3 ReseteinerVerbindung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.4 Datentransfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.5 Verbindungssicherheit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.5.1 ErkennungvonSegmentverlustaufSenderseite. . . . . . . . . . . . . . . . 13

4.5.2 ErkennungvonSegmentverlustaufEmpfangerseite. . . . . . . . . . . . . . 14

4.5.3 Roll-Back-N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Flow- und Congestioncontrol in TCP 15

5.1 Sliding Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.2 NagleAlgorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.3 DelayedAcknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.4 Slowstart/CongestionAvoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Varianten von TCP 18

6.1 TCP-Tahoe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.2 TCP-Reno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.3 SACK-TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2

1 Einleitung

SeitderEntstehungdesARPANET, demVorlauferdesInternet,hatdieBedeutungheterogenerNetz-werke starkzugenommen.DabeiauftretendeSchwierigkeitensindnicht nur dasVernetzenvon sehrunterschiedlichenRechnersystemen,sondernauchdie verschiedenenNetzwerktopologienund diedadurchentstehendeunterschiedlicheGute von Verbindungenim Netzwerk.Auch ist eineeinheit-liche ProgrammierschnittstelleunabdingbareVoraussetzungfur ein heterogenesNetzwerk,denneswird sichkaumein Menschdie Arbeit machenwollen, sich fur jedeserdenkbareSystemund jedenvorstellbarenAnwendungszweckmit anderenSchnittstellenvertrautzu machen.Daherwird ein fle-xiblesProtokoll wie dasTransmissionControl Protocol (TCP)benotigt, ein verbindungsorientiertesProtokoll, dassdie DienstedesInternetProtokoll (IP) nutzt,und eineProgrammierschnittstellezurVerfugungstellt,dieesmoglichmacht,unabhangigvonderNetzwerktopologieundderVerbindungs-qualitat zuprogrammieren.TCPist mittlerweilefur alle gangigenSystemeverfugbar, meistensist esschonmehroderwenigerfestim Betriebssystemverankert.Da esin der Vergangenheitwegenzu hohemDatenverkehr zu Verbindungszusammenbruchenkam,wurdeesnotwendigVariantenvonTCPzuentwickeln,dievor allemzusatzlicheFluss-undStaukon-trolle beherrschen,umUberlastungendesNetzwerksvorzubeugen.NebendemverbindungsorientiertemTCP gibt esnochein verbindungslosesGegenstuck, dasUserDatagramProtocol (UDP).Auf diesesProtokoll mochteich zuersteingehehen,daesnicht nur zeit-lich vorTCP(wennauchnurkurz)liegt,sondernauchaufdertechnischenSeite,alleinschonaufgrundderVerbindungslosigkeit einfacherist.

2 Grundlagen

Um einenUberblickzuerhalten,wasein in derTransportschichtangesiedeltesProtokoll leistensoll,ist ein kurzerBlick aufdie Transportschichtunabdingbar.Die Transportschichtist im ISO/OSI-Referenzmodellalsvierte Schichtzwischender Vermittlungs-schichtundderSitzungsschichtangesiedelt.Die TCP/IPProtkokollsuitemachteinegrobereAuftei-lung in nur vier Schichten,welcheim Folgendemerlautertwerden:Die untersteSchichtist dieLink-Schicht.SiebeinhaltetsehrhardwarenaheDienste,wie zumBeispielNetzwerkkartentreiber. Hier ist auchAddressResolutionProtokoll (ARP) [5] enthalten,dasfur dieZuordnungvonIP-AdressenzuHardwareadressen(MAC) zustandigist.EsschicktdazueinEthernet-Frameanalle Hostsin einemNetzwerk,in demdie MAC-Adressezu einerIP-Adresseangefordertwird (ARP-Request),woraufhinsich der entsprechendeHost meldet,indemer mit einemEthernet-framemit derentsprechendenMAC- sowie IP-Adresseantwortet (ARP-Reply).ARP verwendeteinCache,umAdressenfur einengewissenZeitraumzwischenzuspeichern.In der Netzwerkschichtist das Internet Protocol (IP) und das Internet Control Message Protocol(ICMP) interessant,dennvor allem auf die Dienstevon IP bautdie Transportschicht auf. Sie bein-haltetTCPundUDP undstellt denin derApplication-Schichtzu findendenAnwendungen,wie z.B.FTP, Email, usw. einenDienst bereit.Einer der Hauptgrunde,Netzwerk-und Transportschichtzu

3

trennen,bestehtdarin,dassdieNetzwerkschichtnichtklar vonderverwendetenNetzwerkarchitekturundHardwaregetrenntist,mit derTranssportschichtstehteinvonall demunabhangigerDienstbereit.Wichtig ist hierbeidie UnterscheidungzwischenProtokollen,die die Datagrammevon Hostzu Hostversenden,wie IP einesist und Protokollen, die Datagrammezwischenzwei Prozessenversenden,wie TCPundUDP. Bei ersteremwerdenIP-DatagrammeimmerzumnachstenRouterweitergeleitet,derdasDatagramanhandderangegebenenAdresseweiterleitet,bis derentsprechendeHosterreichtist, unddasPaketvomNetzwerkentfernt.IP definiertfur jedesDatagrameinemaximaleLebensdau-er einesDatagrams,die Timeto live (TTL). DiesebeimVersandauf einenStartwertgesetzt,undbeijedemHop, dendasDatagrampassierenmuss,wird siedekrementiert.Sollte sie0 werden,sowirddasDatagramverworfen.In derTransportschichtgilt es,zweiProtokollartenzuunterscheiden.Die verbindungslosenProtokol-le, wie UDPeinesist, bauenkeineexplizite VerbindungzumZiel auf.Eswird angenommen,dasderZielrechnerimmererreichbarundbereitist, Datenzu empfangen.UDP ist ausserdemein unsichererDienst(unreliable), d.h.eswird nicht sichergestellt,dassDaten,die versendetwurden,auchihr Zielerreichen.Esist leicht einzusehen,dassdieseProtokolle einenrechteinfachenAufbauhaben.Dem gegenuberstehendie verbindsorientiertenProtokolle wie TCP. Sie bauenimmer eineVerbin-dungzumZielrechneraufundstellensicher, dassderZielhostzueinerKommunikationbereitist.TCPist einsichererDienst(reliable), d.h.hierwird demProzess,derTCPbenutzt,garantiert,dassalleDatenihr Ziel erreichen.BeidenProtokollen ist gemein,dasssievon mehrerenProzessengleichzei-tig benutztwerdenkonnen.DurchMultiplexingwerdeneingehendeDatendenProzessenzugeordnet.DazuwerdendenProzessenPortszugeteilt,anhanddererdieProzesseidentifiziertwerden.

3 UserDatagram Protocol

DasUserDatagramProtocol (UDP) [6] ist ein sehreinfachesProtokoll. Esarbeitetverbindungslos,dasheissteswird keineVerbindungzu einemHost aufgebaut.AnfallendeDatenwerdenvon UDPeinfachabgeschickt,ohnedassichergestelltwird, ob dasZiel uberhaupterreichbarist, oderob dasZiel bereit,ist Datenzu empfangen.Datenwerdenvon beliebigerGroßein Form von Datagrammenverschickt.Wennmansichnunvor Augenfuhrt, dassein NetzwerkkeineunendlichenKapazitatenbesitzt,wird schnellklar, dasssich der ProgrammiererdurchausGedanken uberdie Grosseder zuversendendenDatenmachenmuss.Ubersteigtdie entstehendeDatagrammgrosseeinenbestimmten,netzwerkabhangigenGrenzwert,soerfolgteineFragmentierungdurchdasin derVermittlungsschichtagierendeInternetProtokoll (IP). Dochdazuspatermehr.UDP stellt einemBenutzerprozesseinenDienstbereit.Da moglicherweisemehrereProzessediesenDienstin Anspruchnehmenmochten,benutztUDPPortnummern,umProzessezu identifizieren,furwelchedieDatenbestimmtsind(Multiplexing).Die PortnummernsindausdemBereich0-65535freiwahlbar. EinigesindjedochbestimmtenAnwendungenstandardmassigzugewiesen,allerdingsnichtverbindlich.

4

3.1 Der UDP-Header

Zunachstwerfenwir einenBlick auf denHeadereinesUDP-Datagramms.Ein DatagrammbestehtauseinemKopf mit vier Felderndemein DatenblockvariablerGrossefolgt. Die FelderdesKopfssindwie folgt besetzt:

Abb. 3.1DerUDP-Header

� SourcePort(Bit 0 bis15, insgesamt16Bit)In diesesFeldschreibtderAbsenderseinePortadresse,anwelchederZielhostdemsendendenProzessDatenzuruckschickenkann.Esist nichtzwingendnotwendig,dassderHostaufdiesemPortbereitist, Datenzuempfangen.

� DestinationPort(Bit 16 bis31, insgesamt16 Bit)DiesesFeldbeinhaltetdenPortdesEmpfangersfur dendie Datenbestimmtsind.Anhanddie-serNummerwird dasDatagrammeinemBenutzerprozesszugeordnet.

� LangedesUDP-Datagramms(Bit 32 bis47, insgesamt16Bit)Hier ist die LangedesDatagrammsin Byte angegeben.Die LangebeinhaltetdasgesamteDa-tagramm,alsoKopf und Datenzusammen.Die Angabeder Langeist redundant,da sie sichsehrleicht ausderangegebenenLangeim IP-Headererrechnenlasst.Da bei IP fur die Langeebenfalls ein 16-Bit Feld reserviertist, siehtman,dassdie Datenmengein einemDatagrammbeschranktist auf65535Byte - 20 Byte (IP-Header)- 8 Byte (UDP-Header)= 65507Byte.

� ChecksumdesUDP-DatagrammsDie Angabeist optional,eswird aberempfohlensie immerzu verwenden.Wird sienicht ver-wendet,sosinddie 16 Bit mit Nullen zu fullen.Wird siebenutzt,berechnetsiesichwie folgt:Dem eigentlichenHeaderwird ein Pseudo-Headervorangestellt,der die IP-AdressedesAb-sendersunddesEmpfangers(jeweils 32 Bit), 8 Bit Nullen, die AngabedesProtokolls (8 Bit)und die LangedesDatagramms(16 Bit). Header, Pseudo-Headerund Datenteilwerdendannals16-Bit Wortermodulo2 aufaddiert.Hat derDatenteilungeradeLange,sowird er mit 8 BitNullen aufgefullt. DasErgebniswird im Einerkomplementin dasFeld geschrieben,daherist

5

esunterscheidbar, obdieChecksum0 (essinddannalleBits gesetzt)ist odergarkeineBerech-nungstattgefundenhat(keinBit gesetzt).Mansieht,dassdieLangezweimalin dieBerechnungderChecksumeingeht.Ist die Checksumfehlerhaft,so wird dasPaket verworfen und es findet keinerlei Ruckmel-dungstatt.Obwohl die Checksumoptional ist, sollte sie jedochimmer berechnetwerden,dadurchsie Modifikationen(durchfehlerhafteVerbindungo.a.) erkanntwerdenkonnen.Aller-dingskanneineVertauschungvon16-Bit Worternnichterkanntwerden,einNachteilderrechteinfachenBerechnung.

3.2 Fragmentierung durch IP

Die Datenmenge,die in einemPaket im Netzwerkverschicktwerdenkann,ist durchdie in derLink-SchichtfestgelegteMaximumTransferUnit (MTU) [2] beschrankt.Daherwird ein sehrgrossesDa-tagrammunweigerlichzueinerFragmentierungdurchIP in derVermittlungsschichtfuhren.DadieseFragmentierung,d.h.eineAufteilungdesDatagrammsin mehrereIP-Datagramme,im Normalfall zueinemOverhead,bedingtdurchzusatzlichenPlatzfur IP-Header, fuhrt,solltesievermiedenwerden1.DaeineFragmentierunganjedemPunkt,dendasDatagrammpassierenmuss,geschehenkann,ist diekleinsteMTU in derVerbindungzwischendenHostszubestimmen,umdieFragmentierungunterbin-denzukonnen.DieskanndurchsetzendesDF-Bit (Do not fragment)im IP-HeaderundsendeneinesDatagrammsder Grosseder ausgehendenMTU geschehen.Kommt eineFehlerruckmeldungdurchICMP, so kannmanesmit einemDatagrammder im ICMP Paket angegebenenMTU desnachstenHop erneutversuchen.Solltedie Angabeim ICMP Paket nicht erfolgt sein,sosetztmandie GrossedesDatagrammsbeliebigherab.Durch Fragmentierungkannein weitererEffekt zwischenUDP undARP auftreten.Wennder ARPCacheleerist, dannimpliziert einverschicktesDatagrammeinenARP-Request,undeswird einRep-ly erwartet,umdenanderenHostadressierenzukonnen.Da IP dieFragmentesehrschnellgeneriert,wird zu jedemFragmenteinARP-Requestabgeschickt(ARP-flooding).NachdererstenAntwort aufeineAnfragewird dasletzteFragmentgesendet,daeinFragmentim Puffer uberschriebenwird, wenneinneuesankommt.EstretenkeineFehlermeldungendurchICMP auf,daICMP denBenutzerprozessnicht daruberinformierenkann.IP mussnachdemAblauf einesTimeoutsdasempfangeneSegmentverwerfen,damitesnicht zu einemUberlaufdesEmpfangspufferskommt.DasfragmentierteData-grammmussdanacherneutvomBenutzerprozessgesendetwerden.

Aus demObigemerkenntman,dasUDP keineVerbindungssicherheitgarantierenkann,unddeshalbfur Dienste,die dies erfordern,nicht sehrgeeignet2 ist. So eignetsich UDP wegendesgeringenVerwaltungsaufwandeherfur Anwendungen,die eineschnelleVerbindungerfordern,aberbei denenVerlustevonDatennicht sehrbedeutendist.

1Im Prinzipist eshieregal,werdieFragmentierungdurchfuhrt,klar ist, dasssiedurchgefuhrtwerdenmuss,daeinzugrossesDatagramnicht vonderLink-Schichtnicht versendetwird

2nicht sehrgeeignetheisst,esist moglich, jedochnotigt esdemProgrammierernurzusatzlicheArbeit auf

6

4 TransmissionControl Protocol

DasTransmissionControl Protocol(TCP)arbeitetim Gegensatzzu UDP verbindungsorientiert,d.h.eswird zwischenzwei Hosts,die miteinanderkommunizierenwollen, eineVerbindungaufgebaut.DadurchkannVerbindungssicherheitrealisiertwerden.Sowird einDienstzurVerfugunggestellt,derdie zugrundeliegendeNetzwerkarchitekturdenBenutzerprozessentransparentmacht,d.h. esist fureineAnwendungirrelevant,wie dasNetzwerkuberdaskommuniziertwird aufgebautist.TCP teilt zu versendendeDatenselbststandig in Segmenteauf, die einzelnverschicktwerden.Esergibt sichein Byte-StromorientierterDienst.EineAnwendungkannalsokontinuierlichDatenver-senden,waseinegewisseAhnlichkeit mit demSchreibenundLesenvonDateienhat.Zuverlassigkeit erhalt eineTCP-VerbindungdurchdasBestatigenjedesSegments.WerdenSegmentenichtbestatigt,somussensiewiederholtwerden.DadurchkonnenauftretendeUbertragungsfehlerimNetzwerkbehobenwerden.Es gibt aberauchMechanismen,die die versuchen,durchUberlastungeinesHostsoderdesNetzwerkshervorgerufeneFehlerzuvermeiden.DieseMechanismenzahlt manzur Fluss-undStaukontrolle.EffizienteMechanismenzur Fluss-undStaukontrollesindin denVari-antenvonTCP, wie TCPTahoe,TCPRenoundTCP-SACK, implementiert.TCParbeitetim Fullduplex Modus, d.h.eskonnengleichzeitigin beideRichtungenubereineVerbin-dungDatengesendetwerden.Sowird meistensderEmpfangvonSegmentenin Segmentenbestatigt,die selbstwiederumDatenenthalten(Piggyback).

4.1 Der TCP-Header

Betrachtenwir zunachstdie FormderSegmente,die vonTCPverschicktwerden.Ein SegmentbestehtauseinemHeader, dessenGrossezwischen20 Byte und60 Byte variiert. Demangehangtist derDatenteilvon ebenfalls variablerGrosse.Im Headerenthaltensind(in dieserRei-henfolge):

� 16 Bit SourcePort

� 16 Bit DestinationPortWie UDP verwendetauchTCP Portsum eingehendeSegmenteden Anwendungsprozessenzuzuordnen.

� 32 Bit SequenceNumberDie hier angegebeneSequenznummerzeigt an,anwelcheStelledasSegmentim Datenstromeinzusortierenist. DurchdieseNummerwird esmoglich,Paketein falscherReihenfolgezuzu-lassen,dasiesoin die ursprunglicheReihenfolgegebrachtwerdenkonnen.Bei einemVerbin-dungsaufbauist hier die StartnummerdesStroms,die Initial SequenceNumber(ISN), angege-ben.Siewird nachdemBootenmit einerZufallszahlinitialisiert.

7

� 32 Bit AcknowledgementNumberIn diesemFeldwird dieNummerdesSegmentsangegeben,dasalsnachsteserwartetwird. DieAngabeist immervorhanden,auchwennsiemanchmalnur fur eineRichtunggebrauchtwird.Diesist derFall, wenndie Verbindungnur in eineRichtungDatenverschickt.

� 4 Bit HeaderLengthDa die LangedesHeadersvariabelist, ist dieseAngabezwingend,um denDatenteildesSeg-mentserreichenzukonnen.

� 6 Bit reserviertDieseBits werdenbishernicht verwendet.

� 6 Bit OptionsHier sindFlagsin derfolgendenReihenfolgeanzutreffen:

– URG: Ist diesesBit gesetzt,sowird signalisiert,dassderUrgentPointergesetztwurde.

– ACK : DiesesBit zeigt an,dasdie AcknowledgementNumbergesetztist. Ein Segmentmit gesetztemACK-Bit wird im folgendemalsQuittungbezeichnet.

– PSH: Ist dasBit gesetzt,somussendie enthaltenenDatensoschnellwie moglichandenzustandigenBenutzerprozessweitergeleitetwerden.

– RST: DiesesBit veranlasstdasZurucksetzenderVerbindung.

– SYN : DiesesBit zeigt demGegenuberan,daseineVerbindungaufgebautwerdensoll.EswerdendieSequenznummernsynchronisiert.

– FIN : Mit diesemBit signalisiertder Sender, dasser keineweiterenDatenzu versendenhatunddie Verbindungschliessenmochte.

� 16 Bit Window SizeHier wird derfreie Platzim Empfangspuffer angegeben.DieseAngabewird fur die VerfahrenzurFluss-undStaukontrollebenotigt.

� 16 Bit ChecksumDie ChecksumberechnetsichanalogzuderChecksumeinesUDP-Datagramms.

� 16 Bit UrgentPointerDerUrgentPointerzeigtaufdasletzteBytedringenderDatenim Datenteil.DieseDatenwerdendannumgehend,d.h.unabangigvon derReihenfolgeim Datenstrom,andenBenutzerprozessweitergeleitet.

� Am EndedesHeaderskonnenweitereOptionenangehangtsein.DieseOptionenhabeneinenzugeordnetenTyp,mit demmandieOptionidentifiziertwird. Ist eineOptionnureinFlag,dannreichtdieAngabedesTyps,sonstmussnachdemTyp diegesamteLangederOptionangegebenwerden,woraufdanndieeigentlicheOptionfolgenkann.Die gesamteLangeist einVielfachesvon4 Byte.SamtlichemoglichenTypenkonnen[8] entnommenwerden.In derursprunglichenSpezifikation[7]sindfolgendeOptionenenthalten:

8

– EndOf OptionList (Typ 0)DieseOptionmarkiertdasEndederOptionenlisteim Header

– No Operation(Typ 1)DieseOptiondientzumAuffullenderGesamtlangeallerOptionenaufeinVielfachesvon4 Bytes

– MaximumSegmentSize(MSS)(Typ 2)Die LangedieserOption ist 4 Bytes,denneswird hier die maximalerlaubteSegment-grossein 2 Bytesangegeben.

Der Datenteilin einemTCPSegmentist optional.

4.2 Verbindungsaufbau

Esgibt zwei MoglichkeiteneineVerbindungaufzubauen.Die ersteMoglichkeit ist, dassdie Verbin-dungvoneinemHostinitiiert wird. Die zweiteMoglichkeit ist dersimultaneVerbindungsaufbau,beidemzweiHostsquasigleichzeitig,d.h.derzweiteHostinitiiert ebenfallseineVerbindungzumerstenHostnochbevor die erstereVerbindungsanforderungeingetroffen ist.

Im ersterenFall schicktder Initiator ein Segmentmit gesetztemSYN-Bit. DieserHostvollzieht einactiveopen. DieserSchritt wird im Normalfall von einemClient ausgefuhrt, dahersoll er ab jetztauchhier so genanntwerden.In demerstenPaket mit demSYN-Flaggibt er als SequenznummerseineInitial SequenceNumber(ISN) an.Die ISN ist dabeidie ersteSequenznummerdie verwendetwird. Der gegenuberliegendeHost fuhrt ein passiveopenaus.Er wird hier ab jetzt Server genannt.Er quittiert 3 die ISN desClients,undausserdemist dasSYN-Flaggesetzt,um anzuzeigen,dasserdenVerbindungsaufbauerwidert.Der Client quittiert wiederumdie ISN desServers.DieseArt desVerbindungsaufbaunenntsichThree-WayHandshake.Beim simultanenVerbindungsaufbauwird dagegenderAustauschvon vier Segmentenbenotigt, umdieVerbindungherzustellen.Hier fuhrenbeideHostseinactiveopendurch,in demsiefastgleichzei-tig Segmentemit gesetztemSYN-Bit undihrerISN verschicken.NachdemEmpfangdieserSegmentesendendieHostsQuittungen,mit denensiedie ISN desGegenubersbestatigenNachEmpfangdieserQuittungenist die Verbindunghergestellt.Der simultaneVerbindungsaufbaugeschiehteherzufallig,im Normalfall erfolgteineeinseitigeVerbindungsanforderung.EinezentraleRollebeiderSynchronisationderSequenznummernubernimmtdabeidieISN.Esist an-zustreben,dassjedeVerbindungeineeigeneISN zugeteiltbekommt,damitsiesichnicht gegenseitigbeeinflussen.Schliesslichkannmansichvorstellen,dasseinHostabsturztundeineneueVerbindungmit dengleichenVerbindungsdatenaufgebautwird. KommenalteSegmenteverspatetan,sokannespassieren,dassein altesSegmentfalschlicherweiseakzeptiertwird. Daherwird die ISN regelmassigperTimerundbei jedemVerbindungsaufbauiteriert.Sosoll sienach[7] alle4 Microsekundeninkre-mentiertwerden.Dadie ISN eine32Bit Zahl ist, wird sienachca.4,5Stundenuberlaufen.Unterder

3QuittungbezeichneteinSegmentmit gesetztemACK-Bit undentsprechenderACK-Nr.

9

Voraussetzung,dassdie maximaleLebensdauereinesSegmentskurzerist, kannsoeineZweideutig-keit ausgeschlossenwerden.

DurchdasSetzenderMSS-Optionim HeaderkonnensichdieHostsbeimVerbindungsaufbaumittei-len,welchedie grosstevon ihnenakzeptierteSegmentgroßeist.Wie obenbereitserwahnt,werdendie ProzesseubereinenPortadressiert.Solltewider ErwartenaufdemZielhostderVerbindunsanfragekeinProzessaufdemadressiertenPortlauschen,wird ein Resetgesendet,siehedazuauchdennachstenAbschnitt.Ein Resetwird ebenfallsgesendet,wennunerwartetAcknowledgementsfur Verbindungsanforderun-genankommen.Dies kanndurchunterschiedlicheRoutenim Netzwerkentstehen.Sollte eineVer-bindungsanforderungeinenlangenWeg im Netzwerkeingeschlagenhaben4, so trif ft die QuittungbeimSendernicht rechtzeitigein,waszurWiederholungdesSYN fuhrt.DiesesSYN kannnuneinenkurzerenWeg einschlagen,undeineVerbindungaufgebautundwiederabgebautwerden,bevor dasersteSYN seinZiel erreichthat. WenndasersteSYN nun seinZiel erreicht,wird esals erneuterWunscheinesVerbindungsaufbausbetrachtet.Eswird dannquittiert,dieseQuittungjedochbeimIn-itiator nicht mehrerwartet.DazumussderWeg deserstenSYN nur hinreichendlangsein,unddasSYN darfnicht von IP aufgrundeinerTTL von0 verworfenwerden.

4.3 Verbindungsabbau

4.3.1 Verbindungsabbau per Half Close

DerVerbindungsabbauwird durcheinHalf Closerealisiert.Dasbedeutet,dasseineSeitedenVerbin-dungsabbauanfordert,wennsiekeineDatenmehrzu sendenhat.Siebleibt aberin einemZustand,in demsienochDatenvom anderenHostempfangenkann.Der denVerbindungsabbauanforderndeHost fuhrt einenactiveclosedurch.Man sieht,dassbeideRichtungender Fullduplex-Verbindungunabhangigvoneinandergeschlossenwerden.Um die Senderichtungfur einenHostzu schliessen,schicktdieserein Segmentmit gesetztemFIN-Flag an denanderenHost.Dieserquittiert denEmpfang.Damit gilt eineRichtungder Verbindungalsgeschlossen.Der erstereHost befindetsichnun in einemZustand,in demer auf DatenodereinSegmentmit gesetztemFIN-Flag,dasanzeigt,dassnundie Verbindungganzabgebautwerdensoll,wartet.Der EmpfangdiesesSegmenteswird wiederumbestatigt. Nun mussder Host zweimaldieLangederMaximumSegmentLifetime(MSL) warten.Danachgilt dieVerbindungalsvollstandigab-gebaut5. DasWartenhatdenGrund,dassdie Quittungfur denVerbindungsabbauverlorengegangenseinkann.Da ein Paket nachAblaufender MSL verworfen wird, mussein wiederholtesSegmentmit FIN-Flaginnerhalbvon

����������� ������� ��������� ���� ��!#"%$&� '������ (�����() *+�-,/.0� ��!#"eingetroffen

sein.Dieshatzur Folge,dassinnerhalbderMSL nachdemBooteneinesSystemskeineVerbindungaufgebautwerdensollte,daesseinkann,dassdasSystemin diesemwartendenZustandabgesturztseinkann.Bei kurzerBootzeitkonntensonstdie Verbindungsparametereineralten,nicht vollstandig

4woraufTCPkeinenEinflusshat5DasentsprichtdemZustandTIME WAIT in Abb. 4.1

10

abgebautenVerbindungwiederverwendetwerden.NachdemVerbindungsaufbaumussdenProzes-senein End-Of-File(EOF)signalisiertwerden,dadiesevon nunannicht mehrauf denDatenstromzugreifenkonnen.

4.3.2 Simultaner Verbindungsabbau

Wie beimVerbindungsaufbaugibt esauchbeimAbbaudieMoglichkeit dessimultanenAbbaus.Hier-bei wird wiederumvorausgesetzt,dassbeideHostsgleichzeitigein Segmentmit gesetztemFIN-Bitabschicken.DieseSegmentewerdendannvonbeidenSeitenwie beimeinseitigenVerbindungsabbauquittiert. Auch wartenbeideHosts2*MSL bis siedie Verbindungalskomplettaufgelostbetrachten.Insbesondereliegt hierkein Half Closevor, sondernbeideRichtungengeltenalsgeschlossen.

4.3.3 Reseteiner Verbindung

NebeneinemVerbindungsabbaukanneineVerbindungauchzuruckgesetztwerden.Diesgeschieht,wenn ein Host ein Segmentmit gesetztemRST-Bit sendet.Das wird notwendig,wenn Segmenteempfangenwerden,dienichterwartetwerden,weil siez.B.auseineraltenVerbindungstammenodereine zu langeLaufzeit hattenund schonwiederholtwurden,oder dasssie einer falschenAdressezugeordnetwurden.

11

AnschaulichwerdenVerbindungsauf-undabbauim StateTransitionsDiagramin Abb. 4.1dargestellt[9].

Abb.4.1DasStateTransitionDiagram[9]

12

4.4 Datentransfer

Befindetsich die Verbindungim ESTABLISHED-Zustandim StateTransitionDiagram,odernachentsprechendemHalf Closeim ZustandCLOSE WAIT oder FIN WAIT, so konnenuber die Ver-bindungDatenverschicktwerden6. Die Benutzerprozesse,die perTCPmiteinanderkommunizierensehendieVerbindungalskontinuierlichenDatenstrom.Esist fur siedaherirrelevant,in welcherFormdieDatenverschicktwerden.Daherist AufgabevonTCP, dieDatensoin Segmenteaufzuteilen,dassdasNetzwerkoptimalgenutztwird7. MankannzweiArten desDatenaustauschsunterscheiden:1. InteraktiverDatenaustausch(InteractiveDataFlow [9])Hierbeiwerdennur wenigDatenausgetauscht,auf die aberin kurzerZeit reagiertwird. Dasimpli-ziertdasSegmenteabgeschicktwerdenmussen,auchwennnursehrwenigDatenanstehen.Die Folgeist, dassdieDatenmengeproSegmentim VergleichzumHeaderverschwindendgeringseinkann.Esentstehtein grosserOverheaddurchdie Header.2. Nicht interaktiverDatenaustausch(BulkData Flow [9])Es wird hauptsachlichin eineRichtunggesendet(z.B. Dateitransfer).Es ist dahersinnvoll, die ge-samteKapazitat desNetzwerksauszuschopfen,ohnedabeidie Verbindungzu uberlasten,denndaswurdezuunnotigemwiederholtemSendenvon Segmentenfuhren.

4.5 Verbindungssicherheit

Abschliessendbleibt nochdie Frageoffen, wasbei Verlustvon Segmentenin einemNetzwerkge-schieht.Da TCPeinezuverlassigeVerbindungbereitstellt,mussdafur Sorge getragenwerden,dasssolcheVerlusteerkanntundSegmentegegebenenfallswiederholtgesendetwerden.

4.5.1 Erk ennungvon Segmentverlust auf Senderseite

Dafur wird in [7] aufderSenderseiteeinTimergefordert,vor dessenAblauf eineQuittungeingetrof-fen seinmuss.Geschiehtdiesnicht, so mussdasSegmenterneutubertragenwerden.Es wird dazuein RetransmissionTimeout(RTO) berechnet.DieseBerechnungfindetnicht fur jedesSegmentstatt,vielmehr ist nur ein Timer pro Verbindunggefordert.Zunachstwird die SampleRoundTrip Timeberechnet,die einenErwartungswertfur die UmlaufzeiteinesSegmentesangibt.

�)21�13�4657�8)21�19$��;:�<94="=5>)21�1�?A@CB34�BD:RTT bezeichnethier die RoundTrip Time. Sie ist die tatsachlichgemesseneUmlaufzeiteinesSeg-ments.

4sollteum 0,8gewahltwerden[9], damitgehendann20%derneugemessenenund80%der

altenberechnetenUmlaufzeitin dieneueSRTT ein.DenRTO erhalt mandannaus[7]

)212E�GFIHKJMLNEPOQ?R��SUTVLXW2OQ?RY�5-�8)21�1�Z[Z�?\:]?A^CB_Y`Ba�6In denletzterenZustandennur in eineRichtung7Wasin diesemSinnoptimalheisstundwie eserreichtwird, wird im nachstenKapitel aufgezeigt

13

OG undUG bezeichneneinedefinierteOber- bzw. Untergrenzefur denTimeout.Y

bezeichneteinenVerzogerungsfaktor, derzwischen1,3und2 liegensollte[7], damiteinegeringeUberschreitungderberechnetenSRTT nicht sofortzu einerWiederholungdesSegmentsfuhrt 8. Der RTO enthalt einenganzzahligenWert,dadieUmlaufzeitderSegmentein Ticksgemessenwird. Die Tickserfolgenubli-cherweisein Abstandenvon 500ms.Esseiangemerkt,dassdieseTicks unabhangigvom StarteinerMessungder RTT laufen,wodurchein gemessenerRTT-Wert davon abhangt,wieviel Zeit seit demletztemTick vergangenist. Daherist dieserWert nicht eindeutig.Die Messungder Umlaufzeitge-schiehtmit einemZeitstempel,dessenWertderEmpfangerin dasOptionsfelddesQuittungssegmentseintragt.TCPreagiertauf denVerlusteinesSegmentsmit einerVerdoppelungder RTO bei jederwiederhol-tenSendungdesSegmentes,dadasNetzwerkstarkausgelastetzu seinscheint.SowurdedanneineWiederholungdesSegmentsbei gleichemRTO wahrscheinlicherneutzum Verlust fuhren.DiesesVorgehennenntmanExponentialBackoff [9].Solltennun wiederQuittungeneintreffen, so mussder RTO wiederangepasstwerden,da sich dieNetzwerkauslastungwiedernormalisierthabenkann,undein zu hoherTimeoutdazufuhrt, daswei-tereVerlusteerstsehrspat erkanntwerden.Der Zeitpunktder neuenBerechnungwird nachKarn’sAlgorithmus[9] bestimmt.DieserAlgorithmusbesagt,dassdie RTT neugemessen(und dannderRTO neuberechnet)wird, wennnacherfolgreicherWiederholungvonSegmentendasersteneueSeg-mentquittiertwordenist.

4.5.2 Erk ennungvon Segmentverlust auf Empfangerseite

Auf derEmpfangerseitewird gefordert,bei EmpfangeinesSegmentesmit falscherSequenznummerdasletzte in der richtigenReihenfolgeempfangeneSegmentwiederholtzu quittieren.Dashat zurFolge, dassbeim Senderdie QuittungeinesSegmentsmehrfacheintrifft. Der Senderkannso denVerlusteinesSegmentserkennen.Da esmoglich ist, dassein fehlendesSegmentnur verspatetbeimEmpfangereintrifft undeineWiederholungdaherunnotig ist, reagiertder Sendererstbei EmpfangderdrittendupliziertenQuittung.DannhatderSenderdiesesSegmentzuwiederholen.

4.5.3 Roll-Back-N

Roll-Back-N[1] ist dereinfachsteMechanismuszurSegmentwiederholung.SolltederRetransmission-Timerablaufen,bzw. derSenderdiedritteduplizierteQuittungerhaltenhaben,dannwerdenallenichtquittiertenSegmentewiederholt.Dabeiist esnichtvonBedeutung,obnachfolgendeSegmentebereitserfolgreichempfangenwurden.Roll-Back-Narbeitetdahernicht sehrressourcenschonend.Andere,effizientereMethodenzur Segmentwiederholungsind in Variantenvon TCPimplementiert.Siewerdenin Kapitel 6 vorgestellt.

8WurdegeradeeineunterdurchschnittlicheRTT gemessen,sowurdedasFehlendiesesFaktorssehrschnellzueinemtatsachlichnicht vorhandenemUbertragungsfehlerfuhren

14

5 Flow- und Congestioncontrol in TCP

TCPversuchtdasNetzwerkoptimalauszulasten.Optimalauslastenheisst,nacheinemerfolgreichemVerbindungsaufbaumoglichstschnelldenDatenflussauf ein Maximumzu erhohen,dabeiabernichtdasNetzwerkzu uberlasten.Diesgeschiehtin TCPmittelsFlow- undCongestioncontrol.

Zu Flowcontrolzahlt mandie Verfahren,die auf derEmpfangerseite,zu Congestioncontroldie Ver-fahrendieaufderSenderseitedenDatenflussbeeinflussen.Dazuwird einSende-undEmpfangsfens-terbenutzt.DasEmpfangsfensterkannalsabstrakteDarstellungdestatsachlichunbenutztenPlatzimPuffer desEmpfangerbetrachtetwerden.DarauskannderSenderableitenwieviel Datener maximalversendendarf.Es ist nicht gefordert,dassjedesSegmenteinzelnquittiert wird. Quittungenkonnenauchkumulativversandtwerden,d.h.dasEintreffeneinerQuittungmit Sequenznummern+1betstatigtdenEmpfangallerSegmentebis zurSequenznummern. Eskannkein VerlustvonSegmentenmit Sequenznummer, bc�

stattgefundenhaben,denndannmussenduplizierteQuittungen,diedenEmpfangderSegmentebis zurSequenznummerc-1bestatigen,beimSendereingehen.

5.1 Sliding Window

Im Sende-undEmpfangsfensterkonnenSegmente,dienochnichtquittiertwurden,nichtberucksich-tigt werden.DaherhatderSendersichzu merken,wieviel nicht quitterteSegmentewelcherGrosseer verschickthat.Darausergibt sichdie von ihm maximalzuverschickendeDatenmenge:

d e SU�;Sgf�h(i�j;k;lnmoh d �pq�sr+��St��!#u>���\�vu\�;�\w2<yx h�f(h�i\j�h(z{h�|7h x;} h(i/z{h~ ����

���!g���\��� � 5>�� ��]� �

DasSlidingWindow[9] gibt dieDatenmengean,dieversendetwerdenkann,ohnedassderEmpfangs-puffer uberlaufenwird. EsbeginntnachderletztenbestatigtenSequenznummerundhatdie im Emp-fangsfensterangegebeneGrosse.WerdenSegmentequittiert soverschiebtsichdasgesamteFensternachrechts,bis es wieder an der entsprechendenSequenznummerbeginnt. DiesesFensterist dasMaximumanDaten,die derSenderverschickendarf.DerSendermussausobengenanntenGrundendasFensteranpassen,in demer die linke Grenze(letzteQuittung)bis zur letztenverschicktenSe-quenznummernachrechtsverschiebt.DasubriggebliebeneFenstergibt dastatsachlicheMaximumanDaten,die versendetwerdenkonnen,an.Wennder SenderdasMaximum ausgeschopft hat und der EmpfangerseinenEmpfangspuffer nichtrechtzeitigleerenkonnte,sohatsichderEmpfangspuffervollstandiggefullt. DannschicktderEmpfangereineQuittungfur dasletzteempfangeneSegment,welchesseinenPuffer gefullt hat.Er teilt demSen-dermit, dasseinEmpfangsfensterdieGrosse0 erreichthat.DerSenderhort aufDatenzuverschicken,daer weiss,dassderEmpfangspuffer gefullt ist. Damit derSenderdenDatenversandwiederaufneh-men kann,mussder Empfangerden Senderuber einengeandertenFullgrad desEmpfangspuffersinformieren.Dies geschiehtdurchdasWindow Update. DasWindow Updateist eineQuittung,die

15

nichtdenEmpfangeinesneuenSegmentesbestatigt,sonderndemSendermitteilt, dasssichdasEmp-fangsfenstergeanderthat.Damit derEmpfangererkennt,wanner wiederDatenempfangenunddasWindow Updateverschickenkann,wird der PersistTimer [9] verwendet.Mit demSliding WindowbestehtdieGefahr, dassdasSilly WindowPhanomen[9] auftritt. DerEmpfangerbietetin jederQuit-tungdenfreienPlatzin seinemEmpfangspuffer an,welchergegebenenfalls sehrklein werdenkann.Der SenderrichtetsichnachdiesemWert undsendetentsprechendkleineSegmente,auchwenneinewesentlichgrossereMengeanDatenzumVersandansteht.Dadurchentstehtein OverheaddurchdieHeaderderSegmente.DiesemProblemwird vorgebeugt,in demgefordertwird, dassmindestenseinSegmentmit maximalerSegmentgrosse(angegebenin derMSS-Option)verschicktwerdenkann.

5.2 NagleAlgorithmus

WahrenddasSliding Window versucht,eineUberlastungder kommunizierendenHostszu vermei-den,versuchtderNagle Algorithmus[4] eineunnotigeLastauf demNetzwerkzu vermeiden.DieserAlgorithmuswird verwendet,wennnur wenig Datenzum Versendenanstehen,so dassversendeteSegmentesehrklein sind.Klein heissthier, dassderOverheaddurchHeaderRelevanzbesitzt.SolchekleinenSegmentewerdenals Tinygrams[9] bezeichnet.Der NagleAlgorithmusarbeitetdannwiefolgt:Voraussetzungen:

� Esstehtein TinygramzumVersandan� Esist bisherkeineQuittungfur daszuletztversendeteSegmenteingegangen

Dann

� SammleweitereDatendieevtl. anfallenundfugesiedemTinygraman� Wenndie nochaustehendeQuittungeintrifft, dannsendedasausmehrerenDatenzusammen-gesetzteSegment

DergrosseVorteil diesesAlgorithmusist, dasserselbstskalierendist, d.h.wenndieNetzwerkauslas-tunggeringist (dieQuittungentreffenschnellein),werdenDatenohnegrosseVerzogerungversendet.Ist dasNetzwerkjedochstarkausgelastet,sowerdenresourcenschonendegrosseSegmentein gros-senAbstandenversandt,diedazubeitragen,dasssichdieNetzwerklastwiederverringert.AberdieserAlgorithmushataucheinenNachteil,denner ist fur Anwendungen,die ihreDatenschnellbenotigen,nicht einsetzbar(z.B. Echtzeitanwendungen).

5.3 Delayed Acknowledgements

Im GegensatzzumNagleAlgorithmussetztmanmit DelayedAcknowledgements[9] aufderEmpfanger-seitean.Hat derEmpfangerein Segmenterhalten,sowarteter einegewisseZeit, bis er die Quittungsendet.Fallenin dieserZeit Datenan,diezuruckandenSendergeschicktwerdenmussen,sokonnendie Datenunddie Quittungzusammenubertragenwerden.

16

5.4 Slowstart/CongestionAvoidance

Ein NachteildesSlidingWindow ist, dasseszuUberlastungenanKnotenkommenkann,dieaufdemWeg zumEmpfangerpassiertwerdenmussen,da diesekeinenEinflussauf die GrossedesFenstersausubenkonnen.DiesemNachteiltritt Slowstart[9] entgegen.Auf derSenderseitewird dieEingangs-ratevon Quittungenbeobachtet.Mittels Slowstartversuchtman,die Ausgangsratevon SegmentenderEingangsratevon Quittungenanzugleichen.Ein optimalerZustandwird dannerreichtwennderSendkanalvollstandiggefullt ist.

Abb. 5.1Fullung desSendeKanals:1)gering2)optimal

Slowstartversucht,dieKapazitatdesKanalsmoglichstschnellvollstandigauszunutzen,solangekeinSegmentverlorengeht.Dazubenotigt Slowstartfur jedeVerbindungein Congestionwindow, daszuAnfangderVerbindungmit 1 initialisiert wird. Fur jedekorrektempfangeneQuittungwird dasCon-gestionwindow inkrementiert.�q� �+!0�>u\�� � ���2 (�v� � �a ��� ��!0�>u��� � ���� ���� � ��$a:DiesfuhrtzueinemexponentiellemWachstumderAnzahlderUbertragenenSegmente,dennwahrenddesSendensvon Segmentetreffen Quittungenfur die zuletztgesendetenSegmenteein. Sindz.B. 2Segmenteverschicktworden,sokommen2 Quittungenzuruck, sodasssichdie GrossedesConges-tionwindow verdoppelt.Der SendersendetdannDatenmenge= min[Empfangsfenster, Congestionwindow]. Dies fuhrt rechtschnellzu einemgefulltem Sendekanal,solangeder EmpfangerseinenPuffer schnellgenugleerenkann.Sollte jedochein Segmentverlorengehen,so ist dasCongestionwindow wiederauf denAn-fangswertzu setzen,undderFullgraddesSendekanalsnimmt dementsprechendab. Um einesolcheSituationzu verhindern,arbeitetSlowstart in Kombinationmit CongestionAvoidance. So wird einSchwellwert SSThresholdeingefuhrt, der anfangszu 65535Bytes initialisiert wird [10]. Sollte dasCongestionwindow kleinerseinalsderSchwellwert, sowird dasFenstergemassdemSlowstartAl-gorithmuserhoht. Ist derSchwellwert uberschritten,sogehtdasVerfahrenin CongestionAvoidanceuber. Danngilt fur die ErhohungdesCongestionwindow�q� ��!0�>u��� � ���2 (�v� � �a �q� �+!#�>u��� � ���2 ���� � ��$ :��� ��!0�>u��� � ���� ��v� � �

17

WennmandieseFormelmit demgleichenArgumentwie beiderErhohungbeimSlowstartAlgorith-musbetrachtet,dannergibt sicheffektiv eineErhohungum1. Sindz.B.zweiPaketegesendetwordenunddiezugehorigenQuittungeneingetroffen,soergibt sichfur dieErhohungdesCongestionwindow��� ��!0�>u��� � ���� ��v� � ��i\h�����s$D�I5��

��� ��!0�>u��� � ���� ��v� � ����moj�$�:. Sollte esnun dochzu einem

VerlusteinesSegmenteskommen,sowird derSchwellwertSSThresholdangepasst

u>u\����w��>u>�� F�H�J�L ��� ��!0�>u��� � ���� ���� � �P?Rp��sr+��St�+!�u>���\�vu��;�\w7Z�DasCongestionwindow mussebenfalls anpasstwerden,allerdingsgilt eshier zu unterscheiden,obein Timeoutvorliegt oderduplizierteQuittungeneingetroffen sind.Im letzterenFall wird esauf dengleichenWert wie SSThresholdgesetzt.Da weiterhinSegmenteihr Ziel erreichen,ist esin diesemFall sinnvoll denDatenflussauf geringeremNiveauaufrechtzu erhalten.Im erstenFall kannjedochdie Verbindungvollstandigabgebrochensein,unddaherist ein UbertragenvonmehrerenSegmentenhintereinandernicht sinnvoll. DasStaukontrollfensterwird auf 1 gesetzt,und die Verbindungfalltzuruck in dieSlowstart-Phase.

6 Varianten von TCP

6.1 TCP-Tahoe

Ein grosserNachteildeseinfachenGo-Back-NVerfahrenist,dassSegmenteunterUmstandenunnotigwiederholtwerden.Dasgeschiehtdann,wennwirklich nur ein Segmentbei der Ubertragungverlo-ren gegangenist, spatergesendetejedocherfolgreichubertragenwurden.Durch die ausschliesslichpositivenQuittungenist esdemEmpfangernichtmoglich,demSendermitzuteilen,welchesSegmentnicht empfangenwurde.Um dieseNetzlastzuvermeidenmussmanerkennenkonnen,wannein ein-zelnesSegmentverlorengegangenist, um dannnur dieseseinzelnzuwiederholen.Der VerlusteineseinzelnenSegmenteskanneinerseitsdurchUberfullung desEmpfangerpuffersge-schehen,andererseitswerdenim NetzwerkRoutereingesetzt,die ebenfalls einerUberlastungunter-liegenkonnen.Dannwerdenvon ihneneintreffendePaketeverworfen.DadadurchkeineDatenmehruberdasNetzwerkverschicktwerdenkonnen,verwendetmanin denRouternvermehrtdasVerfahrenRandomEarly Discard (RED). DiesesVerfahrenverwirft mit zunehmenderWahrscheinlichkeit beizunehmenderAuslastungeinzelneSegmente,um soeinerUberlastungvorzubeugen.In der VarianteTCP-TahoedasFastRetransmitVerfahren [9] implementiert.Esberuhtauf derAn-nahme,dassderEmpfangduplizierterQuittungenauf denVerlusteineseinzelnenSegmentsdeutet.Liegt jedochein Timeoutvor, dannist dasNetzwerkuberlastet,denneskommenschliesslichauchkeineQuittungenzuruck.Essinddannalle nichtquittiertenSegmenteerneutzusenden.NachEmpfangderdrittendupliziertenQuittungwird voneinemeinfachenUbertragungsfehlerausge-gangen.Mit demFastRetransmitVerfahrenwird nur dasSegmentwiederholt,dasauf dasmehrfachquittierteSegmentfolgt. HatderEmpfangernundiesesSegmentempfangen,soquittierterkumulativ

18

alle Segmentedie er nachdemUbertragungsfehlerkorrekterhaltenhat.NachEmpfangdieserQuit-tungbeginntderSenderwieder, SegmenteabdemquittiertenSegmentzuubertragen.Jedochfallt dieVerbindungzuruck in denSlowstart-Modus,womit derDatenflusssichenormverringert.

6.2 TCP-Reno

Ein Nachteil des in TCP-TahoeimplentiertenFast-RetransmitVerfahrenist, dassdie VerbindungnacheinemdurchduplizierteQuittungengekennzeichnetenFehlerzuruck in denSlowstart-Modusgeht.Die Tasache,dasseinzelneSegmenteverlorengehen,ist einHinweisdarauf,dassderevtl. hoheDatenflussnicht vollstandigabgebrochenist, sondernnur anseineoberemoglicheGrenzestosst[9].Daherist esnichtnotwendig,denDatenflusszuminimieren.

In TCP-Renotritt diesesVerhaltennichtauf,danichtnurdasFastRetransmitVerfahren,sondernauchdasFast-Recovery Verfahren implementiertwurde.DiesesVerfahrensoll denDatenflussauf einemhohemNiveauhalten.Wie obenvorgestellt,wird bei Slowstart/CongestionAvoidancederSchwell-wert SSThreshverwendet,bis zu diesemdasCongestionwindow bei empfangenenQuittungenver-doppeltwird. DieserWert wird bei einemUbertragungsfehlerauf die Halfte desMinimumsausdemCongestionwindow unddemEmpfangsfenstergesetzt.Fast-Recoveryarbeitetnungenausowie Fast-Retransmit,nur wird hierbeider nachdemUbertragungsfehlerneugesetzteSchwellwert SSThreshals angemessenerWert fur dasCongestionwindow angesehenund deshalbauf diesenWert gesetzt.Sogehterstensdie Verbindungnicht in denSlowstart-Modus,sonderndasCongestionwindow wirdgemassdesCongestionAvoidanceAlgorithmusinkrementiert,undzweitenswird derDatenflussaufeinemangemessenenNiveauerhalten.Sollten jedochmehrereSegmenteim ubertragenenFensterverlorengegangenoderdie WiederholungeinesSegmentesebenfalls fehlgeschlagensein,dannwirdauchhier in denSlowstart-Modusubergegangen.TCP-Renoist heutzutagedie amweitestenverbreiteteAusfuhrungvonTCP.

6.3 SACK-TCP

In TCP mit SelctiveAcknowledgements[3], kurz SACK-TCP, wird zusatzlichzu denpositivenundkumulativen Acknowledgementseine Option eingefuhrt, mit der Blocke von Segmentenbestatigtwerdenkonnen.Dazuwerdenzwei Headeroptionenbenutzt.Zum einenist dasdie SACK-permittedOption(Typ 4, Lange2), mit derangezeigtwird, dasSACK verwendetwird. DieseOptionwird ubli-cherweisezusammenmit dem SYN-Flag beim Verbindungsaufbaugesetzt.Die zweite Option istTCP-SACK(Typ 5, Langevariabel).In dieserOptionwerdenBlocke von Segmentenangegeben,diederEmpfangerquittierenmochte.DieseBlockewerdenin derfolgendenFormangegeben:

� 1.Block:SequenznummerdeserstenSegmentsdes1.Blocks

� 1.Block:Sequenznummerdie aufdasletzteSegmentdes1.Blocksfolgt

19

. . .

� n.Block:SequenznummerdeserstenSegmentsdesn.Blocks

� n.Block:Sequenznummerdie aufdasletzteSegmentdesn.Blocksfolgt

Da jederHeadermaximal40 BytesanOptionenaufnehmendarf undjederBlock 64 Bit ( = 8Bytes,4ByteAnfangssequenznummer, 4 Byte folgendeSequenznummer)beansprucht,konnenhochstens4Blocke angegebenwerden.Der EmpfangerbeobachtetstandigseinenEmpfangspuffer. Soll nuneinSegmentquittiertwerden,geschiehtdasnachdenfolgendenRegeln:

� Ist daszu quittierendeSegment in korrekterReihenfolgeeingetroffen ( d.h. vor allem keinfehlendesSegmentvor diesem),sowird einenormaleQuittungohneSACK-Optionverschickt.

� Sollte (genau)ein Segmentvor diesemfehlen,so wird ein Segmentmit SACK-Option ver-sendet.In diesemSegmentwird derEmpfangdesSegmentsvor demfehlendenquittiert (eineublicheduplizierteQuittung).In derSACK-Optionwird einBlock angegeben,in demdasemp-fangeneSegmentquittiert wird. Als ersteSequenznummerwird die auf dasfehlendeSegmentfolgendeSequenznummerangegeben.

� SolltenbereitsmehrereSegmentefehlen,sowird wie im vorangegangenemPunktvorgegangen,ausserdasnun fur jedesfehlendeSegmentein Block eingetragenwird. Der i-te Block enthaltdabeizuerstdieaufdas(Blocke- i)-te fehlendeSegmentfolgendeSequenznummer, danachdieSequenznummerdesnachstenfehlendenSegments,bzw. diedeszuletztempfangenenSegments(derersteBlock enthalt dieNummerdeszuletztempfangenenSegments).

AnhanddieserSACK-OptionenkannderSendererkennen,welcheSegmentenicht korrektausgelie-fert wurdenunddieseselektiv wiederholen.TCP-SACK gehtnacheinemmehrfachenUbertragungsfehlernicht in denSlowstart-Moduszuruck.

Literatur

[1] Fall, K., Floyd, S.,Comparisonsof Tahoe,Reno,andSackTCP, Tech.Report,1995

[2] RossKeith,KamesF. KuroseComputerNetworking:A topdownapproachfeaturingtheInternet,AddisonWesley, 2001

[3] Mathiset al.,SelctiveAcknowledgementOptions, RFC2018,1996

[4] Nagle,CongestionControlin IP/TCPInternetworks, RFC896,1984

[5] Plummer, David C.,An EthernetAddressResolutionProtocol,RFC826,1982

20

[6] Postel,J.,UserDatagramProtocol, RFC768,1980

[7] Postel,J.,TransmissionControlProtocol, RFC793,1981

[8] Postel,J.,TheMagicNumbersin TCP/IP, RFC1340,1992

[9] Stevens,W. Richard,TCP/IPIllustratedVolumeI, AddisonWesley, 1994

[10] Stevenset al., TCPCongestionControl, RFC2581,1999

21