Multimedia-Kommunikation in Hochgeschwindigkeitsnetzen ... · U. Krieger: KTR-MMK-M SS08 Kap.1 3...

U. Krieger: KTR-MMK-M SS08 Kap.1 1

Multimedia-Kommunikation in Hochgeschwindigkeitsnetzen (KTR-MMK-M)

Prof. Dr. Udo Krieger

Otto-Friedrich Universität BambergProfessur für Informatik

insbes. Kommunikationsdienste, Telekommunikationssysteme

und Rechnernetze(KTR)

Modulgruppe Informatik/Wahlpflichtbereich KTR

SS 2008


Die Vorlesung führt in die grundlegenden Techniken der Rechnernetze und Datenkommunikationstechnik ein. Es werden relevante Standards, proto-typische Netzarchitekturen, Protokollmechanismen und -realisierungen

sowie aktuelle Forschungs- und Entwicklungstrends vorgestellt:Einführung

• Übersicht über Entwicklung, Rechnernetze und Märkte• Netztechnische Grundlagen • Kommunikationsprotokolle

Protokolle und Dienste • Das OSI-Referenzmodell• Das TCP/IP-Protokollmodell

Netzarchitekturen und Protokollmechanismen in Datenkommunikationsnetzen• Netzkomponenten, Übertragungsmedien und -verfahren • Übertragungssicherungsmechanismen• Medienzugriffsverfahren • Flusssteuerung • Vermittlung von Nachrichten und Routing• Verfahren der Transportschicht (TCP usw.)

Anwendungen Ausblick auf Datenkommunikationsnetze der neuen Generation

Übersicht Datenkommunikation


Übersicht MMKHGN

Ausgehend von den Grundlagen der Datenkommunikation werden in dieser weiterführenden Lehrveranstaltung die Netzarchitektur, die vermittlungstechnische Struktur, die Protokollstruktur sowie das Verkehrsmanagement moderner Hoch-geschwindigkeitsnetze für neueste Echtzeit- und Multimedia-Anwendungen besprochen. Die zur Abwicklung derartiger Kommunikationsbeziehungen mit ihrer Zusicherung von Dienstgüte-Merkmalen erforderlichen neuen Übermittlungsarchitekturen auf der Basis des Asynchronous Transfer Mode sowie des TCP/IP-Protokollstapels werden in der Veranstaltung vorgestellt. Im Mittelpunkt stehen neben leistungsfähigen Anschlusstechnologien auf leitungs-gebundenen Medien, neue Transport- und Dienstgüte-Architekturen im Kernnetz, wie Intserv, Diffserv sowie MPLS und GMPLS. Außerdem werden die Fortentwicklung des IPv4 durch IPv6 vorgestellt. Ferner werden die schnelle Paketvermittlung und das Routing in IP-Netzen mit Dienstgüte-Unterstüt-zung und der Einsatz neuer Betriebsmittel- und Verkehrsmanagement-Verfahren, z.B. Speicherverwaltungsalgorithmen wie RED, RIO und Schedulingalgorithmen wie WFQ, angesprochen. Darüber hinaus werden typische Anwendungen des Multimedia-Internet der 2. Generation wie WWW, Voice-over-IP und Medien-Streaming skizziert.

Die Fortführung durch Praktika, Hauptseminare und Diplomarbeiten ist möglich und eine wichtige Zielsetzung dieser Lehrveranstaltung.


Einordnung der Vorlesung

Zielsetzung:Einführung in die Datenkommunikation (KTR-Datkom-B): V2+2 SWSVorbereitung des weitergehenden Angebotes des Fachgebietes Kommunikationsdienste, Telekommunikationssysteme und Rechnernetze (KTR)

Fortführung im Wahlpflichtbereich KTR:Modellierung und Analyse von Kommunikationsnetzen und Verteilten Systemen (KTR-MAKV-M im WS): V3+1 SWSMultimedia-Kommunikation in Hochgeschwindigkeitsnetzen (KTR-MMK-M im SS): V3+1 SWSMobilkommunikation und Mobile Computing (KTR-Mobi-M im WS): V3+1 SWSPraktikum (KTR-GIK-M)

derzeit: Grundbausteine der Internet-Kommunikation

Hauptseminare zu wechselnden Themen, im SS2008: Virtualisierungstechniken in Next Generation Networks

Diplom- und ForschungsarbeitenMitarbeit im EU-Projekt COST-TMA


Literatur

Kurose, J., Ross, K.W.: Computernetzwerke – ein Top-Down-Ansatz mit Schwerpunkt Internet, Pearson Studium, München, 4. Aufl. 2008.Kurose, J., Ross, K.W.: Computer Networking: A Top-DownApproach: A Top Down Approach, 4th ed., Addison-Wesley, 2008.Leon-Garcia, A., Widjaja, I.: Communication Networks, McGraw-Hill, Boston, 2nd ed. 2004.Stallings, W.: ISDN and Broadband ISDN with Frame Relay and ATM,Prentice Hall, Englewood Cliffs, 1995.Tanenbaum, A. S.: Computernetzwerke, Pearson Studium, München, 4. Aufl., 2003.Sikora, A.: Technische Grundlagen der Rechnerkommunikation, Fachbuchverlag Leipzig, 2003.Walrand, J., Varaiya, P.: High-Performance Communication Networks, Academic Press (Morgan Kaufmann Series in Networking), 2000.Comer, D.: Computernetzwerke und Internets, Pearson Studium, München, 3. Aufl., 2004. (Bafög-Ausgabe kaufen!)Krishnamurthy, B., Rexford, J.: Web Protocols and Practice, Addison-Wesley, 2001.


Literatur

J. Liebeherr, M. Elzarki: Mastering Networks, An Internet Lab Manual, Pearson Education, Boston, 2004.

- Kapitel 1: IntroductionRodriguez, A, et. al.: TCP/IP Tutorial and Technical Overview, IBM Redbooks, Prentice Hall, 7th ed., 2002.

• http://publib-b.boulder.ibm.com/abstracts/gg243376.html?OpenCharles M. Kozierok: The TCP/IP-Guide, No Starch Press, San Francisco, 2005

• http://www.tcpipguide.com/toc.htmKrüger, G., Reschke, D.: Lehr- und Übungsbuch der Telematik, Fachbuchverlag Leipzig, 3. Aufl., 2004.Saito, H.: Teletraffic Technologies in ATM Networks, Artech House, Boston 1994.Siegmund, G: ATM- Die Technik des Breitband-ISDN, R.v. Decker, Heidelberg, 1994.Stevens, R.: TCP/IP Illustrated, Vol. I, Addison-Wesley, 1994. Stein, E.: Taschenbuch Rechnernetze und Internet, fv Leipzig, 2. Aufl. 2004.


Literatur

Chen, T. M., S.S. Liu: ATM Switching Systems, Artech House, boston, 1995.de Prycker, M.: Asychronous Transfer Mode – Die Lösung für das Breitband-ISDN. Prentice-Hall, München, 2. Aufl. 1994.Onvural, R.: Asynchronous Transfer Mode Networks: Performance Issues, Artech House, Boston, 1994.McDysan, D.E., Spohn, D.L.: ATM – Theory and Application, McGraw-Hill, New York, 1998.Ginsburg, D.: ATM solutions for enterprise internetworking, Addison-Wesley, Harlow, 1996.Händel, R., M.N. Huber: Integrated Broadband Networks – An Introduction to ATM-based Networks, Addison-Wesley, Reading 1991.Lee, B.G. u.a.: Broadband Telecommuniations Technology, ArtechHouse, London, 1996.


Überblick

Einleitung: Die Evolution bestehender KommunikationsnetzeNetzarchitektur des Schmalband-ISDNStruktur von Breitbandkommunikationsnetzen und des InternetGrundlegende Kommunikationsabläufe in Rechnernetzen

Dienste und ProtokolleDienste im OSI-ModellEvolution der Dienste im ISDNEigenschaften und Anforderungen neuer Dienste im B-ISDNMultimedia-Kommunikation mit Video-Wiedergabe und Sprachdatenübertragung

• Web-Architektur (http)• Video-Wiedergabe (RTSP)• Sprachdatenübertragung (RTP, RTCP)• Architekturen für Multimedia-Kommunikation (H.323, SIP)• VoIP und Video-Streaming

Nachrichtentechnische Grundlagen von TelekommunikationsnetzenVermittlungstechnische GrundbegriffeÜbertragungstechnik in Breitbandkommunikationsnetzen


Überblick

Netzarchitektur der HochgeschwindigkeitsnetzeGrundprinzipien der ATM-VermittlungstechnikVermittlungstechnik in BreitbandkommunikationsnetzenBISDN Protokoll-Referenzmodell

IP-Netze der 2. GenerationProtokollarchitektur und GrundlagenIP-over-ATMIPv6IPSec

Dienstgüte in IP-NetzenDienstearchitekturen: Intserv, DiffservSignalisierung und Betriebsmittelmanagement (RSVP)IP-Verkehrsmanagement

• Prioritätenkonzepte• Scheduling• Puffermanagement (RED, RIO)

Routing (OSPF, MPLS, GMPLS)


Kapitel 1:

Einleitung

Aus:http://www.i-m.de/home/datennetze/index.htm


Kapitel 1.1

Evolution der Telekommunikationsnetze


Formen der Telekommunikation

Warum kommunizieren Systeme miteinander?Bedürfnisse nach personenbezogener Kommunikation

Sprachkommunikation mit analogen oder digitalen Telefonsystemen oder PCsFaxelektronische Post (email)personenbezogene Kommunikation über World Wide Web Techniken (Web-Phones, Call-Center-Aufrufe)

Bedürfnisse nach Datenkommunikation zwischen RechnernErzeugen funktionsfähiger Rechnerverbundsysteme unter Zuverlässigkeits- und SicherheitsanforderungenBeispiele: Dateiverbundsysteme, Druckverbundsysteme, Datenbankverbundsysteme

Zukünftige Entwicklung: Integration der Interaktionsformenfreie Übergänge bei der Telefondiensterbringung und Datenübertragung zwischen koexistierenden Systemen, z.B. Fernsprech- und DatenübermittlungsnetzenIntegration verschiedener Medien wie Rechnerdaten, Sprache und Video oder MusikIntegration verschiedener Zugangstechnologien für den stationären oder mobilen Netzzugang von Heim- oder Büroarbeitsplatzumgebungen ausIntegration in betriebliche Arbeitsabläufe, z.B. Workflow-Management, Service-OrientedArchitecture (SOA) oder Verteilte Berechnungsplattformen (GRIDs)


Die Evolution der TelekommunikationsnetzeQoS-Internet•Internet der 2 .Generation mit Dienstgüteunterstützung

ATM•Asynchronous transfer mode

•paketvermittelndesdiensteintegrierendesdigitales Netz

TMN•Telecommunicationmanagement network

•Überwachungssystem des Netzes (NOC Bamberg!)

Übertragungstechnik•PCM: Pulscodemodulation

•PDH: plesiochrone digitale Hierarchie

•STM: synchronous transfermode

Digitalisierung der Übertragungs- und Vermittlungstechnik

SDH


Die Evolution der Telekommunikationsnetze


Struktur von Telekommunikations-Festnetzen

Digitales Fernsprechnetz (ISDN)Vermittlungstechnische Betriebsmittel:

•digitale Vermittlungsstellen (Rechnerknoten mit Echtzeitanforderungen)

Übertragungstechnische Betriebsmittel:

•digitale Übertragungs-systeme mit Verbindungs-medien

Endsysteme:

•Telefonsysteme

•Nutzung durch Endanwender, sog. Anwendungsinstanzen


ISD

N-N

etzs

trukt

ur


Dienste-Integrierendes Digitales Netz (ISDN)

Merkmale des Schmalband-ISDN (S-ISDN):seit 1993 eingeführtes Universal-Weitverkehrsnetzbaut auf digitalem Übertragungsnetz und digitalen Vermittlungsknoten auf

nutzt Pulscodemodulationssystem PCM30 und Vielfache mit 64 kbps Kanälen zur Datenübertragungkann analoge Anschlüsse über A/D Wandler anbinden nutzt zwei unabhängige 64 kbps Nutzkanäle, sog. B-Kanäle, pro digitalem Teilnehmeranschluss zum Nutzdatentransportstellt separates Signalisierungsnetz mit 16 kbps Kanal, dem D-Kanal beim Teilnehmer bereit

Zwei-Draht-Hausanschluss im Ortsnetz


Dienste-Integrierendes Digitales Netz (ISDN)

ISDN-Universalanschluss:Festverbindung oder geschaltete Punkt-zu-Punkt-Verbindung

transparente digitale Verbindung auf der Basis von 1-2 Basis-(B)-Kanälen von 64 kbps Übertragungsrate und einem Steuerungskanal (D-Kanal) mit 16 kbps2 Varianten: 1 B(64 kbps) + D(16 kbps) oder 2 B(64 kbps) + D(16 kbps)Netzabschluss (NT) markiert die Terminal-Netzschnittstelle (S_0)

• wird durch Teilnehmerleitung zum Endsystem verlängertISDN-Universalanschluss in 2 Ausprägungen

Basisanschluss mit 2 B(64 kbps) + 1 D(16 kbps) Kanälen (insgesamt 144 kbps)Primärmultiplexer-Anschluss mit 30 B(64 kbps) + 1 D(64 kbps) Kanälen (insgesamt 2.048 Mbps)technisch realisiert als

• Mehrgeräteanschluss mit max. 12 IAE-Dosen für maximal 8 parallele Geräte• Anlagenanschluss, z.B. Nebenstellenanlage (PBX)

Alle Teledienste am Teilnehmeranschlussunterlagerter Transportdienst stellt Vermittlungs- und Übertragungsdienste bereitEnde-zu-Ende Protokolle stellen Benutzer-Benutzer Dienste bereit

• flexible Zuweisung von Kanälen an unterschiedliche Dienste, z.B.Videofernsprechen, und Endgeräte möglich


ISD

N-V

erbi

ndun

gsab

lauf


Hierarchische Struktur des ISDN-Vermittlungsnetzes 1990

Hierarchischer Aufbau des ISDN-Vermittlungsnetzes in den 90ern:

•Strukturierung der Einzugsbreiche in Ortsnetze mit Endvermittlungsstellen (EVSt/OVSt)

•sternförmige Anbindung von Teilnehmern im Ortsnetz mit der Möglichkeit des ISDN oder Modemzuganges zu Datennetzen

•Teilvermaschung von Vermittlungsknoten in Ortsnetz

•Gliederung des Fernnetzes in drei (heute zwei!) Fernebenen:

•regionale Ebene mit Knotenvermittlungs-stellen (KVSt) als Einstiegspunkten

•Haupt- und Zentralvermittlungsstellen (HVSt, ZVSt) als Verteilungsknoten des nationalen Fernverkehres

•heute abgelöst durch sog. Weitver-kehrsvermittlungsstellen (WVSt)


Netzaufbau eines Weitverkehrsnetzes Aufgaben und Strukturierung der Fernetzebene in einem WAN:•Überbrücken großer Distanzen

•Punkt-zu-Punkt-Verbindung zwischen Vermittlungsknoten

•doppelte Anbindung der Vermittlungs-knoten zur Erhöhung der Netzverfügbar-keit

•doppelte Anbindung an Zugangsknoten (double homing)

•Duplizieren von Vermittlungsknoten

•reguläre vollvermaschte Topologie

•komplexe Zusammenschaltung von lokalen ZugangsbereichenZugangsbereiche

Aufgabe: Ablösung durch IP-Netz ab 2010


Kapitel 1.2

Struktur von Breitbandkommunikationsnetzen


Die Evolution der Telekommunikationsnetze

radio-LANs (Hiperlan, IEEE 802.11 WLANs) enhanced by Bluetooth-PANs in theWLL-area as supplements to UMTS to build mobile networks

low

high

portable

Data rate

3G network

PANs WLANs

Schmalband-ISDN Breitband-ISDN (ATM/IP-2 mit Dienstgüteunterstützung)

4G-Netze

2G+: GSM+, GPRS, EDGE

DECT

WiMAX IP-2/3 HGN und optische Hoch-geschw.-Netze

(NGNs)


Netzarchitektur eines UMTS-Mobilfunknetzes der 3. Generation

S G S N

R N S

R N C

R N S

R N C

C N

N ode B N ode B N ode B N od e B

Iu C S Iu P S

Iu r

Iu b is

M E

U S IM

M S

C u

U u

M S C

G s

G G S NG M S C

G nH L R

G r

G cC

D

E

A u CH

E IR

F G f

G iP S T N

Iu C SIu P S

V L RB

G p

V L RG

B S C

B T S

U m

A

B S C

B T SB T S

G b

A b is A b is

U m

B S SB S S

S IM

S IM -M E i/f o r

M S CB

PS T N

Iu b is

P S T N

B T S

Prinzipien:•Fortschreiben der GSM/GPRS-Architektur

•Nutzung neuer Übertragungsverfahren auf der Luftschnittstelle (code divisionmulitiple access, CDMA)

•Weiterentwicklung der BSC in sog. RNC-Knoten

•Zusammenfügen von BTSen in Node B


Interne Struktur eines 3G-Netzes mit ATM-Kernetzbausteinen

Dienste

Server

ATM/IP Kernnetz

Zugangs-netz


Struktur von Breitband-Telekomunikationsnetzen 2000

ATM-BWIN-StrukturBeispiel der Netzstruktur eines Breitband-Telekommunikationsnetzes:

•Breitband-Wissenschaftsnetz (B-WIN)

•Kopplung von Vermittlungs-Rechnerknoten (ATM-Knoten) auf der Basis der ATM-Netzinfrastruktur der Deutschen Telekom

•ATM: Asynchronous Transfer Mode

•Übermittlungsverfahren des Breitband-ISDN zur Integration von Sprach-, Video- und Datenverkehren in einem Datenkommunikationsnetz

•10 Vermittlungsknoten in den regionalen Wirtschaftszentren des Landes

•Konzentration des Zugangsverkehres und überregionales Verteilen


Typische Netzstruktur eines Breitband-IP-Kommunikationsnetzes mit ISP-Standort (POP)

ISP-Backbone

MPLS

PoP

Subscriber

Label Edge/Switch Router

Customer Premise

Equipment

Edge Access Peering

Global Internet

Local Peering Partners

Ethernet, SDH, ATM etc.

Control Systemsof Internet Access

ISP-Backbone

MPLS

PoP

Subscriber

Label Edge/Switch Router

Customer Premise

Equipment

Edge Access Peering

Global Internet

Local Peering Partners

Ethernet, SDH, ATM etc.

Control Systemsof Internet Access

Quelle:G. Haßlinger, Impact of Peer-to-Peer Networking on Internet Platforms and Services, P2P-Seminar, TU Darmstadt, 01.02.06


IntfIn

LabelIn

Dest IntfOut

3 0.40 47.1 1IntfIn

LabelIn

Dest IntfOut

LabelOut

3 0.50 47.1 1 0.40 47.1

47.2

47.3

1

23

1

2

1

23

3IntfIn

Dest IntfOut

LabelOut

3 47.1 1 0.50

IP 47.1.1.1

IP 47.1.1.1

Label Edge Router (LER)

LER

MPLS-IP- Datennetz

Virtual Private Network AVirtual Private Network A

47.1

Label SwitchedPath (LSP)

VPN-IDLER-Label

Wegewahlinformationen in Form von Quellen- und Zieladressen der kommunizierenden Rechner

Struktur von Breitband-IP-Kommunikationsnetzen

Wegetabellen

Nachrichtenpakete zum Datentransport

Vermittlungsknoten (Router)Standortnetz


IntfIn

LabelIn

Dest IntfOut

3 0.40 47.1 1IntfIn

LabelIn

Dest IntfOut

LabelOut

3 0.50 47.1 1 0.40 47.1

47.2

47.3

1

23

1

2

1

23

3IntfIn

Dest IntfOut

LabelOut

3 47.1 1 0.50

IP 47.1.1.1

IP 47.1.1.1

Label Edge Router (LER)

LER

MPLS-IP- Datennetz

Virtual Private Network AVirtual Private Network A

47.1

Label SwitchedPath (LSP)

VPN-IDLER-Label

Wegewahlinformationen in Form von Quellen- und Zieladressen der kommunizierenden Rechner

Struktur von Breitband-IP-Kommunikationsnetzen

Wegetabellen

Nachrichtenpakete zum Datentransport

Vermittlungsknoten (Router)Standortnetz

Ankunftsklassen

Paket-Scheduling


Weiterentwicklung im DFN-Forschungsnetz X-Win Phase 2/2006

X-Win Phase 2•Grundlage des deutschen Forschungsnetzes

•Weiterentwicklung von B-Winund G-Win

•optisches, fehlertolerantes vollvermaschtes Kernnetz aus 2* 10 Gbps Verbindungen

•Ausbau auf 40 Gbps möglich

•redundanter Anschluß an 4 SuperCore-Knoten in Hannover, Potsdam, Erlangen, Frankfurt

•Oktober 2006:

•43 Glasfaserabschnitte im X-Win mit 6000 km Glasfaserstrecken

•427 Anwender und 276 Mitnutzer


DFN-Forschungsnetz X-Win Phase 2/2006


Das Gigabitnetz-DFN-Projekt Viola


Optisches 40 Gbps-Kernnetz des Viola DFN-Projekts•40 Gbps Kernnetz

•optische Ende-zu-Ende Signalisierung mit ASON/GMPLS

•eigenes Netzmanage-ment in Nürnberg und Bamberg (Telekom NMC)


Optisches 40 Gbps-Kernnetz des Viola DFN-Projekts


Dienste in optischen Hochgeschwindigkeitsnetzen

•verteiltes Rechnen über ein Netz: derzeit 7 Grid-Projekte- Hochenergiephysik (HEP-Grid)– Astrophysik (AstroGrid-D)– Medizin (MediGrid)– Klimaforschung (C3-Grid)– Ingenieurwissenschaften (InGrid)– Geisteswissenschaften (TextGrid)– Energiemeteorologie (WISENT)


Kapitel 1.3

Struktur des Internet


Basiskomponenten einer Web-Architektur


Anwendungsprotokolle im TCP/IP Referenzmodell


Bestandteile der Web-Architektur und des Internet

Internet

TCP Verbindung

Browser

Programm

Anzeige der aktuellen Seiteim Browser

Hyperlinkzu abc.com

Hyperlink

zu xyz.com

http Dämon im Web-Server http Dämon

im Web-Server


Client-Server Kommunikation

AnwendngTransportVermittlgSicherungphysikal.

AnwendngTransportVermittlgSicherungphysikal.

Request

Response

Anwendungsprogramme im Internet umfassen 2 Komponenten: Clients und ServerClient:

initiiert die Kommunikationsverbindung zumServer (“Initiator/1. Sprecher”)verlangt einen Dienst vom Server z.B im Web ist Client im Browser implementiert und zeigt aktuell geladene Webseite an; bei E-mail im Mail-Leseprogrammerlaubt Navigieren im Netz durch Hyperlinksbietet Zusatzfunktionen, externe „Viewer“, Hilfeprogramme (Help) Nutzung auch für andere Dienste wie Email, FTP

Server:stellt geforderten Dienst für die Clients bereit

• z.B. sendet ein Web Server gewünschte Web Seiten nach Angabe des URL (uniform resource locator) als Web-Adresse im Browserein Mail Server liefert E-mails aus


Client-Server Kommunikation

http: hypertext transfer protocol•ist das Protokoll der Anwendungsschicht im World Wide Web (WWW)•nutzt das Client/Server Verarbeitungsmodell:

•Client:•Browser, der Objekte des Web (*.html, *.jpeg, *.gif) anfordert, empfängt und darstellt•Allgemein: ein Prozess (Programm), welcher Dienste eines Servers in Anspruchnimmt

•Server:•Web Server, der als Antwort auf Anfragen angeforderte Objekte sendet•Allgemein: ein Prozess, der unterVerwendung einfacher OperationenDienste im Netz anbietet

•Protokoll-Versionen•http1.0: RFC 1945

- aktuell meistens genutzt•http1.1: RFC 2068 - neue Version

PC mit MSExplorer

Server mit

Apache WebServer

Linux-PC mitNetscape Navigator

http request

http request

http response

http response

Datennetz: Internet


Adressierung von Betriebsmitteln im Web

Bestandteile der Adressierung

•Betriebsmittel (BM) Bezeichner- Uniform Resource Identifier (URI) (RFC 1630)

•7-Bit codierte ASCII Zeichenkette spezieller Syntax und Semantik zur eindeutigen Betriebsmittelidentifikation, d.h. Speicherort, Name, Darstellungsart, usw.

•Uniform Resource Name (URN) (RFC 2141)•identifiziert eine Informationseinheit mit einer bestimmten Identität (RFC 1737) an einer oder mehreren Stellen zu einer Zeit, z.B. urn://biser/dns/le/32/

•Uniform Resource Locator (URL)•identifiziert den Speicherort einer BM-Instanz und codiert Details des Zugriffs auf einem Rechner, http://www.biser.bg/znanie.html

•Uniform Resource Charateristics (URC)•Metainformationen zu einem BM, z.B. Autor, Codierung


Adressierung von Betriebsmitteln im Web

hierarchischer Aufbau der URI Syntax in Backus-Naur Format (RFC 1630) :

Beispiel:

•http://www.spiraldata.com – absoluter URI mit http als Schema der Namensspezifikation

•http://www.library-genf.com – Verwaltungseinheit (authority) des Netzwerkpfades www.library-genf.com

•http://info.kunstakademie.ru/gregorov/kurse?skulptur.pdf – Authorityinfo.kunstakademie.ru, absoluter Pfad gregorov/kurse, Anfrage skulptur.pdf

•ftp://uu.psi.com/wp/nir.txt - Pfadsegment: wp mit „/“ als Trennzeichen

•lokale Pfadangabe durch relative URI <A href=``../../myoper/free.jpg``> parameter </A>

•Webseite enthält eine Menge von Betriebsmitteln mit gleicher Authority im URI


DNS Namensauflösung


Ablauf der Client-Server Kommunikation


Beispiel einer HTTP Sitzung

Ausgabe-Datei zu:www.ietf.org/rfc.html


Beispiel einer HTTP Sitzung


Architektur von Suchmaschinen


Client-Server Kommunikation im World Wide Web

Beispiel einer Client-Server-Interaktion bei einer Internet-Sitzung (nach Liebeherr)

Benutzer am Rechner argon.tcpip-lab.edu (“Argon”) greift im Web auf das URL

http://neon.tcpip-lab.edu/index.html

zu

Frage: Wie sehen die internen Netzabläufe bei dieser Transaktion aus?

argon.tcpip-lab.edu("Argon")

neon.tcpip-lab.edu("Neon")

Web request

Web page

Web client Web server


Namensauflösung mit DNS

•Namensauflösung des logischen Rechnernamens (hostid) neon.tcpip-lab.edu in eine IP Addresse erfolgt durch eine Abfrage in einem verteilten Datenbanksystem, dem Domain Name System (DNS)

•Alle Rechner im öffentlich zugänglichen Internet haben eine eindeutige IP-Adresse, z.B. die 32-Bit IPv4-Adressen:

argon.tcpip-lab.edu 128.143.137.144neon.tcpip-lab.edu 128.143.71.21

HTTP client DNS Server

argon.tcpip-lab.edu 128.143.136.15

neon.tcpip-lab.edu

128.143.71.21


Beispiel des IP-Vermittlungsnetzes

neon.tcpip-lab.edu"Neon"

128.143.71.21

argon.tcpip-lab.edu"Argon"128.143.137.144

router137.tcpip-lab.edu"Router137"

128.143.137.1

router71.tcpip-lab.edu"Router71"128.143.71.1

Ethernet NetworkEthernet Network

Router

Beispielnetz:


HTTP Funktionalität

HTTP-Protokollfunktionen:Web Browser instantiiert ein Client-Programm des HTTPWeb Server führt ein Server-Programm des HTTP ausHTTP Client sendet Anfragenachricht (request) an HTTP ServerHTTP Server sendet Antwortnachricht zur Anfrage (response)

HTTP client

Argon

HTTP server

Neon

HTTP requestHTTP response


Messung des HTTP-Protokolles mit Ethereal


Messung des HTTP- und TCP-Protokolles mit Ethereal


Kapitel 1.4

Grundlagen der Internet-Kommunikation


Das TCP/IP Protokollmodell

•entwickelt von Department of Defense (DoD) seit den 70er Jahren und 1983 offizielles Protokoll des ARPANET Wissenschaftsnetzes

•als Datennetz-Protokollstapel zur robusten paketorientiertenDatenkommunikation im Normal-, Spannungs- oder Kriegsfall

•Netz- und Vermittlungsrechner physisch getrennt


Das TCP/IP Protokollmodell

Anwendungsschicht des TCP/IP-Protokollstapels

•DNS: domain name system Telnet: Fernaufruf von Programmen

•ftp: file transfer protocol http: hypertext transfer protocol

•Smtp: simple mail transfer protocol snmp:simple network management protocol


Kapitel 1.4.1

Die Transportprotokolle TCP und UDP


TCP/IP Protokollmodell der Internetkommunikation

ApplicationLayer

NetworkLayer

Link Layer

IP

ARP HardwareInterface RARP

Media

ICMP IGMP

TransportLayer

TCP UDP

UserProcess

UserProcess

UserProcess

UserProcess

•Betrachtung der Transportschicht


Transportschicht-Protokolle im Internet

Internet Transportdienste:TCP: zuverlässige, die Reihenfolge erhaltende(geordnete) Unicast-Auslieferung

ÜberlastabwehrFlusskontrolleverbindungsorientierterDatentransfer

UDP: unzuverlässige (“best-effort”), ungeordnete Unicast-oder Multicast-Auslieferung:nicht verfügbare Dienste:

Echtzeit-TransportBandbreitengarantienzuverlässige Multicast Dienste

applicationtransportnetworkdata linkphysical

applicationtransportnetworkdata linkphysical

networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysical

Logischer Ende-zu-Ende Transport


Transportschichtprotokolle im Internet

UDP UDP -- User Datagram ProtocolUser Datagram ProtocolDatagramm-orientiertunzuverlässigverbindungsloses TransportprotokolleinfachUnicast und Multicast-Unterstützungfür Echtzeitanwendungen und Steuerungsanwendungen, z.B. Multimedia-Anwendungen, verwendbarfür andere Management-Dienstegenutzt

Netzmanagement (SNMP), Routing (RIP), Namensverwaltung (DNS), etc.

TCP - Transmission Control ProtocolStrom-orientiertzuverlässigverbindungsorientiertesTransportprotokollkomplexnur Unicast-Verbindungenfür viele Internet Anwendungenverwendet:

Web (http), Email (smtp), Dateitransfer (ftp), Terminalemulation (telnet), Identitätsmanagement (IMS) etc.

•Gegenüberstellung der beiden wichtigsten Transportprotokolle:


Kapitel 1.4.1.1

Das Transportprotokoll UDP


UDP: User Datagram Protocol [RFC 768]

ist reines unverfälschtesInternet Transportprotokollstellt “best effort” Dienst bereitUDP Segment können beimTransport

verloren gehennicht in der gesendetenReihenfolge an die Anwendungsschichtausgeliefert werden

ist verbindungslos:es gibt kein Handshake-protokoll zwischen UDP Sender und Empfängerjedes UDP Segment wirdunabhängig von allenanderen übermittelt

Warum gibt es UDP?Verzicht auf Verbindungsaufbauund –Aufbauverzögerungeinfaches, zustandslosesVerfahren: keine Verwaltungvon Verbindungszustands-information beim Sender oderEmpfängerkleine Segmentköpfe(Overhead)kein Überlaststeuerung: UDP kann so schnell wie nur möglichDaten senden


UDP Transport-Protokollstellt unzuverlässigen, verbin-dungslosen Transportdienst bereitoft für Anwendungen mitMultimedia-Strömen (streaming) genutzt:

in Grenzen verlusttolerante,ratensensitive Anwendungen

andere UDP Nutzer:Namensdienst: DNSNWM: SNMP

zuverlässiger Transfer über UDP: ergänze Zuverlässigkeit auf AnwendungsebeneanwendungsspezifischeFehlerbehebungsverfahren!

Quellenportnr. Zielportnr.

32 bit

Anwendungs-daten

(z.B. RTP-Nachricht)

UDP Segmentformat

Länge PrüfsummeLänge inByte des UDP Seg-mentes,inklusivePaketkopf


UDP Paketformat

IP header UDP header UDP data

UDP message length Checksum

DATA

20 bytes 8 bytes

0 15 16 31

Source Port Number Destination Port Number

• Portnummern identifizieren Sender- und Empfängerprozesse auf der Anwendungsschicht

• maximale Portnummernzahl ist 216-1= 65,535

• Nachrichtenlänge (Message Length) ist mindestens 8 Byte bei leerem Datenfeld und höchstens 65,535 Byte

• Prüfsumme (Checksum) für Paketkopf von UDP und einzelne IP Paketkopffelder


UDP Prüfsummenberechnung

Sender:behandle den Segmentinhaltdes Prüfobjektes als Folge von 16-Bit Integer-ZahlenPrüfsumme: Addition des Segmentinhaltes mitanschließender 1er KomplementbildungSender erstellt Wert derPrüfsumme im UDP Paketkopffeld checksum

Empfänger:berechnet die Prüfsumme des empfangenen Segmentsprüft, ob die berechnetePrüfsumme gleich dem Wert imPrüfsummenfeld ist bzw. addiertden gesamten Prüfobjekt- inkl. UDP-Inhalt und testet auf den Wert 111.....1111:

Nein – Fehler entdecktJa – kein Fehler entdeckt. Trotzdem kann es Über-tragungsfehler gegebenhaben!

Ziel: Fehlererkennung in übermittelten Segmenten, z.B. umgekippte Bits


Beispiel einer Prüfsumme im Internet

Algorithmus: addiere zwei 16-Bit Integer-Zahlen mit Übertrag, d.h. Addition modulo 216 – 1 gemäß der Vorschrift:1. x = (b0+b1 ) modulo 216 – 1 2. b2 = - x3. 0 = (b0+b1 +b2 ) modulo 216 – 1 - Testkriterium!

Beachte:beim Addieren von Zahlen muss ein Überlauf (Übertrag) des signifikantesten Bits zum Ergebnis hinzu addiert werden

Beispiel: 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Überlauf

SummePrüfsumme -x


UDP Prüfsummenberechnung

Nutzung dreier Komponenten beim Prüfobjekt:IP Pseudo-Paketkopf, UDP Paketkopf, Anwendungsdaten


Beispiel der UDP Prüfsummenberechnung

111..1111 ist ausgeschlossen, da das Objekt dann nur 0en umfasst.


Kapitel 1.4.1.2

Das Transportprotokoll TCP


Aufruf der Transport-Verbindung im Anwendungsprogramm

Grundprinzipien:Socket-Schnittstelle: als Pufferspeicher zum Datenaustausch zwischen

Anwendungsprozess und einem Ende-zu-Ende-Transport-Protokoll imInternet, z.B. TCP

TCP-Transportdienst: zum zuverlässigen Byte-Strom Transport von einemProzess zum anderen zwischen den beteiligten Rechnern (hosts)

Prozeß

TCP mitPuffern,Variablen

socket

steuerbar vomAnwendungs-programmierer

gesteuert vomBetriebssystem

Prozeß

TCP mitPuffern,Variablen

socketgesteuert vomBetriebssystem(Kernel)

Client-Host oderServer

Internet

steuerbar vomAnwendungs-programmierer


Transport-Protokollkonzepte

Konzepte:(a) abschnittsweise Sichtweise der (Daten-)Sicherungsschicht auf einem physikalischen

Übertragungsabschnitt (Link)(b) Ende-zu-Ende Sichtweise der Transportschicht über verbundene Übermittlungsabschnitte,

sog. Übermittlungswege

Physikalische Kommuni-kationsverbindung (Kanal)

Teilnetz

Logische Verbindung der

Programme in den Hosts

gerichteter Weg

im Netz


TCP-Eigenschaften RFCs: 793, 1122, 1323, 2018, 2581

zuverlässiger, Reihenfolge-erhaltenderByte-Strom Transport

fortlaufendes Senden von BytefolgenSendewiederholung bei Verlust

Überlast- und Sendefluss-Steuerung:Senderatenanpassung an Verarbeitungsgeschwindigkeit des EmpfängersTCP-Sendefluss-Steuerung durchFenstermechanismus

Sende- & Empfangspufferung

verbindungsorientierte Übertragung:3 Phasen: Aufbau einer logischenVerbindung, Übertragung der Daten, Abbau der Verbindung3-Wege-Handshake-Protokoll zurInitialisierung von Zuständen imSender- und Empfängersystem

Duplex-Übertragunggleichzeitige Datenübertragung in beide Richtungen der VerbindungBeschränkung der logischenDateneinheiten (Segmente) durchmaximale Segmentgröße (maximum segment size - MSS) der SDU

Punkt-zu-Punkt Daten-Übertragung :ein Sender & ein Empfänger einerVerbindung

socketIF

TCPSendepuffer

TCPEmpfangpuffer

socketIF

segment

Anwendungschreibt

Anwendungliest Daten


Eigenschaften von TCP: Zuverlässigkeit

• der Byte-Strom wird in einzelne Abschnitte unterteilt, sog. Segmente alsTCP-PDUs

• Empfängerprozess sendet Bestätigungsnachrichten (acknowledgements ACKs) für jedes Segment

• TCP unterhält eine Sendeuhr (timer). Falls kein ACK empfangen wird, erfolgt eine Sendewiederholung des gesendeten Segmentes

•Sendewiederholung durch Timeout der Sendeuhr oder doppelte ACKs (beider Grundversion TCP Tahoe) erzeugt

•Fehlererkennung:

• TCP nutzt Prüfsumme für Paketkopf und Nutzdatenfeld

•Segmente mit ungültigen Prüfsummen werden verworfen

• Jedes gesendete Byte (!) besitzt eine Sequenznummer als eindeutigeKennung zur Sicherung gegen Duplikate und Verluste


Segmentierung des TCP Byte-StromesMaximale Segmentgröße (Maximum Segment Size)

bezeichnet die maximale Größe der TCP-SDU (!), die bis zum Senden an der Quellegesammelt werdenist die beim Verbindungsaufbau durch eine Option vom Empfänger festgelegtemaximale Grunddateneinheit des Nutzdatentransportes zwischen Sender und Empfängerwird i.a. aus der Maximum Transmission Unit (MTU) der Schicht 2 abgeleitetBeispiele: typische DLL-PDU Länge von 576 Bytes enthält je 20 Byte für die IP und TCP Paketköpfe, also 536 Byte MSS für die TCP-VerbindungEthernet erzeugt MSS von 1460 Byte bei einer MTU von 1500 ByteIEEE 802.3 DLL erzwingt 1452 Byte MSS

Quelle Zielknoten

IPv4 AnschlussnetzIPv4 Kernnetz

IPv4 Zielnetz

IP-Transportwegmit Schicht 2 Kanalkapazität

IP-Transportpunkt IP-Transportpunkt

TCP HeaderIPv4 Paket


TCP Paketformat

IP header TCP header TCP data

Sequence number (32 bits)

DATA

20 bytes 20 bytes

0 15 16 31


Acknowledgement number (32 bits)

window sizeheaderlength 0 Flags

Options (if any)

TCP checksum urgent pointer

20 bytes

• ein TCP Segment (=PDU) besitzt 20 Byte Paketkopf mit L ≥ 0 Byte Daten als Nutzlast(SDU)


Felder des TCP Paketkopfes

Portnummer:• die Portnummer identifiziert den Endpunkt einer Transportverbindung.

das Paar <IP-Adresse, Portnummer> identifiziert einen Endpunktder Verbindung.

• Die beiden Paare <Client IP-Adresse, Client Portnummer> und <Server IP-Adresse, Server Portnummer> identifizieren die voll-duplex TCP Unicast-Verbindung n Verbindung mit dem Protokoll-identifikator.

• Der transportierte Datenstrom wird als Fluss (flow) bezeichnet,

TCP

IP

Applications

23 10480Ports:

TCP

IP

Applications

7 1680 Ports:



Sequenznummer (SeqNo):die Sequenznummer ist 32 Bit lang. der Sequenznummernraum ist

0 ≤ SeqNo ≤ 232 -1 ≈ 4.3 Gbyte Jede Sequenznummer identifiziert ein einzelnes Byte des transportiertenBytestromesdie initiale Sequenznummer (ISN) einer Verbindung wird beimVerbindungsaufbau festgelegtFrage: Was sind mögliche Anforderungen an die ISN ?

TCPSendepuffer

TCPEmpfangpuffer

socketIF

segment

Anwendungschreibt

Anwendungliest Daten


Ausschöpfen des Sequenznummernraumes

Größe des Sequenznummernraumes32 Bitfeld im TCP Paketkopf232 = 4.29x109 Byte = 34.3x109 Bit adressierbarbei Übertragungskapazität des TCP-Kanales von R=1 Gbps ist der Sequenznummernraum nach 34.3 Sekunden ausgeschöpft Byte-Zähler beginnt erneut beim Anfangswert (wraparound)

Lösung: Zeitstempel Option (RFC 1323) und Protection against Wraparound (PAWS) Algorithmus

füge 32 Bit Zeitstempel im Paketkopf jedes TCP Segmentes einZeitstempel + Sequenznummer → neue 64-Bit Sequenznummerzugehörige Uhr der Zeitstempel erfüllt die Bedingungen:• tickt mindestens im Rythmus von 1 Zeitschrittinkrement alle 231 Bits• der Zeitzyklus wird nicht in einer MSL Periode ausgeschöpft• Beispiel:

Zeitschritt alle 1 ms bei 8 Tbps Kanalrate ist erst nach 25 Tagen ausgeschöpft


Fensterskalierungsoption (RFC 1323)•Skalierung des 32-Bit Fenstervariablenwertes durch einen zusätzlichen Faktor

•Empfängerfenstervariable WindowSize = rwnd nur 16 Bit, aber Fenstervariablen 32 Bit Werte

•als Linksverschiebung des 32-Bit-Wertes der Sende- und Empfängerfenstervariablen Window = min (cwnd, rwnd) um den Inhalt des Shift Count Feldes

•0 ≤ Shift Count ≤ 214 , 0 entspricht keiner Skalierung (NOP)

•Wertebereich:

•131.070 Byte = 65.535 * 21 ≤ Window ≤ 65.535 * 214 = 1.073.725.440 Byte

•Übertragen der Option im Paketkopf jedes TCP-Segmentes & Anpassen des Empfängerspeichers



Bestätigungsnummer (Acknowledgement Number AckNo):Bestätigungen (Acknowledgements) werden huckepack (piggyback) verschickt, d.h.

ein TCP-Segment von A -> B kann eine Bestätigung eines Datenpakets(TCP-SDU), das in Richtung B -> A verschickt wurde, enthalten

Frage: Warum ist Huckepackversendung (piggybacking) gut ?

Ein Anwendungssystem verwendet das AckNo Feld zum Senden von Bestätigungen.

• falls ein Rechner eine AckNo in einem Segment verschickt, setzt er das “ACK flag”Das AckNo Feld enthält die nächste Sequenznummer, auf deren Empfang derRechner wartetBeispiel: Die Bestätigung eines Segmentes mit den

Sequenznummern 0-1500 ist AckNo=1501

AB



Bestätigungsnummer (cont’d)TCP verwendet ein Flusssteuerungsverfahren mit Sendefenster (sliding window flow protocol) zur Regelung des Verkehrsflusses zwischen Sender und EmpfängerTCP (in der Grundversion Tahoe) benutzt folgende Variationen zurSteuerung des Sendefensters:

keine NACKs (Negative ACKnowledgement)nur kumulative ACKs

Beispiel:Annahme: Sender sendet zwei Segmente mit “1..1500” und “1501..3000” Byte, aber der Empfänger erhält nur das zweite Segment.In diesem Fall kann der Emfänger das zweite Paket nicht bestätigen. Erkann nur senden AckNo=1, d.h. das 1. Byte des 1. Segmentes wird erwartet!



Paketkopflänge (Header Length 4 Bit):bezeichnet die Länge des TCP-Paketkopfes als Vielfaches von 32-bit WortenMan beachte die variable Länge des Paketkopfes (mit Minimum 20 Byte) aufgrund der Optionen

IP header TCP header TCP data

Sequence number (32 bits)

DATA

20 bytes 20 bytes

0 15 16 31


Acknowledgement number (32 bits)

window sizeheaderlength 0 Flags

Options (if any)

TCP checksum urgent pointer

20 bytes


TCP Segment-Format

Quellen-Portnr. Ziel-Portnr.

32 Bit

Anwendungs-daten (HTTP)

(variabler Länge)

SequenznummerQuittungs-(ACK)-Nummer

EmpfängerfensterZeiger eilige DatenPrüfsumme

FSRPAUKopflänge

nichtgen.

Optionen (variabler Länge)

URG: eilige Daten (generell ungenuzt)

ACK: ACK #gültig

PSH: liefere Daten aus(generell ungenutzt)

RST, SYN, FIN:Verbindungsauf-und -abbau Kommandos

Zahl der Bytes die Empfängerakzeptiert

Zähler der Bytes des Datenstroms(nicht Segmente!)

InternetPrüfsumme

(wie in UDP)



Flag Bits:URG: Zeigerfeld Urgent ist gültig

falls das Bit gesetzt ist, enthalten die nachfolgenden Bytes einedringend auszuliefernde Nachricht im Bereich:

SeqNo ≤ dringende Nachricht ≤ SeqNo+urgent ZeigerwertACK: Bestätigungsnummer (Acknowledgement Number) ist gültigPSH: PUSH Flag

ist eine Benachrichtigung vom Sender zum Empfänger, dass derEmpfänger alle erhaltenen Daten seines Empfängerspeichers an die Anwendungsschicht ausliefern soll.wird normalerweise vom Sender gesetzt, wenn der Senderspeicherleer ist



Flag Bits:RST: Zurücksetzen der Verbindung (Reset)

Der Bitschalter (flag) veranlasst den Empfänger seinen TCP-Verbindungsautomaten zurückzusetzenDer Empfänger der RST Nachricht beendet die Verbindung und zeigtder höheren Schicht die Beendigung an

SYN: Synchronisation der Sequenznummernwird im ersten Paket gesendet, wenn eine Verbindung initiiert wird

FIN: Sender beendet die Übertragung (finished)wird zum Schließen einer Verbindung verwendetBeide Kommunikationspartner einer Verbindung müssen eine FIN Nachricht schicken


TCP Segment-Format

Quellen-Portnr. Ziel-Portnr.

32 Bit

Anwendungs-daten (HTTP)

(variabler Länge)

SequenznummerQuittungs-(ACK)-Nummer

EmpfängerfensterZeiger eilige DatenPrüfsumme

FSRPAUKopflänge

nichtgen.

Optionen (variabler Länge)

URG: eilige Daten (generell ungenuzt)

ACK: ACK #gültig

PSH: liefere Daten aus(generell ungenutzt)

RST, SYN, FIN:Verbindungsauf-und -abbau Kommandos

Zahl der Bytes die Empfängerakzeptiert

Zähler der Bytes des Datenstroms(nicht Segmente!)

InternetPrüfsumme

(wie in UDP)


TCP-Segment-Format Beispiel



Empfängerfenstergröße (Window Size):Jede Seite einer Verbindung zeigt die unterstützte Empfängerfenstergröße anDie Fenstergröße ist die maximale Bytezahl, die der Empfänger speichernkann.Maximale Fenstergröße ist 216-1= 65535 Byte

TCP Prüfsumme (Checksum):TCP Prüfsumme erstreckt sich über den TCP Paketkopf und die TCP Nutzdaten sowie einzelne Teile des IP Paketkopfes

Urgent Pointer:ist nur bei gesetztem URG Flag gültig



Optionen:

End ofOptions kind=0

1 byte

NOP(no operation) kind=1

1 byte

MaximumSegment Size kind=2

1 byte

len=4

1 byte

maximumsegment size

2 bytes

Window ScaleFactor kind=3

1 byte

len=3

1 byte

shift count

1 byte

Timestamp kind=8

1 byte

len=10

1 byte

timestamp value

4 bytes

timestamp echo reply

4 bytes

•MSS- bezeichnet die Länge der TCP-SDU

•skaliert das Fenster bei großem Bandbreite-Verzögerungs-produkt



Optionen: NOP wird zum Ergänzen (padding) des TCP Paketkopfes auf Vielfache von 4 Byte verwendetMaximale Segmentgröße (Maximum Segment Size – MSS)• bezeichnet die maximale Länge der TCP SDU

Fensterskalierung (Window Scale Options)Erhöht das TCP Sendefenster von 16 auf 32 Bit, d.h. die Wertedes Fenstergrößenfeldes wird durch Multiplikation mit einemSkalierungsfaktor anders interpretiertDiese Option kann nur im (ersten) SYN Segment während des Verbindungsaufbauphase verwendet werden

Zeitstempel (Timestamp Option)kann zur Messung der Umlaufzeit der PDUs verwendet werden


Kapitel 1.4.2

Verbindungsmanagement von TCP


TCP-Verbindungsaufbau

Idee: TCP Sender & Empfängererzeugen eine “Verbindung” bevorDatensegmente ausgetauschtwerdeninitialisiere TCP Variablen:

SequenznummernPuffer, Flusssteuerungsinfor-mationen (RcvWindow)

Client: initiiert VerbindungSocket clientSocket = new Socket("hostname","port

number");

Server: vom Client angesteuertSocket connectionSocket = welcomeSocket.accept();

Drei-Wege-Handshake:

Schritt 1: Client-Rechner sendet TCP SYN Segment an den Server

spezifiziert initiale Sequenznummerkeine Daten transferiert

Schritt 2: Server empfängt SYN, antwortet mitSYNACK Segment

Server weist Pufferspeicher zuspezifiziert initiale Sequenznummer

Schritt 3: Client empfängt SYNACK, antwortetmit ACK Segment, das schon weitereDaten enthalten kann


TCP-Verbindungsaufbau

6-31

Konzepte:•Aufbau der Verbindung durch SYNchronisationsnachricht

• Nummerierung der Segmente beim Start durch zufällige Sequenznummern, SEQ = x, y

• Anfordern des neu erwarteten Segmentes durch positive Bestätigungen (ACK)

Zeit

ACK

ClientClient ServerServer


Messung des TCP Handshake-Verfahrens


TCP Verbindungsaufbau

TCP benutzt ein Drei-Wege-Handshake Protokoll zum Öffnen einer Verbindung zwischen Endsystemen:(1) Aktives Öffnen (ACTIVE OPEN): Client sendet ein Segment mit

gesetztem SYN Bit *Portnummer des Clientsinitialer Sequenznummer (ISN) des Clients

(2) Passives Öffnen (PASSIVE OPEN): Server antwortet mit einemSegment mit

gesetztem SYN Bit *initialer Sequenznummer des ServersACK für ISN des Clients

(3) Client Bestätigung durch Senden eines Segments mit:ACK ISN des Servers (* zählt als ein Byte)


Verbindungsaufbau mit 3-Wege Handshake-Protokoll

aida.poly.edu mng.poly.edu

S 1031880193:1031880193(0)win 16384 <mss 1460, ...>

S 172488586:172488586(0)

ack 1031880194 win 8760 <mss 1460>

ack 172488587 win 17520

win= Empfänger-fenstergröße


TCP Verbindungsabbau

Schließen einer Verbindung:

Client schließt die socket Schnittstelle:clientSocket.close();

Schritt 1:

Client Endsystem sendet ein TCP FIN Steuerungssegment an den Server

Schritt 2:

Server empfängt FIN & antwortet mit ACK. schließt die Verbindung, sendet FIN.

Client

FIN

Server

ACK

ACK

FIN

close

close

geschlossenW

arte

zeit


TCP Verbindungsabbau

Client

FIN

Server

ACK

ACK

FIN

closing

closing

geschlossen

War

teze

it

Schritt 3:

Client empfängt FIN, antwortet mit ACK:

geht in zeitgesteuerten “Wartezeit” -Zustand (“time_wait”)

antwortet mit ACK auf in der Zwischenzeit erhaltene FINs

Schritt 4:

Server empfängt ACK. Verbindunggeschlossen.

Notiz: simultaner FIN Empfang durchgeringe Modifikationen bearbeitbar


Zustände des TCP-Automaten in normalen Verbindungsphasen

SYN (SeqNo = x)

SYN (SeqNo = y, AckNo = x + 1 )

(AckNo = y + 1 )

SYN_SENT(active open)

SYN_RCVD

ESTABLISHED

ESTABLISHED

FIN_WAIT_1(active close)

LISTEN(passive open)

FIN (SeqNo = m)

CLOSE_WAIT(passive close)

(AckNo = m+ 1 )

FIN (SeqNo = n )

(AckNo = n+1)LAST_ACK

FIN_WAIT_2

TIME_WAIT

CLOSED


Zustände des TCP-Automaten

State Description

CLOSED No connection is active or pendingLISTEN The server is waiting for an incoming callSYN RCVD A connection request has arrived; wait for AckSYN SENT The client has started to open a connectionESTABLISHED Normal data transfer stateFIN WAIT 1 Client has said it is finishedFIN WAIT 2 Server has agreed to releaseTIMED WAIT Wait for pending packets (“2MSL wait state”)CLOSING Both Sides have tried to close simultanesouslyCLOSE WAIT Server has initiated a releaseLAST ACK Wait for pending packets


Automat des TCP Verbindungsaufbaues

CLOSED

LISTEN

SYN RCVD SYN SENT

ESTABLISHED

active opensend: SYN

recv: SYN, ACKsend: ACK

recv: SYNsend: SYN, ACK

recvd: ACKsend: . / .

recv:RST

Application sends datasend: SYN

simultaneous openrecv: SYNsend: SYN, ACK

close ortimeout

passive opensend: . / .

recvd: FIN send: FIN

send:FIN


Automat des TCP Verbindungsabbaues


2MSL Wartezustand

2MSL Wartezustand = TIME_WAITWenn TCP ein aktives Schließen (active close) durchführt und einabschließendes ACK sendet, muß die Verbindung im Zustand TIME_WAIT für die doppelte Dauer der maximalen Segmentlebensdauer verweilen.2MSL= 2 * Maximum Segment Lifetime

Warum erfolgt diese Maßnahme? TCP wird die Chance eingeräumt, das abschließende ACK erneut zuverschicken. Der Server wird nach dem Senden des FIN Segments in eineAuszeit (timeout) übergehen und das FIN erneut schicken.Die MSL wird auf 2 Minuten, 1 Minute oder 30 Sekunden gesetzt.


Zurücksetzen einer Verbindung

Zurücksetzen einer TCP-Verbindung erfolgt durch das Setzen des RST Steuerbits (flag) im PaketkopfWann wird das RST Steuerbit gesetzt?

wenn eine Verbindungsanfrage ankommt und am Zielport ist keinServerprozess vorhanden, der eine Anfrage erwartetbeim Abbruch (Terminate) einer Verbindung

• das Ereignis veranlasst den Empfängerprozess, die gespeichertenDaten zu löschen

• der Empfängerprozess bestätigt den Erhalt eines RST Segmentes nicht!


Kapitel 1.4.3

Fehlerkontrolle bei TCP


TCP-Sequenznumerierung und Paket-Bestätigungen

Sequenznummern:Byte-Strom-“Nummer” des erstenBytes eines Daten-Segmentes

Bestätigungen (ACKs):Sequenznummer des nächstenvom Sender erwarteten Byteskumulierte ACKs zur Bestätigungmehrerer Segmentfolgen

Frage: Wie regelt EmpfängerSegmentempfang beiReihenfolgestörungen ?

Antwort: TCP Spezifikation sagt nichtsaus - Lösung

implementierungsabhängig!

Host A Host B

Seq=42, ACK=79, Daten = ‘C’

Seq=79, ACK=43, Daten = ‘C’

Seq=43, ACK=80

Nutzersendet

‘C’

Host ACKtEmpfangdes Echos

‘C’

Host ACKtEmpfangvon ‘C’, sendetEcho ‘C’ zurück

Zeiteinfaches Telnet Ping-Pong Beispiel


TCP SendewiederholungenHost A

Seq=92, 8 byte Daten

ACK=100

Verlust

Zeit verlorene ACKs

Host B

X


ACK=100

tim

eout

Host A


ACK=100

Seq=

92 t

imeo

ut

Zeit vorzeitiger Timeout,kumulierte ACKs

Host B


ACK=120


Seq=

100

tim

eout

ACK=120

RTT+

δ

(Schleifen)Durchlaufzeit = round-trip-time (RTT) Verarbeitungszeit im Host = δ

timeout > RTT + 2 δ

δ

δ


Sendewiederholungen bei TCP

Der TCP Sender wiederholt einübertragenes Segment, wenn er dasEintreten folgender Ereignissebeobachtet:1. es wurde keine Bestätigung (ACK)

empfangen und eine Zeitüberschreitungder Sendeuhr (timeout) ist aufgetreten

2. mehrere ACKs für dasselbe Segment wurden empfangen (duplicate ACK)

Es wird ein Verlust des Segementsunterstellt.

Host A


ACK=100

Verlust

Zeit

verlorene ACKs

Host B

X


ACK=100

tim

eout

RTT+

δ

δ

δ


XACK=100


Empfang doppelter Bestätigungen (duplicate ACKs)

TCP Reno:falls drei oder mehr Duplikateeiner Bestätigungen empfangenwurden, unterstellt der TCP Sender den Verlust einesübertragenen Segmentesdanach führt der TCP Sender eine Sendewiederholungderjenigen Segmente durch, die als verloren gegangen unterstelltwerden, ohne auf eine Zeit-überschreitung (Timeout) derSendeuhr zu warten.dadurch kann der Verlusteinzelner Segmente überwundenwerden

1K SeqNo=0

AckNo=1024

AckNo=1024

1K SeqNo=1024

SeqNo=20481K

AckNo=1024

SeqNo=30721K

SeqNo=40961K

1. duplicate

2. duplicate

AckNo=1024

SeqNo=10241K

SeqNo=51201K

3. duplicate


Sendewiederholungsuhr (Retransmission Timer)

Prozess:der TCP Sender besitzt für jede aktive Verbindung eine Sendewieder-holungsuhr (Retransmission Timer)wenn diese Uhr einen Schwellwert, den sog. Retransmission Timeout (RTO) Wert, erreicht, wird das erste nicht bestätigte Segment erneut gesendetdie Sendewiederholungsuhr wird gestartet, wenn– ein TCP-Segment mit Nutzlast übertragen wird und die Uhr noch nicht

läuft– eine Bestätigung (ACK) ankommt, die übertragene neue Daten bestätigt, – ein Segment erneut übertragen wirddie Uhr wird angehalten, wenn

alle übertragenen Segmente bestätigt werdenProbleme:

zu kleine RTO Werte erzeugen unnötige Sendewiederholungenzu große RTO Werte erzeugen zu lange Wartezeiten vor einer Sende-wiederholung

⇒ aufgrund der variablen Netzverzögerung muss der RTO adaptiv geregeltwerden


RTO Bestimmung

die Bestimmung des RTO Wertes beruht auf der Messung der Paketumlaufzeiten(round-trip time RTT) durch den TCP Sender

Segment 1

Segment 4

ACK for Segment 1

Segment 2Segment 3

ACK for Segment 2 + 3

Segment 5

ACK for Segment 4

ACK for Segment 5R

TT #1R

TT #2R

TT #3

• jede TCP Verbindung misst die Zeitdifferenz zwischen dem Sendeneines Segmentes mit SEQNO und dem Empfang der zugehörigenQuittung (ACK)

• zu jedem Zeitpunkt existiert nur eineMessung (d.h., Messungenüberlagern sich nicht)

• Beispiel: •es werden drei RTT Messungndargestellt.


RTO Bestimmung

RTO wird auf Basis der RTT Messungen errechnetzur Berechnung der Schätzwerte der Umlaufverzögerung srtt und der zugehörigenVarianz rttvar wird ein “Moving-Average” Verfahren (MAV) (Gleitfenster-Technik, gleitender Mittelwert) der Zeitreihenanalyse verwendet

die aktuellen RTT Meßwerte RTT werden durch MAV zu einem geglättetenSchätzwert srtt bzw. rttvar verarbeitet:

srttn+1 = α RTT + (1- α ) srttnrttvarn+1 = β ( | RTT – srttn+1 | ) + (1- β ) rttvarn

RTOn+1 = srttn+1 + 4 rttvarn+1

Die Konstanten werden i.a. auf α =1/4 und β =1/8 gesetzt.Die letzte Gleichung ist an die Normalverteilungshypothese angelehnt, d.h. Prob{ | RTT - E(RTT) | / ( Var(RTT) )½ < 4 } ≈ 0.999936und die Schätzung der Standardabweichung ( Var(RTT) )½ durch die mittlereMittelwertabweichung | RTT – srttn+1 |, da Integerarithmetik verwendet werden soll.


RTO BestimmungStartbelegung des RTO Wertes:

Sender setzt den Startwert von RTO auf RTO0 = 1.5 sec

(bis 3 sec bei erfolglosen Mehrfachversuchen)

RTO Berechnung erfolgt nach Eingang der ersten RTT Messung

srtt1 = RTT rttvar1 = RTT / 2RTO1 = srtt1 + 4 rttvar1

Wenn ein Timeout auftritt, wird der RTO Wert verdoppelt

RTOn+1 = max ( 2 RTOn, 64) sec Das Verfahren heißt exponential backoff.


Der Algorithmus von Karn

Problem:falls ein ACK eines erneut übertragenen Segmentes empfangen wird, kann der Sender nicht bestimmen, ob es zum Original oder der erneut über-tragenen Kopie gehört ⇒ RTT Messung ist in diesem Fall mehrdeutig.

Karns Algorithmus: Trennung der RTT und Retranmission Timer Berechung•aktualisiere den Wert srtt nicht für jene Segmente, die erneut übertragenwurden, und starte die RTT-Messung nur für neue Übertragungen erneut•bei jeder Sendewiederholung nach einer Schwellwertüberschreitung setze:

RTOn+1 = max ( 2 RTOn, 64) (exponential backoff)

Sender Empfänger

Originalübertragung

ACKSam

pleR

TT Sendewiederholung

Sender Empfänger

Originalübertragung

ACK

Sam

pleR

TT

Sendewiederholung


Beispiel einer RTO Bestimmung

RTT #1 RTT #3

Seg

men

t 1

AC

K for Segm

ent 1

SY

N

SY

N + A

CK Se

gmen

t 2Se

gmen

t 3

AC

K for S

egment 2

AC

K for

Segment 3

RTT #2

Segm

ent 4

.Se

gmen

t 5

.

Segm

ent 6

.

AC

K for

Segment 4

AC

K

1 20 3 4 5 7 86 9 10 11 12 13 14 15 17 1816 19 20 21 23 2422


Messung der Umlaufzeit (Round trip time)

Das Sendewiederholungsverfahren in TCP reagiert adaptiv und bezieht den Netzzustand einDie Sendewiederholungsuhren (retransmission timer) werden anhand der vomTCP Sender ausgeführten Round-Trip Time (RTT) Messungen errechnet

Segment 1

Segment 4

ACK for Segment 1

Segment 2Segment 3

ACK for Segment 2 + 3

Segment 5

ACK for Segment 4

ACK for Segment 5R

TT #1R

TT #2R

TT #3

•Paketumlaufzeit RTT bezeichnet die Zeitdifferenz zwischen dem Sendeneines Segments SEQNO und demEmpfang der Quittung ACKProblem:

•TCP bestätigt nicht jedeseinzelne Segment•jede Verbindung hat nur EINE Sendeuhr


Messung der Umlaufzeit (Round trip time)

die Sendewiederholungsuhr (Retransmission timer) wird durch einenSchwellwert Retransmission Timeout (RTO) gesteuert.RTO wird mittels der RTT Messungen berechnet. aktuelle RTT Messungen werden durch die Moving-Average Schätzersrtt und rttvar geglättet:

srttn+1 = α RTT + (1- α ) srttnrttvarn+1 = β ( | RTT - srttn+1 | ) + (1- β ) rttvarn

RTOn+1 = srttn+1 + 4 rttvarn+1

mit den Konstanten α =1/4 and β =1/8 und Startwertensrtt0 = 0 sec, rttvar0 = 3 sec, RTO1 = srtt1 + 2 rttvar1


TCP Zeitüberwachungsverwaltung (Timeout Management)

(a) Dichtefunktion der ACK Ankunftszeiten auf der Sicherungsschicht im Festnetz zwischenNetzelementen

(b) Dichtefunktion der ACK Ankunftszeiten für TCP auf Ende-zu-Ende Basis


TCP Round Trip Time (RTT) und Timeout Bestimmung

Beispiel: TCP-RTT Zeitreihe und geglättete Variante nach Gleitfenster-Technik (MovingAverage)


Kapitel 1.4.4

Flusskontrolle und Überlaststeuerung bei TCP


Flusssteuerung, Überlast- und Fehlerkontrolle in TCP

• Flußsteuerung (flow control):Algorithmus verhindert, dass der Sender den Empfängerspeicher mitNachrichten überflutet

• Überlastkontrolle (congestion control):Algorithmus verhindert, dass der Sender die Zwischenspeicher derRouter auf dem Weg zwischen Sender und Empfänger überlastet

• Fehlerkontrolle (error control):Algorithmus zur Behebung oder Abmilderung der Wirkungen von Paketverlusten

Jede Betriebsmittelverwaltungsfunktion hat unterschiedlicheZielsetzungen.

Aber ihre Implementierungen werden zusammengeführt


Fensterverwaltung in TCP

Der Empfänger sendet in den TCP Paketköpfen zwei Steuerungs-parameter AckNo und rwnd zum Sender

Interpretation (beim Sender):• Empfängerinstanz kann neue Daten empfangen mit

SeqNo= AckNo, AckNo+1, …., AckNo+rwnd-1

weitere MerkmaleEmpfänger kann die Daten ohne das Öffnen des Empfängerfensters rwndbestätigenEmpfänger kann die Fenstergröße rwnd ohne Bestätigung von Datenverändern (z.B. Enable TCP-Freeze)

AckNo window size(win)

32 bits 16 bits(rwnd)


TCP Flußkontrolle

Empfänger: informiert Sender explizit über (dynamischveränderte) Größe des freienEmpfangspufferspeichersdurch

Empfängerfenster(RcvWindow) Feld imTCP Paketkopf

Sender: hält die Menge derübermittelten unbestätigtenDaten kleiner als das zuletztempfangene RcvWindow

Sender überfüllt nichtden Empfangspuffer, in dem er zu viele Segmen-te zu schnell überträgt

Flußkontrolle

Empfangspuffer

RcvBuffer = Größe des TCP Empfangspuffers

RcvWindow = freier Speicher im Puffer

freier Empfangsspeicherplatz= RcvWindow= RcvBuffer-[LastByteRcvd -

LastByteRead]


TCP Überlaststeuerung

Ende-zu-Ende Regelung der Endsysteme ohne Netzunterstützung oder -eingriffeBegrenzung der Übertragungsrate

durch ein Sendefenster variabler Größe (congestion window size) CWNDüber TCP Segmente der Größe MSS [Byte]

Durchsatz (throughput) = W * MSSRTT Byte/s

CWND

schon mit ACK

bestätigt

abgeschickt

nicht ACKt

nutzbare Seq.nr

ungenutzt

gesperrte Seqnr.

•Durchsatz aus der TCP-Anwendungssicht bei (mittlerer) Größe CWND=W:


Zuverlässiger Datentransfer in TCP

vereinfachter TCP-Sender: •keine Flusskontrolle•keine Überlastabwehr

waitfor

event

warteauf

Ereignis

Ereignis: Daten aus Anwendungs-schicht erhalten

Ereignis: Uhr läuft fürSegment mit Seq.nr. y ab

Ereignis: ACKempfangen,mit ACK # y

erzeuge & sende Segment

Sende Segment erneut

ACK Verarbeitung


Vereinfachter TCP Sender ohne Überlast- oder Flusssteuerung

NextSeqNum = InitialSeqNumSendBase = InitialSeqNumloop (forever) {

switch(event)event: data received from application above

create TCP segment with sequence number NextSeqNumif (timer currently not running)

start timerpass segment to IP NextSeqNum = NextSeqNum + length(data)

event: timer timeoutretransmit not-yet-acknowledged segment with

smallest sequence numberstart timer

event: ACK received, with ACK field value of y if (y > SendBase) {

SendBase = yif (there are currently not-yet-acknowledged segments)

start timer }

} /* end of loop forever */

Annahmen:• SendBase-1: letzteskumulativgeACKck’tes ByteBeispiel:• SendBase-1 = 71;y= 73, derEmpfängererwartet 73+ ;y > SendBase, dasneue Datenelementist bestätigt (ACK)


TCP ACK Erzeugung [RFC 1122, RFC 2581]

Ereignis (Event)

geordnete Segmentankunft, keine Lücken in den Folgen,sonstige Segmente ACKed

geordnete Segmentankunft,keine Lücken in den Folgen,ein verzögertes ACK erwartet

ungeordnete Segmentankunft,höhere Seq.-nr. als erwartetLücke in der Folge entdeckt

Ankunft eines Segmentes, dasteilweise oder vollständig dieLücken füllt

TCP Empfänger-Reaktion

verzögertes ACK: warte bis zu 500msauf das nächste Segment; kommt keinneues Segment, sende ACK

sende sofort ein kumulatives ACK

sende ACK-Duplikat, zeige Seq.-nummerdes nächsten erwarteten Bytes an

sofort ACK senden, falls Segment amunteren Ende der Lücke in der Folgebeginnt


Übertragungseffizienz

Beispiel:•ein TCP Anwender sendet via Telnet jeweils 1 Zeichen in konsekutivenZeitschritten ein•die TCP Quelle sendet es als ein TCP Segment pro Zeichen von 41 Byte

•der Empfänger sendet eine Bestätigung (ACK) von 40 Byte•der Emfänger gibt das Zeichen als Echo zurück (41 Byte)•der Sender bestätigt das Echo (40 Byte)•Bilanz: 162 Bytes werden übertragen, um 1 Zeichen auszutauschen

Frage: Wie lange soll der Sender warten, bis er Daten überträgt, wenn das Sendefenster

sehr gering geöffnet ist, z.B. weniger als MSS Byte?Wie sollte eine effiziente Übertragung gestaltet werden?

Lösung: http://www.ietf.org/rfc/rfc0896.txt?number=896


Naigles Algorithmus (RFC 896)

Naigles Sendealgorithmus:if there is new data to send

if the window size and available data is ≥ MSS send complete MSS size segment now

elseif there is unconfirmed data still in the pipe

enqueue data in the buffer until an Acknowledgeis received

elsesend data immediately

Empfänger zeigt dem Sender ein selbsttaktendes Verhalten durch ACKs an (vgl. auch Abschaltung durch TCP_NODELAY Option)

bei kurzen RTTs,z.B. in LANs, wird häufig mit geringer Effizienz gesendetbei langen RTTs, z.B. in WANs, wird seltener mit größerer Effizienz gesendet


Beispiel der Ineffizienz bei Gleitfenster-Technik

nach SpaniolProblem: zu kleine Öffnung des Empfängerfensters


Beispiel Silly Window Syndrom

aus http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm

•ein ähnliches Problem kann beim Sender durch Verschicken kleiner Datenvolumen inter-aktiver Anwendungen entstehen.

•Frage: Wann sollte ein Sender Segmente ver-schicken?


Silly Window Syndrom

nach Spaniol

Idee nach Clark: Vermeide das Sendens kleiner Nutzdatenvolumen in einer TCP-PDU

•Der Empfänger muss mit der Fensteraktualisierung warten, bis der Empfangsspeicher wieder nahezu leer ist oder die Rückgabe der Bestätigungen (ACKs) verzögern:

•warte bis MSS Daten oder mindestens die Hälfte der Empfängerspeichergröße verfügbar ist


Entwicklung der TCP-ÜberlastabwehrverfahrenTCP Tahoe (1988, FreeBSD 4.3 Tahoe)

Slow Start PhaseCongestion Avoidance PhaseFast Retransmit Protokoll

TCP Reno (1990, FreeBSD 4.3 Reno)Fast Recovery Protokoll

New Reno (1996)verbesserte Reaktion auf mehrfachen Paketverlust

TCP SACK (1996)Variante wie ARQ Selective Repeat

Random Early Detection (RED) (Floyd and Jacobson 1993)Randomisieren der Paketverluste zwischen Verbindungen beiÜberschreiten eines Pufferschwellwertes


TCP-Überlastabwehrverfahren

TCP implementiert im Senderprozess ein Verfahren zur Überlast-abwehr auf Basis einer Gleitfenster-Technik mit zwei Parametern:

Sende-(Steuerungs-)fenster (Congestion Window cwnd)

Sendefenster-Schwellwert, sog. Slow-start Threshhold (ssthresh)

Startwert ist die angebotene Fenstergröße oder 65 KByte.

Überlastkontrolle arbeitet in in zwei Modi:

Slow Start Phase für cwnd < ssthreshCongestion Avoidance Phase für cwnd ≥ ssthresh


TCP Überlaststeuerung: Phase 1 “Slowstart”

exponentielles Anwachsen pro RTT in derSendefenstergröße (nicht so langsam!)

Verlustereignis := timeout (Tahoe TCP)

und/oderduplizierte Quittungen (duplicate ACK) bei TCP Tahoedrei gleiche (duplizierte) ACKs bei TCP Reno

Initialisiere: CWND = 1for (jedes Segment ACKt)

CWND=CWND+1until (Verlustereignis OR

CWND > ssthreshold)

Slowstart AlgorithmusHost A

ein Segment

RTT

Host B

Zeit

zwei Segmente

vier Segmente

Idee: zweiphasiger Bandbreitentest des Kanals bis zu einem Paketverlust


TCP Überlaststeuerung: Phase 2 “Congestion Avoidance”

Initialwert:cwnd = 1;ssthresh =

advertised window size;Ankunft eines neuen Ack:

if (cwnd < ssthresh) /* Slow Start*/cwnd = cwnd + 1;

else/* Congestion Avoidance */cwnd = cwnd + 1 /cwnd;

Timeout:/* Multiplicative decrease */ssthresh = cwnd/2;cwnd = 1; (H1)call slowstart;

⇒ AIMD Algorithmus wächst

Anzahl der Übertragungen (RTTs)

CWND

•cwnd höchstens um den Wert 1 MSS pro RTT, falls alle cwnd im Sendefensterverschickten Segmente bestätigt wurden.•(H1): TCP Reno überspringt Slow-Start (fast recovery) nach drei duplizierten ACKs


Sendefensterverlauf von TCP Tahoe

Verlauf des cwnd für eine TCP-Tahoe Verbindung mit MSS = 1500 Bytes:


Quittungen in TCPEmpfänger sendet positive Quittungen(ACK) zum Sender zurück

ACK wird zur Flusssteuerung, Fehlerkontrolle und Überlastabwehrverwendet

ACK Wert bezeichnet die Sequenz-nummer des als nächstes erwartetenBytes

verzögerte Bestätigungen (ACK): TCP Empfänger verzögert normalerweise die Übertragung einer Bestätigung um bis zu200 ms

Ursache?

Segmentverlust


Quittungen in TCP

Ankünfte außer der Reihe

•ACKs werden nicht verzögert, wennPakete außerhalb der Sendereihenfolgeeintreffen

•Grund?


Fast Retransmit Protokoll

falls drei oder noch mehrduplizierte ACKs empfangenwerden, geht der TCP Sender vom Verlust eines gesendetenSegmentes aus.

Dann führt der TCP Sender die erneute Übertragung eines alsverloren geglaubten Segmentesaus, ohne auf die Zeitüber-schreitung der Sendeuhr zuwarten.

Dann wird in die Slow-Start Phase umgeschaltet mit:

ssthresh = cwnd/2cwnd = 1

3 DupACKs 3

Paket 1Paket 2Paket 3Paket 4

Paket 5

Paket 6

RetransmitPaket 3

ACK 2

ACK 3

ACK 3

ACK 3

ACK 7

ACK 3

Sender Empfänger


Fast Recovery Protokolldas Fast Recovery Protokoll vermeidet den Übergang in die Slow-Start Phase nacheinem “fast retransmit” Ereignis

Begründung: doppelte ACKs zeigen einenDatentransport zum Empfänger an, abermindesens ein Segment ging dabeiverloren

nach dem Epfang von drei dupliziertenACKs führt TCP folgende Aktionen aus:

sende das “verlorene Paket” erneutssthresh = max(cwnd/2,2)cwnd = cwnd+3gehe zur Congestion Avoidance Phase übererhöhe für jedes zusätzlich empfangeneACK Duplikat cwnd um 1

bei Ankunft eines ACK,das “neue Daten” bestätigt (hier: AckNo=2048), setze:

cwnd=ssthreshgehe in die Congestion Avoidance Phase über


TCP Reno

Wirkung duplizierter Bestätigungen (duplicate ACKs):• Fast Retransmit Phase• Fast Recovery Phase

Fast Recovery Protokoll vermeidet den Übergang zur Slow-Start Phase

Wirkung einer Zeitüberschreitung (Timeout):• Retransmit • Slow Start

TCP Reno verbessert die Übertragung von TCP Tahoe, wenn eineinzelnes Paket während einer der Zeitspanne einer Paket-Umlaufzeitverloren geht.


TCP Tahoe und TCP Reno bei Einzelpaketverlusten

Reno

Zeit

cwnd

Zeit

cwnd

Taho


TCP Tahoe


TCP Reno (Jacobson 1990)

Wirkung des Fast retransmission/fast recovery Protokolles


TCP New Reno

bei mehrfachem Paketverlust in einer RTT-Periode gibt es bei Reno ProblemePartielles Bestätigen:

tritt ein, wenn mehrere Pakete verloren gingeneine partielle Bestätigungsnachricht ACK bestätigt einige, aber nicht alle Pakete, die zu Beginn einer Fast Recovery Phase noch zur Bestätigung anstehen und verhindert so den Eintritt in eine Fast Recovery Phase

Sender muß bis zu einer Zeitüberschreitung der Sendeuhr (timeout) warten

New Reno:partielle Bestätigungen verhindern nicht den Eintritt des Senders in die Fast Recovery Phaseeine partielle Bestätigung erzeugt die erneute Übertragung des Segmentes, das auf das bestätigte Segment folgt

New Reno kann mit mehrfachem Paketverlust umgehen, ohne in die Slow-Start Phase einzutreten


TCP SACK (RFC 2018, 1996)

TCP SACK = TCP selective acknowledgment nach Floyd et al., RFC 2018Ursache:

Reno und New Reno wiederholen die Übertragung von höchstens einemPaket pro Umlaufzeit

Selektive Bestätigungen (selective acknowledgments):Der Empfänger kann nicht-konsekutive Datenblöcke bestätigen, z.B. SACK 0-1023, 2047-2050 durch Angabe des linken Randes und des ersten Bytes oberhalb des rechten empfangenen Randes (erwartete Sequenznummer)Mehrere Blöcke können in einem einzigen Segment verschickt werden.

TCP SACK Algorithmus: tritt nach dem Empfang von 3 duplizierten ACKs in die Fast Recovery Phase einSender verfolgt den Verlauf der SACKs und schließt daraus auf (partielle) Paketverluste. als nächstes Segment übertragt der Sender erneut das erste aus der Liste derverloren geglaubten Segmentewird seit Windows 98 unterstützt


Beispiel von TCP SACK (RFC 2018)

•Model:

•Cases:

5000 5500 6000 6500 7000 7500 8000 8500


Beispiel: TCP Verbindung über drahtlose Netzsegmente

Idee:Zerlegung einer TCP Verbindung in zwei gekoppelte Einzel-verbindungen

Basis-station

Luftschnittstelle

Mobiler Rechner

Nachteil: Zerstören der Ende-zu-Ende Logik von TCP-Verbindungenzwischen den Endsystemen


Wirkung der Terminalbewegung auf die TCP-Leistung

Evolution des TCP Sendefensters in einem IEEE802.11b kompatiblen 11 Mbps WLAN mit An/Aus- Verkehrsmuster

TCP Leistung bei Verbindungsüber-gaben :

•varierende SIR erzeugen Fehler

•TCP Sendefenster bricht zusammen

•Durchsatzreduktion

SIR und MS-AP-RTT Korrelation in einem WLAN bei Verbindungsübergabe (handoff)

IP-Verlust und MS-AP-RTT Korrelation in einem WLAN

beim Handoff


TCP-Verkehrsdurchsatzanalyse

typische Transportkapazitäts-(Bandbreiten)-Auslastung einer 3 Megabit pro Sekunde (Mbps)-Leitung und Verschwendung in einem IP-Datennetz durch die Sendewiederholung verlorener TCP-Transportnachrichten

0

0,5

1

1,5

2

2,5

3

0 15000 30000 45000 60000 75000 90000

Time [s]

Ban

dwid

th [M

b/s]

Occupied Band

Retried Band

Bandbreitenverschwendung mit TCP-Sendewiederholung > 10 %


Kapitel 1.5

Das Bandbreite-Länge-Produkt in Kommunikationsnetzen


Evolution existierender Kommunikationsnetze


Paradigmenwechsel in Breitband-Netzen

alte Computer- und KommunikationsnetzeComputer als Endsysteme arbeiten sehr schnell.Das Kommunikationsnetz ist der Engpass.Die Nachrichtenübertragungsverzögerung ist die dominante Zeitkomponente.

HochgeschwindigkeitsnetzeDie Netze sind schnell und leistungsfähig.Die Ausbreitungsverzögerung ist die dominante Zeitkomponente.Rechnersysteme bilden den Engpass des verteilten Systems.



Cb t = L[m]/(2/3 c)[m/s]

in Glasfasern~



c



Beispiel:

US-Transport-Strecke



1. Beispiel: Datenrate: C = 150 MbpsÜbertragungsdauer von b=53 Byte Paketen (sog. ATM-Zellen)

b/C = 53 * 8 / 150 * 106 = 3 * 10{-6} [s]Paket-Umlaufdauer (round trip delay – für Flusssteuerung relevant!)

R = 30 msSpeicherkapazität des Mediums = Bandbreite-Verzögerungsprodukt

N = C * R/b = 30 * 10{-3} / 3 * 10{-6} = 104 Paketeoder 4.24 * 106 Bit

GrundprinzipEin TCP-Sender muss die Transportpipeline in der Größenordnung

des Bandbreite-Verzögerungsproduktes füllen.



SchlussfolgerungNicht die Bandbreite sondern die Latenzzeit des Kanalesdominiert die Zeit zur Auslieferung einer Datei.Es existiert ein Abwägung Latenzzeit vs. Bandbreite:

Übermittlungsverzögerung = Verarbeitungsverzögerung + Übertragungsverzögerung + Ausbreitungsverzögerung

Verarbeitungsverzögerung = Vermittlungsverzögerung

+ Paketwartezeit


Das Bandbreite-Länge-Produkt

0

a = L/(2/3c) * C =

C

a = L/(2/3c) * C

L=Bandbreite-Länge-Produkt = t * C = L/(2/3c) * C

, c = Lichtgeschwindigkeit

t ist dominant.



•Die TCP-Quelle muss diese Transport-Pipeline durch angepasste Senderaten füllen.


Das Bandbreite-Länge-Produkt

HauptproblemeNeue Protokolle zur Fluss- und Überlastkontrolle sind erforderlich.Zu kleine Fenstergrößen bei Fensterflusskontrollverfahren

erzeugen schlechte Kanalauslastung,bei einem Sequenznummernraum von 16 Bit können bei Byteorientierung nur 65536 Byte konsekutiv übertragen werden.Relativ lange Signalumlaufzeiten der Quittungen verringern den Datendurchsatz erheblich.

Handshake-Überlastabwehrverfahren verringern wegen ihrer Verzögerungszeiten den Datendurchsatz ebenfalls.

Multimedia-Kommunikation in Hochgeschwindigkeitsnetzen ... · U. Krieger: KTR-MMK-M SS08 Kap.1 3...

Documents

Transcript of Multimedia-Kommunikation in Hochgeschwindigkeitsnetzen ... · U. Krieger: KTR-MMK-M SS08 Kap.1 3...