Introduction1-1 Reti di calcolatori e Sicurezza -- Application Layer --- Part of these slides are adapted from the slides of the book: Computer Networking:

Presentazione sul tema: "Introduction1-1 Reti di calcolatori e Sicurezza -- Application Layer --- Part of these slides are adapted from the slides of the book: Computer Networking:"— Transcript della presentazione:

1 Introduction1-1 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. (copyright 1996-2002 J.F Kurose and K.W. Ross, All Rights Reserved)

2 Introduction1-2 Chapter 2: Application Layer Our goals:  conceptual, implementation aspects of network application protocols m transport-layer service models m client-server paradigm m peer-to-peer paradigm  learn about protocols by examining popular application-level protocols m HTTP m FTP m SMTP / POP3 / IMAP m DNS  programming network applications m socket API

3 Introduction1-3 Chapter 2 outline  2.1 Principles of app layer protocols m clients and servers m app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail m 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) m Network Web caching m Content distribution networks m P2P file sharing

4 Introduction1-4 Applicazioni Applicazioni di rete m Insieme di processi distribuiti: sono in esecuzione su di un host connesso in rete m Cooperano tramite scambio di messaggi m e.g., email, file transfer, P2P file sharing, IM, Web, Protocolli del livello delle applicazioni m Una componente delle applicazioni di rete m Definiscono la struttura dei msg m Richieste di servizio ai livelli inferiori application transport network data link physical application transport network data link physical application transport network data link physical

5 Introduction1-5 Protocolli livello applicazioni  Tipo dei msg scambiati  Sintassi dei msg  Semantica header dei msg  Regole di elaborazione Public-domain protocols:  RFC  Interoperability m HTTP, SMTP Proprietary protocols: KaZaA

6 Introduction1-6 Terminologia comune  user agent: interfaccia tra le applicazioni di rete ed i protocolli di comunicazione del livello delle applicazioni. m Web:browser m E-mail: mail reader m App. audio/video: player

7 Introduction1-7 Il modello Client - Server Si identificano due componenti: client e server application transport network data link physical application transport network data link physical 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 request reply

8 Introduction1-8 Processes communicating across network  process sends/receives messages to/from its socket  socket analogous to door m sending process shoves message out door m sending process asssumes transport infrastructure on other side of door which brings message to socket at receiving process process TCP with buffers, variables socket host or server process TCP with buffers, variables socket host or server Internet controlled by OS controlled by app developer  API: (1) choice of transport protocol; (2) ability to fix a few parameters (lots more on this later)

9 Introduction1-9 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: m HTTP server: 80 m Mail server: 25  More on this later

10 Introduction1-10 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 Timing  App (e.g., Internet telephony) non possono ammettere dei ritardi nella trasmissione dei dati Bandwidth  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

11 Introduction1-11 Requisiti applicazioni Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games instant messaging Data loss no loss loss-tolerant no loss Bandwidth elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up elastic Time Sensitive no yes, 100’s msec yes, few secs yes, 100’s msec yes and no

12 Introduction1-12 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?

13 Introduction1-13 Internet apps: application, transport protocols Application e-mail remote terminal access Web file transfer streaming multimedia Internet telephony Application layer protocol 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 or UDP typically UDP

14 Introduction1-14 Seminari approfondimento  2004: QoS  2004: Teleconferenze

15 Introduction1-15 Chapter 2 outline  2.1 Principles of app layer protocols m clients and servers m app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail m 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 m Network Web caching m Content distribution networks m P2P file sharing

16 Introduction1-16 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 which includes several referenced objects  Each object is addressable by a URL  Example URL: www.someschool.edu/someDept/pic.gif host name path name

17 Introduction1-17 HTTP overview HTTP: hypertext transfer protocol  Web’s application layer protocol  client/server model m client: browser that requests, receives, “displays” Web objects m server: Web server sends objects in response to requests  HTTP 1.0: RFC 1945  HTTP 1.1: RFC 2068 PC running Explorer Server running Apache Web server Mac running Navigator HTTP request HTTP response

18 Introduction1-18 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!  past history (state) must be maintained  if server/client crashes, their views of “state” may be inconsistent, must be reconciled aside

19 Introduction1-19 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

20 Introduction1-20 Nonpersistent HTTP Suppose user enters URL www.someSchool.edu/someDepartment/home.index 1a. HTTP client initiates TCP connection to HTTP server (process) at www.someSchool.edu on port 80 2. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object someDepartment/home.index 1b. HTTP server at host www.someSchool.edu waiting for TCP connection at port 80. “accepts” connection, notifying client 3. HTTP server receives request message, forms response message containing requested object, and sends message into its socket time (contains text, references to 10 jpeg images)

21 Introduction1-21 Nonpersistent HTTP (cont.) 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. time

22 Introduction1-22 Response time modeling Definition of RRT: time to send a small packet to travel from client to server and back. Response time:  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 time to transmit file initiate TCP connection RTT request file RTT file received time

23 Introduction1-23 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

24 Introduction1-24 Non Persistente vs persistente

25 Introduction1-25 Persistente: non pipeling vs pipeling

26 Introduction1-26 HTTP request message  two types of HTTP messages: request, response  HTTP request message: m ASCII (human-readable format) GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) request line (GET, POST, HEAD commands) header lines Carriage return, line feed indicates end of message

27 Introduction1-27 HTTP request message: general format

28 Introduction1-28 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

29 Introduction1-29 Method types HTTP/1.0  GET  POST  HEAD m asks server to leave requested object out of response HTTP/1.1  GET, POST, HEAD  PUT m uploads file in entity body to path specified in URL field  DELETE m deletes file specified in the URL field

30 Introduction1-30 HTTP response message 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... status line (protocol status code status phrase) header lines data, e.g., requested HTML file

31 Introduction1-31 HTTP response status codes 200 OK m request succeeded, requested object later in this message 301 Moved Permanently m requested object moved, new location specified later in this message (Location:) 400 Bad Request m request message not understood by server 404 Not Found m requested document not found on this server 505 HTTP Version Not Supported In first line in server->client response message. A few sample codes:

32 Introduction1-32 Trying out HTTP (client side) for yourself 1. Telnet to your favorite Web server: 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 telnet www.eurecom.fr 80 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!

33 Introduction1-33 esercizio  Come si fa a far rispondere al server 301 Moved Permanently m requested object moved, new location specified later in this message (Location:)

34 Introduction1-34 User-server interaction: authorization Authorization : control access to server content  authorization credentials: typically name, password  stateless: client must present authorization in each request  authorization: header line in each request  if no authorization : header, server refuses access, sends WWW authenticate: header line in response client server usual http request msg 401: authorization req. WWW authenticate: usual http request msg + Authorization: usual http response msgusual http request msg + Authorization: usual http response msg time

35 Introduction1-35 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: m Susan access Internet always from same PC m She visits a specific e- commerce site for first time m When initial HTTP requests arrives at site, site creates a unique ID and creates an entry in backend database for ID

36 Introduction1-36 Cookies: keeping “state” (cont.) client server usual http request msg usual http response + Set-cookie: 1678 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 server creates ID 1678 for user entry in backend database access Cookie file amazon: 1678 ebay: 8734 Cookie file ebay: 8734 Cookie file amazon: 1678 ebay: 8734 one week later:

37 Introduction1-37 Cookies (continued) What cookies can bring:  authorization  shopping carts  recommendations  user session state (Web e-mail) 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 aside

38 Introduction1-38 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 server HTTP request msg If-modified-since: HTTP response HTTP/1.0 304 Not Modified object not modified HTTP request msg If-modified-since: HTTP response HTTP/1.0 200 OK object modified

39 Introduction1-39 Seminari  2004: Cookies  Tipi di autenticazione su web  Gestione sessioni in http  Web services

40 Introduction1-40 Chapter 2 outline  2.1 Principles of app layer protocols m clients and servers m app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail m 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 m Network Web caching m Content distribution networks m P2P file sharing

41 Introduction1-41 ftp: file transfer protocol  Funzionalità: trasferimento di dati (files) da/per il sistema remoto  Architettura software: client/server m client: il sistema che attiva il trasferimento m server: il sistema remoto  ftp: RFC 959  ftp server: port 21 file transfer FTP server FTP user interface FTP client File system locale Sistema remoto user

42 Introduction1-42 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. FTP client FTP server TCP control connection port 21 TCP data connection port 20  Server opens a second TCP data connection to transfer another file.  Control connection: “out of band”  FTP server maintains “state”: current directory, earlier authentication

43 Introduction1-43 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 retrieves (gets) file  STOR filename stores (puts) file onto remote host 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

44 Introduction1-44 Seminari  Server/client ftp in Java

45 Introduction1-45 Chapter 2 outline  2.1 Principles of app layer protocols m clients and servers m app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail m 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 m Network Web caching m Content distribution networks m P2P file sharing

46 Introduction1-46 Strumenti per l’interazione fra utenti: la posta elettronica  Caratteristiche: m velocità m versatilità m economicità m Indipendenza dal tempo e dallo spazio

47 Introduction1-47 Posta elettronica: gli strumenti necessari  Mailbox (casella postale)  indirizzo posta elettronica  PC connesso ad Internet  programma “client” sul PC

48 Introduction1-48 La Mailbox  Normalmente risiede su un calcolatore potente e sempre connesso alla rete  Ha associato un indirizzo di posta elettronica E’ il contenitore elettronico dei messaggi ricevuti

49 Introduction1-49 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: dcurtin@interserve.com nome utente nome dominio separatore

50 Introduction1-50 Clienti di posta elettronica  Eudora, Microsoft Outlook, Netscape messager, Pine, Rmail …  Comunicano con il server mediante il protocollo SMTP  Funzionalità m Risposta m Inoltro m Archiviazione e recupero messaggi m Reindirazzamento m Vacation

51 Introduction1-51 Tecnica store-and-forward alice@domain.com manda un messaggio di posta elettronica a davide@domain.com. Il messaggio viene depositato sul server di posta di domain.com. Il messaggio viene recapitato al destinario solo quando questo si collega al sistema.

52 Introduction1-52 Tecnica store-and-forward

53 Introduction1-53 Tecnica store-and-forward alice@domain.com manda un messaggio di posta elettronica a bob@anotherdomain.com 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

54 Introduction1-54 Funzioni del servizio: lettura dei messaggi Protocollo POP3 Username + password Trasferimento messaggi sul PC e successiva lettura

55 Introduction1-55 Funzioni del servizio: spedizione dei messaggi Mail da spedire (indirizzo, subject, testo) (SMTP) INTERNET

56 Introduction1-56 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: m handshaking (greeting) m transfer m closure  Modalità di interazione: command/response m command: testo in formato ASCII m response: status code e testo  Messaggi sono codificati in 7-bit ASCII

57 Introduction1-57 Scenario: Alice e Bob 1) Alice vuole inviare una e- mail a bob@someschool.edu 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 user agent mail server mail server user agent 1 2 3 4 5 6

58 Introduction1-58 Esempio di interazione smtp S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 alice@crepes.fr... Sender ok C: RCPT TO: S: 250 bob@hamburger.edu... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C:. S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection

59 Introduction1-59 Piccole esercitazione:  telnet server_di_posta 25  220 reply from server  Digitare i comandi HELO, MAIL FROM, RCPT TO, DATA, QUIT

60 Introduction1-60 smtp  smtp utilizza connessioni persistenti  Smtp: formato dei messaggi (header & body) in 7-bit ascii  Caratteri non permessi (e.g., CRLF.CRLF ). Codifica dei messaggi (in base-64 o quoted printable)  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)

61 Introduction1-61 Seminari  MIME,smime,etc

62 Introduction1-62 POP3-IMAP4

63 Introduction1-63 Accesso alla posta  Esistono diversi protocolli per costruire una infrastruttura distribuita per la gestione delle email. I piu’ diffusi sono: m POP3 - Post Office Protocol versione 3 Protocollo molto ‘vecchio’ quindi molto diffuso Semplice Gestisce la posta in “locale”: scarica i messaggi! m IMAP4 - Internet Message Access Protocol (ver 4) Piu’ complesso del POP3 Permette la gestione delle mailbox remote come se fossero locali

64 Introduction1-64 POP3  Funziona con paradigma client-server  Supporta le funzioni di base per il recupero della posta elettronica da mailbox remota m Download m Delete

65 Introduction1-65 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 m Il client manda la sua idetificazione (user-id e password)  Se il server riconosce il client si entra nello stato di transazione m Il client puo’ accedere alla mailbox  Quando il client esegue il comando quit si entra nello stato update e la connessione e’ chiusa

66 Introduction1-66 IMAP4  Supporta i modelli di posta elettronica m Off-line (POP3): il client si connette periodicamente al server e scarica i messaggi (processati localmente) m On-line il client esegue delle modifiche sul server (accesso tramite protocollo di file system remoto NFS) m 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

67 Introduction1-67 POP3 authorization phase  client:  user: username  pass: password  Server: m +OK  -ERR transaction phase, client:  list: list (message numbers)  retr: retrieve message  dele: delete  quit C: list S: 1 498 S: 2 912 S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: S:. C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on

68 Introduction1-68 Confronto POP3-IMAP4  POP3= recupero su richiesta verso un singolo client  IMAP4= accesso interattivo a piu’ mailbox da piu’ client  Vantaggi filosofia POP3: m Uso minimo del tempo di connessione. m Uso minimo delle risorse del server.  Vantaggi filosofia IMAP4: m Possibilita’ di usare diversi computer in tempi diversi m Possibilita’ di usare macchine con client “senza-dati” (nei laboratori). m Accesso indipendente dalla piattaforma m Accesso concorrente a mailbox condivise.

69 Introduction1-69 Posta elettronica: e-mail  Per lo scambio di messaggi elettronici  Un messaggio contiene: m Uno o più destinatari nel campo TO m Destinatari per conoscenza (CC) m Destinatari per conoscenza “in incognito” (BCC) m Subject: tema del messaggio m Testo del messaggio m Eventuali allegati

70 Introduction1-70 Convenzioni e netiquette  Comunicazione di stati d’animo con le faccette: (emoticons)emoticons :-) sorridente e scherzoso;-) malizioso :-( triste:-I indifferente :-> sarcastico >:-> diabolico :-/ perplesso:-D sorpreso :-O molto sorpreso>;-> ammiccante e diabolico  Usare lettere maiuscole equivale ad URLARE

71 Introduction1-71 Il lingo  AFAIK As Far As I Know  AKAAlso Known As  BBIAB Be Back in a Bit  BBIAF Be Back in a Few  BBL Be Back Later  BFN Bye For Now  BTW By The Way  CID Consider It Done  CIO Check It Out  CUL8R See You Later  FYA For Your Amusement  FYI For Your Information  GTSY Glad To See Ya  GYPOGet Your Pants Off  IMO In My Opinion  IOW In Other Words  IRL In Real Life  KIT Keep In Touch  MOTDMessage Of The Day  POV Point of View  RSN Real Soon Now  RTM Read The Manual  TIA Thanks in Advance  TX Thanks  TYVM Thank You Very Much  WB Welcome Back

72 Introduction1-72 Attachments tecnica per spedire via E-mail ogni tipo di file codifica e decodifica automatiche con i migliori client limitare dimensione (< 1 mb)

73 Introduction1-73 MIME: multimedia extensions  MIME: multimedia mail extension, RFC 2045, 2056  Campi addizionali presenti per la dichiarazione dei MIME content type From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data....................................base64 encoded data Dati multimediali type, subtype, parameter Metodo di codifica MIME version Dati codificati

74 Introduction1-74 MIME types Content-Type: type/subtype; parameters Text  subtypes: plain, html Image  subtypes: jpeg, gif Audio  subtypes: basic (8-bit coding), 32kadpcm (32 kbps coding) Video  subtypes: mpeg, quicktime Applications  Invocate per rendere “viewable” questi tipi  subtypes: msword, octet-stream

75 Introduction1-75 Multipart Type Message From: alice@crepes.fr To: bob@hamburger.edu 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--

76 Introduction1-76  Return-Path:  Received: from phobos.unich.it (phobos.unich.it [192.167.13.101])  by gotham.sci.unich.it (8.12.8/8.12.8) with ESMTP id i8GAZMaS011065  for ; Thu, 16 Sep 2004 12:35:23 +0200  Received: from phobos.unich.it (phobos.unich.it [127.0.0.1])  by phobos.unich.it (8.12.5/8.12.8) with ESMTP id i8GAZ7Rv024306  for ; Thu, 16 Sep 2004 12:35:07 +0200  Received: from sci111.sci.unich.it ([192.167.92.11])  by phobos.unich.it (MailMonitor for SMTP v1.2.2 ) ;  Thu, 16 Sep 2004 12:35:06 +0200 (CEST)  Message-ID:  From: "Maura Fancello"  To: "stefano Bistarelli"  References:  Subject: Re: lavagna luminosa e proiettore  Date: Thu, 16 Sep 2004 12:34:10 +0200  MIME-Version: 1.0  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

77 Introduction1-77 Chapter 2 outline  2.1 Principles of app layer protocols m clients and servers m app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail m 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 m Network Web caching m Content distribution networks m P2P file sharing

78 Introduction1-78 Domain Name Server (DNS) 158.110.1.2 158.110.1.7 130.186.1.53 193.207.87.1 pluto.sci.unich.it ? 192.167.92.33 !

79 Introduction1-79  ad ogni risorsa TCP/IP può essere assegnato un nome simbolico sono necessari: m un metodo per associare il nome simbolico di una macchina all’indirizzo (o agli indirizzi) IP: risoluzione diretta m un metodo per associare ad un indirizzo IP al nome simbolico della macchina: risoluzione inversa  Domain Name System (DNS) m definito presso ISI - USC 1984 m RFC 882, RFC 883, RFC 973 (obsolete) m RFC 1034, RFC 1035, RFC 1123, RFC 1537, RFC 1912 DNS: le funzioni

80 Introduction1-80 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

81 Introduction1-81 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)

82 Introduction1-82 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 bista@sci.unich.it

83 Introduction1-83 Esempio  Mailboxes Name server Mail program User TCP IP 2 cs.princeton.edu 192.12.69.5 3 user @ cs.princeton.edu 1 192.12.69.5 4 5

84 Introduction1-84 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)

85 Introduction1-85 DNS  Gerarchia di naming

86 Introduction1-86 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

87 Introduction1-87 Interrogare il DNS  Il programma nslookup permette di interrogare il DNS m Per convertire un nome di dominio in numero IP m 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  Il sito www.nic.it/RA/database/database.html accede al registro della Registration Authority italiana

88 Introduction1-88 Name Servers  In teoria un solo name server potrebbe contenere l’intero database DNS mondiale; in pratica, questo 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

89 Introduction1-89 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.

90 Introduction1-90 Name Servers  Partizione della gerarchia in zone educom princeton … mit csee ux01ux04 physics cisco … yahoonasa … nsfarpa … navyacm … ieee govmilorgnetukfr Root name server Princeton name server Cisco name server CS name server EE name server … …  Ogni zona può avere due o piu’ name servers

91 Introduction1-91 DNS name servers  Nessun server memorizza l’associazione name-to-IP address per tutta Internet local name servers: m ogni ISP ha un local (default) name server m Primo passo: query al local name server authoritative name server: m host: memorizza l’indirizzo IP ed il nome del sistema m Effettua la traduzione name/IP address translation DNS centralizzato  Punto di fallimento globale  Volume di traffico elevato  Database remoto  maintenance Non scala!!!

92 Introduction1-92 DNS  Quando un programma deve trasformare un nome in un indirizzo IP chiama una procedura detta 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 la destinazione)

93 Introduction1-93 DNS: Root name servers  Contattati dai name server locali root name server: m Interagiscono con il name server di autorità (se non possono risolvere direttamente ilo nome) m Ottengono il mapping m Restituiscono il risultato b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo 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 13 root name servers worldwide

94 Introduction1-94 DNS: Un Esempio host surf.eurecom.fr vuole determinare l’indirizzo IP del nome gaia.cs.umass.edu 1. Collegamento con il server DNS locale dns.eurecom.fr 2. dns.eurecom.fr si collega al root name server (se necessario) 3. root name server si collega all’authoritative name server, dns.umass.edu,(se necessario) requesting host surf.eurecom.fr gaia.cs.umass.edu root name server authorititive name server dns.umass.edu local name server dns.eurecom.fr 1 2 3 4 5 6

95 Introduction1-95 DNS Root name server:  Potrebbe non conoscere l’authoratiative name server  Potrebbe conoscere un intermediate name server: Il server da contattare per collegarsi con il authoritative name server requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr 1 2 3 4 5 6 authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8

96 Introduction1-96 DNS: queries 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” requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr 1 2 3 4 5 6 authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8 iterated query

97 Introduction1-97 DNS: caching  Un generico name server può effetttuare una operazione di caching per memorizzare i risultati delle query m Elementi della cache diventano “vecchi”  Meccanismi per update/notify sono in fase di progetto m RFC 2136 m http://www.ietf.org/html.charters/dnsind-charter.html

98 Introduction1-98 DNS records DNS: distributed db che memorizza resource records (RR)  Type=NS  name is domain (e.g. foo.com)  value is IP address of authoritative name server for this domain RR format: (name, value, type,ttl)  Type=A  name is hostname  value is IP address  Type=CNAME  name è un alias di un nome “canonico” www.ibm.com è servereast.backup2.ib m.com m Value è il nome canonico  Type=MX  value is hostname of mailserver associated with name

99 Introduction1-99 $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.

100 Introduction1-100 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 >

101 Introduction1-101 DNS protocol, messages DNS protocol : query / reply messages, Identico message format msg header  identification: 16 bit # for query, reply to query uses same #  flags: m query or reply m recursion desired m recursion available m reply is authoritative

102 Introduction1-102 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

103 Introduction1-103 DNS  Protocollo di trasporto: UDP  Porta: 53  … bugia..

104 Introduction1-104 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) m www.dnssec.net

105 Introduction1-105 Hint seminario configurazione dns Acl options { directory "/var/named"; pid-file "named.pid"; allow-transfer { mesysslaves; }; allow-recursion { mesysnets; }; blackhole { bogusnets; }; };

106 Introduction1-106 DNS Data flow master resolver stub resolver Zone administrator Zone file slaves Dynamic updates

107 Introduction1-107 Data Protection Server Protection DNS Vulnerabilities Zone file slaves master resolver stub resolver Zone administrator Dynamic updates Cache pollution by Data spoofing Unauthorized updates Corrupting data Impersonating master Cache impersonation

108 Introduction1-108 Chapter 2 outline  2.1 Principles of app layer protocols m clients and servers m app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail m 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 m Network Web caching m Content distribution networks m P2P file sharing JUMP

109 Introduction1-109 Socket programming 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: m unreliable datagram m reliable, byte stream- oriented 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 socket Goal: learn how to build client/server application that communicate using sockets

110 Introduction1-110 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 process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server internet

111 Introduction1-111 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 m allows server to talk with multiple clients m source port numbers used to distinguish clients (more in Chap 3) TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server application viewpoint

112 Introduction1-112 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.

113 Introduction1-113 Socket programming with TCP Example client-server app: 1) client reads line from standard input ( inFromUser stream), sends to server via socket ( 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 client TCP socket

114 Introduction1-114 Client/server socket interaction: TCP wait for incoming connection request connectionSocket = welcomeSocket.accept() create socket, port= x, for incoming request: welcomeSocket = ServerSocket() create socket, connect to hostid, port= x clientSocket = Socket() close connectionSocket read reply from clientSocket close clientSocket Server (running on hostid ) Client send request using clientSocket read request from connectionSocket write reply to connectionSocket TCP connection setup

115 Introduction1-115 Example: Java client (TCP) 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()); Create input stream Create client socket, connect to server Create output stream attached to socket

116 Introduction1-116 Example: Java client (TCP), cont. 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(); } Create input stream attached to socket Send line to server Read line from server

117 Introduction1-117 Example: Java server (TCP) import java.io.*; import java.net.*; 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())); Create welcoming socket at port 6789 Wait, on welcoming socket for contact by client Create input stream, attached to socket

118 Introduction1-118 Example: Java server (TCP), cont DataOutputStream outToClient = new DataOutputStream (connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } Read in line from socket Create output stream, attached to socket Write out line to socket End of while loop, loop back and wait for another client connection

119 Introduction1-119 Chapter 2 outline  2.1 Principles of app layer protocols m clients and servers m app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail m 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 m Network Web caching m Content distribution networks m P2P file sharing

120 Introduction1-120 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

121 Introduction1-121 Client/server socket interaction: UDP close clientSocket Server (running on hostid ) read reply from clientSocket create socket, clientSocket = DatagramSocket() Client Create, address ( hostid, port=x, send datagram request using clientSocket create socket, port= x, for incoming request: serverSocket = DatagramSocket() read request from serverSocket write reply to serverSocket specifying client host address, port number

122 Introduction1-122 Example: Java client (UDP) Output: sends packet (TCP sent “byte stream”) Input: receives packet (TCP received “byte stream”) Client process client UDP socket

123 Introduction1-123 Example: Java client (UDP) import java.io.*; import java.net.*; 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(); Create input stream Create client socket Translate hostname to IP address using DNS

124 Introduction1-124 Example: Java client (UDP), cont. DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } Create datagram with data-to-send, length, IP addr, port Send datagram to server Read datagram from server

125 Introduction1-125 Example: Java server (UDP) 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); Create datagram socket at port 9876 Create space for received datagram Receive datagram

126 Introduction1-126 Example: Java server (UDP), cont String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } Get IP addr port #, of sender Write out datagram to socket End of while loop, loop back and wait for another datagram Create datagram to send to client

127 Introduction1-127 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: m header lines + file  sends response to client  after creating server, you can request file using a browser (eg IE explorer)  see text for details

128 Introduction1-128 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

129 Introduction1-129 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

130 Introduction1-130 domande  E’ possibile implementare un servizio di comunicazione affidabile usando udp? m SI (implemntando I controlli a lato applicazione)  Quale sarebbe il vantaggio? m No controllo congestione!!

131 Introduction1-131 Chapter 2 outline  2.1 Principles of app layer protocols m clients and servers m app requirements  2.2 Web and HTTP  2.3 FTP  2.4 Electronic Mail m 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 m Network Web caching m Content distribution networks m P2P file sharing

132 Introduction1-132 Web caches (proxy server)  user sets browser: Web accesses via cache  browser sends all HTTP requests to cache m object in cache: cache returns object m else cache requests object from origin server, then returns object to client Goal: satisfy client request without involving origin server client Proxy server client HTTP request HTTP response HTTP request HTTP response origin server origin server

133 Introduction1-133 More about Web caching  Cache acts as both client and server  Cache can do up-to-date check using If-modified- since HTTP header m Issue: should cache take risk and deliver cached object without checking? m 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

134 Introduction1-134 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 origin servers public Internet institutional network 10 Mbps LAN 1.5 Mbps access link institutional cache

135 Introduction1-135 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 origin servers public Internet institutional network 10 Mbps LAN 10 Mbps access link institutional cache

136 Introduction1-136 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 origin servers public Internet institutional network 10 Mbps LAN 1.5 Mbps access link institutional cache

137 Introduction1-137 Content distribution networks (CDNs) Content replication  I fornitori di servizi CDN attivano centinaia di server CDN in Internet m ISP di secondo o terzo livello  Il contenuto informativo viene duplicato sui server CDN ogniqualvolta il cliente del CDN aggiorna l’informazione origin server in North America CDN distribution node CDN server in S. America CDN server in Europe CDN server in Asia

138 Introduction1-138 CDN:esempio server  www.foo.com  Rende disponibile direttamente file HTML  Il riferimento: http://www.foo.com/sports.ruth.gif viene modificato h ttp://www.cdn.com/www.foo.com/sports/ruth.gif HTTP request for www.foo.com/sports/sports.html DNS query for www.cdn.com HTTP request for www.cdn.com/www.foo.com/sports/ruth.gif 1 2 3 Origin server CDNs authoritative DNS server Nearby CDN server Provider CDN  cdn.com  Rende disponibili i file gif  Il server DNS di autorità ha il compito di gestire i riferimenti

139 Introduction1-139 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 m Nodi CDN sono una rete virtuale del livello delle applicazioni

140 Introduction1-140 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!

141 Introduction1-141 P2P: directory centralizzata NAPSTER 1) Quando un peer si connette alla rete si collega ad un server centralizato: m Indirizzo IP m Informazione condivisa 2) Alice effettua una query per trovare “Hey Jude” 3) Alice scarica il file da Bob centralized directory server peers Alice Bob 1 1 1 1 2 3

142 Introduction1-142 Discussione  Singolo punto di fallimento  Performance limitata  Copyright …. file transfer is decentralized, but locating content is highly decentralized

143 Introduction1-143 P2P: decentralized directory  Peer m a group leader m È associato ad un group leader.  Un group leader memorizza l’informazioni in condivisione dei “figli”  Peer queries group leader m group leader è in grado di interrogare altri group leader.

144 Introduction1-144 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 m Il servizio di localizzazione è distribuito tra i peer svantaggi  bootstrap node!!!  group leader possono essere troppo carichi

145 Introduction1-145 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

146 Introduction1-146 P2P: query flooding Pros  no group leader  decxentralizzato  no directory info Cons  Traffico di query  query radius: m Potrebbe non essere sufficiente per individuare l’oggetto  bootstrap node  Gestione della overlay network

147 Introduction1-147 seminari  2005-ICP (caching cooperativo)  2004-Peer to peer

148 Introduction1-148 Chapter 2: Summary  application service requirements: m reliability, bandwidth, delay  client-server paradigm  Internet transport service model m connection-oriented, reliable: TCP m unreliable, datagrams: UDP Our study of network apps now complete!  specific protocols: m HTTP m FTP m SMTP, POP, IMAP m DNS  socket programming  content distribution m caches, CDNs m P2P

149 Introduction1-149 Chapter 2: Summary  typical request/reply message exchange: m client requests info or service m server responds with data, status code  message formats: m headers: fields giving info about data m data: info being communicated Most importantly: learned about protocols  control vs. data msgs m in-band, out-of-band  centralized vs. decentralized  stateless vs. stateful  reliable vs. unreliable msg transfer  “complexity at network edge”  security: authentication