Redes de Computadores - UEMelvio/redes/7-Aplicacao.pdfCamada de Aplica»c~ao Introdu»c~ao Estudo de...

Post on 24-Apr-2020

2 views 0 download

Transcript of Redes de Computadores - UEMelvio/redes/7-Aplicacao.pdfCamada de Aplica»c~ao Introdu»c~ao Estudo de...

Camada de Aplicacao

Redes de Computadores7. Camada de Aplicacao

Elvio Leonardo

DIN/CTC/UEM

2008

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Principais FuncoesI Oferece servicos de rede aos processos da aplicacaoI Identifica e estabelece a disponibilidade dos recursos para a

comunicacaoI Sincroniza comunicacao entre as aplicacoesI Estabelece procedimentos para o caso de falhasI Exemplos de protocolos:

I Transferencia de arquivosI File Transfer Protocol (FTP)I Network File System (NFS)

I E-mailI Simple Mail Transfer Protocol (SMTP)I Internet Message Access Protocol (IMAP)I Post Office Protocol (POP)

I Remote loginI Terminal Emulation Protocol (TELNET)

I Gerencia de redeI Simple Network Management Protocol (SNMP)

I Gerencia de nomesI Domain Name System Protocol (DNS)

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

The Big Picture

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)I A Internet e construıda utilizando um esquema de

enderecamento hierarquicoI Roteamento e baseado em classes de enderecos ao inves de

enderecos individuais

I Problema: como associar o nome de um sıtio na Internet aoseu endereco na rede?

I Solucao: Domain Name System associa o nome de umdomınio (domain) ao seu endereco

I Domınio e um grupo de maquinas que estao associadas ougeograficamente ou funcionalmente

I Um nome de domınio e uma cadeia de caracteres (letras enumeros) que representam um nome ou uma abreviacao

I Todo domınio tem uma autoridade que controla a atribuicaode nomes de seus sub-domınios

I Exemplo: www.registro.br controla a atribuicao de enderecosterminados com .br

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)

I Nome de domınio e hierarquicoI Primeira parte carrega o nome da maquinaI Ultima parte carrega o nome do domınio de mais alto nıvelI Exemplo: robot.ai.cs.yale.edu

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)

I Alguns domınios no BrasilI gov.br: entidades do governoI org.br: entidades nao governamentais, sem fins lucrativosI com.br: atividades comerciaisI ind.br: industriasI mil.br: entidades militaresI edu.br: entidades de ensinoI g12.br: entidades de ensino fundamental e medioI .br: entidades de ensino superiorI art.br: artes: musica, pintura, folcloreI esp.br: entidades esportivasI inf.br: provedores de informacao (meios de comunicacao, etc.)I psi.br: provedores de servicos de InternetI tmp.br: eventos temporarios (feiras, etc.)I can.br: candidatosI am.br, fm.br, tv.br: emisoras de radio e televisaoI Lista completa: registro.br/info/dpn.html

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)I Componentes

I Resolver: cliente que solicita as requisicoesI Name Server: servidor que processa requisicoes e envia

respostaI Tipos de servidores

I PrimarioI Informacoes criadas pelo administrador do domınioI Unico por domınio

I SecundarioI Mantem copia das informacoes do domınioI Periodicamente atualiza as informacoes

I Tipos de requisicoesI Nao Recursiva (Interativa)

I Servidor utiliza apenas as suas informacoesI Retorna informacao que mais se aproxima daquela requisitada

I RecursivaI Servidor utiliza as suas informacoes e pode requisitar

informacoes de outros servidoresI Retorna informacao solicitada pela requisicao

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)I Tipos de respostas

I AuthoritativeI Servidor possui autoridade sobre o domınioI Respostas sempre corretas

I Non-AuthoritativeI Servidor nao possui autoridade sobre o domınioI Informacao obtida a partir da cacheI Informacoes podem estar incorretas

Dialogo tıpico

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)I Tipos de mapeamentos

I DiretoI Traduz nome da maquina para o seu endereco IP

I ReversoI Traduz o endereco IP para o nome da maquinaI Domınio in-addr.arpa realiza o mapeamento inversoI Exemplo: 52.0.2.10.in-addr.arpa contem informacao sobre

endereco 10.2.0.52I Outras informacoes

I Utiliza UDP nas comunicacoesI Servidores operam seguindo a hierarquia dos nomesI Nomes de domınios nao diferenciam maiusculo e minusculoI Cada componente do nome pode ter ate 63 caracteres, e

nomes completos ate 255 caracteresI Nomes de domınios seguem divisoes polıticas e organizacionais

e nao existe relacao entre hierarquia DNS e enderecos IPI Somente o nıvel mais alto e globalmente regulamentado

I Por exemplo, Nova Zelandia e Gra Bretanha utilizam .ac emvez de .edu e .co em vez de .com

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)I Servidor DNS

I Aceita requisicoes para traducao de nomesI Cada servidor tem informacao segura sobre certos nomes

(configurados pelo administrador) e inseguranca sobre outros(armazenados em cache)

I Um servidor deve ter informacao segura sobre todos ossub-domınios da sua zona ou conhecer o endereco de outrosservidores que a tenham

I Servidores cobrem regioes nao sobrepostas no espaco de nomesI Todos os servidores podem encontrar o servidor raiz

I CachingI Todo servidor (e clientes tambem) devem armazenar

informacao obtida de transasoes anterioresI Essa pratica funciona bem porque a informacao e

relativamente estatica e em geral utilizada varias vezesI Recursivo ou interativo?

I Clientes normalmente utilizam recursivoI Servidores (atuando como clientes) utilizam interativo

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)I Resource Records

I Todos os domınios tem informacao associada a elesI Um resource record consiste de:

I nome do domınioI tempo de vida (time to live) em segundosI classe (sempre IN para Internet)I tipo de registro (record)I valor do registro

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)I Resource Records

I Start of Authority (SOA)domain ttl IN SOA origin contact (serial refresh retry expire

minimum)

I domain: nome desse domınioI ttl: tempo (em segundos) que clientes devem armazenar a

informacao desse registroI origin: nome do servidor que mantem esse registroI contact: e-mail do administrador desse domınioI serial: versao do registroI refresh: intervalo (em segundos) de atualizacao do servidor

DNS secundarioI retry: intervalo (em segundos) de retentativa de atualizacao

do servidor DNS secundarioI expire: validade (em segundos) da informacao mantida pelo

servidor DNS secundarioI minimum: tempo que o servidor DNS secundario mantem a

informacao desse registro

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)I Resource Records

I Name Server (NS)domain ttl IN NS server

I server: nome do servidor com informacao segura sobre essedomınio

I Address v4 (A) e v6 (AAAA)host ttl IN A address

host ttl IN AAAA address

I host: nome da maquinaI address: endereco IP da maquina

I Main Exchanger (MX): define o servidor de e-maildomain ttl IN MX preference host

I preference: prioridade do servidor

I Canonical Name (CNAME): define um apelidonickname ttl IN CNAME host

I nickname: apelido (alias)

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)I Resource Records

I Pointer (PTR): converte endereco IP em nome de maquinaname ttl IN PTR host

I name: endereco IP no formato in-addr.arpa

I Well Known Services (WKS): identifica servicos disponıveishost ttl IN WKS address protocol service

I protocolo: protocolo de transporte (exemplo, TCP)I service: lista de servicos (exemplo, snmp ftp www)

I Host Information (HINFO)host ttl IN HINFO hardware software

I hardware: identifica o hardware da maquinaI software: identifica o sistema operacional da maquina

I Notacoes especiaisI Sımbolo @ substitui domınio origemI Nomes completos no 1o campo sao terminados com pontoI Nomes terminados sem ponto devem ser complementados com

domınio de origem (exemplo, rowboat = rowboat.cs.vu.nl.)

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)I Exemplo de Resource Records

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)

I Berkeley Internet Name Domain (BIND)I Implementacao mais utilizada em sistemas UNIXI Componentes: Resolver, Name Server e arquivos de dados do

domınio (resource records)I Configuracao do Resolver

I Contem nome do domınio padrao (default)I Contem nome do(s) servidor(es) de nomes utilizado(s)I Armazenada no arquivo /etc/resolv.conf

I Exemplo

domain redes.unb.br → domınio default

nameserver 164.41.67.130 → servidor de nomes 1

nameserver 164.41.67.131 → servidor de nomes 2

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Domain Name System (DNS)

I Berkeley Internet Name Domain (BIND)I Configuracao do Name Server

I Armazenada no arquivo /etc/named.boot

I Algumas linhas de exemplo (para BIND 8.2)

options {directory "/var/named"; → diretorio dos arquivos de dados

forwarders {10.0.0.1;10.0.0.2;}; → para onde encaminhar perguntas

forward first; → encaminha antes de tentar resolver

allow-recursion {192.168.3.0/24;}; → recursao so para hosts locais

};

zone "." { → informacao sobre um domain

type hint; → informacao sobre root domain

file "root.servers"; → onde informacao esta

};zone "example.com" in {

type master;

file "master/master.example.com";

allow-transfer {192.168.23.1;};};

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio EletronicoI Uma das primeira aplicacoes a se beneficiarem da

interconexao de computadores em redesI Atualmente ubıquo (onipresente)I Muitas semelhancas com o sistema postal (snail mail)I Especificacao da Internet prevaleceu apesar de esforcos para

padronizacao internacional (com X.400)I Caracteristicas do servico

I Confiavel, com confirmacao de recebimento opcionalI Servico sem conexao (exemplo de servico sem conexao usando

protocolo orientado a conexao, por exemplo TCP)I Protocolos especificam transferencia de arquivos, formato e

codificacao da mensagem, e formato do enderecoI Funcoes: compor, transferir, reportar, mostrar e disporI Outras funcoes: auto-encaminhar, responder “em ferias”,

mailing lists, alta prioridade, filtrar, etc.I Dois subsistemas: User Agent e Message Transfer Agent

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio EletronicoI Especificacao

I RFCs 821 e sucessor 2821: protocolo de transmissaoI RFCs 822 e sucessor 2822: formato da mensagem

I Arquitetura

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio EletronicoI User Agent

I Composicao e exibicao da mensagemI Disposicao da mensagem

(eliminacao, arquivamento,encaminhamento)

I Comunicacao com o MTA localI Espera endereco no formato:

username@domain

I Muitos exemplos: Outlook,Thunderbird, Eudora, etc.

I Message Transfer AgentI Mantem mensagens ainda nao lidasI Controla fila de mensagens a serem

enviadasI Protocolo SMTP (Simple Message

Transfer Protocol) permite troca demensagens entre MTAs

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio Eletronico

I SMTPI Cliente SMTP estabelece conexao TCP com os servidores

SMTP destinatarios utilizando porta 25I Dialogo composto de 3 fases: Handshaking, Transferencia de

mensagens, e FechamentoI Mensagem (corpo e cabecalho) deve utilizar apenas

codificacao ASCII de 7 bitsI Exemplo de dialogo:

S: 220 hamburger.edu

C: HELO crepes.fr

S: 250 Hello crepes.fr, pleased to meet you

C: MAIL FROM: <alice@crepes.fr>

S: 250 alice@crepes.fr... Sender ok

C: RCPT TO: <bob@hamburger.edu>

S: 250 bob@hamburger.edu ... 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

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio EletronicoI SMTP

I Utiliza conexoes persistentes (varios request-reply em umamesma conexao)

I Fim da mensagem indicada por CRLF . CRLF

I Tente usar o SMTP voce mesmo (como enviar um e-mail semter o cliente):

I Digite telnet servername 25I Deve aparecer uma resposta 220 do servidorI Utilize os comandos HELO, MAIL FROM, RCPT TO, DATA, QUIT

l

I Formato da mensagemI Originalmente apenas texto ASCIII Definido o Multipurpose Internet

Mail Extension (MIME) paramultimıdia, outros idiomas que nao oingles, etc.

I Conteudos em diversos formatosdefinidos na RFC 1521

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio EletronicoI Cabecalho (header) da mensagem

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio EletronicoI MIME

I Protocolo que permite a transmissao de dados nao-textoI Cabecalho indica conteudo do tipo MIME

Cabecalho MIME

Exemplo de cabecalho

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio EletronicoI MIME

I Tipos e subtipos

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio Eletronico

I Protocolos de acessoI SMTP (ou ESMT) entrega e armazena no servidor do destinoI Como o usuario acessa e recupera as mensagens?

I Utilizando um protocolos de acessoI Post Office Protocol (POP): usuarios apenas fazem o

download de mensagens; oferece funcionalidade reduzida;difıcil para o usuario movel

I Internet Mail Access Protocol (IMAP): mais complexo;permite manipulacao de mensagens armazenadas no servidor

I HTTP (exemplo, Hotmail , Yahoo!Mail, etc.)

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio Eletronico

I POP3I Permite que o UA contacte o MTA para copiar mensagensI Apos conexao, dialogo passa por 3 estados: Autorizacao,

Transacao, e AtualizacaoI Alguns comandos

I USER: especifica usuarioI PASS: especifica senhaI STAT: obtem quantidade de mensagensI LIST: obtem lista e tamanhos das mensagensI RETR: recupera mensagemI DELE: marca mensagem para descarteI QUIT: descarta mensagens marcadas e fecha conexao TCP

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio Eletronico

I Exemplo de dialogo POP

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Correio EletronicoI Comparacao POP e IMAP

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Transferencia de ArquivosI File Transfer Protocol (FTP)

I Transferencia de arquivo de/para host remoto (veja RFC 959)I Modelo cliente-servidor (cliente inicia transferencia)I Dialogo:

I Cliente contacta servidor utilizando TCP na porta 21 eestabelece conexao de controle

I Cliente obtem autorizacao para acessoI Cliente navega pelo sistema remoto de diretoriosI Ao receber um um pedido de transferencia de arquivo, servidor

estabele uma conexao de dados com o cliente utilizando TCPna porta 20

I Apos transferencia de arquivo, conexao de dados e fechadaI Servidor mantem estado da conexaoI Dados e controle utilizam canais separados

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Transferencia de ArquivosI File Transfer Protocol (FTP)

I ComandosI enviados como texto ASCII

pelo canal de controleI USER username

I PASS password

I LIST: lista de arquivos nodiretorio atual

I RETR filename: retrieveI STOR filename: store

I RespostasI Codigo seguido de frase

(similar ao HTTP)I 331 Username OK, password

required

I 125 data connection already

open; transfer starting

I 425 Can’t open data

connection

I 452 Error writing file

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Transferencia de Arquivos

I File Transfer Protocol (FTP)I FTP original e inseguro porque senhas, arquivos, comandos e

respostas sao enviados sem encriptacao (podem ser captadospor um packet sniffer)

I A solucao usual a esse problema e utilizar SFTP (SSH FileTransfer Protocol) ou FTPS (FTP over SSL) (veja RFC 4217)

I FTP utiliza multiplas conexoes TCP: 1 para controle e 1 paracada download, upload ou listing

I Alta latencia devido ao numero de comandos para iniciar atransferencia

I Nao existe verificacao de integridade no receptor; se atransferencia e interrompida o receptor nao consegue saber seo arquivo esta completo ou nao

I Alguns servidores utilizam checksum

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Ou simplesmente Web

I Estrutura para acesso de documentos conectados e espalhadospelo globo

I Milhoes de maquinas conectadas

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)I Uma pagina da Web e composta de objetos

I A base e um arquivo HTML (Hypertext Markup Language)que inclui referencia a varios outros objetos

I Objetos podem ser arquivo HTML, imagem JPEG, appletJava, arquivo de audio, etc.

I Cada objeto tem um endereco URL (Uniform ResourceLocator)

I Exemplo URL: http://www.uem.br/din/pics/pic.gifprotocolo html, domınio www.uem.br, diretorio din/pics, earquivo pic.gif

I Lado do cliente (browser)I Interpretador HTMLI Paginas nao HTML com uso de helpers, plug-ins

I Lado do servidorI Otimizacao para acesso rapido: server farms, multithreading,

etc.

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Uniform Resource Locator (URL)

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)I Especifica regras para a interacao cliente-servidor

I Cliente utiliza browser que faz pedidos, recebe e mostraobjetos

I Servidor envia objetos em resposta aos pedidos

I Camada de aplicacao da WebI HTTP/1.0: veja RFC 1945I HTTP/1.1: veja RFC 2616

I Tipicamente utiliza TCP como protocolo de transporteI Operacoes HTTP sao denominadas metodosI Requisicao consiste de 1 ou mais linhas de texto ASCII

especificando o metodo na primeira linhaI Resposta consiste de linha de status (com codigo de 3 dıgitos)

e possivelmente informacao adicional

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)

I Utiliza TCP porta 80

I Cliente inicia conexao e solicita

objetos

I Servidor aceita conexao e responde

as requisicoes

I Ao final conexao TCP e fechada

I Conexao HTTP nao tem estados

I Servidor nao mantem qualquer

informacao sobre as requisioes dos

clientes

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)I Exemplo de operacao

I Usuario entra com a URL www.uem.br/home.html

Cliente HTTP inicia conexão TCP, porta 80, para servidor

HTTP de www.uem.br

Servidor HTTP em www.uem.br espera

conexões TCP na porta 80

Servidor aceita conexão e avisa cliente

Cliente envia request message (contendo a URL)

para servidor Servidor recebe pedido, monta response message

contendo o objeto solicitado e envia

Servidor fecha conexão

Cliente recebe resposta contendo objeto e

apresenta o conteúdo

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)I Hypertext Transfer Protocol (HTTP)

I Nao-persistenteI 1 objeto e enviado por conexao TCPI Servidor analisa pedido, envia resposta e fecha conexao TCPI HTTP/1.0 opera dessa maneiraI 2 RTT (Round Trip Time) para obter 1 objetoI Sofre com slow start do TCPI Browsers usualmente abrem varias conexoes paralelas

I PersistenteI Na mesma conexao TCP varios objetos sao trazidos

I Persistent sem pipeliningI Nova requisicao enviada somente apos receber resposta

anteriorI 1 RTT por objeto

I Persistent com pipeliningI Requisicoes enviadas assim que objetos referenciados sao

encontradosI Com sorte, 1 RTT por todos os objetosI Modo default para HTTP/1.1

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)I Hypertext Transfer Protocol (HTTP)

I Mensagens: request e responseI Formato ASCII para leitura por humanos

I Mensagem de requisicao: formato

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)I Mensagem de requisicao: exemplo

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)I Mensagem de requisicao: metodos (ou verbos)

I HEAD: mesma resposta obtida com o GET mas sem o corpo damensagem de resposta

I GET: requisita o objeto especificadoI POST: submete dados para serem processados (por exemplo,

formulario HTML)I PUT: upload objeto especificadoI DELETE: apaga o objeto especificadoI TRACE: ecoa a requisicao recebidaI OPTIONS: retorna os metodos HTTP respaldados pelo servidorI CONNECT: converte conexao em um tunel TCP/IP (usualmente

para converter para conexao encriptada)

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)I Mensagem de resposta: exemplo

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)I Mensagem de resposta: codigos de status

I 1xx: informacao; requisicao recebida e sendo processadaI 2xx: sucesso; requisicao recebida, entendida e aceitaI 3xx: redirecao; cliente necessita procedimentos adicionais para

completar requisicaoI 4xx: erro do cliente; sintaxe ruim ou requisicao nao pode ser

atendida pelo servidorI 5xx: erro do servidor; requisicao valida mas que nao pode ser

atendida

100 Continue servidor recebeu cabecalho da requisicaoe precisa do corpo da mensagem

200 OK requisicao foi bem-sucedida301 Moved Permanently objeto requisitado foi movido

permanentemente; nova URL no campoLocation da mensagem de resposta

400 Bad Request requisicao nao pode ser atendida404 Not Found documento requisitado nao existe505 HTTP Version Not Supported versao HTTP nao e respaldada pelo servidor

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)I Faca Voce Mesmo

I Conecte-se a um servidor HTTP e abra uma conexao TCP naporta 80telnet www.din.uem.br 80

I Digite um pedido GET e tecle 2 vezes carriage returnGET /~elvio/index.html HTTP/1.0

I Verifique a resposta

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)I Autenticacao

l

I Objetivo: controlar acesso ao servidor

I Sem estados: cliente apresenta autorizacao acada requisicao

I Autorizacao: tipicamente nome e senha

I authorization colocada em linha no

cabecalho

I Se ausente, servidor recusa acesso e envia

WWW authenticate

I Browser mantem nome e senha em cachepara evitar que usuario tenha que digita-losseguidamente

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)I Cookie

l

I Servidor envia cookie ao cliente em umamensagem de respostaExemplo: Set-cookie: 1678453

I Cliente apresenta o cookie em requisicoesfuturasExemplo: cookie: 1678453

I Servidor compara informacao recebida

com informacao armazenada para:

I autenticacao;

I lembrar preferencias do usuario,

escolhas anteriores, etc.

I Desvantagens: permitem obterinformacao sobre usuario (nome, e-mail,etc.)

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

I Hypertext Transfer Protocol (HTTP)I GET Condicional

l

I Objetivo: evitar que servidor envieobjeto que ja esta armazenado nocliente (em cache)

I Cliente especifica data do objetoarmanezando na requisicaoIf-modified-since: date

I Resposta do servidor nao contemdados se o objeto armazenado estaatualizadoHTTP/1.0 304 Not Modified

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)I Proxy Server (Web Cache)

I Objetivo: atender o cliente sem envolver o servidor de Weboriginador da informacao

I Usuario configura browser para realizar acesso atraves de umproxy

I Cliente envia todas as requisicoes HTTP para proxy serverI Se o objecto existe na cache ele e retornadoI Ou proxy server solicita do servidor original

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

World Wide Web (WWW)

ll

I Proxy Server (Web Cache)I Porque Web Caching?

I Armazenamento “perto”do cliente

I Menor tempo de respostaI Reduz trafego com

servidor distanteI Menor custo com enlaces

externos

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Peer to Peer (P2P)

l

I Rede do tipo ad-hoc

I Presenca do servidor nemsempre necessaria

I Computadores finais podemcomunicar-se diretamente

I Peers (parceiros) estaoconectados intermitentemente(nem sempre com o mesmoendereco IP)

I Facil de ser expandido masdifıcil de ser gerenciado

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Peer to Peer (P2P)

I Procura extrair vantagem da grande quantidade de recursosdisponıveis na borda da rede

I Operacao basica e de compartilhamento de arquivosI Afilia-se a redeI Publica e compartilha arquivosI Procura por arquivosI Obtem arquivo

I Aplicacoes:I Compartilhamento de arquivos (audio, vıdeo, codigo)I Telefonia (Skype)I Comunicacao (Instant Messaging)I JogosI TV (Joost)

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Peer to Peer (P2P)

I Questao: Quanto tempo seria necessario para 1 servidordistribuir um arquivo para N parceiros?

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Peer to Peer (P2P)

I Distribuicao de arquivos: BitTorrent

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Peer to Peer (P2P)I Distribuicao de arquivos: BitTorrent

I Arquivo e dividido em pedacos com 256KBI Peer entrando na torrent:

I Nao tem nenhum pedaco; vai acumula-los ao longo do tempoI Registra-se com tracker e consegue uma lista de peersI Conecta-se a subconjundo de peers (denominados vizinhos)

I Peer recebe e envia pedacos ao mesmo tempoI Uma vez que o arquivo completo foi obtido, peer pode deixar

torrent ou permanecer ajudando outrosI Obtendo pedacos

I Em um instante qualquer, cada peer pode ter um subconjuntodiferente de pedacos do arquivo

I Cada peer pergunta aos vizinhos quais pedacos eles tem esolicita primeiro transferencia daqueles mais raros

I Enviando pedacosI Peer envia a 4 vizinhos na mais alta taxa de que capaz e

espera o mesmo tratamentoI A posicao desses 4 vizinhos e reavalizada a cada 10 segundosI A cada 30 segundos um outro peer e escolhido aleatoriamente

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Peer to Peer (P2P)

I Busca por informacaoI Index: relaciona informacao a localizacao do peer (endereco IP

e numero de porta)I Compartilhamento de arquivos (e-mule)

I Index rastreia localizacao dos arquivos compartilhadosI Peers precisam comunicar index o que eles temI Peers procuram no index arquivos que eles querem

I Comunicacao (Instant messaging, IM)I Index relaciona nomes a localizacoesI Quando um usuario comeca a aplicacao IM ele informa a sua

localizacaoI Peers buscam no index o endereco IP dos usuarios

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Peer to Peer (P2P)

l

I Index centralizadoI Arquitetura do Napster

original

1. Quando peer conecta-se,ele informa ao servidorcentral o seu endereco IP eo seu conteudo

2. Alice pergunta por umartigo

3. Alice pede arquivo a Bob

I Problemas:I Ponto unico de falhaI Possıvel engarrafamento

no servidorI Pirataria: alvo e obvio

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Peer to Peer (P2P)

I Index descentralizado: Query floodingI Sem servidor central; totalmente descentralizado

I Usado por GnutellaI Cada peer indexa os arquivos que ele mantem para

compartilhamento

I Utiliza rede em grafo construıda sobre rede fısicaI Enlace entre peers X e Y significa que existe uma conexao

TCP entre elesI Cada peer esta conectado a ate 10 vizinhos

I Query floodingI Mensagem de Query enviada por TCP ao vizinhosI Vizinhos encaminham adiante QueryI Quando ıtem e encontrado, mensagem QueryHit e

encaminada no sentido inverso

Elvio Leonardo Redes de Computadores

Camada de AplicacaoIntroducaoEstudo de Caso

Peer to Peer (P2P)I Query flooding

Elvio Leonardo Redes de Computadores