From d07c44aaf2349c39b724ba9124896e605d3acd5d Mon Sep 17 00:00:00 2001 From: Gianluca <gianlucamastrolonardo10@gmail.com> Date: Thu, 28 Mar 2024 14:59:17 +0100 Subject: [PATCH] appunti reti --- Reti/Teoria/appunti_es_reti.txt | 72 +++++++++++++++++++++++++++++ Reti/Teoria/appunti_reti_slide2.txt | 45 ++++++++++++++++++ 2 files changed, 117 insertions(+) create mode 100644 Reti/Teoria/appunti_es_reti.txt create mode 100644 Reti/Teoria/appunti_reti_slide2.txt diff --git a/Reti/Teoria/appunti_es_reti.txt b/Reti/Teoria/appunti_es_reti.txt new file mode 100644 index 0000000..2e01a77 --- /dev/null +++ b/Reti/Teoria/appunti_es_reti.txt @@ -0,0 +1,72 @@ +N link +M pacchetti + +Formula generale: + +(N+M -1) L/R + +Es slide 66: +Prima calcoli il numero di pacchetti +Poi i tempi di propagazione +Poi i tempo di trasfermimento + +Si calcola anche tempo propagazione +Si fa inclinato per il tempo di propagazione +Distanza serve per calcolare il tempo di propagazione +MTU (Max Transfer Unit) + +Il pacchetto è più grande dell'MTU, quindi devi capire quanti pacchetti mandare. +6 pacchetti da 1500Byte +1 Pachetto da 500Byte + +Tempo di propagazione Tp = distanza/velocità della luce = 400km/2*10^8 m^s = 2ms + +Ttx(1500) = L/R = 1500Byte/1Mbps = 12ms + +Ttx(500) = 12/3 (perché è un terzo di 1500Byte) = 4ms + +a questo punto fai il grafico, inizi con il 2ms, poi aggiungi i 6 pacchetti da 1500 e poi ne metti uno da 500. + +Poi sommi tutto. + +Guarda foto gruppo whatsapp + + +---- +Slide 69: +Ritardo di coda, utilizzando la formula (L*a)/r puoi sapere quanto è il carico, e quindi se c'è il rischio di +perdita di pacchetti + +Se circa 0 sei apposto +Se circa 1 sei al limite della capicità , già si crea un po' di accodamento perché i pacchetti arrivano in maniera +casuale, situazione da evitare. +Se maggiore di uno hai rotto tutto :( + + +La velocità con la quale si spediscono i pacchetti inficia molto su questa. +Esistono algoritmi che gestiscono questa cosa + +---- +Slide 70: + +se il buffer è pieno si perdono i pacchetti, la destinazione se ne accorge e lo richiede + +---- +Slide 71: + +Anche un solo router può farci peggiorare molto la velocità + +TTL: TimeToLeave, quanti router bisogna attraversare per arrviare a destinazione (di solito vale 50) +Ogni router appena incontra un pacchetto decrementa il TTL, questo serve per evitare i loop, perché l'instradamento +potrebbe fottersi. + +Il TTL nel traceroute viene impostato ad 1 per calcolare la velocità con il router, poi viene inpostato a 2, ed infine a 3. + + +---- +Slide 73: + +Throughput +Più router ci sono più ritardo aggiungi + + diff --git a/Reti/Teoria/appunti_reti_slide2.txt b/Reti/Teoria/appunti_reti_slide2.txt new file mode 100644 index 0000000..a17f782 --- /dev/null +++ b/Reti/Teoria/appunti_reti_slide2.txt @@ -0,0 +1,45 @@ +Pila ISO/OSI ogni livello è seperato uno dall'altro. + +Slide 11: +Socket: canali di comunicazione tra due host connessi tra di loro. +È la struttura che ci permette di trasmettere i dati. + +Slide 13: +la data integrity dipende dall'applicazione, per esempio nelle videochiamate è più importante l'audio del video. +Sintesi della slide, certe volte serve più una cosa di un altra, per esempio i giochi non hanno bisogno di sicurezza, +ma altre cose sì + +Slide 14: +Protocollo Sincrono: Giochi, Streaming in diretta, etc... + +Slide 15: +1. TCP: un livello di trasporto affidabile, non accetto perdita di pacchetti! + Flow Control: andare sempre al massimo. + Però ogni tanto devi rallentare tanto, riducendo la velocità (congestion control) + Il TCP non gestisce la sicurezza. + +2. UDP: tollera perdita di pacchetti. + Prova a spedire sempre al massimo + UDP molto più semplice da scrivere confronto a TCP + + +Slide 18: + TLS = Un layer in più tra application e trasporto ed implementa il TCP criptato + +----------------------------------------------------------------------------------------------- + +Slide 24: +Buono che sia stateless, introdurre uno storico all'interno del protocollo sarebbe molto complesso. +Appena una richiesta viene soddisfatta viene chiusa. + +Esistono anche chiamate persistenti, tenendo la connessione aperta per più tempo, questo è meglio perché si evitano +tutti gli handshake, ma più pericoloso. + +Slide 28: +RTT: Round Trip Time + +Slide 31: +Con il Keep-Alive fai una connessione persisitente + +Slide 34: +6821 sono i byte -- GitLab