Protocolli di rete

Bibliografia:
Computer Networking. Cap. 3. Autori: James F. Kurose (University of Massachusetts, Amherst) Keith W. Ross (Polytechnic Institute of NYU).

Il livello Applicazione.

Introduzione

Le reti di calcolatori hanno lo scopo di consentire la cooperazione tra le applicazioni di rete. Per poter comunicare tra loro, le applicazioni di rete si servono di protocolli. Sono state sviluppate numerose applicazioni per Internet, che sono diventate parte integrante delle attività quotidiane delle persone.

Le prime applicazioni per Internet gestivano solo il testo: messaggi di posta elettronica, terminale virtuale, trasferimento di file e newsgroup (bacheche in cui venivano affissi articoli, recensioni, ecc.). Agli inizi degli anni '90 nacque il World Wide Web, una tecnologia che sfruttava il canale telefonico per dare agli utenti la possibilità di ricercare e consultare documenti, e realizzare il commercio elettronico. Le successive applicazioni create per Internet furono la messaggistica istantanea e la condivisione dei file, un modello di comunicazione P2P. Agli inizi del 2000 sono nate le applicazioni per far viaggiare sulla rete anche la voce e i video, le principali applicazioni sono voice-over-IP (VoIP) e la video conferenza su IP come Skype; si è diffusa anche la distribuzione di video amatoriali come YouTube; e la trasmissione di film su richiesta come Netflix. In questo stesso periodo si sono sviluppati anche i giochi in rete, come Second Life e World of Warcraft. La nuova generazione di applicazioni riguarda i social network, come Facebook e Twitter, che hanno stabilito una rete di relazioni tra le persone che si appoggia sulla rete Internet formata da router e canali

Generalità sulle applicazioni di rete

Le applicazioni di rete devono essere concepite per trovarsi in esecuzione su sistemi terminali diversi e possano comunicare tramite la rete. Ad esempio, in un'applicazione Web ci sono due programmi che comunicano tra loro: il browser in esecuzione sul computer utente (desktop, laptop, tablet, smartphone, ...); e il server Web in esecuzione su un altro computer. Oppure, in una applicazione P2P di condivisione di file c'è un programma in ogni host che partecipa alla comunità di condivisione dei file. In questo caso i programmi nei vari host possono essere simili o identici.

L'applicazione di rete può essere scritta, ad esempio, in C, in Java, in Python, e si serve delle funzionalità offerte dalle apparecchiature di rete, come router o switch, che lo sviluppatore usa senza preoccuparsi di programmarle.

Architettura delle Applicazioni di rete

Come regola, prima di addentrarsi nella codifica del software, si deve schematizzare l'architettura dell'applicazione. Dal punto di vista dello sviluppatore di applicazioni, l'architettura di rete è fissa e fornisce un insieme specifico di servizi alle applicazioni. L'architettura dell'applicazione, invece, viene progettata dallo sviluppatore e descrive come l'applicazione è strutturata sui vari sistemi terminali, secondo uno dei due modelli: client-server o peer-to-peer (P2P).

Nell'architettura client-server, c'è sempre un host, chiamato server, che soddisfa le richieste degli altri host, chiamati client. Un esempio classico è il Web. Un server Web, sempre attivo, risponde alle richieste dei browser in esecuzione sugli host client. Quando il server Web riceve una richiesta da un client, risponde inviando l'oggetto richiesto al client. Si noti che, con l'architettura client-server, i client non comunicano direttamente tra loro; per esempio nel Web, due browser non comunicano direttamente. Un'altra caratteristica dell'architettura client-server è che il server ha un indirizzo fisso noto, chiamato indirizzo IP. Un client può sempre contattare il server inviando un pacchetto al suo indirizzo IP. Alcune delle applicazioni più note con architettura client-server sono il Web, l'FTP, il Telnet, e l'e-mail.

Un singolo server riesce a sostenere richieste da parte di molti client. Ma un sito di social networking molto popolare può congestionarsi rapidamente se ha un solo server che gestisce tutte le sue richieste. Per questo motivo viene utilizzato un data center, costituito da un potente server virtuale che bilancia il carico di lavoro tra numerosi host. Molti servizi che si trovano su Internet, come i motori di ricerca (ad esempio Google), il commercio elettronico (ad esempio, Amazon ed e-Bay), la posta elettronica con interfaccia Web (ad esempio Gmail e Yahoo), i social network (ad esempio Facebook e Twitter) impiegano uno o più data center. Google ha da 30 a 50 data center distribuiti in tutto il mondo, che insieme gestiscono i servizi di Goohle: la ricerca, YouTube, Gmail e altro. Un data center può avere centinaia di migliaia di server, che devono essere alimentati e manutenzionati. Inoltre, richiedono una elevata larghezza di banda.

In un'architettura P2P, non c'è nessun server dedicato in un data center. L'applicazione sfrutta la comunicazione diretta tra coppie di host che si connettono occasionalmente, chiamati peer. I peer non sono di proprietà del fornitore di servizi, ma sono invece computer controllati dagli utenti, in casa o in ufficio. L'architettura è chiamata peer-to-peer perchè i peer comunicano senza passare attraverso un server dedicato. Molte delle applicazioni più popolari e ad alta intensità di traffico sono basate su architetture P2P. Queste applicazioni includono la condivisione di file (ad esempio, BitTorrent), l'accelerazione del download assistito (ad esempio Xunlei), la Telefonia (Skype), e IPTV, la diffusione radio e televisiva (ad esempio, Kankan e PPStream). Alcune applicazioni hanno architetture ibride, combinano elementi client-server ed elementi P2P. Ad esempio, per molte applicazioni di messaggistica istantanea, i server vengono utilizzati per mantenere gli indirizzi IP degli utenti, ma i messaggi tra gli utenti vengono inviati direttamente tra gli host degli utenti, senza passare attraverso il server.

Con il termine peer si indica un computer che può svolgere contemporaneamente il ruolo di client e il ruolo di server. È detto anche un computer paritetico, nel senso che è di pari grado agli altri. In un server l'amministratore decide, per ogni categoria di utente, le risorse a cui può accedere, in un peer è l'utente che decide le risorse da condividere con qualsiasi altro utente.

Una delle caratteristiche più interessanti dell'architettura P2P è l'auto-scalabilità. Ad esempio, in un'applicazione di condivisione di file P2P, quando un sistema scarica un file, lo può poi rendere disponibile agli altri peer, che in tal modo non dovranno sovraccaricare lo stesso sistema. Inoltre le architetture P2P non richiedono un'infrastruttura server e una larghezza di banda adeguata. Tuttavia, le future applicazioni P2P dovranno affrontare tre sfide:

• ISP Friendly. La maggior parte dei fornitori di servizi impiegano la capacità di banda "asimmetrica", cioè il traffico in upstream ha una velocità molto bassa. Ma le applicazioni P2P di streaming video e la distribuzione dei file creano un intenso traffico dai server agli ISP. Le future applicazioni P2P devono essere progettate in modo che non abusino della banda a svantaggio dei fornitori.

• Security. Per la loro natura aperta e distribuita, le applicazioni P2P non garantiscono la sicurezza.

• Incentives. Il successo delle future applicazioni P2P dipende dalla disponibilità degli utenti a cedere la larghezza di banda, la memorizzazione e le risorse di calcolo alle applicazioni.

la scalabilità di una rete o di un'applicazione è la proprietà di variare la propria dimensione, secondo un fattore di scala, senza che venga degradato il servizio

Comunicazione tra Processi

Prima di costruire l'applicazione di rete, è necessario conoscere il modo in cui i programmi, in esecuzione su più sistemi terminali, comunicano tra di loro. In realtà non comunicano i programmi, ma i processi. Un processo è un programma in esecuzione su un sistema terminale. Quando i processi in esecuzione sullo stesso sistema devono comunicare tra loro, applicano le regole del sistema operativo. Ma in questo contesto, non si interessa esaminare come comunicano i processi sullo stesso host, ma si vuole studiare come comunicano i processi in esecuzione su host diversi (con sistemi operativi diversi).

I processi su due sistemi terminali diversi comunicano tra loro scambiandosi messaggi attraverso la rete. Un processo mittente crea ed invia messaggi sulla rete; un processo destinatario riceve questi messaggi ed eventualmente risponde con altri messaggi. I processi che comunicano tra loro risiedono nel livello applicazione.

Processi Client e processi Server

Un'applicazione di rete è costituita da due processi che si scambiano messaggi attraverso la rete. Ad esempio, nell'applicazione Web un browser scambia messaggi con un server Web. In un sistema di condivisione di file P2P, un file viene trasferito da un processo in esecuzione su un peer ad un processo in un esecuzione su un altro peer. In ogni coppia di processi in comunicazione, uno dei due viene denominato il client e l'altro il server. Nel Web, un browser è un processo client e un server Web è un processo server. Con la condivisione di file P2P, il peer che sta scaricando il file viene chiamato client e il peer che sta fornendo il file viene chiamato server.

Nelle applicazioni di tipo P2P, un processo può essere sia un client che un server. In effetti, tale ruolo viene assunto solo per la durata di una data sessione di comunicazione. I processi client e server sono definiti così:

Nel contesto di una sessione di comunicazione tra una coppia di processi, il processo che avvia la comunicazione (cioè, contatta per primo l'altro processo) viene etichettato come il client. Il processo che attende di essere contattato per iniziare la sessione è il server.

Nel Web, un browser inizia la comunicazione con un server Web; quindi il browser è il client e il server Web è il server. Nella condivisione di file P2P, quando il Peer A chiede al Peer B di inviargli un file, il Peer A è il client e il Peer B è il server, ma solo durante questa sessione di comunicazione. A volte si usa anche la terminologia "lato client e lato server di un'applicazione".

L'interfaccia tra il Processo e la rete di calcolatori

Ogni messaggio che un processo invia all'altro processo deve passare attraverso la rete. Un processo del livello applicazione invia e riceve messaggi attraverso un'interfaccia chiamata socket. Si consideri la seguente analogia: un processo corrisponde ad una abitazione e il socket alla cassetta postale. Quando un processo vuole inviare un messaggio ad un altro processo residente su un altro host, imbuca il messaggio nella sua cassetta postale (socket). Si presume che vi sia una infrastruttura di trasporto che consegnerà il messaggio presso l'abitazione del destinatario. Una volta che il messaggio raggiunge l'host di destinazione, viene imbucato nella cassetta postale (socket), e il processo indirizzato legge il messaggio

La figura mostra la comunicazione mediante i socket tra due processi che si scambiano messaggi usando la rete. (In figura si assume che il protocollo di trasporto utilizzato dai processi sia il TCP di Internet). Come mostrato in questa figura, un socket è l'interfaccia tra il livello applicazione e il livello trasporto all'interno di un host. Un socket è una Application Programming Interface (API) tra l'applicazione e la rete, in quanto il socket mette a disposizione del programmatore le funzionalità per costruire le applicazioni di rete. Lo sviluppatore dell'applicazione ha il controllo sul lato dell'applicazione ma non può modificare il livello di trasporto. Le sole possibilità che ha lo sviluppatore dell'applicazione sul livello trasporto è (1) la scelta del protocollo di trasporto e (2) (forse) l'impostazione di alcuni parametri quali le dimensioni massime del buffer e del segmento. Una volta che lo sviluppatore dell'applicazione sceglie un protocollo di trasporto, l'applicazione viene costruita utilizzando i servizi che questo rende disponibili.

Indirizzamento dei Processi

Per inviare la posta, la destinazione deve avere un indirizzo. Analogamente, un processo in esecuzione su un host, può inviare pacchetti ad un processo in esecuzione su un altro host, se questo possiede un indirizzo. Per identificare il processo ricevente, devono essere specificate due informazioni: (1) l'indirizzo dell'host e (2) un identificatore che specifica il processo nell'host di destinazione.

In Internet, un host è identificato dal suo indirizzo IP. Un indirizzo IP è un numero di 32 bit che identifica in modo univoco l'host. Oltre a conoscere l'indirizzo dell'host a cui è destinato un messaggio, il processo mittente deve anche identificare il processo destinatario (più esattamente, il socket ricevente) in esecuzione sull'host. Queste informazioni sono necessarie perchè, in generale, su un host ci potrebbero essere molte applicazioni di rete in esecuzione. A questo scopo viene usato un numero di porta di destinazione. Alle applicazioni più diffuse sono stati assegnati dei numeri di porta specifici. Ad esempio, un server Web è in ascolto sulla porta numero 80. Il server di posta (che utilizza il protocollo SMTP) è in ascolto sulla porta numero 25.

Servizi del livello Trasporto disponibili alle applicazioni

Un socket è l'interfaccia tra il processo del livello applicazione e il protocollo del livello trasporto. Dal lato del mittente, l'applicazione passa il messaggio al socket e il protocollo del livello Trasporto preleva i messaggi dal socket.

A livello trasporto sono disponibili diversi protocolli. Quando si sviluppa un'applicazione, è necessario scegliere uno dei protocolli del livello trasporto. Come si fa questa scelta? Si dovrebbero conoscere i servizi forniti dai vari protocolli di trasporto, e poi scegliere quello con i servizi che meglio corrispondono alle esigenze dell'applicazione.

Le caratteristiche dei possibili servizi di un protocollo del livello Trasporto sono: il trasferimento affidabile dei dati, la velocità, i tempi, e la sicurezza.

Trasferimento affidabile dei dati

I pacchetti possono perdersi all'interno della rete. Per esempio, un pacchetto può venire sovrascritto mentre si trova nel buffer di un router congestionato, o può essere scartato da un host perchè illeggibile in conseguenza del rumore che lo ha modificato sul canale. Per molte applicazioni, come la posta elettronica, il trasferimento di file, l'accesso remoto, la consultazione di pagine Web o le transazioni bancarie, la perdita di dati può avere conseguenze devastanti (in quest'ultimo caso, o per la banca o per il cliente). Pertanto, per utilizzare queste applicazioni, si deve garantire che i dati in partenza da un sistema terminale vengano consegnati correttamente e senza perdita all'altro sistema terminale. Se un protocollo fornisce un servizio con garanzia della consegna dei dati, da processo a processo, si dice che il trasferimento dei dati è affidabile.

Quando un protocollo di trasporto fornisce questo servizio, il processo mittente deve passare i suoi dati mediante il socket ed ha la certezza che i dati arriveranno senza errori al processo di destinazione. Quando un protocollo del livello trasporto non fornisce il trasferimento affidabile dei dati, alcuni dei dati inviati dal processo potrebbero non arrivare mai al processo destinazione. Questo può essere accettabile per le applicazioni che possono tollerare la perdita di qualche pacchetto, ad esempio per le applicazioni multimediali come le conversazioni audio/video. In queste applicazioni multimediali, i dati persi non compromettono la comprensione del messaggio.

Flusso (throughput)

Il throughput, nel contesto di una sessione di comunicazione tra due processi collegati tramite una rete, è il tasso a cui il processo sorgente consegna bit al processo ricevente. Poichè altre sessioni di comunicazione condividono il canale, e poichè altre sessioni si aggiungono o terminano, il throughput disponibile varia nel tempo. Queste osservazioni portano a un altro servizio naturale che un protocollo a livello di trasporto potrebbe fornire, cioè, garantire il throughput ad un certo tasso specificato. Con tale servizio, l'applicazione potrebbe richiedere una velocità garantita di r bit/sec, e il protocollo di trasporto dovrebbe quindi assicurare che il throughput disponibile resti sempre almeno r bit/sec. Tale servizio di throughput garantito serve a molte applicazioni. Ad esempio, se un'applicazione di telefonia su Internet codifica la voce a 32 kbps, è necessario che i dati inviati sulla rete vengano consegnati all'applicazione ricevente a questo ritmo. Se il protocollo di trasporto non può fornire tale velocità, l'applicazione ha bisogno di codificare a un tasso inferiore (e di ricevere dati dal processo a velocità inferiore) o potrebbe dover rinunciare, in quanto, ad esempio, la minore velocità renderebbe inutilizzabile l'applicazione di telefonia. Le applicazioni che hanno requisiti di throughput si dicono applicazioni bandwidth-sensitive. Molte applicazioni multimediali attuali dipendono dalla larghezza di banda, anche se alcune applicazioni multimediali possono utilizzare tecniche di codifica adattative per codificare voce o video digitalizzato ad una velocità che corrisponde alla velocità realmente disponibile.

Le applicazioni dipendenti dalla larghezza di banda hanno requisiti di throughput specifici, le applicazioni flessibili, invece, usano un elevato o un basso throughput, a seconda della disponibilità della banda. La posta elettronica, il trasferimento di file e le pagine Web sono applicazioni flessibili. Naturalmente, si desidera massimizzare il flusso.

Temporizzazione

Un protocollo del livello trasporto può anche fornire garanzie di temporizzazione. Come con il flusso garantito, la temporizzazione può essere garantita in varie forme. Ad esempio si potrebbe garantire che ogni bit consegnato dal mittente nel socket impiegherà non più di 100 ms per giungere al socket del ricevitore. Questo servizio dovrebbe soddisfare applicazioni interattive in tempo reale, come la telefonia, la teleconferenza, e i giochi multiplayer. Ognuna di queste applicazioni richiede che la consegna dei dati avvenga entro limiti di tempo ben definiti, altrimenti sono inefficaci. Lunghi ritardi nella telefonia via Internet, per esempio, introducono pause innaturali nella conversazione; in una partita multigiocatore o in un ambiente interattivo virtuale, un intervallo lungo tra il prendere un'azione e l'osservare la reazione dall'ambiente (ad esempio, da un altro giocatore all'altro sistema terminale di una connessione) rende l'applicazione meno realistica. Per le applicazioni non real-time, il minimo ritardo è gradito, ma non rappresenta un vincolo.

Sicurezza

Un protocollo di trasporto può fornire uno o più servizi di sicurezza. Ad esempio, nell'host mittente, un protocollo di trasporto può cifrare tutti i dati trasmessi dal processo sorgente e, nell'host di destinazione, il protocollo di trasporto può decodificare i dati prima di consegnarli al processo ricevente. Tale servizio fornirebbe la riservatezza della comunicazione ai due processi. Un protocollo di trasporto può anche fornire altri servizi di sicurezza in aggiunta alla riservatezza, tra cui l'integrità dei dati e l'autenticazione dei processi.

Servizi di Trasporto offerti da Internet

Fino a questo punto, sono stati considerati i servizi di trasporto che una rete di computer potrebbe fornire in generale. Adesso, più nello specifico, si esamina il tipo dei servizi di trasporto forniti da Internet. Internet (e, più in generale, le reti TCP/IP), offre due protocolli di trasporto alle applicazioni: UDP e TCP. Quando (come sviluppatore) si crea una nuova applicazione di rete, una delle prime decisioni da prendere è se utilizzare UDP o TCP. Ciascuno di questi protocolli offre un diverso insieme di servizi alle applicazioni. La figura seguente mostra i requisiti di servizio per alcune applicazioni.

Applicazione	Perdita di pacchetti	Throughput	Temporizzazione
File transfer/download	Senza perdita	Flessibile	No
E-mail	Senza perdita	Flessibile	No
Pagine Web	Senza perdita	Flessibile (pochi kbps)	No
Telefonia su Internet telephony Video conferenza	leggera tolleranza	Audio: da pochi kbps a 1Mbps Video: da 10 kbps a 5 Mbps	Sì: dell'ordine delle centinaia di 100 msec
Streaming di file audio/video	leggera tolleranza	Come sopra	Sì: pochi secondi
Giochi Interattivi	leggera tolleranza	da pochi kbps a 10 kbps	Sì: dell'ordine delle centinaia di 100 msec
Instant messaging	Senza perdita	Flessibile	Sì e No

Servizi TCP

Il TCP include un servizio orientato alla connessione e un servizio di trasferimento dati affidabile. Quando un'applicazione usa TCP come protocollo di trasporto, l'applicazione riceve entrambi questi servizi da TCP.

1. Servizio orientato alla connessione. Il TCP prevede uno scambio di informazioni di controllo tra il client e il server prima di scambiare messaggi tra i due processi del livello applicazione. Questa procedura di handshaking consente al client ed al server di prepararsi al trasferimento di pacchetti. Dopo la fase di handshaking, è stata stabilita una connessione TCP tra i socket dei due processi. La connessione è di tipo full-duplex, in quanto i due processi possono inviare contemporaneamente messaggi sulla connessione. Quando l'applicazione non ha messaggi da inviare, deve chiudere la connessione.

2. Servizio affidabile di trasferimento dei dati. I processi in comunicazione possono essere sicuri che il TCP invii tutti i pacchetti senza errori e nel giusto ordine. Quando una delle applicazioni invia un flusso di byte in un socket, è sicura che il TCP consegni lo stesso flusso di byte al socket del ricevente, senza byte persi o duplicati.

TCP include anche un meccanismo di controllo della congestione, un servizio nell'interesse generale di Internet, piuttosto che a beneficio diretto dei processi in comunicazione. Il meccanismo di controllo della congestione TCP rallenta un processo sorgente (client o server) quando la rete, tra mittente e destinatario, è congestionata.

Servizi UDP

UDP è un protocollo di trasporto leggero, che offre servizi minimi. UDP è senza connessione, quindi non c'è sincronizzazione prima che i due processi inizino a comunicare. UDP non fornisce un servizio di trasferimento dei dati affidabile cioè, quando un processo invia un messaggio in un socket UDP, UDP non fornisce alcuna garanzia che il messaggio raggiungerà il processo destinatario. Inoltre, i messaggi che arrivano al processo destinatario possono arrivare fuori ordine.

UDP non prevede un meccanismo di controllo della congestione, di conseguenza il processo sorgente di UDP può passare dati al livello sottostante (livello di rete) ogni volta che ha dati da trasferire. (Si noti, tuttavia, che il flusso effettivo end-to-end può essere inferiore a questo tasso a causa della capacità dei canali o a causa della congestione).

Servizi non forniti dai protocolli di Trasporto di Internet

I servizi del protocollo di trasporto sono: il trasferimento affidabile dei dati, il flusso, i tempi, e la sicurezza. Quale di questi servizi sono forniti da TCP e quali da UDP? TCP fornisce il trasferimento affidabile dei dati end-to-end. Inoltre il TCP, con SSL, fornisce servizi di sicurezza alle applicazioni. Il TCP e l'UDP non forniscono garanzie di temporizzazione e di flusso. Questo significa che applicazioni come la telefonia via Internet non possono essere eseguite in Internet. Queste applicazioni spesso funzionano abbastanza bene perchè sono state progettate con funzionalità che sopperiscono, per quanto possibile, a questa mancanza di garanzia.

Applicazioni quali e-mail, accesso a terminali remoti, il Web, e il trasferimento di file usano TCP. Per queste applicazioni si è scelto TCP soprattutto perchè fornisce il trasferimento affidabile dei dati, garantendo che tutti i dati giungano a destinazione. Poichè le applicazioni di telefonia (come Skype) possono tollerare qualche perdita, ma richiedono un tasso minimo per essere efficaci, gli sviluppatori delle applicazioni di telefonia di solito preferiscono eseguire le applicazioni su UDP, aggirando in tal modo il meccanismo di controllo della congestione del TCP a spese dei pacchetti. Ma poichè molti firewall sono configurati per bloccare il traffico UDP, le applicazioni di telefonia sono progettate per ripiegare sul protocollo TCP se la comunicazione UDP fallisce.

Protocolli del livello Applicazione

I processi di rete comunicano tra loro mediante l'invio di messaggi attraverso i socket. Un protocollo del livello applicazione definisce il modo in cui i processi applicativi, in esecuzione su sistemi terminali diversi, si scambiano messaggi. In particolare, un protocollo del livello applicazione definisce:

• Il tipo dei messaggi scambiati, per esempio, i messaggi di richiesta e i messaggi di risposta;

• La sintassi dei vari tipi di messaggio, ad esempio in quali campi è strutturato e come questi sono delimitati;

• La semantica dei campi, cioè il significato delle informazioni contenute nei campi;

• Le regole per determinare quando e come un processo invia messaggi e risponde ai messaggi

Alcuni protocolli del livello applicazione sono specificati nelle RFC e sono quindi di pubblico dominio. Ad esempio, il protocollo del Web nel livello applicazione, HTTP (HyperText Transfer Protocol) è disponibile nella RFC 2616. Se uno sviluppatore di browser segue le regole della RFC, il browser sarà in grado di recuperare le pagine Web da qualsiasi server Web che rispetta le regole della RFC relativa all'HTTP. Molti altri protocolli del livello applicazione sono proprietari e volutamente non disponibili nel pubblico dominio. Ad esempio, Skype utilizza protocolli proprietari del livello applicazione.

È importante distinguere tra applicazioni di rete e protocolli del livello applicazione. Un protocollo del livello applicazione è solo un pezzo di un'applicazione di rete. Esempi: Il Web è un'applicazione client-server che consente agli utenti di ottenere i documenti da server Web su richiesta. L'applicazione Web è costituita da molti componenti, tra cui uno standard per il formato dei documenti (cioè, HTML), un browser (ad esempio, Firefox e Internet Explorer), un server Web (ad esempio, i server Apache e Microsoft), e di un protocollo del livello applicazione. Il protocollo del livello applicazione del Web, HTTP, definisce il formato e la sequenza di messaggi scambiati tra il browser e il server web. Così, HTTP è solo un pezzo dell'applicazione web.

Come altro esempio, anche un'applicazione di posta elettronica ha molti componenti, tra cui i server di posta che ospitano le caselle postali degli utenti; i client di posta elettronica (come Outlook) che permettono agli utenti di leggere e comporre messaggi; uno standard per definire la struttura di un messaggio di posta elettronica; i protocolli del livello applicazione che definiscono: il modo in cui i messaggi vengono passati tra server, il modo in cui i messaggi vengono passati tra server e client di posta, il modo in cui il contenuto delle intestazioni dei messaggi devono essere interpretati. Il protocollo del livello applicazione per la posta elettronica è SMTP (Simple Mail Transfer Protocol) [RFC 5321].

Applicazioni di rete

Nel seguito di questo capitolo ci si concentrerà su alcune applicazioni molto diffuse: il Web, il trasferimento di file, la posta elettronica, il servizio di directory e le applicazioni P2P. Verrà esaminato il web, non solo perchè si tratta di un'applicazione molto popolare, ma anche perchè il suo protocollo del livello applicazione, HTTP, è semplice e facile da capire. Dopo il Web, si esaminerà FTP, perchè consente alcuni interessanti confronti con HTTP. Poi si esaminerà la posta elettronica. Questa è più complessa del Web, nel senso che si avvale non di uno ma di diversi protocolli del livello applicazione. Dopo l'e-mail, si descriverà il DNS, che fornisce un servizio di directory per Internet. La maggior parte degli utenti non interagisce direttamente con DNS; gli utenti invocano DNS tramite altre applicazioni (tra cui il Web, il trasferimento di file e la posta elettronica). DNS illustra bene come una funzionalità di base della rete può essere implementata a livello applicazione in Internet.