Domande Architettura Internet

Http

Il protocollo a livello di applicazione usato nel web è http. Esso è un protocollo che si basa su TCP/IP. Questo protocollo è implementato in due programmi, client e server, in esecuzione su sistemi periferici diversi che comunicano fra di loro scambiandosi messaggi http. Un browser web implementa il lato client, un web server il lato server.

Http utilizza tcp dove il client tcp per prima cosa inizializza una connessione col server, una volta inizializzata i processi client e server accedono a tcp mediante le proprie socket. Il server http non memorizza alcuna informazione di stato a proposito del client, per questo è classificato come protocollo senza memoria di stato (STATELESS PROTOCOL).

Connessioni persistenti e non persistenti

In http ci sono connessioni persistenti e connessioni non persistenti. HTTP con connessioni non persistenti funziona nel seguente modo: il client apre una connessione TCP verso il server sulla porta 80; il client, tramite la propria socket, invia un messaggio di richiesta http al server; il server riceve il messaggio attraverso la socket, a questo punto recupera l’oggetto, lo incapsula in un messaggio di risposta http e lo invia al client tramite la propria socket. Successivamente, il server comunica di chiudere la connessione TCP, ma quest’ultima verrà chiusa quando il client ha ricevuto l’intero messaggio. Quindi, il client riceve il messaggio e la connessione può terminare. Il messaggio conterrà un file HTML che mostrerà l’oggetto richiesto dal client. Il tempo di risposta totale è di 2 RTT, che rappresenta il tempo impiegato da un piccolo pacchetto per viaggiare dal client server per poi ritornare al client.

Invece, http con connessioni persistenti funziona in tutt’altro modo: esso, infatti, opera sulla stessa connessione. Il client e il server possono comunicare sulla stessa connessione. Inoltre, qui può avvenire il fenomeno del pipelining, ovvero le richieste di messaggi possono essere inoltrate una di seguito all’altra, senza aspettare le rispettive risposte. Il server chiuderà la connessione quando questa rimane inattiva per un dato periodo di tempo.

Messaggi HTTP

I messaggi http si dividono in messaggi di richiesta e messaggi di risposta. I messaggi di richiesta http sono formati da una riga iniziale di richiesta e da successive righe dette righe di intestazione; la riga di richiesta è composta dal campo metodo, dal campo URL e dal campo versione di http. Il campo metodo può avere diversi valori, ad esempio GET, usato per recuperare dati dal server, POST, PUT, DELETE. Nelle righe di intestazione troviamo l’host su cui risiede l’oggetto, connection il browser sta comunicando al server che non si deve occupare di connessione persistente e chiudere la connessione una volta inviato l’oggetto, User-agent specifica il browser che effettua la richiesta, infine la lingua che preferirebbe ricevere l’utente se non disponibile verrà inviata quella di default.

Invece, i messaggi di risposta sono composti da una riga di stato iniziale, dalle righe di intestazione e da un corpo. Nella riga di stato presenta tre campi: la versione del protocollo, un codice di stato e un corrispettivo messaggio di stato. Nelle righe di intestazione troviamo, connessione, la riga data, la riga server, la riga ultima modifica, la riga content-length, la riga content-type. Nel corpo troveremo l’oggetto richiesto.

Proxy server o web caching

Proxy server o Web Caching è un’entità di rete che soddisfa richieste http al posto del web server effettivo utilizzato per ridurre in modo sostanziale i tempi di risposta alle richieste dei client e per ridurre il traffico sul collegamento di accesso a internet senza aumentare l’ampiezza di banda e riducendo i costi. Il proxy ha una propria memoria su disco in cui conserva copie di oggetti recentemente richiesti. Il browser utente può essere configurato in modo che tutte le richieste http utente vengano dirette verso il proxy server. Il browser stabilisce una connessione TCP con il proxy server e invia una richiesta http per l’oggetto specificato. Il proxy controlla la presenza di una copia dell’oggetto memorizzata localmente, se l’oggetto viene rilevato il proxy lo inoltra all’interno di un messaggio di risposta http al browser. Se invece non lo rileva, apre una connessione TCP verso il server di origine, poi il proxy invia al server una richiesta http per l’oggetto. Una volta ricevuta tale richiesta, il server di origine invia al proxy l’oggetto all’interno di una risposta http e quando il proxy riceve l’oggetto ne salva una copia nella propria memoria locale e ne inoltra un’altra copia all’interno di un messaggio http al browser tramite la connessione TCP. Questo meccanismo viene chiamato GET CONDIZIONALE. Possiamo dunque dedurre che il proxy è contemporaneamente client e server.

Posta elettronica

Tre componenti hanno a che fare con le funzioni di una e-mail: user agent, i server di posta e il protocollo SMTP. SMTP: Questo protocollo costituisce il cuore della posta elettronica su Internet. Utilizza il protocollo di trasporto TCP. SMTP presenta un lato client in esecuzione sul mail server del mittente e un lato server in esecuzione sul server del destinatario. Quando un server invia posta a un altro agisce come client SMTP, quando lo riceve come server SMTP.

Lo svolgimento di un invio di una e-mail è il seguente: proprio user agent compone il messaggio e fornisce l’indirizzo di posta del destinatario e dà istruzioni allo user agent di inviarlo -> lo user agente mittente lo invia al proprio mail server dove è collocato in una coda di messaggi -> il lato client SMTP eseguito sul mail server del mittente vede il messaggio, apre una connessione tcp verso il server smtp in esecuzione sul mail server del destinatario -> Dopo un handshaking smtp, il client smtp invia il messaggio sulla connessione tcp -> presso il mail server del destinatario il lato server smtp riceve il messaggio che lo posiziona nella casella del destinatario -> quando il destinatario aprirà il proprio user agent leggerà il messaggio. SMTP non usa mail server intermedi ma comunica direttamente col mail server, dove se è spento quello del destinatario attenderà nel mail server del mittente per un nuovo invio. SMTP fa uso di connessioni persistenti, se il mail server di invio ha molti messaggi da inviare allo stesso mail server in ricezione, può mandarli tutti sulla stessa connessione TCP.

Confronto con HTTP

I due protocolli vengono utilizzati per trasferire file da un host a un altro. L' http trasferisce file da un web server a un web client. Invece l’SMTP trasferisce file da un mail server a un altro. È un protocollo push cioè il mail server di invio spinge i file al mail server in ricezione, mentre HTTP è un protocollo pull, quando qualcuno carica informazioni sul web server gli utenti usano http per tirarle a sé. SMTP ha un vincolo di un ASCII a 7 bit mentre http no. Per trasferire i messaggi dal mail server del destinatario al pc del destinatario si usano i protocolli di accesso alla posta.

Protocolli di accesso alla posta

Tutto si basa al SMTP che è usato per trasferire posta dal server del mittente a quello del destinatario. Per fare ciò viene usato il protocollo di accesso alla posta POP3. POP3: è un protocollo estremamente semplice. Entra in azione quando lo user agent apre una connessione TCP verso il mail server sulla porta 110. Quando la connessione TCP è stabilita, POP3 procede in tre fasi: autorizzazione, transazione e aggiornamento. Durante la prima fase lo user agent invia nome utente e password per autenticare l’utente. Durante la seconda fase lo user agent recupera i messaggi e può marcare i messaggi per la cancellazione. La fase di aggiornamento ha luogo dopo che il client ha inviato il comando quit, che conclude la sessione POP3, nello stesso momento il server di posta rimuove i messaggi che sono stati marcati per la cancellazione.

IMAP: Un server IMAP associa ogni messaggio arrivato al server alla cartella INBOX del destinatario. Il protocollo IMAP fornisce comandi per consentire agli utenti di creare cartelle e spostare i messaggi da una cartella a un’altra. A differenza di POP3, i server IMAP conservano informazioni di stato sull’utente da una sessione all’altra. Un’altra caratteristica importante di IMAP è la presenza di comandi che permettono agli user agent di ottenere singole parti dei messaggi.

DNS

DNS: viene comunemente utilizzato da altri protocolli a livello di applicazione, tra cui HTTP e SMTP, per tradurre i nomi di host forniti dall’utente in indirizzi IP. Ecco come lavora il DNS quando un browser in esecuzione sull'host richiede un URL. L’host dell’utente deve inviare un messaggio di richiesta HTTP al web server in questo modo:

• L’host utente esegue il lato client dell’applicazione DNS.
• Il browser estrae il nome dell’host dall’URL e lo passa al lato client dell’applicazione DNS.
• Il client DNS invia una interrogazione contenente l’hostname a un DNS server.
• Il client DNS prima o poi riceve una risposta, che include l’indirizzo IP corrispondente all’hostname.
• Dopo aver ricevuto l’indirizzo IP dal DNS, il browser può dare inizio a una connessione TCP verso il processo server HTTP collegato alla porta 80 di quell’indirizzo IP.

Altri servizi

Altri servizi sono l’host aliasing, Mail server aliasing, ma soprattutto load distribution, per distribuire il carico tra server replicati.

DNS caching

In una concatenazione di richieste, il DNS server che riceve una risposta DNS, può mettere in cache le informazioni ricevute. Ma dato che gli host e le associazioni tra nome e indirizzo IP non sono in alcun modo permanenti, i DNS server invalidano le informazioni in cache ogni 2 giorni. Un DNS server locale può anche memorizzare in cache gli indirizzi IP dei TLD server, consentendogli di aggirare i root server nella catena di richieste.

Messaggi DNS

La sua semantica si basa: nei primi 12 byte rappresentano la sezione di intestazione, che a sua volta è composta da: Identificazione, flag, numero di domande, numero di RR di domande, numero di RR di risposta, numero di RR autoritativi, numero di RR addizionali. Poi vi è una parte composta da: sezione delle domande, sezione delle risposte, sezione autoritativa e sezione aggiuntiva.

UDP

UDP è un protocollo di trasporto leggero dotato di un servizio minimalista. UDP è senza connessione, non necessita handshaking e fornisce un servizio di trasferimento dati non affidabile, così quando un processo invia un messaggio tramite la socket UDP il protocollo non garantisce il raggiungimento della destinazione. UDP prende i messaggi dal processo applicativo, aggiunge il numero di porta di origine e di destinazione per il multiplexing/demultiplexing e passa il segmento risultante al livello di rete. Questo incapsula il segmento in un datagramma IP e quindi effettua un tentativo di consegna all’host di destinazione in modalità best-effort. Se il segmento arriva a destinazione UDP utilizza il numero di porta di destinazione per consegnare i dati del segmento al processo applicativo corretto.

Struttura del segmento UDP

La struttura del segmento UDP si divide in Header suddiviso in 4 parti cioè:

• Intestazione: contiene i numeri di porta di origine 16bit e di destinazione 16bit;
• Lunghezza: campo di 16 bit, specifica il numero di byte del segmento UDP;
• Checksum: campo di 16 bit, usato per vedere se ci sono errori nel segmento;
• Payload: contente i Dati dell’applicazione.

Il checksum UDP serve per determinare se i bit del segmento UDP sono stati alterati durante il loro trasferimento da sorgente a destinazione. Lato mittente UDP effettua il complemento a 1 della somma di tutte le parole da 16 bit nel segmento, e l’eventuale riporto finale viene sommato al primo bit. In ricezione, si sommano le tre parole iniziali con il checksum, se non ci sono errori nel pacchetto, il risultato dell’addizione sarà 1111111111111111, altrimenti se un bit vale 0 c’è stato almeno un errore. Si usa perché non c’è garanzia che tutti i collegamenti tra origine e destinazione controllino gli errori, inoltre si potrebbe verificare un errore mentre il segmento si trova nella memoria di un router.

Dato che non sono garantiti né l’affidabilità del singolo collegamento né il rilevamento di errori in memoria, UDP deve mettere a disposizione a livello di trasporto un meccanismo di verifica su base end to end se si vuole che il servizio trasferimento dati sia in grado di rilevare eventuali errori.

Multiplexing e demultiplexing

Nell’host destinatario il livello di trasporto riceve segmenti dal livello di rete sottostante. Il livello di trasporto ha il compito di consegnare i dati di questi segmenti al processo applicativo appropriato in esecuzione sull’host. Ma, il livello di trasporto nell’host di ricezione, non trasferisce i dati direttamente ad un processo, infatti li manda ad una socket che fa da tramite. Ogni socket avrà un identificatore univoco. Ciascun segmento a livello di trasporto ha vari campi. Lato ricevente, il livello di trasporto esamina questi campi per identificare la socket di ricezione e poi dirige il segmento verso la giusta direzione. Il compito di trasportare i dati a livello di trasporto verso la giusta socket viene detto demultiplexing. Mentre, il compito di radunare frammenti di dati da diverse socket sull’host di origine e incapsulare ognuno con intestazioni a livello di trasporto per creare dei segmenti e passarli a livello di rete, viene detto multiplexing. Quindi, il multiplexing, a livello di trasporto, richiede che le socket abbiano identificatori univoci e che ogni segmento presentano campi che indicano la socket alla quale deve essere indirizzato il segmento. Questi campi sono: campo numero di porta di origine e campo numero di porta di destinazione. I numeri di porta sono di 16 bit e vanno a 0 a 65535, quelli che vanno da 0 a 1023 sono detti numeri di porta noti.

GBN Go-Back-N

GBN (Go-Back-N) In un protocollo GBN il mittente può trasmettere più pacchetti senza dover attendere nessun ACK. Allo stesso tempo non può avere più di N pacchetti in attesa di ACK nella pipeline. La N viene chiamata ampiezza della finestra e, da esso, il protocollo GBN viene detto protocollo a finestra scorrevole. Viene da chiedersi per quale motivo bisogna limitare il numero di pacchetti in sospeso a N: praticamente, il numero di sequenza di un pacchetto viene scritto in un campo a dimensione fissa dell’intestazione del pacchetto.

C’è da dire che il mittente GBN deve rispondere a tre tipi di evento: quando si chiama la funzione rdt_send(), in primis il mittente controlla se la finestra sia piena, quindi se vi sono N pacchetti in sospeso senza acknowledgment. Qualora la finestra non fosse piena, il mittente crea e invia un pacchetto, successivamente le variabili vengono aggiornate. Invece, se la finestra è piena, il mittente restituisce i dati al livello superiore, il quale riproverà successivamente. Il mittente manterrà questo dato in un buffer, oppure implementerà un meccanismo di sincronizzazione che consentirà al livello superiore di invocare rdt_send() solo quando la finestra non sia piena.

Ricezione di un ACK: l’acknowledgment(n) viene considerato un acknowledgment cumulativo che indica che tutti i pacchetti fino ad n sono stati ricevuti dal destinatario. Evento di time-out: per risolvere il problema di pacchetti dati o acknowledgment persi si usa un contatore. Quando si verifica un time-out, il mittente invia di nuovo tutti i pacchetti spediti che ancora non hanno ricevuto un acknowledgment. Se si riceve un ACK, ma ci sono ancora dei pacchetti non riscontrati, il timer viene fatto ripartire.