Kapitel 10 - Anwendungssysteme

Kommunikation und Datenhaltung
10. Anwendungssysteme
Prof. Dr. Martina Zitterbart
Dipl.-Inform. Martin Röhricht
[zit | roehricht]@tm.uka.de
Kapitelübersicht
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
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
… endlich Anwendungen
Die hier behandelten (Standard-)Anwendungen sind allen
bekannt
Hoffentlich hat sie jeder schon mal benutzt
Die Anwendungen profitieren von den angebotenen
Diensten der darunterliegenden Schichten (z.B. gesicherte
Übertragung)
Sind daher teilweise relativ einfach aufgebaut
Allerdings fehlt teilweise noch etwas in der Mitte – die
Middleware
… in diesem Kapitel werden zunächst die Anwendungen
vorgestellt
… darauf folgend kommt dann die Middleware
2
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Anwendungen im Beispiel
Sender
Empfänger
Server zur
Namensauflösung
Ende-zu-EndeKommunikationsbeziehung
E-Mails!
?
m
o
c
e.
l
p
m
a
.6
ex
6
r
6
e
rv
8.
e
6
1
l-S
2.
ai
9
M
1
E-
Authentif
Verschlüizierung,
sselung
neue E-Mails?
10…
…10110100
2006
200
3:41
200666
3:4
3:4111 200
13:
3:333:4
13:3
Jan
19
9113:3
19
Tue
Jan119
Jan
t Tue
host
TueJan
hos
Tue
al
ocal
>>
host
ost
loc
t>
al@l
host
cal
alh
al@
hos
e
t>
loc
loc
ocal
l@lo
cal
le
ampl
ost
mmmloc
lhos
al@
@lo
amp
Fro
al@l
loca
le
alh
Fro
loc
t.ex
le
loca
cal
.ex
<loc
loc
amp
From
::<lo
-hos
cal@
00
Fro
al@
-h
.exxamp
st.e
00
ote
<lo
th:
path
loc
+020
ote
<
ost
-ho
host
-pa
@rem
rem
111+02
urn00
by
ath
th:
te3:41
urn
mote
+020
er@
3:4
Ret
iver
+02
))by
-pa
emo
rn-p
Ret
1])
r@re
eiv
by
rece
urn
r@r
by
33:4
..31]
3:4
Retu
16.3
666113:3
:::rec
eive
1])
Ret
ive
2006
13:
.16
3:3
200
13:3
168.
31]
to:
e-to
ece
16.3
168
Jan
rrec
peJan
200
192.
.16
elop
92.
68.
200
19
-to
))
to
elo
19
,
o=[
168
Jan
=[1
Env
92.1
34)
peJan
4.34
Env
lope
Tue
92.
ue,
19
4.
elo
(hel
T
elo
19
im
o=[1
(h
Enve
=[1
im
te:
34)
e:
4.34
Env
e,
(Ex
Tue,
1]] (h
.31]
elo
4.
(hel
Tu
p (Ex
dat
00
y-da
6.3
te:
imm33:
8.16
ry(Exi
200
te:
esmt
.31]
+020
8.1
iver
(Ex
esm
da
y-da
.31
ive
tp
2.16
.16
.16
Del
tp
29
rywith
.16
Del
200
ver
3:29
esmtp
+020
192
esm
e wit
+0
.168
ive
168
Deli
13:3
mm [[19
29+0
withhhJan
Del
3:29
fro
ampl
92.
[192
mpple
wit
6613:
[1
33:
le
d:
2006
exa
13:3
e.ex
le
13:
ed:
rom
xamp
le.
eive
ffrom
mpl
xam
d:fro
eiv
2006
amp
e.e
Rec
200
19
ed:
.exa
e.e
ive
Rec
, 19
.ex
Jan200
ampl
eiv
mpl
Jan
rn
tern
Rece
ue,
19 Jan
TTue
Rec
exa
19
n.ex
e>>>
T;
mxin
mple
rn.
mxi
9T;
Tue,
mpl
ue,
nter
T
8X-9
nte
.exa
T;
8Xexa
ple
le>
mxinte
T;
0005
mxi
ple
mp
005
le.
8X-9
exam
X-9
NNexa
N-0
amp
exam
005
058
gN
le.
1EHg
-00
139@
NN-0
399@ex
ampple.
exam
id
gNN
id
321
0632
@ex
1EHg
139@
1EH
206
8.2
id1EH
213
0
632
id
88.
0
FF38
063
+020
8.20
FF3
020
2
+
0
8.2
<432
0
8
FF38
<43
2
F38
3:28
+020
D:
-ID:
32F
<432
13:3
<4
288 +020
e-I
33:2
sage
D:19
33:
-ID:
sag
006
13:33:
Mes
e-I
13:
age
Mes
613:
nn22006
Jan
sag
Ja
200
006
Mess
2
19
Mes
Jan
,
Ja
)
Tue,
19
Tue
1)
19
t>
>
e:
(X11
,
Tue,
ost
Dat
.22(X1
lhos
1))
Dat
t>derb
e: Tue
(X11
0.2
1.0
calh
e:
loca
st>
(X1
Date:
lhos
@lo
Dat
lho
ird
rd
cal@
0.2
1.0.
oca
cal
oca
1.
rbi
<lo
@l
al@l
rd1.
bird
m:
cal
Thun
rbi
<loc
Fro
nder
<lo
an
Fro
m:<lo
nde
Thunde
ian
m:
Debi
Thu
From:
an
Deb
Fro
nThu
t:
ent:
bia
Debi
De
gen
r-Ag
t:n:
ent:
Use
gen
Use
r-Ag
0
1.0
e
r-A
User-A
:
Use
ampl
mpple
1.0
ion
le
rsio
1.0
exa
t.ex
le
n:1.
ers
xamp
st.
E-Ve
-hos
ion:
xam
rsio
-ho
MIM
st.e
ers
t.e
ote
MIM
E-Ve
ote
-ho
E-V
hos
@rem
MIME-V
rem
MIM
temote
er@
iver
emo
r@re
rece
er@r
eive
To:
eiv
receiv
To:
rec
ill
To:rec
ail
To:
E-Ma
E-M
ail
t;;
t:
ect:
Mai
E-M
t;
E:
jec
ipar
par
Subj
t:
rt;
Sub
ject
lti
mult
jec
art
mu
:
Sub
tipa
:
Sub
tip
mul
Type
ype
e: mul
t-T
ent929
ype:
-Typ
Cont
929
t-T
153
Con
tent
29
ten
29
th::153
Conten
th:
Con
539
11539
Leng
eng
gth:
t-L
entgth
en
-Len
Cont
t-L
Con
tent
ten
Conten
Con
888
219
..
at.
s: 219
mat
form
2198
at.
for
Line
219
mat
Lin
es:
form
MMIME
es:
for
Lines:
Lin
MIME
IME
eeiin
MIME
sage
in
n
sag
in
mes
age
rt
t mes
00
sag
0400
mess
0 9-1
par
i-pa
mes
0500
00
art
ti0040
mult
art
109
099050
004
ti-p
050004
i-p
-1
001
8000
050
is
ult
859
0109
is
080
mmul
-885
amul
9030
010
-1
O-8
903
This
isaaa
0800
=ISO
800
Thi
is
8599-1
-885
080
00080
030
0903
O-8
--0
Thisss---=ISO
rrset
--0
Thi
809
008
=IS
cha
---00
cha
set=IS
--set
---0
rset
in;
--0
--tabl
char
in;
abl
cha
-------/pla
pla
int
---prin
n;
--ain;
tabl
--ableeee
xt/
---text
-pr
tedlai
--rin
: te
int
t/pl
---ten
ted
:
t/p
quo
---pr
tex
ed-p
Type
ype
tex
: quo
ted
ng:
e:
t-T
quot
ente:
ing
quo
yp
codi
-Typ
Cont
cod
ing:
t-T
ng:
Con
r-En
tent
-En
r
ten
odi
ncod
sfe
Con
sfe
Con
Enc
er-E
Tran
ran
nsfert-T
entransf
-Tra
Cont
t-T
Con
tent
ten
Conten
Con
o
lo
Hell
o
Hel
lo
Hell
Hel
ee
bye
dby
00
Good
0400
bye
Goo
004
dby
0500
Good
00
0400
Goo
109
099050
004
500
001
8000
050
1090
080
9030
010
8000
903
800
080
9030
00080
030
---0
--0
080
809
g;;;;
/jpg
00
------00
/jp
--0
-----tion
jpg
ion
-----jpg
--ica
---cat
ion/
-----on/
--pli
appl
--ati
icat
---e:
::ap
--lic
appl
Typ
ype
app
t-T
ente:
Type
yp
ten
Cont
t-T
entCon
e64
g""
ten
Cont
g"
e64
Con
bas
D.jp
.jp
64
pg"
: bas
ng:
e64
KuD
="Ku
base
ing
.jpg
bas
uD.j
codi
name
ng:
cod
KuD
nam
ng:
e="K
r-En
-En
e="
codi
r
odi
name="
nsfe
nam
sfe
Enc
r-En
;
Tra
ne;
ran
ersfe
ine
t-T
Z
inli
entTran
;
vZ
ransf
ten
ine;
3Nv
Cont
:::inl
b3N
t-T
entCon
inline
WNyb
ion
inl
vZ
ttion
ten
3NvZ
aaWNy
Cont
b3N
ChNa
osi
Con
tion
on:
ChN
WNyb
Dis
WNy
isp
iti
GxlI
osi
xlI
hNa
K
t-D
entpos
ChN
Rpd
pdG
Disp
xlIC
gK
isposi
ten
3Ig
xlI
L1R
Cont
wKL1
b3I
t-D
entCon
RpdG
pdG
XRob
DwK
gK
3IgK
ten
oKPD
ddXRo
Cont
L1R
wKL1
i9Bd
b3I
Con
Ym
XRob
i9B
BvYm
DwK
oKPD
XRo
HkpC
CBv
kpC
9Bd
oKP
gMC
b
vYm
YmoKP
Jpd
i9B
EgM
pdH
kpCi
vb
NCjE
mNv
CBv
kpC
gMCB
dXJ
VjdX
LmN
JpdH
EgM
pdH
3J5L
zNI
2Vj
NCjE
vb
mNvb
cgU2
bb3J5
NCj
dXJ
VjdX
KJcD
WN0b
LmN
JcD
IzNI
bm
3J5L
WN0
zNINCj
Rpbm
2Vj
I
3J5
jIK
cgU2
xLjI
GZmY
JcDIIzNI
XRp
ZmY
N0b
vdX
cgU
JcD
0xL
Q
pbm
Ri0
bmcgU
WN0
5wZ
Jvd
wZG
LjIK
vQ
ZmYW
jIK
uIFJ
ERi
Qov
XRp
ZmY
vdXR
dy5
JVBE
d3dy
KQo
0xL
Ri0x
JVB
5wZG
tYWl
Jvd
wZG
lwpK
YWl
Hd3
vQ
uIFJ
ERi
QovQ
J5IH
bblwp
JVBE
uIF
dy5
d3dy
yZG9
KQo
m1hb
ZG9
JVB
tYWl
b3
lwpK
N0b3
YWluIF
Hd3
t
lwp
J5IH
GVy
udGV
Edlc
ZG9ty
WN0
dlc
GYW
J5I
m1hb
ZG9
R
lud
0b3
IEl
b3J5I
m1h
hQI
ZGY
QIE
dGVy
dlcm1h
vR
wZGZ
GVy
tIE
Aov
WN0
dlc
GYWN
IFh
dCAt
dzIF
PAo
lud
IElu
dCA
hQIE
yICh
ZGY
QIE
go8P
ICh
3dz
wZGZ
vR
AovR
tIE
5kb3
aago8
dCAt
wZG
IFh
5kb
dzIF
hdG9
G9ia
PAo
dG9
dCA
yICh
aW
go8P
G9i
hXaW
IChwZG
3dz
y
5kb3
go8
mVh
DcmV
CAwI
dG95
ChX
AwI
5kb
G9ia
QgXC
dG9
9Dc
XaW
Ci9
aW
oKN
G9i
QgX
KNC
cmVh
AwI
mVh
uNj
pCi
ChX
AwI
uNj
gXCh
b3Ip
Ymo
RvYm
9Dc
Ci9D
b3I
oKNC
5IDE
QgX
KNC
IDE
mRv
uNjQ
pCi
plbm
uNj
b3IpZGZ
Ymo
RvYm
0b3J
b3J
b3I
5IDE
Pg
IDE0Nz
o+Pg
mRv
WN0
plbm
GYWN
Qo+
0b3J
plb
U3KQ
b3J25
ZGY
+Pg
Pgplb
U3K
YWN
WN0
0Nz
wZG
Qo+
3KQo
IChw
ZGY
ZGZG
ICh
2MTQ
U3K
MTQ
0NzU
wZG
IChw
0Nz
wOTE
OTE
ICh
2MTQ
MTQ
2
DUw
wMDU
OTE
IwM
OjI
DUwwOTE
EOj
IChE
IwMMDU
OjIw
ICh
EOj
IChE
ICh
Speicher
3
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)
Web
Server
Hypertext
Link
TCP Port 80
Web
Server
Hypertext
Link
TCP Port 80
Web
Server
TCP Port 80
TCP-Verbindungen
Web Client
(Browser)
Client-Server-Anwendung
Hypertext
Über ein Netz verbundene Objekte
Die grundlegende Idee Hypertext ist wesentlich älter als WWW
Grafischer Browser
Nutzung auch durch Nicht-Informatiker
Die(!) „Killer“-Anwendung im Internet
4
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Entwicklung des WWW
Hervorgegangen aus Arbeiten des britischen Informatikers
Tim Berners-Lee am europäischen Forschungszentrum CERN (Genf)
Ziel: Einfacher weltweiter Austausch von
Dokumenten zwischen Wissenschaftlern
Erster Prototyp Ende 1980
Grafisch und zeilenorientiert
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
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
Marc Andreesen
5
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Eindeutige Adressierung eines WebDokuments
WWW nutzt hierzu den Mechanismus des
Uniform Resource Locator / Identifier (URL / URI)
[RFC3986]
Repräsentiert eine Ressource und weist der Client-Software den „Weg“ zu ihr
Auch für Inhalte anderer Server (USENET, FTP, E-Mail) verwendbar
URL
Protokoll
Rechnername
(DNS)
Ressourcenbezeichnung
Ressourcenbezeichnung identifiziert das Objekt, auf das im jeweiligen
Server zugegriffen werden soll, identifiziert
Bei WWW: aufgerufene Web-Seite
Bei FTP: zu übertragende Datei
Bei Mail: Empfänger der Mail (also die Mail-Adresse)
6
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Komponenten des WWW
Namen/Namensdienst
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
Hypertext
Hypertext Markup Language (HTML) zur Beschreibung von WWW-Seiten
Strukturierung der Dokumente in Kopf (Header) und Rumpf (Body)
Tags zur Markierung von Formatierungsanweisungen
<b>Hallo</b> Ö Hallo
<i>Hallo</i> Ö Hallo
Austausch von HTML-Seiten
Hypertext Transfer Protocol (HTTP)
7
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
Einfaches ASCII-basiertes Transferprotokoll
[RFC1945]
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
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Nicht-persistente Verbindungen
Ablaufschritte
„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
Nicht-persistent
9
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
Persistente Verbindungen & Pipelining
Eigenschaft
Mehrere Objekte und WWW-Seiten werden über die gleiche TCPVerbindung ausgeliefert
Ohne Pipelining
Request wird erst nach Erhalt der vorangegangenen Response
versendet
Verzögerung im Rahmen einer RTT pro Objekt
Mit Pipelining
Requests können direkt hintereinander gesendet werden
Reduziert durch Slow-Start und RTT bedingte Verzögerung
Default-Modus bei HTTP/1.1
[RFC2616]
10
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.2 Namensdienst
Namen
Verwendung logischer Namen (z.B. www.tm.uka.de)
Ö Abbildung logischer Namen auf Referenzen (Binding)
z.B. Abbildung auf IP-Adresse (DNS)
z.B. Abbildung auf interne Objektidentifikatoren
(Beispiele im folgenden Kapitel zum Thema Middleware)
z.B. Abbildung von Dateiname auf Spur-/Sektor-/Blockadressen
Ö Analogie zum Telefonbuch: „White Pages“
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
Behälter für Bindings
11
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Namensdienst
Eigenschaften der Abbildungen
Namen können hierarchisch aufgebaut sein
Sequenz von Bindungen
Bindung ist in seinem Kontext eindeutig
Bindung führt zu genau einer Referenz
mehrere Bindungen können auf dieselbe Referenz verweisen
Probleme
Ausfall des Namensdienstes
Single point of failure
Ö Verteilte bzw. redundant aufgebaute Namensdienste
Skalierbarkeit in großen verteilten Systemen
Ö Verteilte bzw. redundant aufgebaute Namensdienste
Wie findet der Dienstnehmer den Namensdienst?
12
Feste Adresse
Im Zuge der dynamischen Netzwerkkonfiguration
(Mit Hilfe der Middleware, siehe folgendes Kapitel)
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Beispiel: Domain Name System (DNS)
Problem
www.ietf.org
Internet-Systeme können auf verschiedene Arten identifiziert werden
Name oder IP-Adresse
spiegel.de
tm.uka.de
Von den menschlichen Benutzern werden Namen bevorzugt
Abbildung von Name auf IP-Adresse erforderlich
[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?
Arbeitet nach dem Client/Server-Modell
Server kann Anfrage an andere Server weiterleiten
„Kernfunktion“ im Internet – keine eigentliche Anwendung
Komplexität ist am Rande des Netzes lokalisiert Ö Internet Design Philosophie!
Verwendung
Wird von anderen Protokollen der Anwendungsschicht eingesetzt: HTTP, SMTP, FTP
Anfrage nach IP-Adressen, Mail-Server, ...
Unter UNIX mit gethostbyname()
13
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Struktur des Internet-Namensraums
Struktur
Domänen, Sub-Domänen usw.
Oberste Ebene: Top-Level-Domain (TLD)
Generische Domänen
.aero, .biz, .cat, .com, .coop, .edu, .gov, .info, .jobs, .mobi, .int, .mil, .museum, .name,
.net, .org, .pro, .travel
Länder (z.B. .de, .us, .uk,…)
Repräsentation als Baum
generisch
int
com
edu
gov
Länder
mil
org
...
umass
net
de
us
se
uni-karlsruhe
ee
tm
ipd ...
Blätter repräsentieren Domänen ohne Sub-Domänen, aber mit IP-Equipment
Repräsentiert durch absoluten Namen, z.B. tm.uni-karlsruhe.de
14
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Zur Info: Zuordnung der Domänen
com
Kommerzielle Unternehmen
edu
Lehranstalten, Universitäten
gov
Regierungsbehörden
mil
Militärische Einheiten
net
Netzbetreiber und -anbieter
org
Organisationen, die nicht in die obigen Kategorien fallen
arpa
Temporäre Arpa-Domäne, die immer noch benutzt wird
int
Internationale Organisationen
Kurzbezeichnungen der Länder (de, ch, uk, etc.)
15
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Weitere Dienste von DNS
Host Alias
Endsysteme mit komplizierten Namen können über einen oder mehrere
Alias-Namen verfügen
Alias-Namen sind typischerweise einfacher zu merken
DNS kann für einen Alias-Namen den „eigentlichen“ Namen liefern (kanonischer
Name)
Mail Server Alias
E-Mail-Adressen sollten so gestaltet sein, dass sie leicht zu merken sind,
z.B. [email protected]
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
Lastverteilung
Bei redundant ausgelegten Servern (z.B. Server-Cluster) kann eine Menge
von IP-Adressen mit einem Namen assoziiert sein
DNS-Server antwortet mit gesamter Menge der zugehörigen IP-Adressen,
verändert aber die Reihenfolge, in der diese genannt werden
16
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Weshalb verteilte DNS-Server?
Probleme bei Zentralisierung
Singuläre Fehlerquelle
Verkehrsaufkommen an zentralem (weltweit!) Server
Entfernung der zentralen Datenbank
Verwaltung
Ö Ein zentraler Ansatz skaliert hier nicht!
Verteilung von DNS-Servern
Kein Server kennt alle Abbildungen von Namen auf IP-Adressen
Lokale DNS-Server
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)
Erste Nachfrage geht immer zu diesem lokalen Server (Default-Server)
Autoritativer DNS-Server
Enthält autoritative Abbildungen
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
Name-Server
Typen von Name-Servern hierarchisch gegliedert
Root-Server
Weltweit einige wenige solcher Server (bzw. Server-Cluster)
Top-Level Domain (TLD) Server
Verantwortlicher Server für die Top-Level Domains
Autoritative Name-Server
Jeder Host ist bei einem solchen Server registriert
Häufig gleichzeitig lokaler Name-Server in „seinem“ Netz
Lokale Name-Server
z.B. Provider, Universität, Firma etc. betreiben lokalen Name-Server
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)
Besitzt Autorität zur Namensvergabe innerhalb dieser Domäne
Darüber hinaus werden Ergebnisse von vorhergehenden Anfragen
zwischengespeichert
Timeout legt fest wie lange Einträge zwischengespeichert werden
Typischerweise mehrere Tage
18
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
DNS-Hierarchie: Beispiel
root
ch
unibe.ch
ethz.ch
„Weg durch die Hierarchie“
de
...
tu-bs.de
uni-karlsruhe.de
...
cs.tu-bs.de
asterix.unibe.ch
www.uni-karlsruhe.de
www.cs.tu-bs.de
19
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
DNS Root-Server
Lokation der DNS Root-Server
http://www.root-servers.org
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
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Verteilter Betrieb von Root-Servern
Root-Server können verteilt betrieben werden
z.B. K-Root-Server Mirror Instances
[RIPE09]
21
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
TLD-Name-Server für .de: DENIC
Zeitlicher Verlauf der Anzahl an registrierten .de-Domains
14.04.2008 12-millionste .de-Domain registriert
[DENI09]
22
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Die größten TLDs
Die Top Level Domains mit den meisten Einträgen (November 2008)
[DENI09]
23
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
Schema einer Abfrage
Hat Endsystem Antwort nicht im eigenen Cache, wird lokaler DNS-Server
befragt
Lokaler DNS-Server antwortet entweder
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
Datenbank
Anfrage lokaler
DNSServer
Antwort
Anfrage
Cache
Cache
Antwort
weitere
DNSServer
24
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Typen von DNS-Anfragen
Rekursive Anfrage
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
Client
(1) Anfrage
(2) Anfrage
(4) Antwort
(3) Antwort
NameServer A
NameServer A
25
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Typen von DNS-Anfragen
Iterative Anfrage
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
Name-Server A
ge
a
r
f
n
(1) A
wort
t
n
A
(2)
(3) Anfrage
Name-Server B
(4) Antw
Client
ort
26
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Beispiel
Typischerweise fragt Client seinen lokalen Name-Server rekursiv
Lokaler Name-Server arbeitet dann normalerweise iterativ
Root Name-Server
2
3
Lokaler Name-Server
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
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
10.2.2 DNS-Datenbankeinträge
Resource Records (RR)
In der Antwort werden ein oder mehrere solche Resource
Records mitgeführt
Tupel mit (Name, Wert, Typ, TTL)
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
Typ=CNAME
Name=Alias hostname, Value=Canonical hostname
Hiermit kann kanonischer Name bestimmt werden
Typ=MX
Name=Alias hostname, Value=Hostname eines E-Mail-Servers
28
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Resource Records
Varianten von Resource Records
Typ
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
Type
Class
Time to Live
Data Length
Resource Data
29
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
1
IPv6 für DNS-Rootserver
Seit Februar 2008 AAAA-Records für DNS-Rootserver
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
Seit 5. Juni 2008 fünf weitere k.root-servers.net Server
IPv6-fähig
Budapest, Mailand, Helsinki, Genf, Athen
Somit Gesamtzahl derzeit sieben
30
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Beispiel: DNS-Anfrage nach AAAARecords
> dig www.tm.uka.de AAAA
; <<>> 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
;; 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
31
;;
;;
;;
;;
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
Namensauflösung bei VoIP per SIP
Lokalisierung des SIP-Servers nur aus
Domänennamen (sip:[email protected])
nicht einfach
Problem während Sitzungsaufbaus:
Ermitteln von IP Adresse, Port and Transport Protokoll
des nächsten Hops
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)
www.tm.uka.de
Namensauflösung bei VoIP per SIP
Transport
Bestimmung
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
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.2.3 DNS-Dateneinheiten
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
Questions
(Variable number of questions)
Answers
(Variable number of RRs)
Authority
(Varible number of RRs)
Additional information
(Variable number of RRs)
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
DNS-Query – Wireshark
Identification
Flags
Number of Questions
Number of Answers
Number of Authority RRs
Number of Additional RRs
35
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
DNS-Reply – Wireshark
Flags im Reply
aufgeschlüsselt
2 RRs zu Namen
(Answers)
10 RRs anderer
autoritativer Server
3 zusätzliche
Angaben
36
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.2.4 Reverse Lookup
Aufgabe
Bestimmung des logischen Namens zu gegebener
IP-Adresse
Vorgehensweise
Gesuchte IP-Adresse wird in Zeichenkette umgeformt
Hierzu: Spezieller Teilbaum des DNS „in-addr.arpa“
Dient der Zuordnung von IP-Adresse Ö Name
Jede IP-Adresse entspricht Eintrag unterhalb in-addr.arpa
IP-Adresse wird dabei invertiert (siehe Beispiel)
Beispiel
arpa
in-addr
207
171
168
IP-Adresse: 207.171.168.16
DNS-Name in Anfrage: 16.168.171.207.in-addr.arpa
Ergebnis (Antwort RR): Resource Data = www.amazon.de
16
37
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
1
10.2.5 DNS-Beispiel: Akamai
Ziel
[Akam09]
Schnellere Auslieferung von Webseiten
Auslieferung des Contents durch Proxys
sog. Akamai-Server „nahe“ beim User (ISP)
Anpassung der Webseiten notwendig (Preprocessing)
Eingebettete URLs werden zu ARLs (URLs die auf Akamai zeigen)
Proxy-Auswahl
User Lokation + Proxy, der Objekte vorhält
nicht alle Objekte liegen auf allen Proxys
Zweistufiger Abbildungsprozess der ARLs
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
Aufwendigere Namensauflösung Ö Erhöhte DNS-Verzögerung/ -Verkehr
Nachbarschaftsbestimmung ungenau
Routing-technisch nicht klar, welcher Proxy am „nächsten“ zur IP-Adresse des Users liegt
Welche Metrik bestimmt Nachbarschaft?
Anzahl Hops? Auslastung? Geschwindigkeit? Ö Keine triviale Frage
38
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.3 Elektronische Post
Hauptziel
Internationaler Dienst zum Austausch elektronischer Mitteilungen
zwischen Personen oder zwischen Rechnern
Hauptvorteil gegenüber dem Telefon
Asynchron (Nachrichtenvermittlung)
Vergleich von Briefpost und Elektronischer Post:
Absender Umschlag
Absender
Briefkasten
Postamt
Postamt
Briefkasten
Umschlag
Inhalt
Inhalt
Terminal
Terminal
User
Agent
Mail
Transport
Agent
Mail
Transport
Agent
User
Agent
Empfänger
Empfänger
39
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
E-Mail
Vergleichbar mit „Snail Mail“
Traditionelle Post
Mail Server
und MTA
Asynchroner
Datenaustausch
zwischen Benutzern
Inhalte
SMTP
Text, Bilder, Audio und
Video
Mail Server
und MTA
SMTP
Grundlegende
Komponenten
SMTP
User Agent (UA)
Mail Server
Mail Transport Agents
(MTA)
User
Agents Mail Server
und MTA
User Mailbox
Simple Mail Transfer
Protocol (SMTP)
[RFC2821]
40
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Nachrichtenübertragung mit SMTP (1)
Client
Server
SYN
SYN + ACK
ACK
Server signalisiert
Bereitschaft zum
Kommunikationsaustausch
Verbindungsaufbau
durch Client
220 mail.receiver.de SMTP Ready\r\n
HELO mail.client.de
250 mail.receiver.de \r\n
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
41
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Nachrichtenübertragung mit SMTP (2)
Client
Server
MAIL FROM:[email protected]\r\n
250 OK \r\n
SMTP sendet das
MAIL FROM Kommando
RCPT TO:[email protected] \r\n
250 OK \r\n
DATA \r\n
354 Enter e-mail, end with . \r\n
Client sendet E-Mail
mit Kopfzeilen und
Nachrichteninhalt
<Kopfzeilen>Lieber Herr … \r\n
ACK
. \r\n
250 OK Mail accepted\r\n
Client signalisiert
Sitzungsende
ACK
FIN
ACK
Kommunikation und Datenhaltung – SS 2009
Alleiniger Punkt „.“ in
einzelner Zeile signalisiert
Ende der Mail
QUIT
FIN
42
DATA Kommando zeigt
Beginn der Daten an
Kapitel 10: Anwendungssysteme
Verbindungsabbau:
Server und Client
schließen TCP-Verbindung
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
E-Mail-Format nach RFC 822
Beispiel
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
Body
Hallo!
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
Probleme des RFC-Standards
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
SMTP sieht nur einfache ASCII-Texte als Nachrichten vor
MIME erweitert den Kopfteil einer Nachricht um
[RFC2045]
Formatinformation
Content-Type: Definiert den Typ des E-Mail-Inhalts
Content-Transfer-Encoding: Definiert die Transfer-Syntax, in der die
Daten des Hauptteils übertragen werden
Weitgehende Kompatibilität zur herkömmlichen
Internet-E-Mail
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
Wird eine solche Mail von einem "normalen Mailer" angezeigt, so
werden nur diese Erweiterungen verstümmelt
44
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
MIME
Content-types für verschiedenartige Inhalte
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
Z.B. für weitergeleitete (Teile von) E-Mails
Image: GIF, JPEG
Video: MPEG
Audio: Basic
Application: PostScript, octet-stream
Für Daten „bekannter“ Applikationen
Transfer Encoding
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
Base64
45
[RFC2046]
Abbildung von 6-Bit-Werten auf ASCII-Zeichen
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.3.2 Mailserver
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
Einfache Funktionalität
IMAP (Interactive Mail Access Protocol) dient dazu, die Nachrichten
zentral auf einem Mailserver zu verwalten
IMAP erlaubt erweiterte Kommandos (z.B. Ordnerverwaltung, Filterung)
Mailserver
Mail
Queue
Internet
SMTP
SMTP
Mailbox
POP3, Mail Client
IMAP
46
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
1
10.3.2.1 POP3
Ablauf in verschiedenen Phasen
User-Agent öffnet TCP-Verbindung zum POP-Server
auf Port 110
Autorisierung
Benutzername und Passwort
Transaktion
Abrufen von Nachrichten
Markieren von Nachrichten (Löschen ...)
Update
Löschen markierter Nachrichten
[RFC1939]
47
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
POP3
Schema
Sender
Empfänger
POP-Server
User Agent
User Agent
Mailbox
Message
Transfer
Agent
SMTP
Message
SMTP
Transfer
Agent
POPServer
TCP-Verbindung
POP
POPClient
TCP-Verbindung
48
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.3.2.2 IMAP
Vorteile gegenüber POP3
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
Wann ist diese Eigenschaft nützlich?
Ablauf
Verbindungsaufbau zwischen Client und IMAP-Server
Interaktionen
Kommando vom Client, Daten vom Server, Fertigmeldung vom
Server
Vier Zustände einer IMAP-Sitzung
Non-authenticated state
Kein Nutzer angemeldet, Einloggen und Abfragen der Server-Fähigkeiten
Authenticated state
Nutzer angemeldet, Operationen mit Ordnern möglich
Selected state
Ordner ausgewählt, Operationen mit Nachrichten möglich
Logout state
49
[RFC2060]
Ausloggen, Server sichert Änderungen endgültig
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
10.4 Dateitransfer im Internet
File Transfer Protocol (FTP)
Dient der Übertragung von Dateien
Basiert auf Client/Server-Modell
FTP-Dienste
Verbindungsaufbau mit Authentifizierung
Vorsicht: Authentifizierungsdaten werden im Klartext versendet
Auch anonymes FTP möglich
Jeder darf FTP-Dienst auf Server nutzen
Dateiübertragung von und zum Server
z.B. get- und put-Kommandos
Operationen auf Dateisystem
z.B. cd, dir
Hilfefunktionen
z.B. Kommando-Auflistung inklusive Parameter
Weitere implementierungsabhängige Dienste möglich
50
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
FTP-Prozesse für Dateitransfer
Nutzung zweier TCP-Verbindungen
Kontrollverbindung für Clientbefehle und Serverantworten
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
Datenverbindung zur Übermittlung von Daten zwischen Client und Server
Nicht-persistent: Nach der Übertragung einer Datei wird die Verbindung
geschlossen
IP „Type-of-Service“ sollte maximalen Datendurchsatz angeben
Benutzer
Benutzerschnittstelle
Client
Kontrollprozess
2 TCP-Verbindungen
Server
Kontrollprozess
FTP-Kommandos
FTP-Antworten
Dateisystem
Dateisystem
Client
Datentransfer
Daten
Server
Datentransfer
51
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
FTP – Datendarstellung
[RFC959]
Dateityp
ASCII-Dateityp, EBCDIC-Dateityp, Binär-Dateityp,
lokaler Dateityp
Formatierungsinformationen
Nonprint, Telnet-Format-Control, Fortran-CarriageControl
Struktur
Dateistruktur, Datensatzstruktur, Seitenstruktur
Übertragunsmodus
Stream-Modus, Block-Modus, Komprimierter Modus
Æ Nur die blau markierten Optionen werden
typischerweise implementiert
52
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
FTP-Befehle
Befehle und Antworten erfolgen im ASCII-Format
Sequenz Carriage-Return (CR) plus Linefeed (LF) an jedem
Zeilenende notwendig
Befehle bestehen aus 3 oder 4 Bytes mit ASCIIGroßbuchstaben
[Stev04]
Manche mit optionalen Argumenten
Gängige der 30 möglichen Befehle siehe Tabelle unten
53
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
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
FTP-Antworten
Antworten bestehen aus 3-stelligen ASCII-Zahlen mit
optionaler Nachricht nach Nummer
Jede der drei Stellen besitzt andere Bedeutung
Antwort
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
[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
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Beispiel FTP-Nachrichten (1)
FTP Client
$ 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
Beispiel FTP-Nachrichten (Forts.)
FTP Client
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
Datenverbindung auf
Port 53967 wird abgebaut
TCP FIN
Über Kontrollverbindung
Über Datenverbindung
Server wünscht Datenverbindung abzubauen
TCP FIN+ACK
TCP ACK
226 File send OK.
ftp> quit
Sitzung beenden
QUIT
221 Goodbye.
TCP FIN
TCP FIN+ACK
Abbau der
Kontrollverbindung
TCP ACK
56
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Beispiel FTP-Authentifizierung
Übermittlung des
Benutzernamens
im Klartext
57
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Beispiel FTP-Authentifizierung (2)
Übermittlung des
Passworts
im Klartext!
58
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Zusammenfassung
HTTP FTP SMTP POP IMAP
TCP
DNS
UDP
IP
59
Kommunikation und Datenhaltung – SS 2009
Kapitel 10: Anwendungssysteme
Institut für Telematik
Universität Karlsruhe (TH)
www.tm.uka.de
Aufgaben
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
[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
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