Transcript chap2_2ed_5July02

Kapitel 2
Applikationslaget
En dansk udgave af:
Computer Networking: A Top Down Approach.
note:
We’re making these slides freely available to all (faculty, students, readers).
They’re in powerpoint form so you can add, modify, and delete slides (including
this one) and slide content to suit your needs. They obviously represent a lot of
work on our part. In return for use, we only ask the following:
 If you use these slides (e.g., in a class) in substantially unaltered form, that you
mention their source (after all, we’d like people to use our book!)
 If you post any slides in substantially unaltered form on a www site, that you
note that they are adapted from (or perhaps identical to) our slides, and note our
copyright of this material.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2002
J.F Kurose and K.W. Ross, All Rights Reserved
Computer Networking:
A Top Down Approach
Featuring the Internet,
2nd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July
2002.
2: Applikationslaget
1
Kapitel 2: Applikationslaget
Mål:

 Begrebsmæssigt,
implementationsaspekter af netværk,
applikationsprotokoller
 transport-lags service
modeller
 client-server

paradigmet

peer-to-peer paradigmet
Lære om protokoller ved
at undersøge populære
applikations-lags
protokoller




HTTP
FTP
SMTP / POP3 / IMAP
DNS
Programmering af
netværks-applikationer

socket API
2: Applikationslaget
2
Kapitel 2 oversigt
 2.1 Principper for
applikationslagsprotokoller


klienter og servere
applikationskrav
 2.2 Web og HTTP
 2.3 FTP
 2.4 Elektronisk post
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket
programmering med TCP
 2.7 Socket
programmering med UDP
 2.8 Opbygning af en
Web-server
 2.9 Materialedistribution



Netværks Web-caching
Materialedistributionsnetværk
Peer-to-Peer fildeling
2: Applikationslaget
3
Netværks-applikationer: jargon
Proces: program, der
brugeragent: interfacer
kører i en maskine.
med brugeren “ovenover”
og nettet “nedenunder”.
 i samme maskine kan to
processer kommunikere  implementerer brugerved interproces
grænsseflade og
applikations-lags
kommunication
protokol
(defineret af OS).
 Web: browser
 Processer, der kører i
 E-mail: postlæseprogram
forskellige maskiner,
 streaming audio/video:
kan kommunikere med
medieafspiller
en applikationslagsprotokol
2: Applikationslaget
4
Applikationer og applikations-lags protokoller
Applikation: kommunikerende
distributerede processer



f.eks. e-mail, Web, Peer-topeer fildeling, instant
messaging
kører i maskiner (hosts)
udveksler beskeder for at
implementere applikationen
application
transport
network
data link
physical
Applikations-lags protokoller



en “del” af en applikation
definerer beskeder, der
udveksles af applikationerne
og aktioner, der foretages
bruger kommunikationstjenester, der ydes af
laverelags protokoller (TCP,
UDP)
application
transport
network
data link
physical
application
transport
network
data link
physical
2: Applikationslaget
5
Applikations-lags protokoller definerer
 Typer af beskeder, der
udveksles, f.eks anmodningsog svar-beskeder
 Syntaks af besked-typer:
hvilke felter i beskeder og
hvordan felter afgrænses
 Felternes semantik, d.v.s.
betydningen af informationen
i felterne
 Regler for, hvornår og
hvordan processer sender og
besvarer beskeder
Public-domain protokoller:
 defineres i RFC’er
 tillader interoperabilitet
 f.eks. HTTP, SMTP
Proprietære protokoller:
 f.eks. KaZaA
2: Applikationslaget
6
Client-server paradigmet (mønstret)
En typisk netværksapplikation har
to dele: en klient og en server
Klient:
application
transport
network
data link
physical
 indleder kontakten med
serveren (“taler først”)
 typisk beder den om service
fra serveren,
 Web: klienten implementeres i
browseren; e-mail: postlæseren
Serveren:
 yder forlangt service til klienten
request
reply
application
transport
network
data link
physical
 f.eks. sender Webserveren udbedte
Websider, mailserveren afleverer e-mail
2: Applikationslaget
7
Proces-kommunikation over netværk
 proces sender/modtager
beskeder til/fra dens
socket (“sokkel”)
 en socket svarer til en dør


afsenderprocessen smider
beskeden ud af døren
afsenderprocessen antager en
transportinfrastruktur på den
anden side af døren, som
bringer beskeden til
modtagerprocessens socket
klient eller
server
klient eller
server
styres af
app udvikler
proces
proces
socket
socket
TCP med
buffere og
variable
Internet
TCP med
Buffere og
variable
styres
af OS
 API: (1) valg af transportprotokol; (2) mulighed for at
sætte nogle få parametre (mere herom senere)
2: Applikationslaget
8
Adressering af processer:
 For at en proces kan
modtage beskeder må
den have identifikation
 hver maskine har en
unik 32-bit IP-adresse
 Spm: er IP-adressen på
maskinen, på hvilken
processen kører, nok til
at identificere
processen ?
 Svar: Nej, mange
processer kan køre på
samme maskine
 Identifikationen
indeholder både IPadressen og portnumre knyttet til
processen på maskinen.
 Eks. på port-numre:


HTTP server: 80
Mail server: 25
 Mere herom senere
2: Applikationslaget
9
Hvilken transportservice behøver en applikation ?
Data-tab
 nogle applikationer (f.eks.
audio) kan klare noget tab
 andre applikationer
(f.eks., fil-overførsel og
telnet) kræver 100%
pålidelig dataoverførsel
Timing
 nogle applikationer
(f.eks. Internettelefoni og interaktive
spil) kræver lille
forsinkelse for at
være “effektive”
Båndbredde
 nogle applikationer
(f.eks. multimedie)
kræver et minimum af
båndbredde for at
være “effektive”
 andre applikationer
(“elastiske
applikationer”) bruger
den til rådighed
værende båndbredde
2: Applikationslaget
10
Transportservice krav til almindelige applikationer
Data-tab
Båndbredde
Tidsfølsom
filoverførsel
e-mail
Web dokumenter
real-time audio/video
intet tab
intet tab
intet tab
tabs-tolerant
nej
nej
nej
ja, 100dele ms
lagret audio/video
interaktive spil
instant messaging
tabs-tolerant
tabs-tolerant
intet tab
elastisk
elastisk
elastisk
audio: 5kbps-1Mbps
video:10kbps-5Mbps
samme som ovenfor
få kb/s opefter
elastisk
Applikation
ja, få sek
ja, 100dele ms
ja og nej
2: Applikationslaget
11
Internet transportprotolol tjenester
TCP service:





forbindelses-orienteret:
opsætning kræves mellem
klient- og server-processer
pålidelig transport mellem
afsendende og modtagende
proces
flow control: afsender vil ikke
oversvømme modtageren
congestion control: neddrosl
afsender, når netværket
overbelastes
giver ikke: timing, minimum
båndbredde garantier
UDP service:
 upålidelig dataoverførsel
mellem afsendende og
modtagende proces
 giver ikke: forbindelsesopsætning, pålidelighed,
flow control, congestion
control, timing eller
båndbredde garantier
Spm: hvorfor er der en UDP?
2: Applikationslaget
12
Internettet: applikationer og transportprotokoller
Applikation
e-mail
remote terminal access
Web
filoverførsel
streaming multimedie
Internet-telefoni
Applikationslags protokol
Underliggende
transport protokol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
proprietær
(f.eks. RealNetworks)
proprietær
(f.eks. Dialpad)
TCP
TCP
TCP
TCP
TCP eller UDP
typisk UDP
2: Applikationslaget
13
Kapitel 2 oversigt
 2.1 Principper for
applikationslagsprotokoller


klienter og servere
applikationskrav
 2.2 Web og HTTP
 2.3 FTP
 2.4 Elektronisk post
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket
programmering med TCP
 2.7 Socket
programmering med UDP
 2.8 Opbygning af en
Web-server
 2.9 Materialedistribution



Netværks Web-caching
Materialedistributionsnetværk
Peer-to-peer fildeling
2: Applikationslaget
14
Web og HTTP
Først nogle definitioner
 En Web-side består af objekter
 Objekter kan være en HTML-fil, et JPEG-billede,
en Java-applet, en audio fil, o.s.v.
 En Web-side består af en basis HTML-fil, som
inkluderer flere refererede objekter
 Hvert objekt kan adresseres med en URL-adresse
 Eksempel på en URL-adresse:
www.diku.dk/undervisning/pic.jpg
maskinnavn
stinavn
2: Applikationslaget
15
HTTP-oversigt
HTTP: hypertext
transfer protokol
 Webbens applikationslags-
protokol
 en client/server model
 client: browser som
beder om og får samt
“viser” Web-objekter
 server: Web-serveren
sender objekter som
svar på anmodninger
 HTTP 1.0: RFC 1945
 HTTP 1.1: RFC 2068
PC der kører
Explorer
Server
Der kører
Apache Webserver
Mac der kører
Navigator
2: Applikationslaget
16
HTTP-oversigt (fortsat)
Bruger TCP:
 klienten indleder TCP-
forbindelsen (opretter
socket) til serveren, port 80
 serveren accepterer TCPforbindelsen fra klienten
 HTTP-beskeder (applikationslags protokol beskeder)
udveksles mellem browser
(HTTP klient) og Web-server
(HTTP server)
 TCP-forbindelsen lukkes
HTTP er “tilstandsløs”
 Serveren vedligeholder ingen
information om tidligere
klient-anmodninger
Sidebem.
Protokoller der vedligeholder
en “tilstand” er komplekse!
 forhistorien (tilstanden)
skal huskes
 hvis server eller klient går
ned kan deres opfattelse
af “tilstanden” blive
inkonsistente og skal
genoprettes
2: Applikationslaget
17
HTTP-forbindelser
Ikke-persistent HTTP
 Højst et objekt
sendes over en TCPforbindelse.
 HTTP/1.0 bruger ikkepersistent HTTP
Persistent HTTP
 flere objekter kan
sendes over en enkelt
TCP-forbindelse
mellem klient og
server.
 HTTP/1.1 bruger
persistente
forbindelser i default
mode
2: Applikationslaget
18
Ikke-persistent HTTP
(indeholder tekst
Bruger indtaster en URL
og referencer til 10
www.someSchool.edu/someDepartment/home.index
jpeg-billeder)
1a. HTTP-klienten indleder en TCPforbindelse til HTTP-serveren
(processen) i
www.someSchool.edu på port 80
2. HTTP-klienten sender en
HTTP request message
(indeholdende URL) ind i TCPforbindelses-soklen. Beskeden
angiver, at klienten ønsker
objektet
someDepartment/home.index
tid
1b. HTTP-serveren på maskinen
www.someSchool.edu venter
på TCP-forbindelser på port
80, “accepterer” forbindelse
og giver klienten besked
3. HTTP-serveren modtager
request beskeden og laver en
response besked indeholdende
det forlangte objektet og
sender beskeden ind i dens
socket
2: Applikationslaget
19
Ikke-persistent HTTP (fortsat)
4. HTTP serveren lukker TCP5. HTTP-klienten modtager svar-
tid
forbindelsen.
beskeden indeholdende htmlfilen og viser html-filen. Den
skanner html-filen og finder
10 refererede jpeg-objekter
6. Trin 1-5 gentages for hvert af
de 10 jpeg-objekter
2: Applikationslaget
20
Svartids-modellering
Definition af RoundTripTime:
tiden det tager at sende en lille
pakke fra klienten til serveren
og tilbage igen.
indled TCPSvartid:
forbindelsen
 én RTT for at initiere TCPRTT
forbindelsen
Bed om
fil
 én RTT for HTTP-anmodningen
RTT
og de første få bytes af HTTPsvaret kommer tilbage
fil
 filtransmissionstid
modtaget
total = 2RTT+filtransmissionstid
tid
tid for
forsendelse
af fil
tid
2: Applikationslaget
21
Persistent HTTP
Ikke-persistent HTTP:
 kræver 2 RTT pr. objekt
 OS skal arbejde og tildele
maskinressourcer for hver
TCP-forbindelse
 men browserne åbner ofte
parallele TCP-forbindelse
for at hente refererede
objekter
Persistent HTTP
 serveren lader forbindelsen
stå åben efter afsendelse
af svaret.
 de efterfølgende HTTPbeskeder mellem samme
client-server sendes over
forbindelsen
Persistent uden pipelining:
 klienten udsender først en
ny forespørgsel, når det
tidligere forlangte svar er
blevet modtaget
 en RTT for hvert
refereret objekt
Persistent med pipelining:
 default i HTTP/1.1
 klienten sender
forespørgsel, så snart den
møder et refereret objekt
 så lidt som én RTT for alle
de refererede objekter
2: Applikationslaget
22
HTTP request besked
 to typer HTTP beskeder:
request, response
 HTTP request besked:
 ASCII (person-læsbart format)
request linie
(GET, POST,
HEAD kommandoer)
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
linier Accept-language:fr
Carriage return,
line feed
angiver slut på
beskeden
(extra carriage return, line feed)
2: Applikationslaget
23
HTTP request besked: generelt format
2: Applikationslaget
24
Uploading af formular-input
Post metoden:
 Websider indeholder
ofte formularinput
 Input uploades til
serveren i “entity
body” (foregående
slide)
URL metoden:
 Bruger GET metoden
 Input uploades i URLfeltet i request -linien:
www.somesite.com/animalsearch?monkeys&banana
2: Applikationslaget
25
Metodetyper
HTTP/1.0
 GET
 POST
 HEAD

beder serveren om at
udelade udbedte
objekter fra svaret
HTTP/1.1
 GET, POST, HEAD
 PUT

uploader filen i “entity
body” til stien angvet i
URL-feltet
 DELETE
 sletter fil angivet i URL
feltet
2: Applikationslaget
26
HTTP svarbesked
statuslinie
(protokol
statuskode
statussætn.)
header
linier
data, f.eks.
udbedt
HTML-fil
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
2: Applikationslaget
27
HTTP-svar statuskoder
I første linie i server->klient svarbesked.
Nogle få eksempelkoder:
200 OK

request succeeded, requested object later in this message
301 Moved Permanently

requested object moved, new location specified later in
this message (Location:)
400 Bad Request

request message not understood by server
404 Not Found

requested document not found on this server
505 HTTP Version Not Supported
2: Applikationslaget
28
Prøv selv HTTP (klientsiden)
1. Telnet til din favorit Web-server:
telnet www.eurecom.fr 80 Åbner TCP-forbindelse til port 80
(default HTTP server port) i www.eurecom.fr.
Alt, der indtastes, sendes til
port 80 i www.eurecom.fr
2. Indtast GET HTTP request:
GET /~ross/index.html HTTP/1.0
Ved at indtaste dette (efterfulgt af
2 “carriage return”) sendes
denne minimale (men komplette)
GET request til HTTP-serveren
3. Se på svarbeskeden, der sendes af HTTP-serveren !
2: Applikationslaget
29
Bruger-server interaktion: autorisation
Autorisation : styrer adgangen
server
klient
til server-indholdet
sædv. http request msg
 autorisationsinformation:
typisk navn og password
401: authorization req.
WWW authenticate:
 tilstandsløs: klienten skal give
autorisation ved hver request
sædv. http request msg
 autorisation: headerlinie i
+ Authorization: <info>
hver request
 hvis ingen autorisationssædv. http svarbesked
header afslår serveren
adgangen og sender:
WWW authenticate:
svarlinie som svar
sædv. http request msg
+ Authorization: <info>
sædv. http svarbesked
2: Applikationslaget
tid
30
Cookies: husker “tilstanden”
Mange store Web-sites
bruger cookies
Der er fire dele:
1) cookie header-linie i
HTTP-svarbeskeden
2) cookie header linie i
HTTP request-beskeden
3) cookie fil på brugerens
maskine passes af
brugerens browser
4) back-end database på
Web-siten
Eksampel:



Susan går altid på
Internettet fra samme
PC
hun besøger en bestemt
e-handels site for
førstegang
Når den første HTTPrequest ankommer til
sitet, laver det en unik
ID og en post i backend
databasen til ID
2: Applikationslaget
31
Cookies: husker “tilstanden” (fortsat)
klient
Cookie file
ebay: 8734
Cookie file
amazon: 1678
ebay: 8734
server
sædv. http req. msg
server
sædv. http svar +
laver ID
Set-cookie: 1678 1678 for brugeren
sædv. http req. msg
cookie: 1678
sædv. http svarbesked
En uge senere:
Cookie file
amazon: 1678
ebay: 8734
sædv. http req. msg
cookie: 1678
sædv. http svarbesked
cookiespecifik
aktion
cookiespecifik
aktion
2: Applikationslaget
32
Cookies (fortsat)
Hvad cookies kan bringe:
 autorisation
 indkøbsvogn
 anbefalinger
 bruger sessionstilstand (Web e-mail)
apropos
Cookies og privatliv:
 cookies tillader sites
at finde ud af meget
om dig
 du kan give navn og email til sites
 søgemaskiner bruger
redirection og cookies
for at finde ud af
endnu mere
 annonceselskaber får
info på tværs af sites
2: Applikationslaget
33
Conditional GET: klient-side caching
 Mål: send ikke objekt, hvis
klient har opdateret cached
udgave
 klient: angiv dato for cached
kopi i HTTP-requesten
If-modified-since:
<date>
 server: svaret indeholder
intet objekt, hvis den
cachede kopi er up-to-date:
HTTP/1.0 304 Not
Modified
server
klient
HTTP request msg
If-modified-since:
<date>
HTTP response
objekt
ikke
ændret
HTTP/1.0
304 Not Modified
HTTP request msg
If-modified-since:
<date>
HTTP response
objekt
ændret
HTTP/1.0 200 OK
<data>
2: Applikationslaget
34
Kapitel 2 oversigt
 2.1 Principper for
applikationslagsprotokoller


klienter og servere
applikationskrav
 2.2 Web og HTTP
 2.3 FTP
 2.4 Elektronisk post
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket
programmering med TCP
 2.7 Socket
programmering med UDP
 2.8 Opbygning af en
Web-server
 2.9 Materialedistribution



Netværks Web-caching
Materialedistributionsnetværk
Peer-to-peer fildeling
2: Applikationslaget
35
FTP: file transfer protocol
bruger ved
maskine
FTP
FTP
bruger- klient
interface
filoverførsel
lokalt filsystem
FTP
server
remote filsystem
 overfør fil til-fra fjern maskine
 client/server model

client: den side, der indleder overførslen (enten til
eller fra den fjerne maskine)
 server: fjerne maskine
 ftp: RFC 959
 ftp-server: port 21
2: Applikationslaget
36
FTP: separate kontrol- og data-forbindelser
TCP kontrolforbindelse
port 21
 FTP-klienten kontakter FTP-




serveren på port 21 og angiver
TCP som transport- protokol
Klienten får autorisation over
kontrolforbindelsen
Klienten browser det fjerne
katalog ved at sende
kommandoer over kontrolforbindelsen.
Når serveren modtager en
kommando om fil-overførsel,
åbner serveren en TCP dataforbindelse til klienten
Efter overførsel af en fil lukker
serveren forbindelsen.
FTP
klient
TCP dataforbindelse
port 20
FTP
server
 Serveren åbner en anden TCP
data-dataforbindelse for at
overføre en anden fil.
 Kontrolforbindelsen er: “out
of band”
 FTP serveren vedligeholder
en “tilstand”: aktuelle katalog
og tidligere autentifikation
2: Applikationslaget
37
FTP kommandoer og svar
Nogle kommander:
Nogle retur-koder
 sendes som ASCII-tekst
 statuskode og sætning
over kontrolkanalen
 USER username
 PASS password
 LIST returnerer en liste
over filer i det aktuelle
katalog
 RETR filename retriever
(henter) filen
 STOR filename storer
(gemmer) filen på den
fjerne maskine.




(som i HTTP)
331 Username OK,
password required
125 data connection
already open;
transfer starting
425 Can’t open data
connection
452 Error writing
file
2: Applikationslaget
38
Kapitel 2 oversigt
 2.1 Principper for
applikationslagsprotokoller


klienter og servere
applikationskrav
 2.2 Web og HTTP
 2.3 FTP
 2.4 Elektronisk post
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket
programmering med TCP
 2.7 Socket
programmering med UDP
 2.8 Opbygning af en
Web-server
 2.9 Materialedistribution



Netværks Web-caching
Materialedistributionsnetværk
Peer-to-peer fildeling
2: Applikationslaget
39
Elektronisk post
outgoing
message queue
user mailbox
brugeragent
Tre hoveddele:
 brugeragenter
mail
server
 mail servere
SMTP
 simple mail transfer protocol:
SMTP
SMTP
Brugeragent
 en slags “mail reader”
 lav, rediger, læs postbeskeder
 f.eks. Eudora, Outlook, elm,
Netscape Messenger
 udgående og indkommende
beskeder gemmes på serveren
mail
server
bruger
agent
SMTP
brugeragent
mail
server
brugeragent
brugeragent
brugeragent
2: Applikationslaget
40
Elektronisk post: mail-servere
user
agent
Mail-servere
 mailbox indeholder
indkommende beskeder til
brugeren
 message queue af udgående
(at sende) postbeskeder
 SMTP protocol mellem mail
servere for at sende emailbeskeder
 klienten: den afsendende
mail server
 “serveren”: den
modtagende mail server
mail
server
SMTP
SMTP
mail
server
user
agent
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
2: Applikationslaget
41
Elektronisk post: SMTP [RFC 2821]
 bruger TCP til pålidelig overførsel af email-beskeder fra
klient til server på port 25
 direkte overførsel: afsendende server til modtagende server
 tre faser i overførslen
 handshaking (oprettelse af forbindelsen)
 overførsel af beskeder
 nedlukning
 Kommand-svar interaktion
 kommander: ASCII tekst
 svar: statuskode og -sætning
 Beskeder skal være i 7-bit ASCII
2: Applikationslaget
42
Scenario: Alice sender besked til Bob
4) SMTP-klienten sender
Alice’s besked over TCPforbindelsen
5) Bob’s mail server anbringer
beskeden i Bob’s mailbox
6) Bob starter sin
brugeragent for at læse
beskeden
1) Alice starter sin
brugeragent (UA) for at
skrive besked og “til”
[email protected]
2) Alice’s UA sender besked
til hendes mail server;
beskeden anbringes i
beskedkø.
3) Klient-siden af SMTP åbner
en TCP-forbindelse til
Bob’s mail server
1
user
agent
2
mail
server
3
mail
server
4
5
6
user
agent
2: Applikationslaget
43
Eksempel på SMTP interaktion
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
2: Applikationslaget
44
Prøv selv SMTP-interaktion:
 telnet servername 25
 se 220 svar fra serveren
 indtast HELO, MAIL FROM, RCPT TO, DATA,
QUIT kommandoer
sådan kan du sende email uden at bruge en emailclient (læser)
2: Applikationslaget
45
SMTP: slutord
 SMTP bruger persistente
forbindelser
 SMTP kræver besked
(header og body) i 7-bit
ASCII
 SMTP serveren bruger
CRLF.CRLF for at opdage
“end of message”
Sammenligning med HTTP:
 HTTP: pull (træk)
 SMTP: push (skub)
 begge har ASCII kommando-
svar interaktion og statuskoder
 HTTP: hvert objekt indkapsles
i sin egen svarbesked
 SMTP: flere objekter sendes i
multipart-beskeder
2: Applikationslaget
46
Mail beskedformat
SMTP: protokol til udveksling
af email-beskeder
RFC 822: standard for tekst
beskedformat:
 Header-linier, f.eks.



To:
From:
Subject:
header
blank
linie
body
forskelligt fra SMTP
kommandoer !
 body

“beskeden”, Kun ASCIItegn
2: Applikationslaget
47
Beskedformat: multimedie udvidelse
 MIME: multimedia mail extension, RFC 2045, 2056
 ekstra linier i beskedheaderen erklærer MIME
indholdstypen
MIME version
metoden brugt
til indkodning af data
multimedie datatype, subtype,
parametererklæring
indkodede data
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
2: Applikationslaget
48
MIME typer
Content-Type: type/subtype; parameters
Text
Video
 eksempler på undertyper:
 eksempler på undertyper:
plain, html
Image
 eksempler på undertyper:
jpeg, gif
Audio
 eksempler på undertyper:
mpeg, quicktime
Applikation
 andre data, som skal
behandles af læseren, før
de kan “ses”.
 eksempler på undertyper:
msword, octet-stream
basic (8-bit my-lov
indkodet), 32kadpcm (32
kb/s kodning)
2: Applikationslaget
49
Multipart Type
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=StartOfNextPart
--StartOfNextPart
Dear Bob, Please find a picture of a crepe.
--StartOfNextPart
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--StartOfNextPart
Do you want the reciple?
2: Applikationslaget
50
Mail adgangsprotokoller
user
agent
SMTP
SMTP
afsenderens mail
server
adgangs
protokol
user
agent
modtagerens mail
server
 SMTP: aflevering/lagring til modtagerens server
 Mail adgangsprotokol: nedhentning fra serveren



POP: Post Office Protocol [RFC 1939]
• autorisation (agent <-->server) og download
IMAP: Internet Mail Access Protocol [RFC 1730]
• flere features (mere kompleks)
• manipulation af lagrede beskeder på serveren
HTTP: Hotmail , Yahoo! Mail, osv.
2: Applikationslaget
51
POP3 protokol
autorisationsfase
 klient kommandoer:
user: giv username
 pass: password
 server svarer
 +OK
 -ERR

transaktionsfase, klient:
 list: list beskednumre
 retr: hent besked efter
nummer
 dele: slet
 quit
S:
C:
S:
C:
S:
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
2: Applikationslaget
on
52
POP3 (mere) og IMAP
Mere om POP3
 Foregående eksempel
bruger “download and
delete” mode.
 Bob kan ikke genlæse
e-mail, hvis han skifter
klient
 “Download-and-keep”:
kopier af beskeder på
forskellige klienter
 POP3 er tilstandsløs
over sessioner
IMAP
 Behold alle beskeder
på et sted: i serveren
 Tillader brugeren at
organisere beskeder i
foldere
 IMAP opretholder
brugertilstanden over
sessioner:

navne på foldere og
afbildning mellem
besked-ID’er og folder
navne
2: Applikationslaget
53
Kapitel 2 oversigt
 2.1 Principper for
applikationslagsprotokoller


klienter og servere
applikationskrav
 2.2 Web og HTTP
 2.3 FTP
 2.4 Elektronisk post
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket
programmering med TCP
 2.7 Socket
programmering med UDP
 2.8 Opbygning af en
Web-server
 2.9 Materialedistribution



Netværks Web-caching
Materialedistributionsnetværk
Peer-to-peer fildeling
2: Applikationslaget
54
DNS: Domain Name System
Personer: mange
identifikatorer:



distribueret database

applikation-lags protokol
CPR, navn, pasnr.
Internetmakiner og
routere:

Domain Name System:
IP-address (32 bit) –
bruges til at adressere
datagrammer
“navn”, f.eks.
gaia.cs.umass.edu –
bruges af personer
Spm: afbildning mellem
IP-adresser og navn ?
implementeret i hierarki af
mange name servere
maskiner, routere og name
servere kommunikerer for at
resolve navne (oversætte
mellem adresser og navne)
 NB: kærne Internet
funktion, implementeret som
applikation-lags protokol
 kompleksitet ved nettets
“kant”
2: Applikationslaget
55
DNS name servere
 ingen server har alle navne-
Hvorfor ikke central DNS?
til-IP adresse afbildninger
 enkelt fejlpunkt
lokal name server:
 hver ISP og firma har lokal
 trafikvolumen
(default) name server
 fjern central database
 maskine DNS forespørgsel går
 vedligeholdelse
først til den lokale name
server
skalerer ikke !
autoritativ name server:


for en maskine: gemmer
maskinens IP-adresse og navn
kan udføre navn-adresse
oversættelse for denne
maskines navn
2: Applikationslaget
56
DNS: Root name servere
 kontaktes af lokal name server, som ikke kan resolve (oversætte)
et navn
 root name server:
 kontakter autoritativ NS hvis navneafbildningen ikke kendes
 får afbildningen
 returnerer afbildningen til den lokale name server
a NSI Herndon, VA
c PSInet Herndon, VA
d U Maryland College Park, MD
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA
k RIPE London
i NORDUnet Stockholm
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
13 root name
servere i verden
2: Applikationslaget
57
Simpelt DNS eksempel
maskinen
surf.eurecom.fr
ønsker IP adressen på
root name server
2
4
5
3
gaia.cs.umass.edu
1. den kontakter sin lokale DNS
server, dns.eurecom.fr
lokal name server
dns.eurecom.fr
2. dns.eurecom.fr
kontakter root name
1
6
server, hvis nødvendigt
3. root name server kontakter
authoritative name server,
spørgende maskine
dns.umass.edu, hvis
surf.eurecom.fr
nødvendigt
authorititive name server
dns.umass.edu
gaia.cs.umass.edu
2: Applikationslaget
58
DNS eksempel
root name server
Root name server:
 kender måske ikke
7
authoritative name
server
 kender måske
intermediate name
server: hvem skal
kontaktes for at
finde authoritative
name server
6
2
local name server
dns.eurecom.fr
1
8
requesting host
3
intermediate name server
dns.umass.edu
4
5
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
2: Applikationslaget
59
DNS: itererede forespørgsler
root name server
rekursiv forespørgsel:
 lægger byrden ved
name resolution på
den kontaktede name
server
 kraftig belastning ?
itereret forespørgsel:
 den kontaktede
server svarer med
navnet på serveren
der skal kontaktes
 “Jeg kender ikke
dette navn, men spørg
denne server”
itereret forespørgsel
2
3
4
7
local name server
dns.eurecom.fr
1
8
requesting host
intermediate name server
dns.umass.edu
5
6
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
2: Applikationslaget
60
DNS: caching og opdatering af
poster
 når (en vilkårlig) name server lærer en mapping,
cacher den mapningen (afbildningen)
 Cache-værdier
timer ud (forsvinder) efter
nogen tid
 Opdaterings-notifikations mekanismer er under
design af IETF

RFC 2136

http://www.ietf.org/html.charters/dnsind-charter.html
2: Applikationslaget
61
DNS poster (records)
DNS: distribueret database med resource records (RR)
RR format: (name,
 Type=A
 name er maskinnavn
 value er IP-adresse
value, type,ttl)
 Type=CNAME
 name er alias navn for en
“kanonisk” (det rette) navn
www.ibm.com er egentlig
 Type=NS
servereast.backup2.ibm.com
 name er domæne (f.eks.
 value is kanonisk navn
foo.com)
 value er IP-adresse på
 Type=MX
autoritativ name server
 value er navnet på
for dette domæne
mailserver knyttet til name
2: Applikationslaget
62
DNS protokol og beskeder
DNS protokol : query og reply beskeder, begge med
samme beskedformat
besked header
 identifikation: 16 bit nr.
for forespørgsel, svaret
på denne bruger samme
nr.
 flag:
 forespørgsel el. svar
 rekursion ønskes
 rekursion findes
 svaret er autoritativt
2: Applikationslaget
63
DNS protokol og beskeder
Navn, type felter
for en forespørgsel
RR’er som svar
på forespørgslen
records for
autoritative servere
yderligere “hjælpe”
info som kan bruges
2: Applikationslaget
64
Kapitel 2 oversigt
 2.1 Principper for
applikationslagsprotokoller


klienter og servere
applikationskrav
 2.2 Web og HTTP
 2.3 FTP
 2.4 Elektronisk post
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket
programmering med TCP
 2.7 Socket
programmering med UDP
 2.8 Opbygning af en
Web-server
 2.9 Materialedistribution



Netværks Web-caching
Materialedistributionsnetværk
Peer-to-peer fildeling
2: Applikationslaget
65
Socket programmering
Mål: at lære hvorledes man opbygger client/server
applikationer, der kommunikerer v.h.a. sockets
Socket API
 indført i BSD4.1 UNIX 1981
 skal eksplicit oprettes,
bruges og frigives af appl.
 client/server paradigme
 to typer transportservice
via socket API:
 upålidelig datagram
 pålidelig byte streamorienteret
socket
en maskin-lokal,
applications-skabt,
OS-kontrolleret interface
(en “dør”) ad hvilken
applikationsprocesser kan
både sende og
modtage beskeder til/fra
en anden applikationsproces
2: Applikationslaget
66
Socket-programmering med TCP
Socket: en dør mellem applikationsprocess og endend-transport protokol (UCP eller TCP)
TCP service: pålidelig overførsel af bytes fra en
proces til en anden
kontrolleres af
applikationsudvikler
kontrolleres af
operativ
systemet
process
process
socket
TCP med
buffere
variable
maskine eller
server
internet
socket
TCP med
buffere
variable
kontrolleres as
applikations
udvikler
kontrolleres af
operativ
systemet
maskine eller
server
2: Applikationslaget
67
Socket programmering med TCP
Klient vil kontakte server
 Når den kontaktes af klienten
opretter server TCP’en en ny
 serverproces skal først køre
socket til serverprocessen for
 server skal have lave socket
at kommunikere med klienten
(dør) som accepterer
 dette tillader serveren at
klientens kontakt
tale med mange klienter
Klient kontakter server ved:
 source port numre bruges
 at oprette klient-lokal TCP
til at skelne klienter (mere
socket
i kap. 3)
 angive IP-adresse og port
nummer på serverprocessen
applikationssynspunkt
 Når klienten opretter
TCP giver pålidelig, in-order
socket: klient TCP establerer
overførsel af bytes (“pipe”)
forbindelse til server TCP
mellem klient og server
2: Applikationslaget
68
Stream jargon
 En stream er en sekvens af
tegn der flyder ind i eller
ud af en proces.
 En input stream knyttes til
en inputkilde for
processen, f.eks, tastatur
eller socket.
 En output stream knyttes
til en output kilde, f.eks,
monitor eller socket.
2: Applikationslaget
69
Socket programmering med TCP
o u tp u t
s tre a m
i n F ro m U s e r
Klient
P ro ce ss
proces
in p u t
s tre a m
o u tT o S e rv e r
1) klient læser linier fra
standard input (inFromUser
stream) , sender til server via
socket (outToServer
stream)
2) server læser linie fra socket
3) server konverterer linie til
uppercase og sender den
tilbage til klienten
4) klienten læser og viser den
ændrede linie fra socket
(inFromServer stream)
m o n ito r
i n F ro m S e rv e r
Eksempel client-server app:
k e y b o a rd
in p u t
s tre a m
client
TCP
c lie n tS o c k e t
socket
to n e tw o rk
TCP
socket
fro m n e tw o rk
2: Applikationslaget
70
Client/server socket interaktion: TCP
Server (kører på hostid)
Klient
opret socket,
port=x, for
Indkommende forespørgsler:
welcomeSocket =
ServerSocket()
TCP
Vent på indkommende
forb.opsætn.
connection request
connectionSocket =
welcomeSocket.accept()
læs request fra
connectionSocket
skriv svar til
connectionSocket
luk
connectionSocket
Opret socket,
knyttet til hostid, port=x
clientSocket =
Socket()
send request v.h.a.
clientSocket
læs svar fra
clientSocket
luk
clientSocket
2: Applikationslaget
71
Eksempel: Java klient (TCP)
import java.io.*;
import java.net.*;
class TCPClient {
public static void main(String argv[]) throws Exception
{
String sentence;
String modifiedSentence;
Opret
input stream
Opret
client socket,
knyttet til server
Opret
output stream
knyttet til socket
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket("hostname", 6789);
DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());
2: Applikationslaget
72
Eksempel: Java client (TCP), forts.
Opret
input stream
knyttet til socket
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
sentence = inFromUser.readLine();
Send linie
til server
outToServer.writeBytes(sentence + '\n');
Læs linie
fra server
modifiedSentence = inFromServer.readLine();
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
2: Applikationslaget
73
Eksempel: Java server (TCP)
import java.io.*;
import java.net.*;
class TCPServer {
Opret
velkomst socket
på port 6789
Vent på velkomstsocket’en på kontakt
fra klienten
Opret input
stream knyttet
til socket
public static void main(String argv[]) throws Exception
{
String clientSentence;
String capitalizedSentence;
ServerSocket welcomeSocket = new ServerSocket(6789);
while(true) {
Socket connectionSocket = welcomeSocket.accept();
BufferedReader inFromClient =
new BufferedReader(new
InputStreamReader(connectionSocket.getInputStream()));
2: Applikationslaget
74
Eksempel: Java server (TCP), fort.
Opret output
stream knyttet
til socket
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
Indlæs linie
fra socket
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + '\n';
Udskriv linie
til socket
outToClient.writeBytes(capitalizedSentence);
}
}
}
Slut på while-løkke,
Hop tilbage og vent på
en anden klient-forbindelse
2: Applikationslaget
75
Kapitel 2 oversigt
 2.1 Principper for
applikationslagsprotokoller


klienter og servere
applikationskrav
 2.2 Web og HTTP
 2.3 FTP
 2.4 Elektronisk post
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket
programmering med TCP
 2.7 Socket
programmering med UDP
 2.8 Opbygning af en
Web-server
 2.9 Materialedistribution



Netværks Web-caching
Materialedistributionsnetværk
Peer-to-peer fildeling
2: Applikationslaget
76
Socket programmering med UDP
UDP: ingen “forbindelse”
mellem klient og server
 ingen handshaking
 afsenderen knytter IPadresse og port i
destinationen til hver
pakke
 serveren skal uddrage IPadressen og port i
afsenderen fra modtagne
pakker
applikationssynspunkt
UDP giver upålidelig overførsel
af grupper af bytes (“datagrammer”)
mellem klient og server
UDP: transmitterede data kan
ankomme i gal rækkefølge
eller mistes
2: Applikationslaget
77
Client/server socket interaktion: UDP
Server (kører på hostid)
opret socket,
port=x, for
indkommende request:
serverSocket =
DatagramSocket()
læs request fra
serverSocket
skriv svar til
serverSocket
der giver klient
maskinadresse
og port nummer
Klient
opret socket,
clientSocket =
DatagramSocket()
Opret adresse (hostid, port=x,
send datagram request
v.h.a. clientSocket
læs svar fra
clientSocket
luk
clientSocket
2: Applikationslaget
78
Eksempel: Java klient (UDP)
in p u t
s tre a m
Klientproces
m o n ito r
in F ro m Use r
k e y b o a rd
P ro c e s s
Input: modtager pakke
(TCP modtog “byte
stream”)
UDP
packet
re ce ive P a cke t
(TCP sendte “byte
stream”)
se n d P a ck e t
Output: sender pakke
UDP
packet
client
UDP
c lie n tS o c k e t
socket
to n e tw o rk
UDP
socket
fro m n e tw o rk
2: Applikationslaget
79
Eksempel: Java klient (UDP)
import java.io.*;
import java.net.*;
Opret
input stream
Opret
klient socket
Oversæt
maskinnavn til IPadresse v.h.a. DNS
class UDPClient {
public static void main(String args[]) throws Exception
{
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
DatagramSocket clientSocket = new DatagramSocket();
InetAddress IPAddress = InetAddress.getByName("hostname");
byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];
String sentence = inFromUser.readLine();
sendData = sentence.getBytes();
2: Applikationslaget
80
Eksempel: Java klient (UDP), fort.
Opret datagram
med data, længde,
IP-addr, port
Send datagrammet
til serveren
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
clientSocket.send(sendPacket);
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
Læs datagrammet
fra serveren
clientSocket.receive(receivePacket);
String modifiedSentence =
new String(receivePacket.getData());
System.out.println("FROM SERVER:" + modifiedSentence);
clientSocket.close();
}
}
2: Applikationslaget
81
Eksempel: Java server (UDP)
import java.io.*;
import java.net.*;
Opret
datagram socket
på port 9876
class UDPServer {
public static void main(String args[]) throws Exception
{
DatagramSocket serverSocket = new DatagramSocket(9876);
byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];
while(true)
{
Opret plads til
modtagne datagram
Modtag
datagram
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
2: Applikationslaget
82
Eksempel: Java server (UDP), fort.
String sentence = new String(receivePacket.getData());
Få IP-adr
portnr på
afsender
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
Opret datagram
at sende til klient
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress,
port);
Udskriv
datagram
til socket
serverSocket.send(sendPacket);
}
}
}
Slut på while-løkke,
hop tilbage og vent på
et andet datagram
2: Applikationslaget
83
Opbygning af en simpel Web-server
 behandler en HTTP




request
accepterer request
parser header
får ønskede fil fra
serverens filsystem
opretter HTTP
svarbesked:

 efter oprettelsen af
serveren kan du bede
om en fil v.h.a. en
browser (f.eks. IE=
explorer)
 se detaljer i bogen
header lines + fil
 sender svaret til klient
2: Applikationslaget
84
Socket programmering: referencer
C-language tutorial (audio/slides):
 “Unix Network Programming” (J. Kurose),
http://manic.cs.umass.edu/~amldemo/courseware/intro.
Java-tutorials:
 “All About Sockets” (Sun tutorial),
http://www.javaworld.com/javaworld/jw-12-1996/jw-12sockets.html
 “Socket Programming in Java: a tutorial,”
http://www.javaworld.com/javaworld/jw-12-1996/jw-12sockets.html
2: Applikationslaget
85
Kapitel 2 oversigt
 2.1 Principper for
applikationslagsprotokoller


klienter og servere
applikationskrav
 2.2 Web og HTTP
 2.3 FTP
 2.4 Elektronisk post
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Socket
programmering med TCP
 2.7 Socket
programmering med UDP
 2.8 Opbygning af en
Web-server
 2.9 Materialedistribution



Netværks Web-caching
Materialedistributionsnetværk
Peer-to-peer fildeling
2: Applikationslaget
86
Web caches (proxy server)
Mål: opfyld klientforespørgsler uden at inddrage den
oprindelige server
 bruger indstiller
browseren: Web-tilgang
via cache
 browseren sender alle
HTTP requests til cachen


hvis objektet er i
cachen så returnerer
cachen objektet
ellers beder cachen om
objektet fra originalserveren og returnerer
objektet til klienten
original
server
klient
klient
Proxy
server
original
server
2: Applikationslaget
87
Mere om Web-caching
 Cachen virker både som
klient og server
 Cachen kan foretage up-todate check v.h.a. Ifmodified-since HTTP
headeren


Spm: skal cachen tage
risikoen og aflevere
cachede objekter uden
check ?
Der bruges heuristikker.
Hvorfor Web-caching?
 Det reducerer svartiden
for klientforspørgsler.
 Reducerer trafikken på en
institutions adgangslink.
 Et Internet fyldt med
caches gør det muligt for
“fattige” indholdsleverandører at levere
indholdet effektivt
 Typisk installeres cachen
af ISP (edb-afd., firma,
bolig ISP)
2: Applikationslaget
88
Caching eksempel (1)
Antagelser
 gns. objektstørrelse = 100,000
bit
 gns. request rate fra
institutionens browser til
originalserver = 15/sec
 forsinkelse fra institutionel
router til enhver originalserver
og tilbage til routeren = 2 sec
Konsekvencer
originalservere
off.
Internet
1.5 Mb/s
access link
institutionelt
netværk
10 Mb/s LAN
 udnyttelse på LAN = 15%
 udnyttelse på access link = 100%
 total forsinkelse
=
Internetforsinkelse + access fors. +
LAN fors.
= 2 sek + minutter + millisekunder
institutionel
cache
2: Applikationslaget
89
Caching eksempel (2)
Mulig løsning
 forøg båndbredden på access
link til f.eks. 10 Mb/s
Konsekvencer
originale
servere
off.
Internet
 udnyttelse af LAN = 15%
 udnyttelse af access link = 15%
= Internet-fors. +
access fors. + LAN fors.
= 2 sek + msek + msek
 ofte en kostbar opgradering
10 Mb/s
access link
 Total fors.
institutionelt
netværk
10 Mb/s LAN
institutionel
cache
2: Applikationslaget
90
Caching eksempel (3)
originale
servere
Installér cache
 antag en hit rate på 0.4
Konsekvens
off.
Internet
 40% requests opfyldes næsten



=
øjeblikkeligt
60% requests opfyldes af
original-serveren
udnyttelsen af access-link
reduceres til 60%, resulterende
i forsvindende små forsinkelser
(f.eks. 10 msek)
total fors. = Internet-fors. +
access fors. + LAN fors.
0.6*2 sek + .6*0.01 sek +
millisekunder < 1.3 sek
1.5 Mb/s
access link
institutionelt
netværk
10 Mb/s LAN
institutionel
cache
2: Applikationslaget
91
Materialedistributions-netværk (CDNs)
 Materiale-udbyderne er
CDN-kunderne.
Materiale-replikation
 Et CDN-firma installerer
hundredevis af CDN-servere
i Internettet
 hos lavniveau ISP’ere tæt
på brugerne
 CDN replikerer kundernes
materiale i CDN-servere. Når
udbyderen opdaterer
indholdet, så opdaterer CDN
serverne
original server
i Nordamerika
CDN distributionsknude
CDN server
i Sydamerika
CDN server
i Europa
CDN server
i Asien
2: Applikationslaget
92
CDN eksempel
1
HTTP anmodning om
www.foo.com/sports/sports.html
Originalserver
2
3
DNS foresp. om www.cdn.com
CDNs autoritativ
DNS-server
HTTP anmodning om
www.cdn.com/www.foo.com/sports/ruth.gif
Nærliggende
CDN server
originalserver
 www.foo.com
 distributerer HTML
 Erstatter:
http://www.foo.com/sports.ruth.gif
med
http://www.cdn.com/www.foo.com/sports/ruth.gif
CDN firma
 cdn.com
 distributerer gif-filer
 bruger dets
autoritative DNSserver til at
omdirigere
requests 93
2: Applikationslaget
Mere om CDN’ere
routningsforespørgsler
ikke blot Web-sider
 CDN opretter et “kort”  streaming gemt
der giver afstande fra
audio/video
blad-ISP’ere og CDN streaming real-time
knuder
audio/video
 når en forespørgsel
 CDN knuder opretter
applikations-lags
kommer til en
overlay netværk
autoritativ DNS-server:


serveren finder ISP fra
hvilken spm. stammer
bruger “kortet” for at
finde bedste CDN server
2: Applikationslaget
94
Peer-to-peer (P2P) fildeling
 Alice vælger en af
Eksempel
 Alice kører P2P klientapplikation på sin
notebook computer
 Af og til forbinder hun
sig til Internettet og
får en ny IP-adresse
for hver forbindelse
 Beder om “Hey Jude”
 Applikationen viser
andre peers som har
kopi af Hey Jude.
peers, Bob.
 Filen kopieres fra
Bob’s PC til Alice’s
notebook: HTTP
 Mens Alice downloader
uploader andre
brugere fra Alice.
 Alice’s peer er både en
Web-klient og en
transient Web-server.
Alle peers er servere =
skalerer yderst godt!
2: Applikationslaget
95
P2P: centraliseret katalog
det originale “Napster”design
1) når peer forbinder sig
får den centrale server:


IP-adresse
materiale
2) Alice spørger om “Hey
Jude”
3) Alice beder om filen fra
Bob
Bob
centraliseret
katalog-server
1
peers
1
3
1
2
1
Alice
2: Applikationslaget
96
P2P: problemer med centralt katalog
 Enkelt fejlpunkt
 Ydelses-flaskehals
 Copyright-krænkelse
fil-overførslen er
decentral, men
lokalisering af
indhold er meget
centraliseret
2: Applikationslaget
97
P2P: decentraliseret katalog
 Hver peer er enten
gruppeleder eller
knyttet til en gruppeleder.
 Gruppelederne holder
styr på indholdet i alle
dets børn.
 Peers spørger
gruppeledere; gruppeledere kan spørge
andre gruppeledere.
ordinary peer
group-leader peer
neighoring relationships
in overlay network
2: Applikationslaget
98
Mere om decentraliserde kataloger
overlay netværk
 peers er knuder
 kanter mellem peers og
deres gruppeledere
 kanter mellem nogle par
af gruppeledere
 virtuelle naboer
bootstrap knude
 en tilkoblet peer er
enten knyttet til en
gruppeleder eller
udpeges til leder
ved tilgangen
 ingen centraliseret
katalog-server


localiserings-service
distribueres over peers
vanskeligere at lukke ned
ulemper ved tilgangen
 brug for bootstrapknude
 gruppeledere kan blive
overbelastede
2: Applikationslaget
99
P2P: Query flooding
 Gnutella
 Send forespørgsel til naboer
 intet hierarki
 bruger bootstrapknude
til at erfare om andre
 gå ind (join) besked
 Naboer videresender
forespørgslen
 Hvis en forespurgt peer har
objektet, sender den besked
tilbage til den spørgende peer
join
2: Applikationslaget
100
P2P: mere om query flooding
For
 peers har samme
ansvar: ingen
gruppeledere
 yderst decentraliseret
 ingen peer har kataloginfo
Imod
 stor query trafik
 query radius: maskiner
indenfor har måske
ikke materialet, når de
er på
 bootstrap-knude
 vedligeholdelse af
overlay netværk
2: Applikationslaget
101
Kapitel 2: Resumé
Studiet af netværksapplikationer komplet!
 applikationsydelser,
 specifikke protokoller:
krav:
 HTTP
 pålidelighed, båndbredde
 FTP
og forsinkelse
 SMTP, POP, IMAP
 client-server paradigmet
 DNS
 Internet transport
service model


 socket programmering
 materiale-distribution
forbindelses-orienteret og
 caches, CDN’ere
pålidelig: TCP
 P2P
upålidelig og datagram: UDP
2: Applikationslaget
102
Kapitel 2: Resumé
Vigtigst: vi har lært om protokoller
 typisk request/reply
beskedudveksling:


klienten beder om info
eller ydelse
serveren svarer med
data og statuskode
 besked-formater:
 headere: felter, der
giver info om data
 data: info der
kommunikeres
 kontrol- kontra data-beskeder
in-band, out-of-band
centraliserede/decentraliserede
tilstandsløse kontra med tilstand
pålidelig kontra upålidelig
beskedoverførsel
“kompleksitet ved nettets kant”
sikkerhed: autentifikation






2: Applikationslaget
103