Transcript Part I: Introduction
Reti di calcolatori e Sicurezza
--
Application Layer
-- Part of these slides are adapted from the slides of the book: Computer Networking: A Top Down Approach Featuring the Internet, 2nd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2002. J.F Kurose and K.W. Ross, All Rights Reserved) Introduction 1-1
Chapter 2: Application Layer
Our goals: conceptual, implementation aspects of network application protocols transport-layer service models client-server paradigm peer-to-peer paradigm learn about protocols by examining popular application-level protocols HTTP FTP SMTP / POP3 / IMAP DNS programming network applications socket API Introduction 1-2
Chapter 2 outline
2.1 Principles of app layer protocols clients and servers app requirements 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 Socket programming with TCP (facoltativo) 2.7 Socket programming with UDP (facoltativo) 2.8 Building a Web server (facoltativo) 2.9 Content distribution (self study) Network Web caching Content distribution networks P2P file sharing Introduction 1-3
Applicazioni
Applicazioni di rete Insieme di processi distribuiti: sono in esecuzione su di un host connesso in rete Cooperano tramite scambio di messaggi e.g., email, file transfer, P2P file sharing, IM, Web, Protocolli del livello delle applicazioni Una componente delle applicazioni di rete Definiscono la struttura dei msg Richieste di servizio ai livelli inferiori application transport network data link physical application transport network data link physical application transport network data link physical Introduction 1-4
Protocolli livello applicazioni
Tipo dei msg scambiati Sintassi dei msg Semantica header dei msg Regole di elaborazione Public-domain protocols: RFC Interoperability HTTP, SMTP Proprietary protocols: KaZaA Introduction 1-5
Terminologia comune
user agent : interfaccia tra le applicazioni di rete ed i protocolli di comunicazione livello delle applicazioni .
del
Web:browser E-mail: mail reader App. audio/video: player Introduction 1-6
Il modello Client - Server
Si identificano due componenti:
client
e
server
Client: Connette al server (“speaks first”) Effettua la richiesta del servizio, E.g. Web: cliente è il browser; e-mail: cliente è il mail reader Server: Fornisce un certo numero di servizi (in risposta alle richieste del cliente) Web server invia le pagine richieste application transport network data link physical request reply application transport network data link physical Introduction 1-7
Processes communicating across network
process sends/receives messages to/from its socket host or server controlled by host or server app developer socket analogous to door process process sending process shoves message out door sending process asssumes transport infrastructure on other side of door which brings message to socket at receiving process socket TCP with buffers, variables controlled by OS Internet socket TCP with buffers, variables API: (1) choice of transport protocol; (2) ability to fix a few parameters (lots more on this later) Introduction 1-8
Addressing processes:
For a process to receive messages, it must have an identifier Every host has a unique 32-bit IP address Q: does the IP address of the host on which the process runs suffice for identifying the process?
Answer: No, many processes can be running on same host Identifier includes both the IP address and port numbers associated with the process on the host.
Example port numbers: HTTP server: 80 Mail server: 25 More on this later Introduction 1-9
Quali sono I requisiti di servizio delle applicazioni di rete
Data loss Alcune app. (e.g., audio) possono tollerare la perdita di dati Altre app. (e.g., file transfer, telnet) richiedono il 100% di affidabilità nella trasmissione dei dati Bandwidth Timing App (e.g., Internet telephony) non possono ammettere dei ritardi nella trasmissione dei dati Alcune app. (e.g., multimedia) richiedono di avere almeno un determinato livello di banda per poter operare Altre applicazioni (“elastic apps”) non fanno richieste sulla banda di trasmissione Introduction 1-10
Requisiti applicazioni
Application Data loss Bandwidth Time Sensitive
file transfer e-mail Web documents real-time audio/video no loss no loss no loss loss-tolerant stored audio/video interactive games instant messaging loss-tolerant loss-tolerant no loss elastic elastic elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up elastic no no no yes, 100’s msec yes, few secs yes, 100’s msec yes and no Introduction 1-11
I servizi di trasporto
TCP:
connection-oriented:
richiede una fase di inizializzazione
affidabile Controllo del flusso e della congestione Non fornisce:
timing, e un livello minimo di banda
UDP:
Non affidabilie No controllo del flusso e della congestione D: Come mai esiste UDP?
Introduction 1-12
Internet apps: application, transport protocols
Application Application layer protocol
e-mail remote terminal access Web file transfer streaming multimedia Internet telephony SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietary (e.g. RealNetworks) proprietary (e.g., Dialpad)
Underlying transport protocol
TCP TCP TCP TCP TCP or UDP typically UDP Introduction 1-13
Seminari approfondimento
2004: QoS 2004: Teleconferenze
Introduction 1-14
Chapter 2 outline
2.1 Principles of app layer protocols clients and servers app requirements 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 Socket programming with TCP 2.7 Socket programming with UDP 2.8 Building a Web server 2.9 Content distribution Network Web caching Content distribution networks P2P file sharing Introduction 1-15
Web and HTTP
First some jargon Web page consists of objects Object can be HTML file, JPEG image, Java applet, audio file,… Web page consists of base HTML-file includes several referenced objects which Each object is addressable by a URL Example URL: www.someschool.edu/someDept/pic.gif
host name path name Introduction 1-16
HTTP overview
HTTP: hypertext transfer protocol Web’s application layer protocol client/server model
client:
browser that requests, receives, “displays” Web objects
server:
Web server sends objects in response to requests HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 PC running Explorer Mac running Navigator Server running Apache Web server Introduction 1-17
HTTP overview (continued)
Uses TCP: client initiates TCP connection (creates socket) to server, port 80 server accepts TCP connection from client HTTP messages (application layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server) TCP connection closed HTTP is “stateless” server maintains no information about past client requests Protocols that maintain “state” are complex!
aside past history (state) must be maintained if server/client crashes, their views of “state” may be inconsistent, must be reconciled Introduction 1-18
HTTP connections
Nonpersistent HTTP At most one object is sent over a TCP connection.
HTTP/1.0 uses nonpersistent HTTP Persistent HTTP Multiple objects can be sent over single TCP connection between client and server.
HTTP/1.1 uses persistent connections in default mode Introduction 1-19
Nonpersistent HTTP
Suppose user enters URL www.someSchool.edu/someDepartment/home.index
(contains text, references to 10 jpeg images) 1a .
HTTP client initiates TCP connection to HTTP server (process) at www.someSchool.edu on port 80 1b.
HTTP server at host www.someSchool.edu client waiting for TCP connection at port 80. “accepts” connection, notifying 2.
HTTP client sends HTTP
request message
(containing URL) into TCP connection socket. Message indicates that client wants object someDepartment/home.index
3.
HTTP server receives request message, forms
message response
containing requested object, and sends message into its socket time Introduction 1-20
Nonpersistent HTTP (cont.)
time 5 .
HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects 6.
Steps 1-5 repeated for each of 10 jpeg objects 4.
HTTP server closes TCP connection. Introduction 1-21
Response time modeling
Definition of RRT: server and back.
Response time: time to send a small packet to travel from client to one RTT to initiate TCP connection one RTT for HTTP request and first few bytes of HTTP response to return file transmission time total = 2RTT+transmit time initiate TCP connection RTT request file RTT file received time time to transmit file time Introduction 1-22
Persistent HTTP
Nonpersistent HTTP issues: requires 2 RTTs per object OS must work and allocate host resources for each TCP connection but browsers often open parallel TCP connections to fetch referenced objects Persistent HTTP server leaves connection open after sending response subsequent HTTP messages between same client/server are sent over connection Persistent without pipelining: client issues new request only when previous response has been received one RTT for each referenced object Persistent with pipelining: default in HTTP/1.1
client sends requests as soon as it encounters a referenced object as little as one RTT for all the referenced objects Introduction 1-23
Non Persistente vs persistente
Introduction 1-24
Persistente: non pipeling vs pipeling
Introduction 1-25
HTTP request message
two types of HTTP messages: request, response HTTP request message: ASCII (human-readable format) request line (GET, POST, HEAD commands) header lines
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu User-agent: Mozilla/4.0
Connection: close Accept-language:fr
Carriage return, line feed indicates end of message (extra carriage return, line feed) Introduction 1-26
HTTP request message: general format
Introduction 1-27
Uploading form input
Post method: Web page often includes form input Input is uploaded to server in entity body URL method: Uses GET method Input is uploaded in URL field of request line: www.somesite.com/animalsearch?monkeys&banana Introduction 1-28
Method types
HTTP/1.0
GET POST HEAD asks server to leave requested object out of response HTTP/1.1
GET, POST, HEAD PUT uploads file in entity body to path specified in URL field DELETE deletes file specified in the URL field Introduction 1-29
HTTP response message
status line (protocol status code status phrase) header lines
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, e.g., requested HTML file
data data data data data ...
Introduction 1-30
HTTP response status codes
In first line in server->client response message.
A few sample codes:
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
Introduction 1-31
Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server:
telnet www.eurecom.fr 80
Opens TCP connection to port 80 (default HTTP server port) at www.eurecom.fr.
Anything typed in sent to port 80 at www.eurecom.fr
2. Type in a GET HTTP request:
GET /~ross/index.html HTTP/1.0
By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP server 3. Look at response message sent by HTTP server!
Introduction 1-32
esercizio
Come si fa a far rispondere al server
301 Moved Permanently
requested object moved, new location specified later in this message (Location:) Introduction 1-33
User-server interaction: authorization
Authorization : control access to server content client authorization credentials: typically name, password stateless: client must present authorization in each request server usual http request msg 401: authorization req.
WWW authenticate:
authorization: each request header line in if no sends authorization : header, server refuses access, usual http request msg + Authorization:
WWW authenticate:
header line in response usual http request msg + Authorization:
Cookies: keeping “state”
Many major Web sites use cookies Four components: 1) cookie header line in the HTTP response message 2) cookie header line in HTTP request message 3) cookie file kept on user’s host and managed by user’s browser 4) back-end database at Web site Example: Susan access Internet always from same PC She visits a specific e commerce site for first time When initial HTTP requests arrives at site, site creates a unique ID and creates an entry in backend database for ID Introduction 1-35
Cookies: keeping “state” (cont.)
Cookie file
ebay: 8734 client server usual http request msg usual http response +
Set-cookie: 1678
server creates ID 1678 for user
Cookie file
amazon: 1678 ebay: 8734 one week later:
Cookie file
amazon: 1678 ebay: 8734 usual http request msg
cookie: 1678
usual http response msg usual http request msg
cookie: 1678
usual http response msg cookie specific action cookie spectific action Introduction 1-36
Cookies (continued)
What cookies can bring: authorization shopping carts recommendations user session state (Web e-mail) aside Cookies and privacy: cookies permit sites to learn a lot about you you may supply name and e-mail to sites search engines use redirection & cookies to learn yet more advertising companies obtain info across sites Introduction 1-37
Conditional GET: client-side caching
Goal: don’t send object if client has up-to-date cached version client: specify date of cached copy in HTTP request
If-modified-since:
server: response contains no object if cached copy is up to-date:
HTTP/1.0 304 Not Modified
client HTTP request msg
If-modified-since:
HTTP response
HTTP/1.0 304 Not Modified
HTTP request msg
If-modified-since:
HTTP response
HTTP/1.0 200 OK
server object not modified object modified Introduction 1-38
Seminari
2004: Cookies Tipi di autenticazione su web Gestione sessioni in http Web services
Introduction 1-39
Chapter 2 outline
2.1 Principles of app layer protocols clients and servers app requirements 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 Socket programming with TCP 2.7 Socket programming with UDP 2.8 Building a Web server 2.9 Content distribution Network Web caching Content distribution networks P2P file sharing Introduction 1-40
ftp: file transfer protocol
FTP user interface FTP client file transfer FTP server user File system locale Sistema remoto Funzionalità: trasferimento di dati (files) da/per il sistema remoto Architettura software: client/server
client:
il sistema che attiva il trasferimento
server:
il sistema remoto ftp: RFC 959 ftp server: port 21 Introduction 1-41
FTP: separate control, data connections
FTP client contacts FTP server at port 21, specifying TCP as transport protocol Client obtains authorization over control connection Client browses remote directory by sending commands over control connection.
When server receives a command for a file transfer, the server opens a TCP data connection to client After transferring one file, server closes connection.
TCP control connection port 21 FTP client TCP data connection port 20 FTP server Server opens a second TCP data connection to transfer another file.
Control connection: “out of band” FTP server maintains “ state ”: current directory, earlier authentication Introduction 1-42
FTP commands, responses (PROVATELI!!)
Sample commands: sent as ASCII text over control channel
USER username
PASS password
LIST
return list of file in current directory
RETR filename
(gets) file retrieves
STOR filename
(puts) file onto remote host stores Sample return codes status code and phrase (as in HTTP)
331 Username OK, password required
125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file
Introduction 1-43
Seminari
Server/client ftp in Java
Introduction 1-44
Chapter 2 outline
2.1 Principles of app layer protocols clients and servers app requirements 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 Socket programming with TCP 2.7 Socket programming with UDP 2.8 Building a Web server 2.9 Content distribution Network Web caching Content distribution networks P2P file sharing Introduction 1-45
Strumenti per l’interazione fra utenti: la posta elettronica
Caratteristiche:
velocità versatilità economicità Indipendenza dal tempo e dallo spazio Introduction 1-46
Posta elettronica: gli strumenti necessari
Mailbox (casella postale) indirizzo posta elettronica
PC connesso ad Internet
programma “client” sul PC
Introduction 1-47
La Mailbox •E’ il contenitore elettronico dei messaggi ricevuti
Normalmente risiede su un calcolatore potente e sempre connesso alla rete Ha associato un indirizzo di posta elettronica Introduction 1-48
Un applicativo di rete: la posta elettronica
La posta elettronica (e-mail) consente di spedire messaggi ad altri utenti connessi ad Internet.
I messaggi sono tipicamente preparati con programmi di videoscrittura.
Ad essi possono essere allegati video e/o audio.
Gli indirizzi hanno la forma del seguente esempio: nome utente nome dominio separatore
Introduction 1-49
Clienti di posta elettronica
Eudora, Microsoft Outlook, Netscape messager, Pine, Rmail … Comunicano con il server mediante il protocollo SMTP Funzionalità Risposta Inoltro Archiviazione e recupero messaggi Reindirazzamento Vacation Introduction 1-50
Tecnica store-and-forward
•
[email protected]
posta elettronica a manda un messaggio di
[email protected].
• Il messaggio viene depositato sul server di posta di
domain.com
.
• Il messaggio viene recapitato al destinario solo quando questo si collega al sistema.
Introduction 1-51
Tecnica store-and-forward
Introduction 1-52
•
Tecnica store-and-forward [email protected]
manda un messaggio di posta elettronica a
[email protected]
• Il messaggio viene inviato dal server di posta di
domain.com
al server di posta di
anotherdomain.com
• Come nel caso precedente, il messaggio viene recapitato al destinario solo quando questo si collega al sistema • Quindi la tecnica scala facilmente Introduction 1-53
Funzioni del servizio: lettura dei messaggi
• Protocollo POP3 • Username + password • Trasferimento messaggi sul PC e successiva lettura Introduction 1-54
Funzioni del servizio: spedizione dei messaggi
Mail da spedire (indirizzo, subject, testo) (SMTP) (SMTP)
INTERNET
Introduction 1-55
E-Mail: smtp [RFC 821]
Basato su tcp per avere un trasferimento affidabile delle mail, la porta 25 è la porta di default Trasferimento diretto tra i server coinvolti effettuato in tre passi denominati: handshaking (greeting) transfer closure Modalità di interazione: command/response command: response: testo in formato ASCII status code e testo Messaggi sono codificati in 7-bit ASCII Introduction 1-56
Scenario: Alice e Bob
1) Alice vuole inviare una e mail a [email protected]
2) Messsaggio è inserito nella coda del mail server 3) SMTP (lato cliente) apre una connessione TCP con il mail server di Bob 4) SMTP (lato cliente) trasmette il messaggio di Alice sulla connessione TCP 5) Il mailserver di Bob memorizza il messaggio nella mailbox di Bob 6) Bob legge il messaggio tramite il suo user agent 1 user agent 2 mail server 3 4 mail server 5 6 user agent Introduction 1-57
Esempio di interazione smtp
S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM:
Introduction 1-58
Piccole esercitazione:
telnet server_di_posta 25
220 reply from server Digitare i comandi HELO, MAIL FROM, RCPT TO, DATA, QUIT Introduction 1-59
smtp
smtp utilizza connessioni persistenti Smtp: formato dei messaggi (header & body) in 7-bit ascii Caratteri non permessi (e.g., CRLF.CRLF
quoted printable) ). Codifica dei messaggi (in base-64 o smtp server: utilizza CRLF.CRLF
per indicare la fine del msg Smtp vs http http: pull email: push Interazione ASCII di tipo command/response + status codes http: ogni oggetto è incapsulato nella risposta smtp: multipart message con oggetti multipli (eg attachment) Introduction 1-60
Seminari
MIME,smime,etc
Introduction 1-61
POP3-IMAP4
Introduction 1-62
Accesso alla posta
Esistono diversi protocolli per costruire una infrastruttura distribuita per la gestione delle email. I piu’ diffusi sono: POP3 - Post Office Protocol versione 3 • Protocollo molto ‘vecchio’ quindi molto diffuso • Semplice • Gestisce la posta in “locale”: scarica i messaggi!
IMAP4 - Internet Message Access Protocol (ver 4) • Piu’ complesso del POP3 • Permette la gestione delle mailbox remote come se fossero locali Introduction 1-63
POP3
Funziona con paradigma client-server Supporta le funzioni di base per il recupero della posta elettronica da mailbox remota
Download Delete Introduction 1-64
Come funziona
Il client POP3 si connette tramite TCP alla porta 110 del server Il server POP3 risponde con messaggio di benvenuto La sessione entra nello stato di
autenticazione
Il client manda la sua idetificazione (user-id e password) Se il server riconosce il client si entra nello stato di
transazione
Il client puo’ accedere alla mailbox Quando il client esegue il comando quit si entra nello stato
update
e la connessione e’ chiusa Introduction 1-65
IMAP4
Supporta i modelli di posta elettronica
Off-line
(POP3): il client si connette periodicamente al server e scarica i messaggi (processati localmente)
On-line
il client esegue delle modifiche sul server (accesso tramite protocollo di file system remoto NFS)
Disconnected
: (modo “ibrido”) il client si connette al server, scarica i messaggi, li processa localmente e poi li aggiorna sul server Connessione su porta 143 Introduction 1-66
POP3
authorization phase client:
user:
username
pass:
password Server:
+OK
-ERR
transaction phase, client:
list:
list (message numbers)
retr:
retrieve message
dele:
delete
quit S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on C: list S: 1 498 S: 2 912 S: . C: retr 1 S:
Introduction 1-67
Confronto POP3-IMAP4
POP3= recupero su richiesta verso un singolo client IMAP4= accesso interattivo a piu’ mailbox da piu’ client Vantaggi filosofia POP3: Uso minimo del tempo di connessione.
Uso minimo delle risorse del server.
Vantaggi filosofia IMAP4: Possibilita’ di usare diversi computer in tempi diversi Possibilita’ di usare macchine con client “senza-dati” (nei laboratori).
Accesso indipendente dalla piattaforma Accesso concorrente a mailbox condivise.
Introduction 1-68
Posta elettronica: e-mail
Per lo scambio di messaggi elettronici Un messaggio contiene:
Uno o più destinatari nel campo TO Destinatari per conoscenza (CC) Destinatari per conoscenza “in incognito” (BCC) Subject: tema del messaggio Testo del messaggio Eventuali allegati Introduction 1-69
Convenzioni e netiquette
Comunicazione di stati d’animo con le faccette: ( emoticons :-( triste ) :-) sorridente e scherzoso ;-) malizioso :-I indifferente :-> sarcastico >:-> diabolico :-/ perplesso :-D sorpreso :-O molto sorpreso >;-> ammiccante e diabolico Usare lettere maiuscole equivale ad URLARE Introduction 1-70
Il lingo
AFAIK As Far As I Know
AKA
Also Known As BBIAB Be Back in a Bit BBIAF Be Back in a Few
BBL BFN BTW CID CIO
By The Way Consider It Done Check It Out CUL8R See You Later
FYA FYI GTSY
Be Back Later Bye For Now For Your Amusement For Your Information Glad To See Ya
GYPO IMO IOW IRL KIT MOTD POV RSN RTM TIA TX TYVM WB
Get Your Pants Off In My Opinion In Other Words In Real Life Keep In Touch Message Of The Day Point of View Real Soon Now Read The Manual Thanks in Advance Thanks Thank You Very Much Welcome Back Introduction 1-71
Attachments • tecnica per spedire via E-mail ogni tipo di file • codifica e decodifica automatiche con i migliori client • limitare dimensione (< 1 mb)
Introduction 1-72
MIME: multimedia extensions
MIME: multimedia mail extension, RFC 2045, 2056 Campi addizionali presenti per la dichiarazione dei MIME content type MIME version Metodo di codifica Dati multimediali type, subtype, parameter Dati codificati
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
Introduction 1-73
MIME types
Content-Type: type/subtype; parameters
Text subtypes:
plain, html
Video
subtypes:
mpeg, quicktime
Image subtypes:
jpeg, gif
Audio subtypes:
basic
(8-bit coding),
32kadpcm (32 kbps coding)
Applications
Invocate per rendere “viewable” questi tipi subtypes:
msword, octet-stream
Introduction 1-74
Multipart Type Message
From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe.
--98766789 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data --98766789--
Introduction 1-75
Return-Path:
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C49BE9.77729620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-Antivirus-Summary: Mod score: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on gotham.sci.unich.it
X-Spam-Level: X-Spam-Status: No, hits=-4.8 required=3.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=2.63
Introduction 1-76
Chapter 2 outline
2.1 Principles of app layer protocols clients and servers app requirements 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 Socket programming with TCP 2.7 Socket programming with UDP 2.8 Building a Web server 2.9 Content distribution Network Web caching Content distribution networks P2P file sharing Introduction 1-77
Domain Name Server (DNS) pluto.sci.unich.it ?
192.167.92.33 !
158.110.1.7
Introduction 1-78
DNS: le funzioni
ad ogni risorsa TCP/IP può essere assegnato un nome
simbolico
sono necessari: un metodo per associare il nome simbolico di una macchina all’indirizzo (o agli indirizzi) IP: risoluzione diretta un metodo per associare ad un indirizzo IP al nome simbolico della macchina: risoluzione inversa Domain Name System (DNS) definito presso ISI - USC 1984 RFC 882, RFC 883, RFC 973 (obsolete) RFC 1034, RFC 1035, RFC 1123, RFC 1537, RFC 1912 Introduction 1-79
Un po’ di storia
Ai tempi di ARPANET esisteva in ogni sistema opertivo un unico file, hosts.txt, che elencava tutti gli host e i loro indirizzi IP. Ogni notte tutti gli host della rete lo copiavano dal sito in cui era mantenuto Quando la rete comprendeva solo qualche centinaio di grosse macchine questo approccio funzionava bene; quando la rete crebbe venne inventato il servizio DNS (Domain Name Server), definito nei documenti RFC 1034 e 1035 Introduction 1-80
DNS: caratteristiche principali
database distribuito basato sul modello client/server tre componenti principali: • spazio dei nomi e informazioni associate (Resource Record - RR) • nameserver (application server che mantiene i dati) • resolver (client per l’interrogazione del nameserver) accesso veloce ai dati (database in memoria centrale e meccanismo di caching) Introduction 1-81
Esempio
Hosts
cheltenham.cs.princeton.edu 192.12.69.17
192.12.69.17 80:23:A8:33:5B:9F
Files
/usr/llp/tmp/foo (server, fileid)
Users
Stefano Bistarelli [email protected]
Introduction 1-82
Esempio
Mailboxes
2 cs.princeton.edu
User 1 user @ cs.princeton.edu
Name server Mail program 192.12.69.5
4 192.12.69.5
3 TCP 192.12.69.5
5 IP Introduction 1-83
Lo spazio dei nomi
lo spazio dei nomi è organizzato secondo il modello gerarchico: • il database del DNS ha una struttura logica “ad albero rovesciato” • ciascun nodo dell’albero rappresenta un dominio • ogni dominio può essere suddiviso in altri domini: sottodomini • ogni nodo ha una etichetta che lo identifica rispetto al padre La radice dell'albero è unica, e la sua etichetta è vuota. In certi casi si indica anche come “.” struttura dello spazio dei nomi: • domini generali (gTLD) • domini nazionali (ccTLD) • domini per la risoluzione inversa (arpa) Introduction 1-84
DNS
Gerarchia di naming
edu com gov mil org princeton … mit cisco … yahoo nasa … nsf arpa … navy acm … ieee net uk fr cs ux01 ux04 ee physics Introduction 1-85
Gerarchie di naming
Il nome di un dominio è composto dal cammino inverso dalla foglia fino alla radice (anonima); i componenti del cammino sono separati da punti. I nomi dei domini sono insensibili alle maiuscole/minuscole I nomi all’interno dei cammini possono essere lunghi al più 63 caratteri, mentre un cammino non può superare complessivamente i 255 caratteri Esempio: il dominio del dipartimento di scienze a Pescara è sci.unich.it
Introduction 1-86
Interrogare il DNS
Il programma nslookup permette di interrogare il DNS Per convertire un nome di dominio in numero IP Per convertire un numero IP in nome di dominio La funzione nslookup è presente in tutti i sistemi operativi (es Windows 2000) Il sito Web www.infobear.com/nslookup.shtml permette di interrogare via Web il DNS al registro della Registration Authority italiana Introduction 1-87
Name Servers
In teoria un solo name server potrebbe contenere server sarebbe così sovraccarico da essere inservibile. Inoltre, se mai si guastasse, l’intera Internet sarebbe bloccata.
Nota: Nel 2000 c’erano solo 13 root name servers:10 negli USA, uno a Londra, uno a Stoccolma, uno a Tokyo www.icann.org/committees/dns-root/y2k statement.htm
Introduction 1-88
Zone
Lo spazio dei nomi DNS è suddiviso in zone non sovrapposte (cioè senza intersezione); normalmente una zona avrà un name server principale, che legge informazioni da un file sul proprio disco, ed uno o più name server secondari, che prendono le loro informazioni dal name server principale Per migliorare l’affidabilità, è possibile che alcuni server di zona si trovino al di fuori della zona stessa.
Dove siano posti i confini di una zona è affare dell’amministratore della zona. Questa decisione è in gran parte basata su quanti name server si vogliono e dove vanno collocati. Introduction 1-89
Name Servers
Partizione della gerarchia in zone
cs edu com gov mil org princeton …mit cisco …yahoo nasa …nsf arpa …navy acm …ieee net uk fr ee physics ux01 ux04
Ogni zona può avere due o piu’ name servers
Root name server Princeton name server … Cisco name server CS name server … EE name server Introduction 1-90
DNS name servers
DNS centralizzato Punto di fallimento globale Volume di traffico elevato Database remoto maintenance Non scala!!!
Nessun server memorizza l’associazione name-to-IP address per tutta Internet local name servers: ogni ISP ha un
local (default) name server
Primo passo: query al local name server authoritative name server: host: memorizza l’indirizzo IP ed il nome del sistema Effettua la traduzione name/IP address translation Introduction 1-91
DNS
Quando un programma deve trasformare un nome risolutrice (resolver), passandole il nome come parametro di ingresso. Il resolver interroga un server DNS locale, che cerca il nome nelle sue tabelle e restituisce l’indirizzo al resolver, che a sua volta lo trasmette al programma chiamante (usando tale indirizzo IP il programma può aprire una connessione di rete con Introduction 1-92
DNS: Root name servers
Contattati dai name server locali root name server: Interagiscono con il name server di autorità (se non possono risolvere direttamente ilo nome) Ottengono il mapping Restituiscono il risultato e NASA Mt View, CA f Internet Software C. Palo Alto, CA 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 b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA 13 root name servers worldwide Introduction 1-93
DNS: Un Esempio
root name server host
surf.eurecom.fr
vuole determinare l’indirizzo IP del nome
gaia.cs.umass.edu
1.
2.
3.
Collegamento con il server DNS locale
dns.eurecom.fr
dns.eurecom.fr
al root name server (se necessario) si collega 1 2 6 root name server si collega all’authoritative name server,
dns.umass.edu,(se
necessario) requesting host
surf.eurecom.fr
5 local name server
dns.eurecom.fr
3 4 authorititive name server
dns.umass.edu
gaia.cs.umass.edu
Introduction 1-94
DNS
Root name server: Potrebbe non conoscere l’authoratiative name server Potrebbe conoscere un
intermediate name server:
contattare per collegarsi con il server Il server da authoritative name 2 root name server 7 3 6 local name server
dns.eurecom.fr
1 8 intermediate name server
dns.umass.edu
4 5 requesting host
surf.eurecom.fr
authoritative name server
dns.cs.umass.edu
gaia.cs.umass.edu
Introduction 1-95
DNS: queries
root name server recursive query: Meccanismo di trasmissione delle query tra i vari name server iterated query: server restituisce il nome del name server da contattare per risolvere la query “I don’t know this name, but ask this server” 2 local name server
dns.eurecom.fr
1 8 requesting host
surf.eurecom.fr
3 iterated query 4 7 intermediate name server
dns.umass.edu
5 6 authoritative name server
dns.cs.umass.edu
gaia.cs.umass.edu
Introduction 1-96
DNS: caching
Un generico name server può effetttuare una operazione di
caching
per memorizzare i risultati delle query Elementi della cache diventano “vecchi” Meccanismi per update/notify sono in fase di progetto RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html
Introduction 1-97
DNS records
DNS: distributed db che memorizza resource records (RR) RR format:
(name, value, type,ttl)
Type=A
name value
is hostname is IP address Type=NS
name
is domain (e.g. foo.com)
value
is IP address of authoritative name server for this domain Type=CNAME
name
m.com
è un alias di un nome “canonico” www.ibm.com è servereast.backup2.ib
Value è il nome canonico
Type=MX
value
mailserver associated with
name
is hostname of Introduction 1-98
$TTL 43200 @ IN SOA ns.mesys.it. hostmaster.mesys.it. ( 2002053101 ; serial 86400 ; refresh 3600 ; retry 604800 ; expire 86400 ; default_ttl ) @ IN MX 5 mail.mesys.it.
@ IN NS ns.mesys.it.
@ IN NS dns2.nic.it.
localhost IN A 127.0.0.1
ns IN A 151.4.83.2
ns1 IN A 151.4.83.3
mail IN A 151.4.83.2
www IN CNAME turtle.mesys.it.
ftp IN CNAME dolphin.mesys.it.
Introduction 1-99
C:\Documents and Settings\bista>nslookup Server predefinito: deimos.unich.it
Address: 192.167.13.102
> set querytype=ANY > sci.unich.it
Server: deimos.unich.it
Address: 192.167.13.102
sci.unich.it
primary name server = deimos.unich.it
responsible mail addr = root.deimos.unich.it
serial = 2002061901 refresh = 86400 (1 day) retry = 1800 (30 mins) expire = 2592000 (30 days) default TTL = 432000 (5 days) sci.unich.it nameserver = deimos.unich.it
sci.unich.it nameserver = dns2.unich.it
sci.unich.it MX preference = 10, mail exchanger = gotham.sci.unich.it
dns2.unich.it internet address = 192.167.14.208
deimos.unich.it internet address = 192.167.13.102
gotham.sci.unich.it internet address = 192.167.14.11
> Introduction 1-100
DNS protocol, messages
DNS protocol :
query
/
reply
Identico
message format
messages, msg header identification: query, reply to query uses same # 16 bit # for flags: query or reply recursion desired recursion available reply is authoritative Introduction 1-101
DNS protocol, messages
Name, type fields for a query RRs in reponse to query records for authoritative servers additional “helpful” info that may be used Introduction 1-102
DNS
Protocollo di trasporto: UDP Porta: 53
… bugia ..
Introduction 1-103
Esercizi e seminari
Scoprire per quali messaggi DNS usa la porta 53 e il TCP (invece che l’UDP)
2004-Seminario su configurazioni del DNS 2005-Seminario su DNSSEC (due persone) dopo che abbiamo fatto crittografia (novembre)
www.dnssec.net
Introduction 1-104
Hint seminario configurazione dns Acl options { directory "/var/named"; pid-file "named.pid"; allow-transfer { mesysslaves; }; allow-recursion { mesysnets; }; blackhole { bogusnets; }; };
Introduction 1-105
DNS Data flow
Zone administrator Zone file Dynamic updates master slaves resolver stub resolver Introduction 1-106
DNS Vulnerabilities
Cache impersonation
Zone administrator
Corrupting data
Zone file master
Impersonating master
resolver Dynamic updates slaves
Unauthorized updates Server Protection
stub resolver
Cache pollution by Data spoofing Data Protection
Introduction 1-107
Chapter 2 outline
2.1 Principles of app layer protocols clients and servers app requirements 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS
2.6 Socket programming with TCP 2.7 Socket programming with UDP 2.8 Building a Web server 2.9 Content distribution Network Web caching Content distribution networks P2P file sharing Introduction 1-108
Socket programming
Goal: learn how to build client/server application that communicate using sockets Socket API introduced in BSD4.1 UNIX, 1981 explicitly created, used, released by apps client/server paradigm two types of transport service via socket API: unreliable datagram reliable, byte stream oriented socket a
host-local
,
application-created
,
OS-controlled
interface (a “door”) into which application process can both send and receive messages to/from another application process Introduction 1-109
Socket-programming using TCP
Socket: a door between application process and end end-transport protocol (UCP or TCP) TCP service: reliable transfer of
bytes
from one process to another controlled by application developer controlled by operating system process socket TCP with buffers, variables host or server internet process socket TCP with buffers, variables host or server controlled by application developer controlled by operating system Introduction 1-110
Socket programming
with TCP
Client must contact server server process must first be running server must have created socket (door) that welcomes client’s contact Client contacts server by: creating client-local TCP socket specifying IP address, port number of server process When client creates socket : client TCP establishes connection to server TCP When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk with multiple clients source port numbers used to distinguish clients (more in Chap 3) application viewpoint
TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server
Introduction 1-111
Stream jargon
A stream is a sequence of characters that flow into or out of a process.
An input stream is attached to some input source for the process, eg, keyboard or socket.
An output stream is attached to an output source, eg, monitor or socket.
Introduction 1-112
Socket programming with TCP
keyboard monitor Example client-server app: 1) client reads line from standard input ( socket (
inFromUser
stream) , sends to server via
outToServer
stream) 2) server reads line from socket 3) server converts line to uppercase, sends back to client 4) client reads, prints modified line from socket (
inFromServer
stream) Client Process input stream output stream input stream client TCP clientSocket socket TCP socket to network from network Introduction 1-113
Client/server socket interaction: TCP
Server (running on
hostid
) create socket, port=
x
, for incoming request: welcomeSocket = ServerSocket() wait for incoming connection request connectionSocket = welcomeSocket.accept() TCP connection setup Client create socket, connect to
hostid
, port=
x
clientSocket = Socket() send request using clientSocket read request from connectionSocket write reply to connectionSocket close connectionSocket read reply from clientSocket close clientSocket Introduction 1-114
Example: Java client (TCP)
Create input stream Create client socket, connect to server Create output stream attached to socket import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream()); Introduction 1-115
Example: Java client (TCP), cont.
Create input stream attached to socket Send line to server Read line from server } } BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine(); System.out.println
("FROM SERVER: " + modifiedSentence ); clientSocket.close(); Introduction 1-116
Example: Java server (TCP)
import java.io.*; import java.net.*; Create welcoming socket at port 6789 Wait, on welcoming socket for contact by client Create input stream, attached to socket class TCPServer { 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())); Introduction 1-117
Example: Java server (TCP), cont
Create output stream, attached to socket Read in line from socket DataOutputStream outToClient = new DataOutputStream (connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; Write out line to socket } } } outToClient.writeBytes(capitalizedSentence); End of while loop, loop back and wait for another client connection Introduction 1-118
Chapter 2 outline
2.1 Principles of app layer protocols clients and servers app requirements 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 Socket programming with TCP 2.7 Socket programming with UDP 2.8 Building a Web server 2.9 Content distribution Network Web caching Content distribution networks P2P file sharing Introduction 1-119
Socket programming
with UDP
UDP: no “connection” between client and server no handshaking sender explicitly attaches IP address and port of destination to each packet server must extract IP address, port of sender from received packet UDP: transmitted data may be received out of order, or lost application viewpoint
UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server
Introduction 1-120
Client/server socket interaction: UDP
Server (running on
hostid
) Client create socket, port=
x
, for incoming request: serverSocket = DatagramSocket() create socket, clientSocket = DatagramSocket() Create, address (
hostid, port=x,
send datagram request using clientSocket read request from serverSocket write reply to serverSocket specifying client host address, port number read reply from clientSocket close clientSocket Introduction 1-121
Example: Java client (UDP)
keyboard monitor Client process input stream Output: sends packet (TCP sent “byte stream”) UDP packet UDP packet client UDP clientSocket socket UDP socket to network from network Input: receives packet (TCP received “byte stream”) Introduction 1-122
Example: Java client (UDP)
import java.io.*; import java.net.*; Create input stream Create client socket class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); address Translate hostname to IP using DNS InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); Introduction 1-123
Example: Java client (UDP), cont.
Create datagram with data-to-send, length, IP addr, port Send datagram to server DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); Read datagram from server clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } } Introduction 1-124
Example: Java server (UDP)
Create datagram socket at port 9876 Create space for received datagram Receive datagram import java.io.*; import java.net.*; 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) { DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); Introduction 1-125
Example: Java server (UDP), cont
Get IP addr port #, of sender String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); Create datagram to send to client DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); Write out datagram to socket } } } serverSocket.send(sendPacket); End of while loop, loop back and wait for another datagram Introduction 1-126
Building a simple Web server
handles one HTTP request accepts the request parses header obtains requested file from server’s file system creates HTTP response message: header lines + file sends response to client after creating server, you can request file using a browser (eg IE explorer) see text for details Introduction 1-127
Socket programming: references
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-12 sockets.html
“Socket Programming in Java: a tutorial,” http://www.javaworld.com/javaworld/jw-12-1996/jw-12 sockets.html
Introduction 1-128
seminari
2005-Implementare 2.6 2.7 2.8
2005-Invece che un client/server web implementare un client server ftp 2005-Invece che un client/server web implementare un client server smtp 2005-Invece che un client/server web implementare un client server pop
Introduction 1-129
domande
E’ possibile implementare un servizio di comunicazione affidabile usando udp?
SI (implemntando I controlli a lato applicazione)
Quale sarebbe il vantaggio?
No controllo congestione!! Introduction 1-130
Chapter 2 outline
2.1 Principles of app layer protocols clients and servers app requirements 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 Socket programming with TCP 2.7 Socket programming with UDP 2.8 Building a Web server 2.9 Content distribution Network Web caching Content distribution networks P2P file sharing Introduction 1-131
Web caches (proxy server)
Goal: satisfy client request without involving origin server user sets browser: Web accesses via cache browser sends all HTTP requests to cache object in cache: cache returns object else cache requests object from origin server, then returns object to client client Proxy server client origin server origin server Introduction 1-132
More about Web caching
Cache acts as both client and server Cache can do up-to-date check using If-modified since HTTP header Issue: should cache take risk and deliver cached object without checking?
Heuristics are used.
Typically cache is installed by ISP (university, company, residential ISP) Why Web caching?
Reduce response time for client request.
Reduce traffic on an institution’s access link.
Internet dense with caches enables “poor” content providers to effectively deliver content Introduction 1-133
Caching example (1)
Assumptions average object size = 100,000 bits avg. request rate from institution’s browser to origin serves = 15/sec delay from institutional router to any origin server and back to router = 2 sec Consequences utilization on LAN = 15% utilization on access link = 100% total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + milliseconds public Internet institutional network 1.5 Mbps access link 10 Mbps LAN origin servers institutional cache Introduction 1-134
Caching example (2)
Possible solution increase bandwidth of access link to, say, 10 Mbps Consequences utilization on LAN = 15% utilization on access link = 15% Total delay = Internet delay + access delay + LAN delay = 2 sec + msecs + msecs often a costly upgrade public Internet institutional network 10 Mbps access link 10 Mbps LAN origin servers institutional cache Introduction 1-135
Caching example (3)
Install cache suppose hit rate is .4
Consequence 40% requests will be satisfied almost immediately 60% requests satisfied by origin server utilization of access link reduced to 60%, resulting in negligible delays (say 10 msec) total delay = Internet delay + access delay + LAN delay = .6*2 sec + .6*.01 secs + milliseconds < 1.3 secs public Internet institutional network origin servers 1.5 Mbps access link 10 Mbps LAN institutional cache Introduction 1-136
Content distribution networks (CDNs)
origin server in North America Content replication I fornitori di servizi CDN attivano centinaia di server CDN in Internet ISP di secondo o terzo livello Il contenuto informativo viene duplicato sui server CDN ogniqualvolta il cliente del CDN aggiorna l’informazione CDN distribution node CDN server in S. America CDN server in Europe CDN server in Asia Introduction 1-137
CDN:esempio
HTTP request for www.foo.com/sports/sports.html
1 Origin server 3 2 DNS query for www.cdn.com
CDNs authoritative DNS server HTTP request for server www.foo.com
Nearby CDN server Rende disponibile direttamente file HTML Il riferimento: www.cdn.com/www.foo.com/sports/ruth.gif
http://www.foo.com/sports.ruth.gif
viene modificato h ttp://www.cdn.com/www.foo.com/sports/ruth.gif
Provider CDN cdn.com
Rende disponibili i file gif Il server DNS di autorità ha il compito di gestire i riferimenti
CDN: cont.
CDN ha una tabella con le informazioni relative alle distanze tra i server CDN e gli ISP Le richieste effettuate al DNS di autorità utilizzano questa informazione.
Non solo pagine web streaming audio/video streaming real-time audio/video Nodi CDN sono una rete virtuale del livello delle applicazioni Introduction 1-139
P2P file sharing
Alice runs P2P client application on her notebook computer Intermittently connects to Internet; gets new IP address for each connection Asks for “Hey Jude” Application displays other peers that have copy of Hey Jude.
Alice chooses one of the peers, Bob.
File is copied from Bob’s PC to Alice’s notebook: HTTP While Alice downloads, other users uploading from Alice.
Alice’s peer is both a Web client and a transient Web server.
All peers are servers = highly scalable!
Introduction 1-140
P2P: directory centralizzata
NAPSTER 1) Quando un peer si connette alla rete si collega ad un server centralizato: Indirizzo IP Informazione condivisa 2) Alice effettua una query per trovare “Hey Jude” 3) Alice scarica il file da Bob centralized directory server 2 1 1 1 1 Alice 3 Bob peers Introduction 1-141
Discussione
Singolo punto di fallimento Performance limitata Copyright ….
file transfer is decentralized, but locating content is highly decentralized Introduction 1-142
P2P: decentralized directory
Peer a group leader È associato ad un group leader.
Un group leader memorizza l’informazioni in condivisione dei “figli” Peer queries group leader group leader è in grado di interrogare altri group leader.
ordinary peer group-leader peer neighoring relationships in overlay network Introduction 1-143
decentralized directory: caratteristiche innovative
overlay network peer sono i nodes connessioni tra peer ed i rispettivi group leader Connessioni tra group leader Rete virtuale bootstrap node un peer che si connette deve essere associato ad un group leader o dveve essere designato group leader vantaggi Non è presente una directory centralizzata Il servizio di localizzazione è distribuito tra i peer svantaggi bootstrap node!!!
group leader possono essere troppo carichi Introduction 1-144
P2P: Query flooding
Gnutella no gerarchia bootstrap node sono utilizzati per avere informazioni sui pari join Query sono inviate ai vicini Query forwarding Se l’oggetto viene trovate il riferimento è inviato direttamente al peer di partenza join Introduction 1-145
P2P: query flooding
Pros no group leader decxentralizzato no directory info Cons Traffico di query query radius: Potrebbe non essere sufficiente per individuare l’oggetto bootstrap node Gestione della overlay network Introduction 1-146
seminari
2005-ICP (caching cooperativo) 2004-Peer to peer
Introduction 1-147
Chapter 2: Summary Our study of network apps now complete!
application service requirements: reliability, bandwidth, delay client-server paradigm Internet transport service model connection-oriented, reliable: TCP unreliable, datagrams: UDP specific protocols: HTTP FTP SMTP, POP, IMAP DNS socket programming content distribution caches, CDNs P2P Introduction 1-148
Chapter 2: Summary Most importantly: learned about protocols
typical request/reply message exchange: client requests info or service server responds with data, status code message formats: headers: fields giving info about data data: info being communicated control vs. data msgs in-band, out-of-band centralized vs. decentralized stateless vs. stateful reliable vs. unreliable msg transfer “complexity at network edge” security: authentication Introduction 1-149