Livello applicazione - HTTP

Il livello applicazione

Il livello applicazione fornisce servizi all'utente. La comunicazione avviene su una connessione logica: le due applicazioni si comportano come se ci fosse un collegamento diretto immaginario su cui scambiarsi messaggi. È diverso dagli altri livelli perché è il più alto della pila: i suoi protocolli non offrono servizi a nessun altro protocollo, ricevono soltanto i servizi del livello di trasporto (Modello ISO-OSI e pila TCP-IPUna comunicazione tra due calcolatori è un problema troppo vario (segnali, errori, accesso al mezzo, instradamento, controllo di flusso, rappresentazione dei dati) per un solo protocollo, quindi si divide in strati (layer). Il modello ISO/OSI ha 7 livelli (fisico, collegamento, rete, trasporto, sessione, presentazione, applicazione); la pila TCP/IP riunisce gli ultimi tre in un solo livello applicazione, quindi ne ha 5. Ogni livello offre un servizio a quello sopra e parla solo con il livello pari dell'altro nodo tramite PDU; scendendo si aggiunge un'intestazione (PCI): incapsulamento. Indirizzi: MAC (collegamento, locale), IP (rete, globale).Modello ISO-OSI e pila TCP-IP →). Servizi diversi usano protocolli diversi:

Questa nota tratta il Web e HTTP; la posta elettronica è in Posta elettronica - SMTP, POP3 e IMAPLa posta elettronica è una transazione a senso unico: non ha senso che il destinatario tenga un server sempre acceso, quindi si usano server intermedi. Servono due User Agent (UA, il programma dell'utente), due programmi client/server di spinta (MTA, protocollo SMTP: mittente-suo server e server-server) e un programma client/server di tiro (MAA, POP3 o IMAP4: server del destinatario-destinatario). SMTP usa TCP porta 25, comandi HELO, MAIL FROM, RCPT TO, DATA, QUIT e risposte a tre cifre (220 pronto, 250 ok, 354 inizia il testo, 221 chiusura, 421 non disponibile) in tre fasi: apertura, trasferimento, chiusura. POP3 (porta 110): utente e password, poi elenca e scarica i messaggi uno a uno; non organizza la posta sul server. IMAP4 aggiunge intestazioni prima del download, ricerca, download parziale, cartelle sul server. MIME permette di spedire dati non ASCII (immagini, video, lettere accentate) traducendoli in ASCII a 7 bit, per esempio in base64 (3 byte diventano 4 caratteri).Posta elettronica - SMTP, POP3 e IMAP →.

Il World Wide Web

L'idea del Web è stata proposta da Tim Berners-Lee nel 1989 al CERN, per permettere a ricercatori di sedi diverse d'Europa di consultare le ricerche degli altri. Oggi il Web è un archivio di informazioni in cui i documenti, le pagine web, sono distribuiti in tutto il mondo e collegati tra loro. Il collegamento si realizza con l'ipertesto: quando in un documento compare un riferimento a un altro documento, il sistema lo recupera automaticamente (oggi, quando l'utente fa clic sul collegamento).

Il WWW è un servizio client-server distribuito: un client, usando un browser, accede a un servizio offerto da un server. Il servizio è distribuito su molti siti; ogni sito contiene una o più pagine web, cioè file con un nome e un indirizzo.

Esempio. Per recuperare un documento (file A) che contiene un riferimento a un testo (file C) e a una grande immagine (file B), con A e B nello stesso sito e C in un altro sito, servono tre transazioni, una per file, se si vuole vedere il documento intero.

Client e server. Un browser è formato di solito da tre parti: un controllore, i protocolli client e gli interpreti (che mostrano la pagina, per esempio HTML). La pagina è memorizzata sul server e a ogni richiesta il documento corrispondente viene spedito al client. Per migliorare l'efficienza, il server tiene in cache in memoria i file richiesti (la memoria è più veloce del disco), e può servire più richieste insieme con più processi o più thread (multithreading, multiprocessing).

L'URL

Una pagina, essendo un file, ha bisogno di un identificatore unico. Servono tre dati: host, porta e percorso; e bisogna dire al browser anche quale applicazione client-server usare per raggiungere il percorso, cioè il protocollo. L'URL (Uniform Resource Locator) li riunisce:

Definizione (URL). protocollo://host/percorso (usato quasi sempre) oppure protocollo://host:porta/percorso (quando serve indicare la porta).

• Protocollo: abbreviazione del programma client-server usato per accedere alla pagina, di solito HTTP.
• Host: l'indirizzo IP del server oppure il suo nome unico, di norma il nome di dominio (per esempio wikipedia.org, tradotto dal DNS, Livello applicazione - DNSIl DNS (Domain Name System) traduce i nomi (www.amazon.com) negli indirizzi IP, perché le persone preferiscono i nomi e i protocolli TCP/IP usano gli indirizzi. È un database distribuito e gerarchico: albero rovesciato con radice, domini di primo livello e sottodomini (al più 128 livelli); le informazioni sono su tanti server (13 server radice) e i nuovi domini si registrano presso un registrar accreditato ICANN. Ogni ISP ha un DNS locale, il cui indirizzo l'host riceve con DHCP: l'host (resolver) gli manda la richiesta, di solito su UDP, e il DNS locale interroga radice, dominio di primo livello e server dell'organizzazione. Ogni server che impara un'associazione la tiene in cache, marcando la risposta non autoritativa, e la scarta dopo il TTL. Record (nome, tipo, valore, classe, TTL). Con il NAT il DNS deve restituire l'indirizzo pubblico. Quattro attacchi: macchina compromessa, risposta falsa all'host, avvelenamento della cache del DNS locale, server DNS malevolo.Livello applicazione - DNS →).
• Porta: intero a 16 bit (da $0$ a $2^{16}-1=65\,535$, Sistemi di numerazione posizionaliNotazione posizionale in base b; conversioni tra base 10, 2, 8 e 16 per interi (divisioni successive) e per parti frazionarie (moltiplicazioni successive); numeri periodici in binario.Sistemi di numerazione posizionali →), normalmente predefinito per l'applicazione (HTTP usa la porta 80); si scrive solo se è diverso.
• Percorso: posizione e nome del file nel sistema operativo del server; in UNIX è una serie di nomi di cartelle seguiti dal nome del file, separati da / (per esempio /top/next/last/myfile).

Esempio. http://www.example.it:8080/corsi/internet.html: protocollo http, host www.example.it, porta 8080 (invece della 80), percorso /corsi/internet.html. La richiesta conterrà GET /corsi/internet.html HTTP/1.1 e Host: www.example.it:8080.

Una pagina web è un file HTML con vari oggetti incorporati (immagini, fogli di stile, script), ciascuno con il proprio URL e quindi scaricato con una richiesta distinta. Questo conta nei calcoli sui tempi: una pagina con 1 file HTML e 10 immagini richiede 11 richieste.

HTTP

HTTP (HyperText Transfer Protocol) definisce come si scrivono i programmi client e server che recuperano le pagine dal Web. Un client HTTP manda una richiesta; un server HTTP restituisce una risposta.

• Il server usa la porta 80; il client usa una porta temporanea (Livello di trasporto - porte e multiplexingIl livello di trasporto (transport layer) offre la comunicazione logica end-to-end tra processi applicativi di host diversi, ed è realizzato solo negli host finali, non nei router. Il livello di rete consegna al computer giusto (indirizzo IP), il trasporto consegna al processo giusto (numero di porta di 16 bit, 0-65535). Una porta più un indirizzo IP formano un socket; la quaterna (IP sorgente, porta sorgente, IP destinazione, porta destinazione) identifica una connessione. I servizi sono: comunicazione processo-processo, indirizzamento, incapsulamento/decapsulamento, multiplexing/demultiplexing e, se il protocollo è affidabile, controllo di errore, di flusso e di congestione. I protocolli sono UDP (senza connessione, inaffidabile), TCP (con connessione, affidabile) e SCTP (combina i due).Livello di trasporto - porte e multiplexing →).
• HTTP usa i servizi di TCP: servono quindi le fasi di apertura e di chiusura della connessione (TCP - connessione, affidabilità e controllo di flussoTCP (Transmission Control Protocol) è il protocollo di trasporto con connessione e affidabile: trasforma il servizio senza connessione e inaffidabile di IP in un flusso di byte ordinato, senza errori né duplicati. La connessione si apre con l'handshake a tre vie (SYN, SYN+ACK, ACK) e si chiude con tre o quattro segmenti (FIN). I byte sono numerati: il numero di sequenza è quello del primo byte del segmento, il numero di ACK (cumulativo) è il prossimo byte atteso. Il mittente può inviare $\min(\text{rwnd},\text{cwnd})$ byte non ancora confermati; rwnd (finestra del ricevitore, in un campo di 16 bit) è il controllo di flusso. L'errore si gestisce con checksum, ACK, timeout di ritrasmissione (RTO) e ritrasmissione rapida dopo tre ACK duplicati. Per usare tutto il canale la finestra deve valere almeno il prodotto banda-ritardo (BDP); il throughput massimo è $\text{MSS}\cdot W_{\max}/\text{RTT}$.TCP - connessione, affidabilità e controllo di flusso →). Client e server non devono preoccuparsi di errori o perdite dei messaggi, perché TCP è affidabile e ci pensa lui.
• È senza stato (stateless): il server non ricorda nulla delle richieste precedenti dello stesso client. Quando serve la memoria (carrello, accesso) si usano i cookie.
• Nelle versioni 1.x i messaggi sono testo ASCII, quindi si possono leggere e scrivere a mano con telnet o nc sulla porta 80.

I messaggi HTTP/1.1

Richiesta: una riga di richiesta, le intestazioni (una per riga, Nome: valore), una riga vuota, poi l'eventuale corpo. Ogni riga termina con CR LF.

GET /corsi/internet.html HTTP/1.1
Host: www.example.it
User-Agent: Mozilla/5.0 (X11; Linux x86_64) Firefox/130.0
Accept: text/html,application/xhtml+xml;q=0.9,*/*;q=0.8
Accept-Language: it-IT,it;q=0.9,en;q=0.5
Connection: keep-alive

Risposta: una riga di stato (versione, codice, frase), le intestazioni, la riga vuota, il corpo.

HTTP/1.1 200 OK
Date: Fri, 09 Oct 2026 10:15:30 GMT
Server: Apache/2.4
Content-Type: text/html; charset=UTF-8
Content-Length: 44

<html><body><h1>Internet</h1></body></html>

Content-Length: 44 è il numero di byte del corpo: la stringa <html><body><h1>Internet</h1></body></html> più il carattere di a capo finale sono 44 byte (contati con Python). Serve al client per sapere quando il corpo è finito senza chiudere la connessione.

L'intestazione Host è obbligatoria in HTTP/1.1: lo stesso indirizzo IP può ospitare molti siti (virtual hosting), e il nome del sito si vede solo qui, perché il DNS ha già "consumato" il nome per trovare l'IP.

Definizione (intestazioni principali).

Richiesta: Host (sito richiesto), User-Agent (programma client), Accept e Accept-Language (formati e lingue preferiti, con pesi q), Cookie (cookie memorizzati). Risposta: Date, Server, Set-Cookie, Location (dove andare, per i reindirizzamenti). Entrambe: Content-Type (formato del corpo, per esempio text/html, image/png, application/json), Content-Length (lunghezza del corpo in byte), Connection (keep-alive o close).

Esempio. Una POST che invia un modulo: Content-Type: application/x-www-form-urlencoded e Content-Length: 17 per il corpo nome=Mario&eta=30 (17 caratteri contati).

POST /iscrizione HTTP/1.1
Host: www.example.it
Content-Type: application/x-www-form-urlencoded
Content-Length: 17

nome=Mario&eta=30

Metodi

Definizione (metodo sicuro, metodo idempotente). Un metodo è sicuro se non modifica lo stato del server (solo lettura); è idempotente se ripeterlo $n$ volte ha lo stesso effetto che eseguirlo una volta.

Esempio. DELETE /foto/7 ripetuto due volte lascia il server nello stesso stato (la foto 7 non c'è più; la seconda volta può rispondere 404): idempotente. Due POST /ordini creano invece due ordini: non idempotente. Per questo il browser avvisa quando si ricarica una pagina ottenuta con una POST.

Con una GET i parametri stanno nella query dell'URL (visibili, nella cronologia, nei log); con una POST stanno nel corpo.

Codici di stato

Il primo cifra indica la classe: 1xx informativi, 2xx successo, 3xx reindirizzamento, 4xx errore del client, 5xx errore del server.

Proprietà (reindirizzamento). Una risposta 301/302 contiene Location: nuovo-URL: il browser fa una nuova richiesta a quell'URL, automaticamente. Un solo clic può quindi costare più richieste (e più RTT).

Esempio. Chi scrive http://www.example.it/ riceve 301 con Location: https://www.example.it/: oltre ai 2 RTT già spesi per ottenere la 301, servono una nuova connessione TCP verso la porta 443 (1 RTT) e la nuova richiesta (almeno 1 RTT, più l'handshake TLS).

Connessioni: non persistenti e persistenti

L'ipertesto di una pagina può richiedere più richieste e risposte (una per file). Se gli oggetti stanno su server diversi non c'è altra scelta che aprire una connessione TCP separata per ciascuno. Se alcuni oggetti stanno sullo stesso server ci sono due possibilità.

HTTP non persistente: al più un oggetto per connessione TCP.

1. Il client apre la connessione TCP e manda la richiesta.
2. Il server manda la risposta e chiude la connessione.
3. Il client legge i dati fino al marcatore di fine file, poi chiude la connessione.

Per scaricare un oggetto servono:

• 1 RTT per la sincronizzazione (three-way handshake, TCP - connessione, affidabilità e controllo di flussoTCP (Transmission Control Protocol) è il protocollo di trasporto con connessione e affidabile: trasforma il servizio senza connessione e inaffidabile di IP in un flusso di byte ordinato, senza errori né duplicati. La connessione si apre con l'handshake a tre vie (SYN, SYN+ACK, ACK) e si chiude con tre o quattro segmenti (FIN). I byte sono numerati: il numero di sequenza è quello del primo byte del segmento, il numero di ACK (cumulativo) è il prossimo byte atteso. Il mittente può inviare $\min(\text{rwnd},\text{cwnd})$ byte non ancora confermati; rwnd (finestra del ricevitore, in un campo di 16 bit) è il controllo di flusso. L'errore si gestisce con checksum, ACK, timeout di ritrasmissione (RTO) e ritrasmissione rapida dopo tre ACK duplicati. Per usare tutto il canale la finestra deve valere almeno il prodotto banda-ritardo (BDP); il throughput massimo è $\text{MSS}\cdot W_{\max}/\text{RTT}$.TCP - connessione, affidabilità e controllo di flusso →): il client manda SYN e il server risponde SYN-ACK; l'ACK finale parte insieme alla richiesta;
• 1 RTT per la richiesta e per l'arrivo dell'inizio della risposta;
• più il tempo di trasmissione dell'oggetto $L/R$ (lunghezza su velocità del collegamento, Analisi delle prestazioni di reteLe prestazioni di una rete si misurano con tre famiglie di metriche: traffico (bitrate $R_0$ massimo del collegamento, throughput $S\le R_0$ dati consegnati con successo, goodput al livello applicazione), ritardo (end-to-end $d_{tot}=d_{proc}+d_{queue}+d_{trans}+d_{prop}$ con $d_{trans}=L/R$ e $d_{prop}=d/v$; jitter; RTT) e capacità del tubo (BDP $=R\cdot$ ritardo, bit che riempiono il collegamento), più l'affidabilità (PER, PDR, PLR). Il throughput di un percorso è quello del collegamento collo di bottiglia, $\min$ dei bitrate, ricordando che i collegamenti condivisi dividono la capacità.Analisi delle prestazioni di rete →).

Quindi un oggetto costa $2\,\text{RTT}+L/R$.

non persistente, un oggetto                      persistente, più oggetti
client                  server                   client                  server
  |--- SYN ------------->|                         |--- SYN ------------->|
  |<-- SYN+ACK ----------|    1 RTT                |<-- SYN+ACK ----------|    1 RTT (una volta sola)
  |--- ACK + GET ------->|                         |--- ACK + GET pagina->|
  |<-- risposta ---------|    1 RTT + L/R          |<-- pagina -----------|    1 RTT + L/R
  |    (connessione chiusa)                        |--- GET oggetto 1 --->|
  per il prossimo oggetto: di nuovo SYN...         |<-- oggetto 1 --------|    1 RTT + L/R

Il tempo di andata e ritorno RTT conta due ritardi di propagazione (Analisi delle prestazioni di reteLe prestazioni di una rete si misurano con tre famiglie di metriche: traffico (bitrate $R_0$ massimo del collegamento, throughput $S\le R_0$ dati consegnati con successo, goodput al livello applicazione), ritardo (end-to-end $d_{tot}=d_{proc}+d_{queue}+d_{trans}+d_{prop}$ con $d_{trans}=L/R$ e $d_{prop}=d/v$; jitter; RTT) e capacità del tubo (BDP $=R\cdot$ ritardo, bit che riempiono il collegamento), più l'affidabilità (PER, PDR, PLR). Il throughput di un percorso è quello del collegamento collo di bottiglia, $\min$ dei bitrate, ricordando che i collegamenti condivisi dividono la capacità.Analisi delle prestazioni di rete →): la richiesta (o il SYN) va, la risposta (o il SYN+ACK) torna. Il tempo di trasmissione $L/R$ si aggiunge una volta per oggetto, perché i bit di una risposta escono dal collegamento uno dopo l'altro alla velocità $R$.

HTTP persistente: più oggetti viaggiano sulla stessa connessione TCP tra client e server. Il server chiude la connessione su richiesta del client o allo scadere di un time-out. HTTP/1.1 rende persistenti le connessioni di default (Connection: keep-alive, si chiude con Connection: close). L'handshake si fa una volta sola. Ci sono due modi di usarla:

• senza pipelining: la richiesta successiva parte solo quando la risposta precedente è arrivata (1 RTT per oggetto);
• con pipelining: il client manda tutte le richieste senza aspettare le risposte, che tornano nello stesso ordine (all'incirca 1 RTT per tutti). Nella pratica i browser l'hanno disattivato, per via di head-of-line blocking (una risposta lenta blocca quelle dietro) e di server che lo gestivano male.

Formula (tempo di caricamento di una pagina con $N$ oggetti incorporati). Trascurando i tempi di trasmissione, con $N+1$ oggetti in tutto (la pagina HTML più $N$ oggetti):

• non persistente: $T=2(N+1)\,\text{RTT}$;
• persistente senza pipelining: $T=(2+N)\,\text{RTT}$ (2 per la pagina, 1 per ciascun oggetto);
• persistente con pipelining: $T=3\,\text{RTT}$ (2 per la pagina, 1 per tutti gli oggetti insieme).

Da dove vengono. Non persistente: ogni oggetto ha la sua connessione e costa $1$ RTT (handshake) $+\,1$ RTT (richiesta e risposta) $=2$ RTT; gli oggetti sono $N+1$ (la pagina e gli $N$ incorporati), uno dopo l'altro, quindi $2\cdot(N+1)$ RTT. Persistente senza pipelining: l'handshake si fa una volta per la pagina: pagina $=1+1=2$ RTT; poi la connessione è già aperta e ogni oggetto costa solo $1$ RTT (una richiesta e la sua risposta), uno alla volta: $N\cdot1$. Totale $2+N$. Con pipelining: dopo la pagina (2 RTT) il client conosce tutti gli URL e manda le $N$ richieste insieme, senza aspettare le risposte: il costo è $1$ RTT per tutte, totale $3$ RTT. Con $N=10$: $2\cdot11=22$, $2+10=12$, $3$ RTT.

Esempio. $\text{RTT}=100$ ms, $N=10$: non persistente $2\cdot11\cdot0{,}1=2{,}2$ s; persistente $12\cdot0{,}1=1{,}2$ s; con pipelining $0{,}3$ s. Il risparmio della persistenza rispetto al non persistente è $2(N+1)-(2+N)=N$ RTT: un RTT per ogni oggetto incorporato (l'handshake che non si ripete).

Con i tempi di trasmissione: pagina HTML di 50 kB e 10 immagini da 100 kB su un collegamento da 10 Mbit/s: $t_{\text{html}}=50\,000\cdot8/10^7=0{,}04$ s e $t_{\text{obj}}=100\,000\cdot8/10^7=0{,}08$ s (si moltiplica per $8$ perché la velocità è in bit/s e la dimensione in byte; $1$ kB $=10^3$ byte e $1$ Mbit/s $=10^6$ bit/s, Analisi delle prestazioni di reteLe prestazioni di una rete si misurano con tre famiglie di metriche: traffico (bitrate $R_0$ massimo del collegamento, throughput $S\le R_0$ dati consegnati con successo, goodput al livello applicazione), ritardo (end-to-end $d_{tot}=d_{proc}+d_{queue}+d_{trans}+d_{prop}$ con $d_{trans}=L/R$ e $d_{prop}=d/v$; jitter; RTT) e capacità del tubo (BDP $=R\cdot$ ritardo, bit che riempiono il collegamento), più l'affidabilità (PER, PDR, PLR). Il throughput di un percorso è quello del collegamento collo di bottiglia, $\min$ dei bitrate, ricordando che i collegamenti condivisi dividono la capacità.Analisi delle prestazioni di rete →; $L/R$ ha l'unità bit/(bit/s) $=$ s). Non persistente: $0{,}2+0{,}04+10(0{,}2+0{,}08)=3{,}04$ s. Persistente: $0{,}2+0{,}04+10(0{,}1+0{,}08)=2{,}04$ s. Con pipelining: $0{,}2+0{,}04+0{,}1+10\cdot0{,}08=1{,}14$ s (le richieste partono insieme, ma le immagini arrivano comunque una dopo l'altra sul collegamento). Il tempo di trasmissione non si riduce con il protocollo: solo i round-trip.

Il risparmio più grande lo dà la persistenza (si elimina 1 RTT per ogni oggetto); le connessioni TCP nuove hanno anche il difetto di ripartire con la finestra di congestione piccola (TCP - controllo di congestioneLa congestione nasce quando collegamenti veloci alimentano un collegamento lento: le code dei router si riempiono, i pacchetti si perdono o ritardano e, nel caso peggiore, la rete collassa (quasi solo ritrasmissioni). TCP controlla la propria finestra di congestione cwnd con il feedback delle perdite (timeout o tre ACK duplicati): slow start (cwnd raddoppia a ogni RTT) fino alla soglia ssthresh, poi congestion avoidance (+1 MSS per RTT); a ogni perdita ssthresh = W/2. Le varianti si distinguono per come reagiscono ai tre dupACK: Tahoe riparte da cwnd = 1 dopo la ritrasmissione rapida; Reno usa il fast recovery (ssthresh = cwnd/2, cwnd = ssthresh + 3, +1 per ogni altro dupACK); NewReno gestisce gli ACK parziali e recupera più perdite nella stessa finestra; SACK riscontra i blocchi ricevuti e ritrasmette solo quello che manca.TCP - controllo di congestione →), mentre una connessione persistente ha già "preso velocità".

Cookie

Il Web è nato come entità senza stato: un client manda una richiesta, il server risponde. Oggi però molte funzioni devono ricordare qualcosa del client (negozi online, portali, pubblicità). Per questo è stato inventato il meccanismo dei cookie:

• il server raccoglie informazioni sul client (nella richiesta) e prepara un cookie, che manda al client nella risposta;
• il cookie è incluso dal client nelle richieste successive;
• il cookie è "fatto e mangiato" dal server: il client lo conserva soltanto.

Definizione (cookie). Una piccola stringa, per esempio sessione=18988466, che il server manda in una risposta con l'intestazione Set-Cookie; il browser la memorizza e la rimanda in ogni richiesta successiva allo stesso sito, con l'intestazione Cookie. Il server usa il valore come chiave per ritrovare nella propria base di dati i dati dell'utente.

Esempio (come nelle slide).

GET /ntw/index.html HTTP/1.1                  <- prima richiesta, nessun cookie

HTTP/1.1 200 OK
Set-Cookie: 18988466                          <- il server assegna il cookie

GET /ntw/carrello/index.html HTTP/1.1
Cookie: 18988466                              <- il client lo rimanda

GET /image.gif HTTP/1.1
Cookie: 18988466                              <- e a ogni richiesta successiva

Il formato ha quattro componenti:

1. una riga di intestazione nel messaggio di risposta HTTP (Set-Cookie);
2. una riga di intestazione nel messaggio di richiesta HTTP (Cookie);
3. un file conservato sul computer dell'utente e gestito dal suo browser;
4. una base di dati dietro al sito web (back-end), dove il valore del cookie ritrova i dati del cliente.

A che cosa servono.

• Gestione della sessione: dopo l'accesso, un cookie ricorda l'utente, che non deve reinserire le credenziali a ogni pagina.
• Personalizzazione: preferenze come lingua e tema.
• Tracciamento e statistiche: seguire l'attività dell'utente tra siti diversi, per analisi e pubblicità personalizzata.
• Carrello: nei negozi online i cookie conservano il carrello anche se l'utente cambia pagina o torna più tardi.

Il valore del cookie di sessione deve essere casuale e lungo: un identificatore indovinabile permette di impersonare un altro utente (session hijacking, Introduzione alla sicurezza delle retiUna minaccia è un evento o una sequenza di azioni che può violare uno o più obiettivi di sicurezza; la sua realizzazione è un attacco. Obiettivi: riservatezza, integrità, disponibilità, responsabilità (accountability), privacy. Minacce: intercettazione, analisi del traffico, falsificazione, mascheramento, ripudio, profilazione, fingerprinting, disturbo (jamming). Servizi (segretezza, protezione dell'integrità, autenticazione del messaggio e dell'entità, non ripudio, anonimizzazione, gestione delle chiavi, controllo degli accessi) e meccanismi (cifratura, firma digitale, rilevamento delle intrusioni, MAC, randomizzazione, accordo sulla chiave). Un protocollo di sicurezza di livello N protegge la PDU di livello N e superiori, non quelle sotto. Attacchi fisici, software e di rete; sniffing e spoofing alla base di DoS (esempio: Smurf con ICMP) e MITM (avvelenamento della cache ARP o DNS, ICMP redirect). Altri: sinkhole, wormhole, ping of death, DDoS con botnet.Introduzione alla sicurezza delle reti →). Quantitativamente (probabilità uniforme: casi favorevoli su casi possibili, Spazi di probabilità discreti e uniformiIn uno spazio discreto la probabilità è determinata dalla densità discreta p(ω) = P({ω}), con somma 1, e P(A) è la somma di p(ω) sugli esiti di A; negli spazi uniformi (esiti equiprobabili) P(A) = |A| / |Ω|, casi favorevoli su casi possibili.Spazi di probabilità discreti e uniformi →): se il sito ha $S=10^6$ sessioni aperte e il cookie è un numero di $8$ cifre decimali (come 18988466, $10^8$ valori possibili), un tentativo a caso azzecca una sessione valida con probabilità $S/10^8=10^6/10^8=1\%$; con $64$ bit casuali la probabilità è $S/2^{64}=10^6/1{,}8\cdot10^{19}\approx5\cdot10^{-14}$, trascurabile. Il cookie viaggia in chiaro con HTTP semplice; con HTTPS è protetto dalla cifratura.

Cache e proxy

Un proxy (web cache, proxy server) è un computer che conserva copie delle risposte alle richieste recenti.

1. Il client HTTP manda la richiesta al proxy (il browser è configurato per usarlo e scrive nella richiesta l'URL completo: GET http://www.example.it/ HTTP/1.1).
2. Il proxy controlla la sua cache. Se la risposta non c'è, manda la richiesta al server vero.
3. Le risposte in arrivo passano dal proxy e vengono memorizzate per le richieste future di altri client.

Il proxy riduce il carico sul server d'origine, diminuisce il traffico e migliora la latenza. Lo stesso principio è usato dai grandi operatori con le CDN (content delivery network).

Formula (tempo medio con una cache). Se la frazione $h$ delle richieste è soddisfatta dalla cache (hit ratio), $\bar T=h\,T_{\text{hit}}+(1-h)\,T_{\text{miss}}$, dove $T_{\text{miss}}=T_{\text{hit}}+T_{\text{origine}}$ (la cache va attraversata comunque).

Esempio. $T_{\text{hit}}=10$ ms, $T_{\text{origine}}=200$ ms, $h=0{,}4$: $\bar T=0{,}4\cdot10+0{,}6\cdot210=130$ ms invece di $200$ ms senza cache.

Passaggi: con probabilità $h$ la risposta arriva dalla cache e costa $T_{\text{hit}}$; con probabilità $1-h$ la richiesta attraversa la cache e poi va all'origine, e costa $T_{\text{hit}}+T_{\text{origine}}=10+200=210$ ms. La media pesata è il Valore attesoIl valore atteso E[X] = Σ x p_X(x) è la media dei valori di X pesata con le loro probabilità (esiste se la serie converge assolutamente); per una funzione g vale E[g(X)] = Σ g(x) p_X(x) senza trovare la legge di g(X), ed E è lineare: E[aX + bY + c] = aE[X] + bE[Y] + c.Valore atteso → del tempo: $\bar T=h\cdot10+(1-h)\cdot210=210-200\,h$. Confrontando con i $200$ ms senza cache: $210-200\,h<200$ solo se $h>10/200=5\%$. Sotto il $5\%$ di successi la cache fa perdere tempo (il passaggio extra non è compensato).

HTTPS

HTTPS è HTTP trasportato dentro una connessione TLS, di norma sulla porta 443: gli stessi messaggi, ma cifrati, con l'identità del server provata da un certificato. Prima della richiesta HTTP si aggiunge quindi l'handshake TLS (Crittografia asimmetrica, RSA e TLSCrittografia asimmetrica (a chiave pubblica): chiave di cifratura pubblica v_B, chiave di decifratura privata s_B, matematicamente legate; C = E_vB(P), P = D_sB(C); dà riservatezza. I certificati digitali, emessi da una Certificate Authority e firmati con la sua chiave privata, legano un'identità a una chiave pubblica. Firma digitale: hash del messaggio cifrato con la chiave privata; garantisce autenticità, integrità e non ripudio. RSA: si scelgono due primi grandi p e q, N = pq, phi(N) = (p-1)(q-1), e coprimo con phi(N), d = e^(-1) mod phi(N); chiave pubblica (N, e), segreta (N, d); cifratura c = m^e mod N, decifratura m = c^d mod N con m < N (teorema di Eulero); sicura finché la fattorizzazione è difficile (N di almeno 2048 bit); il padding casuale (PKCS#1 v1.5: 00 02 [casuale] 00 [m]) difende da malleabilità e determinismo. La firma RSA è s = m^d mod N, verificata con s^e mod N. TLS (su TCP) autentica gli estremi con il certificato, cifra i dati con una chiave di sessione simmetrica e garantisce l'integrità con i MAC; da TLS 1.0 a 1.3 la chiave si ricava con Diffie-Hellman e l'handshake si accorcia. DTLS è la versione per UDP.Crittografia asimmetrica, RSA e TLS →). Per questo l'attributo Secure dei cookie ha senso: il browser verifica il certificato prima di mandare cookie e password.

Errori comuni

• Dire che HTTP "mantiene lo stato": è il cookie a farlo, il protocollo no.
• Contare un solo RTT per oggetto in una connessione non persistente: sono 2 (handshake TCP + richiesta).
• Contare 3 RTT per ogni oggetto con pipelining: l'handshake e la pagina HTML si pagano una volta, gli $N$ oggetti insieme costano 1 RTT.
• Dimenticare la riga vuota che separa intestazioni e corpo.
• Dimenticare di sommare i tempi di trasmissione $L/R$ quando i dati sono dati nell'esercizio.