Come funziona internet ?

Corso e Certificazione: Cisco CCNA

Come presentato nei capitoli 2-1.1.6.1-2 del Corso di Certificazione Cisco CCNA, definiamo Internet come l’insieme delle reti LAN e WAN private degli utenti finali e dei Provider, collegate dai vari tipi di WAN pubblica esistenti (collegamenti e circuiti, terrestri, sottomarini o satellitari, via cavo o via radio). Ciò crea un tessuto completamente connesso, in cui l’IETF-Internet Engineering Task Force governa gli standard e l’assegnazione degli indirizzi IPv4 e IPv6 per mantenere coerente l’insieme.

La trasmissione di un Pacchetto da un capo all’altro di Internet (end-to-end) è schematizzata nella seguente figura, che commentiamo. NB: Termini o concetti esposti di seguito quali: DNS, ARP, indirizzi IP e MAC…) – ampiamente affrontata all’interno del corso CCNA – non viene qui approfondita per motivi di spazio.

La Sorgente di un Pacchetto è un Host di qualche tipo, che decide di inviare dei dati ad un altro Host rispondente ad un certo URL-Uniform Resource Locator, come potrebbe essere una richiesta HTTP da un browser al Server web www.cisco.com.

L’Host mittente si deve dapprima procurare l’indirizzo IP pubblico del destinatario, e lo fa con una richiesta al Server DNS-Domain Name System che gli è stato configurato, perché traduca www.cisco.com nel corrispondente IP (198.133.219.25). Ciò si può esaminare anche manualmente col comando DOS/Windows (Start – Esegui – cmd):

• li imbusta (“incapsulamento” in senso lato, ne riparleremo) dapprima in Segmenti, a livello 4, con i numeri di Porta mittente e destinataria; quest’ultima (80) decisa dal Protocollo di livello 7 che genera i dati, che nel nostro caso è appunto HTTP-HyperText Transport Protocol
• ogni Segmento finisce in un Pacchetto, a livello 3, con l’IP del mittente e del destinatario (spesso l’IP del mittente è un indirizzo “privato”, che diventa “pubblico” prima di lasciare la LAN del mittente stesso, tramite un’operazione di NAT-Network Address Translation che vedremo… Ciò è necessario per ottenere una risposta dal destinatario, dato che gli indirizzi IP privati non circolano su Internet, e la risposta si perderebbe per strada)
• il Pacchetto viene incapsulato in una Trama (Frame), a livello 2, con gli indirizzi MAC (che studieremo) del mittente e del Default Gateway della LAN, essendo destinato ad un IP esterno alla LAN stessa. Il MAC del Default Gateway si ottiene, se non è già disponibile per utilizzi recenti, con una richiesta ARP-Address Resolution Protocol, in broadcast sulla LAN, che studieremo meglio più avanti. Come si vede, la Trama oltre che una Testata (Header) ha anche una Coda (Trailer), contenente un codice di controllo per verificarne la correttezza in arrivo
• finalmente la Trama viene trattata come pura sequenza di Bit dal livello 1, ed inviata sul mezzo fisico con la opportuna codifica elettrica (su rame), ottica (su fibra) o radio (via etere)
• la Trama è quindi ricevuta dall’interfaccia Ethernet del Gateway della LAN mittente, che è un Router, anche se banale (trivial). Infatti, avendo solo due interfacce, tale Router svolge un compito piuttosto facile: manda fuori ciò che arriva dall’interno, e dentro ciò che arriva da fuori. Comunque il Router estrae il Pacchetto dalla Trama Ethernet (che viene scartata), guarda l’IP destinatario e prende la sua decisione: il Pacchetto deve proseguire sull’interfaccia WAN!
• crea quindi una nuova Trama per l’interfaccia di uscita, mettiamo di tipo PPP-Point to Point Protocol (si noti il colore diverso da quella di arrivo, mentre il Pacchetto è lo stesso) e la inoltra sull’interfaccia collegata all’ISP, magari su un livello fisico ADSL. Si noti che il protocollo PPP non prevede l’uso di indirizzi di livello 2 come i MAC, dato che gli interlocutori sulla linea sono solo due, e non hanno bisogno di identificarsi ulteriormente
• così il Pacchetto, nella sua nuova Trama, arriva ad un altro Router intermedio di Internet, in figura rappresentato dal Router 2 (ce ne possono essere decine tra i due interlocutori, ed operano tutti come segue). Questo Router non è banale come il precedente, ma deve prendere una decisione vera: se il destinatario si raggiunga prima e meglio sull’interfaccia 2 o sulla 3. Per farlo, estrae il Pacchetto dalla Trama PPP, e confronta l’IP destinatario (immutato) con le “entries” della sua Routing Table: da qui decide che il “best path” passa dall’interfaccia 2! (Ci chiederemo, a suo tempo, chi abbia riempito la Routing Table con la preziosa informazione).
• reimbusta quindi il Pacchetto in una nuova Trama adatta a tale interfaccia, ad es. una Frame Relay, e lo fa proseguire su Internet, un salto dopo l’altro (hop by hop) finché non arriva al Gateway di ingresso/uscita (Router N) della rete destinataria
• questo è a sua volta un “trivial Router”, che prende la Trama in arrivo, ne estrae il Pacchetto e “decide” che deve inoltrarlo all’interno della LAN, sull’interfaccia Ethernet
• scopre però anche un’altra cosa interessante, a differenza di tutti i suoi predecessori: che la rete destinataria non è lontana, ma che risulta direttamente connessa (directly connected) alla sua interfaccia LAN. Quindi il Pacchetto ha finito la sua corsa, e deve essere inoltrato non ad un altro Router (next hop), ma all’Host destinatario
• si procura quindi il suo MAC (con una normale richiesta ARP, come già visto in partenza) ed incapsula il Pacchetto in una Trama (ultimo colore sulla destra della figura) col proprio MAC come mittente ed il MAC del Server come destinatario
• il Pacchetto giunge quindi al Server web 198.133.219.25, dove viene estratto dalla Trama Ethernet; il carico pagante del Pacchetto è un Segmento, destinato alla Porta 80. Dietro la Porta 80, su un Server web, sta sempre pronto un Demone HTTP (HTTP Daemon), che riceve la richiesta del browser mittente e prepara finalmente la sua risposta
• tale risposta viene spedita al mittente scambiando gli indirizzi IP della richiesta arrivata, e creando uno o più Pacchetti che intraprendono il percorso inverso
• non è detto che tutti i Router intermedi seguano a ritroso esattamente lo stesso percorso, come non è detto che in andata altri Pacchetti tra i due interlocutori facciano la stessa strada. Infatti le “rotte” (routes) presenti nelle Tabelle di routing possono variare nel tempo, in funzione di vari parametri: collegamenti (link) funzionanti o guasti, carico delle varie reti, tassi di errore rilevati o stimati, ritardi, e perfino condizioni commerciali (policy) variate tra i vari Provider!
• di fatto, Internet fa sempre “del suo meglio” (best effort) per portare i Pacchetti a destinazione, e ci riesce abbastanza bene, come ci mostra l’esperienza. Ma non si può a priori far conto su certi percorsi, né in realtà c’è motivo per farlo: pensano a tutto i Router!

Info [email protected]