HTTP è l'acronimo di Hypertext Transfer Protocol. È un protocollo di richiesta-risposta a livello di applicazione per il Web. L'HTTP ha un'architettura client-server che consente il trasferimento affidabile di risorse tra un server di applicazioni web e un agente utente (UA) come un browser web. Gli UA includono web crawler, applicazioni mobili e altri software utilizzati per accedere alle risorse web.
HTTP è stato progettato per consentire una facile comunicazione tra dispositivi e applicazioni sul web. IT definisce come vengono formattate e trasmesse le richieste di contenuto e come vengono costruite le risposte. HTTP trasmette contenuti come testo, immagini, audio e video utilizzando una suite di protocolli chiamata Transmission Control Protocol/Internet Protocol (TCP/IP).
Con l'evoluzione di HTTP, ogni versione ha aggiunto nuove funzionalità e ognuna esegue alcuni processi, come la gestione delle connessioni, in modo diverso.
Tim Berners-Lee, considerato il fondatore del web, ha scritto la prima versione di HTTP. Le specifiche per HTTP, Hypertext Markup Language (HTML) e Uniform Resource Identifier (URI) sono state scritte tra il 1989 e il 1990. Il primo server web è entrato in funzione nel 1991.
Un protocollo Internet è un insieme di regole che definisce le modalità di comunicazione tra i dispositivi di una rete Internet. Questo insieme di regole si basa su standard comuni creati tramite richieste di commenti (RFC). Le RFC sono le build degli standard utilizzati per la comunicazione in rete su Internet. Le RFC sono gestite dalla Internet Engineering Task Force (IETF), il principale organismo di definizione degli standard per il funzionamento di Internet. Esempi di protocolli di rete comuni sono HTTP, TCP, IPS, FTP e Secure Shell (SSH).
I protocolli di rete possono essere ulteriormente suddivisi. Il modello OSI (Open Systems Interconnection) è un quadro concettuale che descrive le funzioni di un sistema informatico. IT è composto da sette livelli: fisico, collegamento dati, rete, trasporto, sessione, presentazione e applicazione. I dati di ogni livello sono gestiti da protocolli diversi. HTTP è un protocollo di livello 7 (applicazione), da non confondere con il livello di rete del modello OSI.
I dati su Internet sono gestiti e trasmessi da una pila di protocolli di rete che vengono chiamati collettivamente TCP/IP. Ogni livello della pila può essere mappa dei livelli del modello OSI e ognuno ha una funzione diversa. HTTP fa parte del livello delle applicazioni e permette a diverse applicazioni di comunicare tra loro. IT utilizza il TCP per stabilire sessioni tra un client e un server. Il TCP fa parte del livello di trasporto dello stack. IT divide i messaggi in pacchetti di dati all'origine, che vengono poi riassemblati a destinazione. IP nell'acronimo TCP/IP è il protocollo che indirizza i pacchetti di dati a un computer specifico tramite un indirizzo IP. IPS fa parte del livello di rete dello stack.
In teoria, HTTP potrebbe utilizzare un protocollo di livello di trasporto alternativo a UDP, come UDP, ma HTTP utilizza quasi sempre TCP, che è basato sulla connessione e più affidabile di UDP. IT è preferito dalle applicazioni in cui i dati devono essere affidabili, pertinenti e completi, ad esempio per le notizie. UDP è un protocollo senza connessione e non può ritrasmettere i pacchetti di dati persi. Tuttavia, UDP è più veloce di TCP e viene spesso utilizzato in applicazioni come le videoconferenze e lo streaming, dove i piccoli intoppi di trasferimento sono appena percettibili. Tuttavia, la versione più recente della bozza di HTTP, HTTP/3, affronta alcuni dei problemi di TCP e UDP, combinando le caratteristiche di due protocolli: HTTP/2 e QUIC su UDP. HTTP/3 è chiamato anche HTTP-over-QUIC.
QUIC è un protocollo di rete che funziona come un'alternativa a una combinazione di TCP, Transport Layer Security (TLS) e HTTP/2. È implementato su UDP. QUIC trasporta il traffico HTTP/3 su UDP in modo più rapido ed efficiente rispetto alle vecchie versioni HTTP che utilizzano TCP. QUIC riduce la latenza della connessione, migliora il controllo della congestione, consente il multiplexing senza blocco della linea principale, permette la correzione degli errori in avanti e consente la migrazione della connessione. QUIC è completamente crittografato con TLS 1.3 per impostazione predefinita. UDP è un protocollo senza connessione, quindi una delle funzioni principali di QUIC è quella di garantire l'affidabilità della connessione, consentendo ad esempio la ritrasmissione dei pacchetti.
La prima versione di HTTP includeva solo il metodo di richiesta GET e non aveva intestazioni, metadati come il tipo di contenuto o codici di stato. Poiché HTTP/09 non utilizzava intestazioni, al client potevano essere restituite solo pagine HTML (ipertesto). Dopo aver ricevuto una risposta dal server, il client chiudeva immediatamente la connessione. L'HTTP/09 è per lo più deprecato, ma alcuni server web popolari come nginx lo supportano ancora.
HTTP/1.0 supportava i metodi GET e POST e aggiungeva informazioni sulla versione e codici di stato. Furono introdotte le intestazioni, che consentivano di specificare un tipo di contenuto in modo da poter trasmettere file diversi dall'HTML. Dopo aver ricevuto una risposta dal server, il client chiudeva immediatamente la connessione. L'introduzione delle intestazioni in HTTP/1.0 ha reso HTTP molto estensibile.
Quando viene fatta una richiesta per una pagina web, la pagina deve essere resa in più parti, ad esempio contenuti testuali e altri contenuti come immagini o video. I file immagine, video e audio hanno i propri URL e ogni file deve essere richiesto separatamente. In HTTP/1, ciò significava che dovevano essere effettuate più richieste individuali al server e dovevano essere avviate più connessioni. HTTP/1.1 ha introdotto le connessioni persistenti e il pipelining. Una connessione persistente non viene chiusa per impostazione predefinita dopo che è stata effettuata una richiesta. Il pipelining significa che le richieste successive di una transazione possono essere effettuate da un client senza attendere la risposta del server. Le connessioni persistenti e il pipelining consentono di inviare ipertesti e altri file, come le immagini, in successione dal server al client su un'unica connessione con una latenza ridotta. HTTP/1.1 consentiva anche metodi aggiuntivi, come DELETE, PUT e TRACE. Questa versione ha introdotto il supporto per la cache, i cookie del client, i trasferimenti codificati e la negoziazione dei contenuti. La negoziazione dei contenuti permetteva al server e al client di selezionare il contenuto più adatto da scambiare in termini di lingua, codifica o tipo di contenuto. HTTP/1.1 ha anche reso più coerente la standardizzazione di HTTP ed è attualmente la versione di HTTP più utilizzata.
Basato su SPDY, HTTP/2 è un protocollo di comunicazione deprecato sviluppato da Google per ridurre la latenza di caricamento delle pagine web e migliorare la sicurezza. È stato progettato per migliorare le prestazioni del web e ridurre i costi, poiché HTTP/1.1 era costoso in termini di utilizzo delle risorse della CPU. HTTP/2 ha introdotto il multiplexing avanzato, ovvero la capacità di trasmettere in modo efficiente i dati da più risorse in una singola sessione utilizzando frame HTTP e flussi HTTP. Questa funzione è stata introdotta per risolvere i problemi di blocco dell'head-of-line HTTP in HTTP/1.1 e per consentire una comunicazione parallela su una singola connessione TCP. Il blocco HTTP head-of-line si riferisce allo scenario in cui le richieste successive in un flusso possono essere bloccate se c'è un problema con la richiesta corrente nella coda o se non è ancora stata completata.
Mentre le richieste e le risposte HTTP/1.1 sono in formato testo, i frame HTTP/2 utilizzano il formato binario.
I frame binari di HTTP/2 suddividono una richiesta di messaggio in unità logiche separate, come frame di intestazione e frame di dati, ciascuno dei quali è codificato in binario e condivide un ID di flusso HTTP comune. Un flusso HTTP/2 è una singola richiesta logica bidirezionale che comprende più frame. In HTTP/2, più flussi possono essere inviati (multiplexati) su una singola connessione TCP a un server che mappa i frame in base al loro ID di flusso e li riassembla in messaggi di richiesta HTTP request completi in base a una priorità di messaggio predeterminata. Il multiplexing consente di effettuare più richieste su un'unica connessione e il server può anche inviare più risposte al client nello stesso modo. Questa caratteristica impedisce il blocco della linea di testa a livello di applicazione e migliora le prestazioni.
HTTP/2 ha introdotto anche una migliore gestione degli errori e del controllo del flusso, nonché il server push. Il server push significa che il server può inviare al client dati non esplicitamente richiesti, ad esempio risorse che il server intuisce essere necessarie al client. L'IT notificherà prima al client ciò che intende inviare e il client potrà rifiutare.
Secondo W3Techs HTTP/2 è utilizzato da circa il 46% dei siti web. Non è compatibile con le versioni HTTP precedenti.
La terza versione di HTTP, HTTP/3, è stata progettata per migliorare le prestazioni di HTTP/2 e per risolvere alcuni problemi di HTTP/2. HTTP/3 utilizza UDP come livello di trasporto invece di TCP. Il blocco dell'head-of-line a livello TCP in HTTP/2 è risolto dall'uso di UDP. Il blocco della linea di testa in TCP si riferisce allo scenario in cui, se un pacchetto viene perso, un messaggio viene bloccato fino a quando il pacchetto non può essere recuperato. HTTP/3 consente connessioni più veloci perché non si basa sugli indirizzi IP. IT utilizza ID di connessione in modo che i download siano coerenti anche in caso di cambio di rete. A differenza del TCP, l'UDP non richiede la conferma di un trasferimento di dati prima della trasmissione della richiesta successiva. Le connessioni sono anche più veloci perché è necessario inviare meno pacchetti di dati su flussi paralleli. Per stabilire una connessione, il TCP utilizza un handshake a tre vie. UDP crea una connessione in un solo round trip. Poiché TLS 1.3 è integrato in HTTP/3, supporta solo connessioni criptate (HTTPS).
Gli avvisi personalizzati e la visualizzazione dei dati consentono di identificare e prevenire rapidamente i problemi di salute e di prestazioni della rete.
Le intestazioni rendono HTTP estensibile, in quanto client e server possono concordare l'aggiunta di nuovi nomi di campi e informazioni in base alle proprie esigenze.
Anche se può farlo, un server HTTP non è tenuto a memorizzare alcuna informazione tra una richiesta e l'altra. Questa caratteristica rendeva le prime versioni di HTTP senza stato. Le richieste nelle versioni precedenti a HTTP/2 venivano effettuate in modo indipendente, senza sapere cosa fosse successo nelle richieste precedenti. HTTP è stato progettato come modello stateless principalmente per la scalabilità; le richieste HTTP possono essere indirizzate a qualsiasi server perché il server non ha bisogno di mantenere un particolare stato per un client. In questo modo è facile scalare il numero di server in base al carico di lavoro previsto, laddove il mantenimento di una connessione persistente richiederebbe molte risorse. Quando è necessario interagire con un sito web in modo progressivo, ad esempio quando si fanno acquisti online, l'HTTP può utilizzare i cookie, le sessioni lato server, la riscrittura degli URL o le variabili nascoste per consentire sessioni con stato. Un altro vantaggio dell'assenza di stato è che la quantità di dati da trasferire nella maggior parte dei casi è ridotta al minimo.
L'intero stack TCP/IPS non è stateless. Il livello di trasporto TCP è stateful, mantiene lo stato di una sessione HTTP e garantisce che i pacchetti di dati persi possano essere ritrasmessi.
L'HTTP è generalmente considerato senza connessione perché, dopo che il client ha stabilito una connessione con un server, ha inviato una richiesta e ha ricevuto una risposta, la connessione viene immediatamente interrotta. HTTP è considerato senza connessione anche perché le connessioni di rete sono controllate a livello di trasporto e non a livello di applicazione. HTTP utilizza il TCP, che è basato sulla connessione, al livello di trasporto.
Finché il client e il server sanno come gestire il contenuto specifico dei dati, come specificato dal tipo MIME in un'intestazione, qualsiasi tipo di dati può essere inviato tramite HTTP. MIME sta per Multipurpose Internet Mail Extensions.
L'HTTP viene utilizzato sul Web ovunque sia necessario trasferire dati tra un client e un server, ad esempio API, servizi Web e richieste del browser.
L'HTTP è solitamente utilizzato dagli utenti che non hanno informazioni riservate che devono temere di essere violate, che non desiderano acquistare un certificato SSL o che non vogliono la complessità di mantenere un sito sicuro.
Le prime versioni di HTTP erano senza stato, ma non senza sessione. In genere, una sessione HTTP prevede tre fasi, con alcune variazioni nel modo in cui le fasi vengono gestite nelle diverse versioni.
Innanzitutto, il client stabilisce una connessione al server. Nella maggior parte delle versioni di HTTP, si tratta di una connessione TCP, ma HTTP/3 utilizza UDP come livello di trasporto.
In secondo luogo, il client invia un messaggio di richiesta per visualizzare, ad esempio, una pagina web. Un metodo di richiesta nel messaggio specifica l'azione che il server deve compiere. Ad esempio, per visualizzare una pagina web, il client utilizzerà il metodo GET .
In terzo luogo, il server elabora la richiesta e restituisce al client un messaggio di risposta, ad esempio il contenuto della pagina web richiesta, se la richiesta ha avuto successo, e un codice di stato.
Nelle versioni di HTTP precedenti a HTTP/1.1, la connessione veniva chiusa per impostazione predefinita dopo il completamento di una richiesta. Se il client desiderava mantenere aperta la connessione, doveva specificarlo abilitando l'intestazione Keep-Alive Connection. HTTP/1.1 e le versioni successive di HTTP consentono al client di inviare ulteriori messaggi di richiesta e la connessione viene mantenuta viva per impostazione predefinita. Quindi, se un client riceve un codice di errore, potrebbe voler riprovare la richiesta. Se il client desidera chiudere la connessione, deve specificarlo con l'intestazione Close Connection.
Tra il client e il server ci sono numerosi altri server chiamati proxy, che sono intermediari che svolgono funzioni aggiuntive come la crittografia dei contenuti, la cache e la compressione dei dati, il bilanciamento del carico, il logs e la fornitura di connessioni condivise per utenti concorrenti.
I messaggi HTTP vengono scambiati in un formato simile al MIME. MIME è uno standard per la posta elettronica su Internet che consente di estendere il formato delle richieste di messaggi per supportare dati diversi dal testo semplice ASCII. Le intestazioni simili a MIME in HTTP hanno una funzione simile; ad esempio, permettono a un client di selezionare l'applicazione appropriata per aprire file diversi dal testo, come video, immagini, eseguibili, audio, ecc.
Le request e le risposte HTTP utilizzano lo stesso formato di messaggio. I messaggi sono costituiti da una riga iniziale (una riga di richiesta nel caso di un messaggio di richiesta o una riga di stato nel caso di un messaggio di risposta), uno o più campi di intestazione opzionali, una riga vuota che indica che non ci sono altri campi di intestazione e un corpo del messaggio opzionale.
La riga iniziale include la versione del protocollo e alcune informazioni sul tipo di richiesta, nel caso di un messaggio di richiesta, o sul successo o sul fallimento della richiesta, nel caso di un messaggio di risposta.
Le intestazioni HTTP consentono di includere informazioni aggiuntive sulla richiesta o sulla risposta, come il metodo di richiesta nel caso dei messaggi di richiesta e la lunghezza del contenuto restituito nel caso dei messaggi di risposta.
Il corpo del messaggio opzionale di una richiesta può includere le informazioni che devono essere caricate o eliminate da un server. Il corpo del messaggio opzionale di una risposta può includere il contenuto richiesto dal client.
L'uso delle intestazioni è ciò che rende HTTP flessibile ed estensibile come client e un server può creare nuove intestazioni rilevanti per una transazione, purché entrambi concordino sul formato.
Alcune intestazioni HTTP sono specifiche per i messaggi di richiesta o di risposta, ad esempio l'intestazione Accept-Language è specifica per i messaggi di richiesta. Tuttavia, alcune intestazioni possono comparire sia nelle richieste che nelle risposte. Ad esempio, l'intestazione Content-Type, classificata come intestazione di rappresentazione, può essere inclusa nei messaggi di richiesta o di risposta. Nel primo caso, specifica il tipo di contenuto desiderato dal client. Nel secondo, specifica il tipo di contenuto che il server restituisce.
Le intestazioni delle richieste possono includere informazioni aggiuntive sul client e sulla risorsa. Ad esempio, l'URI (Uniform Resource Identifier) è la risorsa su cui il metodo deve agire per ottenere informazioni da un sito web specifico, ad esempio. Le intestazioni delle richieste HTTP possono anche specificare informazioni su quali dati devono essere cache, informazioni generali sulla connessione, dettagli sull'autenticazione, data e ora, informazioni sulla codifica del trasferimento, in quale formato le informazioni possono essere utilizzate per trasferire il contenuto, ecc.
Le intestazioni di richiestaAccept (come Accept-language e Accept-encoding ) e alcune intestazioni di rappresentazione complementari (come Content-Language e Content-Encoding ) consentono la negoziazione dei contenuti di HTTP. Le intestazioni Accept specificano le preferenze del client e le intestazioni di rappresentazione complementare nella risposta specificano ciò che il server ha effettivamente restituito.
Le intestazioni della risposta possono includere informazioni aggiuntive sul server e sulla risorsa. Possono anche specificare eventuali cookie, la lunghezza del contenuto restituito, il tipo di contenuto, l'ultima modifica del contenuto, ecc.
Esistono intestazioni speciali per numerose funzioni HTTP, come l'autenticazione, i tipi di connessione, la memorizzazione dei cookie, il download di file, la gestione dei proxy, la sicurezza, la codifica dei trasferimenti, ecc.
L'HTTP è un modello di richiesta-risposta per la comunicazione di rete. La sua controparte è il modello publish-subscribe, in cui un server (chiamato anche broker) riceve e distribuisce i dati mentre il client pubblica i dati al server per aggiornarli o si iscrive al server per ricevere informazioni. Nel modello publish-subscribe, i dati vengono scambiati automaticamente, ma solo quando cambiano o se le informazioni sono nuove. MQTT è un esempio di protocollo di trasporto che utilizza il publish-subscribe.
Web Real-Time Communication (WebRTC) è utilizzato per effettuare connessioni peer-to-peer (P2P), che permettono di condividere facilmente i dati delle applicazioni e i file multimediali come audio e video. Facebook Messenger è un esempio di applicazione che utilizza WebRTC.
QUIC utilizza il TCP, ma si basa su UDP. QUIC è stato progettato per ridurre la latenza nei trasferimenti di dati su Internet e per risolvere alcuni problemi relativi a HTTP/2. Google Chrome è un esempio di applicazione che utilizza QUIC.
L'InterPlanetary File System (IPFS) è un'alternativa recente all'HTTP che ha un'architettura P2P distribuita e permette di scegliere tra connessioni TCP, QUIC o WebRTC. Grazie alla sua architettura distribuita, è stato progettato per risolvere i problemi di guasto del server, comuni ai modelli di protocollo di comunicazione di rete centralizzati come l'HTTP.
Sensore HTTP Pagina Web completa
Monitoraggio HTTP nel cloud
Contenuto HTTP del sensore
Hypertext Transfer Protocol Secure (HTTPS) è fondamentalmente HTTP con crittografia; "avvolge" i messaggi HTTP in un formato crittografato. HTTPS utilizza il Transport Layer Security (TLS) per crittografare le richieste e le risposte HTTP.
HTTP e HTTPS utilizzano porte diverse. Normalmente, HTTP utilizza la porta 80 e HTTPS la porta 443 anche se, in teoria, è possibile utilizzare qualsiasi porta, tranne quelle riservate a servizi specifici.
Il vantaggio principale dell'utilizzo di HTTPS è la maggiore sicurezza. Per i siti web che non trasferiscono informazioni riservate, l'HTTP potrebbe essere un'opzione accettabile e meno complessa da configurare e mantenere. Inoltre, nel 2014 Google ha annunciato che avrebbe utilizzato HTTPS come segnale di ranking leggero per incoraggiare le aziende a passare da HTTP a HTTPS.
L'utilizzo di HTTPS al posto di HTTP presenta alcuni svantaggi sottili e, in pratica, minori. In primo luogo, il trasferimento dei dati può comportare un sovraccarico di lavoro, in quanto è necessario effettuare prima un'operazione di handshaking. In secondo luogo, il processo di generazione delle chiavi di crittografia può impedire al server di svolgere altre attività. In terzo luogo, alcuni contenuti non possono essere cachettati localmente perché i dati sono crittografati.
Per impostazione predefinita, HTTP/3 è disponibile solo con HTTPS.
Notifiche in tempo reale significano una risoluzione più rapida dei problemi, in modo da poter intervenire prima che si verifichino problemi più gravi.
Il TCP è più affidabile, ma è più lento dell'UDP. Tuttavia, quando UDP viene combinato con QUIC, il risultato è una trasmissione di pacchetti veloce e affidabile grazie a HTTP/3. HTTP/3 è ancora agli inizi. All'inizio del 2021, è stato abilitato da applicazioni popolari come Google, WhatsApp, YouTube e Facebook, ma non da applicazioni altrettanto popolari come Uber o Twitter.
HTTP/3 è ancora una bozza RFC ma è supportato, secondo Wikipedia, da quasi il 75% dei browser web e, secondo W3Techs, dal 21% dei 10 milioni di siti web per i quali W3Techs fornisce dati di utilizzo.
La commercializzazione di Internet ha comportato una maggiore necessità di analisi e monitoraggio della rete in tempo reale per fornire alle organizzazioni il massimo tempo di attività. Il monitoraggio e l'analisi dei pacchetti - chiamato packet sniffing - è la chiave per analizzare quali pacchetti vengono persi, quando e perché, al fine di mantenere prestazioni elevate e costanti.
Lostrumento di monitoraggio dei pacchetti di PTRG monitora e analizza ogni pacchetto della rete per identificare la larghezza di banda utilizzata, i problemi di larghezza di banda e le potenziali falle nella sicurezza. Il packet sniffer monitora tutto il traffico HTTP, HTTPS, UDP e TCP, oltre ad altri tipi di posta, trasferimento di file, controllo remoto e traffico infrastrutturale.
Lo strumento di monitoraggio dei sensori web di PTRG consente di monitorare i server web che utilizzano HTTP per assicurarsi che le pagine web siano sempre raggiungibili.
