Camada de Aplicação Teleprocessamento e Redes Instituto de Informática – UFG Prof. Fábio M....
Transcript of Camada de Aplicação Teleprocessamento e Redes Instituto de Informática – UFG Prof. Fábio M....
Camada de Aplicação
Teleprocessamento e Redes
Instituto de Informática – UFGProf. Fábio M. Costa
(slides baseados em [Kurose&Ross2003])
Cap. 2: Camada de Aplicação 2
Parte 2: Camada de Aplicação
Nossos objetivos: conceitual, aspectos de
implementação de protocolos de aplicação para redes paradigma cliente-
servidor modelos de serviço
aprenda sobre protocolos examinando algumas aplicações populares
Outros objetivos do capítulo protocolos específicos:
http ftp smtp pop dns
programação de aplicações de rede socket API
Cap. 2: Camada de Aplicação 3
Aplicações e Protocolo de Aplicação
Aplicação: processos distribuídos que comunicam entre si rodam nos computadores
(hosts) da rede como programas de usuário
trocam mensagens entre si para realização da aplicação
e.x., email, ftp, Web
Protocolos de aplicação fazem parte das aplicações definem mensagens trocadas
e as ações tomadas usam serviços de
comunicação das camadas inferiores
aplicaçãotransporte
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
Cap. 2: Camada de Aplicação 4
Aplicações de Rede
Processo: programa executando num host.
dentro do mesmo host: interprocess communication (definido pelo SO).
processos executando em diferentes hosts se comunicam com um protocolo da camada de aplicação
agente usuário: software que interfaceia com o usuário de um lado e com a rede de outro. implementa protocolo
da camada de aplicação
Web: browser E-mail: leitor de correio streaming áudio/vídeo:
media player
Cap. 2: Camada de Aplicação 5
Paradigma Cliente-ServidorAplicações de rede típicas têm duas
partes: cliente and servidoraplicaçãotransporte
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
Cliente: inicia comunicação com o
servidor (“fala primeiro”) tipicamente solicita serviços do
servidor, Web: cliente implementado no
browser; e-mail: leitor de correio
pedido
resposta
Servidor: fornece os serviços solicitados pelo cliente e.x., Web server envia a página Web
solicitada, servidor de e-mail envia as mensagens, etc.
Cap. 2: Camada de Aplicação 6
Interfaces de Programação
API: application programming interface
define a interface entre a camada de aplicação e de transporte
socket: Internet API dois processos se
comunicam enviando dados para o socket e lendo dados de dentro do socket
Q: Como um processo “identifica” o outro processo com o qual ele quer se comunicar? IP address do
computador no qual o processo remoto executa
“port number” - permite ao computador receptor determinar o processo local para o qual a mensagem deve ser entregue.
Cap. 2: Camada de Aplicação 7
Serviços de Transporte
Perda de dados algumas aplicações (e.x.,
aúdio) podem tolerar alguma perda
outras aplicações (e.x., transferência de arquivos, telnet) exigem transferência de dados 100% confiável
Temporização algumas aplicações (e.x.,
telefonia Internet, jogos interativos) exigem baixos atrasos para operarem
Banda Passante algumas aplicações (e.x.,
multimedia) exigem uma banda mínima para serem utilizáveis
outras aplicações (“aplicações elásticas”) melhoram quando a banda disponível aumenta
Cap. 2: Camada de Aplicação 8
Requisitos de Transporte de Aplicações Comuns
Applicação
transf. de arquivose-mail
documentos Webáudio/vídeo tempo real
áudio/vídeo armazenadojogos interativos
comércio eletrônico
Perdas
sem perdassem perdastolerantetolerante
tolerantetolerantesem perda
Banda
elásticaelásticaelásticaaúdio: 5Kb-1Mbvídeo:10Kb-5Mbigual à anterior Kbps elástica
Sensível ao Atraso
nãonãonãosim, 100’s msec
sim, segundossim, 100’s msecsim
Cap. 2: Camada de Aplicação 9
Serviços de Transporte da Internet
serviço TCP: orientado á conexão: conexão
requerida entre cliente e servidor transporte confiável dados perdidos
na transmissão são recuperados controle de fluxo: compatibilização
de velocidade entre o transmissor e o receptor
controle de congestionamento : protege a rede do excesso de tráfego
não oferece: garantias de temporização e de banda mínima
serviço UDP: transferência de dados
não confiável entre os processos transmissor e receptor
não oferece: estabelecimento de conexão, confiabilidade, controle de fluxo e de congestionamento, garantia de temporização e de banda mínima.
Cap. 2: Camada de Aplicação 10
Aplicações e Protocolos de Transporte da Internet
Aplicação
e-mailacesso de terminais remotos
Web transferência de arquivos
streaming multimedia
servidor de arquivos remototelefonia Internet
Protocolo de Aplicação
smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959]RTP ou proprietario(e.g. RealNetworks)NFSRTP ou proprietary(e.g., Vocaltec)
Protocolo deTransporte
TCPTCPTCPTCPTCP ou UDP
TCP ou UDPtipicamente UDP
Cap. 2: Camada de Aplicação 11
Protocolo HTTP
HTTP: HyperText Transfer Protocol
protocolo da camada de aplicação da Web
modelo cliente/servidor cliente: browser que
solicita, recebe e apresenta objetos da Web
server: envia objetos em resposta a pedidos
http1.0: RFC 1945 http1.1: RFC 2068
PC rodandoExplorer
Servidorrodando
NCSA Webserver
Mac rodandoNetscapeNavigator
http request
http re
quest
http response
http re
sponse
Cap. 2: Camada de Aplicação 12
Protocolo HTTP
http - protocolo de transporte: TCP
cliente inicia conexão TCP (cria socket) para o servidor na porta 80
servidor aceita uma conexão TCP do cliente
mensagens http (mensagens do protocolo de camada de aplicação) são trocadas entre o browser (cliente http) e o servidor Web (servidor http)
A conexão TCP é fechada
http é “stateless” o servidor não mantém
informação sobre os pedidos passados pelos clientes
Protocolos que mantém informações de estado são complexos!
necessidade de organizar informações passadas
se ocorrer um queda do sistema, as informações podem ser perdidas ou gerar inconsistências entre o cliente e o servidor
Cap. 2: Camada de Aplicação 13
Exemplo de OperaçãoUsuário entra com a URL: www.someSchool.edu/someDepartment/home.index
1a. cliente http inicia conexão TCP ao servidor http (processo) em www.someSchool.edu. Porta 80 é a default para o servidor http .
2. cliente http client envia uma mensagem de requisição http (contendo a URL) para o socket da conexão TCP
1b. servidor http no host www.someSchool.edu esperando pela conexão TCP na porta 80. “aceita” conexão, notificando o cliente
3. servidor http recebe mensagem de pedido, constrói a mensagem de resposta contendo o objeto solicitado (someDepartment/home.index), envia mensagem para o socket
tempo
(contém referência a 10 imagens jpeg)
Cap. 2: Camada de Aplicação 14
Exemplo (cont.)
5. cliente http recebe mensagem de resposta contendo o arquivo html, apresenta o conteúdo html. Analisando o arquivo html encontra 10 objetos jpeg referenciados
6. Passos 1-5 são repetidos para cada um dos 10 objetos jpeg.
4. servidor http fecha conexão TCP.
tempo
Cap. 2: Camada de Aplicação 15
Conexões persistentes e não-persistentes
Não-persistente http/1.0: servidor analisa
pedido, envia resposta e fecha a conexão TCP
2 RTTs para obter um objeto Conexão TCP solicitação e
transferência do objeto cada transferência sofre por
causa do mecanismo de slow-start do TCP
muitos browsers abrem várias conexões paralelas
Persistente modo default para htp/1.1 na mesma conexão TCP são
trazidos vários objetos o cliente envia pedido para
todos os objetos referenciados tão logo ele recebe a página HTML básica.
poucos RTTs, menos slow start.
Cap. 2: Camada de Aplicação 16
Formato das Mensagens
dois tipos de mensagens HTTP: request, response
mensagem de requisição http (request): ASCII (formato legível para humanos)
GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif, image/jpeg Accept-language:fr
(extra carriage return, line feed)
linha de pedido(comandos GET,
POST, HEAD )
linhas decabeçalho
Carriage return, line feed
indica fim da mensagem
Cap. 2: Camada de Aplicação 17
HTTP request: formato geral
Cap. 2: Camada de Aplicação 18
Formatos HTTP: response
HTTP/1.0 200 OK Date: 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 ...
linha de status(protocolo
código de status frase de status)
linhas decabeçalho
dados, e.x., arquivo html
Cap. 2: Camada de Aplicação 19
HTTP response: formato geral
version status phrase
Cap. 2: Camada de Aplicação 20
Códigos de status das respostas
200 OK requisição bem sucedida, objeto solicitado vem em seguida
301 Moved Permanently objeto requisitado foi movido; a nova localização é
especificada a seguir na mensagem
400 Bad Request mensagem de requisição não entendida pelo servidor
404 Not Found documento requisitado não encontrado neste servidor
505 HTTP Version Not Supported
Cap. 2: Camada de Aplicação 21
HTTP Cliente: faça você mesmo!
1. Telnet para um servidor Web:
Abre conexão TCP para a porta 80(porta default do servidor http) em www.eurecom.fr.Qualquer coisa digitada é enviada para a porta 80 em www.eurecom.fr
telnet www.eurecom.fr 80
2. Digite um pedido GET http:
GET /~ross/index.html HTTP/1.0 Digitando isto (tecle carriagereturn duas vezes), você envia estepedido HTTP GET mínimo (mas completo) ao servidor http
3. Examine a mensagem de resposta enviada pelo servidor http!
Cap. 2: Camada de Aplicação 22
HTML (HyperText Markup Language)
HTML: uma linguagem simples para hipertexto começou como versão simples de SGML construção básica: cadeias (strings) de texto anotadas
Construtores de formato operam sobre cadeias <b> .. </b> bold (negrito) <H1 ALIGN=CENTER> ..título centrado .. </H1> <BODY bgcolor=white text=black link=red ..> ..
</BODY>
vários formatos listas de bullets, listas ordenadas, listas de definição tabelas frames
Cap. 2: Camada de Aplicação 23
Encadeamento de referências
Referências <A HREF=LinkRef> ... </A> a componentes do documento local
<A HREF=“importante”> clique para uma dica </A> a documentos no servidor local
<A HREF=“../index.htm”> voltar ao sumário </A> a documentos em outros servidores
<A HREF=“http://www.ufg.br”> saiba mais sobre a UFG </A> Multimídia
imagem embutida: <IMG SRC=“eclipse”> imagem externa: <A HREF=“eclipse.gif”> imagem maior </A> vídeo Mpeg <A HREF=“ByeByeBrasil.mpg”> um bom filme </A> som <A HREF=“http://www.sons.br/aniv.au”> feliz aniversário
</A>
Cap. 2: Camada de Aplicação 24
Formulários e interação bidirecional
Formulários transmitem informação do cliente ao servidor
HTTP permite enviar formulários ao servidor
Resposta enviada como página HTML dinâmica
Formulários processados usando scripts CGI (programas que executam no servidor WWW) CGI - Common Gateway
Interface scripts CGI escondem acesso
a diferentes serviços servidor WWW atua como
gateway universal
Outras tecnologias: ASP, JSP, PHP, ...
clienteWWW
servidorWWW
Sistema deinformação
GET/POST formulário
resposta: HTML
Cap. 2: Camada de Aplicação 25
Interação usuário-servidor: autenticação Meta da autenticação: controle de
acesso aos documentos do servidor
sem estado: cliente deve apresentar autorização com cada pedido
autorização: tipicamente nome, senha authorization: linha de
cabeçalho no pedido se não for apresentada
autorização, servidor nega accesso, e coloca no cabeçalho da respostaWWW authenticate:
cliente servidor
msg de pedido http comum
401: authorization req.WWW authenticate:
msg de pedido http comum
+ Authorization:linemsg de resposta http
comum
tempo
Browser guarda nome e senha paraevitar que sejam pedidos ao usuário a cada acesso.
msg de pedido http comum
+ Authorization:linemsg de resposta http
comum
Cap. 2: Camada de Aplicação 26
Cookies
gerados e lembrados pelo servidor, usados mais tarde para: autenticação lembrar preferencias
dos usuários ou prévias escolhas
servidor envia “cookie” ao cliente na resposta HTTPSet-cookie: 1678453
cliente apresenta o cookie em pedidos posteriorescookie: 1678453
cliente servidorusual http request msg
usual http response +Set-cookie: uid
usual http request msgcookie: uid
usual http response msg
usual http request msgcookie: uid
usual http response msg
açãoespecíficado cookie
açãoespecífica do cookie
Gera resposta+
ID único (uid)p/ cookie
Cap. 2: Camada de Aplicação 27
Conditional GET: armazenando no cliente
Razão: não enviar objeto se a versão que o cliente já possui está atualizada.
cliente: especifica data da versão armazenada no pedido HTTP If-modified-since: <date>
servidor: resposta não contém objeto se a cópia do cliente está atualizada: HTTP/1.0 304 Not Modified
cliente servidor
http request msgIf-modified-since:
<date>
http responseHTTP/1.0
304 Not Modified
objeto não
modificado
http request msgIf-modified-since:
<date>
http responseHTTP/1.1 200 OK
<data>
objeto modificado
Cap. 2: Camada de Aplicação 28
ftp: o protocolo de transferência de arquivos
transferência de arquivos de e para o computador remoto modelo cliente servidor
cliente: lado que inicia a transferência (seja de ou para o lado remoto)
servidor: host remoto ftp: RFC 959 ftp servidor: porta 21
transferência de arquivos
FTPservidor
FTPinterface
de usuário
FTPcliente
sistema de arquivos local
sistema de arquivos remoto
user at host
Cap. 2: Camada de Aplicação 29
ftp: controle separado, conexões de dados
cliente ftp contata o servidor ftp na porta 21, especificando TCP como protocolo de transporte
duas conexões TCP paralelas são abertas: controle: troca de comandos
e respostas entre cliente e servidor.
“controle out of band” dados: dados do arquivo
trocados com o servidor servidor ftp mantém o
“estado”: diretório corrente, autenticação anterior
FTPcliente
FTPservidor
TCP conexão de controleporta 21
TCP conexão de dadosporta 20
Cap. 2: Camada de Aplicação 30
ftp comandos, respostas
Exemplos de comandos: Enviados em texto ASCII
através do canal de controle
USER username PASS password LIST retorna listagem dos
arquivos no diretório atual RETR filename recupera
(obtém) o arquivo (GET) STOR filename armazena o
arquivo no host remoto (PUT)
Exemplos de códigos de retorno
código de status e frase (como no http)
331 Username OK, password required
125 data connection already open; transfer starting
425 Can’t open data connection
452 Error writing file
Cap. 2: Camada de Aplicação 31
Correio Eletrônico
Três componentes principais: agentes de usuário servidores de correio simple mail transfer protocol: smtp
Agente de usuário “leitor de correio” composição, edição, leitura de
mensagens de correio ex., Eudora, Outlook, elm,
Netscape Messenger mensagens que chegam e saem
são armazenadas em filas no servidor
caixa postal
fila de saída de mensagem
mailserver
agenteusuário
agenteusuário
agenteusuário
servidorde correio
agenteusuário
agenteusuário
servidor de correio
agenteusuário
SMTP
SMTP
SMTP
Cap. 2: Camada de Aplicação 32
Correio eletrônico: servidores de correio
Servidores de Correio caixa postal contém mensagens
que chegaram (ainda não lidas) para o usuário
fila de mensagens contém as mensagens de correio a serem enviadas
protocolo smtp permite aos servidores de correio trocarem mensagens entre eles “cliente”: servidor de
correio que envia “servidor”: servidor de
correio que recebe
mailserver
agenteusuário
agenteusuário
agenteusuário
servidorde correio
agenteusuário
agenteusuário
servidor de correio
agenteusuário
SMTP
SMTP
SMTP
Cap. 2: Camada de Aplicação 33
Correio Eletrônico: smtp [RFC 821]
usa TCP para transferência confiável de mensagens de correio do cliente para o servidor, através da porta 25
transferência direta: do servidor que envia para o servidor que recebe
três fases de trasnferência handshaking (apresentação) transferência de mensagens fechamento
interação comando/resposta comandos: texto ASCII resposta: código de status e frase
mensagens devem ser formatadas em código ASCII de 7 bits
Cap. 2: Camada de Aplicação 34
Exemplo de interação SMTP
S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection
Cap. 2: Camada de Aplicação 35
Tente o SMTP você mesmo:
telnet <nome do servidor> 25 veja resposta 220 do servidor envie comandos HELO, MAIL FROM, RCPT TO,
DATA, QUIT como no exemplo anterior
a seqüência acima permite enviar um e-mail sem usar o agente de usuário do rementente
Cap. 2: Camada de Aplicação 36
SMTP: palavras finais SMTP usas conexões
persistentes SMTP exige que as
mensagens (cabeçalho e corpo) estejam em ASCII de 7 bits
algumas seqüências de caracteres não são permitidas no corpo das mensagens (ex., CRLF.CRLF). Assim mensagens genéricas têm que ser codificadas (usualmente em “base-64” ou “quoted printable”)
Servidor SMTP usa CRLF.CRLF para indicar o final da mensagem
Comparação com http: http: modelo pull email: modelo push
ambos usam comandos e respostas em ASCII, interação comando / resposta e códigos de status
http: cada objeto encapsulado na sua própria mensagem de resposta
smtp: múltiplos objetos são enviados numa mensagem multiparte
Cap. 2: Camada de Aplicação 37
Formato das Mensagens
smtp: protocolo para trocar mensagens de e-mail
RFC 822: padrão para mensagens do tipo texto:
linhas de cabeçalho, e.g., To: From: Subject:
não confudir com os comandos SMTP !
corpo a “mensagem”, ASCII
somente com caracteres
cabeçalho
corpo da mensagem
linha em branco
Cap. 2: Camada de Aplicação 38
Formato das Mensagens: extensões multimedia MIME: multimedia mail extension: RFC 2045, 2056 linhas adicionais no cabeçalho declaram o tipo de
conteúdo MIME
From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg
base64 encoded data ..... ......................... ......base64 encoded data
tipo, subtipo edeclaração de parâmetro
dos dados multimídia
método usadopara codificar dados
versão de MIMEutilizada
dados codificados
Cap. 2: Camada de Aplicação 39
Tipos MIMEContent-Type: type/subtype; parâmetros
Text exemplo de subtipos:
plain, html
Image exemplo de subtipos: jpeg,
gif
Audio exemplo de subtipos: basic
(codificado 8-bit -law ), 32kadpcm (codificação 32 kbps)
Video exemplo de subtipos: mpeg,
quicktime
Application outros dados que devem
ser processados pelo leitor antes de serem apresentados “visualmente”
exemplo de subtipos: msword, octet-stream
Cap. 2: Camada de Aplicação 40
Tipo Multiparte: Mensagens com múltiplos objetos de tipos diferentes
From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789Content-Transfer-Encoding: quoted-printableContent-Type: text/plain
Dear Bob, Please find a picture of a crepe.--98766789Content-Transfer-Encoding: base64Content-Type: image/jpeg
base64 encoded data ..... ......................... ......base64 encoded data --98766789--
1a. parte: texto
2a. parte: imagem
delimitador
Cap. 2: Camada de Aplicação 41
Formato das mensagens recebidas Servidor de correio do destino (que recebe
a mensagem) adiciona a linha de cabeçalho Received:
Received: from crepes.fr by hamburger.edu;12 Oct 98 15:27:39 GMT
From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg
base64 encoded data ..... ......................... ......base64 encoded data
Cap. 2: Camada de Aplicação 42
Protocolos de acesso ao correio
SMTP: entrega e armazena as mensagens no servidor do destino Protocolo de acesso: recupera mensagens do servidor
POP: Post Office Protocol [RFC 1939]• autorização (agente <-->servidor) e download
IMAP: Internet Mail Access Protocol [RFC 1730]• mais recursos (mais complexo)• permite a manipulação de mensagens armazenadas no servidor (ex.: organizá-las
em diretórios) HTTP: Hotmail , Yahoo! Mail, etc.
agenteusuário
servidor de correio da origem
agenteusuário
SMTP SMTP POP3 orIMAP
servidor decorreio do destino
Cap. 2: Camada de Aplicação 43
protocolo POP3
fase de autorização comandos do cliente:
user: declara nome do usuário
pass: password respostas do servidor
+OK -ERR
fase de transação list: lista mensagens e
tamanhos retr: recupera mensagem pelo
número dele: apaga quit
C: list S: 1 498 S: 2 912 S: . C: retr 1 S: (blah blah blah ... S: .....................) S: . C: dele 1 C: retr 2 S: (blah blah blah ... S: .....................) S: . C: dele 2 C: quit S: +OK POP3 server signing off
S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on
Cap. 2: Camada de Aplicação 44
DNS: Domain Name System
Pessoas: muitos identificadores: RG, nome, passaporte
Hosts e roteadores na Internet: endereços IP (32 bit) -
usados para endereçar datagramas
“nome”, ex., gaia.cs.umass.edu - usados por humanos
Q: Como relacionar nomes com endereços IP?
Domain Name System: base de dados distribuída
implementada numa hierarquia de muitos servidores de nomes
protocolo de camada de aplicação host, roteadores se comunicam com servidores de nomes para resolver nomes (tradução nome/endereço) nota: função interna da
Internet, implementada como um protocolo da camada de aplicação
complexidade na “borda” da rede
Cap. 2: Camada de Aplicação 45
Servidores de Nomes DNS Nenhum servidor tem todos os
mapeamentos de nomes para endereços IP
servidores de nomes locais: cada ISP ou empresa tem um
servidor de nomes local (default)
Consultas dos computadores locais ao DNS vão primeiro para o servidor de nomes local
servidor de nomes autoritativo: para um computador:
armazena o nome e o endereço IP daquele computador
pode realizar mapeamentos de nomes para endereços para aquele nome de computador
Porque não centralizar o DNS?
ponto único de falha volume de tráfego base de dados distante manutenção
Não cresce junto com a rede!isto é: não seria escalável
Cap. 2: Camada de Aplicação 46
DNS: Servidores de Nomes Raiz são contactados pelos servidores de nomes locais que não podem resolver
um nome servidor de nomes raiz::
busca servidores de nomes autoritativos se o mapeamento do nome não for conhecido
obtém o mapeamento retorna o mapeamento para o servidor de nomes local
b USC-ISI Marina del Rey, CAl ICANN Marina del Rey, CA
e NASA Mt View, CAf Internet Software C. Palo Alto, CA
i NORDUnet Stockholm
k RIPE London
m WIDE Tokyo
a NSI Herndon, VAc PSInet Herndon, VAd U Maryland College Park, MDg DISA Vienna, VAh ARL Aberdeen, MDj NSI (TBD) Herndon, VA
existem 13 servidores de nomes raiz no mundo (2002)
Cap. 2: Camada de Aplicação 47
DNS: exemplo simples
host surf.eurecom.fr quer o endereço IP de gaia.cs.umass.edu
1. contacta seu servidor DNS local, dns.eurecom.fr
2. dns.eurecom.fr contata o servidor de nomes raiz, se necessário
3. o servidor de nomes raiz contata o servidor de nomes autoritativo, dns.umass.edu, se necessário
computador solicitantesurf.eurecom.fr
gaia.cs.umass.edu
servidor de nomes raiz
servidor de nomesautoritativo
dns.umass.edu
servidor de nomes localdns.eurecom.fr
1
23
4
5
6
Cap. 2: Camada de Aplicação 48
DNS: exemplo
Servidor de nomes raiz:
pode não conhecer o servidor de nomes autoritativo para um certo nome
pode conhecer: servidor de nomes intermediário: aquele que deve ser contactado para encontrar o servidor de nomes autoritativo
computador solicitantesurf.eurecom.fr
gaia.cs.umass.edu
servidor de nomes raiz
servidor de nomes localdns.eurecom.fr
1
23
4 5
6
servidor de nomesautoritativo
dns.cs.umass.edu
servidor de nomesintermediáriodns.umass.edu
7
8
Cap. 2: Camada de Aplicação 49
DNS: consultas encadeadas
consulta recursiva: transfere a tarefa de
resolução do nome para o servidor de nomes consultado
carga pesada?
consulta encadeada: servidor contactado
responde com o nome de outro servidor de nomes para contato
“Eu não sei isto ,mas pergunte a este servidor”
computador solicitantesurf.eurecom.fr
gaia.cs.umass.edu
servidor de nomes raiz
servidor de nomes localdns.eurecom.fr
1
23
4
5 6
servidor de nomesautoritativo
dns.cs.umass.edu
servidor de nomesintermediáriodns.umass.edu
7
8
consulta encadeada
Cap. 2: Camada de Aplicação 50
DNS: armazenando e atualizando registros
Uma vez que um servidor de nomes apreende um mapeamento, ele armazena o mapeamento num registro do tipo cache registro da cache tornam-se obsoletos
(desapareçem) depois de um certo tempo Tradicionalmente: registros são armazenados
estaticamente ex.: a partir de um arquivo de configuração
RFC 2136: mecanismos de atualização dinâmica estão sendo projetados pelo IETF Dynamic DNS updates: adicionar ou remover registros
dinamicamente http://www.ietf.org/html.charters/dnsind-charter.html
Cap. 2: Camada de Aplicação 51
registros do DNSDNS: base de dados distribuída que armazena registros de recursos (RRs)
Type=NS name é um domínio (ex.
foo.com) value é o endereço IP do
servidor de nomes autoritativo para este domínio
formato dos RRs: (name, value, type, ttl)
Type=A name é o nome do
computador value é o endereço IP
Type=CNAME name é um “apelido” para algum
nome “canônico” (o nome real) Ex.: www.ibm.com é realmente servereast.backup2.ibm.com value é o nome canônico
Type=MX value é o nome canônico do
servidor de correio associado com name
Cap. 2: Camada de Aplicação 52
DNS: protocolo e mensagens
protocolo DNS: mensagen de consulta e resposta , ambas com o mesmo formato de mensagem
cabeçalho da mensagem identificação: número de 16
bit para a consulta, resposta usa o mesmo número
flags: consulta ou resposta recursão desejada recursão disponível resposta é autoritativa
Cap. 2: Camada de Aplicação 53
Campos de nome e tipo para uma consulta
RRs de respostaa uma consulta
registros para servidores autoritativos
informação adicionalque pode ser útil
Ex.: se answer é do tipo “MX”,additional info poderá conter
um RR do tipo “A” com oendereço IP do servidor de e-mail
DNS: protocolo e mensagens
Cap. 2: Camada de Aplicação 54
Programação de Sockets
API de Sockets introduzida no BSD4.1 UNIX,
1981 sockets são explicitamente
criados, usados e liberados pelas aplicações
paradigma cliente/servidor dois tipos de serviço de
transporte via socket API: datagrama não confiável confiável, orientado a fluxo
de bytes
uma interface local, criada e possuída pelas aplicações
controlada pelo OS
uma “porta” através qual os processos de aplicação podem tanto enviar quanto receber mensagens de e para outro processo de aplicação (local ou remoto)
socket
Objetivo: aprender a construir aplicações cliente/servidor que se comunicam usando sockets
Cap. 2: Camada de Aplicação 55
Programação de Sockets com TCP
Socket: uma porta entre o processo de aplicação e o protocolo de transporte fim-a-fim (UDP ou TCP)
serviço TCP: transferência confiável de bytes de um processo para outro
processo
TCP com buffers,
variáveis
socket
controlado pelocriador da aplicação
controlado pelosistema
operacional
host ouservidor
processo
TCP combuffers,
variáveis
socket
host ouservidor
internet
controlado pelocriador da aplicação
controlado pelosistemaoperacional
Cap. 2: Camada de Aplicação 56
Programação de Sockets com TCP
Cliente deve contactar o servidor
processo servidor já deve estar executando antes de ser contactado
servidor deve ter criado um socket (porta) que aceita o contato do cliente
Como o cliente contacta o servidor:
criando um socket TCP local
especificando endereço IP e número da porta do processo servidor
Quando o cliente cria o socket: cliente TCP estabelece conexão com o TCP do servidor
Quando contactado pelo cliente, o TCP do servidor cria um novo socket para o processo servidor comunicar-se com o cliente permite ao servidor
conversar com múltiplos clientes
TCP fornece a transferência confiável (fluxo de bytes ordenados)
(“pipe”) entre o cliente e oservidor
ponto de vista da aplicação
Cap. 2: Camada de Aplicação 57
Exemplo de aplicação cliente-servidor:
cliente lê uma linha da entrada padrão do sistema (stream inFromUser) , envia para o servidor via socket (stream outToServer)
servidor lê a linha do socket servidor converte linha para
letras maiúsculas e envia de volta ao cliente
cliente lê a linha modificada através do sockete (stream inFromServer)
ou
tTo
Se
rve
r
para rededa rede
inF
rom
Se
rve
r
inF
rom
Use
r
teclado monitor
clientSocket
inputstream
inputstream
outputstream
TCPsocket
stream de entrada: seqüência de bytespara dentro do processostream de saída:
seqüência de bytes para fora do processo
processocliente
TCP socketcliente
Programação de Sockets com TCP
Cap. 2: Camada de Aplicação 58
Interação Cliente/servidor: TCP
espera por pedidode conexão entranteconnectionSocket =welcomeSocket.accept()
cria socket,porta=x, parasolicitação entrante:welcomeSocket =
ServerSocket()
cria socket,conecta com hostid, porta=x:clientSocket =
Socket()
fechaconnectionSocket
lê resposta declientSocket
fechaclientSocket
Servidor(executando em hostid)
Cliente
envia pedido usandoclientSocketlê pedido de
connectionSocket
escreve resposta paraconnectionSocket
TCP estab. de conexão
Cap. 2: Camada de Aplicação 59
Exemplo: cliente Java (TCP)
import java.io.*; import java.net.*; class TCPClient {
public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence;
BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket("hostname", 6789);
DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());
Criastream de entrada
Cria socket cliente,
conecta ao servidor
Criastream de saídaligada ao socket
Cap. 2: Camada de Aplicação 60
Exemplo: cliente Java (TCP), cont.
BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
sentence = inFromUser.readLine();
outToServer.writeBytes(sentence + '\n');
modifiedSentence = inFromServer.readLine();
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close(); } }
Criastream de entrada
ligada ao socket
Envia linhapara o servidor
Lê linha do servidor
Cap. 2: Camada de Aplicação 61
Exemplo: servidor Java (TCP)import java.io.*; import java.net.*;
class TCPServer {
public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence;
ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept();
BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));
Criasocket de aceitação
na porta 6789
Espera, no socketde aceitação por
contato do cliente
Cria stream deentrada, ligado
ao socket
Cap. 2: Camada de Aplicação 62
Exemplo: servidor Java (cont)
DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + '\n';
outToClient.writeBytes(capitalizedSentence); } } }
Lê linha do socket
Cria stream de saída, ligado ao
socket
Escreve linhapara o socket
Fim do while loop,retorne e espere poroutra conexão do cliente
Cap. 2: Camada de Aplicação 63
Programaçaõ de Sockets com UDP
UDP: não há conexão entre o cliente e o servidor
não existe apresentação (handshaking)
transmissor envia explicitamente endereço IP e porta de destino em cada mensagem
servidor deve extrair o endereço IP e porta do transmissor de cada datagrama recebido
UDP: dados transmitidos podem ser recebidos foram de ordem ou perdidos
ponto de vista da aplicaçãoUDP fornece a transferência
não confiável de grupos de bytes (“datagramas”) entre o cliente e o
servidor
Cap. 2: Camada de Aplicação 64
Interação Cliente/servidor: UDP
fechaclientSocket
Servidor(executando em hostid)
lê resposta declientSocket
cria socket,clientSocket = DatagramSocket()
Cliente
Cria endereço (hostid, port=x),envia datagrama de pedido usando clientSocket
cria socket,porta=x, para solicitação entrante:serverSocket = DatagramSocket()
lê pedido de:serverSocket
escreve resposta paraserverSocketespecificando endereçodo host cliente enúmero da porta
Cap. 2: Camada de Aplicação 65
Exemplo: cliente Java (UDP)
sen
dP
ack
et
para rede da redere
ceiv
eP
ack
et
inF
rom
Use
r
teclado monitor
Process
clientSocket
pacoteUDP
streamde entrada
pacoteUDP
UDPsocket
Saída: envia pacote (TCP enviaria “byte stream”)
Entrada: recebe pacote (TCP receberia “byte stream”)
processocliente
socket UDP cliente
Cap. 2: Camada de Aplicação 66
Exemplo: cliente Java (UDP)
import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine();
sendData = sentence.getBytes();
Criastream de entrada
Criasocket cliente
Traduz nome do host para
endereço IPusando DNS
Cap. 2: Camada de Aplicação 67
Exemplo: cliente Java (UDP), cont.
DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); }
}
Cria datagrama comdados a enviar,
tamanho, endereço IPe porta
Envia datagramapara servidor
Lê datagramado servidor
Cap. 2: Camada de Aplicação 68
Exemplo: servidor Java (UDP)
import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) { DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
Criasocket datagrama
na porta 9876
Cria espaço paradatagramas recebidos
Recebedatagram
a
Cap. 2: Camada de Aplicação 69
Exemplo: servidor Java, (cont.)
String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } }
}
Obtém endereço IP e número da porta
do transmissor
Escreve o datagrama para
dentro do socket
Termina o while loop,retorna e espera poroutro datagrama
Cria datagramapara enviar ao cliente
Cap. 2: Camada de Aplicação 70
Programação de Sockets: referências
tutorial sobre sockets em linguagem C (audio/slides): “Unix Network Programming” (J. Kurose),http://manic.cs.umass.edu
Tutoriais sobre sockets em Java: “Socket Programming in Java: a tutorial,”http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html
Cap. 2: Camada de Aplicação 71
Construção de um Servidor Web Simplificado
Ingredientes: Protocolo HTTP + Sockets Funcionalidade:
Trata apenas uma requisição HTTP Aceita e interpreta a requisição Obtém o arquivo requisitado a partir do sistema
de arquivos local (do servidor Web) Cria uma mensagem de resposta HTTP: Linhas
de cabeçalho + arquivo requisitado Envia a resposta diretamente para o cliente Fecha conexão e termina
Cap. 2: Camada de Aplicação 72
Construção de um Servidor Web Simplificado Cliente: Navegador Web padrão
Netscape, IE, Konqueror, etc. Exemplo de requisição:
URL: http://somehost.somewhere.br:6789/somefile.html
host e porta: usados p/ estab. conexão com servidor
Requisição:GET /somefile.html HTTP/1.0
Cap. 2: Camada de Aplicação 73
WebServer.java (1)
import java.io.*;import java.net.*;import java.util.*;class WebServer {
public static void main (String argv[]) throws Exception{
String requestMessageLine;ServerSocket listenSocket = new ServerSocket(6789);Socket connectionSocket = listenSocket.accept();BufferedReader inFromClient =
new BufferedReader (new InputStreamReader(connectionSocket.getInputStream()));
Socket paraespera de conexões
Socket de conexão c/ clienteStream
para receber
dados via socket
Cap. 2: Camada de Aplicação 74
WebServer.java (2)
DataOutputStream outToClient =new DataOutputStream(
connectionSocket.getOutputStream());requestMessageLine = inFromClient.readLine();StringTokenizer tokenizedLine =
new StringTokenizer( requestMessageLine);if (tokenizedLine.nextToken().equals(“GET”)){
fileName = tokenizedLine.nextToken();if (fileName.startsWith(“/”) == true)
fileName = fileName.substring(1);File file = new File(fileName);int numOfBytes = (int) file.length();
Stream para enviar dados através do
socket
Lê requisição do cliente
Separa os tokens da requisição
Verifica se comando é
GET
Obtém o nome do arquivo
Obtém o tamanho
do arquivo
Cap. 2: Camada de Aplicação 75
WebServer.java (3)
FileInputStream inFile = new FileInputStream(fileName);
byte [] fileInBytes = new byte[numOfBytes];inFile.read(fileInBytes);outToClient.writeBytes(
“HTTP/1.0 200 Document Follows\r\n”);if (fileName.endsWith(“.jpg”))
outToClient.writeBytes(“Content-Type: image/jpeg\r\n”);
if (fileName.endsWith(“.gif”))outToClient.writeBytes(“Content-Type:
image/gif\r\n”);
Lê o arquivo
requisitado
Envia a primeira linha do cabeçalho da resposta
Segunda linha (content-type)
depende do tipo do arquivo
requisitado (jpeg ou gif)
Cap. 2: Camada de Aplicação 76
WebServer.java (4)
outToClient.writeBytes(“Content-Length: “ +numOfBytes + “\r\n”);
outToClient.writeBytes(“\r\n”);outToClient.write(fileInBytes, 0, numOfBytes);connectionSocket.close();
}else System.out.println(“Bad Request Message”);
}}
Envia a 3a. linha do
cabeçalho
Linha em branco para separar o cabeçalho do corpo da msg
Envia o arquivo
requisitado
Fecha a conexão com
o cliente
Cap. 2: Camada de Aplicação 77
WebServer.java: O que Falta?
Aceitar múltiplas requisições Cada requisição processada por uma thread
diferente Tratar outros tipos de conteúdo (linha de
cabeçalho Content-type:) Suporte para demais comandos (POST,
HEAD) Suporte para demais tipos de mensagem
de resposta (Bad request, Not found, etc.) O que mais?
Cap. 2: Camada de Aplicação 78
Distribuição de Conteúdo
Web Caches (ou Web Proxies)
Redes de Distribuição de Conteúdo (CDNs)
Redes “Peer-to-Peer”
Cap. 2: Camada de Aplicação 79
Web Caches (proxy server)
usuário configura o browser: acesso à Web é feito através de um proxy
cliente envia todos os pedidos http para o proxy se o objeto existe no proxy (web
cache): proxy retorna o objeto caso contrário, o proxy solicita
o objeto ao servidor original e então envia o objeto ao cliente.
proxy guarda o objeto em sua cache
Objetivo: atender o cliente sem envolver o servidor Web originador da informação
cliente
Proxyserver
cliente
http re
quest
http re
sponse
http request http request
http response http response
servidororiginal
servidororiginal
Cap. 2: Camada de Aplicação 80
Porque Web Caching?
armazenamento está “perto” do cliente (ex., na mesma rede)
menor tempo de resposta
reduz o tráfego para servidores distantes links externos podem
ser caros e facilmente congestionáveis
servidoresoriginais
Internetpública
redeinstitucional 10 Mbps LAN
enlace de acesso1.5 Mbps
cache institucional
Cap. 2: Camada de Aplicação 81
Análise simplificada
Tamanho médio dos objetos requisitados: 100.000 bits
15 requisições / segundo “Atraso da Internet”: 2s Atraso total:
LAN + acesso + Internet Intensidade de tráfego na
LAN:
Intens. de tráf. no acesso:
Congestionamento no enlace de acesso: atraso crescente
servidoresoriginais
Internetpública
redeinstitucional 10 Mbps LAN
enlace de acesso1.5 Mbps
(15 reqs/s) . (100kbits/req)/(10Mbps) = 0,15
(15 reqs/s) . (100kbits/req)/(1,5Mbps) = 1
Cap. 2: Camada de Aplicação 82
Análise: Com o Proxy
Taxa de acerto: 0,4 40% dos acessos: via
proxy• Atraso da LAN (0,01s)
60% dos acessos: servidor original
• Intes. tráf. no acesso: 0,6• Atraso: 2,01s
Atraso médio:
Na média, melhor do que um simples upgrade da “largura de banda” do enlace de acesso (e.g., para 10Mbps) Verificar!
servidoresoriginais
Internetpública
redeinstitucional 10 Mbps LAN
enlace de acesso1.5 Mbps
cache institucional
0,4*(0,01s) + 0,6*(2,01s) = 1,2s
Cap. 2: Camada de Aplicação 83
Caches Cooperativas
Múltiplos níveis de caches institucional, ISP, nacional
Caches de mais alto nível população de usuários maior maior taxa de acerto
ICP: Internet Caching Protocol uma forma eficiente para
uma cache consultar outra se esta possui o objeto
cliente
cache institucional
cache do ISP
cache nacional
Req.
Resp.
Req. Resp.
Req. Resp.
servidororiginalReq.
Resp.
Cap. 2: Camada de Aplicação 84
Caches Cooperativas
Outra técnica: Cluster de caches cada cache: um sub-conjunto dos objetos cliente (navegador) mapeia a URL sobre uma
tabela de espalhamento (hash), que determina qual das caches deve ser consultada
CARP: Cache Array Routing Protocol
cliente
hash(URL)cluster
de caches
Cap. 2: Camada de Aplicação 85
Outros Meios de Distribuição de Conteúdo
Redes de Distribuição de Conteúdo Seção 2.9.2, K&R 2nd Edition (em Inglês)
Compartilhamento de arquivos em redes de sobreposição (overlay networks) do tipo Peer-to-Peer Seção 2.9.3, K&R 2nd Edition (em Inglês)
Cap. 2: Camada de Aplicação 86
Redes de Distribuição de Conteúdo
Contrastando as Abordagens: Web Caches: o provedor de acesso (ISP)
arca com os custos de uma maior eficiência de acesso à Web para seus clientes
CDNs - Um modelo diferente: Provedor de conteúdo contrata uma empresa de
distribuição de conteúdo, a qual mantém a rede de distribuíção
Custo fica sob a responsabilidade do provedor de conteúdo
Cap. 2: Camada de Aplicação 87
Redes de Distribuição de Conteúdo
Provedor envia conteúdo para o nodo de distribuição da CDN
CDN replica o conteúdo nos seus diversos servidores de distribuição
Requisições de usuários são servidas pelo servidor com o melhor tempo de resposta mais próximo do usuário
servidororiginal
nodo dedistribuição
servidorde distribuiçãona Am. do Sul servidor
de distribuiçãona Europa
servidorde distribuição
na Am. do Norte
Cap. 2: Camada de Aplicação 88
Redes de Distribuição de Conteúdo
Como o navegador sabe qual o servidor de distribuição com o melhor tempo de resposta? Provedor original do
conteúdo serve a página principal do site
Demais páginas são marcadas com o nome de domínio da CDN
• serão servidas pela CDN Requisições do cliente são
redirecionadas pelo DNS
Página principal
(index.html)
Objeto referenciado
http://www.cdn.com/www.foo.com/
img.gif
Objeto referenciado
http://www.cdn.com/www.foo.com/
filme.mpeg
Distribuído pelo servidor original
Distribuído pela CDN
Cap. 2: Camada de Aplicação 89
Redes de Distribuição de Conteúdo
Redirecionamento via DNS
CDN configura o servidor de DNS autoritativo para responder de acordo com o IP do cliente
Tomando como base: tabelas de roteamento da Internet estatísticas de desempenho da rede
Cap. 2: Camada de Aplicação 90
Redes “Peer-to-Peer”
Idéia geral Não há um servidor (ou servidores) de
conteúdo centralizado Alto nível de escalabilidade
Cada computador ligado à rede é capaz de prover e requisitar conteúdo
Exemplo: Compartilhamento de arquivos MP3 em redes
como Napster, Kazaa, Gnutella
Cap. 2: Camada de Aplicação 91
Redes de Sobreposição (Overlay) Uma rede lógica construída sobre a Internet Conecta os vários computadores em uma
rede peer-to-peer Estrutura altamente dinâmica: nodos
podem ser inseridos ou removidos a todo tempo
Cap. 2: Camada de Aplicação 92
Redes Peer-to-Peer
Problema básico: Descobrir quais peers contêm o conteúdo desejado
Diretório Centralizado (ex.: Napster)
Diretório Distribuído (ex.: KaZaA)
Inundação de consultas (query flooding)
Cap. 2: Camada de Aplicação 93
Parte 2: Sumário
exigências dos serviços de aplicação: confiabilidade, banda
passante, atraso paradigma cliente-servidor modelo do serviço de
transporte da Internet l orientado à conexão,
confiável: TCP não confiável, datagramas:
UDP
Nosso estudo das aplicações está agora completo!
protocolos especificos: http ftp smtp, pop3 dns
programação de sockets implementação
cliente/servidor usando sockets tcp, udp
Cap. 2: Camada de Aplicação 94
Parte 2: Sumário
tipica troca de mensagens comando/resposta: cliente solicita informação
ou serviço servidor responde com
dados e código de status formatos das mensagens: cabeçalhos: campos que
dão informações sobre os dados
dados: informação sendo comunicada
Mais importante: características dos protocolos
controle vs. dados in-band, out-of-band
centralizado vs. descentralizado stateless vs. stateful transferência de mensagens
confiável vs. não confiável “complexidade na borda da
rede” segurança: autenticação