Le chiamate di funzione

La libreria fornita da Microsoft fornisce allo sviluppatore un ricco insieme di API: il nucleo centrale è basato sulla libreria di Berkeley, mentre un ulteriore insieme estende le funzionalità esportate con alcune caratteristiche specifiche per Windows.

Prosegue...

Concetti Preliminari

L’interfaccia di programmazione chiamata Windows Socket (Winsock) utilizza il paradigma delle socket introdotto dalla libreria BDS del mondo UNIX, anche se con qualche piccolo adattamento per il sistema operativo della Microsoft.

Prosegue...

Che cosa significa HTTP

HTTP è l'acronimo di “Hypertext Transfer Protocol”, il protocollo di rete impiegato per distribuire virtualmente sul World Wide Web (WWW) file HTML, immagini, o qualunque altro genere di informazioni. Più in generale il protocollo HTTP è utilizzato per trasmettere risorse, intendendo con questo termine qualsiasi blocco di informazione che possa essere identificata tramite un URL: le risorse più comuni sono certamente i file HTML, ma rientrano in questa categoria anche le pagine generate dinamicamente da un server, l'output di uno script CGI, ecc.

La comunicazione avviene tramite socket TCP e le entità che partecipano allo scambio dei dati sono il client HTTP (solitamente un browser web) ed il server HTTP.

Le transazioni del protocollo

Come molti altri protocolli di rete, HTTP segue il modello client-server: la transazione tipica ha inizio con il client che stabilisce una connessione con il server, inoltra la propria richiesta e rimane in attesa della risposta; il server, ricevuta la richiesta del client, la elabora, spedisce una risposta e chiude la connessione. Questo meccanismo si ripete per ogni transazione senza che il server mantenga alcuna memoria di ciò che è avvenuto durante le connessioni precedenti.

I formati di una richiesta e di una risposta HTTP sono molto simili, entrambi sono formati da: una linea iniziale, zero o più linee di intestazione, una linea bianca ed un messaggio opzionale (vedi il Riquadro seguente).

Ciascuna linea del messaggio HTTP dovrebbe terminare con CRLF (valori ASCII 10 e 13), sebbene molto più comunemente termini con LF solamente.

Si immagini di voler recuperare la risorsa identificata dall'URL seguente:

Volendo analizzare nel dettaglio il comportamento del client e del server a seguito della richiesta precedente, potremmo individuare quattro fasi diverse nella transazione HTTP.

1. Il client crea una connessione

Il client stabilisce una connessione TCP con il server www.sanlab.it sulla porta 80 (default); eventualmente l'utente può specificare una porta diversa da quella di default aggiungendola nel URL. Ad esempio la richiesta:

forza il client ad aprire una connessione sulla porta 8080.

2. Il client trasmette una richiesta

Il client spedisce un messaggio al server richiedendo la risorsa specificata nell'URL. Generalmente la linea iniziale della richiesta è formata di tre parti distinte, separate da uno spazio: il nome del metodo, il percorso locale della risorsa e la versione del protocollo utilizzato. La linea successiva rappresenta un esempio di richiesta.

Sebbene la sola linea iniziale sia già un messaggio HTTP completo, alcuni client possono includere altre informazioni che assumono la forma seguente:

La più comune delle keyword è Accepted, che specifica al server quale tipi di dati il client sia in grado di elaborare. Un'altra parola chiave molto utilizzata è User-Agent, che specifica il tipo di browser utilizzato dal client. Infine una linea vuota termina la richiesta ("\r\n\r\n"). Il Riquadro successivo mostra una possibile richiesta completa.

3. Il server risponde

Come nella richiesta, anche la linea iniziale della risposta, detta anche linea di stato, è composta di tre parti separate da spazi: la versione del protocollo HTTP, un codice di stato che informa sull'esito della richiesta, ed una frase in lingua inglese che descrive il significato del codice di stato, ad esempio:

Alla linea di stato seguono le linee di intestazione che forniscono informazioni sulla richiesta, la risposta oppure l'oggetto spedito nel corpo del messaggio. Se supponiamo che il file richiesto sia stato trovato dal server, allora una possibile risposta potrebbe essere:

Come si può notare da Riquadro 3, dopo le linee di intestazione segue una linea bianca e poi il corpo del messaggio. Se la risposta del server HTTP include un corpo, allora vi sono anche due linee di intestazione che descrivono la lunghezza (Content-Length: 21435) e la natura (Content-Type: text/html) del corpo.

4. Il server ed il client chiudono la connessione

Entrambi chiudono la connessione e per ogni successiva richiesta è utilizzata una nuova connessione. Inoltre se il client esegue una nuova richiesta al medesimo server viene aperta una nuova connessione anche se quella precedente non è ancora stata chiusa.

A questo punto il browser interpreta i dati ricevuti e li visualizza; nel caso in cui il documento contenga altri documenti o immagini, il Web browser inoltra ulteriori richieste al server finché tutte le informazioni non siano state elaborate. E' importante evidenziare che il server HTTP decide autonomamente ed in base alla sua configurazione se il documento richiesto sia un file che può essere recuperato dal file system, o se corrisponda ad un'applicazione. In questo ultimo caso, il server HTTP esegue l'applicazione e restituisce il suo output.

Le richieste HTTP

I metodi di richiesta più comuni del protocollo HTTP sono GET e POST. Il metodo GET è utilizzato per richiamare una risorsa dal server, mentre il metodo POST è utilizzato per spedire informazioni ad una risorsa sul server. Una risorsa è definita come un qualunque oggetto o servizio.

Un esempio del metodo GET potrebbe essere il seguente:

Mentre un esempio del metodo POST potrebbe essere:

Entrambi i metodi trasmettono alcune coppie Header/Value, mentre per delimitare ciascun metodo viene utilizzata una linea bianca.

Le risposte HTTP

In generale quando il server riceve una richiesta dal client, localizza la risorsa indicata nella richiesta, esegue il metodo richiesto dal client su quella risorsa, infine trasmette il risultato al client. Nel caso del metodo GET il server semplicemente forma una risposta che include la risorsa specificata nella richiesta. Nel caso del metodo POST, il server passa i dati inclusi nel POST alla risorsa e riceve un risultato dalla risorsa da includere nella risposta da trasmettere al client.

Le risposte cominciano con una linea di stato che consiste nella versione del protocollo del server, seguita da un codice di stato di risposta e da un messaggio di stato opzionale. Alcuni tipici codici di risposta con i relativi messaggi sono:

Come già visto, di seguito alla linea di stato vi sono una o più coppie header/valore e poi i dati.

Quindi, come per la richiesta, anche la risposta include una lista opzionale di coppie header/valore. Due di questi campi header (intestazione), "Content-Type" e "Content-Length", indicano rispettivamente il tipo e la lunghezza della risorsa che sta per essere ritornata. Il tipo della risorsa è descritto come un tipo MIME (RFC 1521), che può essere utilizzato per identificare qualunque risorsa inclusi tipi specifici di applicazioni.

Autenticazione

L'HTTP utilizza un meccanismo di autenticazione semplice ed estensibile. Il server emette una richiesta di autenticazione mandando al client una risposta con codice 401 (richiesta non autorizzata). Nella risposta sono specificati gli schemi di autenticazione supportati e tutti i parametri necessari per raggiungere l'autenticazione con lo schema adottato. Uno di questi parametri indica un dominio o uno spazio di protezione sul server. Questo permette che le risorse del server siano partizionate in regioni protette, ognuna con il suo schema di autenticazione e/o database di autorizzazione. Il client, a seguito di una risposta con codice 401, può riemettere la richiesta con un'intestazione di autenticazione che identifica lo schema in uso insieme con le necessarie credenziali per provare la propria identità per il dominio in questione.

Il linguaggio HTML

L'HTML è un linguaggio per la descrizione di documenti indipendente dalla piattaforma; è un sottoinsieme del SGML, che è uno standard ISO più elaborato per la composizione di documenti. L'HTML è stato ideato per collegamenti con piccola larghezza di banda. Questa sua caratteristica lo rende particolarmente adatto per trasportare informazioni formattate anche da sistemi "embedded".

La filosofia generale del linguaggio consiste nel non controllare tutti gli aspetti della visualizzazione. Attraverso il linguaggio il progettista della pagina da delle indicazioni alla stazione visualizzatrice sul layout del documento, senza controllare tutti gli aspetti fino al livello dei pixel. Questo minimizza la quantità di informazione necessaria che deve essere trasferita per visualizzare una particolare risorsa.

HTML è definito un linguaggio per ipertesti perché consente di specificare collegamenti ad altri documenti identificati tramite un URL (Uniform Resource Locator). Un URL è un modo per identificare univocamente la locazione di un file in Internet.

URL, URI e URN

Uniform Resource Identifier (URI) è un mezzo per localizzare in modo non ambiguo una risorsa su Internet. In genere la risorsa è un file, ma può essere anche un indirizzo email, un messaggio di un gruppo di discussione, un programma CGI, o qualunque altra cosa. Esistono due tipi di URI: Uniform Resource Locator (URL) e Uniform Resource name (URN). Un URL è un puntatore ad una particolare risorsa su Internet ad una specifica locazione. Per esempio, http://www.sanlab.it e ftp://sunsite.unc.edu/pub/javafaq sono entrambi URL. Un URN è un puntatore ad una particolare risorsa, ma senza un riferimento ad una specifica locazione. Gli URN sono stati pensati per poter gestire con facilità risorse duplicate in più locazioni o che possono essere spostate in più locazioni. Essi identificano la risorsa, non la locazione dove tale risorsa si trova.

Un URL specifica il protocollo utilizzato per accedere al server (ftp, http...), il nome del server e la locazione del file su quel server. La sintassi di un URL è la seguente:

protocol, qualche volta chiamato anche schema, definisce il protocollo da utilizzare per lo scambio dei dati e può essere uno dei seguenti:

La parte hostname definisce il server che fornisce la risorsa, ad esempio www.sanlab.it, e può essere rappresentato anche tramite il suo indirizzo IP.

port rappresenta il numero di porta ed è opzionale nel caso in cui il servizio sia in ascolto sulla porta di default (per i server HTTP la porta di default è la numero 80).

path, invece, punta ad una particolare directory sul server ed il percorso è relativo alla directory radice dei documenti, non necessariamente alla directory radice del file system.

filename punta ad un particolare file nella directory specificata dal path. Spesso il nome del file è omesso, in qesto caso il server spedisce un file a propria discrezione, in genere il file index.html, altri presentano la lista dei file presenti nella directory, altri ancora spediscono un messaggio di errore.

Infine section è utilizzato per far riferimento ad un punto specifico all'interno di un documento HTML.

Conclusioni

HTTP differisce da altri protocolli di livello 7 come FTP, per il fatto che le connessioni vengono generalmente chiuse una volta che una particolare richiesta (o una serie di richieste correlate) è stata soddisfatta; l'HTTP ha uno scambio di dati fondamentalmente stateless, cioè non mantiene memoria della storia delle richieste e delle risposte. La scelta di un protocollo "stateless", cioè di un protocollo che non "conserva memoria" delle connessioni effetuate, è conseguenza della natura del World Wide Web, che è costituito da un insieme di pagine connesse tra loro attraverso link ipertestuali e residenti su molti server differenti. Se da un lato, l'adozione di un protocollo stateless ha semplificato la realizzazione dei server HTTP, dall'altra ha notevolmente complicato la vita agli sviluppatori di applicazioni web che sono stati costresti a ricorrere a metodi alternativi (ad esempio i cookie) per conservare lo stato dell'utente.

L'architettura di un sistema di comunicazione, a causa della sua complessità, viene generalmente suddivisa in livelli funzionali. Ciascuno strato implementa un insieme di servizi utilizzati dal livello successivo per realizzare compiti più complessi. L'ultimo livello quindi per svolgere le proprie funzioni si avvale della collaborazione di tutti i livelli sottostanti. Il modello OSI (Open System Interconnection), ad esempio, divide l'operazione di trasferimento di dati da un luogo ad un altro in sette fasi gerarchiche, ognuna delle quali contribuisce ad assemblare e/o disassemblare i pacchetti che costituiscono il flusso delle informazioni.

La famiglia di protocolli TCP/IP è stata sviluppata prima che il modello OSI fosse definito, essa definisce solo quattro livelli ed a ciascun di questi è associato almeno un protocollo che specifica il comportamento di determinate funzioni di rete.

Poiché nell'ambito delle applicazioni di controllo di processo è essenziale disporre di un sistema di comunicazione affidabile, l'articolo focalizzerà l'attenzione sul livello di trasporto, che è il principale responsabile per il conseguimento di tale obiettivo.

Introduzione

La suite di protocolli TCP/IP mette a disposizione due differenti protocolli che implementano il livello di trasporto; di seguito saranno discussi i principali vantaggi e svantaggi di entrambi, al fine di capire quale sia il migiore candidato per l'implementazione della comunicazione tra processi che costituiscono un'applicazione di controllo distribuita.

Il protocollo IP della famiglia di protocolli TCP/IP, corrisponde al livello di rete nel modello OSI e fornisce le funzionalità base del trasferimento di dati che includono: indirizzamento, instradamento e frammentazione. Il livello di trasporto di questo stesso modello è costituito dal protocollo TCP, che risiede sopra il livello di rete, e implementa sia la comunicazione punto a punto, sia un'interfaccia comune utilizzabile dal livello applicazione.
In genere l'affidabilità della comunicazione è gestita o a livello di trasporto, o a livello di applicazione. Poiché la maggior parte dei bus di campo furono sviluppati prima che il TCP/IP diventasse popolare, implementano il concetto di affidabilità a livello di applicazione. Tuttavia esistono anche alcuni protocolli di bus di campo, quali il MODBUS/TCP, che si affidano al meccanismo di consegna garantita del TCP.
Il livello di trasporto dello stack TCP/IP mette a disposizione due protocolli, ciascuno dei quali può essere impiegato nelle reti di controllo: lo User Data Protocol (UDP) e il "trasmission Control Protocol" (TCP), entrambi esaminati in questo articolo.

User Datagram Protocol (UDP)

Il protocollo UDP fornisce un servizio di trasporto senza connessione e non affidabile, poiché non spedisce alla stazione trasmittente alcuna informazione sui dati ricevuti o persi. L'integrità dei dati, quindi, non è assicurata poiché è possibile la ricezione di pacchetti fuori sequenza o doppioni, all'insaputa della stazione di origine. 

Dal punto di vista della correttezza e affidabilità dei dati l'UDP non pare migliore del protocollo IP, ma introduce un concetto nuovo, utilizzato dal livello applicazione, i numeri di porta.

L'intestazione del protocollo UDP è corta e semplice (figura 1): richiede solo un supplemento di 8 byte. I campi relativi alle porte della stazione sorgente e di destinazione hanno una lunghezza di 16 bit ciascuno, perciò occupano 4 byte. Il campo "Message length", di 16 bit, indica la lunghezza dell'intestazione più quella dei dati. Infine il campo "checksum" di 16 bit è utilizzato per controllare la validità dell'intestazione e dei dati. 

Il livello di trasporto affida il datagramma UDP al protocollo IP che lo memorizza nel proprio campo dati ed inserisce propria intestazione gli indirizzi delle stazioni (ricevente e trasmittente). A sua volta il datagramma IP è incapsulato all'interno del frame Ethernet, che implementa il livello di collegamento dati, e finalmente spedito alla stazione desiderata. Una volta che il frame è giunto a destinazione viene eseguito il processo nell'ordine inverso. E' importante notare che l'unico contributo fornito dal protocollo UDP è l'assegnazione al messaggio di un numero di porta, che sarà utilizzato dal livello applicazione.

L'utilizzo del protocollo UDP implica che tutti i controlli relativi all'ordinamento ed alla quantità dei messaggi spediti e ricevuti, all'eliminazione dei pacchetti doppioni e all'eventuale ritrasmissione di pacchetti errati, siano tutte operazioni che devono essere eseguite dal livello applicazione. Allora se il livello applicazione è originariamente progettato per fornire un servizio di comunicazione affidabile, non c'è motivo di averlo anche nel livello di trasporto, rendendo sensato l'utilizzo del protocollo UDP. In questo caso il protocollo UDP risulta adeguato anche per applicazioni di controllo poiché ha un basso consumo delle risorse ed è eseguito con alte prestazioni.

I numeri di porta

Il protocollo IP consente di trasmettere un messaggio ad una determinata stazione ma, una volta giunto a destinazione, è necessario un meccanismo che consenta di recapitarlo all'applicazione corretta; per questo motivo il protocollo UDP introduce i numeri di porta. A ciascuna applicazione (o servizio) può essere associato un numero di porta ed ogni volta che la stazione riceve un datagramma UDP, inserisce i dati nella coda associata al numero di porta specificato nell'intestazione del pacchetto. Poiché è ammesso l'utilizzo di molti numeri di porta differenti è possibile supportare la comunicazione con più applicazioni anche contemporaneamente sulla stessa macchina. 

I numeri di porta sono codificati utilizzando 16 bit e classificati in tre differenti categorie: assegnati, registrati e dinamici.

I numeri di porta "assegnati" sono compresi nell'intervallo di valori da 0 a 1023 e sono stati definiti da "Internet Assigned Numbers Autority" (IANA) ed utilizzati da varie applicazioni che oggi sono considerate parte integrante della famiglia di protocolli TCP/IP, come TELNET, FTP ed altre. I numeri di porta appartenenti a questo intervallo sono definiti anche "well known" e non possono essere utilizzati da altre applicazioni.

I numeri di porta "registrati", invece, sono quelli che un organizzazione richiede allo IANA quando vuole definire un nuovo servizio. Le altre organizzazioni devono rispettare questo assegnamento e non utilizzare né i numeri di porta assegnati, né quelli registrati.

Infine i numeri di porta "dinamici" sono scelti in modo casuale da una stazione trasmittente per definire la porta sorgente a cui inviare la risposta. Per esempio, se la stazione A richiede il servizio "trivial file transfer protocol (TFTP) alla stazione B, inserirebbe 69 (una porta "well known" indicante il servizio TFTP) come porta di destinazione ed una porta dinamica (cioè un numero casuale ma non in conflitto con altre porte) come porta sorgente, infine la richiesta viene spedita alla stazione B. La stazione B riceve il pacchetto e riconosce che si tratta di una richiesta TFTP poiché il numero di porta di destinazione vale 69, quindi crea un pacchetto di risposta inserendo 69 come numero di porta sorgente e come porta di destinazione utilizza il numero di porta dinamico che trova nel pacchetto ricevuto, infine trasmette la risposta.

L'utilizzo dei numeri di porta assieme all'indirizzo IP costituisce ciò che è comunemente chiamato "socket" ed è rappresentato come <netid, hostid, portid>. Poiché esiste una procedura per l'assegnamento dei numeri di

porta, il socket diventa una rappresentazione univoca di una particolare applicazione nell'intera rete IP.

Transmition control protocol (TCP)

Il secondo protocollo del livello di trasporto è il TCP. Questo protocollo fornisce ai processi un servizio di consegna dei messaggi affidabile basato sulla connessione. Questo solleva il livello applicazione dalla responsabilità di garantire la consegna dei messaggi. Oltre alle connessioni affidabili il TCP mette a disposizione il controllo del flusso per assicurare che le stazioni non siano intasate per la quantità di dati trasmessi.

I dati scambiati tra le stazioni sono spediti come una sequenza di pacchetti e riassemblati dalla stazione ricevente in modo da ricreare il flusso di dati iniziale. Durante la trasmissione i pacchetti possono corrompersi, perdersi o raggiungere la stazione di arrivo con un ordine differente da quello di partenza. Una tecnica utilizzata per risolvere questo tipo di problemi consiste nell'associare a ciascun pacchetto un numero di sequenza, indipendentemente da quale sia il numero di sequenza del pacchetto iniziale, al secondo pacchetto sarà associato un numero di sequenza pari a quello del primo pacchetto più uno, e tutti i successivi pacchetti del flusso di dati avranno numeri sequenza crescenti, ciascuno incrementato di una unità rispetto a quello precedente. Ogni volta che la stazione di arrivo riceve un nuovo pacchetto senza errori spedisce un messaggio di acknowledgment per informare la stazione di origine della avvenuta ricezione del pacchetto. Quando tutti i pacchetti sono stati ricevuti, allora i numeri di sequenza sono utilizzati per ordinare in modo corretto la sequenza di pacchetti. Se tutti i pacchetti risulteranno corretti, allora il flusso di dati è stato ricevuto correttamente e la stazione ricevente può informare la stazione di partenza dell'avvenutà ricezione, altrimenti invia una richiesta di ritrasmissione del solo pacchetto mancante o corrotto. In questo modo si evita di dover richiedere la ritrasmissione dell'intero flusso di dati.

E' bene notare che i messaggi di "acknowledgment" non richiedono una trasmissione separata; per motivi di efficienza il TCP consente di spedire tale messaggio con i dati: se la stazione B sta rispondendo alla richiesta della stazione A, allora i dati possono essere spediti contemporaneamente al messaggio di acknowledgment del pacchetto di richiesta della stazione A. Questa tecnica velocizza l'intero processo.

In realtà il TCP fornisce un protocollo sequenziale orientato al byte, che risulta più robusto rispetto allo schema orientato ai pacchetto descritto in precedenza. Invece di sequenzializzare ciascun pacchetto, il TCP associa un numero di sequenza a ciascun byte: più precisamente il TCP associa un numero di sequenza al primo byte di dati presente nel pacchetto iniziale, mentre il secondo pacchetto avrà un numero di sequenza pari al primo numero di sequenza più il numero di byte presenti nel primo pacchetto. La stazione ricevente segnala la ricezione di un pacchetto valido trasmettendo un "acknowledgment" che contiene il valore del prossimo numero di sequenza previsto, cioè il numero di sequenza dell'ultimo byte del pacchetto ricevuto o più uno. Una volta ricevuto questo "acknowledgement" il trasmettirore può assumere che tutti i byte predenti a quello con il numero di sequenza indicato siano stati ricevuti correttamente e può quindi può "dimenticarli". Affiché la stazione di partenza possa eliminare i byte spediti dal buffer di trasmissione è necessario che attenda questo "acknowledgment" poiché il ricevente può sempre richiedere una ritrasmissione dei byte.

L'intestazione del TCP è più grande di quella del UDP (figura 2), ma usa lo stesso schema di quest'ultimo per l'assegnamento delle porte . A differenza dell'UDP, l'intestazione contiene anche un numero di sequenza a 32 bit, un numero di "acknowledgement" e molti bit di flag. Poiché l'intestazione del TCP può essere di lunghezza variabile, a seconda del contenuto del campo "options", è presente un ulteriore campo chiamato "data offset" per determinare l'inzio dei dati. Il campo "padding" è utilizzato per allineare il campo "options" sul 32 bit.

Il campo window indica al trasmettitore quanti dati il ricevitore vuole accettare. Infine i dati seguono l'intestazione del TCP. L'intestazione può essere composto al massimo da 40 byte. L'insieme dell'intestazione più i dati successivi è detto segmento. Il campo di cheksum assicura l'integrità dell'intestazione dei dati.

Utilizzare le connessioni

Quando si utilizza il TCP, prima di tutto deve essere stabilita e mantenuta una connessione, in modo da creare un canale attraverso cui trasmettere il flusso dei dati. Instaurando una connessione tra due stazioni vengono creati alcuni buffer di dimensioni opportune per mantenere i dati trasmessi e ricevuti.

Quando la stazione A vuole comunicare con la stazione B, stabilisce una connessione che gestisce la sincronizzazione ed il numero degli "acknowlegment". Questo processo è mostrato in figura 3. Uno dei flag dell'intestazione del TCP è il bit SYN, che è utilizzato per indicare il numero di sequenza iniziale quando viene stabilita una connessione. Questo informa il ricevitore di sincronizzare il suo controllo degli errori con questo numero di sequenza. Perciò la stazione A spedisce alla stazione B un segmento TCP con il suo numero di sequenza (che nel caso rappresentato in figura è 10) ed il flag SYN impostato. La stazione B risponde spedendo un "acknowledgment" con il valore 11, cioè il valore del prossimo numero di sequenza che si aspetta di ricevere ed il proprio numero di sequenza, che nel nostro caso è 30. Questo valore è confermato dalla stazione A che a sua volte trasmette un 31. Al termine di queste operazioni sono state stabilite due connessioni, attraverso le quali le due stazioni possono scambiarsi i dati. Ogni volta che la stazione A spedisce dei dati alla stazione B, la prima incrementa il numero di sequenza e la seconda lo conferma. Questo tipo di connessione è denomitata "full duplex", perché utilizza due canali contemporanemente: una da A a B e l'altra da B ad A. Queste connessioni rimangono attive finché non sono esplicitamente terminate.  

Una volta che il trasferimento dei dati è completato, le due connessioni dovrebbero essere terminate in modo da liberare la memoria allocata per i buffer nelle due stazioni. Per terminare una connessione è utilizzato il flag FIN: la stazione A spedisce un segmento TCP con il flag FIN impostato ed un numero di sequenza, la stazione B riconosce la richiesta e spedisce un ACK, quando la stazione A riceve l'ACK la connessione da A a B è terminata.

E' necessario seguire la medesima procedura per chiudere anche la connessione da B ad A.

Controllo di flusso

Il controllo di flusso riguarda la gestione del traferimento di dati tra due stazioni. A seconda del ruolo della stazione, client o server, o della sua potenza di calcolo, una stazione può non essere in grado di sostenere il traffico della rete. Per rallentare gli eventi l'intestazione del TCP ha un campo chiamato "window". La stazione ricevente utilizza tale campo per specificare alla stazione trasmittente quanti byte è in grado di accettare. La finistra ha una dimesione dinamica che può essere aumentata non appena sarà disponibile nuovo spazio nel buffer del ricevitore. La finistra può anche avere dimensione zero, bloccando così la trasmissione dei dati. Se il trasmettitore avesse la necessità di comunicare informazioni nonostante la dimesione della finestra non lo consenta, può spedire un pacchetto con il flag URG impostato ed un numero di sequenza nel campo "urgent pointer" (che indica il primo byte che segue i dati urgenti). Il ricevitore dovrebbe avere sempre dello spazio per consentire la ricezione di dati urgenti.

Conclusioni

Sebbene il TCP sia più affidabile del protocollo UDP, quest'ultimo può risultare adatto se il software del livello applicazione è in grado di trattare il controllo dell'errore e la ritrasmissione; invece, per le applicazioni che richiedono una comunicazione sicura, il TCP è la scelta migliore.

La codifica Manchester consiste nel suddividere il periodo di un bit in due intervalli uguali; il bit 1 è trasmesso con la tensione alta durante il primo intervallo e bassa nel secondo, mentre per il bit 0 avviene l'opposto: prima bassa e poi alta. Questo metodo garantisce che ciascun periodo di un bit abbia sempre una transizione nel mezzo.

La codifica Manchester fornisce un modo semplice per codificare sequenze binarie arbitrarie senza mai aver lunghi periodi di tempo privi di transizioni di clock, il che permette di prevenire la perdita della sincronizzazione del clock.