#172 – Il protocollo TCP

Pillole di Bit

Lo si vede nelle impostazioni della rete del computer e nelle configurazioni del router. Due parole du come funziona e come è composto, bit per bit. Oggi si va nel profondo

• Vedere per bene come è fatto l'header del segmento TCP
• La puntata 36 sull'IP
• Il caricatore Wireless LIVBOJ di IKEA

Pillole di Bit (https://www.pilloledib.it/) è un podcast indipendente realizzato da Francesco Tucci, se vuoi metterti con contatto con me puoi scegliere tra diverse piattaforme: - Telegram (o anche solo il canale dedicato solo ai commenti delle puntate) - TikTok (per ora è un esperimento) - Twitter - BlueSky - Il mio blog personale ilTucci.com - Il mio canale telegram personale Le Cose - Mastodon personale - Mastodon del podcast - la mail (se mi vuoi scrivere in modo diretto e vuoi avere più spazio per il tuo messaggio) Rispondo sempre Se questo podcast ti piace, puoi contribuire alla sue realizzazione! Con una donazione diretta: - Singola con Satispay - Singola o ricorrente con Paypal Usando i link sponsorizzati - Con un acquisto su Amazon (accedi a questo link e metti le cose che vuoi nel carrello) - Attivando uno dei servizi di Ehiweb - Iscrivendoti a FiscoZen, se hai la Partita IVA (prima consulenza gratuita e 50€ di sconto sul primo anno) Se hai donato più di 5€ ricordati di compilare il form per ricevere i gadget!

Il sito è gentilmente hostato da ThirdEye (scrivete a domini AT thirdeye.it), un ottimo servizio che vi consiglio caldamente e il podcast è montato con gioia con PODucer, un software per Mac di Alex Raccuglia

Il sito è gentilmente hostato da ThirdEye (scrivete a domini AT thirdeye.it), un ottimo servizio che vi consiglio caldamente e il podcast è montato con gioia con PODucer, un software per Mac di Alex Raccuglia

Ciao a tutti e bentornati all’ascolto di Pillole di Bit, questa è la puntata 172 e io sono, come sempre, Francesco. Oggi torniamo a parlare di reti, e andiamo ad analizzare un acronimo che sentiamo spesso nominare e vediamo molto spesso nella configurazione della rete del PC e del nostro router. Quando apriamo le configurazioni di rete del PC, vediamo spesso le impostazioni TCP/IP. Quando invece dobbiamo aprire qualche porta sul router, attività da fare sempre con attenzione, sono dovuto intervenire non molto tempo fa su un NAS completamente crittografato perché era esposto su Internet tramite il router di casa e aveva una vulnerabilità, dobbiamo scegliere se aprire la porta sul protocollo TCP o UDP. Oggi vi parlo del protocollo TCP che sta per Transmission Control Protocol. E’ un protocollo che si posiziona all’interno dello stack ISO OSI delle reti al livello 4, del trasporto, ed è, come abbiamo detto prima, usato in abbinata con il protocollo IP, Internet Protocol che è il livello 3, detto livello di rete. Del protocollo IP ho parlato nella lontana puntata 36. IP assegna gli indirizzi, TCP, fa girare i dati. Detto in modo estremamente semplicistico. Partiamo da come è fatto un pacchetto del TCP, detto segmento. Essendo composto da bit, è diviso in gruppi di bit, come gli indirizzi IP, chiamati ottetti, ma sono sempre byte, quindi otto bit. I primi 4 byte sono le porte del client, quindi di chi chiede la connessione e del server, di chi accetta la connessione. Sono due byte per porta, per questo le porte sono da 0 a 65535 e sono qulle che a voi servono sul router per l’apertura per i vari protocolli particolari, che sono sullo strato più alto. FTP, per esempio, si appoggia su TCP e usa la porta 21 del server, SSH, usa sempre TCP e usa la porta 22 e così via. Ogni coppia di porte identifica una comunicazione, quindi se vi collegate alla porta 21 di un server FTP non è detto che la vostra porta di partenza sia per forza la 21. I 4 byte successivi sono quelli che identificano la sequenza del segmento. Quando i segmenti vengono composti, ognuno di essi ha un numero di sequenza, il numeratore è grande 4 byte, facendo un rapido conto i segmenti possono essere 2 elevato a 32, quasi 4 miliardi e 300 milioni. Il contatore dei segmenti è importante. Il ricevente ne tiene conto, se arriva un segmento di un numero che non si aspetta si comporta di conseguenza. Parliamo con un esempio che è tutto più facile. Il server ha ricevuto il segmento 100, si aspetta il 101. Invece gli arriva il 98, che ha già ricevuto. Potrebbe succedere e, per evitare di mettere in difficoltà l’applicazione che sta al livello più alto, lo scarta e non glielo manda neanche. Gli arriva il 110. Non lo ha ancora ricevuto, ma non gli serve in questo momento, lui vuole il 101, se lo tiene da parte e aspetta il successivo. Quando avrà il 101, lo passerà all’applicazione, quando arriverà, nell’ordine, il 109, passerà all’applicazione il 109 e il 110 che aveva già messo da parte. Davvero capita che arrivano i pacchetti in disordine? Capita, certo che capita! Capita che nel mondo delle reti, i pacchetti di una stessa trasmissione facciano giri completamente diversi tra origine e destinazione, quindi i tempi di consegna siano diversi. In una determinata modalità di trasmissione il cliente e il server possono anche scambiarsi un ulteriore contatore che dice, guarda, adesso mi aspetto questo pacchetto, questo contatore è inserito nei 4 byte successivi. I 4 byte ancora successivi sono divertenti. Per noi interessati di questa roba ovviamente. Ci sono 4 bit che indicano quanto è grande tutto il pacchetto di intestazione del segmento TCP, perché con alcune opzioni, potrebbe variare Gli altri 4 non sono in uso, perché chi pensa ai protocolli, pensa anche a sviluppi futuri e ha lasciato lo spazio per possibili evoluzioni. Poi ce ne sono altri 8 che sono come dei piccoli interruttori, che a seconda del loro stato, 0 o 1, attivano o disattivano delle opzioni, non vado così nel dettaglio, vi dico solo che il penultimo, se impostato a 1 vuol dire “ok, voglio iniziare una trasmissione”, l’ultimo, se impostato a 1, vuol dire “voglio chiudere questa trasmissione” Altri 2 byte indicano quanti byte è in grado di ricevere il mittente Non disperate, il segmento è quasi finito. Prima dei dati, i due byte più interessanti sono quelli del checksum che servono per controllare che il segmento sia arrivato corretto e che non serve richiederne la ritrasmissione. Qui ci fermiamo un attimo a capire perché questa cosa è importante. Avete presente il gioco del telefono senza fili? Se la frase di partenza è “l’ape regina ha invitato sua cugina in cucina”, alla fine dopo qualche decina di passaggi a destinazione arriva “la cugina mangia la torta della zia col miele della regina” In informatica questa cosa non è accettabile. Se devo trasferire un file composto da qualche milione di bit, è necessario che tutti questi bit, come partono così devono arrivare. Tutti, nessuno escluso. Visto che nel viaggio il rischio di corruzione dei dati è elevato, ci va un controllo che permetta di capire se il segmento è arrivato integro o no. Nelle trasmissioni seriali, di pochi bit per volta c’è il bit di parità, io trasmetto un byte di 8 bit il primo mi dice quanti sono i bit a 1, se sono pari questo è settato a 1, se sono dispari, questo è settato a zero. Se c’è un errore, il bit di parità mi dà l’informazione errata e quindi sò c’è il dato è corrotto, non so dove, ma so che lo è. Se ci sono due errori potrei non accorgermene, ma non è questo il momento di discuterne. I due byte di checksum servono a questo, attraverso un complesso algoritmo, il ricevente è in grado di controllare se tutto il segmento è arrivato integro oppure no, se non lo è il protocollo è fatto in modo tale che il destinatario chiede al mittente la trasmissione dell’intero segmento. Visto che ogni segmento è numerato è facile sapere qualche chiedere. Finito tutto l’header, cioè la testata del segmento, c’è il vero contenuto del pacchetto. Qui arriviamo a capire del perché si usa una certa parola nel gergo comune. Se l’header del pacchetto pesa nella trasmissione 16 byte e io devo trasmettere 10 byte, ho più header che dati. Per definire questo spreco di banda si usa il termine di overhead, che poi è declinato in quelle cose dove i convenevoli sono più lunghi e pesanti della vera comunicazione. Come avviene la comunicazione dei segmenti tra client e server? Con il cosiddetto handshake a 3 fasi. Il client contatta il server e gli dice “ciao, voglio comunicare con te”, gli manda un pacchetto di SYN Il server gli risponde “ok, comunichiamo”, gli manda il pacchetto di ACK+SYN Intanto si sono scambiati i contatori dei pacchetti che si susseguiranno nella trasmissione Il client allora invia un terzo messaggio “yee, che bello”, con il pacchetto di ACK. A questo punto inizia la trasmissione. La trasmissione, con tutte le regole che abbiamo detto prima, si instaura su un socket, composto da due coppie di IP e porta, quella del client e quella del server, questo permette al server di poter gestire più socket contemporaneamente anche sulla stessa porta in ascolto. Infatti un server web, ad esempio, è in ascolto solo sulla porta 443, quella dell’https, ma può servire molte richieste contemporaneamente e non solo una per volta. Server dell’INPS a parte, a quanto pare. Il protocollo TCP poi ha una miriade di sistemi per gestire i ritardi, gli errori, le ritrasmissioni, i timeout e un sacco di cose che possono succedere durante la trasmissione dei dati, ma direi che questo non è un corso di laurea sulle reti e quindi ci possiamo anche fermare qui. Solo un dettaglio aggiuntivo: nel segmento, se ve ne siete accorti, manca l’indirizzo IP di partenza e l’indirizzo IP di arrivo. Come mai? Perché questi dati fanno parte del protocollo sottostante, che è il protocollo IP, che a sua volta ha un header, dentro il quale ci saranno queste e altre informazioni. Poi si scenderà ancora, al livello MAC, dove il pacchetto che viaggia dovrà spostarsi tra una scheda di rete e un’altra e quindi dovrà sapere tra quali MAC address dovrà essere spostato, altro header che viene messo all’esterno degli altri due. Le reti sono così, tutte incapsulate, man mano che si scende i dati sono incapsulati all’interno della struttura del livello più basso. Parlare di reti è sempre molto interessante, perché nel mondo i dati viaggiano su di esse, dal bit che passa su un filo di rame, su una fibra ottica o nell’etere fino al formarsi di strutture dati organizzate che portano qualunque tipo di informazioni da una parte all’altra del globo. Prossimamente parleremo anche degli strati più bassi delle reti, perché sotto al TCP c’è l’IP, poi si scende ancora fino al livello fisico e si scoprono cose molto interessanti, un po’ come quando si entra in un batiscafo e si esplorano le profondità dei mari. I contatti Come potete contattarmi e interagire con la community del podcast? In un sacco di modi! E’ tutto indicato sul sito www.pilloledib.it col punto prima dell’it, hostato da Thirdeye, se volete mettere anche voi il vostro sito, scrivete a [e-mail]. Sul sito ci sono sempre tutti i link di cui parlo in puntata, quindi potete stare tranquilli che li recuperate tutti. Mi trovate su Twitter con gli account pilloledibit o il mio personale cesco_78. Per scrivere cose più dirette e più lunghe c’è la mail [e-mail]. La community la trovate sul nuovo forum https://extra.pilloledib.it/forum o sul gruppo Telegram, io, personialmente, preferisco il forum. Se il podcast vi piace potreste pensare a una donazione singola o un abbonamento con importo a scelta, tutte le istruzioni sono sul sito. Potete donare senza spendere, usando i link sponsorizzati di Amazon, che trovate qua e là sul sito. Si può anche sponsorizzare una puntata di Pillole di Bit, le informazioni sono alla pagina https://pilloledib.it/sponsor E se vi serve una consulenza tecnica informatica, un sito, un e-commerce o altro, tutto fatturato, potete informarvi su www.iltucci.com/consulenza Se non ve ne siete ancora accorti faccio un nuovo podcast, con uscita irregolare e parla di videogiochi, se vi interessa lo trovate su https://pilloledib.it/pdv Se potete ascoltare questi podcast senza che io sia andato al manicomio dovete ringraziare Alex Raccuglia che con il suo fantastico PODucer per MacOS mi risparmia ore e ore di lavoro di montaggio. Il tip Oggi vi propongo un oggetto, piccolo, tondo, nero e che costa 5€ da Ikea, si chiama con uno dei loro soliti nomi impronunciabili, LIVBOJ ed è un piattello che ricarica il telefono cellulare con la tecnologia senza fili IQ, per farlo funzionare serve un alimentatore USB e un cavo con connettore USB-C, lo mettete su un tavolo e quando ci appoggiate sopra il vostro telefono compatibile con la ricarica wireless IQ, questo inizierà a caricarsi. L’ho preso, l’ho trovato economico, funzionale, discreto, c’è anche bianco, insomma, se volete provare la ricarica senza fili è il modo giusto per iniziare. E per 5€, direi che la spesa non è neanche folle. Bene è proprio tutto, non mi resta che salutarvi e darvi appuntamento alla prossima puntata, come di consueto, il lunedì mattina Ciao!