1 \chapter{Introduzione alla rete}
4 In questo capitolo sarà fatta un'introduzione ai contetti generali che servono
5 come prerequisiti per capire la programmazione di rete ed esamineremo a grandi
6 linee i protocolli di rete e come questi sono organizzati e interagiscono.
8 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
9 programmazione di rete, ci concentreremo sul protocollo più diffuso che è
10 quello che sta alla base di internet, ed in particolare sulle parti più
11 importanti ai fini della programmazione.
14 \section{Il modello client-server}
15 \label{sec:net_cliserv}.
17 La differenza principale fra un'applicazione di rete e un programma normale è
18 che quest'ultima per definizione concerne la comunicazione fra ``processi''
19 diversi (che in generale non girano neanche sulla stessa macchina). Questo già
20 prefigura un cambiamento completo rispetto all'ottica del ``programma''
21 monolitico all'interno del quale vengono eseguite tutte le istruzioni, e
22 presuppone un sistema operativo ``multitasking'' in grado di eseguire processi
25 Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
26 sotto Unix in generale) è il modello \textit{client-server} in cui un
27 programma di servizio, il \textit{server} riceve un connessione e risponde a
28 un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
29 definito insieme di servizi.
31 Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni
32 servizio che viene fornito tramite la rete, ma il modello è utilizzato in
33 generale anche per programmi di uso locale.
35 Normalmente si dividono i server in due categorie principali,
36 \textit{concorrenti} e \textit{iterativi}, sulla base del loro comportamento.
38 Un server iterativo risponde alla richiesta inviando i dati e resta occupato
39 (non rispondendo ad ulteriori richieste) fintanto che non ha concluso la
40 richiesta. Una volta completata la richiesta il server diventa di nuovo
43 Un server concorrente al momento di trattare la richiesta crea un processo
44 figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di
45 ulteriori richieste. In questo modo più richieste possono essere soddisfatte
46 contemporaneamente, una volta che il processo figlio ha concluso il suo lavoro
47 viene terminato, mentre il server originale resta sempre attivo.
50 \section{I protocolli di rete}
51 \label{sec:net_protocols}
53 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
54 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
55 ottica, alle comunicazioni via satellite; per rendere possibile la
56 comunicazione attraverso un così variegato insieme di mezzi sono stati
57 adottati una serie di protocolli, il più famoso dei quali, quello alla base
58 del funzionamento di internet, è il cosiddetto TCP/IP.
60 \subsection{Il modello ISO/OSI}
61 \label{sec:net_iso_osi}
63 Una caratteristica comune dei protocolli di rete è il loro essere strutturati
64 in livelli sovrapposti; in questo modo un livello superiore esegue richieste
65 al livello sottostante e da questo riceve responsi, mentre livelli uguali su
66 macchine diverse conversano tramite lo stesso protocollo. Questo modello di
67 funzionamento è stato stato standardizzato dalla \textit{International
68 Standards Organization} (ISO) che ha preparato fin dal 1984 il Modello di
69 Riferimento \textit{Open Systems Interconnection} (OSI), strutturato in sette
70 livelli, secondo la tabella in \ntab.
74 \begin{tabular}{l c c l}
75 \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \\
77 Livello 7&\textit{Application} &\textsl{Applicazione}& \\
78 Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\
79 Livello 5&\textit{Session} &\textsl{Sessione}& \\
80 Livello 4&\textit{Transport} &\textsl{Trasporto}& \\
81 Livello 3&\textit{Network} &\textsl{Rete}& \\
82 Livello 2&\textit{DataLink} &\textsl{Collegamento Dati}& \\
83 Livello 1&\textit{Connection} &\textsl{Connessione Fisica}& \\
86 \caption{I sette livelli del protocollo ISO/OSI.}
87 \label{tab:net_osilayers}
90 Il modello ISO/OSI è stato sviluppato corrispondentemente alla definizione
91 della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante
92 il lavoro dettagliato di standardizzazione il modello si è rivelato
93 sostanzialmente troppo complesso e poco flessibile rispetto a quello,
94 precedente, su cui si basa TCP/IP che è diventato uno standard de facto;
95 quest'ultimo viene comunemente chiamato modello DoD (\textit{Department of
96 Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
97 della Difesa Americano.
99 \subsection{Il modello DoD (TCP/IP)}
100 \label{sec:net_tcpip_overview}
102 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
103 \ntab); un confronto fra i due è riportato in \nfig dove viene evidenziata
104 anche la corrispondenza fra i rispettivi livelli (che comunque è
105 approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
106 operativo rispetto alla divisione fra user space e kernel space spiegata in
107 \ref{sec:intro_unix_struct}.
111 \begin{tabular}{l c c l}
112 \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \textbf{Esempi} \\
114 Livello 1&\textit{Application} &\textsl{Applicazione}&
116 Livello 2&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
117 Livello 3&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
118 Livello 4&\textit{Link} &\textsl{Connessione}&
119 device driver \& scheda di interfaccia \\
122 \caption{I quattro livelli del protocollo TPC/IP.}
123 \label{tab:net_layers}
127 Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in
128 soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo
129 compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
130 \textit{Internet Protocol}. Le funzioni dei vari livelli sono le seguenti:
133 \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
134 genere questi vengono realizzati secondo il modello Client-Server (vedi
135 \ref{sec:net_cliserv}.
136 \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
137 terminali su cui girano gli applicativi, regola il flusso delle
138 informazioni, e può fornire un trasporto affidabile, cioè con recupero
139 errori. Il protocollo principale di questo livello è il TCP.
140 \item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una
141 rete complessa e interconnessa, a questo stesso livello operano i protocolli
142 per il reperimento delle informazioni necessarie allo smistamento, per lo
143 scambio di messaggi di controllo e per il monitoraggio della rete. Il
144 protocollo su cui si basa questo livello è IP (sia nella attuale versione,
145 IPv4 che nella nuova IPv6).
146 \item \textbf{Connessione} È responsabile per l'interfacciamento al
147 dispositivo elettronico che effettua la comunicazione fisica, gestendo
148 l'invio e la ricezione dall'hardware dei pacchetti.
152 La comunicazione fra due stazioni avviene pertanto secondo le modalità
155 Le singole applicazioni si scambieranno i dati secondo un loro formato
156 specifico, implementando un protocollo di applicazione (esempi possono essere
157 HTTP, POP, telnet, SMTP, etc).
159 Questi dati vengono inviati al livello di trasporto usando un'interfaccia
160 opportuna (i \textit{socket}, che esamineremo in dettaglio in seguito), i
161 quali li spezzerà in pacchetti di dimensione opportuna e li incapsulerà
162 all'interno del suo protocollo di trasporto aggiungendo ad ogni pacchetto le
163 informazioni necessarie alla gestione di quest'ultimo. Questo processo viene
164 svolto dirattamente nel kernel ad esempio dallo stack TCP nel caso il
165 protocollo di trasporto sia questo.
167 Una volta composto il pacchetto nel formato adatto al protocollo di trasporto
168 usato questo sarà passato al successivo livello, quello del collegamento che
169 si occupa di inserire le opportune informazioni per poter effettuare
170 l'instradamento nella rete ed il recapito alla destinazione finale. In genere
171 questo è il livello di IP (Internet Protocol), a cui vengono inseriti i numeri
172 IP che identificano i computer su internet.
174 L'ultimo passo è il trasferimento del pacchetto al driver della interfaccia di
175 trasmissione che si incarica di incapsularlo nel relativo protocollo di
176 trasmissione fisica usato dall'hardware usato per la comunicazione (ad esempio
177 ethernet per una scheda di rete).
180 \subsection{Criteri generali del design di TCP/IP}
181 \label{sec:net_tcpip_design}
183 La filosofia architetturale di TCP/IP è semplice: costruire una rete che
184 possa sopportare il carico in transito, ma permettere ai singoli nodi di
185 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
186 errati o non recapitabili.
188 L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
189 di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
190 natura inaffidabile, in quanto non è assicurata né una percentuale di
191 successo né un limite sui tempi di consegna dei pacchetti.
193 È il livello di trasporto che si deve occupare (qualora necessiti) del
194 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
195 dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
196 al livello di trasporto o superiore.
198 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
199 terminali di comunicazione, ma possono anche assumere il ruolo di router, per
200 l'interscambio di pacchetti da una rete ad un'altra. Questo rende possibile la
201 flessibilità della rete che è in grado di adattarsi ai mutamenti delle
204 La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
205 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
206 nel formato del livello successivo, fino al livello della connessione fisica.
207 In questo modo il pacchetto ricevuto ad un livello $n$ dalla stazione di
208 destinazione è esattamente lo stesso spedito dal livello $n$ dalla sorgente.
209 Questo rende facile il progettare il software facendo riferimento unicamente a
210 quanto necessario ad un singolo livello, con la confidenza che questo poi sarà
211 trattato uniformemente da tutti i nodi della rete.
214 \section{Il protocollo TCP/IP}
215 \label{sec:net_tpcip}
217 Come già affermato il protocollo TCP/IP è un insieme di protocolli diversi,
218 che operano su 4 livelli diversi. Per gli interessi della programmazione di
219 rete però sono importanti principalmente i due livelli centrali, e soprattutto
220 quello di trasporto, su cui è innestata l'interfaccia fra kernel space e user
223 Il livello 4 infatti è normalmente gestito dal kernel, e si accede ad esso
224 solo quando si vogliono fare applicazioni di sistema per il controllo della
225 rete (locale) a basso livello, un uso quindi molto specialistico. Il livello 1
226 invece dipende dalle singole applicazioni ed è di nuovo troppo specifico per
227 essere affrontato qui.
229 In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
230 ma ci concentreremo principalmente sul livello di trasposto e in particolare
231 sul protocollo TCP sia per il ruolo centrale che esso svolge nella maggior
232 parte delle applciazioni, sia per la sua complessità che necessita di maggiori
235 \subsection{Il quadro generale}
237 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
238 altri membri. In \nfig si è riportato una figura di quadro che mostra un
239 panorama sull'intera famiglia, e di come i vari protocolli vengano usati dalle
242 La figura è da fare ...
244 I vari protocolli mostrati in figura sono i seguenti:
247 \item \textsl{IPv4} \textit{Internet Protocol version 4}. È quello che
248 comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
249 cui è cotriuta internet. Usa indirizzi a 32 bit e provvede la trasmissione
250 dei pacchetti TCP, UDP, ICMP e IGMP.
251 \item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a
252 metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua
253 lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
254 \item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
255 orientato alla connessione che provvede un trasporto affidabile e
256 bidirezionale di un flusso di dati. I socket TCP sono esempi di
257 \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
258 trasporto, come l'acknoweledgment, i timout, la ritrasmissione, etc. È usato
259 dalla maggior parte delle applicazioni. Può essere usato sia con IPv4 che
261 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
262 connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
263 socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
264 garanzia che i pacchetti raggiungano la loro destinazione, né sull'eventuale
265 ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
266 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
267 errori e trasporta l'informazione di controllo fra stazioni remote e
268 instradatori (\textit{router} e \textit{host}). I messaggi sono normalmente
269 generati dal software del kernel che gestisce la comunicazione TCP/IP, anche
270 se può venire usato direttamente da alcuni programmi come \texttt{ping}. A
271 volte ci si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
272 \item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
273 protocollo usato per il \textit{multicasting} (vedi
274 \ref{sec:xxx_multicast}), che è opzionale in IPv4.
275 \item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
276 mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
277 internet). È usato in reti di tipo broadcast come ethernet, token ring o
278 FDDI ma non serve in connessioni punto-punto.
279 \item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
280 protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
281 volte per durante il boot per assegnare un indirizzo IP ad una macchina.
282 \item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}.
283 Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
284 \item \textsl{NETLINK} \textit{Netlink}.
285 Provvede l'interfaccia di accesso alla comunicazione a basso livello.
288 Gran parte delle applicazioni comunicano usando TCP o UDP, ed alcune si
289 rifanno ad IP (ed i suoi correlati ICMP e IGMP); benché sia TCP che UDP siano
290 basati su IP e sia possibile intervenire a questo livello con i \textit{raw
291 socket} questa tecnica è molto meno diffusa e a parte applicazioni
292 particolari si preferisce sempre usare i servizi messi a disposizione dai due
293 protocolli precedenti. Per questo motivo a parte alcuni brevi accenni su IP
294 in questa sezione ci concentreremo sul livello di trasporto.
296 \subsection{Internet Protocol (IP)}
299 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
300 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
301 venne standardizzata nel 1981 dall'RFC~719.
303 Internet protocol nasce per disaccoppiare le applicazioni della struttura
304 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
305 dei dati indipendente dal sottostante substrato di rete, che può essere
306 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
307 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
308 all'altro della rete; le caratteristiche essenziali con cui questo viene
309 realizzato in IPv4 sono due:
312 \item \textit{Universal addressing} la comunicazione avviene fra due host
313 identificati univocamente con un indirizzo a 32 bit che può appartenere ad
314 una sola interfaccia di rete.
315 \item \textit{Best effort} viene assicurato il massimo impegno nella
316 trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
317 percentuale di successo né sul tempo di consegna dei pacchetti di dati.
320 Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
321 internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
322 problemi si è perciò definita una nuova versione del protocollo, che (saltando
323 un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
324 IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
325 eliminando quelle inutili e aggiungendone poche altre per mantenere il
326 protocollo il più snello e veloce possibile.
328 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
329 grandi linee nei seguenti punti:
331 \item l'espansione delle capacità di indirizzamento e instradamento, per
332 supportare una gerarchia con più livelli di indirizzamento, un numero di
333 nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
334 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
335 si aggiungono agli usuali \textit{unycast} e \textit{multicast}
336 \item la semplificazione del formato della testata, eliminando o rendendo
337 opzionali alcuni dei campi di IPv4, per eliminare la necessità di
338 riprocessamento della stessa da parte dei router e contenere l'aumento di
339 dimensione dovuto ai nuovi indirizzi
340 \item un supporto per le opzioni migliorato, per garantire una trasmissione
341 più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
342 delle opzioni, e la flessibilità necessaria per introdurne di nuove in
344 \item il supporto per delle capacità di qualità di servizio (QoS) che permetta
345 di identificare gruppi di dati per i quali si può provvedere un trattamento
346 speciale (in vista dell'uso di internet per applicazioni multimediali e/o
350 Per maggiori dettagli riguardo al protocollo si può consultare
354 \subsection{UDP: User Datagram Protocol)}
357 UDP è un protocollo di trasporto molto semplice, la sua descizione completa è
358 contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP dal
359 livello di trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto
360 di dati (il cosiddetto \textit{datagram} che da il nome al protocollo) su un
361 socket, al pacchetto viene aggiunto un header molto semplice (per una
362 descrizione più accurata vedi \ref{sec:appA_udp}), e poi viene passato al
363 livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione.
364 Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il
365 pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso
366 ordine in cui sono stati spediti.
368 Pertanto il problema principale che si affronta quando si usa UDP è la
369 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
370 destinazione occorrerà provvedere con l'applicazione all'interno della quale
371 si dovrà inserire tutto quanto necessario a gestire la notifica di
372 ricevimento, la ritrasmissione, il timeout.
374 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
375 stesso ordine in cui sono stati trasmessi, e può anche accadere che i
376 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
377 questo di nuovo deve tenere conto l'applicazione.
379 Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
380 destinazione esso viene passato all'applicazione ricevente in tutta la sua
381 lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
382 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
384 Infine UDP è un protocollo che opera senza connessione
385 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
386 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
387 in cui un client può scrivere su uno stesso socket pacchetti destinati a
388 server diversi, o un server ricevere su un socket paccetti provenienti da
389 client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è
390 quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più
391 stazioni usando la stessa frequenza.
393 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
394 grande pregio della velocità che in certi casi è essenziale; inoltre si presta
395 bene per le applicazioni in cui la connessione non è necessaria e
396 costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può
397 essere tollerata, come quelle che usano il multicasting.
399 \subsection{TCP: Transport Control Protocol)}
402 Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
403 diverso da UDP; alla base del suo design infatti non stanno semplicità e
404 velocità, ma la ricerca della massima affidabilità possibile nella
405 trasmissione dei dati.
407 La prima differenza con UDP è che TCP provvede sempre una conessione diretta
408 fra un client e un server, attraverso la quale essi possono comunicare; per
409 questo il paragone più appropriato per questo protocollo è quello del
410 collegamento telefonico, in quanto prima viene stabilita una connessione fra
411 due stazioni su cui poi viene effettuata una comunicazione diretta.
413 Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
414 inviati attraverso una connessione ne viene richiesto un ``ricevuto''
415 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
416 ritrasmessi facendo un determinato numero di tentativi intervallati da un
417 periodo di tempo crescente, fintanto che la connessione sarà considerata
418 fallita o caduta la connessione (con un errore di \textit{time-out}), dopo un
419 periodo di tempo che dipende dall'implementazione e che può variare far i
420 quattro e i dieci minuti.
422 Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
423 di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
424 tempo di andata e ritorno dei pacchetti (il cosiddetto RTT,
425 \textit{round-trip time}) fra un client e un server che lo rende in grado di
426 adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o
427 cadere facilmente in timeout.
429 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
430 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
431 bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due
432 segmenti (le unità di dati passate da TCP a IP vengono chiamate
433 \textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di
434 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
435 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
436 più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
437 all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati.
439 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
440 cioè specifica sempre all'altro capo della trasmissione quanti dati può
441 ricevere tramite una \textit{advertised window} (letteralmente finestra
442 annunciata), che indica lo spazio disponibile nel buffer di ricezione,
443 cosicchè nella trasmissione non vengano inviati più dati di quelli che possono
446 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
447 socket ed aumentando con la lettura di quest'ultimo da parte
448 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
449 verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
450 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
451 ricevitore non può sostenere.
453 Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
454 \textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
455 stesso tempo, il che poi comporta che quanto dicevamo a proposito del
456 controllo di flusso e della gestione della sequenzialità dei dati viene
457 effettuato per entrambe le direzioni di comunicazione.
459 \subsection{Creazione e terminazione della connessione TCP}
461 Per capire il funzionamento delle funzioni della interfaccia dei socket che
462 operano con TCP (come \texttt{connect}, \texttt{accept} e \texttt{close} che
463 vedremo più avanti) è fodamentale capire come funziona la creazione e la
464 conclusione di una connessione TCP.
469 \subsection{Le porte}