Rechnerkommunikation Sommersemester 2014
Rechnerkommunikation Prof. Dr. habil. TH Nürnberg Fakultät Informatik Keßlerplatz 12 90489 Nürnberg Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Autors urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen. Es wird darauf hingewiesen, dass die hier verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen. Alle Angaben und Programme wurden mit größter Sorgfalt kontrolliert. Der Autor kann jedoch nicht für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieser Publikation stehen. 2
Inhalt Kapitel 1: Einleitung... 4 Kapitel 2: Transportprotokolle des Internets... 17 Kapitel 3: Grundlagen der Anwendungskommunikation... 37 Kapitel 4: Entfernte Aufrufe und Webservices... 70 Kapitel 5: Peer-to-Peer-Netzwerke... 99 Kapitel 6: Sicherheit... 114 Kapitel 7: Namen... 147 Kapitel 8: Darstellung von Daten... 176 Kapitel 9: Konsistenz verteilter Daten... 198 Übungsaufgaben... 213 3
Rechnerkommunikation SS 2014 Kapitel 1 Einleitung Übersicht über die Vorlesung Zwei Verlesungen befassen sich mit Rechnernetzen und Kommunikation: Kapitel 1, Folie 2 4
Übersicht über die Vorlesung Kapitel 2: Transportprotokolle des Internets Kapitel 3: Grundlagen der Anwendungskommunikation Kapitel 4: Entfernte Aufrufe und Webservices Kapitel 5: Peer-to-Peer-Netzwerke Kapitel 6: Sicherheit Kapitel 7: Namen Kapitel 8: Darstellung von Daten Kapitel 9: Konsistenz verteilter Daten A B C E D F F E D C B A Kapitel 1, Folie 3 Literatur Peterson L. L.; Davie B. S: Computernetze, dpunkt, 2007 Lienemann G., Larisch D.: TCP/IP - Grundlagen und Praxis, heise, 2011 Tanenbaum A. S., van Steen M.: Verteilte Systeme, Pearson, 2007 Coulouris G.: Distributed Systems: Concepts and Design, Pearson, 2009 Haase O.: Kommunikation in verteilten Anwendungen, Oldenbourg, 2008 Dunkel J., Eberhart A., Fischer S., Kleiner C., Koschel A.: Systemarchitekturen für Verteilte Anwendungen, Hanser, 2008 Roth J.: Mobile Computing, dpunkt, 2005 Roth J.: Prüfungstrainer Rechnernetze, Vieweg+Teubner, 2010 (Lösung der Übungsaufgaben bis Aufgabe 71) Kapitel 1, Folie 4 5
Kapitel 1: Einleitung Ziel: Einleitung und Motivation zu dem Gebiet der Rechnerkommunikation Motivation Themen und Probleme Beispiele Kapitel 1, Folie 5 Themen und Problemstellungen Anwendungsnahe Kommunikation: Wunsch: Komfort bei der Anwendungsentwicklung Heterogenität verschiedener Umgebungen (Prozessor, Betriebssysteme, Endgerätetypen etc.) Verteiltes "Denken" zur Problemlösung erforderlich Unterschiede zu Ein-Rechner-Entwicklung: kein gemeinsamer Speicher, Aufrufe dauern länger Verschiedene Paradigmen: Sockets, entfernte Aufrufe, mobiler Code Verschiedene Architekturen: Client-Server, Peer-to-Peer Kapitel 1, Folie 6 6
Themen und Problemstellungen Sicherheit: Ein wichtiger Aspekt gemessen an der öffentlichen Aufmerksamkeit vielleicht sogar der wichtigste für bestimmte Anwendungsszenarien Verteilte (potenziell offene) Systeme sind Ziel von Sicherheitsangriffen Angriffe: Passives Lesen vertraulicher Daten, Verändern von Daten, Denial-of-Service Sicherheit kann nicht allein technologisch betrachtet werden ("Post-It mit Kennwort am Rechner") Kapitel 1, Folie 7 Themen und Problemstellungen Betreff: Update der Programmierungshilfen [Nachricht ID: 3365585378] Von: kundensupport@sparkasse.de Sender: 0QDHORA@yahoo.com Datum: 04.03.2009 13:43 An: Joerg.Roth@ohm-hochschule.de Sehr geehrter Nutzer der Sparkasse, Unterstützungsdienste der Sparkasse wickeln ein regelmäßiges Update der Programmierungshilfen für eine mehr sichere Kundenbetreuung der Bank ab. Damit wir die Angabensicherheit des Kunden garantieren könnten, bitten wir Sie die Sparkasse Kundenform ausfüllen. Um die Formausfüllung anzufangen, klicken Sie bitte den Link unten: http://www.sparkasse.de/subdir/kundenform.aspx?ms=4901 (Anmerkung: Ziel war http://www.sparkasse.de.strd-id12.eu/subdir/kundenform.aspx?ms=4901) Diese Nachricht ist automatisch erschafft worden. Sie brauchen nicht darauf zu antworten. Kapitel 1, Folie 8 7
Themen und Problemstellungen Weitere Themen: Anwendungen und Menschen benutzen lieber Namen als Adressen Daten müssen für den Transport zwischen Rechnern geeignet dargestellt werden Verteilte Zugriffe auf gemeinsame Daten müssen konsistent erfolgen Wir beginnen mit einigen Beispielen aus der Welt der anwendungsnahen Rechnerkommunikation Kapitel 1, Folie 9 Erhöhung der Rechengeschwindigkeit Kapitel 1, Folie 10 8
Verteiltes Rechnen Kapitel 1, Folie 11 Verteiltes Rechnen Einige Berechnungsaufgaben lassen sich in unabhängige Unteraufgaben zerlegen Aus den einzelnen Resultaten kann eine Gesamtlösung berechnet werden Beispiele: Klimaforschung Klimamodelle sind sehr komplex Riesige Mengen von Einzeldaten Problem kann einfach zerlegt werden (Quelle: Heise Newsticker vom 12.09.2003 ) Kapitel 1, Folie 12 9
Verteiltes Rechnen Seti At Home (Start 1999) Suche nach künstlichen extraterrestrischen Signalen Komplexe Analyse Aufwändige Frequenzanalyse, um natürliche Signale von künstlichen zu unterscheiden Problem leicht zerlegbar (Quelle: http://setiathome.ssl.berkeley.edu, nicht mehr verfügbar) Kapitel 1, Folie 13 Verteiltes Rechnen Kapitel 1, Folie 14 10
HTTP HTTP ein Protokoll mit vielen Einsatzbereichen Ursprünglich dazu gedacht, im World Wide Web Seiten und Dokumente auf Anfrage zu übertragen Mittlerweile: Basis für verteilte Anwendungsentwicklung mit Webservices Browser/Web-Server/HTTP sind die Anwendungsumgebung für viele netzbasierte Anwendungen vom Webshop zum Lexikon viele Entwicklungsrahmenwerke (z.b. JSF, PHP) Kapitel 1, Folie 15 HTTP Beispiel: TicTacToe mit JavaServer Faces Wichtig: Die Spielelogik läuft hier auf dem Server Nur Benutzungsschnittstelle des Spiels läuft im Browser Viele unterschiedliche Aufteilungen der Zuständigkeiten zwischen Client und Server sind denkbar Kapitel 1, Folie 16 11
Web 2.0 Ursprünglich waren die Anbieter von Web-Inhalten Experten: Spezial-Kenntnisse bezüglich Seiten-Formattierung, Zugriffssteuerung, Dateitypen, Dokumentenverwaltung Content Management Systeme (CMS): Organisation und Darstellung von Inhalten auch für nicht-experten Web 2.0: Rollen zwischen Inhalte-Anbieter und Konsument wird nicht mehr klar getrennt: Sozial Networks, Social Media Wikis, Blogs, Foren Tagging alles über HTTP Kapitel 1, Folie 17 Cloud Computing Cloud Computing: Anwendungsdaten werden so abgelegt, dass man mit unterschiedlichen Gerätetypen und über unterschiedliche Netze darauf zugreifen kann Beispiele: Fotos, Audio-Dateien, Kalender Auch möglich: die Anwendungen selbst liegen in der Cloud (z.b. Web-basiert) Vorteil im mobilen Umfeld: Datenübertragung von Endgerät zu Endgerät muss nicht mehr manuell erfolgen Nachteil: private Daten werden weit über das Netzwerk transportiert, die Server-Infrastruktur ist für den Benutzer nicht durchschaubar Kapitel 1, Folie 18 12
Smart Phones Eine neue Anwendungsplattform: Smart Phones Nicht alleine ein neues Endgerät: völlig neue Anwendungszenarien neue Geschäftsmodelle Browser typischweise nicht wichtigste Anwendungsumgebung, statt dessen native Apps Apps für alle Lebenslagen Kapitel 1, Folie 19 Smart Phones Smart Phones sind in der Regel nur vernetzt sinnvoll einsetzbar: Cloud Computing für Kalender, E-Mail, Kontakte Konten werden zentral verwaltet Netzwerk-Dienste Lokationsdienste Such-Assistenten Kartenmaterial, Navigation Kapitel 1, Folie 20 13
Ubiquitous Computing Allgegenwärtige Computer, Ubiquitous Computing (Ubicomp) [Weiser 91]: "The idea of integrating computers seamlessly into the world at large runs counter to a number of present-day trends.»ubiquitous computing«in this context does not just mean computers that can be carried to the beach, jungle or airport. Even the most powerful notebook computer, with access to a worldwide information network, still focuses attention on a single box." Kapitel 1, Folie 21 Ubiquitous Computing Mark Weisers Vision: Drei Phasen der Computer-Benutzung: Mainframes (Vergangenheit) PCs (jetzt) Ubiquitous Computing (2005-2020) Computer beanspruchen nicht mehr die volle Aufmerksamkeit des Benutzers Calm Computing, Invisible Computing, Pervasive Computing, Disappearing Computing Kapitel 1, Folie 22 14
Groupware Ellis C. A.; Gibbs S. J.; Rein G. L. (1991): Computer based systems, which support groups of people engaged in a common task (or goal) and that provide an interface to a common environment. gleicher Ort räumlich getrennt synchron Telekonferenzen gemeinsames Editieren asynchron Zeit- und Aufgabenmanagement E-Mail Bulletinboards Workflow-Management Kapitel 1, Folie 23 Groupware Sitzungsunterstützung Übersichtsfunktionen Telepointer Kapitel 1, Folie 24 15
Groupware Kapitel 1, Folie 25 16
Rechnerkommunikation SS 2014 Kapitel 2 Transportprotokolle des Internets Kapitel 2: Transportprotokolle des Internets Ziel: Möglichkeiten von kommunizierenden Anwendungen auf der Transportschicht des Internets. Transportprotokolle UDP, TCP Fluss- und Überlastkontrolle Aufbau von TCP-Nachrichten TCP-Verbindungsaufbau Kapitel 2, Folie 2 17
Neue Anforderungen Was bisher geschah... Wir können IP-Pakete von einem Host über ein Vermittlungsnetzwerk zu einem weit entfernten anderen Host übertragen, ungeachtet der jeweiligen Schicht-2- Netzwerke zwischen den Hosts. Die Übertragung auf jedem einzelnen Hop ist jeweils durch ein Schicht-2-Protokoll gesichert, deshalb dürften eigentlich keine Pakete verloren gehen. Dennoch: Pakete können durch Router-Überlastung verloren gehen. Die Reihenfolge der Pakete kann sich durch unterschiedliche Übertragungswege verändern. Kapitel 2, Folie 3 Neue Anforderungen Wichtige Anforderungen aus der Sicht einer Anwendung (bzw. eines Anwendungsentwicklers) Garantierte Übertragung von Nachrichten Gleiche Reihenfolge beim Empfänger wie beim Sender Unterstützung beliebig großer Nachrichten Unterstützung mehrerer Anwendungsprozesse Flusskontrolle, d.h. Sender stimmt Datenrate auf Empfänger ab Überlastkontrolle, d.h. Sender stimmt die Datenrate auf das Router-Netzwerk ab Kapitel 2, Folie 4 18
Neue Anforderungen Wie erfüllen die Internet Transportprotokolle diese Anforderungen: Anforderung Garantierte Übertragung Reihenfolge Beliebig große Nachrichten Mehrere Anwendungsprozesse Flusskontrolle Überlastkontrolle UDP Nein Nein Nein Ja Nein Nein TCP Ja Ja Ja Ja Ja Ja Kapitel 2, Folie 5 Anwendungsmultiplexing Unterstützung mehrerer Anwendungsprozesse pro Host: Man erweitert IP-Pakete um die Funktionalität zu demultiplexen, d.h. um verschieden Prozesse auf einem Host zu adressieren. Denkbar: man identifiziert einen Empfängerprozess anhand seiner Prozess-ID, aber nicht beim Sender bekannt ändert sich beim Neustart der Anwendung Statt dessen: man verwendet eine 16-Bit lange Portnummer. Die empfangende Anwendung bindet sich an eine Portnummer und kann so die Nachrichten für diesen Port empfangen. Kapitel 2, Folie 6 19
Ports Problem: wie weiß der Sender, an welchem Port sich eine Anwendung befindet? Well-known-Ports: für wichtige Dienste gibt es bekannte Portnummern, z.b. Port 20,21/tcp 22/tcp 23/tcp Dienst FTP ssh telnet Port 25/tcp 53/tcp/udp 69/udp Dienst SMTP DNS tftp Port 80/tcp 119/tcp 513/udp Dienst HTTP NNTP who Ansonsten verwendet die Anwendung einen freien Port und kodiert diesen fest oder die Anwendungen vereinbaren über einen festen Port, über welchen Port sie weiter arbeiten sollen oder die Anwendung testet einige Ports, bis sie verbunden wird Kapitel 2, Folie 7 Ports Mittlerweile sind Ports bis 50000 von der IANA definiert Kapitel 2, Folie 8 http://www.iana.org/assignments/port-numbers 20
UDP User Datagram Protocol (UDP): Telegramm-orientiert, d.h. Übertragung nur in eine Richtung (eventuelle Rücksendung ist ein eigener Vorgang) keine Zustellungsgarantie keine Quittung der Sender weiß nicht, ob ein Paket angekommen ist UDP ist geeignet für bestimmte Anwendungen: verbindungslos Nachrichten dürfen verloren gehen Z.B. Audio- oder Video-Übertragung, Suchanfragen im lokalen Netz Kapitel 2, Folie 9 TCP TCP (Transmission Control Protocol): Multiplexen verläuft analog zu UDP Zuverlässige, bidirektionale Byte-Streams Kumulative Quittungen, Sliding Windows Pakete in falscher Reihenfolge werden gepuffert, bis die Sendereihefolge hergestellt werden kann. Fluss- und Überlastkontrolle Empfänger sendet auf dem Rückkanal die maximale Anzahl der Bytes bis zum Pufferüberlauf. Sender tastet sich an die Überlastsituation (Pufferüberlauf der Router) heran. Kapitel 2, Folie 10 21
TCP Kapitel 2, Folie 11 TCP Wie werden TCP-Segmente aus dem Byte-Strom gebildet? Es wurden genug Bytes gepuffert, um ein TCP-Segment ohne IP-Fragmentierung zu versenden. Die Anwendung wünscht explizit, die bisher gepufferten Bytes zu versenden (flush). Periodischer Timer TCP verwendet das Sliding-Window-Verfahren bekannt aus der Schicht-2 zur Sicherung der Punkt-zu- Punkt-Übertragung Kapitel 2, Folie 12 22
TCP Unterschiede von Sliding Window auf Schichten 2 und 4: Schicht 4 erfordert Verbindungsauf- und -abbau, während bei der Schicht-2-Verbindung zwischen zwei Computern die Verbindung implizit definiert ist. Die Round-Trip-Zeit schwankt bei Schicht 4 sehr stark, während sie auf Schicht 2 im Wesentlichen konstant ist. Auf Schicht 4 können Pakete umgeordnet werden bei Schicht-2-Verbindungen ist das (meistens) nicht möglich. Ressourcen, insb. Puffergrößen, sind variabel auf Schicht 4 und können sich zur Laufzeit ändern. Überlastungen auf Schicht 4 betreffen Router auf Schicht 2 betrifft die Überlastung lediglich eine Direktverbindung, wird somit auf Senderseite erkannt. Kapitel 2, Folie 13 TCP Konsequenz: TCP muss viel über die Verbindung zur Laufzeit lernen, während auf Schicht-2 die Optimierungen a priori vorgenommen werden können. Realisierung des TCP-Sliding-Window-Verfahrens: TCP-Sender und -Empfänger verwenden Buffer. Die sendende Anwendung schreibt i.d.r. unblockierend in den Sendepuffer. Analog kann die empfangende Anwendung unblockierend aus dem Empfangspuffer lesen, wenn Daten vorliegen. Kapitel 2, Folie 14 23
TCP Sliding Window MaxSendBuffer gepufferte Bytes Sendender Anwendungsprozess gesendete, unbestätigte Bytes gesendete, bestätigte Bytes gesendete, unbestätigte Bytes LastByteAcked LastByteSent LastByteWritten von der Anwendung geschriebene, ungesendete Bytes TCP-Verbindung MaxRcvBuffer gepufferte Bytes von der Anwendung gelesene Bytes empfange Bytes Empfangender Anwendungsprozess LastByteRead NextByteExpected LastByteRcvd Kapitel 2, Folie 15 TCP Flusskontrolle Der Empfänger sendet bei jedem empfangenen TCP- Segment eine Antwort mit Acknowledge: bis zu welchem Byte wurde eine ununterbrochene Folge empfangen (kumulatives ACK) AdvertisedWindow: wie viele Bytes kann der Empfänger noch empfangen, bevor der Puffer überläuft TCP Segment Acknowlege=x AdvertisedWindow=y Kapitel 2, Folie 16 24
TCP Flusskontrolle Der Empfänger berechnet nach jedem Empfang AdvertisedWindow = MaxRcvBuffer (LastByteRcvd LastByteRead) MaxRcvBuffer AdvertisedWindows gepufferte Bytes LastByteRead NextByteExpected LastByteRcvd So viele Bytes kann der Empfänger noch puffern, wenn die Anwendung nicht weitere Bytes konsumiert. Kapitel 2, Folie 17 TCP Flusskontrolle Der Sender darf nur soviel senden, damit gilt LastByteSent LastByteAcked AdvertisedWindow anders ausgedrückt: er kann noch EffectiveWindow=AdvertisedWindow (LastByteSent LastByteAcked) senden EffectiveWindow AdvertisedWindow gesendet, unbestätigt Kapitel 2, Folie 18 LastByteAcked LastByteSent 25
TCP Flusskontrolle EffectiveWindow kann auch 0 sein Der Sender darf erstmal nichts senden. Schreibt die sendende Anwendung ständig weiter in den Puffer, wird dieser irgendwann voll. Ist der Sendepuffer voll, wird die Anwendung beim nächsten Schreiben solange blockiert, bis wieder Pufferplatz frei ist. Problem: neue AdvertisedWindow-Werte kommen nur vom Empfänger als Antwort auf ein TCP-Segment Der Sender versucht periodisch, ein einziges Byte zu senden (auch wenn er eigentlich nicht dürfte), bis EffectiveWindow>0 Grundregel: smart sender/dump receiver Kapitel 2, Folie 19 TCP Neuübertragung Geht ein TCP-Segment verloren, sollte es möglichst schnell erneut gesendet werden. Grundlage zur Berechnung des Timeouts: die Round- Trip-Zeit (RTT) zwischen Sender und Empfänger. Hierzu wird die Zeit zwischen Senden eines TCP-Segments und Eintreffen des betreffenden ACKs gemessen. Erster Ansatz: man berechnet einen gleitenden Durchschnitt vergangener RTT-Zeiten RTT = RTT. a + RTT last. (1 a) (a=0.8...0.9) und setzt den Timeout auf 2. RTT Problem: sendet man ein TCP-Segment zweimal, kann man das ACK nicht mehr der Sendung zuordnen in solchem Fall setzt man die Messung aus Kapitel 2, Folie 20 26
TCP Neuübertragung Weiteres Problem: die 2. RTT sind häufig zu großzügig hat man eine weitgehend konstante RTT, so wird in der Regel zu lange gewartet bis ein Segment neu übertragen wird. Lösung von Jacobson/Karels RTT wird wie bisher berechnet Zusätzlich wird der gleitende Durchschnitt der Abweichung von RTT und letzter Messung berechnet RTT = RTT. a + RTT. last (1 a) Deviation = Deviation. a + RTT last RTT. (1 a) Timeout = RTT + 4. Deviation (a=7/8) (a=7/8) Kapitel 2, Folie 21 TCP Überlastkontrolle Bisher wurde nur die Flusskontrolle betrachtet ein Empfänger kann die Datenrate beim Sender so drosseln, dass der Empfangspuffer nie überläuft. Notwendig ist jedoch auch eine Überlastkontrolle (Congestion Control): diese stellt sicher, dass die Übertragungswege, insb. die Router nicht überlastet werden. Problem: im Gegensatz zum Empfänger geben die Router eine drohende Überlastung nicht an. Der Sender passt sich dynamisch an eine Überlastsituation an und berechnet ständig einen Wert CongestionWindow Kapitel 2, Folie 22 27
TCP Überlastkontrolle Anpassung der Formel für das EffectiveWindow (Anzahl Bytes, die noch unbestätigt versendet werden dürfen). MaxWindow = min(congestionwindow, AdvertisedWindow) EffectiveWindow = MaxWindow (LastByteSend LastByteAcked) Der Wert CongestionWindow (Überlastfenster) gibt an, wie viele Bytes unbestätigt versendet werden dürfen, bis eine Überlastung droht. Berechnung von CongestionWindow über Additive Increase/Multiplicative Decrease in den folgenden Ausführen nehmen wir vereinfachend die Anzahl der Pakete, statt die Anzahl der Bytes Kapitel 2, Folie 23 TCP Überlastkontrolle Start: CongestionWindow = 1 Wenn alle Pakete im CongestionWindow positiv bestätigt wurden: CongestionWindow = CongestionWindow + 1 (Additive Increase) Wenn ein Paket im CongestionWindow verloren gegangen ist (erkannt durch Timeout): CongestionWindow = CongestionWindow / 2 (Multiplicative Decrease) Kapitel 2, Folie 24 28
TCP Überlastkontrolle Sender Additive Increase Empfänger Multiplicative Decrease Sender Empfänger Paket Bestätigung Kapitel 2, Folie 25 TCP Überlastkontrolle Der Sender tastet sich langsam an die Überlastgrenze heran und reduziert dann drastisch das Überlastfenster bei Überlastung: typische TCP-Verbindung Überlastfenster Zeit Warum die drastische Senkung? Überlast ist viel schlimmer als ein zu kleines EffectiveWindow. Würde man die Überlast durch Additive Decrease verringern, würde die Überlastsituation kaum beseitigt werden. Kapitel 2, Folie 26 29
TCP Überlastkontrolle, Slow Start Am Anfang einer Sitzung ist das Additive Increase zu langsam. Slow Start erhöht das Überlastfenster multiplikativ bei Erfolg wird es verdoppelt. Sender Slow Start wird angewendet direkt nach dem Sitzungsaufbau jedes Mal, nachdem eine Sitzung "abgestorben" ist, d.h. die Datenrate auf 0 gesunken ist Warum "slow"? Historisch: Vorher verwendete man nur das AdvertisedWindow des Empfängers Slow Start ist da viel langsamer Paket Bestätigung Empfänger Kapitel 2, Folie 27 TCP Überlastkontrolle Fast Retransmission Der Sender kann durch Timeout feststellen, dass ein Segment nicht zugestellt wurde. Andere Möglichkeit: Auswerten der kumulativen ACKs zu nachfolgenden Segmenten. Beispiel: wird 1, 2, 3, 4, 5 gesendet und kommt ACK(1), ACK(2), ACK(2), ACK(2) zurück, so ging wahrscheinlich Segment 3 verloren die ACK(2) heißen hier Duplikat-ACKs TCP Fast Retransmission wartet drei Duplikat-ACKs ab, bis es das Segment erneut sendet Warum nicht nur zwei Duplikat-ACKs? Das Segment könnte ja auf einem "langsamen Weg" unterwegs sein Kapitel 2, Folie 28 30
Aufbau von TCP-Nachrichten Kapitel 2, Folie 29 Aufbau von TCP-Nachrichten SrcPort, DstPort: Felder für das Multiplexen. Zusammen mit den IP-Adressen des IP-Pakets (SourceAddr, DestinationAddr) wird damit eindeutig eine Verbindung identifiziert. SequenceNumber: Byte-Nummer der Nutzdatenbytes im gesamten Datenstrom (mod 2 32 ) Acknowledgement, AdvertisedWindow: Felder zur Flusskontrolle in die Rückrichtung HdrLen: Länge des TCP-Headers in 32-Bit-Blöcken Checksum: Prüfsumme von Header und Daten Kapitel 2, Folie 30 31
Flags: Aufbau von TCP-Nachrichten SYN: Aufbau einer Verbindung FIN: Normales Beenden einer Verbindung RESET: Aktives Beenden der Verbindung wegen Problemen PUSH: Daten sollen sofort unter Umgehung des Empfangspuffers an die Anwendung gesendet werden URG: Selten verwendet: die Daten, auf die UrgPtr zeigt, müssen sofort von der Anwendung gelesen werden (analog zu einem Interrupt) ACK: Das Feld Acknowledgement wird verwendet UrgPtr: Wenn URG in Flags gesetzt: dringende Daten Optionen: Liste variabler Länge Kapitel 2, Folie 31 Aufbau von TCP-Nachrichten Optionen TCP-Optionen: HdrLen ist meistens 5 (entspricht 20 Bytes, keine Optionen). Wenn HdrLen>5 gibt es Optionen. Der Maximalwert von HdrLen (4 Bits) ist 15. Damit können maximal (15-5) 4 Bytes=40 Bytes Optionen vorkommen. Restriktionen: alle Optionen zusammen müssen ein Vielfaches von 4 Bytes (32 Bits) lang sein (ggfs. mit 0 aufgefüllt) jede Option muss ein Vielfaches von 1 Byte (8 Bits) lang sein Format: KindNr (1 Byte), Länge (1 Byte), Inhalt Kapitel 2, Folie 32 32
Aufbau von TCP-Nachrichten Optionen Beispiel TCP-Selective ACKs Während des Verbindungsaufbaus erlaubt ein Partner dem anderen das Quittieren mit Selective Acks (KindNr=4). Selective Acks (KindNr=5) KindNr 0 4 5 Bedeutung Keine weitere Optionen mehr Erlaube Selective Acks Selective Ack Blöcke von bis Maximale Anzahl n=4 (ergibt sich aus der Maximalgröße von 40 Bytes für Optionen) 0 31 Length KindNr=5 SequenceNumberFrom1 (n 8+2) SequenceNumberFrom1 (Fortsetzung) SequenceNumberTo1 (Fortsetzung)... SequenceNumberTo1... SequenceNumberFromn SequenceNumberFromn (Fortsetzung) SequenceNumberTon SequenceNumberTon (Fortsetzung) Kapitel 2, Folie 33 TCP-Pseudo-Header Prüfsumme der TCP-Nachricht: Aus Sicht der Anwendung bestehen Endpunkte neben den Ports auch aus den IP-Teilnehmern, repräsentiert durch deren IP-Adressen IP-Adressen sind Bestandteil der IP-Header, also "außerhalb" der TCP-Nachricht Änderungen der IP-Adressen beim Transport wären ein Problem für die TCP-Verbindung Lösung: die TCP-Checksumme berücksichtigt auch einige Felder des IP-Pakets Eine Verletzung der Ebenen-Trennung Die Felder aus dem IP-Paket werden TCP-Pseudo- Header genannt Kapitel 2, Folie 34 33
TCP-Pseudo-Header 0 4 8 16 19 31 Version HLen TOS Length Ident Flags Offset TTL Protocol Checksum SourceAddr DestinationAddr TCP-Pseudo-Header SourceAddr DestinationAddr Optionen (variabel) Füllbits 00000000 Protocol (=6) TCP-Length (Header & Daten des TCP- Segments, kein Feld, sondern berechnet) IP 0 4 10 16 31 SrcPort DstPort TCP SequenceNumber Acknowledgement HdrLen 0 Flags AdvertisedWindow Checksum UrgPtr Optionen (variabel) Prüfsumme von - TCP-Pseudo-Header - TCP-Header - TCP-Daten Daten Kapitel 2, Folie 35 TCP-Verbindungsaufbau Ziel des Verbindungsaufbaus: Beide Seiten sollen sich einige darüber sein, dass eine Verbindung besteht. Vereinbaren der Sequenznummern der Nachrichten: Das Sliding-Window-Verfahren verlangt, dass die Reihenfolge der Nachrichten und die Vollständigkeit über Sequenznummern geregelt wird. Diese Sequenznummern sind fortlaufend, die Startnummer ist aber beliebig sie sollte möglichst zufällig sein. Da Sequenznummern mod 2 32 gerechnet werden, kann jede Startnummer aus 0 2 32-1 ausgewählt werden. Während des Verbindungsaufbaus teilt jeder Partner die Startnummer mit. Kapitel 2, Folie 36 34
Three-Way-Handshake: TCP-Verbindungsaufbau Kapitel 2, Folie 37 Ende der Verbindung Das Ende der Verbindung kann von jedem der beiden Partner separat angekündigt werden. Wenn ein Partner eine Verbindung beendet, kann der andere weiter senden. Man spricht dann von einer halboffenen Verbindung. Möglichkeiten der Beendigung: Four-Way-Handshake: jeder beendet die Verbindung separat (dazwischen: halboffene Verbindung) Three-Way-Hanshake: der zweite Partner stimmt einer Beendigung zu, FIN und ACK werden in einer Nachricht versendet. Kapitel 2, Folie 38 35
Ende der Verbindung Four- und Three-Way-Handshake: Timeout Timeout Kapitel 2, Folie 39 36
Rechnerkommunikation SS 2014 Kapitel 3 Grundlagen der Anwendungskommunikation Kapitel 3: Grundlagen der Anwendungskommunikation Ziel: Möglichkeiten von kommunizierenden Anwendungen auf der Transportschicht des Internets. Abstraktionen zur Anwendungskommunikation Sockets Beispiele von Anwendungsprotokollen SMTP, HTTP Protokolle auf der Basis von HTTP Kapitel 3, Folie 2 37
Abstraktionen Entwickler müssen auf Kommunikationseinrichtungen zugreifen können Application Programming Interface (API) Z.B. C: Header-Dateien und C-Libraries Klassenbibliothek Z.B. Java-Packages Abstraktionen: Anwendungsentwickler können nur lokale Entitäten (Variablen, Instanzen) modifizieren, bzw. lokale Prozeduren oder Methoden aufrufen Zugriff auf Kommunikationseinrichtungen über "Abstraktionen" Kapitel 3, Folie 3 Beispiele für Abstraktionen: Datagramme: Abstraktionen Unidirektionale Paketversendung, Keine Garantien für Ankunft, Sender kann nicht ermitteln, ob Daten angekommen sind Prominentester Vertreter: UDP Operationen: send(bytes), receive(bytes) Streams: Bidirektionale Datenströme, hohe Verlässlichkeit Prominentester Vertreter: TCP Operationen: write(bytes), read(bytes) Kapitel 3, Folie 4 38
Entfernter Prozeduraufruf: Abstraktionen Aus der Sicht des Anwendungsentwicklers wird eine lokale Prozedur aufgerufen Der Aufruf wird jedoch "verpackt" und eine entsprechende Prozedur auf einem anderen Rechner aufgerufen Der Aufrufer wird solange blockiert, bis der Rückgabewert zurücktransportiert wurde Kommunikationsaspekte werden weitgehend vom Aufrufer fern gehalten Operationen: resultat=procedureaufruf(parameterliste) Kapitel 3, Folie 5 Abstraktionen Entfernte Objekte: Die objektorientierte Variante vom entfernten Prozeduraufruf Die Anwendung beschafft sich eine Objektreferenz auf das entfernte Objekt Aus der Sicht der Anwendung, ein lokaler Aufruf Operationen: resultat=objekt.methode(parameterliste) Variante: Multicast-Aufruf ein Aufruf mehrere Ausführungen Kapitel 3, Folie 6 39
Mobiler Code, Agenten: Abstraktionen Die "Aufgabe" wird als ausführbarer Code formuliert, der zum Zielsystem übertragen wird Vorteil: das Zielsystem muss nicht für die spezielle Aufgabe vorbereitet werden, sondern muss lediglich eine allgemeine Ausführungsplattform bereitstellen Nachteil Sicherheitsproblematik: - Mobiler Code kann Ressourcen des Zielsystems beanspruchen (Speicherplatz, CPU-Zyklen) - Schlimmer: der mobile Code kann das Zielsystem infiltrieren (Viren) - Lösung: Sandbox (z.b. bei Web-Browsern) Kapitel 3, Folie 7 Beispiele Abstraktion Datagramme Streams Entfernter Prozeduraufruf Entfernter Objektaufruf Mobiler Code Programmierung klassisch objektorientiert Sockets SUNs RPC CORBA Sockets, Pipes CORBA, Java RMI Postscript JavaScript, Java- Applets, Flash, mobile Agenten leider auch: Viren - Kapitel 3, Folie 8 40
Sockets Für viele Anwendungen reicht ein Zugriff auf Layer-4- Mechanismen zur Kommunikation aus. Für die Abstraktionen Streams und Datagramme: Das Betriebssystem verwaltet so genannte Sockets um Endpunkte einer UDP- oder TCP-Kommunikation im Speicher einer Anwendung darstellen zu können Rollen: initiierender (typischerweise "Client") und reagierender Kommunikationspartner (typischerweise "Server") Varianten: UDP-Socket TCP-Client und -Server-Socket Multicast-Sockets (für Multicast IP) Kapitel 3, Folie 9 Sockets Sockets abstrahieren von der darunter liegenden Kommunikationsschicht. Einmal eingerichtet, verwendet man dieselben Operationen für z.b. TCP/IP, IrDA (Infrarot), oder Bluetooth (Funk) Weit verbreitet: BSD-Sockets (Berkley Software Distribution) Eng verknüpft mit der Programmiersprache C Entsprechende Funktionen werden unter Windows als Winsock-API angeboten Kapitel 3, Folie 10 41
BSD-Socket BSD-Socket-Aufrufe: s=socket(protfamiliy, type, protocol); Einrichten eines Sockets protfamily: Protokolldomäne: #define AF_UNIX 1 /* Unix domain sockets */ #define AF_INET 2 /* Internet IP Protocol */ #define AF_IPX 4 /* Novell IPX */ #define AF_APPLETALK 5 /* AppleTalk DDP */ #define AF_INET6 10 /* IP version 6 */ #define AF_IRDA 23 /* IRDA sockets */ #define AF_BLUETOOTH 31 /* Bluetooth sockets */ type: Stream (SOCK_STREAM) oder Datagramm (SOCK_DGRAM) protocol: zusätzliche Unterscheidung zu type Kapitel 3, Folie 11 close(s); BSD-Socket Freigeben der Socket-Struktur beim Betriebssystem bind(s, localaddr, addrlen); Nur für den reagierenden Teilnehmer: Binden des Sockets an eine bestimmte Portnummer listen(s, queuesize); Nur für den reagierenden Teilnehmer: Konfigurieren des Sockets als reagierender Socket queuesize: wie viele eingehende Verbindungen werden gepuffert Kapitel 3, Folie 12 42
BSD-Socket s2=accept(s, client_addr, client_addrlen); Nur für den reagierenden Teilnehmer: warten auf eingehende Verbindungen Blockiert solange, bis ein initiierender Rechner ein connect auf den entsprechenden Port durchgeführt hat client_addr: Angaben über den initiierenden Rechner s2: Socket-Descriptor für die weitere Kommunikation mit dem reagierenden Rechner Während man über s2 kommuniziert, kann die Anwendung schon wieder ein neues accept auf s durchführen eine Anwendung kann so mehrere eingehende Verbindung an demselben Port behandeln (notwendig z.b. bei Web- Servern) Kapitel 3, Folie 13 BSD-Socket connect(s, server_addr, server_addrlen); Nur für den initiierenden Teilnehmer: Aufbau einer Verbindung zum reagierenden Rechner server_addr: Adresse und Port des Ziels write(s, buf, length, flags); Beide Teilnehmer: Senden von Bytes read(s, buf, length, flags); Beide Teilnehmer: Empfangen von Bytes Kapitel 3, Folie 14 43