Kommunikation und Datenhaltung

Kapitelübersicht
Kommunikation und Datenhaltung
10. Anwendungssysteme
Prof. Dr. Martina Zitterbart
Dipl.-Inform. Martin Röhricht
[zit | roehricht]@tm.uka.de
1.
Einführung
2.
Physikalische Grundlagen
3.
Protokollmechanismen
4.
Geschichtete Architekturen
5.
Sicherungsschicht: HDLC
6.
Beschreibungsmethoden
7.
Sicherungsschicht:
Lokale Netze
8.
Netzkopplung und Vermittlung
9.
Die Transportschicht
10.
Anwendungssysteme
11.
Middleware
10.1
10.1Das
DasWorld
WorldWide
WideWeb
Web
10.2
10.2Namensdienst
Namensdienst
10.2
10.2Elektronische
ElektronischePost
Post
10.3
10.3Dateitransfer
Dateitransferim
imInternet
Internet
1
Kommunikation und Datenhaltung – SS 2009
… endlich Anwendungen
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Anwendungen im Beispiel
Die hier behandelten (Standard-)Anwendungen sind allen
bekannt
Sender
Empfänger
Hoffentlich hat sie jeder schon mal benutzt
Die Anwendungen profitieren von den angebotenen
Diensten der darunterliegenden Schichten (z.B. gesicherte
Übertragung)
Hello
Hello
Hello
Hello
400
Goodbye
Goodbye
400
Goodbye
050
0905000
Goodbye
00400
0109
05000400
0905000
3080001
9030800
000109
3080001
080
0008090
00
g;
8090308
0008090
jpg;
000
------------g;
tion/jp
-------ap
------cation/
------n/jpg;
------tion/jp
pli
applica
--------Type:
------licatio
applica
-Type:
e: app
-Type:
Content
Content
Content-Typ
e64
Content
base64
uD.jpg"
"
uD.jpg"
e64
base64
ding:
jpger
bas
uD.jpg"
name="K
uD.
coding:
g:bas
name="K
ding:
-En
er-Enco
name="K
name="K
Encodin
er-Enco
er-Transf
-Transf
ZZ
inline;
nsfit
-Transf
Content
: inline;
-Tra
b3NvZ
Content
inline;
WNyb3Nv
ion
ition:
inline;
Content-Dispos
Na
b3NvZ
Content
on:
WNyb3Nv
ition:
WNy
xlIChNa
-Dispos
NaWNy
KK
dGxlICh
positi
xlIChNa
-Dispos
KL1RpdG
Content
b3IgK
dGxlICh
Content
XRob3Ig
KL1RpdG
Content-Dis
oKP
Bd
YmoKPDw
b3IgK
Content
XRob3Ig
DwKL1Rp
XRo
kpCi9Bd
BvYm
oKPDwKL1Rp
BdXRo
YmoKPDw
bb
dHkpCi9
jEgMCBv
kpCi9Bd
BvYm
jdXJpdH
LmNvb
dHkpCi9
jEgMCBv
3J5LmNv
zNI
DIzNINC
DI
jdXJpdH
NCjEgMC
cgU
0b
bmcgU2V
LmNvb
3J5LmNv
zNINCjEgMC
DIzNINC
2VjdXJp
3J5
ZmYWN0b
xLjIKJc
Rpbm
DI
cgU2VjdXJp
0b3J5
xLjIKJc
bmcgU2V
QQ
ZGZmYWN
FJvdXRp
ZmYWN0b
Rpbm
xLjIKJc9t
3dy5wZG
JVBERi0
xLjIKJc
KQovQ
ZGZmYWN
JVBERi0
FJvdXRp
lwpKQov
YWl
9tYWluI
3dy5wZG
JVBERi0udGVyZG
uIFJvdX
J5I
hb
b3J5IHd
KQovQ
JVBERi0
lwpKQov
YWluIFJvdX
Hd3dy5w
9tYWluI
lwp
dlcm1hb
N0b3
udGVyZG
9t
J5IHd3dy5w
hblwp
b3J5IHd
R
IEdlcm1
GZGYWN0
dlcm1hb
N0b3
udGVyZG9y
zIFhQIE
dCAtIEl
udGVyZG
PAovR
IEdlcm1
dCAtIEl
GZGYWN0
go8PAov
ICh
9yIChwZ
zIFhQIE
dCAtIElDcmVhdG
wZGZGYW
5kb
ia
aW5kb3d
PAovRR
dCAtIEl
go8PAov
IChwZGZGYW
3dzIFhQ
9yIChwZ
go8
AwIG9ia
hXaW
DcmVhdG
9y
5kb3dzIFhQ
iago8
aW5kb3d
NCAwIG9
jQgXChX
AwIG9ia
hXaW
DcmVhdGJ5
vYmoKNC
uNjQgXC
b3IpCi9
DcmVhdG
NCAwIG9
b3IpCi9
jQgXChX
IDE
mRvYmoK
J5IDEuN
vYmoKNC
uNjQgXC
b3IpCi9GYWN0b3
plb
PgplbmR
b3IpCi9
IDE
J5IDEuN
GYWN0b3
o+Pg
J5
plb
PgplbmR
zU3KQo+
o+Pg mRvYmoK
GYWN0b3E2
IChwZGZ
GYWN0b3
IChwZGZ
zU3KQo+
MTQ
E2MTQ0N
IChwZGZwMDUwOT
0NzU3KQ
IChwZGZ
MTQ0NzU3KQ
E2MTQ0N
wMDUwOT
wMDUwOTE2
IChEOjI
IChEOjI
IChEOjIwMDUwOT
IChEOjI
… in diesem Kapitel werden zunächst die Anwendungen
vorgestellt
3
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Ende-zu-EndeKommunikationsbeziehung
Speicher
… darauf folgend kommt dann die Middleware
2
6
r
.6
ve
er
68
S
1
.
l
2
ai
M
19
E-
Authentifi
Verschlüszierung,
selung
E-Mails!
Allerdings fehlt teilweise noch etwas in der Mitte – die
Middleware
?
m
co
e.
l
p
am
.6
ex
neue E-Mails?
2006
1 2006
2006
119
13:33:4
3:33:411 2006
13:33:41
Jan
19
9113:33:4
19
Tue
Jan
Jan
tttTue
TueJan
hos
Tue
ocalhos
ocal
ost
st>
ost>
alh
ocalhos
local@l
st>ost.exampl
ee
loc
localho
@localh
From
lhost>
local@l
example
From
local@
localho
cal
<local@
Fromlocal@l
example
From
e-host.
al@loca
.exampl
<local@
te-h
path:
loc
+0200
<
ost3:33:41
path:
11+0200
e-host.
r@remot
00
by
path:<lo
+0200
er@remo
Returnpath:
mote-h
+02
))))by
Returnr@remot
eiv
by
receive
by
Return-e-to:
66113:33:4
6.
.16.31]
Returniver@re
2006
3:33:41
200
113:33:4
31]
e-to:
ece
Jan
rreceive
6.31]
.16.31]
Jan
2006
2.168.1
:rec
192.168
200
19
19
e-to:
Jan.31]
Envelop
e-to
34)
Jan
4.34)
2.168.1
Envelop
192.168
Tue,
ue,
198.16.31
4.
elo=[19
(helo=[
19
Envelopy-date:
]](h
34)
4.34)
Envelop
e,.168.16
(Exim
Tue,
elo=[19
4.
(helo=[
(Exim
y-date:
(h
(Exim
200
te:T[Tu
esmtp
+0200
(Exim
esmtp
y-date:
99+0
y-da
Deliver
16.31]
8.16.31
with
Deliver
200
esmtp
+0200
[192.16
192
esmtp
+0
33:
Deliverd:
13:33:2
le
29
withJan
Deliver
from
92.168.
[192.16
with
33:29
xampple
d:
2006
13:33:2
ple
lewith
2006
le.exam
13:
rom n[1
ffrom
d:from
200613:
ample.e
Receive
.examp
2006
19
le.exam
Receive
19
n.examp
.ex
Janxample>
Jan
Received:
19 Jan
Receive
example
19
n.examp
mxinter
9T;
T; TTue,
rn.
mxinter
Tue,
ue,ample.e
xample>
Tue,
nte
le>
mxinter
9T;
00058Xmxi
0058X-9
xample>
-9T;
ample.e
N-0
00058X@ex
1EHgNNample.examp
-00058X
2139@ex
ample.e
id
2139
gNN
id
@ex0200
1EHgNN1EH
2139@ex
id1EHgN
88.2063
id
88.2063
632139
FF3
88.2063
<432FF3
88 ++0200
<432
F388.20
0200
-ID:
32F
<432FF3
13:33:2
-ID:
<4
13:33:2
-ID:19
13:33:288 ++0200
Message
-ID:
13:33:2
Message
nn22006
Jan
Ja
2006
006
Message
2006
19
Message
Jan
Ja
Tue,
19
Tue,
19
(X11)
st>
Tue, loc
ost>
Date:
Tue,
Date:
(X11)
st> bird
alh
0.2
1.0.2
localho
(X11)
Date: <local@
Date:
lhost>
bird
0.2(X11)
1.0.2
oca
1.
llocalho
<local@
bird1.
Thunder
<local@
From:
From:
annThunder
Thunderbird
Debian
Thunder
From: <local@
From:
ent:
bia
Debian
ent:
De
ent:Debi
User-Ag
ent:
User-Ag
0
1.0
1.
User-Agrsion:
le
User-Ag
1.0
example
xamp
rsion:
1.0
le
n:
example
rsion:
e-host.
-host.e
rsio
.examp
MIME-Ve
MIME-Ve
ote
e-host.
MIME-Ve
r@remot
MIME-Ve
te-host
r@rem
emo
r@remot
receive
r@r
To:
receive
To:
receive
To:receive
To:
E-Mail
l
::::E-Mail
Maimu
rt;
E-Mail
Epart;
Subject
rt;
Subject
lti
multipa
Subject-Type:
Subject
tipart;
multipa
-Type:
mul
e:
-Type: :: 153
Content
929
-Typ
153929
Content
Content-Length
Content
53929
-Length
gth:: 1153929
-Length
Content
-Len
Content
Content2198
Content
2198
format.
2198
format.
Lines:
Lines:
format.
format.
Lines: 2198
iin
Lines:
MIME
IME
MIME
in
nMMIME
in
message
400
t message
art
message
par
message
400 59-1
art
050
0905000
multi-p
art
00400
0109
i-p
aaaamulti59-1
05000400
0905000
is
ult00
3080001
mmulti-p
59-1
9030800
This
000109
is------=ISO-88
59-1
3080001
This
is
080
0008090
set
Thisis
=ISO-88ble
This
8090308
=ISO-88
charset
0008090
le
000
set=ISO-88
------ain;
charset
char
le
-------te
plain;
------printab
;char
------ble
ain;
------xt/
text/pl
--------Type:
printab
ted
t/plain
quoted-------printa
text/pl
-Type:
tex
ted-printa
quotede: er
ding:
quo
-Type:
Content
coding:
-Typ
g:quo
Content
ding:
-En
Content-Transf
Content
Encodin
er-Enco
er-Transf
nsfer-Enco
-Transf
Content
Content
Content-Tra
Content
10…
…10110100
Sind daher teilweise relativ einfach aufgebaut
Server zur
Namensauflösung
Sendender
E-Mail-Server
Kommunikation und Datenhaltung – SS 2009
Zwischensystem
(Vermittlungssystem)
Kapitel 10: Anwendungssysteme
Dateneinheit
Institut für Telematik
Universität Karlsruhe (TH)
EmpfangsE-Mail-Server
www.tm.uka.de
10.1 World Wide Web (WWW)
Hypertext
Link
Web
Server
Web
Server
Hypertext
Link
Entwicklung des WWW
Hervorgegangen aus Arbeiten des britischen Informatikers
Tim Berners-Lee am europäischen Forschungszentrum CERN (Genf)
Web
Server
Ziel: Einfacher weltweiter Austausch von
Dokumenten zwischen Wissenschaftlern
Erster Prototyp Ende 1980
TCP Port 80
TCP Port 80
TCP Port 80
Grafisch und zeilenorientiert
TCP-Verbindungen
Durchbruch des WWW durch den WWW-Client Mosaic
Entwickelt von Marc Andreesen und Eric Bina (University of Illinois)
Ursprünglich für X-Windows-Systeme
Als Quellcode per FTP kostenlos verfügbar Ö schnelle Verbreitung
Marc Andreesen und Jim Clark gründeten im April 1994 die Firma
Netscape Communication Corporation
1998 wurde Netscape von America Online übernommen
Marc Andreesen inzwischen nicht mehr bei Netscape
Web Client
(Browser)
Client-Server-Anwendung
Hypertext
Über ein Netz verbundene Objekte
Die grundlegende Idee Hypertext ist wesentlich älter als WWW
Berners-Lee
Gründung des W3-Konsortiums im Juli 1994
Vorrangiges Ziel: Weiterentwicklung des WWW, z.B. durch
Standardisierung von HTML
Vorsitzender: Tim Berners-Lee
Infos unter http://www.w3.org
Grafischer Browser
Nutzung auch durch Nicht-Informatiker
Die(!) „Killer“-Anwendung im Internet
4
Marc Andreesen
5
Kommunikation und Datenhaltung – SS 2009
Institut für Telematik
Universität Karlsruhe (TH)
Kapitel 10: Anwendungssysteme
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Eindeutige Adressierung eines WebDokuments
Universal Resource Locator (URL)
kompakte Repräsentation der Lokation und Zugriffsmethode auf InternetRessourcen
<scheme>:<scheme-specific-part>
ftp://<user>:<password>@<host>:<cwd1>..<cwdN>/<name>; type=<typecode>
http://<host>:<port>/<path>?<searchpart>
mailto:<rfc822-addr-spec>
nntp://<host>:<port>/<newsgroup-name>/<article-number>
telnet://<user>:<password>@<host>:<port>
file://<host>/path
Auch für Inhalte anderer Server (USENET, FTP, E-Mail) verwendbar
URL
Ressourcenbezeichnung
Hypertext
Hypertext Markup Language (HTML) zur Beschreibung von WWW-Seiten
Strukturierung der Dokumente in Kopf (Header) und Rumpf (Body)
Tags zur Markierung von Formatierungsanweisungen
Ressourcenbezeichnung identifiziert das Objekt, auf das im jeweiligen
Server zugegriffen werden soll, identifiziert
<b>Hallo</b> Ö Hallo
<i>Hallo</i> Ö Hallo
Bei WWW: aufgerufene Web-Seite
Austausch von HTML-Seiten
Hypertext Transfer Protocol (HTTP)
Bei FTP: zu übertragende Datei
Bei Mail: Empfänger der Mail (also die Mail-Adresse)
6
7
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
www.tm.uka.de
Namen/Namensdienst
[RFC3986]
Repräsentiert eine Ressource und weist der Client-Software den „Weg“ zu ihr
Rechnername
(DNS)
Institut für Telematik
Universität Karlsruhe (TH)
Komponenten des WWW
WWW nutzt hierzu den Mechanismus des
Uniform Resource Locator / Identifier (URL / URI)
Protokoll
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Zustandsloses Protokoll (HTTP-Server hält keine Information über Clients)
Oberhalb TCP angeordnet
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.1.1 HTTP
Nicht-persistente Verbindungen
Einfaches ASCII-basiertes Transferprotokoll
Ablaufschritte
[RFC1945]
„Anklicken" des Objekts
Browser ermittelt URL
Browser fragt DNS (Domain Name System) nach IP-Adresse
DNS antwortet mit IP-Adresse
Browser etabliert TCP-Verbindung zu Port 80 dieser IP-Adresse
Browser schickt GET /...
Server sendet gewünschtes File
TCP-Verbindung wird geschlossen
Browser zeigt Text des Files an
Browser zeigt Bilder des Files an
Zwei Typen von Nachichten: Request und Response
Zustandslos: Jeder Request wird individuell bearbeitet
Setzt auf TCP-Verbindungen auf
kurzlebig: HTTP-Server schließt Verbindung nach Beantwortung der
Anfrage
Default-Port: 80
Beispiele von Requests
GET:
HEAD:
PUT:
POST:
Aufruf eines Objekts (mit und ohne Protokollversion)
Aufruf des Kopfs einer WWW-Seite
Speichern einer WWW-Seite
Übermittlung neuer Informationen; z.B. durch
interaktive Benutzer ausgefüllter Inhalt von Formularen
DELETE: Löschen einer WWW-Seite
8
Nicht-persistent
9
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
TCP-Verbindung wird nach Senden des Objekts geschlossen
Pro TCP-Verbindung genau ein Request-Response-Paar
Parallele TCP-Verbindungen möglich (ca. 5-10 bei derzeitigen
Browsern)
Probleme: Hoher Ressourcenverbrauch im Server, Slow-Start, RTT
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.2 Namensdienst
Persistente Verbindungen & Pipelining
Namen
Eigenschaft
Verwendung logischer Namen (z.B. www.tm.uka.de)
Ö Abbildung logischer Namen auf Referenzen (Binding)
Mehrere Objekte und WWW-Seiten werden über die gleiche TCPVerbindung ausgeliefert
z.B. Abbildung auf IP-Adresse (DNS)
z.B. Abbildung auf interne Objektidentifikatoren
Ohne Pipelining
Request wird erst nach Erhalt der vorangegangenen Response
versendet
(Beispiele im folgenden Kapitel zum Thema Middleware)
z.B. Abbildung von Dateiname auf Spur-/Sektor-/Blockadressen
Ö Analogie zum Telefonbuch: „White Pages“
Verzögerung im Rahmen einer RTT pro Objekt
Mit Pipelining
Verwaltung von Zuordnungen (Bindings)
Entgegennahme neuer Bindings
Auffinden der zu einem Objektnamen gehörenden Referenz
Löschen von Bindings
Erzeugen und Löschen von Namenskontexten
Requests können direkt hintereinander gesendet werden
Reduziert durch Slow-Start und RTT bedingte Verzögerung
Default-Modus bei HTTP/1.1
Behälter für Bindings
[RFC2616]
10
11
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Namensdienst
Beispiel: Domain Name System (DNS)
Eigenschaften der Abbildungen
Problem
Namen können hierarchisch aufgebaut sein
Name oder IP-Adresse
Sequenz von Bindungen
tm.uka.de
[RFC1034, 10.5]
Domain Name System
Verteilte Datenbank mit einer Hierarchie von Name-Servern (DNS-Servern)
Protokoll der Anwendungsschicht, das Kommunikation mit Name-Servern regelt
Über UDP realisiert – Port 53
Wieso nicht TCP?
Probleme
Ausfall des Namensdienstes
Arbeitet nach dem Client/Server-Modell
Single point of failure
Server kann Anfrage an andere Server weiterleiten
Ö Verteilte bzw. redundant aufgebaute Namensdienste
„Kernfunktion“ im Internet – keine eigentliche Anwendung
Komplexität ist am Rande des Netzes lokalisiert Ö Internet Design Philosophie!
Skalierbarkeit in großen verteilten Systemen
Ö Verteilte bzw. redundant aufgebaute Namensdienste
Verwendung
Wie findet der Dienstnehmer den Namensdienst?
Wird von anderen Protokollen der Anwendungsschicht eingesetzt: HTTP, SMTP, FTP
Feste Adresse
Im Zuge der dynamischen Netzwerkkonfiguration
(Mit Hilfe der Middleware, siehe folgendes Kapitel)
Kommunikation und Datenhaltung – SS 2009
spiegel.de
Von den menschlichen Benutzern werden Namen bevorzugt
Abbildung von Name auf IP-Adresse erforderlich
Bindung ist in seinem Kontext eindeutig
Bindung führt zu genau einer Referenz
mehrere Bindungen können auf dieselbe Referenz verweisen
12
www.ietf.org
Internet-Systeme können auf verschiedene Arten identifiziert werden
Anfrage nach IP-Adressen, Mail-Server, ...
Unter UNIX mit gethostbyname()
13
Institut für Telematik
Universität Karlsruhe (TH)
Kapitel 10: Anwendungssysteme
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Struktur des Internet-Namensraums
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Zur Info: Zuordnung der Domänen
Struktur
com
Domänen, Sub-Domänen usw.
Oberste Ebene: Top-Level-Domain (TLD)
Kommerzielle Unternehmen
edu
Generische Domänen
Lehranstalten, Universitäten
.aero, .biz, .cat, .com, .coop, .edu, .gov, .info, .jobs, .mobi, .int, .mil, .museum, .name,
.net, .org, .pro, .travel
gov
Länder (z.B. .de, .us, .uk,…)
Regierungsbehörden
Repräsentation als Baum
mil
generisch
Militärische Einheiten
Länder
net
Netzbetreiber und -anbieter
int
com
edu
gov
mil
org
...
umass
net
de
us
org
se
Organisationen, die nicht in die obigen Kategorien fallen
arpa
uni-karlsruhe
ee
tm
Temporäre Arpa-Domäne, die immer noch benutzt wird
ipd ...
int
Internationale Organisationen
Blätter repräsentieren Domänen ohne Sub-Domänen, aber mit IP-Equipment
Kurzbezeichnungen der Länder (de, ch, uk, etc.)
Repräsentiert durch absoluten Namen, z.B. tm.uni-karlsruhe.de
14
15
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Weitere Dienste von DNS
Weshalb verteilte DNS-Server?
Host Alias
Probleme bei Zentralisierung
Endsysteme mit komplizierten Namen können über einen oder mehrere
Alias-Namen verfügen
Singuläre Fehlerquelle
Verkehrsaufkommen an zentralem (weltweit!) Server
Entfernung der zentralen Datenbank
Verwaltung
Ö Ein zentraler Ansatz skaliert hier nicht!
Alias-Namen sind typischerweise einfacher zu merken
DNS kann für einen Alias-Namen den „eigentlichen“ Namen liefern (kanonischer
Name)
Mail Server Alias
Verteilung von DNS-Servern
E-Mail-Adressen sollten so gestaltet sein, dass sie leicht zu merken sind,
z.B. [email protected]
Kein Server kennt alle Abbildungen von Namen auf IP-Adressen
Lokale DNS-Server
Aber in vielen Fällen ist der Host-Name des Mail-Servers komplexer
gestaltet, z.B. für [email protected] der Mail-Server iramx2.ira.uni-karlsruhe.de
I.A. hat jeder Netz-Provider, jede Firma einen lokalen DNS-Server
Am Institut für Telematik (DNS der ATIS): iraun1.ira.uka.de (129.13.10.90)
Lastverteilung
Erste Nachfrage geht immer zu diesem lokalen Server (Default-Server)
Bei redundant ausgelegten Servern (z.B. Server-Cluster) kann eine Menge
von IP-Adressen mit einem Namen assoziiert sein
Autoritativer DNS-Server
Enthält autoritative Abbildungen
DNS-Server antwortet mit gesamter Menge der zugehörigen IP-Adressen,
verändert aber die Reihenfolge, in der diese genannt werden
16
Liefert maßgebliche Antworten
17
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Name-Server
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
DNS-Hierarchie: Beispiel
Typen von Name-Servern hierarchisch gegliedert
root
Root-Server
Weltweit einige wenige solcher Server (bzw. Server-Cluster)
Top-Level Domain (TLD) Server
Verantwortlicher Server für die Top-Level Domains
ch
Autoritative Name-Server
Jeder Host ist bei einem solchen Server registriert
Häufig gleichzeitig lokaler Name-Server in „seinem“ Netz
unibe.ch
Lokale Name-Server
ethz.ch
z.B. Provider, Universität, Firma etc. betreiben lokalen Name-Server
„Weg durch die Hierarchie“
de
...
tu-bs.de
uni-karlsruhe.de
...
Für jede Hierarchie-Ebene (= Domäne) gilt
Die Adresse eines Root-Servers ist bekannt
Kennt Name-Server, die für die nächst tiefere Ebene zuständig sind
Jeder Nameserver enthält die Einträge, für die er verantwortlich ist
(authoritative)
cs.tu-bs.de
asterix.unibe.ch
Besitzt Autorität zur Namensvergabe innerhalb dieser Domäne
www.uni-karlsruhe.de
Darüber hinaus werden Ergebnisse von vorhergehenden Anfragen
zwischengespeichert
www.cs.tu-bs.de
Timeout legt fest wie lange Einträge zwischengespeichert werden
Typischerweise mehrere Tage
18
19
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
DNS Root-Server
Verteilter Betrieb von Root-Servern
Lokation der DNS Root-Server
Root-Server können verteilt betrieben werden
http://www.root-servers.org
z.B. K-Root-Server Mirror Instances
Aufgaben
Kontaktiert
autoritative
Name-Server,
falls Abbildung
unbekannt
Gibt Abbildung
dem lokalen
Name-Server
bekannt
Weltweit gibt es 13
Root-Server
Root-Server
enthalten nur
Einträge für TLDs
[KuRo07]
Generische und
Länder-TLDs
20
[RIPE09]
21
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
TLD-Name-Server für .de: DENIC
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Die größten TLDs
Zeitlicher Verlauf der Anzahl an registrierten .de-Domains
Die Top Level Domains mit den meisten Einträgen (November 2008)
14.04.2008 12-millionste .de-Domain registriert
[DENI09]
[DENI09]
22
23
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.2.1 DNS-Abfrage
Typen von DNS-Anfragen
Schema einer Abfrage
Rekursive Anfrage
Hat Endsystem Antwort nicht im eigenen Cache, wird lokaler DNS-Server
befragt
Lokaler DNS-Server antwortet entweder
Kennt angefragter Server die Antwort nicht, befragt er weitere
Server, bis er die Antwort zurückliefern kann
Vorteil: Geringer Aufwand für Client, da Arbeit zur vollständigen
Namensauflösung dem Server überlassen wird
aus seiner eigenen Datenbank mit Einträgen (falls autorativ)
aus seinem Cache gespeicherter Antworten auf vorangegangene Anfragen
nach Befragung anderer DNS-Server, falls er die Antwort nicht liefern kann
Endsystem
Anfrage
Cache
(1) Anfrage
Datenbank
Anfrage lokaler
DNSServer
Antwort
(4) Antwort
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
(3) Antwort
NameServer A
Client
Cache
NameServer A
Antwort
weitere
DNSServer
24
(2) Anfrage
25
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Typen von DNS-Anfragen
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Beispiel
Typischerweise fragt Client seinen lokalen Name-Server rekursiv
Iterative Anfrage
Lokaler Name-Server arbeitet dann normalerweise iterativ
Kennt angefragter Server die Antwort nicht, kann er mit
Verweis auf anderen Server antworten
Client befragt dann weitere Server selbst
Vorteil: Weniger Aufwand für angefragten Name-Server
Root Name-Server
2
3
Lokaler Name-Server
Name-Server A
e
nfrag
(1) A
rt
ntwo
(2) A
(3) Anfrage
Name-Server B
(4) Antw
Client
ort
5
1 8
7
4
TLD Name-Server für .de
6
Autoritativer Name-Server
netserv.rz.uni-karlsruhe.de
Gesuchter Host
Client
sucht: www.uni-karlsruhe.de
26
www.uni-karlsruhe.de
27
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.2.2 DNS-Datenbankeinträge
Resource Records
Resource Records (RR)
Varianten von Resource Records
In der Antwort werden ein oder mehrere solche Resource
Records mitgeführt
Tupel mit (Name, Wert, Typ, TTL)
Typ
Typ=A bzw. Typ=AAAA
Name=Hostname, Value=IPv4-, bzw. IPv6-Adresse für Hostname
Typ=NS
Name=Domain, Value=IP-Adresse des autorativen Servers für
diese Domäne
Dieser Server weiß, wie IP-Adressen für Systeme dieser
Domäne bestimmt werden können
Beschreibung
A bzw. AAAA (Address)
Abbildung Name auf IPv4/IPv6-Adresse
MX (Mail Exchange)
E-Mail-Server einer Domäne
NS (Nameserver)
Nameserver einer Domäne
CNAME (Canonical Name)
„Alias“-Namen für Rechner/Domänen
PTR (Pointer)
Abbildung IP-Adresse auf Name
HINFO (Host Info)
Zusätzliche Informationen (CPU, …)
Format
0
31 bit
Domain Name
Typ=CNAME
Type
Name=Alias hostname, Value=Canonical hostname
Hiermit kann kanonischer Name bestimmt werden
Class
Time to Live
Data Length
Typ=MX
Resource Data
Name=Alias hostname, Value=Hostname eines E-Mail-Servers
28
29
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
> dig www.tm.uka.de AAAA
Seit Februar 2008 AAAA-Records für DNS-Rootserver
; <<>> DiG 9.4.1-P1 <<>> www.tm.uka.de AAAA
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12076
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
Namensauflösung von IPv6-Adressen in lesbare Namen und
umgekehrt
Unterstützung in sechs der insgesamt 13 Rootserver
[Heis08, RFC3596]
Zuvor keine ausschließlichen IPv6-basierten
DNS-Abfragen auf Root-Ebene möglich
Viele Toplevel-Domains bereits mit IPv6-fähigen
Nameservern ausgestattet
Z.B. DeNIC für TLD „.de“ seit 2004
Budapest, Mailand, Helsinki, Genf, Athen
Somit Gesamtzahl derzeit sieben
30
31
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
;; QUESTION SECTION:
;www.tm.uka.de.
IN
AAAA
;; ANSWER SECTION:
tm.uka.de.
86400
www.tm.uka.de.
0
www.tm.uni-karlsruhe.de. 86400
IN
IN
IN
DNAME
CNAME
AAAA
tm.uni-karlsruhe.de.
www.tm.uni-karlsruhe.de.
2001:638:204::42
;; AUTHORITY SECTION:
tm.uni-karlsruhe.de.
tm.uni-karlsruhe.de.
tm.uni-karlsruhe.de.
tm.uni-karlsruhe.de.
IN
IN
IN
IN
NS
NS
NS
NS
deneb.dfn.de.
iraun1.ira.uni-karlsruhe.de.
iraun2.ira.uni-karlsruhe.de.
netserv.rz.uni-karlsruhe.de.
A
A
A
A
192.76.176.9
141.3.10.90
141.3.10.91
129.13.64.5
86400
86400
86400
86400
;; ADDITIONAL SECTION:
deneb.dfn.de.
22190
IN
iraun1.ira.uni-karlsruhe.de. 13885 IN
iraun2.ira.uni-karlsruhe.de. 13885 IN
netserv.rz.uni-karlsruhe.de. 13887 IN
Seit 5. Juni 2008 fünf weitere k.root-servers.net Server
IPv6-fähig
Kapitel 10: Anwendungssysteme
www.tm.uka.de
Beispiel: DNS-Anfrage nach AAAARecords
IPv6 für DNS-Rootserver
Kommunikation und Datenhaltung – SS 2009
Institut für Telematik
Universität Karlsruhe (TH)
Kapitel 10: Anwendungssysteme
;;
;;
;;
;;
Query time: 2 msec
SERVER: 2001:638:204::11#53(2001:638:204::11)
WHEN: Thu Mar 27 06:20:31 2008
MSG SIZE rcvd: 269
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
DNS-Anfrage via IPv6!
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
1
Namensauflösung bei VoIP per SIP
Namensauflösung bei VoIP per SIP
Lokalisierung des SIP-Servers nur aus
Domänennamen (sip:[email protected])
nicht einfach
Problem während Sitzungsaufbaus:
SIP kann verschiedene Transportprotokolle nutzen
TCP, UDP, SCTP, TLS
32
Endsysteme müssen herausfinden, welche
Transportprotokolle zur Verfügung stehen
Endsystem kann anderen Server probieren, falls
einer ausfällt
DDDS/NAPTR ermöglicht grobgranulares
kapazitätsbasiertes „Load Balancing“
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
Transport
Bestimmung
Ermitteln von IP Adresse, Port and Transport Protokoll
des nächsten Hops
Gewünschte SRV
Namen von
Transportprotokollen
für nächste Anfrage
wählen
Load
Balancing
Robustheit
Vorhandene
Transportprotokolle
ausfindig machen
Gewünschte SRV
RR für nächste
Anfrage wählen
DNS Query
NAPTR RR
DNS Query
SRV RR
DNS Query
IP Adresse,
Protokoll und Ports
bekannt
AAAA RR
NAPTR RRs für example.com
erhalten:
SIP+D2T _sip._tcp.example.com
SIP+D2U _sip._udp.example.com
SRV RRs für _sip._tcp.example.com
SRV erhalten:
sipbalance01.example.com
sipbalance02.example.com
AAAA/A RR für
sipbalance02.example.com erhalten:
Löse Namen zu IP Adressen auf
33
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
10.2.3 DNS-Dateneinheiten
Institut für Telematik
Universität Karlsruhe (TH)
Kapitel 10: Anwendungssysteme
www.tm.uka.de
DNS-Query – Wireshark
Typen von Dateneinheiten
Query
Reply
Format der Dateneinheiten
Query/Reply, Authoritative, ...
31 bit
0
Identifiziert Query
Identification
Flags
Number of Questions Number of answer RRs
Number of authority RRs
Name und Typ
RRs zu Namen
Records anderer
autoritativer Server
Andere hilfreiche
Records
34
Kommunikation und Datenhaltung – SS 2009
Kopf
Number of additional RRs
Identification
Questions
(Variable number of questions)
Flags
Number of Questions
Answers
(Variable number of RRs)
Number of Answers
Number of Authority RRs
Authority
(Varible number of RRs)
Number of Additional RRs
Additional information
(Variable number of RRs)
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
35
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
DNS-Reply – Wireshark
10.2.4 Reverse Lookup
Aufgabe
Bestimmung des logischen Namens zu gegebener
IP-Adresse
Vorgehensweise
arpa
Gesuchte IP-Adresse wird in Zeichenkette umgeformt
Hierzu: Spezieller Teilbaum des DNS „in-addr.arpa“
in-addr
Dient der Zuordnung von IP-Adresse Ö Name
Jede IP-Adresse entspricht Eintrag unterhalb in-addr.arpa
Flags im Reply
aufgeschlüsselt
207
IP-Adresse wird dabei invertiert (siehe Beispiel)
2 RRs zu Namen
(Answers)
Beispiel
168
IP-Adresse: 207.171.168.16
10 RRs anderer
autoritativer Server
16
DNS-Name in Anfrage: 16.168.171.207.in-addr.arpa
Ergebnis (Antwort RR): Resource Data = www.amazon.de
3 zusätzliche
Angaben
36
171
37
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
10.2.5 DNS-Beispiel: Akamai
Ziel
www.tm.uka.de
1
10.3 Elektronische Post
Hauptziel
[Akam09]
Schnellere Auslieferung von Webseiten
Auslieferung des Contents durch Proxys
Institut für Telematik
Universität Karlsruhe (TH)
Kapitel 10: Anwendungssysteme
Internationaler Dienst zum Austausch elektronischer Mitteilungen
zwischen Personen oder zwischen Rechnern
sog. Akamai-Server „nahe“ beim User (ISP)
Hauptvorteil gegenüber dem Telefon
Anpassung der Webseiten notwendig (Preprocessing)
Eingebettete URLs werden zu ARLs (URLs die auf Akamai zeigen)
Asynchron (Nachrichtenvermittlung)
Proxy-Auswahl
Vergleich von Briefpost und Elektronischer Post:
User Lokation + Proxy, der Objekte vorhält
nicht alle Objekte liegen auf allen Proxys
Absender Umschlag
Zweistufiger Abbildungsprozess der ARLs
Briefkasten
HLDNS (High Level DNS, TTL 30 min)
LLDNS (Low Level DNS, TTL 30 sec)
Berücksichtigt Zustand des Internets, User-Anforderungen, Verfügbarkeit der Proxys
Text wird von Originalseite geladen, Objekte von Akamai-Servern
Probleme
Postamt
Postamt
Briefkasten
Inhalt
Aufwendigere Namensauflösung Ö Erhöhte DNS-Verzögerung/ -Verkehr
Nachbarschaftsbestimmung ungenau
Welche Metrik bestimmt Nachbarschaft?
Anzahl Hops? Auslastung? Geschwindigkeit? Ö Keine triviale Frage
Absender
38
Empfänger
Inhalt
Terminal
Routing-technisch nicht klar, welcher Proxy am „nächsten“ zur IP-Adresse des Users liegt
Umschlag
Terminal
User
Agent
Mail
Transport
Agent
Mail
Transport
Agent
User
Agent
Empfänger
39
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
E-Mail im Internet: SMTP
Nachrichtenübertragung mit SMTP (1)
E-Mail
Client
Server
Mail Server
und MTA
Vergleichbar mit „Snail Mail“
Traditionelle Post
SYN
SYN + ACK
Asynchroner
Datenaustausch
zwischen Benutzern
Inhalte
SMTP
Text, Bilder, Audio und
Video
Server signalisiert
Bereitschaft zum
Kommunikationsaustausch
SMTP
Grundlegende
Komponenten
220 mail.receiver.de SMTP Ready\r\n
HELO mail.client.de
SMTP
User Agent (UA)
Mail Server
Mail Transport Agents
(MTA)
User
Agents Mail Server
und MTA
250 mail.receiver.de \r\n
User Mailbox
Verbindungsaufbau
durch Client
ACK
Mail Server
und MTA
Client sendet
Verifikationswunsch
für Benutzer zit
VRFY zit\r\n
Der Client identifiziert
sich mittels des HELO
Kommandos
Stimmt der DNS-Eintrag
mit dem angegebenen
Namen wird Verbindung
akzeptiert
250 OK \r\n
Simple Mail Transfer
Protocol (SMTP)
[RFC2821]
40
41
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Nachrichtenübertragung mit SMTP (2)
Client
Server
Beispiel
250 OK \r\n
DATA \r\n
Client sendet E-Mail
mit Kopfzeilen und
Nachrichteninhalt
ACK
FIN
ACK
42
Kommunikation und Datenhaltung – SS 2009
Weitere Header-Felder:
BCC: Blind Carbon Copy
Reply-To: Antwort-Adresse falls nicht an Sender-Adresse zurück geschickt werden soll
In-Reply-To: Message-ID auf die Bezug genommen wird
Alleiniger Punkt „.“ in
einzelner Zeile signalisiert
Ende der Mail
QUIT
FIN
Kapitel 10: Anwendungssysteme
Body
Hallo!
ACK
250 OK Mail accepted\r\n
Client signalisiert
Sitzungsende
DATA Kommando zeigt
Beginn der Daten an
<Kopfzeilen>Lieber Herr … \r\n
. \r\n
www.tm.uka.de
Envelope-to: [email protected]
Received: from i72pc108.tm.uni-karlsruhe.de ([141.3.71.162] helo=tm.uka.de)
by irams1.ira.uka.de with smtp (Exim 3.30 #7 (Debian))
id 161oxI-0005j9-00
Header
for <[email protected]>; Thu, 08 Nov 2001 14:11:07 +0100
Message-Id: <[email protected]>
From: [email protected]
Date: Thu, 08 Nov 2001 14:11:07 +0100
SMTP sendet das
MAIL FROM Kommando
RCPT TO:[email protected] \r\n
354 Enter e-mail, end with . \r\n
Institut für Telematik
Universität Karlsruhe (TH)
E-Mail-Format nach RFC 822
MAIL FROM:[email protected]\r\n
250 OK \r\n
Kapitel 10: Anwendungssysteme
Probleme des RFC-Standards
Verbindungsabbau:
Server und Client
schließen TCP-Verbindung
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
43
Keine Übertragung von Binärdateien oder ausführbaren Programmen möglich
Keine länderspezifischen Zeichen
[RFC822]
Begrenzte Größe der Mails
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.3.1 MIME – Multipurpose Internet Mail
Extensions
MIME
Content-types für verschiedenartige Inhalte
SMTP sieht nur einfache ASCII-Texte als Nachrichten vor
MIME erweitert den Kopfteil einer Nachricht um
[RFC2045]
Formatinformation
Text: plain, richtext, HTML
Multipart: mixed, parallel, alternative, digest
Aus mehreren Teilen bestehende E-Mail (z.B. Text und HTML)
Message: rfc822, partial, external-body
Content-Type: Definiert den Typ des E-Mail-Inhalts
Content-Transfer-Encoding: Definiert die Transfer-Syntax, in der die
Daten des Hauptteils übertragen werden
Z.B. für weitergeleitete (Teile von) E-Mails
Image: GIF, JPEG
Video: MPEG
Audio: Basic
Application: PostScript, octet-stream
Weitgehende Kompatibilität zur herkömmlichen
Internet-E-Mail
Für Daten „bekannter“ Applikationen
Transfer Encoding
Mit der Transfersyntax Base 64 ist es möglich, Binärdaten durch
Subnetze zu leiten, die nur die Übertragung von 7-Bit-ASCII-Texten
erlauben
Die Transfersyntax Quoted Printable erlaubt nationale
Sonderzeichen
7bit (ASCII Zeichen), 8bit (non-ASCII Zeichen)
Binary
Quoted-printable
Kompromiss zwischen Lesbarkeit und Übertragung von nicht-ASCII-Zeichen
ASCII-Zeichen + Hex-Codes
z.B. Darstellung von 12 (dezimal) : =0C
Wird eine solche Mail von einem "normalen Mailer" angezeigt, so
werden nur diese Erweiterungen verstümmelt
Base64
44
45
Kommunikation und Datenhaltung – SS 2009
Institut für Telematik
Universität Karlsruhe (TH)
Kapitel 10: Anwendungssysteme
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
10.3.2 Mailserver
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Ablauf in verschiedenen Phasen
User-Agent öffnet TCP-Verbindung zum POP-Server
auf Port 110
Autorisierung
Einfache Funktionalität
IMAP (Interactive Mail Access Protocol) dient dazu, die Nachrichten
zentral auf einem Mailserver zu verwalten
Benutzername und Passwort
Transaktion
IMAP erlaubt erweiterte Kommandos (z.B. Ordnerverwaltung, Filterung)
Abrufen von Nachrichten
Markieren von Nachrichten (Löschen ...)
Mailserver
Internet
Kapitel 10: Anwendungssysteme
10.3.2.1 POP3
E-Mail wird meist zentral über einen Mailserver abgewickelt (Relay-MTA)
Mittels POP3 (Post Office Protocol 3) holt der Client die vom Mailserver
empfangenen und in der Mailbox gespeicherten Nachrichten ab
Mail
Queue
[RFC2046]
Abbildung von 6-Bit-Werten auf ASCII-Zeichen
Update
Löschen markierter Nachrichten
SMTP
SMTP
Mailbox
POP3, Mail Client
IMAP
[RFC1939]
46
47
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
1
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
POP3
10.3.2.2 IMAP
Vorteile gegenüber POP3
Schema
Sender
Benutzer kann Nachrichten-Ordner auf dem Server anlegen und
verwalten
Suchen in Ordnern wird unterstützt
IMAP-Server verwaltet Ordner-Hierarchie
Benutzer kann Teile von Nachrichten abrufen
Empfänger
POP-Server
User Agent
User Agent
Wann ist diese Eigenschaft nützlich?
Ablauf
Mailbox
Message
Transfer
Agent
SMTP
Message
SMTP
Transfer
Agent
POP
POPServer
Verbindungsaufbau zwischen Client und IMAP-Server
Interaktionen
Kommando vom Client, Daten vom Server, Fertigmeldung vom
Server
POPClient
Vier Zustände einer IMAP-Sitzung
Non-authenticated state
TCP-Verbindung
Kein Nutzer angemeldet, Einloggen und Abfragen der Server-Fähigkeiten
TCP-Verbindung
Authenticated state
Nutzer angemeldet, Operationen mit Ordnern möglich
Selected state
Ordner ausgewählt, Operationen mit Nachrichten möglich
Logout state
48
49
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
[RFC2060]
Ausloggen, Server sichert Änderungen endgültig
Kommunikation und Datenhaltung – SS 2009
10.4 Dateitransfer im Internet
Institut für Telematik
Universität Karlsruhe (TH)
Kapitel 10: Anwendungssysteme
www.tm.uka.de
FTP-Prozesse für Dateitransfer
File Transfer Protocol (FTP)
Nutzung zweier TCP-Verbindungen
Kontrollverbindung für Clientbefehle und Serverantworten
Dient der Übertragung von Dateien
Basiert auf Client/Server-Modell
Server wartet dazu passiv auf Port 21
Bleibt bestehen, solange Client mit Server kommuniziert
Ermöglicht Kommunikation während eines Dateitransfers
IP „Type-of-Service“ sollte wegen Befehlseingabe auf minimale Verzögerung
gestellt sein
FTP-Dienste
Verbindungsaufbau mit Authentifizierung
Datenverbindung zur Übermittlung von Daten zwischen Client und Server
Vorsicht: Authentifizierungsdaten werden im Klartext versendet
Auch anonymes FTP möglich
Nicht-persistent: Nach der Übertragung einer Datei wird die Verbindung
geschlossen
IP „Type-of-Service“ sollte maximalen Datendurchsatz angeben
Jeder darf FTP-Dienst auf Server nutzen
Dateiübertragung von und zum Server
Benutzer
Benutzerschnittstelle
2 TCP-Verbindungen
z.B. get- und put-Kommandos
Operationen auf Dateisystem
z.B. cd, dir
Hilfefunktionen
Client
Kontrollprozess
FTP-Kommandos
Client
Datentransfer
Daten
Server
Kontrollprozess
FTP-Antworten
Dateisystem
Dateisystem
z.B. Kommando-Auflistung inklusive Parameter
Weitere implementierungsabhängige Dienste möglich
50
Server
Datentransfer
51
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
FTP – Datendarstellung
FTP-Befehle
Befehle und Antworten erfolgen im ASCII-Format
[RFC959]
Dateityp
Sequenz Carriage-Return (CR) plus Linefeed (LF) an jedem
Zeilenende notwendig
ASCII-Dateityp, EBCDIC-Dateityp, Binär-Dateityp,
lokaler Dateityp
Befehle bestehen aus 3 oder 4 Bytes mit ASCIIGroßbuchstaben
Formatierungsinformationen
Struktur
Dateistruktur, Datensatzstruktur, Seitenstruktur
Übertragunsmodus
Stream-Modus, Block-Modus, Komprimierter Modus
Æ Nur die blau markierten Optionen werden
typischerweise implementiert
52
53
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Befehl
Beschreibung
ABOR
Vorherigen FTP-Befehl sowie Datentransfer abbrechen
LIST dateiliste
Liste von Dateien oder Verzeichnissen ausgeben
PASS passwort
Passwort für Server
PORT n1,n2,n3,n4,n5,n6
Client IP-Adresse (n1,n2,n3,n4) und Port (n5 x 256 + n6)
QUIT
Am Server abmelden
RETR dateiname
Datei holen (get)
STOR dateiname
Datei speichern (put)
SYST
Server gibt Systemtyp zurück
TYPE type
Dateityp spezifizieren: A für ASCII, I für Binärdatei
USER benutzername
Benutzername am Server
Kommunikation und Datenhaltung – SS 2009
FTP-Antworten
Bedeutung
1yz
Positive vorläufige Antwort
2yz
Positive abschließende Antwort
3yz
Positive zwischenzeitliche Antwort
4yz
Transiente negative abschließende Antwort
5yz
Permanente negative abschließende Antwort
x0z
Syntax
x1z
Information
x2z
Verbindungen
x3z
Authentifizierung und Abrechnung
x4z
Nicht spezifiziert
x5z
Dateisystem-Status
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Beispiel FTP-Nachrichten (1)
Antworten bestehen aus 3-stelligen ASCII-Zahlen mit
optionaler Nachricht nach Nummer
Jede der drei Stellen besitzt andere Bedeutung
Antwort
[Stev04]
Manche mit optionalen Argumenten
Gängige der 30 möglichen Befehle siehe Tabelle unten
Nonprint, Telnet-Format-Control, Fortran-CarriageControl
FTP Client
[Stev04]
Beispiele:
125 Datenverbindung
besteht
200 Befehl OK
214 Hilfemeldung
331 Benutzername OK,
Passwort erforderlich
425 Kann Datenverbindung
nicht öffnen
500 Syntaxfehler (Befehl
unbekannt)
501 Syntaxfehler (ungültige
Argumente)
54
$ ftp ftp.uni-koeln.de
Verbindungsaufbau
an Port 21 für
Kontrollverbindung
FTP Server
Server lauscht passiv
an Port 21
TCP SYN
TCP SYN+ACK
TCP ACK
220 Welcome to ftp.uni-koeln.de
Authentifizieren
Benutzer wird nach
Passwort gefragt
TCP Kontrollverbindung
an Port 21 aufgebaut
USER anonymous
331 Please specifiy the password.
PASS pass
230 Login successful.
ftp> get robots.txt
In Binärmodus
wechseln
TYPE I
200 Switching to Binary mode.
Client gibt IP-Adresse
und Port (53967) für
Datenverbindung an
PORT 141,3,71,33,210,207
200 PORT command successful.
55
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Beispiel FTP-Nachrichten (Forts.)
FTP Client
Beispiel FTP-Authentifizierung
FTP Server
Client fordert Datei
robots.txt an
RETR robots.txt
Aufbau TCP-Verbindung
für Daten auf Port 53967
TCP SYN
TCP SYN+ACK
TCP ACK
150 Opening BINARY mode data connection for robots.txt (211 bytes).
FTP Data: 211 bytes
Über Datenverbindung
Server wünscht Datenverbindung abzubauen
TCP FIN
Datenverbindung auf
Port 53967 wird abgebaut
Über Kontrollverbindung
TCP FIN+ACK
TCP ACK
226 File send OK.
ftp> quit
Sitzung beenden
Übermittlung des
Benutzernamens
im Klartext
QUIT
221 Goodbye.
Abbau der
Kontrollverbindung
TCP FIN
TCP FIN+ACK
TCP ACK
56
57
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Beispiel FTP-Authentifizierung (2)
Institut für Telematik
Universität Karlsruhe (TH)
Kapitel 10: Anwendungssysteme
www.tm.uka.de
Zusammenfassung
HTTP FTP SMTP POP IMAP
TCP
DNS
UDP
IP
Übermittlung des
Passworts
im Klartext!
58
59
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Aufgaben
Literatur
10.1 Was ist ein URL, wozu dient er und wie ist er aufgebaut?
10.2 Wie läuft üblicherweise der Abruf einer WWW-Seite über HTTP1.0
ab?
10.3 Beschreiben Sie, wie die Mechanismen Persistente Verbindungen,
sowie Pipelining Verbesserungen bewirken.
10.4 Erläutern Sie die Aufgaben des Domain Name Systems und dessen
Aufbau.
10.5 Wie läuft eine Namensauflösung ab und welche unterschiedlichen
Anfragetypen können hierbei vorkommen?
10.6 Beschreiben Sie, worin eine DNS-Antwort besteht und geben Sie
Beispiele, was sie enthalten kann.
10.7 Wozu dient und wie funktioniert eine rekursive DNS-Abfrage?
10.8 Wie werden E-Mails über das Internet transportiert?
10.9 Erläutern Sie, mit welchen Mitteln über E-Mails mehr als nur Text
transportiert werden kann.
10.10 Welche Protokolle spielen beim Abruf von E-Mails aus Mailboxen
die Hauptrolle und worin bestehen deren wichtigste Unterschiede?
10.11 Wofür werden beim Dateitransfer über FTP zwei Verbindungen
verwendet?
60
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Literatur
[RFC2045] N. Freed, N. Borenstein; Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies; RFC 2045,
November 1996
[RFC2046] N. Freed, N. Borenstein; Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types; RFC 2046, November 1996
[RFC2060] M. Crispin; Internet Message Access Protocol – Version 4rev1;
RFC 2060, December 1996
[RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee; Hypertext Transfer Protocol – HTTP/1.1; RFC
2616, June 1999
[RFC2821] J. Klensin (Ed.); Simple Mail Transfer Protocol; RFC 2821,
April 2001
[RFC3596] S. Thomson, C. Huitema, V. Ksinant, M. Souissi; DNS
Extensions to Support IP Version 6; RFC 3596, October 2003
[RFC3986] T. Berners-Lee, R. Fielding, L. Masinter; Uniform Resource
Identifier (URI): Generic Syntax; RFC 3986, January 2005
[RIPE09] RIPE NCC; k-root-server; http://k.root-servers.org
[Stev04] W. R. Stevens; TCP/IP; Hüthig-Verlag, 2004
62
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
[Akam09] http://www.akamai.com
[DENI09] DENIC eG; http://www.denic.de
[Hals05] F. Halsall; Computer Networking and the Internet; Addison-Wesley,
2005, 5th Edition
[Heis08] R. Kaps; IPv6 für DNS-Rootserver; heise online News, Februar
2008
[KuRo07] J. F. Kurose, K. W. Ross; Computer Networking; 4rd ed.,
Addison-Wesley, 2007
[RFC822] David H. Crocker (Ed.); Standard for the Format of ARPA Internet
Text Messages; RFC 822, August 1982
[RFC959] J. Postel, J. Reynolds; File Transfer Protocol (FTP); RFC 959,
October 1985
[RFC1034] P. Mockapetris; Domain Names – Concepts and Facilities; RFC
1034; November 1987
[RFC1035] P. Mockapetris; Domain Names – Implementation and
Specification; RFC 1035; November 1987
[RFC1939] J. Myers, M. Rose; Post Office Protocol – Version 3; RFC 1939,
May 1996
[RFC1945] T. Berners-Lee, R. Fielding, H. Frystyk; Hypertext Transfer
Protocol -- HTTP/1.0; RFC 1945, May 1996
61
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de