L'ICMP è un meccanismo attraverso il quale i router e le utenze comunicano per rilevare eventuali problemi o comportamenti anomali che si sono verificati in rete. Il protocollo IP, in sé, non contiene nessuno strumento per poter riscontrare, da parte della stazione di origine e di quella di destinazione, la eventuale perdita di un pacchetto o il collasso di una rete.
L'ICMP consente, quindi, una comunicazione straordinaria tra router ed host rendendo possibile lo scambio di segnali di errore (o di controllo) attraverso le interfacce software dell'internet, senza però arrivare su fino al livello degli applicativi. L'ICMP è una parte necessaria ed integrante dell'IP ed è contenuto nell'area dati di un datagramma IP.
L'ICMP include:
- messaggi di source quench, che ritardano il rate di trasmissione
- messaggi di redirect, che richiedono ad un host di cambiare la propria tabella di routing
- messaggi di echo request/reply, che l'host può usare per determinare se la destinazione può essere raggiunta (ping).
Un ICMP possiede 3 campi di lunghezza fissa nella testa del messaggio:
- il type field (8 bits), che identifica il messaggio
- il code field (8 bits), che contiene informazioni circa il tipo del messaggio
- il checksum field (16 bits). I restanti campi del formato ICMP variano in base al tipo di messaggio.
UDP - User Datagram Protocol
E' un protocollo di trasporto che si colloca sopra l'Internet Protocol Layer (IP):
E' simile all'IP, ma oltre ai dati spediti, ciascun messaggio UDP contiene:
- il numero di porta di destinazione
- il numero della porta di origine
Ciò permette al software UDP di destinazione di recapitare il messaggio al corretto ricevente (programma o utenza) e a quest'ultimo di inviare una replica.
Il grado di inaffidabilità è quello propria dell'IP, nel senso che l'UDP non prevede nessun protocollo per il controllo dell'errore e, a differenza del TCP:
- non usa acknowledgement per assicurare al mittente che i messaggi siano effettivamente arrivati
- non dispone le sequenze di datagrammi in ordine
- non fornisce una retroazione per il controllo del rate del flusso di informazioni tra macchine.
Quindi i messaggi UDP possono essere persi, duplicati o arrivare fuori ordine.I datagrammi, inoltre, possono arrivare più velocemente di quanto il ricevente sia in grado di processarli.
Il protocollo UDP lavora bene in una rete locale, ma potrebbe fallire se usato in una rete di dimensioni maggiori. Esso fornisce un datagramma più utile di quello IP per i collegamenti fra utenze. Su tale base, infatti, è stato costruito l'applicativo Network File System (NFS) molto diffuso nelle reti locali. Ciascun messaggio UDP è definito come user datagram ed è costituito di due parti:
- UDP header
- UDP data area
che vengono incapsulate nell'IP datagram.
Come mostrato nella prossima figura, l'header del'UDP è simile a quello del TCP, ma:
- risulta essere più corto non avendo nessun numero di sequenza;
- è diviso in quattro campi di 16 bits, che specificano il numero di porta da cui il messaggio è stato spedito (opzionale), quello della porta di destinazione (usata per demultiplexare i datagrammi tra i processi che aspettano di riceverli), la lunghezza del messaggio ed il checksum.
Tutte le operazioni di multiplexing e di demultiplexing tra l'UDP ed i programmi applicativi avvengono attraverso il meccanismo delle porte. Praticamente, ciascun programma applicativo deve negoziare con il sistema operativo per ottenere una porta di protocollo e, con essa, il numero associato, prima che sia spedito un UDP datagram.
Assegnata la porta, ogni datagramma che il programma applicativo spedisce attraverso di essa avrà quel determinato numero di porta nel suo UDP source port field.
L'UDP accetta i datagrammi provenienti dal software IP e li demultiplexa in base alla UDP destination port, come mostrato in figura:
Porte del Protocollo UDP
I sistemi operativi della maggior parte degli elaboratori, permettono a più programmi applicativi di essere in esecuzione contemporaneamente (processes. tasks, application programs); tali sistemi sono definiti come sistemi multitasking.
Immaginiamo che ciascuna macchina contenga un set di punti di destinazione astratti, definiti protocol ports e identificati, ciascuno, da un intero positivo. Il sistema operativo locale fornisce un meccanismo di interfaccia che i processi usano per specificare una porta o accedere ad essa.
Generalmente, le porte sono bufferizzate, in modo che i dati arrivati prima che il processo sia pronto, non vengano persi. Per permettere il buffering, il software di protocollo del sistema operativo posiziona in una coda (finita) i pacchetti che arrivano per una particolare porta, finchè il processo non li estrae.
Per comunicare con una porta esterna, il mittente deve conoscere sia indirizzo IP che numero di porta di protocollo della macchina di destinazione. Ciascun messaggio deve contenere:
- il numero della Destination Port della macchina da cui il messaggio è spedito;
- il numero della Source Port della macchina mittente, a cui la replica dovrà essere indirizzata.
Ciò rende possibile, per ogni processo, il colloquio tra mittente e destinatario.
Ci sono due approcci per l'assegnazione delle porte:
- Il Central Authority in cui due macchine che devono interoperare tra di loro, si accordano per permettere a un'autorità centrale di assegnare i numeri di porta (Well-known ports) che sono necessari e di pubblicare la lista di tutte le assegnazioni (Universal assignment). Il software che gestisce le porte sarà realizzato in base a tale lista.
- Il Dynamic Binding - in questa modalità le porte non sono universalmente conosciute, nel caso che un programma necessiti di una porta, è il software di rete ad assegnarla. Per sapere la porta corrente assegnata su un altro macchina è necessario inviargli una richiesta del numero di porta assegnata al servizio di interesse.
I progettisti del TCP/IP usano un approccio ibrido che assegna alcuni numeri di porta a priori (Low values) e lascia altri disponibili per siti locali o programmi applicativi (High values).
La tabella seguente contiene alcune tra le più significative UDP well-known ports:
Fine della sesta parte
Commenti
Posta un commento