8.Vorlesung Netzwerke

Transkript

1 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS1112 1/56 8.Vorlesung Netzwerke Dr. Christian Baun Hochschule Darmstadt Fachbereich Informatik ,

2 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS1112 2/56 Wiederholung vom letzten Mal Transportschicht Ports und Portnummern, Sockets User Datagram Protocol (UDP) Aufbau von UDP-Datagrammen Verbindungslose Kommunikation mit Sockets Transmission Control Protocol (TCP) Aufbau von TCP-Paketen Verbindungsorientierte Kommunikation mit Sockets TCP-Verbindungsaufbau Flusskontrolle bei TCP Verhalten von TCP beim Verlust von Paketen Denial of Service-Attacken via SYN-Flood

3 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS1112 3/56 Heute Sitzungsschicht Darstellungsschicht Anwendungsschicht Anwendungsprotokolle Namensauflösung (DNS) Automatische Vergabe von Adressen (DHCP) Zeitsynchronisierung (NTP) Fernsteuerung von Computern (Telnet, SSH) Übertragung von Daten (HTTP) s austauschen (SMTP) s herunterladen (POP3) Dateien hochladen und herunterladen (FTP)

4 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS1112 4/56 Sitzungsschicht Verantwortlich für Aufbau, Überwachung und Beenden einer Sitzung Eine Sitzung ist die Grundlage für eine virtuelle Verbindung zwischen 2 Anwendungen auf physisch unabhängigen Rechnern Funktionen zur Dialogkontrolle (welcher Teilnehmer gerade spricht) Sorgt für Verbindungsaufbau und Verbindungsabbau Sorgt für die Darstellung der Daten in einer für die darüberliegende Schicht unabhängigen Form Funktionen zur Synchronisierung Kontrollpunkte können in längeren Übertragungen eingebaut werden Kommt es zum Verbindungsabbruch, kann zum nächsten Kontrollpunkt zurückgekehrt werden und die Übertragung muss nicht von vorne beginnen Wird in der Praxis kaum benutzt Beispiel für ein Protokoll in dieser Schicht: Remote Procedure Calls (RPC) als Technik zur Interprozesskommunikation

5 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS1112 5/56 Darstellungsschicht Enthält Regeln zur Formatierung (Präsentation) der Nachrichten Der Sender kann den Empfänger informieren, dass eine Nachricht in einem bestimmten Format vorliegt Datensätze können hier mit Feldern (z.b. Name, Matrikelnummer... ) definiert werden Art und Länge des Datentyps kann definiert werden Komprimierung und Verschlüsselung können hier eine Rolle spielen Wird in der Praxis kaum benutzt Beispiele für Protokolle in dieser Schicht: T.73 und EHKP-6 für Bildschirmtext Situation heute Die Funktionalitäten, die für die Sitzungsschicht und Darstellungsschicht vorgesehen waren, sind heute fast immer Teil der Protokolle und Dienste in der Anwendungsschicht

6 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS1112 6/56 Anwendungsschicht Enthält Anwendungsprotokolle und darauf aufbauende Dienste u.a. zur Datenübertragung, Synchronisierung und Fernsteuerung von Rechnern und Namensauflösung Geräte: keine Protokollet: DNS, NTP, SSH, HTTP, FTP...

7 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS1112 7/56 Domain Name System (DNS) Das DNS ist ein Protokoll und Dienst zur Namensauflösung Führt die Beantwortung von Anfragen zur Namensauflösung aus Analogie zur Telefonauskunft Person/Familie/Firma = Telefonnummer Rechnername/Website = IP-Adresse Entwicklung 1983 von Paul Mockapetris Ziel: Ablösung der lokalen Namenstabellen in der Datei hosts.txt, die bis dahin für die Verwaltung der Namen/Adressen-Zuordnungen zuständig waren Diese waren der zunehmenden Zahl von Neueinträgen nicht mehr gewachsen Basiert auf einem hierarchischen Namensraum, die Information mit den Zuordnungen sind in separate Teile gegliedert und im gesamten Internet auf Name-Servern verteilt die über das Netzwerk abgefragt werden

8 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS1112 8/56 Domain-Namensraum Der Domain-Namensraum hat eine baumförmige Struktur Die Blätter und Knoten nennt man Labels Ein Unterbaum wird Domäne genannt Ein kompletter Domainname besteht aus der Verkettung aller Labels eines Pfades Label sind alphanumerische Zeichenketten Als einziges Sonderzeichen ist der Bindestrich erlaubt Labels sind mindestens 1 Zeichen und maximal 63 Zeichen lang Labels müssen mit einem Buchstaben beginnen dürfen nicht mit einem Bindestrich enden Die Labels werden durch Punkte voneinander getrennt Domainnamen dürfen inklusive aller Punkte max. 255 Zeichen lang sein Domainnamen werden immer mit einem Punkt abgeschlossen Wird meist weggelassen, gehört rein formal aber zu einem vollständigen Domainnamen Fully Qualified Domain-Name (FQDN) dazu Ein vollständiger Domainname ist z.b.

9 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS1112 9/56 Domain-Namensraum Domainnamen werden von rechts nach links delegiert und aufgelöst Je weiter rechts ein Label steht, umso höher steht es im Baum Der Punkt am rechten Ende eines Domainnamens trennt das Label für die erste Hierarchieebene von der Wurzel Die erste Ebene nennt man Top-Level-Domain (TLD) Die DNS-Objekte einer Domäne (z.b. die Rechnernamen) werden als Satz von Resource Records (RR) in einer Zonendatei gehalten, die auf einem oder mehreren Nameservern vorhanden ist Die Zonendatei nennt man häufig einfach Zone

10 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Root-Nameserver (1/3) Die 13 Root-Nameserver (A bis M) publizieren die Root-Zone des DNS Die Root-Zone enthält ca Einträge und ist die Wurzel des DNS Enthält die Namen und IPs der für die TLDs zuständigen Nameserver Einige Root-Server bestehen jedoch nicht aus einem, sondern mehreren Rechnern, die zu einem logischen Server zusammengeschlossen sind Diese Rechner befinden sich an verschiedenen Standorten weltweit und sind per Anycast über dieselbe IP-Adresse erreichbar Die DNS-Namen haben die Form buchstabe.root-servers.net Alter Name IPv4 IPv6 Betreiber Ort A ns.internic.net :503:ba3e::2:30 VeriSign verteilt (Anycast) B ns1.isi.edu USC-ISI USA C c.psi.net Cogent Communications verteilt (Anycast) D terp.umd.edu :500:2d::d University of Maryland USA E ns.nasa.gov NASA USA F ns.isc.org :500:2f::f ISC verteilt (Anycast) G ns.nic.ddn.mil U.S. DoD NIC verteilt (Anycast) H aos.arl.army.mil :500:1::803f:235 U.S. Army Research Lab USA I nic.nordu.net :7FE::53 Autonomica verteilt (Anycast) J :503:c27::2:30 VeriSign verteilt (Anycast) K :7fd::1 RIPE NCC verteilt (Anycast) L :500:3::42 ICANN verteilt (Anycast) M :dc3::35 WIDE Project verteilt (Anycast)

11 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Root-Nameserver (2/3) Bildquelle: Wikipedia

12 Root-Nameserver (3/3) Bevor Anycast eingesetzt wurde, lagen 10 Root-Nameserver in den USA Das wurde kritisiert, da diese geographische Zentrierung dem Dezentralisierungsgedanken des Internets entgegenläuft Bildquelle: Wikipedia Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56

13 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Aufbau der DNS-Datenbank und Ressourceneinträge DNS ist eine Art verteilte Datenbank mit baumförmiger Struktur Beim Internet-DNS liegen die Daten auf einer Vielzahl weltweit verteilter Server, die untereinander über Verweise (Delegierungen) verknüpft sind In jedem Nameserver existieren eine oder mehrere Zonendateien Die Dateien enthalten Listen von Resource Records (RR) Jeder Ressourceneintrag ist ein Name/Wert-Binding Jeder Ressourceneintrag besteht aus 5 Elementen <Name, Wert, Typ, Klasse, TTL> Die Tabelle enthält einige Typen von Ressourceneinträgen Typ SOA A AAAA NS CNAME MX PTR Beschreibung Enthält Angaben zur Verwaltung der Zone wie den Namen und die -Adresse des Administrators Enthält die IPv4-Adresse eines Hosts Enthält die IPv6-Adresse eines Hosts Definiert, welcher Nameserver für die Zone zuständig ist oder verknüpft Zonen zu einem Zonen-Baum (Delegation) Liefert einen Alias-Domain-Namen für einen bestimmten Host Weist einem Namen einen SMTP-Mailserver zu. Alle anderen Dienste nutzen CNAME, A und AAAA Resource Records für die Namensauflösung Weist einer IP-Adresse einen oder mehrere Hostname(s) zu. Gegenstück zur üblichen Zuordnung einer oder mehrerer IPs zu einem Hostnamen per A oder AAAA Resource Record

14 Beispiele von Ressourceneinträgen (Quelle: Wikipedia) Der NS Resource Record (RR) ist in der Zonendatei der Domain org. definiert wikipedia IN NS ns0.wikimedia.org. Bedeutung: Die Zonendatei der Domain wikipedia.org. liegt auf dem Server ns0.wikimedia.org. IN bedeutet, das der Eintrag die Klasse Internet besitzt ist die Time To Live (TTL) in Sekunden Legt fest, wie lange die Information in einem Cache zwischengespeichert werden kann, bevor sie neu erfragt werden sollte Folgender CNAME RR in der Zonendatei der Domain wikipedia.org. definiert, dass der Name de.wikipedia.org. auf den Namen rr.wikimedia.org. verweist de 3600 IN CNAME rr.wikimedia.org. Folgende RRs in der Zonendatei der Domain wikimedia.org. definieren, dass der Name rr.wikimedia.org. auf den Namen rr.esams.wikimedia.org. verweist und diesem die IPv4-Adresse zugewiesen ist rr 600 IN CNAME rr.esams rr.esams 3600 IN A Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56

15 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Auflösung einer DNS-Anfrage (Quelle: Wikipedia) 1/2 Szenario einer Namensauflösung des Namens de.wikipedia.org 1 Rechner X sucht in seiner lokalen hosts-datei, ob die IP-Adresse für de.wikipedia.org hinterlegt ist Falls nicht, fragt er beim DNS-Server nach, der entweder fest eingetragen ist oder per DHCP automatisch zugewiesen wurde 2 Hat der DNS-Server von Rechner X eine IP-Adresse für den angefragten Namen zwischengespeichert, sendet sie die IP-Adresse an den anfragenden Rechner Andernfalls fragt er einen der 13 Root-Nameserver nach de.wikipedia.org. 3 Da die Auflösung des Namens in der Zone org. weitergeht, sendet der Root-Nameserver die Namen und IP-Adressen der org.-nameserver (NS Resource Records und deren AAAA bzw. A RR) zum DNS-Server von Rechner X

16 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Auflösung einer DNS-Anfrage (Quelle: Wikipedia) 2/2 4 Der DNS-Server von Rechner X fragt bei einem der Nameserver für org.-domains nach de.wikipedia.org. 5 Der Nameserver für org.-domains sendet dem DNS-Server von Rechner X die Namen der Nameserver (und deren IPs, sofern sie zur selben TLD gehören) für die Zone wikipedia.org. 6 Der DNS-Server von Rechner X fragt einen Nameserver der Zone wikipedia.org. wie die IP des Namens de.wikipedia.org. ist 7 Der DNS-Server von Rechner X sendet die IP von de.wikipedia.org. an Rechner X

17 Auflösung einer DNS-Anfrage (schönes Beispiel) Bildquelle: Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56

18 Beispiel einer Namensauflösung (1/5) Im folgenden Beispiel wird der Namen mit dem Kommandozeilenwerkzeug dig aufgelöst dig +trace +additional -t A +trace = Die einzelnen Antworten auf dem Pfad durch die Nameserver-Hierarchie ausgeben +additional = Zeigen, dass die Nameserver für Delegierungen nicht nur NS Resource Records verwalten, sondern teilweise auch deren IP-Adressen in Form von A oder AAAA RRs kennen und mit ausliefern -t A = A Resource Record (die IPv4-Adresse) anfragen Auf dem Weg zur IP müssen nacheinander 4 Nameserver befragt werden Auf der nächsten Folie ist in der letzten Zeile die IP des Nameservers des abfragenden Rechners, welcher auf die Root-Nameserver verweist, die die TLD-Zone verwalten Die IP-Adressen der Root-Nameserver ändern sich sehr selten und müssen allen Nameservern bekannt sein, sofern sie das Internet betreffende Anfragen beantworten Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56

19 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Beispiel einer Namensauflösung (2/5) $ dig + trace + additional -t A www. fbi.h-da.de. ; <<>> DiG P2 <<>> + trace + additional -t A ;; global options : + cmd IN NS m.root - servers.net IN NS h.root - servers.net IN NS b.root - servers.net IN NS i.root - servers.net IN NS k.root - servers.net IN NS a.root - servers.net IN NS f.root - servers.net IN NS d.root - servers.net IN NS l.root - servers.net IN NS c.root - servers.net IN NS g.root - servers.net IN NS j.root - servers.net IN NS e.root - servers.net. e.root - servers.net IN A j.root - servers.net IN A i.root - servers.net IN A f.root - servers.net IN A h.root - servers.net IN A d.root - servers.net IN A l.root - servers.net IN A g.root - servers.net IN A b.root - servers.net IN A m.root - servers.net IN A c.root - servers.net IN A a.root - servers.net IN A k.root - servers.net IN A ;; Received 449 bytes from # 53( ) in 45 ms

20 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Beispiel einer Namensauflösung (3/5) de IN NS a. nic.de. de IN NS f. nic.de. de IN NS z. nic.de. de IN NS s.de.net. de IN NS l.de.net. a. nic.de IN A a. nic.de IN AAAA 2001:678:2::53 f. nic.de IN A f. nic.de IN AAAA 2a02 :568:0:2::53 l.de.net IN A l.de.net IN AAAA 2001:668:1 f :11::105 s.de.net IN A z. nic.de IN A ;; Received 287 bytes from #53(i.root - servers.net ) in 45 ms Aus den 13 Root-Nameservern wurde zufällig i.root-servers.net ausgewählt, um ihm die Frage nach zu stellen Die Antwort enthält 8 Nameserver zur Auswahl, die für die Zone de. verantwortlich sind Bei 3 Servern ist die Abfrage auch mittels IPv6 (AAAA) möglich

21 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Beispiel einer Namensauflösung (4/5) h-da.de IN NS sylt. fhrz.h-da.de. h-da.de IN NS kronos. fhrz.h-da.de. h-da.de IN NS cardassia. fhrz.h-da.de. sylt. fhrz.h-da.de IN A kronos. fhrz.h-da.de IN A cardassia. fhrz.h-da.de IN A ;; Received 150 bytes from # 53( f. nic.de) in 61 ms Aus den 8 genannten Nameservern wurde zufällig f.nic.de ausgewählt, um ihm die Frage nach zu stellen Die Antwort enthält 3 möglichen Delegierungen zur Auswahl, die für die Zone h-da. verantwortlich sind

22 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Beispiel einer Namensauflösung (5/5) www. fbi.h-da.de IN A fbi.h-da.de IN NS sylt. fhrz.h-da.de. fbi.h-da.de IN NS minos. fhrz.h-da.de. fbi.h-da.de IN NS kronos. fhrz.h-da.de. sylt. fhrz.h-da.de IN A minos. fhrz.h-da.de IN A kronos. fhrz.h-da.de IN A ;; Received 162 bytes from #53( kronos.fhrz.h-da.de) in 45 ms Aus den 3 genannten Nameservern wurde zufällig kronos.fhrz.h-da.de ausgewählt, um ihm die Frage nach zu stellen Die Antwort lautet Protokoll von DNS DNS-Anfragen werden meist per UDP Port 53 zum Namensserver gesendet DNS-Anfragen via TCP sind auch möglich und nach dem Standard erlaubt Die maximal zulässige Länge des DNS-UDP-Pakets beträgt 512 Bytes Überlange Antworten werden abgeschnitten übertragen

23 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Dynamic Host Configuration Protocol (DHCP) Das Protokoll ermöglicht die Zuweisung der Netzwerkkonfiguration (IP-Adressen und weitere Parameter) an Netzwerkgeräte mit DHCP-Client durch einen DHCP-Server Verwendet das verbindungslose Transportprotokoll UDP und die Ports 67 (Server oder Relay-Agent) und 68 (Client) Netzwerkeinstellungen müssen nicht manuell eingegeben und fest vergeben werden Bei mobilen Geräten ist es nicht sinnvoll, feste IP-Adressen zu vergeben Bei Änderungen am Netzwerk (an der Topologie) muss man nicht alle Clients, sondern nur die Konfiguration des DHCP-Servers anpassen Der DHCP-Server verfügt über einen Pool an IP-Adressen und verteilt diese an anfragende Clients Damit ein DHCP-Client einen DHCP-Server nutzen kann, muss sich dieser im selben Netzwerksegment befinden Grund: Router leiten keine Broadcasts weiter Liegt der DHCP-Server in einem anderen Netzwerksegment, muss ein DHCP-Relay die Anfragen an den eigentlichen Server weitergeben

24 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Arbeitsweise von DHCP (1/2) 1 Ein Client ohne IP-Adresse sendet als Broadcast eine Anfrage (DHCP-Discover) an die verfügbaren DHCP-Server Es kann durchaus mehrere DHCP-Server in einem Subnetz geben Absender-IP-Adresse des Broadcast: Zieladresse des Broadcast: Jeder erreichbare DHCP-Server mit freien IP-Adressen antwortet auf die Anfrage mit einem Adressangebot (DHCP-Offer) Auch das Adressangebot wird als Broadcast mit der Zieladresse gesendet 3 Der DHCP-Client nimmt ein Adressangebot an, indem er eine Anfrage (DHCP-Request) via Broadcast ins Netzwerk schickt Das Paket enthält die ID des gewünschten DHCP-Servers Die (eventuell vorhandenen) weiteren DHCP-Server erkennen in dem Paket die Absage für ihre Adressangebote 4 Der Server antwortet mit DHCP-Ack und markiert die IP-Adresse in seinem Adresspool als vergeben Er kann die Anfrage auch mit DHCP-Nak ablehnen

25 Arbeitsweise von DHCP (2/2) Hat ein DHCP-Server eine Adresse vergeben und dieses mit DHCP-Ack bestätigt, trägt er in seiner Datenbank bei der Adresse ein Lease ein Sind alle Adressen vergeben (verliehen), können keine weiteren Clients mit IP-Adressen versorgt werden Jede Adresse besitzt ein Verfallsdatum (Lease Time) Wird mit der Bestätigung (DHCP-Ack) an den Client übermittelt Aktive Clients verlängern den Lease regelmäßig nach der Hälfte der Lease-Zeit mit einem erneuten DHCP-Request direkt (via Unicast) an den Server (nicht per Broadcast) Der Server antwortet mit einer erneuten Bestätigung (DHCP-Ack) mit den identischen Daten wie vorher und einem neuen Verfallsdatum Ist das Verfallsdatum abgelaufen, kann der Server die Adresse bei Anfragen wieder vergeben Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56

26 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Aufbau von DHCP-Paketen Operation gibt an, ob es sich um eine Anforderung (Request = 1) des Clients oder eine Antwort (Reply = 2) des Servers handelt Netztyp gibt den Netzwerkstandard an z.b. Ethernet = 1 Länge = Länge der physischen Netzadresse Hops ist optional und gibt die Anzahl der DHCP-Relays auf dem Datenpfad an Flags gibt an, ob der Client noch eine gültige IP-Adresse hat Dateiname ist optional und legt eine Datei (z.b. einen Kernel) fest, die vom Server via TFTP an den Client gesendet werden soll

27 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 DHCP-Relay (1/2) Router trennen Broadcast-Domänen, lassen also Broadcasts nicht durch DHCP-Anfragen werden via Broadcast gesendet Soll DHCP über einen Router hinweg in ein anderes Subnetz angeboten werden, muss der Router als DHCP-Relay konfiguriert werden Der Router wird dann so konfiguriert, dass er Pakete dieses Protokolls weiterleitet Der Router verhält sich dann im Bezug auf das Protokoll so wie eine Bridge in der Sicherungsschicht (2. Schicht) Dieses Vorgehen ist aber nicht erwünscht, da so eventuell mehrere Subnetze mit Broadcasts geflutet werden

28 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 DHCP-Relay (2/2) Ein guter Router, der als DHCP-Relay konfiguriert ist, wird die DHCP-Broadcast-Anfrage in einem IP-Paket verpacken und direkt via Unicast an den DHCP-Server senden Der DHCP-Server sendet sein Adressangebot auch via Unicast an den Router zurück So können mit einem DHCP-Server mehrere Subnetze bedient werden Heute haben viele Router bereits DHCP-Server eingebaut In großen Infrastrukturen muss man abwägen, ob es besser ist, viele dezentrale DHCP-Server (die man warten muss) oder einen zentralen DHCP-Server und DHCP-Relays in den Routern zu betreiben

29 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Network Time Protocol (NTP) Standard zur Synchronisierung von Uhren in Computersystemen über Kommunikationsnetze NTP steht für das Protokoll und für die Referenzimplementierung Entwickelt im 1985 von David L. Mills an der Universität von Delaware Verwendet das verbindungslose Transportprotokoll UDP und Port 123 Die lokale Uhr eines Rechners wird vom lokalen Hintergrundprozess (Dämon) der NTP-Software mit einem externen Zeitsignal (z.b. lokale Atom-Uhr, lokaler Funkempfänger oder entfernter NTP-Server via NTP) synchronisiert Die Zeitstempel im NTP sind 64 Bit lang 32 Bit enthalten die UNIX-Zeit (Sekunden seit dem 1. Januar :00:00 Uhr) 32 Bit enthalten den Sekundenbruchteil Ein Zeitraum von 2 32 Sekunden (ca. 136 Jahre) mit einer Auflösung von 2 32 Sekunden (ca. 0,23 Nanosekunden) ist so darstellbar

30 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Hierarchische Struktur eines Verbundes von NTP-Servern NTP nutzt ein hierarchisches System sogenannter Strata Stratum 0 ist eine Atomuhr oder Funkuhr auf Basis des Zeitsignalsenders DCF77 oder des globalen Navigationssatellitensystems Stratum 1 sind die direkt mit Stratum 0 gekoppelten NTP-Server Jede weitere abhängige Einheit erhält eine höhere Nummer Die NTP-Software auf Stratum 1, 2, usw. ist zugleich Client des darüber liegenden Stratums als auch Server für das darunter liegende Stratum, wenn es denn existiert NTP verwendet die UTC-Zeitskala Es existierten über NTP-Knoten weltweit

31 Eine NTP-Zeitquelle (Stratum 0) U.S. Naval Observatory Schriever Air Force Base in Colorado Bildquelle: Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56

32 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Zeit-Synchronisations-Algorithmus von NTP Berechnung von Umlaufzeitverzögerung und der Abweichung Zeitpunkt t 0 : Client sendet Anfrage Zeitpunkt t 1 : Server empfängt Anfrage Zeitpunkt t 2 : Server sendet Antwort Zeitpunkt t 3 : Client empfängt Antwort t 3 t 0 = Zeitraum zwischen Senden und Empfangen des Clients t 2 t 1 = Zeitraum zwischen Empfangen und Senden des Servers Umlaufzeitverzögerung (Round Trip Delay) = (t 3 t 0 ) (t 2 t 1 ) Abweichung (Offset) = (t 1 t 0 )+(t 2 t 3 ) 2

33 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Telnet (Telecommunication Network) Protokoll zur Fernsteuerung von Rechnern 1971 im Rahmen des ARPANET-Projekts erfunden Bietet zeichenorientierten Datenaustausch über eine TCP-Verbindung Verwendet standardmäßig Port 23 Software, die das Protokoll implementiert, heißt auch einfach Telnet Besteht aus den beiden Diensten Telnet-Client und Telnet-Server Eignet sich nur für Anwendungen ohne grafische Benutzeroberfläche Wird heute häufig zur Fehlersuche bei anderen Diensten und zur Administration von Datenbanken eingesetzt Nachteil: Keine Verschlüsselung! Auch Passwörter werden im Klartext versendet Nachfolger: Secure Shell Protokoll (SSH)

34 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Telnet und das virtuelle Netzwerkterminal Telnet basiert auf dem Standard NVT NVT (Network Virtual Terminal) = virtuelles Netzwerkterminal Konvertierungskonzept für unterschiedliche Codes und Datenformate Herstellerunabhängige Schnittstelle Wird von allen Telnet-Implementierungen unterstützt Verwendet auch andere bekannte Protokolle wie FTP und SMTP Telnet-Clients konvertieren die Tasteneingaben und Kontrollanweisungen in das NVT-Format und übertragen diese Daten an den Telnet-Server NVT arbeitet mit Informationseinheiten von je 8 Bit = 1 Byte Telnet verwendet ASCII-Zeichen mit je 7 Bit Das höchstwertige Bit wird mit Null aufgefüllt, um auf 8 Bit zu kommen

35 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Kontrollanweisungen in Telnet Die Tabelle enthält die Kontrollanweisungen von NVT Die ersten 3 Kontrollzeichen versteht jeder Telnet-Client und -Server Die übrigen 5 Kontrollzeichen sind optional Name Code Dezimalwert Beschreibung NULL NUL 0 No operation Line Feed LF 10 Zeilenvorschub (nächste Zeile, gleiche Spalte) Carriage Return CR 13 Wagenrücklauf (gleiche Zeile, erste Spalte) BELL BEL 7 Hörbares oder sichtbares Signal auf dem Display Back Space BS 8 Cursor eine Position zurück bewegen Horizontal Tab HT 9 Cursor zum nächsten horizontalen Tabulatorstopp bewegen Vertical Tab VT 11 Cursor zum nächsten vertikalen Tabulatorstopp bewegen Form Feed FF 12 Cursor in die erste Spalte der ersten Zeile bewegen und Terminal löschen Ein Zeilenende im Text wird als Wagenrücklauf Carriage Return (CR), gefolgt von einem Zeilenvorschub Line Feed (LF) übertragen Ein Wagenrücklauf im Text wird als CR, gefolgt von einem NUL-Zeichen (alle Bits 0) übertragen

36 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Secure Shell (SSH) Ermöglicht eine verschlüsselte und damit sichere Verbindung zwischen zwei Rechnern über ein unsicheres Netzwerk Sichere Alternative zu Telnet Verwendet standardmäßig Port 22 SSH-1 wurde 1995 von Tatu Ylönen entwickelt und als Freeware veröffentlicht Quelloffene Alternative: OpenSSH ( SSH-2 wurde 1996 veröffentlicht und hat u.a. eine verbesserte Integritätsprüfung X11 kann über SSH transportiert werden Beliebige TCP/IP-Verbindungen können über SSH getunnelt werden (Port-Weiterleitung) SSH-2 verwendet den Verschlüsselungsalgorithmus AES mit einer 128 Bit Schlüssellänge Zudem werden 3DES, Blowfish, Twofish, CAST, IDEA, Arcfour, SEED und AES mit anderen Schlüssellängen unterstützt

37 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Hypertext-Übertragungsprotokoll Das Hypertext Transfer Protocol (HTTP) ist ein zustandsloses Protokoll zur Übertragung von Daten Ab 1989 von Roy Fielding, Tim Berners-Lee und anderen am CERN entwickelt Ist gemeinsam mit den Konzepten URL und HTML die Grundlage des World Wide Web (WWW) Haupteinsatzzweck: Webseiten aus dem World Wide Web (WWW) in einen Webbrowser laden Zur Kommunikation ist HTTP auf ein zuverlässiges Transportprotokoll angewiesen In den allermeisten Fällen wird TCP verwendet Jede HTTP-Nachricht besteht aus: Nachrichtenkopf (HTTP-Header): Enthält u.a. Informationen zu Kodierung, zur gewünschten Sprache, über den Browser und Inhaltstyp Nachrichtenkörper (Body): Enthält die Nutzdaten

38 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 HTTP-Anfragen (1/2) Wird über HTTP auf eine URL (z.b. zugegriffen, wird an den Rechner mit dem Hostnamen die Anfrage gesendet, die Ressourcen /~baun/index.html zurückzusenden Zuerst wird der Hostname via DNS in eine IP-Adresse umgewandelt Über TCP wird zu Port 80 (auf dem der Web-Server üblicherweise arbeitet) folgende HTTP-GET-Anforderung gesendet GET /~baun / index.html HTTP /1.1 Host : www. informatik.hs - mannheim.de User - Agent : Mozilla /5.0 (X11 ; U; Linux i686 ; de; rv : ) Gecko / Ubuntu /10.10 ( maverick ) Firefox / Accept : text /html, application / xhtml+xml, application /xml ;q=0.9,*/*; q=0.8 Accept - Language : de -de,de;q=0.8,en -us;q=0.5, en;q=0.3 Accept - Encoding : gzip, deflate Accept - Charset : ISO , utf -8;q=0.7,*;q=0.7 Keep - Alive : 115 Connection : keep - alive...

39 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 HTTP-Anfragen (2/2) So ein großer Nachrichtenkopf ist eigentlich nicht nötig Die folgende HTTP-GET-Anforderung genügt völlig GET /~baun / index.html HTTP /1.1 Host : www. informatik.hs - mannheim.de Der Nachrichtenkopf wird mit einer Leerzeile (bzw. zwei aufeinanderfolgenden Zeilenenden) vom Nachrichtenkörper abgegrenzt In diesem Fall hat die HTTP-Anforderung keinen Nachrichtenkörper

40 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 HTTP-Antworten (1/2) Die HTTP-Antwort des Web-Servers besteht aus einem Nachrichtenkopf und dem Nachrichtenkörper mit der eigentlichen Nachricht In diesem Fall enthält der Nachrichtenkörper den Inhalt der Datei index.html HTTP / OK Date : Sun, 04 Sep :19:13 GMT Server : Apache / ( Fedora ) Last - Modified : Mon, 22 Aug :37:04 GMT ETag : " 101ec ab17561a3c00 " Accept - Ranges : bytes Content - Length : 8535 Keep - Alive : timeout=13, max=499 Connection : Keep - Alive Content - Type : text / html <! DOCTYPE HTML PUBLIC " -// W3C // DTD HTML 4.01 Transitional // EN" "http :// /TR/ html4 / loose.dtd "> <html >... </ html >

41 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 HTTP-Antworten (2/2) Jede HTTP-Antwort enthält einen HTTP-Statuscode (3 Ziffern) und eine Textkette, die den Grund für die Antwort beschreibt Statuscode Bedeutung Beschreibung 1xx Informationen Anfrage erhalten, Prozess wird fortgeführt 2xx Erfolgreiche Operation Aktion erfolgreich empfangen. Antwort wird an den Client gesendet 3xx Umleitung Weitere Aktion des Clients erforderlich 4xx Client-Fehler Anfrage des Clients fehlerhaft 5xx Server-Fehler Fehler, dessen Ursache beim Server liegt Die Tabelle enthält einige populäre HTTP-Statuscodes Statuscode Beschreibung Beschreibung 118 Connection timed out Zeitüberschreitung beim Ladevorgang 200 OK Anfrage erfolgreich bearbeitet. Ergebnis wird in der Antwort übertragen 202 Accepted Anfrage akzeptiert, wird aber zu einem späteren Zeitpunkt ausgeführt 204 No Content Anfrage erfolgreich durchgeführt. Antwort enthält bewusst keine Daten 301 Moved Permanently Ressource verschoben. Die alte Adresse ist nicht länger gültig 307 Temporary Redirect Ressource verschoben. Die alte Adresse bleibt gültig 400 Bad Request Anfrage-Nachricht war fehlerhaft aufgebaut 401 Unauthorized Anfrage kann nicht ohne gültige Authentifizierung durchgeführt werden 403 Forbidden Anfrage mangels Berechtigung des Clients nicht durchgeführt 404 Not Found Ressource vom Server nicht gefunden 500 Bad Request Unerwarteter Serverfehler

42 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Das Protokoll HTTP Es existieren 2 Protokollversionen: HTTP/1.0 und HTTP/1.1 HTTP/1.0: Vor jeder Anfrage wird eine neue TCP-Verbindung aufgebaut und nach Übertragung der Antwort standardmäßig vom Server wieder geschlossen Enthält ein HTML-Dokument z.b. 10 Bilder, sind 11 TCP-Verbindungen nötig HTTP/1.1: Ein Client kann durch den Headereintrag Connection: keep-alive anweisen, dass kein Verbindungsabbau durchgeführt wird So kann die Verbindung immer wieder verwendet werden Für das HTML-Dokument mit 10 Bildern ist so nur 1 TCP-Verbindung nötig Dadurch kann die Seite schneller geladen werden

43 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 HTTP-Methoden Das HTTP-Protokoll enthält einige Methoden für Anfragen HTTP PUT GET POST DELETE HEAD TRACE OPTIONS CONNECT Beschreibung Neue Ressource auf den Web-Server hochladen Ressource vom Web-Server anfordern Daten zum Web-Server hochladen, um Ressourcen zu erzeugen Eine Ressource auf dem Web-Server löschen Header einer Ressource vom Web-Server anfordern, aber nicht den Body Liefert die Anfrage so zurück, wie der Web-Server sie empfangen hat. Hilfreich für die Fehlersuche Liste der vom Web-Server unterstützten HTTP-Methoden anfordern SSL-Tunnel mit einem Proxy herstellen HTTP ist ein zustandsloses Protokoll. Über Cookies in den Header-Informationen sind dennoch Anwendungen realisierbar, die Status- bzw. Sitzungseigenschaften erfordern weil sie Benutzerinformationen oder Warenkörbe den Clients zuordnen.

44 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Eine Möglichkeit, Web-Server zu testen, ist telnet (1/2) $ telnet www. informatik.hs - mannheim.de 80 Trying Connected to anja.ki.fh - mannheim.de. Escape character is ^]. GET /~baun / index.html HTTP /1.0 HTTP / OK Date : Sun, 04 Sep :43:53 GMT Server : Apache / ( Fedora ) Last - Modified : Mon, 22 Aug :37:04 GMT ETag : " 101ec ab17561a3c00 " Accept - Ranges : bytes Content - Length : 8535 Connection : close Content - Type : text / html X-Pad : avoid browser bug <! DOCTYPE HTML PUBLIC " -// W3C // DTD HTML 4.01 Transitional // EN" "http :// /TR/ html4 / loose.dtd "> <html > <head > <meta http - equiv="content -Type " content="text /html ; charset=iso ">... </ body > </ html > Connection closed by foreign host.

45 Dr. Christian Baun 8.Vorlesung Netzwerke Hochschule Darmstadt WS /56 Eine Möglichkeit, Web-Server zu testen, ist telnet (2/2) $ telnet www. informatik.hs - mannheim.de 80 Trying Connected to anja.ki.fh - mannheim.de. Escape character is ^]. GET /~baun / test. html HTTP /1.0 HTTP / Not Found Date : Sun, 04 Sep :47:26 GMT Server : Apache / ( Fedora ) Content - Length : 301 Connection : close Content - Type : text / html ; charset=iso <! DOCTYPE HTML PUBLIC " -// IETF // DTD HTML 2.0// EN"> <html ><head > <title >404 Not Found </ title > </ head ><body > <h1 >Not Found </h1 > <p>the requested URL /~ baun / test. html was not found on this server.</p> <hr > <address>apache / ( Fedora ) Server at anja.ki.hs - mannheim.de Port 80</ address> </ body ></ html > Connection closed by foreign host.