|
Wiki
UniCrema
Materie per semestre
Materie per anno
Materie per laurea
Help
|
|
Uni.Ceravolo History
Hide minor edits - Show changes to output
Changed line 544 from:
[[Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani->Sistemi]] to:
[[Torna alla pagina di Sistemi per l'elaborazione delle informazioni->Sistemi]]
Changed line 3 from:
[[Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani->Sistemi]] to:
[[Torna alla pagina di Sistemi per l'elaborazione delle informazioni->Sistemi]]
Changed line 31 from:
to:
** [[#s102|MIME (RFC 822)]]
Changed lines 473-475 from:
Per capire meglio l'architettura vedi slide 86
[[#s134]] to:
Per capire meglio l'architettura vedi slide 86
[[#s133]]
Added lines 417-419:
[[#su|[-'''Torna su'''-]]]
Added lines 492-494:
[[#su|[-'''Torna su'''-]]]
Added lines 527-528:
[[#su|[-'''Torna su'''-]]] Added lines 535-536:
[[#su|[-'''Torna su'''-]]]
Added lines 34-45:
# [[#s12|Content distribution]]
** [[#s121|Web caching]]
** [[#s122|Content distribution networks]]
# [[#s13|P2P]]
** [[#s131|P2P centralizzato - Eg. Napster]]
** [[#s132|P2P distribuito - Eg. Gnutella]]
** [[#s133|P2P ibrido - Eg. Kazaa]]
# [[#s14|Scalability]]
# [[#s15|Socket programming]]
** [[#s151|Socket programming with TCP]]
** [[#s152|Socket programming with UDP]]
# [[#s16|Costruire un semplice Web server]] Changed lines 417-418 from:
to:
[[#s12]]
!!!Content distribution Changed lines 420-426 from:
*Propagazione: tempo e velocità di propagazione dei byte
*trasmissione legata alla banda (dtrans = Lunghezza/ Rate{portata})
*coda dei pacchetti che dipende dalla prestazioni del router e dei protocolli di trasporto
*processo: legato all’header del pacchetto e all’instradamento dei router
Le strategie per ridurre il ritardo sono chiamate di Content Distribution. Tutte agiscono sul tempo di trasmissione aumentando e diminuendo l’uso della banda.
Esse sono: to:
*''Propagazione'': tempo e velocità di propagazione dei byte
*''trasmissione'' legata alla banda (dtrans = Lunghezza/ Rate{portata})
*''coda dei pacchetti'' che dipende dalla prestazioni del router e dei protocolli di trasporto
*''tempo di processo'' legato all’header del pacchetto e all’instradamento dei router
Le strategie per ridurre il ritardo sono chiamate di ''Content Distribution''. Tutte agiscono sul tempo di trasmissione aumentando e diminuendo l’uso della banda. Esse sono: Changed lines 431-432 from:
to:
Changed lines 439-440 from:
!!!!CONTENT DISTRIBUTION NETWORKS to:
[[#s122]]
!!!!Content distribution networks Changed lines 444-447 from:
!!!!!P2P file sharing
Non si usa un’architettura client-server (richiesta a un fornitore di servizio) ma host che fungono sia da client che da server.
Distribuire i contenuti non significa però diminuirli.
Ci sono due tipi di file sharing:
to:
[[#su|[-'''Torna su'''-]]]
[[#s13]]
!!!P2P
Non si usa un’architettura client-server (richiesta a un fornitore di servizio) ma host che fungono sia da client che da server. Distribuire i contenuti non significa però diminuirli.
Ci sono tre tipi di file sharing: Changed lines 453-455 from:
#'''lookup''': per avere la risorsa x devo fornire uno o più host che mi dicono ciò che voglio.
Data transfert: dare risorsa ad altri (host to host) to:
#'''lookup''': per avere la risorsa x devo fornire uno o più host che mi dicono ciò che voglio
#'''data transfert''': permette a un host di prendere le risorse da altri (host to host) Changed lines 458-460 from:
''[+P2P centralized as Napster+]''
to:
[[#s131]]
!!!!P2P centralizzato - Eg. Napster Added line 461:
Changed lines 464-467 from:
*infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentralizzato
''[+P2P as Gnutella+]'' to:
*infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentralizzato
[[#s132]]
!!!!P2P distribuito - Eg. Gnutella Changed lines 472-475 from:
''[+Ibrido: KaZaA+]''
In quest'architettura c'è un super peer cioè un gruppo leader che funge da server, collegati ciascuno ad altrettanti host tutti attraverso il protocollo TCP.
to:
[[#s134]]
!!!!P2P ibrido - Eg. KaZaA
In quest'architettura c'è un ''super peer'' cioè un gruppo leader che funge da server, collegati ciascuno ad altrettanti host tutti attraverso il protocollo TCP. Added lines 480-482:
[[#su|[-'''Torna su'''-]]]
[[#s14]] Changed lines 484-485 from:
La scalabilità di un protocollo è relativa all'efficacia del servizio di lookup (cioè quello che manda i messaggi di richiesta dei dati)
to:
La scalabilità di un protocollo è relativa all'efficacia del servizio di lookup (cioè quello che manda i messaggi di richiesta dei dati). Added line 492:
Deleted line 493:
Changed lines 498-499 from:
!!!!!Socket programming with TCP to:
[[#s151]]
!!!!Socket programming with TCP Changed lines 520-521 from:
!!!!!Socket programming with UDP to:
[[#s152]]
!!!!Socket programming with UDP Deleted line 524:
Changed lines 527-529 from:
!!!Costruire un semplice Web server ''(nb. può servirci per costruire quello da fare per Sassi?)''
Esso to:
[[#s16]]
!!!Costruire un semplice Web server
''(nb. può servirci per costruire quello da fare per Sassi?)''\\
Un web server si occupa di richieste HTTP e di tutti gli annessi e i connessi, cioè: accettare le richieste, analizzare l'header, ottenere le richieste dal server file system, creare una risposta al messaggio HTTP (header lines + file), mandare la risposta al client.\\ Deleted lines 532-534:
Changed lines 192-193 from:
* '''request line''', così formata: ''metodo'' (vedi dopo), URI, versione del protocollo. Ad esempio: %green%GET/somedir/page.html HTTP/1.1%none% to:
* '''request line''', così formata: ''metodo'' (vedi dopo), URI, versione del protocollo.\\
Ad esempio: %green%GET/somedir/page.html HTTP/1.1%none% Changed lines 229-230 from:
* '''Status line''', nella quale compare un codice a tre cifre che definisce la categoria del messaggio. Per conoscere il significato dei vari codici si può fare richiesta con un telnet, oppure andare su [[questa pagina->CodiciDiStato]]. Ad esempio, una status line potrebbe essere: %green% "HTTP/1.1 200 OK <CR><LF>"%none%
* '''Header''': to:
* '''status line''', nella quale compare un codice a tre cifre che definisce la categoria del messaggio. Per conoscere il significato dei vari codici si può fare richiesta con un telnet, oppure andare su [[questa pagina->CodiciDiStato]]. Ad esempio, una status line potrebbe essere: %green% "HTTP/1.1 200 OK <CR><LF>"%none%
* '''header''': Changed lines 237-238 from:
* '''Body''', il contenuto della risposta. to:
* '''body''', il contenuto della risposta. Changed lines 287-288 from:
File Transfer Protocol. Attivo sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati.\\
Problemi: to:
File Transfer Protocol. Attivo sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati. Problemi: Changed lines 291-305 from:
E' persistente perciò la connessione viene tenuta aperta e si mantiene una sessione. Per autenticarsi occorre mandare username e password.
''FTP commands'':
*manda un testo ASCII
*chiede USER e PASS
*LIST ritorna una lista di file nella directory corrente
*RETR filename retrievers (gets) file
*STOR filename stores (puts) file onto remote host
''FTP codici''
*331 user ok, pass requied
*125 data connection already open, transfer starting
*425 can't open data connection
*452 error writing file to:
E' persistente perciò la connessione viene tenuta aperta e si mantiene una sessione. Meglio ancora: è la connessione per il controllo del trasferimento che rimane aperta per tutta la sessione, mentre quella del trasferimento vero e proprio si apre e si chiude per ogni file trasferito.\\
Per autenticarsi occorre mandare username e password.
I comandi FTP sono delle stringhe di caratteri ASCII, che richiedono l'inserimento di una USER e di una PASSword per ogni sessione. Alcuni comandi:
*'''LIST''', ritorna una lista di file nella directory corrente
*'''RETR''', filename retrievers (gets) file. Obbliga il server a spedire una copia del file all'utente/server dall'altra parte della connessione.
*'''STOR''', filename stores (puts) file onto remote host. Obbliga il server ad accettare i dati inviati tramite la connessione dati e salvarli.
Di seguito alcuni codici di ritorno dell'FTP:
*'''125''': data connection already open, transfer starting
*'''200''': command ok
*'''220''': service ready for new user
*'''231''': user logged out; service terminated
*'''331''': user ok, pass requied
*'''332''': need account for login
*'''425''': can't open data connection
*'''452''': error writing file
[[#su|[-'''Torna su'''-]]]
Changed line 335 from:
!!!!!Sample SMTP interaction
to:
!!!!Sample SMTP interaction Changed lines 338-345 from:
client: MAIL FROM <address@server.extension>\\
server: 250 server ok\\
client: RCPT TO <....@....>\\
server: recipient ok\\
client: DATA\\
server: 354 Enter mail\\
client: ...inizio email.... to:
[@client: MAIL FROM <address@server.extension> server: 250 server ok client: RCPT TO <....@....> server: recipient ok client: DATA server: 354 Enter mail client: ...inizio email.... @] Changed lines 347-350 from:
Alla fine si saluta scrivendo QUIT.
Riassumendo i comandi principali di un messaggio in SMTP sono: '''HELO, MAIL FROM, RCPT TO, DATA, QUIT''' to:
Alla fine si saluta scrivendo [@QUIT@].
Riassumendo i comandi principali di un messaggio in SMTP sono: '''HELO''', '''MAIL FROM''', '''RCPT TO''', '''DATA''', '''QUIT'''.
SMTP viene usato anche tra server e server per l'invio effettivo di mail. ''NON'' c'è bisogno di autenticazioni. Changed lines 354-365 from:
!!!!!RFL 822
E' lo standard per i messaggi di testo che sono composti da un header e da un body.\\
''Header'': to, from, subjet => comandi differenti da quelli di SMTP\\
''Body'': contiene il messaggio in codifica ASCII
Qualora volessi inviare altro oltre al testo dovrei servirmi dei tipi ''MIME''' che codificheranno il messaggio.
Content-transfer-encoding : base 64 => codifica in base 64\\
Content-type : image/jpg => questi sono definiti dalla versione del MIME (solitamente versione 1.0)
SMTP viene usato anche tra server e server per l'invio effettivo di mail. ''NON'' c'è bisogno di autenticazioni. to:
!!!!MIME (RFC 822)
Il MIME (Multipurpose Internet Mail Extensions) è uno standard che estende il formato delle e-mail, consentendo di inviare altri tipi di informazione oltre al testo ASCII, come ad esempio testi scritto in lingue diverse dall'Inglese, immagini, suoni e filmati, o anche programmi.
Gli ''headers'' aggiuntivi del MIME sono:
*'''MIME-Version''': se è presente nel messaggio significa che questo è formattato secondo lo standard MIME. Generalmente la versione è la 1.0
*'''Content-type''': il tipo dei dati multimediali contenuti nel messaggio, descritti come ''tipo/sottotipo''. Tra questi ricordiamo:
**testo semplice: ''text/plain'' (che è il valore di default dell'header content-type)
**testo html: ''text/html''
**immagine: eg, ''image/jpg''
**audio: eg, ''audio/mp3''
**video: eg, ''video/avi''
*'''Content-transfer-encoding''': metodo usato per decodificare i dati. Generalmente impostato come ''base 64'' Changed line 368 from:
to:
Added lines 374-376:
[[#su|[-'''Torna su'''-]]]
Changed lines 405-407 from:
to:
Changed lines 407-411 from:
Propagazione: tempo e velocità di propagazione dei byte
trasmissione legata alla banda (dtrans = Lunghezza/ Rate{portata})
coda dei pacchetti che dipende dalla prestazioni del router e dei protocolli di trasporto
processo: legato all’header del pacchetto e all’instradamento dei router to:
*Propagazione: tempo e velocità di propagazione dei byte
*trasmissione legata alla banda (dtrans = Lunghezza/ Rate{portata})
*coda dei pacchetti che dipende dalla prestazioni del router e dei protocolli di trasporto
*processo: legato all’header del pacchetto e all’instradamento dei router Changed lines 419-422 from:
to:
Changed lines 426-427 from:
!!!!!CONTENT DISTRIBUTION NETWORKS to:
!!!!CONTENT DISTRIBUTION NETWORKS Deleted line 430:
Changed lines 191-192 from:
* '''request line''', così formata: ''metodo'' (vedi dopo), URI, versione del protocollo. Ad esempio: %green%"GET/somedir/page.html HTTP/1.1"%none% to:
* '''request line''', così formata: ''metodo'' (vedi dopo), URI, versione del protocollo. Ad esempio: %green%GET/somedir/page.html HTTP/1.1%none% Changed line 203 from:
(:table border=0 width=80% cellpadding=5 cellspacing=0:) to:
(:table border=0 width=100% cellpadding=5 cellspacing=0:)
Added line 2:
Added line 16:
Changed lines 25-26 from:
** [[#s84|Implementare stati HTTP]]
** [[#s85|Proxy Server]] to:
** [[#s84|Esempio di HTTP Message]]
** [[#s85|Implementare stati HTTP]]
** [[#s86|Proxy Server]] Added lines 36-37:
Changed line 39 from:
to:
Added lines 42-44:
[[#su|[-'''Torna su'''-]]]
Changed line 46 from:
to:
Added lines 55-57:
[[#su|[-'''Torna su'''-]]]
Changed line 59 from:
!!!Comunicazioni fra processi
to:
!!Comunicazioni fra processi Added lines 64-92:
[[#s31]]
!!!!Porte note
Le '''porte note''' (''well known ports'', per dirlo alla francese) sono delle porte dai valori compresi tra lo 0 e il 1023, che lo '''IANA''' ('''''I'''nternet '''A'''ssigned '''N'''umbers '''A'''uthority'') ha associato a specifici servizi TCP e/o UDP. Tra le più importanti ricordiamo:
(:table width=50% border=0 cellpadding=5 cellspacing=0 align=left:)
(:cellnr bgcolor=#d9e4f2 align=center:) '''Porta'''
(:cell bgcolor=#d9e4f2 align=center:) '''Servizio'''
(:cellnr width=20%:) '''20''' /tcp
(:cell:) [[#s9|FTP]] (data)
(:cellnr bgcolor=#f5f9fc valign=middle:) '''21''' /tcp
(:cell bgcolor=#f5f9fc valign=middle:) FTP (controllo)
(:cellnr width=20%:) '''23''' /tcp
(:cell:) Telnet
(:cellnr bgcolor=#f5f9fc valign=middle:) '''25''' /tcp
(:cell bgcolor=#f5f9fc valign=middle:) [[#s10|SMTP]]
(:cellnr width=20%:) '''53''' /tcp/udp
(:cell:) [[#s11|DNS]]
(:cellnr bgcolor=#f5f9fc valign=middle:) '''80''' /tcp
(:cell bgcolor=#f5f9fc valign=middle:) [[#s8|HTTP]]
(:cellnr width=20%:) '''110''' /tcp
(:cell:) [[#s103|POP3]]
(:cellnr bgcolor=#f5f9fc valign=middle:) '''143''' /tcp
(:cell bgcolor=#f5f9fc valign=middle:) IMAP4
(:tableend:)
[[<<]]
[[#su|[-'''Torna su'''-]]]
Changed line 94 from:
!!!Che cosa definisce un protocollo applicativo?
to:
!!Che cosa definisce un protocollo applicativo? Added lines 101-103:
[[#su|[-'''Torna su'''-]]]
Changed line 105 from:
!!!Che tipi di servizio richiede un'applicazione distribuita?
to:
!!Che tipi di servizio richiede un'applicazione distribuita? Added lines 113-115:
[[#su|[-'''Torna su'''-]]]
Changed lines 117-118 from:
!!!Livello di trasporto {+TCP vs UDP+} to:
!!Livello di trasporto: {+TCP vs UDP+} Changed lines 120-121 from:
(:cellnr bgcolor=#d9e4f2 colspan=2:)'''TCP'''
(:cell bgcolor=#d9e4f2 colspan=2:)'''UDP''' to:
(:cellnr bgcolor=#d9e4f2 colspan=2 align=center:)'''TCP'''
(:cell bgcolor=#d9e4f2 colspan=2 align=center:)'''UDP''' Changed lines 133-135 from:
Ma se UDP non fa un cavolo, che utilità ha? E' un protocollo più leggero. to:
[[<<]]
Ma se UDP non fa un cavolo, che utilità ha? Beh, innanzitutto è un protocollo più leggero (intestazione di 8 byte) e quindi comporta un basso consumo di banda. Poi il fatto di non creare alcuna connessione elimina i ritardi dovuti alla configurazione della comunicazione (non ci sono partecipanti da sincronizzare).
[[#su|[-'''Torna su'''-]]] Changed lines 141-147 from:
!!!WEB & HTTP
Le pagine web come tutti sappiamo sono composte da un gran numero di oggetti: un file html di base contiene infatti riferimenti ad altri oggetti: immagini jpg, applet java ecc... Ogni oggetto è indirizzabile con un URL: eg. "www.someschool.edu/someDept/pic.gif" identificherà il nome di un'immagine.\\
Attenzione! Ci sono delle differenze quando di parla di URL, URI e URN!
*URL = universal resource locator: identifica la risorsa in modo globale attraverso la ''locazione'' della risorsa stessa (su che server è)
*URI = universal resource identifier: identifica la risorsa indipendentemente da dove si trova o dal nome con il quale è nota
*URN = universal resource name: identifica la risorsa attraverso il ''nome'' anche se l'oggetto stesso non è reperibile (eg. voglio dare un nome alla documentazione di un software all'interno della mia rete aziendale) to:
!!WEB & HTTP
Le pagine web come tutti sappiamo sono composte da un gran numero di oggetti: un file html di base contiene infatti riferimenti ad altri oggetti: immagini jpg, applet java ecc... Ogni oggetto è indirizzabile con un URL: eg. "www.someschool.edu/someDept/pic.gif" identificherà il nome di un'immagine.
Attenzione! Ci sono delle differenze quando di parla di '''URL''', '''URI''' e '''URN'''!
*'''URL''' = Universal Resource Locator: identifica la risorsa in modo globale attraverso la ''locazione'' della risorsa stessa ("su che server è")
*'''URI''' = Universal Resource Identifier: identifica la risorsa indipendentemente da dove si trova o dal nome con il quale è nota
*'''URN''' = Universal Resource Name: identifica la risorsa attraverso il ''nome'' anche se l'oggetto stesso non è reperibile (eg. voglio dare un nome alla documentazione di un software all'interno della mia rete aziendale) Added lines 151-153:
[[#su|[-'''Torna su'''-]]]
Changed line 155 from:
!!!HTTP (Hyper Test Transfer Protocol)
to:
!!HTTP (Hyper Test Transfer Protocol) Changed lines 157-158 from:
Ne esistono due versioni diverse: la 1.0 e la 1.1 (come GDA d'altronde). to:
Ne esistono due versioni diverse: la 1.0 e la 1.1 (come [[GDA->Olimpo.GDA]] d'altronde). Changed lines 165-166 from:
'''Attenzione!''' Tenere la connessione aperta non significa avere gli stati. to:
'''Attenzione!''' Mantenere la connessione aperta non significa avere gli stati. Changed lines 168-169 from:
!!!!!HTTP message
HTTP 1.0: to:
!!!!HTTP Message
Nell' ''HTTP 1.0'': Changed lines 177-179 from:
%center green% TOTALE = 2RTT + tempo di trasmissione per ogni oggetto.\\ to:
%center green% TOTALE = 2RTT + tempo di trasmissione per ogni oggetto. Changed lines 184-187 from:
* l'altra è detta PIPELING: il client manda richiesta per ogni oggetto che trova, senza aspettare di aver ricevuto gli oggetti trovati prima, il server crea una ''pipeline'' e glieli manda tutti insieme.
Ho due messaggi HTTP: REQUEST e RESPONSE to:
* l'altra è detta PIPELING: il client manda richiesta per ogni oggetto che trova, senza aspettare di aver ricevuto gli oggetti trovati prima; il server crea una ''pipeline'' e glieli manda tutti insieme.
Ho due messaggi HTTP: ''REQUEST'' e ''RESPONSE'' Changed lines 189-213 from:
!!!!!HTTP REQUEST MESSAGE
E' in ASCII.
La ''request line'' è così formata:\\
'''GET, POST, HEAD commands''' => %green%"GET/somedir/page.html HTTP/1.1"%none% (per far sapere al server se ho persistenza o no)
L' ''Header line'' è così formata:
*'''Host''' : www.someschool.edu
*'''User-agent''' : Mozilla/4.0
*'''Connection''' : Close (indico che voglio chiudere la connessione)
*'''Accept-language''' : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo)
Alla fine dell'header c'è un ''<CR>'' (Carrige Return) e un ''<LF>'' (Line Feed) che indicano la fine del messaggio. Poi c'è il ''Body'' con cui si può inviare roba al server.
Metodi''\\
{+HTTP 1.0+}
* Get = serve a richiedere dati al server, la risposta finisce nell'URL/URI (tanti server mandano le variabili direttamente nell'URI, con un vantaggio per il copia e incolla - ad esempio i file di youtube con il ?= - ma uno svantaggio perché sono in chiaro)
* Post = che serve a richiedere dati al server, la risposta finisce nel body
* Head = non chiedo tutto l'oggetto ma solo l'intestazione (eg. per conoscere quando è stato aggiornato l'oggetto)
{+HTTP 11+}
Aggiunge due nuovi metodi:
* Put = per l'upload dei file
* Delete = per cancellare file dal server to:
!!!!HTTP REQUEST MESSAGE
E' in ASCII ed è composto da tre parti:
* '''request line''', così formata: ''metodo'' (vedi dopo), URI, versione del protocollo. Ad esempio: %green%"GET/somedir/page.html HTTP/1.1"%none%
* '''header line''', così formata:
**''Host'' : www.someschool.edu
**''User-agent'' : Mozilla/4.0
**''Connection'' : Close (indico che voglio chiudere la connessione)
**''Accept-language'' : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo)
**infine, un ''<CR>'' (Carriage Return) e un ''<LF>'' (Line Feed) che indicano la fine del messaggio.
* '''body''', che è il corpo del messaggio, con cui si può inviare roba al server.
I ''metodi'' che possono apparire nella request line sono i seguenti, divisi per versione del protocollo:
(:table border=0 width=80% cellpadding=5 cellspacing=0:)
(:cellnr bgcolor=#d9e4f2 width=10% align=center:)'''HTTP 1.0'''
(:cell bgcolor=#d9e4f2 width=10% align=center:)'''HTTP 1.1'''
(:cell bgcolor=#d9e4f2 align=center:)'''Descrizione'''
(:cellnr align=center valign=middle:)GET
(:cell align=center valign=middle:)GET
(:cell valign=middle:)Serve a richiedere dati al server, la risposta finisce nell'URL/URI (tanti server mandano le variabili direttamente nell'URI, con un vantaggio per il copia e incolla - ad esempio i file di youtube con il ?= - ma uno svantaggio perché sono in chiaro).
(:cellnr align=center bgcolor=#f5f9fc valign=middle:)POST
(:cell align=center bgcolor=#f5f9fc valign=middle:)POST
(:cell bgcolor=#f5f9fc valign=middle:)Serve a richiedere dati al server, ma in questo caso la risposta finisce nel body.
(:cellnr align=center valign=middle:)HEAD
(:cell align=center valign=middle:)HEAD
(:cell valign=middle:)Non chiede tutto l'oggetto ma solo l'intestazione (eg. per conoscere quando è stato aggiornato l'oggetto).
(:cellnr align=center bgcolor=#f5f9fc valign=middle:)
(:cell align=center bgcolor=#f5f9fc valign=middle:)PUT
(:cell bgcolor=#f5f9fc valign=middle:)Per l'upload dei file.
(:cellnr align=center valign=middle:)
(:cell align=center valign=middle:)DELETE
(:cell valign=middle:)Per cancellare file dal server.
(:tableend:)
[[<<]] Changed lines 225-245 from:
!!!!!HTTP RESPONSE MESSAGE
C'è uno ''Status line'' così fatto:\\
%green% "HTTP/1.1 200 OK <CR><LF>"%none%
I messaggi hanno codici di tre cifre, come ad esempio:
* 200 - OK
* 301 - Moved permanentely
* 400 - Bad request
* 404 - Page not found
* 505 - HTTP version not supported
La prima cifra mi definisce la categoria del messaggio. Per conoscere il significato dei vari messaggi si può fare richiesta con un telnet.
''Header'':
*'''Connection''' : close
*'''Date''' : Thu,6 august ecc..
*'''Server''' : Apache/1.3.0(Unix)
*'''Last modified''' : <data>
*'''Content length''' : 6821
*'''Content type''' : text/html (sono i tipi MIME) to:
!!!!HTTP RESPONSE MESSAGE
Anch'essi composti da tre parti:
* '''Status line''', nella quale compare un codice a tre cifre che definisce la categoria del messaggio. Per conoscere il significato dei vari codici si può fare richiesta con un telnet, oppure andare su [[questa pagina->CodiciDiStato]]. Ad esempio, una status line potrebbe essere: %green% "HTTP/1.1 200 OK <CR><LF>"%none%
* '''Header''':
**''Connection'', eg: close
**''Date'', eg: Thu,6 august
**''Server'', tipo e versione del server. Eg: Apache/1.3.0(Unix)
**''Last modified'', eg: Thu,1 may
**''Content length'', eg: 6821
**''Content type'', tipo di contenuto restituito. Eg: text/html (sono i tipi MIME)
* '''Body''', il contenuto della risposta. Changed lines 238-239 from:
!!!!!Implementare stati HTTP
Vengono usati i '''Cookies'''.\\ to:
!!!!Esempio di HTTP Message
''HTTP REQUEST MESSAGE'':\\
[@GET /wiki HTTP/1.1
Host: doppioclic.altervista.org
Connection: Close
User-Agent: Mozilla/5.0
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: it@]
''HTTP RESPONSE MESSAGE'':\\
[@HTTP/1.1 301 Moved Permanently
Date: Fri, 18 Jan 2008 20:56:52 GMT
Server: Apache
Location: http://doppioclic.altervista.org/wiki/
Vary: Accept-Encoding
Content-Length: 246
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head ... ecc ecc@]
[[#s85]]
!!!!Implementare stati HTTP
Per simulare uno stato nell'HTTP vengono usati i '''Cookies'''.\\ Changed line 275 from:
to:
Added lines 280-282:
[[#su|[-'''Torna su'''-]]]
Changed lines 149-150 from:
* Get
* Post = che serve a mandare dati al server (anche se adesso tanti server mandano le variabili direttamente nell'URI, con un vantaggio per il copia e incolla - ad esempio i file di youtube con il ?= - ma uno svantaggio perché sono in chiaro) to:
* Get = serve a richiedere dati al server, la risposta finisce nell'URL/URI (tanti server mandano le variabili direttamente nell'URI, con un vantaggio per il copia e incolla - ad esempio i file di youtube con il ?= - ma uno svantaggio perché sono in chiaro)
* Post = che serve a richiedere dati al server, la risposta finisce nel body
Changed line 320 from:
*ditribution of multiple host on a single DNS to:
*distribution of multiple host on a single DNS Changed lines 355-356 from:
*infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentrallizzato to:
*infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentralizzato Changed lines 359-360 from:
Successivo a Napster. In questo caso le richiste di dati vengono propagate attraverso query attraverso una connessione TCP tra host. Le query sono gestite attraverso un TTL per cui dopo un po' non può più essere propagata la richiesta per non saturare la rete. Il protocollo ha una sua tipologia che si inserisce su internet. to:
Successivo a Napster. In questo caso le richieste di dati vengono propagate attraverso query attraverso una connessione TCP tra host. Le query sono gestite attraverso un TTL per cui dopo un po' non può più essere propagata la richiesta per non saturare la rete. Il protocollo ha una sua tipologia che si inserisce su internet. Changed lines 411-413 from:
Che differenza c'è? C'è che l'IP addresse la porta di destinazione del mittente deve essere estratta direttamente dal pacchetto inviato, non viene mandato a parte. to:
Che differenza c'è? C'è che l'IP address e la porta di destinazione del mittente deve essere estratta direttamente dal pacchetto inviato, non viene mandato a parte.
Changed line 311 from:
Propagazione: tempo e velocità di propagazione dei bite to:
Propagazione: tempo e velocità di propagazione dei byte
Changed line 285 from:
to:
Changed lines 292-293 from:
Il DNS usa un database distribuito, strutturato con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una chache per mantenere la lista dei nomi. to:
Il DNS usa un database distribuito, strutturato con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una cache per mantenere la lista dei nomi. Changed line 295 from:
Nelle organizzazioni si possono matenere DNS per indirizzi interni alla rete.\\ to:
Nelle organizzazioni si possono mantenere DNS per indirizzi interni alla rete.\\
Changed line 175 from:
*'''Sever''' : Apache/1.3.0(Unix) to:
*'''Server''' : Apache/1.3.0(Unix)
Changed lines 170-171 from:
La prima cifra mi definisce la categoria del messaggio. Per conoscere il signficato dei vari messaggi si può fare richiesta con un telnet. to:
La prima cifra mi definisce la categoria del messaggio. Per conoscere il significato dei vari messaggi si può fare richiesta con un telnet.
Changed lines 41-42 from:
# '''Client-sever''' = c'è un client, presente in modo discontinuo sulla rete che richiede man mano informazioni al server che invece è sempre presente. I client per contro non possono comunicare direttamente l'uno con l'altro ma solo tramite server. '''''IL SERVER é SCALABILE??(ndP)''''' to:
# '''Client-server''' = c'è un client, presente in modo discontinuo sulla rete che richiede man mano informazioni al server che invece è sempre presente. I client per contro non possono comunicare direttamente l'uno con l'altro ma solo tramite server. '''''IL SERVER é SCALABILE??(ndP)'''''
Changed lines 354-356 from:
collo di bottiglia: collegamento con problemi di banda tra host con differenti bande
infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentrallizzato to:
*collo di bottiglia: collegamento con problemi di banda tra host con differenti bande
*infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentrallizzato Changed lines 399-405 from:
'''''Esempio client/server with TCP'''''
1. client legge le righe che riceve in input (inFromUser stream) e le manda al server via socket (outToServer stream)
2. il server legge le linee dal socket
3. le converte in maiuscolo (uppercase???)e le rimanda al client
4. il client legge, stampa e modifica le linee dal socket (inFromServer stream) to:
'''''Esempio client/server with TCP'''''\\\
1. client legge le righe che riceve in input (inFromUser stream) e le manda al server via socket (outToServer stream)\\
2. il server legge le linee dal socket\\
3. le converte in maiuscolo (uppercase???)e le rimanda al client\\
4. il client legge, stampa e modifica le linee dal socket (inFromServer stream)\\\
Changed lines 350-351 from:
[+P2P centralized as Napster+] to:
''[+P2P centralized as Napster+]'' Changed lines 357-358 from:
to:
Changed lines 363-364 from:
to:
Changed lines 392-393 from:
[++Stream jargon++] ''(non ho la minima idea del perchè sia messo qui, ma teniamolo)'' to:
[+Stream jargon+] ''(non ho la minima idea del perchè sia messo qui, ma teniamolo)''
Changed lines 350-351 from:
[++P2P centralized as Napster++] to:
[+P2P centralized as Napster+] Changed lines 357-358 from:
to:
Changed lines 363-364 from:
to:
Changed lines 408-409 from:
'''''Socket programming with UDP'''''
to:
!!!!!Socket programming with UDP
Added lines 307-423:
!!!Tipi di ritardo
Viaggiando dal sorgente al destinatario il pacchetto può essere soggetto a differenti ritardi. Elementi di ritardo possono essere:
Propagazione: tempo e velocità di propagazione dei bite
trasmissione legata alla banda (dtrans = Lunghezza/ Rate{portata})
coda dei pacchetti che dipende dalla prestazioni del router e dei protocolli di trasporto
processo: legato all’header del pacchetto e all’instradamento dei router
Le strategie per ridurre il ritardo sono chiamate di Content Distribution. Tutte agiscono sul tempo di trasmissione aumentando e diminuendo l’uso della banda.
Esse sono:
*web caching (ottimizzare contenuti server)
*mirroring
*ditribution of multiple host on a single DNS
*P2P
!!!!!WEB CACHING
Server proxy: le richieste del client non vanno al server di origine ma si fermano in un server diverso che ha già in sè la maggioranza delle informazioni richieste dal client. Il vantaggio principale è derivato dal fatto che di solito la banda passante tra client e proxy è maggiore di quella tra client e server di origine.
Inoltre riduce il tempo di risposta alla richiesta e il traffico al link.
E' un'architettura con grande replicazione cache e a chi ha banda bassa può fornire risorse con banda alta richiedendo direttamente alla cache. Siccome non so come mettere i suoi disegni guardare le sue dispense:
{+Vedi slide 74-78 Ceravolo+}
!!!!!CONTENT DISTRIBUTION NETWORKS
Sono compagnie che affittano spazi dove i clienti possono replicare contenuti. Il cliente sviluppa un meccanismo che risolve le richieste del server centrale e le reindirizza al più vicino CND, quindi fornisco degli spazi dove smistare le richieste a vari mirroring. L’impatto positivo è la valorizzazione economica del servizio.
Conoscere la mappa della rete è quindi importante.
!!!!!P2P file sharing
Non si usa un’architettura client-server (richiesta a un fornitore di servizio) ma host che fungono sia da client che da server.
Distribuire i contenuti non significa però diminuirli.
Ci sono due tipi di file sharing:
#'''bootstrap''': gli host si collegano alla rete quindi deve essere agganciato alla rete stessa e avere un punto di collegamento per invio richieste ad altri peer. Smisto le richieste sapendo chi sono i suoi vicini
#'''lookup''': per avere la risorsa x devo fornire uno o più host che mi dicono ciò che voglio.
Data transfert: dare risorsa ad altri (host to host)
Penso che tutti sappiano come sia il file sharing, i punti principali sono spiegati {+nella slide 81 di Ceravolo+} comunque.
[++P2P centralized as Napster++]
In quest'architettura centralizzata il server riconosce l'host e lo registra e si occupa del lookup cioè controlla chi è l'host che può soddisfare la richiesta inviata da un altro host. (Lookup = richiesta di dati ai vicini, che propagano la richiesta ad altri vicini e man mano si allarga il giro)
I problemi di questo tipo sono:
collo di bottiglia: collegamento con problemi di banda tra host con differenti bande
infrazione di copyright: il server non sa cosa si inviano tra loro gli host perchè il trasferimento dei file è decentrallizzato
[++P2P as Gnutella++]
Successivo a Napster. In questo caso le richiste di dati vengono propagate attraverso query attraverso una connessione TCP tra host. Le query sono gestite attraverso un TTL per cui dopo un po' non può più essere propagata la richiesta per non saturare la rete. Il protocollo ha una sua tipologia che si inserisce su internet.
Per capire meglio l'architettura vedi slide 86
[++Ibrido: KaZaA++]
In quest'architettura c'è un super peer cioè un gruppo leader che funge da server, collegati ciascuno ad altrettanti host tutti attraverso il protocollo TCP.
Ogni file ha un suo codice e una descrizione. Il client manda la query con la parola chiave al suo gruppo leader. Questo risponde con le informazioni richieste fornendo metadata (dati relativi al dato dato), hash e IP address. Se il gruppo leader deve inviare la domanda ad altri gruppi anche questi dovranno rispondere con le stesse informazioni. Infine il client sceglie i file da scaricare.
Ci sono dei problemi sull'efficienza e la sicurezza perchè un peer può ingannare l'altro modificando i dati visibili del file da scaricare. Limitato inoltre il download parallelo per via delle code nella rete.
!!!Scalability
La scalabilità di un protocollo è relativa all'efficacia del servizio di lookup (cioè quello che manda i messaggi di richiesta dei dati)
Due sono gli obiettivi principali:
*minimizzare il numero di messaggi richiesti per il lookup
*minimizzare i metadata richiesti per descrivere ogni nodo
Il progetto ''Chord'' si prefigge di sviluppare sistemi distribuiti scalabili (può allargare la sua distribuzione) e robusti sfruttando le idee del peer-to-peer. Il componente base del progetto Chord è l'algoritmo di ricerca distribuita basata su tabelle di hash, tabelle di codici di dati. Chord può trovare dati usando log(N) messaggi, dove N è il numero di nodi nel sistema. Perciò per trovare dei dati non fa passare il messaggio di richiesta da tutti i nodi ma solo a logN nodi attraverso un sistema di ricerca del "vicino". Cioè invio la richiesta a un nodo conoscendo già il suo o i suoi vicini.
!!!Socket programming
Cos'è un socket?
Un socket in inglese è letteralmente la "presa da muro". Attraverso di esso un processo applicativo può sia mandare che ricevere messaggi da un altro processo. I socket permettono al protocollo applicativo di comunicare con il protocollo di trasporto.
Il protocollo di trasporto può essere come tutti ben sappiamo UDP o TCP.
!!!!!Socket programming with TCP
TCP è un protocollo affidabile, ossia trasferisce pacchetti in ordine tra client e server. E' più lungo da utilizzare perchè bisogna tener conto del fatto che il client e il server "si mettono d'accordo" su dettagli di trasferimento.\\
Infatti il client contatta il server che deve essere prima fatto "partire" (running) e deve essere stata creata una socket door che riceve il client.\\
Quando il client vuole contattare il server deve fornire IP address e port number. Quando il client crea il socket il client TCP stabilisce una connessione con il server TCP. E ogni volta che il client lo contatta il server TCP crea nuovi socket per il processo per comunicare con il client. Il server può parlare con molti client e identificarli attraverso il numero di porta.
[++Stream jargon++] ''(non ho la minima idea del perchè sia messo qui, ma teniamolo)''
Lo stream è una sequenza di caratteri che scorre dentro o fuori dal processo.
*Input stream = semplicemente tutti i dati che vengono dalle periferiche di input (tastiera, mouse ecc)
*Output stream = tutti i dati che deve inviare in uscita (stampante)
'''''Esempio client/server with TCP'''''
1. client legge le righe che riceve in input (inFromUser stream) e le manda al server via socket (outToServer stream)
2. il server legge le linee dal socket
3. le converte in maiuscolo (uppercase???)e le rimanda al client
4. il client legge, stampa e modifica le linee dal socket (inFromServer stream)
{+vedi slide 100-104 per un esempio di Java client/server TCP+}
'''''Socket programming with UDP'''''
UDP non dà connessione e il lavoro è perciò ridotto perchè non c'è bisogno dei patteggiamenti (le "strette di mano") da fare con UDP, è un modello più semplice perchè non c'è bisogno di aprire la connessione. Però come ricordiamo è un protocollo non affidabile quindi i pacchetti possono essere persi o ricevuti in ordine sbagliato.
Che differenza c'è? C'è che l'IP addresse la porta di destinazione del mittente deve essere estratta direttamente dal pacchetto inviato, non viene mandato a parte.
{+vedi slide 107-112 per un esempio di Java client/server UDP+}
!!!Costruire un semplice Web server ''(nb. può servirci per costruire quello da fare per Sassi?)''
Esso si occupa di richieste HTTP e di tutti gli annessi e i connessi, cioè: accettare le richieste, analizzare l'header, ottenere le richieste dal server file system, creare una risposta al messaggio HTTP (header lines + file), mandare la risposta al client.\\
Dopo aver creato un server HTTP posso fare le richieste direttamente dal browser.
Changed lines 35-36 from:
Sono applicazioni distribuite, ovvero eseguiti su una macchina locale ma che interagiscono con una macchina altrove sulla rete. Esempi di questi protocolli sono: server Email su internet, Msn, Emule, VoIp ecc... to:
Sono applicazioni distribuite, ovvero eseguiti su una macchina locale ma che interagiscono con una macchina posta altrove sulla rete. Esempi di questi protocolli sono: server Email su internet, Msn, Emule, VoIp ecc... Changed lines 43-46 from:
#'''P2P''' = ogni host chiede e passa informazioni ad altri host che possono esserci o non esserci, sono connessi in modo intermittente. Proprio qui sta il problema: le informazioni devono essere "garantite" a prescindere da quali host sono connessi. Sono rare le P2P pure, di solito sono ibride, l'unico è Gnutella che è scalabile cioè funziona con pochi utenti che con tanti.
#'''Ibride''' = ci sono dei ''supernodi'' che smistano gli host collegati. Esempi di ibridi sono Napster (file transfer P2P) o IM (istant messaging) in cui comunico ad un server la mia esistenza e quando sono registrata trova tutti gli indirizzi collegati al mio buddy (penso intenda profilo...) to:
#'''P2P''' = ogni host chiede e passa informazioni ad altri host che possono esserci o non esserci, sono connessi in modo intermittente. Proprio qui sta il problema: le informazioni devono essere "garantite" a prescindere da quali host sono connessi. Sono rare le P2P pure, di solito sono ibride, l'unico è Gnutella che è scalabile cioè funziona sia con pochi utenti che con tanti.
#'''Ibride''' = ci sono dei ''supernodi'' che smistano gli host collegati. Esempi di ibridi sono Napster (file transfer P2P) o IM (istant messaging) in cui comunico ad un server la mia esistenza e quando sono registrata trova tutti gli indirizzi collegati al mio buddy (il profilo). Changed lines 49-51 from:
Un processo è un qualunque programma che funziona su un host, sia lato client che lato server. Il sistema operativo gestisce i processi e la IPC (Inter Process Communication). Come collegare tra loro processi diversi? tramite la nozione di '''porta'''. Una porta è un concetto astratto per stabilire che il processo X, che sarà interrotto da altri processi, possa comunicare con il processo Y, il quale parimenti sarà interrotto e così via.\\
Per gestire la comunicazione dei processi fra host diversi uso i ''socket''. A cosa mi servono le porte allora? Non posso tener conto solo del fatto che ogni host ha un indirizzo IP unico perchè processi diversi possono essere inviati allo stesso host, perciò devo associare un numero di porta (eg il numero di porta di internet solitamente è 80). to:
Un processo è un qualunque programma che funziona su un host, sia lato client che lato server. Il sistema operativo gestisce i processi e la IPC (Inter Process Communication). Come collegare tra loro processi diversi? Tramite la nozione di '''porta'''. Una porta è un concetto astratto per stabilire che il processo X, che sarà interrotto da altri processi, possa comunicare con il processo Y, il quale parimenti sarà interrotto e così via. Sostanzialmente per porta si intende quindi un canale di comunicazione attraverso cui due host riescono a comunicare.
Per gestire la comunicazione dei processi fra host diversi uso i ''socket''. A cosa mi servono le porte allora? Beh, non posso tener conto solo del fatto che ogni host ha un indirizzo IP unico, perchè processi diversi possono essere inviati sullo stesso terminale. Devo quindi associare un numero di porta per distinguerli (eg il numero di porta di internet solitamente è 80). Changed lines 59-60 from:
Solitamente il protocollo definisce espressamente le prime due cose, la terza è implicita to:
Solitamente il protocollo definisce espressamente le prime due cose, la terza è implicita. Changed line 63 from:
In base a ciò che un'applicazione richiede infatti si caratterizza il protocollo to:
In base a ciò che un'applicazione richiede si caratterizza il protocollo: Changed lines 66-67 from:
#''Banda'': quanta banda minima mi serve?\\ to:
#''Banda'': quanta banda minima mi serve? Changed lines 88-89 from:
Ma se UDP non fa un cavolo, a cosa mi serve? E' un protocollo più leggero. to:
Ma se UDP non fa un cavolo, che utilità ha? E' un protocollo più leggero. Changed line 92 from:
Le pagine web come tutti sappiamo sono composte da un gran numero di oggetti: un file html di base che contiene riferimenti ad altri oggetti: immagini jpg, applet java ecc... Ogni oggetto è indirizzabile con un URL: eg. "www.someschool.edu/someDept/pic.gif" identificherà il nome di un'immagine.\\ to:
Le pagine web come tutti sappiamo sono composte da un gran numero di oggetti: un file html di base contiene infatti riferimenti ad altri oggetti: immagini jpg, applet java ecc... Ogni oggetto è indirizzabile con un URL: eg. "www.someschool.edu/someDept/pic.gif" identificherà il nome di un'immagine.\\ Changed lines 96-97 from:
*URN = universal resource name: identifica la risorsa attraverso il ''nome'' anche se l'oggetto stesso non è reperibile (eg. voglio dare un nome alla documentazione di un software all'interno della mia rete aziendale)\\ to:
*URN = universal resource name: identifica la risorsa attraverso il ''nome'' anche se l'oggetto stesso non è reperibile (eg. voglio dare un nome alla documentazione di un software all'interno della mia rete aziendale) Changed lines 101-104 from:
!!!HTTP -> Hyper Test Transfer Protocol
Applicazione Web. Il client invia una richiesta di un oggetto, identificato con un URI, il server se ce l'ha lo invia, altrimenti risponde con un errore, semplice vero?\\
Esistono due versioni diverse: la 1.0 e la 1.1 (come GDA d'altronde)\\
Esso si basa su TCP: il client richiede dati aprendo una connessione TCP al server sulla porta 80-> quando ho ottenuto le informazioni che mi servono, la connessione si chiude. Per ogni oggetto invio una richiesta.\\ to:
!!!HTTP (Hyper Test Transfer Protocol)
Applicazione Web. Il client invia una richiesta di un oggetto, identificato con un URI: il server se ce l'ha lo invia, altrimenti risponde con un errore. Semplice vero?\\
Ne esistono due versioni diverse: la 1.0 e la 1.1 (come GDA d'altronde).
L'HTTP si basa su TCP: il client richiede dati aprendo una connessione TCP al server sulla porta 80; quando ho ottenuto le informazioni che mi servono, la connessione si chiude. Per ogni oggetto invio una richiesta.\\ Changed lines 107-109 from:
E' un protocollo senza stati cioè la connessione è ogni volta aperta e chiusa, il server non tiene memoria delle richieste precedenti perciò se non mi arriva un oggetto devo ripetere la mia richiesta. Ma questa semplicità eccessiva non permette di gestire la persistenza della connessione. Si è passati perciò alla versione 1.0 con il vantaggio che mando più oggetti con una singola connessione e risparmio banda.\\
'''Attenzione!''' Tenere al connessione aperta non significa che ha gli stati. to:
E' un protocollo senza stati, cioè la connessione viene aperta e chiusa ogni volta; il server non tiene memoria delle richieste precedenti, perciò se non mi arriva un oggetto dovrò ripetergliela.
Dato però che questa semplicità eccessiva non permetteva di gestire la persistenza della connessione (e per altri motivi), si è passati alla versione 1.1 con il vantaggio che riesco a mandare più oggetti con una singola connessione, risparmiando banda.
'''Attenzione!''' Tenere la connessione aperta non significa avere gli stati. Added line 115:
Changed lines 122-124 from:
Quant'è perciò il tempo di risposta? C'è un RTT per aprire la connessione, un RTT per la richiesta HTTP e i primi bytes delal risposta, infine il tempo di trasmissione dei file.
%center green% TOTALE = 2RTT + tempo di trasmissione per ogni oggetto\\
Ecco perchè c'è la necessità di HTTP persistente. Ci sono due implementazioni di persistenza: to:
Quant'è perciò il tempo di risposta? C'è un RTT per aprire la connessione, un RTT per la richiesta HTTP e i primi bytes della risposta, infine il tempo di trasmissione dei file.
%center green% TOTALE = 2RTT + tempo di trasmissione per ogni oggetto.\\
Ecco perchè sorge la necessità di un HTTP persistente.
Ci sono due implementazioni di persistenza: Changed lines 128-129 from:
* una è detta PIPELING: il client manda richiesta per ogni oggetto che trova, senza aspettare di aver ricevuto gli oggetti trovati prima, il server crea una ''pipeline'' e glieli manda tutti insieme. to:
* l'altra è detta PIPELING: il client manda richiesta per ogni oggetto che trova, senza aspettare di aver ricevuto gli oggetti trovati prima, il server crea una ''pipeline'' e glieli manda tutti insieme. Changed lines 134-135 from:
to:
Changed lines 150-152 from:
* Post = che serve per mandare roba al server (anche se adesso tanti server mandano le variabili direttamente nell'URI, vantaggio per il copia e incolla, ad esempio i file di youtube con il ?=, svantaggio è che sono in chiaro)
* Head = non chiedo tutto l'oggetto ma solo l'intestazione (eg. per conoscere quando è stato aggiornato l'oggetto to:
* Post = che serve a mandare dati al server (anche se adesso tanti server mandano le variabili direttamente nell'URI, con un vantaggio per il copia e incolla - ad esempio i file di youtube con il ?= - ma uno svantaggio perché sono in chiaro)
* Head = non chiedo tutto l'oggetto ma solo l'intestazione (eg. per conoscere quando è stato aggiornato l'oggetto) Changed line 163 from:
I messaggi hanno codici di tre cifre come si può vedere,questi codici sono ad esempio: to:
I messaggi hanno codici di tre cifre, come ad esempio: Changed line 183 from:
Eg. ho un sito che vende roba e voglio mantenere un carrello della spesa per un utente, ma so che HTTP non ha memoria perciò uso i cookies. Essi possono servire quindi per: to:
Eg. ho un sito che vende ciarpame e voglio mantenere un carrello della spesa per un utente. Dato che HTTP non ha memoria, scrivo le informazioni su file detti cookies. Posso dunque usarli per: Changed lines 189-190 from:
Se serve un cookie quando il server risponde nell'header invierà eg: 'e il client deve mantenere quel cookie, perciò poi quando il client invierà successive richieste manderà anche: ''"cookie: 1678"'' così il server sa chi sono. I cookie creano però problemi di privacy. to:
Se serve un cookie, quando il server risponde aggiungerà una linea nell'header (ad esempio) ''"Set-cookie:1678"'' ed il client dovrà mantenerlo in memoria. Quando poi il client invierà successive richieste, manderà anche ''"cookie: 1678"'' così che il server sappia chi sono.
E' tutto bello e comodo, ma sorgono però dei problemi di privacy, dato che questi file contengono informazioni più o meno riservate sul mio conto. Changed lines 195-199 from:
Per migliorare l'efficienza della rete è meglio ridurre il numero di richieste perciò uso un proxy che mantiene nella memoria locale le informazioni richieste così che è lui a darle al cliente, non il server, così non si sovraccarica. Il proxy deve controllare se un oggetto è aggiornato. Ecco a cosa serve la richiesta dello head che il proxy usa per aggiornare la chache.
'''Attenzione!'''questo lavoro di aggiornamento non lo fa ogni volta altrimenti il risparmio è relativo.
Per sapere se un oggetto è aggiornato o no ecco che il server risponde 304 se non è modificato oppure se lo è dice la data. to:
Per migliorare l'efficienza della rete è meglio ridurre il numero di richieste sui server. Si utilizzano così dei dispositivi chiamati '''proxy''' che provvedono a fare da tramite e che mantengono nella loro cache una copia degli oggetti richiesti, così da mandar questi invece di richiederli dai server. Certo, in questo modo un proxy dovrà sempre controllare che l'oggetto nella cache sia aggiornato, ed ecco quindi a cosa serve il campo date dello header HTTP. ('''Attenzione!''' l'aggiornamento non viene fatto ogni volta, o il risparmio di traffico sarebbe relativo) \\
Il server a cui viene chiesto di controllare se l'oggetto sia stato aggiornato risponde 304 se non lo è, con una data altrimenti. Changed line 200 from:
File Transfer Protocol. Aperto sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati.\\ to:
File Transfer Protocol. Attivo sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati.\\ Changed lines 213-214 from:
to:
Changed lines 222-223 from:
Tre sono le componenti principali:
#user agent
to:
Esistono tre componenti principali:
#user agent (il client email, ad esempio Thunderbird o {-Outlook-}) Changed lines 225-227 from:
#SMTP simple mail transfer protocol
E tre sono le fasi: to:
#SMTP (Simple Mail Transfer Protocol)
...e tre fasi di comunicazione: Changed lines 232-233 from:
Il messaggio viene passato in codifica ASCII\\ to:
Il messaggio viene passato in codifica ASCII. Changed lines 240-241 from:
#Per leggere il messaggio invoco lo User agent to:
#Per leggere il messaggio utilizzo di nuovo l'User agent Changed lines 252-254 from:
client: ...inizio email....\\
Le email sono terminate da un punto messo in una riga da solo. La connessione viene aperta e chiusa alla fine del messaggio, si può fare da telnet sulla porta 25.\\ to:
client: ...inizio email....
Le email sono terminate da un punto messo in una riga da solo. La connessione viene aperta e chiusa alla fine del messaggio. Si può eseguire il tutto da telnet sulla porta 25.\\ Changed lines 257-258 from:
Riassumendo i comandi principali di un messaggio in SMTP sono: '''HELO,MAIL FROM, RCPT TO, DATA, QUIT''' to:
Riassumendo i comandi principali di un messaggio in SMTP sono: '''HELO, MAIL FROM, RCPT TO, DATA, QUIT''' Changed lines 263-264 from:
''Body'': contiene il messaggio in codifica ASCII\\ to:
''Body'': contiene il messaggio in codifica ASCII Changed lines 268-269 from:
Content-type : image/jpg => questi sono definiti dalla versione del MIME (solitamente versione 1.0)\\ to:
Content-type : image/jpg => questi sono definiti dalla versione del MIME (solitamente versione 1.0) Changed lines 274-275 from:
Diversamente dall'SMTP per ricevere la posta ha bisogno dell'autenticazione con username e pass. Si possono listare i messaggi, che vengono identificati con un numero, e poi cancellati dal server, e non posso più rileggere i messaggi se accedo a un altro client. to:
Diversamente dall'SMTP, per ricevere la posta ha bisogno dell'autenticazione con username e pass. Si possono listare i messaggi, che vengono identificati con un numero, e poi cancellati dal server, e non posso più rileggere i messaggi se accedo a un altro client. Changed lines 277-278 from:
Poi, noi DATA di una mail, ogni singolo pezzo ha il suo charnet e il suo tipo MIME. to:
Poi, nel DATA di una mail, ogni singolo pezzo ha il suo charnet e il suo tipo MIME. Changed lines 292-296 from:
Il DNS usa un databese distribuito, organizzata con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una chache per mantenere la lista dei nomi.
Nella gerarchia c'è un ROOT DNS, ce ne sono pochi nel mondo e poi ci sono di livello più basso, uno per dominio (.com, .edu, ecc.. =>server top level) e infine quelli locali.\\
Nelle organizzazioni ci possono matenere DNS per indirizzi interni alla rete.\\
I DNS mmantengono una cahce di indirizzi dopo che ne hanno trovati alcuni sconoscuti, la chache ogni tot scade. to:
Il DNS usa un database distribuito, strutturato con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una chache per mantenere la lista dei nomi.
Nella gerarchia c'è un ROOT DNS (ce ne sono pochi nel mondo) e poi altri livelli più bassi, uno per il dominio (.com, .edu, ecc.. => server top level) e infine quelli locali.\\
Nelle organizzazioni si possono matenere DNS per indirizzi interni alla rete.\\
I DNS mantengono una cache (aggiornata) di indirizzi dopo che ne hanno trovati alcuni sconosciuti. Changed line 300 from:
*'''TYPE NS''': dò un domnio mi dà l'IP del DNS che sa qualcosa di quel dominio to:
*'''TYPE NS''': dò un dominio, mi dà l'IP del DNS che sa qualcosa di quel dominio Changed lines 304-306 from:
Il formato delle richieste RR (Resource Record) sono del tipo: ''name, value, type, TTL'' e anche le risposte sono così. A seconda del tipo di chiamata il VALUE contine cose diverse.\\
Le QUERY e le REPLY hanno lo stesso formato di messaggio. A una richiesta DNS possono rispondere sia di DNS che ce l'hanno in cache, sia quelli che sono AUTORITHATIVE per quel server, se indico RECURSION voglio raggiungere il server autoritativo di quell'indirizzo, se no lascio decidere al DNS a cui chiedo. to:
Il formato delle richieste RR (Resource Record) sono del tipo: ''name, value, type, TTL'' e anche le risposte sono così. A seconda del tipo di chiamata il VALUE contiene cose diverse.\\
Le QUERY e le REPLY hanno lo stesso formato di messaggio. A una richiesta DNS possono rispondere sia con DNS che hanno in cache, sia con quelli che sono AUTORITHATIVE per quel server. Se indico RECURSION voglio raggiungere il server autoritativo di quell'indirizzo, se no lascio decidere al DNS a cui chiedo.
Changed lines 104-105 from:
'''Attenzione!''' Tenere al connessione aperta non significa che ha gli stati.\\ to:
'''Attenzione!''' Tenere al connessione aperta non significa che ha gli stati.
Changed line 34 from:
to:
Changed line 38 from:
to:
Changed line 48 from:
!!!!Comunicazioni fra processi
to:
!!!Comunicazioni fra processi Changed line 53 from:
!!!!Che cosa definisce un protocollo applicativo?
to:
!!!Che cosa definisce un protocollo applicativo? Changed line 61 from:
!!!!Che tipi di servizio richiede un'applicazione distribuita?
to:
!!!Che tipi di servizio richiede un'applicazione distribuita? Changed lines 69-70 from:
!!!!Livello di trasporto {+TCP vs UDP+}
to:
!!!Livello di trasporto {+TCP vs UDP+} Changed line 89 from:
to:
Changed line 98 from:
!!!!HTTP -> Hyper Test Transfer Protocol
to:
!!!HTTP -> Hyper Test Transfer Protocol Changed line 188 from:
to:
Changed line 209 from:
to:
Changed line 267 from:
to:
Changed line 9 from:
>>left bgcolor=#f5f9fc width=350px border='2px solid #cccccc' padding=5px<< to:
>>left bgcolor=#f5f9fc width=300px border='2px solid #cccccc' padding=5px<<
Changed line 9 from:
>>left bgcolor=#f5f9fc width=500px border='2px solid #cccccc' padding=5px<< to:
>>left bgcolor=#f5f9fc width=350px border='2px solid #cccccc' padding=5px<<
Changed line 9 from:
>>left bgcolor=#f5f9fc width=300px border='2px solid #cccccc' padding=5px<< to:
>>left bgcolor=#f5f9fc width=500px border='2px solid #cccccc' padding=5px<<
Changed lines 7-9 from:
%sottotitolo%ovvero Protocolli applicativi - Application Layer
>>left bgcolor=#f5f9fc width=215px border='2px solid #cccccc' padding=5px<< to:
%center%%sottotitolo%ovvero Protocolli applicativi - Application Layer
>>left bgcolor=#f5f9fc width=300px border='2px solid #cccccc' padding=5px<<
Changed lines 2-7 from:
%titolo%'''::A lezione con Ceravolo!(ovvero Protocolli applicativi - Application Layer)::'''
!!!!!Cosa sono?
to:
[[Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani->Sistemi]]
----
%titolo%''':: A lezione con Ceravolo! ::'''
%sottotitolo%ovvero Protocolli applicativi - Application Layer
>>left bgcolor=#f5f9fc width=215px border='2px solid #cccccc' padding=5px<<
%center%'''Indice'''
# [[#s1|Cosa sono]]
# [[#s2|Nozioni preliminari]]
# [[#s3|Comunicazioni fra processi]]
# [[#s4|Che cosa definisce un protocollo applicativo?]]
# [[#s5|Che tipi di servizio richiede un'applicazione distribuita?]]
# [[#s6|Livello di trasporto {+TCP vs UDP+}]]
# [[#s7|WEB & HTTP]]
# [[#s8|HTTP]]
** [[#s81|HTTP message]]
** [[#s82|HTTP REQUEST MESSAGE]]
** [[#s83|HTTP RESPONSE MESSAGE]]
** [[#s84|Implementare stati HTTP]]
** [[#s85|Proxy Server]]
# [[#s9|FTP]]
# [[#s10|Posta elettronica]]
** [[#s101|Sample SMTP interaction]]
** [[#s102|RFL 822]]
** [[#s103|POP]]
# [[#s11|DNS]]
>><<
[[#s1]]
!!!!Cosa sono? Changed lines 37-38 from:
to:
[[#s2]]
!!!!Nozioni preliminari Changed lines 47-48 from:
!!!!!Comunicazioni fra processi
to:
[[#s3]]
!!!!Comunicazioni fra processi Changed lines 52-53 from:
!!!!!Che cosa definisce un protocollo applicativo?
to:
[[#s4]]
!!!!Che cosa definisce un protocollo applicativo? Changed lines 56-57 from:
* Azioni da intraprendere a seconda di ciò che riceve\\ to:
* Azioni da intraprendere a seconda di ciò che riceve Changed lines 60-61 from:
!!!!!Che tipi di servizio richiede un'applicazione distribuita?
to:
[[#s5]]
!!!!Che tipi di servizio richiede un'applicazione distribuita? Changed lines 68-69 from:
!!!!!Livello di trasporto {+TCP vs UDP+}
to:
[[#s6]]
!!!!Livello di trasporto {+TCP vs UDP+} Changed lines 88-89 from:
to:
Changed line 91 from:
Attenzione! Ci sono delle differenze quando di parla di URL, URI e URN!\\ to:
Attenzione! Ci sono delle differenze quando di parla di URL, URI e URN! Changed lines 97-98 from:
[+HTTP+]->Hyper Test Transfer Protocol\\ to:
[[#s8]]
!!!!HTTP -> Hyper Test Transfer Protocol Changed lines 106-107 from:
to:
[[#s81]]
!!!!!HTTP message Changed lines 122-123 from:
[+HTTP REQUEST MESSAGE+]\\\ to:
[[#s82]]
!!!!!HTTP REQUEST MESSAGE Changed lines 125-131 from:
La ''request line'' è così formata: '''GET, POST, HEAD commands''' => %green%"GET/somedir/page.html HTTP/1.1"%none% (per far sapere al server se ho persistenza o no)\\
L' ''Header line'' è così formata:\\
*'''Host''' : www.someschool.edu\\
*'''User-agent''' : Mozilla/4.0\\
*'''Connection''' : Close (indico che voglio chiudere la connessione)\\
*'''Accept-language''' : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo)\\\ to:
La ''request line'' è così formata:\\
'''GET, POST, HEAD commands''' => %green%"GET/somedir/page.html HTTP/1.1"%none% (per far sapere al server se ho persistenza o no)
L' ''Header line'' è così formata:
*'''Host''' : www.someschool.edu
*'''User-agent''' : Mozilla/4.0
*'''Connection''' : Close (indico che voglio chiudere la connessione)
*'''Accept-language''' : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo) Changed lines 141-142 from:
to:
Changed lines 147-150 from:
+HTTP RESPONSE MESSAGE+]\\\
C'è uno ''Status line''
center%%green% "HTTP/1.1 200 OK <CR><LF>"%none%\\
to:
[[#s83]]
!!!!!HTTP RESPONSE MESSAGE
C'è uno ''Status line'' così fatto:\\
%green% "HTTP/1.1 200 OK <CR><LF>"%none% Changed lines 157-160 from:
* 505 - HTTP version not supported\\
La prima cifra mi definisce la categoria del messaggio. Per conoscere il signficato dei vari messaggi si può fare richiesta con un telnet.\\ to:
* 505 - HTTP version not supported
La prima cifra mi definisce la categoria del messaggio. Per conoscere il signficato dei vari messaggi si può fare richiesta con un telnet. Added line 169:
Changed line 171 from:
Vengono usati i '''Cookies'''\\ to:
Vengono usati i '''Cookies'''.\\ Added line 177:
Added line 180:
Added line 183:
Changed lines 187-188 from:
!!!!!FTP
File Transfer Protocol. Aperto sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati. to:
[[#s9]]
!!!!FTP
File Transfer Protocol. Aperto sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati.\\ Changed line 196 from:
to:
Changed lines 208-209 from:
to:
[[#s10]]
!!!!Posta elettronica Changed lines 229-231 from:
[+Sample SMTP interaction+]\\\
Il client si presenta con il comando HELO\\ to:
[[#s101]]
!!!!!Sample SMTP interaction
Il client si presenta con il comando HELLO: Changed lines 242-243 from:
Alla fine si saluta scrivendo QUIT.\\\ to:
Alla fine si saluta scrivendo QUIT. Changed lines 246-247 from:
to:
Changed lines 252-253 from:
Qualora volessi inviare altro oltre al testo dovrei servirmi dei tipi '''MIME''' che codificheranno il messaggio.\\ to:
Qualora volessi inviare altro oltre al testo dovrei servirmi dei tipi '''MIME''' che codificheranno il messaggio. Changed lines 257-259 from:
SMTP viene usato anche tra server e server per l'invio effettivo di mail. ''NON'' c'è bisogno di autenticazioni
!!!!POP3 to:
SMTP viene usato anche tra server e server per l'invio effettivo di mail. ''NON'' c'è bisogno di autenticazioni.
[[#s103]]
!!!!!POP3 Changed line 263 from:
IMAP invece mantiene tutti i messaggi sul server e si può accedervi da diversi client. I messaggi in genere contengono più oggetti, esempio testo e allegati. Il MIME è quello che me li fa vedere. Devo anche stabilire un marcatore per dividere un tipo di oggetto da un altro, eg. BOUNDARY: "--next part 011397--", quindi dopo questa riga so che c'è un altro oggetto di diverso. to:
IMAP invece mantiene tutti i messaggi sul server e si può accedervi da diversi client. I messaggi in genere contengono più oggetti, esempio testo e allegati. Il MIME è quello che me li fa vedere. Devo anche stabilire un marcatore per dividere un tipo di oggetto da un altro, eg. BOUNDARY: "--next part 011397--", quindi dopo questa riga so che c'è un altro oggetto di diverso.\\ Changed lines 266-267 from:
to:
Added line 269:
Changed lines 273-275 from:
*si distribuisce il carico di un server: si danno più indirizzi IP a un singolo nome così che ci sono più computer che lo gestiscono\\
Perchè non è una buona idea avere un registro centrale?\\
Perchè: to:
*si distribuisce il carico di un server: si danno più indirizzi IP a un singolo nome così che ci sono più computer che lo gestiscono
Perchè non è una buona idea avere un registro centrale? Perchè: Changed lines 277-278 from:
*inoltre non è scalabile\\
Il DNS usa un databese distribuito, organizzata con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una chache per mantenere la lista dei nomi\\ to:
*inoltre non è scalabile
Il DNS usa un databese distribuito, organizzata con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una chache per mantenere la lista dei nomi. Changed lines 288-289 from:
*'''TYPE MX''': mi dà l'IP di un mail server associato con nome\\ to:
*'''TYPE MX''': mi dà l'IP di un mail server associato con nome Added line 292:
Changed line 294 from:
to:
[[Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani->Sistemi]]
Added lines 215-239:
IMAP invece mantiene tutti i messaggi sul server e si può accedervi da diversi client. I messaggi in genere contengono più oggetti, esempio testo e allegati. Il MIME è quello che me li fa vedere. Devo anche stabilire un marcatore per dividere un tipo di oggetto da un altro, eg. BOUNDARY: "--next part 011397--", quindi dopo questa riga so che c'è un altro oggetto di diverso.
Poi, noi DATA di una mail, ogni singolo pezzo ha il suo charnet e il suo tipo MIME.
!!!!!DNS
Domain Name System: è basato su architetture client - server ma è un protocollo "fondativo" di internet, un servizo offerto alle applicazioni.
I servizi offerti sono:
*alias di host
*alias dei mal server
*si distribuisce il carico di un server: si danno più indirizzi IP a un singolo nome così che ci sono più computer che lo gestiscono\\
Perchè non è una buona idea avere un registro centrale?\\
Perchè:
*la rete rallenterebbe
*inoltre non è scalabile\\
Il DNS usa un databese distribuito, organizzata con server organizzati gerarchicamente: in pratica se non so una cosa il DNS sa a quale altro server chiedere, magari di livello superiore. Usa inoltre una chache per mantenere la lista dei nomi\\
Nella gerarchia c'è un ROOT DNS, ce ne sono pochi nel mondo e poi ci sono di livello più basso, uno per dominio (.com, .edu, ecc.. =>server top level) e infine quelli locali.\\
Nelle organizzazioni ci possono matenere DNS per indirizzi interni alla rete.\\
I DNS mmantengono una cahce di indirizzi dopo che ne hanno trovati alcuni sconoscuti, la chache ogni tot scade.
Al DNS si possono fare delle richieste:
*'''TYPE A''': dò un nome intero, voglio un IP
*'''TYPE NS''': dò un domnio mi dà l'IP del DNS che sa qualcosa di quel dominio
*'''TYPE CNAME''': nome è l'alias, mi dà indietro il suo nome canonico (eg.www.ibm.com è alias di severeast.backup2.ibm.com)
*'''TYPE MX''': mi dà l'IP di un mail server associato con nome\\
Il formato delle richieste RR (Resource Record) sono del tipo: ''name, value, type, TTL'' e anche le risposte sono così. A seconda del tipo di chiamata il VALUE contine cose diverse.\\
Le QUERY e le REPLY hanno lo stesso formato di messaggio. A una richiesta DNS possono rispondere sia di DNS che ce l'hanno in cache, sia quelli che sono AUTORITHATIVE per quel server, se indico RECURSION voglio raggiungere il server autoritativo di quell'indirizzo, se no lascio decidere al DNS a cui chiedo.
Changed lines 205-214 from:
''Body'': contiene il messaggio in codifica ASCII to:
''Body'': contiene il messaggio in codifica ASCII\\
Qualora volessi inviare altro oltre al testo dovrei servirmi dei tipi '''MIME''' che codificheranno il messaggio.\\
Content-transfer-encoding : base 64 => codifica in base 64\\
Content-type : image/jpg => questi sono definiti dalla versione del MIME (solitamente versione 1.0)\\
SMTP viene usato anche tra server e server per l'invio effettivo di mail. ''NON'' c'è bisogno di autenticazioni
!!!!POP3
Diversamente dall'SMTP per ricevere la posta ha bisogno dell'autenticazione con username e pass. Si possono listare i messaggi, che vengono identificati con un numero, e poi cancellati dal server, e non posso più rileggere i messaggi se accedo a un altro client.
Changed line 153 from:
to:
Changed line 186 from:
[+Sample SMTP interaction+]\\ to:
[+Sample SMTP interaction+]\\\ Changed line 202 from:
to:
Changed line 186 from:
[+Sample SMTP interaction+] to:
[+Sample SMTP interaction+]\\ Changed line 202 from:
to:
Added lines 186-205:
[+Sample SMTP interaction+]
Il client si presenta con il comando HELO\\
client: MAIL FROM <address@server.extension>\\
server: 250 server ok\\
client: RCPT TO <....@....>\\
server: recipient ok\\
client: DATA\\
server: 354 Enter mail\\
client: ...inizio email....\\
Le email sono terminate da un punto messo in una riga da solo. La connessione viene aperta e chiusa alla fine del messaggio, si può fare da telnet sulla porta 25.\\
Alla fine si saluta scrivendo QUIT.\\\
Riassumendo i comandi principali di un messaggio in SMTP sono: '''HELO,MAIL FROM, RCPT TO, DATA, QUIT'''
[+RFL 822+]
E' lo standard per i messaggi di testo che sono composti da un header e da un body.\\
''Header'': to, from, subjet => comandi differenti da quelli di SMTP\\
''Body'': contiene il messaggio in codifica ASCII
Changed line 179 from:
#Invio un messaggio con un User agent to:
#Scrivo un messaggio con un User agent Changed lines 182-183 from:
to:
#SMTP client manda il messaggio attraverso una connessione TCP
#Il mail server del destinatario mette il messaggio nella casella di posta destinata
#Per leggere il messaggio invoco lo User agent
Added lines 165-183:
!!!!!Posta elettronica
Tre sono le componenti principali:
#user agent
#mail server
#SMTP simple mail transfer protocol
E tre sono le fasi:
#handshaking
#transfer
#closure
Il messaggio viene passato in codifica ASCII\\
Passaggi:
#Invio un messaggio con un User agent
#Lo mando al mio mail server, esso viene messo in una coda
#Il lato client dell'SMTP apre una connessione TCP con il server mail del destinatario
#Viene inviato
Changed lines 140-142 from:
to:
!!!!!Proxy server
Per migliorare l'efficienza della rete è meglio ridurre il numero di richieste perciò uso un proxy che mantiene nella memoria locale le informazioni richieste così che è lui a darle al cliente, non il server, così non si sovraccarica. Il proxy deve controllare se un oggetto è aggiornato. Ecco a cosa serve la richiesta dello head che il proxy usa per aggiornare la chache.
'''Attenzione!'''questo lavoro di aggiornamento non lo fa ogni volta altrimenti il risparmio è relativo.
Per sapere se un oggetto è aggiornato o no ecco che il server risponde 304 se non è modificato oppure se lo è dice la data.
!!!!!FTP
File Transfer Protocol. Aperto sulla porta 21, apre due connessioni: una per il controllo e una per il trasferimento dati.
Problemi:
* è basato su due connessioni, perciò non basta telnet per usarlo
* la codifica dei caratteri va gestita perchè può essere che server e client usino codifiche diverse.
E' persistente perciò la connessione viene tenuta aperta e si mantiene una sessione. Per autenticarsi occorre mandare username e password.
[+FTP commands+]
*manda un testo ASCII
*chiede USER e PASS
*LIST ritorna una lista di file nella directory corrente
*RETR filename retrievers (gets) file
*STOR filename stores (puts) file onto remote host
[+FTP codici+]
*331 user ok, pass requied
*125 data connection already open, transfer starting
*425 can't open data connection
*452 error writing file
Changed lines 131-133 from:
to:
!!!!!Implementare stati HTTP
Vengono usati i '''Cookies'''\\
Eg. ho un sito che vende roba e voglio mantenere un carrello della spesa per un utente, ma so che HTTP non ha memoria perciò uso i cookies. Essi possono servire quindi per:
* autorizzazioni
* shopping carts
* raccomandazioni
* sessioni aperte (eg web mail)
Se serve un cookie quando il server risponde nell'header invierà eg: ''"Set-cookie:1678"'' e il client deve mantenere quel cookie, perciò poi quando il client invierà successive richieste manderà anche: ''"cookie: 1678"'' così il server sa chi sono. I cookie creano però problemi di privacy.
Changed line 113 from:
%center%%green% "HTTP/1.1 200 OK <CR><LF>"%green%\\ to:
%center%%green% "HTTP/1.1 200 OK <CR><LF>"%none%\\
Changed line 113 from:
%center%%green% "HTTP/1.1 200 OK <CR><LF>"\\ to:
%center%%green% "HTTP/1.1 200 OK <CR><LF>"%green%\\
Changed line 91 from:
La ''request line'' è così formata: '''GET, POST, HEAD commands''' => %green%"GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)%none%\\ to:
La ''request line'' è così formata: '''GET, POST, HEAD commands''' => %green%"GET/somedir/page.html HTTP/1.1"%none% (per far sapere al server se ho persistenza o no)\\ Changed line 113 from:
%center green% "HTTP/1.1 200 OK <CR><LF>"\\ to:
%center%%green% "HTTP/1.1 200 OK <CR><LF>"\\
Changed line 91 from:
La ''request line'' è così formata: '''GET, POST, HEAD commands''' => %green%"GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)\\ to:
La ''request line'' è così formata: '''GET, POST, HEAD commands''' => %green%"GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)%none%\\
Changed line 91 from:
La ''request line'' è così formata: '''GET, POST, HEAD commands''' => "GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)\\ to:
La ''request line'' è così formata: '''GET, POST, HEAD commands''' => %green%"GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)\\ Changed line 113 from:
%center% "HTTP/1.1 200 OK <CR><LF>"\\ to:
%center green% "HTTP/1.1 200 OK <CR><LF>"\\
Changed line 100 from:
to:
Changed line 100 from:
to:
Changed line 100 from:
to:
Changed line 112 from:
C'è uno status line così fatto: to:
C'è uno ''Status line'' così fatto: Changed lines 120-125 from:
La prima cifra mi definisce la categoria del messaggio. Per conoscere il signficato dei vari messaggi si può fare richiesta con un telnet. to:
La prima cifra mi definisce la categoria del messaggio. Per conoscere il signficato dei vari messaggi si può fare richiesta con un telnet.\\
''Header'':
*'''Connection''' : close
*'''Date''' : Thu,6 august ecc..
*'''Sever''' : Apache/1.3.0(Unix)
*'''Last modified''' : <data>
*'''Content length''' : 6821
*'''Content type''' : text/html (sono i tipi MIME)
Changed lines 114-118 from:
I messaggi hanno codici di tre cifre come si può vedere to:
I messaggi hanno codici di tre cifre come si può vedere,questi codici sono ad esempio:
* 200 - OK
* 301 - Moved permanentely
* 400 - Bad request
* 404 - Page not found
* 505 - HTTP version not supported\\
La prima cifra mi definisce la categoria del messaggio. Per conoscere il signficato dei vari messaggi si può fare richiesta con un telnet.
Changed line 100 from:
to:
Changed lines 111-112 from:
to:
[+HTTP RESPONSE MESSAGE+]\\\
C'è uno status line così fatto:
%center% "HTTP/1.1 200 OK <CR><LF>"\\
I messaggi hanno codici di tre cifre come si può vedere
Changed line 105 from:
to:
Changed line 106 from:
Aggiunge due nuovi metodi:\\ to:
Aggiunge due nuovi metodi:
Changed lines 98-101 from:
Alla fine dell'header c'è un ''<CR>'' (Carrige Return) e un ''<LF>'' (Line Feed) che indicano la fine del messaggio. Poi c'è il ''Body'' to:
Alla fine dell'header c'è un ''<CR>'' (Carrige Return) e un ''<LF>'' (Line Feed) che indicano la fine del messaggio. Poi c'è il ''Body'' con cui si può inviare roba al server.
!!!!!Metodi
{+HTTP 1.0+}
* Get
* Post = che serve per mandare roba al server (anche se adesso tanti server mandano le variabili direttamente nell'URI, vantaggio per il copia e incolla, ad esempio i file di youtube con il ?=, svantaggio è che sono in chiaro)
* Head = non chiedo tutto l'oggetto ma solo l'intestazione (eg. per conoscere quando è stato aggiornato l'oggetto
{+HTTP 1.1+}
Aggiunge due nuovi metodi:\\
* Put = per l'upload dei file
* Delete = per cancellare file dal server
Changed line 92 from:
L' ''header line'' è così formata:\\ to:
L' ''Header line'' è così formata:\\ Changed lines 96-99 from:
*'''Accept-language''' : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo to:
*'''Accept-language''' : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo)\\\
Alla fine dell'header c'è un ''<CR>'' (Carrige Return) e un ''<LF>'' (Line Feed) che indicano la fine del messaggio. Poi c'è il ''Body''
Changed line 92 from:
L'''header line'' è così formata:\\ to:
L' ''header line'' è così formata:\\
Changed lines 93-99 from:
'''Host''' : www.someschool.edu
'''Accept-language''' : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo to:
*'''Host''' : www.someschool.edu\\
*'''User-agent''' : Mozilla/4.0\\
*'''Connection''' : Close (indico che voglio chiudere la connessione)\\
*'''Accept-language''' : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo
Changed lines 93-95 from:
'''Host''' : www.someschool.edu\\
'''User-agent''' : Mozilla/4.0\\
'''Connection''' : Close (indico che voglio chiudere la connessione)\\ to:
'''Host''' : www.someschool.edu
'''User-agent''' : Mozilla/4.0
'''Connection''' : Close (indico che voglio chiudere la connessione)
Changed lines 93-99 from:
'''Host''': www.someschool.edu\\
'''User-agent''': Mozilla/4.0\\
'''Connection''': Close (indico che voglio chiudere la connessione)\\
'''Accept-language''': Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo to:
'''Host''' : www.someschool.edu\\
'''User-agent''' : Mozilla/4.0\\
'''Connection''' : Close (indico che voglio chiudere la connessione)\\
'''Accept-language''' : Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo
Changed lines 93-99 from:
%center%Host: www.someschool.edu\\
%center%User-agent: Mozilla/4.0\\
%center%Connection: Close (indico che voglio chiudere la connessione)\\
%center%Accept-language: Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo
to:
'''Host''': www.someschool.edu\\
'''User-agent''': Mozilla/4.0\\
'''Connection''': Close (indico che voglio chiudere la connessione)\\
'''Accept-language''': Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo
Changed line 92 from:
L'''header line'' è così formata:\\ to:
L'''header line'' è così formata:\\
Changed lines 92-94 from:
L'''header line'' è così formata: %center%Host: www.someschool.edu
to:
L'''header line'' è così formata:\\
%center%Host: www.someschool.edu\\
%center%User-agent: Mozilla/4.0\\
%center%Connection: Close (indico che voglio chiudere la connessione)\\
Changed lines 88-90 from:
[+HTTP REQUEST MESSAGE+]\\
E' in ASCII.\\\ to:
[+HTTP REQUEST MESSAGE+]\\\
E' in ASCII.\\
Changed line 90 from:
to:
Changed lines 88-89 from:
to:
[+HTTP REQUEST MESSAGE+]\\
Changed lines 70-73 from:
E' un protocollo senza stati cioè la connessione è ogni volta aperta e chiusa, il server non tiene memoria delle richieste precedenti perciò se non mi arriva un oggetto devo ripetere la mia richiesta. ''Problema'': quanto tempo ci metto? Contando che per ogni oggetto invio una sola richiesta e ottengo ogni volta risposta,%green% totale = ''' 2RTT+transmit time''' to:
E' un protocollo senza stati cioè la connessione è ogni volta aperta e chiusa, il server non tiene memoria delle richieste precedenti perciò se non mi arriva un oggetto devo ripetere la mia richiesta. Ma questa semplicità eccessiva non permette di gestire la persistenza della connessione. Si è passati perciò alla versione 1.0 con il vantaggio che mando più oggetti con una singola connessione e risparmio banda.\\
'''Attenzione!''' Tenere al connessione aperta non significa che ha gli stati.\\
HTTP message:
* client apre una connessione TCP con un host su una certa porta
* server risponde
* client invia REQUEST MESSAGE per un oggetto
* server invia RESPONSE MESSAGE e chiude la connessione
* se però il client aprendo la pagina vede che contiene 10 oggetti richiede le 10 immagini in sequenza e ricomincia daccapo
Quant'è perciò il tempo di risposta? C'è un RTT per aprire la connessione, un RTT per la richiesta HTTP e i primi bytes delal risposta, infine il tempo di trasmissione dei file.
%center green% TOTALE = 2RTT + tempo di trasmissione per ogni oggetto\\
Ecco perchè c'è la necessità di HTTP persistente. Ci sono due implementazioni di persistenza:
* una si limita a NON chiudere la connessione dopo l'invio di un oggetto
* una è detta PIPELING: il client manda richiesta per ogni oggetto che trova, senza aspettare di aver ricevuto gli oggetti trovati prima, il server crea una ''pipeline'' e glieli manda tutti insieme.
Ho due messaggi HTTP: REQUEST e RESPONSE
[+HTTP REQUEST MESSAGE+]
E' in ASCII.\\
La ''request line'' è così formata: '''GET, POST, HEAD commands''' => "GET/somedir/page.html HTTP/1.1" (per far sapere al server se ho persistenza o no)\\
L'''header line'' è così formata: %center%Host: www.someschool.edu
%center%User-agent: Mozilla/4.0
%center%Connection: Close (indico che voglio chiudere la connessione)
%center%Accept-language: Fr (se il server gestisce più versioni dello stesso oggetto in base alla lingua, posso richiederlo
Changed lines 70-73 from:
E' un protocollo senza stati cioè la connessione è ogni volta aperta e chiusa, il server non tiene memoria delle richieste precedenti perciò se non mi arriva un oggetto devo ripetere la mia richiesta. ''Problema'': quanto tempo ci metto? Contando che per ogni oggetto invio una sola richiesta e ottengo ogni volta risposta, totale = '''%green% 2RTT+transmit time'''\\ to:
E' un protocollo senza stati cioè la connessione è ogni volta aperta e chiusa, il server non tiene memoria delle richieste precedenti perciò se non mi arriva un oggetto devo ripetere la mia richiesta. ''Problema'': quanto tempo ci metto? Contando che per ogni oggetto invio una sola richiesta e ottengo ogni volta risposta,%green% totale = ''' 2RTT+transmit time'''\\
Changed line 65 from:
'''HTTP'''->Hyper Test Transfer Protocol\\
to:
[+HTTP+]->Hyper Test Transfer Protocol\\ Changed lines 68-72 from:
Esso si basa su TCP: il client richiede dati aprendo una connessione TCP al server sulla porta 80-> quando ho ottenuto le informazioni che mi servono, la connessione si chiude.\\
E' semplice da gestire, sia lato client che lato server, e questa è stata la base del successo iniziale del web. to:
Esso si basa su TCP: il client richiede dati aprendo una connessione TCP al server sulla porta 80-> quando ho ottenuto le informazioni che mi servono, la connessione si chiude. Per ogni oggetto invio una richiesta.\\
E' semplice da gestire, sia lato client che lato server, e questa è stata la base del successo iniziale del web.\\
E' un protocollo senza stati cioè la connessione è ogni volta aperta e chiusa, il server non tiene memoria delle richieste precedenti perciò se non mi arriva un oggetto devo ripetere la mia richiesta. ''Problema'': quanto tempo ci metto? Contando che per ogni oggetto invio una sola richiesta e ottengo ogni volta risposta, totale = '''%green% 2RTT+transmit time'''\\
Changed lines 56-57 from:
to:
!!!!!WEB & HTTP
Le pagine web come tutti sappiamo sono composte da un gran numero di oggetti: un file html di base che contiene riferimenti ad altri oggetti: immagini jpg, applet java ecc... Ogni oggetto è indirizzabile con un URL: eg. "www.someschool.edu/someDept/pic.gif" identificherà il nome di un'immagine.\\
Attenzione! Ci sono delle differenze quando di parla di URL, URI e URN!\\
*URL = universal resource locator: identifica la risorsa in modo globale attraverso la ''locazione'' della risorsa stessa (su che server è)
*URI = universal resource identifier: identifica la risorsa indipendentemente da dove si trova o dal nome con il quale è nota
*URN = universal resource name: identifica la risorsa attraverso il ''nome'' anche se l'oggetto stesso non è reperibile (eg. voglio dare un nome alla documentazione di un software all'interno della mia rete aziendale)\\
Una URI può essere rappresentata in forma di URL, URN o una combinazione di entrambi.
'''HTTP'''->Hyper Test Transfer Protocol\\
Applicazione Web. Il client invia una richiesta di un oggetto, identificato con un URI, il server se ce l'ha lo invia, altrimenti risponde con un errore, semplice vero?\\
Esistono due versioni diverse: la 1.0 e la 1.1 (come GDA d'altronde)\\
Esso si basa su TCP: il client richiede dati aprendo una connessione TCP al server sulla porta 80-> quando ho ottenuto le informazioni che mi servono, la connessione si chiude.\\
E' semplice da gestire, sia lato client che lato server, e questa è stata la base del successo iniziale del web.
Changed line 48 from:
(:cellnr bgcolor=#f5f9fc valign=middle:)eNO timing to:
(:cellnr bgcolor=#f5f9fc valign=middle:)NO timing Added lines 54-57:
Ma se UDP non fa un cavolo, a cosa mi serve? E' un protocollo più leggero.
Changed line 48 from:
(:cellnr bgcolor=#f5f9fc valign=middle:)NO timing to:
(:cellnr bgcolor=#f5f9fc valign=middle:)eNO timing Changed lines 50-51 from:
to:
(:cellnr valign=middl:)NO banda minima
(:cell valign=middle:)NO banda minima
Changed lines 42-43 from:
(:cellnr:)connessione
(:cell:)NO connessione to:
(:cellnr valign=middle:)connessione
(:cell valign=middle:)NO connessione Changed lines 48-49 from:
(:cellnr bgcolor=#f5f9fc valign=middle:)
to:
(:cellnr bgcolor=#f5f9fc valign=middle:)NO timing
(:cell bgcolor=#f5f9fc valign=middle:)NO timing
Changed lines 40-43 from:
(:cellnr bgcolor=#d9e4f2 colspan=2 align=center:)'''TCP'''
(:cell bgcolor=#d9e4f2 colspan=2 align=center:)'''UDP'''
(:cellnr align=center:)connessione
(:cell align=center:)NO connessione to:
(:cellnr bgcolor=#d9e4f2 colspan=2:)'''TCP'''
(:cell bgcolor=#d9e4f2 colspan=2:)'''UDP'''
(:cellnr:)connessione
(:cell:)NO connessione
Changed lines 42-43 from:
(:cellnr:)connessione
(:cell:)no connessione to:
(:cellnr align=center:)connessione
(:cell align=center:)NO connessione
(:cellnr bgcolor=#f5f9fc valign=middle:)controllo flusso
(:cell bgcolor=#f5f9fc valign=middle:)NO controllo flusso
(:cellnr valign=middle:)controllo congestione
(:cell valign=middle:)NO congestion control Deleted lines 48-51:
(:cell bgcolor=#f5f9fc valign=middle:)
(:cellnr valign=middle:)
(:cell valign=middle:)
(:cellnr bgcolor=#f5f9fc valign=middle:)
Changed lines 40-43 from:
(:cellnr bgcolor=#d9e4f2 colspan=2 align=center:)
(:cell:) to:
(:cellnr bgcolor=#d9e4f2 colspan=2 align=center:)'''TCP'''
(:cell bgcolor=#d9e4f2 colspan=2 align=center:)'''UDP'''
(:cellnr:)connessione
(:cell:)no connessione
Added lines 39-51:
(:table border=0 width=55% cellpadding=5 cellspacing=0:)
(:cellnr bgcolor=#d9e4f2 colspan=2 align=center:)
(:cell bgcolor=#d9e4f2 colspan=2 align=center:)
(:cellnr:)
(:cell:)
(:cellnr bgcolor=#f5f9fc valign=middle:)
(:cell bgcolor=#f5f9fc valign=middle:)
(:cellnr valign=middle:)
(:cell valign=middle:)
(:cellnr bgcolor=#f5f9fc valign=middle:)
(:cell bgcolor=#f5f9fc valign=middle:)
(:tableend:)
Changed lines 3-6 from:
!!!A lezione con Ceravolo!(ovvero Protocolli applicativi - Application Layer)
to:
%titolo%'''::A lezione con Ceravolo!(ovvero Protocolli applicativi - Application Layer)::'''
Changed lines 17-18 from:
#'''P2P''' = ogni host chiede e passa informazioni ad altri host che possono esserci o non esserci, sono connessi in modo intermittente. Proprio qui sta il problema: le informazioni devono essere "garantite" a prescindere da quali host sono connessi. Sono rare le P2P pure, di solito sono ibride, l'unico è Gnutella è scalabile cioè funziona con pochi utenti che con tanti. to:
#'''P2P''' = ogni host chiede e passa informazioni ad altri host che possono esserci o non esserci, sono connessi in modo intermittente. Proprio qui sta il problema: le informazioni devono essere "garantite" a prescindere da quali host sono connessi. Sono rare le P2P pure, di solito sono ibride, l'unico è Gnutella che è scalabile cioè funziona con pochi utenti che con tanti.
#'''Ibride''' = ci sono dei ''supernodi'' che smistano gli host collegati. Esempi di ibridi sono Napster (file transfer P2P) o IM (istant messaging) in cui comunico ad un server la mia esistenza e quando sono registrata trova tutti gli indirizzi collegati al mio buddy (penso intenda profilo...)
!!!!!Comunicazioni fra processi
Un processo è un qualunque programma che funziona su un host, sia lato client che lato server. Il sistema operativo gestisce i processi e la IPC (Inter Process Communication). Come collegare tra loro processi diversi? tramite la nozione di '''porta'''. Una porta è un concetto astratto per stabilire che il processo X, che sarà interrotto da altri processi, possa comunicare con il processo Y, il quale parimenti sarà interrotto e così via.\\
Per gestire la comunicazione dei processi fra host diversi uso i ''socket''. A cosa mi servono le porte allora? Non posso tener conto solo del fatto che ogni host ha un indirizzo IP unico perchè processi diversi possono essere inviati allo stesso host, perciò devo associare un numero di porta (eg il numero di porta di internet solitamente è 80).
!!!!!Che cosa definisce un protocollo applicativo?
* Formato dei messaggi
* Ordine della comunicazione
* Azioni da intraprendere a seconda di ciò che riceve\\
Solitamente il protocollo definisce espressamente le prime due cose, la terza è implicita
!!!!!Che tipi di servizio richiede un'applicazione distribuita?
In base a ciò che un'applicazione richiede infatti si caratterizza il protocollo
#''Perdita dei dati'': è tollerata o no?
#''Tempistica'': i pacchetti devono arrivare entro un certo tempo?
#''Banda'': quanta banda minima mi serve?\\
Eg: per il trasferimento dei file non dovrò avere perdita di dati, poco tempo di attesa e una banda elastica in base alla quantità di dati da trasferire.
!!!!!Livello di trasporto {+TCP vs UDP+}
Changed line 20 from:
to:
Added lines 1-20:
(:title Lezioni con Ceravolo:)
!!!A lezione con Ceravolo!(ovvero Protocolli applicativi - Application Layer)
!!!!!Cosa sono?
Sono applicazioni distribuite, ovvero eseguiti su una macchina locale ma che interagiscono con una macchina altrove sulla rete. Esempi di questi protocolli sono: server Email su internet, Msn, Emule, VoIp ecc...
!!!!!Nozioni preliminari
Ci sono tipi diversi di applicazioni distribuite:
# '''Client-sever''' = c'è un client, presente in modo discontinuo sulla rete che richiede man mano informazioni al server che invece è sempre presente. I client per contro non possono comunicare direttamente l'uno con l'altro ma solo tramite server. '''''IL SERVER é SCALABILE??(ndP)'''''
#'''P2P''' = ogni host chiede e passa informazioni ad altri host che possono esserci o non esserci, sono connessi in modo intermittente. Proprio qui sta il problema: le informazioni devono essere "garantite" a prescindere da quali host sono connessi. Sono rare le P2P pure, di solito sono ibride, l'unico è Gnutella è scalabile cioè funziona con pochi utenti che con tanti.
----
[[!Sistemi]]
|
|
