Telecomunicazioni Top-Down

Strato di applicazione

Martedì 4 ottobre 2022 13:00

Architettura alla pari

• Non c'è un processo che è unicamente server o unicamente client
• Non esiste un server sempre attivo
• Coppie di host (peer) comunicano direttamente tra loro
• I peer non devono necessariamente essere sempre attivi e possono cambiare indirizzo IP
• Facilmente scalabile
• Difficile da gestire
• Un processo è programma in esecuzione su di un host
• All’interno dello stesso host, due processi comunicano utilizzando schemi inter-processo definiti dal Sistema Operativo
• Processi su host differenti comunicano attraverso la rete mediante lo scambio di messaggi
• Ci sono due tipi di processo:
  • Processo client: dà inizio alla comunicazione
  • Processo server: attende di essere contattato
• Le applicazioni con architetture P2P hanno processi client e processi server

Comunicazione tra processi

Affinché un processo su un host invii un messaggio a un processo su un altro host, il mittente deve identificare il processo destinatario. Un host ha un indirizzo IP univoco a 32 bit. Dato che sullo stesso host possono essere in esecuzione molti processi, è necessario conoscere sia l'indirizzo IP (deve essere univoco nella rete in modo da garantire che non esistano server con lo stesso IP) sia il port number (univoco nel server in modo che non ci siano altri processi con lo stesso port number).

Definizione e scambio di messaggi

• Tipi di messaggi scambiati: messaggi di richiesta e di risposta
• Sintassi dei tipi di messaggio: quali sono i campi nel messaggio e come sono descritti
• Semantica dei campi: significato delle informazioni nei campi
• Regole per determinare quando e come un processo invia e risponde ai messaggi

Tipi di protocolli

1. Protocolli di pubblico dominio
   • Definiti nelle RFC
   • Consentono l’interoperabilità
   • Esempi: HTTP, SMTP
2. Protocolli proprietari
   • Esempio: Skype

Caratteristiche delle applicazioni

• Perdita di dati:
  • Alcune applicazioni (ad esempio, audio) possono tollerare qualche perdita
  • Altre applicazioni (ad esempio, trasferimento di file, telnet, ecc.) richiedono un trasferimento dati affidabile al 100%
• Ritardo:
  • Alcune applicazioni (ad esempio, telefonia Internet, giochi interattivi, ecc.) richiedono piccoli ritardi per essere “realistiche”
• Throughput:
  • Alcune applicazioni (ad esempio, quelle multimediali) richiedono un bit rate minimo garantito
  • Altre applicazioni (“applicazioni elastiche”) utilizzano il bit rate che si rende disponibile
• Sicurezza: Cifratura, integrità dei dati

Connessione e affidabilità

Orientato alla connessione: è richiesto un setup fra i processi client e server. Affidabilità: trasporto fra i processi d’invio e di ricezione. Pensata per tutte le applicazioni che non tollerano perdita dei dati, garantisce la consegna affidabile dei messaggi. Controllo di flusso: evita il sovraccarico del destinatario. Controllo di congestione: regola il processo d’invio se la rete è sovraccarica.

Elementi mancanti

• Ritardo non garantito
• Throughput non garantito
• Sicurezza

Servizio connectionless

• Trasferimento dati inaffidabile fra i processi d’invio e di ricezione
• Elementi mancanti:
  • Setup della connessione
  • Affidabilità
  • Controllo di flusso
  • Controllo della congestione
  • Controllo del ritardo
  • Throughput non garantito
  • Sicurezza

Applicazione di rete Web

Lunedì 10 ottobre 2022 15:00

• Una pagina web è costituita da oggetti (file)
• Un oggetto può essere un file HTML, un’immagine JPEG, un’applet Java, un file audio/video, ecc.
• Una pagina web è formata da un file base HTML che descrive com'è fatta la pagina web e include diversi oggetti referenziati che la compongono
• Ogni oggetto è referenziato da un Uniform Resource Locator (URL) formato dall'hostname e dal nome del percorso dei file da recuperare nel suo file system
• Obiettivo della navigazione web: la pagina web si vuole visualizzare su un dispositivo client, dove il processo client è rappresentato dal browser web
• Obiettivo: prendere i file dal web server e copiarli del browser web attraverso il protocollo HTTP con cui il client fa una richiesta di connessione TCP, specificando l'oggetto da richiedere attraverso l'URL
• Il messaggio di risposta sarà molto più pesante di quello di richiesta, perché contiene i file da trasmettere (HyperText Transfer Protocol)

HTTP

Protocollo a livello di applicazione del Web (RFC 1945, 2616). Modello client/server:

• Client: il browser che richiede, riceve e “visualizza” gli oggetti del Web
• Server: il server web invia oggetti in risposta a una richiesta di un client

Usa TCP:

• Il client inizializza la connessione TCP (crea una socket) con il server (porta 80)
• Instaurazione di una connessione TCP tra server e client
• Scambio di messaggi HTTP fra browser (client HTTP) e server web (server HTTP)
• Chiusura della connessione TCP

HTTP è un protocollo stateless. Il server non mantiene informazioni sulle richieste fatte dal client. Due richieste consecutive dello stesso oggetto danno luogo a trasmissioni distinte. I protocolli che mantengono lo “stato” sono complessi poiché la storia passata (stato) deve essere memorizzata. Se il server e/o il client si bloccano, le loro viste dello “stato” potrebbero essere contrastanti e dovrebbero essere riconciliate.

Connessioni non persistenti

• Gli oggetti sono trasmessi su connessioni TCP distinte tra client e server (connessioni TCP dedicate)
• Ogni volta che un client invia una richiesta di connessione al server, dopo che il server invia la risposta, la connessione TCP viene abbattuta

1. Il client HTTP inizializza una connessione TCP sulla porta 80 con il server HTTP (processo) il cui nome è dato dall'hostname dell'URL
2. Il server HTTP con nome hostname, in attesa di una connessione TCP alla porta 80, “accetta” la connessione e avvisa il client
3. Il client HTTP trasmette un messaggio di richiesta verso la socket della connessione TCP. Il messaggio indica che il client vuole l’oggetto indicato dal nome del percorso
4. Il server HTTP riceve il messaggio di richiesta, forma il messaggio di risposta che contiene l’oggetto richiesto e invia il messaggio nella sua socket
5. Il server HTTP chiude la connessione TCP
6. 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 n oggetti
7. I passi 1-6 sono ripetuti per ciascuno degli n oggetti

Connessioni persistenti

• Più oggetti possono essere trasmessi su una singola connessione TCP tra client e server (connessione TCP condivisa)
• La connessione TCP rimane attiva dopo il termine dell’invio di un oggetto fino alla scadenza di un timeout

Stabilire una connessione web richiede tempo e genera ritardo. Si parla di Round Trip Time (RTT): tempo impiegato da un pacchetto per andare dal client al server e ritornare al client. Tempo di risposta:

• Un RTT per inizializzare la connessione TCP
• Un RTT perché ritornino la richiesta HTTP e i primi byte della risposta HTTP
• Tempo di trasmissione del file -> Ritardo totale= 2RTT + tempo di trasmissione del file

Connessioni persistenti: vantaggi e svantaggi

Svantaggi delle connessioni non persistenti:

• Il server lascia la connessione TCP aperta dopo l’invio di una risposta
• Richiedono un tempo pari a 2 RTT per ogni oggetto
• I successivi messaggi tra gli stessi client/server vengono trasmessi sulla connessione TCP aperta
• Overhead del sistema operativo per ogni connessione TCP
• I browser spesso aprono connessioni TCP parallele per trasmettere gli oggetti referenziati

Esempio in HTTP 1.1: un browser apre da 5 a 10 connessioni TCP (parametro configurabile)

• Il client invia le richieste non appena incontra un oggetto referenziato
• Un solo RTT per tutti gli oggetti referenziati

Caching web

• La cache è una memoria in cui si va a salvare un contenuto molto richiesto
• Obiettivo: soddisfare la richiesta del client senza coinvolgere il server d’origine
• L’utente configura il browser: accesso al Web tramite la cache
• Il browser trasmette tutte le richieste HTTP alla cache:
  • Se oggetto nella cache: la cache fornisce l’oggetto
  • Altrimenti la cache richiede l’oggetto al server d’origine e poi lo inoltra al client
• La cache opera sia come client che come server
• Tipicamente la cache è installata da un ISP (università, aziende o ISP residenziali)
• Motivi per usare il caching web:
  • Riduce i tempi di risposta alle richieste dei client -> collegamento client-server più veloce
  • Riduce il traffico sul collegamento di accesso a Internet -> collo di bottiglia, zona dove si verifica più spesso congestione di rete
  • Internet arricchita di cache consente ai provider “scadenti” di fornire dati con efficacia

1. Client richiede connessione e chiede alla cache se contiene il contenuto
2. Se la cache non lo contiene (è la prima richiesta verso quell'URL) -> avviene il collegamento client-server con il web server
3. Il web server completa la richiesta mandando il file alla cache
4. Da questo momento in poi, la richiesta verrà espletata dalla web cache

Ipotesi e calcoli

• Dimensione media di un oggetto= 1 Mbit
• Frequenza media di richieste dai browser istituzionali ai server d’origine = 15 richieste/sec
• Ritardo dal router istituzionale a qualsiasi server d’origine e ritorno al router = 2 sec (ritardo di Internet)
• Ritardo totale di risposta: Ritardo LAN + Ritardo accesso + Ritardo internet
• Intensità del traffico nella rete locale -> = 15 r/s x 1 Mbit = 15 Mbit/s
• Grado di utilizzazione della LAN
  • = / 100 Mbit/s = 0.15
• Ritardo limitato
• Intensità del traffico nella rete di accesso -> = 15 r/s x 1 Mbit = 15 Mbit/s
• Grado di utilizzazione della rete di accesso
  • = / 15 Mbit/s = 1
• Ritardo molto elevato
• Conseguenze
  • Ritardo totale = 2 sec + x minuti + y millisecondi
  • Il collo di bottiglia (bottleneck) è il segmento di accesso
  • Problema di sottodimensionamento dato che C < d -> non si riesce ad instaurare comunicazione causando ritardo infinito
  • Si verifica molta congestione di rete con perdita pacchetti a causa della coda che risulta essere piena

Soluzioni al problema

1. Ridimensionamento della rete per soddisfare la domanda di traffico => costo economico alto
2. Diminuire la richiesta da parte dell'utente
3. Web caching:
   • Nell'esempio supponiamo di installare una cache
   • Supponiamo una percentuale di successo (hit rate) pari a 0,4 -> contenuto che sto scaricando stia effettivamente nella cache
   • Conseguenze:
     • Il 40% delle richieste sarà soddisfatto quasi immediatamente
     • Il 60% delle richieste sarà soddisfatto dal server d’origine
     • L’utilizzazione del collegamento d’accesso si è ridotta al 60%, determinando ritardi trascurabili (circa 10 msec)
     • Ritardo totale medio = ritardo di Internet + ritardo di accesso + ritardo della LAN = 0,6*(2,01) sec + millisecondi < 1,4 sec
     • Si passa da ritardo infinito a prestazioni veloci

DNS

Per instaurare una connessione web TCP, bisogna ricavare l'ip_server. La socket conosce l'hostname del server e da questa si può ricavare l'ip attraverso il DNS. Il DNS è un database distribuito implementato in una gerarchia di server DNS.

È un protocollo a livello di applicazione:

• Consente agli host, ai router e ai server DNS di comunicare per risolvere i nomi (tradurre nomi/indirizzi)
• Diversi DNS dello stesso web server servono a localizzare geograficamente e customizzare la pagina di conseguenza
• Funzioni critiche di Internet implementate come protocollo a livello di applicazione
• Complessità nelle parti periferiche della rete
• Ritardo addizionale

Servizi DNS

• Traduzione degli hostname in indirizzi IP
• Host aliasing
  • Un host può avere più nomi: nome canonico + alias
  • Il DNS traduce un alias nel nome canonico
  • Mail server aliasing
• Distribuzione locale: server web replicati -> insieme di indirizzi IP per un nome canonico

Motivi per non centralizzare il DNS

• Singolo punto di guasto
• Volume di traffico
• Database centralizzato distante
• Manutenzione
• Un database centralizzato su un singolo server DNS non è scalabile (mantiene intatte le performance all'aumentare dei dati che contiene)

Gerarchia DNS

1. Root server
   • Sono contattati da un server DNS locale che non può tradurre il nome
   • Contatta un server DNS autorizzato se non conosce la mappatura
   • Ottiene la mappatura
   • Restituisce la mappatura al server DNS locale
2. Server TLD (Top-Level Domain server): si occupano dei domini com, org, net, edu, ecc. e di tutti i domini locali di alto livello, quali uk, fr, ca e jp.
3. Server Autoritativi (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 gestiti dall’organizzazione o dal service provider
4. Server DNS locale
   • Ciascun ISP (università, società, ISP residenziale) ha un server DNS locale detto anche “default name server”
   • Non appartiene alla gerarchia dei 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

1. Il client interroga il DNS locale con la richiesta HTTP
2. Il DNS locale interroga il DNS Root Server per trovare l'IP server del server da contattare
3. Il DNS Root Server ritorna l'IP del DNS Server TLD
4. Il DNS locale interroga il DNS Server TLD
5. Il DNS Server TLD restituisce l'IP del DNS Server autoritativo
6. Il DNS locale interroga il DNS Server autoritativo
7. Il DNS Server autoritativo restituisce l'IP del server da contattare
8. Il DNS locale restituisce l'IP del server da contattare al client

Il server contattato risponde con il nome del server da contattare.

Interrogazione DNS

• L'interrogazione avviene nello stesso modo della query iterativa, solo che al DNS locale viene restituito solo il risultato finale, cioè l'IP del server da contattare
• Affida il compito di tradurre il nome al server DNS contattato
• Il traffico addizionale ed il delay introdotti dalla risoluzione dei nomi può essere diminuito mediante l’uso di cache
• In entrambi i casi vengono instaurate delle connessioni basate su UDP che abbatte i tempi di connessione
• Dato che ci potrebbe essere perdita di pacchetti, viene implementato un meccanismo di recupero: se entro x secondi non è stata espletata la richiesta, riprova
• Una volta che un server DNS conosce la mappatura «nome, indirizzo», la memorizza nella propria memoria cache
  • Le informazioni nella cache vengono cancellate dopo un certo periodo di tempo (tipicamente 48 ore)
  • Normalmente 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 definiti dall’IETF

DNS è un database distribuito che memorizza i Resource Record (RR) -> Formato RR: (name, value, type, ttl)

• Type = A
  • name è il nome dell’host
  • value è l’indirizzo IP
• Type=NS
  • name è il dominio (ad esempio foo.com)
  • value è il nome dell’host del server autoritativo di questo dominio
• Type = CNAME
  • name è il nome alias di un server
  • value è il nome canonico
• Type = MX
  • value è il nome del server di posta associato a name

Può succedere che ad uno stesso hostname vengano associate diverse macchine fisiche con hostname più complicati. Si usa un alias per semplificare l'hostname all'utente che ne fa la richiesta. 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

Per rendere l'indirizzo web fruibile a un client bisogna:

• Avere un proprio server DNS autoritativo
• Registrare l'hostname presso registrar
• Fornire a registrar i nomi e gli indirizzi IP dei server DNS di competenza (primario e secondario)
• Registrar inserisce due RR nel server TLD del corrispondente dominio
• Inserire nel server autoritativo due record che corrispondono a quelli inseriti nel server TLD

Protocolli di trasporto

Martedì 11 ottobre 2022 13:00

• Fornisce un collegamento logico end to end tra processi in host remoti
• Obiettivo: inviare messaggi end to end tra i terminali
• Le funzioni di trasporto sono eseguite nei sistemi terminali
  • Lato emittente: divide i messaggi (A-PDU) in segmenti (T-PDU) e li inoltra allo strato di rete
  • Lato ricevente: esegue la ricostruzione dei messaggi e li inoltra allo stato di applicazione
• Protocolli di trasporto in Internet: TCP e UDP
• Sono servizi basilari dei protocolli di trasporto basati su