Scarica Protocollo di Comunicazione sul Web: Introduzione al Protocollo HTTP e più Dispense in PDF di Informatica gestionale solo su Docsity!
Cosa succede quando si clicca un un link: I protocolli di
comunicazione
Sito: Virtuale Corso: Informatica di Base (1) (A-D) Libro: Cosa succede quando si clicca un un link: I protocolli di comunicazione Stampato da: Ludovica Caporaso Data: domenica, 16 maggio 2021, 15
Sommario
**1. Introduzione
- Che cosʼè un protocollo di comunicazione
- Come funziona lʼHypertext Transfer Protocol (HTTP)
- Che cosʼè un server web
- Bibliografia**
2. Che cosʼè un protocollo di comunicazione
Formalmente, un protocollo di comunicazione è un insieme di regole che due entità, parte di un sistema di comunicazione, devono seguire per scambiarsi informazioni. Informalmente, può essere considerato come un linguaggio comune, nel senso proprio del termine, usato da due entità in modo da poter comunicare fra loro. Infatti, ogni protocollo definisce una specifica sintassi da seguire per costruire i messaggi, accompagnata da determinate regole interpretative del messaggio così da definirne anche la semantica. Inoltre, solitamente, un protocollo di comunicazione prevede anche dei meccanismi per sincronizzare la comunicazione e per correggere e/o gestire eventuali errori che possono intercorrere nello scambio dei messaggi. Protocolli di varia natura, anche informali, sono utilizzati nella vita di tutti i giorni quando vogliamo, per esempio, comunicare con qualcuno. Per esempio, il diagramma in Figura 2 riassume le componenti principali del protocollo, strettamente informale, che due persone, fluenti nella lingua italiana, utilizzano per scambiarsi delle informazioni verbalmente. In questo caso, mentre la sintassi della lingua è veicolata da opportune regole, e la semantica delle varie parole che compongono il messaggio è stata appresa nel tempo con lʼapprendimento della lingua stessa, le altre componenti del protocollo derivano principalmente da regole sociali (ad esempio, il parlare uno alla volta) e dalle proprie conoscenze (ad esempio, riproponendo il senso di un messaggio usando differenti costrutti se è poco chiaro allʼinterlocutore) e dallʼambiente circostante (ad esempio, alzando la voce per farsi sentire meglio). Figura 2. Esempio di protocollo di comunicazione tra due persone che usano lʼitaliano come lingua di comunicazione. Nel corso di questo e dei successivi capitoli, analizzeremo alcuni dei protocolli di comunicazione più importanti per il funzionamento del Web e di Internet, a partire dal protocollo HTTP.
3. Come funziona lʼHypertext Transfer Protocol (HTTP)
LʼHypertext Transfer Protocol, o HTTP [Fielding et al., 1999], è un protocollo di comunicazione inizialmente sviluppato da Tim Berners-Lee per facilitare lʼimplementazione del Web, e poi migliorato ed esteso negli anni successivi – ad esempio con il protocollo HTTPS, che altri non è che unʼestensione di HTTP che implementa un protocollo di comunicazione più sicuro sul Web, in particolare quando è necessario trasmettere dati di autenticazione come nomi utenti e password. HTTP è un protocollo basato su metodi di comunicazione di richiesta-risposta, tipico di molti protocolli (anche informali) di comunicazione – si pensi, ad esempio, al protocollo che regola le telefonate, dove un richiedente chiama (la richiesta) un ricevente che accetta la chiamata (la risposta) per iniziare la conversazione. Nel caso di HTTP, un client (lʼagente che fa la richiesta, ad esempio un browser) manda un messaggio di richiesta di una specifica risorsa, identificata da un URL, ad un server (lʼagente che dovrebbe avere informazioni su quella specifica risorsa, ad esempio un server Web), che restituisce al client un messaggio di risposta. La composizione di questo messaggio di risposta dipende da diversi fattori – ad esempio se la risorsa è o non è presente sul server, se è stata spostata in unʼaltra locazione, etc. – e, anche, dal tipo di richiesta effettuata dal client. Le tipologie di richieste che possono essere effettuate da un client vengono definite grazie allʼuso di uno specifico metodo, ovvero lʼoperazione di richiesta relativa allʼURL coinvolto nella comunicazione. In pratica è come se, quando si comunica con qualcuno, si avesse la possibilità di scegliere tra alcune possibili operazioni che il ricevente deve eseguire, che possono andare dalla semplice richiesta di informazioni (ad esempio, quando chiamiamo la banca per sapere lo stato del nostro conto), ad azioni più operative che determinano lʼesecuzione di una specifica azione da parte del ricevente (ad esempio, quando chiamiamo la banca per far emettere un bonifico). Il metodo più usato nel Web è sicuramente GET, che permette di richiedere informazioni sulla risorsa definita dallʼURL specificato. GET viene usato ogni qual volta richiediamo di visitare una specifica pagina web, per esempio come conseguenza di un click su un collegamento ipertestuale. Altri metodi largamente usati sono: PUT permette di creare sul server web contattato la risorsa specificata dallʼURL utilizzato nella richiesta, e di associare le informazioni, relative ad essa, incluse nella richiesta effettuata; DELETE permette di rimuovere dal server web contattato tutte le informazioni relative alla risorsa specificata nella richiesta tramite lʼURL; POST permette di specificare informazioni aggiuntive, incluse nella richiesta, ad una risorsa esistente che già risiede sul server. Tuttavia, mentre GET è preponderante nel Web, visto che viene usato per richiedere una qualsiasi risorsa, gli altri metodi non sempre sono liberamente utilizzabili da tutti i client. Sta sempre al server web decidere quali di questi metodi possano essere usati nella comunicazione. Tutti i metodi HTTP sono classificabili a seconda che siano conformi o meno a due caratteristiche specifiche, ovvero se sono safe e/o se sono idempotenti. Un metodo si dice safe quando viene usato solo per recuperare delle informazioni dal server web, senza cambiarne lo stato, ad esempio aggiungendo nuovi dati. Il metodo GET è un metodo safe, considerando che viene usato soltanto per richiedere informazioni relativamente ad una specifica risorsa, mentre PUT non lo è perché viene usato per creare una nuova risorsa sul server web. Invece, un metodo si dice idempotente se molteplici richieste effettuate allo stesso URL hanno lo stesso effetto, sul server web, che effettuare una sola richiesta. Anche in questo caso, il metodo GET, così come PUT e DELETE, sono metodi idempotenti, mentre POST non lo è, perché diverse richieste POST identiche possono di fatto generare comportamenti differenti. A prescindere dal metodo usato per la comunicazione, tutti i messaggi di ogni richiesta e risposta veicolano due tipi di dati ben distinti: i metadati relativi alla comunicazione – come il nome di client usato per effettuare la richiesta, il nome del server web che dovrebbe avere a disposizione la risorsa, etc. – ed eventuali dati (o contenuto) da accompagnare al messaggio. Per esempio, in una conversazione telefonica, il chiamante come prima cosa introduce chi è al ricevente (i metadati della comunicazione), per poi passare ad esplicitare il motivo della chiamata e le informazioni che si vorrebbero ottenere (il contenuto della comunicazione). Considerando i messaggi consegnati utilizzando il protocollo HTTP, queste due tipologie di informazioni, ovvero i metadati e i dati, sono contenute in due specifiche sezioni del messaggio, rispettivamente chiamate intestazione (header) e contenuto (payload). Tipicamente, una qualunque richiesta o risposta ha sempre lʼheader specificato, mentre il payload può contenere informazioni come no. Per esempio, quando si richiede una pagina web attraverso un browser, viene effettuata una richiesta ad un certo URL contenente soltanto i metadati nellʼheader, mentre il payload è completamente vuoto. Al contrario, la risposta del server web contiene sia informazioni nellʼheader sia un vero e proprio documento nel payload, ovvero la pagina web che deve essere visualizzata sul browser richiedente, nel caso tale informazione sia a disposizione del server web a cui è arrivata la richiesta. Tutte le risposte, oltre che a contenere metadati nellʼheader e, talvolta, dati nel payload, specificano anche un codice di stato che indica se la richiesta è andata a buon fine o se sono intercorsi dei problemi. Un codice di stato è un numero di tre cifre, la cui prima cifra (da 1 a 5) definisce la classe di risposta, mentre le altre due sono usate per identificare una specifica motivazione relativa alla risposta. Le cinque classi di risposta sono:
4. Che cosʼè un server web
Come anticipato nel precedente capitolo, un server web è un computer “speciale” che esegue un software specifico che permette di ricevere, gestire, e soddisfare richieste HTTP provenienti da un client, ad esempio un browser. Il nome del server web è incluso nellʼURL che identifica la risorsa di cui si vuole ottenere informazioni, nella parte host, come introdotto nel capitolo precedente (ad esempio it.wikipedia.org). Tuttavia, la forma corretta e completa della richiesta HTTP mandata dal client non è quella semplicistica introdotta precedentemente col solo URL, ma è strutturata in modo preciso, in modo da identificare i vari componenti che ne fanno parte, incluso il nome del server web da contattare. In particolare, quando un client (ad esempio, un browser) richiede informazioni su una specifica risorsa (ad esempio una pagina web) utilizzando lʼURL relativo, la richiesta che viene davvero effettuata ha la seguente forma, dove ogni parte della richiesta è di fatto derivata dallʼURL: HOST: Ad esempio, quando si vuole accedere alla pagina web allʼURL http://it.wikipedia.org/wiki/Uniform_Resource_Locator, la richiesta effettuata dal browser viene strutturata come segue: GET /wiki/Uniform_Resource_Locator HTTP/1. HOST: it.wikipedia.org Una volta che il server web riceve una richiesta fatta in questo modo, cerca localmente informazioni del documento indicate nel percorso della richiesta e, una volta trovate, le impacchetta in un nuovo messaggio di risposta, restituendole al richiedente. Tuttavia, cʼè un ulteriore aspetto molto importante che non è stato ancora discusso in questo capitolo. Seppur noi, utilizzatori di client come i browser, cerchiamo di accedere ad una risorsa a disposizione in un certo server web usando il nome di questʼultimo, it.wikipedia.org nellʼesempio precedente, in realtà il server web non è direttamente raggiungibile usando il suo nome, ma avviene una cosa molto simile a quello che succede con una comunicazione telefonica. In pratica, quando dobbiamo chiamare qualcuno col nostro cellulare, cerchiamo questa persona nella nostra rubrica attraverso il suo nome, e chiediamo al nostro cellulare di iniziare una chiamata telefonica. Tuttavia, quello che davvero fa il cellulare, è di prendere il numero di telefono associato a quella persona e di attivare la comunicazione mandando una richiesta di telefonata a questo numero. Ovviamente, in alternativa, si potrebbe anche digitare direttamente il numero di telefono della persona che si vuol chiamare se si conosce a memoria, senza necessariamente cercarla in rubrica. In più, se il numero chiamato è un numero fisso di casa, e in casa vivessero diverse persone, una volta che la telefonata è stata risposta, il mittente dovrebbe chiedere esplicitamente al ricevente di poter parlare con la persona di interesse. Questo scenario, molto naturale, si presenta in modo totalmente analogo anche quando un client richiede una pagina web ad un server web. Infatti, un qualunque server web è identificato in modo univoco da una sequenza di quattro numeri separati da punti, ad esempio 130.136.130.1, ove ogni numero può essere un valore che va da 0 a 255. Questo numero si chiama indirizzo IP, dove “IP” è lʼacronimo di “Internet Protocol”, che discuteremo in dettaglio nel capitolo successivo. In pratica, ogni volta che si fa una richiesta HTTP, in qualche modo viene recuperato lʼindirizzo IP del server web a cui mandare la richiesta partendo dal nome di questo indicato nellʼURL – il campo host – per poi inviare il messaggio esplicitamente a quellʼindirizzo, menzionando esplicitamente, come abbiamo visto in precedenza, qual è il nome del server a cui il messaggio deve essere rivolto – nellʼesempio sopra HOST: it.wikipedia.org. Figura 3 estende il diagramma in Figura 1 includendo tutte le tecnologie presentate in questo capitolo. Figura 3. Riassunto delle tecnologie che abbiamo trattato in questo capitolo e nel precedente.
5. Bibliografia
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., & Berners-Lee, T. (1999). Hypertext Transfer Protocol -- HTTP/1.1 (Request For Comment No. RFC2616). Internet Engineering Task Force. https://doi.org/10.17487/rfc 2616
