In questa lezione analizzeremo i protocolli di comunicazione client-server, pilastri fondamentali per l'interazione nelle architetture di rete moderne.
Esamineremo come questi standard permettano lo scambio di dati efficiente e sicuro tra sistemi, essenziale per comprendere il funzionamento dei servizi web e del cloud computing.
Quando uno studente scrive l'indirizzo di un sito nella barra del browser e preme invio, il suo computer e quello del server non si erano mai incontrati prima, sono stati costruiti da aziende diverse, usano sistemi operativi diversi e programmi scritti da persone che non si conoscono. Eppure si capiscono al primo colpo. Questo accade perche entrambi seguono lo stesso protocollo: un insieme di regole stabilite in anticipo e uguali per tutti.
Nelle lezioni precedenti abbiamo visto chi fa cosa in un'architettura client-server e quali caratteristiche servono ai due ruoli. Restava aperta la domanda tecnica: in che modo, concretamente, i messaggi vengono formulati e scambiati. Questa lezione risponde alla prima meta della domanda, occupandosi delle regole del dialogo.
Un protocollo di comunicazione e un insieme di regole condivise che stabiliscono come due programmi collegati in rete devono scambiarsi i messaggi. In particolare definisce il formato dei messaggi (come sono fatti dentro, quali parti contengono), il loro significato (cosa vuol dire ciascun tipo di messaggio), la sequenza ammessa (chi parla per primo, cosa puo seguire cosa) e il comportamento da tenere in caso di errore.
Il motivo per cui questo insieme di regole e indispensabile e stato in realta gia incontrato parlando di eterogeneita: il client puo girare su qualunque dispositivo e sistema operativo, e il server e stato scritto da qualcun altro. Nessuno dei due puo permettersi di dare per scontato come sia fatto l'altro. Il protocollo e il terreno comune che rende possibile l'intesa: se entrambi lo rispettano, funzionano insieme anche senza essersi mai conosciuti.
Sapere a quale macchina rivolgersi non basta. Su uno stesso server possono essere attivi contemporaneamente piu servizi diversi: un sito web, un servizio di posta, un archivio di file. Per distinguerli si usa il numero di porta, un numero associato al singolo servizio in ascolto su quella macchina.
La divisione dei compiti e quindi netta: l'indirizzo IP individua la macchina nella rete, il numero di porta individua il servizio attivo su quella macchina, e il protocollo stabilisce cosa dirsi una volta stabilito il contatto. I protocolli piu diffusi hanno porte assegnate per convenzione, cosi un client sa dove bussare senza doverlo chiedere: e il motivo per cui un browser trova il servizio web di un sito senza che l'utente debba indicare nulla oltre all'indirizzo.
Regola fondamentale: per raggiungere un servizio servono tre informazioni distinte e complementari: l'indirizzo della macchina, la porta del servizio su quella macchina, e il protocollo che regola il dialogo. Sbagliarne una sola impedisce la comunicazione, anche se le altre due sono corrette.I protocolli che l'utente incontra piu spesso sono quelli applicativi, cioe quelli che descrivono un servizio specifico. I principali, nel mondo client-server, sono pochi e ricorrenti.
HTTP (e la sua versione protetta HTTPS) regola il dialogo fra browser e server web: il client chiede una risorsa, il server la restituisce insieme a un codice che dice come e andata. I protocolli della posta elettronica sono divisi per compito: SMTP serve a inviare i messaggi, mentre IMAP e POP servono a consultarli dal server. FTP, e le sue varianti protette, si occupa del trasferimento di file. DNS traduce i nomi leggibili dalle persone negli indirizzi numerici usati dalla rete. SSH permette di accedere a una macchina remota lavorandoci come se si fosse davanti, ma attraverso un canale protetto.
Tutti seguono lo schema richiesta-risposta visto nella lezione sulla definizione di client-server, ma ciascuno stabilisce un proprio vocabolario di messaggi, adatto al servizio che descrive.
Digitare l'indirizzo di un sito e premere invio mette in gioco due protocolli diversi in pochi istanti: prima il computer usa DNS per chiedere a quale indirizzo numerico corrisponda quel nome, poi usa HTTP (o HTTPS) verso quell'indirizzo per chiedere la pagina vera e propria. Due dialoghi distinti, con due server diversi, dietro un gesto solo. Il server didattico di una scuola puo offrire nello stesso momento un sito interno consultabile dal browser e un servizio per il trasferimento dei file degli studenti. Si tratta della stessa macchina, quindi dello stesso indirizzo IP, ma di due servizi in ascolto su porte diverse, ciascuno con il proprio protocollo: e la porta a dire a quale dei due si sta bussando.I protocolli applicativi non si occupano di tutto: descrivono che cosa i due programmi si dicono, ma non come i dati attraversano materialmente la rete. Di questo si occupa un livello sottostante, quello dei protocolli di trasporto, il cui compito e portare i dati da un capo all'altro e, a seconda del protocollo scelto, garantire o meno che arrivino tutti, integri e nell'ordine giusto.
I due livelli sono complementari e vanno tenuti distinti: HTTP stabilisce che il client chieda una pagina e che il server risponda con un codice e un contenuto; il livello di trasporto fa in modo che quella richiesta e quella risposta arrivino davvero a destinazione. Il modo in cui un programma utilizza concretamente il livello di trasporto per aprire una comunicazione e argomento delle prossime lezioni di questa unita, dedicate ai socket.
L'errore piu frequente e confondere il protocollo con il programma che lo usa. HTTP non e il browser: e l'insieme delle regole che il browser rispetta, e che rispettano anche programmi molto diversi, come un'app per smartphone o uno script che scarica dati automaticamente. Allo stesso modo SMTP non e il programma di posta, ma la convenzione che tutti i programmi di posta seguono per inviare i messaggi.
Un secondo errore e credere che ogni nuovo servizio richieda un protocollo nuovo. Nella pratica accade l'opposto: si riutilizzano i protocolli standard esistenti, e in particolare HTTP, perche sono gia implementati ovunque, gia gestiti dagli apparati di rete e gia noti a chi programma. Inventare un protocollo proprio significa doverlo realizzare, documentare e mantenere da soli su entrambi i lati.
Resta infine un limite di prospettiva utile da tenere presente: conoscere il protocollo dice quali messaggi vengono scambiati e con quali regole, ma non dice nulla su quanto sia sicuro il canale, ne su come il server tratti i dati una volta ricevuti. Sono aspetti che dipendono da altre scelte, che incontreremo piu avanti nel corso.
Di fronte a un servizio di rete, tre domande permettono di inquadrarlo subito: su quale macchina si trova, su quale porta e in ascolto, e quale protocollo parla. La terza e la piu informativa, perche dal protocollo discendono il tipo di messaggi ammessi e il modo in cui il dialogo si svolge. Nella prossima lezione vedremo lo strumento con cui i programmi mettono concretamente in pratica tutto questo, cioe il socket.
Domanda di autoverifica: un server ha un solo indirizzo IP ma ospita sia un sito web sia un servizio di posta. In che modo un client che contatta quella macchina riesce a raggiungere il servizio giusto, e non l'altro?
Contatti Supportaci Chi siamo Cookies
La possibilità di poter ascoltare l'audio è offerto da ResponsiveVoice-NonCommercial
licensed under
Questo sito è un'idea di Francesco
Statistics