Reti
===
- [x] Intro
- [ ] Capitolo 1
- [x] Capitolo 2
- [x] Capitolo 3
- [x] Capitolo 4
- [ ] Capitolo 5
- [ ] Capitolo 8
- [ ] Wireless
# Intro
> Una **RETE** è un insieme di dispositivi di calcolo autonomi e interconnessi (esista una piattaforma di rete che trasmetta lo scambio di informazioni digitali fra host).
A cosa serve :
- nuovi servizi di comunicazione (*email, WWW*)
- condivisione di informazione
- condivisione di dispositivi e risorse (Es. ho un problema? Posso dividerlo su più calcolatori anche online, che me lo risolvano in meno tempo e risorse)
- accesso a calcolatori remoti
- calcolo distribuito di sistemi scalabili
## Classificazione
In base alla dimensione geografica :
- **Personal Area Network ([PAN](https://it.wikipedia.org/wiki/Personal_Area_Network))**
- **Local Area Network ([LAN](https://it.wikipedia.org/wiki/Local_Area_Network))**
- **Metropolitan Area Network ([MAN](https://it.wikipedia.org/wiki/Metropolitan_Area_Network))**
- **Wide Area Network ([WAN](https://it.wikipedia.org/wiki/Wide_Area_Network))**
- **Internet (Inter - Network)**
## Evoluzione e Costi
Storicamente la prima rete di Internet nasce da un esperimento del **1969**, connettendo solo 4 calcolatori di 4 Università Americane.
All'inizio del **2003 ha oltre 172 milioni** di calcolatori connessi.
Nel **2020** si stima siano oltre 4 miliardi di dispositivi connessi (dotati di IP) e oltre **25 miliardi** considerando i dispositivi di **IoT**.
**Costi** di realizzazione, mantenimento, gestione e uso?
Più prestante più costa. Dipende dalla scala del servizio/rete
## Prestazioni
- **Capacità di trasmissione** : numero di bit o byte al secondo
- **Ritardo di collegamento** : tempo richiesto dai dati per transitare da mit a dest. Il ritardo è determinato dalla distanza fisica e anche dai tempi di gestione dovuti alle leggi dei processi di comunicazione.
- **Stabilità - Jitter** : variazione del ritardo tra i pacchetti. In caso di **Jitter** elevato si ha un effetto "fisarmonica" : prima non vengono inviati, poi vengono inviati tutti insieme (Se un app svuota un buffer e per colpa del Jitter non sono ancora arrivati altri dati, lo stream si blocca)
## Componenti
**Dispositivi o scheda di rete** : Codifica, trasmette, riceve e decodifica dati dal calcolatore alla rete e viceversa. Ad ogni scheda è associato un indirizzo MAC univoco da 48bit.
**Mezzo di Trasmissione** : supporto fisico di propagazione e trasmissione di segnali, come cavi elettrici, fibra ottiche o onde radio, in questo ultimo caso non può essere fisico, perchè può trasmettere nel vuoto.
**Connettore di Rete** : Interfaccia standard presente sul dispositivo di rete per collegamento con il mezzo di trasmissione.
**Protocollo di Rete** : insieme di regole implementate sotto forma di software, univocamente definite per garantire compatibilità e corretta gestione della comunicazione
## Collegamenti e Infrastrutture di Rete
Il **Collegamento** avviene attraverso il mezzo di trasmissione condiviso da più calcolatori in rete.
Un insieme di collegamenti in una rete, si chiama **Infrastruttura**, che può essere **Punto-Punto** (a) oppure **Connessioni Multiple** :
- **Completamente Connesse** (*b*): ogni host è collegato direttamente ad tutti gli altri. **n\*(n-2)/2 cammini totali**
- **Parzialmente Connesse** (*c*): esiste un cammino che collega due dispositivi, passando tra un nodo intermedio. Costa meno, ma più ritardi
- **Partizioni di Rete** (*d*): due gruppi di host non connessi
## Topologia di Rete
- **Anello** (*a*) : compromesso tra complex e ridondanza. Se si rompe un nodo, non si interrompe il servizio. Però se il protocollo non è corretto, un pacchetto potrebbe girare all'infinito
- **Stella** (*b*): switch centrale con SinglePointOfFailure. Costa poco da gestire e si evitano loop di pacchetti
- **Bus** (*c*): connessi ad un bus condiviso. Ha un broadcast naturle, però può parlare una coppia sola di dispositivi. Costosa e se si rompe il bus e si rompe tutto.
- **Albero** (*d*): Ogni nodo può comunicare con i figli
Reti più grandi usano topologie ibride, dette a maglia tramite **cablaggio struttruato**, riducendo il rischio di partizione di rete, creando più cammini tra due nodi
## Mezzo fisico di trasmissione
- **Cavi o Fili metallici** : Trasmettono segnali elettrici, che si traducono in bit in base alla variazione della sinusoidale descritta da tale segnale. Sono i più comuni poichè hanno un buon rapporto costo/prestazioni (fino a 1-2 Gbit/s), ma suscettibili ad interferenze.
- **Fibra ottica** : Trasmette segnali luminosi in fibre di vetro. Decisamente prestazioni migliori (migliaia di Gbit/s) e subiscono poca interferenza, ma hano alti costi di infrastruttura e gunzione (non puoi facilmente "piegare" un filo di vetro)
- **Segnali Radio** : Trasmissione di radiazioni elettromagnetiche nello spazio (quindi anche nel vuoto). Permettono una mobilità del calcolatore (limitata poichè dopo una certa distanza viene disperso il segnale), ma sono MOLTO suscettibili ad interferenze ed errori. Capacità odierna è di 1-54 Mbit/s
## Dispositivo o Scheda di Rete
Componente collegato al calcolatore che permette la comunicazione in rete, tramite opportune interfacce per entrambi. Trasmette (*codifica*) e riceve (*decodifica*) dati che girano sulla rete come vari tipi di segnale, in base al mezzo di trasmissione usato.
Ethernet = IEEE 802.3
WIFI = IEEE 802.11
Ogni scheda ha un codice identificativo univoco : **Indirizzo di livello MAC** (medium access control). Serve per controllare se i dati ricevuti sono della scehda, quindi MAC di dest è quello della scheda oppure è in broadcast (tutti i bit a 1)
## Canali di Comunicazione della Rete
Visione astratta del mezzo di trasmissione, ne esistono 2 tipi :
- **Canale punto a punto** : Riservato tra solo due dispositivi. Non importa quanti canali punto a punto sono presenti sul mezzo di trasmissione, tramite espedienti come filtri di frequenze di luce ogni scheda di rete riceverà solo i dati destinati a sè
- **Canale ad accesso multiplo** broadcast : usato contemporaneamente da più dispositivi, in modo che ciò che trasmette uno arriva a tutti. Richiede arbitraggio, altrimenti si sovrapponebbero i dati, perndendoli. Richiedono indirizzamento, con indirizzi MAC, per mit e destinatari/o del dato. Conviene quando 1 vuole comunicare con tutti gli altri in una volta sola. Se voglio comunicare con solo una "fetta" di host, posso virtualizzare un canale LAN.
## Commutazione di Circuito
Serie di canali di comunicazione **punto a punto** su ogni connessione lungo il cammino. Basso tempo di ritardo, ma alto prezzo (paghi il tempo di connessione anche se non scambi dati) e spreco di risorse. ES : linea telefonica
## Commutazione di Pacchetto
Usata in reti basati su canali ad accesso multiplo e su Internet. I dati vengono divisi in pacchetti, spediti sul canale comune separatamente. Così si ottimizza l'uso del canale comune. Ovviamente ci saranno maggiori ritardi di comunicazone, ma costi minori.
---
## **Protocolli di Rete**
> **Insieme di Regole** garantire la comunicazione di messaggi non ambigui. Ogni livello fornisce servizi a quello superiore, sfruttando i servizi del livello inferiore.
I servizi offerti dalle reti nella commutazione a pacchetto dipendono dai protocolli utilizzati :
- **Connection Oriented** : i dati vengono spediti e ricevuti in ordine, senza errori e pacchetti persi vengono rispediti
- **Connection-less** : i dati vengono affidati alla rete, quindi non si ha la certezza che arrivino e che siano ordinati
Ad esempio ...
## ISO/OSI
Ad ogni livello i protocolli aggiungono informazioni, andando ad incapsulare il messaggio dentro delle "buste". Ogni livello si occupa di analizzare e scrivere nelle buste dati relativi al suo livello.
### Rendere un Canale Affidabile
Tra i compiti del livello MAC/LLC, c'è quello di controllare se il pacchetto è stato ricevuto entro un certo timeout, in caso contrario rispedire il frame, ripetere finchè non arriva a destinazione.
## Integrazione di reti
- Al livello **fisico**, la rete è solo un segmento di essa, cioè il mezzo di trasmissione condiviso tra dispositivi. Si occupa solo di codifica e trasmettere dati su tali mezzi.
- A livello **MAC** o "Data Link", la rete è un unione di più segmenti di rete, anche con diverse tecnologie. Regole per gli indirizzi MAC dei dispositivi, gestione accesso al canale condiviso, evitare errori di trasmissione e gestire comunicazione tra segmenti con tecnologie diverse.
- A livello **rete**, comunicazione tra reti in una struttura gerarchica, Rete Di Reti. Introduce indirizzi IP, per nascondere i dettagli locali. Serve un nuovo dispositivo (router) che smista pacchetti di dati tra reti
- A livello **trasporto**, regole per la spedizione affidabile dei pacchetti e controllo di congestione
- A livello **applicazione**, la rete esiste, funziona ed è usabile
## Esempi Protocolli liv2
- Ethernet : molto usato in reti locali, trasmette solo se nessuno sta già trasmettendo. Se viene rilevata una collisione, imposta un timer prima di riprovare
- IEEE 802.11 (Wi-Fi) : si cerca di prevenire le collisioni dilazionando nel tempo i tentativi di trasmissione.
- Token Ring : usato in reti ad anello. Esiste un frame detto "token", usato come testimone, chi lo detiene può trasmettere e poi passarlo
## Dispositivi per comporre Segmenti
**Livello Fisico (1)**
- Repeater : ripete i segnali che riceve. Utile per propagare segnali su rete Ethernet.
- Hub : come un Repeater, ma con più porte
**Livello MAC/LLC (2)**
- Bridge : connette segmenti di una rete, anche con tecnologie diverse. Gestisce accesso al canale, riducendo eventuali collisioni.
- Switch : come il Brdige, ma con più porte e con una tabella, per ricordarsi a quale porta corrisponde un indirizzo MAC.
---
# Capitolo 1
## Struttura
## Network Core
## Network Edge
## Sicurezza
---
# Capitolo 2
## Principi delle Applicazioni di rete
Applicazioni di Rete sono scritti per essere eseguiti su diversi dispositivi, che comunicano attraverso Internet. Non girano sui dispositivi del Network-Core.
### Possibili Architetture
- **Client Server** :
**Server** è un host sempre raggiungibile, IP statico, fornisce servizi per i **Client**, che potrebbe cambiare IP, non essere costantemente connesso alla rete. I due non parlano direttamente fra di loro.
- **Peer to Peer (P2P)** :
Una macchina può essere sia client che server. I "peer" possono sia chiedere un servizio, che fornirne uno. È necessario che essi comunichino direttamente fra di loro. Questa architettura è fortemente scalabile. La complessità sta nel gestire le richieste : "A chi richiedo un file?" se non c'è un server con IP fisso e magari l'ultimo peer a cui ho fatto una richiesta non è raggiungibile?
### Comunicazione tra processi
Per scambiarsi messaggi, le applicazioni usano dei **processi**. Se appartengono allo stesso host possono comunicare con *inter-process communication* definito dall'OS, altrimenti possono usare dei **socket**.
Sono delle *porte* in cui : chi tramsette pusha dati (send), chi riceve li preleva (listen).
Il processo client è colui che inizia la comunicazione, mentre quello server attende di essere contattato.
Per ricevere dei messaggi, il processo deve avere un identificatore **indirizzo IP : porta**
Non basta, il protocollo a livello Applicazione definisce anche :
- **Tipo dei messaggi scambiati** request/send
- **Sintassi** "Quali campi e come compilarli"
- **Semantica** Significato di ogni campo
- **Regole** su quando e come mandare/ricevere messaggi
Può essere sia open source, quindi chiunque può implementarlo ed sfruttarlo meglio, oppure proprietario, per questione economiche.
Le applicazioni richiedono che a livello trasporto ci sia :
- **Data integrity** perchè alcune app richiedono un trasferimento al 100% affidabile (ES file sharing, web transaction), mentre altre tollerano alcune perdite
- **Timing** alcune app richiedono un basso ritardo (ES giochi o chiamata)
- **Throughput** alcune app ne richiedono un minimo per funzionare (ES streaming), altre app "più elastiche" possono funzionare anche duranti cali.
- **Sicurezza** alcune app, come quelle bancarie, richiedono la riservatezza dei dati
### Servizi Protocolli liv Trasporto
**TCP** è un servizio connection-oriented, prima di trasmettere viene stabilita la connessione. Quindi deve garantire un trasporto affidabile, regola la velocità per non mandare più dati di quanti ne possa ricevere il destinatario , anche per non sovraccaricare la rete. Non garantisce sicurezza, timing e minimo throughput.
**UDP** essendo connectionless, non fornisce nessun servizio, è molto più legero e serve a quelle app a cui non importa di garanzie sulla comunicazione. Serve per "bypassare" il livello trasporto.
Per rendere sicuro TCP, si usa SSL. È un protocollo che agisce a livello applicazione e parla con TCP, senza agire sulle connessioni in se.
## Web e HTTP
Pagine **web** sono file HTML, in cui sono linkati altri file (foto, script JS, audio, video ecc). Ogni oggetto ha un indirizzo URL.
**HTTP** è il protocollo standard per scambio di messaggi nel web e si basa su **TCP**.
- **client** inizalizza la connessione TCP verso il server su porta 80
- **server** può accettare la richiesta
- **Client richiede** una pagina web e il **Server risponde**
- In **HTTP 1.1** la connessione si chiude subito, ma vista l'evoluzione del web può essere scomodo, quindi in **HTTP 1.2** è il client a chiudere.
***Round Trip Time** è il tempo che impiega un piccolo pacchetto per viaggio andata e ritorno da client a server.*
Per **HTTP 1.1** non-persistent, per ogni file il tempo di trasferimento è di 2RTT (uno per aprire la connessione e uno per trasferire il file). Mentre in **HTTP 1.2**, rimane 1RTT per inizializzazione e 1RTT per ogni file trasferito.
### Messaggi HTTP
Non tutti i campi nell'header lines sono obbligatori, tranne il campo Host
Nel campo metodo possiamo trovare :
- GET richiesta pagina web
- POST caricare sul server info
- HEAD simile a GET, ma non preleva oggetti richiesti
- PUT carica il file in *entity body* nel path specificato dal campo URL
- DELETE cancella il file specificato nel campo URL
*in HTTP 1.0 erano inclusi solo i primi 3*
La lina di stato contiene : versione HTTP e **codice stato**. ES
- **200 OK**
- **301 Moved Permanently**, include anche campo con la nuova Location del file
- **400 Bad Request**
- **404 Not Found**
- **505 HTTP Version Not Supported**
### Cookies
Si usano perchè HTTP in se è **stateless** : non si ricorda delle connessioni passate.
Viene fornito nel campo header *set-cookie : ID* dal server, che aggiunge il ID cookie nel database, e salvato dal client su un file.
A questo punto il browser associa quel server a quel cookie all’interno di una cache, così ogni volta che dovrà fare altre richieste, passerà anche il campo *cookie : ID*.
### Proxy Server
*Come evito di fare richiesta sempre al server origine?* Creo un server "intermedio" che salva in cache pagine web.
Riduce il tempo di risposta, traffico sulla rete e permette a provider con una connessione scarsa di poter funzionare
Si aggiunge il Conditional-GET *if-modified-since : \<date>* per evitare di ritrasmettere la stessa pagina non modificata
## Posta elettronica
Client manda una mail al **mail server** tramite protocollo SMTP. Usa TCP su porta 25, messaggi in ASCII 7-bit e connessioni persistenti.
Comandi possibili sono :
- HELLO indica host di provenienza della mail
- MAIL FROM inidirizzo mail mittente
- RCPT TO a chi inviare la mail
- DATA indicare il messaggio da inviare
- QUIT terminare connessione
Lo standard RFC 822 specifica che ci devono essere 3 righe : From, To e Subject *(diversi dai comandi SMTP)*
Per ricevere messaggi ci sono due Protocolli, entrambi hanno una fase di autenticazione tramite username e password
**POP3**
Scarica e cancella file dal server.Non posso riscaricare i file da client diversi, quinid è stateless. Usa porta 110. È possibile scaricare i messaggi con `list` e `retr`, cancellarli dal server con `dele` e uscire con `quit`. Ha due limitazioni : autenticazione in chiaro e modalità scarica-cancella (default).
**IMAP**
Mantiene i messaggi solo sul server, permette l'organizzazione in cartelle, mantiente lo state. Permette l'uso di un client email via browser e usare protocollo HTTP per ricevere e mandare email.
## DNS : Domain Name System
Più comodo ricordare un nome che un IP.
È un database distribuito implementato con una gerarchia di *Name Server*, che vengono distribuiti su uan parte dell'edge internet. Permette *aliasing* : più indirizzi IP associati a stesso nome (distribuisce le richieste), più nomi a stesso IP.
**Perchè non centralizzare il DNS?** Single point of failure e non è scalabile.
Il meccanismo per risolvere un nome con DNS funziona ad albero : dal basso parte una richiesta, se il server DNS non riesce a soddisfarla, passa la richiesta al livello superiore, fino ad arrivare al Root DNS Server.
**Top-Level Domain Server**
Responsabile per com, org, net, edu, uk, fra, ca, jp, it eccetera.
**Local DNS name server**
Ogni ISP (residenziale, azienda, università) ne ha uno.
Ogni richiesta dell'host viene fatta prima al server DNS locale.
Richiesta può essere **iterativa**, server locale contatta altri name server, che risponderanno "Non conosco questo nome, ma questo altro server sì". Carico principalmente sul Local DNS
Oppure può essere **ricorsiva**, ad ogni passo il server interpella quello successivo, fino ad arrivare ad un root DNS. Meno carico sul local, a discapito del Root.
DNS implementa il protocollo UDP, con la particolarità di rispedire le richieste topo un certo TimeOut.
La cache del DNS deve avere un TimeToLive, perchè le entries possono essere datate a causa di un cambio di IP. Nel cache dei local DNS viene salvato indirizzo del TLD.
Un record DNS salvato nel database si chiama **Resource Record (RR)** : `(name, value, type, ttl)`
`type=A` : `name` è hostname, `value` è indirizzo IP
`type=NS` : `name` è il domain, `value` è hostname del Name Server autorevole
`type=CNAME` : `name` è l'alias per qualche nome canonico, salvato in `value`
`type=MX` : `value` è il nome del mailserver associato con `name`
Richieste e risposte DNS usano entrambe questo formato :point_down:
I primi 16 bit sono dedicati per `identification`, numero della domanda a cui si riferisce. I successivi 16bit sono per `flags` per specificare se è : domanda oppure risposta, ricorsiva, disponibile la ricorsione o una risposta da DNS Authoritative.
`questions` indica il nome e tipi di campi per la query
`answers` per i **RRs** in risposta alla query
`authority` records di altri server authoritative
`additrional info` che potrebbero essere utili
Per registrare un nuovo dominio bisogna fornire ad un **DNS Registrar** il nome e indirizzi IP del authoritative Name Server Primario e Secondario. **Registrar** inserisce due RRs nel TLD Server (uno NS e un A per associare il dominio al authoritative DNS e quest'ultimo al suo indirizzo IP).
Ci sono vari modi per compromettere un DNS :
- **DDoS** bombardo i **server root** (non efficace perchè c'è un filtro traffico e cache sui local)
- **DDoS** bombardo quelli TLD (potenzialmente più pericoloso)
- Man-In-Middle
- **DNS poisoning** mandare risposte sbagliate ai DNS server, che le salva in cache
- sfruttare DNS per attacchi DDoS : mandi richieste con source IP address spoofed (sostiuisci il tuo con quello del bersaglio)
## P2P
Già detto : non esiste un server *always-on*. End-system comunicano direttamente. I vari *peers* si connettono ad intermiattenza e cambiano IP.
*es : file distribution (BitTorrent), Streaming (KanKan), VoIP (Skype)*
Se un server deve mandare un file ad N client sulla rete, ne dovrà mandare N copie. Il tempo per distribuirle è il massimo tra il tempo che impiega il server a mandare N copie e il client più lento a scaricare la sua $\to D_{c-s} \ge max\{NF/u_s, F/d_{min}\}$ aumenta linearmente in N
Con l'approccio P2P, il server deve mandare almeno una copia del file, poi anche i vari client che hanno finito di scaricare la loro copia possono condividerla. Quindi diventa il massimo tra il tempo che impiega il server ad inviare una copia, il client a scaricarlo e la rete a trasmettere N copie a max upload rate $\to D_{P2P} \ge max\{F/u_s,\ F/d_{min},\ NF/(\ u_s + \Sigma u_i\ )\}$ aumenta linearmente in N, ma anche la capacità della rete
### ES **BitTorrent**
File vengono spezzati in chunks da 256Kb. Ogni peer del torrent invia/riceve chunks.
Ci sono peer speciale chiamati **trackers** che registrano i peer attivi in rete che hanno la copia di un determinato file.
Quando entra un nuovo peer non ha subito chunk, ma li accumula da altri peers, si registra sul tracker per avere la lista dei peer e si connettete ai suoi "neighors". Mentre finisce di scaricare, può già condividere quelli che ha. Il problema è che un peer quando ha finito di scaricare l'intero file, potrebbe abbandonare il torrent. Questo uso *egoistico* del servizio può essere marginato con dei meccanismi che obbligano i peer a uplodare se vogliono scaricare
## Video Streaming e CDN
Il maggior consumo della banda è traffico video. La sifda è come raggiungere 1 Miliardo di utenti? *(Ovviamente non con un mega-video server)* E utenti diversi hanno una banda diversa *(dati mobili o cablato, alta o bassa bandwith)*
**Soluzione** : Infrastuttura distribuita livello applicazione
### Video
Sequenza di immagini mostrate a ritmo costante, ogni immagine è un array di pixel, ogni pixel è rappresentato da bits. Si possono usare coding intelligenti per evitare ridondanze *fra* e *nelle* immagini, risparmiando spazio.
Bit rate può rimanere **Costante** *CBR*, oppure variare in un range *VBR*
### DASH
*Dynamic Adaptive Streaming over HTTP*
Il **server** divide il file in *chunks*, che vengono salvati e codificate con rate diversi, e crea un *manifest file* in cui sono segnati ogni URL per i vari chunk
Il **client** misura periodicamente la banda server-to-client, consulta il manifest per chiedere un chunk alla volta, scelto prendendo quello con max coding rate possibile per la banda corrente. Può decidre in ogni momento di cambiare coding rate
Scelta sta al client :
- **quando** chiedere un chunk (niente buffer starvation o overflow)
- **quale enconding rate** chiedere (alta qualità quando è disponibile più banda)
- **dove** richiedere il chunk (chiede ad un server più vicino al client o che ha più banda disponibile)
### Content Distribution Networks CDNs
Esistono più copie dello stesso video distribuiti geograficamente in vari nodi. Si è più vicini all'utente finale, evita il "single point of failure" e scalabile.
L'utente accedera con il suo account, chiederaun file manifest in cui sono contenuti i URL su vari *Nodi*.
Ovviamente deve scegliere il *CDN Node* più "veloce"
## Socket Programming
### UDP
Non c'è una vera connessione tra client e server, poichè non c'è un handshake prima di mandare dati. Come sempre possono arrivare in disordine o persi.
**Mittente** aggiunge esplicitamente il suo IP : porta ad ogni pacchetto
**Destinatario** estrae IP : porta del mittente dal pacchetto ricevuto
### TCP
Client controlla che il server sia vivo, contattandolo via welcome-socket. Server crea un *nuovo socket TCP* dedicato alla comunicazione con un singolo client, così il server può comunicare con più client alla volta e la porta può essere usata per distinguere i client connessi.
---
# Capitolo 3
## 3.1 Transport-Layer Services
Provede ad una comunicazione fra app su host diversi.
- Sender : spezza messaggio in frammenti e li passa al livello rete
- Reciever : ricompila messaggio
Il livello trasporto gestisce comunicazione tra processi, rispetto a quello di rete che lo fa tra host. Sono disponibili su Internet due protocolli :
**TCP**
Affidabile, manda i pacchetti in ordine
Controllo Congestione e Flusso, Setup Connessione
**UDP**
Best Effort
Arrivano come arrivano
Nessuno dei due garantisce delay e banda minimi.
## 3.2 Multiplexing e Demultiplexing
## ## Demux
Ogni host riceve IP Datagram che contengono *IP* di mit e dest. Ogni datagram trasporta un segmento livello trasporto con *porta* di mit e dest.
Host usa IP:port per indirizzare il segmento al giusto socket.
**Connectionless demux**
Quando host riceve un segmento *UDP* lo inoltra al socket che corrisponde alla *porta dest* in esso. Un solo socket può ricevere *IP datagram* con **stessa porta dest** da diversi **source IP**.
**Connection-oriented demux**
Il socket TCP usa una quadrupla
( **source ip, source port, dest ip, dest port** )
Il ricevitore usa tutte e 4 i valori per inoltrare il segmento al giusto socket. Server host può supportare più socket TCP simultanei, ognuno è identificato da una quadrupla. Web Server hanno 1 socket per ogni client connesso.
## 3.3 UDP
***Perchè esiste UDP?***
Senza Handshake, meno delay
Semplice, stateless
Header più piccolo
Nessun controllo congestione : * ugh kansei durifto *
## ## UDP Checksum
Controllare che non ci siano "errori" nei segmenti.
**Sender** : Considera il segmento come sequenza di interi a 16-bit, li somma e aggiunge questo *checksum* nel campo apposito
**Receiver** : calcola il checksum e lo compara con quello nel campo *UDP Checksum*. Anche se non rileva un errore, potrebbe esserci lo stesso.
## 3.4 Principi di trasferimento dati affidabile
La complessità del canale affidabile è determinata dalle caratteristiche del canale **inaffidbaile**.
rtd : Reliabale Data Rransfer protocol
FSM : Finite State Machine
**rtd 1.0**
Trasferimento su un canale completamente affidabile (niente bit di errori o perdita di pacchetti)
FSM per Sender e Receiver
**rtd 2.0**
Il canale sottostante potrebbe flippare dei bit nel pacchetto.
Aggiungiamo i bit errore e feedback (**ACK** **N**egative**AK**). Il sender ritrasmette solo se riceve **NAK**
Servono meccanismi di error detection e feedback.
**rtd 2.1**
**Se ACK/NAK sono corrotti?**
Aggiungo un numero sequenza e ritrasmetto il pacchetto corrente se ricevo un ACK/NAK corrotto. Il receiver scarta i duplicati
**STOP and WAIT**
Sender manda un pacchetto e prima di continuare aspetta una risposta.
**Sender**
**Receiver**
Basteranno 2 seq#? Prob not se voglio mandare più di un pacchetto alla volta
**rtd 2.2**
Evitiamo NAK, al suo posto usiamo ACK e seq# dell'ultimo pkt ricevuto correttamente. Se Sender riceve un ACK duplicato, lo considera come un NAK $\to$ ritrasmette il pkt corrente
**rtd 3.0**
Assumiamo che il canale potrebbe perdere i pacchetti.
Il Sender aspetta un **countdown timer**, ritrasmette se non riceve un ACK in tempo. Se viene duplicato per un ritardo eccessivo, ci pensa il seq#
Il rtd 3.0 è corretto, ma ha una pessima performance se usato con **stop-and-wait**. Quindi si passa a protocolli pipelined per mandare più pacchetti alla volta. Aggiungere un buffer per sender e/o receiver.
- **Go-Back-N**
-
Il Receiver manda solo *comulative ack*, quindi non manda ack se c'è un gap.
Sender ha un timer il paccketto unacked più vecchio. Quando scade ritrasmette tutti quelli unacked.
**ACK(n)** : ACK comulativo per tutti pacchetti fino al seq# n, incluso
**timeout(n)** : ritrasmette tutti i pacchetti con seq# ≥ n
ACK-Only : manda ACK per il pacchetto correttamente ricevuto con **max** seq#
out-of-order pkt vengono scartati
- **Selective Repeat**
-
Receiver manda ACK individuali
Sender rimanda solo i pkt che non sono stati ACKed (timer individuale per ogni pkt)
## 3.5 TCP
Da punto a punto, controllo del flusso ordinato di pacchetti, full duplex data : flusso bidirezionale stessa connessione, handshake
**SEQ** : numero del "primo byte" nel data del segmento
**ACK** : seq# del prossimo byte che ci si aspetta dall'altra parte
**Time Out** deve essere più lungo del RTT, che però è variabile.
Troppo breve causa una ritrasmissione inutile.
Troppo lungo lenta reazione ad un pacchetto perso
**RTT** viene stimato misurando con `SampleRTT` (tempo trascorso trasmissione e ACK). `SampleRTT` può variare e si vuole una stima generale.
$EstimatedRTT = (1- \alpha) * EstimatedRTT + \alpha * SampleRTT$
tipicamente $\alpha = 0.125$
$DevRTT = (1-\beta)*DevRTT+\beta*|SampleRTT-EstimatedRTT|$
tipicamente $\beta = 0.25$
$TimeoutInterv al = EstimatedRTT + 4*DevRTT$
### Reliabale Data Transfer
TCP crea un servizio rdt attorno ad un servizio non-affidabile IP (segmenti pipelined, cumulative acks, single retransimssion timer). Ritrasmissione avviene con timeout o ack duplicati.
**Esempio TCP Semplificato**
*Ignora acks duplicati e ignora controllo flusso e congestione*
- **Data ricevuto da App**
Crea segmento con seq#
seq# è il numero byte-stream del primo byte data nel segmento
Fai partire il timer, se lo era già.
- **Timeout**
Ritrasmetti segmento che ha causato timeout
Restart timeout
- **Ricevuto ACK**
se è ACK di un pacchetto `non confermato`
aggiorna a `confermato`
Fai partire il timer se ci sono altri segmenti `non confermati`
**TCP Fast Retransmit**
se il sender riceve 3 ACKs per gli stessi dati
*molto prob quel segmento sia perso, quindi non aspetta un timeout*
rimanda segmento`non confermato`con il più piccolo seq#
### Controllo del flusso
Serve per non sovraccaricare il buffer del receiver, evitando che il sender trasmetta troppo e troppo veloce.
**Receiver** indica lo spazio libero nel buffer (`RcvBuffer`di default = 409 6byte) includendo nell'header TCP il valore `rwnd`.
### Gestione Connessione
Prima di scambiarsi i dati, si "stringono la mano". Concordare su : il stabilire una connessione e i parametri di connessione
**2-Way handshake ?** Delay variabili, ordine e ritrasmissione messaggi, non vedi l'altra parte
**3-Way handhsake** client sa che server è vivo, server sa che client è vivo
**FIN chiusura comunicazione** da entrambe le parti, con rispettivo ACK
## 3.6 Principi del Controllo Congestione
Diverso dalla congestione flusso, il problema sono i router della Network. Causa perdita di pacchetti (buffer overflow nei routers) e lunghi delay (accodamento nei router buffer).
**Scenario 1**
**Scenario 2**
Il sender dovrebbe mandare solo quando il router buffer è disponibile, ma comunque si perderebbero pacchetti.
Realisticamente ci saranno **duplicati** : scade timer del pacchetto (perso o droppato dai router) e ne manda un copia, entrambe consegnate. I "**costi**" di congestione sono legati alla ritrasmissione : lavoro in più (per mantenere un "goodput") e inutile (copie di pkt che diminuiscono il "goodput")
**Scenario 3**
Altro "**costo**" : quando i pacchetti vengono droppati, la capacità usata viene **sprecata!**
## 3.7 TCP Controllo Congestion
**Approccio** : sender incrementa il ritmo di trasmissione (*window size*), capendo la banda usabile, finchè non avviene una perdita di pacchetto.
congestion window = `cwnd`
Maximum Segment Size = `MSS`
additive increase : `cwnd` += 1 MSS
multiplicative decrease : `cwnd` /=2
`LastByteSent` - `LasByteAcked` ≤ `cwnd`
TCP sending rate ≈`cwnd`/ RTT bytes/sec
*Mandi cwnd byte e aspetti RTT per un ACK, mandi altri byte*
**Slow start**
Inizialmente lento ma incrementa esponenzialmente, fino a una perdita.
cwnd = 1 MSS
cwnd *= 2 // Ogni RTT
**Rilevare e reagire alla perdita**
Perdita indicata dal timeout $\to$ `cwnd` = 1MSS, poi window cresce exp fino al threshold e poi incremento lineare.
Perdicat indicata da 3 ACK duplicati :
- **TCP RENO** ACK dup indicano che la network riesce a consegnare dei segmenti. `cwnd` /= 2
- **TCP Tahoe** sempre `cwnd` = 1
**Quando dovremme switchare da exp a lin?**
quando `cwnd` arriva a 1/2 del suo valore prima del timeout (`ssthresh`)
**W** : window size quando avviene una perdita
**avg TCP Throughtput** come funzione di window size e RTT?
*ignora slow start e assumi che i dati vengano sempre mandati*
$= \frac{3}{4} * W/RTT$ bytes/sec
### Equità del TCP
*se K sessioni TCP condividono lo stesso bottolneck link di banda R*, ognuno dovrebbe avere un **average rate di R/K**.
**Connessioni Parallele TCP**, come i web browser,
**Multimedia app** non vogliono essere limitati dal controllo della congestione, quindi usano **UDP**
### Explicit Congestion Notiication (ECN)
-Due bit nel **header IP** (ToS field) segnato dal *network router* per indicare la congestione.
-Viene trasportato fino al host ricevente
-Receiver vede la congestione indicata dal *datagram IP*, imposta bit ECE nel segmento ACK per notificare il sender della congestione.
---
# Capitolo 4
## 4.1 Overview del livello Rete
Due funzioni principali
- **Forwarding** : sposta i pacchetti da *router input* a *router output*
**Data Plane**, locale per-router
- **Routing** : deterimina la strada presa dai pacchetti da mit a dest
**Control Plane** logica network-wide : *algoritmi routing tradizionali* oppure *SDN*
**CA** Control Agents
## 4.2 Cosa c'è dentro un router
### Longest Prefix Matching
Si fa matching con la entry per prefisso più lungo
| Range Inidirizzo Destinazione | Interfaccia Link |
| -------------------------------------- | ---------------- |
| `11001000 00010111 00010*** *********` | 0 |
| `11001000 00010111 00011000 *********` | 1 |
| `11001000 00010111 00011*** *********` | 2 |
| altrimenti | 3 |
Di solito svolto usando delle Ternary Content Addressable Memories (**TCAMs**)
Comodo per tabelle grandi, recuperi l'indirizzo in un ciclo di clock.
### Switching Fabrics
Trasferisci pacchetti da input buffer al corretto output buffer.
**Switching rate** : misurato come N volte input/output line rate.
- Switching via memoria
-
*Prima generazione di Router* : pacchetto copiato nella memoria di sistema. Velocità limitata dalla banda della memoria
- Switching via un bus
-
Bus condiviso fra porte input / output, limita velocità di switch
32 Gbps bus, Cisco 5600: velocità sufficente per router di accesso o enterprise
- Switching via rete interconnessa
-
Supera le limitazioni di banda del bus. Si usa una tecnologia pensata per connettere processori in un multiprocessore. Rete programmabile simile a ponte elevatoi. Frammenta i datagram in celle di lungezza fissa, che vengono trasferite sulla fabric. 
Cisco 12000: switches 60 Gbps via una rete interconnessa
### Coda Input Port
Se la fabric è più lenta di tutte le porte input combinate $\to$ input queueing
*Come ogni coda, causa delay e perdita per buffer overflow*
Quando un datagram nella coda blocca quelli che gli stanno dietro, si dice **Head-of-the-Line (HOL) blocking**
### Coda Output Port
- **Buffering** capita quando arrival rate via switch eccede la velocità di output
*Come ogni coda, causa delay e perdita per buffer overflow*
*Quanto buffering serve?* **RFC 3439** rule of thumb = RTT * *Link Capacity* C
**Consiglio più recente** = $\frac{RTT \cdot C}{\sqrt{N}}$
- **Scheduling**
- **FIFO** manda come arrivano. Ci sono più policy di scarto : coda, priorità o random
- **Priority** manda i pacchetti con la priorità più alta. Più classi con priorità diverse, basate su informazioni dell'header come IP/port Source/Dest
- **Round Robin** ciclicamente controlla le classi in coda, manda in pacchetto completo per ogni classe (se si può)
- **Weighted Fair** RoundRobin generalizzato, ogni classe ha un peso per la quantità di servizio in ogni ciglo
## 4.3 IP
I link rete hanno un proprio **Max Transfer Unit**, cioè il frame più grande possibile.
Grandi datagram IP devono essere "frammentati" nela rete, viaggiano come datagram separati e poi vengono riassemblati solo a destinazione. Per riconoscere l'ordine si usano i campi `length`, `fragflag` e `offset`
### IP Addressing
Indirizzo IP è un identificativo 4-byte per interfaccia host/router. Tipicamente un router ha più interfaccie, mentre host tipicamente ethernet+wifi
Diviso in più classi :
| Classe | Bit (N: Network, H:Host) | Subnet Mask | Reti Disp | Host Disp x Rete |
| ------ | ----------------------------------- | ---------------- | --------- | ---------------- |
| A | 0NNNNNNN.HHHHHHHH.HHHHHHHH.HHHHHHHH | 255.0.0.0/8 | 128 | 16.777.216(-2) |
| B | 10NNNNNN.NNNNNNNN.HHHHHHHH.HHHHHHHH | 255.255.0.0/16 | 16'384 | 65'536(-2) |
| C | 110NNNNN.NNNNNNNN.NNNNNNNN.HHHHHHHH | 255.255.255.0/24 | 2'097'152 | 256(-2) |
**Subnet**
*Cos'è?* Insieme di device, con stesso IP subnet, che possono comunicare fra loro, senza interpellare il router. Può essere vista anche come una "rete isolata".
**CIDR** Classless InterDomain Routing
**a.b.c.d/x** dove x sono il numero di bit dell'indirizzo che indicano la subnet
11001000 00010111 0001000 0 00000000 $\to$ 200.23.16.0/23
**Ma come ottengo un indirizzo IP?**
IP Statico : hard-codado dal system admin in un file
IP Dinamico : ottenuto da un server DHCP
### DHCP Dynamic Host Configuration Protocol
Serve agli host per ottenere dinamicamente un indirizzo IP quando entrano in una rete.
Host può aggiornare la "scadenza" del suo indirizzo. Ma se scade? L'indirizzo può essere riassegnato. Comunicazione con DHCP avviene sulla porta 67/68 e con UDP. Ogni richiesta ha un `transaction ID`
**DHCP DORA**
- **Discover** host manda in broadcast per capire se c'è un server DHCP disp
- **Offer** server risponde e manda un indirizzo IP disponibile
- **Request** host richiede quel indirizzo IP
- **ACK** server conferma
Per completare la configurazione dell'host, DHCP ovviamente manda anche Default Gateway, nome e IP del server DNS, Network Mask.
Le reti di un ISP vengono assegnate da un blocco di IP, che viene dato ai ISP da **Internet Corporation for Assigned Name and Numbers** (alloca indirizzi, gestisce DNS e assegna nomi domain e risolve)
### NAT Network Address Translation
Indirizzi IP inziavano a scarseggiare, ci vuole una soluzione! Una rete locale usa solo **UN INDIRIZZO** per il mondo esterno. Risparmio per gli ISP, cambiare indirizzo nella rete locale senza notificare il mondo esterno, cambiare ISP senza cambiare tutti gli indirizzi rete locale, i device nella rete locale non sono "visibili " dall'esterno.
- **Datagram in uscita - sostituire** (source IP, port#) con (NAT IP, port#)
- **Tabella NAT - ricordarsi** ogni coppia tradotta
- **Datagram in entrata - sostituire** (NAT IP, port#) con (source IP, port#), leggendo Tab NAT
Campo Porta ha 16-bit $\to$ 60'000 connessioni simultanee con un solo indirizzo LAN.
Controverso :
- router dovrebbe lavorare solo a liv 3
- con IPv6 si dovrebbe risolvere la mancanza di IP
- viola end-to-end
- Se il client si vuole connettere al server dietro un NAT?
### IPv6
Inizialmente creata per risolvere la fine degli indirizzi IPv4 4-byte. Poi usata per velocizzare processing/forwarding, migliorare QoS. Header ora è sempre di 40-byte e non è permessa frammentazione.
**Priority** : priorità fra i datagram nel flusso
**Flow Label** : identifica datagram nello stesso "flusso"
**Next Header** : protocollo di livello superiore
~~Checksum~~ tolto per ridurre processing time ad ogni hop
~~Option~~ spostato fuori dall'header, dove "Next hdr" indica
**ICMPv6** nuovi messaggi (es "Packet Too Big") e funzioni gestione gruppi multicast
Non tutti i router supportano IPv6, quindi si incapsula il pacchetto IPv6 in uno IPv4
## 4.4 Generalized Forward e SDN
Ogni router ha una *tabella di flusso*, calcolata e distribuita da una controller di routing centralizzato, una separazione tra control e data plane.
### OpenFlow
Flusso definito dai campi dell'header.
Forwarding generalizzato : semplici regole di gestione pacchetto
Rule $\to$ pattern da matchare nei campi di header
Priorità $\to$ gestire pattern sovrapposti
Counters $\to$ numero di bytes e pacchetti
Si possono creare vari tipi di device
- Router
- **match** prefisso dest IP più lungo
- **action** inoltra al link out
- Switch
- **match** indirizzo MAC destinazione
- **action** inoltra a una o tutte le porte
- Firewall
- **match** indirizzo IP e porte TCP/UDP
- **action** permetti o nega passaggio
- NAT
- **match** indirizzo IP e porta
- **action** riscrive indirizzo e porta
---
# Capitolo 5
## 5.1 Intro
Come già detto, esistono due metodi per strutturare il control plane : tradizionale, in cui il routing è calcolato localmente su ogni router, e globale, gestito da un'unità centrale SDN.
## 5.2 Routing Protocol
Scopo è determinare quando siano "buoni" i vari percorsi, da host mittente a host destinatario, via rete di router. Per "buono" si intende il più economico, veloce e meno congestionato.
C(u,v) = 2 cioè costo dell'arco da u a v
- **Globale**?
tutti i router hanno una topologia completa dei costi. Algoritmi **"link state"**
- o **Decentralizzato**?
Router conosce solo i "vicini", scambio di informazioni iterativo fra "vicini". Algoritmi **"distance vector"**
- **Statico**?
Percorsi cambiano lentamente
- o **Dinamico**?
Percorsi cambiano velocemente $\to$ aggiornamento periodico e risposta al cambiamento costi
### Link State - Dijkstra
Tutti i nodi conscono tutto, si condividono le info tramite "link state broadcast"
Calcola il costo per il percoso meno costoso da un nodo verso tutti gli altri.
```c=
// Initialization:
N' = {u}
for all nodes v
if v adjacent to u
then D(v) = c(u,v)
else D(v) = ∞
Loop
find w not in N' such that D(w) is a minimum
add w to N'
update D(v) for all v adjacent to w and not in N' :
D(v) = min( D(v), D(w) + c(w,v) )
/* new cost to v is either old cost to v or known
shortest path cost to w plus cost from w to v */
until all nodes in N'
```
almeno $n(n+1)/2$ comparazioni : $O(n^2)$, implementazione più efficente $O(n \log n)$
### Distance Vector - Bellman-Ford
$d_x(y)$ := costo del percorso costo min x a y
$d_x(y) = \min\{c(x,v) + d_v(y)\}$, dove v è un "vicino" di x, quindi minimo su tutti i vicini
L'idea chiave è di mandare di tanto in tanto ai nodi vicini il proprio Distance Vector $\textbf{D}_x$, che aggiorneranno il proprio usando B-F.
Il problema principale è che potrebbe non arrivare mai ad uno stato stazionario, mentre nel **link state** la velocità di convergenza è quadratica $O(n^2)$, ma sempre preferibile a quella del **distance vector**. Inoltre, nel caso di **link state** se un nodo sbaglia un calcolo, influisce solo se stesso, mentre con un distance vector tutta la rete è compromessa.
## 5.3 Intra-AS routing internet OSPF
Prima abbiamo ipotizzato che tutti i router fossero identici e una rete "piatta", nella realtà non è così. Non si possono salvare miliardi di destinazioni in una sola tabella e gli scambi intaserebbero la rete. Siccome internet è una rete di reti, magari l'amministratore di una rete vuole un suo modo di controllare il routing.
Quindi ci sono delle distinzioni gerarchiche, che rendono il calcolo degli algoritmi più agevole, dette **Autonomous System o AS**. All'interno di ogni AS tutti i router usano lo stesso algoritmo di routing (*intra-AS*), mentre fra AS i router di gateway useranno altri algoritmi (*inter-AS*).
In **Intra-AS** le metriche del costo includono anche costi sul traffico di rete o accordi politici.
Un **AS** può essere suddiviso ulteriormente in aree e gerarchie. Ogni "area" ha 1+ router di **gateway** o **border** che si fa carico dei pacchetti indirizzati all'esterno.
- **RIP** Routing Information Protocol
- **OSPF** Open Shortest Path First
- **IGRP** Interior Gateway Routing Protocol (proprietario CISCO fino al '06)
### OSPF
Come dice il nome, è "open". Usa algoritmo **LS** con **Dijkstra**. Tutti i messaggi OSPF sono autenticati. Sono permessi più percorsi con lo stesso costo. Supporto per uni- e multi-cast.
Divisa in due livelli : local area e backbone.
**Backbone** ha il ruolo di instradare il traffico tra le aree nel sistema autonomo. La dorsale contiene sempre tutti i router di confine, ma non necessariamente *solo* quelli.
L'instradamento nell'area di un sistema autonomo richiede che i pacchetti siano instradati prima verso il proprio router di confine (*instradamento intra-area*) e da questi, attraverso la dorsale, al router di confine dell'area di destinazione, che provvedrà a inoltrarli alla destinazione finale.
## 5.4 Routing fra ISP BGP
Di fatto il protocollo routing inter-domain. **eBGP** ottenere le informazioni di raggiungibilità dai AS vicini e **iBGP** propagare questa info ai router interni. I percorsi "buoni" vengono determinati dalle prestazioni e policy aggiuntive. Permette alle sottoreti di avvisare il resto dell'Internet della loro esistenza.
I **router gateway BGP** si scambiano messaggi in cui pubblicizzano che sono router gateway di un AS e che reti possono raggiungere. Usano una connessione *semi-permanente* TCP.
Messaggi possibili :
- **OPEN** aprire connessione TCP
- **UPDATE** avverte di nuovi percorsi (invalida i vecchi)
- **KEEPALIVE** tiene la connessione viva in assenza di **UPDATEs**, serve come ACKs richieste OPEN
- **NOTIFICATION** segnala errori in messaggi precedenti, usata anche per chiudere connessioni
### Hot potato Routing
---
## Capitolo 8
---
## Wireless
dbm = $10*\log(mW)$
mW = $10^{dBm/10}$
Perdita segnale in db = $36.6 = 20*\log(\text{Freq in MHz})+20\log(\text{Distanza in miglia})$
Link budget deve essere superiore a **system operating margin** tra 10 e 20 dB
- **FSK** Frequency Shift Keying
1 = Frequenza alta
0 = Frequenza bassa
- **PSK** Phase Shift Keying
- **BPSK** Binary Phase Shift Keyin
0 = fase 0
1 = fase 180
- **QPSK** Quadrature Phase Shift Keying
- **QAM**
Come QPSK but tieni conto Ampiezza (coordinate polari Ampiezza * phase=angolo)
Reti Wireless sono boradcast naturali, quindi collisioni succedono pefforza.
**Protocollo Aloha**
**Slotted Aloha**
Introduce slot = frammenti di tempo. Frame può essere trasmesso all'inizio di un nuovo slot.
**CSMA Protocol**
Ascolta il canale e trasmette se nessuno lo sta facendo. Vunerabilità è il propagation delay.
Quindi chi trasmette manda un **RequestToSend**, se destinatario riceve manda un **ConsentToSend** al mittente e a tutti gli altri.
Lo standard **802.11** funziona con due schemi preesistenti, un D**CF** (distributed coordination function) basato su **CSMA/CA** (congestion avoidance) con binary exponential backoff, generalmente utilizzato per le reti ad hoc in quanto non necessita di una stazione di base, e **PCF** (point coordination function) basato su un controllore centralizzato, con un access point che decide chi parla.
Access buon trasmette un pachetto **Beacon** che contiene info per schedulare chi parla. Quando finisce la fase **PCF**, fino al prossimo beacon si entra nella fase decentralizzata **DCF**, in cui tutti provano a parlare (*se non esiste il **beacon** rimane solo la fase **DCF***)
Sign in with Wallet
Connect another wallet