Transmission Control Protocol: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica |
|||
Riga 7:
La corrispondenza con il modello OSI non è perfetta, in quanto il TCP e l'IP nascono prima del suddetto modello. La loro combinazione è indicata come [[TCP/IP]] e, alle volte, è erroneamente considerata un unico protocollo. Da qui, la difficoltà di una classificazione univoca per un protocollo che comprende, a pieno titolo, due livelli dello stack [[Open Systems Interconnection|OSI]] (o ''pila ISO/OSI'' in italiano).
In linea con i dettami del livello di trasporto stabiliti dal modello [[Open System Interconnection|ISO-OSI]], 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 '''[[canale (telecomunicazioni)|canale di comunicazione]] affidabile tra due [[processo (informatica)|processi]] applicativi di rete'''. Il canale di comunicazione così costruito è costituito da un flusso bidirezionale di [[byte]] a seguito dell'instaurazione di una [[connessione (informatica)|connessione]]
Il TCP nacque nel [[1970]] come frutto del lavoro di un gruppo di ricerca del dipartimento di difesa statunitense. I suoi punti di forza sono l'alta affidabilità e robustezza. La sua popolarità si deve anche grazie ad una sua implementazione diffusa dalla [[Università della California, Berkeley|Università di Berkeley]], rilasciata in California sotto forma di sorgenti (TCP Berkeley). Molte tuttavia sono le implementazioni e sviluppi che si sono succedute nel tempo come evoluzioni e miglioramenti (es. TCP Tahoe, TCP Reno, TCP New Reno).
Riga 73:
* '''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.
===Affidabilità della comunicazione===▼
====Consegna ordinata ed eliminazione di duplicati====▼
Il '''Sequence number''', o numero di sequenza, serve a identificare e posizionare in maniera ordinata il carico utile del segmento TCP all'interno del flusso di dati. Con la trasmissione tipica a commutazione di pacchetto delle rete dati infatti ciascun pacchetto può seguire percorsi diversi in rete e giungere fuori sequenza in ricezione.▼
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''').▼
In relazione al numero di sequenza TCP ricevente attua le seguenti procedure:▼
* se il numero di sequenza ricevuto è quello atteso invia direttamente il carico utile del segmento al processo di livello applicativo e liberare 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 passenti 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 duqnue scartato. Questo permette di realizzare l''''eliminazione dei duplicati di rete'''.▼
====Riscontro dei pacchetti====▼
Per ogni segmento ricevuto in sequenza inoltre TCP lato ricevente invia un '''Acknowledgment Number''' o numero di riscontro dell'avvenuta ricezione. ''Il numero di riscontro presente in un segmento riguarda il flusso di dati nella direzione opposta''. In particolare, il numero di riscontro inviato da A a B è pari al numero di sequenza atteso da A e, quindi, '''riguarda il flusso di dati da B ad A'''. ▼
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, 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 opzionali appositi permette l'utilizzo della ripetizione selettiva.▼
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 anche se qualche pacchetto possa essere perso nel transito attraverso la rete.▼
== I timer del TCP ==▼
=== Timer di ritrasmissione ===▼
Come descritto sopra, il timer di ritrasmissione serve a verificare che ciascun segmento trasmesso venga riscontrato. ▼
La corretta impostazione di questo timer è difficile ma molto importante, in quanto un timer troppo breve comporta ritrasmissioni inutili (il timer scatta mentre il riscontro o il pacchetto sono ancora in viaggio), mentre un timer troppo lungo comporta attese in caso di effettiva perdita di pacchetti. Ovviamente tale intervallo dovrà essere almeno pari al [[Round Trip Time]] cioè al tempo di percorrenza a due vie di un pacchetto per tornare al mittente sotto forma di ACK. Tale RTT, per la natura intrinseca della commutazione di pacchetto interna alla rete, è tipicamente variabile in maniera aleatoria. TCP allora aggiusta continuamente il timer di ritrasmissione basandosi su una stima a [[media mobile]] del [[Round Trip Time]].▼
=== Timer di persistenza (finestra scorrevole) ===▼
Come spiegato sopra, il TCP utilizza il metodo della [[finestra scorrevole]] per gestire il [[controllo di flusso]] di dati che il ricevente è in grado di accettare dal mittente. Tra i valori validi di questo campo vi è anche lo zero, a significare che il ricevente richiede l'interruzione momentanea dell'invio di dati.▼
Nel malaugurato caso in cui il pacchetto che riapre la finestra venga perso, il mittente del canale TCP rimarrà però in attesa indefinita. Per evitare questo, il TCP avvia un timer, detto ''timer di persistenza'', ogni qual volta il ricevente chiude la finestra. Quando questo timer scade, il mittente invia un pacchetto sonda al ricevente, provocandone una risposta: in questo modo il mittente potrà essere sicuro che la finestra sia chiusa (ricevendo un altro pacchetto con campo Window a 0) o sbloccarsi dallo stallo (ricevendo un pacchetto con campo Window diverso da zero).▼
{{vedi anche|Controllo della congestione in TCP}}▼
=== Timer di keepalive ===▼
La RFC 793 che definisce il protocollo TCP non prevede particolari azioni da intraprendere quando non ci sono dati da trasmettere sulla connessioni. 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.▼
=== Timed wait ===▼
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.▼
==Connessione==
Prima ancora del trasferimento dei dati su [[canale (telecomunicazioni)|canale]] di comunicazione e delle operazioni di controllo di trasmissione sul flusso dei dati in ricezione, in trasmissione TCP si occupa di instaurare la connessione
=== Apertura di una connessione - ''Three-way handshake'' ===
Line 163 ⟶ 117:
Il processo server, che è in ascolto su una certa porta, rimane bloccato in attesa che un client si colleghi. Il processo client richiede di stabilire una connessione verso un determinato server su una determinata porta. Normalmente la porta sorgente usata dal client viene allocata dinamicamente dal sistema operativo del client. Quando il TCP stabilisce la connessione, a entrambi i processi viene assegnato un socket tramite cui essi possono comunicare tra loro. Tipicamente il processo server effettua una [[fork]], affida al figlio il compito di comunicare con il nuovo client e si rimette in ascolto. Da questo punto in poi, client e server hanno ruoli simmetrici, e utilizzano gli stessi strumenti per comunicare attraverso il socket.
▲Il '''Sequence number''', o numero di sequenza, serve a identificare e posizionare in maniera ordinata il carico utile del segmento TCP all'interno del flusso di dati. Con la trasmissione tipica a commutazione di pacchetto delle rete dati infatti ciascun pacchetto può seguire percorsi diversi in rete e giungere fuori sequenza in ricezione.
▲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''').
▲In relazione al numero di sequenza TCP ricevente attua le seguenti procedure:
▲* se il numero di sequenza ricevuto è quello atteso invia direttamente il carico utile del segmento al processo di livello applicativo e liberare 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 passenti 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 duqnue scartato. Questo permette di realizzare l''''eliminazione dei duplicati di rete'''.
▲Per ogni segmento ricevuto in sequenza inoltre TCP lato ricevente invia un '''Acknowledgment Number''' o numero di riscontro dell'avvenuta ricezione. ''Il numero di riscontro presente in un segmento riguarda il flusso di dati nella direzione opposta''. In particolare, il numero di riscontro inviato da A a B è pari al numero di sequenza atteso da A e, quindi, '''riguarda il flusso di dati da B ad A'''.
▲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, 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 opzionali appositi permette l'utilizzo della ripetizione selettiva.
▲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 anche se qualche pacchetto possa essere perso nel transito attraverso la rete.
===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 RCW_WND ([[finestra di ricezione]]) il quale specifica il numero massimo di segmenti ricevibile dal destinatario.
===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. Di fatto tale controllo viene attuato attraverso la definizione da parte del mittente di un opportuno campo noto come CWN ([[finestra di congestione]]) la quale assegna, dinamicamente nel tempo, il numero massimo di segmenti da trasmettere al destinatario avendo scelto come parametro di riferimento per valutare lo stato di congestione interno la perdita di pacchetti trasmessi desunta a sua volta dai mancati ACK di riscontro dei pacchetti trasmessi.
▲== I timer del TCP ==
▲=== Timer di ritrasmissione ===
▲Come descritto sopra, il timer di ritrasmissione serve a verificare che ciascun segmento trasmesso venga riscontrato.
▲La corretta impostazione di questo timer è difficile ma molto importante, in quanto un timer troppo breve comporta ritrasmissioni inutili (il timer scatta mentre il riscontro o il pacchetto sono ancora in viaggio), mentre un timer troppo lungo comporta attese in caso di effettiva perdita di pacchetti. Ovviamente tale intervallo dovrà essere almeno pari al [[Round Trip Time]] cioè al tempo di percorrenza a due vie di un pacchetto per tornare al mittente sotto forma di ACK. Tale RTT, per la natura intrinseca della commutazione di pacchetto interna alla rete, è tipicamente variabile in maniera aleatoria. TCP allora aggiusta continuamente il timer di ritrasmissione basandosi su una stima a [[media mobile]] del [[Round Trip Time]].
▲Come spiegato sopra, il TCP utilizza il metodo della [[finestra scorrevole]] per gestire il [[controllo di flusso]] di dati che il ricevente è in grado di accettare dal mittente. Tra i valori validi di questo campo vi è anche lo zero, a significare che il ricevente richiede l'interruzione momentanea dell'invio di dati.
▲Nel malaugurato caso in cui il pacchetto che riapre la finestra venga perso, il mittente del canale TCP rimarrà però in attesa indefinita. Per evitare questo, il TCP avvia un timer, detto ''timer di persistenza'', ogni qual volta il ricevente chiude la finestra. Quando questo timer scade, il mittente invia un pacchetto sonda al ricevente, provocandone una risposta: in questo modo il mittente potrà essere sicuro che la finestra sia chiusa (ricevendo un altro pacchetto con campo Window a 0) o sbloccarsi dallo stallo (ricevendo un pacchetto con campo Window diverso da zero).
▲=== Timer di keepalive ===
▲La RFC 793 che definisce il protocollo TCP non prevede particolari azioni da intraprendere quando non ci sono dati da trasmettere sulla connessioni. 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.
▲=== Timed wait ===
▲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.
== Voci correlate ==
| |||