Rieccomi con il secondo episodio di Internet, IP, TCP, UDP!
In questa puntata capiremo come funziona il protocollo UDP.
Innanzi tutto bisogna dire che è un protocollo a livello software. E ora vi spiego cosa significa
Un protocollo software è un protocollo implementato nel sistema operativo piuttosto che in una scheda di rete: se la vostra scehda di rete sa cos'è il protocollo IP, non sa cos'è il protocollo UDP.
Ques'ultimo non è altro che una serie di specifiche implementate nello stesso modo in ogni sistema operativo!
Se è unificato il modo di instaurare una connessione (IP), allora deve essere unificato il modo di comunicare (UDP, TCP, ICMP), altrimenti Windows non potrebbe comunicare con Mac OS X o con Linux anche se tutti e tre conoscono il protocollo IP.
Un po' come gli umani: tutti parlano con la bocca ma fino a che parlano lingue diverse non si può comunicare. Le corde vocali e le orecchie sono l'IP, la lingua (intesa come idioma, non come parte del corpo) è il protocollo a livello di software.
Se vogliamo essere più precisi, queste "lingue" andrebbero chiamate protocolli a livello di trasporto, ossia sono il modo in cui le informazioni viaggiano proprio a livello di bit.
Prima di spiegare come è strutturato il protocollo UDP vorrei fare un'ultima precisazione: c'è un altro modo di comunicare, senza seguire protocollo UDP o TCP o altro, ma inviando direttamente la sequenza di byte che si vuole mandare. Sono i RAW Sockets, il vantaggio è che per le soluzioni di sicurezza sono quelli più difficili da intercettare e soprattutto capire (non c'è niente con cui riconoscerli, come invece accade come vedremo per i pacchetti UDP o TCP), ma hanno lo svantaggio... di non avere i vantaggi dei protocolli più comuni (soprattutto TCP): l'affidabilità.
Ora passiamo alla vera e propria spiegazione.
Partiamo con un esempio: voglio mandare via UDP a 43.56.102.75 sulla porta 22345 la seguente sequenza di 4 interi a 8 bit (totale 4 byte)
(che non sono altro che i caratteri ASCII "C", "i", "a", "o")
Tramite il complicato percorso che abbiamo visto ieri il pacchetto arriva (forse, dato che il protocollo UDP non garantisce né che i pacchetti arrivino nell'ordine giusto né che arrivino asd) a destinazione.
Vediamo com'è strutturato:
Abbiamo 16 + 16 + 16 + 16 bit (64 bit, 8 byte) di header in cui è contenuta la porta di provenienza (opzionale!), la porta di destinazione (in modo che il sistema operativo possa consegnare il pacchetto al programma in ascolto su quella porta), la lunghezza del messaggio (in byte, compresi gli 8 byte dell'header), e il checksum di controllo dell'integrità (anche questo opzionale, tranne se usiamo la versione sei dell'IP, meglio conosciuto come IPv6).
Poi ci vanno i dati.
Quindi il nostro pacchetto finito sarà così (tralasciando porta di provenienza e checksum per semplicità):
[per facilitare la lettura sono andato a capo ogni 16 bit e ho lasciato uno spazio ogni 4 bit]
0000 0000 0000 0000 -> 0,
source port0101 0111 0100 1001 -> 22345,
destination port0000 0000 0000 1100 -> 12,
lunghezza0000 0000 0000 0000 -> 0,
checksum0100 0011 0110 1001 -> C, i
0110 0001 0110 1111 -> a, o
* DA FINIRE *Il sistema operativo, ricevuti questi dati, li consegna al programma in ascolto sulla porta 22345 o semplicemente li scarta se nessuno è in ascolto su quella porta.
Per fare la stessa cosa con un pacchetto TCP ci sarebbe voluto più tempo e il pacchetto sarebbe stato più grande, ma con TCP si ha la sicurezza che tutto andrà bene, che tutto
prima o poi arriverà se c'è un modo per farlo arrivare (cioè se in quel momento le due macchine sono accese e collegate in rete), e che arriverà in ordine.
Per questo UDP va bene in quei campi in cui se si perde un pacchetto ogni tanto l'errore viene compensato dai pacchetti successivi (giochi online, streaming audio/video...) mentre TCP va bene dove hai bisogno di assoluta affidabilità (invio di comandi, testo, file).
Per ora è tutto!
Come al solito, criticate, ditemi le vostre opinioni, ditemi se vi interessa approfondire qualcosa o se una parte non è chiara o troppo complicata!
Grazie.
Edited by ‡ (dd) - 22/1/2013, 12:56
(volevo provare 'sta emoticon asd)