Transmission Control Protocol: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Etichette: Annullato Modifica da mobile Modifica da web per mobile |
m clean up, replaced: lingua=inglese → lingua=en |
||
| (39 versioni intermedie di 27 utenti non mostrate) | |||
Riga 1:
{{F|
{{citazione|Per il TCP due host sono una compagnia, tre sono una folla|J.F. Kurose, K.W. Ross - Internet e Reti di Calcolatori, un approccio top-down}}
In [[telecomunicazioni]] e [[informatica]] il '''Transmission Control Protocol''' ('''TCP''') è un [[protocollo di rete]] a [[rete a pacchetto|pacchetto]] di [[livello di trasporto]], appartenente alla [[suite di protocolli Internet]], che si occupa di ''controllo della [[trasmissione (telecomunicazioni)|trasmissione]]'' ovvero rendere ''affidabile'' la comunicazione dati in rete tra mittente e destinatario. Definito nella [[Request for Comments|RFC]]
== Descrizione ==
Il TCP può essere classificato al [[Livello di trasporto|livello trasporto]] (level 4) del [[modello di riferimento OSI]], e di solito è usato in combinazione con il protocollo di [[Livello di rete|livello rete]] (OSI level 3) [[Internet Protocol|IP]].
Nel [[Suite di protocolli Internet|modello TCP/IP]] il protocollo TCP occupa il livello
In linea con i dettami del livello di trasporto stabiliti dal [[modello ISO/OSI]] e con l'intento di superare il problema della mancanza di affidabilità e controllo della comunicazione sorto con l'interconnessione su vasta scala di [[rete locale|reti locali]] in un'unica grande [[Wide Area Network|rete geografica]], TCP è stato progettato e realizzato per utilizzare i servizi offerti dai protocolli di rete di livello inferiore ([[Internet Protocol|IP]] e protocolli di [[livello fisico]] e [[livello datalink]]) che definiscono efficacemente il [[modo di trasferimento]] sul [[canale (telecomunicazioni)|canale]] di comunicazione, ma che non offrono alcuna garanzia di affidabilità sulla consegna in termini di ritardo, perdita ed [[controllo di errore|errore]] dei [[pacchetto (reti)|pacchetti]] informativi trasmessi, sul [[controllo di flusso]] tra terminali e sul [[controllo della congestione]] di rete, supplendo quindi ai problemi di cui sopra e costruendo così un affidabile [[canale (telecomunicazioni)|canale di comunicazione]] tra due [[processo (informatica)|processi]] applicativi di rete. Il canale di comunicazione così costruito è composto da un flusso bidirezionale di [[byte]] a seguito dell'instaurazione di una [[connessione (informatica)|connessione]] agli estremi tra i due terminali in comunicazione. Inoltre alcune funzionalità di TCP sono vitali per il buon funzionamento complessivo di una rete IP. Sotto questo punto di vista TCP può essere considerato come un protocollo di rete che si occupa di costruire connessioni e garantire affidabilità su una rete IP sottostante che è sostanzialmente di tipo ''[[Best effort|best-effort]]''.
Il TCP nacque nel [[1970]] come frutto del lavoro di un gruppo di ricerca del [[Dipartimento della Difesa statunitense]]. I suoi punti di forza sono l'alta affidabilità e robustezza. La sua popolarità si deve anche
=== Caratteristiche principali ===
Riga 20 ⟶ 21:
* TCP possiede funzionalità di [[controllo di flusso]] tra terminali in comunicazione e [[controllo della congestione]] sulla connessione, attraverso il meccanismo della [[finestra scorrevole]]. Questo permette di ottimizzare l'utilizzo dei buffer di ricezione/invio sui due end devices (controllo di flusso) e di diminuire il numero di segmenti inviati in caso di [[congestione (reti)|congestione]] della rete.
* TCP fornisce un servizio di [[multiplazione#Multiplazione nei protocolli di trasporto|multiplazione]] delle connessioni su un [[host]], attraverso il meccanismo dei numeri di [[Porta (reti)|porta]] del mittente.
=== Confronto con UDP ===▼
Le principali differenze tra TCP e [[User Datagram Protocol|UDP]] (''User Datagram Protocol''), l'altro principale protocollo di [[Livello di trasporto|trasporto]] della [[suite di protocolli Internet]], sono: ▼
* TCP è un protocollo orientato alla connessione. Pertanto, per stabilire, mantenere e chiudere una connessione, è necessario inviare segmenti di servizio i quali aumentano l'overhead di comunicazione. Al contrario, UDP è [[connectionless|senza connessione]] ed invia solo i [[datagramma|datagrammi]] richiesti dal [[Livello applicazioni|livello applicativo]]; (nota: i pacchetti prendono nomi diversi a seconda delle circostanze a cui si riferiscono: segmenti (TCP) o datagrammi (UDP));▼
* UDP non offre nessuna garanzia sull'affidabilità della comunicazione, ovvero sull'effettivo arrivo dei segmenti, né sul loro ordine in sequenza in arrivo; al contrario il TCP, tramite i meccanismi di acknowledgement e di ritrasmissione su timeout, riesce a garantire la consegna dei dati, anche se al costo di un maggiore [[Overhead#Reti di calcolatori|overhead]] (raffrontabile visivamente confrontando la dimensione delle intestazioni dei due protocolli); TCP riesce altresì a riordinare i segmenti in arrivo presso il destinatario attraverso un campo del suo header: il sequence number;▼
* l'oggetto della comunicazione di TCP è un ''flusso di byte,'' mentre quello di UDP sono ''singoli datagrammi''.▼
L'utilizzo del protocollo TCP rispetto a [[User Datagram Protocol|UDP]] è, in generale, preferito quando è necessario avere garanzie sulla consegna dei dati o sull'ordine di arrivo dei vari segmenti (come per esempio nel caso di trasferimenti di file).▼
Al contrario UDP viene principalmente usato quando l'interazione tra i due host è [[idempotente]] o nel caso si abbiano forti vincoli sulla velocità e l'economia di risorse della rete (es. [[streaming]] in tempo reale, videogiochi multiplayer).▼
=== 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 (
Un segmento TCP è così strutturato:
Riga 61 ⟶ 53:
! 12
! <kbd>96</kbd>
| colspan="4"| Data offset || colspan="4"| Reserved<br/><kbd>'''0 0 0 0'''</kbd> || cellpadding="1"|<kbd>C<br/>W<br/>R</kbd>|||<kbd>E<br/>C<br/>E</kbd>|||<kbd>U<br/>R<br/>G</kbd>|||<kbd>A<br/>C<br/>K</kbd>|||<kbd>P<br/>S<br/>H</kbd>|||<kbd>R<br/>S<br/>T</kbd>|||<kbd>S<br/>Y<br/>N</kbd>|||<kbd>F<br/>I<br/>N</kbd>|| colspan="16"| Window Size
|-
! 16
Riga 79 ⟶ 71:
* '''Source port''' [16 bit] - Identifica il ''numero di porta sull'host mittente'' associato alla connessione TCP.
* '''Destination port''' [16 bit] - Identifica il ''numero di porta sull'host destinatario'' associato alla connessione TCP.
* '''Sequence number''' [32 bit] - Numero di sequenza, indica lo scostamento (espresso in byte) dell'inizio del segmento TCP all'interno del flusso completo, a partire dall'Initial Sequence Number (''ISN''), deciso all'apertura della connessione (Un campo a 32 bit utilizzato per il riassemblaggio dei dati).
* '''Acknowledgment number''' [32 bit] - Numero di riscontro, ha significato solo se il flag [[ACK (informatica)|ACK]] è impostato a 1, e conferma la ricezione di una parte del flusso di dati nella direzione opposta, indicando il valore del prossimo ''Sequence number'' che l'host mittente del segmento TCP si aspetta di ricevere.
* '''Data offset''' [4 bit] - Indica la lunghezza (in [[dword]] da 32 bit) dell'header del segmento TCP; tale lunghezza può variare da 5 dword (20 byte) a 15 dword (60 byte) a seconda della presenza e della lunghezza del campo facoltativo ''Options''.
Riga 93 ⟶ 85:
** '''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.
* '''Data''' - rappresenta il carico utile o ''payload'' da trasmettere cioè la [[Protocol Data Unit|PDU]] proveniente dal livello superiore.
▲=== Confronto con UDP ===
▲Le principali differenze tra TCP e [[User Datagram Protocol|UDP]] (''User Datagram Protocol''), l'altro principale protocollo di [[Livello di trasporto|trasporto]] della [[suite di protocolli Internet]], sono:
▲* TCP è un protocollo orientato alla connessione. Pertanto, per stabilire, mantenere e chiudere una connessione, è necessario inviare segmenti di servizio i quali aumentano l'overhead di comunicazione. Al contrario, UDP è [[connectionless|senza connessione]] ed invia solo i [[datagramma|datagrammi]] richiesti dal [[Livello applicazioni|livello applicativo]]; (nota: i pacchetti prendono nomi diversi a seconda delle circostanze a cui si riferiscono: segmenti (TCP) o datagrammi (UDP));
▲* UDP non offre nessuna garanzia sull'affidabilità della comunicazione, ovvero sull'effettivo arrivo dei segmenti, né sul loro ordine in sequenza in arrivo; al contrario il TCP, tramite i meccanismi di acknowledgement e di ritrasmissione su timeout, riesce a garantire la consegna dei dati, anche se al costo di un maggiore [[Overhead#Reti di calcolatori|overhead]] (raffrontabile visivamente confrontando la dimensione delle intestazioni dei due protocolli); TCP riesce altresì a riordinare i segmenti in arrivo presso il destinatario attraverso un campo del suo header: il sequence number;
▲* l'oggetto della comunicazione di TCP è un ''flusso di byte,'' mentre quello di UDP sono ''singoli datagrammi''.
▲L'utilizzo del protocollo TCP rispetto a [[User Datagram Protocol|UDP]] è, in generale, preferito quando è necessario avere garanzie sulla consegna dei dati o sull'ordine di arrivo dei vari segmenti (come per esempio nel caso di trasferimenti di file).
▲Al contrario UDP viene principalmente usato quando l'interazione tra i due host è [[idempotente]] o nel caso si abbiano forti vincoli sulla velocità e l'economia di risorse della rete (es. [[streaming]] in tempo reale, videogiochi [[Multigiocatore|multiplayer]]).
== Connessione ==
Riga 102 ⟶ 103:
=== Apertura di una connessione - ''Three-way handshake'' ===
[[File:Tcp-handshake.svg|
La procedura utilizzata per instaurare in modo affidabile una [[connessione (informatica)|connessione]] TCP tra due host è chiamata ''three-way handshake'' (stretta di mano in 3 passaggi), indicando la necessità di scambiare 3 messaggi tra host mittente e host ricevente affinché la connessione sia instaurata correttamente.
Consideriamo ad esempio che l'host A intenda aprire una connessione TCP con l'host B; i passi da seguire quindi sono:
Riga 118 ⟶ 120:
=== Chiusura di una connessione - ''doppio two-way handshake'' ===
[[File:FIN a 3 vie.jpg|alt=3-way handshake per terminare la connessione|
[[File:TCP-Chiusura-a-4-vie.png|
Dopo che è stata stabilita, una connessione TCP non è considerata una singola connessione bidirezionale, ma piuttosto come l'interazione di due connessioni monodirezionali; pertanto, ognuna delle parti dovrebbe terminare la ''propria'' connessione. Possono esistere anche ''connessioni chiuse a metà'', in cui solo uno dei due host ha chiuso la connessione poiché non ha più nulla da trasmettere, ma può (e deve) ancora ricevere i dati dall'altro host.
Riga 139 ⟶ 142:
=== Server e Client ===
I due processi che comunicano attraverso una connessione TCP hanno ruoli diversi:
* Il processo che avvia una nuova connessione TCP è detto [[client]], ed invia una richiesta di connessione verso una determinata porta.
* Affinché la connessione venga stabilita, su quella porta deve esserci un processo [[server]] "in ascolto", che accetta di stabilire una connessione TCP.
Riga 149 ⟶ 151:
== Affidabilità della comunicazione ==
=== Consegna ordinata ed eliminazione di duplicati ===
Il '''Sequence number'''
In ricezione TCP si aspetta di ricevere il segmento successivo all'ultimo segmento ricevuto in ordine, ovvero, quello il cui numero di sequenza è pari al numero di sequenza dell'ultimo pervenuto in ordine, più la dimensione del carico utile del segmento in attesa (cioè del suo campo '''Data''').
Riga 156 ⟶ 158:
* 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
=== Riscontro dei pacchetti e ritrasmissione ===
Riga 163 ⟶ 165:
In particolare il protocollo TCP adotta la politica di '''Conferma cumulativa''', ovvero l'arrivo di numero di riscontro indica al TCP trasmittente che il ricevente ha ricevuto e correttamente inoltrato al proprio processo applicativo il segmento avente numero di sequenza pari al numero di riscontro indicato (-1) ed anche ''tutti i segmenti ad esso precedenti''. Per tale motivo TCP lato trasmittente mantiene temporaneamente in un buffer una copia di tutti i dati inviati, ma non ancora riscontrati: quando questi riceve un numero di riscontro per un certo segmento, deduce che tutti i segmenti precedenti a quel numero sono stati ricevuti correttamente liberando il proprio buffer dai dati. La dimensione massima dei pacchetti riscontrabili in maniera cumulativa è specificata dalle dimensioni della cosiddetta [[finestra scorrevole]].
Per evitare tempi di attesa troppo lunghi o troppo corti per ciascun segmento inviato TCP lato trasmittente avvia un [[Timer (informatica)|timer]], detto ''timer di ritrasmissione RTO'' (Retransmission Time Out): se questi non riceve un ACK di riscontro per il segmento inviato prima che il timer [[SCADA|scada]], TCP assume che tutti i segmenti trasmessi a partire da questo siano andati persi e quindi procede alla ritrasmissione.
Si noti che, in TCP, il meccanismo dei numeri di riscontro non permette al ricevitore di comunicare al trasmettitore che un segmento è stato perso, ma alcuni dei successivi sono stati ricevuti (meccanismo ad ''Acknowledgment Number negativi''), quindi è possibile che per un solo pacchetto perso ne debbano essere ritrasmessi molti. Questo comportamento non ottimale è compensato dalla semplicità del protocollo.
Questa tecnica è detta [[Go-Back-N ARQ|Go-Back-N]] (vai indietro di N segmenti); l'alternativa, ovvero progettare il protocollo in modo tale che solo i pacchetti effettivamente persi vengano ritrasmessi, è detta [[Selective repeat ARQ|Selective Repeat]] (ripetizione selettiva); l'utilizzo però di alcuni campi
I numeri di riscontro e i relativi timer di ritrasmissione permettono quindi di realizzare la '''consegna affidabile''', ovvero di garantire che tutti i dati inviati siano comunque consegnati nel caso in cui qualche pacchetto possa essere perso nel transito attraverso la rete (controllo di errore in termini di riscontro di trasmissione).
=== Controllo di flusso ===
{{vedi anche|Controllo di flusso}}
{{vedi anche|Controllo di flusso}}L'affidabilità della comunicazione in TCP è garantita anche dal cosiddetto [[controllo di flusso]] ovvero far in modo che il flusso di dati in trasmissione non superi le capacità di ricezione ovvero di memorizzazione del ricevente con perdita di pacchetti e maggior peso e [[Latenza|latenze]] nelle successive richieste di ritrasmissione. Viene attuato attraverso la specifica da parte del destinatario di un opportuno campo noto come RCV_WND ([[finestra di ricezione]]), variabile dinamica (ossia dipendente dallo spazio disponibile) che specifica il numero massimo di segmenti ricevibili dal destinatario. Definito:▼
▲
* ''LastByteRead'': numero dell'ultimo byte nel flusso di dati che il processo applicativo in B ha letto dal buffer
* ''LastByteRcvd:'' numero dell'ultimo byte nel flusso di dati proveniente dalla rete che è stato copiato nel buffer di ricezione RcvBuffer precedentemente allocato
Riga 186 ⟶ 189:
A sua volta il mittente terrà traccia dell'ultimo byte mandato e dell'ultimo byte per cui si è ricevuto l'ACK affinché esso non mandi in overflow il buffer del destinatario.
Si noti come, qualora la finestra di ricezione fosse vuota (RCV_WND == 0), il mittente continuerà ad inviare segmenti di un byte, in modo tale da garantire la sincronizzazione tra
=== Problemi nel controllo di flusso in TCP ===
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
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
Tale algoritmo risolutivo viene chiamato algoritmo di Clark.
'''Silly window lato trasmettitore''': si verifica quando
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
=== Controllo di congestione ===
{{vedi anche|Controllo della congestione in TCP}}
Infine l'ultimo tipo di controllo effettuato da TCP per garantire affidabilità alla comunicazione è il cosiddetto [[controllo della congestione]] ovvero far in modo che si limitino il più possibile fenomeni di [[congestione (reti)|congestione]] all'interno della rete per eccessivo [[traffico (telecomunicazioni)|traffico]] sui [[dispositivi di rete]] con perdita di pacchetti in transito e maggior peso e [[latenza|latenze]] nelle successive richieste di ritrasmissione, modulando nel tempo la quantità di dati in trasmissione in funzione dello stato interno di congestione. La particolarità di tale controllo è che viene effettuato agendo sulla trasmissione agli estremi cioè sui terminali di rete e non attraverso la commutazione interna alla rete grazie alle informazioni deducibili dal terminale stesso sullo stato della trasmissione dei pacchetti. Nello specifico, una volta "stimato" lo stato di congestione interno della rete avendo scelto come parametro di riferimento la perdita di pacchetti trasmessi desunta dai mancati ACK di riscontro dei pacchetti stessi, tale controllo viene poi attuato attraverso la definizione da parte del mittente di un opportuno campo noto come C_WND ([[finestra di congestione]]) la quale assegna, dinamicamente nel tempo, il numero massimo di segmenti da trasmettere al destinatario.
== I timer del TCP ==
=== Timer di ritrasmissione (RTO->Retransmission Time Out) ===
Come descritto sopra, il timer di ritrasmissione serve a verificare che ciascun segmento trasmesso venga riscontrato.
Riga 217 ⟶ 221:
=== Timer di keepalive ===
La [[Request for Comments|RFC]] 793 che definisce il protocollo TCP non prevede particolari azioni da intraprendere quando non ci sono dati da trasmettere sulla connessione. Alcune implementazioni però consentono di trasmettere periodicamente segmenti vuoti, detti ''keepalive'', per evitare di mantenere indefinitamente in memoria connessioni con sistemi che potrebbero anche non essere più attivi. In molti sistemi il software applicativo ha la possibilità di scegliere se abilitare o meno i keepalive per ogni connessione.
Quando si usano i keepalive, è presente dunque il ''timer di keepalive'': esso viene reimpostato alla ricezione o alla trasmissione di ogni segmento, e quando scade viene trasmesso un keepalive. Un valore tipico è di due ore.
Riga 224 ⟶ 228:
L'ultimo timer utilizzato da TCP è il ''timed wait''. In pratica, prima di disconnettere effettivamente una connessione, i due estremi del canale attendono un tempo pari al doppio del tempo di vita di un comune pacchetto: questo evita che dei pacchetti possano rimanere circolanti per la rete anche dopo la chiusura.
== Vulnerabilità ==
Il protocollo TCP viene progettato per la prima volta come strumento da utilizzare in reti chiuse e private, gestite da enti o università che quindi non si pongono il problema di garantirne la sicurezza; funzionalità come la sicurezza, l'integrità e l'autenticità della comunicazione tra due host vengono relegate a [[Modello OSI|livelli di rete]] superiori. Esistono perciò diverse soluzioni implementative per ovviare a questa mancanza. I risultati di una valutazione completa sulla sicurezza di questo protocollo, insieme a possibili soluzioni, sono stati pubblicati nel 2009<ref>{{Cita web|url=https://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf |titolo=Security Assessment of the Transmission Control Protocol (TCP) |accesso=23 dicembre 2010 |urlmorto=bot: unknown |urlarchivio=https://web.archive.org/web/20090306052826/http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
=== Denial of service ===
{{vedi anche|Denial of service}}
Un attacco [[Denial of service|
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.
=== Connection hijacking ===
Come detto precedentemente, ogni pacchetto TCP è identificato da un numero di sequenza che lo individua univocamente all'interno della comunicazione. Un utente malintenzionato che è in grado di intercettare una sessione TCP e di reindirizzare i pacchetti può disattivare una connessione TCP. Per farlo, l'attaccante apprende il successivo numero di sequenza della comunicazione in corso e crea un falso pacchetto che assomigli a quello successivo del flusso e lo invia al destinatario al posto dell'originale. Quando il destinatario riceve il pacchetto falso, lo accetta per via del numero di sequenza corretto, ma riscontrando una lunghezza del pacchetto diversa da quella prevista, perde la sincronizzazione con l'host sorgente e chiude quindi la connessione. Questo procedimento può essere combinato con tecniche di [[ARP spoofing]] o di modifica del [[protocollo di routing]] per gestire il controllo del flusso di pacchetti, in modo da ottenere un controllo permanente sulla connessione TCP.
Attuare questo tipo di attacco non era difficile prima della RFC 1948, quando il numero di sequenza era facilmente prevedibile grazie a tecniche di IP Spoofing. Questo è il motivo per cui, ad oggi, il numero di sequenza iniziale viene scelto casualmente.
=== TCP Veto ===
Un utente malintenzionato che, oltre al numero di sequenza, è
=== TCP Reset ===
Nei pacchetti TCP è presente un flag nell'header, chiamato [[RST (TCP)|RST]]. In molti pacchetti questo bit è impostato a zero e non ha nessun effetto, se invece è impostato a uno, indica al destinatario che può interrompere immediatamente la connessione e quindi liberare tutte le risorse occupate, dato che il mittente non ha intenzione di inviare ulteriori pacchetti. Un utente malintenzionato può quindi ascoltare la conversazione tra due host, e inviare a uno o a entrambi un pacchetto con il flag RST impostato a uno. Questo metodo consente di interrompere connessioni TCP in modo veloce e senza lasciare particolari tracce. L'attaccante deve comunque camuffare il pacchetto modificando l'indirizzo IP di provenienza, per poter ingannare l'host.
== Note ==
<references />
== Bibliografia ==
* {{IETF|793|Transmission Control Protocol}}
* {{cita libro|autore=W. Richard Stevens|autore2=Kevin R. Fall|titolo=TCP/IP Illustrated: The Protocols|volume=1|edizione=2|editore=Addison-Wesley|anno=2012|lingua=en|ISBN=9780321336316}}
== Voci correlate ==
Riga 259 ⟶ 267:
== Altri progetti ==
{{interprogetto|preposizione=sul|wikt=TCP|wikt_etichetta=TCP}}
== Collegamenti esterni ==
* {{Collegamenti esterni}}
* {{FOLDOC}}
* {{cita web|http://www.rfc.altervista.org/rfctradotte/rfc793_tradotta.txt|Traduzione in italiano dell'RFC}}▼
* {{IETF|9293|Transmission Control Protocol (TCP)}}
* {{cita web|http://www.answersthatwork.com/Download_Area/ATW_Library/Networking/Network__2-List_of_Common_TCPIP_port_numbers.pdf|Porte di comunicazione TCP|lingua=en}}▼
▲* {{cita web|url=http://www.rfc.altervista.org/rfctradotte/rfc793_tradotta.txt|
* {{cita web|https://tools.ietf.org/html/rfc1948|RFC 1948 - Defending Against Sequence Number Attacks|lingua=en}}▼
▲* {{cita web|url=http://www.answersthatwork.com/Download_Area/ATW_Library/Networking/Network__2-List_of_Common_TCPIP_port_numbers.pdf|titolo=Porte di comunicazione TCP|lingua=en|urlmorto=sì|accesso=11 novembre 2011|dataarchivio=22 novembre 2011|urlarchivio=https://web.archive.org/web/20111122144159/http://www.answersthatwork.com/Download_Area/ATW_Library/Networking/Network__2-List_of_Common_TCPIP_port_numbers.pdf}}
* {{cita web|https://web.archive.org/web/20090306052826/http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf|Security Assessment of the Transmission Control Protocol (TCP)|lingua=en}}▼
▲* {{
▲* {{cita web|
{{IPstack}}
{{Portale|telematica}}
[[Categoria:
[[Categoria:Protocolli livello trasporto]]
| |||