Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a.

Presentazione sul tema: "Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a."— Transcript della presentazione:

1 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 1 a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 1 Il livello di trasporto prof. G. Russo (grusso@unina.it) ing. A. Violetta (violetta@unina.it)©2008

2 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 2 Introduzione E’ il cuore dell’intera gerarchia di protocolli Compito: fornire comunicazioni affidabili e convenienti dal computer sorgente al computer destinatario, indipendentemente dalla rete fisica utilizzata Per assolvere questo compito, il livello di trasporto utilizza i servizi forniti dal livello di rete Gli utenti del livello di trasporto sono i processi del livello delle applicazioni

3 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 3 Obiettivo del livello di trasporto: Offrire un canale di comunicazione tra una coppia di processi (comunicazione point-to- point) Introduzione

4 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 4 Problemi posti dal livello inferiore (rete): perdita di messaggi riordino di messaggi inoltro di copie multiple dello stesso messaggio limitazione sulla dimensione dei messaggi inoltro di messaggi con un ritardo arbitrariamente lungo Requisiti richiesti dal livello superiore (applicazioni): garantire l’inoltro del messaggio rispettare l’ordine di invio dei messaggi inoltrare solo una copia di ogni messaggio supportare messaggi di lunghezza arbitraria consentire la sincronizzazione tra chi invia e chi riceve consentire a chi riceve di controllare il flusso dei messaggi del mittente supportare la presenza di processi multipli sullo stesso host Problemi e requisiti

5 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 5 Fornisce un servizio efficiente, affidabile e conveniente alle applicazioni (o al livello sessione) i servizi possono essere connessi o non connessi, proprio come al livello di rete Mette a disposizione funzioni di libreria per i programmi applicativi Gestisce il multiplexing del traffico di rete tra le varie applicazioni Servizi forniti ai livelli superiori

6 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 6 Esempio di interfaccia verso i programmi applicativi: Si basano su un insieme di primitive per rendere disponibile un punto di accesso al servizio per i client remoti aprire/chiudere una connessione scambiare dati Socket per TCP SocketCrea un punto iniziale/finale di comunicazione BindAssocia un indirizzo locale ad una socket ListenSi rende disponibile ad accettare connessioni AcceptSi blocca nell’attesa di una connessione ConnectTenta di stabilire una connessione SendInvia dati sulla connessione ReceiveRiceve dati dalla connessione CloseChiude la connessione

7 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 7 Socket per TCP Processo ServerProcesso Client 2 1 3 3 44 5 66 7 7

8 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 8 TSAP: Transport Service Access Point In Internet: coppie esempio: 158.110.1.2:23 (porta 23: telnet) Definiscono punti di accesso presso cui iprocessi possono attendere le connessioni Indirizzi del livello di trasporto Come conoscerli? noti a priori (le “well known ports” di TCP) elencati in un “name server” o “directory server”

9 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 9 Indirizzi del livello di trasporto Applicazioni Livello di trasporto Livelli 1,2,3

10 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 10 a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 10 Creare, chiudere e gestire Connessioni prof. G. Russo (grusso@unina.it) ing. A. Violetta (violetta@unina.it)©2008

11 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 11 Creare una connessione req ack Problema: se gli ack non arrivano in tempo, il mittente rispedisce i pacchetti, che arrivano duplicati, aprendo una nuova connessione parallela

12 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 12 Creare una connessione È necessario ridurre il massimo tempo di vita di un pacchetto (questo richiede un supporto da parte del livello rete, per esempio, il “time to live” di IP) A questo punto ogni connessione può numerare le proprie TPDU con numeri di sequenza differenti (ad esempio estratti da un orologio) Quando i numeri di sequenza vengono riutilizzati, le vecchie TPDU sono estinte

13 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 13 Chiudere una connessione Chiudere una connessione è più semplice che stabilirla, ma comunque qualche piccolo problema c'è anche in questa fase. In questo contesto, rilasciare la connessione significa che l'entità di trasporto rimuove le informazioni sulla connessione dalle proprie tabelle e informa l'utente di livello superiore che la connessione è chiusa. Ci sono due tipi di rilasci: asimmetrico; simmetrico.

14 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 14 Chiudere una connessione Asimmetrico: quando una delle due parti "mette giù" si chiude immediatamente la connessione. Ciò però può portare alla perdita di dati, in particolare di tutti quelli che l'altra parte ha inviato e non sono ancora arrivati. Simmetrico: si considera la connessione come una coppia di connessioni unidirezionali, che devono essere rilasciate indipendentemente. Quindi, lungo una direzione possono ancora scorrere dei dati anche se la connessione lungo l'altra direzione è stata chiusa. Il rilascio simmetrico è utile quando un processo sa esattamente quanti dati deve spedire, e quindi può autonomamente decidere quando rilasciare la sua connessione in uscita.

15 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 15 Questa operazione sembra facile ma non lo è, perché la subnet può perdere o duplicare (a causa di ritardi interni) dei pacchetti. Ad esempio, a causa di ripetuti ritardi nell'invio degli ack può succedere che vengano duplicati e successivamente arrivino in perfetto ordine a destinazione tutti i pacchetti precedentemente generati nel corso di una connessione. Ciò in linea di principio può significare che l'attivazione della connessione e tutto il suo svolgimento abbiano luogo due volte. Si immaginino le conseguenze di tale inconveniente se lo scopo di tale connessione fosse stato la richiesta (a una banca) di versare un miliardo sul conto di un personaggio dalla dubbia onestà. Gestione di una connessione

16 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 16 Il problema di fondo risiede nella possibile esistenza di duplicati ritardatari che arrivano a destinazione molto dopo essere partiti. Una volta che la connessione è stabilita, il problema non si pone. Infatti durante il setup della connessione le peer entity si accordano sul numero iniziale di sequenza, e quindi i doppioni ritardatari non vengono accettati. Viceversa, per risolvere il problema dei duplicati relativi alla fase di attivazione della connessione esiste una soluzione detta three-way handshaking. Gestione di una connessione

17 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 17 Il protocollo funziona così: il richiedente invia un TPDU di tipo conn.request con un numero x proposto come inizio della sequenza; il destinatario invia un TPDU di tipo ack contenente: la conferma di x; la proposte di un proprio numero y di inizio sequenza; il richiedente invia un TPDU di tipo dati contenente: i primi dati del dialogo; la conferma di y. I valori x e y possono essere generati, ad esempio, sfruttando l'orologio di sistema, in modo da avere valori ogni volta diversi. Three-way handshaking

18 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 18 Esempio: connessione in assenza di errori

19 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 19 Esempio: connessione in presenza di duplicati -1 Se arriva a destinazione un duplicato della richiesta di attivazione, il destinatario risponde come prima ma il mittente, che sa di non aver richiesto una seconda connessione, lo informa dell'errore

20 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 20 Se infine arrivano al destinatario sia un duplicato della richiesta di attivazione che un duplicato del primo TPDU dati, la situazione è la seguente: Esempio: connessione in presenza di duplicati -2

21 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 21 Esempio: connessione in presenza di duplicati -2 Infatti, in questo caso: il mittente invia un reject alla risposta del destinatario, perché sa di non aver richiesto una seconda connessione (come nel caso precedente); il destinatario scarta il TPDU dati, perché questo reca un ack relativo ad un numero di sequenza (z) precedente e non a quello (y) da lui testé inviato.

22 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 22 Il problema delle due armate La definizione del problema è la seguente: i due eserciti che compongono l'armata A sono ciascuno più debole dell'esercito che costituisce l'armata B; l'armata A però nel suo complesso è più forte dell'armata B; i due eserciti dell'armata A possono vincere solo se attaccano contemporaneamente; i messaggi fra gli eserciti dell'armata A sono portati da messaggeri che devono attraversare il territorio dell'armata B, dove possono essere catturati. Come fanno ad accordarsi gli eserciti dell'armata A sull'ora dell'attacco? Una possibilità è la seguente: il comandante dell'esercito 1 manda il messaggio "attacchiamo a mezzanotte. Siete d'accordo?"; il messaggio arriva, un ok di risposta parte e arriva a destinazione, ma il comandante dell'esercito 2 esita perché non può essere sicuro che la sua risposta sia arrivata.

23 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 23 Si potrebbe pensare di risolvere il problema con un passaggio in più (ossia con un three-way handshake): l'arrivo della risposta dell'esercito 2 deve essere a sua volta confermato. Ora però chi esita è il comandante dell'esercito 1, perché se tale conferma si perde, l'armata 2 non saprà che la sua conferma alla proposta di attaccare è arrivata e quindi non attaccherà. Aggiungere ulteriori passaggi non aiuta, perché c'è sempre un messaggio di conferma che è l'ultimo, e chi lo spedisce non può essere sicuro che sia arrivato. Dunque, non esiste soluzione. Il problema delle due armate

24 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 24 Per fortuna, rilasciare una connessione è meno critico che attaccare un'armata nemica. Quindi, qualche rischio si può anche prendere. Un protocollo di tipo three-way handshaking arricchito con la gestione di timeout è considerato adeguato, anche se non infallibile: il mittente invia un disconn.request e, se non arriva risposta entro un tempo prefissato (timeout), lo invia nuovamente per un massimo di n volte: appena arriva una risposta (disconn.request) rilascia la connessione in ingresso e invia un ack di conferma; se non arriva nessuna risposta, dopo l'ultimo timeout rilascia comunque la connessione in ingresso; il destinatario, quando riceve disconn.request, fa partire un timer, invia a sua volta un disconn.request e attende l'ack di conferma. Quando arriva l'ack o scade il timer, rilascia la connessione in ingresso. Il problema delle due armate

25 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 25 a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 25 Livello di trasporto in internet: TCP e UDP prof. G. Russo (grusso@unina.it) ing. A. Violetta (violetta@unina.it)©2008

26 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 26 TCP (Transmission Control Protocol): protocollo orientato alla connessione UDP (User Data Protocol): protocollo senza connessione I protocolli di trasporto

27 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 27 Fu progettato esplicitamente per fornire un flusso affidabile end-to-end a partire da un internet inaffidabile Ogni macchina che supporta TCP possiede un’entità di trasporto TCP che gestisce i flussi di dati TCP e si interfaccia col livello IP Un’entità TCP riceve flussi di dati dai processi locali, li spezza in unità larghe al più 64 KB (ma generalmente di circa 1500 byte) e spedisce queste unità come datagram IP separate Ogni datagram che arriva al destinatario viene passato all’entità TCP che ricostruisce il flusso originario dei dati Il livello IP non fornisce alcuna garanzia sulla consegna corretta dei datagram: quindi è compito di TCP ritrasmetterli quando necessario TCP

28 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 28 TCP Il servizio di TCP si ottiene mediante la creazione, da parte dell’utente e del ricevente, di punti di accesso (socket) Ogni socket è caratterizzato da un identificatore (indirizzo), consistente nell’indirizzo IP dell’host, e di un numero di 16 bit locale all’host, detto porta Una porta è una Transport Service Access Point (TSAP) Un socket può essere utilizzato contemporaneamente da più connessioni Una connessione è caratterizzata dai socket degli interlocutori, cioè dalla coppia (s1, s2) Le porte inferiori alla 256 sono chiamate porte ben note, e vengono usate per servizi standard Ad es., nell’ambito di un processo di scambio file (FTP) TCP usa la porta 21, per il login remoto (TELNET) usa la porta 23 Le connessioni TCP sono full duplex, punto-a-punto e non sono supportati multicasting e broadcasting

29 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 29 TCP trasferisce flussi di dati e non di messaggi. Ovvero TCP non ha idea del significato dei byte trasmessi, e di come vanno letti Quando un processo passa dati a TCP, questi potrebbe spedirli immediatamente oppure salvarli in un buffer per un invio successivo (magari insieme ad altri dati) E’ possibile forzare l’invio immediato dei dati usando il flag PUSH Dati urgenti: vengono inviati in seguito all’utilizzo del flag URGENT TCP : Il modello del servizio

30 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 30 Le entità TCP mittente e ricevente si scambiano dati sotto forma di segmenti Un segmento consiste in un preambolo fisso di 20 byte (più alcune parti opzionali) seguito da 0 o più byte di dati Il software TCP decide la dimensione dei segmenti Limite 1: ogni segmento, preambolo incluso, deve entrare in un pacchetto IP di 65536 byte Limite 2: ogni rete possiede un Maximum Transfer Unit (MTU, lungo generalmente poche migliaia di byte) e ogni segmento deve entrare in un MTU Un segmento può arrivare ad una rete con un MTU più piccolo della dimensione del segmento: in questo caso il segmento viene frammentato dal router di confine della rete TCP : Il protocollo

31 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 31 Ogni byte di una connessione TCP possiede un proprio numero di sequenza Al momento di trasmettere un segmento, il mittente inizializza un timer Quando il segmento arriva a destinazione, il ricevente spedisce indietro un segmento che contiene un numero di ack (conferma di ricezione) uguale al successivo numero di sequenza che attende di ricevere Se il timer del mittente scade prima che il messaggio sia ricevuto, il segmento viene ritrasmesso TCP : Il protocollo

32 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 32 Header TCP Source port,destination port: identificano gli end point (locali ai due host) della connessione. Essi, assieme ai corrispondenti numeri IP, formano i due TSAP. Sequence number: il numero d'ordine del primo byte contenuto nel campo dati. Ack. Number: il numero d'ordine del prossimo byte aspettato. TCP header length: quante parole di 32 bit ci sono nell'header (necessario perché il campo options è di dimensione variabile). URG: 1 se urgent pointer è usato, 0 altrimenti. ACK: 1 se l'ack number è valido (cioè se si convoglia un ack), 0 altrimenti.

33 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 33 PSH: dati urgenti (pushed data), da consegnare senza aspettare che il buffer si riempia. RST: richiesta di reset della connessione (ci sono problemi!). SYN: usato nella fase di setup della connessione:SYN=1 ACK=0 richiesta connessione;SYN=1 ACK=1 accettata connessione. FIN: usato per rilasciare una connessione. Header TCP

34 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 34 Window size: il controllo di flusso è di tipo sliding window di dimensione variabile. Window size dice quanti byte possono essere spediti a partire da quello (compreso) che viene confermato con l'ack number. Un valore zero significa: fermati per un pò, riprenderai quando ti arriverà un uguale ack number con un valore di window size diverso da zero. Checksum: simile a quello di IP; il calcolo include uno pseudoheader. Urgent pointer: puntatore ai dati urgenti. Options: fra le più importanti, negoziabili al setup:dimensione massima dei segmenti da spedire;uso di selective repeat invece che go-back-n;uso di NAK. Header TCP

35 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 35 Le porte del TCP sono molto più complesse rispetto a quelle dell'UDP, perchè un dato numero di porta non corrisponde ad un singolo oggetto. Infatti nel TCP gli oggetti da identificare sono delle connessioni di circuito virtuali tra due programmi applicativi, e non delle particolari porte. Il TCP usa la connessione, e non la porta di protocollo, come sua fondamentale astrazione; le connessioni sono identificate da una coppia di end points, ognuno dei quali è costituito da due interi host,port, dove l'host è l'indirizzo IP dell'host e port è il numero di porta TCP su quell'host (per esempio: l'end point 128.10.2.3,25 specifica la porta 25 sulla macchina di indirizzo 128.10.2.3). Poichè il TCP identifica una connessione con una coppia di valori, uno dato numero di porta può essere condiviso da più connessioni su una stessa macchina, senza che si crei ambiguità. Perciò la macchina identificata da 128.10.2.3,53 può comunicare simultaneamente con le macchine identificate da 128.2.254.139,1184 e 128.9.0.32,1184. Si possono così creare servizi concorrenti con connessioni multiple simultanee, senza dover riservare un numero di porta locale per ogni connessione. Per esempio, alcuni sistemi forniscono un accesso concorrente al loro servizio di posta elettronica, permettendo a più utenti di spedire un E-mail contemporaneamente. Le porte TCP

36 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 36 Le porte TCP Ci sono due fondamentali approcci per l'assegnazione delle porte, usando: Central Authority: due computers che devono interoperare tra di loro, si accordano per permettere ad un'autorità centrale di assegnare i numeri di porta (Well-known ports) che necessitano e di pubblicare la lista di tutte le assegnazioni (Universal assignment) il software che gestisce le porte sarà realizzato in base a tale lista. Dynamic Binding: in questo approccio le porte non sono universalmente conosciute; infatti, se un programma necessita di una porta, è il software di rete ad assegnargliela. Per sapere la porta corrente assegnata su un altro computer, è necessario inviargli una richiesta del numero di porta assegnata al servizio di interesse.

37 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 37 Le porte TCP DecimalKeywordUNIX KeywordDescription 7ECHOechoEcho 9DISCARDdiscardDiscard 11USERSsystatActive Users 20FTP-DATAftp-dataFile Transfer Protocol (data) 21FTPftpFile Transfer Protocol 23TELNETtelnetTerminal connection 25SMTPsmtpSimple Mail Transport Protocol 42NAMESERVERnameHost Name Server 43NICNAMEwhoisWho is 53DOMAINnameserverDomain Name Server Tabella well-Know port TCP

38 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 38 UDP Lo User Datagram Protocol (UDP) è definito in RFC 768 UDP è un servizio del livello di trasporto di Internet UDP è un servizio senza connessione UDP non è un protocollo affidabile UDP si basa sul protocollo di rete IP UDP offre un servizio del tipo best effort

39 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 39 UDP Il servizio UDP offre i seguenti vantaggi: non viene creata alcuna connessione un messaggio viene inviato direttamente al nodo senza scambio preliminare di pacchetti per sincronizzare i due partecipanti alla comunicazione quindi l’UDP non introduce nessun ritardo per impostare la comunicazione nessuno stato della connessione non dovendo memorizzare informazioni per la connessione, un server UDP può supportare un numero maggiore di client attivi poco sovraccarico dovuto alla dimensione dell’intestazione essendo minimale, di soli 8 byte, l’intestazione UDP introduce un aggravio nel consumo di banda che è solitamente trascurabile – controllo di livello applicativo più fine i messaggi vengono inoltrati non appena richiesto di farlo la mancanza di controllo di flusso e di congestione permette all’applicazione di controllare quando e con che ritmo inviare i messaggi

40 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 40 UDP Per i suoi vantaggi, UDP viene impiegato da molti protocolli di livello applicativo: nella maggior parte dei casi, il vantaggio decisivo è la velocità combinata alla possibilità di poter eventualmente perdere piccole quantità di dati senza particolari conseguenze

41 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 41 Header UDP Il segmento UDP è composto da due parti: l’intestazione ed il corpo: Il corpo contiene i dati ed ha una lunghezza massima teorica di 65535 byte L’intestazione è composta da quattro campi, ciascuno di 16 bit

42 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 42 Header UDP I campi dell’intestazione sono: Source port number: numero di porta sorgente Destination port number: numero di porta destinazione UDP lenght: lunghezza del corpo in byte UDP Checksum: codice di controllo per gli errori di trasmissione (checksum)

43 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 43 Per verificare l’integrità di un segmento, il protocollo UDP calcola un valore hash, detto checksum, a partire dal contenuto completo del segmento stesso. Il checksum viene calcolato sia sui dati che sull’intestazione. Il checksum è un valore hash: piccole variazioni nel contenuto del segmento modificano sensibilmente il valore di checksum il valore di checksum permette di controllare la presenza di errori di trasmissione Un valore di checksum corretto non significa che il pacchetto sia integro, ma piuttosto che il pacchetto ha una probabilità insignificante di essere errato. Il controllo di integrità confronta il valore di checksum calcolato dal trasmittente con quello calcolato dal ricevente UDP : calcolo dell’integrità

44 Università degli Studi di Napoli “Federico II” Facoltà di Scienze MM. FF. NN. – Sez. Informatica Sistemi per l’Elaborazione dell’Informazione: RETI a.a. 2008-2009 prof. Guido Russo – ing. Angelo Violetta 44 Le porte UDP Tabella porte well-know UDP DecimalKeywordUNIX KeywordDescription 7ECHOechoEcho 9DISCARDdiscardDiscard 11USERSsystatActive Users 42NAMESERVERnameHost Name Server 43NICNAMEwhoisWho is 53DOMAINnameserverDomain Name Server 69TFTPtftpTrivial File Transfer