1 Alma Mater Studiorum - Universita' di Bologna Sede di Cesena II Facolta' di Ingegneria Reti di Calcolatori Esercitazione 6 httpSockets Copyright © 2009-2011.

Presentazione sul tema: "1 Alma Mater Studiorum - Universita' di Bologna Sede di Cesena II Facolta' di Ingegneria Reti di Calcolatori Esercitazione 6 httpSockets Copyright © 2009-2011."— Transcript della presentazione:

1 1 Alma Mater Studiorum - Universita' di Bologna Sede di Cesena II Facolta' di Ingegneria Reti di Calcolatori Esercitazione 6 httpSockets Copyright © 2009-2011 by Claudio Salati.

2 2 Internet vs. WWW.1 Confusione tra Internet e WWW: Il WWW, in quanto accesso a pagine multimediali, e lapplicazione piu diffusa di Internet. Larchitettura 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. Allinterno di ogni intranet si utilizzano solo indirizzi IP privati. Solo i nodi che interagiscono direttamente con lesterno come server, proxy, router, … hanno un indirizzo IP pubblico. Per ragioni di sicurezza laccesso 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 3 Internet vs. WWW: modello della rete sottorete Sottorete sottorete Sottorete client server IS client IS sottorete IS intranet backbone server

4 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 lutilizzo di NAT contribuisce a rendere difficile lutilizzo 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 dallesterno dellintranet. Tutte le altre applicazioni convenzionali diverse dal Web, basate sullutilizzo 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 sullinfrastruttura di trasporto WWW-HTTP.

5 5 Tunnel HTTP Il tunnel, come illustrato nella figura, puo supportare qualunque applicazione tradizionale basata su comunicazioni attraverso ununica 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: lend point del tunnel HTTP su web server lato server. Applicazione Cliet TCP Applicazione Server TCP Tunnel TCP/HTTP Stub Tunnel TCP/HTTP Proxy Web server Web Application Relay Connessione TCP TCP su HTTP Sessione well known

6 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 daccesso 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 daccesso al servizio del server applicativo sul web server.

7 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 daccesso 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 lURL del tunnel switch?

8 8 Il tunnel proxy 1.Richiede lapertura 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 linformazione 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 linformazione 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 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 linformazione 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 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 laltra 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 11 Il protocollo di tunnel HTTP Il protocollo puo basarsi sullutilizzo delloperazione POST di HTTP. Nel corpo del PDU di richiesta HTTP viene indicata loperazione 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, loperazione GetData potra avere come risposta: DataAvailable(dati) DisconnectionEvent(ragione) NoDataAvailable()

12 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 13 Transport Mapping.1 Ma di quante connessioni TCP-HTTP ce 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 loperazione (non si aspetta di ricevere piu nessuna risposta). Questo significa in particolare che loperazione 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 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 15 Problemi della soluzione tunnel: tecnici Un tunnel ha un comportamento specializzato: Tutte le applicazioni distribuite sono basate sulluso 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 lalgoritmo 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 16 Problemi della soluzione tunnel: gestionali Un tunnel ha bisogno di un web server che operi come relay: se il tunnel e specializzato lapplicazione 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 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 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

19 19 httpSocket Un dominio di comunicazione diverso da quello internet: – SocketDomainT.WEB vs. SocketDomainT.INET – Un insieme di servizi di trasporto in questo dominio. UnAPI 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 nelluso 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 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 lapplicazione web httpSocket. Due possibilita di comunicazione: Locale Globale

21 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. Lapplicazione client interfaccia il TSAP sul web server tramite un socket. socket stub, sul client socket proxy, sul webserver, e limplementazione del TSAP

22 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 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 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 25 httpSocket: implementazione Il package genericsocketstub sostituisce nei programmi dellutente 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 linterazione 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 lURL 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. Lidentificatore univoco potra poi essere utilizzato per costruire lindirizzo dei socket WEB creati da questa applicazione client su questo web server (vedi parametro hostname di un indirizzo di TSAP WEB ).

26 26 httpSocket: indirizzo di un TSAP WEB Lindirizzo di un TSAP WEB e composto di 3 coordinate: String serverUrl; serverUrl identifica lURL della web application httpSocket su cui e stato creato il socket di cui si sta dando lindirizzo, 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 allinterno 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 27 httpSocket: lato web server public class httpSocketServletProxy extends HttpServlet e la classe che implementa la servlet che e lapplicazione web httpSocket. A parte i metodi init() e destroy() definisce soltanto loperazione 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, lunico PDU HTTP utilizzato nellinterazione web client-server httpSocket e POST. Il PDU HTTP POST e utilizzato per trasportare i PDU del protocollo httpSockets. La servlet e installata allURL: http://httpsocket.smart.it/HttpSocketProxy/httpSocketServletProxy

28 28 httpSocket: ASE HTTP di Java Lato server lASE HTTP (lato server) e parte del framework del web server (e.g. Tomcat, GlassFish,...). Lato client lASE httpSocket non e implementato utilizzando direttamente lAPI di trasporto. Lato client lASE httpSocket e implementato utilizzando un insieme di classi standard dellambiente Java che implementano lASE 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 loggetto 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 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 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 loutput 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 loggetto connessione per poter poi acquisire la risposta return httpUc; }

31 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); }

32 internetintranet 32 httpSocket: security Rendere accessibili servizi sulla rete tramite httpSockets non significa rinunciare alla sicurezza di rete, ma basarsi su strumenti piu flessibili. Consideriamo larchitettura 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 daccesso dellutente (uscire come client, e di chi, offrire servizi, …).

33 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