Capítulo 2: Camada de AplicaçãoMetas do capítulo:Ø aspectos conceituais e de
implementação de protocolos de aplicação em redes
ü paradigma cliente servidor
Mais metas do capítuloØ protocolos específicos:
ü HTTPü FTPü SMTP / POP3 / IMAP
DNS
2: Camada de Aplicação 1
paradigma cliente servidor
ü modelos de serviçoØ aprenda sobre protocolos
através do estudo de protocolos populares do nível da aplicação
ü DNS
Ø a programação de aplicações de rede
ü programação usando sockets
Aplicações de rede: algum jargão
Ø Um processo é um programa que executa num hospedeiro (host).
Ø 2 processos no mesmo hospedeiro se comunicam usando comunicação entre
Ø Um agente de usuário (UA) é uma interface entre o usuário e a aplicação de rede.
ü WWW: browser
2: Camada de Aplicação 2
usando comunicação entre processos definida pelo sistema operacional (SO).
Ø 2 processos em hospedeiros distintos se comunicam usando um protocolo da camada de aplicação.
ü WWW: browserü Correio:
leitor/compositor de mensagens
ü streaming audio/video: tocador de mídia
Aplicações e protocolos da camada de aplicação
Aplicação: processos distribuídos em comunicação
ü executam em hospedeiros no “espaço de usuário”
ü trocam mensagens para implementar a aplicaçãop.ex., correio, transf. de
aplicaçãotransporte
redeenlacefísica
2: Camada de Aplicação 3
ü p.ex., correio, transf. de arquivo, WWW
Protocolos da camada de aplicaçãoü uma “parte” da aplicaçãoü define mensagens trocadas
por apls e ações tomadasü usam serviços providos por
protocolos de camadas inferiores (TCP, UDP)
aplicaçãotransporte
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
Camada de aplicação define:
Ø Tipo das mensagens trocadas: ex, mensagens de requisição & resposta
Ø Sintaxe das mensagens: quais os campos de uma mensagem & como estes
Protocolos de domínio público:
Ø Definidos por RFCsØ Garante
interoperabilidade
2: Camada de Aplicação 4
mensagem & como estes são delineados;
Ø Semântica dos campos: qual o significado das informações nos campos;
Ø Regras: definem quando e como os processos enviam & respondem mensagens;
interoperabilidadeØ ex, HTTP, SMTPProtocolos proprietários:Ø ex, KaZaA
• Cliente-servidor
• Peer-to-peer (P2P)
• Híbrida de cliente-servidor e P2P
Arquiteturas de aplicação
2: Camada de Aplicação 5
• Híbrida de cliente-servidor e P2P
Paradigma cliente-servidor (C-S)
Apl. de rede típica tem duas partes: cliente e servidor
aplicaçãotransporte
redeenlacefísicaCliente:
Ø inicia contato com o servidor (“fala primeiro”)
Ø tipicamente solicita serviço do
pedido
2: Camada de Aplicação 6
aplicaçãotransporte
redeenlacefísica
Ø tipicamente solicita serviço do servidor
Ø para WWW, cliente implementado no browser; para correio no leitor de mensagens
Servidor:Ø provê ao cliente o serviço
requisitadoØ p.ex., servidor WWW envia
página solicitada; servidor de correio entrega mensagens
resposta
Arquitetura cliente-servidor
Clientes:
Servidor:• Hospedeiro sempre ativo• Endereço IP permanente• Fornece serviços solicitados pelo cliente
2: Camada de Aplicação 7
Clientes:• Comunicam-se com o servidor• Pode ser conectado intermitentemente
• Pode ter endereço IP dinâmico• Não se comunicam diretamente uns com os
outros
Classification of Servers
Ø Concurrent connectionless serverØ Concurrent connection-oriented serverØ Iterative connectionless serverØ Iterative connection-oriented server
8
Ø Iterative connection-oriented server
Chapter 6: Application Layer
• Nem sempre no servidor• Sistemas finais arbitrários comunicam-se diretamente
• Pares são intermitentemente conectados e trocam endereços IP
• Ex.: Gnutella
Arquitetura P2P pura
2: Camada de Aplicação 9
• Ex.: Gnutella
Altamente escaláveis mas difíceis de gerenciar
Napster• Transferência de arquivo P2P• Busca centralizada de arquivos:
• Conteúdo de registro dos pares no servidor central• Consulta de pares no mesmo servidor central para localizar o
conteúdo
Híbrida de cliente-servidor e P2P
2: Camada de Aplicação 10
Instant messaging• Bate-papo entre dois usuários é P2P• Detecção/localização centralizada de presença:
• Usuário registra seu endereço IP com o servidor central quando fica on-line
• Usuário contata o servidor central para encontrar endereços IP dos vizinhos
Processo: programa executando num hospedeiro• Dentro do mesmo hospedeiro: dois processos se comunicam usando comunicação interprocesso (definido pelo OS)
• Processos em diferentes hospedeiros se comunicam por meio de troca de mensagens
Comunicação de processos
2: Camada de Aplicação 11
mensagens
• Processo cliente: processo que inicia a comunicação
• Processo servidor: processo que espera para ser contatado
Nota: aplicações com arquiteturas P2P possuem processos cliente e processos servidor
Comunicação entre processos na redeØ processos se comunicam
enviando ou recebendo mensagens através de um socket;
Ø socketü O processo emissor joga a
mensagem por seu socket;processo
socket
host ou
servidor
processo
socket
host ou
servidor
Controlado pelo
Desenvolvedor
da aplicação
2: Camada de Aplicação 12
mensagem por seu socket;ü O processo emissor assume
que há uma infra-estrutura de transporte no lado oposto do socket que irá transmitir a mensagem até o socket do processor receptor;
TCP com
buffers,
Variáveis
TCP com
buffers,
Variáveis
Internet
Controlado
pelo OS
Ø API: (1) escolhe do protocolo de transporte; (2) habilidade para fixar alguns parâmetros (voltamos mais tarde a este assunto)
Identificando processos:Ø Para que um processo
possa receber mensagens, ele precisa ter um identificador;
Ø Cada host tem um endereço único de 32 bits – endereço IP;
Ø O identificador inclui tanto o endereço IPcomo também o número de porta associado com o processo no host;
Ø Exemplo de número de
2: Camada de Aplicação 13
– endereço IP;Ø Q: O endereço IP de um
host no qual um processo está executando é suficiente para identificar este processo?
Ø Resposta: Não, muitos processos podem estar em execução em um mesmo host
Ø Exemplo de número de portas:
ü Servidor HTTP: 80ü Servidor de Correio: 25
Ø Voltaremos a este assunto mais tarde
De que serviço de transporte uma aplicação precisa?Perda de dadosØ algumas apls (p.ex. áudio)
podem tolerar algumas perdas
Ø outras (p.ex., transf. de arquivos, telnet) requerem transferência 100%
Largura de bandaØ algumas apls (p.ex.,
multimídia) requerem quantia mínima de banda para serem “viáveis”
Ø outras apls (“apls elásticas”)
2: Camada de Aplicação 14
transferência 100% confiável
TemporizaçãoØ algumas apls (p.ex.,
telefonia Internet, jogos interativos) requerem baixo retardo para serem “viáveis”
Ø outras apls (“apls elásticas”) conseguem usar qualquer quantia de banda disponível
Requisitos do serviço de transporte de apls comuns
Aplicação
transferência de arqscorreio
documentos WWWáudio/vídeo de
Perdas
sem perdassem perdassem perdastolerante
Banda
elásticaelásticaelásticaáudio: 5Kb-1Mb
Sensibilidade temporal
nãonãonãosim, 100’s mseg
2: Camada de Aplicação 15
áudio/vídeo detempo real
áudio/vídeo gravadojogos interativosapls financeiras
tolerante
tolerantetolerantesem perdas
áudio: 5Kb-1Mbvídeo:10Kb-5Mbcomo anterior> alguns Kbpselástica
sim, 100’s mseg
sim, alguns segssim, 100’s msegsim e não
Serviços providos por protocolos de transporte Internet
serviço TCP:Ø orientado a conexão:
negociação e definição da conexão (setup) requerida entre cliente, servidor
Ø transporte confiável entre processos remetente e
serviço UDP:Ø transferência de dados não
confiável entre processos remetente e receptor
Ø não provê: setup da conexão, confiabilidade, controle de
2: Camada de Aplicação 16
Ø transporte confiável entre processos remetente e receptor
Ø controle de fluxo: remetente não vai sobrecarregar o receptor
Ø controle de congestionamento:estrangular remetente quando a rede está sobrecarregada
Ø não provê: garantias temporais ou de banda mínima
confiabilidade, controle de fluxo, controle de congestionamento, garantias temporais ou de banda mínima
P: Qual é o interesse em ter um UDP?
Apls Internet: seus protocolos e seus protocolos de transporte
Aplicação
correio eletrônicoaccesso terminal remoto
WWW transferência de arquivos
Protocolo da camada de apl
smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959]
Protocolo de transporte usado
TCPTCPTCPTCP
2: Camada de Aplicação 17
transferência de arquivosstreaming multimídia
servidor de arquivo remototelefonia Internet
ftp [RFC 959]proprietário(p.ex. RealNetworks)NSFproprietário(p.ex., Vocaltec)
TCPTCP ou UDP
TCP ou UDPtipicamente UDP
WWW e HTTP: algum jargão
Ø Página WWW:ü consiste de “objetos”ü endereçada por uma URL
Ø Quase todas as páginas WWW consistem de:
Ø Agente de usuário para WWW se chama de browser:
ü MS Internet Explorerü Netscape Communicator
Servidor para WWW se
2: Camada de Aplicação 18
WWW consistem de:ü página base HTML, eü vários objetos
referenciados.
Ø URL tem duas partes: nome de hospedeiro, e nome de caminho:
Ø Servidor para WWW se chama “servidor WWW”:
ü Apache (domínio público)ü MS Internet Information
Server (IIS)
www.someschool.edu/someDept/pic.gif
nome do host nome do caminho
Web Naming and Addressing
Ø Uniform Resource Identifier (RFC 2396)Ø Uniform Resource Locator (RFC 1738)Ø Uniform Resource Name (RFC 2141)
19
http:
ftp:
gopher:
etc.
urn:URLs
URNs
URNs
Chapter 6: Application Layer
Uniform Resource IdentifierØ What is URI?
ü A compact string of characters for identifying an abstract or physical resource.
Ø URI syntax:ü Absolute URI: <scheme>:<scheme-specific-part>ü Generic URI: <scheme>://<authority><path>?<query>URI examples:
20
Ø URI examples:ü http://speed.cis.nctu.edu.tw/~ydlin/index.html#Booksü http://www.google.com/search?q=linuxü ftp://ftp.cis.nctu.edu.tw/Documents/IETF/rfc2300~2399/r
fc2396.txtü mailto: [email protected]ü news: comp.os.linuxü telnet://bbs.cis.nctu.edu.tw/ü ../icons/logo.gif
Chapter 6: Application Layer
Uniform Resource LocatorØ What is URL?
ü A compact string representation of the location for a resource that is available via the Internet
Ø URL syntax:ü <service>://<user>:<password>@<host>:<port>/<url-path>
Service Description
21
Service Description
ftp File Transfer protocol
http Hypertext Transfer Protocol
gopher The Gopher protocol
mailto Electronic mail address
news USENET news
nntp USENET news using NNTP access
telnet Reference to interactive sessions
wais Wide Area Information Servers
file Host-specific file names
prospero Prospero Directory Service
Chapter 6: Application Layer
Uniform Resource Locator (cont.)Ø Some URL examples:
ü http://www.cis.nctu.edu.tw/chinese/ccg/titleMain.gif
ü ftp://john:[email protected]/projects/book.txt
22
k.txtü nntp://news.cis.nctu.edu.tw/cis.course.computer-
networks/5238ü telnet://mail.cis.nctu.edu.tw:110/ü mailto: [email protected]
Chapter 6: Application Layer
Uniform Resource Name
Ø What is URN? ü A name that identifies a resource of unit of information independent of its location
Ø URN syntax:ü <URN> ::= "urn:" <NID> ":" <NSS>ü NID: Namespace Identifier
23
ü NID: Namespace Identifierü NSS: Namespace Specific String
Ø URN examples:ü urn:path:/A/B/C/doc.htmlü urn:ans:cis.nctu.edu.tw/ydlin/Resourceü urn:isbn:0-201-56317-7
Ø URN resolutioin:ü http://www.isbn.com/0-201-56317-7
Chapter 6: Application Layer
Protocolo HTTP: visão geral
HTTP: hypertext transfer protocol
Ø protocolo da camada de aplicação para WWW
Ø modelo cliente/servidor
PC executaExplorer
2: Camada de Aplicação 24
ü cliente: browser que pede, recebe, “visualiza” objetos WWW
ü servidor: servidor WWW envia objetos em resposta a pedidos
Ø http1.0: RFC 1945Ø http1.1: RFC 2068
Servidor executandoservidor WWW do NCSA
Mac executaNavigator
Mais sobre o protocolo HTTP
HTTP: serviço de transporte TCP:
Ø cliente inicia conexão TCP (cria socket) ao servidor, porta 80servidor aceita conexão TCP
HTTP é “sem estado”Ø servidor não mantém
informação sobre pedidos anteriores do cliente
Protocolos que mantêm Nota
2: Camada de Aplicação 25
Ø servidor aceita conexão TCP do cliente
Ø mensagens HTTP (mensagens do protocolo da camada de apl) trocadas entre browser (cliente HTTP) e servidor e WWW (servidor HTTP)
Ø encerra conexão TCP
Protocolos que mantêm “estado” são complexos!
Ø história passada (estado) tem que ser guardada
Ø Caso servidor/cliente parem de executar, suas visões do “estado” podem ser inconsistentes, devendo então ser reconciliadas
Nota
Conexões HTTPHTTP: não persistenteØ No máximo um objeto
é enviado em uma conexão TCP;
Ø HTTP/1.0 usa conexões não
HTTP: persistenteØ Múltiplos objetos podem
ser enviados numa única conexão TCP entre o servidor e o cliente;
Ø HTTP/1.1 usa conexões
2: Camada de Aplicação 26
conexões não persistentes
Ø HTTP/1.1 usa conexões persistentes no modo default;
Ex: HTTP não-persistenteSupomos que usuário digita a URL
www.algumaUniv.br/algumDepartmento/inicial.index
1a. Cliente http inicia conexão TCP com o servidor http (processo) www.algumaUniv.br. Porta 80 é padrão para servidor http.
1b. servidor http no hospedeiro www.algumaUniv.br espera por conexão TCP na porta 80. “aceita” conexão, avisando ao
(contém texto,
referências a 10
imagens jpeg)
2: Camada de Aplicação 27
2. cliente http envia mensagem de pedido de http (contendo URL) através do socket da conexão TCP. A mensgem indica qeu o cliente deseja o objeto someDepartment/home.index
conexão TCP na porta 80. “aceita” conexão, avisando ao cliente
3. servidor http recebe mensagem de pedido, formula mensagem de resposta contendo objeto solicitado (algumDepartmento/inicial.index), envia mensagem via socket
tempo
Ex: HTTP não-persistente (cont.)
5. cliente http recebe mensagem de resposta contendo arquivo html, visualiza html. Analisando arquivo html, encontra 10 objetos jpeg referenciados
4. servidor http encerra conexão TCP .
2: Camada de Aplicação 28
6. Passos 1 a 5 repetidos para cada um dos 10 objetos jpeg
tempo
Tempo de RespostaDefinição de RTT: tempo para
enviar um pequeno pacote para viajar do cliente para o servidor e retornar;
Tempo de resposta:Ø um RTT para iniciar a
conexão TCP
Inicia
conexão
TCP RTT
requisição
2: Camada de Aplicação 29
um RTT para iniciar a conexão TCP
Ø um RTT para a requisição HTTP e para que alguns bytes da resposta HTTP sejam recebidos
Ø tempo de transmissão do arquivo
total = 2RTT+tempo de transmissão
Tempo para
transmitir
arquivo
requisição
do arquivo
RTT
Arquivo
recebido
tempo tempo
HTTP persistenteHTTP não-persistente:Ø servidor analisa pedido,
responde, e encerra conexão TCPØ requer 2 RTTs para trazer cada
objetoØ mas os browsers geralmente
abrem conexões TCP paralelas para trazer cada objeto
Persistente sem pipelining:Ø Cliente só faz nova
requisição quando a resposta de uma requisição anterior foi recebida;
Ø um RTT para cada objetoPersistente com pipelining:
default in HTTP/1.1
2: Camada de Aplicação 30
para trazer cada objetoHTTP- persistenteØ servidor mantém conexão aberta
depois de enviar a resposta;Ø mensagens HTTP subsequentes
entre o o mesmos cliente/servidor são enviadas por esta conexão;
Ø na mesma conexão TCP: servidor analisa pedido, responde, analisa novo pedido e assim por diante
Ø default in HTTP/1.1Ø O cliente envia a requisição
assim que encontra um objeto;
Ø Um pouco mais de um RTT para trazer todos os objetos
Características do HTTP persistente:• Requer 2 RTTs por objeto• OS deve manipular e alocar recursos do hospedeiro para cada conexão TCPMas os browsers freqüentemente abrem conexões TCP paralelas para buscar objetos referenciados
HTTP persistente• Servidor deixa a conexão aberta após enviar uma resposta• Mensagens HTTP subseqüentes entre o mesmo cliente/servidor são enviadas pela conexão
Persistente sem pipelining:
HTTP persistente
2: Camada de Aplicação 31
Persistente sem pipelining:• O cliente emite novas requisições apenas quando a resposta anterior for recebida
• Um RTT para cada objeto referenciadoPersistente com pipelining:• Padrão no HTTP/1.1• O cliente envia requisições assim que encontra um objeto referenciado• Tão pequeno como um RTT para todos os objetos referenciados
Formato de mensagem HTTP: pedido
Ø Dois tipos de mensagem HTTP: pedido, respostaØ mensagem de pedido HTTP:
ü ASCII (formato legível por pessoas)
linha do pedido(comandos GET,
2: Camada de Aplicação 32
GET /somedir/page.html HTTP/1.0
User-agent: Mozilla/4.0
Accept: text/html, image/gif,image/jpeg
Accept-language:fr
(carriage return (CR), line feed(LF) adicionais)
linha do pedido(comandos GET, POST, HEAD)
linhas docabeçalho
Carriage return, line feed indica fim
de mensagem
Mensagem de pedido HTTP: formato geral
2: Camada de Aplicação 33
Tipos de Requisição
Método Post:Ø A página Web
geralmente inclue um formulário para entrada de dados;
Método URL:Ø Usa método GETØ A requisição é enviada
2: Camada de Aplicação 34
entrada de dados;Ø A requisição é enviada
para o servidor no corpo da entidade;
Ø A requisição é enviada para o servidor no campo URL da linha de requisição;
www.somesite.com/animalsearch?monkeys&banana
Tipos de Métodos
HTTP/1.0Ø GETØ POSTØ HEAD
Pede ao servidor que
HTTP/1.1Ø GET, POST, HEADØ PUTØ DELETE
Remove o arquivo
2: Camada de Aplicação 35
ü Pede ao servidor que deixe de fora da resposta o objeto solicitado; geralmente é usado para depuração;
ü Remove o arquivo especificado no campo URL;
Formato de mensagem HTTP: resposta
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
linha de status(protocolo,
código de status,frase de status)
linhas decabeçalho
2: Camada de Aplicação 36
Content-Length: 6821
Content-Type: text/html
dados dados dados dados ...
cabeçalho
dados, p.ex., arquivo htmlsolicitado
Códigos de status da resposta HTTP
200 OK
ü sucesso, objeto pedido segue mais adiante nesta mensagem301 Moved Permanently
ü objeto pedido mudou de lugar, nova localização
Na primeira linha da mensagem de resposta servidor->cliente. Alguns códigos típicos:
2: Camada de Aplicação 37
ü objeto pedido mudou de lugar, nova localização especificado mais adiante nesta mensagem (Location:)
400 Bad Request
ü mensagem de pedido não entendida pelo servidor404 Not Found
ü documento pedido não se encontra neste servidor505 HTTP Version Not Supported
ü versão de http do pedido não usada por este servidor
Experimente você com http (do lado cliente)
1. Use cliente telnet para seu servidor WWW favorito:Abre conexão TCP para a porta 80(porta padrão do servidor http) a www.ic.uff.br.Qualquer coisa digitada é enviada para aporta 80 do www.ic.uff.br
telnet www.ic.uff.br 80
2: Camada de Aplicação 38
2. Digite um pedido GET http:GET /~michael/index.html HTTP/1.0 Digitando isto (deve teclar
ENTER duas vezes), está enviandoeste pedido GET mínimo (porém completo) ao servidor http
3. Examine a mensagem de resposta enviado pelo servidor http !
Open Source Implementation 6.3: ApacheØ Introduction to Apache:
ü Open-Source Web server originally based on NCSA server
ü Available on over 160 varieties of Unix -- and Windows NT
39
Windows NTü Over 58% of Internet Web servers run Apache or an Apache derivative
Chapter 6: Application Layer
Apache Server Life Cycle
Ø On Unix systems, Apache creates multiple processes to handle requests.
Ø The Windows and OS/2 ports are multithreaded..
40Chapter 6: Application Layer
HTML (HyperText Markup Language)
Ø HTML: uma linguagem simples para hipertextoü começou como versão simples de SGMLü construção básica: cadéias de texto anotadas
Ø Construtores de formato operam sobre cadéiasü <b> .. </b> bold (negrito)
2: Camada de Aplicação 41
ü <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
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.uff.br”> saiba sobre a UFF </A>
2: Camada de Aplicação 42
ü a documentos em outros servidores<A HREF=“http://www.uff.br”> saiba sobre a UFF </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 niver </A>
Extensible Markup Language
Ø What is XML?ü A pared-down version of SGML, designed especially for Web documents.
Ø Why XML?How to use XML?
43
Ø How to use XML?ü Traditional data processingü Document-driven programming (DDP)ü Archiving ü Binding
Chapter 6: Application Layer
Extensible HyperText Markup Language
Ø What is XHTML?ü A hybrid between HTML and XML specifically designed for Net device displays.
Ø Why XHTML?Ø Using XHTML with other W3C tag sets:
44
Ø Using XHTML with other W3C tag sets:ü XHTML for structural markup of documents ü SMIL for multimedia ü MathML for mathematics ü SVG for scalable vector graphics ü XForms for smart web forms
Chapter 6: Application Layer
Cache WWW (servidor-procurador)
Ø usuário configura browser: acessos WWW via procurador
Ø cliente envia todos pedidos http ao procurador
Meta: atender pedido do cliente sem envolver servidor de origem
clienteServidor-procurador
Servidorde origem
2: Camada de Aplicação 45
pedidos http ao procurador
ü se objeto no cache do procurador, este o devolve imediatamente na resposta http
ü senão, solicita objeto do servidor de origem, depois devolve resposta http ao cliente
clienteServidorde origem
Mais sobre Web cache
Ø Cache atua tanto como cliente como servidor;
Ø Cache pode fazer ferificação no cabeçalho HTTP usando o campo If-modified-since :
Por quê usar cache WWW?Ø tempo de resposta menor:
cache “mais próximo” do cliente
Ø diminui tráfego aos
2: Camada de Aplicação 46
modified-since :ü Questão: a cache deve
correr o risco e enviar objetos solicitados sem verificação?
ü São usadas heurísticas;Ø Tipicamente os caches web
são instalados em ISPs (universidades, companhias, ISP residencial)
Ø diminui tráfego aos servidores distantes
ü muitas vezes é um gargalo o enlace que liga a rede da instituição ou do provedor à Internet
Exemplo de Cache (1)AssumptionsØ Tamanho médio do objeto =
100,000 bitsØ Taxa média de requisição do
browser da instituição para os servidores de origem = 15/seg
Ø Atraso do roteador da
Servidoresde origem
Internetpública
enlace de accesso
2: Camada de Aplicação 47
Ø Atraso do roteador da instituição para qualquer servidor de origem e de volta para o roteador = 2 seg
ConseqüênciasØ Utilização da LAN = 15%Ø Utilização do enlace de acesso =
100%Ø Atraso total = atraso Internet +
atraso de acesso + atraso LAN= 2 seg + minutos + milisegundos
rede dainstituição LAN 10 Mbps
enlace de accesso 1.5 Mbps
cache dainstituição
Exemplo cache (2)Solução possívelØ Aumentar a banda do enlace
de acesso para 10 MbpsConseqüênciasØ utilização LAN = 15%Ø Utilização do enlace de acesso =
15%
Servidoresde origem
Internetpública
enlace de accesso
2: Camada de Aplicação 48
Utilização do enlace de acesso = 15%
Ø Atraso total = atraso Internet + atraso de acesso + atraso LAN = 2 sec + msecs + msecs
Ø Geralmente um upgrade caro
rede dainstituição LAN 10 Mbps
enlace de accesso 10 Mbps
cache dainstituição
Exemplo cache(3)
Instala cacheØ Suponha que a taxa de hits é .4ConseqüênciaØ 40% das requisições são
satisfeitas quase que imediatamente;60% das requisições são
Servidoresde origem
Internetpública
enlace de accesso
2: Camada de Aplicação 49
Ø 60% das requisições são satisfeitas pelo servidor;
Ø Utilização do enlace de acesso deduzido para 60%, resultando resulting em atrasos desprezíveis (digamos 10 mseg)
Ø Atraso total = atraso Internet + atraso de acesso + atraso = .6*2 sec + .6*.01 seg + millisegundos < 1.3 sg
rede dainstituição LAN 10 Mbps
enlace de accesso 1.5 Mbps
cache dainstituição
Interação usuário-servidor: GET condicional
Ø Meta: não enviar objeto se cliente já tem (no cache) versão atual
Ø cliente: especifica data da
cliente servidor
msg de pedido httpIf-modified-since:
<date>
resposta httpHTTP/1.0
objeto não
modificado
2: Camada de Aplicação 50
Ø cliente: especifica data da cópia no cache no pedido httpIf-modified-since:
<date>
Ø servidor: resposta não contém objeto se cópia no cache é atual: HTTP/1.0 304 Not
Modified
HTTP/1.0
304 Not Modified
msg de pedido httpIf-modified-since:
<date>
resposta httpHTTP/1.1 200 OK
…
<data>
objeto modificado
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
Ø Formulários processados usando scripts CGI (programas que executam no servidor WWW)
ü CGI - Common Gateway Interface
ü scripts CGI escondem
2: Camada de Aplicação 51
Ø Resposta enviada como página HTML dinâmica
ü scripts CGI escondem acesso a diferentes serviços
ü servidor WWW atua como gateway universal
cliente
WWW
servidor
WWWSistema de
informação
GET/POST
formulário
resposta:
HTML
Interação usuário-servidor: autenticaçãoMeta 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
cliente servidormsg de pedido http comum
401: authorization req.WWW authenticate:
msg de pedido http comum
2: Camada de Aplicação 52
senhaü authorization: linha de
cabeçalho no pedidoü se não for apresentada
autorização, servidor nega acesso, e coloca no cabeçalho da respostaWWW authenticate:
msg de pedido http comum+ Authorization:line
msg 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:line
msg de resposta http comum
Interação usuário-servidor: cookies, mantendo o “estado”
Exemplo:ü Susan acessa a Internet sempre usando o mesmo
PC;ü Ela visita um site de comércio eletrônico pela
primeira vez;
2: Camada de Aplicação 53
primeira vez;ü Quando a requisição HTTP inicial chega ao site, é
criado um ID único e uma entrada no bando de dados para este ID;
ü servidor envia “cookie” ao cliente na msg de resposta
ü cliente apresenta cookie nos pedidos posterioresü servidor casa cookie- apresentado com a info
guardada no servidor
A grande maioria dos sites Web usa cookiesQuatro componentes:
1) linha de cabeçalho do cookie na mensagem de resposta HTTP;
2) linha de cabeçalho do cookie na mensagem de requisição HTTP
Interação usuário-servidor: cookies, mantendo o “estado”
2: Camada de Aplicação 54
requisição HTTP3) Arquivo de cookie mantido na máquina do usuário
e gerenciado por seu browser;4) Banco de dados no site Web
cliente servidorrequisição http comum
resposta http comum +Set-cookie: 1678
requisição http comum
servidorcria ID
1678 para o usuário
Arquivo Cookie
Arquivo Cookie
ebay: 8734
Interação usuário-servidor: cookies, mantendo o “estado”
2: Camada de Aplicação 55
requisição http comumcookie: 1678
resposta http comum
requisição http comumcookie: 1678
resposta http comum
Açãoespecífica do cookie
Açãoespecífica do cookie
Arquivo Cookie
amazon: 1678
ebay: 8734
Arquivo Cookie
amazon: 1678
ebay: 8734
Uma semana depois:
O que cookie pode trazer?
Ø autorizaçãoØ shopping cartsØ recomendações
Cookies e privacidade:Ø O uso de cookies permite
que o site “aprenda” muita coisa sobre você
Ø Você deve fornecer nome e e-mail para os sites;
Nota
Interação usuário-servidor: cookies, mantendo o “estado”
2: Camada de Aplicação 56
Ø recomendaçõesØ Estado de sessões de
usuários (Web e-mail)
e e-mail para os sites;Ø Ferramentas de buscas
usam redirecionamento & cookies para aprender ainda mais;
Ø Agências de publicidade obtém suas informações através dos sites;
FTP: o protocolo de transferência de arquivos
transferênciado arquivo FTP
servidor
Interface do usuário
FTP
cliente FTP
sistema de arquivos local
sistema de arquivos remoto
usuário na
estação
2: Camada de Aplicação 57
Ø transferir arquivo de/para hospedeiro remotoØ modelo cliente/servidor
ü cliente: lado que inicia transferência (pode ser de ou para o sistema remoto)
ü servidor: hospedeiro remotoØ ftp: RFC 959Ø servidor ftp: porta 21
local remoto
FTP: conexões separadas p/ controle, dados
Ø Cliente FTP contacta servidor ftp na porta 21, especificando TCP como protocolo de transporte
Ø Cliente obtem autorização através da conexão de controle;
cliente FTP
servidor FTP
conexão de controleTCP, porta 21
conexão de dados TCP, porta 20
Ø são abertas duas conexões
2: Camada de Aplicação 58
através da conexão de controle;Ø O cliente acessa o diretório
remoto através do envio de comandos pela conexão de controle;
Ø Quando o servidor recebe um comando para transferência de arquivo, o servidor abre uma conexão TCP com o cliente;
Ø Depois de transferir o arquivo a conexão é finalizada;
Ø são abertas duas conexões TCP paralelas:
ü controle: troca comandos, respostas entre cliente, servidor.“controle fora da banda”
ü dados: dados de arquivo de/para servidor
FTP: comandos, respostas
Comandos típicos:Ø enviados em texto ASCII pelo
canal de controleØ USER nome
Ø PASS senha
Códigos de retorno típicosØ código e frase de status (como
para http)Ø 331 Username OK, password
required
125 data connection
2: Camada de Aplicação 59
Ø LIST devolve lista de arquivos no directório corrente
Ø RETR arquivo recupera (lê) arquivo remoto
Ø STOR arquivo armazena (escreve) arquivo no hospedeiro remoto
Ø 125 data connection
already open; transfer
starting
Ø 425 Can’t open data
connection
Ø 452 Error writing file
Correio Eletrônico
Três grandes componentes:Ø agentes de usuário (UA) Ø servidores de correioØ SMTP: simple mail transfer
protocol
caixa de correio do usuário
fila demsg de saída
agente
servidor de correio
agente de
usuário
SMTP
SMTP
agente de
usuário
servidor de correio
2: Camada de Aplicação 60
Agente de UsuárioØ a.k.a. “leitor de correio”Ø compor, editar, ler mensagens
de correioØ p.ex., Eudora, Outlook, elm,
Netscape MessengerØ mensagens de saída e chegada
são armazenadas no servidor
agente de
usuário
SMTP
SMTP
agente de
usuário
agente de
usuárioagente de
usuário
servidor de correio
de correio
Correio Eletrônico: servidores de correio
Servidores de correioØ caixa de correio contém
mensagens de chegada (ainda não lidas) p/ usuário
Ø fila de mensagens contém mensagens de saída (a serem enviadas)
servidor de correio
agente de
usuário
SMTP
SMTP
agente de
usuário
servidor de correio
2: Camada de Aplicação 61
mensagens de saída (a serem enviadas)
Ø protocolo SMTP entre servidores de correio para transferir mensagens de correio
ü cliente: servidor de correio que envia
ü “servidor”: servidor de correio que recebe
SMTP
SMTP
agente de
usuário
agente de
usuárioagente de
usuário
servidor de correio
de correio
Correio Eletrônico: SMTP [RFC 821]
Ø usa TCP para a transferência confiável de msgs do correio do cliente ao servidor, porta 25
Ø transferência direta: servidor remetente ao servidor receptor
Ø três fases da transferênciahandshaking (cumprimento)
2: Camada de Aplicação 62
ü handshaking (cumprimento)ü transferência das mensagensü encerramento
Ø interação comando/respostaü comandos: texto ASCIIü resposta: código e frase de status
Ø mensagens precisam ser em ASCII de 7-bits
Cenário: Alice envia msg para Bob1) Alice usa UA para compor a
mensagem e enviá-la para [email protected]
2) O UA da Alice envia a mensagem para o seu servidor de correio; a msg é colocada na fila de mensagens;
4) SMTP cliente envia a msg da Alice através da conexão TCP;
5) Servidor de correio de Bob coloca a msg na caixa de correio de Bob;
6) Bob invoca o seu UA para ler a sua msg;
2: Camada de Aplicação 63
mensagens;3) O cliente SMTP abre uma
conexão TCP com o servidor de correio do Bob
6) Bob invoca o seu UA para ler a sua msg;
agente usuário
servidorcorreio
servidorcorreio agente
usuário
1
2 3 4 56
Interação SMTP típicaS: 220 doces.br
C: HELO consumidor.br
S: 250 Hello consumidor.br, 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
2: Camada de Aplicação 64
S: 250 [email protected] ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Voce gosta de chocolate?
C: Que tal sorvete?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 doces.br closing connection
Experimente você uma interação SMTP :
Ø telnet nomedoservidor 25
Ø veja resposta 220 do servidorØ entre comandos HELO, MAIL FROM, RCPT TO,
DATA, QUIT
2: Camada de Aplicação 65
estes comandos permite que você envie correio sem usar um cliente (leitor de correio)
SMTP: últimas palavras
Ø SMTP usa conexões persistentes
Ø smtp requerque a mensagem (cabeçalho e corpo) sejam em ASCII de 7-bits
Ø algumas cadeias de caracteres não são permitidas numa
Comparação com httpØ HTTP : pull (puxar)Ø email: push (empurrar)
Ø ambos tem interação comando/resposta, códigos
2: Camada de Aplicação 66
não são permitidas numa mensagem (p.ex., CRLF.CRLF). Logo a mensagem pode ter que ser codificada (normalmente em base-64 ou “quoted printable”)
Ø servidor SMTP usa CRLF.CRLF para reconhecer o final da mensagem
comando/resposta, códigos de status em ASCII
Ø HTTP: cada objeto é encapsulado em sua própria mensagem de resposta
Ø SMTP: múltiplos objetos de mensagem enviados numa mensagem de múltiplas partes
Formato de uma mensagem
SMTP: protocolo para trocar msgs de correio
RFC 822: padrão para formato de mensagem de texto:
Ø linhas de cabeçalho, p.ex.,ü To:
cabeçalho
corpo
linha em branco
2: Camada de Aplicação 67
ü To:ü From:ü Subject:diferentes dos comandos de
SMTP!Ø corpo
ü a “mensagem”, somente de caracteres ASCII
corpo
Formato de uma mensagem: extensões para multimídiaØ MIME: multimedia mail extension, RFC 2045, 2056Ø linhas adicionais no cabeçalho da msg declaram tipo do
conteúdo MIME
From: [email protected]
To: [email protected]ão MIME
2: Camada de Aplicação 68
Subject: Imagem de uma bela torta
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
tipo, subtipo dedados multimídia,
declaração parâmetros
método usadop/ codificar dados
Dados codificados
Tipos MIME Content-Type: tipo/subtipo; parâmetros
TextØ subtipos exemplos: plain,
html
Ø charset=“iso-8859-1”,
ascii
AudioØ subtipos exemplos : basic
(8-bit codificado mu-law), 32kadpcm (codificação 32 kbps)
Application
2: Camada de Aplicação 69
ImageØ subtipos exemplos : jpeg,
gif
VideoØ subtipos exemplos : mpeg,
quicktime
ApplicationØ outros dados que precisam
ser processados por um leitor para serem “visualizados”
Ø subtipos exemplos : msword, octet-stream
Tipo MultipartFrom: [email protected]
Subject: Imagem de uma bela torta MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
caro Bernardo,
2: Camada de Aplicação 70
caro Bernardo,
Anexa a imagem de uma torta deliciosa.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--98766789--
Protocolos de accesso ao correio
Ø SMTP: entrega/armazenamento no servidor do receptor
servidor de correio do remetente
SMTP SMTP POP3 ouIMAP
servidor de correiodo receptor
agente de
usuário
agente de
usuário
2: Camada de Aplicação 71
Ø SMTP: entrega/armazenamento no servidor do receptorØ protocolo de accesso ao correio: recupera do servidor
ü POP: Post Office Protocol [RFC 1939]• autorização (agente <-->servidor) e transferência
ü IMAP: Internet Mail Access Protocol [RFC 1730]• mais comandos (mais complexo)• manuseio de msgs armazenadas no servidor
ü HTTP: Hotmail , Yahoo! Mail, Webmail, etc.
Protocolo POP3
fase de autorizaçãoØ comandos do cliente:
ü user: declara nomeü pass: senha
Ø servidor respondeü +OK
C: list
S: 1 498
S: 2 912
S: .
S: +OK POP3 server ready
C: user ana
S: +OK
C: pass faminta
S: +OK user successfully logged on
2: Camada de Aplicação 72
ü +OK
ü -ERR
fase de transação, cliente:Ø list: lista números das
msgsØ retr: recupera msg por
númeroØ dele: apaga msgØ quit
S: .
C: retr 1
S: <message 1 contents>
S: .
C: dele 1
C: retr 2
S: <message 1 contents>
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off
POP3 e IMAPMais sobre POP3Ø O exemplo anterior usa o
modo “ler-e-apagar”.Ø Bob não pode reler suas
msgs se ele mudar de cliente;POP3 não mantém estado;
IMAPØ Usa o modo: “ler-e-
guardar” que posibilita acessar mensagens de vários clientes;
Ø Mantém todas as mensagens em um único lugar: servidor;
Ø Permite que o usuário organize suas msgs em
2: Camada de Aplicação 73
Ø POP3 não mantém estado; organize suas msgs em pastas remotas como se fosse locais;
Ø IMAP mantém estado dos usuários durante as sessões:
ü Nomes e pastas e mapeia os IDs das msgs e o nome das pastas;
DNS: Domain Name System
Pessoas: muitos identificadores:
ü CPF, nome, no. da Identidade
hospedeiros, roteadores Internet :
Domain Name System:Ø base de dados distribuída
implementada na hierarquia de muitos servidores de nomes
Ø protocolo de camada de aplicaçãopermite que hospedeiros, roteadores, servidores de nomes
2: Camada de Aplicação 74
Internet :ü endereço IP (32 bit) -
usado p/ endereçar datagramas
ü “nome”, ex., jambo.ic.uff.br - usado por gente
P: como mapear entre nome e endereço IP?
permite que hospedeiros, roteadores, servidores de nomes se comuniquem para resolvernomes (tradução endereço/nome)
ü note: função imprescindível da Internet implementada como protocolo de camada de aplicação
ü complexidade na borda da rede
DNS
Ø Roda sobre UDP e usa a porta 53
Ø Especificado nas RFCs 1034 e 1035 e atualizado em outras
Ø Outros serviços:ü apelidos para
hospedeiros (aliasing)ü apelido para o servidor
de mailsdistribuição da carga
2: Camada de Aplicação 75
atualizado em outras RFCs. ü distribuição da carga
Pessoas: muitos identificadores:• RG, nome, passaporte
Internet hospedeiros, roteadores:• Endereços IP (32 bits) - usados para endereçar datagramas• “nome”, ex.: gaia.cs.umass.edu - usados por humanos
P.: Relacionar nomes com endereços IP?
Domain Name System:• Base de dados distribuída implementada numa hierarquia de muitos
DNS: Domain Name System
2: Camada de Aplicação 76
• Base de dados distribuída implementada numa hierarquia de muitos servidores de nomes
• Protocolo de camada de aplicação hospedeiro, roteadores se comunicam com servidores de nomes para resolver nomes (translação nome/endereço)• Nota: função interna da Internet, implementada como protocolo da camada de aplicação
• Complexidade na “borda” da rede
Servidores de nomes DNS
Ø Nenhum servidor mantém todos os mapeamento nome-para-endereço IP
servidor de nomes local:ü cada provedor, empresa tem
servidor de nomes local (default)
Por que não centralizar o DNS?
Ø ponto único de falhaØ volume de tráfegoØ base de dados
2: Camada de Aplicação 77
servidor de nomes local (default)ü pedido DNS de hospedeiro vai
primeiro ao servidor de nomes local
servidor de nomes oficial:ü p/ hospedeiro: guarda nome,
endereço IP deleü pode realizar tradução
nome/endereço para este nome
Ø base de dados centralizada e distante
Ø manutenção (da BD)
Não é escalável!
DNS: Servidores raizØ procurado por servidor local que não consegue resolver o
nomeØ servidor raiz:
ü procura servidor oficial se mapeamento é desconhecidoü obtém tradução
devolve mapeamento ao servidor local
2: Camada de Aplicação 78
ü devolve mapeamento ao servidor local
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA
i NORDUnet Stockholm
k RIPE London
m WIDE Tokyo
a NSI Herndon, VA
c PSInet Herndon, VA
d U Maryland College Park, MD
g DISA Vienna, VA
h ARL Aberdeen, MDj NSI (TBD) Herndon, VA
13 servidores raíz no mundo
Base de dados distribuída, hierárquica
2: Camada de Aplicação 79
Cliente quer o IP para www.amazon.com; 1a aprox.:• Cliente consulta um servidor de raiz para encontrar o servidor DNS com• Cliente consulta o servidor DNS com para obter o servidor DNS amazon.com• Cliente consulta o servidor DNS amazon.com para obter o endereço IP para www.amazon.com
Servidores top-level domain (TLD): responsáveis pelos domínios com, org, net, edu etc e todos os domínios top-level nacionais uk, fr, ca, jp.• Network Solutions mantém servidores para o TLD “com” TLD• Educause para o TLD “edu”
Servidores TLD e autoritários
2: Camada de Aplicação 80
Servidores DNS autorizados: servidores DNS de organizações, provêm nome de hospedeiro autorizado para mapeamentos IP para servidores de organizações (ex.: Web e mail).• Podem ser mantidos por uma organização ou provedor de serviços
Top Level DomainsDomain Description
com Commercial organizations, such as Intel (intel.com).
org Non-profit organizations, such as WWW consortium (w3.org).
gov Government organizations, reserved for U.S government such as National Science Foundation (nsf.gov).
edu Educational organizations, such as UCLA (ucla.edu).
net Networking organizations, such as Internet Assigned Numbers Authority which maintains the DNS root servers (gtld-servers.net) .
81
which maintains the DNS root servers (gtld-servers.net) .
int Organizations established by international treaties between governments. For example, International Telecommunication Union (itu.int).
Mil Reserved exclusively for the United States Military. For example, Network Information Center, Department of Defense (nic.mil).
Two-letter country code
The two-letter country code top level domains (ccTLDs) are based on the ISO 3166-1 two-letter country codes. Examples are tw (Taiwan), uk (United Kingdom).
arpa Mostly unused now, except for the in-addr.arpa domain, which is used to maintain a database for reverse DNS queries.
Others Such as .biz (business), .name (for individuals), .info (similar with .com).
Chapter 6: Application Layer
• O hospedeiro em cis.poly.edu
Exemplo
2: Camada de Aplicação 82
• O hospedeiro em cis.poly.edu quer o endereço IP para gaia.cs.umass.edu
Consulta recursiva:• Transfere a tarefa de resolução do nome para o servidor de nomes consultado
• Carga pesada?
Consulta encadeada:•
Consultas recursivas
2: Camada de Aplicação 83
Consulta encadeada:• Servidor contatado responde com o nome de outro servidor de nomes para contato
• “eu não sei isto, mas pergunte a este servidor”
Uma vez que um servidor de nomes apreende um mapeamento, ele armazena o mapeamento num registro do tipo cache• Registro do cache tornam-se obsoletos (desaparecem) depois de um certo tempo• Servidores TLD são tipicamente armazenados em cache nos servidores de nome locais
DNS: armazenando e atualizando registros
2: Camada de Aplicação 84
servidores de nome locais
Mecanismos de atualização e notificação estão sendo projetados pelo IETF• RFC 2136• http://www.ietf.org/html.charters/dnsind-charter.html
Registros do DNS
DNS: base de dados distribuída que armazena registros de recursos (RR)
formato dos RR: (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)
2: Camada de Aplicação 85
• Type = NS• name é um domínio (ex.: foo.com)• value é o endereço IP do servidor de nomes autorizados para este domínio
• value é o endereço IP nome “canônico” (o nome real)www.ibm.com é realmenteservereast.backup2.ibm.com
• value é o nome canônico
• Type = MX• value é o nome do servidor de correio associado com name
DNS: protocolo e mensagem
Protocolo DNS: mensagem de consulta e resposta , ambas com o mesmo formato de mensagem
Cabeçalho da msg• Identificação: número de 16 bits para consulta, resposta usa o mesmo número
• Flags:
2: Camada de Aplicação 86
• Flags:• Consulta ou resposta• Recursão desejada • Recursão disponível• Resposta é autorizada
Camada de aplicação
2: Camada de Aplicação 87
DNS: protocolo e mensagens
• Exemplo: empresa recém-criada “Network Utopia”• Registrar o nome networkuptopia.com num “registrar” (ex.: Network Solutions)• É necessário fornecer ao registrar os nomes e endereços IP do seu servidor nomes autorizados (primário e secundário)• Registrar insere dois RRs no servidor TLD do domínio com:
(networkutopia.com, dns1.networkutopia.com, NS)
Camada de aplicação
2: Camada de Aplicação 88
Inserindo registros no DNS
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
• No servidor autorizado, inserir um registro Tipo A para www.networkuptopia.com e um registro Tipo MX para networkutopia.com
• Como as pessoas obtêm o endereço IP do seu Web site?
DNS: uso de cache, atualização de dados
Ø uma vez que um servidor qualquer aprende um mapeamento, ele o coloca numa cache localü futuras consultas são resolvidas usando dados da cache
ü entradas na cache são sujeitas a temporização (desaparecem depois de um certo tempo)
2: Camada de Aplicação 89
entradas na cache são sujeitas a temporização (desaparecem depois de um certo tempo)ttl = time to live (sobrevida)
Ø estão sendo projetados pela IETF mecanismos de atualização/notificação dos dados
ü RFC 2136ü http://www.ietf.org/html.charters/dnsind-charter.html
Registros DNSDNS: BD distribuído contendo registros de recursos (RR)
formato RR: (nome, valor, tipo, sobrevida)
Ø Tipo=Aü nome é nome de hospedeiro
Ø Tipo=CNAMEü nome é nome alternativo
(alias) para algum nome
2: Camada de Aplicação 90
Ø Tipo=NSü nome é domínio (p.ex.
foo.com.br)ü valor é endereço IP de
servidor oficial de nomes para este domínio
nome é nome de hospedeiroü valor é o seu endereço IP (alias) para algum nome
“canônico” (verdadeiro)ü valor é o nome
canônico
Ø Tipo=MXü nome é domínioü valor é nome do servidor de
correio para este domínio
DNS: protocolo e mensagensprotocolo DNS: mensagens de pedido e resposta, ambas com o
mesmo formato de mensagem
cabeçalho de msgØ identificação: ID de 16 bit
para pedido, resposta ao pedido usa mesmo ID
2: Camada de Aplicação 91
para pedido, resposta ao pedido usa mesmo ID
Ø flags:ü pedido ou respostaü recursão desejadaü recursão permitidaü resposta é oficial
DNS: protocolo e mensagens
campos de nome, e de tipo num pedido
RRs em respostaao pedido
2: Camada de Aplicação 92
ao pedido
registros para outrosservidores oficiais
info adicional “relevante” que pode ser usada
Programação com sockets
API Sockets Ø apareceu no BSD4.1 UNIX
em 1981são explicitamente criados,
uma interface (uma “porta”), local ao
hospedeiro, criada por e pertencente à aplicação, e
socket
Meta: aprender a construir aplicações cliente/servidor que se comunicam usando sockets
2: Camada de Aplicação 93
Ø são explicitamente criados, usados e liberados por apls
Ø paradigma cliente/servidorØ dois tipos de serviço de
transporte via API Socketsü datagrama não confiável ü fluxo de bytes, confiável
pertencente à aplicação, e controlado pelo SO, através da qual um
processo de aplicação pode tanto enviar como receber mensagens
para/de outro processo de aplicação
(remoto ou local)
Programação com sockets usando TCPSocket: uma porta entre o processo de aplicação e um
protocolo de transporte fim-a-fim (UDP ou TCP)Serviço TCP: transferência confiável de bytes de um
processo para outro
2: Camada de Aplicação 94
processo
TCP combuffers,variáveis
socket
controlado peloprogramador de
aplicação
controladopelo sistemaoperacional
estação ouservidor
processo
TCP combuffers,variáveis
socket
controlado peloprogramador deaplicação
controladopelo sistemaoperacional
estação ouservidor
internet
Cliente deve contatar o servidor• Processo servidor já deve estar em execução• Servidor deve ter criado socket (porta) que aceita o contato do cliente
Cliente contata 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 contatado pelo cliente, o TCP do servidor cria um novo socket para
Programação de sockets com TCP
2: Camada de Aplicação 95
Quando contatado 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• Números da porta de origem são usados para distinguir o cliente (mais no capítulo 3)
Ponto de vista da aplicaçãoTCP fornece a transferência confiável, em ordem de bytes
(“pipe”) entre o cliente e o servidor
• Um stream é uma seqüência de caracteres que fluem para dentro ou para fora de um processo
• Um stream de entrada é agregado a alguma fonte de entrada para o processo, ex.: teclado ou socket
Jargão stream
2: Camada de Aplicação 96
• Um stream de saída é agregado a uma fonte de saída, ex.: monitor ou socket
Exemplo de aplicação cliente-servidor:
1) Cliente lê linha da entrada-padrão do sistema (inFromUser stream), envia para o servidor via socket (outToServer stream)
2) Servidor lê linha do socket
Programação de sockets com TCP
2: Camada de Aplicação 97
2) Servidor lê linha do socket
3) Servidor converte linha para letras maiúsculas e envia de volta ao cliente
4) Cliente lê a linha modificada através do (inFromServer stream)
Programação de sockets com TCP
Comunicação entre sockets
2: Camada de Aplicação 98
Exemplo de aplicação cliente-servidor
Ø cliente lê linha da entrada padrão (fluxo doUsuário), envia para servidor via socket (fluxo paraServidor)
Ø servidor lê linha do socketØ servidor converte linha para
doU
suário
teclado monitor
Process fluxo de entrada: seqüência de bytespara dentro do
processocliente
2: Camada de Aplicação 99
Ø servidor converte linha para letras maiúsculas, devolve para o cliente
Ø cliente lê linha modificada do socket (fluxo doServidor), imprime-a d
o U
suário
para rede da rede
para
Serv
idor
clientSocket
TCPsocket
para dentro do processofluxo de saída:
seqüência de bytes para fora do processo
TCP socketcliente
Interações cliente/servidor usando o TCP
aguarda chegada de
cria socket,porta=x, para
receber pedido:socketRecepção =
ServerSocket ()
cria socket,abre conexão a nomeHosp, porta=x
Servidor (executa em nomeHosp) Cliente
TCP setup da conexão
2: Camada de Aplicação 100
aguarda chegada de pedido de conexãosocketConexão =socketRecepção.accept()
abre conexão a nomeHosp, porta=xsocketCliente =
Socket()
fechasocketConexão
lê resposta desocketCliente
fechasocketCliente
Envia pedido usandosocketClientelê pedido de
socketConexão
escreve resposta para socketConexão
setup da conexão
Exemplo: cliente Java (TCP)
import java.io.*;
import java.net.*;
class ClienteTCP {
public static void main(String argv[]) throws Exception
{
String frase;
2: Camada de Aplicação 101
String frase;
String fraseModificada;
BufferedReader doUsuario =
new BufferedReader(new InputStreamReader(System.in));
Socket socketCliente = new Socket(”nomeHosp", 6789);
DataOutputStream paraServidor = new DataOutputStream(socketCliente.getOutputStream());
Criafluxo de entrada
Criasocket de cliente,
conexão ao servidorCria
fluxo de saídaligado ao socket
Exemplo: cliente Java (TCP), cont.
BufferedReader doServidor =
new BufferedReader(new
InputStreamReader(socketCliente.getInputStream()));
frase = doUsuario.readLine();
Criafluxo de entradaligado ao socket
Envia linha
2: Camada de Aplicação 102
paraServidor.writeBytes(frase + '\n');
fraseModificada = doServidor.readLine();
System.out.println(”Do Servidor: " + fraseModificada);
socketCliente.close();
}
}
Envia linhaao servidor
Lê linhado servidor
Exemplo: servidor Java (TCP)import java.io.*;
import java.net.*;
class servidorTCP {
public static void main(String argv[]) throws Exception
{
String fraseCliente;
StringfFraseMaiusculas; Cria socket
2: Camada de Aplicação 103
StringfFraseMaiusculas;
ServerSocket socketRecepcao = new ServerSocket(6789);
while(true) {
Socket socketConexao = socketRecepcao.accept();
BufferedReader doCliente =
new BufferedReader(new
InputStreamReader(socketConexao.getInputStream()));
Cria socketpara recepçãona porta 6789
Aguarda, no socketpara recepção, o
contato do cliente
Cria fluxo deentrada, ligado
ao socket
Exemplo: servidor Java (TCP), cont
DataOutputStream paraCliente =
new DataOutputStream(socketConexão.getOutputStream());
fraseCliente= doCliente.readLine(); Lê linha
do socket
Cria fluxode saída, ligado
ao socket
2: Camada de Aplicação 104
fraseEmMaiusculas= fraseCliente.toUpperCase() + '\n';
paraClient.writeBytes(fraseEmMaiusculas);
}
} }
Escreve linhaao socket
Final do laço while,volta ao início e aguardaconexão de outro cliente
Programação com sockets usando UDP
UDP: não tem “conexão” entre cliente e servidor
Ø não tem “handshaking”Ø remetente coloca
explicitamente endereço IP e porta do destino
UDP provê transferência não confiável de grupos
ponto de vista da aplicação
2: Camada de Aplicação 105
e porta do destinoØ servidor deve extrair
endereço IP, porta do remetente do datagrama recebido
UDP: dados transmitidos podem ser recebidos fora de ordem, ou perdidos
não confiável de grupos de bytes (“datagramas”) entre cliente e servidor
Interações cliente/servidor usando o UDP
Servidor (executa em nomeHosp)
cria socket,
socketCliente = DatagramSocket()
Cliente
cria, endereça (nomeHosp, porta=x,
cria socket,porta=x, para
pedido que chega:socketServidor = DatagramSocket()
2: Camada de Aplicação 106
fechasocketCliente
lê resposa dosocketCliente
cria, endereça (nomeHosp, porta=x,
envia pedido em datagramausando socketCliente
lê pedido dosocketServidor
escreve resposta ao socketServidorespecificando endereçoIP, número de porta do cliente
Cliente UDP
2: Camada de Aplicação 107
Exemplo: cliente Java (UDP)
doU
suário
teclado monitor
Process
fluxo
de entrada
envia pacote
Entrada: recebe pacote (TCP recebe “byte stream”)
processocliente
2: Camada de Aplicação 108
envia
Packet
para rede da rede
recebeP
acket
clientSocket
pacote
UDP
pacote
UDP
UDPsocket
Saída: envia pacote (TCP envia “byte stream”)
“byte stream”)
socket UDP cliente
Exemplo: cliente Java (UDP)
import java.io.*;
import java.net.*;
class clienteUDP {
public static void main(String args[]) throws Exception
{
BufferedReader do Usuario=
Criafluxo de entrada
2: Camada de Aplicação 109
BufferedReader do Usuario=
new BufferedReader(new InputStreamReader(System.in));
DatagramSocket socketCliente = new DatagramSocket();
InetAddress IPAddress = InetAddress.getByName(”nomeHosp");
byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];
String frase = doUsuario.readLine();
sendData = frase.getBytes();
fluxo de entrada
Cria socket de cliente
Traduz nome de hospedeiro ao endereço IP usando DNS
Exemplo: cliente Java (UDP) cont.
DatagramPacket pacoteEnviado =
new DatagramPacket(dadosEnvio, dadosEnvio.length,
IPAddress, 9876);
socketCliente.send(pacoteEnviado);
DatagramPacket pacoteRecebido =
new DatagramPacket(dadosRecebidos, dadosRecebidos.length);
Cria datagrama com dados para enviar,
comprimento, endereço IP, porta
Envia datagramaao servidor
2: Camada de Aplicação 110
new DatagramPacket(dadosRecebidos, dadosRecebidos.length);
socketCliente.receive(pacoteRecebido);
String fraseModificada =
new String(pacoteRecebido.getData());
System.out.println(”Do Servidor:" + fraseModificada);
socketCliente.close();
}
}
Lê datagramado servidor
Servidor UDP
2: Camada de Aplicação 111
Exemplo: servidor Java (UDP)
import java.io.*;
import java.net.*;
class servidorUDP {
public static void main(String args[]) throws Exception
{
DatagramSocket socketServidor = new DatagramSocket(9876);
Cria socketpara datagramas
na porta 9876
2: Camada de Aplicação 112
DatagramSocket socketServidor = new DatagramSocket(9876);
byte[] dadosRecebidos = new byte[1024];
byte[] dadosEnviados = new byte[1024];
while(true)
{
DatagramPacket pacoteRecebido =
new DatagramPacket(dadosRecebidos,
dadosRecebidos.length);
socketServidor.receive(pacoteRecebido);
na porta 9876
Aloca memória parareceber datagrama
Recebedatagrama
Exemplo: servidor Java (UDP), contString frase = new String(pacoteRecebido.getData());
InetAddress IPAddress = pacoteRecebido.getAddress();
int porta = pacoteRecebido.getPort();
String fraseEmMaiusculas = frase.toUpperCase();
Obtém endereço IP, no. de porta do remetente
2: Camada de Aplicação 113
dadosEnviados = fraseEmMaiusculas.getBytes();
DatagramPacket pacoteEnviado =
new DatagramPacket(dadosEnviados,
dadosEnviados.length, IPAddress, porta);
socketServidor.send(pacoteEnviado);
}
}
}
Escrevedatagramano socket
Fim do laço while,volta ao início e aguardachegar outro datagrama
Cria datagrama p/enviar ao cliente
Servidor Web Simples
Ø Funções do servidor Web:ü Trata apenas um pedido HTTP por vezü Aceita e examina o pedido HTTPü Recupera o arquivo pedido do sistema de arquivos do servidor
2: Camada de Aplicação 114
arquivos do servidorü Cria uma mensagem de resposta HTTP consistindo do arquivo solicitado precedido por linhas de cabeçalho
ü Envia a resposta diretamente ao clienteü Depois de criado o servidor, pode-se requisitar um arquivo utilizando um browser;
Servidor Web Simplesimport java.io.*;
import java.net.*;
import java.util.*;
class WebServer {
public static void main(String argv[]) throws Exception
{
String requestMessageLine;
String fileName;
Contém a classe StringTokenizer que éusada para examinar
o pedido
Primeira linha da mensagemde pedido HTTP e
Nome do arquivo solicitado
2: Camada de Aplicação 115
String fileName;
ServerSocket listenSocket = new ServerSocket(6789);
Socket connectionSocket = listenSocket.accept();
BufferedReader inFromClient =
new BufferedReader(new InputStreamReader(
connectionSocket.getInputStream()));
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
Aguarda conexãodo cliente
Nome do arquivo solicitado
Cria fluxo de Entrada
Cria fluxo de Saída
Servidor Web Simples, cont
requestMessageLine = inFromClient.readLine();
StringTokenizer tokenizedLine =
new StringTokenizer(requestMessageLine);
if (tokenizedLine.nextToken().equals("GET")){
fileName = tokenizedLine.nextToken();
Lê a primeira linha dopedido HTTP que deveriater o seguinte formato:
GET file_name HTTP/1.0
Examina a primeira linha da mensagem para extrair
o nome do arquivo
2: Camada de Aplicação 116
fileName = tokenizedLine.nextToken();
if (fileName.startsWith("/") == true )
fileName = fileName.substring(1);
File file = new File(fileName);
int numOfBytes = (int) file.length();
FileInputStream inFile = new FileInputStream (
fileName);
byte[] fileInBytes = new byte[];
inFile.read(fileInBytes);
o nome do arquivo
Associa o fluxo inFile
ao arquivo fileName
Determina o tamanho doarquivo e constrói um vetorde bytes do mesmo tamanho
Servidor Web Simples, cont
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");
Transmissão do cabeçalho da resposta
HTTP.
Inicia a construção damensagem de resposta
2: Camada de Aplicação 117
image/gif\r\n");
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");
}}
HTTP.
Programação de Sockets: referências
Tutorial sobre linguagem C (audio/slides):Ø “Unix Network Programming” (J. Kurose),http://manic.cs.umass.edu.
Tutoriais sobre Java:
2: Camada de Aplicação 118
Tutoriais sobre Java:Ø “Socket Programming in Java: a tutorial,”
http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html
P2P compartilhamento de arquivos
ExemploØ Alice executa a aplicação
cliente P2P no seu notebookØ Interminentemente
conecta com a Internet; adquire um endereço IP
Ø Alice escolhe um dos nós, Bob.
Ø Arquivo é copiado do nó do Bob para o nó (notebook) da Alice: HTTP
Ø Enquanto Alice copia o arquivo do nó de Bob, outros usuários copiam os
2: Camada de Aplicação 119
adquire um endereço IP para cada conexão;
Ø Requisita “Hey Jude”Ø A aplicação apresenta
vários nós que possuem uma cópia de “Hey Jude.
outros usuários copiam os arquivos do nó da Alice;
Ø O nó daAlice é um cliente web como também um servidor web temporário.
Todos os nós são servidores = extremamente escalável!
P2P: diretório centralizado
“Napster” projeto original 1) Quando um dos pares se
conecta, ele informa ao servidor central :
ü Endereço IP
Servidor de diretório
centralizadopares
Bob
1
1
2: Camada de Aplicação 120
ü Endereço IPü conteúdo
2) Alice procura por “Hey Jude”
3) Alice requisita o arquivo de Bob
Alice
1
12
3
P2P: problemas com diretórios centralizados
Ø Único ponto de falhaØ Gargalo de
desempenhoØ Infringe-se Copyright
transferência de arquivo é descentralizada, mas localizar conteúdo é totalmente descentralizada
2: Camada de Aplicação 121
P2P: diretório descentralizado
Ø Cada par ou é um líder de grupo ou pertence ao grupo de um líder;
Ø O líder do grupo localiza o conteúdo em
2: Camada de Aplicação 122
localiza o conteúdo em todos os seus filhos;
Ø Os pares consultam o líder do grupo; o par líder pode consultar outros nós pares que também são líder;
Par qualquer
Par líder do grupo
Relacionamento de vizinhançana rede de cobertura
Mais sobre diretório descentralizado
Rede de coberturaØ Os pares são nósØ Arestas entre os pares e o
seu líder;Ø Arestas entre alguns nós
pares líderes de grupos;
Vantagens da abordagemØ Nenhum servidor
centralizado;ü O serviço de localização é
distribuído entre os pares
2: Camada de Aplicação 123
pares líderes de grupos;Ø Vizinhos virtuaisNó bootstrapØ O par conectado ou faz
parte de um grupo de um líder ou é um par líder de grupo;
distribuído entre os pares ü Mais dificuldade de se ter
falhas;
Desvantagem da abordagemØ Necessário nó bootstrapØ O líder do grupo pode ficar
sobrecarregado;
P2P: fluxo de consultas (query flooding)Ø Gnutella Ø Sem hierarquiaØ Mensagem joinØ Usa o nó bootstrap para
aprender sobre os outros
Ø Envia a “pergunta ou consulta”para os vizinhos;
Ø Vizinhos reencaminham as mensagens;
Ø Se o par consultado possui o objeto, envia uma mensagem de volta para o par originador da
2: Camada de Aplicação 124
volta para o par originador da consulta;
join
Chapter 2: Application layer
r 2.1 Principles of network applications � app architectures� app requirements
r 2.2 Web and HTTP
r 2.6 P2P applicationsr 2.7 Socket programming
with TCPr 2.8 Socket programming
with UDP
2: Application Layer 125
r 2.2 Web and HTTPr 2.4 Electronic Mail
� SMTP, POP3, IMAP
r 2.5 DNS
with UDP
Pure P2P architecture
r no always-on serverr arbitrary end systems
directly communicater peers are intermittently
connected and change IP
peer-peer
2: Application Layer 126
connected and change IP addresses
r Three topics:� File distribution� Searching for information� Case Study: Skype
File Distribution: Server-Client vs P2PQuestion : How much time to distribute file from one server to N peers?
Server
us: server upload bandwidth
ui: peer i upload bandwidth
2: Application Layer 127
us
u2d1d2
u1
uN
dN
Network (with abundant bandwidth)
File, size F
bandwidth
di: peer i download bandwidth
File distribution time: server-client
us
u2d1 d2
u1
uN
dN
Server
Network (with abundant bandwidth)
Fr server sequentially sends N copies:� NF/us time
r client i takes F/di time to download
2: Application Layer 128
uNclient i takes F/di time to download
increases linearly in N(for large N)
= dcs = max { NF/us, F/min(di) }i
Time to distribute Fto N clients using
client/server approach
File distribution time: P2P
us
u2d1 d2
u1
uN
dN
Server
Network (with abundant bandwidth)
Fr server must send one copy: F/us time
r client i takes F/di time to download
r NF bits must be
2: Application Layer 129
uNr NF bits must be downloaded (aggregate)r fastest possible upload rate: us + Σui
dP2P = max { F/us, F/min(di) , NF/(us + Σui) }i
2.5
3
3.5M
inim
um
Dis
trib
ution T
ime P2P
Client-Server
Server-client vs. P2P: example
Client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
2: Application Layer 130
0
0.5
1
1.5
2
0 5 10 15 20 25 30 35
N
Min
imum
Dis
trib
ution T
ime
File distribution: BitTorrent
tracker: tracks peers participating in torrent
torrent: group of peers exchanging chunks of a file
r P2P file distribution
2: Application Layer 131
obtain listof peers
trading chunks
peer
BitTorrent (1)
r file divided into 256KB chunks.r peer joining torrent:
� has no chunks, but will accumulate them over time
2: Application Layer 132
has no chunks, but will accumulate them over time� registers with tracker to get list of peers, connects to subset of peers (“neighbors”)
r while downloading, peer uploads chunks to other peers.
r peers may come and gor once peer has entire file, it may (selfishly) leave or
(altruistically) remain
BitTorrent (2)Pulling Chunksr at any given time,
different peers have different subsets of file chunksperiodically, a peer
Sending Chunks: tit-for-tatr Alice sends chunks to four
neighbors currently sending her chunks at the highest rate� re-evaluate top 4 every 10 secs
2: Application Layer 133
r periodically, a peer (Alice) asks each neighbor for list of chunks that they have.
r Alice sends requests for her missing chunks� rarest first
10 secsr every 30 secs: randomly
select another peer, starts sending chunks� newly chosen peer may join top 4
� “optimistically unchoke”
BitTorrent: Tit-for-tat(1) Alice “optimistically unchokes” Bob(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates(3) Bob becomes one of Alice’s top-four providers
2: Application Layer 134
With higher upload rate, can find better trading partners & get file faster!
Distributed Hash Table (DHT)
r DHT = distributed P2P databaser Database has (key, value) pairs;
� key: ss number; value: human name� key: content type; value: IP address� key: content type; value: IP address
r Peers query DB with key� DB returns values that match the key
r Peers can also insert (key, value) peers
DHT Identifiers
r Assign integer identifier to each peer in range [0,2n-1].� Each identifier can be represented by n bits.
r Require each key to be an integer in same range.Require each key to be an integer in same range.r To get integer keys, hash original key.
� eg, key = h(“Led Zeppelin IV”)� This is why they call it a distributed “hash” table
How to assign keys to peers?
r Central issue:� Assigning (key, value) pairs to peers.
r Rule: assign key to the peer that has the closest ID.closest ID.
r Convention in lecture: closest is the immediate successor of the key.
r Ex: n=4; peers: 1,3,4,5,8,10,12,14; � key = 13, then successor peer = 14� key = 15, then successor peer = 1
1
3
4
15
Circular DHT (1)
5
810
12
r Each peer only aware of immediate successor and predecessor.
r “Overlay network”
Circle DHT (2)
0001
00111111
Who’s resp
for key 1110 ?I am
O(N) messageson avg to resolvequery, when thereare N peers
0100
0101
10001010
1100
1110
1110
1110
1110
1110
1110
Define closestas closestsuccessor
Circular DHT with Shortcuts1
3
4
512
15
Who’s resp for key 1110?
r Each peer keeps track of IP addresses of predecessor, successor, short cuts.
r Reduced from 6 to 2 messages.r Possible to design shortcuts so O(log N) neighbors, O(log
N) messages in query
5
810
12
Peer Churn1
3
4
512
15
•To handle peer churn, require each peer to know the IP address of its two successors. • Each peer periodically pings its two successors to see if they are still alive.
r Peer 5 abruptly leavesr Peer 4 detects; makes 8 its immediate successor;
asks 8 who its immediate successor is; makes 8’s immediate successor its second successor.
r What if peer 13 wants to join?
5
810
12
P2P Case study: Skype
r inherently P2P: pairs of users communicate.
r proprietary application-layer protocol (inferred via
Skype clients (SC)
Supernode (SN)
Skype login server
2: Application Layer 142
protocol (inferred via reverse engineering)
r hierarchical overlay with SNs
r Index maps usernames to IP addresses; distributed over SNs
(SN)
Peers as relays
r Problem when both Alice and Bob are behind “NATs”. � NAT prevents an outside
peer from initiating a call to insider peer
2: Application Layer 143
to insider peerr Solution:
� Using Alice’s and Bob’s SNs, Relay is chosen
� Each peer initiates session with relay.
� Peers can now communicate through NATs via relay
P2P: mais sobre fluxo de consultas
PrósØ pares possuem
responsabilidades semelhantes: não existem líderes de
ContrasØ Tráfico excessivo de
consultasØ Raio da consulta: pode
não ser o suficiente
2: Camada de Aplicação 144
existem líderes de grupo;
Ø Extremamente descentralizado;
Ø Nenhum par mantem informações de diretório;
não ser o suficiente para obter o conteúdo, quando este existir;
Ø Manutenção de uma rede de cobertura;
Ø Necessário nó bootstrap
Capítulo 2: Resumo
Ø Requisitos do serviço de aplicação:
ü confiabilidade, banda, retardo
Ø paradigma cliente-servidor
Terminamos nosso estudo de aplicações de rede!Ø Protocolos específicos:
ü httpü ftpü smtp, pop3, imap
2: Camada de Aplicação 145
Ø paradigma cliente-servidor Ø modelo de serviço do
transporte ü orientado a conexão,
confiável da Internet: TCPü não confiável, datagramas:
UDP
smtp, pop3, imapü dns
Ø programação c/ socketsü implementação
cliente/servidorü usando sockets tcp, udp
Ø Distribuição de conteúdo:ü caches, CDNsü P2P
Capítulo 2: Resumo
Ø troca típica de mensagens pedido/resposta:
ü cliente solicita info ou serviçoü servidor responde com dados,
Mais importante: aprendemos sobre protocolos
Ø msgs de controle X dadosü na banda, fora da banda
Ø centralizado X descentralizado
2: Camada de Aplicação 146
ü servidor responde com dados, código de status
Ø formatos de mensagens:ü cabeçalhos: campos com info
sobre dados (metadados)ü dados: info sendo comunicada
Ø centralizado X descentralizado Ø s/ estado X c/ estadoØ transferência de msgs
confiável X não confiável Ø “complexidade na borda da
rede”Ø segurança: autenticação
Top Related