Capítulo 2: Camada de Aplicação

suruagy@[Link]

Baseado nos slides de Kurose e Ross

2: Camada de Aplicação 1
Capítulo 2: Roteiro
 2.1 Princípios de aplicações
 de
2.6rede
Aplicações P2P
 2.2 A Web e o HTTP  2.7 Programação e
desenvolvimento
 2.3 Transferência de arquivo: FTP de
aplicações com TCP
 2.4 Correio Eletrônico na Internet
 2.8 Programação de
 2.5 DNS: o serviço de diretório da Internet
sockets com UDP

2: Camada de Aplicação 2
Capítulo 2: Camada de Aplicação
Metas do capítulo:  aprender sobre protocolos
 aspectos conceituais através do estudo de
e de implementação protocolos populares da
de protocolos de camada de aplicação:
aplicação em redes  HTTP
 modelos de serviço da
camada de transporte
 FTP
 paradigma cliente
 SMTP/ POP3/ IMAP
servidor  DNS
 paradigma peer-to-  Criar aplicações de rede
peer  programação usando a API
de sockets

2: Camada de Aplicação 3
Algumas aplicações de rede
 Streaming
Correio eletrônico
de vídeos armazenados (YouTube, Hulu,
 Netflix)
A Web
 Telefonia
 Mensagenspor IP (Skype)
instantâneas

 Videoconferência em tempo
Login em computador remotoreal
como Telnet e SSH

 Busca
Compartilhamento de arquivos P2P
 ...
 Jogos multiusuários em rede
 ...

2: Camada de Aplicação 4
Criando uma aplicação de rede
Programas que aplicação
transporte
 Executam em (diferentes) rede
enlace
sistemas finais física

 Comunicam-se através da rede

 [Link]., servidor Web se comunica
com o navegador
Programas não relacionados
ao núcleo da rede
 Dispositivos do núcleo da rede
aplicação
não executam aplicações dos aplicação transporte
transporte
usuários rede
rede
enlace
enlace
 Aplicações nos sistemas finais física
física

permite rápido desenvolvimento

e disseminação

2: Camada de Aplicação 5
Arquiteturas das aplicações de
rede
 Estruturas possíveis das aplicações:
 Cliente-servidor
 Peer-to-peer (P2P)

2: Camada de Aplicação 6
Arquitetura cliente-servidor
Servidor:
 Sempre ligado
 Endereço IP permanente
 Escalabilidade com data
centers
Clientes:
 Comunicam-se com o servidor
 Podem estar conectados
intermitentemente cliente/servidor
 Podem ter endereços IP
dinâmicos
 Não se comunicam diretamente
com outros clientes

2: Camada de Aplicação 7
Arquitetura P2P
peer-peer
 Não há servidor sempre ligado
 Sistemas finais arbitrários se
comunicam diretamente
 Pares solicitam serviços de
outros pares e em troca
proveem serviços para outros
parceiros:
 Autoescalabilidade – novos
pares trazem nova capacidade
de serviço assim como novas
demandas por serviços.
 Pares estão conectados
intermitentemente e mudam
endereços IP
 Gerenciamento complexo
2: Camada de Aplicação 8
 Comunicação entre Processos
Processo: programa que Processo cliente:
executa num sistema final processo que inicia a
 processos no mesmo comunicação
sistema final se comunicam Processo servidor:
usando comunicação processo que espera
interprocessos (definida ser contatado
pelo sistema operacional)
 processos em sistemas  Nota: aplicações com
finais distintos se arquiteturas P2P
comunicam trocando possuem processos
mensagens através da rede clientes e processos
servidores
2: Camada de Aplicação 9
Sockets
 Os processos enviam/ recebem mensagens
para/dos seus sockets
 Um socket é análogo a uma porta
 Processo transmissor envia a mensagem através da porta
 O processo transmissor assume a existência da infraestrutura
de transporte no outro lado da porta que faz com que a
mensagem chegue ao socket do processo receptor

aplicação aplicação
socket Controlado pelo
processo processo desenvolvedor
da aplicação
transporte transporte
rede rede controlado
enlace
pelo SO
enlace Internet
física física

2: Camada de Aplicação 10
Endereçamento de processos
 Para que um processo  O identificador inclui tanto
receba mensagens, ele deve o endereço IP quanto os
possuir um identificador números das portas
 Cada hospedeiro possui um associadas com o processo
endereço IP único de 32 no hospedeiro .
bits  Exemplo de números de
 Pergunta: o endereço IP do portas:
hospedeiro no qual o  Servidor HTTP: 80
processo está sendo  Servidor de Correio: 25
executado é suficiente para  Para enviar uma msg HTTP
identificar o processo? para o servidor Web
 Resposta: Não, muitos [Link]
processos podem estar  Endereço IP: [Link]
executando no mesmo  Número da porta: 80
hospedeiro  Mais sobre isto
posteriormente.

2: Camada de Aplicação 11
Os protocolos da camada de
aplicação definem
Protocolos
 abertos:
Tipos de mensagens
 trocadas:
definidos em RFCs
 ex. mensagens de
 Permitem
requisiçãoae interoperação
resposta
 ex, HTTP
Sintaxe dase mensagens:
SMTP
Protocolos proprietários:
 campos presentes nas
mensagens e como são
 Ex., Skype
identificados
 Semântica das msgs:
 significado da informação
nos campos
 Regras para quando os
processos enviam e
respondem às mensagens
2: Camada de Aplicação 12
De que serviços uma aplicação necessita?
Integridade dos dados Vazão (throughput)
(sensibilidade a perdas)  algumas apls ([Link]., multimídia)
 algumas apls ([Link]., transf. de
requerem quantia mínima de
arquivos, transações web)
requerem uma transferência vazão para serem “viáveis”
100% confiável  outras apls (“apls elásticas”)
 outras ([Link]. áudio) podem conseguem usar qq quantia de
tolerar algumas perdas banda disponível

Segurança
Temporização (sensibilidade a  Criptografia, integridade dos
atrasos) dados, ...
 algumas apls ([Link]., telefonia
Internet, jogos interativos)
requerem baixo retardo para
serem “viáveis”

2: Camada de Aplicação 13
 Requisitos de aplicações de rede selecionadas

Sensib. a Sensibilidade a
Aplicação Perdas Vazão atrasos

transferência de arqs sem perdas elástica não

correio sem perdas elástica não
documentos Web sem perdas elástica não
áudio/vídeo em tolerante áudio: 5kbps-1Mbps sim, 100’s mseg
tempo real vídeo:10kbps-5Mbps
áudio/vídeo gravado tolerante Igual acima sim, alguns segs
jogos interativos tolerante Alguns kbps-10Mbps sim, 100’s mseg
mensagem instantânea sem perdas elástica sim e não

2: Camada de Aplicação 14
 Serviços providos pelos protocolos de
transporte da Internet
Serviço TCP: Serviço UDP:
 transporte confiável entre  transferência de dados não
processos remetente e confiável entre processos
receptor remetente e receptor
 controle de fluxo: remetente
 não provê: estabelecimento
não vai “afogar” receptor
da conexão, confiabilidade,
 controle de
controle de fluxo, controle
congestionamento:
estrangular remetente quando de congestionamento,
a rede estiver carregada garantias temporais ou de
 não provê: garantias banda mínima
temporais ou de banda mínima
 orientado a conexão: P: Qual é o interesse em ter um
apresentação requerida entre protocolo como o UDP?
cliente e servidor

2: Camada de Aplicação 15
 Apls Internet: seus protocolos e seus
protocolos de transporte
Protocolo da Protocolo de
Aplicação camada de apl. transporte usado

correio eletrônico SMTP [RFC 2821] TCP

acesso terminal remoto telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
transferência de arquivos FTP [RFC 959] TCP
streaming multimídia HTTP (ex. Youtube) TCP ou UDP
RTP [RFC 1889]
telefonia Internet SIP, RTP, proprietário TCP ou UDP
(ex., Skype)

2: Camada de Aplicação 16
Tornando o TCP seguro
TCP & UDP SSL está na camada de
 Sem criptografia aplicação
 Senhas em texto aberto  Aplicações usam bibliotecas
enviadas aos sockets SSL, que “falam” com o TCP
atravessam a Internet em
texto aberto API do socket SSL
SSL  Senhas em texto aberto
 Provê conexão TCP enviadas ao socket
criptografada atravessam a rede
 Integridade dos dados criptografadas
 Autenticação do ponto  Vide Capítulo 7
terminal

2: Camada de Aplicação 17
Capítulo 2: Roteiro
 2.1 Princípios de aplicações
 de
2.6rede
Aplicações P2P
 2.2 A Web e o HTTP  2.7 Programação e
desenvolvimento
 2.3 Transferência de arquivo: FTP de
aplicações com TCP
 2.4 Correio Eletrônico na Internet
 2.8 Programação de
 2.5 DNS: o serviço de diretório da Internet
sockets com UDP

2: Camada de Aplicação 18
A Web e o HTTP
Primeiro uma revisão...
 Páginas Web consistem de objetos
 um objeto pode ser um arquivo HTML, uma imagem
JPEG, um applet Java, um arquivo de áudio,…
 Páginas Web consistem de um arquivo base HTML
que inclui vários objetos referenciados
 Cada objeto é endereçável por uma URL
 Exemplo de URL:

[Link]/someDept/[Link]

nome do hospedeiro nome do caminho

2: Camada de Aplicação 19
Protocolo HTTP

HTTP: hypertext transfer protocol

 protocolo da camada de aplicação da Web pe d
ido
 modelo cliente/servidor htt
PC executando re p
s po
 (usando o sprotocolo
Explorer
cliente: browser que pede, recebe ta
ht t
p
HTTP) e “visualiza” objetos Web
 servidor: servidor Web envia (usando o protocolop HTTP)
objetos em resposta a pedidos o h tt
d di p Servidor t t
pe ah executando
ost
s p servidor
re
Web Apache

iphone executando
o navegador Safari

2: Camada de Aplicação 20
Mais sobre o protocolo HTTP
Usa serviço de transporte HTTP é “sem estado”
 servidor não mantém
TCP:
informação sobre
 cliente inicia conexão TCP
pedidos anteriores do
(cria socket) ao servidor, cliente
porta 80
 servidor aceita conexão TCP Nota
Protocolos que mantêm
do cliente “estado” são complexos!
 mensagens HTTP (mensagens  história passada (estado)
do protocolo da camada de tem que ser guardada
apl) trocadas entre browser  Caso caia servidor/cliente,
(cliente HTTP) e servidor suas visões do “estado”
Web (servidor HTTP) podem ser inconsistentes,
 encerra conexão TCP
devem ser reconciliadas

2: Camada de Aplicação 21
Conexões HTTP
HTTP persistente
não persistente
 Múltiplos
No máximo objetos
um objeto
podem
é enviado
ser enviados
numa conexão
sobre uma
TCP
única conexão
 A conexão TCP encerrada
é então entre cliente e servidor
 Baixar múltiplos objetos requer o uso de múltiplas
conexões

2: Camada de Aplicação 22
 Exemplo de HTTP não persistente
Supomos que usuário digita a URL (contém texto,
[Link]/algumDepartmento/[Link] referências a 10
imagens jpeg)
1a. Cliente http inicia conexão
TCP a servidor http (processo)
a [Link]. Porta 80
1b. servidor http no hospedeiro
[Link] espera por
é padrão para servidor http.
conexão TCP na porta 80.
“aceita” conexão, avisando ao
cliente
2. cliente http envia
mensagem de pedido de
http (contendo URL) 3. servidor http recebe mensagem
através do socket da de pedido, formula mensagem
conexão TCP. A mensagem de resposta contendo objeto
indica que o cliente deseja solicitado e envia a mensagem
receber o objeto via socket
algumDepartamento/inicial.
tempo index
2: Camada de Aplicação 23
 Exemplo de HTTP não persistente
(cont.)
4. servidor http encerra conexão
TCP .

5. cliente http recebe mensagem

de resposta contendo arquivo
html, visualiza html.
Analisando arquivo html,
encontra 10 objetos jpeg
referenciados

6. Passos 1 a 5 repetidos para

cada um dos 10 objetos jpeg
tempo

2: Camada de Aplicação 24
Modelagem do tempo de resposta
Definição de RTT (Round Trip
Time): intervalo de tempo
entre a ida e a volta de um
pequeno pacote entre um
cliente e um servidor Inicia a conexão
Tempo de resposta: TCP
 um RTT para iniciar a conexão RTT
TCP solicita
 um RTT para o pedido HTTP e arquivo
tempo para
o retorno dos primeiros bytes RTT
transmitir
da resposta HTTP o arquivo
 tempo de transmissão do arquivo
arquivo recebido

total = 2RTT+tempo de
transmissão do arquivo tempo tempo

2: Camada de Aplicação 25
HTTP persistente
Problemas com o HTTP não HTTP persistente
persistente:  o servidor deixa a conexão
 requer 2 RTTs para cada aberta após enviar a
objeto resposta
 SO aloca recursos do  mensagens HTTP seguintes
hospedeiro (overhead) para entre o mesmo
cada conexão TCP cliente/servidor são
 os browser enviadas nesta conexão
frequentemente abrem aberta
conexões TCP paralelas  o cliente envia os pedidos
para recuperar os objetos logo que encontra um
referenciados objeto referenciado
 pode ser necessário apenas
um RTT para todos os
objetos referenciados

2: Camada de Aplicação 26
 Mensagem de requisição HTTP
 Dois tipos de mensagem HTTP: requisição, resposta
 mensagem de requisição HTTP:
 ASCII (formato legível por pessoas)

linha da requisição
GET /[Link] HTTP/1.1\r\n
(comandos GET, Host: [Link]\r\n
POST, HEAD) User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
linhas de Accept-Language: en-us,en;q=0.5\r\n
cabeçalho Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Carriage return, Connection: keep-alive\r\n
line feed \r\n
indicam fim
de mensagem
2: Camada de Aplicação 27
Mensagem de requisição HTTP:
formato geral

2: Camada de Aplicação 28
Enviando conteúdo de formulário

Método POST :
 Páginas Web frequentemente contêm formulário
de entrada
 Conteúdo é enviado para o servidor no corpo da
mensagem
Método URL:
 Usa o método GET
 Conteúdo é enviado para o servidor no campo URL:

[Link]/animalsearch?key=monkeys&bananas

2: Camada de Aplicação 29
Tipos de métodos
HTTP/1.1
HTTP/1.0
 GET,
GET POST, HEAD
 PUT
POST
 Upload de arquivo contido no corpo da mensagem para o
 HEAD
 caminho
Pede paraespecificado no enviar
o servidor não campo oURL
objeto requerido junto
 DELETE
com a resposta
 Exclui arquivo especificado no campo URL

2: Camada de Aplicação 30
 Mensagem de resposta HTTP
linha de status
(protocolo,
código de status, HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 [Link] GMT\r\n
frase de status) Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 [Link]
GMT\r\n
linhas de ETag: "17dc6-a5c-bf716880"\r\n
cabeçalho Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\
r\n
\r\n
data data data data data ...
dados, [Link].,
arquivo html
solicitado
2: Camada de Aplicação 31
códigos de status da resposta HTTP
Na primeira linha da mensagem de resposta
servidor->cliente. Alguns códigos típicos:
200 OK
 sucesso, objeto pedido segue mais adiante nesta mensagem
301 Moved Permanently
 objeto pedido mudou de lugar, nova localização
especificado mais adiante nesta mensagem (Location:)
400 Bad Request
 mensagem de pedido não entendida pelo servidor
404 Not Found
 documento pedido não se encontra neste servidor
505 HTTP Version Not Supported
 versão de http do pedido não usada por este servidor
2: Camada de Aplicação 32
Experimente você com HTTP (do lado
cliente)
1. Use cliente telnet para seu servidor WWW favorito:
telnet [Link] 80 Abre conexão TCP para a porta 80
(porta padrão do servidor http) a [Link].
Qualquer coisa digitada é enviada para a
porta 80 do [Link]

2. Digite um pedido GET HTTP:

GET /~ross/ HTTP/1.1 Digitando isto (deve teclar
Host: [Link] ENTER duas vezes), está enviando
este pedido GET mínimo (porém
completo) ao servidor http

3. Examine a mensagem de resposta enviada pelo servidor HTTP !

(ou use Wireshark para ver as msgs de pedido/resposta HTTP
capturadas)
2: Camada de Aplicação 33
Cookies: manutenção do “estado” da
conexão
Exemplo:
Muitos dos principais sítios Web usam cookies
Quatro componentes:
 Suzana acessa a Internet sempre do mesmo PC
1)
 linha de cabeçalho
Ela visita cookie na mensagem
um sítiodoespecífico de resposta
de comércio HTTP
eletrônico pela
2) primeira
linha de cabeçalho
vez do cookie na mensagem de pedido HTTP
3) arquivo dooscookie
 Quando mantido
pedidos no host
iniciais HTTPdochegam
usuário eno
gerenciado pelo
sítio, o sítio
browser do usuário
cria
4) BD
• de retaguarda no sítio Web
uma ID única
• uma entrada para a ID no BD de retaguarda

2: Camada de Aplicação 34
 Cookies: manutenção do “estado” (cont.)
cliente servidor
arquivo de msg usual pedido http servidor de ntrad
e
Cookies a
resposta usual http + cria a ID 1678 retag no B
ua D
ebay: 8734
Set-cookie: 1678 para o usuário rd
a

arquivo de
msg usual pedido http
Cookies
amazon: 1678 cookie: 1678 ação o
s
ebay: 8734 específica aces
resposta usual http do cookie

o
uma semana depois:

s
es
ac
msg usual pedido http
arquivo de
ação
Cookies cookie: 1678
amazon: 1678 específica
ebay: 8734 resposta usual http do cookie

2: Camada de Aplicação 35
Cookies (continuação)
nota
O que os cookies podem obter: Cookies e privacidade:
 autorização  cookies permitem que os
sítios aprendam muito
 carrinhos de compra
sobre você
 recomendações  você pode fornecer nome e
 estado da sessão do usuário e-mail para os sítios
(Webmail)
Como manter o “estado”:
 Pontos finais do protocolo: mantêm o
estado no transmissor/receptor para
múltiplas transações
 Cookies: mensagens http transportam
o estado
2: Camada de Aplicação 36
 Cache Web (servidor proxy)
Meta: atender pedido do cliente sem envolver servidor de origem
 usuário configura
Servidor
browser: acessos Web via de origem
proxy cliente
 cliente envia todos Servidor
pe d
proxy ttp
pedidos HTTP ao proxy r es
ido
htt ido
h
tp
pos p e d h t
 se objeto estiver no ta p
st a
cache do proxy, este o ht t po
p res
devolve imediatamente ttp
na resposta HTTP h
dido t tp
p e h
senão, solicita objeto do st a

p o
servidor de origem, res
depois devolve resposta
HTTP ao cliente cliente
Servidor
de origem

2: Camada de Aplicação 37
Mais sobre Caches Web
Para
 Cache
que fazer
atua tanto
cachecomo
Web? cliente quanto como servidor
 Redução
Tipicamente
do tempo
o cache
deéresposta
instaladopara
por os
umpedidos
ISP (universidade,
do cliente
 empresa, ISP
Redução do residencial)
tráfego no canal de acesso de uma instituição
 A Internet cheia de caches permitem que provedores de
conteúdo “pobres” efetivamente forneçam conteúdo (mas o
compartilhamento de arquivos P2P também!)

2: Camada de Aplicação 38
Exemplo de cache (1) Servidores
de origem

Hipóteses
 Tamanho médio de um objeto =
Internet
100.000 bits pública
 Taxa média de solicitações dos
browsers de uma instituição
para os servidores originais =
15/seg
 Atraso do roteador institucional enlace de acesso
1,5 Mbps
para qualquer servidor origem e
de volta ao roteador = 2seg rede da
Conseqüências instituição
LAN 10 Mbps
 Utilização da LAN = 15%
 Utilização do canal de acesso =
100% problema!
 Atraso total = atraso da
Internet + atraso de acesso +
atraso na LAN = 2 seg + minutos
+ microssegundos
2: Camada de Aplicação 39
Exemplo de cache (2) Servidores
de origem

Solução em potencial
 Aumento da largura de banda Internet
do canal de acesso para, por pública
exemplo, 10 Mbps
Consequências
 Utilização da LAN = 15%
 Utilização do canal de acesso enlace de acesso
10 Mbps
= 15%
 Atraso total = atraso da rede da
instituição
Internet + atraso de acesso LAN 10 Mbps
+ atraso na LAN = 2 seg +
msegs + msegs
 Frequentemente este é uma
ampliação cara

2: Camada de Aplicação 40
Exemplo de cache (3) Servidores
de origem

Instale uma cache

 Assuma que a taxa de acerto
Internet
seja de 0,4 pública
Consequências
 40% dos pedidos serão
atendidos quase que
imediatamente enlace de acesso
 60% dos pedidos serão servidos
1,5 Mbps
pelos servidores de origem
 Utilização do canal de acesso é rede da
reduzido para 60%, resultando instituição
LAN 10 Mbps
em atrasos desprezíveis (ex. 10
mseg)
 Atraso total = atraso da
Internet + atraso de acesso + cache
atraso na LAN = 0,6*2 seg + institucional
0,6*0,01 segs + msegs < 1,3 segs

2: Camada de Aplicação 41
 GET condicional
 Meta: não enviar objeto se cache servidor
cliente já tem (no cache)
versão atual msg de pedido http
 Sem atraso para transmissão
If-modified-since: objeto
do objeto
<date> não
 Diminui a utilização do enlace resposta http modificado
 cache: especifica data da HTTP/1.0
304 Not Modified
cópia no cache no pedido
HTTP
If-modified-since:
<date> msg de pedido http
If-modified-since:
 servidor: resposta não <date>
objeto
contém objeto se cópia no modificado
resposta http
cache for atual: HTTP/1.1 200 OK
HTTP/1.0 304 Not …
Modified <data>
2: Camada de Aplicação 42
HTTP/2
 Aprovado pela IESG (Internet Engineering Steering Group)
em Fevereiro de 2015
 [Link]
 Objetivos:
 Mecanismos de negociação para permitir a clientes e servidores
escolher o HTTP 1.1, 2, ou outros protocolos
 Manutenção de compatibilidade de alto nível como HTTP 1.1
 Diminuir a latência para melhorar a velocidade de carga das
páginas através de:
• Compressão de dados dos cabeçalhos HTTP
• Tecnologias de envio (push) pelos servidores
• Consertar o problema de bloqueio do cabeça da fila (HOL) do HTTP
1.1
• Carga de elementos da página em paralelo através de uma única
conexão TCP
 Dar suporte aos casos de uso comuns atuais do HTTP
2: Camada de Aplicação 43
HTTP/2: Diferenças do HTTP 1.1
 Mantém a maior parte da sintaxe de alto nível do HTTP 1.1
tais como: métodos, códigos de status, campos de cabeçalhos
e URIs
 O que é modificado é como os dados são estruturados e
transportados entre o cliente e o servidor de forma binária e
não textual.
 HTTP/2 permite ao servidor enviar (push) conteúdo, i.e.,
enviar mais dados que os solicitados pelo cliente.
 Multiplexa os pedidos e as respostas para evitar o problema
de bloqueio pelo cabeça da fila do HTTP 1.1.
 Realiza ainda um controle de fluxo e priorização dos pedidos.

2: Camada de Aplicação 44
HTTP/2: Transporte Binário

2: Camada de Aplicação 45
HTTP/2: Quadros

 Tipos:
 HEADERS,DATA, PRIORITY, RST_STREAM,
SETTINGS, PUSH_PROMISE, PING,
GOAWAY, WINDOW_UPDATE,
CONTINUATION

2: Camada de Aplicação 46
HTTP/2: Multiplexação

2: Camada de Aplicação 47
Capítulo 2: Roteiro
 2.1 Princípios de aplicações
 de
2.6rede
Aplicações P2P
 2.2 A Web e o HTTP  2.7 Programação e
desenvolvimento
 2.3 Transferência de arquivo: FTP de
aplicações com TCP
 2.4 Correio Eletrônico na Internet
 2.8 Programação de
 2.5 DNS: o serviço de diretório da Internet
sockets com UDP

2: Camada de Aplicação 48
FTP: o protocolo de transferência
de arquivos
transferência
Interface cliente do arquivo servidor
do usuário FTP
FTP
FTP
usuário
na sistema de sistema de
estação arquivos arquivos
local remoto

 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

2: Camada de Aplicação 49
FTP: conexões separadas p/ controle, dados
 cliente FTP contata servidor
FTP na porta 21, conexão de controle
especificando o TCP como TCP, porta 21
protocolo de transporte
 O cliente obtém autorização conexão de dados
através da conexão de cliente TCP, porta 20 servidor
controle FTP FTP
 O cliente consulta o
diretório remoto enviando  O servidor abre uma segunda
comandos através da conexão TCP para transferir
conexão de controle outro arquivo
 Quando o servidor recebe  Conexão de controle: “fora da
um comando para a faixa”
transferência de um arquivo,  Servidor FTP mantém o
ele abre uma conexão de
dados TCP para o cliente “estado”: diretório atual,
 Após a transmissão de um autenticação anterior
arquivo o servidor fecha a
conexão 2: Camada de Aplicação 50
 FTP: comandos, respostas

Comandos típicos: Códigos de retorno típicos

 enviados em texto ASCII  código e frase de status (como
pelo canal de controle para http)
  331 Username OK, password
USER nome
 required
PASS senha  125 data connection
 LIST devolve lista de already open; transfer
arquivos no diretório atual starting
 RETR arquivo recupera  425 Can’t open data
(lê) arquivo remoto connection

 STOR arquivo armazena 452 Error writing file
(escreve) arquivo no
hospedeiro remoto

2: Camada de Aplicação 51
Capítulo 2: Roteiro
 2.1 Princípios de aplicações
 de
2.6rede
Aplicações P2P
 2.2 A Web e o HTTP  2.7 Programação e
desenvolvimento
 2.3 Transferência de arquivo: FTP de
aplicações com TCP
 2.4 Correio Eletrônico na Internet
 2.8 Programação de
 2.5 DNS: o serviço de diretório da Internet
sockets com UDP

2: Camada de Aplicação 52
 fila de
Correio Eletrônico mensagens
de saída
caixa de
agente correio do usuário
Três grandes componentes: de
usuário
 agentes de usuário (UA) agente
servidor
 servidores de correio de correio de
usuário
 Simple Mail Transfer Protocol:
SMTP SMTP
servidor
de correio agente
Agente de Usuário SMTP de
usuário
 a.k.a. “leitor de correio”
 compor, editar, ler mensagens SMTP
agente
de correio de
servidor
 [Link]., Outlook, Thunderbird, de correio usuário
cliente de mail do iPhone
 mensagens de saída e chegando agente
são armazenadas no servidor de
usuário
agente
de
usuário
2: Camada de Aplicação 53
Correio Eletrônico: servidores de correio
agente
Servidores de correio de
usuário
 caixa de correio contém agente
servidor
mensagens de chegada de correio de
(ainda não lidas) p/ usuário usuário
 fila de mensagens contém SMTP
servidor
mensagens de saída (a serem de correio
enviadas) SMTP
 protocolo SMTP entre
servidores de correio para SMTP
transferir mensagens de agente
servidor de
correio usuário
de correio
 cliente: servidor de
correio que envia
agente
 “servidor”: servidor de de
correio que recebe agente
usuário
de
usuário
2: Camada de Aplicação 54
Correio Eletrônico:
SMTP [RFC 2821]
 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ência
 handshaking (saudação)
 transferência das mensagens
 encerramento
 interação comando/resposta (como o HTTP e o FTP)
 comandos: texto ASCII
 resposta: código e frase de status

 mensagens precisam ser em ASCII de 7-bits

2: Camada de Aplicação 55
Gerência da Porta 25

[Link]

2: Camada de Aplicação 56
Cenário: Alice envia uma msg para Bob
1) Alice usa o UA para compor 4) O cliente SMTP envia a
uma mensagem “para” mensagem de Alice através
bob@[Link] da conexão TCP
2) O UA de Alice envia a 5) O servidor de correio de
mensagem para o seu
Bob coloca a mensagem na
servidor de correio; a
mensagem é colocada na caixa de entrada de Bob
fila de mensagens 6) Bob chama o seu UA para
3) O lado cliente do SMTP ler a mensagem
abre uma conexão TCP com
o servidor de correio de
Bob

2: Camada de Aplicação 57
Interação SMTP típica
S: 220 [Link]
C: HELO [Link]
S: 250 Hello [Link], pleased to meet you
C: MAIL FROM: <alice@[Link]>
S: 250 alice@[Link] ... Sender ok
C: RCPT TO: <bob@[Link]>
S: 250 bob@[Link] ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 [Link] closing connection

2: Camada de Aplicação 58
Experimente uma interação SMTP:

 telnet nomedoservidor 25
 veja resposta 220 do servidor
 entre comandos HELO, MAIL FROM, RCPT TO,
DATA, QUIT

estes comandos permitem que você envie correio sem

usar um cliente (leitor de correio)

2: Camada de Aplicação 59
 SMTP: últimas palavras
 Comparação com
SMTP usa conexões HTTP
persistentes
 HTTP: pull (recupera)
 SMTP requer que a mensagem
 SMTP: push (envia)
(cabeçalho e corpo) sejam em
ASCII
 ambosdetêm
7-bits
interação comando/resposta, códigos de status
 servidor SMTP usa
em ASCII
[Link] para reconhecer o
 HTTP:
final cada objeto é encapsulado em sua própria mensagem
da mensagem
de resposta
 SMTP: múltiplos objetos de mensagem enviados numa
mensagem de múltiplas partes

2: Camada de Aplicação 60
Formato de uma mensagem

SMTP: protocolo para trocar msgs de correio

RFC 822: padrão para formato de mensagemcabeçalho
de texto:
linha em
 linhas de cabeçalho, [Link].,
branco
 To:
 From:
Subject:
corpo


diferentes dos comandos de smtp FROM, RCPT TO

 corpo
 a “mensagem”, somente de caracteres ASCII

2: Camada de Aplicação 61
 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: ana@[Link]
versão MIME To: bernardo@[Link]
Subject: Imagem de uma bela torta
método usado MIME-Version: 1.0
p/ codificar dados Content-Transfer-Encoding: base64
Content-Type: image/jpeg
tipo, subtipo de
dados multimídia, base64 encoded data .....
declaração parâmetros .........................
......base64 encoded data
Dados codificados

2: Camada de Aplicação 62
Tipos MIME
Content-Type: tipo/subtipo; parâmetros

Text
Audio
 subtipos exemplos
exemplos::plain,
basic (8-bit
html codificado mu-law),
 32kadpcm (codificação 32 kbps)
charset=“iso-8859-1”, ascii
Application
Image
 outros dados que precisam ser processados por um leitor
 para serem
subtipos “visualizados”
exemplos : jpeg, gif
 subtipos exemplos : msword, octet-stream

Video
 subtipos exemplos : mpeg, quicktime

2: Camada de Aplicação 63
Tipo Multipart
From: alice@[Link]
To: bob@[Link]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789

--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain

Dear Bob,
Please find a picture of a crepe.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg

base64 encoded data .....

.........................
......base64 encoded data
--98766789--

2: Camada de Aplicação 64
Protocolos de acesso ao correio
agente SMTP SMTP POP3 ou agente
de de
usuário IMAP usuário

servidor de correio servidor de correio

do remetente do receptor

 SMTP: entrega/armazenamento no servidor do receptor

 protocolo de acesso 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: gmail, Hotmail , Yahoo! Mail, etc.

2: Camada de Aplicação 65
Protocolo POP3 S: +OK POP3 server ready
C: user ana
fase de autorização S: +OK
 comandos do cliente: C: pass faminta
S: +OK user successfully logged on
 user: declara nome
 pass: senha C: list
 servidor responde S: 1 498
 +OK
S: 2 912
S: .
 -ERR
C: retr 1
fase de transação, cliente: S: <message 1 contents>
 list: lista números das S: .
msgs C: dele 1
 retr: recupera msg por C: retr 2
S: <message 1 contents>
número S: .
 dele: apaga msg
C: dele 2
 quit C: quit
S: +OK POP3 server signing off
2: Camada de Aplicação 66
POP3 (mais) e IMAP
Mais sobre o POP3 IMAP
 O exemplo anterior  Mantém todas as
usa o modo “download mensagens num único
e delete”. lugar: o servidor
 Bob não pode reler as  Permite ao usuário
mensagens se mudar organizar as mensagens
de cliente em pastas
 “Download-e-  O IMAP mantém o estado
mantenha”: copia as do usuário entre sessões:
mensagens em clientes  nomes das pastas e
diferentes mapeamentos entre as IDs
 POP3 não mantém das mensagens e o nome da
pasta
estado entre conexões
2: Camada de Aplicação 67
Capítulo 2: Roteiro
 2.1 Princípios de aplicações
 de
2.6rede
Aplicações P2P
 2.2 A Web e o HTTP  2.7 Programação e
desenvolvimento
 2.3 Transferência de arquivo: FTP de
aplicações com TCP
 2.4 Correio Eletrônico na Internet
 2.8 Programação de
 2.5 DNS: o serviço de diretório da Internet
sockets com UDP

2: Camada de Aplicação 68
DNS: Domain Name System

Pessoas: muitos identificadores:

Domain Name System:
  base de dados distribuída
CPF, nome, no. da Identidade
hospedeiros, roteadores Internet implementada
: na hierarquia de
muitos servidores de nomes
 endereço IP (32 bit) - usado p/ endereçar datagramas
 protocolo de camada de
 “nome”, ex., [Link] - usado por gente
aplicação permite que
P: como mapear entre nome e endereço IP?
hospedeiros, roteadores,
servidores de nomes se
comuniquem para resolver nomes
(tradução endereço/nome)
 nota: função imprescindível
da Internet implementada
como protocolo de camada de
aplicação
 complexidade na borda da
rede
2: Camada de Aplicação 69
 DNS (cont.)
Serviços DNS Por que não centralizar o
 Tradução de nome de DNS?
 ponto único de falha
hospedeiro para IP
 volume de tráfego
 Apelidos para
 base de dados
hospedeiros (aliasing) centralizada e distante
 Nomes canônicos e apelidos  manutenção (da BD)
 Apelidos para
servidores de e-mail Não é escalável!
 Distribuição de carga
 Servidores Web replicados:
conjunto de endereços IP
para um mesmo nome

2: Camada de Aplicação 70
 Base de Dados Hierárquica e
Distribuída
Root DNS Servers

com DNS servers org DNS servers edu DNS servers

[Link] [Link] [Link] [Link] [Link]

DNS serversDNS servers DNS servers DNS serversDNS servers

Cliente quer IP para [Link]; 1a aprox:

 Cliente consulta um servidor raiz para encontrar um servidor
DNS .com
 Cliente consulta servidor DNS .com para obter o servidor DNS
para o domínio [Link]
 Cliente consulta servidor DNS do domínio [Link] para
obter endereço IP de [Link]

2: Camada de Aplicação 71
 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

a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD
k RIPE London (also Amsterdam,
g US DoD Vienna, VA
Frankfurt)
h ARL Aberdeen, MD
j Verisign, ( 11 locations) i Autonomica, Stockholm
(plus 3 other locations)
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA (and 17 other locations)
13 servidores de
nome raiz em todo o
b USC-ISI Marina del Rey, CA mundo
l ICANN Los Angeles, CA

2: Camada de Aplicação 72
DNS: Servidores raiz
Hostname IP Addresses Manager
[Link] [Link], [Link] VeriSign, Inc.

[Link] [Link], [Link] University of Southern California (ISI)

[Link] [Link], [Link] Cogent Communications

[Link] [Link], [Link] University of Maryland

[Link] [Link], [Link] NASA (Ames Research Center)

[Link] [Link], [Link] Internet Systems Consortium, Inc.

[Link] [Link] US Department of Defense (NIC)

[Link] [Link], [Link] US Army (Research Lab)

[Link] [Link], [Link] Netnod

[Link] [Link], [Link] VeriSign, Inc.

[Link] [Link], [Link] RIPE NCC

[Link] [Link], [Link] ICANN

[Link] [Link], [Link] WIDE Project

2: Camada de Aplicação 73
Servidores TLD e Oficiais
 Servidores de nomes de Domínio de Alto Nível (TLD):
 servidores DNS responsáveis por domínios com, org, net, edu,
etc, e todos os domínios de países como br, uk, fr, ca, jp.
 Domínios genéricos: book, globo, rio

 Lista completa em: [Link]

 [Link] (Registro .br) para domínio .br ([Link]

 Servidores de nomes com autoridade:
 servidores DNS das organizações, provendo mapeamentos
oficiais entre nomes de hospedeiros e endereços IP para os
servidores da organização (e.x., Web e correio).
 Podem ser mantidos pelas organizações ou pelo provedor de
acesso

2: Camada de Aplicação 74
13/09/2016

2: Camada de Aplicação 75
Servidor DNS Local
 Não pertence necessariamente à hierarquia
 Cada ISP (ISP residencial, companhia,
universidade) possui um.
 Também chamada do “servidor de nomes default”
 Quanto um hospedeiro faz uma consulta DNS, a
mesma é enviada para o seu servidor DNS local
 Possui uma cache local com pares de tradução
nome/endereço recentes (mas podem estar
desatualizados!)
 Atua como um intermediário, enviando consultas para a
hierarquia.

2: Camada de Aplicação 76
Exemplo de resolução servidor raiz
de nome pelo DNS
 Hospedeiro em 2
3
[Link] quer servidor TLD
4
endereço IP para
[Link] 5

consulta interativa: servidor local

[Link]
 servidor consultado 7 6
responde com o nome 1 8
de um servidor de servidor com autoridade
contato [Link]
 “Não conheço este solicitante
nome, mas pergunte [Link]
para esse servidor” [Link]

2: Camada de Aplicação 77
Exemplo de resolução
de nome pelo DNS servidor DNS raiz

consulta recursiva: 2 3
 transfere a 6
7
responsabilidade de
resolução do nome servidor TLD
para o servidor de
nomes contatado servidor DNS local
 carga pesada? [Link] 5 4
1 8

servidor DNS com autoridade

[Link]
solicitante
[Link]

[Link]

2: Camada de Aplicação 78
DNS: uso de cache, atualização de dados
 uma vez que um servidor qualquer aprende um mapeamento,
ele o coloca numa cache local
 entradas na cache são sujeitas a temporização
(desaparecem) depois de um certo tempo (TTL)
 Entradas na cache podem estar desatualizadas (tradução
nome/endereço do tipo melhor esforço!)
 Se o endereço IP de um nome de host for alterado, pode não
ser conhecido em toda a Internet até que todos os TTLs
expirem

2: Camada de Aplicação 79
Registros DNS
DNS: BD distribuído contendo registros de recursos (RR)

formato RR: (nome, valor, tipo, ttl)

 Tipo=A  Tipo=CNAME
 nome é nome de hospedeiro  nome é nome alternativo
 valor é o seu endereço IPv4 (alias) para algum nome
 Tipo=AAAA para IPv6 “canônico” (verdadeiro)
 valor é o nome canônico

 Tipo=NS
 nome é domínio ([Link].  Tipo=MX
[Link])
 nome é domínio
 valor é endereço IP de
servidor oficial de nomes  valor é nome do servidor de
para este domínio correio para este domínio
2: Camada de Aplicação 80
DNS: protocolo e mensagens

protocolo 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
 flags:
 pedido ou resposta
 recursão desejada
 recursão permitida
 resposta é oficial

2: Camada de Aplicação 81
DNS: protocolo e mensagens

2: Camada de Aplicação 82
Inserindo registros no DNS
 Exemplo: acabou de criar a empresa “Network
Utopia”
 Registra o nome [Link] em uma entidade
registradora (e.x., [Link])
 Tem de prover para a registradora os nomes e endereços IP
dos servidores DNS oficiais (primário e secundário)
 Registradora insere dois RRs no servidor TLD .br:

([Link], [Link], NS)

([Link], [Link], A)

 Põe no servidor oficial um registro do tipo A para

[Link] e um registro do tipo MX para
[Link]

2: Camada de Aplicação 83
Ataques ao DNS
Ataques DDoS Ataques de redirecionamento
 Bombardeia os servidores  Pessoa no meio
raiz com tráfego  Intercepta as consultas
 Até o momento não  Envenenamento do DNS
tiveram sucesso  Envia respostas falsas
 Filtragem do tráfego para o servidor DNS que
 Servidores DNS locais as coloca em cache
cacheiam os IPs dos Exploração do DNS para
servidores TLD, DDoS
permitindo que os
 Envia consultas com
servidores raízes não
sejam consultados endereço origem
 Bombardeio aos servidores falsificado: IP alvo
TLD  Requer amplificação
 Potencialmente mais
perigoso
2: Camada de Aplicação 84
Capítulo 2: Roteiro
 2.1 Princípios de aplicações
 de
2.6rede
Aplicações P2P
 2.2 A Web e o HTTP  2.7 Programação e
desenvolvimento
 2.3 Transferência de arquivo: FTP de
aplicações com TCP
 2.4 Correio Eletrônico na Internet
 2.8 Programação de
 2.5 DNS: o serviço de diretório da Internet
sockets com UDP

2: Camada de Aplicação 85
Arquitetura P2P pura
 sem servidor sempre ligado
 sistemas finais arbitrários se
comunicam diretamente
 pares estão conectados de par-par
forma intermitente e mudam
seus endereços IP

 Exemplos:
 Distribuição de arquivos
(BitTorrent)
 Streaming (KanKan)
 VoIP (Skype)

2: Camada de Aplicação 86
 Distribuição de Arquivo: C/S x P2P
Pergunta: Quanto tempo leva para distribuir um arquivo
de um servidor para N pares?
 Capacide de upload/download de um par é um recurso limitado

Servidor
us: banda de upload
u2 do servidor
u1 d1
us d2 ui: banda de upload
Arquivo, do par i
tamanho F di: banda de
dN
Rede (com download do par i
uN banda abundante)

2: Camada de Aplicação 87
 Tempo de distribuição do arquivo: C/S
 transmissão do servidor: deve enviar
F
sequencialmente N cópias do us
arquivo: di
 Tempo para enviar uma cópia = F/us
rede
 Tempo para enviar N cópias = NF/us ui
 cliente: cada cliente deve fazer o
download de uma cópia do arquivo
 dmin = taxa mínima de download
 Tempo de download para usuário com
menor taxa: F/dmin

Tempo para distribuir F

para N clientes usando
abordagem cliente/servidor Dcs ≥ max { NF/u , F/d }
s min

cresce linearmente com N

2: Camada de Aplicação 88
Tempo de distribuição do arquivo: P2P
 transmissão do servidor: deve
enviar pelo menos uma cópia: F
 tempo para enviar uma cópia: F /us us
 cliente: cada cliente deve di
baixar uma cópia do arquivo network
ui
 Tempo de download para usuário
com menor taxa: F/dmin
 clientes: no total devem baixar NF bits

Taxa máxima de upload : us + Su i

tempo para distribuir

F para N clientes
DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}
usando abordagem P2P

cresce linearmente com N …

… assim como este, cada par traz capacidade de serviço
2: Camada de Aplicação 89
 Cliente-servidor x P2P: Exemplo
Taxa de upload do cliente= u, F/u = 1 hora, us = 10u, dmin ≥ us

3.5
P2P
Minimum Distribution Time

3
Client-Server
2.5

1.5

0.5

0
0 5 10 15 20 25 30 35

N
2: Camada de Aplicação 90
 Distribuição de arquivo P2P:
BitTorrent
 arquivos divididos em blocos de 256kb
 Pares numa torrente enviam/recebem blocos do arquivo

tracker: registra pares

participantes de uma torrente: grupo de
pares trocando
torrente blocos de um arquivo

Alice chega…
… obtém lista de
parceiros do tracker
… e começa a trocar blocos
de arquivos com os
parceiros na torrente
2: Camada de Aplicação 91
 Distribuição de arquivo P2P:
BitTorrent
 par que se une à torrente:
 não tem nenhum bloco, mas irá
acumulá-los com o tempo
 registra com o tracker para
obter lista dos pares, conecta a
um subconjunto de pares
(“vizinhos”)
 enquanto faz o download, par carrega blocos para outros pares
 par pode mudar os parceiros com os quais troca os blocos
 pares podem entrar e sair
 quando o par obtiver todo o arquivo, ele pode (egoisticamente)
sair ou permanecer (altruisticamente) na torrente

2: Camada de Aplicação 92
BitTorrent: pedindo, enviando blocos de
arquivos
Enviando blocos: toma lá, dá cá!
obtendo blocos:
 Alice envia blocos para os
 num determinado instante,
quatro vizinhos que estejam
pares distintos possuem
lhe enviando blocos na taxa
diferentes subconjuntos de
blocos do arquivo
mais elevada
 outros pares foram sufocados por
 periodicamente, um par Alice
(Alice) pede a cada vizinho  Reavalia os 4 mais a cada 10 segs
a lista de blocos que eles  a cada 30 segs: seleciona
possuem aleatoriamente outro par,
 Alice envia pedidos para os começa a enviar blocos
pedaços que ainda não tem  “optimistically unchoked”
 Primeiro os mais raros  o par recém escolhido pode se
unir aos 4 mais

2: Camada de Aplicação 93
BitTorrent: toma lá, dá cá!
(1) Alice “optimistically unchokes” Bob
(2) Alice se torna um dos quatro melhores provedores de Bob;
Bob age da mesma forma
(3) Bob se torna um dos quatro melhores provedores de Alice

Com uma taxa de upload mais

alta, pode encontrar melhores
parceiros de troca e obter o
arquivo mais rapidamente!
2: Camada de Aplicação 94
Distributed Hash Table (DHT)
 DHT: uma base de dados P2P distribuída
 base de dados possui duplas (chave, valor);
exemplos:
 chave: cpf; valor: nome da pessoa
 chave: título do filme; valor: endereço IP
 Distribui as duplas (chave, valor) entre os milhões
de pares
 um par consulta a DHT com a chave
 a DHT retorna valores que casam com a chave
 pares podem também inserir duplas (chave, valor)

2: Camada de Aplicação 95
P: como atribuir chaves aos
pares?
 questão central:
 atribuição duplas (chave, valor) aos pares.

 ideia básica:
 converter cada chave para um inteiro
 atribuir inteiros para cada par
 colocar a dupla (chave, valor) no par que esteja
mais próximo da chave

2: Camada de Aplicação 96
Identificadores DHT
 designa um identificador inteiro a cada par
na faixa [0, 2n-1] de algum n fixo.
 cada identificador é representado por n bits.

 requer que cada chave seja um inteiro na

mesma faixa
 para encontrar a chave inteira, aplica a
função de hash à chave original.
 ex.,chave = hash(“Led Zeppelin IV”)
 é por isto que é chamada de tabela de “hash”
distribuída.
2: Camada de Aplicação 97
Alocação de chaves aos pares
 regra: atribui a chave ao par que tiver a ID
mais próxima.
 convenção de leitura: o mais próximo é o
sucessor imediato da chave.
 Ex., n=4; pares: 1,3,4,5,8,10,12,14
 chave = 13, então par sucessor = 14
 chave = 15, então par sucessor = 1

2: Camada de Aplicação 98
DHT circular (I)
1

3
15

4
12
5
10
8
 cada par rastreia apenas o seu sucessor e
antecessor imediatos.
 “rede sobreposta (overlay)”

2: Camada de Aplicação 99
 DHT circular (II)
Em média O(N)
mensagens para 0001 Quem é
resolver a responsável pela
consulta, chave 1110 ?
quando houver Eu sou
0011
N pares
1111
1110

1110
0100
1110

1100
1110
1110 0101
Defina mais próximo 1110

como o sucessor mais 1010

próximo 1000
2: Camada de Aplicação 100
DHT circular com atalhos
1 Quem é responsável
pela chave 1110?
3
15

4
12
5
10
8
 cada par rastreia os endereços IP do antecessor, sucessor e
atalhos.
 reduz de 6 para 2 mensagens.
 Permite projetar atalhos de modo que para O(log N)
vizinhos, O(log N) mensagens na consulta
2: Camada de Aplicação 101
Peer churn tratando peer churn:
1  pares podem chegar e sair
(churn)
3  cada para conhece o endereço
15 dos seus dois sucessores
 cada par periodicamente envia
4 um ping aos seus dois
12 sucessores para verificar se
5 estão vivos
 se o sucessor imediato sair,
10 escolha o próximo sucessor
8
exemplo: par 5 sai abruptamente como o sucessor imediato.
par 4 detecta a saída do par 5; torna 8 o seu sucessor imediato;
pergunta a 8 quem é o seu sucessor imediato; torna o sucessor
imediato de 8 como o seu segundo sucessor.
o que fazer caso o par 13 resolva entrar?

2: Camada de Aplicação 102

Estudo de caso P2P: Skype
Skype clients (SC)
 inerentemente P2P:
comunicação entre pares
de usuários.
 protocolo proprietário da Skype
login server Supernode
camada de aplicação
(inferido através de (SN)
engenharia reversa)
 overlay hierárquico com
SNs
 Índice mapeia nomes dos
usuários a endereços IP;
distribuído através dos
SNs

2: Camada de Aplicação 103

Pares como intermediários
(relays)
 Problema quando tanto
Alice como Bob estão
atrás de “NATs”.
 O NAT impede que um
par externo inicie uma
chamada com um par
interno
 Solução:
 Intermediário é escolhido,
usando os SNs de Alice e de
Bob.
 Cada par inicia sessão com o
intermediário
 Pares podem se comunicar
através de NATs através do
intermediário

2: Camada de Aplicação 104

Capítulo 2: Roteiro
 2.1 Princípios de aplicações
 de
2.6rede
Aplicações P2P
 2.2 A Web e o HTTP  2.7 Programação e
desenvolvimento
 2.3 Transferência de arquivo: FTP de
aplicações com TCP
 2.4 Correio Eletrônico na Internet
 2.8 Programação de
 2.5 DNS: o serviço de diretório da Internet
sockets com UDP

2: Camada de Aplicação 105

Programação com sockets
Meta: aprender a construir aplicações cliente/servidor
que se comunicam usando sockets
socket
API Sockets uma interface (uma
 apareceu no BSD4.1 UNIX “porta”), local ao
em 1981 hospedeiro, criada por e
 são explicitamente criados, pertencente à aplicação, e
usados e liberados por apls controlado pelo SO,
 paradigma cliente/servidor através da qual um
 dois tipos de serviço de processo de aplicação
transporte via API Sockets pode tanto enviar como
 datagrama não confiável
receber mensagens
para/de outro processo
 fluxo de bytes, confiável
de aplicação
(remoto ou local)

2: Camada de Aplicação 106

 Programação com sockets usando TCP
Socket: 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

controlado pelo
controlado pelo
desenvolvedor de processo processo desenvolvedor de
aplicação
aplicação
socket socket
TCP com TCP com controlado
controlado
pelo sistema buffers, buffers, pelo sistema
internet operacional
operacional
variáveis variáveis

estação ou estação ou
servidor servidor

2: Camada de Aplicação 107

 Programação com sockets usando TCP
Cliente deve contactar servidor  Quando contatado pelo cliente, o
 processo servidor deve antes TCP do servidor cria socket novo
estar em execução para que o processo servidor possa
 servidor deve antes ter se comunicar com o cliente
criado socket (porta) que  permite que o servidor
aguarda contato do cliente converse com múltiplos clientes
 Endereço IP e porta origem
Cliente contacta servidor para:
 criar socket TCP local ao são usados para distinguir os
clientes (mais no cap. 3)
cliente
 especificar endereço IP,
número de porta do processo
servidor ponto de vista da aplicação
 Quando cliente cria socket: TCP provê transferência
TCP cliente cria conexão com confiável, ordenada de bytes
TCP do servidor (“tubo”) entre cliente e servidor

2: Camada de Aplicação 108

Comunicação entre sockets

2: Camada de Aplicação 109

Jargão para Fluxo (Stream)
 Um fluxo (stream) é uma seqüência de caracteres que fluem
de ou para um processo.
 Um fluxo de entrada é conectado a alguma fonte de entrada
para o processo, por exemplo, teclado ou socket.
 Um fluxo de saída é conectado a uma fonte de saída, por
exemplo, um monitor ou um socket.

2: Camada de Aplicação 110

 Programação com sockets usando TCP
keyboard monitor

Exemplo de apl. cliente-

servidor:

inFromUser
1. cliente lê linha da entrada input
stream
padrão (fluxo doUsuário), Processo
envia para servidor via Process Fluxo de entrada:
cliente
socket (fluxo Seqüência de bytes
paraServidor) Fluxo de saída: recebidos pelo
Seqüência de bytes processo
2. servidor lê linha do socket transmitidos pelo
3. servidor converte linha para processo
letras maiúsculas, devolve

inFromServer
outToServer
output input

para o cliente
stream stream

4. cliente lê linha modificada do

socket (fluxo doServidor),
Socket
clientSocket

imprime-a cliente TCP socket

TCP

to network from network

2: Camada de Aplicação 111

Interações cliente/servidor usando o TCP
Servidor (executa em nomeHosp) Cliente
cria socket,
porta=x, para
receber pedido:
socketRecepção =
ServerSocket ()

aguarda chegada de
TCP cria socket,
abre conexão a nomeHosp, porta=x
pedido de conexão setup da conexão socketCliente =
socketConexão =
Socket()
socketRecepçã[Link]()

Envia pedido usando

lê pedido de socketCliente
socketConexão

escreve resposta
para socketConexão lê resposta de
socketCliente
fecha
socketConexão fecha
socketCliente
2: Camada de Aplicação 112
 Exemplo: cliente Java (TCP)
import [Link].*;
import [Link].*;
class ClienteTCP {

public static void main(String argv[]) throws Exception

{
String frase;
String fraseModificada;
Cria
BufferedReader doUsuario =
fluxo de entrada
new BufferedReader(new InputStreamReader([Link]));
Cria
socket de cliente, Socket socketCliente = new Socket(”nomeHosp", 6789);
conexão ao servidor
Cria DataOutputStream paraServidor =
fluxo de saída new DataOutputStream([Link]());
ligado ao socket
2: Camada de Aplicação 113
Exemplo: cliente Java (TCP), cont.

Cria BufferedReader doServidor =

fluxo de entrada new BufferedReader(new
InputStreamReader([Link]()));
ligado ao socket
frase = [Link]();
Envia linha
[Link](frase + '\n');
ao servidor
Lê linha fraseModificada = [Link]();
do servidor [Link](”Do Servidor: " + fraseModificada);

[Link]();

}
}
2: Camada de Aplicação 114
 Exemplo: servidor Java (TCP)
import [Link].*;
import [Link].*;

class servidorTCP {

public static void main(String argv[]) throws Exception

{
String fraseCliente;
Cria socket String FraseMaiusculas;
para recepção ServerSocket socketRecepcao = new ServerSocket(6789);
na porta 6789
Aguarda, no socket while(true) {

para recepção, o Socket socketConexao = [Link]();

contato do cliente
BufferedReader doCliente =
Cria fluxo de new BufferedReader(new
entrada, ligado InputStreamReader([Link]()));
ao socket
2: Camada de Aplicação 115
 Exemplo: servidor Java (TCP), cont

Cria fluxo
de saída, ligado DataOutputStream paraCliente =
ao socket new DataOutputStream(socketConexã[Link]());
Lê linha
fraseCliente= [Link]();
do socket
fraseEmMaiusculas= [Link]() + '\n';
Escreve linha
[Link](fraseEmMaiusculas);
ao socket }
}
} Final do laço while,
volta ao início e aguarda
conexão de outro cliente

2: Camada de Aplicação 116

 Exemplo: cliente Python (TCP)
inclui a biblioteca de sockets
do Python from socket import *
serverName = ’servername’
serverPort = 12000
cria socket TCP socket
para o servidor, porta clientSocket = socket(AF_INET, SOCK_STREAM)
remota 12000
[Link]((serverName,serverPort))
sentence = raw_input(‘Input lowercase sentence:’)
[Link](sentence)
não há necessidade de
especificar nem o nome
modifiedSentence = [Link](1024)
do servidor nem a porta print ‘From Server:’, modifiedSentence
[Link]()

2: Camada de Aplicação 117

 Exemplo: servidor Python (TCP)

from socket import *

cria socket TCP de serverPort = 12000
recepção serverSocket = socket(AF_INET,SOCK_STREAM)
[Link]((‘’,serverPort))
servidor inicia a escuta
por solicitações TCP [Link](1)
print ‘The server is ready to receive’
loop infinito
while 1:
servidor espera no accept() connectionSocket, addr = [Link]()
por solicitações, um novo
socket é criado no retorno
lê bytes do socket (mas sentence = [Link](1024)
não precisa ler endereço capitalizedSentence = [Link]()
como no UDP)
[Link](capitalizedSentence)
fecha conexão para este [Link]()
cliente (mas não o socket
de recepção)

2: Camada de Aplicação 118

Capítulo 2: Roteiro
 2.1 Princípios de aplicações
 de
2.6rede
Aplicações P2P
 2.2 A Web e o HTTP  2.7 Programação e
desenvolvimento
 2.3 Transferência de arquivo: FTP de
aplicações com TCP
 2.4 Correio Eletrônico na Internet
 2.8 Programação de
 2.5 DNS: o serviço de diretório da Internet
sockets com UDP

2: Camada de Aplicação 119

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 ponto de vista da aplicação
UDP provê
 servidor deve extrair endereço IP, porta transferência
do remetente do
datagrama recebido não confiável de grupos
de bytesfora
UDP: dados transmitidos podem ser recebidos (“datagramas”)
de ordem,
ou perdidos entre cliente e servidor

2: Camada de Aplicação 120

Interações cliente/servidor usando o UDP
Servidor (executa em nomeHosp) Cliente

cria socket, cria socket,

porta=x, para socketCliente =
pedido que chega: DatagramSocket()
socketServidor =
DatagramSocket()
cria, endereça (nomeHosp, porta=x,
envia pedido em datagrama
usando socketCliente
lê pedido do
socketServidor

escreve resposta
ao socketServidor
especificando endereço lê resposta do
IP, número de porta socketCliente
do cliente fecha
socketCliente

2: Camada de Aplicação 121

Exemplo: Cliente Java (UDP)

UDP

2: Camada de Aplicação 122

 Exemplo: cliente Java (UDP)
import [Link].*;
import [Link].*;

class clienteUDP {
public static void main(String args[]) throws Exception
{
Cria
fluxo de entrada BufferedReader doUsuario=
new BufferedReader(new InputStreamReader([Link]));
Cria
socket de cliente DatagramSocket socketCliente = new DatagramSocket();
Traduz nome de
InetAddress IPAddress = [Link](”nomeHosp");
hospedeiro ao
endereço IP byte[] dadosEnvio = new byte[1024];
usando DNS byte[] dadosRecebidos = new byte[1024];

String frase = [Link]();

dadosEnvio = [Link]();
2: Camada de Aplicação 123
 Exemplo: cliente Java (UDP) cont.
Cria datagrama
com dados para
enviar, DatagramPacket pacoteEnviado =
new DatagramPacket(dadosEnvio, [Link],
comprimento, IPAddress, 9876);
endereço IP, porta
Envia datagrama [Link](pacoteEnviado);
ao servidor
DatagramPacket pacoteRecebido =
new DatagramPacket(dadosRecebidos, [Link]);
Lê datagrama
[Link](pacoteRecebido);
do servidor
String fraseModificada =
new String([Link]());

[Link](“Do Servidor:" + fraseModificada);

[Link]();
}
}

2: Camada de Aplicação 124

 Exemplo: cliente Python (UDP)
inclui a biblioteca de sockets
do Python from socket import *
serverName = ‘hostname’
serverPort = 12000
cria socket UDP para
servidor clientSocket = socket(socket.AF_INET,
obtém entrada do teclado do socket.SOCK_DGRAM)
usuário
message = raw_input(’Input lowercase sentence:’)
acrescenta o nome do
servidor e número da porta à [Link](message,(serverName, serverPort))
mensagem; envia pelo socket
modifiedMessage, serverAddress =
lê caracteres de resposta
do socket e converte em [Link](2048)
string
print modifiedMessage
imprime string recebido e
fecha socket [Link]()

2: Camada de Aplicação 125

Servidor UDP

2: Camada de Aplicação 126

 Exemplo: servidor Java (UDP)
import [Link].*;
import [Link].*;

class servidorUDP {
public static void main(String args[]) throws Exception
Cria socket {
para datagramas DatagramSocket socketServidor = new DatagramSocket(9876);
na porta 9876
byte[] dadosRecebidos = new byte[1024];
byte[] dadosEnviados = new byte[1024];

while(true)
{
Aloca memória para DatagramPacket pacoteRecebido =
new DatagramPacket(dadosRecebidos,
receber datagrama [Link]);
Recebe [Link](pacoteRecebido);
datagrama
2: Camada de Aplicação 127
 Exemplo: servidor Java (UDP), cont
String frase = new String([Link]());
Obtém endereço
InetAddress IPAddress = [Link]();
IP, no. de porta
do remetente int porta = [Link]();

String fraseEmMaiusculas = [Link]();

dadosEnviados = [Link]();
Cria datagrama p/
DatagramPacket pacoteEnviado =
enviar ao cliente new DatagramPacket(dadosEnviados,
[Link], IPAddress, porta);
Escreve
datagrama [Link](pacoteEnviado);
no socket }
}
} Fim do laço while,
volta ao início e aguarda
chegar outro datagrama 2: Camada de Aplicação 128
 Exemplo: servidor Python (UDP)

from socket import *

serverPort = 12000
cria socket UDP
serverSocket = socket(AF_INET, SOCK_DGRAM)
liga socket à porta local
número 12000 [Link](('', serverPort))
print “The server is ready to receive”
loop infinito while 1:
lê mensagem do socket
UDP, obtendo endereço do
message, clientAddress = [Link](2048)
cliente (IP e porta do modifiedMessage = [Link]()
cliente)
retorna string em [Link](modifiedMessage, clientAddress)
maiúsculas para este cliente

2: Camada de Aplicação 129

Capítulo 2: Resumo
Nosso estudo sobre aplicações de rede está agora
completo!
 Arquiteturas de aplicações  Protocolos específicos:
 cliente-servidor  HTTP
 P2P  FTP

 Requisitos de serviço das  SMTP, POP, IMAP

 DNS
aplicações:
 P2P: BitTorrent, DHT
 confiabilidade, banda, atraso
 Modelos de serviço de  Programação de sockets

transporte da Internet
 orientado à conexão,
confiável: TCP
 não confiável, datagramas:
UDP

2: Camada de Aplicação 130

 Capítulo 2: Resumo
Mais importante: aprendemos sobre protocolos
 troca típica de mensagens
Temas importantes:
pedido/resposta  msgs de controle vs. dados
 cliente solicita info ou serviço  na banda, fora da banda
 servidor responde com dados,
código de status
 centralizado vs.
descentralizado
 formatos de mensagens:
 s/ estado vs. c/ estado
 cabeçalhos: campos com info
sobre dados (metadados)
 transferência de msgs
 dados: info sendo comunicada confiável vs. não confiável
 “complexidade na borda da
rede”

2: Camada de Aplicação 131