Rechnerkommunikation

Inhalt der Vorlesung „ Rechnerkommunikation“







Einführung
Anwendungsschicht
Transportschicht
Netzwerkschicht
Verbindungsschicht
Physikalische Schicht
Netzwerksicherheit
Rechnerkommunikation, Anwendungsschicht
1
Anwendungsschicht
 Einführung
 Verbreitete Anwendungen








Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
E-Mail
Netzwerkmanagement
Domain Name System (DNS)
Content Distribution Networks
Real-Time Protocol (RTP)
Session Initiation Protocol (SIP)
 Socket-Programmierung
 Verteilte Systeme
 Peer-to-Peer-Systeme
Rechnerkommunikation, Anwendungsschicht
2
Einführung
 Netzwerkanwendung
 Anwendungsprozesse auf
verschiedenen Endsystemen (Hosts),
die mittels Nachrichten über ein
Netzwerk kommunizieren
 kann direkt unter Verwendung der
Dienste der Transportschicht
implementiert werden
 standardisierte Anwendungen
benutzen ein Anwendungsprotokoll,
das das Format der Nachrichten und
das Verhalten beim Empfang von
Nachrichten festlegt
 z.B: Web-Browser und -Server
 die unteren Schichten und der
Netzwerkkern benötigen keine
Kenntnis der Anwendung
 einfache Verbreitung, große Dynamik
Rechnerkommunikation, Anwendungsschicht
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
3
Einführung
 Client-Server-Paradigma
 Server stellt Dienst zur Verfügung,
der von Client angefordert wird
 übliches Paradigma von vielen
traditionellen Anwendungen, wie
z.B. Web-Browser und –Server
 typische Eigenschaften des Servers
- leistungsfähig
- immer verfügbar
 typische Eigenschaften der Clients
- nur manchmal verbunden
- kommunizieren mit Server,
nicht untereinander
Rechnerkommunikation, Anwendungsschicht
4
Einführung
 Client-Server-Paradigma ist zentralisierte Architektur
 Weitere Paradigmen
 wechselnde Rolle von Client und Server: Hosts übernehmen mal die
eine, mal die andere Rolle (z.B. bei Web-Caching oder SMTP)
 verteilte Anwendung: besteht aus mehreren unabhängigen
Anwendungen, die zusammen wie eine einzelne Anwendung erscheinen
(z.B. WebShop mit Web-Server, Applikations-Server und Datenbank),
Koordination ist zwar verteilt, findet aber für das Gesamtsystem statt
 noch stärker dezentrale Architektur: autonome sich selbst
organisierende Systeme ohne globale Steuerung (z.B. einige Peer-toPeer-Anwendungen wie Gnutella, Chord)
 Hybridarchitektur: zur Initialisierung ist eine zentrale Architektur nötig,
die Anwendung findet dann dezentral direkt zwischen Hosts statt (z.B.
bei Session Initiation Protocol, SIP oder bei manchen Peer-to-PeerAnwendungen wie Bittorrent)
Rechnerkommunikation, Anwendungsschicht
5
Einführung
 Varianten des Client-Server-Paradigmas
Client-Computer
Thin Client
Benutzungsschnittstelle
Fat Client
Benutzungsschnittstelle
Benutzungsschnittstelle
Benutzungsschnittstelle
Benutzungsschnittstelle
Anwendung
Anwendung
Anwendung
Datenbank
Benutzungsschnittstelle
Anwendung
Anwendung
Anwendung
Datenbank
Datenbank
Datenbank
Fat Server
Datenbank
Datenbank
Thin Server
Server-Computer
Rechnerkommunikation, Anwendungsschicht
6
Einführung
 Dienste der Transportschicht
 im Internet gibt es zwei dominierende Transportprotokolle
- TCP: verbindungsorientiert (abstrakte Sicht des Versendens eines
Bytestroms), zuverlässig
- UDP: verbindungslos (Versenden einzelner Datagramme),
unzuverlässig
 werden meist im Betriebssystem realisiert
 die meisten Betriebssysteme bieten Socket-Schnittstelle, die durch
Programmiersprachen als API angeboten wird
 mit Socket kann festgelegt werden
- Transportprotokoll (TCP oder UDP)
- IP-Adresse von Sende- und Zielhost
- Portnummern (um Anwendungen auf Hosts zu unterscheiden)
 und so können Anwendungen programmiert werden …
Rechnerkommunikation, Anwendungsschicht
7
Einführung
 Quantitative Anforderungen von Anwendungen
 Verlust
- nicht tolerierbar bei Dateitransfer, Online-Banking etc.
- teilweise tolerierbar bei Multimedia
 Bitrate
- traditionelle Anwendungen wie FTP, e-mail und HTTP benötigen
keine feste Bitrate, sind aber „besser“, wenn sie viel Bitrate
erhalten („Best-Effort-Verkehr“, „elastische Anwendungen“)
- Echtzeit-Multimedia benötigt Mindest-Bitrate
 Verzögerungszeit
- traditionelle Anwendungen benötigen keine maximale
Verzögerungszeit, sind aber wieder „besser“ bei kurzen Zeiten
- Echtzeit-Multimedia und interaktive Spiele benötigen kurze
Verzögerungszeit
- Steuerungen technischer Geräte benötigen oft Garantie einer
maximalen Verzögerungszeit
Rechnerkommunikation, Anwendungsschicht
8
Einführung
 Quantitative Anforderungen von Anwendungen
Anwendung
Verlust
Bitrate
Verzögerungszeit
Dateitransfer
kein Verlust
elastisch
keine harte Grenze
e-mail
kein Verlust
elastisch
keine harte Grenze
Web-Dokumente
kein Verlust
elastisch
keine harte Grenze
Echtzeit-Multimedia
Verlust tolerierbar
Audio: Kbps - Mbps
Video: 10 Kbps - 5 Mbps
150 ms
Einwegverzögerung
unbemerkt
Streaming von
Multimedia
Verlust tolerierbar
wie oben
einige s
Interaktive Spiele
Verlust tolerierbar
Kbps – 10 Kbps
einige 100 ms
Automatisierung
kein Verlust
Kbps
oft harte Grenzen,
z.B. einige ms
Instant Messaging
kein Verlust
elastisch
„kommt darauf an“
Rechnerkommunikation, Anwendungsschicht
9
Einführung
 Einige bekannte Anwendungsprotokolle und das
darunterliegende Transportprotokoll
Anwendung
Anwendungsprotokoll
verwendetes
Transportprotokoll
e-mail
SMTP [RFC 2821]
TCP
Remote Terminal Access
Telnet [RFC 854]
TCP
Web
HTTP [RFC 2616]
TCP
Dateitransfer
FTP [RFC 959]
TCP
Remote File Server
NFS [McKusik 1996]
UDP or TCP
Streaming Multimedia
RTP, proprietär
UDP or TCP
Internettelefonie
RTP, proprietär
meistens UDP
Rechnerkommunikation, Anwendungsschicht
10
Anwendungsschicht
 Einführung
 Verbreitete Anwendungen








Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
E-Mail
Netzwerkmanagement
Domain Name System (DNS)
Content Distribution Networks
Real-Time Protocol (RTP)
Session Initiation Protocol (SIP)
 Socket-Programmierung
 Verteilte Systeme
 Peer-to-Peer-Systeme
Rechnerkommunikation, Anwendungsschicht
11
HTTP
 Ablauf
 Benutzer gibt Uniform Resource
Locator (URL) in Web-Browser
ein
 URL enthält Host-Namen eines
Web-Servers und den Pfad zu
einem Objekt (Datei) dort
 Web-Browser stellt Anfrage an
Web-Server für dieses Objekt
 Web-Server liefert Objekt an
Web-Browser zurück
 Web-Browser stellt Objekt in für
den Benutzer lesbarer Form dar
PC mit
MS Explorer
Server
mit
Apache WebServer
Mac mit
Firefox
Rechnerkommunikation, Anwendungsschicht
12
HTTP: Anfragenachrichten
 Format der Anfragenachrichten
Anfragezeile
method
sp
URL
sp
version
header field name: sp
value
cr lf
header field name: sp
value
cr lf
cr lf
Kopfzeilen
Leerzeile
cr lf
Rumpf
Rechnerkommunikation, Anwendungsschicht
13
HTTP: Anfragenachrichten
 Methoden




GET: Abruf eines Dokuments, besteht aus Methode, URL, Version
HEAD: Abruf von Metainformationen eines Dokuments
POST: Ausgabe von Informationen an Server
Put, Delete, Trace, Options
 Kopfzeilen
 Typ/Wert-Paare, Typen: Host, User-agent, …
 Rumpf

 leer bei GET, kann bei POST Inhalt haben
/somedir/page.html HTTP/1.1
Beispiel Anfragenachricht: GET
Host: www.someschool.edu
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr
(extra carriage return, line feed)
Rechnerkommunikation, Anwendungsschicht
14
HTTP: Antwortnachrichten
 Format der Antwortnachrichten
Statuszeile
version
sp status code sp
phrase
header field name: sp
value
cr lf
header field name: sp
value
cr lf
cr lf
Kopfzeilen
Leerzeile
cr lf
Rumpf
Rechnerkommunikation, Anwendungsschicht
15
HTTP: Antwortnachrichten
 Mögliche Codes in der Statuszeile





200
301
400
404
505
OK („alles klar“)
Moved Permanently (Redirection: Objekt zu finden unter Location: …)
Bad Request (Anfragenachricht nicht verstanden)
Not Found (Objekt nicht gefunden)
HTTP Version Not Supported
 BeispielAntwortnachricht:
HTTP/1.1 200 OK
Connection: close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
Rechnerkommunikation, Anwendungsschicht
16
HTTP: Ablauf
 HTTP-Ablauf
 nicht-persistentes HTTP
- für jedes Objekt wird einzelne TCP-Verbindung geöffnet, Server
beendet sie sofort nach dem Senden eines Objekts
- entweder Basis-Seite und eingebettete Objekte sequentiell
- oder parallele einzelne Verbindungen für die eingebetteten Objekte
 persistentes HTTP
- Server läßt Verbindung bestehen
- alle Objekte werden über eine TCP-Verbindung gesendet
- ohne Pipelining: nach jedem Objekt Anfrage für nächstes Objekt
- mit Pipelining: eine Anfrage für alle eingebetteten Objekte
 Was sind die Vor- und Nachteile?
 Standardport des Web-Servers: 80
Rechnerkommunikation, Anwendungsschicht
17
HTTP: Ablauf
 Beispiel-Ablauf von nicht-persistentem HTTP
 URL: www.someSchool.edu/someDepartment/home.index
 Basis-Seite enthält 10 eingebettete Objekte (jpeg)
1a. HTTP-Client-Prozeß initiiert TCP-
Verbindung zu HTTP-Server-Prozeß
auf Host www.someSchool.edu an
Port 80
1b. HTTP-Server-Prozeß auf Host
www.someSchool.edu wartet auf
TCP-Verbindungen an Port 80,
nimmt TCP-Verbindung an,
benachrichtigt Client
2. HTTP-Client übergibt HTTP-Anfrage
an TCP-Socket, enthält URL mit
Verweis auf Objekt
someDepartment/home.index
3. HTTP-Server empfängt HTTP-
Anfrage, erstellt HTTP-Antwort mit
dem gewünschten Objekt und
übergibt diese TCP-Socket
Zeit
Rechnerkommunikation, Anwendungsschicht
18
HTTP: Ablauf
4. HTTP-Server schließt TCP-Verbindung
5. HTTP-Client erhält HTTP-Antwort mit
dem HTML-Inhalt, analysiert ihn,
stellt ihn auf dem Bildschirm dar,
erkennt 10 eingebettete jpegObjekte
Zeit
6. die Schritte 1-5 werden für jedes
eingebettete Objekt wiederholt
Rechnerkommunikation, Anwendungsschicht
19
HTTP: Ablauf
 Antwortzeit
 Basis-Seite
- Aufbau der TCPVerbindung
erfordert eine
Round Trip Time (RTT)
- Anfragenachricht hin,
Antwortnachricht zurück,
erfordert noch eine RTT
- insgesamt:
2 RTT
+ Zeit zum Senden
+ weitere Wartezeiten
durch TCP
 wie ist es bei den anderen
HTTP-Varianten?
Rechnerkommunikation, Anwendungsschicht
Initialisierung
der TCPVerbindung
RTT
Senden der
HTTP-Anfrage
Übertragungszeit
HTTPAntwort
RTT
Antwort
erhalten
Zeit
Zeit
20
HTTP: Dynamische Inhalte
 Senden von Information vom Browser zum Server
 in Rumpf von Anfragenachricht mit POST
 häufig: als Typ/Wert-Paare angehängt an die URL in einer
Anfragenachricht mit GET
 Dynamische Inhalte mit CGI-Skripten
 Common Gateway Interface (CGI) verarbeitet als externer Prozeß die
Information und liefert neue HTML-Seite an Server
User
Server
Browser
1
2
3
8
7
6
Rechnerkommunikation, Anwendungsschicht
1. User füllt Formular aus
CGI
2. mit HTTP an Server
Script Datenbank 3. wird CGI übergeben
4. CGI fragt DB
4
5. DB-Eintrag gefunden
6. CGI erstellt HTML
7. mit HTTP an User
5
8. HTML darstellen
21
HTTP: Dynamische Inhalte
 Dynamische Inhalte durch Scripting
 durch Interpretation von eingebetteten Skripten können dynamische
Inhalte erzeugt werden
 Server-seitiges Scripting: im HTML ist Code eingebettet, der vom
Server interpretiert wird und dabei HTML erzeugt, z.B. PHP
 Client-seitiges Scripting: im HTML ist Code eingebettet, der vom Client
interpretiert wird, z.B. JavaScript
Browser
User
Server
Browser
User
1
2
1
4
3
2
PHP-Modul
Rechnerkommunikation, Anwendungsschicht
Server
JavaScript
22
HTTP: Caching
 Web-Caching
 Verringerung der Wartezeit des Benutzers und des Netzwerkverkehrs
durch Zwischenspeicher
 Cache ist Server für Web-Browser und Client für Web-Server
 möglich an vielen Stellen: Browser, angeschlossenes LAN, ISP, …
Proxy
server
Client
Origin
server
Client
Origin
server
Rechnerkommunikation, Anwendungsschicht
23
HTTP: Caching
Server
Cache
 Cache kann bei Server
erfragen, ob sein Objekt
noch aktuell ist:
HTTP-Anfrage
If-modified-since:
<date>
Objekt
unverändert
HTTP-Antwort
HTTP/1.0
304 Not Modified
HTTP-Anfrage
If-modified-since:
<date>
Objekt
verändert
HTTP-Antwort
HTTP/1.0 200 OK
<data>
Rechnerkommunikation, Anwendungsschicht
24
HTTP: Caching
 Beispiel für Nutzen eines Caches
 Annahmen
- mittlere Objektgröße = 100.000 Bits
- mittlere Rate von HTTP-Anfragen der
Clients im LAN = 15/s
- Internetverzögerung zwischen LAN
und HTTP-Server = 2 s
 Folgen
- Auslastung des LANs
15/s ⋅ 100.000 Bits / 10 ⋅ 106 Bits/s
= 0,15 = 15 %
- Auslastung der Zugangsleitung
15/s ⋅ 100.000 Bits / 1,5 ⋅ 106 Bits/s
= 1 = 100 %
- Gesamtverzögerung = Verzögerung
im LAN + beim Zugang + im Internet
= ms + Minuten + 2 s = Minuten
Rechnerkommunikation, Anwendungsschicht
HTTPServer
Internet
1,5 Mbps
Zugangsleitung
10 Mbps LAN
25
HTTP: Caching
 1. Lösung: Upgrade des Zugangs
 Zugangsleitung mit 10 Mbps
 möglich, aber mit Kosten verbunden
 Folgen
- Auslastung des LANs = 15 %
- Auslastung der Zugangsleitung
15/s ⋅ 100.000 Bits / 10 ⋅ 106 Bits/s
= 0,15 = 15 %
- Gesamtverzögerung = Verzögerung
im LAN + beim Zugang + im Internet
= ms + ms + 2 s = Sekunden
Rechnerkommunikation, Anwendungsschicht
HTTPServer
Internet
10 Mbps
Zugangsleitung
10 Mbps LAN
26
HTTP: Caching
 2. Lösung: Verwendung eines
Caches
 Annahme: Cache-Hitrate ist 0,4
 realistisch: 40 % der abgefragten Seiten
befinden sich langfristig im Cache, 60%
müssen bei HTTP-Servern angefordert
werden
 Folgen
- Auslastung des LANs = 15 %
- Auslastung der Zugangsleitung
0,6 ⋅ 15/s ⋅ 100.000 Bits /
1,5 ⋅ 106 Bits/s = 0,6 = 60 %
- Gesamtverzögerung = Verzögerung
im LAN + beim Zugang + im Internet
= ms + ms + 0,6 ⋅ 2 s < 2 s
Rechnerkommunikation, Anwendungsschicht
HTTPServer
Internet
1,5 Mbps
Zugangsleitung
10 Mbps LAN
Cache
27
Anwendungsschicht
 Einführung
 Verbreitete Anwendungen








Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
E-Mail
Netzwerkmanagement
Domain Name System (DNS)
Content Distribution Networks
Real-Time Protocol (RTP)
Session Initiation Protocol (SIP)
 Socket-Programmierung
 Verteilte Systeme
 Peer-to-Peer-Systeme
Rechnerkommunikation, Anwendungsschicht
28
FTP
 File Transfer Protocol
 Übertragung von Dateien zwischen Hosts
 eine TCP-Verbindung (Port 21) zur Steuerung
 lesbare Kommandos: USER username, PASS password, LIST, RETR
filename, STOR filename, …
 jeweils eine TCP-Verbindung (Port 20) zur Übertragung einer Datei
 „out-of-band-control“
 mehr Einzelheiten in der Übung
FTP user
interface
FTP
client
User
Local file
system
Rechnerkommunikation, Anwendungsschicht
File transfer
FTP
server
FTP
server Remote file
system
29
E-Mail
 Simple Mail Transfer Protocol (SMTP)
 Nachrichten im ASCII-Format, Kopf, Rumpf
 andere Daten (Word-Dateien u.ä.) werden in ASCII umgewandelt
angehängt: multimedia mail extension (MIME)
 Versenden mit SMTP über TCP (lesbar)
 Abholen mit POP3, IMAP, HTTP (lesbar)
 mehr Einzelheiten in der Übung
Alice's
agent
SMTP
Bob's
Alice's
mail server SMTP mail server
Rechnerkommunikation, Anwendungsschicht
POP3,
IMAP,
HTTP
Bob's
agent
30
E-Mail: SMTP [RFC 821]
 nutzt TCP zur zuverlässigen Übertragung der Nachrichten vom Client
zum Server, dazu wird Port 25 verwendet.
 direkte Übertragung: vom sendenden Server zu empfangendem Server
 drei Phasen der Übertragung
 Handshaking (Begrüßung)
 Nachrichtenübertragung
 Abschlussphase
 Interaktion mittels Befehlen und Antworten
 Befehle: ASCII-Text
 Antworten: Statuscode und Text
 Nachrichten müssen 7-bit ASCII-Text sein
Rechnerkommunikation, Übung 2
31
Beispiel für einen SMTP-Dialog
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
Rechnerkommunikation, Übung 2
32
Anwendungsschicht
 Einführung
 Verbreitete Anwendungen








Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
E-Mail
Netzwerkmanagement
Domain Name System (DNS)
Content Distribution Networks
Real-Time Protocol (RTP)
Session Initiation Protocol (SIP)
 Socket-Programmierung
 Verteilte Systeme
 Peer-to-Peer-Systeme
Rechnerkommunikation, Anwendungsschicht
33
Netzwerkmanagement
 Aufgaben des Netzwerkmanagements
 Überwachung und Verwaltung eines Netzwerks = komplexes HW/SWGebilde (zahlreiche Geräte, Leitungen, Datenstrukturen, …)
 nach ISO 5 Einsatzbereiche
- Leistung: Monitoring von Auslastung, Durchsatz, Antwortzeiten,
Dokumentation (z.B. für die Überwachung von Service Level
Agreements), Reaktionsmaßnahmen
- Fehler: Monitoring, Dokumentation, Reaktionsmaßnahmen
- Konfiguration: Übersicht über Geräte und deren HW/SWKonfigurationen
- Zugang: Festlegung, Kontrolle, Dokumentation des Zugangs von
Benutzern und Geräten
- Sicherheit: Monitoring und Kontrolle des Zugangs,
Schlüsselverwaltung, z.B. Filterregeln für Firewalls,
Intrusion Detection
 diverse komplexe Standards, z.B. TMN, TINA
Rechnerkommunikation, Anwendungsschicht
34
Netzwerkmanagement
 Simple Network Management
Protocol (SNMP)
Agent
Managing
Data
entity
 einfach und verbreitet
 Managing Entity, Prozeß auf zentraler
Management Station, ≈ Client
Network
 Managed Device, Gerät im Netz
management
 Managed Object, HW oder SW im
protocol
Managed Device, z.B. Routing-Tabelle
 Management Agent, Prozeß auf Managed
Device, kann lokale Aktionen ausführen,
≈ Server
Agent
 Anfrage/Antwort-Protokoll zwischen
Management Entity und Management
Agent über UDP
Managed
Data
Managed
device
Agent Data
Managed
device
Agent
Data
Data
Managed
device
device
Rechnerkommunikation, Anwendungsschicht
35
Netzwerkmanagement
 SNMP Nachrichten (Version 2)




GET: Anfrage der Managing Entity einer Variable des Managed Objects
SET: Setzen der Variable eines Managed Objects durch Managing Entity
auch GET-NEXT and GET-BULK für Datenstrukturen
TRAP: Nachricht des Managing Agents über Fehlersituation
Get/set header
PDU
type
(0-3)
PDU
type
(4)
Variables to get/set
Request
ID
Error
Status
(0-5)
Error
Index
Enterprise
Agent
Addr
Trap
Type
(0-7)
Trap header
Rechnerkommunikation, Anwendungsschicht
Name
Value
…
Specific Time
Name
code stamp
Value
…
Name
Value
Trap information
36
Netzwerkmanagement
 Management Information Base (MIB)
 MIB-Module enthalten Datenstrukturen für die Managed Objects, von
der IETF genormt
 Syntax wird in Structure of Management Information (SMI) der IETF
festgelegt, die wiederum die Abstract Syntax Notation One (ASN.1) der
ISO benutzt (im wesentlichen wie C ohne Referenzen)
 ASN.1 besitzt auch ein Nummerierungsschema zur eindeutigen ObjektIdentifizierung, damit wird jedes MIB-Modul eindeutig bezeichnet
 mit den Bit Encoding Rules (BER) wird noch das genaue binäre Format
für die Übertragung festgelegt
Rechnerkommunikation, Anwendungsschicht
37
Netzwerkmanagement
 Nummerierung von ASN.1
ITU-T (0)
Standard (0)
ISO (1)
Joint ISO/ITU-T(2)
ISO member
body (2)
US
DoD (6)
ISO identified
organization (3)
Open Software
Foundation (22)
NATO
identified(57)
Internet (1)
directory management experimentalprivate security snmpv2
(4)
(1)
(2)
(3)
(5)
(6)
mail
(7)
MIB-2 (1)
system interface address
ip icmp tcp
(1)
(2) translation (4) (5)
(6)
(3)
Rechnerkommunikation, Anwendungsschicht
udp egp
(7) (8)
cmot transmission snmp
(9)
(10)
(11)
rmon
(16)
38
Netzwerkmanagement
 MIB-Modul für UDP
Object Identifier
Name
Type
Description (from RFC 2013)
1.3.6.1.2.1.7.1
udpInDatagrams
Counter32
“total number of UDP datagrams delivered to UDP
users“
1.3.6.1.2.1.7.2
udpNoPorts
Counter32
“total number of received UDP datagrams for which
there was no application at the destination port“
1.3.6.1.2.1.7.3
udpInErrors
Counter32
“number of received UDP datagrams that could not
be delivered for reasons other than the lack of an
application at the destination port“
1.3.6.1.2.1.7.4
udpOutDatagrams
Counter32
“total number of UDP datagrams sent from this
entity“
1.3.6.1.2.1.7.5
udpTable
SEQUENCE of
UdpEntry
“a sequence of UdpEntry objects, one for each port
that is currently open by an application, giving the IP
address and the port number used by application“
Rechnerkommunikation, Anwendungsschicht
39
Netzwerkmanagement
 Basic Encoding Rules (BER)
 Repräsentation zur Übertragung
 Tag, Length, Value (TLV)
- Tag = Nummer für Typ
- Length = Länge in Bytes
 Übertragung von „smith“
- Tag 4 für OCTET STRING
- Length 5
- ASCII-Werte der Zeichen
 Übertragung von 282
- Tag 2 für INTEGER
- Length 2
- 0x011a (hexadezimal),
höherwertiges Byte zuerst
(„Big Endian“)
lastname ::= OCTET STRING
weight ::= INTEGER
Module of data type
declarations written
in ASN.1
{weight, 282}
{lastname, “smith“}
Instances of data type
specified in module
Basic Encoding Rules
(BER)
1a
01
02
02
'h'
Transmitted
byte stream
't'
'i'
'm'
's'
05
04
Rechnerkommunikation, Anwendungsschicht
40
Anwendungsschicht
 Einführung
 Verbreitete Anwendungen








Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
E-Mail
Netzwerkmanagement
Domain Name System (DNS)
Content Distribution Networks
Real-Time Protocol (RTP)
Session Initiation Protocol (SIP)
 Socket-Programmierung
 Verteilte Systeme
 Peer-to-Peer-Systeme
Rechnerkommunikation, Anwendungsschicht
41
DNS
 Domain Name System (DNS)
Host-Namen bzw. Domain-Namen lesbar
DNS bildet Domain-Namen auf Werte ab
diese Werte sind u.a. IP-Adressen
DNS ist verteilte Datenbank, besteht aus vielen Namen-Servern, die
über ein Anwendungsprotokoll kommunizieren
 eine wesentliche Aufgabe, um die Infrastruktur zu nutzen
 z.B. Namens-Auflösung beim Versenden einer e-mail:




2
cs.princeton.edu
Name
server
User
1
user @ cs.princeton.edu
Mail
program
192.12.69.5
3
Rechnerkommunikation, Anwendungsschicht
192.12.69.5
4
TCP
42
DNS
 Domain-Struktur




DNS implementiert hierarchischen Namensraum für Internet-Objekte
von links nach rechts lesen, von rechts nach links verarbeiten
eine Zone wird von einem Name-Server verwaltet
die Hierarchie wird durch die Namen-Server implementiert
edu
princeton … mit
cs
ee
com
gov
cisco … yahoo nasa … nsf
mil
org
arpa … navy
acm … ieee
net
de
eu
physics
ux01 ux04
Rechnerkommunikation, Anwendungsschicht
43
DNS
Root
name server
 Hierarchie von Name-Servern
 Root Name Server
einige wenige
 Top-level Domain-Server
für com, org, net, edu, uk, de, eu, …
 …
 autoritativer Name-Server
unterste Ebene, für
einzelne Organisation
Princeton
name server
CS
name server
…
…
Cisco
name server
EE
name server
 Root Name Server
Stand 2004:
Rechnerkommunikation, Anwendungsschicht
44
DNS: Resource Records
 Resource Records
 Datensätze der Namenserver (Domainname, Wert, Typ, TTL)
 TTL: Time to Live, Dauer der Gültigkeit
 Typ = A
- Wert = IP-Adresse
- Bsp.: (ns.cisco.com, 128.96.32.20, A, TTL)
 Typ = NS
- Wert = Domainname eines Hosts, auf dem ein Namen-Server läuft,
der Namen in der Domain auflösen kann
- Bsp.: (princeton.edu, cit.princeton.edu, NS, TTL)
 Typ = CNAME (Canonical Name)
- Wert = kanonischer Name eines Hosts, ermöglicht Aliasnamen
- Bsp.: (cic.cs.princeton.edu, cicada.cs.princeton.edu, CNAME, TTL)
 Typ = MX (Mail Exchange)
- Wert = Domain-Name des Hosts, auf dem Mail-Server läuft
- Bsp.: (cs.princeton.edu, optima.cs.princeton.edu, MX, TTL)
Rechnerkommunikation, Anwendungsschicht
45
DNS: Resource Records
 Bsp: Resource Records
 Root Name Server
(princeton.edu, cit.princeton.edu, NS, TTL)
(cit.princeton.edu, 128.196.128.233, A, TTL)
(cisco.com, ns.cisco.com, NS, TTL)
(ns.cisco.com, 128.96.32.20, A, TTL)
…
 enthält einen NS-Datensatz für jeden Server der nächsten Ebene und
einen A-Datensatz mit der IP-Adresse
 diese bilden zusammen einen Verweis auf die Server der zweiten Ebene
Rechnerkommunikation, Anwendungsschicht
46
DNS: Resource Records
 Server von princeton.edu
(cs.princeton.edu, optima.cs.princeton.edu, NS, TTL)
(optima.cs.princeton.edu, 192.12.69.5, A, TTL)
(ee.princeton.edu, helios.ee.princeton.edu, NS, TTL)
(helios.ee.princeton.edu, 128.196.28.166, A, TTL)
(jupiter.physics.princeton.edu, 128.196.4.1, A, TTL)
(saturn.physics.princeton.edu, 128.196.4.2, A, TTL)
(mars.physics.princeton.edu, 128.196.4.3, A, TTL)
(venus.physics.princeton.edu, 128.196.4.4, A, TTL)
 einige Datensätze sind Verweise auf die dritte Ebene, einige lösen die
IP-Adressen direkt auf
Rechnerkommunikation, Anwendungsschicht
47
DNS: Resource Records
 Server der Domain cs.princeton.edu
(optima.cs.princeton.edu, 192.12.69.5, A, TTL)
(cheltenham.cs.princeton.edu, 192.12.69.60, A, TTL)
(baskerville.cs.princeton.edu, 192.12.69.35, A, TTL)
(che.cs.princeton.edu, cheltenham.cs.princeton.edu, CNAME, TTL)
(opt.cs.princeton.edu, optima.cs.princeton.edu, CNAME, TTL)
(bas.cs.princeton.edu, baskerville.cs.princeton.edu, CNAME, TTL)
(www.cs.princeton.edu, optima.cs.princeton.edu, CNAME, TTL)
(cs.princeton.edu, optima.cs.princeton.edu, MX, TTL)
 enthält A-Datensätze für alle Hosts
 Aliasnamen: praktischere Namen, erlaubt Flexibilität, z.B. für WebServer
 MX-Datensätze: gleicher Zweck speziell für Mail-Server
Rechnerkommunikation, Anwendungsschicht
48
DNS: Protokoll
 DNS-Protokoll
 Anfrage- und Antwortnachrichten,
gleiches Format:
 Kopf
- Identification: Zuordnung
Anfrage, Antwort
- Flags: Art der Anfrage bzw.
Antwort
 Rumpf
- Questions: Domainnamen
- Answers: Resource Records
- Authority: Antworten von
autoritativen Servern
Rechnerkommunikation, Anwendungsschicht
Identification
Flags
Number of questions
Number of answers RRs
Number of authority RRs Number of additional RRs
Questions
(variable number of questions)
Answers
(variable number of resource records)
Authority
(variable number of resource records)
Additional information
(variable number of resource records)
49
DNS: Protokoll
 Anfragearten
 iterativ
- Antwort: anderer Server, der Namen evtl. auflösen kann
(oder keine Antwort)
- NS- und A-Datensatz
- Antwort wird sofort geliefert, es muß keine Information gespeichert
werden, gut für hochfrequentierte Server
 rekursiv
- Antwort: Auflösung des Namens, die u.U. von anderen Servern
geholt wird
- A-Datensatz
- bei Anfrage an einen anderen Server muß die Information
gespeichert werden
Rechnerkommunikation, Anwendungsschicht
50
DNS: Protokoll
root DNS server
 Beispiel für iterative Anfrage:
2
3
4
TLD DNS server
5
local DNS server
dns.poly.edu
1
8
requesting host
7
6
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu
Rechnerkommunikation, Anwendungsschicht
51
DNS: Protokoll
root DNS server
 Beispiel für rekursive Anfrage:
2
3
7
6
TLD DNS server
local DNS server
dns.poly.edu
1
5
4
8
requesting host
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu
Rechnerkommunikation, Anwendungsschicht
52
DNS: Protokoll
root name server
 Kombination aus rekursiver
und iterativer Anfrage:
2
iterated query
3
4
7
local name server
dns.eurecom.fr
1
8
requesting host
intermediate name server
dns.umass.edu
5
6
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
Rechnerkommunikation, Anwendungsschicht
53
Anwendungsschicht
 Einführung
 Verbreitete Anwendungen








Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
E-Mail
Netzwerkmanagement
Domain Name System (DNS)
Content Distribution Networks
Real-Time Protocol (RTP)
Session Initiation Protocol (SIP)
 Socket-Programmierung
 Verteilte Systeme
 Peer-to-Peer-Systeme
Rechnerkommunikation, Anwendungsschicht
54
Content Distribution Networks
Origin server
in North America
 Content Distribution Networks
(CDNs)
 Ziel: Vermeiden längerer
Wartezeiten beim Laden von WebSeiten, z.B. bei Flash-Crowds
(Millionen Benutzer greifen auf eine
Seite zu)
 3 Engpässe: erste Meile, letzte Meile,
Peering-Punkte (Übergänge
zwischen ISPs)
 Idee: sehr viele (Hunderte) SpiegelServer geografisch verteilen (diese
sind wie Web-Caches, der Inhalt
wird aber proaktiv auf sie repliziert)
 bekannte CDNs: Akamai, Digital
Island
Rechnerkommunikation, Anwendungsschicht
CDN distribution
node
CDN server
in South America
CDN server
in Asia
CDN server
in Europe
55
Content Distribution Networks
 Verteilung der Anfragen
 Server-basierte HTTP Redirection: Server liefert aufgrund der IPAdresse des Clients einen geeigneten anderen Server, erfordert
zusätzliche RTT, Gefahr der Überlast für Server
 Client-nahe HTTP-Redirection: z.B. durch Web-Proxy, schwieriger zu
verwirklichen
 DNS-basierte Redirection: DNS-Server bildet den Domain-Namen des
Servers auf die IP-Adresse eines geeigneten Servers ab
 URL-Rewriting: Server liefert Basisseite, die URLs der eingebetteten
Objekte werden umgeschrieben, mit dem Domain-Namen eines
geeigneten anderen Servers
 kommerzielle CDNs verwenden meist Kombination aus DNS-basierter
Redirection und URL-Rewriting
Rechnerkommunikation, Anwendungsschicht
56
Content Distribution Networks
 Bsp. für URL-Rewriting
 www.foo.com ist Content-Provider, Video-Dateien werden auf den
CDN-Servern von cdn.com verteilt
 1. HTTP-Anfrage für HTML-Basisseite, Antwort enthält eingebettete
Video-Datei www.cdn.com/www.foo.com/sports/ruth.mpg
 2. DNS-Anfrage für IP-Adresse von www.cdn.com, DNS-Server liefert
aufgrund der IP-Adresse des Clients und einer internen Tabelle die IPAdresse eines geeigneten Servers
 3. HTTP-Anfrage an diesen Server
Origin server
1
DNS query for
2
3
Rechnerkommunikation, Anwendungsschicht
www.cdn.com
CDN‘s authoritative
DNS server
57
Anwendungsschicht
 Einführung
 Verbreitete Anwendungen








Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
E-Mail
Netzwerkmanagement
Domain Name System (DNS)
Content Distribution Networks
Real-Time Protocol (RTP)
Session Initiation Protocol (SIP)
 Socket-Programmierung
 Verteilte Systeme
 Peer-to-Peer-Systeme
Rechnerkommunikation, Anwendungsschicht
58
Real-Time Protocol
 Multimediaanwendungen
 Multimedia = Daten, Bilder, Sprache, Audio, Video
 grundsätzliche Probleme bei Audio + Video
- Verzögerung durch Verarbeitung (z.B. Kompression) und Laufzeit
beschränkt Interaktivität
- Variabilität der Verzögerung (Jitter) erschwert kontinuierliche
Wiedergabe
- Verluste verschlechtern Qualität
- ggfs. geringe Bitrate beschränkt Auflösung (insbes. Video)
 Lösungsansätze
- Streaming: Wiedergabepuffer, um Schwankungen des Netzes
auszugleichen, möglich in „Best-Effort“-Netzen
- Dienstgütemechanismen wie z.B. Reservierung und Priorisierung
Rechnerkommunikation, Anwendungsschicht
59
Real-Time Protocol
 Streaming
 Sender erzeugt Pakete kontinuierlich (d.h. periodisch) und versendet
sie mit Sequenznummer und Zeitstempel
 die Pakete werden durch das Netz wegen dynamischer Lastsituationen
unterschiedlich verzögert
 Prefetching: beim Empfänger Zwischenspeicherung in
Wiedergabepuffer
 Zeitstempel ermöglicht kontinuierliche (d.h. periodische) Wiedergabe
nach einer Verzögerung
Rechnerkommunikation, Anwendungsschicht
60
Real-Time Protocol
 Real-Time Transport Protocol (RTP, RFC 3550)
 verbreitetes Anwendungsprotokoll für den Transport von
Multimediadaten
 üblicherweise über UDP
 unterstützt Codec-Identifikation, Sequenznummern, Zeitstempel,
Sitzungsidentifikation
 aber nicht Pufferung, Fehlerkontrolle, Zeitsynchronisation auf
Endsystemen oder Reservierung, Priorisierung im Netz
 auch keine Bestätigungen und kein Sitzungsaufbau
 Philosophie: Bereitstellung einheitlicher Funktionalität für
Multimediaanwendungen, überläßt möglichst viel der Anwendung,
kurzer Kopf für Effizienz
 Erweiterung durch Profile und Formate für Anwendungsklassen
 Sender kann mehrere Medienströme versenden, z.B. Video und
Sprache
 Unterstützung von Multicast
Rechnerkommunikation, Anwendungsschicht
61
Real-Time Protocol
 RTP-Kopf
 Version (V, 2 Bits),
gegenwärtig 2
 Paddingbit (P), Länge in UDPKopf, letztes Byte enthält
Anzahl von Auffüllbytes
 Extensionbit (X), Anzeige eines
Erweiterungs-Kopfes
 CSRC Count (CC), Anzahl
CSRC-Felder, normalerweise 0
 Markerbit (M), spezielle
Kennzeichnung gemäß Profil
0
8
V P X
CC
M
 Payload Type (7 Bits) für CodecIdentifikation
 Sequenznummern (16 Bits),
zufälliger initialer Wert,
inkrementiert pro Paket
 Zeitstempel (32 Bits), zufälliger
initialer Wert, Einheit (Tick) Codecabhängig (Profil)
 SSRC (32 Bits), Identifikation der
Synchronisationsquelle
 CSRC (32 Bits), Identifikation
mehrer beitragender Quellen
16
Payload Type
31
Sequence Number
Time Stamp
SSRC Identifier
CSRC Identifier
Rechnerkommunikation, Anwendungsschicht
62
SIP
Alice
 Session Initiation Protocol
(SIP)
 Initialisierung einer Sitzung
über IP-Netz, z.B. für Sprache
 Anfrage/Antwort-Modell ähnlich
wie HTTP, aber über UDP
 Bsp.: Aufbau einer Verbindung
bei bekannter IP-Adresse
(vereinfacht)
 Aushandeln von
Kodierungsverfahren mit
Session Description Protocol
(SDP), hier unterschiedlich in
beide Richtungen
 die Medienströme werden dann
unabhängig über RTP
transportiert
Rechnerkommunikation, Anwendungsschicht
Bob
193.64.210.89
167.180.112.24
Bob‘s
terminal
rings
µ Law audio
port 38060
GSM
port 48753
Time
Time
63
SIP
SIP registrar
upenn.edu
 Lokalisieren von Benutzern
 Infrastruktur aus verschiedenen Servern
 [email protected] möchte mit
[email protected] telefonieren, kennt
aktuelle IP-Adresse nicht
- 1. INVITE [email protected] an
Proxy-Server umass.edu senden
- 2. umass.edu fragt Registrar
upenn.edu, wo Keith gerade ist
- 3. bei upenn.edu ist Keith nicht, aber
vielleicht bei eurecom.fr
- 4. Frage an eurecom.fr
- 5. eurecom.fr schickt INVITE an
Host, auf dem sich Keith gerade
befindet
- 6.-8. OK über Registrar, Proxy zurück
- 9. Medienstrom direkt zwischen
Hosts
 1.-8. entspricht Signalisierung im
Telefonnetz
Rechnerkommunikation, Anwendungsschicht
2
SIP proxy
umass.edu
SIP registrar
eurcom.fr
3
4
7
1
6
8
5
9
SIP client
217.123.56.89
SIP client
197.87.54.21
64
Anwendungsschicht
 Einführung
 Verbreitete Anwendungen








Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
E-Mail
Netzwerkmanagement
Domain Name System (DNS)
Content Distribution Networks
Real-Time Protocol (RTP)
Session Initiation Protocol (SIP)
 Socket-Programmierung
 Verteilte Systeme
 Peer-to-Peer-Systeme
Rechnerkommunikation, Anwendungsschicht
65
Socket-Programmierung
 Socket-Schnittstelle





verbreitetes API für Transportdienste
Festlegung von TCP/UDP, IP-Adressen, Portnummern
im folgenden Java-Programm mit TCP (UDP in Übung)
Java erlaubt flexible Nutzung der Strom-Abstraktion
Architektur:
Kontrolle durch
Anwendungsprogramm
Kontrolle durch
Betriebssystem
Prozeß
Prozeß
Socket
Socket
TCP mit
Puffern,
Variablen
Host oder
Server
Rechnerkommunikation, Anwendungsschicht
Internet
TCP mit
Puffern,
Variablen
Kontrolle durch
Anwendungsprogramm
Kontrolle durch
Betriebssystem
Host oder
Server
66
Socket-Programmierung
 Beispiel für einfache
Client-Server-Anwendung
Rechnerkommunikation, Anwendungsschicht
inFromUser
Bildschirm
ClientProzeß
Ausgabestrom
inFromServer
Eingabestrom
outToServer
 Client liest Zeile aus
Standardeingabe (inFromUser
stream) und sendet ihn über
ein TCP-Socket zum Server
 Server liest Zeile aus TCPSocket
 Server konvertiert in
Großbuchstaben (seine
Dienstleistung) und sendet
diese Zeichenkette über TCPSocket zurück an Client
 Client liest Zeichenkette aus
TCP-Socket und gibt diese auf
Standardausgabe aus
Tastatur
clientSocket
zur
Transportschicht
Eingabestrom
TCP-Socket
von der
Transportschicht
67
Socket-Programmierung: Übersicht
Server-Prozeß auf hostid
Client-Prozeß
erzeuge Socket für
eingehende Verbindungswünsche an Port x:
welcomeSocket =
ServerSocket(x)
TCP-
warte auf Verbindungswünsche: Verbindungsaufbau
connectionSocket =
welcomeSocket.accept()
schreibe Zeile in
clientSocket
lese Zeile aus
connectionSocket
schreibe Antwort in
connectionSocket
schließe
connectionSocket
erzeuge Socket,
Verbindung zu hostid, port=x
clientSocket =
new Socket(hostid, x)
lese Antwort aus
clientSocket
TCPVerbindungsabbau
Rechnerkommunikation, Anwendungsschicht
schließe
clientSocket
68
Socket-Programmierung: Client
import java.io.*;
import java.net.*;
class TCPClient {
erzeuge
Eingabestrom für
Standardeingabe
erzeuge
Clientsocket,
verbinde mit Server
erzeuge
Ausgabestrom
für Socket
public static void main(String argv[]) throws Exception
{
String sentence;
String modifiedSentence;
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket("hostname", 6789);
DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());
Rechnerkommunikation, Anwendungsschicht
69
Socket-Programmierung: Client
erzeuge
Eingabestrom
für Socket
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
sentence = inFromUser.readLine();
schreibe Zeile in Socket,
wird zu Server gesendet
outToServer.writeBytes(sentence + '\n');
modifiedSentence = inFromServer.readLine();
lese Zeile aus Socket,
wurde von Server
gesendet
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
Rechnerkommunikation, Anwendungsschicht
70
Socket-Programmierung: Server
import java.io.*;
import java.net.*;
class TCPServer {
erzeuge
WelcomeSocket
für Port 6789
blockiert,
erzeuge Socket bei
Verbindungswunsch
von Client
erzeuge
Eingabestrom
für Socket
public static void main(String argv[]) throws Exception
{
String clientSentence;
String capitalizedSentence;
ServerSocket welcomeSocket = new ServerSocket(6789);
while(true) {
Socket connectionSocket = welcomeSocket.accept();
BufferedReader inFromClient =
new BufferedReader(new
InputStreamReader(connectionSocket.getInputStream()));
Rechnerkommunikation, Anwendungsschicht
71
Socket-Programmierung: Server
erzeuge
Ausgabestrom
für Socket
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
lese Zeile aus Socket,
wurde von Client
gesendet
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + '\n';
schreibe Zeile
in Socket,
wird zu Client
gesendet
}
}
}
outToClient.writeBytes(capitalizedSentence);
Ende der While-Schleife,
zurück und Warten auf neue TCP-Verbindung
Rechnerkommunikation, Anwendungsschicht
72
Anwendungsschicht
 Einführung
 Verbreitete Anwendungen








Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
E-Mail
Netzwerkmanagement
Domain Name System (DNS)
Content Distribution Networks
Real-Time Protocol (RTP)
Session Initiation Protocol (SIP)
 Socket-Programmierung
 Verteilte Systeme
 Peer-to-Peer-Systeme
Rechnerkommunikation, Anwendungsschicht
73
Verteilte Systeme
 Verteiltes System
 besteht aus mehreren unabhängigen Systemen, die wie ein einzelnes
kohärentes System erscheinen
 wird oft durch Middleware realisiert, eine verteilte Software-Schicht, die
zwischen Betriebssystem und den Anwendungen angeordnet ist
Endsystem A
Endsystem B
verteilte Anwendung
Endsystem C
Anwendung
Verteilte Systemschicht (Middleware)
Netzdienste
des BS
Netzdienste
des BS
Netzdienste
des BS
Betriebssystem
Betriebssystem
Betriebssystem
Netz
Rechnerkommunikation, Anwendungsschicht
74
Verteilte Systeme
 Remote Procedure Call (RPC)
 verteilte Systeme können durch expliziten Nachrichtenaustausch
zwischen Prozessen über Sockets realisiert werden
 im Prozedurfernaufruf (Remote Procedure Call, RPC) werden
Prozeduren auf entfernten Rechnern aufgerufen
 in der Programmiersprache sieht dies wie ein herkömmlicher
Prozeduraufruf auf einem einzelnen Rechner aus
 der RPC wird vor dem Benutzer verdeckt in Primitive des
Betriebssystems umgewandelt, z.B. mit Sockets
 Transparenz, bietet bequeme Möglichkeit zur Abstraktion
 RPC verbreiteter Ansatz zur Realisierung verteilter Anwendungen
Rechnerkommunikation, Anwendungsschicht
75
Verteilte Systeme
 Realisierung eines RPCs
 RPC wird durch Client Stub und Server Stub realisiert (Stub = Stumpf)
 Client-Prozess legt Parameter auf Stack
 Client Stub wandelt sie in Nachricht um (Marshalling) und sendet sie
zum Server-Stub
 Server-Stub ruft Prozedur in Server-Prozess auf und sendet Ergebnis in
Nachricht zurück (benötigt Kopie des Inhalts, nicht Zeiger)
 Server-Stub schreibt Ergebnis auf Stapel und ggfs. in andere
Speicherbereiche
Warten auf Ergebnis
Client
Aufruf der
Prozedur
Anfrage
Server
Rückkehr
vom Aufruf
Antwort
Aufruf einer lokalen
Zeit
Prozedur und Rückgabe
der Ergebnisse
Rechnerkommunikation, Anwendungsschicht
76
Verteilte Systeme
 Bsp.: RPC add(i,j)
Client-Computer
Server-Computer
Client-Prozess
Server-Prozess
1. Client-Aufruf
der Prozedur
Implementierung
von add
Server-Stub
Client-Stub
k = add(i,j)
proc:“add“
int: val(i)
int: val(j)
2. Stub erstellt
Nachricht
Betriebssystem des Clients
proc: “add“
int: val(i)
int: val(j)
k = add(i,j)
proc:“add“
int: val(i)
int: val(j)
6. Stub führt einen
lokalen Aufruf
von „add“ aus
5. Stub entpackt
Nachricht
4. Das Betriebssystem
des Servers leitet
Betriebssystem des Servers
die Nachricht zum
Server-Stub weiter
3. Die Nachricht wird über
das Netzwerk gesendet
Rechnerkommunikation, Anwendungsschicht
77
Verteilte Systeme
 Verteilte Objekte
 Objekte auf verschiedenen Rechnern bieten Dienste an
 Remote Method Invocation (RMI): wie RPC, für Methoden der Objekte
 wird durch Vertreter der Objekte realisiert, die die Kommunikation über
Primitiven des Betriebssystems ausführen
Client
Client
Server
gleiche
Schnittstelle
wie Objekt
Client ruft
Methode auf
Proxy
BS des Clients
Netz
Rechnerkommunikation, Anwendungsschicht
Skeleton
ruft Methode
von Objekt
auf
Server
Objekt
Zustand
Methode
Skeleton
Schnittstelle
BS des Servers
„Marshallisierter“ Aufruf wird
übertragen
78
Verteilte Systeme
 Mechanismen von Middleware-Systemen
 Kommunikation
- Verdecken der „Low-Level“-Mechanismen des Netzwerks
- Marshalling, Unmarshalling (Kodierung und Dekodierung der
gesendeten Daten)
- Heterogenität von Plattformen und Sprachen
 Prozesse: Threads, Migration, Agenten
 Namensdienste: Namen für Objekte, Look-Up-Dienste
 Uhrensynchronisation
 Replikation von Daten und Konsistenzerhaltung
 Fehlertoleranz
 Sicherheit
 Probleme von Middleware-Systemen
 Komplexität, Performance-Overhead, Sicherheitsprobleme
Rechnerkommunikation, Anwendungsschicht
79
Verteilte Systeme
 Einige Middleware- und RPC-Systeme
 Common Object Request Broker Architecture (CORBA)
- durch Object Management Group (OMG) standardisiert, nichtkommerzielle Organisation mit über 800 Mitgliedern, www.omg.org
- Object Request Broker (ORB) ermöglicht Interaktion von
Anwendungen in verschiedenen Programmiersprachen
 Java 2 Platform Enterprise Edition (J2EE)
- offener Standard (Java Community Process)
- nur für Java (weniger Overhead als bei CORBA), verwendet Java RMI
- verwendet Komponenten: komplexe Objekte (Enterprise Java Beans)
 .NET
- für Microsoft Plattformen, Component Object Model (COM, DCOM)
 Web Services
- Anbieten von Diensten über XML-basierte Internet-Protokolle
- WSDL (Web Service Description Language, W3C), SOAP (Middleware
Protokoll, W3C), UDDI (Universal Description, Discovery, and
Integration, OASIS)
Rechnerkommunikation, Anwendungsschicht
80
Verteilte Systeme: Remote Method Invocation (RMI)
 Komponenten
RMI-Registry
 Remote Interface
2
1
Naming.rebind()
Naming.lookup()
- beschreibt die Funktionen,
die auf dem Server zur
Server
Client
Verfügung stehen
3 Funktionsaufruf mit
- definiert damit das Verhalten
Funktionsparametern
Remote
Remote
des entfernten Objekts
Object
Interface
 Remote Object
Rückgabewert
4 oder Exception
- stellt das entfernte Objekt dar
- liegt auf dem Server
- implementiert das Remote Interface und das Verhalten der für die
Clients zur Verfügung stehenden entfernten Methoden
 Remote Reference
- Referenz auf Remote Object
- bekommen die Clients von der RMI Registry
Rechnerkommunikation, Anwendungsschicht
81
Verteilte Systeme: Remote Method Invocation (RMI)
 Ablauf
RMI-Registry

2
1 Der Server registriert ein Remote
1
Naming.lookup()
Naming.rebind()
Object bei der RMI-Registry unter
einem eindeutigen Namen.
Server
Client
2 Der Client schaut bei der RMI
Registry unter diesem Namen nach
3 Funktionsaufruf mit
Funktionsparametern
Remote
Remote
und bekommt eine Objektreferenz,
Object
Interface
die seinem Remote Interface
Rückgabewert
4 oder Exception
entsprechen muss.

3 Der Client ruft eine Methode aus der
Objektreferenz auf
4 Der Server gibt dem Client die Rückgabewerte

dieses Aufrufs, oder der Client bekommt eine
Fehlermeldung (z. B. bei einem Verbindungsabbruch).
Rechnerkommunikation, Anwendungsschicht
82
Verteilte Systeme: Remote Method Invocation (RMI)
 Remote Interface
Definition der
angebotenen
Methode
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface Converter extends Remote {
public String toUpperCase(String toConvert)
throws RemoteException;
}
 Remote Object
Implementierung der angebotenen Methode
public class ConverterImpl implements Converter {
public String toUpperCase(String toConvert) {
return toConvert.toUpperCase();
}
}
Rechnerkommunikation, Anwendungsschicht
83
Verteilte Systeme: Remote Method Invocation (RMI)
 Server
Erzeugen des
Objekts
Exportieren des
Objekts, vgl.
ServerSocket
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.rmi.server.UnicastRemoteObject;
public class Server {
public static void main(String args[]) throws Exception {
ConverterImpl obj = new ConverterImpl();
Converter stub = (Converter)
UnicastRemoteObject.exportObject(obj, 0);
// Bind the remote object's stub in the registry
Registry registry = LocateRegistry.getRegistry();
registry.bind("MyConverter", stub);
Bekanntmachen
des Objekts in
der Registry
1
System.err.println("Server ready");
}
}
Rechnerkommunikation, Anwendungsschicht
84
Verteilte Systeme: Remote Method Invocation (RMI)
 Client
Laden der
Registry
import
import
import
import
java.io.BufferedReader;
java.io.InputStreamReader;
java.rmi.registry.LocateRegistry;
java.rmi.registry.Registry;
public class Client {
public static void main(String[] args) throws Exception {
String sentence;
String modifiedSentence;
Registry reg = LocateRegistry.getRegistry(„hostname");
Converter stub = (Converter) reg.lookup("MyConverter");
Client bekommt 2
Remote Reference
Rechnerkommunikation, Anwendungsschicht
85
Verteilte Systeme: Remote Method Invocation (RMI)
Einlesen der
Benutzereingabe
BufferedReader inFromUser = new BufferedReader(
new InputStreamReader(System.in));
sentence = inFromUser.readLine();
Aufruf am 3 4
RemoteObject
modifiedSentence = stub.toUpperCase(sentence);
Ausgabe des
Ergebnisses
System.out.println("FROM SERVER: " + modifiedSentence);
}
}
Rechnerkommunikation, Anwendungsschicht
86
Verteilte Systeme: Web Services
 Überblick
 Software-Anwendung, die mit URL identifizierbar ist und deren
Schnittstelle über XML beschrieben, gefunden, und benutzt wird
 Analogie: Web Services ist für Computer ähnlich zu Webseiten für
Menschen
 Bsp.:
Kombination
einzelner Dienst
einzelner Dienst
Temperatur
Info Service
Neuer Web Service (Reise Info Service):
Ein Service, der einem mit dem Flugzeug
erreichbare Reiseziele, nach Entfernungen
geordnet, zusammen mit der aktuellen
Temperatur auflistet.
Flug Info
Service
Karten Info
Service
einzelner Dienst
Rechnerkommunikation, Anwendungsschicht
87
Verteilte Systeme: Web Services
 XML Basistechnologien
 SOAP (Simple Object Access Protocol)
- dient zur Kommunikation zwischen den Services
- arbeitet mit jedem Betriebssystem auf jeder Plattform
 UDDI (Universal Description, Discovery and Integration)
- Industrieinitiative
- dient zur Suche und Registrierung von Services (weltweit eindeutig)
- ist vergleichbar mit einem Telefonbuch (Gelbe Seiten)
- Dienstanbieter registrieren Informationen zu ihren Services mit UDDI
 WSDL (Web Services Description Language)
- dient zur Beschreibung
Beschreibung
WSDL
der angebotenen Dienste
Nachrichtenformat
SOAP
UDDI
HTTP, SMTP
Transport
TCP/IP, RMI …
Rechnerkommunikation, Anwendungsschicht
Verwaltung
88
Verteilte Systeme: Web Services
 Zusammenhang / Rollen
 Web Service Provider
1- beschreibt die Schnittstelle mittels WSDL
2- registriert seinen Dienst bei der UDDI Registry
 Web Service Requestor (Applikation)
3- macht den Service ausfindig, indem er mit der UDDI Registry Kontakt
aufnimmt, und erhält Informationen, wo er das WSDL-Dokument des
Service findet
4- wertet die Informationen (u.a. XML-Schema für Anfrage) aus und
generiert eine SOAP-Nachricht
5- bezieht die passenden Informationen vom Service Provider
WSDL 
SOAP
4
Suchen
UDDI
Web Service
Requestor
3
UDDI
Registry
Registrieren 2
UDDI
Aufruf SOAP
Web Service
Provider
5
Rechnerkommunikation, Anwendungsschicht
1
WSDL
Interface
89
Verteilte Systeme: Web Services, SOAP
Firewall
 Eigenschaften
 Mit SOAP können Web Services
miteinander kommunizieren, auch
wenn sie hinter einer Firewall sind.
 SOAP Nachrichten haben eine sehr
einfache Struktur
 Der SOAP-Envelope besteht aus einem
Header und einem Body
SOAP
Server
Server
Internet
SOAP
SOAP
Server
 Die für den Empfänger gedachten Informationen (z.B. RPCInformationen, XML messages oder Error messages) stehen im Body
 Der Header kann zusätzliche Informationen zur SOAP Nachricht
enthalten, z.B. Digitale Signatur, Transactions- und RoutingInformationen
Rechnerkommunikation, Anwendungsschicht
90
Verteilte Systeme: Web Services, SOAP
<?xml version = “1.0“?>
<soap:Envelope xmlns:soap=“http://schemas.xmlsoap.org/soap/envelope/“>
<soap:Header>
<!-- Optionale Headerinformationen -->
<To>Wetter Info Service</To>
<From>Reise Info Service</From>
Inhalt ist nicht spezifiziert;
</soap:Header>
er wird von der Anwendung
festgelegt!
<soap:Body>
 <soap:Envelope
<!-- Eigentliche Nachricht -->
xmlns:soap=“http://schemas.xmlsoap.org/soap/envelope/“
Schicke mir die aktuelle Temperatur in Rom
></soap:Body>
</soap:Envelope>
Rechnerkommunikation, Anwendungsschicht
91
Verteilte Systeme: Web Services, UDDI
 White Pages
 Namensregister, sortiert nach Namen
 Auflistung der Anbieter mit allen Detailangaben
 Kontaktinformationen (Telefon, Telefax,...)
 Yellow Pages




Branchenverzeichnis
spezifische Suche gemäß verschiedener Taxonomien (Ort, Dienstart,...)
verweist auf White Pages
klassifiziert die Services anhand internationaler Standards wie UNSPEC
 Green Pages
 Informationen über das Geschäftsmodell des Unternehmens
 technische Details zu den angebotenen Web Services
 Auskunft über Geschäftsprozesse
Rechnerkommunikation, Anwendungsschicht
92
Verteilte Systeme: Web Services, UDDI
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<find_business xmlns="urn:uddi-org:api_v2" generic="2.0">
<categoryBag>
Interesse: Software-Industrie
<keyedReference keyValue="51121"
tModelKey="uuid:c0b9fe13-179f-413d-8a5b5004db8e5bb2" />
</categoryBag>
</find_business>
Referenzspezifikation:
</soap:Body>
Wie arbeitet der Webservice?
</soap:Envelope>
Diese Informationen muss der Benutzer kennen.
Es wird z.B. ein Web User Interface angeboten.
Rechnerkommunikation, Anwendungsschicht
93
Verteilte Systeme: Web Services, WSDL
 Aufgabe
 Beschreibung von Web Services
 Auswertung von Computern
 Informationen für den
Entwickler
WSDL
u.a. Infos zu:
beschreibt
•Interface
•Implementierung
•URL
Web
Service
 Inhalt
 Informationen zum Interface
- Nachrichtenformat
- Kommunikationsprotokoll
- Operationen für den Datentransfer (z.B. send only, receive only,
send and receive)
 Informationen zur Implementierung
- Access Point des Web Services (URL)
Rechnerkommunikation, Anwendungsschicht
94
Verteilte Systeme: Web Services, WSDL
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
targetNamespace="http://localhost/wetterFrosch"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:tns="http://localhost/wetterFrosch"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
Deklaration der Namespaces
Rechnerkommunikation, Anwendungsschicht
95
Verteilte Systeme: Web Services, WSDL
<wsdl:portType name="Temperature">
<wsdl:operation name="getTemp" parameterOrder="ort">
<wsdl:input message="tns:tempRequest" name="TempRequest"/>
<wsdl:output message="tns:tempResponse" name="TempResponse"/>
</wsdl:operation>
</wsdl:portType>
Deklaration der Schnittstelle
<wsdl:message name="TempRequest">
<wsdl:part name="ort" type="xsd:string"/>
</wsdl:message>
<wsdl:message name="TempResponse">
<wsdl:part name="tempReturn" type="xsd:int"/>
</wsdl:message>
Deklaration der
verwendeten Nachrichten
Rechnerkommunikation, Anwendungsschicht
96
WSDL
Wie kommt man an den Dienst
mittels SOAP ran?
<wsdl:binding name="TemperatureSoapBinding" type="tns:Temperature">
<wsdlsoap:binding
RPC
style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getTemp">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="TempRequest">
TempRequest erwartet
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="TempResponse">
TempResponse zurück
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost/wetterFrosch" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
Rechnerkommunikation, Anwendungsschicht
97
Verteilte Systeme: Web Services, WSDL
<wsdl:service name="TemperatureService">
<wsdl:port binding="impl:TemperatureSoapBinding"
name="Temperature">
<wsdlsoap:address location="http://localhost/wetterFrosch"/>
</wsdl:port>
</wsdl:service>
Unter der Angegebenen URL wird ein
TemperatureService angeboten.
</wsdl:definitions>
Rechnerkommunikation, Anwendungsschicht
98
Anwendungsschicht
 Einführung
 Verbreitete Anwendungen








Hypertext Transfer Protocol (HTTP)
File Transfer Protocol (FTP)
E-Mail
Netzwerkmanagement
Domain Name System (DNS)
Content Distribution Networks
Real-Time Protocol (RTP)
Session Initiation Protocol (SIP)
 Socket-Programmierung
 Verteilte Systeme
 Peer-to-Peer-Systeme
Rechnerkommunikation, Anwendungsschicht
99
P2P
 Peer-to-Peer
 bekannt von Anwendungen zum Filesharing
 Grundidee: Inhalte nicht nur von zentralem Server, sondern auch von
anderen Peers
 Upload-Bitrate der Peers wird mitgenutzt
File: F
Server
u5
u1
d1
u2
d2
u3
Internet
d3
u4
dN
uN
Rechnerkommunikation, Anwendungsschicht
d6
u6
d5
d
uU5 4
100
P2P
 Peer-to-Peer
 Anwendungen wie Napster und KaZaA zum direkten Austausch von
Musikdateien (MP3) haben P2P populär gemacht
 Napster aus juristischen Gründen stillgelegt, diverse Nachfolger
(Gnutella, Pastry, eDonkey, …)
 Hauptteil des Netzverkehrs wird heute durch P2P erzeugt
 Peers kommunizieren direkt mittels TCP oder UDP
 P2P-Netze bilden Overlay-Netz: logisches Netz aus Peers über dem
physikalischen Netz
Rechnerkommunikation, Anwendungsschicht
101
P2P
 Zentralisiertes Verzeichnis
 Architektur von Napster
 Eintritt eines Peers:
er informiert zentralen Server
über seine IP-Adresse und seine
Inhalte
 Suche nach Inhalt:
über zentralen Server
 Dateiübertragung: direkt
zwischen Peers
 zentraler Server
- juristischer „Schwachpunkt“
- Leistungs- und
Zuverlässigkeitsproblem
Bob
centralized
directory server
1
peers
1
3
1
2
1
Alice
Rechnerkommunikation, Anwendungsschicht
102
P2P
 Dezentralität durch Fluten von Anfragen











Architektur von Gnutella
Peers bilden Overlay-Netzwerk über TCP-Verbindungen
anfragender Peer sendet Anfrage an alle Nachbarn
diese vergleichen Anfrage mit den von ihnen angebotenen Inhalten
Fluten: wenn sie die Anfrage nicht beantworten können, wird sie an mehrere
Nachbarn weitergeleitet (aber nicht an den Peer, von dem die Anfrage kommt)
das Fluten wird durch einen maximalen Hopcount begrenzt
wenn ein Peer den Inhalt anbieten kann, antwortet er dem anfragenden Peer,
dieser leitet wiederum zurück (die Identität des ursprünglich anfragenden Peers
bleibt so unbekannt)
die Antwort findet zur Quelle zurück, diese kontaktiert direkt einen der Peers,
der die Anfrage beantworten kann, die Übertragung erfolgt mittels HTTP
kein zentraler Server benötigt
Eintritt in das Overlay-Netzwerk: Nachricht an eine veröffentlichte
Liste von möglichen Peers schicken
Skalierbarkeit ist wegen des Flutens problematisch
Rechnerkommunikation, Anwendungsschicht
103
P2P
 Hierarchie
 Architektur von KaZaA
 proprietäres Protokoll,
Kontrollnachrichten verschlüsselt
 Peers bilden Gruppen, einer ist Group
Leader
 Group Leader kennt Inhalte aller
Peers aus Gruppe (Gruppe ≈ „MiniNapster“)
 Overlay-Netzwerk zwischen Group
Leadern
 Austausch zwischen Group Leadern
ähnlich wie bei Gnutella
 bessere Skalierbarkeit, ebenfalls
keine zentrale Kontrolle
Rechnerkommunikation, Anwendungsschicht
104
P2P
 Verteilte Hash-Tabellen (Distributed Hash Tables, DHT)
 dezentrales Verfahren für Speicherung und Lookup von
Datenelementen, bekannt aus Chord-System
 Peers bilden ringförmiges Overlay-Netz
 jedem Peer wird zufälliger Bezeichner p (0 ≤ p ≤ 2m-1) aus
Bezeichnerraum mit m Bits zugewiesen
 jedem Datenelement wird mittels Hash-Funktion ein Schüssel k
ebenfalls aus diesem Raum zugewiesen
 Nachfolger von k
- Datenelement mit Schlüssel k wird auf Nachfolger p von k
gespeichert, p = succ(k)
- dies ist der Peer mit dem kleinstem Bezeichner p ≥ k
(die ≤-Relation gilt bis auf Modulo 2m-1)
- Lookup für ein Datenelement mit Schlüssel k erfolgt auf Peer
succ(k)
Rechnerkommunikation, Anwendungsschicht
105
P2P
 Finger-Tabelle
 jeder Peer p unterhält Finger-Tabelle FTp mit maximal m Einträgen
 i-ter Eintrag der Finger-Tabelle: FTp[i] = succ(p+2i-1)
enthält Nachfolger mit exponentiell steigenden Distanz
 Lookup für Datenelement mit Schlüssel k
- Start mit beliebigem Peer p
- Wiederhole bis p ≥ k:
• wenn k ≤ FTp[1], dann q = FTp[1]
• wenn FTp[m] ≤ k, dann q = FTp[m]
• sonst q = FTp[i] ≤ k < FTp[i+1]
• p=q
- succ(k) = p
 Beispiel (nächste Folie)
 m = 5, Bezeichnerraum 0 ≤ p ≤ 2m-1 = 31
 farbige Peers gehören zum Overlay
Rechnerkommunikation, Anwendungsschicht
106
Eigentlicher Knoten
1
2
3
4
5
30
1
1
1
4
14
0
1
4
4
9
9
18
2
Finger-Tabelle
i
4
28
Lookup von k =12
auf Peer 28
27
1
2
3
4
5
3
29
26
1
2
3
4
5
31
1
2
3
4
5
5
9
9
9
14
20
6
25
7
24
8
28
28
28
1
9
23
1
2
3
4
5
21
28
28
28
4
Lookup von k = 26
auf Peer 1
9
22
10
21
11
20
12
19
1
2
3
4
5
20
20
28
28
4
18
17
Rechnerkommunikation, Anwendungsschicht
16
15
14
13
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
11
11
14
18
28
14
14
18
20
28
18
18
18
28
1
107
P2P
 Lookup von k = 26 auf Peer 1





Lookup auf Peer 1 ergibt p = 18 = FT1[5] ≤ 26
Lookup auf Peer 18 ergibt p = 20 = FT18[2] ≤ 26 < FT18[3]
Lookup auf Peer 20 ergibt p = 21 = FT20[1] ≤ 26 < FT20[2]
Lookup auf Peer 21 ergibt p = 28 = FT21[1] ≥ 26
Ergebnis: succ(26) = 28
 Lookup von k = 12 auf Peer 28





Lookup auf Peer 28 ergibt p = 4 = FT28[4] ≤ 12 < FT28[5]
Lookup auf Peer 4 ergibt p = 9 = FT4[3] ≤ 12 < FT4[3]
Lookup auf Peer 9 ergibt p = 11 = FT9[2] ≤ 12 < FT9[3]
Lookup auf Peer 11 ergibt p = 14 = FT11[1] ≥ 12
Ergebnis: succ(12) = 14
 Diverse weitere Operationen notwendig
 Aktualisierung des Overlays, Optimierung
Rechnerkommunikation, Anwendungsschicht
108
P2P
 Hybridarchitektur
Tracker
Peer
Obtain
list of
peers
Alice
Rechnerkommunikation, Anwendungsschicht
Trading chunks
109