Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Capitolo 2 PowerPoint Presentation

Capitolo 2

237 Views Download Presentation
Download Presentation

Capitolo 2

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Capitolo 2 LivelloApplicazione

  2. Capitolo2: indice 2.1 INTRODUZIONE 2.2 PARADIGMA CLIENT-SERVER 2.3 APPLICAZIONI STANDARD 2.4 PARADIGMA PEER-TO-PEER 2.5 PROGRAMMAZIONE DELLE SOCKET

  3. Capitolo 2: Obiettivi • Si analizza la natura dei servizi forniti da Internet: il paradigma client-server e il paradigma peer-to-peer. • Si approfondisce il paradigma client-server. • Si discutono alcune applicazioni standard o predefinite basate sul paradigma client-server come il WWW, il trasferimento di file e la posta elettronica. • Si affrontano il concetto e i protocolli nel paradigma peer-to-peer come Chord, Pastry e Kademlia. • Si mostra come creare una nuova applicazione client-server scrivendo due programmi in linguaggio C.

  4. 2-1Introduzione Il livello applicazione fornisce servizi all’utente. La comunicazione è fornita per mezzo di una connessione logica: questo significa che i livelli applicazione nei due lati della comunicazione agiscono come se esistesse un collegamento diretto attraverso il quale poter inviare e ricevere messaggi. La Figura 2.1 illustra l’idea alla base di questo collegamento logico.

  5. Figura 2.1: Connessione logica a livello applicazione

  6. 2.1.1 L’offerta di servizi Internet venne inizialmente progettata per fornire servizi ai suoi utenti. Dato che il livello applicazione è l’unico che fornisce servizi agli utenti di Internet, la sua flessibilità consente di aggiungere nuovi protocolli con estrema facilità, così come si è verificato nella storia di Internet e sta tuttora avvenendo. Alla nascita di Internet solo alcuni protocolli di livello applicazione erano disponibili per gli utenti; oggi non è più possibile indicare il numero dei protocolli esistenti poiché ne vengono costantemente aggiunti di nuovi.

  7. 2.1.1 L’offerta di servizi (continuazione) • Protocolli standard e non standard • Protocolli standard di livello applicazione • Protocolli non standard di livello applicazione

  8. 2.1.2 Paradigmidel livello applicazione Dovrebbe ormai essere chiarocheper utilizzare Internet sono necessari due programmi che interagiscono l’uno con l’altro: uno eseguito su un certo computer in qualche parte del mondo, l’altro eseguito su un secondo computer in qualsiasi altro luogo. I due programmi hanno la necessità di scambiarsi messaggi sfruttando l’infrastruttura di Internet. La modalità di relazione tra questi due programmi non è ancora stata trattata. I due programmi applicativi devono essere entrambi ingrado di richiedere e offrire servizi, oppure ciascuno deve occuparsi di uno dei due compiti?

  9. 2.1.2 Paradigmi del livello applicazione (continuazione) • Client-Server: il paradigma tradizionale • Peer-to-peer: il nuovo paradigma • Il paradigma misto

  10. Figura 2.2: Esempio di architettura client-server

  11. Figura 2.3: Esempio di architettura peer-to-peer

  12. 2-2 Paradigma CLIENT-SERVER • Nel paradigma client/server la comunicazione a livello applicazione avviene tra due programmi applicativi in esecuzione chiamati processi: un client e un server. • Un client è un programma in esecuzione che inizia la comunicazione inviando una richiesta; • Un server è un altro programma applicativo che attende le richieste dai client.

  13. 2.2.1 API: Application Programming Interface Un linguaggio di programmazione prevede un insieme di istruzioni matematiche, un insieme di istruzioni per la manipolazione delle stringhe, un insieme di istruzioni per la gestione dell’input/output ecc. Se si vuole sviluppare un programma capace di comunicare con un altro programma, è necessario un nuovo insieme di istruzioni per chiedere ai primi quattro livelli dello stack TCP/IP di aprire la connessione, inviare/ricevere dati e chiudere la connessione. Un insieme di istruzioni di questo tipo viene chiamato API (Application Programming Interface).

  14. 2.2.1 API (continuazione) • Socket • Socket Address • Individuare i Socket Address • Lato server • Lato client

  15. Figura 2.4: L’interfaccia socket nella pila dei protocolli

  16. Figura 2.5: Impiego delle socket nella comunicazione tra processi

  17. Figura 2.6: Un socket address

  18. Esempio 2.1 È possibile individuare degli indirizzi a due livelli anche nella comunicazione telefonica. Il numero di telefono identifica l’azienda, mentre l’estensione identifica un utente specifico all’interno dell’azienda. Il numero di telefono che identifica l’azienda corrisponde in questo caso all’indirizzo IP, l’estensione che identifica il particolare utente corrisponde al numero di porta.

  19. 2.2.2 Utilizzo dei servizi di livello trasporto Una coppia di processi fornisce servizi agli utenti di Internet, siano questi persone o applicazioni. La coppia di processi, tuttavia, deve utilizzare i servizi offerti dal livello trasporto per la comunicazione, poiché non vi è una comunicazione fisica a livello applicazione. Nel livello trasporto della pila di protocolli TCP/IP sono previsti due protocolli principali: • Protocollo UDP • Protocollo TCP

  20. 2-3 Applicazioni client/server standard Nel tempo sono state sviluppate numerose applicazioni client/server. Il nostro obiettivo non è quello di riprogettarle, ma di comprenderne il funzionamento e di conoscere, per ciascuna applicazione, le opzioni a nostra disposizione. Lo studio di questi programmi e del modo in cui forniscono i vari servizi potrà aiutarci a creare nuove applicazioni adatte alle nostre esigenze.

  21. 2.3.1 World Wide Web e HTTP In questo paragrafo si introduce per primo il World Wide Web, abbreviato con l’acronimo WWW o con Web. Di seguito verrà descritto l’HTTP (Hypertext Transfer Protocol), il protocollo client/server più utilizzato nel Web.

  22. 2.3.1 WWW e HTTP (continuazione) • World Wide Web • Architettura • URL (Uniform Resource Locator) • Documenti Web • HTTP (HyperText Transfer Protocol) • Connessioni persistenti e non persistenti • Formato dei messaggi • Richieste condizionali • Cookie

  23. 2.3.1 WWW e HTTP (continuazione) • Web Caching: il server proxy • Posizione del server proxy • Aggiornamento della cache • Aspetti di sicurezza nel protocollo HTTP

  24. Esempio 2.2 Si supponga di voler ottenere un documento scientifico che contiene un riferimento a un altro documento testuale e un riferimento a un’immagine, come illustrato nella Figura 2.7. Il documento principale e l’immagine sono memorizzati in due file separati nello stesso sito (file A e file B), mentre il documento testuale referenziato è memorizzato in un altro file in un altro sito (file C). Poiché si hanno tre file differenti, sono necessarie tre transazioni per poter vedere il documento completo.

  25. Figura 2.7: Esempio 2.2 (Prelievo di due file e un’immagine)

  26. Figura 2.8: Architettura generale di un browser

  27. Esempio 2.3 L’URL http://www.ateneonline.it/forouzan identifica la pagina Web associata all’edizione italiana di questo volume. La stringa www.ateneonline.it è il nome di un computer dell’azienda McGraw-Hill (le tre lettere www fanno convenzionalmente parte del nome dell’host). Il percorso invece è /forouzan, che definisce la pagina Web di questo testo.

  28. Esempio 2.4 La Figura 2.9 illustra un esempio di connessione non persistente. Il client deve accedere a un file che contiene un link a un’immagine; il file di testo e l’immagine si trovano sullo stesso server. In questo caso sono richieste due connessioni. Per ognuna di queste, TCP richiede almeno tre messaggi di handshake per stabilire la connessione, inviando la richiesta all’interno del terzo messaggio. Una volta stabilita la connessione l’oggetto richiesto può essere trasferito; una volta ricevuto, sono necessari altri tre messaggi di terminazione per la chiusura della connessione, come si vedrà nel Capitolo 3.

  29. Figura 2.9: Esempio 2.4

  30. Esempio 2.5 La Figura 2.10 illustra lo stesso scenario dell’Esempio 2.4, utilizzando però le connessioni persistenti. Vengono utilizzate una sola apertura e chiusura della connessione, la richiesta dell’immagine sfrutta la connessione già aperta.

  31. Figura 2.10: Esempio 2.5

  32. Figura 2.11: Formati dei messaggi di richiesta e di risposta

  33. Tabella 2.1: Metodi di HTTP

  34. Tabella 2.2: Intestazione di richiesta

  35. Tabella 2.3: Intestazione di risposta

  36. Esempio 2.6 Questo esempio (Figura 2.12) illustra come il client preleva un documento: viene usato il metodo GET per ottenere l’immagine individuata dal percorso /usr/bin/image1. La riga di richiesta contiene il metodo (GET), l’URL e la versione (1.1) del protocollo HTTP. L’intestazione è costituita da due righe in cui si specifica che il client accetta immagini nei formati GIF e JPEG. Il messaggio di richiesta non ha corpo. Il messaggio di risposta contiene la riga di stato e quattro righe di intestazione che contengono la data, il server, il metodo di codifica del contenuto (la versione MIME, argomento che verrà descritto nel paragrafo dedicato alla posta elettronica) e la lunghezza del documento. Il corpo del messaggio segue l’intestazione.

  37. Figura 2.12: Esempio 2.6

  38. Esempio 2.7 In questo esempio il client spedisce al server una pagina Web da pubblicare. Si utilizza il metodo PUT. La riga di richiesta contiene il metodo (PUT), l’URL e la versione (1.1) del protocollo HTTP. L’intestazione è costituita da quattro righe d’intestazione. Il corpo del messaggio di richiesta contiene la pagina Web inviata. Il messaggio di risposta contiene la riga di stato e quattro righe di intestazione. Il documento creato, un documento CGI, è incluso nel corpo del messaggio di risposta (Figura 2.13).

  39. Figura 2.13: Esempio 2.7

  40. Esempio 2.8 Si illustra come un client può specificare La condizione di data e ora di modifica in una richiesta. La riga di stato nella risposta indica che il file non è stato modificato successivamente alla data indicata. Il corpo del messaggio è vuoto anche in questo caso.

  41. Esempio 2.9 La Figura 2.14 illustra uno scenario nel quale un negozio elettronico sfrutta opportunamente l’impiego dei cookie. Si supponga che un cliente desideri comprare un giocattolo da un negozio elettronico chiamato BestToys. Il browser del cliente invia una richiesta al server BestToys. Questo crea per il cliente un carrello della spesa vuoto e gli assegna un identificatore (per esempio 12343). Il server invia quindi un messaggio di risposta che contiene le immagini di tutti i giocattoli disponibili, con un link associato a ciascun giocattolo che consente all’utente di selezionarlo. Questo messaggio di risposta contiene anche la riga di intestazione “ Set-Cookie” con valore 12343. Il browser sul computer client visualizza le immagini e memorizza il valore del cookie in un file chiamato BestToys.

  42. Figura 2.14: Esempio 2.9

  43. Esempio 2.10 La Figura 2.15 illustra un esempio di impiego di un server proxy in una rete locale, per esempio una rete aziendale o un campus universitario. Il proxy è installato all’interno della rete locale. Quando il browser di uno dei client genera una richiesta HTTP, questa viene diretta per prima cosa al proxy. Se questi ha già la pagina corrispondente invia la risposta al client. In caso contrario il proxy agisce da client e invia la richiesta al server Web in Internet. Quando la risposta viene restituita, il proxy ne memorizza una copia nella propria memoria cache prima di inviarla al client che l’aveva richiesta.

  44. Figura 2.15: Esempio di architettura di rete con server proxy

  45. 2.3.2 FTP FTP (File Transfer Protocol) è il protocollo standard offerto da TCP/IP per la copia di file da un host a un altro. Sebbene il trasferimento di un file possa sembrare un’operazione semplice, vi sono, in realtà, numerosi problemi ai quali bisogna prestare attenzione: i due sistemi coinvolti, per esempio, possono adottare convenzioni differenti per la denominazione dei file, oppure gestire in modo differente la struttura delle directory. Problemi di questo tipo vengono risolti in modo semplice ed elegante dal protocollo FTP.

  46. 2.3.2 FTP (continuazione) • Durata delle due connessioni • Connessione di controllo • Connessione per lo scambio dei dati • Comunicazione lungo la connessione per lo scambio dei dati • Trasferimento di file • Sicurezza nel protocollo FTP

  47. Figura 2.16: Il protocollo FTP

  48. Tabella 2.4: Principali comandi FTP

  49. Tabella 2.5: Esempi di risposte FTP

  50. Esempio 2.11 La Figura 2.17 illustra un esempio d’uso di FTP per trasferire un file dal server al client. Questa figura riguarda il trasferimento di un solo file. La connessione di controllo rimane sempre aperta, la connessione dati viene invece aperta e chiusa ripetutamente. Si ipotizza che il file venga trasferito in sei fasi. Appena completato il trasferimento, il processo di controllo server chiude la connessione dati. Dato che il processo di controllo client non ha altri file da trasferire, invia il comando QUIT che fa chiudere la connessione di controllo.