+Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
+diverso da UDP; alla base del suo design infatti non stanno semplicità e
+velocità, ma la ricerca della massima affidabilità possibile nella
+trasmissione dei dati.
+
+La prima differenza con UDP è che TCP provvede sempre una connessione diretta
+fra un client e un server, attraverso la quale essi possono comunicare; per
+questo il paragone più appropriato per questo protocollo è quello del
+collegamento telefonico, in quanto prima viene stabilita una connessione fra
+due i due capi della comunicazione su cui poi viene quest'ultima viene
+effettuata.
+
+Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
+inviati attraverso una connessione ne viene richiesto un ``ricevuto''
+(il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
+ritrasmessi per un determinato numero di tentativi, intervallati da un
+periodo di tempo crescente, fino a che sarà considerata fallita o caduta la
+connessione (e generato un errore di \textit{time-out}), dopo un periodo di
+tempo che dipende dall'implementazione e che può variare far i
+quattro e i dieci minuti.
+
+Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
+di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
+tempo di andata e ritorno dei pacchetti (il cosiddetto RTT,
+\textit{round-trip time}) fra un client e un server che lo rende in grado di
+adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o
+cadere facilmente in timeout.
+
+Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
+sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
+byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
+segmenti (le unità di dati passate da TCP a IP vengono chiamate
+\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
+sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
+i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
+più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
+all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati.
+
+Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
+cioè specifica sempre all'altro capo della trasmissione quanti dati può
+ricevere tramite una \textit{advertised window} (letteralmente finestra
+annunciata), che indica lo spazio disponibile nel buffer di ricezione,
+cosicché nella trasmissione non vengano inviati più dati di quelli che possono
+essere ricevuti.
+
+Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
+socket ed aumentando con la lettura di quest'ultimo da parte
+dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
+verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
+ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
+ricevitore non può sostenere.
+
+Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
+\textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
+stesso tempo, il che poi comporta che quanto dicevamo a proposito del
+controllo di flusso e della gestione della sequenzialità dei dati viene
+effettuato per entrambe le direzioni di comunicazione.
+
+Una descrizione più accurata del protocollo è fornita in appendice
+\capref{cha:tcp_protocol}.
+
+\subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
+\label{sec:net_lim_dim}
+
+Un aspetto di cui bisogna tenere conto, e che ritornerà in seguito, è che ci
+sono una serie di limiti a cui la trasmissione dei dati attraverso i vari
+livelli del protocollo deve sottostare, limiti che è opportuno tenere presente
+perché in certi casi si possono avere delle conseguenze sul comportamento
+delle applicazioni.
+
+Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle
+loro origini ed alle eventuali implicazioni che possono avere:
+\begin{itemize}
+\item La dimensione massima di un pacchetti IP è di 65535 byte, compreso
+ l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
+ apposito nell'header di IP che è lungo 16 bit (vedi
+ \tabref{tab:IP_ipv4head}).
+\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
+ il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
+ dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
+ suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
+ un pacchetto usando la \textit{jumbo payload option}.
+\item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
+ dipende dal protocollo specifico usato al livello di link. Il più comune è
+ quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili
+ sono riportati in \ntab.
+\end{itemize}