Appunti di Ingegneria dell'Internet e Web

PACKET TRANSMISSION

• L/X BIT DEL PACCHETTO
• R VELOCITÀ BIT N BIT/S

RETI TELEFONICHE, RETI A COMMUTAZIONE A CIRCUITO

RISORSE DEDICATE ALL'UTENTE 64 Kbit/s

• RETI A PACCHETTI tutte le altre. posso offrire

Reti a commutazione a circuito

1. ALLOCAZIONE RISORSE UNO TUTTO IL PERCORSO
2. INSTRADAZIONE TRAFFICO VELOCITÀ "FISSA"
3. RILASCIARE LE RISORSE

Frequency Division: FDM

La capacità di rete è partizionata (Poiché sono canali FISICI, non sono mmm, fittizi). le diverse partizioni allocate a utenti diversi.

Time Division: TDM

Il mezzo viene ora suddiviso in slot temporali, uno per ciascun utente, ripetuti in ogni frame

ISPs Internet Service Providers

gli utenti si connettono ad Internet tramite ISPs

RITARDO DI PACCHETTI

• Processamento, Controllo Errori BIT
• Calcolo LINK USCITA
• QUEUE: dipende dalla congestione

STRUTTURA A LIVELLI TCP/IP

1. LIVELLO 5: APPLICATION
2. LIVELLO 4: TRANSPORT
3. LIVELLO 3: NETWORK
4. LIVELLO 2: DATA LINK
5. LIVELLO 1: PHYSICAL

Ogni livello offre un servizio ai livelli superiori

(N) - PDU Protocol Data Unit

Unità dati del protocollo; dati scambiati dalle N entità (livelli)

Internet protocol stack

• Application: FTP, SMTP, HTTP
• Transport: TCP, UDP
• Network: IP, routing protocol
• Data Link: PPP, Ethernet

FINE C/..P?

LIVELLO 5: Application layer

A livello architetturale le applicazioni utilizzano

• Client-server
• Peer-to-peer (P2P)
• Ibridi

Client-server

• Il server:
• Sempre accesso
• IP fisso, noto ai client
• Offrono un servizio
• Il client:
• Interagiscono con il server
• Non c'è una comunicazione client-client
• È dinamico
• Non sempre acceso

Peer to peer

Nascono in assenza di server, i nodi (non sempre accesi) possono comunicare tra loro ma disconnettendosi non hanno sempre lo stesso indirizzo.

PROTOCOLLI DEL LIVELLO APPLICATIVO

I protocolli definiscono il tipo di messaggio che viene inviato/ricevuto, con regole nella semantica, sintassi e regole

PROTOCOLLI PUBBLICI: RFC(n), HTTP, SMTP

PROTOCOLLI PROPRIETARI: Vari

I processi inviano e ricevono messaggi da/alla propria socket

Socket: interfaccia tra il livello applicativo e di trasporto

Indirizzamento

IP address 32-bit = 4 byte → 2³² possibilità (4 miliardi)

Porta 16-bit = 2 byte → 2¹⁶ (65mila)

• HTTP server: 80
• Mail server: 25
• 0-1023: o well known
• 1-255: riservati per processi conosciuti
• 256-1023: riservati per altri processi
• 1024-65535: dedicato alle app utenti

EMAIL

Protocollo SMTP

Usa TCP per rendere il trasferimento di EMAIL affidabile da client a server

• posta al PORTA 25
• 3 fasi: invio, tentativi, risposta
• il client invia il server della propria posta elettronica, viene messa in coda
• il server, usando TCP, instaura una connessione con il server del ricevente che la invierà al destinatario
• periodicamente il server svuoterà la coda

SMTP: usa connessioni persistenti (nel server non chiude la connessione subito)

si invia in 7-BIT ascii

SMTP server usa CRLF e CRLF per determinare la chiusura del messaggio

• HTTP: pull (il server invia)
• SMTP: push (il client invia)

MIME: Multimedia mail extension, linea aggiuntiva in header line che definisce il contenuto "allegato"

• Text
• Video
• Image
• Application
• Audio

From

To

Subject

MIME-Version: 1.0.0

Content-Transfer-Encoding: base64

Content-Type: image/jpeg

Encoded DATA

Nel caso volessimo inviare più generi di tipo

Content-type: multipart/mixed; boundary=StartOfNextPart

boundary sarà il separatore tra un oggetto ed un altro

--StartOfNextPart

Corpo

--StartOfNextPart

Content-Transfer-Encoding

Content-Type: video/mpeg

--StartOfNextPart

Capito?

Mail access protocol

Il client che deve ricevere la mail può utilizzare diversi protocolli:

• POP3: Post Office Protocol = autorizzazione e download
• IMAP: Internet Mail Access Protocol
• HTTP: Si visualizza in browser

POP3

• S: +OK POP3 server ready
• C: list
• S: mess
• Autorizzazione
• +tok -ERR
• Senza stato
• C: qit
• S: 1 162 oct
• C: del 1
• C: quit

PROTOCOLLI SU CANALI AFFIDABILI - SECONDA PARTE

Per accorgerci se c’è stato almeno un errore avremmo bisogno di un feedback da parte del receiver

• ACK = OK
• NAK/NACK = NOK

Un ricevitore potrebbe non accorgersi che c’è un errore nella ricezione degli ACK/NAK

Se produrrà di riandare con il sender che rinvia il pkt a prescindere se l’ack/nak è corretto

Come se il receiver l’ha ricevuto il pkt a causa di un ack corrotto, come se è un nuovo pacchetto lo ricevono. Si numerano il pkt con 0-1 (1 bit, dipiù codiamo)

STOP AND WAIT Il sender invia un pacchetto e aspetta che il receiver risponde

Problema? E se il sender o non riceve gli ACK/NAK a cosa si rifessiamo, si aggiunge un bit

• E si rinvia solamente ACK (il nak non accertano)
• Se il sender o il receiver vedono attivare qualcosa che non accettano riceviano l’ultimo pikt ( 1 )

CON REDRIT la costruzione che abbiamo fatto finora non ci aiuta in caso di perdite pacchetti

Assumiamo di aver perso un ACK il sender aspetta per sempre senza inviare nulla

Si inserisce un timer, se sono nello stato di wait ed il timer scade, ritrasmetto

Ritrasmetto pikt inviato

Con questo metodo funzionale descrito finora (stop and wait) il problema ritornante diventa utilizzo del canale, perché l’RTT diventa rilevante rispetto al tempo di

trasmissione _L / ^R = length bit / Rate trasm

PIPELINED PROTOCOLS

I pacchetti vengono inviati in successione senza aspettare l’ack

GO BACK N Il sender può inviare massimo N pacchetti da inviare in pipeline di cui non conosce l’esisto (ACK)

Gli ack sono cumulativi (Ho ricevuto tutto fino a), esempio di pkt non ricevuti in ordine

Il receiver tiene nel timer per il più vecchio pkt inviato e non riscontrato

Se questo timer scade ritrasmette tutti i pk di pkt non riscontrato finora

al predecessors

SENDER La finestra ha dimensione N (non ammoso discontinui)

base = del pkt più vecchio non ancora riscontrato

nextseqnum = prossima X da inviare della req

Se dicevo qualcosa di corretto non fa nulla e aspetta che il timer scada

• allora scade reinvia tutto il pacchetti che aveva inviato senza ack

Se ricevo l’ack del pkt base, fermo il timer, se ne ho attivi un voto faccio partire un nuovo timer, altrimenti no

I^º credo dai battiglia di TCP e

link tra router, meno gli accodamenti e le code, se ci

sono, bisogno sempre

misurare i minimi, controllavo ogni invio se Ritturata è

rimaino

TCP VEGAS misura min e riduco

riado basso ma come calcolo rimaino

ECN: Explicit Congestion Notification Sviluppato per modificare i router

Si potrebbe ottenere informazioni migliorati, la rete mi fornisse info sullo stato di congestione

Esiste il Network-Assisted Congestion Control

E 26^th mezzo header IP (Compra ToS) che vengono scritte dai router

ed a destinazione, i viene notificato al sender nell'ack

ECN: 10

al 2 cam router incontra congestione modifica il campo con ECN=11

11=Congestione

e inviano gli altri router non modi Ricompis cofc comp o

Se il destinatario leggera ECN invierto in ECE om bit 0 se non congestionato, 1 o 2

se 1

e il mittente trovo cmptisce come ne di fosse stata una perdita

Si utilizzano 2 bit

perfetto potrebbero esercito il config:

BASSO, NUVO, MEDIO, ALTO

QUIC: Quick UDP Internet Connections

È un livello applicativo sopra UDP, che unito con HTTPS

formano HTTP/3

Adotta gli argomenti di comessione, errore di congestione e controllo di congestione

• Livello cifrativo

Utilizzata per foo stream remote UDP ofiffidabile

• Connection establishment

TCP

QUIC

TCP

QUIC TCP

2 cerical Handshake

1 Handshake

QUIC Handshake