Riassunto Reti di Calcolatori, prof. Riccobene

SOCKET

2. , per collegarlo ad un indirizzo specifico

BIND

3. , per rimanere in ascolto in attesa di connessioni

LISTEN

4. , per collegare la socket alla prima connessione (riuscita) in arrivo

ACCEPT

Un client esegue in ordine:

1. , per creare l'endpoint

SOCKET

2. , per tentare la connessione con il server

CONNECT

Il client non ha bisogno di un indirizzo specifico, quindi non viene usata . Il sistema operativo assegnerà un indirizzo automaticamente.

BIND

Dopodiché entrambi usano e per scambiare dati. Ognuno poi chiude unilateralmente la sua “metà” della connessione con

SEND RECEIVE

.

CLOSE

Fairness tra connessioni TCP

Se sessioni TCP condividono un canale a banda limitata (bottleneck link

), ognuna di esse dovrebbe ottenere della capacità del

N 1/N

collegamento. (Additive increase/multiplicative decrease)

Il metodo AIMD usato per il controllo della congestione assicura che, dopo un certo numero di

iterazioni, questo risultato sarà approssimativamente raggiunto.

L'algoritmo TCP Reno, il più utilizzato in Internet, garantisce una buona fairness.

Dimostrazione grafica

Prendiamo il caso di due connessioni TCP su un canale stretto.

Il grafico sottostante mostra l'andamento della finestra di congestione complessiva.

La linea tratteggiata indica un uso equo del canale, la linea continua indica il pieno utilizzo del canale.

L'intersezione tra queste due linee è il punto ideale di fairness (massima utilizzazione e massima equità).

L'incremento della finestra di congestione è indicato dalle linee di 45°, che indicano che inizialmente entrambe le finestre crescono

linearmente.

Al primo segmento perso la finestra si dimezzerà, come indicato dalle linee che tornano verso l'origine.

Dopo un certo numero di iterazioni, entrambe le finestre convergeranno al punto di fairness , ovvero l'intersezione delle due linee principali.

Appunti Reti - © 2017 Mario Cianciolo <mr.udda@gmail.com>

Livello applicazione

Il livello Applicazione contiene i protocolli per le comunicazioni Internet da processo a processo, con modelli peer-to-peer o client-server.

L'unico livello superiore a questo è l'interfaccia utente.

Comunicazione tra processi

Le applicazioni richedono un canale bidirezionale per scambiare dati. Questo canale è, come sappiamo, fornito dal livello di trasporto (in UNIX tramite i Socket

).

I processi dello strato applicazione scambiano dati attraverso uno o più protocolli

, in base alla loro natura e al loro scopo.

Sistemi distribuiti

In un sistema distribuito due processi remoti possono procedere in parallelo solo se riescono a sincronizzarsi. Lo scambio dei messaggi consente la sincronizzazione.

Modello Client-Server

In un modello di comunicazione client-server, esistono due tipi di applicazione:

Applicazione server-side , che fornisce i servizi e condivide risorse

Applicazione client-side , normalmente più semplice, utilizza servizi e risorse del server

Indirizzamento nella comunicazione tra processi

Due processi comunicano collegando i rispettivi livelli di trasporto. In UNIX, vengono usati i Socket

.

Numeri di porta

I possibili numeri di porta vanno da 0 a 65535 (valore 16 bit).

Le porte sono suddivise in tre gruppi:

G I N

RUPPO NTERVALLO OTE

Well known ports o 0-1023 riservate a processi di sistema, per usarle servono privilegi di superuser

System ports 1024-

Registered ports assegnate per qualche uso da IANA, per usarle non servono privilegi di superuser

49151

49152- contiene porte dinamiche (utilizzate per una singola connessione e poi liberate) o private, non possono

Dynamic/Private ports 65535 essere registrate da IANA

Molti protocolli largamente usati hanno dei numeri di porta fissi nell'intervallo delle well known ports.

Requisiti delle applicazioni

In base alla natura dell'applicazione, i requisiti sono diversi:

Affidabilità

: alcune applicazioni (streaming, videochiamate) possono permettersi di perdere qualche pacchetto, altre invece no (e-mail, trasferimento file)

Larghezza di banda

: alcune applicazioni scambiano pochi dati (chat), mentre altre hanno bisogno di più larghezza di banda (trasferimento file, e-mail con allegati)

Sensibilità al tempo : alcune applicazioni hanno bisogno di bassi ritardi (video in tempo reale, giochi interattivi), altre invece non hanno particolari esigenze in

termini di tempo (e-mail, trasferimento file)

I requisiti condizionano la scelta del protocollo di trasporto, ad esempio:

dove è importante l'affidabilità, l'applicazione sceglierà di usare TCP al livello di trasporto

dove è importante la latenza, l'applicazione potrebbe preferire UDP per via della maggiore velocità di elaborazione

Il protocollo HTTP

HTTP è un tipico protocollo client-server. Il client invia una HTTP Request e il server restituisce una HTTP Response .

HTTP è generalmente in ascolto sulla porta 80

, e utilizza TCP per assicurare la correttezza della trasmissione.

HTTP è un protocollo testuale, che utilizza solo caratteri ASCII (tranne che per il corpo che può contenere dati binari). I client normalmente sono i Web browser

, che

visualizzano le pagine web (spesso HTML) presenti sui server.

Se la pagina contiene riferimenti ad altri oggetti (immagini, script, etc) questi vengono richiesti sempre tramite HTTP, in parallelo o sequenzialmente.

Versioni di HTTP

HTTP 1.0 chiude la connessione dopo il trasferimento di un singolo oggetto.

HTTP 1.1 utilizza connessioni permanenti (keep-alive ) che migliorano le prestazioni perché non serve un handshake a tre vie per ogni oggetto.

Esiste anche lo standard HTTP 2.0, compatibile con i precedenti, che migliora le prestazioni generali.

HTTP Request

Il formato di una richiesta HTTP è il seguente.

Alla fine delle opzioni deve esserci una linea vuota, anche se non ci sono opzioni o non c'è corpo.

I fine linea devono contenere il doppio byte ( ).

CR LF \r\n

[METODO] [URL] [VERSIONE]

[HEADER_1]: [VALORE_1]

[HEADER_2]: [VALORE_2]

...

[HEADER_N]: [VALORE_N]

[CORPO REQUEST]

METODO : i metodi più utilizzati sono GET e POST

, ma ne esistono altri

Uniform Resource Locator,

URL : stringa che identifica in modo univoco una data risorsa

VERSIONE : o

HTTP/1.0 HTTP/1.1

HEADER

: un'intestazione valida per le request (come o ), seguita dal suo valore

Host User-Agent

Metodi HTTP

I possibili metodi da utilizzare nelle request sono i seguenti:

M S

ETODO COPO

GET Ottenere una pagina web

HEAD Ottenere gli header di una pagina web

PUT Memorizzare una pagina web

POST Inviare dati al server (come il contenuto di un form)

DELETE Eliminare una pagina web

TRACE Ottenere indietro la request ricevuta dal server

CONNECT Riservato per usi futuri

OPTIONS Legge il valore di alcune opzioni

HTTP Response

Il formato di una richiesta HTTP è il seguente.

Alla fine delle opzioni deve esserci una linea vuota, anche se non ci sono opzioni o non c'è corpo.

I fine linea devono contenere il doppio byte ( ).

CR LF \r\n

[VERSIONE] [STATO] [FRASE]

[HEADER_1]: [VALORE_1]

[HEADER_2]: [VALORE_2]

...

[HEADER_N]: [VALORE_N]

[CORPO RESPONSE]

VERSIONE : o

HTTP/1.0 HTTP/1.1

STATO : un codice di stato HTTP (numerico)

FRASE : un breve testo che descrive il codice di stato

HEADER

: un'intestazione valida per le response (come ), seguita dal suo valore

Content-Length

Codici di stato

I possibili codici di stato sono di tipo diverso in base alla prima cifra:

1

: Informazioni ( )

100 Continue

2

: Successo ( , )

200 OK 204 No Content

3

: Reindirizzamento ( )

305 Use Proxy

4

: Errore client ( , , )

400 Bad Request 403 Forbidden 404 Not Found

5

: Errore server ( , )

500 Internal Server Error 505 HTTP Version not supported

HTML dinamico

Molti web server creano la pagina web al momento della richiesta, utilizzando appositi sistemi (PHP, ASP, …).

statica, dinamica.

In questo modo, pur essendo la response di per sé la pagina web è generata ad ogni request ed è quindi

Il protocollo FTP

FTP è un protocollo client-server che usa TCP per lo scambio affidabile di file tra host. Generalmente il server FTP è in ascolto sulla porta 21

.

I due canali FTP

FTP utilizza due connessioni separate per gestire comandi e dati.

Un server FTP generalmente rimane in ascolto sulla porta 21, a cui si connette il client.

La connessione comporta l'inizializzazione del canale comandi

, attraverso il quale client e server si scambiano comandi e risposte.

Lo scambio effettivo di dati (come per esempio un file) richiede l'apertura del canale dati

, che può essere di due tipi:

attivo : il client apre una porta solitamente casuale, tramite il canale comandi rende noto il numero di tale porta al server. Il server connette la propria porta 20 alla

porta del client

passivo : il server apre una porta solitamente casuale (superiore alla 1023), tramite il canale comandi rende noto il numero di tale porta al client e attende che si

connetta

Sia il canale comandi, sia il canale dati sono delle connessioni TCP.

FTP crea un nuovo canale dati per ogni file trasferito, mentre il canale comandi rimane aperto per l'intera durata della sessione utente.

In altre parole il canale comandi è persistente mentre il canale dati è non persistente .

Funzioni di FTP

Un server FTP offre funzioni per interagire con il suo filesystem, tra cui:

download/upload di file

resume di trasferimenti interrotti

rimozione e rinomina di file

creazione di directory

navigazione tra directory

Autenticazione

FTP fornisce inoltre un sistema di autenticazione in chiaro (non criptato).

Il client che si connette potrebbe dover fornire delle credenziali a seconda delle quali gli saranno assegnati determinati privilegi per poter operare sul filesystem.

L'autenticazione cosiddetta anonima prevede che il client non specifichi nessuna password di accesso e che lo stesso abbia privilegi che sono generalmente di sola lettura.

Differenze con HTTP

Le principali differenze tra FTP e HTTP sono le seguenti:

M FTP HTTP

ETRICA

Connessioni TCP Due connessioni (controllo e dati) Headers e dati nella stessa connessione

Dati trasferiti File (salvati in locale) Pagine web (soltanto visualizzate)

Dati aggiuntivi Solo controllo (poco overhead) Controllo e metadati (molto overhead per file piccoli)

Protocolli di posta

La posta elettronica viene implementata in Internet attraverso la cooperazione dei seguenti sottosistemi:

(MUA):

Mail User Agent client (applicazione di posta), usa SMTP in invio e POP/IMAP in ricezione

(MTA):

Mail Transport Agent server (interfaccia con la r