TCP/IP

Spread the love

In questa sezione affrontiamo un po’ più a fondo la struttura del protocollo TCP/IP. Innanzitutto ricordiamo che è una versione semplificata del modello OSI che prevede solo 4 strati (anziché 7):

  • Applicazione
  • Trasporto
  • Internet
  • Fisico

Cosa vuol dire? vuol dire che per scrivere un programma per internet non serve fare un mega software che comprende tutto, dalla UI al driver per la scheda wireless, ma ci si può concentrare solo sull’aspetto che in genere riguarda solamente il livello applicazione (a meno che l’applicazione che stiamo scrivendo sia in realtà un sistema operativo o anche solo una sua libreria). Per tutto il resto, sono ormai 50 anni che si scrive software per la rete e c’è già un bel po’ di roba che si può riutilizzare, funziona e di cui non ci dobbiamo preoccupare.

Il problema però è più di tipo culturale. Avere a che fare con una scatola nera sotto i nostri piedi è sempre tra il frustrante e l’ansiogeno. Appena qualcosa non va ci sentiamo impotenti e incapaci e ci sentiamo obbligati ad andare con il cappello in mano dal sistemista guru di turno a chiedere umilmente oracoli.

Questo è uno stato d’animo che conosco molto bene, non arrivo come formazione da una laurea in informatica e comunque mi sono perso moltissimi passaggi.

Grosso modo possiamo pensare che lo strato applicazione sia il software che scriviamo noi, gli strati trasporto e internet siano programmi/librerie del sistema operativo e il livello fisico sia il firmware delle schede di rete.

Cominciamo a imparare come viaggia un pacchetto di dati dall’applicazione che sitiamo usando (di solito il browser) al server web.

Multiplexing e demultiplexing

È il nome che diamo alle operazioni di trasferimento di un datagramma tra protocolli, su e giù per lo stack TCP/IP.

Come avviene il passaggio del dato fino alla rete, il trasferimento lungo internet e, una volta dalla parte opposta della rete, la risalita dello stack fino al web server?

Breve iter per exempla.

Teniamo a mente com’è nata questa architettura dalle parole di Jon Postel nella sezione che gli abbiamo dedicato.

Se invoco con il brower http://www.google.com sto inviando in rete un comando (applicazione) HTTP/GET questo comando dovrà attraversare Internet e giungere al web server di Google che è l’applicazione in ascolto dall’altra parte del “cavo”.

L’operazione di immersione del comando dell’applicazione allo strato IP (network) è detta multiplexing e viene svolta dal sistema operativo in cui gira il browser, mentre l’operazione inversa di emersione del pacchetto IP verso al corretto protocollo (TCP) e alla corretta applicazione (www) è detta demultiplexing e viene svolta dal sistema operativo del server. Poi per la risposta si ribalta il flusso e si rifà tutto in senso contrario.

Dunque l’applicazione chiama il corretto protocollo di trasporto (TCP in questo caso) codificandolo nel pacchetto con il 6 (che è il numero del TCP) e contrassegna l’applicazione con il numero 80, comunemente detto numero di porta che non è altro che un codice per identificare l’applicazione a cui consegnare il pacchetto.

All’arrivo, IP usa il numero di protocollo per identificare a quela protocollo consegnare il datagramma (tcp=6) e infiine TCP utilizza il numero di porta per identificare l’applicazione a cui consegnare il dato (http=80)

La codifica di protocolli (ad uso del protocollo IP) e porte (ad uso del protocollo TCP) si trovano in due file, rispettivamente /etc/protocols e /etc/services. Ne riporto alcuni per curiosità:

$ cat /etc/protocols
ip       0   IP        # internet protocol, pseudo protocol number
hopopt   0   HOPOPT    # IPv6 Hop-by-Hop Option [RFC1883]
icmp     1   ICMP      # internet control message protocol
igmp     2   IGMP      # Internet Group Management
ggp      3   GGP       # gateway-gateway protocol
ipencap  4   IP-ENCAP  # IP encapsulated in IP (officially ``IP'')
st       5   ST        # ST datagram mode
tcp      6   TCP       # transmission control protocol
egp      8   EGP       # exterior gateway protocol
igp      9   IGP       # any private interior gateway (Cisco)
pup      12  PUP       # PARC universal packet protocol
udp      17  UDP       # user datagram protocol
...
$ cat /etc/services
tcpmux       1/tcp      # TCP port service multiplexer
echo         7/tcp
echo         7/udp
discard      9/tcp        sink null
discard      9/udp        sink null
systat      11/tcp        users
daytime     13/tcp
daytime     13/udp
netstat     15/tcp
ftp-data    20/tcp
ftp         21/tcp
fsp         21/udp        fspd
ssh         22/tcp      # SSH Remote Login Protocol
telnet      23/tcp
smtp        25/tcp        mail
time        37/tcp        timserver
time        37/udp        timserver
rlp         39/udp        resource   # resource location
nameserver  42/tcp        name       # IEN 116
whois       43/tcp        nicname
tftp        69/udp
gopher      70/tcp      # Internet Gopher
finger      79/tcp
http        80/tcp        www        # WorldWideWeb HTTP
...

Attenzione: non è detto che il protocollo dello strato trasporto debba essere per forza TCP: esistono (basta leggere la lista qui sopra) altri protocolli come UDP (che per esempio è quello usato quando si interrogano i DNS) o ICMP (quello che si usa quando si utilizza il comando ping) che sono un po’ meno sofisticati di TCP ma la cui funzione si situa allo stesso livello.

TCP gestisce la comunicazione tramite 2 coppie di numeri che rappresentano il filo che stabisce la comunicazione tra client e server: l’indirizzo IP e il numero di porta del client e l’indirizzo ed il numero di porta del server. Generalmente il numero di porta del server è fisso ed è determinato dalla tabella sopra (a meno che non definiamo noi una porta server diversa non standard come accade quando abbiamo diversi web server in ascolto: Apache, Tomcat, WebSphere ecc.) mentre il numero di porta client è un numero pseudocasuale stabilito da TCP al collegamento.

L’insieme {indirizzo IP, numero di porta} si chiama socket.

Ed è proprio la presa (socket) a cui attacchiamo la spina (plug) tramite il filo, pensiamo ai fili che gli operatori dei centralini telefonici di una volta attaccavano alla griglia di boccole per mettere in contatto gli utenti prima dell’avvento della teleselezione. È probabile che chi sta leggendo queste righe non fosse ancora nato quando non c’era la teleselezione, forse nemmeno io l’ho vista ma l’esempio è calzante.