04 CamadaDeAplicacao

T EORIA DE REDES
PROF. VINICIUS RUIZ MARTINS
CAMADA DE APLICAÇÃO
CAMADA DE APLICAÇÃO TEORIA DE REDES
Objetivos:
• Conceitual, aspectos de implementação de protocolos de aplicação de redes

• Modelos de serviço da camada de transporte
• Paradigma cliente-servidor
• Paradigma de compartilhamento de arquivos P2P (peer-to-peer)
• Aprender sobre protocolos examinando protocolos da camada de aplicação
populares:
• HTTP (Hypertext Transfer Protocol)
• FTP (File Transfer Protocol)
• Correio eletrônico: SMTP (Simple Mail Transfer Protocol) / POP3 (Post Office Protocol) /
IMAP (Internet Message Access Protocol)
• DNS (Domain Name System)
• Programação de aplicações de rede
• Socket API (Application Programming Interface)
• Programação de socket com TCP (Transmission Control Protocol)
• Programação de socket com UDP (User Datagram Protocol)
2
SUMÁRIO
• Princípios de aplicações de rede

• Web e HTTP
• FTP
• Correio eletrônico (SMTP, POP3, IMAP)
• DNS
• Compartilhamento de arquivos P2P
3
Razão de ser de uma rede de computadores.
Algumas aplicações de rede:
• E-mail
• Web
• Mensagem instantânea
• Login remoto
• Compartilhamento de arquivo P2P
• Jogos de rede multiusuário
• Streaming stored videoclipes
• Telefonia via Internet
• Videoconferência em tempo real
• Computação paralela massiva
4
CRIANDO UMA NOVA APLICAÇÃO DE REDE
Escrever programas que

• Executem sobre diferentes sistemas
finais e
• Se comuniquem através de uma rede.
Ex.: aplicação Web – software de
servidor Web se comunicando com
software do browser (navegador)
5
CRIANDO UMA NOVA APLICAÇÃO DE REDE
Nenhum software é escrito

para dispositivos no núcleo
da rede!
• Dispositivos do núcleo da rede não trabalham na camada de aplicação.
• Confinar o software de aplicação nos sistemas finais permite um rápido

desenvolvimento de aplicações de Internet.
6
ARQUITETURAS DE APLICAÇÃO
Antes de construir uma nova aplicação de rede, o desenvolvedor

primeiramente precisa escolher a arquitetura da aplicação.
• Cliente-servidor
• Peer-to-peer (P2P)
• Híbrida de cliente-servidor e P2P
7
ARQUITETURA CLIENTE-SERVIDOR
Servidor:
• Hospedeiro sempre ativo
• Endereço IP permanente
• Fornece serviços solicitados pelo
cliente
Obs.: Server farm: conjunto de
hospedeiros, servidor virtual, para
atender à demanda dos clientes.
Clientes:
• Comunicam-se com o servidor
• Podem ser conectados
intermitentemente
• Podem ter endereço IP dinâmico
• Não se comunicam diretamente
uns com os outros
Ex.: Web, transferência de arquivos, login

remoto, e-mail.
8
ARQUITETURA P2P PURA
• Peer-to-peer, par-a-par
• Não há um servidor sempre funcionando
no centro da aplicação
• Sistemas finais arbitrários comunicam-se
diretamente
• Pares são intermitentemente conectados e
trocam endereços IP
• Ex.: BitTorrent, Skype, IPTV.
Altamente escaláveis mas difíceis

de gerenciar
Embora cada par gere uma carga de trabalho solicitando
arquivos, também acrescenta capacidade de serviço ao
sistema distribuindo arquivos a outros pares.
Um par pode ter a única cópia de um arquivo importante
e sair da comunidade a qualquer momento.
9
ARQUITETURA HÍBRIDA CLIENTE-SERVIDOR E P2P
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 usuários
que estão online e disponíveis.
10
COMUNICAÇÃO DE PROCESSOS
Processo: programa executando num hospedeiro.

• Dentro do mesmo hospedeiro: dois processos se comunicam usando
comunicação interprocesso (definido pelo SO).
• Processos em diferentes hospedeiros se comunicam por meio de troca
de 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
11
SOCKETS
• Um processo envia/recebe
mensagens para/de seu socket.
• O socket é análogo a uma porta
• O processo de envio empurra
a mensagem para fora da
porta.
• O processo de envio confia
na infra-estrutura de
transporte no outro lado da
porta que leva a mensagem
para o socket no processo de
recepção.
• Também denominado API (Application Programming Interface): interface

entre as camadas de aplicação e transporte
O desenvolvedor da aplicação controla a camada de aplicação. Já na camada de transporte
pode apenas escolher o protocolo de transporte e, talvez, fixar alguns parâmetros (tamanho
máximo de buffer, etc).
12
PROCESSOS DE ENDEREÇAMENTO
• Para um processo receber mensagens, ele deve ter um identificador.

• Um hospedeiro possui um único endereço IP de 32 bits.
Pergunta: O endereço IP do hospedeiro onde o processo está executando é

suficiente para identificar o processo?
Resposta: Não, muitos processos podem estar em execução no mesmo
hospedeiro.
• O identificador inclui o endereço IP e o número da porta associada ao processo

no hospedeiro.
Exemplos de números de porta:
• Servidor HTTP: 80
• Servidor de Correio: 25
13
O PROTOCOLO DA CAMADA DE APLICAÇÃO DEFINE
Como as mensagens enviadas via sockets são estruturadas?

Quem define isso são os protocolos da camada de aplicação, que definem:
• Tipo das mensagens trocadas (ex: mensagens de requisição e resposta);

• Sintaxe dos tipos de mensagem: os campos nas mensagens e como são
delineados;
• Semântica dos campos, ou seja, significado da informação nos campos;
• Regras para quando e como os processos enviam e respondem às mensagens.
Protocolos de domínio público:

• Definidos nas RFCs
• Recomendados para interoperabilidade
• Ex.: HTTP (Hypertext Transfer Protocol), SMTP (Simple Mail Transfer Protocol)
Protocolos proprietários:
• Ex.: Skype, KaZaA (programa de compartilhamento de arquivos ponto a ponto).
14
DE QUAL SERVIÇO DE TRANSPORTE UMA APLICAÇÃO

NECESSITA?
Escolha do protocolo de camada de transporte que atenda às necessidades
da aplicação
• Analogia: escolha entre uma viagem de trem ou de avião.
Perda de dados
• Algumas aplicações (ex.: áudio) podem tolerar alguma perda
• Outras aplicações (ex.: transferência de arquivos, telnet) exigem
transferência de dados 100% confiável
Temporização
• Algumas aplicações (ex.: telefonia Internet, jogos interativos) exigem
baixos atrasos para serem “efetivos”
Vazão (largura de banda)
• Algumas aplicações (ex.: multimídia) exigem uma vazão r bits/s para serem
“efetivas”
• Outras aplicações (“aplicações elásticas”), quanto maior a vazão melhor,
mas aceitam o que estiver disponível.
15
REQUISITOS DE TRANSPORTE DE APLICAÇÃO COMUNS
* e-business: sim
16
SERVIÇOS DOS PROTOCOLOS DE TRANSPORTE DA

INTERNET
Serviço TCP:
• Orientado à conexão: conexão requerida entre processos cliente e servidor.
• Transporte confiável entre os processos de envio e recepção.
• Controle de fluxo: o transmissor não sobrecarrega o receptor.
• Controle de congestionamento: protege a rede do excesso de tráfego.
Serviço UDP:
• Transferência de dados não confiável entre os processos transmissor e receptor.
• Não oferece: estabelecimento de conexão, confiabilidade, controle de fluxo e
de congestionamento, garantia de temporização e de banda mínima.
Os dois serviços não oferecem: garantias de temporização e de banda mínima.
Pergunta: Por que ambos? Por que existe o UDP?
17
APLICAÇÃO E PROTOCOLOS DE TRANSPORTE DA

INTERNET
18
SUMÁRIO

• Web e HTTP
• FTP
• DNS
19
WEB E HTTP
Alguns jargões:
• Página Web consiste de objetos.

• Objeto pode ser arquivo HTML (HyperText Markup Language, Linguagem
de Marcação de Hipertexto), imagem (JPEG, GIF, …), applet Java, arquivo
de áudio,…
• A página Web consiste de arquivo-HTML base, que inclui vários objetos
referenciados.
• Cada objeto é endereçado por uma URL (Uniform Resource Locator,
localizador uniforme de recursos).
Exemplo de URL:
https:\\www.someschool.edu/someDept/pic.gif
Protocolo Nome do hospedeiro Nome do caminho
(domínio)
20
WEB E HTTP
Atividade Classroom
Por que o Google quer “acabar com a URL” como

conhecemos
21
VISÃO GERAL DO HTTP
HTTP: hypertext transfer protocol

• Protocolo da camada de aplicação
da Web
• Modelo cliente/servidor
• Cliente: browser que solicita,
recebe e apresenta objetos da Web
• Servidor: envia objetos em
resposta a pedidos
• HTTP 1.0: RFC 1945
• HTTP 1.1: RFC 2068
22
Utiliza TCP:
• Cliente inicia conexão TCP (cria um socket) com o servidor na porta 80;
• Servidor aceita uma conexão TCP do cliente;
• Mensagens HTTP (mensagens do protocolo de camada de aplicação) são
trocadas entre o browser (cliente HTTP) e o servidor Web (servidor HTTP);
• A conexão TCP é fechada.
Obs.: uma das vantagens de uma arquitetura de camadas:
O HTTP não precisa se preocupar com dados perdidos ou com detalhes de como
o TCP recupera a perda de dados ou os reordena dentro da rede.
Esta é a tarefa do TCP e dos protocolos das camadas mais inferiores da pilha de
protocolos.
23
HTTP é “stateless” (protocolo sem estado)

• O servidor não mantém informação sobre os pedidos passados pelos
clientes.
Se um determinado cliente solicita o mesmo objeto duas vezes em um
período de poucos segundos, o servidor não responde dizendo que
acabou de enviar o objeto ao cliente.
Em vez disso, envia novamente o objeto, pois já “esqueceu”
completamente o que fez antes.
Protocolos que mantêm informações de “estado” são complexos!

• Histórico do passado (estado) deve ser mantido.
• Se o servidor/cliente quebra, suas visões de “estado” podem ser
inconsistentes, devendo ser reconciliadas.
24
CONEXÕES HTTP
HTTP não persistente

• No máximo, um objeto é enviado sobre uma conexão TCP.
• O HTTP/1.0 utiliza HTTP não persistente.
HTTP persistente
• Múltiplos objetos podem ser enviados sobre uma conexão TCP entre o
cliente e o servidor.
• O HTTP/1.1 utiliza conexões persistentes em seu modo padrão.
25
HTTP NÃO PERSISTENTE

Usuário entra com a URL:
www.someSchool.edu/someDepartment/home.index
Obs.: a página consiste de 1 arquivo-base HTML e de 10 imagens jpeg.
1a. Cliente HTTP inicia conexão TCP

ao servidor HTTP (processo) em
www.someSchool.edu. Porta 80 1b. Servidor HTTP no hospedeiro
é a default para o servidor HTTP www.someSchool.edu esperando
pela conexão TCP na porta 80.
“Aceita” conexão, notificando o
cliente
2. Cliente HTTP envia HTTP request
message (contendo a URL) para o
socket da conexão TCP 3. Servidor HTTP recebe mensagem de
pedido, forma response message
contendo o objeto solicitado
(someDepartment/home.index),
envia mensagem para o socket
Tempo
26
HTTP NÃO PERSISTENTE
4. Servidor HTTP fecha conexão TCP
5. Cliente HTTP recebe mensagem

de resposta contendo o arquivo
html, apresenta o conteúdo
html. Analisando o arquivo html,
encontra 10 objetos jpeg
Tempo referenciados
6. Passos 1-5 são repetidos para cada

um dos 10 objetos jpeg
27
MODELAGEM DO TEMPO DE RESPOSTA
Definição de RRT (round-trip-

time): tempo para enviar um
pequeno pacote que vai do
cliente para o servidor e
retorna.
Tempo de resposta:
• Um RTT para iniciar a
conexão TCP;
• Um RTT para requisição
HTTP e os bytes da
resposta HTTP para
retorno;
• Tempo de transmissão de
arquivo.
Total = 2 RTTs + tempo de transmissão

28
HTTP PERSISTENTE
Conexões não persistentes têm algumas desvantagens.
▪ Primeiro, uma nova conexão deve ser estabelecida e mantida para cada objeto
solicitado. Para cada conexão, devem ser alocados buffers TCP e conservadas
variáveis TCP tanto no cliente quanto no servidor. Isso pode sobrecarregar
seriamente o servidor Web (OS), que poderá estar processando requisições de
centenas de diferentes clientes ao mesmo tempo.
▪ Obs.: os browsers frequentemente abrem conexões TCP paralelas para buscar
objetos referenciados
▪ Segundo, cada objeto sofre 2 RTTs: um para estabelecer a conexão TCP e outro
para solicitar e receber um objeto.
HTTP persistente
• Servidor deixa a conexão aberta após enviar uma resposta.

• Mensagens HTTP subsequentes entre o mesmo cliente/servidor são
enviadas pela conexão.
29
HTTP PERSISTENTE
Persistente sem pipelining (ou sem paralelismo):
• O cliente emite novas requisições apenas quando a resposta anterior for

recebida.
• Um RTT para cada objeto referenciado.
• Gera ociosidade na conexão do servidor.
Persistente com pipelining (ou com paralelismo):
• Padrão no HTTP/1.1
• O cliente envia requisições assim que encontra um objeto referenciado.
• O servidor envia os objetos sequencialmente.
• Gasta-se apenas um RTT para todos os objetos referenciados.
30
MENSAGEM HTTP
• As especificações do HTTP [RFC 1945; RFC 2616]

incluem as definições dos formatos das mensagens
HTTP.
• Há dois tipos delas: de requisição (request) e de

resposta (response).
Como exemplo, será apresentada a mensagem request.
31
MENSAGEM HTTP REQUEST

• ASCII (formato legível para humanos)
Linha de requisição Objeto requisitado Versão

(comandos GET, POST,
HEAD ) GET /somedir/page.html HTTP/1.0
Linhas de
User-agent: Mozilla/4.0
cabeçalho Accept: text/html, image/gif,image/jpeg
Accept-language:fr
Carriage return (cr),
line feed (lf) (extra carriage return, line feed)
indica fim da mensagem
Exemplos de cabeçalhos de negociação de conteúdo:

• User-agent: especifica o tipo de navegador que está fazendo a requisição ao servidor.
(Útil pois o servidor pode enviar versões diferentes do mesmo objeto a tipos diferentes de
agentes de usuário).
• Accept-language: mostra que o usuário prefere receber uma versão em francês do objeto
se este existir no servidor; se não existir, o servidor deve enviar a versão default.
32
MENSAGEM HTTP REQUEST: FORMATO GERAL
Corpo da entidade
• Fica vazio com o método GET.
• Método POST: quando um usuário preenche um formulário (palavras de busca a um site
buscador). O conteúdo específico de retorno depende do que o usuário escreveu.
33
CÓDIGOS DE STATUS DAS RESPOSTAS
Na primeira linha da mensagem de resposta servidor → cliente.

Alguns exemplos de códigos:
• 200 OK
Requisição bem-sucedida, objeto requisitado a seguir nesta mensagem.
• 301 Moved permanently

Objeto requisitado foi movido, nova localização especificada a seguir nesta
mensagem (cabeçalho Location: da mensagem de resposta).
• 400 Bad request

Mensagem de requisição não compreendida pelo servidor.
• 404 Not Found

Documento requisitado não encontrado neste servidor.
• 505 HTTP version not supported

Versão do protocol HTTP não suportada pelo servidor.
34
TESTANDO UMA MENSAGEM HTTP

1) Dê um comando Telnet em um servidor.
2) Digite uma mensagem de requisição de uma linha solicitando algum objeto
abrigado no servidor. Exemplo:
Abre conexão TCP para a porta 80
telnet cis.poly.edu 80 (porta default do servidor HTTP) em
cis.poly.edu.
GET /~ross/ HTTP/1.1 Qualquer coisa digitada é enviada
Host: cis.poly.edu para a porta 80 em cis.poly.edu
3) Pressione duas vezes a tecla “Enter” (cariage return) após digitar a última
linha. Está sendo enviado este pedido HTTP GET mínimo (mas completo) ao
servidor HTTP.
Essa sequência de comandos abre uma conexão TCP para a porta número 80
do hospedeiro cis.poly.edu e, em seguida, envia a mensagem de requisição
HTTP.
Deverá aparecer uma mensagem de resposta que inclui o arquivo-base HTML
da homepage em questão.
35
TESTANDO UMA MENSAGEM HTTP

Outros testes:
1) Para apenas ver as linhas da mensagem HTTP e não receber o objeto em si,
substitua GET por HEAD.
2) Substitua /~ross/ por /~banana/ e veja que tipo de mensagem obtida.
3)
telnet ucl.br 80
GET /~historico/ HTTP/1.1
Host: ucl.br
Obs.:
1) Para habilitar o Telnet execute o comando optionalfeatures, em seguida

marque a opção "Cliente Telnet".
2) Para parar o Telnet: CTRL + ] ou CTRL + ç. Para sair: q.

36
SUMÁRIO

• Web e HTTP
• FTP
• DNS
37
FTP: O PROTOCOLO DE TRANSFERÊNCIA DE ARQUIVOS
• Transferência de arquivos de e para o computador remoto

• Modelo cliente servidor
• Cliente: lado que inicia a transferência (seja de ou para o lado remoto)
• Servidor: hospedeiro remoto
• FTP: RFC 959
• FTP servidor: porta 21
38
• Primeiro o usuário fornece o nome do hospedeiro remoto, o que faz com

que o processo cliente FTP do hospedeiro local estabeleça uma conexão
TCP com o processo servidor FTP do hospedeiro remoto.
• O usuário então fornece sua identificação e senha, que são enviadas pela
conexão TCP como parte dos comandos FTP. Assim que autorizado pelo
servidor, o usuário copia um ou mais arquivos armazenados no sistema de
arquivo local para o sistema de arquivo remoto (ou vice-versa).
39
• HTTP e FTP são protocolos de transferência de arquivos e têm muitas

características em comum (Ex.: utilizam o TCP).
• Diferença notável: FTP usa duas conexões TCP paralelas para transferir um
arquivo: uma conexão de controle e uma conexão de dados.
▫ Controle: usada para enviar informações de controle entre os dois
hospedeiros — como identificação de usuário, senha, comandos para trocar
diretório remoto e comandos de “enviar” (put) e “receber” (get) arquivos;
▫ Dados: usada para enviar de fato um arquivo.
• Como o FTP usa uma conexão de controle separada, dizemos que ele envia
suas informações de controle fora da banda.
Obs.: o HTTP envia linhas de cabeçalho de requisição e de resposta pela
mesma conexão TCP que carrega o próprio arquivo transferido. Por essa
razão, dizemos que o HTTP envia suas informações de controle na banda.
(Assim como acontece com o SMTP, o principal protocolo para correio
eletrônico).
40
FTP: CONTROLE SEPARADO, CONEXÕES DE DADOS

• Cliente FTP contata o servidor FTP na porta 21 especificando o TCP como
protocolo de transporte
• Cliente obtém autorização pela conexão de controle
• Cliente procura o diretório remoto enviando comandos pela conexão de controle
• Quando o servidor recebe um comando para uma transferência de arquivo, ele
abre uma conexão de dados TCP para o cliente
• Após a transferência de um arquivo, o servidor fecha a conexão de dados. A
conexão de controle permanece aberta durante toda a sessão do usuário.
• Servidor abre uma segunda conexão de dados TCP para transferir outro arquivo (a
conexão de dados é não persistente!)
• Conexão de controle: “fora da banda”
• Servidor FTP mantém “estado”: diretório atual, autenticação anterior
(lembrando: HTTP é sem estado).
41
SUMÁRIO

• Web e HTTP
• FTP
• DNS
42
CORREIO ELETRÔNICO
Três componentes principais:

• Agentes de usuário
• Servidores de correio
• Simple mail transfer protocol:
SMTP
Agente de usuário
•“leitor de correio”
• Composição, edição, leitura de
mensagens de correio
• Ex.: MS Outlook, Apple Mail
• Mensagens de entrada e de
saída são armazenadas no
servidor
43
CORREIO ELETRÔNICO: SERVIDORES DE CORREIO
Servidores de correio
• Caixa postal contém mensagens
que chegaram (ainda não lidas)
para o usuário
• Fila de mensagens contém as
mensagens de correio a serem
enviadas
• Cuidam das falhas: se o servidor
de correio do remetente não
puder fazer a entrega, manterá
a mensagem em uma fila e
tentará transferi-la mais tarde.
Normalmente novas tentativas
são feitas aprox. a cada 30
minutos. Se não obtiver sucesso
após alguns dias, o servidor
removerá a mensagem e
notificará o remetente. 44
CORREIO ELETRÔNICO: SMTP
Protocolo SMTP
Usa TCP para transferência

confiável de mensagens de
correio do cliente ao servidor,
porta 25.
Permite aos servidores de correio

trocarem mensagens entre si
• Cliente: servidor de correio
que envia
• “Servidor”: servidor de
correio que recebe
45
CORREIO ELETRÔNICO: SMTP
• Transferência direta: servidor que envia para o servidor que recebe.
• Três fases de transferência

• Handshaking (apresentação)
• Transferência de mensagens
• Fechamento
• Interação comando/resposta
• Comandos: texto ASCII
• Resposta: código de status e frase
• Mensagens devem ser formatadas em código ASCII de 7 bits.

(Tecnologia antiga!)
46
CORREIO ELETRÔNICO: CENÁRIO EXEMPLO

1) Alice usa o agente de usuário para compor a mensagem e para enviar a
bob@ucl.br
2) O agente de usuário dela envia a mensagem para o seu servidor de correio; a
mensagem é colocada na fila de mensagens.
3) O lado cliente do SMTP abre uma conexão TCP com o servidor de correio do
Bob.
4) O cliente SMTP envia a mensagem de Alice pela conexão TCP.
5) O servidor de correio de Bob coloca a mensagem na caixa de correio de Bob.
6) Bob invoca seu agente de usuário para ler a mensagem (quando ele quiser).
47
PROTOCOLOS DE ACESSO AO CORREIO
• SMTP: entrega e armazena no servidor do destino

• Protocolo de acesso: recupera mensagens do servidor
• POP: Post Office Protocol [RFC 1939]
• Autorização (agente <-->servidor) e download
• IMAP: Internet Mail Access Protocol [RFC 1730]
• Mais recursos (mais complexo)
• Manipulação de mensagens armazenadas no servidor
• HTTP: Hotmail, Yahoo!, Google, etc.
48
PROTOCOLOS DE ACESSO AO CORREIO
POP3
• Configurações: “ler-e-apagar” e “ler-e-guardar”.
• “ler-e-apagar”: não se pode reler o e-mail se trocar o cliente.
• “ler-e-guadar”: cópias das mensagens em clientes diferentes.
• POP3 é stateless através das sessões.
IMAP
• Mantém todas as mensagens em um lugar: o servidor.
• Permite que o usuário organize as mensagens em pastas.
• IMAP mantém o estado do usuário através das sessões:
• Nomes das pastas e mapeamentos entre os IDs da mensagem e o
nome da pasta.
49
SUMÁRIO

• Web e HTTP
• FTP
• DNS
50
DNS: DOMAIN NAME SYSTEM
Pessoas: muitos identificadores:

• RG, nome, passaporte
Assim como seres humanos podem ser identificados de muitas maneiras, o

mesmo acontece com hospedeiros da Internet.
Um identificador é seu nome de hospedeiro (hostname). Nomes de
hospedeiro
ieee.org, www.yahoo.com, ucl.br
são mais fáceis de lembrar!

Mas fornecem pouca (ou quase nenhuma) informação sobre a localização
de um hospedeiro na Internet.
51
DNS: DOMAIN NAME SYSTEM
Internet hospedeiros, roteadores:

• Endereços IP (32 bits) - usados para endereçar datagramas
• “nome”, ex.: ucl.br - usados por humanos
P.: Como relacionar nomes com endereços IP?
Domain Name System:

• Base de dados distribuída implementada numa hierarquia de muitos
servidores de nomes
• Protocolo de camada de aplicação 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
52
BASE DE DADOS DISTRIBUÍDA, HIERÁRQUICA
Servidores de
nomes raiz
Servidores
TLD (top-
level domain)
Servidores DNS
com autoridade
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
53
BASE DE DADOS DISTRIBUÍDA, HIERÁRQUICA
Por que não centralizar o DNS?

• Ponto único de falha;
• Volume de tráfego;
• Base centralizada de dados distante;
• Manutenção.
54
EXEMPLO 1
• 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:
• Servidor contatado
responde com o nome de
outro servidor de nomes
para contato
• “Eu não sei isto, mas
pergunte a este servidor”
55
EXEMPLO 1
Este exemplo trata de consultas
recursivas e consultas iterativas.
A consulta enviada de cis.poly.edu

para dns.poly.edu é recursiva,
visto que pede a dns.poly.edu que
obtenha o mapeamento em seu
nome.
As três consultas subsequentes são

iterativas, visto que todas as
respostas são retornadas
diretamente a dns.poly.edu.
Na prática, as consultas em geral

seguem este padrão: a consulta do
hospedeiro requisitante ao servidor
DNS local é recursiva e todas as
outras são iterativas.
56
EXEMPLO 2
Mostra uma cadeia de consultas DNS

na qual todas são recursivas.
57
SUMÁRIO

• Web e HTTP
• FTP
• DNS
58
COMPARTILHAMENTO DE ARQUIVOS P2P
• Com uma arquitetura P2P, há dependência mínima (se houver) de

servidores com infraestrutura que permanecem sempre ligados.
• Em vez disso, duplas de hospedeiros intermitentemente

conectados (chamados pares), comunicam-se direto entre si.
• Os pares não são de propriedade de um provedor de serviços, mas sim de

desktops e laptops controlados por usuários.
59
COMPARTILHAMENTO DE ARQUIVOS P2P
Exemplo
• Alice executa a aplicação cliente P2P em seu notebook
• intermitentemente, conecta-se à Internet; obtém novos endereços IP para
cada conexão
• pede por “Hey Jude”
• a aplicação exibe outros pares que possuem uma cópia de Hey Jude
• Alice escolhe um dos pares, Bob
• o arquivo é copiado do PC de Bob para o notebook de Alice: HTTP
• enquanto Alice faz o download, outros usuários fazem upload de Alice
• o par de Alice é tanto um cliente Web como um servidor Web transiente
Todos os pares são servidores = altamente escaláveis!
60
APLICAÇÕES P2P
Distribuição de arquivos P2P
• Na distribuição de arquivos P2P, cada par pode redistribuir

qualquer parte do arquivo recebido para outros pares, auxiliando,
assim, o servidor no processo de distribuição.
• O tempo de distribuição é o tempo necessário para que todos os N

pares obtenham uma cópia do arquivo.
• O BitTorrent é um protocolo P2P popular para distribuição de

arquivos.
61
APLICAÇÕES P2P
Um problema ilustrativo de
distribuição de arquivo
u: upload
d: download
62
APLICAÇÕES P2P
Tempo de distribuição
para arquiteturas P2P
e cliente-servidor
O tempo de distribuição é o tempo necessário para que todos os N pares

obtenham uma cópia do arquivo.
63
APLICAÇÕES P2P
Distribuição de arquivos com

o BitTorrent
64

04 CamadaDeAplicacao

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

04 CamadaDeAplicacao

Enviado por

Direitos autorais:

Formatos disponíveis

T EORIA DE REDES

PROF. VINICIUS RUIZ MARTINS

• Conceitual, aspectos de implementação de protocolos de aplicação de redes

• Princípios de aplicações de rede

Razão de ser de uma rede de computadores.

Algumas aplicações de rede:

CRIANDO UMA NOVA APLICAÇÃO DE REDE

Escrever programas que

CRIANDO UMA NOVA APLICAÇÃO DE REDE

Nenhum software é escrito

• Dispositivos do núcleo da rede não trabalham na camada de aplicação.

• Confinar o software de aplicação nos sistemas finais permite um rápido

Antes de construir uma nova aplicação de rede, o desenvolvedor

Ex.: Web, transferência de arquivos, login

ARQUITETURA P2P PURA

Altamente escaláveis mas difíceis

ARQUITETURA HÍBRIDA CLIENTE-SERVIDOR E P2P

• Bate-papo entre dois usuários é P2P

Processo: programa executando num hospedeiro.

Nota: aplicações com arquiteturas P2P possuem processos cliente

• Também denominado API (Application Programming Interface): interface

• Para um processo receber mensagens, ele deve ter um identificador.

Pergunta: O endereço IP do hospedeiro onde o processo está executando é

• O identificador inclui o endereço IP e o número da porta associada ao processo

O PROTOCOLO DA CAMADA DE APLICAÇÃO DEFINE

Como as mensagens enviadas via sockets são estruturadas?

• Tipo das mensagens trocadas (ex: mensagens de requisição e resposta);

Protocolos de domínio público:

DE QUAL SERVIÇO DE TRANSPORTE UMA APLICAÇÃO

REQUISITOS DE TRANSPORTE DE APLICAÇÃO COMUNS

SERVIÇOS DOS PROTOCOLOS DE TRANSPORTE DA

Os dois serviços não oferecem: garantias de temporização e de banda mínima.

Pergunta: Por que ambos? Por que existe o UDP?

APLICAÇÃO E PROTOCOLOS DE TRANSPORTE DA

• Princípios de aplicações de rede

• Página Web consiste de objetos.

Por que o Google quer “acabar com a URL” como

VISÃO GERAL DO HTTP

HTTP: hypertext transfer protocol

VISÃO GERAL DO HTTP

Obs.: uma das vantagens de uma arquitetura de camadas:

VISÃO GERAL DO HTTP

HTTP é “stateless” (protocolo sem estado)

Protocolos que mantêm informações de “estado” são complexos!

HTTP não persistente

HTTP NÃO PERSISTENTE

1a. Cliente HTTP inicia conexão TCP

HTTP NÃO PERSISTENTE

4. Servidor HTTP fecha conexão TCP

5. Cliente HTTP recebe mensagem

6. Passos 1-5 são repetidos para cada

MODELAGEM DO TEMPO DE RESPOSTA

Definição de RRT (round-trip-

Total = 2 RTTs + tempo de transmissão

Conexões não persistentes têm algumas desvantagens.

• Servidor deixa a conexão aberta após enviar uma resposta.

Persistente sem pipelining (ou sem paralelismo):

• O cliente emite novas requisições apenas quando a resposta anterior for

Persistente com pipelining (ou com paralelismo):

• As especificações do HTTP [RFC 1945; RFC 2616]

• Há dois tipos delas: de requisição (request) e de

Como exemplo, será apresentada a mensagem request.