Appunti reti - dalle spiegazioni fatte in classe PDF

Preview

Summary

dalle spiegazioni fatte in classe...

Description

ARCHITETTURA DI RETI- Appunt Hosts->device che si collegano alla rete Larghezza di banda(bandwidth)->rate di bit che possono essere trasmessi Packet Switches->oggetti a cui si connettono più hosts. Questi oggetti ricevono pacchetti su una porta e li ritrasmettono su un'altra porta, fa quindi comunicare gli host collegati. ISP->Internet Service Provider: azienda che permette di far collegare gli hosts ad un suo packet switch che è a sua volta collegato alla rete internet, a volte anche su due o più piani (un'azienda collegata ad un'altra azienda più grande). Multiplexing->metodo per utilizzare lo stesso canale mandando dati diversi FDM(Frequency Division Multiplexing)->divisione banda per frequenze: diverse comunicazioni, ma su frequenze diverse, poi un filtro le divide. TDM(Time Division Multiplexing)->divisione banda per tempo: prima uno, poi l'altro, e così via. Packet o Circuit Switching? Circuit->banda garantita, senza perdita di dati. Spreco di banda se ci sono pochi utenti. Prima di iniziare la connessione bisogna trovare il percorso da utilizzare . Gli apparati devono essere più intelligenti e quindi più costosi. Bandwidth->Quantità associata ad un limite; rate massimo al quale si possono scrivere i bit su un singolo collegamento fisico. Throughput->Quantità di bit che si possono spedire sul canale tra mittente e destinatario per unità di tempo (bit/s). Si è deciso di effettuare una divisione in layer in modo da poter apportare modifiche solo ad un layer anzichè a tutto. SICUREZZA IN RETE Virus-> programmi che hanno la capacità di autoreplicarsi negli altri computer(file eseguibili). Worm->Tipo di virus che si propaga anche se non viene eseguito. Malware->Software che arrecano danni. Spyware->Software che spiano i dati sensibili(es keylogger). DDoS Attacks->Distributed Denial of Service: può fare in modo che tutti i computer infetti facciano accesso allo stesso server obiettivo dell'attacco in modo da rendere quel server non disponibile agli altri utenti che si vogliono connettere poichè la banda viene intasata. Distributed perchè vengono utilizzate molte macchine. Pocket Sniffing->ad esempio Wireshark, programmi che sniffano i pacchetti sulla rete, anche direttamente dal canale fisico. IP Spoofing->Accedere alla rete con un IP diverso da quello reale per "fingersi un'altra persona". Negli anni '90 iniziano ad esserci interessi commerciali sulla rete internet, negli stessi anni viene introdotto il web. HTML e HTTP->Inizialmente per scambio informazioni al CERN. APPLICATION LAYER Tutti i software che utilizzano la rete per mandare messaggi di qualunque tipo fanno parte dell'application layer. Il protocollo è la "lingua" con cui i programmi mittente e destinatario parlano tra loro. Il Transport layer recapita i messaggi. Un'applicazione di rete è in grado di girare su diversi sistemi (sia hw che sw) ed è in grado di comunicare attraverso la rete. Quando scriviamo il codice per un'applicazione network possiamo non curarci di come funziona il network-core. SERVER-CLIENT Server->offre un servizio(sempre acceso). P2P->Non esiste una parte che è esplicitamente un server o un client. Quando si accede ad un file P2P si è sia host che client. Socket->Sta tra il layer application e il transport: è un meccanismo di trasporto tra i due layer, in più in una macchina possono girare più applicazioni, con il socket si sa quale processo deve ricevere il messaggio. FTP Tutto ciò che può fare ormai è già stato implementato anche su HTTP. Il suo principale utilizzo è nei sistemi in cui vi è l'upload di file. Il trasferimento FTP inizia con il client che fa una richiesta di connessione al server, che la accetta, dopodichè il client ha la possibilità di vedere i file all'interno del server e di utilizzare comandi. I dati passano su un'altra connessione (una per file), che, finito il trasferimento, viene chiusa. "out of band"->avere due connessioni diverse (?) Anche il protocollo FTP è codificato in ASCII (?)

1

SMTP Il sistema di scambio di mail è basato su 3 componenti: user agents, mail servers e SMTP(simple mail transfer protocol) I server servono per memorizzare i messaggi, se per esempio un PC è spento, con un altro computer non si potrebbe aprire una connessione, quindi non si potrebbe inviare la mail. La porta di default per SMTP è la 25. Il protocollo SMTP permetterebbe solo testo: i dati che non sono testo vengono codificati per "far finta" che sia testo. SMTP usa connessione persistente, c'è un header e un body. L'HTTP è un protocollo di pull-> il client apre una connessione per ricevere qualcosa. SMTP è di push-> si apre la connessione per inviare file. Nell'header ci sono messaggi non per forza uguali a quelli che abbiamo scritto per mandare la mail(?). I programmi di posta fanno quello che facevano prima gli utenti con Telnet. PROTOCOLLI POP3-IMAP Il protocollo POP3 mette a disposizione dei comandi che permettono di scaricare i messaggi nella casella di posta. Il protocollo IMAP ha lo stesso utilizzo di POP3, ma mantiene i messaggi all'interno del server, organizzandoli in diverse directories. Con il protocollo POP3 invece scarichiamo i messaggi direttamente sul client, perciò se cambio il PC perdo i messaggi, con IMAP invece li lascio sul server e posso accedervi da diversi dispositivi. DNS Protocollo che si utilizza per risolvere problemi di dominio. L'IP è un indirizzo di 32bit. Si usa un nome al posto dell'IP, più facile da ricordare. Per convertire da nome a IP(e viceversa) si usa il DNS(Domain Name System) che è formato da database, c'è un protocollo con cui posso chiedere l'IP di un nome di dominio(è sul livello applicativo poichè è un protocollo creato dopo per non cambiare tutti gli altri protocolli). I server DNS sono degli host collegati alla rete internet nel network edge. Host aliasing-> Nomi di domini diversi collegati allo stesso indirizzo IP. I server DNS di primo livello sono 13 nel mondo. Quando ci si collega alla rete, si riceve anche l'IP del server DNS(uno qualunque), ha senso utilizzare quello più vicino. Con le query ricorsive, i server contattati possono fowardare le richieste agli altri server, ma questo è poco efficiente perchè ci sono solo 13 root DNS. Quindi i root rispondono sempre dicendo di chiedere ad altri, il server DNS locale forwarda la richiesta al TLD(sigla?) DNS server oppure fa con iterazioni(?), dipende come viene impostato. Solitamente i local DNS server tengono in sè gli indirizzi dei server TLD. Le coppie IP-nome sono salvate nella cache, ma possono variare, per questo per ogni coppia è associata una flag(TTL) per determinare il periodo di tempo per cui la coppia è valida. Quando scade il tempo le coppie vengono aggiornate. DNS RECORDS Tipo A-> Match tra IP e nome. Tipo NS-> MAtch tra nome dominio e nome DNS server che è authority del dominio(es www.google.qualcosa.com->il server è google.com). Tipo CNAME->nome->alias value->nome vero(quello messo prima)(?). Tipo MX->Mail exchange, si associa il nome del dominio e dentro il value si ha il nome del mail server che gestisce la posta per quel dominio. SICUREZZA LEGATA AL PROTOCOLLO DNS Ci possono essere diversi tipi di attacchi: DDoS-> Enormi quantità di richieste al server per fargli esaurire le risorse(di banda o computazionali), i server root applicano meccanismi di filtraggio: sarebbero più attaccabili i server TLD, ma non ci sono attacchi avvenuti con successo in passato. Redirect attacks->Si danno informazioni sbagliate al posto dei servers, dirottando il client su un altro indirizzo. DNS Poisoning->Collegarsi alla rete e mandare risposte a domande mai fatte, in modo che i server aggiornino i loro dati. Exploit DNS for DDoS-> usare server DNS per attacchi di DDos. Se effettuo tante chiamate al server fingendo di essere un altro pc, il server manda le risposte al PC, che rischia di finire le risorse.

2

APPLICAZIONI PEER TO PEER Implemetntare protocolli peer to peer è più cpmplicato che con client-server. Ogni computer scarica da tutti i peer e fa l'upload a tutti i peer. Su bitTorrent ci sono dei nodi che per esempio mantengono la lista di tutti gli altri nodi partecipanti (tracker). MULTIPLEXING E DEMULTIPLEXING UDP Quando il socket iceve il pacchetto guarda la porta e indirizza il pacchetto alla porta anche se i pacchetti arrivano da diversi indirizzi IP. Tutti i messaggi contengono porta sorgente e porta destinazione. TCP Una connessione è definita da IP sorgente, porta sorgente, IP destinazione, porta destinazione: questi parametri identificano un canale aperto tra due processi. Per decidere a quale socket passare i pacchetti il meccanismo di demultiplexing utilizza tutti e 4 i valori per dare informazioni su dove mandare i pacchetti. Viene utilizzato un socket diverso per ogni client. Di solito sono applicazioni multithread e ad ogni thread è associato un client. PROTOCOLLO UDP Utilizzato principalmente per lo streaming(ho bisogno di velocità e non di affidabilità massima), per il protocollo DNS e SNMP. Per il DNS si usa l'UDP perchè è semplice, in modo da non sovraccaricare i propri server. Un'applicazione può utilizzare il protocollo UDP, mettendo però dei meccanismi di verifica dell'effettivo arrivo dei pacchetti. CHECKSUM Rileva gli errori all'interno dei pacchetti. Il mittente calcola il numero ignorando come sia composto il pacchetto. Si ha una serie di numeri(non so da dove venga(?)) e si divide in segmenti da 16bit, che vengono sommati tra loro con il complemento a 1, facendo si che il numero sia sempre di 16bit, poi si mette nel checksum e si manda. Il ricevente ricalcola il checksum e se è uguale a quello iniziale significa che non ci sono stati errori. Non permette però di capire dov'è l'errore e ne identifica solo alcuni tipi: il checksum può inoltre risultare corretto anche quando in realtà ci sono errori. RELIABLE DATA TRANSFER Il canale è unreliable, cioè la rete può corrompere e perdere pacchetti, perciò bisogna implementare un protocollo reliable sul transport layer. Lavoriamo con macchine a stati finiti. c'è un'azione che modifica lo stato e le azioni che vengono compiute quando lo stato cambia. Le usiamo per indicare gli stati in cui possono trovarsi mittente e destinatario di un messaggio. Assumiamo che il canale possa shiftarre i bit->implementiamo un checksum, come possiamo risolvere il problema se si è perso un dato? Si manda un messaggio per informare il mittente che il pacchetto non è arrivato con successo al destinatario. Ci sono vari modi->ACK:dire che il pacchetto è arrivato oppure NAK: dire che il pacchetto è errato e chiederne il reinvio. Lo stato iniziale del mittente è in attesa dei dati. Quando arrivano si crea un pacchetto con dati e checksum e lo manda. Quindi si cambia stato: "in attesa di risposta". Se si riceve un NAK torniamo nello stato di attesa dei dati. Dal lato del ricevente, se il pacchetto è corrotto si manda un NAK, se non è corrotto si mandano i dati all'applicazione e si invia al mittente una ACK. Il problema è che anche ACK e NAK possono perdersi, quindi questa soluzione non è corretta. Un altro problema è se gli ACK e i NAK vengono ricevuti ma sono corrotti, quindi non si sa se in origine erano l'uno o l'altro, perciò il sender deve per forza ritrasmettere il pacchetto, che però può essere un duplicato. Per risolvere questo problema si può attaccare un numero di sequenza ad ogni pacchetto, per fare in modo che il receiver riconosca se il pacchetto è un duplicato. il sender rimane in attesa dei dati, poi si attacca un numero di sequenza corrispondente allo stato(inizialmente 0), poi si passa in attesa di ACK o NAK con numero di sequenza 0(in questo caso), se è un NAK rimando il pacchetto, se è un ACK si rimette in attesa di dati dall'applicazione con numero di sequenza incrementato di 1. Il receiver è in attesa del pacchetto 0. Se non è corrotto estrae il pacchetto, dà i dati all'applicazione e manda ACK, se è corrotto manda NAK, se arriva un pacchetto non corrotto ma con numero di sequenza sbagliato, manda un ACK, senza mandarlo all'applicazione(perchè era un duplicato). Il modello è STOP AND WAIT, cioè mando e aspetto. Un'altro aspetto negativo è che ci sono più stati perchè è stata introdotta una memoria. Chi riceve non sa se il suo ACK o NAK è stato ricevuto. Il NAK non è però necessario, se è arrivato il pacchetto si manda ACK altrimenti non manda nulla. Posso mandare ACK specifici per un particolare numero di sequenza. Stato iniziale mittente->aspetto dati poi creo pacchetto con numero di sequenza 0 e checksum, lo mando e aspetto l'ACK relativo al numero di sequenza 0. Se si riceve un ACK con numero di sequenza 1 il destinatario chiede di ritrasmettere il pacchetto 0.

3

destinatario-> riceve un pacchetto che può essere corrotto o avere numero di sequenza diverso da quello voluto, manda un ACK per il pacchetto 1 per dire che l'ultimo pacchetto ricevuto correttamente è l'1 e, essendo un ciclo(0-1-0-1) vuol dire che deve rimandare il pacchetto 0, cioè quello successivo all'1. I pacchetti possono anche venire persi. viene introdotto un "time-out" per far uscire dallo stato. Se dopo un periodo di tempo non arriva lo si dà per perso. Può però arrivare successivamente al time-out. Il sender è in attesa->pacchetto con numero di sequenza, dati e checksum. Si fa partire un timer, se scade il tempo rimanda il pacchetto e fa ripartire il timer. In RDT 3.0 si ha uno stop and wait: manda un messaggio e aspetta l'ACK. Deve aspettare perchè il contatore è solo 0 e 1(?). Pipelined Protocol->manda più pacchetti e aspetta più ACKs. Tipi di questo protocollo sono: Go-Back-N e Selected Repeat. L'utilizzo del canale è proporzionale al numero dei pacchetti messi sul canale stesso. RTT non è un numero costante, dipende dalla rete. GO-BACK-N Il mittente può avere al massimo N pacchetti di cui non ha ancora ricevuto ACK. Il destinatario può mandare un solo ACK per il pacchetto più grande. Il mittente ha un timer per il più vecchio pacchetto di cui non ha ricevuto ACK(solo un timer). SELECTIVE REPEAT Gli ACKs vengono mandati per ogni pacchetto. Il mittente deve mantenere un timer per ogni pacchetto. 1-Definisce una finestra lunga N(numero massimo di pacchetti in volo di cui sto aspettando un ACK). Se un pacchetto non viene ricevuto, o comunque non arriva l'ACK la finestra si blocca. Scade il timeout, che essendo solo uno, il server rimanda il pacchetto, più tutti gli altri già mandati(senza ACK). Se per esempio non arriva l'ACK 2, il receiver rimanda l'ACK 1, per dire che è l'ultimo pacchetto ricevuto correttamente. Il receiver deve mandare i dati all'applicazione in ordine. Questo metodo non è particolarmente efficiente ma è facile da implementare. 2-Permette di rimandare i pacchetti di cui non è stata ricevuta l'ACK. Viene mantenuto un buffer in cui i pacchetti vengono scritti in modo da tenerli in ordine. C'è un timer per ogni pacchetto, in modo da sapere quale ACK non è stato ricevuto. Anche qui c'è una finestra che tiene N elementi che possono essere "in volo" senza quel ACK. Anche dal lato di chi riceve c'è una finestra perchè deve mantenere un buffer per i pacchetti fuori sequenza. La dimensione della finestra deve essere proporzionale al numero di sequenza/2. TCP PROTOCOL Protocollo antico con rivisitazioni. è punto-a-punto, connessione reliable. i pacchetti devono essere consegnati all'applicazione in modo ordinato. I dati che arrivano dall'applicazione è come se fossero un flusso di byte, non messaggi separati. é full-duplex-> il mittente può mandare dati al destinatario mentre il destinatario manda altri dati al mittente. I pacchetti spediti hanno una certa dimensione (...) per la connessione c'è l'handshaking in cui si scambiano messaggi di gestione(per esempio la dimensione della finestra). Ha un meccanismo di controllo del flusso: il mittente smette di mandare dati(o cala il bitrate) se il buffer del ricevente si svuota troppo lentamente rispetto alla mole di dati entrante. Nell'header del pacchetto TCP c'è un campo per il numero di sequenza del pacchetto per cui si vuole mandare un ACK, perchè può succedere che deve mandare un pacchetto e anche un ACK; esiste anche un campo (A) che dice se c'è l ACK o no. Ci sono delle flag che servono per aprire la connessione(R,S,F). Il campo PUSH (P) serve a dire che questi dati devono essere spediti il più velocemente possibile(non devono andare in buffering). Receive windows->byte liberi all'interno del buffer di chi riceve (flow control), così se il buffer è quasi pieno, il sender rallenterà la velocità di trasferimento. Anche nel protocollo TCP si usano i concetti di numero di sequenza e ACK. Siccome è un flusso di byte, come numero di sequenza viene usato il numero del primo byte di ogni segmento. RAPPORTO TRA ROUNDTRIP TIME E TIMEOUT Se il RTT è troppo lungo rimango bloccato con la finestra e il mittente aspetta tanto tempo prima di ritrasmettere. Il RTT non può essere scelto a priori, il timeout dovrebbe essere circa uguale al RTT. Per stimare il RTT si usano i RTT misurati, che variano molto tra di loro.

4

In TCP la ritrasmissione è causata non solo dallo scadere del timeout, ma anche a causa degli ACK duplicati. Se il mittente si vede arrivare 3 ACKs ripetuti, ipotizza che un segmento sia andato perso, quindi rimanda il segmento, anche se non è scaduto il timeout. HANDSHAKING Si decide il primo numero di sequenza dal server al client e dello stream dal client e server(?). A 3 vie-> 1-client-server 2-server-client 3-client-server 1) Il client richiede la connessione con un segmento avente flag (SYNbit=1) e il numero di sequenza iniziale 2) Il server risponde con una sequenza con SYNbit=1, ACKbit=1 e numero di sequenza iniziale. 3) Il client manda un pacchetto con ACKbit=1 ed entra in ESTAB(established, stabilita la connessione). Ricevuto questo ACK, anche il server si mette nello stato ESTAB. Per chiudere una connessione, sia il client che il server si mandano pacchetti con il bit FIN settato. Quando manda questo pacchetto la macchina resta in ascolto, può ricevere pacchetti ma non inviarne. Quando viene ricevuto il pacchetto con bit FIN, viene mandata l'ACK e si aspetta un periodo di tempo, poi viene chiusa la connessione, l'altra macchina la chiude non appena arriva l'ACK. CONTROLLO DELLA CONGESTIONE Tanti host che cercano di trasmettere dati che che devono passare all'interno degli stessi collegamenti(flow control si riferisce al buffer del destinatario). La congestione si manifesta con pacchetti che vengono persi e lentezza di connessione. Il congestion control diminuisce il rate delle connessioni. L'ideale sarebbe che il mittente sappia quando il buffer è pieno in modo da smettere di mandare dati fino a quando non si libera. In questo caso i pacchetti non andrebbero mai persi. Oltre alla perdita del pacchetto può succedere che scatti il timer prima di ricever l'ACK e quindi vengono mandate due copie del pacchetto. Il fatto che l'ACK ritardi è causato dalla congestione. Sprechiamo quindi parte della banda utilizzabile per mandare pacchetti che erano già arrivati correttamente. Più la rete è congestionata più aumentano le cause della congestione stessa, fino ad avere la banda inutilizzabile perchè viene usata per rispedire i pacchetti. 2 modi per gestire la congestione: 1) NETWORK-ASSISTED CONGESTION CONTROL I router segnalano al mittente che sta per congestionarsi, spingendolo a ridurre il rate con cui manda i pacchetti. Non viene usata in TCP. La conoscenza dei router dovrebbe essere troppa. 2) END-TO-END CONGESTION CONTROL Scarica il compito di gestire la connessione agli host: è usato nel TCP. Il mittente capisce che si sta congestionando la rete in base al ritardo con cui riceve gli ACK o agli ACK duplicati. Se ricevo un timeout o 3 ACK duplicati devo diminuire il rate. Il rate con cui il mittente trasmette è legato al rate del controllo di flusso e di congestione. SLOW START->Prima si manda un solo segmento, poi raddoppiamo la finestra di congestione aumentandola di 1 MSS per ogni ACK che arriva. Poi mando 2 segmenti, poi 4, poi 8 e così via in modo esponenziale per ogni RTT. La velocità di aumento del rate è legata a RTT, più è corto il RTT più velocemente aumenta il rate. Quando ho 3 ACK duplicati, dimezzo la finestra di congestione, quindi torno ad aumentarla ma questa volta linearmente. Nel caso scada un timeout si riduce la finestra di congestione a 1 MSS e si riparte con lo slow ...