1

Alma Mater Studiorum - Universita' di BolognaSede di Cesena

II Facolta' di Ingegneria

Reti di Calcolatori

Esercitazione 6

httpSockets

Copyright © 2009-2011 by Claudio Salati.

2

Internet vs. WWW .1

• Confusione tra Internet e WWW:

• Il WWW, in quanto accesso a pagine multimediali, e’ l’applicazione piu’ diffusa di Internet.

• L’architettura WWW distingue nettamente gli ES tra client e server.

Anche se un server puo’ anche assumere il ruolo di client.

• La rete non e’ piatta, ma e’ organizzata come un insieme di intranet connesse da un backbone.

All’interno di ogni intranet si utilizzano solo indirizzi IP privati.

Solo i nodi che interagiscono direttamente con l’esterno come server, proxy, router, … hanno un indirizzo IP pubblico.

• Per ragioni di sicurezza l’accesso a Internet da molte intranet aziendali e’ consentito in uscita solo in direzione di porte HTTP/HTTPS e in entrata solo verso ES esplicitamente autorizzati.

(Anche le interazioni SMTP sono consentite solo da/verso un server ben definito)

3

Internet vs. WWW: modello della rete

sottoretesottorete

Sottorete

sottorete

Sottoreteclient server

IS

client

IS

IS

sottorete

IS

intranet

intranet

backbone

server

4

Internet vs. WWW .2

• Quando un client HTTP (che e’ dotato solo di indirizzo IP privato) apre una connessione con un server il suo indirizzo privato viene mappato dal NAT.

• Ma anche l’utilizzo di NAT contribuisce a rendere difficile l’utilizzo delle tradizionali applicazioni di rete basate su TCP/UDP.

(in gergo WWW: applicazioni di tipo peer-to-peer, cioe’ tra due macchine che normalmente operano come client HTTP)

Una macchina client HTTP, dotata solo di indirizzo IP privato, non e’ indirizzabile come server dall’esterno dell’intranet.

• Tutte le altre applicazioni convenzionali diverse dal Web, basate sull’utilizzo del servizio di Trasporto TCP/UDP tra intranet diverse, sono praticamente inutilizzabili.

• Ma HTTP stesso e’ utilizzato/abile come un servizio di trasporto.

• Possiamo incanalare le connessioni TCP sull’infrastruttura di trasporto WWW-HTTP.

5

Tunnel HTTP

• Il tunnel, come illustrato nella figura, puo’ supportare qualunque applicazione tradizionale basata su comunicazioni attraverso un’unica connessione TCP, e.g. VNC.

• Per semplicita’ assumiamo di avere a che fare con un servizio end-to-end sequenziale.

• Il servizio e’ accessibile, anziche’ su una porta TCP well known su una “sessione well known” sul web server: l’end point del tunnel HTTP su web server lato server.

ApplicazioneCliet TCP

ApplicazioneServer TCP

TunnelTCP/HTTP

Stub

TunnelTCP/HTTP

Proxy

Web serverWeb Application

Relay

Connessione TCP Connessione TCP

TCP su HTTP

TCP su HTTP

Sessione well

known

6

Tunnel HTTP: architettura .1

• Il tunnel e’ realizzato come una applicazione web divisa in 3 parti:

• Il tunnel proxy.

• Il tunnel stub.

• Il tunnel switch.

• Il tunnel proxy:

• E’ allocato sulla stessa macchina del server applicativo.

• E’ un client web.

• Esporta sul server web il punto d’accesso al servizio del server applicativo.

• Il tunnel stub:

• E’ allocato sulla stessa macchina del client applicativo.

• E’ un client web.

• Consente al client applicativo di connettersi al punto d’accesso al servizio del server applicativo sul web server.

7

Tunnel HTTP: architettura .2

• Il tunnel switch:

• E’ allocato sul web server.

• E’ un server web, composto ad esempio da un insieme di (anche una sola) servlet.

• Implementa il punto d’accesso web al servizio del server applicativo.

• Consente al client applicativo di connettersi a questo servizio.

• Una volta instaurata la sessione tra client e server applicativi effettua lo scambio dati (switch dati) tra le due parti del tunnel web, quella verso client applicativo e quella verso server applicativo.

• Come fanno tunnel stub e tunnel proxy a conoscere l’URL del tunnel switch?

8

Il tunnel proxy

1. Richiede l’apertura di una sessione well known (con quale identificatore?) sul tunnel switch.

2. Si mette in attesa della connessione di sessione da parte di un tunnel stub.

3. Quando riceve dal tunnel switch l’informazione che un tunnel stub si e’ connesso alla sessione, apre la connessione TCP con il server applicativo.

4. Se vede chiudere/cadere la connessione TCP con il server applicativo chiude la sessione corrente sul tunnel switch e ritorna in attesa di una nuova connessione alla sessione sullo switch (passo 2).

5. Se riceve dal tunnel switch l’informazione di chiusura/abort della sessione corrente chiude la connessione TCP con il server applicativo e ritorna in attesa di una nuova connessione alla sessione well known sullo switch (passo 2).

6. Durante lo stato di connessione della sessione esegue lo switch dei dati tra la connessione TCP verso il server applicativo e il tunnel HTTP verso il tunnel switch.

9

Il tunnel stub

1. Attende la indicazione di connessione TCP da parte del client applicativo (almeno in linea di principio: perche’ questo caveat?).

2. Quando il client applicativo effettua la connessione TCP chiede al tunnel switch sul web server di essere connesso alla sessione well known di interesse(come fa a sapere quale e’?).

3. Se vede chiudere/cadere la connessione TCP con il client applicativo chiude la sessione corrente sul tunnel switch e termina.

4. Se riceve dal tunnel switch l’informazione di rifiuto/chiusura/abort della sessione corrente chiude la connessione TCP con il client applicativo e termina.

5. Durante lo stato di connessione della sessione esegue lo switch dei dati tra la connessione TCP verso il client applicativo e il tunnel HTTP verso il tunnel switch.

10

Il tunnel switch sul web server

1. Rimane in attesa di tunnel proxy che chiedano la apertura di una sessione well known o di tunnel stub che chiedano la connessione ad una sessione well known .

2. Quando riceve da un tunnel proxy una richiesta di apertura di una sessione well known la registra.

3. Quando riceve da un tunnel stub una richiesta di connessione ad una sessione well known registrata, verifica se questa e’ gia’ in stato di connessione:

• Se si’ rifiuta la richiesta.

• Se no effettua la connessione e ne informa tunnel stub e tunnel proxy.

4. Quando riceve dal tunnel proxy o dal tunnel stub il comando di disconnessione della sessione corrente, effettua la chiusura e ne informa l’altra parte.

5. Una volta instaurata la sessione tra client e server applicativi effettua lo scambio dati (switch dati) tra le due parti del tunnel web, quella verso tunnel stub e quella verso tunnel proxy.

11

Il protocollo di tunnel HTTP

• Il protocollo puo’ basarsi sull’utilizzo dell’operazione POST di HTTP.

• Nel corpo del PDU di richiesta HTTP viene indicata l’operazione di tunnel che il client HTTP (il proxy o lo stub) richiede al server HTTP (lo switch), piu’ i parametri di questa operazione. Ad esempio:

• OpenSession(nome della sessione)

• ConnectSession(nome della sessione)

• AcceptConnection(nome della sessione)

• DisconnectSession(nome della sessione)

• PutData(nome della sessione, stubXORproxy, dati)

• GetData(nome della sessione, stubXORproxy)

• Anche i parametri di ritorno sono contenuti nel corpo del PDU di risposta HTTP. Ad esempio, supponendo che non ci sia stato nessun errore di protocollo HTTP, l’operazione GetData potra’ avere come risposta:

• DataAvailable(dati)

• DisconnectionEvent(ragione)

• NoDataAvailable()

12

Problemi di Presentazione

• Richieste e risposte possono essere codificate come un normale testo o come un testo XML (e.g. un valore secondo una sintassi descritta da uno schema XML).

• In realta’ per scambiare informazioni con un web server e’ di norma comunque necessario:

• Codificare i byte binari come Base64 per poter operare solo a caratteri.

• URLencodificarla (nella direzione client server).

(altrimenti la piattafoprma server considera certi caratteri, come lo spazio, come caratteri speciali e li tratta come tali)

13

Transport Mapping .1

• Ma di quante connessioni TCP-HTTP c’e’ bisogno tra ciascun client HTTP e il server HTTP per supportare il tunnel?E che vincoli di utilizzo hanno?

• HTTP e’ un protocollo request-reply, ma il tunnel switch ha bisogno di poter inviare spontaneamente dati e eventi di dis/connessione a ciascuno dei client durante la vita del tunnel.

• Le operazioni HTTP non possono durare un tempo infinito: un client HTTP, se non vede arrivare in un tempo ragionevole la reply alla sua request, considera abortita l’operazione (non si aspetta di ricevere piu’ nessuna risposta).

Questo significa in particolare che l’operazione di tunnel GetData deve terminare anche se non ci sono ne’ dati ne’ altri eventi che lo switch debba comunicare al client.

• Ciascun client deve comunque inviare periodicamente delle request HTTP verso il web server, anche se non ha in realta’ niente da comunicare, altrimenti il web server chiuderebbe la connessione TCP di colloquio con il client.

14

Transport Mapping .2• Questi problemi possono essere risolti se ciascun client web utilizza 2

connessioni TCP-HTTP per comunicare con il server web.

• Sulla prima connessione il client invia dati (quando la sessione e’ in stato connesso) e comandi che possono avere risposta immediata (ad esempio ConnectSession e DisconnectSession). Su questa connessione il client deve comunque inviare

periodicamente delle richieste, eventualmente nulle, per evitare che il web server chiuda la connessione stessa.

• La seconda connessione consente ai client di ricevere dal web server dati ed eventi di variazione di stato della sessione (tramite le operazioni AcceptConnection e GetData). Queste operazioni non e’ detto che abbiano una risposta

immediata. Ad un certo punto il web server deve comunque inviare una

risposta, ma questa deve poter avere anche valore NoEvent . A fronte di una risposta di questo genere il web client tornera’

immediatamente ad inviare la stessa richiesta (una operativita’ a polling!) in modo che appena il web server si trovi nella situazione di poter inviare una risposta significativa lo possa fare (senza ritardi).

15

Problemi della soluzione tunnel: tecnici

• Un tunnel ha un comportamento specializzato:

• Tutte le applicazioni distribuite sono basate sull’uso di una sola connessione? No!

Quante connessioni TCP deve tunnelare?

• Ci sono servizi offerti su porte effimere, come quelli basati su RPC Sun.

• Sulle connessioni TCP l’algoritmo di Nagle deve essere attivo o no?

• E se vogliamo tunnelare un servizio concorrente?

• E se il servizio fa uso di connessioni secondarie basate su porte effimere (il cui numero deve essere acquisito tramite getsockname() e comunicato al pari perche’ ci si possa connetere), come fa FTP?

Come posso comunicare al mio pari il numero di porta effimera se questo puo’ essere modificato da NAT?

Si e’ dovuto modificare FTP per aggirare il problema!

16

Problemi della soluzione tunnel: gestionali

• Un tunnel ha bisogno di un web server che operi come relay: se il tunnel e’ specializzato l’applicazione web che opera come relay deve essere specializzata.

• Il servizio di tunneling non e’ reso disponibile per se’, ma solo come parte di una applicazione web distribuita, e.g. TeamViewer.

• Non esistono tunnel neutri, che si limitano a fornire un servizio di trasporto dati full-duplex, bidirezionale come una overlay network su HTTP.

E ci sarebbero significativi problemi tecnici nel realizzarli.

17

WebSockets di Google

• http://en.wikipedia.org/wiki/WebSockets

• WebSocket is a technology providing for bi-directional, full-duplex communications channels, over a single Transmission Control Protocol (TCP) socket.

• It is designed to be implemented in web browsers and web servers but it can be used by any client or server application.

• The handshake looks like HTTP but actually isn't. It allows the server to interpret part of the handshake request as HTTP and then switch to WebSocket.

• Once established, WebSocket data frames can be sent back and forth between the client and the server in full-duplex mode.

• Text frames can be sent full-duplex, in either direction at the same time. The data is minimally framed with 2 bytes: a frame starts with a 0x00 byte, ends with a 0xFF byte, and contains UTF-8 data in between.

• Binary frames are not supported yet in the API.

18

Cosa vorremmo• Una internet piatta, senza problemi di firewall e di NAT.

• Per poter scambiare dati, anche binari, tra due ES qualunque, non solo tra un browser e un web server.

• Senza bisogno di tunnel specializzati.

• Dove potessero essere utilizzate, come nel dominio internet, anche porte effimere.

• Che consentisse di riutilizzare facilmente tutte le applicazioni sviluppate su TCP e UDP senza doverle modificare.

ES

ESES

ES

ES

19

httpSocket

• Un dominio di comunicazione diverso da quello internet:

– SocketDomainT.WEB vs. SocketDomainT.INET

– Un insieme di servizi di trasporto in questo dominio.

• Un’API che consente di utilizzare i socket sia per interfacciare il dominio di comunicazione internet che quello WEB.

• Socket estesi (generici) per poter rappresentare TSAP di diversi domini di comunicazione.

• E’ mantenuta la completa compatibilita’ di interfaccia nell’uso dei socket INET.

• Si opera sui socket WEB nella stessa maniera con cui si opera sui socket INET.

• Sono introdotte nuove classi per la gestione degli indirizzi nel nuovo dominio di comunicazione.

• Sono introdotti nuovi metodi che consentono di creare dei socket nel dominio WEB.

20

httpSocket: communication domain• Il dominio di comunicazione e’ implementato da un insieme di web server che

funzionano da relay e sui quali e’ attiva l’applicazione web httpSocket.

• Due possibilita’ di comunicazione:

• Locale

• Globale

21

httpSocket: communication domain• Il protocollo sulla sezione di accesso consente ad una applicazione

allocata su un web client di operare su un TSAP allocato su un web server.

• L’applicazione client interfaccia il TSAP sul web server tramite un socket.

• socket stub, sul client

• socket proxy, sul webserver, e’ l’implementazione del TSAP

22

httpSocket: genericita’ .1

public enum SocketDomainT {

INET,

WEB

}

public class Socket implements ProtocolInterface {

// socket generico

private java.net.Socket s;

// usato come tale solo per i socket di tipo INET.

// usato solo per denominazione univoca per socket

// di tipo WEB

private SocketDomainT socketType;

. . .

}

23

httpSocket: genericita’ .2

public Socket(SocketDomainT pf) {

socketType=pf;

if (pf==SocketDomainT.INET) {

socketType = SocketDomainT.INET;

s = new java.net.Socket();

} else {

// un socket WEB e’ implementato

// direttamente (cialtroneria)

socketType = SocketDomainT.WEB;

socketState = SocketStateT.LOCAL_CREATED;

s = null;

}

}

24

httpSocket: bacward compatibility

• Se un socket e’ del dominio INET viene mappato su un socket standard di Java (che puo’ appartenere solo al dominio internet), e le operazioni sul socket generico si ribaltano nelle corrispondenti operazioni sul socket Java.

• I costruttori che non specificano in qualche modo il dominio del socket costruiscono un socket INET.

public Socket() {

socketType=SocketDomainT.INET;

s = new java.net.Socket();

}

public void bind(java.net.SocketAddress bindpoint)

throws IOException {

try {

if (socketType==SocketDomainT.INET &&

bindpoint.getClass()

.getName().equals("java.net.InetSocketAddress")) {

s.bind(bindpoint);

} else if (socketType==SocketDomainT.WEB && ...

25

httpSocket: implementazione• Il package genericsocketstub sostituisce nei programmi dell’utente il

package java.net.

• La classe HttpSocketAddress deriva (come la classe standard InetSocketAddress) dalla classe standard SocketAddress.

La classe HttpSocketAddress e’ definita nel package genericsocketutility e quindi il programma utente deve importare anche questo package.

• Prima di iniziare l’interazione con una web application httpSocket un programma client deve invocare il metodo (statico) WSStartup() della classe Socket.

String WSStartup(String serverUrl, boolean getHost)

• serverUrl e’ l’URL della web application con cui si vuole interagire .

• getHost indica alla web application se deve (true) o no (false) ritornare al cliente un identificatore univoco di sessione.

• L’identificatore univoco potra’ poi essere utilizzato per costruire l’indirizzo dei socket WEB creati da questa applicazione client su questo web server(vedi parametro hostname di un indirizzo di TSAP WEB).

26

httpSocket: indirizzo di un TSAP WEB

L’indirizzo di un TSAP WEB e’ composto di 3 coordinate:

• String serverUrl;

serverUrl identifica l’URL della web application httpSocket su cui e’ stato creato il socket di cui si sta dando l’indirizzo, ad es.:

http://httpsocket.smart.it/HttpSocketProxy/httpSocketServletProxy

• String hostname;

hostname e’ un identificatore univoco della macchina client (e.g. il suo nome dns) o comunque un identificatore univoco all’interno della web application httpSockets di indirizzo serverUrl, ad es.:

Puo’ essere generato dinamicamente o assere assegnato dal gestore del web server.

• int port;

port e’ il numero di porta, univoco rispetto a hostname, del socket che si vuole indirizzare.

27

httpSocket: lato web server• public class httpSocketServletProxy

extends HttpServlet

e’ la classe che implementa la servlet che e’ l’applicazione web httpSocket.

• A parte i metodi init() e destroy() definisce soltanto l’operazione doPost().

public void doPost(HttpServletRequest request,

HttpServletResponse response)

• request e’ il corpo del PDU HTTP POST che attiva il metodo.

• response e’ il corpo del PDU HTTP di risposta che verra’ inviato al client.

• Per come e’ definita la servlet, l’unico PDU HTTP utilizzato nell’interazione web client-server httpSocket e’ POST.

• Il PDU HTTP POST e’ utilizzato per trasportare i PDU del protocollo httpSockets.

• La servlet e’ installata all’URL:

http://httpsocket.smart.it/HttpSocketProxy/httpSocketServletProxy

28

httpSocket: ASE HTTP di Java

• Lato server l’ASE HTTP (lato server) e’ parte del framework del web server (e.g. Tomcat, GlassFish, ...).

• Lato client l’ASE httpSocket non e’ implementato utilizzando direttamente l’API di trasporto.

• Lato client l’ASE httpSocket e’ implementato utilizzando un insieme di classi standard dell’ambiente Java che implementano l’ASE HTTP lato client.

• Classe URL, che rappresenta un indirizzo di un servizio/risorsa web.

• Classe HttpURLConnection, che

• Rappresenta una connessione con un servizio/risorsa web specifico (con indirizzo l’URL tramite cui e’ stato creato l’oggetto HttpURLConnection).

• Consente la preparazione del PDU HTTP da spedire.

• Classe OutputStream e InputStream della connessione HTTP, per inviare e ricevere PDU su di essa.

29

Classe HttpURLConnection

• Each HttpURLConnection instance is used to make a single request but the underlying network connection to the HTTP server may be transparently shared by other instances.

• Calling the close() methods on the InputStream or OutputStream of an HttpURLConnection after a request may free network resources associated with this instance but has no effect on any shared persistent connection.

• Calling the disconnect() method may close the underlying socket if a persistent connection is otherwise idle at that time.

30

httpSocket: ASE HTTP client di Java, TX

public static HttpURLConnection sendHTTPPostRequest(byte [] msg, URL url)

throws Exception {

// apre una connessione con il web server di indirizzo url

HttpURLConnection httpUc = (HttpURLConnection)url.openConnection();

// crea un PDU di POST

httpUc.setRequestMethod("POST");

// setta i field dell'header

httpUc.setRequestProperty("Content-Length", Integer.toString(urlEnc.length));

httpUc.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");

httpUc.setRequestProperty("Host", url.getHost());

httpUc.setRequestProperty("Connection", "Keep-Alive");

httpUc.setDoInput(true);

httpUc.setDoOutput(true);

// encodifica il corpo del PDU msg in BASE-64 + URL-encode

byte [] urlEnc = URLEncoder.encode(Base64.encodeBytes(msg), "UTF-8").getBytes();

// si garantisce che la connessione con il web server sia effettivamente aperta

httpUc.connect();

// acquisisce l’output stream di questa connessione

OutputStream os = httpUc.getOutputStream();

// spedisce il PDU HTTP preparato, con corpo di PDU = urlEnc

os.write(urlEnc);

os.flush();

os.close();

// ritorna l’oggetto connessione per poter poi acquisire la risposta

return httpUc;

}

31

httpSocket: ASE HTTP client di Java, RX

public static byte [] receiveHTTPPostResponse(HttpURLConnection httpUc) throws Exception {

// procedura bloccante: aspetta la risposta del web server

int code = httpUc.getResponseCode();

InputStream is = null;

if (code>=200 && code<=299) {

//range codice di risposta OK

is = httpUc.getInputStream();

int len = httpUc.getContentLength(), nb=0;

int offset = 0;

byte [] res = new byte[len];

while(true) {

nb=is.read(res, offset, len);

if (nb==-1) throw new IOException(“ricezione fallita dal web server”);

len -= nb;

offset += nb;

}

// res = Base64.decode(URLDecoder.decode(new String(res, 0, res.length), "UTF-8"));

res = Base64.decode(res);

is.close();

return res;

} else { // il server ha restituito un PDU di errore

String errorMsg = "HTTP Response Error: " + code + httpUc.getResponseMessage();

System.out.println(errorMsg);

throw new Exception(errorMsg);

}

}

internet intranetintranet

32

httpSocket: security

• Rendere accessibili servizi sulla rete tramite httpSockets non significa rinunciare alla sicurezza di rete, ma basarsi su strumenti piu’ flessibili.

• Consideriamo l’architettura globale e che i web server siano allocati sulla frontiera tra intranet e internet.

• Il metodo WSStartup() puo’ fornire al web server le credenziali che dimostrano i diritti d’accesso dell’utente (uscire come client, e di chi, offrire servizi, …).

33

Esempio di come e' evoluto il WWW

• httpSockets e’ una infrastruttura client-server

• distribuita su Internet

• in cui un sistema di trasporto e i suoi TSAP, residenti sui server e controllabili tramite applicazioni web residenti sui server,

• possono essere riferiti (e indirizzati) e possono riferirirsi tra loro

• tramite URL (e.g. http://httpsocket.smart.it/HttpSocketProxy/httpSocketServletProxy)

• e possono accedersi tra loro e essere acceduti da applicazioni residenti sui client

• tramite le operazioni messe a disposizione dalla interfaccia httpSockets

• l'interfaccia puo' essere definita come una API Java o C

• e utilizza HTTP solo come protocollo di trasporto