Transmission Control Protocol DETTO TCP

sabato 29 maggio 2010

Transmission Control Protocol DETTO TCP

Transmission Control Protocol

Da HACKER2010, l'enciclopedia libera.

Transmission Control Protocol (TCP) è un protocollo di livello di trasporto della suite di protocolli Internet. È definito nella RFC 793, e su di esso si appoggiano gran parte delle applicazioni Internet.

Il TCP può essere classificato al livello trasporto (OSI level 4) del modello di riferimento OSI, e di solito è usato in combinazione con il protocollo dilivello rete (OSI level 3) IP. La corrispondenza con il modello OSI non è perfetta, in quanto il TCP e l'IP nascono prima. 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 OSI (o pila ISO/OSI in italiano)

Il TCP è stato progettato per utilizzare i servizi del protocollo IP, che non offre alcuna garanzia in ordine alla consegna dei pacchetti, al ritardo, alla congestione, e costruire un canale di comunicazione affidabile tra due processi applicativi. Il canale di comunicazione è costituito da un flusso bidirezionale di byte. Inoltre, alcune funzionalità di TCP sono vitali per il buon funzionamento complessivo di una rete IP.

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à di Berkeley, rilasciata in California sotto forma di sorgenti.

Caratteristiche principali

• Il servizio offerto da TCP è il trasporto di un flusso di byte bidirezionale tra due applicazioni in esecuzione su host differenti. Il protocollo permette alle due applicazioni di trasmettere contemporaneamente nelle due direzioni, quindi il servizio può essere considerato "Full Duplex" anche se non tutti i protocolli applicativi basati su TCP utilizzano questa possibilità.
• Il flusso di byte viene frazionato in blocchi per la trasmissione dall'applicazione a TCP (che normalmente è implementato all'interno del sistema operativo), per la trasmissione all'interno di segmenti TCP, per la consegna all'applicazione che lo riceve, ma questa divisione in blocchi non è per forza la stessa nei diversi passaggi.
• TCP è un protocollo orientato alla connessione, ovvero prima di poter trasmettere dati deve stabilire la comunicazione, negoziando una connessione tra mittente e destinatario, che viene esplicitamente chiusa quando non più necessaria. Esso quindi ha le funzionalità per creare, mantenere e chiudere una connessione.
• TCP garantisce che i dati trasmessi, se giungono a destinazione, lo facciano in ordine e una volta sola ("at most once"). Più formalmente, il protocollo fornisce ai livelli superiori un servizio equivalente ad una connessione fisica diretta che trasporta un flusso di byte. Questo è realizzato attraverso vari meccanismi di acknowledgment e di ritrasmissione su timeout.
• TCP possiede funzionalità di controllo di flusso e di controllo della congestione sulla connessione, attraverso il meccanismo della finestra scorrevole. Questo permette di ottimizzare l'utilizzo della rete anche in caso di congestione, e di condividere equamente la capacità disponibile tra diverse sessioni TCP attive su un collegamento.
• TCP fornisce un servizio di multiplazione delle connessioni su un host, attraverso il meccanismo delle porte.

• Confronto con UDP

  Le principali differenze tra TCP e UDP (User Datagram Protocol), l'altro principale protocollo di trasporto della suite di protocolli Internet, sono:

  • UDP non offre nessuna garanzia dell'arrivo dei datagrammi né sul loro ordine di 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 (raffrontabile visivamente confrontando la dimensione delle intestazioni dei due protocolli);
  • TCP è un protocollo orientato alla connessione, pertanto per stabilire, mantenere e chiudere una connessione, è necessario inviare pacchetti di servizio i quali aumentano l'overhead di comunicazione. Al contrario, UDP invia solo i datagrammi richiesti dal livello applicativo;
  • l'oggetto della comunicazione di TCP è il flusso di byte mentre quello di UDP è il singolo datagramma.

  L'utilizzo del protocollo TCP rispetto a 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.

  TCP Header

  Bit offset	Bits 0–3				4–7				8–15								16–31
  0	Source port																Destination port
  32	Sequence number
  64	Acknowledgment number
  96	Data offset				Reserved				CWR	ECE	URG	ACK	PSH	RST	SYN	FIN	Window Size
  128	Checksum																Urgent pointer
  160	Options (optional)
  160/192+	Data

  • 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), negoziato all'apertura della connessione.
  • Acknowledgment number [32 bit] - Numero di riscontro, ha significato solo se il flag ACK è settato 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 word da 32 bit) dell'header del segmento TCP; tale lunghezza può variare da 5 word (20 byte) a 15 word (60 byte) a seconda della presenza e della lunghezza del campo facoltativo Options.
  • Reserved [4 bit] - Bit non utilizzati e predisposti per sviluppi futuri del protocollo; dovrebbero essere settati a zero.
  • Flags [8 bit] - Bit utilizzati per il controllo del protocollo:
    • CWR (Congestion Window Reduced) - se settato a 1 indica che l'host sorgente ha ricevuto un segmento TCP con il flag ECE settato a 1 (aggiunto all'header in RFC 3168).
    • ECE (ECN-Echo) - se settato a 1 indica che l'host supporta ECN (Explicit Congestion Notification) durante il 3-way handshake (aggiunto all'header in RFC 3168).
    • URG - se settato a 1 indica che nel flusso sono presenti dati urgenti alla posizione (offset) indicata dal campo Urgent pointer;
    • ACK - se settato a 1 indica che il campo Acknowledgment number è valido;
    • PSH - se settato a 1 indica che i dati in arrivo non devono essere bufferizzati ma passati subito ai livelli superiori dell'applicazione;
    • RST - se settato a 1 indica che la connessione non è valida; viene utilizzato in caso di grave errore;
    • SYN - se settato a 1 indica che l'host mittente del segmento vuole aprire una connessione TCP con l'host destinatario e specifica nel campo Sequence number il valore dell' Initial Sequence Number (ISN); ha lo scopo di sincronizzare i numeri di sequenza dei due host. L'host che ha inviato il SYN deve attendere dall'host remoto un pacchetto SYN/ACK.
    • FIN - se settato 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.
  • Advertise Window [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) 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 è settato 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.

  • Sequence number e Acknowledgment number

    Il Sequence number, o numero di sequenza, serve a posizionare il carico utile del segmento TCP all'interno del flusso di dati.

    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 segmento inviato in ordine più la dimensione del carico utile dello stesso segmento (cioè del suo campo Data).

    In ricezione, TCP controlla se il numero di sequenza ricevuto è quello atteso e in caso affermativo può inviare direttamente il carico utile al processo di livello applicativo e liberare i propri buffer.

    Se invece riceve un numero di sequenza maggiore di quello atteso, deduce che uno o più segmenti ad esso precedenti sono andati persi o ritardati dal livello di rete sottostante. Pertanto, memorizza temporaneamente in un buffer il carico utile del segmento per poterlo consegnare al processo applicativo dopo aver ricevuto e consegnato anche tutti quelli precedenti. 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 infine 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 quindi scartato. Questo permette di realizzare l'eliminazione dei duplicati di rete.

    In ogni segmento inoltre, viene inviato un Acknowledgment Number, o numero di riscontro. 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.

    Il protocollo TCP adotta la politica di Conferma cumulativa, ciò significa semplicemente che l'arrivo di numero di riscontro indica al ricevente che il mittente ha ricevuto e correttamente inoltrato al proprio processo applicativo, il segmento avente numero di sequenza uguale al numero di riscontro indicato (-1) e anche tutti i segmenti ad esso precedenti. Per tale motivo, in trasmissione, TCP mantiene temporaneamente una copia di tutti i dati inviati ma non ancora riscontrati. Quando riceve un numero di riscontro per un segmento, ne deduce che tutti i dati precedenti a quel numero sono stati ricevuti correttamente e quindi libera il proprio buffer da questi dati.

    Per ciascun segmento inviato, TCP avvia un timer, detto timer di ritrasmissione RTO (Retransmission Time Out). Se il segmento non riceve un ACK prima che il timer scada, TCP assume che tutti i segmenti trasmessi a partire da quello siano andati persi e quindi li ritrasmette.

    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 adAcknowledgment 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; l'alternativa, ovvero progettare il protocollo di trasporto in modo che solo i pacchetti effettivamente persi vengano ritrasmessi, è detta 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 permettono quindi di realizzare la consegna affidabile, ovvero di garantire che tutti i dati inviati siano consegnati anche se alcuni pacchetti vengono persi dalla rete.

    FINE PRIMA PARTE