Introduzione
Questo articolo è una rielaborazione di un mio precedente post a parer mio troppo vecchio e poco approfondito.
In questo articolo verranno trattati i seguenti argomenti :
Livello Application
Cos’è l’ampiezza di banda minima?
Quando viene utilizzato il protocollo UDP e quando il protocollo TCP ?
I primissimi protocolli
Come funzione l’architettura di comunicazione Client- Server
Architettura Peer-to-peer
Cos’è un Web Server e come funziona
HTTP request e HTTP response, come e da cosa sono creati
Codici di errore
Architettura multi-tier
Come avviene una comunicazione TCP
Cos’è un URL ?
Vantaggi e Svantaggi del Protocollo HTTP
Nel pratico come avviene la comunicazione ?
Differenza tra HTTP 1.0 e HTTP 1.1
Considerazioni Finali
Conclusione
Livello Application
Il livello Application fa parte dei livelli più alti, direttamente a contatto con l’utente finale. I protocolli più importanti sono:
HTTP: usato per pagine web
SMTP
DNS: importantissimo. Traduce il nome logico in un indirizzo IP (il nome logico è un qualcosa che serve a noi per cercare il sito) [può usare o il protocollo UDP o il protocollo TCP]
FTP: serve per trasferire file
SNMP [e molti altri…]
Questi protocolli si appoggiano su due protocolli che abbiamo conosciuto nel livello Transport. Sono il protocollo UDP e il protocollo TCP
Cos’è l’ampiezza di banda minima ?
Importante è l’ampiezza di banda minima , chiamata anche throughput garantito. Lo troviamo spesso con l’acronimo QoS.
Throughput garantito è l’ampiezza di banda minima (ampiezza di banda e come il tubo dell’acqua più è ampio più acqua scorre al suo interno, più l'ampiezza di banda più dati scorrono al suo interno).
Ci sono applicazioni o servizi che per funzionare correttamente esigono una banda minima, altri servizi hanno meno bisogno di una larghezza di banda garantita, queste ultime vengono definite Applicazioni meno esigenti .
Applicazioni esigenti (applicazioni che hanno bisogno di una banda minima per funzionare correttamente) :
WEB tv
Videoconferenza
Film in streaming
Applicazioni meno esigenti :
FTP
HTTP
Quando viene utilizzato il protocollo UDP e quando il protocollo TCP ?
Il protocollo TCP viene utilizzato quando abbiamo bisogno di più sicurezza sull’arrivo dei dati, necessitiamo che ogni pacchetto arrivi a destinazione e che quindi non se ne perda neanche uno, è una comunicazione più lenta rispetto il protocollo UDP.
UDP non ha nessun ACK di conferma e permette quindi l’invio più veloce di dati, non necessitiamo che tutti i pacchetti arrivino a destinazione poiché abbiamo bisogno di velocità.
I primissimi protocolli
I primissimi protocolli nascono in situazioni diverse da quelle attuali, quando nacquero questi protocolli ormai obsoleti e non più utilizzati, internet era agli albori e ad usarlo erano davvero in pochi, quindi essendo molto pochi gli utilizzatori non c’era la necessità di stare attenti alla sicurezza.
I protocolli "vecchi" senza sicurezza sono esempio:
HTTP
FTP
TELNET (non più utilizzato sarà soppiantato dal SSH)
Le evoluzioni di questi protocolli furono evoluzioni più sicure come :
HTTPS
FTPS
SSH (rimpiazza il protocollo Telnet)
Come funzione l’architettura di comunicazione
Client- Server
Il concetto di Client-Server è alla base della comunicazione online. Questa tipologia di comunicazione interessa due grandi ruoli.
Client: fanno la richiesta, sono le persone interessate al servizio o ai dati.
Server: offrono servizi e dati.
Un esempio di comunicazione Client Server sono le ricerche che noi banalmente facciamo su google. Quando noi cerchiamo qualcosa su un motore di ricerca, ci stiamo comportando da Client, a rispondere sarà in un secondo momento un Server Web che ci fornirà le informazioni che abbiamo ricercato con una pagina HTML.
(Farò un articolo molto più dettagliato sul funziona del Client-Server e sull’effettivo ruolo del DNS)
Architettura Peer-to-peer
Peer-to Peer: gli host sono tutti allo stesso livello possono fare sia da server che da client. Un esempio di comunicazione Peer-to-Peer è un gruppo di amici. Tutti i ragazzi sono alla pari, tutti possono fare sia da Client, quindi tutti possono richiedere informazioni e tutti possono dare informazioni quindi possono comportarsi anche da Server. A differenza quindi del Client-Server, non si hanno ruoli già prestabiliti e quindi non si hanno macchine che si elevano alle altre poiché possiedono le informazioni; nel peer-to-peer tutti sono completamente alla pari.
Il P2P (Peer-to Peer) può essere :
Centralizzato: Il Server centrale contiene tutte le informazioni sui possibili host che hanno quella determinata informazione, quindi di per sé non contiene nessuna informazione, nel caso di una richiesta lui mostra l’host a cui può chiedere tale informazione. Quindi il Server ha lo scopo di mettere in contatto l’host richiedente con l’altro host che ha l’informazione.
IBRIDO: in questo caso sono gli stessi Peer che diventano SUPERNODI, cioè ci sono alcuni host che hanno lo scopo di avere al proprio interno la lista di tutti i possibili posseditori dell’informazione. Quindi arriva una richiesta a questo Peer eletto, e lui mostra l’host che ha l’informazione, proprio come nel caso precedente.
Cos’è un Web Server e come funziona
Il Web Server è un server che gestisce e che comunica mediante il protocollo HTTP. Gestisce le richiesta e fornisce le risposte al client che le richiede.
IMPORTANTE la comunicazione avviene tra due Socket diversi , uno che ha lo scopo di ricevere richieste [HTTP request] l’altro socket ha lo scopo di fornire risposte a quelle richieste [HTTP response]
HTTP Request = richiesta fatta dal client
HTTP Response = Risposta data dal Server
Entrambi i componenti della comunicazione sono composti da 3 zone :
Start-Line
Header
Body
Quindi sia l’HTTP Request che l’HTTP Response al suo interno hanno queste 3 zone, ovviamente varieranno gli attributi al loro interno.
HTTP Request :
Nella zona Start-line troviamo : troviamo un metodo che può essere GET o POST, in questa zona troviamo l’URL del Server a cui stiamo chiedendo l’informazione e la versione del protocollo HTTP che stiamo utilizzando.
HTTP Response :
Start-line troviamo : Numero Versione HTTP, Codice di risposta (se Ok o Tipo Errore)
Header Troviamo : Tipo generale di documento (es. Text/Html), Entità (es. data e ora Ultima Modifica dei dati richiesti) Ecc...
Body troviamo: La pagina HTML che verrà visualizzata dal client
Codici di Errore :
Il Server per comunicare al client l’esito dell’elaborazione della richiesta utilizza dei codici composti da 3 numeri che vanno da : 200 a 599
tra 200 e 299 la richiesta è stata elaborata con successo
tra 300 e 399 Ridirezione, magari il documento o la risorsa sono stati spostati
tra 400 e 499 Errore del Client , quindi accessi vietati o errori provenienti dal client
tra 500 e 599 Errore del Server sono errori provenienti da problemi o malfunzionamenti del server.
Online potrete trovare anche delle tabelle dove sono riportati tutti i codici errori o i più comuni.
Architettura multi-tier
Per architettura multi-tier si intende come è suddiviso ed organizzato un software, solitamente in questi casi un software viene suddiviso a livelli, tradotto infatti in italiano multi-tier viene tradotto in multistrato
Possiamo fare due grandi distinzioni, lato server e lato client :
Lato server ci sono dei programmi scritti con linguaggi di programmazione come il python o il PHP che hanno lo scopo di comprendere le richieste fatte dal client.
Lato Client, noi vedremo il risultato della nostra richiesta se stiamo dialogando con un server Web avremo in risposta una pagina HTML. Ricordiamo : Il browser ha lo scopo di interpretare tali script, il vero client di tale comunicazione è proprio il browser.
Nota bene : Il protocollo HTTP è un protocollo che si basa sull’architettura Client-Server, inoltre l’HTTP si appoggia al protocollo TCP.
Come avviene una comunicazione
Il Client, nel nostro caso un motore di ricerca o in generale un Browser si comporta da Client e compie una richiesta ad un server, (solitamente un server Apache), quest’ultimo resta in ascolto su un Socket. Il client per conoscere a quale server connettersi utilizza un URL.
Meccanismo di comunicazione TCP
Viene aperta una connessione via socket tra Client e Server utilizzando il protocollo TCP
Il browser, cioè il client in questo caso, richiede un’informazione al server utilizzando il metodo GET
Il server Risponde inviando la risposta sul socket del client
Si chiude la connessione TCP e si chiude la comunicazione.
Cos’è un URL ?
L’URL è un indirizzo univoco che punta direttamente ad una risorsa online, un esempio di URL potrebbe essere https://www.infodibase.com/. Ogni URL è composto da un protocollo, da un server e da un’eventuale risorsa come magari un PDF.
Nel nostro caso https è il protocollo (HTTPS è la versione “sicura” del protocollo HTTP).
infodibase.com è il nostro nome server
A seguire se avessi avuto una qualsivoglia risorsa
Se vuoi sapere cos’è un Socket o per ulteriori informazioni clicca qui.
Vantaggi e Svantaggi del Protocollo HTTP
Vantaggi del protocollo HTTP : Efficiente e semplice
Limiti : Protocollo senza stato, non viene ricordato l’utente e non viene mantenuta l’informazione, alla chiusura della connessione il protocollo dimentica completamente chi siamo e non tiene traccia delle richieste avvenute precedentemente. Il client può fare richiesta al server ma il server non può contattare di sua spontanea volontà il client ma può solo rispondere alla sua richiesta.
Nel pratico come avviene la comunicazione ?
Il browser analizza l’URL e ne estrae il Dominio. Le due cose non vanno confuse, un esempio di URL è https://www.infodibase.com/ , un esempio di dominio è infodibase.com
Il browser consulta il DNS Server per ottenere l’IP del server
Il browser Apre una connessione TCP con il Server Web (porta 80)
Stabilita la connessione, Browser e Server Web usano HTTP per comunicare
pagina web caricata sul browser
Differenza tra HTTP 1.0 e HTTP 1.1
Abbiamo una differenza sostanziale tra il protocollo HTTP 1.0 e il protocollo HTTP 1.1 .
Nel protocollo HTTP 1.0 i messaggi successivi al primo hanno bisogno di instaurare nuovamente la connessione allungando le tempistiche. Il Client apre la comunicazione il server risponde e chiude la comunicazione, allora il client per continuare a comunicare ha bisogno di riaprire la comunicazione e quindi instaurare una nuova connessione
Nel protocollo HTTP 1.1 i messaggi successivi non hanno bisogno di instaurare nuovamente la connessione,ma continuano nella connessione precedente già instaurata. La connessione viene chiusa semplicemente allo scadere di un timeout di non utilizzo . Il client apre la connessione poiché (come abbiamo detto prima il Server non può decidere di sua volontà di comunicare con il client), quindi il client apre la comunicazione e continuano a comunicare fin quando non scade un timeout posto per chiudere la comunicazione in caso di non più utilizzo dopo appunto un tot di tempo.
Considerazioni Finali
HTTP Non ha memoria : il protocollo HTTP non ricorda la storia dell’utente non capisce la nozione di sessione, non ricorda che lo stesso utente magari ha avuto altre connessioni precedentemente, quindi tratta ogni connessione come unica e assestante. Il problema di non ricordare la sessione di un utente viene colmato con la nascita dei cookies che hanno lo scopo di tenere traccia delle sessioni che compie un utente in un determinato sito.
Il Server non può comunicare il client, a fare ciò può essere solo il client. Quindi è il client che richiede la connessione non il server
Inizialmente HTTP nasce per trasmettere pagine statiche, con il passare del tempo si sono create pagine dinamiche e successivamente sono nate delle vere e proprie applicazioni o giochi completamente online
HTTP non è sicuro, nascerà successivamente la sua evoluzione ovvero l’HTTPS che ha lo scopo di cifrare i dati prima di trasmetterli in modo da rendere la comunicazione più “sicura”. Possiamo quindi dire che l’HTTPS è l’evoluzione del protocollo HTTP ed ovviamente molto più adatto quando degli utenti inseriscono magari dati personali all’interno di pagine web. Ciò evita i possibili attacchi o sniffing all’interno della comunicazione, può essere ad esempio utile per rendere il lavoro molto più complicato se non impossibile ad un eventuale Man in the Middle.
Conclusione
Grazie per essere arrivati fin qui, spero vivamente che questa mega guida vi sia stata d’aiuto, e che in qualche modo abbia colmato qualche vostro dubbio.
Da Infodibase per oggi è tutto e alla prossima : )
Articoli che ti consiglio :
Parliamo dei Bitcoin, o forse no ! - Intelligenze Artificiali e ChatGPT
Cos'è un Server e un Socket? Sguardo generale.
LCD : tutto quello che devi sapere , spiegato in modo semplice
Se sei interessato a conoscere il livello Data Link della pila protocollare ISO/OSI ti consiglio il mio ebook .
Commenti
Posta un commento