reti_cap2.pdf
Document Details
Related
- PCSII Depression/Anxiety/Strong Emotions 2024 Document
- A Concise History of the World: A New World of Connections (1500-1800)
- Human Bio Test PDF
- University of Santo Tomas Pre-Laboratory Discussion of LA No. 1 PDF
- Vertebrate Pest Management PDF
- Lg 5 International Environmental Laws, Treaties, Protocols, and Conventions
Full Transcript
Reti (Computer Networks) Capitolo 2 Il livello applicazione Docente: Fabrizio Granelli AA 2024/2025 Capitolo 2: Il livello applicazione 2.1 Principi delle 2.6 Applicazioni P2P applicazioni di rete 2.7 Cloud Computing 2.2 Web e HTTP 2.8 Programmazione...
Reti (Computer Networks) Capitolo 2 Il livello applicazione Docente: Fabrizio Granelli AA 2024/2025 Capitolo 2: Il livello applicazione 2.1 Principi delle 2.6 Applicazioni P2P applicazioni di rete 2.7 Cloud Computing 2.2 Web e HTTP 2.8 Programmazione delle 2.3 FTP socket (cenni) 2.4 Posta elettronica ❖ SMTP, POP3, IMAP 2.5 DNS 2-2 Capitolo 2: Il livello applicazione Obiettivi: Apprendere informazioni sui Fornire i concetti base e gli protocolli esaminando quelli aspetti implementativi dei delle più diffuse applicazioni protocolli delle applicazioni di rete di rete ❖ HTTP (1.0, 1.1, 2.0) ❖ Modelli di servizio del livello di ❖ FTP trasporto ❖ SMTP / POP3 / IMAP ❖ Paradigma client-server ❖ DNS ❖ Paradigma peer-to-peer Programmare le applicazioni di rete ❖ Socket API 2-3 Internet e le Applicazioni 2-4 Creare un’applicazione di rete Applicazione trasporto rete collegamento Scrivere programmi che fisico ❖ Girano su sistemi terminali diversi ❖ Comunicano attraverso la rete ❖ Ad es. il software di un server Web comunica con il software di un browser Software in grado di funzionare su più macchine ❖ Non occorre predisporre Applicazione programmi per i dispositivi del trasporto rete nucleo della rete, quali router o collegamento fisico Applicazione commutatori Ethernet trasporto rete collegamento fisico 2-5 Capitolo 2: Livello applicazione 2.1 Principi delle 2.6 Applicazioni P2P applicazioni di rete 2.7 Cloud Computing 2.2 Web e HTTP 2.8 Programmazione delle 2.3 FTP socket 2.4 Posta elettronica ❖ SMTP, POP3, IMAP 2.5 DNS 2-6 Architetture delle applicazioni di rete Client-server Peer-to-peer (P2P) Architetture ibride (client-server e P2P) Cloud computing 2-7 Architettura client-server ❑ Server ❑ Host sempre attivo ❑ Indirizzo permanente ❑ Come scalare? ❑ Client ❑ Comunica con il server ❑ Può disconnettersi Client/server temporaneamente ❑ Può avere un indirizzo dinamico ❑ Non comunica direttamente con altri client 2-8 Architettura P2P pura Non c’è un server sempre attivo Coppie arbitrarie di host (peer) comunicano direttamente tra loro Peer to peer I peer non devono necessariamente essere sempre attivi, e cambiano indirizzo IP Facilmente scalabile Difficile da gestire 2-9 Ibridi (client-server e P2P) Skype ❖ Applicazione P2P di Voice over IP ❖ Server centralizzato: ricerca indirizzi della parte remota ❖ Connessione client-client: diretta (non attraverso il server) Messaggistica istantanea ❖ La chat tra due utenti è del tipo P2P ❖ Individuazione della presenza/location centralizzata: l’utente registra il suo indirizzo IP sul server centrale quando è disponibile online l’utente contatta il server centrale per conoscere gli indirizzi IP dei suoi amici 2-10 Cloud computing Insieme di tecnologie che permettono di memorizzare, archiviare e/o elaborare dati (con CPU o software) tramite l'utilizzo di risorse distribuite e virtualizzate in rete La creazione di una copia di sicurezza (backup) è automatica e l'operatività si trasferisce tutta online I dati sono memorizzati in server farm generalmente localizzate nei Paesi di origine del service provider 2-11 Processi del sistema operativo in comunicazione Processo: programma in esecuzione su di un host Processo client: processo che dà All’interno dello stesso host, due inizio alla comunicazione processi comunicano utilizzando Processo server: processo che schemi interprocesso (definiti dal attende di essere contattato SO) Processi su host differenti comunicano attraverso lo scambio di messaggi Nota: le applicazioni con architetture P2P hanno processi client e processi server 2-12 Socket Host o Host o Un processo invia/riceve messaggi server server a/da la sua socket Una socket è analoga a una porta Controllato dallo sviluppatore ❖ Un processo che vuole inviare un dell’applicazione Processo Processo messaggio, lo fa uscire dalla propria “porta” (socket) Socket Socket ❖ Il processo presuppone l’esistenza di TCP con TCP con un’infrastruttura esterna che Internet buffer e buffer e trasporterà il messaggio attraverso la variabili variabili rete fino alla “porta” del processo di destinazione Controllato dal SO API: (1) scelta del protocollo di trasporto; (2) capacità di determinare alcuni parametri (approfondiremo questo aspetto più avanti) 2-13 Indirizzamento ❑ Affinché un processo su un host L’identificatore comprende sia invii un messaggio a un processo su l’indirizzo IP che i numeri di porta un altro host, il mittente deve associati al processo in esecuzione identificare il processo destinatario su un host ❑ Un host ha un indirizzo (detto Esempi di numeri di porta: indirizzo IP) univoco di 32 bit ❖ HTTP server: 80 D: È sufficiente conoscere l’indirizzo ❖ Mail server: 25 IP dell’host su cui è in esecuzione il Per inviare un messaggio HTTP al processo per identificare il processo server gaia.cs.umass.edu: stesso? ❖ Indirizzo IP: 128.119.245.12 Risposta: No, sullo stesso host possono essere in esecuzione molti ❖ Numero di porta: 80 processi. 2-14 Protocolli a livello applicazione Tipi di messaggi scambiati, ad Protocolli di pubblico dominio: esempio messaggi di richiesta e Definiti nelle RFC della IETF di risposta Consentono l’interoperabilità Sintassi dei tipi di messaggio: Ad esempio, HTTP, SMTP quali sono i campi nel messaggio e come sono descritti Protocolli proprietari: Ad esempio, Skype Semantica dei campi, ovvero significato delle informazioni nei campi Regole per determinare quando e come un processo invia e risponde ai messaggi 2-15 Quale servizio di trasporto richiede un’applicazione? Perdita di dati Throughput alcune applicazioni (ad esempio, audio) alcune applicazioni (ad esempio, possono tollerare qualche perdita quelle multimediali) per essere altre applicazioni (ad esempio, “efficaci” richiedono un certo trasferimento di file, telnet) richiedono throughput minimo per funzionare un trasferimento dati affidabile al 100% altre applicazioni (le "applicazioni elastiche”) utilizzano il throughput a disposizione Temporizzazione Sicurezza alcune applicazioni (ad esempio, Cifratura, integrità dei dati,... telefonia Internet, giochi interattivi) per essere “realistiche” richiedono piccoli ritardi 2-16 Requisiti del servizio di trasporto di alcune applicazioni comuni Tolleranza alla perdita Sensibilità Applicazione di dati Throughput al tempo Trasferimento file No Variabile No Posta elettronica No Variabile No Documenti Web No Variabile No Audio/video Sì Audio: da 5 kbit/s a 1 Mbit/s Sì, centinaia di ms in tempo reale Video: da 10 kbit/s a 5 Mbit/s Audio/video Sì Come sopra Sì, pochi secondi memorizzati Giochi interattivi Sì Fino a pochi kbit/s Sì, centinaia di ms Messaggistica No Variabile Sì e no istantanea 2-17 Servizi dei protocolli di trasporto Internet Servizio di Transport Control Servizio di User Datagram Protocol (TCP): Protocol (UDP): orientato alla connessione: è trasferimento dati inaffidabile richiesto un setup fra i processi client fra i processi d’invio e di e server ricezione trasporto affidabile fra i processi d’invio e di ricezione non offre: setup della controllo di flusso: il mittente non connessione, affidabilità, vuole sovraccaricare controllo di flusso, controllo il destinatario della congestione, controllo della congestione: “strozza” temporizzazione né ampiezza di il processo d’invio quando le rete è banda minima e sicurezza sovraccaricata D: Perché preoccuparsi? Perché non offre: temporizzazione, garanzie su un’ampiezza di banda minima, esiste UDP? sicurezza 2-18 Applicazioni Internet: protocollo a livello applicazione e protocollo di trasporto, RFC Protocollo di Protocollo a livello trasporto Applicazione applicazione sottostante Posta elettronica SMTP [RFC 2821] TCP Accesso a terminali remoti Telnet [RFC 854] TCP Web HTTP [RFC 2616] TCP Trasferimento file FTP [RFC 959] TCP Multimedia in streaming HTTP (es. YouTube) TCP o UDP RTP [RFC 1889] Telefonia Internet SIP, RTP, proprietario Tipicamente UDP (es. Skype) 2-19 Capitolo 2: Livello applicazione 2.1 Principi delle 2.6 Applicazioni P2P applicazioni di rete 2.7 Cloud computing ❖ Architetture 2.8 Programmazione delle delle applicazioni socket (cenni) ❖ Servizi richiesti dalle applicazioni 2.2 Web e HTTP 2.3 FTP 2.4 Posta elettronica ❖ SMTP, POP3, IMAP 2.5 DNS 2-20 Tim Berners-Lee ❑ Inventore del World Wide Web ❑ Ha ricevuto l’ACM Turing Award ❖ “For inventing the World Wide Web, the first web browser, and the fundamental protocols and algorithms [that allowed] the web to scale” ❑ https://amturing.acm.org/award_winners/berners-lee_8087960.cfm ❑ Sir Tim Berners-Lee 2016 ACM A.M. Turing Lecture "What is the World Wide Web & what is its future?” 2-21 Web e HTTP Terminologia Una pagina web è costituita da oggetti Un oggetto può essere un file HTML, un’immagine JPEG, un’applet Java, un file audio, … Una pagina web è formata da un file base scritto tramite l’Hypertext Markup Language (HTML), che solitamente include diversi oggetti referenziati Ogni oggetto è referenziato da uno Uniform Resource Locator (URL) Esempio di URL: www.someschool.edu/someDept/home.html nome dell’host nome del percorso 2-22 Panoramica su HTTP HTTP: HyperText Transfer Protocol Protocollo a livello di PC con applicazione del Web Explorer Modello client/server ❖ client: il browser che richiede, riceve, “visualizza” gli oggetti del Web Server ❖ server: il server web invia con server web Apache oggetti in risposta a una richiesta Mac con Navigator 2-23 Panoramica su HTTP (continua) Usa TCP: HTTP è un protocollo “senza stato” (stateless) Il client inizializza la Il server non mantiene connessione TCP (crea una informazioni sulle richieste socket) con il server, fatte dal client la porta 80 Il server accetta la connessione nota I protocolli che mantengono lo “stato” TCP dal client sono complessi! Messaggi HTTP scambiati fra La storia passata (stato) deve browser (client HTTP) e server essere memorizzata web (server HTTP) Se il server e/o il client si Connessione TCP chiusa bloccano, le loro viste dello “stato” potrebbero essere contrastanti e dovrebbero essere riconciliate 2-24 Connessioni HTTP Connessioni non persistenti Connessioni persistenti Almeno un oggetto viene Più oggetti possono trasmesso su una essere trasmessi su una connessione TCP singola connessione TCP tra client e server 2-25 Connessioni non persistenti (contiene testo, Supponiamo che l’utente immetta l’URL riferimenti a 10 www.someSchool.edu/someDepartment/home.html immagini jpeg) 1a. Il client HTTP inizializza una connessione TCP con il server HTTP (processo) a 1b. Il server HTTP all’host www.someSchool.edu www.someSchool.edu in attesa di sulla porta 80 una connessione TCP alla porta 80 “accetta” la connessione e avvisa il 2. Il client HTTP trasmette un client messaggio di richiesta (con l’URL) nella socket della connessione TCP. Il messaggio indica che il client vuole 3. Il server HTTP riceve il messaggio l’oggetto di richiesta, forma il messaggio di someDepartment/home.index risposta che contiene l’oggetto richiesto e invia il messaggio nella sua socket tempo 2-26 Connessioni non persistenti (continua) 4. Il server HTTP chiude la connessione TCP 5. Il client HTTP riceve il messaggio di risposta che contiene il file html e visualizza il documento html. Esamina il file html, trova i riferimenti a 10 oggetti jpeg tempo 6. I passi 1-5 sono ripetuti per ciascuno dei 10 oggetti jpeg 2-27 Schema del tempo di risposta Definizione di Round-Trip Time (RTT): Tempo di propagazione di andata e ritorno tra due host (Es.: tempo impiegato da un piccolo pacchetto per andare dal client al Inizializzazione della server e ritornare al client) connessione TCP Tempo di risposta: RTT un RTT per inizializzare la Richiesta del file connessione TCP Tempo di RTT un RTT perché ritornino la richiesta trasmissione HTTP e i primi byte della risposta del file File HTTP ricevuto tempo di trasmissione del file tempo tempo totale = 2 RTT + tempo di trasmissione 2-28 Connessioni persistenti Svantaggi delle connessioni non Connessioni persistenti persistenti: il server lascia la connessione richiedono 2 RTT per oggetto TCP aperta dopo l’invio di una overhead del sistema operativo risposta per ogni connessione TCP i successivi messaggi tra gli i browser spesso aprono stessi client/server vengono connessioni TCP parallele per trasmessi sulla connessione caricare gli oggetti referenziati aperta il client invia le richieste non appena incontra un oggetto referenziato un solo RTT per tutti gli oggetti referenziati 2-29 Messaggi HTTP Due tipi di messaggi HTTP: richiesta, risposta Messaggio di richiesta HTTP: ❖ ASCII (formato leggibile dall’utente) Riga di richiesta (comandi GET, GET /somedir/page.html HTTP/1.1 POST, HEAD) Host: www.someschool.edu Righe di User-agent: Mozilla/4.0 intestazione Connection: close Accept-language:fr Un carriage return e un line feed (carriage return e line feed extra) indicano la fine del messaggio 2-30 Messaggio di richiesta HTTP: formato generale 2-31 Upload dell’input di un form Metodo Post: La pagina web spesso include un form per Metodo URL: l’input dell’utente Usa il metodo GET L’input arriva al server nel L’input arriva al server nel corpo dell’entità campo URL della riga di richiesta: www.somesite.com/animalsearch?monkeys&banana 2-32 Tipi di metodi HTTP/1.0 HTTP/1.1 GET GET, POST, HEAD POST PUT HEAD ❖ Include il file nel corpo dell’entità e lo invia ❖ Chiede al server di al percorso specificato nel escludere l’oggetto campo URL richiesto dalla risposta DELETE ❖ Cancella il file specificato nel campo URL 2-33 Messaggio di risposta HTTP Riga di stato (protocollo + codice di stato HTTP/1.1 200 OK + espressione di stato) Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Righe di Server: Apache/1.3.0 (Unix) intestazione Last-Modified: Mon, 22 Jun 1998... Content-Length: 6821 Content-Type: text/html dati dati dati dati dati... Dati, ad esempio il file HTML richiesto 2-34 Codici di stato della risposta HTTP Nella prima riga nel messaggio di risposta server->client. Alcuni codici di stato e relative espressioni: 200 OK ❖ La richiesta ha avuto successo; l’oggetto richiesto viene inviato nella risposta 301 Moved Permanently ❖ L’oggetto richiesto è stato trasferito; la nuova posizione è specificata nell’intestazione Location: della risposta 400 Bad Request ❖ Il messaggio di richiesta non è stato compreso dal server 404 Not Found ❖ Il documento richiesto non si trova su questo server 505 HTTP Version Not Supported ❖ Il server non supporta la versione richiesta del protocollo HTTP 2-35 Provate HTTP (lato client) 1. Collegatevi via Telnet o simili al vostro server web preferito: telnet www.unitn.it 80 Apre una connessione TCP alla porta 80 (porta di default per un server HTTP) rlwrap nc –C www.unitn.it 80 dell’host www.unitn.it Tutto ciò che digitate viene trasmesso (oppure via putty) alla porta 80 di www.unitn.it 2. Digitate una richiesta GET: GET / HTTP/1.1 Digitando questo (premete due volte Host: www.unitn.it il tasto Invio), trasmettete una richiesta GET minima (ma completa) al server HTTP 3. Guardate il messaggio di risposta trasmesso dal server HTTP! 4. Inviate quanto sotto a gaia.cs.umass.edu: cosa cambia? GET /kurose_ross/interactive/index.php HTTP/1.1 Host: gaia.cs.umass.edu 2-36 Interazione utente-server: i cookie Molti dei più importanti siti web Esempio: usano i cookie ❖ Susan accede sempre a Quattro componenti: Internet dallo stesso PC 1) Una riga di intestazione ❖ Visita per la prima volta un nel messaggio di risposta HTTP particolare sito di 2) Una riga di intestazione nel commercio elettronico messaggio di richiesta HTTP ❖ Quando la richiesta HTTP 3) Un file cookie mantenuto sul iniziale giunge al sito, il sito sistema terminale dell’utente e gestito dal browser dell’utente crea un identificativo unico (ID) e una entry nel 4) Un database sul sito database per ID 2-37 Cookie (continua) Client (Susan) Server ebay 8734 messaggio di richiesta Il server cookie messaggio di risposta + crea l’ID 1678 Set-cookie: 1678 per l’utente ebay 8734 amazon 1678 messaggio di richiesta cookie: 1678 Specifica del cookie messaggio di risposta una settimana dopo: ebay 8734 messaggio di richiesta amazon 1678 Specifica cookie: 1678 del cookie messaggio di risposta 2-38 Cookie (continua) nota Cosa possono contenere i Cookie e privacy: cookie: I cookie permettono ai siti di Autorizzazione imparare molte cose sugli Carta per acquisti utenti Raccomandazioni L’utente può fornire al sito il nome e l’indirizzo e-mail Stato della sessione dell’utente (e-mail) Lo “stato” Mantengono lo stato del mittente e del ricevente per più transazioni I messaggi http trasportano lo stato 2-39 Cache web (server proxy) Obiettivo: soddisfare la richiesta del client senza coinvolgere il server d’origine L’utente configura il Server d’origine browser: accesso al Web tramite la cache Server Il browser trasmette tutte le proxy client richieste HTTP alla cache ❖ Oggetto nella cache: la cache fornisce l’oggetto ❖ Altrimenti la cache richiede l’oggetto al server d’origine e poi lo inoltra al client client Server d’origine 2-40 Cache web (continua) La cache opera come client e Perché il caching web? come server Riduce i tempi di risposta alle Tipicamente la cache è richieste dei client installata da un ISP (università, Riduce il traffico sul aziende o ISP residenziali) collegamento di accesso a Internet Internet arricchita di cache consente ai provider “scadenti” di fornire dati con efficacia (ma così fa anche la condivisione di file P2P) 2-41 Esempio di caching Ipotesi Server Dimensione media di un oggetto = 100.000 bit d’origine Frequenza media di richieste dai browser Internet istituzionali ai server d’origine = 15/secondo pubblica Ritardo dal router istituzionale a qualsiasi server d’origine e ritorno al router = 2 s Conseguenze Intensità di utilizzo della LAN = 15% Collegamento d’accesso Intensità di utilizzo del collegamento d’accesso a 1,5 Mbit/s = 100% Ritardo totale = ritardo di Internet + ritardo di Rete accesso + ritardo della LAN istituzionale LAN a 10 Mbit/s Intensità traffico su LAN: (15 richieste/s) * (0,1 Mbit/richiesta) / (10 Mbit/s) = 0,15 Intensità traffico sul link di accesso: (15 richieste/s) * (0,1 Mbit/richiesta) / (1,5 Mbit/s) = 1 Ritardo = 2 s + minuti + qualche ms Intensità del traffico 2-42 0 1 Esempio di caching (continua) Server Soluzione possibile d’origine Aumentare l’ampiezza di banda del collegamento d’accesso a Internet 10 Mbps, per esempio pubblica Conseguenze Intensità di utilizzo della LAN = 15% Intensità di utilizzo del collegamento di accesso = 15% = 0.15 Collegamento d’accesso a 10 Mbit/s Quindi il ritardo non arriva fino a minuti, al più fino a qualche millisecondo Rete Ritardo totale = ritardo di Internet + istituzionale LAN a 10 Mbit/s ritardo di accesso + ritardo della LAN = 2 s + qualche ms + qualche ms Tuttavia: Cambiare infrastruttura Ritardo è spesso molto costoso Intensità del traffico 2-43 0 1 Esempio di caching (continua) Server Soluzione possibile: installare la cache d’origine Supponiamo una percentuale di successo Internet (hit rate) pari a 40% pubblica Conseguenze Il 40% delle richieste sarà soddisfatto quasi immediatamente (diciamo in 0,01 s) Il 60% delle richieste sarà soddisfatto dal server d’origine Collegamento d’accesso a 1,5 Mbit/s L’utilizzo del collegamento d’accesso si è ridotta al 60%, determinando ritardi Rete trascurabili (circa 10 ms) istituzionale (0,6*15 richieste/s) * (0,1 Mbit/richiesta) / (1,5 LAN a 10 Mbit/s Mbit/s) = 0,6 < 1 → molto meglio! Ritardo totale: 2,01 s (ovvero Internet + 10 ms) Quindi qual è il ritardo medio adesso? Ritardo Cache 0,6*(2,01) s + 0.4*0,01 s = 1,21 s istituzionale Intensità del traffico 2-44 0 1 Supporto HTTP per le cache: GET condizionale Obiettivo: non inviare un oggetto cache server se la cache ha una copia Richiesta HTTP aggiornata dell’oggetto If-modified-since: oggetto Cache: specifica la data non della copia dell’oggetto modificato nella richiesta HTTP Risposta HTTP HTTP/1.0 ❖ If-modified-since: 304 Not Modified Server: la risposta non contiene Richiesta HTTP l’oggetto se la copia nella cache è If-modified-since: aggiornata: oggetto ❖ HTTP/1.0 304 Not modificato Modified Risposta HTTP HTTP/1.0 200 OK 2-45 HTTP/1.0 e HTTP/1.1 2-46 HTTP/2.0 ❑ HTTP/2 rappresenta un’evoluzione di HTTP, cioe’ mantiene i metodi HTTP, i codici di stato e la semantica ❑ Il protocollo è focalizzato sulle prestazioni, specificamente sulla latenza percepita dall’utente e l’utilizzo delle risorse di rete e dei server. ❑ L’obiettivo è utilizzare un’unica connessione dai browser ad un sito web. 2-47 HTTP/2.0 ❑ HTTP/2 si basa su SPDY, protocollo Transport Layer di livello applicazione per trasportare Security contenuti sul web con minima latenza, tramite: ❖ Multiplexing di flussi: supporta un numero illimitato di flussi su una singola connessione TCP (”allunga la connessione” aumentandone l’efficienza) ❖ Priorità delle richieste: il client può inviare quante richieste desidera, assegnando a ciascuna una priorità (evita la congestione) ❖ Compressione dell’header HTTP: diminuisce i byte trasmessi 2-48 Framing binario ❑ Nuovo livello di framing binario, responsabile della modalità di incapsulamento e trasferimento dei messaggi HTTP 2-49 Framing binario ❑ La semantica HTTP è invariata ❑ La codifica in transito è differente ❑ Tutte le comunicazioni HTTP/2 sono suddivise in messaggi e frame più piccoli, ognuno dei quali codificato in formato binario ❑ Sia il client che il server devono utilizzare il nuovo meccanismo di codifica binario per capirsi tra loro: un client HTTP/1.x non comprende un server HTTP/2 e viceversa 2-50 Stream, messaggi e frame ❑ Tutte le comunicazioni vengono eseguite all’interno di una singola connessione TCP che può portare qualsiasi numero di stream bidirezionali di byte ❑ Ogni stream ha un identificativo univoco e le informazioni di priorità opzionali utilizzate per il trasporto di messaggi ❑ Ogni messaggio è un messaggio HTTP logico, come una richiesta o una risposta, che consiste di uno o più frame ❑ Il frame è la più piccola unità di comunicazione che porta un tipo specifico di dati (intestazioni HTTP, payload del messaggio) ❑ I frame di diversi stream possono essere interposti e quindi riassemblati tramite l'identificatore di flusso incorporato nell'intestazione di ciascun frame 2-51 Stream, messaggi e frame 2-52 Multiplexing di richieste e risposte ❑ In HTTP/1.x, se il client desiderava fare più richieste parallele per migliorare le prestazioni, doveva utilizzare più connessioni TCP ❑ Il nuovo livello di framing binario in HTTP/2 rimuove queste limitazioni e consente il multiplexing di richieste e risposte ❑ Il client e il server possono dividere un messaggio HTTP in frame indipendenti, intervallarli e ricomporli all'altro capo 2-53 Priorità degli stream ❑ L'ordine in cui i frame vengono interposti e consegnati sia dal client che dal server influenza le prestazioni ❑ HTTP/2 consente a ciascun stream di avere peso e dipendenza associati: ❖ Ogni stream può avere assegnato un peso intero compreso tra 1 (più leggero) e 256 (più pesante) ❖ Ogni stream può avere una dipendenza esplicita su un altro stream ❑ Il client può costruire e comunicare un "albero di priorità" che esprime come preferirebbe ricevere risposte. A sua volta, il server può utilizzare queste informazioni per dare priorità all'elaborazione dello stream 2-54 Connessione HTTP/2 ❑ HTTP/2 non ha più bisogno di più connessioni TCP per eseguire multiplex di stream in parallelo; ogni stream è suddiviso in molti frame, che possono essere intervallati e gestiti con priorità diverse ❑ Tutte le connessioni HTTP/2 sono persistenti, e si rende necessaria solo una connessione per origine 2-55 Connessione HTTP/2 2-56 Connessione HTTP/2 2-57 Server push ❑ Il server può inviare più risposte per una singola richiesta del client: ❖ Oltre alla risposta alla richiesta originale, il server può inviare risorse aggiuntive senza che il client debba richiederle esplicitamente ❑ Una tipica applicazione web è costituita da decine di risorse, tutte scoperte dal cliente esaminando il documento fornito dal server ❖ Perché non eliminare la latenza supplementare e lasciare che il server invii le risorse associate in anticipo? 2-58 Server push 2-59 Transport Layer Security (TLS) ❑ Protocollo crittografico che permette una comunicazione sicura dalla sorgente al destinatario fornendo: ❖ Autenticazione ❖ Integrità dei dati ❖ Confidenzialità ❑ Il funzionamento del protocollo TLS può essere suddiviso in tre fasi principali: ❖ Negoziazione fra le parti dell'algoritmo da utilizzare ❖ Scambio delle chiavi e autenticazione ❖ Cifratura simmetrica e autenticazione dei messaggi 2-60 HTTPS ❑ Estende HTTP inviando tutte le richieste e risposte attraverso una comunicazione cifrata (tramite TLS) sulla porta 443 ❑ Es., https://www.unitn.it ❖ Il browser capisce automaticamente che deve usare TLS ❖ Inizializza la connessione ❖ Invia richieste criptate e deve decriptare le risposte che riceve ❑ Nota: questo cripta solo le informazioni del protocollo HTTP… ❖ …non gli header dei protocolli inferiori ❖ …quindi le porte TCP usate e gli indirizzi IP usati sono in chiaro ❑ Recentemente, > 50-70% dei siti usa HTTPS (fonte: Wikipedia) 2-61 La «S» aumenta il ritardo di connessione ❑ L’inizializzazione di una sessione TLS richiede tempo ❑ 2 RTT ❑ +1 RTT per stabilire una connessione TCP ❑ Soluzione: protocolli più moderni (HTTP/3, QUIC) ❖ Capitolo 3 sul livello di trasporto 2-62 Capitolo 2: Livello applicazione 2.1 Principi delle 2.6 Applicazioni P2P applicazioni di rete 2.7 Cloud computing 2.2 Web e HTTP 2.8 Programmazione delle 2.3 FTP socket (cenni) 2.4 Posta elettronica ❖ SMTP, POP3, IMAP 2.5 DNS 2-63 FTP: file transfer protocol Interfaccia Client Trasferimento file Server utente FTP FTP FTP utente File system locale File system remoto Trasferimento file a/da un host remoto Modello client/server ❖ client: il lato che inizia il trasferimento (a/da un host remoto) ❖ server: host remoto FTP: definito nell’RFC 959 Server FTP: porta 21 2-64 FTP: connessione di controllo, connessione dati Porta 21 per la connessione Il client FTP contatta il server FTP di controllo TCP alla porta 21, specificando TCP come protocollo di trasporto Porta 20 per la Il client ottiene l’autorizzazione Client connessione dati TCP Server sulla connessione di controllo FTP FTP Il client cambia la directory remota inviando i comandi sulla Il server apre una seconda connessione di controllo connessione dati TCP per trasferire un Quando il server riceve un altro file. comando per trasferire un file, Connessione di controllo: apre una connessione dati TCP “fuori banda” (out-of-band) con il client Il server FTP mantiene lo “stato”: Dopo il trasferimento di un file, il directory corrente, autenticazione server chiude la connessione precedente 2-65 Comandi e risposte FTP Comandi comuni: Codici di ritorno comuni: Inviati come testo ASCII sulla Codice di stato ed espressione connessione di controllo (come in HTTP) USER username 331 Username OK, PASS password password required LIST 125 data connection elenca i file della already open; transfer directory corrente starting RETR filename 425 Can’t open data recupera (get) un file connection dalla directory corrente 452 Error writing file STOR filename memorizza (put) un file nell’host remoto 2-66 Capitolo 2: Livello applicazione 2.1 Principi delle 2.6 Applicazioni P2P applicazioni di rete 2.7 Cloud computing 2.2 Web e HTTP 2.8 Programmazione delle 2.3 FTP socket (cenni) 2.4 Posta elettronica ❖ SMTP, POP3, IMAP 2.5 DNS 2-67 Posta elettronica Coda di messaggi in uscita casella di posta dell’utente Tre componenti principali: agente utente Agente utente server agente Server di posta di posta utente Simple mail transfer protocol: SMTP SMTP server di posta Agente utente agente Detto anche “mail reader” SMTP utente Composizione, editing, lettura dei messaggi SMTP server agente di posta elettronica utente di posta Esempi: Eudora, Outlook, elm, Mozilla, Thunderbird I messaggi in uscita o in arrivo agente sono memorizzati utente agente sul server utente 2-68 Posta elettronica: server di posta Server di posta agente utente Casella di posta (mailbox) server contiene i messaggi in arrivo per di posta agente l’utente utente Coda di messaggi da trasmettere SMTP server Protocollo SMTP tra server di di posta agente posta per inviare messaggi di SMTP utente posta elettronica ❖ Client: server di posta SMTP trasmittente agente server utente ❖ "Server”: server di posta di posta ricevente agente utente agente utente 2-69 Posta elettronica: SMTP [RFC 2821] Usa TCP per trasferire in modo affidabile i messaggi di posta elettronica dal client al server, porta 25 Trasferimento diretto: dal server SMTP trasmittente al server SMTP ricevente Tre fasi per il trasferimento ❖ handshaking (saluto) ❖ trasferimento di messaggi ❖ chiusura Interazione comando/risposta ❖ comandi: testo ASCII ❖ risposta: codice di stato ed espressione I messaggi devono essere nel formato ASCII a 7 bit 2-70 Codici ASCII a 7 bit 2-71 Scenario: Alice invia un messaggio a Bob 1) Alice usa il suo agente utente 4) Il client SMTP invia il messaggio per comporre il messaggio da di Alice sulla connessione TCP inviare a [email protected] 5) Il server di posta di Bob pone il messaggio nella casella di posta 2) L’agente utente di Alice invia un messaggio al di Bob server di posta di Alice; 6) Bob invoca il suo agente utente il messaggio è posto nella coda per leggere il messaggio di messaggi 3) Il lato client di SMTP apre una connessione TCP con il server di posta di Bob 1 server server agente di posta di posta agente utente 2 3 6 utente 4 5 2-72 SMTP: note finali SMTP usa connessioni Confronto con HTTP: persistenti HTTP: pull SMTP richiede che il messaggio SMTP: push (intestazione e corpo) sia nel formato Entrambi hanno un’interazione ASCII a 7 bit comando/risposta Il server SMTP usa in ASCII, codici di stato. HTTP: ciascun oggetto è per determinare la fine incapsulato nel suo messaggio del messaggio di risposta SMTP: più oggetti vengono trasmessi in un unico messaggio 2-73 Formato dei messaggi di posta elettronica SMTP: protocollo per scambiare messaggi di posta elettronica intestazione RFC 822: standard per il formato dei riga messaggi di testo: vuota Righe di intestazione, per esempio ❖ From/Da: ❖ To/A: corpo ❖ Subject/Oggetto: *** Diversi dai comandi SMTP ! *** Riga vuota Corpo ❖ il “messaggio”, soltanto caratteri ASCII 2-74 Esempio di interazione SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 [email protected]... Sender ok C: RCPT TO: S: 250 [email protected]... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C:. S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection 2-75 Provate un’interazione SMTP: Aprite una connessione con il server, ad esempio usate: telnet servername 25 (Linux) oppure rlwrap nc -C servername 25 (Linux) oppure usando l’applicazione putty (Windows) Riceverete la risposta con codice 220 dal server Digitate i comandi HELO, MAIL FROM, RCPT TO, DATA, QUIT Ricordate di inserire i campi intestazione (From: / To: / Subject:), poi una linea vuota, poi il corpo del messaggio Questo vi consente di inviare messaggi di posta elettronica anche senza usare un client per la posta elettronica Altri comandi: https://blog.mailtrap.io/smtp-commands-and-responses/ Per chi vuole far girare il container docker con il server SMTP (comandi Linux): sudo docker pull reachfive/fake-smtp-server sudo docker run --name fake-smtp -p 1080:1080 -p 1025:1025 reachfive/fake-smtp-server 2-76 Formato del messaggio: estensioni di messaggi multimediali MIME: estensioni di messaggi di posta multimediali, RFC 2045, 2056 Alcune righe aggiuntive nell’intestazione dei messaggi dichiarano il tipo di contenuto MIME Versione MIME From: [email protected] To: [email protected] metodo usato Subject: Picture of yummy crepe. per codificare i dati MIME-Version: 1.0 Content-Transfer-Encoding: base64 Tipo di dati Content-Type: image/jpeg multimediali, sottotipo, dichiarazione base64 encoded data..... dei parametri...............................base64 encoded data Dati codificati 2-77 Codifica base-64 Inefficiente per definizione: ogni gruppo di 6 bit viene codificato usando 8 bit 2-78 Un esempio reale Date: Fri, 19 May 2000 10:23:16 -0400 (EDT) From: Doug Sauder To: =?iso-8859-1?Q?Heinz_M=FCller?= Subject: PNG graphic Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463757054-170444605-958746196=:8452" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to [email protected] for more info. ---1463757054-170444605-958746196=:8452 Content-Type: TEXT/PLAIN; charset=US-ASCII ---1463757054-170444605-958746196=:8452 Content-Type: APPLICATION/octet-stream; name="redball.png" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: red ball Content-Disposition: attachment; filename="redball.png" iVBORw0KGgoAAAANSUhEUgAAABsAAAAbCAMAAAC6CgRnAAADAFBMVEX///8A AAABAAALAAAVAAAaAAAXAAARAAAKAAADAAAcAAAyAABEAABNAABIAAA9AAAj AAAWAAAmAABhAAB7AACGAACHAAB9AAB0AABgAAA5AAAUAAAGAAAnAABLAABv AACQAAClAAC7AAC/AACrAAChAACMAABzAABbAAAuAAAIAABMAAB3AACZAAC0 GRnKODjVPT3bKSndBQW4AACoAAB5AAAxAAAYAAAEAABFAACaAAC7JCTRYWHf hITmf3/mVlbqHx/SAAC5AACjAABdAABCAAAoAAAJAABnAAC6Dw/QVFTek5Pl rKzpmZntZWXvJSXXAADBAACxAACcAABtAABTAAA2AAAbAAAFAABKAACBAADL ICDdZ2fonJzrpqbtiorvUVHvFBTRAADDAAC2AAB4AABeAABAAAAiAABXAACS AADCAADaGxvoVVXseHjveHjvV1fvJibhAADOAAC3AACnAACVAABHAAArAAAP AACdAADFAADhBQXrKCjvPDzvNTXvGxvjAADQAADJAAC1AACXAACEAABsAABP Provate a copiare e incollare AAASAAACAABiAADpAADvAgLnAADYAADLAAC6AACwAABwAAATAAAkAABYAADI AADTAADNAACzAACDAABuAAAeAAB+AADAAACkAACNAAB/AABpAABQAAAwAACR AACpAAC8AACqAACbAABlAABJAAAqAAAOAAA0AACsAACvAACtAACmAACJAAB6 AABrAABaAAA+AAApAABqAACCAACfAACeAACWAACPAAB8AAAZAAAHAABVAACO AACKAAA4AAAQAAA/AAByAACAAABcAAA3AAAsAABmAABDAABWAAAgAAAzAAA8 in un file di testo, e a riconvertire AAA6AAAfAAAMAAAdAAANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD8 LtlFAAAAAXRSTlMAQObYZgAAABZ0RVh0U29mdHdhcmUAZ2lmMnBuZyAyLjAu il contenuto dalla codifica MT1evmgAAAIISURBVHicY2CAg/8QwIABmJhZWFnZ2Dk4MaU5uLh5eHn5+LkF BDlQJf8zC/EIi4iKiUtI8koJScsgyf5nlpWTV1BUUlZRVVPX4NFk1UJIyghp 6+jq6RsYGhmbKJgK85mZW8Dk/rNaSlhZ29ja2Ts4Ojkr6Li4urFDNf53N/Ow 8vTy9vH18w8IDAoWDQkNC4+ASP5ni4wKio6JjYtPSExKTnFWSE1LF4A69n9G base64 a un file di nome ZlZ2Tm5efkFhUXFySWlZlEd5RSVY7j+TkGRVdU1tXX1DY1Ozcktpa1t7h2Yn OAj+d7l1tyo79vT29SdNSJ44SbFVdHIo9xSIHNPUaWqTpifNSJrZnK00S0U1 a/acUG5piNz/uXLzVJ2qm6dXz584S2WB1cJFi5cshZr539xVftnyFKUVTi2T VjqvyhJLXb1m7TqoHPt6F/HW0g0bN63crGqVtWXrtu07BJihcsw71+zanRW8 Z89eq337RQ/Ip60xO3gIElX/LbikDm8T36KwbNmRo7O3zpHkPSZwHBqL//8f “redball.png” lz1x2OOkyKJTi7aqbzutfUZI2gIuF8F2lr/D5dw2+fZdwpl8YVOlI+CJ4/9/ joOyYed5QzMvhGqnm2V0WiClm///D0lfXHtJ6vLlK9w7rx7vQk5SQJbFtSms 1y9evXid7QZacgOxmSxktNzdtSwwU+J/VICaCPFIYU3XAJhIOtjf5sfyAAAA JXRFWHRDb21tZW50AGNsaXAyZ2lmIHYuMC42IGJ5IFl2ZXMgUGlndWV0NnM7 vAAAAABJRU5ErkJggg== ---1463757054-170444605-958746196=:8452-- 2-79 Protocolli di accesso alla posta SMTP SMTP protocollo agente agente di accesso utente utente Server di posta Server di posta del mittente del destinatario SMTP: consegna/memorizzazione sul server del destinatario Protocollo di accesso alla posta: ottenere i messaggi dal server ❖ POP: Post Office Protocol [RFC 1939] Autorizzazione (agente → server) e download ❖ IMAP: Internet Mail Access Protocol [RFC 1730] Più funzioni (più complesse) Manipolazione di messaggi memorizzati sul server ❖ HTTP: gmail, Hotmail , Yahoo! Mail, ecc. 2-80 Protocollo POP3 S: +OK POP3 server ready C: user rob Fase di autorizzazione S: +OK Comandi del client: C: pass hungry S: +OK user successfully logged on ❖ user: dichiara il nome dell’utente C C: list ❖ pass: password S: 1 498 Risposte del server S: 2 912 ❖ +OK S:. ❖ -ERR C: retr 1 S: Fase di transazione, client: S:. list: elenca i numeri C: dele 1 dei messaggi C: retr 2 retr: ottiene i messaggi S: in base al numero S:. dele: cancella C: dele 2 quit C: quit S: +OK POP3 server signing off 2-81 POP3 (altro) e IMAP Ancora su POP3 IMAP Il precedente esempio usa la Mantiene tutti i messaggi in un modalità “scarica e cancella” unico posto: il server Bob non può rileggere Consente all’utente di le e-mail se cambia client organizzare i messaggi in Modalità “scarica e mantieni”: cartelle copia i messaggi su più client IMAP conserva lo stato POP3 è un protocollo senza dell’utente tra le varie sessioni: stato tra le varie sessioni ❖ I nomi delle cartelle e l’associazione tra identificatori dei messaggi e nomi delle cartelle 2-82 SMTP e Transport Layer Security (TLS) ❑ Per garantire la sicurezza della comunicazione, si può usare SMTP insieme a TLS ❑ Le comunicazioni non possono avvenire su porte di comunicazione ove è in ascolto un server di posta che non usa la crittografia ❑ Sono pertanto utilizzate porte diverse: ❖ SMTP con SSL/TLS su porta 465 ❖ POP3 con SSL/TLS su porta 995 ❖ IMAP con SSL/TLS su porta 993 2-83 STARTTLS ❑ Evoluzione di TLS ❑ Consente di cifrare la connessione anche sulle porte originali o standard (110 per POP3, 143 per IMAP, 25 per SMTP) ❑ Il client che sfrutta tale protocollo: ❖ Chiede in prima istanza al server l'instaurazione di una connessione cifrata ❖ La sessione inizia «in chiaro» ❖ Quindi diventa cifrata prima che venga trasmessa qualunque informazione sensibile o potenzialmente tale ❑ Viene spesso impiegato tra MTA (Mail Transfer Agent) ovvero durante il trasporto dell'email da un provider all'altro 2-84 Capitolo 2: Livello applicazione 2.1 Principi delle 2.6 Applicazioni P2P applicazioni di rete 2.7 Cloud computing 2.2 Web e HTTP 2.8 Programmazione delle 2.3 FTP socket (cenni) 2.4 Posta elettronica ❖ SMTP, POP3, IMAP 2.5 DNS 2-85 DNS: Domain Name System Persone: molti identificatori: Domain Name System: ❖ Nome, codice fiscale, Database distribuito implementato numero della carta d’identità in una gerarchia di server DNS Host e router di Internet: Protocollo a livello di applicazione che consente agli host, ai router e ❖ Indirizzo IP (32 bit) - usato per ai server DNS di comunicare per indirizzare i datagrammi risolvere i nomi (tradurre ❖ Es. 121.7.106.83 indirizzi/nomi) ❖ Ogni campo compreso tra 0 e 255 ❖ Si noti: funzioni critiche di Internet (8 bit per campo, in totale 32 bit) implementate come protocollo a ❖ “Nome”, ad esempio, livello di applicazione www.yahoo.com – usato ❖ Complessità nelle parti periferiche dagli esseri umani della rete D: Come associare un indirizzo IP ad un nome? 2-86 DNS Servizi DNS Perché non centralizzare DNS? Traduzione degli hostname in Singolo punto di guasto indirizzi IP Volume di traffico Host aliasing Database centralizzato ❖ Un host può avere più nomi distante ❖ Es. relay1.west.enterprise.com Manutenzione → www.enterprise.com Mail server aliasing Un database centralizzato Distribuzione del carico su un singolo server DNS ❖ Server web replicati: insieme di non è scalabile ! indirizzi IP raggruppati sotto lo stesso nome canonico 2-87 Database distribuiti e gerarchici Server DNS radice Server DNS com Server DNS org Server DNS edu Server DNS Server DNS Server DNS Server DNS Server DNS di yahoo.com di amazon.com di pbs.org di poly.edu di umass.edu Il client cerca l’IP di www.amazon.com Semplificando, succede che: ❑ Il client chiede al root server di trovare il DNS server del dominio.com ❑ Il client chiede al server DNS.com di trovare il server DNS di amazon.com ❑ Infine il client chiede al server DNS di amazon.com di restituirgli l’indirizzo IP del server www in quel dominio, cioè www.amazon.com 2-88 DNS: server DNS radice Contattato da un server DNS locale che non può tradurre il nome Server DNS radice: ❖ contatta un server DNS autorizzato se non conosce la mappatura ❖ ottiene la mappatura ❖ restituisce la mappatura al server DNS locale a Verisign, Dulles, VA c Cogent, Herndon, VA (e Los Angeles) d U Maryland College Park, MD k RIPE Londra (anche Amsterdam e Francoforte) g US DoD Vienna, VA h ARL Aberdeen, MD i Autonomica, Stoccolma (più altre 3 posizioni) j Verisign, ( 11 locazioni) m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto , CA (e altre 17 locazioni) 13 server DNS radice «logici» nel mondo b USC-ISI Marina del Rey, CA (ciascuno con diverse l ICANN Los Angeles, CA repliche nel mondo) 2-89 DNS: server DNS radice Mappa delle istanze DNS radice: https://root-servers.org/ Concetto di anycasting (https://it.wikipedia.org/wiki/Anycast) 2-90 Server TLD e server di competenza Server TLD (top-level domain): Si occupano dei domini com, org, net, edu, ecc. e di tutti i domini locali di alto livello, quali it, uk, fr, ca e jp Network Solutions gestisce i server TLD per il dominio com Educause gestisce quelli per il dominio edu Server di competenza (authoritative server) Ogni organizzazione dotata di host Internet pubblicamente accessibili (quali i server web e i server di posta) deve fornire i record DNS di pubblico dominio che mappano i nomi di tali host in indirizzi IP Possono essere mantenuti dall’organizzazione o dal service provider 2-91 Server DNS locale Non appartiene strettamente alla gerarchia dei server Ciascun ISP (università, società, ISP residenziale) ha un server DNS locale ❖ Detto anche “default name server” Quando un host effettua una richiesta DNS, la query viene inviata al suo server DNS locale ❖ Il server DNS locale opera da proxy e inoltra la query in una gerarchia di server DNS 2-92 Server DNS radice Esempio 2 L’host cis.poly.edu 3 Server DNS TLD vuole l’indirizzo IP di 4 gaia.cs.umass.edu 5 Query iterativa: Il server contattato Server DNS locale dns.poly.edu risponde con il nome del 6 7 server da contattare 1 8 8 MESSAGGI “Io non conosco questo Server DNS di competenza dns.cs.umass.edu nome, ma puoi Host richiedente cis.poly.edu chiederlo a questo server” gaia.cs.umass.edu 2-93 Esempio Server DNS radice Query ricorsiva: 2 3 Affida il compito di tradurre il nome al server 7 6 DNS contattato Server DNS TLD D: E’ più efficiente questa maniera o la precedente? Server DNS locale dns.poly.edu 5 4 1 8 Server DNS di competenza dns.cs.umass.edu Host richiedente cis.poly.edu gaia.cs.umass.edu 2-94 DNS: caching e aggiornamento dei record Una volta che un server DNS impara la mappatura, la mette nella cache ❖ le informazioni nella cache vengono invalidate (spariscono) dopo un certo periodo di tempo ❖ tipicamente un server DNS locale memorizza nella cache gli indirizzi IP dei server TLD quindi i server DNS radice non vengono visitati spesso I meccanismi di aggiornamento/notifica sono progettati da IETF ❖ RFC 2136 ❖ http://www.ietf.org/html.charters/dnsind-charter.html D: Quali problemi possono sorgere abilitando una cache DNS? 2-95 E se i DNS radice falliscono? ❑ MOLTO difficile che succeda ❖ Infrastruttura estremamente ridondata ❖ Gli indirizzi IP dei server TLD sono cached quasi ovunque ❑ Attacco Distributed Denial-of-Service (DDoS) di ottobre 2002 ❖ Molto massiccio ❖ …ma del tutto inefficace (gli utenti quasi non se ne sono accorti) ❑ Attacchi più mirati hanno maggiori probabilità di successo ❖ Attacco al DNS locale → impedisce l’accesso al DNS ❖ Attacco al DNS autoritativo → impedisce l’accesso al dominio 2-96 Resource Record (RR) nel DNS DNS: database distribuito che memorizza i record di risorsa (RR) Formato RR: (name, value, type, ttl) Type=A Type=CNAME ❖ Associazione standard tra ❖ name è il nome alias di qualche nome dell’host e indirizzo IP nome “canonico” (nome vero) ❖ name è il nome dell’host www.ibm.com è in realtà ❖ value è l’indirizzo IP servereast.backup2.ibm.com ❖ value è il nome canonico Type=NS ❖ name è il dominio (ad esempio foo.com) Type=MX ❖ value è il nome dell’host del ❖ value è il nome del server di server di competenza di posta associato a name questo dominio 2-97 DNS Types 2-98 Messaggi DNS Protocollo DNS: domande (query) e messaggi di risposta, entrambi con lo stesso formato Intestazione del messaggio Identificazione: numero di 16 bit per la domanda; la risposta alla domanda usa lo stesso numero Flag: ❖ domanda o risposta ❖ richiesta di ricorsione ❖ ricorsione disponibile ❖ risposta di competenza 2-99 Messaggi DNS Campi per il nome richiesto e il tipo di domanda RR nella risposta alla domanda Record per i server di competenza Informazioni extra che possono essere usate 2-100 Inserire record nel database DNS Esempio: abbiamo appena avviato la nuova società “Network Utopia” Registriamo il nome networkutopia.com presso un registrar (ad esempio, Network Solutions) Registrar: società che controlla l’unicità del nome, lo inserisce nel database DNS come sotto, e vi tariffa un prezzo per il servizio ❖ Forniamo al registrar i nomi e gli indirizzi IP dei server DNS di competenza (primario e secondario) ❖ Registrar inserisce due RR nel server TLD per il dominio com: ❖ (networkutopia.com, dns1.networkutopia.com, NS) ❖ (dns1.networkutopia.com, 212.212.212.1, A) Inseriamo nel server di competenza un record tipo A per www.networkutopia.com e un record tipo MX per networkutopia.com In che modo gli utenti otterranno l’indirizzo IP del nostro sito web? 2-101 Cosa succede quando si cerca di accedere a www.networkutopia.com ❑ Es. un utente in Australia vuol vedere www.networkutopia.com 1. Query al server DNS locale 2. Il DNS locale contatta il server TLD del dominio com (e anche un root server se il server TLD di com non è in cache) 3. Il server TLD trova il record (precedentemente inserito dal registrar) 4. Il server TLD risponde con il record al DNS locale 5. Il DNS locale manda query a 212.212.212.1 chiedendo il record Type A corrispondente a www.networkutopia.com 6. Il DNS locale manda la risposta ad Alice, diciamo 212.212.71.4 7. Alice può finalmente aprire una connessione HTTP verso 212.212.71.4 (aka www.networkutopia.com) e scaricare la pagina 2-102 Capitolo 2: Livello applicazione 2.1 Principi delle 2.6 Condivisione di file P2P applicazioni di rete 2.7 Cloud computing 2.2 Web e HTTP 2.8 Programmazione delle 2.3 FTP socket (cenni) 2.4 Posta elettronica ❖ SMTP, POP3, IMAP 2.5 DNS 2-103 Architettura P2P pura Non c’è un server sempre attivo Coppie arbitrarie di host (peer) comunicano direttamente tra loro I peer non devono peer to peer necessariamente essere sempre attivi, e cambiano indirizzo IP Tre argomenti chiave: Distribuzione di file Ricerca informazioni Caso di studio: Skype 2-104 Distribuzione di file: confronto tra Server-Client e P2P Domanda : Quanto tempo ci vuole per distribuire file da un server a N peer? us : bit rate di upload del File di collegamento di accesso del dimensione F Server server ui : bit rate di upload del u2 collegamento di accesso dell’i- u1 d1 esimo peer us d2 di : bit rate di download del collegamento di accesso dell’i- esimo peer dN Rete (con abbondante ampiezza di banda) uN 2-105 Distribuzione di file: server-client Server Il server invia in sequenza F u1 d1 u2 N copie: us d2 ❖ Tempo = NF/us dN Rete (con abbondante Il client i impiega il tempo ampiezza di banda) F/di per scaricare uN Tempo per distribuire F a N client usando = dcs = max { NF/us , F/min (di ) } l’approccio client/server i aumenta linearmente con N peer 2-106 Distribuzione di file: P2P Server il server deve inviare una copia nel tempo F/us F u1 d1 u2 us d2 il client i impiega un tempo F/di per il download dN Rete (con abbondante Devono essere scaricati NF bit ampiezza di banda) uN Il più veloce tasso di upload è: us + i ui dP2P = max { F/us , F/min(di ) , NF/(us + i ui) } i 2-107 Confronto tra server-client e P2P: un esempio Tasso di upload del client = u, F/u = 1 ora, us = 10u, min( di ) ≥ us i 3.5 P2P Time 3 minimo Client-Server Distribution 2.5 empo di distribuzione 2 1.5 TMinimum 1 0.5 0 0 5 10 15 20 25 30 35 N 2-108 Distribuzione di file: BitTorrent 2-109 Distribuzione di file: BitTorrent Distribuzione di file P2P tracker: tiene traccia dei peer torrent: gruppo di peer che partecipano che si scambiano parti di un file Ottiene la lista dei peer Scambi delle parti del file peer 2-110 BitTorrent (1) Il file viene diviso in parti (chunk), tipicamente da 256 kByte Quando un peer entra a far parte del torrent: ❖ non possiede nessuna parte del file, ma le accumula col passare del tempo ❖ si registra presso il tracker per avere la lista dei peer, e si collega ad un sottoinsieme di peer vicini (neighbors) Mentre effettua il download, il peer carica le sue parti su altri peer I peer possono entrare e uscire a piacimento dal torrent Una volta ottenuto l’intero file, il peer può lasciare il torrent (egoisticamente, leech) o rimanere collegato (altruisticamente, seeder) 2-111 BitTorrent (2) Alice invia le sue parti a quattro vicini, quelli che attualmente le stanno inviando i propri chunk alla In un dato istante, peer diversi frequenza più alta hanno differenti sottoinsiemi del (peer «non soffocati», o unchoked) file ❖ I 4 favoriti vengono rivalutati Periodicamente, un peer (Alice) ogni 10 secondi chiede a ciascun vicino la lista dei chunk che possiede Ogni 30 secondi, Alice seleziona casualmente un altro peer, Alice invia le richieste per le sue e inizia a inviargli chunk parti mancanti: (optimistically unchoked) ❖ Adotta la tecnica del ❖ Il peer appena scelto può rarest first entrare a far parte dei top 4 ❖ A parte i “top 4” e il “nuovo entrato”, gli altri peer sono “soffocati” (choked), cioè non ricevono nulla 2-112 BitTorrent: occhio per occhio (tit for tat) (1) Alice casualmente sceglie Bob (2) Alice diventa uno dei quattro fornitori preferiti di Bob → Bob ricambia (3) Bob diventa uno dei quattro fornitori preferiti di Alice Con un’elevata frequenza di upload, è possibile trovare i partner migliori e ottenere il file più velocemente 2-113 P2P: ricerca di informazioni Indice nei sistemi P2P: corrispondenza tra le informazioni e la loro posizione negli host, di solito è una Distributed Hash Table File sharing (es. e-mule) Messaggeria istantanea L’indice tiene traccia L’indice crea la dinamicamente della corrispondenza tra utenti e posizione dei file che i peer posizione. condividono. Quando l’utente lancia I peer comunicano all’indice l’applicazione, informa ciò che possiedono. l’indice della sua posizione I peer consultano l’indice per I peer consultano l’indice per determinare dove trovare i determinare l’indirizzo IP file. dell’utente. 2-114 P2P: directory centralizzata Bob Progetto originale di “Napster” Server di directory 1) quando il peer centralizzato 1 si collega, informa peer il server centrale: 1 ❖ indirizzo IP 1 3 ❖ contenuto 2 1 2) Alice cerca la canzone Hey Jude “Hey Jude” Hey Jude 3) Il server informa Alice che Bob possiede il file Alice 4) Alice richiede il file a Bob 2-115 P2P: problemi con la directory centralizzata Unico punto di guasto Il trasferimento dei file è distribuito, ma il processo Collo di bottiglia di localizzazione è fortemente per le prestazioni centralizzato Violazione del diritto d’autore 2-116 Query flooding Completamente distribuito Rete di copertura ❖ Nessun server centrale (overlay network): grafo Protocollo di pubblico Arco tra i peer X e Y se c’è dominio usato da Gnutella una connessione TCP Ciascun peer indicizza i file Tutti i peer attivi e gli archi che rende disponibili per la formano la rete di copertura condivisione (e nasconde Un arco è un collegamento ogni altro file) virtuale e non fisico Un dato peer sarà solitamente connesso con meno di 10 peer vicini nella rete di copertura 2-117 Query flooding Il messaggio di Trasferimento file: richiesta è HTTP trasmesso sulle connessioni TCP esistenti Query Il peer inoltra Successo il messaggio di richiesta Il messaggio di successo è trasmesso sul Query percorso Query inverso Query Scalabilità: query flooding a raggio limitato 2-118 Copertura gerarchica La copertura gerarchica combina le migliori caratteristiche di un indice centralizzato e del query flooding Ogni peer è un leader di gruppo o è assegnato a un leader di gruppo ❖ Connessione TCP tra peer e il suo leader di gruppo ❖ Connessioni TCP tra qualche coppia di leader di gruppo Il leader di gruppo tiene traccia Peer ordinario del contenuto di tutti i propri figli Peer leader di gruppo Relazioni di adiacenza nella rete di copertura 2-119 Esempio di sistema ibrido: Skype Skype client (SC) Intrinsecamente P2P: coppie di utenti comunicano tra loro Protocollo proprietario Skype Supernodo (dedotto mediante login server reverse engineering) (SN) Copertura gerarchica con i supernodi L’indice crea corrispondenza tra nomi utente e indirizzi IP 2-120 Capitolo 2: Livello applicazione 2.1 Principi delle 2.6 Condivisione di file P2P applicazioni di rete 2.7 Cloud computing 2.2 Web e HTTP 2.8 Programmazione delle 2.3 FTP socket (cenni) 2.4 Posta elettronica ❖ SMTP, POP3, IMAP 2.5 DNS 2-122 Cloud computing Il cloud computing prevede uno o più server reali, generalmente organizzati in un’architettura ad alta affidabilità e fisicamente collocati presso il data center del fornitore del servizio Il fornitore di servizi espone delle interfacce per elencare e gestire i propri servizi Il cliente amministratore utilizza tali interfacce per selezionare il servizio richiesto (ad es. un server virtuale completo oppure solo storage) e per amministrarlo (configurazione, attivazione, disattivazione) Il cliente finale utilizza il servizio configurato dal cliente amministratore 2-123 Cloud computing Le caratteristiche fisiche dell'implementazione (server reale, localizzazione del data center) sono irrilevanti Criticità: Sicurezza e privacy Problemi internazionali di natura economica e politica Continuità del servizio offerto Difficoltà di migrazione dei dati https://www.reddit.com/r/mildlyinteresting/comments/20jlv3/never_underestimate_the_bandwidth_of_a_station/ La «banda» di FedEx: https://what-if.xkcd.com/31/ 2-124 Cloud computing Dove si trovano i data center? Source: http://www.vox.com/ 2-125 Cloud computing Dove si trovano i data center (Amazon)? 2-126 Source: getcodelove.com Cloud computing Scales to over 10,000 servers 8-way Come è fatto un data center dal punto di vista architetturale? ECM Core Network Aggregation Network Access Network S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S Links Nodes 10 GE 1 GE L3 Switch L2/L3 Rack Switch Computing Server S 2-127 I data center di Google (dati 2016) ❑ 14 “mega data-centers” (8 in nord america, 4 in europa, 4 in asia) ❖ Circa 100.000 server per data center ❖ Servono contenuti dinamici e personalizzati (ad, ricerche, gmail) ❑ Circa 50 cluster di calcolo “bring home” negli IXP ❖ 100-500 server per cluster ❖ Servono contenuti statici, inclusi i video Youtube ❑ Centinaia di cluster “enter-deep” nelle reti di accesso degli ISP ❖ In ogni cluster: 1 rack, qualche decina di server ❖ Servono contenuti statici (es., le parti statiche delle pagine di risposta alle ricerche) Inoltre permettono il TCP splitting (ask me about it later) 2-128 Content Delivery Networks (CDN) ❑ Le Content Delivery Network (CDN) rappresentano una soluzione comune per la realizzazione di servizi su Internet ❑ Una CDN costruisce una rete “overlay” per la distribuzione di contenuti (social media, video, etc.) ❑ Il concetto è memorizzare i dati il più vicino possibile ai consumatori in modo da: ❖ Ottimizzare le prestazioni di rete ❖ Ridurre la latenza ❖ Evitare i colli di bottiglia ❑ Due diverse filosofie: ❖ Enter deep (es. Akamai): installare i server nelle reti degli ISP in tutto il mondo: migliora ritardo e throughput percepiti dagli utenti ❖ Bring home (es. Limelight): meno server, ma installati negli IXP per poter servire le reti di più ISP contemporaneamente con la stessa infrastruttura 2-131 Content Delivery Networks (CDN) 2-132 Content Delivery Networks (CDN) ❑ Esempio: Facebook ha la propria CDN ❑ Aprite una pagina di Facebook ed esamina l’html ❑ Troverete riferimenti a fbcdn.net, che è la CDN di Facebook ❑ Per scoprire dove si trova il nodo che vi serve i contenuti: ❖ Inviate il comando “ping www.fbcdn.net” e otterrete l’indirizzo IP di un nodo della CDN ❖ Localizzate geograficamente l’indirizzo IP Google “where is IP xx.xx.xx.xx?” 2-133 Capitolo 2: Livello applicazione 2.1 Principi delle 2.6 Applicazioni P2P applicazioni di rete 2.7 Cloud computing 2.2 Web e HTTP 2.8 Programmazione delle 2.3 FTP socket (cenni) 2.4 Posta elettronica ❖ SMTP, POP3, IMAP 2.5 DNS 2-138 Programmazione delle socket Obiettivo: imparare a costruire un’applicazione client/server che comunica utilizzando le socket Socket API socket Introdotta in BSD4.1 UNIX, nel 1981 Esplicitamente creata, usata, distribuita Interfaccia di un dalle applicazioni host locale, Esistono diversi tipi di socket creata dalle applicazioni, ❖ DARPA Internet Address (Internet controllata dal SO Socket) (una “porta”) in cui ❖ Unix Socket il processo di un’applicazione può ❖ Indirizzi X.25 (X.25 Socket) Paradigma client/server inviare e ricevere Due tipi di servizio di trasporto tramite messaggi al/dal processo di una socket API: un’altra applicazione ❖ Datagramma inaffidabile ❖ Affidabile, orientata ai byte 2-139 Programmazione delle socket con TCP Socket: una porta tra il processo di un’applicazione e il protocollo di trasporto end-end (UDP o TCP) Servizio TCP: trasferimento affidabile di byte da un processo all’altro, detto anche stream socket (SOCK_STREAM) Controllato dallo Controllato dallo processo sviluppatore sviluppatore processo dell’applicazione dell’applicazione socket socket TCP con TCP con Controllato dal Controllato dal buffer e sistema operativo buffer e Internet sistema operativo variabili variabili host o host o server server 2-140 Programmazione delle socket con TCP Il client deve contattare il server Quando viene contattato dal Il processo server deve essere client, il server TCP crea una nuova in esecuzione socket per il processo server per comunicare con il client Il server deve avere creato una socket (porta) che dà il ❖ consente al server di benvenuto al contatto con il comunicare con più client client ❖ numeri di porta origine usati per distinguere i client Il client contatta il server: (maggiori informazioni Creando una socket TCP nel Capitolo 3) Specificando l’indirizzo IP e il numero di porta del processo server Quando il client crea la socket: Punto di vista dell’applicazione il client TCP stabilisce una TCP fornisce un trasferimento di connessione con il server TCP byte affidabile e ordinato (“pipe”) tra client e server 2-141 Interazione delle socket client/server: TCP Server (gira su hostid) Client Creazione del socket Associazione ad un porta