corso reti ed applicazioni mauro campanellacmp/corsoreti/slides04/cap3-1.pdf · 2004-04-21 · data...

Capitolo 3 - parte 1

Corso Reti ed ApplicazioniMauro Campanella

M. Campanella Corso Reti ed Applicazioni - Como 2004 Cap 3 - 1 pag. 2

Agenda

- Le applicazioni per il Sig. Rossi- Lo strato di trasporto- Multiplexing/Demultiplexing- User Datagram Protocol (UDP)- Trasferimento affidabile


I servizi base per il Sig. Rossi

Necessità Server Client

Web Apache NetscapeProxy Squid -e-Mail sendmail, PostFix Eudora, Netscape,pineDNS (rossi.org) Bind -Database MySQL -Condivisione dischi NFS,Altro NFS, altroStampe Stampante in rete LPRFax Stampante in rete -Sistema Operativo Unix (Linux) Mac, Windows, LinuxVoce centralino + IP telefono + IPVideo vari (su IP) vari (su IP)Firewall Router, Ipchains -


Agenda



Indirizzamento Internet

Applicazione

Trasporto

IP

Data Link

Fisico

Numero di porta (da 0 a 1024 - “well known ports”-sono riservati - 1025-65535 liberi)

Numero di protocollo (assegnato da IANA)

L’indirizzo unico a livello mondiale dell’interfaccia,(in IPv4 intero, 32 bit, unsigned) scritto nella forma1.2.3.4

Indirizzo MAC o simile a seconda della tecnologia

Nulla


Indirizzamento

Applicazione

Socket

Porta, numero di processo, socket

Descrittore verso il sistemaPorta/indirizzo verso il trasporto

Trasporto Numero di protocollo

Rete Indirizzo IP

Una “socket” è: sia una interfaccia di programmazione, che la coppia (porta, indirizzo IP)


Protocolli Internet

IP porta pacchetti per vari protocolli, tra cui due fondamentaliper il trasporto end to end dei pacchetti.

ip 0 IP # internet protocol, pseudo protocolnumbericmp 1 ICMP # internet control message protocoligmp 2 IGMP # internet group management protocolggp 3 GGP # gateway-gateway protocolipencap 4 IP-ENCAP # IP encapsulated in IPtcp 6 TCP # transmission control protocolegp 8 EGP # exterior gateway protocoludp 17 UDP # user datagram protocolipv6 41 IPv6 # IPv6rsvp 46 RSVP # Resource ReSerVation Protocolgre 47 GRE # Generic Routing Encapsulationospf 89 OSPFIGP # Open Shortest Path First IGPpim 103 PIM # Protocol Independent Multicastisis 124 ISIS # ISIS over IPv4

http://www.iana.org/assignments/protocol-numbers


Lo strato di trasporto

applicazione

trasportotrasporto

rete (IP)

data link

fisico

E’ lo strato che si occupa di fornire unservizio di trasferimento dei dati dalnodo sorgente al nodo destinazione.

Normalmente viene richiesto untrasporto affidabile, efficente eindipendente dal comportamentodegli strati sottostanti


Il servizio di trasporto

Fornisce la comunicazione logica(orizzontale) fra applicazioni neidue nodi.

Internet offre due tipi di trasporto:

- TCP: affidabile, orientato alla connessione con controllo della congestione e di flusso

- UDP: non affidabile, senza connessione

Non offrono garanzie sui parametridi QoS (p.e. ritardo e capacità)

applicazionetrasporto

retedata link

fisico

retedata link

fisico

retedata link

fisico

retedata link

fisico

Trasporto logico end to end


retedata link

fisico

retedata link

fisico


Perché strato di trasporto e rete ?

I due strati svolgono funzioniapparentemente simili, cioèportare i messaggi generatidall’applicazione a destinazione

MAlo Strato di rete svolge il suocompito distribuito nei routerlo Strato di trasporto svolge ilcompito nei nodi iniziale eterminale indipendentementedalle prestazioni dello strato direte

Essenzialmente l’esistenza dellostrato di trasporto rendepossibile fornire un servizioglobale di trasporto piùaffidabile e sicuro di quello cheoffrirebbe da sola la rete erende l’applicazioneindipendente dalla tecnologia direte.

Per esempio nella rete esistonoerrori fisici nei pacchetti,duplicazioni, perdite …


Agenda



Multiplexing/demultiplexing

applicazione

trasporto

rete

data link

fisico

P1 application

trasporto

rete

data link

fisico

applicazione

trasporto

rete

data link

fisico

P2P3 P4P1

nodo 1 nodo 2 nodo 3

= processo= socket

Smistare i pacchetti alla socketcorretta usando l’header

Demultiplexing : alla ricezioneRaccogliere da tutte le socket,aggiungendo l’header.

Multiplexing : nel mittente

Nel nodi la porta è scelta diversa per ogni processo


Header

Ogni strato riceve dati e li passa dallo strato adiacente.Vi aggiunge (toglie) informazione specifica nella forma diun “header” e crea una nuova unità di informazione datrasmettere allo strato successivo.


retedata link

fisico


retedata link

fisico

sorgente destinazione

M

M

M

M

H t

H tH r

H tH rH l

M

M

M

M

Ht

HtHr

HtHrHl

messaggio

segmento

datagramma

frame


Demultiplexing

Nodo riceve il datagramma IP:– L’header del datagramma IP

contiene gli indirizzi sorgente edestinazione ed il protocollo

– l’header del segmento ditrasporto contiene le portesorgente e destinazione

– l’header del messaggio contieneinformazioni variabili per ogniapplicazione

Il nodo usa sia gli indirizzi IP che inumeri di porta per identificare lasocket corretta

sempre 32 bit

32 bit

IP destinazioneIP sorgente

altri header di datagramma

header di datagramma

altri header di segmento

porta sorg. porta dest.

header del messaggio

Dati applicazione


Anteprima formato datagramma IP

32 bits

vers. lunghezza totale

dati (lunghezza variabile)

identificatore 16-bit

Internet checksumtime to live

32 bit indirizzo IP sorgente

lungh.head.

tipo di servizioToS ora DSCP

flgs offset frammento

protocollo

32 bit indirizzo IP destinazione

Opzioni (se presenti)

0 8 16 24 3115

20byte


Demultiplexing

Nel demultiplexing, lo strato sottostante potrebbeeliminare tutta l’informazione nel suo header, inclusil’indirizzo IP e la porta sorgente o altri valori !

Esistono delle opzioni delle socket o il comportamentonormale del sistema operativo che permettonoall’applicazione di accedere o ricevere tali valori.

Questo permette anche ai server UDP di demultiplarefinemente i datagrammi ricevuti.


Demultiplexing con UDP

La socket crea automaticamentela porta o si forza la scelta:

DatagramSocket mySocket = newDatagramSocket();DatagramSocket mySocket = newDatagramSocket(9222);

La socket UDP è identificatadalla coppia:(IP , porta destinazione)

Il nodo ricevente:– controlla la porta di

destinazione– smista il datagramma su

quella portaDatagrammi con IP o portasorgente differenti sonoinviati alla stessa socket.

MA

in realtà sono usati sia lacoppia {IP,porta} sorgente,che quella di destinazione


Demultiplexing con UDP

DatagramSocket serverSocket = new DatagramSocket(6428);

clientIP:B

P3

client IP: A

P1P1P3

serverIP: C

SP: 6428DP: 9157

SP: 9157DP: 6428

SP: 6428DP: 5775

SP: 5775DP: 6428

SP nel datagramma prodotto dal client fornisce “l’indirizzo di ritorno”


Demultiplexing con TCP

La socket TCP è identificatadai quattro valori (4-tuple):

– indirizzo IP mittente– porta mittente– indirizzo IP destinatario– porta destinatario

Il nodo ricevente usa tutti equattro i valori per smistare ilsegmento alla socket corretta.

Un server può manteneremolte socket aperte:– ogni socket è identificata da

una quadrupla

I Web server hanno una socketdiversa per ogni client:– HTTP non-persistente deve

usare una socket per ognirichiesta (max 65536)


Connessioni contemporanee ?

Singola connessione dura 10 minuti (600 secondi), quanteSingola connessione dura 10 minuti (600 secondi), quantesono le connessioni al secondo massime che un web serversono le connessioni al secondo massime che un web serverpuò accettare ?può accettare ?

(65535 - 1024) / 600 secondi = 107 socket/secondo(65535 - 1024) / 600 secondi = 107 socket/secondo

Quanto tempo impiega un sistema a creare unQuanto tempo impiega un sistema a creare unsottoprocesso od un thread ?sottoprocesso od un thread ?

Quanta memoria serve per ogni thread ?Quanta memoria serve per ogni thread ?


Demultiplazione con TCP

P3

client IP: A

clientIP:B

P1P1

serverIP: C

P1Processo Server

S: A, 9157D: C, 80

P2

S: C, 80D: A, 9157

S: B, 5775D: C, 80

S: C, 80D: B, 5775

Sottoprocessoserver T1 Thread


Agenda



UDP: User Datagram Protocol

RFC 768 del 1980 (3 pagine)Definisce un trasportosemplice in cui ognioperazione di invio da partedell’applicazione produceesattamente undatagramma, mentre conTCP questo non è vero.

Non garantisce la consegnae quindi neanche altriparametri di qualità.

Vantaggi di UDP?

– senza connessione (ritardominimo quindi)

– semplice: nessuno stato nelmittente e nel ricevente

– header minimo– nessun controllo di

congestione o flusso: ipacchetti possono essereinviati costantemente allamassima velocità


Formato del segmento UDP

Usato spesso per applicazionimultimediali (voce, video)– tollerano la perdita di dati– isocrone

altre applicazioni su UDP– DNS– Simple Network Monitor

ProtocolSe l’applicazione desideraaffidabilità deve avereinternamente una parte dicontrollo e recupero errori.

porta sorg. porta dest.

32 bits

Dati dell’applicazione(messaggio)

Formato del segmento UDP

lunghezza checksum

Lunghezza,in bytes del

segmentoUDP incluso

l’header.Minimo 8

bytes (0 datiaccettabile)

8bytes


Datagramma IP + UDP

vers. lunghezza totale

dati

identificatore 16-bit

IP checksumtime to live


lungh.head.

tipo di servizioToS ora DSCP

flgs offset frammento

protocollo


Opzioni (se presenti)

0 8 16 24 3115

20byte

porta del mittente porta del destinatario

lunghezza totale UDP UDP checksum8

byte


Checksum

Mittente:– divide il segmento in

blocchi da 16 bit– somma i blocchi (senza

riporto finale)– ne fa il complemento ad 1– lo inserisce nel campo

checksum

Ricevente:Ricalcola il checksumincludendo il checksum stessosenza fare il complemento ad 1Il risultato sono tutti “1” ?– NO - errore– SI - nessun errore trovato

Scopo: scoprire “errori” (cioè bit cambiati) nel segmentotrasmesso.


Esempio di Checksum (8 bit)

Mittente:

10101000010100101000111000000000 checksum azzerato

10001000 somma

01110111 complemento ad 1 = checksum

Destinatario:

10101000010100101000111001110111

11111111 checksum OK


PseudoHeader Checkshum

dati

lunghezza UDPzero


protocollo


0 8 16 24 3115

UDPpseudoheader

porta del mittente porta del destinatario

lunghezza totale UDP UDP checksum

UDPheader

byte di pad


Checksum

Nel caso di una lunghezza in byte dispari del segmento, siaggiunge un byte di “pad” (completamento) di valore zero.

Il checksum è calcolato in modo tal che, se si deve cambiareanche un sola coppia di byte, basta sottrarre il vecchiovalore e sommare il nuovo, senza ricalcolare completamenteil checksum.

L’RFC non obbliga ad effettuare il calcolo del checksum, maè meglio che sia sempre abilitato.

Naturalmente non è in grado di correggere gli errori o dirivelare errori multipli …


Overhead e lunghezza massima

La massima lunghezza di un datagramma IP è di 65535 bytes(16 bit). Togliendo 20 bytes minimo di header IP ed 8 byteper quello UDP, rimangono 65507 byte di dati.28 byte sono l’overhead di protocollo, cioé la parte diinformazione trasmessa che non sono dati utente.

Ad utilizzare questa dimensione vi può essere una limitazione:– nelle socket nel dimensionare i buffer di UDP sia nel

mittente che nel ricevente– nella configurazione del kernel dello stack IP– nell’applicazione (ma meglio scritture di grandi blocchi dati)


Agenda



I problemi nella rete

Durante il tragitto di unpacchetto nella rete, ilpacchetto può:– subire errori a livello fisico– subire ritardi anche elevati– essere scartato per

congestione– essere consegnato in

ordine diverso rispettoall’emissione

Il canale di trasmissione puòessere inaffidabile ed esserecomposto da molte reti diversecon caratteristiche diverse.

Questo è il principio base diprogettazione di IP e quindil’affidabilità deve esseretrasportata allo stratosuperiore.


I problemi nella rete

Il protocollo deve quindi:– poter ritrasmettere e

ricordarsi ciò che devetrasmettere fino a certezzadella ricezione (buffer)

– avere dei timer– accorgersi della congestione– riordinare i segmenti– ricevere feedback dal nodo

destinatario (essereconnesso)

Dato che sarebbe complessoinserire il controllo diaffidabilità in ogniapplicazione, lo strato ditrasporto deve poter offrireun servizio affidabile.

Deve quindi garantire cheuna sequenza di byte inviatisiano ricevuti nello stessoordine e senza perdite

corso reti ed applicazioni mauro campanellacmp/corsoreti/slides04/cap3-1.pdf · 2004-04-21 · data...

Documents