Transmission Control Protocol: differenze tra le versioni

Versione delle 17:10, 18 ago 2022

Versione delle 02:18, 9 ott 2022

Riga 31:

=== Segmento TCP ===

La [[Protocol Data Unit|PDU]] di TCP è detta ''segmento''. Ciascun segmento viene normalmente [[imbustamento|imbustato]] in un pacchetto [[Internet Protocol|IP]], ed è costituito dall'intestazione ([[header]]) TCP e da un carico utile (in inglese [[Payload (softwareinformatica)|payload]]), ovvero i dati provenienti dal [[livello applicazioni|livello applicativo]] (es.: HTTP). I dati contenuti nell'intestazione costituiscono un canale di comunicazione tra TCP mittente e TCP destinatario, che viene utilizzato per realizzare le funzionalità dello strato di trasporto e non è accessibile agli strati dei livelli superiori.

Un segmento TCP è così strutturato:

Riga 93:

** '''FIN''' - se impostato a 1 indica che l'host mittente del segmento vuole ''chiudere la connessione TCP'' aperta con l'host destinatario. Il mittente attende la conferma dal ricevente (con un FIN-ACK). A questo punto la connessione è ritenuta chiusa per metà: l'host che ha inviato FIN non potrà più inviare dati, mentre l'altro host ha il canale di comunicazione ancora disponibile. Quando anche l'altro host invierà il pacchetto con FIN impostato, la connessione, dopo il relativo FIN-ACK, sarà considerata completamente chiusa.

* '''Window size''' [16 bit] - Indica la dimensione della ''finestra di ricezione'' dell'host mittente, cioè il numero di byte che il mittente è in grado di accettare a partire da quello specificato dall'acknowledgment number.

* '''[[Checksum]]''' [16 bit] - Campo di controllo utilizzato per la verifica della validità del segmento. È ottenuto facendo il complemento a 1 della somma complemento a uno a 16 bit dell'intero header TCP (con il campo checksum messo a zero), dell'intero payload, con l'aggiunta di uno pseudo header composto da: indirizzo IP sorgente (32bit),indirizzo IP destinazione (32bit), un byte di zeri, un byte che indica il protocollo e due byte che indicano la lunghezza del pacchetto TCP (header + dati).

* '''Urgent pointer''' [16 bit] - Puntatore a dato urgente, ha significato solo se il flag URG è impostato a 1 ed indica lo scostamento in byte a partire dal ''Sequence number'' del byte di dati urgenti all'interno del flusso.

* '''Options''' - Opzioni (facoltative) per usi del protocollo avanzati.

Riga 156:

* se il numero di sequenza ricevuto è quello atteso invia direttamente il carico utile del segmento al processo di livello applicativo e libera i propri [[buffer]].

* se il numero di sequenza ricevuto è maggiore di quello atteso deduce che uno o più segmenti ad esso precedenti sono andati persi, ritardati dal livello di rete sottostante o ancora in transito sulla rete. Pertanto, memorizza temporaneamente in un buffer il carico utile del segmento ricevuto fuori sequenza per poterlo consegnare al processo applicativo solo dopo aver ricevuto e consegnato anche tutti i segmenti precedenti non ancora pervenuti passanti anch'essi per il buffer, aspettandone l'arrivo fino ad un tempo limite prefissato (''time-out''). All'istante di consegna del blocco ordinato di segmenti tutto il contenuto del buffer viene liberato. Dal punto di vista del processo applicativo, quindi, i dati arriveranno in ordine anche se la rete ha per qualsiasi motivo alterato questo ordine realizzando così il requisito della '''consegna ordinata dei dati'''.

* se il numero di sequenza ricevuto è inferiore a quello atteso, il segmento viene considerato un duplicato di uno già ricevuto e già inviato allo strato applicativo e dunque scartato. Questo permette di realizzare l’l''''eliminazione dei duplicati di rete'''.

=== Riscontro dei pacchetti e ritrasmissione ===

Riga 191:

Esistono alcuni problemi nel controllo di flusso in TCP che si verificano sia lato trasmettitore che lato ricevitore. Tali problemi vanno sotto il nome di '''Silly window syndrome''' ed hanno effetti e cause diverse a seconda del lato.

'''Silly window lato ricevitore''': se il ricevitore svuota molto lentamente il buffer di ricezione, solo quando il ricevitore estrae informazioni dal buffer di ricezione si libera un piccolo spazio (Receive Window molto piccola) e tale valore di Receive Window viene comunicato indietro al trasmettitore. il problema è che ora, il trasmettitore usa una finestra di trasmissione molto stretta e quindi può succedere che esso sia costretto ad inviare dei segmenti molto corti rispetto all’headerall'header canonico di 20 byte, con conseguente abbassamento dell’efficienzadell'efficienza della trasmissione.

Per mitigare questo problema il TCP fa in modo che il ricevitore "menta" al trasmettitore indicando una finestra nulla sino a che il suo buffer di ricezione non si è svuotato per metà o per una porzione almeno pari al MSS (=Maximun''Maximum Segment Size'' (MSS), evitando così che il trasmettitore invii segmenti molto corti che limitino l’efficienzal'efficienza della trasmissione.

Tale algoritmo risolutivo viene chiamato algoritmo di Clark.

'''Silly window lato trasmettitore''': si verifica quando l’applicazionel'applicazione genera dati molto lentamente. Dal momento che il TCP legge i dati che sono presenti nel buffer di trasmissione creando dei segmenti che invia dall’altradall'altra parte, nel caso in cui l’applicazionel'applicazione generi i dati molto lentamente l’entitàl'entità TCP potrebbe essere forzata a creare segmenti molto corti (e con tanto overhead).

La soluzione si chiama algoritmo di Nagle, per cui il TCP sorgente invia la prima porzione di dati anche se corta, e quando è il momento di creare nuovi segmenti, tali segmenti, vengono creati solamente se il buffer d’uscitad'uscita contiene dati sufficienti per riempire un MSS oppure anche quando riceve un riscontro valido.

=== Controllo di congestione ===

Riga 206:

== I timer del TCP ==

=== Timer di ritrasmissione (RTO->Retrasmission Time Out) ===

Come descritto sopra, il timer di ritrasmissione serve a verificare che ciascun segmento trasmesso venga riscontrato.

Riga 229:

===Denial of service===

{{vedi anche|Denial of service}}

Un attacco [[Denial of service|DosDoS]] ha come scopo quello di mandare in tilt un server occupando tutte le risorse a sua disposizione. Questo obiettivo può essere raggiunto attraverso diverse tecniche.

Un primo modo consiste nell'utilizzare un metodo che prende il nome di [[SYN flood]]. Per aprire una connessione TCP, come già detto, è necessario il meccanismo del Three-Way Handshake. Se il client che ha chiesto di instaurare una connessione non risponde al server con il pacchetto di ACK dopo che ha ricevuto il relativo SYN-ACK, il server rimarrà in attesa. Utilizzando tecniche di [[IP spoofing]] e inviando ripetutamente pacchetti SYN appositamente assemblati e non il corrispettivo ACK, un singolo host può arrivare a consumare grandi quantità di risorse sul server che continuerà a tenere in memoria informazioni su connessioni fittizie. Possibili soluzioni a questo problema sono l'introduzione di timer al termine del quale il server cancellerà la connessione o l'introduzione di un meccanismo chiamato [[SYN cookies]], anche se quest'ultimo porta con sé un proprio insieme di vulnerabilità. Un altro attacco che mira a consumare tutte le risorse di un sistema è l'utilizzo di software di tipo [[Sockstress]], tale eventualità può facilmente essere scongiurata applicando politiche di gestione delle risorse del sistema.