Capítulo 2
Camada de Aplicação
A note on the use of these ppt slides:
We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you can add, modify, and delete slides
(including this one) and slide content to suit your needs. They obviously
represent a lot of work on our part. In return for use, we only ask the
following:
 If you use these slides (e.g., in a class) in substantially unaltered form,
that you mention their source (after all, we’d like people to use our book!)
 If you post any slides in substantially unaltered form on a www site, that
you note that they are adapted from (or perhaps identical to) our slides, and
note our copyright of this material.
Computer Networking:
A Top Down Approach,
5th edition.
Jim Kurose, Keith Ross
Addison-Wesley, July
2009.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2009
J.F Kurose and K.W. Ross, All Rights Reserved
2: Camada de Aplicação
1
2: Camada de Aplicação
2
2
Capítulo 2: Camada de Aplicação
• 2.1 Princípios das aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Aplicações P2P
• 2.7 Programação de Socket com TCP
• 2.8 Programação de Socket com UDP
2: Camada de Aplicação
3
Capítulo 2: Camada de Aplicação
Objetivos:
• Conceitual, aspectos
de implementação
dos protocolos de
aplicação
 Modelos de
serviço da camada
de transporte
 Modelo Cliente x
Servidor
 Modelo Peer-toPeer (Peer2Peer)
2: Camada de Aplicação
• Aprender sobre os
protocolos através de
protocolos populares
na camada de
aplicação




HTTP
FTP
SMTP / POP3 / IMAP
DNS
• Programação de
aplicações de rede
 socket API
4
Algumas aplicações de rede
• E-mail
• Web
• Sistema de Mensagem
•
•
•
•
instantânea (Instant
Messaging)
Login remoto
Compartilhamento de
arquivo P2P
Jogos de rede multiusuários
Vídeo sob demanda
2: Camada de Aplicação
• Voz sobre IP (VoiP)
• Vídeo-conferência
• Computação GRID
•
•
•
…
…
…
5
Criando uma aplicação de rede
Escreva programas que



Executem em sistemas finais
diferentes
Comuniquem-se via rede
e.x., o software de um
servidor web comunica-se com
o software de um browser
Poucos softwares são escritos
para os dispositivos no núcleo
da rede


Os dispositivos do núcleo não
executam aplicações do
usuário
Aplicações nos sistemas finais
permitem um rápido
desenvolvimento da aplicação
e a sua propagação
2: Camada de Aplicação
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
6
Capítulo 2: camada de aplicação
• 2.1 Princípios das aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Aplicações P2P
• 2.7 Programação de Socket com TCP
• 2.8 Programação de Socket com UDP
2: Camada de Aplicação
7
Arquiteturas de aplicação
• Cliente-Servidor
• Peer-to-peer (P2P)
• Híbrido de Cliente-Servidor e P2P
2: Camada de Aplicação
8
Arquitetura Cliente-Servidor
cliente/servidor
2: Camada de Aplicação
Servidor:
 Sempre “on”
 Endereço IP permanente
 Fazendas de servidores
para fins de escalabilidade
Cliente:
 Comunica com o servidor
 Pode ser conectado de
modo intermitente
 Pode possuir endereço IP
dinâmico
 Não se comunica
diretamente com outro
cliente
9
Data Centers: Google
• Custo Estimado de um Data Center: $600M
• Google tem gasto mais de $3B/ano em data
centers
• Cada data center utilliza 50-100 megawatts
de potência
2: Camada de Aplicação
10
Arquitetura P2P Pura
 Não existem servidores
sempre “on”
 Sistemas finais arbitrários
comunicam-se diretamente
 Os pares são conectados de
modo intermitente e podem
ter o endereço IP alterado
 exemplo: Gnutella
P2P
Altamente escalável mas difícil
de gerenciar
2: Camada de Aplicação
11
Híbrido de Cliente-Servidor e P2P
Skype
Aplicação P2P de voz sobre IP (VoiP)
 Servidor centralizado: permite encontrar o endereço de um
parceiro remoto;
 Conexão cliente-cliente: direta (sem passar pelo servidor)
Mensagem Instantânea
 Conversa entre dois usuários (P2P)
 Serviço centralizado: deteção/localização da presença do
cliente

• Usuários registram seus endereços IP no
servidor central quando eles tornam-se “online”
• Usuário contacta o servidor central para obter
o endereço IP dos pares
2: Camada de Aplicação
12
Processos comunicantes
Processo: programa em
execução no host
 Dentro de um mesmo
host, dois processos
comunicam-se através
do uso da comunicação
entre-processos
(definida pelo OS)
 Processos em hosts
diferentes comunicamse através da troca de
mensagens
2: Camada de Aplicação
Processo cliente:
processo que inicia a
comunicação
Processo servidor:
processo que espera
ser contactado
 Nota: aplicações P2P
possuem processos
clientes & processos
servidores
13
Sockets
•
•
Processo envia/recebe
mensagens para/do seu
socket
O socket é análogo a uma
porta


o processo emissor empurra a
mensagem através da porta
o processo emissor confia na
infra-estrutura de transporte
do outro lado da porta que
leva a mensagem ao socket do
processo receptor.
host ou servidor
host ou servidor
processo
Controlado pelo
desenvolvedor da
aplicação
socket
socket
TCP com
buffers,
variáveis
processo
Internet
TCP com
buffers,
variáveis
Controlado pelo OS
• API: (1) escolha do protocolo de transporte; (2)
possibilidade de fixar alguns parâmetros (discussão
mais à frente!)
2: Camada de Aplicação
14
Identificação dos processos
• Para receber mensagens os processos
devem possuir um identificador
• O host possui um endereço IP de 32-bits
• Q: o endereço IP do host no qual o
processo executa é suficiente para
identificar o processo?
2: Camada de Aplicação
15
Identificação dos processos
R: Não, já que
muitos processos
podem estar
executando no
mesmo host
identificador inclui o
endereço IP e o número da
porta associada ao
processo no host.
• Exemplos de portas:
•


Servidor HTTP: 80
Servidor de e-mail: 25
• Para enviar mensagens
HTTP ao servidor web
gaia.cs.umass.edu:


2: Camada de Aplicação
Endereço Ip: 128.119.245.12
Número da porta: 80
16
Protocolo da camada de aplicação
define:
•
Tipos das mensagens
trocadas,

•
Sintaxe da mensagem:

•
Quais campos fazem parte
da mensagem, ordem e
tamanho dos campos
Semântica da mensagem

•
e.x., requisição (request),
resposta (response)
Protocolos de domínio público:
• Definidos em RFCs
• Permite a
interoperabilidade
• e.x., HTTP, SMTP
Protocolos proprietários:
• e.x., Skype
Significado da informação
nos campos
Regras para quando e como
os processos reagem à
troca de mensagens
2: Camada de Aplicação
17
Quais serviços de transporte as aplicações
necessitam?
Perda de dados
• Algumas aplicações (e.x., áudio)
podem tolerar alguma perda
• Outras aplicações (e.x.,
transferência de arquivos,
telnet) requerem 100% para a
transferência confiável de
dados
Temporização
• Algumas aplicações
(ex. Telefonia na
Internet, jogos
interativos) requerem
baixo atraso para
serem “efetivas”
2: Camada de Aplicação
Bandwidth
• Algumas aplicações
(e.x. multimídia)
requerem uma
quantidade mínima de
banda para serem
“efetivas”
• Outras aplicações
(“aplic. elásticas)
utilizam qualquer banda
que eles obtêm
18
Requisitos de algumas aplicações relativamente
ao serviço de transporte
Aplicação
Transf. de arquivo
e-mail
Documentos Web
Áudio/vídeo em
teleconferência
Perda
de dados
Sem perda
Sem perda
Sem perda
Tolerante
Tolerante
Jogos interativos Tolerante
Mensagem instantânea Sem perda
Áudio/vídeo armazenado
2: Camada de Aplicação
Sensibilidade
Bandwidth
ao tempo
elástico
não
elástico
não
elástico
não
áudio: 5kbps-1Mbps sim, 100’s msec
vídeo:10kbps-5Mbps
sim, alguns secs
igual ao de cima
Alguns kbps a mais sim, 100’s msec
sim e não
elástico
19
Protocolos de transporte na
Internet
Serviço TCP:
Serviço UDP:
•
•
•
•
•
•
Orientado à conexão: requer
o estabelecimento da
conexão entre os processos
cliente e servidor
Transporte confiável: entre
os processos emissor e
receptor
Controle de fluxo: o emissor
não deve sobrecarregar o
receptor
Controle de
congestionamento: regular o
emissor quando a rede está
sobrecarregada
Não suporta: temporização,
garantia de banda mínima
2: Camada de Aplicação
•
Transferência nãoconfiável de dados entre
os processos emissor e
receptor
Não suporta:
estabelecimento de
conexão, controle
defluxo, controle de
congestionamento,
temporizações, ou
garantia de banda
20
Aplicações Internet: protocolos de aplicação & de
transporte
Applicação
Protocolo da
camada de aplicação
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
proprietário
(e.g. RealNetworks)
Telefonia Internet proprietary
(e.g., Vonage,Dialpad)
e-mail
Acesso de terminal remoto
Web
Transferência de arquivos
Fluxo multimídia
2: Camada de Aplicação
Protocolo de
transporte associado
TCP
TCP
TCP
TCP
TCP or UDP
tipicamente UDP
21
Capítulo 2: Camada de Aplicação
• 2.1 Princípios das aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Aplicações P2P
• 2.7 Programação de Socket com TCP
• 2.8 Programação de Socket com UDP
2: Camada de Aplicação
22
Web e HTTP
Inicialmente algumas definições
• página Web consiste de objetos
• Objeto pode ser um arquivo HTML, imagem
JPEG, applet Java, arquivo de áudio, …
• Página Web consiste de um arquivo HTML que
inclui referências a outros objetos
• Cada objeto é endereçável através de uma URL
• Exemplo URL:
www.someschool.edu/someDept/pic.gif
Nome do host
2: Camada de Aplicação
Nome do caminho (path)
23
Descrição do HTTP
HTTP: hypertext
transfer protocol
•
•
•
•
Protocolo de aplicação da
Web
Modelo cliente x servidor
 cliente: browser usado
para requisitar,
receber, apresentar
objetos Web
 servidor: servidor Web
envia objetos em
resposta às requisições
HTTP 1.0: RFC 1945
HTTP 1.1: RFC 2068
2: Camada de Aplicação
R eq
uis
içã
oH
PC executando Res
TT
P
pos
Int. Explorer
ta
HT
TP
TP
T
oH
ã
ç
TP Servidor
si
i
T
u
q
executando
aH
Re
t
s
o
Servidor
sp
Re
Apache Web
Mac executando
Navegador
24
Descrição HTTP (continuação)
Utiliza TCP:
•
•
•
•
Cliente inicia conexão TCP
(cria socket) com o
servidor, porta 80
Servidor aceita pedido de
conexão TCP do cliente
Troca de mensagens HTTP
entre o browser (cliente
HTTP) e o servidor Web
(servidor HTTP)
encerramento da conexão
TCP
2: Camada de Aplicação
HTTP é “stateless”
•
Servidor não mantém
qualquer informação
sobre as requisições
anteriores do cliente
Obs.
Protocolos que mantêm
estado são complexos!
• O passado (estado) deve
ser mantido
• Caso o servidor/cliente
falhe, suas visões de
“estado” podem ser
inconsistentes e devem ser
reconciliadas
25
Conexões HTTP
HTTP não-persistente
• No máximo um objeto
é enviado em uma
conexão TCP.
• HTTP/1.0 utiliza o
HTTP não-persistente
2: Camada de Aplicação
HTTP Persistente
• Múltiplos objetos
podem ser enviados
em uma única conexão
TCP entre o cliente e
o servidor.
• HTTP/1.1 utiliza
conexões persistentes
como modo “default”
26
HTTP Não-Persistente
(contém texto e
Suponha que o usuário entre a seguinte URL
referências p/10
www.someSchool.edu/someDepartment/home.index Imagens jpeg)
1a. cliente HTTP inicia
conexãoTCP com o servidor
HTTP (processo) em
www.someSchool.edu on port
80
2. cliente HTTP envia mensagem
de requisição (contendo URL)
no socket da conexão TCP. A
mensagem indica que o cliente
deseja o objeto
someDepartment/home.index
1b. Servidor HTTP no host
www.someSchool.edu espera
por conexão TCP na porta 80.
“aceita” a conexão notificando
ao client
3. Servidor HTTP recebe a
mensagem de requisição,
prepara a mensagem de
resposta contendo o objeto
requisitado e a envia no socket
tempo
2: Camada de Aplicação
27
HTTP não-persistente (cont.)
4. Servidor HTTP server fecha
5. Cliente HTTP recebe a
tempo
a conexão TCP .
mensagem de resposta
contendo arquivo html e, em
seguida, apresenta o arquivo
html. O parsing do arquivo
html encontra 10 referências
a objetos .jpeg.
6. Repete os passos 1-5 para
cada um dos 10 objetos jpeg
2: Camada de Aplicação
28
HTTP não-persistente: tempo de
resposta
Definição de RTT: tempo de
ida e volta de um pacote
(cliente-servidor-cliente).
Tempo de resposta:
• um RTT para iniciar a
conexãoTCP
• um RTT para a requisição
HTTP e o retorno da
resposta HTTP
• Tempo de transmissão do
arquivo
total = 2RTT + tempo de
transmissão
2: Camada de Aplicação
Inicia conexão
TCP
RTT
Requisita
o arquivo
Tempo de
tranmissão
do arquivo
RTT
Arquivo
recebido
tempo
tempo
29
HTTP persistente
HTTP não-persistente:
• requer 2 RTTs por objeto
• Overhead do OS para cada
conexão TCP
• Em geral os browsers abrem
conexões TCP em paralelo
para buscar os objetos
HTTP persistente
• O servidor deixa a conexão
aberta após o envio da
resposta
• Mensagens HTTP
subsequentes entre o par
cliente/servidor são
enviadas na conexão aberta
2: Camada de Aplicação
Persistente sem pipelining:
• Cliente envia nova
requisição somente quando
a anterior foi recebida
• um RTT para cada objeto
referenciado
Persistente com pipelining:
• default no HTTP/1.1
• Cliente envia requisições
assim que ele encontra
referência para um objeto
• Praticamente um RTT para
todos os objetos
referenciados
30
Mensagem de requisição HTTP
• Dois tipos de mensagens HTTP messages:
request, response
• Mensagem de requisição HTTP:
ASCII (formato legível ao ser-humano)
Linha de requisição
(comandos GET,
GET /somedir/page.html HTTP/1.1
POST, HEAD)
Host: www.someschool.edu
User-agent: Mozilla/4.0
cabeçalho Connection: close
Accept-language:fr

Carriage return,
line feed
indicam o fim da
mensagem
2: Camada de Aplicação
(carriage return, line feed extras)
31
Mensagem de requisição HTTP: formato
geral
2: Camada de Aplicação
32
Enviando dados de formulário
Método Post:
• Página Web inclui um
formulário
• A entrada é encaminhada
(uploaded) ao servidor no
“entity body”
Método URL:
• Usa o método Get
• A entrada é encaminhada
no campo URL da linha de
requisição:
www.somesite.com/animalsearch?monkeys&banana
2: Camada de Aplicação
33
Tipos de métodos
HTTP/1.0
• GET
• POST
• HEAD

Similar ao Get. O
servidor não retorna o
objeto especificado
(usado para debugging)
2: Camada de Aplicação
HTTP/1.1
• GET, POST, HEAD
• PUT

Envia arquivo no “entity
body” para o caminho
(path) especificado no
campo URL
• DELETE
 Deleta o arquivo
especificado no campo
URL
34
Mensagem de resposta HTTP
Linha de status
Cabeçalho
dado, e.x.,
Arquivo HTML
requisitado
2: Camada de Aplicação
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
35
Códigos de status nas mensagens
de resposta HTTP
Aparecem na primeira linha da mensagem de
resposta servidor ->cliente
Alguns exemplos de códigos:
200 OK

Requisição bem sucedida; objeto requisitado incluído na
mensagem;
301 Objeto deslocou

Objeto requisitado moveu; nova localização incluída na mensagem;
400 Requisição incorreta

Mensagem de requisição não entendida pelo servidor
404 Não encontrado

Documento requisitado não encontrado no servidor
505 Versão HTTP Version não suportada
2: Camada de Aplicação
36
Acessando um servidor HTTP via linha de
comandos
1. Comando telnet para um servidor Web:
telnet cis.poly.edu 80 abre conexão TCP na porta 80
(porta default do servidor Web) em cis.poly.edu.
Qualquer comando é enviado para a porta 80 em
cis.poly.edu
2. comando de requisição GET HTTP:
GET /~ross/ HTTP/1.1
Host: cis.poly.edu
Ao entrar este comando (bater duas
vezes o carriage return), voce envia
uma requisição GET mínima mas
completa ao Servidor HTTP
3. Analise a resposta enviada pelo servidor HTTP!
2: Camada de Aplicação
37
Olhando o HTTP em ação-Exemplos
• Exemplo telnet
• Exemplo Wireshark (ferramenta livre de
monitoramento de redes)
2: Camada de Aplicação
38
Estado do usuário: cookies
Vários sítios Web utilizam
pequenos arquivos
chamados cookies
Quatro situações:
1) Cookie é gerado no sítio
Web na primeira conexão e
guardado em base de dados.
2) Cookie é inserido no
cabeçalho da mensagem de
resposta HTTP
3) Cookie é armazenado e
gerenciado pelo browser no
host do usuário
4) Cookie é enviado pelo
browser ao servidor a cada
nova requisição HTTP
2: Camada de Aplicação
Exemplo:
• Susan sempre acessa a
Internet através do mesmo
PC
• Visita um sítio específico de
e-comércio pela primeira vez
• Quando a requisição HTTP
inicial chega no destino, o
sítio cria:
 ID único
 Entrada na base de dados
para o ID
e devolve tais informações na
forma de um arquivo cookie.
39
Cookies: mantendo o “estado”
cliente
ebay 8734
Arquivo cookie
ebay 8734
amazon 1678
servidor
requisição http
resposta http
Set-cookie: 1678
requisição http
cookie: 1678
resposta http customizada
Servidor Amazon
cria ID 1678
para o usuário cria
entrada
cookie
Uma semana após:
ebay 8734
amazon 1678
2: Camada de Aplicação
accesso
accesso
Base de
dados
requisição http
cookie: 1678
resposta http customizada
cookie
40
Cookies (cont.)
O quê os cookies oferecem:
• autorização
• cartões de compra
• recomendações
• estado da sessão do
usuário
2: Camada de Aplicação
Obs
Cookies e privacidade:
• Os cookies permitem que
se aprenda bastante sobre
o usuário
• Você pode fornecer seu
nome e e-mail para os sítios
41
Caches Web (servidor proxy)
Objetivo: atender a requisição do cliente sem envolver o
servidor original
• Usuário configura
o
browser: acesso Web é
feito por meio de um proxy
• Cliente envia todos os
pedidos HTTP para o Web
cache
• Se o objeto existe no
Web cache: Web cache
retorna o objeto
• Ou o Web cache solicita
objeto do servidor original
e então envia o objeto ao
cliente
2: Camada de Aplicação
42
Mais sobre o cache Web
•
O cache atua tanto como
cliente como servidor
• Tipicamente, o cache é
instalado pelo ISP
(universidade,
companhia, ISP
residencial)
2: Camada de Aplicação
Porque o cache Web?
• Reduz o tempo de resposta
para a requisição do
cliente.
• Reduz o tráfego num enlace
de acesso de uma
instituição.
• A densidade de caches na
Internet habilita os “fracos”
provedores de conteúdo a
efetivamente entregarem o
conteúdo (mas fazendo P2P
file sharing)
43
Exemplo de caching
Suponha:
• Tamanho médio objeto = 100.000
bits
• Taxa média de requisições dos
browsers da instituição para os
servidores de origem = 15/s
• Atraso típico na nuvem Internet
Pública = 2 seg.
• Atraso típico na LAN = 10 ms
Conseqüências:
• Utilização da LAN =
100.000 x 15 / 10.000.00 = 15%
• Utilização do enlace de acesso =
100.000 x 15 / 1.000.000 = 150%
• Atraso total = atraso da LAN +
atraso de acesso + atraso da
Internet = 10 ms + alguns minutos
(sobrecarga) + 2 s = alguns minutos
2: Camada de Aplicação
Servidores de
origem
Internet
Pública
Enlace de acesso
1 Mbps
Rede
institucional
10 Mbps LAN
44
Exemplo de caching (cont)
Servidores de
origem
Solução possível
•
Aumentar a banda do acesso do
enlace para, p. ex., 10 Mbps
consequência
•
•
•
•
Utilização da LAN =
= 100.000 x 15 / 10.000.000 =
15%
Utilization do enlace de acesso =
= 100.000 x 15 / 10.000.000 =
15%
Atraso total = atraso da LAN +
atraso do acesso + atraso Internet
= 10 ms + 10 ms + 2 s = 2,02 s
Trata-se, em geral, de um
“upgrade” caro!
2: Camada de Aplicação
Internet
Pública
Enlace de acesso
1 Mbps -> 10 Mbps
Rede
institucional
10 Mbps LAN
45
Exemplo de caching (cont)
Solução possível: instalação de
um cache
•
Suponha que a tx. de sucesso é
de 0,4 (40% dos dados pedidos
já estão no cache)
Servidores de
origem
Internet
Pública
Consequência
•
•
•
•
40% das requisições serão
satisfeitas imediatamente
60% das requisições serão
atendidas pelos servidores
originais (usam enlace)
A utilização do enlace de acesso
é reduzida para 60% implicando
em atrasos negligíveis (~10 ms)
Atraso médio total= atraso de
LAN + atraso de acesso +
atraso Internet = 0.4* 10 ms +
0.6*(10 ms + 2.0 s) = 1.21 s
2: Camada de Aplicação
Enlace de acesso
1 Mbps
Rede
institucional
10 Mbps LAN
Cache
institucional
46
GET condicional
Servidor
Cliente
• Razão: não enviar objeto se
a versão que o cliente já
possui está atualizada.
• Cliente: especifica a data da
versão armazenada no pedido
HTTP
If-modified-since:
<date>
• Servidor: resposta não
contém objeto se a cópia é
atualizada:
HTTP/1.0 304 Not Modified
2: Camada de Aplicação
HTTP request msg
If-modified-since: <date>
HTTP response
HTTP/1.0
304 Not Modified
HTTP request msg
If-modified-since: <date>
Objeto
não
modificado
Objeto
modificado
HTTP response
HTTP/1.1 200 OK
<data>
47
Capítulo 2: Camada de Aplicação
• 2.1 Princípios das aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Aplicações P2P
• 2.7 Programação de Socket com TCP
• 2.8 Programação de Socket com UDP
2: Camada de Aplicação
48
FTP: the file transfer protocol
usuário
Interface de Cliente
usuário
FTP
FTP
Transf. de arquivo
Sistema de
Arquivo local
•
•
•
•
Servidor
FTP
Sistema de
Arquivo
remoto
Transferência de arquivo para/do host remoto
Modelo cliente x servidor
 cliente: lado que inicia a transferência (seja para/do
host remoto)
 servidor: host remoto
ftp: RFC 959
Servidor ftp: porta 21
2: Camada de Aplicação
49
FTP: separa fluxo de controle e fluxo
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
• Servidor abre uma segunda conexão de dados TCP para transferir outro
arquivo
• Conexão de controle: “fora da banda”
• Servidor FTP mantém “estado”: diretório atual, autenticação anterior
Conexão de controle TCP
porta 21
Cliente
FTP
2: Camada de Aplicação
Conexão TCP de dados
Servidor
porta 20
FTP
50
FTP commands, responses
Exemplos de comandos:
• Envie um texto ASCII sobre canal de controle
• USER username
• PASS password
• LIST retorna listagem do arquivo no diretório atual
• RETR filename recupera (obtém) o arquivo
• STOR filename armazena o arquivo no hospedeiro remoto
Exemplos de códigos de retorno
• Código de status e frase (como no HTTP)
• 331 Username OK, password required
• 125 data connection already open; transfer starting
• 425 Can’t open data connection
• 452 Error writing file
2: Camada de Aplicação
51
Capítulo 2: Camada de Aplicação
• 2.1 Princípios das aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Aplicações P2P
• 2.7 Programação de Socket com TCP
• 2.8 Programação de Socket com UDP
2: Camada de Aplicação
52
Correio eletrônico
Fila de
mensagens de saída
Mailbox do
usuário
Três componentes principais:
•
•
•
Agentes do usuário
Servidores de e-mail
Protocolo de transferência de
e-mail: SMTP
Agente do usuário
• Conhecido como “leitor de email”
• Composição, edição, leitura de
mensagens de e-mail
• E.x., Eudora, Outlook, elm,
Mozilla Thunderbird
• O servidor armazena as
mensagens enviadas e
recebidas
2: Camada de Aplicação
Agente
do
usuário
Servidor
de e-mail
SMTP
SMTP
SMTP
Servidor
de e-mail
Agente
do
usuário
Agente
do
usuário
Servidor
de e-mail
Agente
do
usuário
Agente
do
usuário
Agente
do
usuário
53
Correio eletrônico: servidores de
e-mail
Servidores de e-mail
•
•
•
Mailbox: contém as
mensagens enviadas para o
usuário
Fila de mensagens: contém
as mensagens de saída (a
serem enviadas)
Protocolo SMTP: protocolo
tipo cliente-servidor entre
os servidores de e-mail
para troca de mensagens
 “cliente”: servidor
emissor do e-mail
 “servidor”: servidor
receptor do e-mail
2: Camada de Aplicação
Agente
do
usuário
Servidor
de e-mail
SMTP
SMTP
SMTP
Servidor
de e-mail
Agente
do
usuário
Agente
do
usuário
Servidor
de e-mail
Agente
do
usuário
Agente
do
usuário
Agente
do
usuário
54
Correio eletrônico: SMTP [RFC 2821]
•
•
•
•
Utiliza o TCP para transferência confiável das
mensagens de e-mail do cliente para o servidor via
porta 25
Transferência direta: servidor emissor para servidor
receptor
Transferência em três fases:
 handshaking (cumprimentos)
 Transferência de mensagens
 encerramento
Interação comando/resposta
 comandos: texto ASCII
 resposta: frase e código de status
• As mensagens devem ser codificadas em
ASCII de 7-bits
2: Camada de Aplicação
55
Cenário: Alice envia mensagens para
Bob
1) Alice usa o agente (UA)
para compor a mensagem e
enviar “to”
[email protected]
2) O agente de Alice envia a
mensagem para o seu
servidor; a mensagem é
colocada na fila de
mensagem
3) O lado cliente do SMTP
abre uma conexão TCP com
o servidor de e-mail do Bob
1
2
Agente
do
usuário
2: Camada de Aplicação
4) O cliente SMTP envia a
mensagem da Alice na
conexão TCP
5) O servidor de e-mail do
Bob coloca a mensagem no
mailbox do Bob
6) Bob evoca o seu agente
para ler a mensagem
Servidor
de e-mail
3
4
Servidor
de e-mail
5
6
Agente
do
usuário
56
Exemplo de uma interação SMTP
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
2: Camada de Aplicação
57
Tente uma interação SMTP!
• Entre telnet servername 25
• Aguarde resposta tipo: 220 reply from server
• Entre os comandos para envio de um e-mail sem
a utilização de um cliente de e-mail (reader):
HELO, MAIL FROM:, RCPT TO:, DATA, QUIT
2: Camada de Aplicação
58
SMTP: características
•
•
•
SMTP utiliza conexão
persistente
SMTP requer as
mensagens (cabeçalho &
corpo) em ASCII de 7
bits: necessidade de
codificação de mensagens
com outras codificações
que usam mais de 7 bits
SMTP utiliza CRLF.CRLF
para determinar o fim da
mensagem
2: Camada de Aplicação
Comparação com o HTTP:
•
•
HTTP: pull
SMTP: push
•
Ambos interagem via
comandos/resposta e
códigos de status em
ASCII
•
HTTP: cada objeto é
encapsulado na mensagem
de resposta
SMTP: múltiplos objetos
enviados na mensagem
•
59
Formato da mensagem de e-mail
SMTP: protocolo para troca
de mensagens de e-mail
RFC 822: padrão para
formato da mensagem de
texto:
• Linhas de cabeçalho, e.x.,
To:
 From:
 Subject:
(não são os comandos SMTP !)

•
cabeçalho
Linha
em branco
CRLFCRLF
body
body

mensagem codificada com
caracteres ASCII de 7 bits
2: Camada de Aplicação
60
Formato da mensagem: extensões
multimídia
•
•
MIME: extensão multimedia para o e-mail, RFC 2045,
2056
Linhas adicionais no cabeçalho da mensagem declaram
o conteúdo do tipo MIME
Versão MIME
Método usado para
codificação do dado
Dado multimídia
tipo, subtipo,
dado codificado
2: Camada de Aplicação
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
61
Protocolos de acesso ao e-mail
SMTP
Agente
do
usuário
SMTP
Protocolo
de acesso
Agente
do
usuário
Servidor de e-mail Servidor de e-mail
emissor
receptor
•
•
SMTP: entrega/armazenamento no servidor de recepção
Protocolo de acesso ao e-mail: recebimento da mensagem do
servidor
 POP: Post Office Protocol [RFC 1939]
• autorização (agente <-->servidor) e download
 IMAP: Internet Mail Access Protocol [RFC 1730]
• Mais características (mais complexo)
• Manipulação das mensagens armazenadas no servidor
 HTTP: gmail, Hotmail, Yahoo! Mail, etc.
2: Camada de Aplicação
62
Protocolo POP3
Fase de autorização
•
•
Comandos do cliente:
 user: declara username
 pass: password
Respostas do servidor
 +OK
 -ERR
Fase de transação, cliente:
list: lista número da
mensagem
• retr: recupera mensagem
pelo número
• dele: deleta
• quit
•
2: Camada de Aplicação
S:
C:
S:
C:
S:
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
63
on
POP3 e IMAP
Mais sobre o POP3
• Exemplo anterior utiliza o
modo “download and
delete”.
• Bob não pode reler o email caso ele troque de
cliente
• “Download-and-keep”:
cópias das mensagens em
clientes diferentes
• POP3 é do tipo “stateless”
2: Camada de Aplicação
IMAP
• Mantém as mensagens em
único lugar: o servidor
• Permite que o usuário
organize as mensagens em
pastas
• IMAP mantém o estado do
usuário entre sessões:

Nomes dos folders e
mapeamento entre o ID
das mensagens e o nome da
pasta
64
Capítulo 2: Camada de Aplicação
• 2.1 Princípios das aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Aplicações P2P
• 2.7 Programação de Socket com TCP
• 2.8 Programação de Socket com UDP
2: Camada de Aplicação
65
DNS: Domain Name System
Pessoas: vários
identificadores:
Domain Name System:
Base de dados distribuída
 RG, name, #cic, …
implementada através de uma
Hosts Internet, roteadores:
hierarquia de vários
 Endereço IP (32 bits) –
servidores de nomes
usado para endereçamento • Protocolo de aplicação permite
de datagramas
que hosts e servidores de
 “nome”, e.x., ww.yahoo.com
nomes comuniquem-se para
– usado por humanos
resolução de nomes (tradução
Q: como mapear nomes e
nome/endereço)
endereços IP?
 nota: função do núcleo da
Internet mas implementada
como um protocolo de
camada de aplicação
2: Camada de Aplicação
•
66
DNS
Serviços DNS
• Tradução do nome do
host no endereço IP
• Aliasing do host

Canonical, sinônimos
(aliases)
• Aliasing do servidor
de e-mail
• Distribuição da carga

Servidores Web
replicados: conjunto de
endereços IP para um
nome canônico
2: Camada de Aplicação
Por que não um DNS
centralizado?
• Ponto único de falha
• Alto volume de tráfego
• Base de dados
centralizada distante
• Dificuldades de
manutenção
Conclusão: não é escalável!
67
Base de dados Hierárquica e
distribuída
Servidores DNS Root
Servidores DNS .com
Servidores DNS .org
Servidores
Servidores DNS
DNS yahoo.com amazon.com
Servidores DNS .edu
Servidores DNS Servidores DNS Servidores DNS
umass.edu
poly.edu
pbs.org
Cliente deseja IP para www.amazon.com; 1a aprox:
• Cliente consulta um servidor root para obter o
servidor DNS responsável por .com
• Cliente consulta servidor DNS .com para obter
servidor DNS amazon.com
• Cliente consulta servidor DNS amazon.com para
obter o endereço IP de www.amazon.com
2: Camada de Aplicação
68
DNS: servidores de nome raiz
(Root)
•
Contactado pelo servidor de nome local que não é capaz de resolver o
nome
Servidor de nome raiz:
 Contata o servidor de nome autoridade (authoritative) se o
mapeamento do nome não é conhecido
 Obém o mapeamento
 Retorna o mapeamento para o servidor de nome local
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD
g US DoD Vienna, VA
h ARL Aberdeen, MD
j Verisign, ( 21 locations)
e NASA Mt View, CA
f Internet Software C. Palo Alto,
k RIPE London (also 16 other locations)
i Autonomica, Stockholm (plus
28 other locations)
m WIDE Tokyo (also Seoul,
Paris, SF)
CA (and 36 other locations)
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
2: Camada de Aplicação
13 servidores de
nome raiz no
mundo!
69
Servidores TLD e Servidores
autoridades
• Servidores Top-level domain (TLD):



responsáveis por com, org, net, edu, etc, e todos os domínios de
países como br, uk, fr, ca, jp.
Network Solutions mantém servidores TLD .com
Educause mantém TLD .edu
• Servidores DNS autoridades:


Servidores DNS das organizações são autoridades para
fornecimento do mapeamento IP para o nome dos servidores da
organização (e.x., Web, mail).
Podem ser mantidos pelas organizações ou pelo provedor de serviço
2: Camada de Aplicação
70
Servidor de Nome Local
• Na verdade, não pertence à hierarquia do DNS
• cada ISP (ISP residencial, empresa,
universidade) possui um.

Também chamado de “default name server”
• Quando um host faz uma consulta DNS, a
consulta é encaminhada ao seu servidor DNS
local

Atua como um proxy encaminhando a consulta na hierarquia
2: Camada de Aplicação
71
Exemplo de resolução de nome
root DNS server
através do DNS
2
• Host em cis.poly.edu
deseja o endereço IP
para
gaia.cs.umass.edu
Consulta iterativa:
•
•
Servidor contactado
responde com o nome
do servidor a ser
contactado
“Eu não conheço este
nome mas pergunte a
este servidor”
2: Camada de Aplicação
3
4
TLD DNS server
5
local DNS server
dns.poly.edu
1
8
requesting host
7
6
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu
72
Exemplo de resolução de nome DNS
root DNS server
Consulta recursiva:
•
2
Transfere o ônus da
resolução de nome ao
servidor contactado
3
7
6
TLD DNS server
local DNS server
dns.poly.edu
1
5
4
8
requesting host
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu
2: Camada de Aplicação
73
DNS: caching e atualização dos
registros
• Uma vez que qualquer servidor de nomes
aprende um mapeamento, ele faz o cache
deste mapeamento
 As entradas do cache possuem validade por
um tempo (timeout) desaparecendo após
expirado este tempo
 Parte do conteúdo dos servidores TLD em
geral encontra-se no cache dos servidores
locais
• Isso evita a necessidade de contactar os
servidores de nome root a todo momento.
2: Camada de Aplicação
74
Registros DNS
DNS: base de dados distribuída armazenando “resource records” (RR)
Formato RR:
(name, value, type, ttl)
• Type=A
 Nome é hostname
 Valor é endereço IP
• Type=NS
Nome é domínio
(e.x. foo.com)

Valor é o hostname do
servidor autoridade para
este domínio
2: Camada de Aplicação
• Type=CNAME
 name é um alias para algum
nome canônico (nome real)
www.ibm.com é, na realidade,
servereast.backup2.ibm.com

Valor corresponde ao
nome canônico
• Type=MX
 value é o nome do servidor
de e-mail associado ao name
75
DNS: protocolo, mensagens
Protocolo DNS : mensagens de consulta e
resposta, ambas possuem o mesmo formato
Cabeçalho da mensagem
•
•
identificação: 16 bits
para consulta; resposta
usa o mesmo
identificador
flags:
 consulta ou resposta
 demanda de recursão
 recursão disponível
 resposta é de
autoridade do domínio
2: Camada de Aplicação
76
DNS: protocolo, mensagens
Nome, tipo da consulta
RRs na resposta
a uma consulta
Registros para
servidores autoridades
Informação adicional
2: Camada de Aplicação
77
Inserindo registros no DNS
• Exemplo: novo domínio “Network Utopia”
Registro do nome networkuptopia.com no DNS (e.g.,
Network Solutions)


Fornece nome e endereço IP do servidor de nomes autoridade
(deve haver primário e secundário)
É preciso inserir 2 registros RRs no servidor TLD:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
Criar registros do Tipo A no servidor autoridade para
o servidor web www.networkutopia.com e do Type MX
para o servidor de mail mail.networkutopia.com
2: Camada de Aplicação
78
Capítulo 2: Camada de Aplicação
• 2.1 Princípios das aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Aplicações P2P
• 2.7 Programação de Socket com TCP
• 2.8 Programação de Socket com UDP
2: Camada de Aplicação
79
P2P: Compartilhamento de arquivo
Alice escolhe um dos
“peers”, Bob.
• Uma cópia do arquivo é
trazida do PC do Bob para o
notebook da Alice: HTTP
• Enquanto Alice faz o
download, outros usuários
realizam uploading do
notebook da Alice.
• Os pares da Alice são,
simultaneamente, um cliente
e um Servidor.
Todos os pares são servidores
= alta escalabilidade!
•
Exemplo
• Alice executa uma
aplicação P2P no seu
notebook
• Intermitentemente
conecta-se à Internet;
obtém um novo endereço
IP a cada acesso
• Pergunta por “Hey Jude”
• A aplicação informa
outros “peers” que
possuem uma cópia de Hey
Jude.
2: Camada de Aplicação
80
P2P: diretório centralizado
Projeto original do “Napster”
1) Quando um peer conectacentralized
se, ele informa ao
directory server
servidor central:


Bob
1
peers
Endereço IP
conteúdo
2) Alice pergunta por “Hey
Jude”
3) Alice requisita arquivo da
máquina do Bob
1
3
1
2
1
Alice
2: Camada de Aplicação
81
P2P: problemas relacionados a um
diretório centralizado
• Ponto único de falha
• Gargalo no desempenho
• Problemas de copyright: a ação da lei
é óbvia
A transferência do arquivo é descentralizada, mas a
localização do conteúdo é altamente centralizada
2: Camada de Aplicação
82
Gnutella: inundação
• Completamente
distribuída

Não possui servidor
central
• Protocolo de domínio
público
• Muitos clientes
Gnutella implementam o
protocolo
2: Camada de Aplicação
Rede overlay: grafo
• Arco entre os pares X e
Y caso exista uma
conexão TCP entre eles
• Todos os pares ativos e
os arcos formam uma
rede overlay
• arco: enlace virtual (não
físico)
• Um “peer” conecta-se,
tipicamente, com < 10
vizinhos overlay.
83
Gnutella: protocolo
mensagem de query nas conexões TCP existentes
❒ os pares encaminham a mensagem
de Query
❒ mensagem de QueryHit
enviada no caminho reverso
ry
e
it
Qu
H
ry
e
Qu
File transfer:
HTTP
Query
QueryHit
Qu
ery
Query
QueryHit
Escalabilidade:
Limitada pelo esquema
de inundação
2: Camada de Aplicação
Qu
e
ry
84
Gnutella: associação do Peer
Ao associar-se, o peer Alice precisa encontrar
um outro peer Gnutella na rede: utiliza a lista
de candidatos a “peers”
2. Alice tenta, sequencialmente, conexões TCP com
os candidatos “peers” até o “set up” com Bob
3. Flooding: Alice envia mensagem de Ping para
Bob; Bob encaminha a mensagem para os seus
vizinhos overlay.
1.
❒
Pares ao receberem a mensagem Ping de Alice respondem com
mensagem Pong
Alice recebe várias mensagens do tipo Pong e
pode, portanto, estabelecer conexões
TCP adicionais
Desassociação de um Peer: veja a lista de
exercícios!
4.
2: Camada de Aplicação
85
Overlay Hierárquico
•
•
Situa-se entre a indexação
centralizada e a abordagem
baseada em inundação
Cada peer é um líder de grupo
ou é atribuído a um líder de
grupo.


•
Conexão TCP entre o peer e o
seu líder de grupo.
Conexões TCP entre alguns
pares de líderes de grupo.
Líder de grupo pesquisa o
conteúdo no seus liderados
Peer comum
Peer líder de grupo
Relações de vizinhança na rede overlay
2: Camada de Aplicação
86
P2P Estudo de caso: Skype
Clientes Skype (SC)
• P2P (pc-to-pc, pc-
to-phone, phone-topc) Voice-Over-IP
Skype
(VoIP)
Servidor de login

também IM
Super nó
(SN)
• Protocolo proprietário
(algumas pistas
obtidas via
engenharia reversa)
• Overlay hierárquico
2: Camada de Aplicação
87
Skype: Realizando uma chamada
•
Usuário inicia o Skype
SC registra-se no SN
•

Lista de SNs de bootstrap
Skype
login server
•
SC realiza o login
(authenticate)
•
Call: SC contacta o SN e fornece
o ID do destino

•
SN contacta outros SNs
(protocolo desconhecido, talvez
por inundação) para encontrar o
addr do destino; retorna o addr
para o SC
SC contacta diretamente o destino via TCP
2: Camada de Aplicação
88
Estudo de Caso P2P: BitTorrent
• Distribuição de arquivo P2P
tracker: registra os peers
participantes de um torrent
torrent: grupo de
peers que estão
trocando pedaços
de um arquivo
Obtém a
lista de peers
Negociando
partes do
arquivo
peer
2: Camada de Aplicação
89
BitTorrent (1)
•
•
•
•
•
O arquivo é divido em pedaços (chunks) de 256KB.
Peer ao associar-se a um torrent:
 Não possui “chunks”, mas irá acumulá-los com o tempo
 Registra-se com o “tracker” para obter a lista dos “peers” e
conecta-se ao sub-conjunto dos pares (“neighbors”)
Enquanto faz o download, o peer realiza o upload para outros
pares.
Peers podem ir e vir
Uma vez que o peer possui todo o arquivo, ele pode sair
(egoísta) ou ficar (altruista)
2: Camada de Aplicação
90
BitTorrent (2)
Obtendo Chunks
• Em um certo instante,
diferentes peers possuem
diferentes subconjuntos de
chunks
• Periodicamente, um peer
(Alice) pergunta a cada
vizinho pela lista dos
chunks que ele possui.
• Alice envia uma solicitação
para as partes que ela não
possui
 Raramente ocorre de ser
o primeiro!
2: Camada de Aplicação
Enviando Chunks: tit-for-tat
• Alice envia chunks para 4
vizinhos que estão, atualmente,
enviando chunks para ela na
taxa mais elevada
 Reavalia os 4 tops a cada 10
segundos
• A cada 30 segundos: seleciona
aleatoriamente um outro peer,
para o qual começa a enviar
chunks
 O novo peer pode fazer
parte dos top 4
91
Comparando as arquiteturas ClienteServidor e P2P
Questão : Quanto tempo para distribuir um arquivo
inicialmente em um servidor para N outros
computadores?
Servidor
F, tamanho
do arquivo
us
uN
dN
2: Camada de Aplicação
u1
d1
u2
d2
Rede (possui abundância
de banda)
us: banda de upload
do servidor
ui: banda de upload
do peer cliente i
di: banda de
download do peer
cliente i
92
Cliente-servidor: tempo de distribuição do
arquivo
Server
• O servidor envia N
F
cópias:

Tempo: NF/us
us
uN
• Cliente i gasta F/di
de tempo para
download
dN
Tempo para distribuir F
para N clientes usando
o modelo cliente-servidor
u1 d1 u2
d2
Network (with
abundant bandwidth)
= dcs = max { NF/us, F/min(di) }
i
Cresce linearmente com N
2: Camada de Aplicação
93
P2P: tempo de distribuição do arquivo
Servidor
•
•
•
•
Servidor precisa enviar uma
cópia de F: tempo de F/us
F
cliente i gasta o tempo F/di
para download
NF bits no total devem ser
recebidos (downloaded)
us
uN
dN
u1 d1 u2
d2
Rede (com abundância
de banda)
Maior taxa de upload possível (assumindo que
todos os nós enviam pedaços do arquivo para
algum peer): us +
ui
Σ
i=1,N
Σ
ui }
i=1,N
dP2P = max { F/us, F/min(di) , NF/(us +
i
2: Camada de Aplicação
94
Comparando as arquiteturas ClienteServidor e P2P
Tempo Mínimo de Distribuição
3.5
P2P
Cliente-Servidor
3
2.5
2
1.5
1
0.5
0
0
5
10
15
20
25
30
35
N
2: Camada de Aplicação
95
Distributed Hash Table (DHT)
• DHT = base de dados distribuída P2P
• A base de dados possui tuplas (chave,valor);
 chave: cpf; valor: nome de alguém
 chave: nome de música; valor: endereço IP
• Peers consultam o BD com uma chave
 BD retorna valor(es) que casam com a chave
• Peers também podem inserir tuplas (chave,
valor)
2: Camada de Aplicação
96
Identificadores na DHT
• Atribui um identificador inteiro para cada peer
no intervalo [0,2n-1].

Cada identificador é representado por n bits.
• Requer que cada chave seja um inteiro no mesmo
intervalo.
• Para obter a chave, fazer o hash da chave
original.
ex, chave = h(“Led Zeppelin IV”)
 Esta é a razão do nome distributed “hash” table

2: Camada de Aplicação
97
Como atribuir chaves aos peers?
• Questão central:
 Atribuir as tuplas (chave, valor) aos peers.
• Regra: atribua a chave ao peer que possui o
ID mais próximo do ID.
• Convenção adotada: mais próximo
corresponde ao sucessor imediato ao valor
da chave.
• Ex: n=4; peers: 1,3,4,5,8,10,12,14;
chave = 13, então o sucessor é o peer = 14
 chave = 15, então o sucessor é o peer = 1

2: Camada de Aplicação
98
DHT Circular (1)
1
3
15
4
12
5
10
8
• Cada peer é ciente somente do sucessor e do
predecessor imediatos.
• “Exemplo de uma Rede Overlay”
2: Camada de Aplicação
99
DHT Circular (2)
O(N) mensagens na
média para resolver
uma consulta (query)
quando existem N
1111
peers
Quem é o responsável
0001
Sou eu!
pela chave 1110
0011
1110
0100
1110
1110
1100
1110
1010
2: Camada de Aplicação
?
1110
0101
1110
1000
100
DHT Circular com Atalhos
1
Quem é o
responsável pela
chave 1110?
3
15
4
12
10
5
8
Cada peer conhece os endereços IP do sucessor e do
predecessor, assim como, alguns atalhos.
• Reduz o número de mensagens necessárias.
• Normalmente adota-se atalhos para O(log N) vizinhos,
O(log N) mensagens no caso de uma query
•
2: Camada de Aplicação
101
Dinâmica dos Peers
1
• Para gerenciar a dinâmica dos peers,
3
15
4
12
5
10
requere-se que cada peer conheça o
endereço IP dos seus 2 sucessores.
• Cada peer faz um ping periodicamente para os seus dois sucessores
para verificar se ambos ainda estão
vivos.
8
Peer 5 falha
• Peer 4 deteta; faz o 8 o seu sucessor imediato; pergunta
ao peer 8 quem é o seu sucessor imediato; torna o sucessor
imediato de 8 seu segundo sucessor.
• O que acontece se um peer 13 associa-se à rede?
•
2: Camada de Aplicação
102
Capítulo 2: Camada de Aplicação
• 2.1 Princípios das aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Aplicações P2P
• 2.7 Programação de Socket com TCP
• 2.8 Programação de Socket com UDP
2: Camada de Aplicação
103
Programação via Socket
Objetivo: aprender como desenvolver aplicações
cliente/servidor que se comunicam via socket
API de socket
•
•
•
•
Introduzida no Unix FSD4.1,
1981
Criada, utilizada e encerrada
de forma explícita pela
aplicação
Paradigma cliente/servidor
Dois tipos de serviços de
transporte oferecidos pela
API de socket:
 Datagrama não-confiável
 Confiável e orientada ao
byte
2: Camada de Aplicação
socket
Trata-se de uma interface
local ao host, criada pela
aplicação e controlada pelo
SO (“porta”) através da qual
processos de aplicação podem
enviar e receber mensagens
de/para outro processo de
aplicação
104
Programação de socket via TCP
Socket: pode ser visto como uma porta entre o
processo de aplicação e o protocolo de
transporte fim-a-fim (UCP ou TCP)
Serviço TCP: transferência confiável de bytes de
um processo para outro
Controlado pelo
programador
Controlado pelo
SO
processo
socket
TCP com
buffers,
variáveis
host ou
servidor
2: Camada de Aplicação
processo
internet
socket
TCP com
buffers,
variáveis
Controlado pelo
programador
Controlado pelo
SO
host ou
servidor
105
Programação de socket com TCP
Cliente deve contactar o servidor
• Primeiramente, o processo
servidor precisa estar
executando
• O servidor precisa ter criado o
socket (porta) que receberá o
contacto do cliente
•
Quando contactado pelo cliente,
o servidor TCP cria um novo
socket para o processo servidor
comunicar-se com o cliente
 Permite que o servidor
converse com múltiplos
clientes
 O número da porta de origem
serve para distinguir os
clientes (mais no cap. 3)
Cliente contacta o servidor via:
• Criação de um socket TCP local
ao cliente
• Especificação do endereço IP e
Ponto de vista da aplicação
do número da porta associados
O TCP provê uma transferência
ao processo servidor
confiável e ordenada de bytes
• Quando cliente cria o socket: o
(“pipe”) entre o cliente e o servidor
cliente TCP estabelece uma
conexão com o servidor TCP
2: Camada de Aplicação
106
Interação cliente/servidor via socket:
TCP
Servidor
(executando no hostid)
Cliente
cria socket,
porta=x, para receber
as requisições:
welcomeSocket =
ServerSocket()
Espera um pedido
Setup
de conexão
connectionSocket =
welcomeSocket.accept()
Lê a requisição do
connectionSocket
Responde para
connectionSocket
encerra
connectionSocket
2: Camada de Aplicação
TCP
da conexão
Cria socket e conecta ao
hostid, porta=x
clientSocket =
Socket()
Envia requisição via
clientSocket
Lê resposta de
clientSocket
encerra
clientSocket
107
Stream: jargão
• um stream é uma
input
stream
output
stream
input
stream
client
client TCP
socket
para a rede
2: Camada de Aplicação
inFromServer
Processo cliente
outToServer
sequência de bytes
que flui para/de um
processo.
• um stream de entrada
é associado a alguma
fonte de entrada para
o processo, ex.,
teclado ou socket.
• Um stream de saída é
associado a uma saída,
ex., monitor ou socket
monitor
inFromUser
teclado
da rede
108
Programação de socket com TCP
Exemplo de aplicação cliente-servidor:
1) Cliente lê linha da entrada (input) padrão
(inFromUser stream) e envia para o servidor via
socket (outToServer stream)
2) Servidor lê a linha via socket
3) Servidor converte a linha para maiúscula e envia de
volta para o cliente
4) Cliente lê a linha modificada via socket
(inFromServer stream) e imprime
2: Camada de Aplicação
109
Exemplo: Cliente Java (TCP)
import java.io.*;
import java.net.*;
class TCPClient {
public static void main(String argv[]) throws Exception
{
String sentence;
String modifiedSentence;
Cria fluxo (stream)
de entrada
Cria socket do
cliente e conecta
ao servidor
Cria fluxo de saída
associado ao socket
2: Camada de Aplicação
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket("hostname", 6789);
DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());
110
Exemplo: Cliente Java (TCP), cont.
Cria fluxo de
entrada
associado ao socket
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
sentence = inFromUser.readLine();
Envia linha para o
servidor
outToServer.writeBytes(sentence + '\n');
modifiedSentence = inFromServer.readLine();
Lê linha enviada
pelo servidor
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
2: Camada de Aplicação
111
Exemplo: servidor Java (TCP)
import java.io.*;
import java.net.*;
class TCPServer {
Cria socket de
recepção na porta
6789
Espera no socket
de recepção um
contacto de cliente
Cria um fluxo
de entrada associado
ao socket
2: Camada de Aplicação
public static void main(String argv[]) throws Exception
{
String clientSentence;
String capitalizedSentence;
ServerSocket welcomeSocket = new ServerSocket(6789);
while(true) {
Socket connectionSocket = welcomeSocket.accept();
BufferedReader inFromClient =
new BufferedReader(new
InputStreamReader(connectionSocket.getInputStream()));
112
Exemplo: Servidor Java (TCP), cont.
Cria fluxo de
saída associado
ao socket
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
Lê linha
Recebida no socket
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + '\n';
Escreve linha
no socket
outToClient.writeBytes(capitalizedSentence);
}
}
}
2: Camada de Aplicação
Final do loop do while; passa a
esperar por uma nova conexão de cliente
113
TCP: Observações e Questões
• O Servidor possui dois tipos de sockets:
 ServerSocket e Socket
• Quando o cliente “bate na porta” do
serverSocket, o Servidor cria o
connectionSocket e completa a conexão TCP.
• O IP destino e a porta não são explicitamente
anexados ao segmento.
• Múltiplos clientes podem acessar o servidor?
2: Camada de Aplicação
114
114
Capítulo 2: Camada de Aplicação
• 2.1 Princípios das aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio Eletrônico
 SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Aplicações P2P
• 2.7 Programação de Socket com TCP
• 2.8 Programação de Socket com UDP
2: Camada de Aplicação
115
Programação de Socket com UDP
UDP: não existe conexão
entre cliente e servidor
• sem handshaking
• A origem associa
ponto de vista da aplicação
explicitamente um
endereço IP de destino e
UDP provê uma transferência
uma porta de destino a
de bytes não confiável
cada pacote
(“datagramas”) entre o cliente
• O servidor deve extrair o
e o servidor
endereço IP e a porta de
origem do pacote recebido
UDP: o dado transmitido
pode ser recebido fora de
ordem ou perdido
2: Camada de Aplicação
116
Interação Cliente/Servidor via socket
UDP
Servidor
(executando no hostid)
cria socket,
porta=x, para recebimento
da requisição:
serverSocket =
DatagramSocket()
Lê requisição de
serverSocket
Responde via
serverSocket
especificando
o endereço do host do
cliente e o número da porta
2: Camada de Aplicação
Cliente
cria socket,
clientSocket =
DatagramSocket()
Cria datagrama de requisição
contendo (endereço hostid e porta=x)
e envia através de clientSocket
Lê a resposta de
clientSocket
encerra
clientSocket
117
Exemplo: cliente Java (UDP)
Client
process
Saída: envia pacote
(lembrar que oTCP
envia fluxo de
bytes)
UDP
packet
receivePacket
Entrada: recebe
sendPacket
Processo
input
stream
monitor
inFromUser
teclado
pacotes (lembrar
que o TCP recebe
fluxo de bytes)
UDP
packet
clientSocket
client UDP
socket
para a rede
2: Camada de Aplicação
UDP
socket
da rede
118
Exemplo: cliente Java (UDP)
import java.io.*;
import java.net.*;
Cria fluxo de
entrada
Cria socket do
cliente
Traduz o nome do
host para o
endereço IP via
DNS
class UDPClient {
public static void main(String args[]) throws Exception
{
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
DatagramSocket clientSocket = new DatagramSocket();
InetAddress IPAddress = InetAddress.getByName("hostname");
byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];
String sentence = inFromUser.readLine();
sendData = sentence.getBytes();
2: Camada de Aplicação
119
Example: Java client (UDP), cont.
Cria o datagrama
contendo o dado,
tamanho, end. IP e
porta
Envia o datagrama
para o servidor
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
clientSocket.send(sendPacket);
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
Lê o datagrama
do servidor
clientSocket.receive(receivePacket);
String modifiedSentence =
new String(receivePacket.getData());
System.out.println("FROM SERVER:" + modifiedSentence);
clientSocket.close();
}
}
2: Camada de Aplicação
120
Exemplo: servidor Java (UDP)
import java.io.*;
import java.net.*;
Cria o
datagrama socket
na porta 9876
class UDPServer {
public static void main(String args[]) throws Exception
{
DatagramSocket serverSocket = new DatagramSocket(9876);
byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];
while(true)
{
Cria o espaço para
receber o datagrama
Recebe o
datagrama
2: Camada de Aplicação
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
121
Exemplo: servidor Java (UDP), cont
String sentence = new String(receivePacket.getData());
Obtém o end. IP
# da porta da
origem
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
Cria datagrama
para enviar ao
cliente
Escreve o
datagrama no
Socket de saída
}
2: Camada de Aplicação
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress,
port);
serverSocket.send(sendPacket);
}
}
Fim do loop do while e volta a
esperar um outro datagrama
122
Capítulo 2: resumo
O estudo das aplicações de rede está completo!
• Arquiteturas de aplicação
 Cliente-servidor
 P2P
 híbrida
• Requisitos do serviço de
aplicação:

confiabilidade, banda, atraso
• Protocolos específicos:
 HTTP
 FTP
 SMTP, POP, IMAP
 DNS
 P2P: BitTorrent, Skype
• Programação via socket
• Modelo de serviço de
transporte na Internet


Confiável e orientado a conexão:
TCP
Não-confiável, datagrama: UDP
2: Camada de Aplicação
123
Capítulo 2: resumo
Importante: conceitos sobre protocolos
•
Troca típica de mensagem
request/reply:


•
cliente requisita informação
ou serviço
Servidor responde com
dados e código de status
Formatos das mensagens:


cabeçalhos: campos que
fornecem informações sobre
os dados
Dado: informação que é
comunicada
2: Camada de Aplicação
Temas importantes:
• Mensagens de controle vs.
mensagens de dado
 in-band, out-of-band
• centralizado vs.
decentralizado
• stateless vs. stateful
• Transferência confiável vs.
não-confiável de mensagem
• “complexidade na borda da
rede”
124