Docsity
Docsity

Prepara i tuoi esami
Prepara i tuoi esami

Studia grazie alle numerose risorse presenti su Docsity


Ottieni i punti per scaricare
Ottieni i punti per scaricare

Guadagna punti aiutando altri studenti oppure acquistali con un piano Premium


Guide e consigli
Guide e consigli


Protocollo HTTP: Connessioni Persistenti e Non Persistenti, HTTP/1.0 e HTTP/1.1, Appunti di Sistemi di reti

Una panoramica completa del protocollo http, analizzando nel dettaglio le differenze tra connessioni persistenti e non persistenti in http/1.0 e http/1.1. vengono illustrate le caratteristiche principali di ogni versione, i vantaggi delle connessioni parallele e il funzionamento dei messaggi di richiesta e risposta. una solida base per comprendere i principi fondamentali del funzionamento di internet e delle comunicazioni web.

Tipologia: Appunti

2024/2025

In vendita dal 02/05/2025

letizia-dalloca
letizia-dalloca 🇮🇹

44 documenti

1 / 9

Toggle sidebar

Questa pagina non è visibile nell’anteprima

Non perderti parti importanti!

bg1
PROTOCOLLO HTTP (HyperText Transfer Protocol)
HTTP è il protocollo di livello applicativo utilizzato per il trasferimento di risorse web, come pagine HTML
o altri elementi, da un server a un client. La sua funzione principale è gestire le richieste (URL) inviate dal
client al server e le risposte inviate dal server al client. Una caratteristica distintiva di HTTP è che è un protocollo
stateless, il che significa che non mantiene informazioni relative ai messaggi precedentemente scambiati, da
parte del server da parte del client.
Questo protocollo si è evoluto attraverso diverse versioni significative. Nel corso del tempo sono state sviluppate
versioni come HTTP/1.0, HTTP/1.1 (che include anche il pipelining) e, più di recente, HTTP/2 e WebSocket, che
introducono miglioramenti in termini di efficienza e gestione delle connessioni.
La connessione tra client e server è un
circuito virtuale stabilito a livello di trasporto (di
solito tramite il protocollo TCP) che consente
la comunicazione tra le due applicazioni. La
comunicazione stessa avviene attraverso
messaggi, che rappresentano l'unità base del
protocollo HTTP e consistono in una
sequenza di byte concettualmente indivisibile.
I messaggi possono essere di tipo request
(richiesta) o response (risposta). Una
richiesta inviata dal client contiene l'URL della
risorsa desiderata, mentre la risposta del
server include i dati della risorsa o
informazioni sul suo stato.
Le resource sono gli oggetti richiesti o restituiti, identificati univocamente tramite un URI (Uniform Resource
Identifier). L'URI è un identificatore che specifica la posizione o il nome della risorsa in modo da renderla
accessibile attraverso il protocollo HTTP.
pf3
pf4
pf5
pf8
pf9

Anteprima parziale del testo

Scarica Protocollo HTTP: Connessioni Persistenti e Non Persistenti, HTTP/1.0 e HTTP/1.1 e più Appunti in PDF di Sistemi di reti solo su Docsity!

PROTOCOLLO HTTP (HyperText Transfer Protocol) HTTP è il protocollo di livello applicativo utilizzato per il trasferimento di risorse web, come pagine HTML o altri elementi, da un server a un client. La sua funzione principale è gestire le richieste (URL) inviate dal client al server e le risposte inviate dal server al client. Una caratteristica distintiva di HTTP è che è un protocollo stateless , il che significa che non mantiene informazioni relative ai messaggi precedentemente scambiati, né da parte del server né da parte del client. Questo protocollo si è evoluto attraverso diverse versioni significative. Nel corso del tempo sono state sviluppate versioni come HTTP/1.0, HTTP/1.1 (che include anche il pipelining) e, più di recente, HTTP/2 e WebSocket, che introducono miglioramenti in termini di efficienza e gestione delle connessioni. La connessione tra client e server è un circuito virtuale stabilito a livello di trasporto (di solito tramite il protocollo TCP) che consente la comunicazione tra le due applicazioni. La comunicazione stessa avviene attraverso messaggi , che rappresentano l'unità base del protocollo HTTP e consistono in una sequenza di byte concettualmente indivisibile. I messaggi possono essere di tipo request (richiesta) o response (risposta). Una richiesta inviata dal client contiene l'URL della risorsa desiderata, mentre la risposta del server include i dati della risorsa o informazioni sul suo stato. Le resource sono gli oggetti richiesti o restituiti, identificati univocamente tramite un URI (Uniform Resource Identifier). L'URI è un identificatore che specifica la posizione o il nome della risorsa in modo da renderla accessibile attraverso il protocollo HTTP.

Nel caso di HTTP/1.0, il protocollo segue il modello request-response (richiesta-risposta) e opera in modalità stateless e one-shot. Ciò significa che ogni richiesta e risposta avviene come un singolo ciclo, senza che il server mantenga traccia delle richieste precedenti. Alcune caratteristiche principali di HTTP/1.0 sono: ⇒ Protocollo basato su TCP : la comunicazione avviene attraverso il protocollo TCP, che garantisce una connessione affidabile tra client e server. Non viene utilizzato UDP. ⇒ Schema di funzionamento :

  • il server è in modalità passiva, in attesa di connessioni, tipicamente sulla porta 80 (la porta predefinita per HTTP);
  • il client apre una connessione TCP alla porta 80 del server (sul lato client, la porta locale può essere una porta qualsiasi, generalmente una porta temporanea assegnata dal sistema operativo);
  • il server accetta la connessione e può gestire più connessioni contemporaneamente grazie alla capacità di accettare connessioni in parallelo, sebbene non in modo efficiente come nelle versioni successive di HTTP;
  • il client invia una richiesta HTTP al server;
  • il server risponde con i dati richiesti e chiude la connessione TCP. In HTTP/1.0, ogni singola richiesta e risposta è trattata come una connessione separata. Questo approccio non consente di mantenere una connessione aperta per più richieste, quindi la connessione viene chiusa dopo ogni ciclo di richiesta-risposta, il che può risultare inefficiente per operazioni multiple. DIFFERENZE FRA HTTP v1.0 e v1.
  1. HTTP/1.0 utilizza connessioni non persistenti , il che significa che per ogni richiesta e risposta viene aperta una nuova connessione TCP, che viene poi chiusa una volta completata la comunicazione. HTTP/1.1 , invece, introduce le connessioni persistenti , che permettono di utilizzare la stessa connessione TCP per più richieste e risposte, riducendo il sovraccarico causato dall'apertura e chiusura continua delle connessioni.
  1. Il client riceve la risposta con il file HTML, lo interpreta e trova i riferimenti (tag ) alle 10 immagini JPEG. Ora la connessione TCP si chiude.
  2. A questo punto, la connessione TCP viene riaperta per ciascuna delle 10 immagini JPEG. La sequenza di operazioni (1-4) viene ripetuta per ogni immagine:
  • il client apre una nuova connessione TCP con il server;
  • invia una richiesta HTTP per ciascuna delle 10 immagini JPEG;
  • il server risponde inviando il file richiesto;
  • la connessione TCP viene chiusa. Quindi, in totale, vengono aperte e chiuse 11 connessioni TCP (1 per il file HTML e 10 per le immagini JPEG). Nel caso di una connessione non persistente , ogni file richiesto (sia la pagina HTML che le immagini) viene trasferito su una connessione TCP separata, il che porta alla creazione di 11 connessioni TCP per il trasferimento di una pagina HTML e 10 immagini JPEG. Ogni connessione TCP trasporta un messaggio di richiesta e un messaggio di risposta. Le connessioni non persistenti presentano alcuni svantaggi significativi: 1. Per ogni file richiesto, è necessario instaurare una nuova connessione TCP , che richiede risorse aggiuntive (buffer e variabili) sia sul client che sul server. Quando il server deve gestire richieste da molti client, questo può portare a un sovraccarico significativo. 2. Prima di trasferire ciascun file, è necessario attendere due RTT, il che aumenta i tempi complessivi di trasferimento. CONNESSIONI IN SERIE VS PARALLELE Connessioni in serie :
  • se il browser (client) utilizza connessioni in serie , richiede ogni file (HTML o immagine) una volta che la connessione precedente è stata completata. In questo caso, il browser stabilisce una connessione TCP per ogni file e chiude la connessione dopo aver ricevuto il file. Questo processo potrebbe essere lento, soprattutto se ci sono molte risorse da scaricare, come nel caso delle immagini. Connessioni in parallelo :
  • i browser moderni, però, possono utilizzare connessioni TCP in parallelo per scaricare più file simultaneamente. Di solito, è possibile configurare un numero massimo di connessioni parallele (tipicamente 5-10 connessioni), il che significa che il browser può fare più richieste allo stesso tempo, riducendo il tempo complessivo di caricamento della pagina;
  • quando il browser fa uso di connessioni parallele , può ottenere simultaneamente più immagini in parallelo, riducendo i tempi di attesa per ciascun file, dato che non deve attendere che una connessione si completi prima di avviarne un'altra. Questo approccio migliora significativamente le prestazioni e diminuisce i tempi di risposta. VANTAGGI DELL'USO DI CONNESSIONI PARALLELE L'uso di connessioni parallele consente di scaricare i file più rapidamente, poiché il browser può avviare più trasferimenti contemporaneamente. Questo approccio è particolarmente utile quando ci sono molte risorse (come immagini o script) da caricare su una pagina web, poiché riduce il tempo totale per caricare tutti i file richiesti. Tuttavia, c'è un limite al numero di

connessioni parallele che il browser può gestire per motivi di prestazioni e di limitazioni imposte dai server o dai protocolli di rete. CONNESSIONE PERSISTENTE Con la connessione persistente , più file possono essere trasferiti utilizzando una sola connessione TCP. Ad esempio, una pagina HTML con 10 immagini JPEG può essere inviata interamente su un’unica connessione persistente. La connessione viene chiusa solo quando il server rileva che non è più utilizzata per un determinato intervallo di tempo, definito come timeout. Le connessioni persistenti possono operare in due modalità: Modalità senza parallelismo

  • Il client invia una nuova richiesta solo dopo aver ricevuto la risposta precedente.
  • Questo approccio mantiene la connessione attiva, ma non ottimizza pienamente i tempi di trasferimento. Modalità con parallelismo
    • Il client invia richieste appena trova riferimenti a file nella pagina HTML di base, senza attendere la risposta alla richiesta precedente.
    • Il server, ricevute le richieste, invia i file uno dopo l’altro.
    • Questo metodo utilizza un solo RTT per tutti i file richiesti, riducendo significativamente i tempi di attesa rispetto al modello senza parallelismo.
    • Inoltre, la connessione TCP rimane attiva per un tempo più breve, migliorando l’efficienza. Per impostazione predefinita, HTTP/1.1 utilizza connessioni persistenti con parallelismo, rendendo il trasferimento delle risorse più veloce e meno dispendioso in termini di risorse di sistema. MESSAGGI Un messaggio HTTP si compone di due parti principali:
  • Message Header : contiene tutte le informazioni necessarie per identificare il messaggio, insieme a tutte le altre intestazioni obbligatorie o opzionali. Fornisce dettagli come il tipo di contenuto, la lunghezza dei dati, le specifiche di cache e altre informazioni di controllo.
  • Non ci sono limiti di lunghezza per i parametri.
  • Viene spesso usato per comunicare dati dal client al server senza creare o modificare risorse esistenti. CGI (Common Gateway Interface)
  • È un meccanismo che permette di creare pagine dinamiche, generate in base a dati provenienti da utenti o database esterni.
  • Un browser può richiedere l’esecuzione di un programma CGI sul server per elaborare e restituire dati, spesso in formato HTML. Tipico flusso del processo CGI:
  1. Il client si connette al server con un URL.
  2. Il client invia una richiesta (GET o POST).
  3. I dati vengono passati al programma CGI referenziato nell’URL.
  4. Il programma elabora i dati e genera una risposta.
  5. La risposta, spesso un documento HTML, viene inviata al client tramite il server.
  6. La connessione tra client e server viene chiusa. PUT
  • Permette di memorizzare una risorsa sul server all’URL specificato.
  • Trasmette informazioni dal client al server, creando o sovrascrivendo la risorsa indicata.
  • La risorsa creata è quella che ci si aspetta di ottenere con un GET sullo stesso URL. DELETE
  • Richiede la cancellazione di una risorsa indicata dall’URL specificato.
  • Questo metodo è generalmente disabilitato sui server pubblici per motivi di sicurezza. HEAD
  • Funziona come il metodo GET ma il server restituisce solo gli header , senza il body del messaggio.
  • Utile per testare collegamenti senza scaricare il contenuto. Utilizzi principali:
  • Validità dell'URL : per verificare che la risorsa esista e non sia vuota.
  • Accessibilità : per controllare se l’accesso alla risorsa richiede autenticazione. OPTIONS
  • Fornisce informazioni sulle opzioni disponibili per la comunicazione con il server.
  • Risponde indicando i metodi HTTP supportati dal server per una specifica risorsa o per tutte le risorse (se richiesto a livello generale).
  • Usato per scopi di configurazione e diagnostica. TRACE
  • Esegue un loop-back remoto del messaggio di richiesta.
  • Permette al client di visualizzare esattamente ciò che il server ha ricevuto.
  • Può essere disabilitato per motivi di sicurezza, dato che potrebbe rivelare informazioni sensibili. Utilizzato per:
  • Diagnostica : verificare eventuali modifiche apportate alla richiesta durante il transito.
  • Testing : assicurarsi che i servizi Web funzionino correttamente.

RISPOSTA HTTP