Reti di calcolatori e Sicurezza

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)

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

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

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

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

Terminologia comune



user agent: interfaccia tra le applicazioni di rete ed i protocolli di comunicazione del

livello delle applicazioni.



Web:browser



E-mail: mail reader



App. audio/video: player

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)

request

reply

Processes communicating across network



process sends/receives messages to/from its socket



socket analogous to door

 sending process shoves message out door

 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)

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

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 Bandwidth 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

Requisiti applicazioni

Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games instant messaging

Data loss no loss no loss no loss

loss-tolerant loss-tolerant loss-tolerant no loss

Bandwidth elastic

elastic elastic

audio: 5kbps-1Mbps video:10kbps-5Mbps same as above

few kbps up elastic

Time Sensitive no

no no

yes, 100’s msec yes, few secs yes, 100’s msec yes and no

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?

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 TCP TCP

TCP or UDP

typically UDP

Seminari approfondimento



2004: QoS



2004: Teleconferenze

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

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

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

PC running Explorer

Server running Apache Web

server

Mac running

HTTP r

equest

HTTP request HTTP r

esponse

HTTP response

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

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

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)

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

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 time

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

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

Non Persistente vs persistente

Persistente: non pipeling vs pipeling

HTTP request message



two types of HTTP messages: request , response



HTTP request message:

 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

HTTP request message: general format

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

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

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

HTTP response status 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

In first line in server->client response message.

A few sample codes:

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!

esercizio



Come si fa a far rispondere al server

301 Moved Permanently



requested object moved, new location specified

later in this message (Location:)

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: <cred>

usual http response msg

usual http request msg + Authorization: <cred>

usual http response msg time

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

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

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

access Cookie file

amazon: 1678 ebay: 8734

Cookie file ebay: 8734

Cookie file amazon: 1678 ebay: 8734

one week later:

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

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:

<date>

 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:

<date>

HTTP response

HTTP/1.0 304 Not Modified

object modifiednot

HTTP request msg

If-modified-since:

<date>

HTTP response

HTTP/1.0 200 OK

<data>

object modified

Seminari



2004: Cookies



Tipi di autenticazione su web



Gestione sessioni in http



Web services

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

ftp: file transfer protocol

 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

file transfer FTP server userFTP

interface

clientFTP

File system locale

Sistema remoto user

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.

clientFTP 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

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

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

Seminari



Server/client ftp in Java

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

Strumenti per l’interazione fra utenti: la posta elettronica



Caratteristiche:



velocità



versatilità



economicità



Indipendenza dal tempo

e dallo spazio

Posta elettronica:

gli strumenti necessari



Mailbox (casella postale)



indirizzo posta elettronica

 PC connesso ad Internet

 programma “client” sul PC

La Mailbox 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

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

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

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.

Tecnica store-and-forward

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

Funzioni del servizio: lettura dei messaggi

Funzioni del servizio: lettura dei messaggi

• Protocollo POP3

• Username + password

• Trasferimento messaggi sul PC

e successiva lettura

Funzioni del servizio: spedizione dei messaggi

Funzioni del servizio: spedizione dei messaggi

Mail da spedire

(indirizzo, subject, testo)

(SMTP)

INTERNET INTERNET

(SMTP)

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: testo in formato ASCII

 response: status code e testo



Messaggi sono codificati in 7-bit ASCII

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

agentuser

servermail

servermail user agent 1

2

Esempio di interazione smtp

S: 220 hamburger.edu C: HELO crepes.fr

S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr>

S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu>

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

Piccole esercitazione:



telnet server_di_posta 25



220 reply from server



Digitare i comandi HELO, MAIL FROM, RCPT TO,

DATA, QUIT

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)

Seminari



MIME,smime,etc

POP3-IMAP4

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

POP3



Funziona con paradigma client-server



Supporta le funzioni di base per il recupero della posta elettronica da mailbox remota



Download



Delete

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

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

POP3

authorization phase

 client:

 user: username

 pass: password

 Server:

 +OK

 -ERR

transaction phase, ^client:

 list: list (message numbers)

 retr: retrieve message

 dele: delete

 quit

C: retr 1

S: <message 1 contents>

S: .

C: dele 1 C: retr 2

S: <message 1 contents>

S: .

S: +OK POP3 server ready C: user alice

S: +OK

C: pass hungry

S: +OK user successfully logged on

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.

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

Convenzioni e netiquette



Comunicazione di stati d’animo con le faccette: ( 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

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

 GYPO Get Your Pants Off

 IMO In My Opinion

 IOW In Other Words

 IRL In Real Life

 KIT Keep In Touch

 MOTD Message 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

Attachments Attachments

• tecnica per spedire via E-mail ogni tipo di file

• codifica e decodifica automatiche con i migliori client

• limitare dimensione (< 1 mb)

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

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

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

 Return-Path: <fancello@sci.unich.it>

 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 <bista@sci.unich.it>; 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 <bista@sci.unich.it>; 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: <001801c49bd8$b54118c0$0b5ca7c0@sci.unich.it>

 From: "Maura Fancello" <fancello@sci.unich.it>

 To: "stefano Bistarelli" <bista@sci.unich.it>

 References: <000801c3d5fd$56b8ce20$0b5ca7c0@sci.unich.it>

<6c7301c49bd0$23e50150$bd603092@iit.cnr.it>

 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

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

Domain Name Server (DNS) 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 !

 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

DNS: le funzioni

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

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)

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

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

192.12.69.5 5

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)

DNS



Gerarchia di naming

edu com

princeton … mit

cs ee

ux01 ux04

physics

cisco … yahoo nasa … nsf arpa … navy acm … ieee

gov mil org net uk fr

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

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



Il sito www.nic.it/RA/database/database.html accede

al registro della Registration Authority italiana

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

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.

Name Servers



Partizione della gerarchia in zone

edu com

princeton … mit

cs ee

ux01 ux04

physics

cisco … yahoo nasa … nsf arpa … navy acm … ieee

gov mil org net uk fr

name serverRoot

Princeton

name server Cisco

name server

name serverCS EE name server

…

…



Ogni zona può avere

due o piu’ name servers

DNS name servers

 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

DNS centralizzato

 Punto di fallimento globale

 Volume di traffico elevato

 Database remoto

 maintenance Non scala!!!

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)

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

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

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