Netzwerke Marcel Waldvogel
Netzwerke
Marcel Waldvogel
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 2
Netzwerke
Verbinden Endgeräte (End Systems) (Mobil-)Telefone, Terminals, Rechner
Verbindungen zwischen Schaltknoten(Intermediate Systems)
Router, Switches, Gateways, Firewalls, NATs, ...
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 3
Vorteile
Nutzung entfernter Resourcen Rechenleistung Information (Datenbanken)
Anfragen, Synchronisation
Ein-/Ausgabegeräte Personen
Sofortige Verbindung
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 4
Basisdienste
Verbindung ("Best Effort") Adressierung
Telefonnummern Internet-Adressen
Routing (Leitweglenkung)
Qualität ("QoS") Mindestbandbreite Maximale Verzögerung, Jitter Bitfehler, Paketverluste
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 5
Applikationen
Datentransfer
Fernbenutzung/-steuerung Remote Login/Telnet
Namenszuordnung
Chat
Fernabfrage Gopher, WWW, ...
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 6
Leitweglenkung
Ziel: Kenntnis des besten Pfades zujedem Endsystem im Netz
Probleme Internet mehrere 100 Millionen Rechner Mobiltelefonie: ~100 Millionen Telefone Wenn für wenige Promille davon pro
Minute die Pfadinformation ändert, ist das Netz mit Aktualisieren allein bereits überlastet
Neuer Rechner/Einwahl ins Netz Beenden der Verbindung Verschieben
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 7
Skalierung
Lösung im Internet: Aggregation Rechner werden zu Netzen
zusammengefasst; nur Information pro Netzwerk, nicht pro Endsystem
Netzwerke werden hierarchisch weiter zusammengefasst, je weiter man davon weg ist
Beispiel Uni Konstanz: Einige 100 Netze, ausserhalb der Uni nicht sichtbar
Beispiel Internet Service Provider: Am Ort X mehrere kleine Firmen mit benachbarten Adressen; innerhalb Details bekannt, am Ort Y nur summarische Information zu XAusserhalb ISP: Nur summarische Information zum Gesamtnetz
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 8
Skalierung (2)
Lösung Mobiltelefonie: Heimbasis Selten neue Verbindungen; selten grosse
Reisedistanzen während einer Verbindung Bei Bewegungen wird Heimbasis über
aktuelle Position informiert Bei Anruf (Verbindungsaufbau) wird
Heimbasis kontaktiert, welche dann aktuelle Position für Datenaustausch liefert
Innerhalb einer Gruppe von benachbarten Basisstationen Übergabe und Nachführung ohne Heimbasis
Verwendung auch bei Mobile IP
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 9
Distanz-Vektor
Regelmässige "Hallo"-MeldungenSo entdeckte direkte Nachbarn
tauschen untereinander Routinginformationen aus
Bekannte Ziele und "Distanz" (oft "Kosten" genannt) dorthin
Lokale Bestimmung des "kürzesten" Pfades zu allen Zielen und des dafür zuständigen Nachbarn ("Vektor")
Informiere Nachbarn, wenn Distanz ändert
RIP: Einsatz typischerweise nur in sehr kleinen Netzen
Problem: Count-to-Infinity
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 10
Pfad-Vektor
Wie Distanz-Vektor, aber Liste aller zu durchlaufender Router
Vermeidet Count-to-Infinity
BGP: Border Gateway Protocol Globales Routing im Internet (zwischen
ISPs) Pfad listet Autonomous Systems (etwa
ISPs), nicht Router
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 11
Link-Zustand
Information: Nachbarliste jedes Routers
Verteilung durch Fluten ("Flooding") Jeder Router kennt so gesamte Topologie Pfadsuche im lokalen Graphen
OSPF: Einsatz in grösseren Netzwerken (Unis, ISPs, Mittel-/Grossfirmen)
Kein Count-to-Infinity
Erweiterbar Alternative Pfade QoS
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 12
Mehrere Applikationen?
Typischerweise mehrere Applikationen pro Rechner
Well-Known Services Nur ein Anbieter pro Service und Rechner http: HyperText Transfer Protocol ftp: File Transfer Protocol telnet, rlogin, rsh, ssh: Secure/Remote
Shells smtp: Simple Mail Transfer Protocol domain: Domain Name Service (DNS) ntp: Network Time Protocol nfs: Network File System
Dienstadressen (Ports)
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 13
Anforderungen der Applikationen
Eigenschaften von Kommunikationskanälen?
Zuverlässigkeit Datenverlust Übertragungsfehler Reihenfolge
Latenzzeit Übertragungsrate Datenpakete und -ströme
Maximierung aller Eigenschaften gleichzeitig?
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 14
Kompromiss
Zwei Protokolle im Internet
TCP (Transmission Control Protocol) Zuverlässig Verbindungsorientierter Datenstrom Latenzzeit und Datenrate
"netzwerkfreundlich"
UDP (User Datagram Protocol) Unzuverlässige Einzelpakete Optionaler Fehlererkennung Alles andere Aufgabe der Applikation
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 15
Wahl des Protokolls
Telnet Virtuelle Terminalverbindung Zuverlässiger TCP-Strom von Zeichen
NTP (Network Time Protocol) Möglichst verzögerungsfreie
Übertragung von einzelnen Zeitstempeln
NFS (Network File System) Zuverlässiger Dienst Klassisch UDP (wieso?), heute meist TCP
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 16
File Transfer Protokoll
Getrennte Verbindungen für Steuerung und Daten
TCP Vierbuchstabiges textbasiertes Interface
USER PASS (...word) LIST PORT oder PASV (passive) RETR (...ieve) QUIT
Dreistellige Codes
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 17
SMTP
Eine TCP-Verbindung für Steuerung und Daten
ASCII-basierte Befehle mit vier Buchstaben
HELO oder EHLO (Extended HELO für ESMTP) MAIL FROM: RCPT TO: DATA QUIT
Dreistellige Codes
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 18
HTTP
TCP-basiertASCII-Interface mit
Versionsverwaltung Befehle
GET <URL> HTTP/<Version> POST HEAD
... und Header ("Titelzeilen"); Zusatzinfos Host: User-Agent: If-Modified-Since:
Dreistellige Zifferncodes ab Version 1.0 erst nach HTTP/<Version>
Vor HTTP/1.1 nur eine Anfrage
Content-Type: Content-Length: Date:
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 19
Namen und Adressen
Internet: "dotted-quad"-Adressen 134.34.57.32
Menschen: Mnemonische Namen www.inf.uni-konstanz.de
Umsetzung Name Adressehosts.txt bis ein paar tausend
RechnerSuche nach neuem Mechanismus
Verteilte Server Verteilte Administration Skalierbar Erweiterbar
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 20
DNS
Hierarchische Struktur Punkte als Hierarchietrenner
www.inf.uni-konstanz.de Struktur analog Dateisystem
/de/uni-konstanz/inf/www Einträge
Delegationen für "Unterverzeichnisse" (NS) Adressen (A) weitere Informationen (MX, CNAME, TXT,
KEY, ...) Wurzel redundant (z.Z. 13 Server) Möglichst direkte Anfragen Aggressives Caching mit Time-To-Live Rückwärtsumsetzung
134.34.57.32 -> 32.57.34.134.in-addr.arpa
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
21
DNS: Domain Name System
Personen: Viele IdentifikationenName, Telefon-, Passnummer
Rechner+Router im Internet:IP-Adresse (32 bit) - Adressierung von Datenpaketen“Name”, z.B. www.inf.uni-konstanz.de für Menschen
Frage: Umsetzung?
Domain Name System:Verteilte Datenbank: Hierarchie von vielen Name Servers
Applikationsprotokoll: Rechner, Router und Name Servers kommunizierenMerke: Kernfunktion des Internets implementiert auf ApplikationsebeneZiel: Komplexität an den Rand des NetzwerksErstes binäres Protokoll
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
22
DNS Name Server
Kein Server hat alle Namens-IP-Umsetzungen
Lokale Name ServerJeder ISP, jede Organisation hat Lokale (Standard-) Name ServerAnfrage zuerst an Lokalen Server
Originale Name Server:
Offizieller Verwalter einer Umsetzung
Wieso kein zentrales DNS?"Single Point of Failure"VerkehrsvolumenEntfernte DatenbankUnterhaltVertrauensfrageSkaliert nicht
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
23
DNS: Wurzelserver
Anfrage von lokalen Servern
WurzelserverVerbindet zu offiziellem Name Server, falls Umsetzung nicht bekannt
13 Wurzelserver weltweit
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
24
Einfaches DNS-Beispiel
Rechner surf.ethz.ch will IP-Adresse von neo.arl.wustl.edu
1. Anfrage an lokalen Server, dns1.ethz.ch
2. dns1.ethz.ch fragt Wurzelserver falls nötig
3. Wurzelserver fragt offiziellen Server (ns1.wustl.edu) falls nötig Anfrage
surf.ethz.chneo.arl.wustl.edu
Wurzelserver
Offizieller Serverns1.wustl.edu
Lokaler Serverdns1.ethz.ch
1
23
4
5
6
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
25
DNS-Beispiel
Wurzelserver:kennt u.U. offiziellen Nameserver nicht
kennt aber Zwischenliegende Name Server: jemanden, der bei der Suche weiterhelfen kann
Anfragesurf.ethz.ch
neo.arl.wustl.edu
Wurzelserver
Lokaler Serverdns1.ethz.ch
1
23
4 5
6
Offizieller Serverdns.arl.wustl.edu
Zwischenliegender Serverns1.wustl.edu
7
8
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
26
DNS: Rekursion und Iteration
Rekursive Anfrage:Belastet den angefragten Server mit der gesamte Aufgabe
Zustand und Timer für Wiederholungen
Hohe Last
Liefert auch offiziellen Server für weitere direkte Anfragen
Iterative Anfrage:Angefragter Server antwortet mit Name und Adresse des Servers für den nächsten Schritt
"Keine Ahnung, aber frag mal den da"
Lokaler Server kennt den offiziellen Server
Distanzen?
requesting hostsurf.ethz.ch
neo.arl.wustl.edu
root name server
local name serverdns1.ethz.ch
1
23
4
5 6
authoritative name serverdns.arl.wustl.edu
intermediate name serverns1.wustl.edu
7
8
iterated query
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
27
DNS: Zwischenspeicher und Aktualisieren
Sobald ein Server eine Zuordnung kennt, speichert er dieses
Wann ist Caching gut? (“locality of reference”)
Timeout (TTL)
Aktives UpdateRFC 2136 and 2137
http://www.ietf.org/html.charters/dnsind-charter.html
Nicht für Caches (zu viel Zustandsinformation)
Sicherheit von DNSDNS kritisch zur Identifikation von Servern ("spoofing")
DNSsec-Arbeitsgruppe der IETF
http://www.ietf.org/html.charters/dnssec-charter.html
RFCs 2535 ... 2541
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
28
DNS: Erfolg des Caches
Anfrage vonsurf.ethz.ch trinity.arl.wustl.edu
Lokaler Serverdns1.ethz.ch
1
2
Offizieller Serverdns.arl.wustl.edu
3
4
Anfrage vonbrowse.ethz.ch
Lokaler Serverdns1.ethz.ch
1 2
neo.arl.wustl.edu? trinity.arl.wustl.edu?
Effizienter für ähnliche Anfragen (sowohl an der Quelle, als auch am Ziel)
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
29
DNS-Einträge
DNS: Verteilte, hierarchische Datenbank für "resource records"(RR). Delegation durch NS.
Typ=NSname ist Domäne (z.B. example.com)value ist Name des offiziellen Servers; Adresse im "Additional"-Abschnitt
Format der RR:(name, value, type, ttl)
Typ=Aname ist hostnamevalue ist IP-Adresse
Typ=CNAMEname ist ein Alias für einen "kanonischen" valueCNAMEs werden als Nebeneffekt aufgelöst; Exklusivitätsanspruch
Typ=MXvalue ist Hostname (und Priorität) des Mailservers für die Domäne name
SOA, HINFO, TXT, PTR
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
30
DNS-Protokoll, -Nachrichten
DNS-Protokoll: Anfragen und Antworten im selben Format
Nachrichtenkopf:identification: 16 bits; Antwort benutzt selbe ID
flags:Frage oder AntwortRekursion erwünschtRekursion möglichAntwort ist offiziell
RFC 1035
32 bits
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
31
DNS-Protokoll, -Nachrichten
Name, Typ der Anfrage
RRs der Antwort
Wer ist offizieller Server
Zusätzliche hilfreicheInformation
32 bitsSequenznummer,
minimale Sicherheit
Befehl und Resultat
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
32
DNS-Anfrage
% dig tik2.ethz.ch any; <<>> DiG 8.2 <<>> tik2.ethz.ch any;; res options: init recurs defnam dnsrch;; got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3;; QUERY SECTION:;; tik2.ethz.ch, type = ANY, class = IN ;; ANSWER SECTION:tik2.ethz.ch. 11h23m2s IN A 129.132.119.132 ;; AUTHORITY SECTION:ethz.ch. 6d23h38m19s IN NS dns1.ethz.ch.ethz.ch. 6d23h38m19s IN NS dns3.ethz.ch.ethz.ch. 6d23h38m19s IN NS dns2.ethz.ch. ;; ADDITIONAL SECTION:dns1.ethz.ch. 23h38m19s IN A 129.132.98.12dns3.ethz.ch. 23h38m19s IN A 129.132.250.2dns2.ethz.ch. 23h38m19s IN A 129.132.250.220 ;; Total query time: 1 msec;; FROM: neo.arl.wustl.edu to SERVER: default -- 128.252.153.107;; WHEN: Thu Sep 21 14:18:14 2000;; MSG SIZE sent: 30 rcvd: 158 Umgekehrt
eAnfrage?
Nicht erfragt,müsste abererfragt werden.}
Mehrere Einträge mitgleichem Namen undTyp, zufällig sortiert(Laustausgleich)
}
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
33
Umgekehrte Anfrage
Wieso braucht jemand den Namen zu einer Adresse?
Wieso sprecht ihr eure Freunde mit Namen an und nicht mit der Telefon- oder Personalnummer?
Authentisierung (einzelner Rechner oder ganze Domäne, z.B. *.inf.uni-konstanz.de)
Logdateien
Delegation? Hierarchie?
DNS-names: ASCII-Zeichenketten, “little endian”
IP-Addressen: Bit strings (oder "Dotted Quads"), “big endian”
Trick: Reversal of dotted quad, append pseudo-domain129.132.1.11 ® 11.1.132.129.in-addr.arpa (PTR RR)
Sicherheit?
Einfacher: Frage den Host (Lösung in IPv6)
Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet
34
% dig -x 129.132.119.132; <<>> DiG 8.2 <<>> -x;; res options: init recurs defnam dnsrch;; got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3;; QUERY SECTION:;; 132.119.132.129.in-addr.arpa, type = ANY, class = IN ;; ANSWER SECTION:132.119.132.129.in-addr.arpa. 1D IN PTR tik2.ethz.ch. ;; AUTHORITY SECTION:132.129.in-addr.arpa. 5w6d16h IN NS dns1.ethz.ch.132.129.in-addr.arpa. 5w6d16h IN NS dns2.ethz.ch.132.129.in-addr.arpa. 5w6d16h IN NS dns3.ethz.ch. ;; ADDITIONAL SECTION:dns1.ethz.ch. 1D IN A 129.132.98.12dns2.ethz.ch. 1D IN A 129.132.250.220dns3.ethz.ch. 1D IN A 129.132.250.2 ;; Total query time: 4091 msec;; FROM: neo.arl.wustl.edu to SERVER: default -- 128.252.153.107;; WHEN: Thu Sep 21 14:23:17 2000;; MSG SIZE sent: 46 rcvd: 197
Umkehrfrage
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 35
Wer macht Internet-Standards?
Urzeit (~1970) Mitteilungen an andere Benutzer als
nummerierte "Requests for Comment (RFC)"
Heute IETF (Internet Engineering Task Force)
Daneben IRTF (R=Research) für experimentelles Unterteilt in Gebiete (Areas) Unterteilt in Arbeitsgruppen (Working
Groups) Jeder kann mitmachen (keine Mitgliedschaft) Diskussion von Vorschlägen in öffentlichen
Mailinglisten ® Internet-Drafts Evt. zu RFC (z.Z. > 3000) Etliche Jahre später evt. zu STD (Standard; ~20)
Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 36
IETF-Grundlagen
Grundlage für ein RFC Rough consensus and running code
Zunehmende Komplexität des Netzwerkes und der Interaktionen mit Protokollen
Always think very hard before messing with TCP. And then don't. –Matt Crawford