HTTP

L'HyperText Transfer Protocol (protocollo di trasferimento di un ipertesto) è

un protocollo a livello applicativo usato come principale sistema per la trasmissione
d'informazioni sul web ovvero in un'architettura tipica client-server.

HTTP così come l’FTP, TCP etc.. è un protocollo di trasferimento. Ideato agli inizi del
Web vero e proprio, per trasferire informazioni sul web. Opera solitamente sulla porta
80.

Esistono varie implementazioni dell’HTTP sviluppate nel corso degli anni. Questo per far
fronte ad alcune carenze della versione iniziale. L’HTTP funziona su un meccanismo
richiesta/risposta (client/server).
Tra i metodi di richiesta più conosciuti nell’HTTP vi sono GET e POST.

Mentra tra gli header di richiesta: Host (Nome del server a cui si riferisce l’URI)
e User-Agent (Identifica il client, quindi il browser, la versione etc..).
Gli header della risposta più comuni sono:
 Server. Indica il tipo e la versione del server. Può essere visto come l’equivalente
dell’header di richiesta User-Agent
 Content-Type. Indica il tipo di contenuto restituito. La codifica di tali tipi (detti
Media type) è registrata presso lo IANA (Internet Assigned Number Authority ); essi
sono detti tipi MIME(Multimedia Internet Message Extensions).

Alcuni tipi usuali di tipi MIME incontrati in una risposta HTML sono:

 text/html Documento HTML

 text/plain Documento di testo non formattato
 text/xml Documento XML
 image/jpeg Immagine di formato JPEG

Ha un funzionamento diverso dall’FTP in quanto la connessione aperta tra un client ed

un server, viene chiusa dopo ogni singola richiesta completata. Invece in FTP rimane
costantemente attiva… Infatti, questo è il motivo per cui nell’HTTP bisogna ricorrere ai
“Cookies“. Per Memorizzare una serie di stati/valori da una richiesta ad un’altra.
Per quanto concerne l’HTTP e la Sicurezza informatica, già da svariati anni per
scongiurare attacchi di tipo MID (Man In the Middle), è stato introdotto l’HTTPS. La
porta di default impiegata non è la 80 come in HTTP, ma la 443, mentre
(trasparentemente all’utente) tra il protocollo TCP e HTTP si interpone un livello di
crittografia/autenticazione come il Secure Sockets Layer (SSL).
Ma abbiamo dato uno sguardo alle caratteristiche principali.

HTTP/REST, la scelta più comune ma non sempre la

migliore
Uno dei protocolli maggiormente utilizzati per la connessione dei device al Cloud è il
protocollo HTTP attraverso l’architettura REST (REpresentation State Transfer). Sarà
proprio questa la modalità di connessione che utilizzeremo più avanti in un caso
pratico, ma va detto che può non essere considerata la migliore, in particolare nel
nostro caso.
HTTP è un protocollo ASCII e puramente testuale che si basa sul
pattern request/response ma che soprattutto tende a trasferire troppe informazioni
di “contorno”, come ad esempio gli header, in relazione al reale contenuto
informativo incluso nel body (anche se in alcuni modelli, le informazioni possono
essere trasferite anche attraverso headers “custom” non standard e senza alcun
body).
Spesso, la quantità di dati da manipolare è un problema per un device embedded
soprattutto in termini di memoria e può contemporaneamente determinare un
aumento dei costi durante il trasferimento nel caso, per esempio, di una connessione
GPRS e quindi di un traffico dati attraverso una SIM.
HTTP resta indubbiamente il protocollo più comune e ciò può risultare utile
soprattutto nel caso di applicazioni su tablet o smartphone che accedono al Cloud per
mostrare all’utente finale i dati acquisiti.
L'HTTP è un protocollo "stateless" (senza memoria) che permette sia la ricerca che il
recupero dell'informazione in maniera veloce, e permette quindi di seguire i rimandi
ipertestuali. La scelta di un protocollo "stateless", cioè di un protocollo che non
"conserva memoria" della connessione fatta, è stata necessaria affinché fosse possibile
saltare velocemente da un server ad un altro attraverso i "links" ipertestuali.

HTTP ad ogni richiesta effettua una nuova connessione al server che viene chiusa al
termine del trasferimento dell'oggetto richiesto (pagina HTML, immagine, ecc.).

È gestito da un software (server HTTP) residente sugli host che intendono essere
fornitori di informazioni. Chi vuole accedere alle informazioni fornite dal server HTTP
deve utilizzare un software client (browser) in grado di interpretare le informazioni
inviate dal server.

IL SERVER, informalmente, è un programma che "gira" in attesa di una richiesta di

connessione sul suo socket (la porta assegnatagli, tipicamente la 80). Il protocollo viene
utilizzato da un processo daemon (cioè sempre in esecuzione)

Questo protocollo è invocato da TCP/IP ogni qualvolta l'URL (che è una stringa che
specifica la risorsa a cui riferirci) istanziata contiene nel primo campo la parola http. I
comandi utilizzati per comunicare con esso sono detti Metodi.

Un server WWW ha il compito (potenzialmente computazionalmente dispendioso) di

rispondere a tutte le richieste che giungono dalla rete. Basti pensare che server WWW di
siti professionali raggiungono facilmente le 300.000 richieste al giorno.
FASI DI COMUNICAZIONE
L'acquisizione del documento da parte del client può essere schematizzata in quattro
fasi:

 CONNESSIONE: Il client crea una connessione TCP-IP con il server usando il suo
nome di dominio (o il numero IP) ed il numero della porta di trasmissione; se non
viene fornito il numero di porta, il protocollo assume per default che il numero
sia 80.
 RICHIESTA DOCUMENTO: Il client invia la richiesta di un documento mediante una
riga di caratteri ASCII terminata da una coppia di caratteri CR-LF (Carriage
Return, Line Feed).
 RISPOSTA: La risposta inviata dal server è un messaggio in linguaggio HTML nel
quale è contenuto il documento richiesto (o un messaggio d'errore).
 SCONNESSIONE: Il server subito dopo aver spedito il documento si sconnette.
Comunque anche il client può interrompere la connessione in ogni momento, in
questo caso il server non registrerà nessuna condizione d'errore.

Messaggi
 Gli oggetti implicati nella comunicacine client/server prendono il nome di
messaggi. La richiesta di un client e la risposta di un server sono messaggi. Essi
sono trasmessi in un formato simile a quello usato per le E-mail che prende il
nome di Multipurpose Internet Mail Extensions (MIME).
 Il server deve comunicare al client il tipo MIME utilizzato nella risposta e il client
deve comunicare, attraverso il campo accept, al server quali formati può gestire.

Proxy, Gateway e Tunnel

Abbiamo detto sopra che l’HTTP è un protocollo client/server.

Un cliente manda una richiesta ad un server, fornendogli un uri che localizza la risorsa
sul server, per poi ricevere un risposta da quest’ultimo.

Nel caso più semplice si apre una singola connessione attraverso un socket che connette
il client (browser) con il server http.

Una situazione più complicta avviene quando vengono coinvolti:

 Proxy: è un programma che si trova intermediamente tra il client ed il server e

simula entrambi. Il client inoltra la richiesta al proxy e questo la invia al
server,poi il server inoltra la risposta al proxy e questo la invia al client. Un
"transparent proxy" è un proxy che non modifica i dati che gli arrivano, mentre un
"non-transparent proxy" modifica le richieste e le risposte aggiungendo loro altre
 informazioni inerenti al client o al server oppure per una riduzione di protocollo
oppure per fungere da filtro.
 Gateway: è un server che funge da server originario ricevendo la richiesta per poi
rispondere. Il client richiedente potrebbe non essere consapevole di stare in
comunicazione con un gateway. Il gateway viene utilizzato per interconnettere
reti locali diverse in modo da permettere lo scambio di informazioni tra di loro.
 Tunnel: è un programma intermediario che serve per unire due connessioni senza
né cambiare i messaggi né capirli. Si potrebbe immaginarlo come un firewall.

Per ridurre il traffico sulla rete e per velocizzare i trasferimenti più frequenti, sono stati
introdotti i Proxy Server che generalmente supportano una cache memory. I dati che
attraversano il Proxy server, vengono memorizzati su una memoria di massa in modo da
poter essere restituiti il più rapidamente possibile durante successive richieste
identiche.

L'idea alla base del "Caching" é semplice: archiviare il documento ricevuto in un file
locale per usarlo di nuovo, senza che sia necessario riconnettersi al server remoto
quando quel documento sará nuovamente richiesto.

MQTT e altri protocolli

Dal punto di vista dei device che devono trasmettere dei dati, può invece non essere
la scelta migliore: nell’ambito dell’Internet of Things si stanno affermando, sempre
più numerosi, altri protocolli soprattutto “binari” che, non solo hanno un pattern
diverso noto come publish/subscribe, ma soprattutto garantiscono un trasferimento
minimo di byte “inutili” rispetto al contenuto informativo. Tra i più noti ci sono:
 MQTT (Message Queue Telemetry Transport) nato proprio per la “telemetria”, molto
leggero ed affidabile (garantisce tre livelli differenti di QoS) soprattutto su reti non
perfette in termini di stabilità della connessione.
 AMQP (Advanced Message Queuing Protocol), nato soprattutto per la connessione
“server to server” e quindi per sistemi enterprise, più “pesante” di MQTT ma con il
supporto a numerosissimi pattern differenti.
Ad essi si aggiungono anche i vari XMPP, DDS, STOMP e così via. Per gli amanti
dell’HTTP, ma che comunque vogliono evitare il suo “enorme” peso, c’è il
protocollo CoAP(Constrained Application Protocol) che è HTTP-like, basato sul pattern
request/response, su UDP (in luogo di TCP) ma soprattutto “binario” e quindi più
leggero.
Nell’ambito di questa ampia varietà di protocolli, la scelta dell’uno rispetto ad un
altro dipende sempre dal tipo di applicazione da realizzare ed in moltissimi casi si
tende ad utilizzarne sempre più di uno. Un’analisi di questo tipo occuperebbe una
guida intera e per questo motivo, utilizzeremo per maggiore semplicità il protocollo
HTTP.