Loading AI tools
protocollo applicativo per la trasmissione d'informazioni sul web Da Wikipedia, l'enciclopedia libera
In telecomunicazioni e informatica l'HyperText Transfer Protocol (HTTP) (in italiano: protocollo di trasferimento ipertesto) è un protocollo a livello applicativo usato come principale sistema per la trasmissione d'informazioni sul web ovvero in un'architettura tipica client-server. Le specifiche del protocollo sono gestite dal World Wide Web Consortium (W3C). Un server HTTP generalmente resta in ascolto delle richieste dei client sulla porta 80 usando il protocollo TCP a livello di trasporto.
La prima versione dell'HTTP, la 0.9, risale alla fine degli anni 1980 e costituiva, insieme con il linguaggio HTML e gli URL, il nucleo base del World Wide Web (WWW) global information initiative sviluppata da Tim Berners-Lee al CERN di Ginevra per la condivisione delle informazioni tra la comunità dei fisici delle alte energie. Prima di HTTP il protocollo di riferimento per tali scopi era il più semplice e leggero FTP.
Con la diffusione di NCSA Mosaic, un browser grafico di facile uso, il WWW conobbe un successo crescente e divennero evidenti alcuni limiti della versione 1.0 del protocollo, in particolare:
L'HTTP è un protocollo che lavora con un'architettura di tipo client/server: il client esegue una richiesta e il server restituisce la risposta mandata da un altro host. Nell'uso comune il client corrisponde al browser ed il server la macchina su cui risiede il sito web. Vi sono quindi due tipi di messaggi HTTP: messaggi richiesta (detti HTTP requests) e messaggi risposta (detti HTTP responses).
HTTP differisce da altri protocolli di livello 7 come FTP, per il fatto che le connessioni vengono generalmente chiuse una volta che una particolare richiesta (o una serie di richieste correlate) è stata soddisfatta. Questo comportamento rende il protocollo HTTP ideale per il World Wide Web, in cui le pagine molto spesso contengono dei collegamenti (link) a pagine ospitate da altri server diminuendo così il numero di connessioni attive limitandole a quelle effettivamente necessarie con aumento quindi di efficienza (minor carico e occupazione) sia sul client che sul server. Talvolta però pone problemi agli sviluppatori di contenuti web, perché la natura senza stato (stateless) della sessione di navigazione costringe ad utilizzare dei metodi alternativi - tipicamente basati sui cookie - per conservare lo stato dell'utente.
Il messaggio di richiesta è composto da quattro parti:
La riga di richiesta è composta da metodo, URI e versione del protocollo. Il metodo di richiesta, per la versione 1.1, può essere uno dei seguenti:
l'URI, uniform resource identifier (identificatore univoco di risorsa), indica l'oggetto della richiesta (ad esempio la pagina web che si intende ottenere).
I metodi HTTP più comuni sono GET, HEAD e POST. Il metodo GET è usato per ottenere il contenuto della risorsa indicata come URI (come può essere il contenuto di una pagina HTML). HEAD è analogo a GET, ma restituisce solo i campi dell'header, ad esempio per verificare la data di modifica del file. Una richiesta con metodo HEAD non prevede l'uso del body.
Il metodo POST è usato di norma per inviare informazioni al server (ad esempio i dati di un form). In questo caso l'URI indica che cosa si sta inviando e il body ne indica il contenuto.
Gli header di richiesta più comuni sono:
Il messaggio di risposta è di tipo testuale ed è composto da quattro parti:
La riga di stato riporta un codice a tre cifre catalogato nel seguente modo:
I codici di risposta più comuni sono:
Gli header della risposta più comuni sono:
Il client può chiedere al server, nel messaggio di richiesta, di utilizzare due tipi di comunicazione:
Da un lato, le connessioni non persistenti introducono una latenza aggiuntiva rispetto a quelle persistenti di almeno 3 Round Trip Time (RTT). Infatti, al termine di ogni risposta da parte del server si rendono necessari:
D'altro canto, le connessioni persistenti precludono il parallelismo nelle comunicazioni, giacché il client che abbia diverse richieste da inviare allo stesso server è costretto ad evaderle sequenzialmente, una dopo l'altra. Per queste ragioni, i browser solitamente sfruttano le complementarità prestazionali delle due politiche di comunicazione per massimizzare la loro efficienza: solitamente aprono con ogni server diverse connessioni TCP in parallelo, su cui comunicano con strategia persistente.
Seguono esempi di messaggi di richiesta e risposta HTTP/1.1.
Gli esempi riguardano il recupero di contenuti su questa enciclopedia web e possono essere riprodotti - e quindi verificati - sul proprio PC copiando e incollando il testo con un client TCP (ad es: telnet it.wikipedia.org 80
nel caso di URL http://), oppure client TCP con supporto SSL (ad es: openssl s_client -connect it.wikipedia.org:443
nel caso di URL https://).
Ai fini della riproduzione si annota che:
Host
contenente la parte host dell'URL (come scritto sopra);Accept-Encoding
per specificare la possibilità di ricevere la risposta in formato compresso. L'header è eliminato per rendere leggibile la risposta (es: Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
);Recupera la risorsa web presente all'URL https://it.wikipedia.org/wiki/Pagina_principale
GET /wiki/Pagina_principale HTTP/1.1
Host: it.wikipedia.org
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: it
Connection: Keep-Alive
Risposta di successo (200 OK):
HTTP/1.1 200 OK
Date: Fri, 22 Feb 2019 10:50:37 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 22208
Connection: keep-alive
Server: mw1215.eqiad.wmnet
Content-language: it
Content-Encoding: gzip
Last-Modified: Fri, 22 Feb 2019 08:46:20 GMT
Age: 20548
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Vary: Accept-Encoding,Cookie,Authorization
[...]
<!DOCTYPE html>
<html class="client-nojs" lang="it" dir="ltr">
<head>
<meta charset="UTF-8"/>
<title>Wikipedia, l'enciclopedia libera</title>
[...]
</body>
</html>
Qui il client recupera l'URL http://it.wikipedia.org/wiki/Pagina_principale (differisce dal precedente poiché http invece di https).
La richiesta rimane la stessa dell'esempio precedente.
La risposta cambia esponendo un codice di spostamento permanente (301 Moved Permanently):
HTTP/1.1 301 Moved Permanently
Date: Wed, 19 Apr 2017 16:50:43 GMT
Server: Varnish
Location: https://it.wikipedia.org/wiki/Pagina_principale
Content-Length: 0
Connection: keep-alive
Questa è una richiesta POST per modificare le proprie preferenze di Wikipediano con il tema "Cologne Blue" (la sottostringa &wpskin=cologneblue nella prima riga del corpo della richiesta POST)
POST /wiki/Speciale:Preferenze HTTP/1.1
Host: it.wikipedia.org
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: it
Connection: Keep-Alive
Cache-control:no-cache
Content-length:1291
Content-type:application/x-www-form-urlencoded
wplanguage=it&wpgender=unknown&wpnickname=&wpdisablemail=1&wpskin=cologneblue&wppopups=0&wpdate=default&wpServerTime=1034&wptimecorrection=System%7C120&wptimecorrection-other=02%3A00&wpimagesize=2&wpthumbsize=2&wpmultimediaviewer-enable=1&wpunderline=2&wpstubthreshold=0&wpmath=mathml&wpcompact-language-links=1&wpeditfont=default&wpuseeditwarning=1&wpshowtoolbar=1&wpusebetatoolbar=1&wpusebetatoolbar-cgd=1&wppreviewontop=1&wprcdays=7&wprclimit=50&wphidecategorization=1&wpwatchlistdays=3&wpwllimit=250&wpwatchlisthidecategorization=1&wpcirrussearch-pref-completion-profile=fuzzy&wpgadgets%5B%5D=HiddenCat&wpgadgets%5B%5D=OpenStreetMap&wpgadgets%5B%5D=ReferenceTooltips&wpgadgets%5B%5D=WikiMiniAtlas&wpgadgets%5B%5D=ExternalSearch&wpecho-email-frequency=0&wpecho-email-format=html&wpecho-subscriptions%5B%5D=email-edit-user-talk&wpecho-subscriptions%5B%5D=web-edit-thank&wpecho-subscriptions%5B%5D=web-flow-discussion&wpecho-subscriptions%5B%5D=web-mention&wpecho-subscriptions%5B%5D=web-user-rights&wpecho-subscriptions%5B%5D=email-user-rights&wpecho-subscriptions%5B%5D=web-reverted&wpecho-subscriptions%5B%5D=web-emailuser&wpecho-cross-wiki-notifications=1&wpecho-show-alert=1&wpEditToken=dc1583a58b9a1293689802ce0700c46e58f79b12%2B%5C&title=Speciale%3APreferenze&wpenotifusertalkpages
Risposta HTTP di redirezione temporanea (302 Found) rimanda alla pagina per il login
HTTP/1.1 302 Found
Date: Wed, 19 Apr 2017 17:21:16 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Server: mw2224.codfw.wmnet
Vary: Accept-Encoding,X-Forwarded-Proto,Cookie,Authorization
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: https://it.wikipedia.org/w/index.php?title=Speciale:Entra&returnto=Speciale%3APreferenze&returntoquery=&warning=prefsnologintext2
Age: 0
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
La GET nella versione HTTP/1.0 risulta comoda per le docenze, si può effettuare con una sola riga perché nella versione 1.0 del protocollo non era obbligatorio inserire l'header "Host:"
Per eseguirla si fa:
GET / HTTP/1.0
Si ricorda di lasciare una riga vuota dopo la richiesta. Attendere la risposta dal webserver...
Risulta allo stesso modo molto comodo effettuare la richiesta HEAD del protocollo che restituisce le sole intestazioni con:
HEAD / HTTP/1.0
Dal momento che tutto il traffico HTTP è anonimo e in chiaro, sono state sviluppate diverse alternative per garantire differenti livelli di sicurezza, in termini di
La prima proposta venne direttamente da NCSA, con le versioni server 1.1 e client 2.2 che supportavano un meccanismo di autenticazione utente e cifratura dati basati su messaggi formato PEM e chiavi PGP.
In seguito, sono state standardizzate due versioni sicure del protocollo HTTP chiamate SHTTP e HTTPS. La prima, modellata sulla posta cifrata S/MIME, è ormai caduta in disuso e prevede meccanismi crittografici a livello di payload: le richieste e gli header vengono scambiati in chiaro mentre il contenuto della pagina viene cifrato come una struttura MIME multipart. Il meccanismo HTTPS, inventato da Netscape, usa invece il sottostante canale cifrato a livello di trasporto mediante SSL o TLS per impedire l'intercettazione di qualsiasi parte della transazione. Entrambi i protocolli possono garantire l'identità del mittente, ma solo SHTTP è in grado di garantire anche l'integrità del contenuto dopo averlo, ad esempio, memorizzato su un disco.
La fruizione nelle pagine WEB di materiale multimediale, quale audio o video viene gestito in modo del tutto analogo al download dei file, tramite un caricamento progressivo o distribuzione progressiva, in cui il file viene scaricato in modo progressivo dall'inizio alla fine (tramite i protocolli Real Time Streaming Protocol e Real-time Transport Protocol) e nel caso il bit-rate sia eccessivo per la rete che lo trasporta può verificarsi un continuo ricaricamento del buffer
Per evitare questi inconvenienti esistono altri sistemi alternativi, che permettono l'adattamento del file alla rete dell'utente finale, questi sistemi sono caratterizzati dai protocolli:
Per contro queste soluzioni sono notevolmente più complesse rispetto alle tradizionali tecnologie di streaming. Alcune delle considerazioni documentate riguardano lo stoccaggio, i costi aggiuntivi per la codifica e la difficoltà nel mantenimento della qualità globale. Ci sono state anche alcune dinamiche interessanti trovate intorno alle interazioni complesse fra logica adattiva bit rate in competizione con complessa logica di controllo del flusso TCP.[8][9]
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.