cap. 2 – o nível aplicação 1ª parte departamento de informática da faculdade de ciências e...

Cap. 2 – O nível aplicação

1ª Parte

Departamento de Informática da Faculdade de Ciências e Tecnologia da

UNL

Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins – Copyright DI - FCT/ UNL – Aplicações Internet / 2

Nota prévia

A estrutura da apresentação é semelhante e utiliza algumas das figuras, textos e outros materiais do livro de base do curso

James F. Kurose and Keith W. Ross, "Computer Networking - A Top-Down Approach Featuring the Internet,“ Addison Wesley Longman, Inc., 3rd Edition, 2005


Objectivos do capítulo

• Perceber como são organizadas e funcionam algumas das aplicações mais comuns

• Perceber o paradigma cliente / servidor e o paradigma P2P (“par a par” ou “peer-to-peer”)

• Conhecer protocolos aplicacionais populares


Organização do capítulo

• Aplicações em rede ou distribuídas

• Conceitos de base, paradigmas e tipos de transportes

• Protocolo HTTP (Web)

• O DNS (“Domain Name System”)

• Protocolo SMTP — Correio electrónico

• Transferência de ficheiros - Protocolo FTP e sistemas P2P

• Os protocolos RTP e SIP


Aplicações distribuídas

application

transportnetworkdata linkphysical

application


application


• Aplicação: processos distribuídos que comunicam através de mensagens

• Executam nos hosts em “user space”

• Comunicam através de protocolos do nível aplicação

• Usam os serviços do nível de transporte da rede

• Protocolos Aplicacionais• Definem as mensagens

trocadas pelas aplicações e a sua semântica

• Não são senão uma parte da aplicação


Alguma terminologia

• A aplicação é formada por um conjunto de processos distribuídos

• Os processos distribuídos comunicam através de um IPC Inter Process Communication Facility de comunicação em rede

• Um IPC também se designa uma API (“Application Programming Interface”) de comunicação

• O IPC é usado para executar um protocolo do nível aplicação

• Um processo interactivo que serve directamente um utilizador diz-se um agente do utilizador (“user agent”)


O paradigma cliente servidor

applicationtransportnetworkdata linkphysical

applicationtransportnetworkdata linkphysical

request

reply


Características de base

• Em geral, o cliente toma a iniciativa de contactar o servidor, enquanto que o servidor espera pelo contacto do cliente

• O cliente solicita serviços ao servidor• Este responde ao pedido• Um servidor que serve um cliente de cada vez diz-se

um servidor iterativo (serializa os pedidos)• Um servidor que serve vários clientes em paralelo

diz-se um servidor concorrente• Ao protocolo base chama-se um protocolo “pedido /

resposta” (“request / reply”)• A sincronização característica é semelhante à da

invocação de um procedimento ou método


Arquitecturas P2P

• Conjuntos de hosts comunicam directamente entre si sem uma estruturação hierárquica

• Os Peers (pares, parceiros, …) nem sempre estão ligados e podem trocar de endereço IP de cada vez que estão ligados

• Muito escalável

• Mas mais difícil de gerir


Sistemas híbridos Cliente / Servidor e P2P

Skype A comunicação da chamada telefónica é de host a host - P2P A pesquisa dos interlocutores é centralizada

Os utilizadores (peers) registam o seu IP no servidor Os peers contactam o servidor para saber o IP do seu parceiro

Correio electrónico As caixas de correio estão em servidores As mensagens são trocadas entre servidores de correio electrónico

de forma horizontal (servidores actuando de forma P2P entre si)

Presença e mensagens instantâneas As aplicações dos utilizadores trocam mensagens directamente -

P2P Localização e detecção da presença centralizada num servidor:

Os utilizadores quando on-line registam o seu endereço num servidor Os utilizadores contactam o servidor central para localizar os seus

amigos








• Transferência de ficheiros - Protocolo FTP e sistemas P2P



Necessidades das aplicações

• Perca de dados• Algumas aplicações toleram perca de dados (som, ...)• Outras necessitam de fiabilidade a 100% (e.g. transferência

de um ficheiro)

• Capacidade de transferência• Algumas aplicações necessitam de uma certa garantia de

capacidade mínima (som, ...)• Outras são “elásticas” e adaptam-se à capacidade

disponível (e.g. transferência de um ficheiro)

• Latência ou tempo de trânsito (“Timing”)• Algumas aplicações necessitam de garantias no que toca à

latência e até à sua variação (Jogos, som interactivo, ...)• Outras toleram grandes variações da latência


Exemplos

Aplicação

file transfere-mail

Documentos Webreal-time audio/video

stored audio/videoJogos interactivos

Aplicações financeiras

Perca de dados ?

não toleranão toleranão toleratolera

toleratoleranão tolera

Capacidade garantida ?

elásticaelásticaelásticaaudio: 5Kb-1Mbvideo:10Kb-6Mbidem > alguns Kbpselástica

Sensível ao tempo ?

nãonãonãosim, 100’s ms

sim, alguns segsim, 100’s mssim e não


Transportes e suas características

• TCP• Orientado conexão (exige conexão prévia)• Transporte fiável de uma sequência de octetos (“bytes”)• Controlo de fluxo• Controlo de saturação• Não dá garantias de banda nem de latência

• UDP• Serviço datagramas sem conexão (não exige conexão

prévia)• Não fiável (“best effort”)• Não tem garantias de banda, latência, controlo de fluxo ou

saturação


Exemplos

Aplicação

e-mailremote terminal access

Web file transfer

streaming multimedia

remote file serverInternet telephony

Protocolo do nívelaplicação

smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959], NFS

Protocolo detransporte

TCPTCPTCPTCPTCP ou UDP

TCP ou UDPtipicamente UDP








• Transferência de ficheiros - Protocolos TFTP, FTP e sistemas P2P



WWW - um serviço de acesso a informação multimédia para a Internet

O Protocolo HTTP e o serviço WWW


Terminologia

• Página Web:• formada por “objectos”• endereçada via um URL

• As páginas Web geralmente são formadas por:• página HTML de base, e• referências para

objectos.

• Um URL tem duas componentes: nome de um host e nome de um objecto local ao servidor:

• O User agent chama-se um browser:• MS Internet Explorer• Netscape Communicator• Opera, …

• Existem vários servidores:• Apache (public domain)• MS Internet Information

Server• …..

asc.di.fct.unl.pt/rc/index.html


Aspectos fundamentais

• Os servidores funcionam como repositórios de informação

• A estruturação da informação baseia-se em “hyperlinks / hypermedia”

• A interface dos browser é intuitiva, generalizada e permite lidar com múltiplos formatos e tipos de recursos

• Os browsers admitem a “navegação” dinâmica através dos “hyperlinks”

• O browser interpreta o conteúdo dos documentos, expandindo dinamicamente os formatos multimedia (texto, som, imagem, …) através de funcionalidades internas ou de programas externos

• Para melhor desempenho, os browsers gerem uma cache local dos últimos documentos que foram acedidos


Forma geral de um URL - Uniform Resource Locator

Os URLs são endereços de recursos WEB

protocolo ou método de acesso://servidor[:porta]/nome-do-objecto

Exemplos de protocolos: HTTP, FTP, TELNET, FILE, MAILTO, …

Servidor: nome DNS do servidor onde reside o objecto

Porta: porta a usar na conexão, pode ser omitida, nesse caso usa-se uma por defeito em função do protocolo


O protocolo HTTP

• HTTP: hypertext transfer protocol

• Protocolo do nível aplicação

• cliente/servidor• cliente: browser

envia pedidos, recebe, interpreta e mostra os objectos

• servidor: o servidor Web envia os objectos em resposta aos pedidos

• http1.0: RFC 1945• http1.1: RFC 2068

PC runningInt Explorer

Server running

Apache Webserver

Mac runningMozilla

http request

http re

quest

http response

http re

sponse


Continuação

• http: usa o transporte TCP:

• O cliente abre uma conexão TCP para a porta 80 do servidor

• O servidor aceita a conexão do cliente

• O servidor e o cliente trocam mensagens HTTP

• A conexão TCP é fechada

• O http é sem estado (“stateless”)

• O servidor não mantêm nenhuma informação sobre as conexões dos clientes

• Os protocolos que mantêm “estado” são mais complexos!

• O estado (“história”) tem de ser mantido

• Se o servidor ou o cliente avariam, o estado pode ficar não coerente e tem de ser re-sincronizado


Como funciona o HTTP

O que se passa quando é solicitado a um browser que aceda a um recurso especificado por um URL, como por exemplo:

http://en.wikipedia.org/wiki/Main_Page ?

1) O browser faz a análise do URL2) Solicita ao DNS o endereço do servidor (en.wikipedia.org)3) O DNS responde com 145.97.39.155 por exemplo4) O browser abre uma conexão TCP para o porto 80 de 145.97.39.1555) Envia então o comando: “GET /wiki/Main_Page HTTP/1.0” seguido de uma linha em branco6) O servidor responde com esse documento7) O browser lê o documento através do canal TCP8) O servidor e o browser fecham a conexão9) O browser começa a interpretação do documento e abre novas conexões para ir buscar as imagens e outros documentos indicados no mesmo


Exemplo

O Utilizador solicita o URL http://en.wikipedia.org/wiki/Main_Page

1a. O cliente HTTP inicia a abertura de uma conexão para en.wikipedia.org na porta 80

2. O cliente HTTP envia a request message (contendo o URL) através do socket TCP. A mensagem indica que o cliente quer o objecto wiki/Main_Page

1b. O servidor HTTP en.wikipedia.org estava à espera de pedidos de conexão na porta 80. “aceita” a conexão e indica isso ao cliente

3. O servidor HTTP recebe a mensagem, forma a response message contendo o objecto e envia-a através do socket

time

(que contém texto e referências para 10 objectos)


Continuação

5. O cliente HTTP cliente recebe a mensagem contendo o objecto, interpreta-o visto ser HTML. Ao fazer a interpretação encontra a referência para 10 objectos

6. Os passos 1 a 5 são repetidos para os 10 objectos

4. O servidor HTTP fecha a conexão TCP.

time


Modelização do tempo de resposta

RTT: tempo de ida e volta de um pequeno pacote entre o cliente e o servidor.

Tempo total de resposta: Um RTT para iniciar a

conexão Sensivelmente mais um

RTT por cada pedido HTTP com alguns bytes da resposta

Tempo de transmissão do objecto

total = 2.RTT+tempo total de transmissão do objecto

time to transmit the object

initiate TCPconnection

RTT

requestfile

RTT

objectreceived

time time


Conexões persistentes e não persistentes

• Não-persistentes• HTTP/1.0• O servidor analisa o

pedido, responde, e fecha a conexão TCP

• 2 RTTs pelo menos por cada objecto pedido

• Persistentes• Disponíveis em

HTTP/1.1• Sem fechar a conexão:

o servidor analisa, responde, analisa, responde,..

• Pipelining: logo que o cliente reconhece URLs envia os pedidos mesmo sem esperar pelas respostas anteriores

• Menos RTTs


As mensagens HTTP

GET /somedir/page.html HTTP/1.0 Host: www.someschool.edu User-agent: Mozilla/4.0Connection: close Accept-language:fr

(extra carriage return, line feed)

request line(GET, POST, HEAD, ....)

header lines

Carriage return, line feeds

indicam o fim damensagem


Forma geral de um pedido HTTP


HTTP/1.0 GET POST HEAD

asks server to leave requested object out of response

HTTP/1.1 GET, POST, HEAD PUT

uploads file in entity body to path specified in URL field

DELETE deletes file specified in the

URL field

Comandos do cliente


Um cliente HTTP manual

1. Fazer telnet para um servidor Web:

Abrir conexão para a porta 80Tudo o que se escrever é enviado ao servidor pela conexão TCP

telnet www.di.fct.unl.pt 80

2. Escrever o comando GET HTTP:

GET /~jalm/ HTTP/1.0Host: www.di.fct.unl.pt

Desta forma (carregando em RETURN duas vezes) envia-se o pedido manualmente

3. Obter a resposta enviada pelo servidor HTTP!


Análise de uma resposta

HTTP/1.1 200 OK Connection closeDate: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data ...

status line(protocol

status codestatus phrase)

header lines

data, e.g., requestedhtml file


Alguns cabeçalhos

Os cabeçalhos usados tanto nos pedidos como nas respostas são cabeçalhos MIME que servem para indicar propriedades e outras opções do diálogo entre o browser e o servidor. Exemplos:

MIME-version versão MIME usadaIf-Modified-Since conditional GETLast-Modified data da última modificaçãoContent-length dimensãoContent-Encoding codificação MIMEContent-Type tipo MIME do documentoDate data do requestFrom e-mail do userServer identificação do servidorUser-Agent identificação do browser….

Nota: o cabeçalho MIME Content-Transfer-Encoding não é necessário.


Transmissão de dados para o servidor

Através de um “post method”: Frequentemente as páginas

têm um “form” Os dados do utilizador são

transmitidos para o servidor no corpo (“body”) da mensagem

Através do URL: Usa o método GET Os dados vão

codificados no URL

www.somesite.com/animalsearch?monkeys&banana


CGI - Common Gateway Interface

File system

CGI

Ficheiros não executáveis

server

browser

http + parâmeteros

Por convenção, o directório “/cgi-bin” contem o código executável dos “scripts”.


Alguns códigos de resposta

Os códigos de resposta têm o formato geral: xyz (3 digitos) seguidos de uma frase informativa

Exemplos:

200 Ok, request succeeded204 Ok, but no content to return301 Requested resource has been assigned a new URL304 Document has not been modified (conditional GET)400 Bad request404 Not found…..


HTML - HyperText Markup Language

Linguagem HTML é a linguagem adoptada na Web para se descreverem os documentos de hypertext que são visualizados pelo browser.

Os documentos HTML são estruturados (Cabeçalhos, Títulos, Tipos/Fontes, Tamanhos, Barras, Imagens in-line, Listas, Menus, Links, …)

A linguagem HTML permite a anotação de um texto com marcas (“tags”) que correspondem a directivas de formatação.

HTML é um sub-conjunto da linguagem de markup SGML (Standard Generalized Markup Language) que é definida pela norma ISO 8879.

Algumas TAGS comuns

<HTML> …. </HTML> Indica uma página escrita em HTML<HEAD> …. </HEAD> Delimita o cabeçalho da página<TITLE> …. </TITLE> Título da página (não afixado)<BODY> …. </BODY> Corpo da página<Hn> …. </Hn> Heading de nível n (1 a 6) …. Texto em Boldface …. Texto em itálico<UL> …. </UL> Lista não numerada de itens<OL> …. </OL> Lista numerada de itens<MENU> …. </MENU> Menu<LI> Item de uma lista Produz uma mudança de linha obrigatória Fim de parágrafo<HR> Linha horizontal<PRE> …. </PRE> Texto pré-formatado<IMG SRC=“….”> Carregar uma imagem neste ponto<A HREF=“….”> …. </A> Hyperlink (âncora)


Interacção com autenticação

• Objectivo: controlar o acesso a certos documentos

• Sem estado: o cliente tem de apresentar as credenciais em cada acesso

• Tipicamente nome, password

cliente servidor

usual http request msg401: authorization req.

WWW authenticate:

usual http request msg

+ Authorization:lineusual http response

msg


+ Authorization:lineusual http response

msg

tempo

O browser faz caching do nome & passwordpara tornar a utilização mais confortável.


Estado sobre um utilizador no servidor: cookies

Muitos WEB sites que necessitam de manter estado sobre os clientes entre acessos usam cookies

Quatro componentes:1) cookie header line of HTTP

response message2) cookie header line in HTTP

request message3) cookie file kept on user’s

host, managed by user’s browser

4) back-end database at Web site

Exemplo: O João acede sempre à

Internet usando o mesmo PC

Visita com alguma frequência um dado site

A quando do 1º acesso, o servidor cria para o João:

um ID único Uma entrada na base

de dados backend com esse ID


Acesso a um servidor com estado: cookies

client Amazon server

usual http request msgusual http response

+Set-cookie: 1678


cookie: 1678usual http response

msg


cookie: 1678usual http response msg

cookie-specificaction

cookie-spectificaction

servercreates ID

1678 for user

entry in backend

database

access

acce

ss

Cookie file

amazon: 1678ebay: 8734

Cookie file

ebay: 8734

Cookie file

amazon: 1678ebay: 8734

one week later:


Cookies (continued)

What cookies can bring: authorization shopping carts recommendations user session state (Web

e-mail)

Cookies and privacy: cookies permit sites to

learn a lot about you you may supply name

and e-mail to sites

aside

How to keep “state”: protocol endpoints: maintain state at

sender/receiver over multiple transactions

cookies: http messages carry state


Web Caches (proxy server)

• O utilizador parametriza o browser para usar o proxy

• O browser envia os pedidos para o proxy• Se o objecto está na

cache do proxy este envia a cópia cached

• Senão, vai buscar o objecto ao servidor Web, faz caching dele e responde

Objectivo: satisfazer o pedido do cliente sem envolver o servidor Web

client

Proxyserver

client

http request

http re

quest

http response

http re

sponse

http re

quest

http re

sponse

http requesthttp response

origin server

origin server


Hipóteses: Dimensão média dos objectos

= 100.000 bits Média de = 15 pedidos

/segundo Latência do router local a cada

site web = 2 segundos em média = Internet delay

Consequências: Utilização da LAN = 15% Utilização do link de acesso =

100% Latência total = Internet

delay + link delay + LAN delay = 2 seg + minutos + mili

segundos

originservers

public Internet

institutionalnetwork 10 Mbps LAN

1.5 Mbps access link

Alternativas de acesso à Internet


1ª solução possível - link a 10 Mbps

Consequência Utilização da LAN = 15% Utilização do link = 15% Latência total = Internet

delay + link delay + LAN delay

= 2 segundos + mili segundos + mili segundos

Mas a solução é cara

originservers

public Internet


10 Mbps access link

Solução baseada num proxy

Instala-se um proxy Por hipótese com um hit rate

is 0.4

Consequências 40% dos pedidos satisfeitos

localmente (admitamos um LAN delay de 2 ms)

60% dos pedidos satisfeitos pelo servidor final

A utilização do link de acesso desceu para 60% (admitamos um delay no link de 10 ms)

Latência total média = Internet delay + access delay + LAN delay = 0.6*(2.01) segundos + 0.4*0.002 < 1,2 segundos

originservers

public Internet


1.5 Mbps access link

institutionalcache

Get condicional

• Objectivo: se a versão cached está actual, não enviar o objecto

• cliente: especifica a data da versão cached• If-modified-since:

<date>

• servidor: a resposta só contem o objecto se este tiver sido modificado• HTTP/1.0 304 Not

Modified

cliente servidor

http request msgIf-modified-since:

<date>

http responseHTTP/1.0

304 Not Modified

object not

modified

http request msgIf-modified-since:

<date>

http responseHTTP/1.1 200 OK

…

<data>

object modified

cap. 2 – o nível aplicação 1ª parte departamento de informática da faculdade de ciências e...

Documents