Redes de computadores e a Internet
Capítulo 2
Camada
de
aplicação
2
Camada de aplicação
• 2.1 Princípios de aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio electrônico
• SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Compartilhamento de arquivos P2P
• 2.7 Programação de socket com TCP
• 2.8 Programação de socket com UDP
• 2.9 Construindo um servidor Web
© 2005 by Pearson Education
2-2
2
Comunicação de processos
Processo: programa executando num hospedeiro
• Dentro do mesmo hospedeiro: dois processos se comunicam usando
comunicação interprocesso (definido pelo OS)
• Processos em diferentes hospedeiros se comunicam por meio de troca
de mensagens
• Processo cliente: processo que inicia a comunicação
• Processo servidor: processo que espera para ser contatado
Nota: aplicações com arquiteturas P2P possuem processos cliente
e processos servidor no mesmo hospedeiro
© 2005 by Pearson Education
2 - 11
2
Sockets
• Um processo envia/recebe
mensagens para/de seu socket
• O socket é análogo a uma
porta
• O processo de envio empurra
a mensagem para fora da
porta, confiando na infraestrutura de transporte no
outro lado da porta que leva
a mensagem para o socket no
processo de recepção.
• API (application programming interface): (1) escolha do protocolo de
transporte; (2) determinação de alguns parâmetros (tamanhos máximos
de buffer e segmento, marcação de QoS, etc)
© 2005 by Pearson Education
2 - 12
2
Processos de endereçamento
• Um hospedeiro possui um único endereço IP de 32 bits por interface de
rede e pode hospedar vários processos
•
Endereço IP é exclusivo
• Para endereçar um processo de forma exclusiva usa-se um
identificador que inclui o endereço IP e o número da porta associada
ao processo no hospedeiro
•
Portas conhecidas e reservadas IANA — Internet Assigned Numbers
Authority
• Servidor HTTP: 80
• Servidor de Correio: 25
• (mais detalhes serão mostrados mais tarde)
© 2005 by Pearson Education
2 - 13
2
Aplicação e protocolos de transporte da Internet
Aplicação
e-mail
acesso de terminais remotos
Web
transferência de arquivos
streaming multimídia
servidor de arquivos remoto
telefonia Internet
© 2005 by Pearson Education
Protocolo de
aplicação
Protocolo de
transporte
smtp [RFC 821]
telnet [RFC 854]
http [RFC 2068]
ftp [RFC 959]
RTP ou proprietário
(ex.: RealNetworks)
NSF
RTP ou proprietário
(ex.: Vocaltec)
TCP
TCP
TCP
TCP
TCP ou UDP
2 - 19
TCP ou UDP
tipicamente UDP
2
Camada de aplicação
• 2.1 Princípios de aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio electrônico
• SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Compartilhamento de arquivos P2P
• 2.7 Programação de socket com TCP
• 2.8 Programação de socket com UDP
• 2.9 Construindo um servidor Web
© 2005 by Pearson Education
2 - 20
2
Web e HTTP
Primeiro alguns jargões
• Página Web consiste de objetos
• Objeto pode ser arquivo HTML, imagem JPEG, Java applet, arquivo
de áudio,…
• A página Web consiste de arquivo-HTML base que inclui vários
objetos referenciados
• Cada objeto é endereçado por uma URL (universal resource locator)
• Exemplo de URL:
www.someschool.edu/someDept/pic.gif
Nome do caminho
Nome do hospedeiro
© 2005 by Pearson Education
2 - 21
2
Visão geral do HTTP
HTTP: hypertext transfer protocol
• Protocolo da camada de aplicação
da Web
• Modelo cliente/servidor
• Cliente: browser que solicita,
recebe e apresenta objetos da Web
• Servidor: envia objetos em
resposta a pedidos
• HTTP 1.0: RFC 1945
• HTTP 1.1: RFC 2616, jun/1999
(obsoleta RFC 2068),
atualizada pela RFC 2817 (uso de
transporte seguro TLS com HTTP)
© 2005 by Pearson Education
2 - 22
2
Visão geral do HTTP
Utiliza TCP:
• Cliente inicia conexão TCP (cria socket) para o servidor na porta 80
• Servidor aceita uma conexão TCP do cliente
• Mensagens HTTP (mensagens do protocolo de camada de aplicação) são
trocadas entre o browser (cliente HTTP) e o servidor Web (servidor HTTP)
• A conexão TCP é fechada
HTTP é “stateless”
• O servidor não mantém informação sobre os pedidos passados dos clientes
Protocolos que mantêm informações de “estado” são complexos!
• Histórico do passado (estado) deve ser mantido
• Se o servidor/cliente quebra, suas visões de “estado” podem ser
inconsistentes, devendo ser reconciliadas
© 2005 by Pearson Education
2 - 23
2
Conexões HTTP
HTTP não persistente
• No máximo, um objeto é enviado sobre uma conexão TCP
• O HTTP/1.0 utiliza HTTP não persistente
HTTP persistente
• Conexão é mantida e permite que múltiplos objetos possam ser enviados
• TCP entre o cliente e o servidor
• O HTTP/1.1 utiliza conexões persistentes em seu modo padrão
© 2005 by Pearson Education
2 - 24
2
HTTP não persistente
(contém texto,referências a 10 imagens jpeg)
www.someSchool.edu/someDepartment/home.index
Usuário entra com a URL:
1a. Cliente HTTP inicia conexão
TCP ao servidor HTTP
(processo) em
www.someSchool.edu. Porta
80 é a default para o servidor
HTTP.
2. Cliente HTTP envia HTTP request
message (contendo a URL) para
o socket da conexão TCP
Tempo
© 2005 by Pearson Education
2 - 25
1b. Servidor HTTP no hospedeiro
www.someSchool.edu
esperando pela conexão TCP na
porta 80. “Aceita” conexão,
notificando o cliente
3. Servidor HTTP recebe mensagem
de pedido, forma response
message contendo o objeto
solicitado
(someDepartment/home.index),
envia mensagem para o socket
2
HTTP não persistente
4. Servidor HTTP fecha conexão
TCP.
Tempo
5. Cliente HTTP recebe
mensagem de resposta
contendo o arquivo html,
apresenta o conteúdo html.
Analisando o arquivo html,
encontra 10 objetos jpeg
referenciados
6. Passos 1-5 são repetidos para
cada um dos 10 objetos jpeg.
© 2005 by Pearson Education
2 - 26
2
Modelagem do tempo de resposta
Definição de RRT: tempo para
enviar um pequeno pacote
que vai do cliente para o
servidor e retorna.
Tempo de resposta:
• Um RTT para iniciar (abrir)
a conenexão TCP
• Um RTT para requisição
HTTP e primeiros bytes da
resposta HTTP para
retorno
• Tempo de transmissão de
arquivo
Total = 2RTT+ tempo de transmissão do arquivo
© 2005 by Pearson Education
2 - 27
2
HTTP persistente
Características do HTTP não-persistente:
• Requer 2 RTTs por objeto
• SO deve manipular e alocar recursos do hospedeiro para cada conexão TCP
Mas os browsers freqüentemente abrem conexões TCP paralelas para
buscar objetos referenciados
HTTP persistente
• Servidor deixa a conexão aberta após enviar uma resposta
• Mensagens HTTP subseqüentes entre o mesmo cliente/servidor são
enviadas pela conexão
Persistente sem pipelining (paralelismo):
• O cliente emite novas requisições apenas quando a resposta anterior for
recebida
• Um RTT para cada objeto referenciado
Persistente com pipelining (paralelismo):
• Padrão no HTTP/1.1
• O cliente envia requisições assim que encontra um objeto referenciado
• Tão pequeno como um RTT para todos os objetos referenciados
© 2005 by Pearson Education
2 - 28
2
Mensagem HTTP request
• HTTP request message:
• ASCII (formato legível para humanos)
Linha de requisição
(método, URL, versão)
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Linhas de Connection: close
cabeçalho User-agent: Mozilla/4.0
Accept: text/html,image/gif,image/jpeg
Accept-language:fr
Carriage return,
line feed
(extra carriage return, line feed)
indica fim da mensagem
© 2005 by Pearson Education
2 - 29
2
Mensagem HTTP request: formato geral
© 2005 by Pearson Education
2 - 30
2
Tipos de métodos
HTTP/1.0
• GET
• Requisita objeto
• POST
• Fornece dados de entrada para localizar página
• HEAD
• Pede para o servidor deixar o objeto requisitado fora da resposta
HTTP/1.1
• GET, POST, HEAD
• PUT
• Envia o arquivo no corpo da entidade para o caminho especificado
no campo de URL
• DELETE
• Apaga o arquivo especificado no campo de URL
© 2005 by Pearson Education
2 - 31
2
Entrada de formulário
Método Post:
• Apresenta ao servidor os dados de entrada de formulário no corpo da
entidade, o que influencia o objeto a ser retornado
Método URL:
• Utiliza o método GET
• A entrada é enviada no campo de URL da linha de requisição:
www.somesite.com/animalsearch?monkeys&banana
© 2005 by Pearson Education
2 - 32
2
Mensagem HTTP response
Linha de status
(protocolo
código de status
frase de status)
Linhas de
cabeçalho
HTTP/1.0 200 OK
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
Dados, ex.:
arquivo html
© 2005 by Pearson Education
2 - 33
2
Códigos de status das respostas
Na primeira linha da mensagem de resposta servidor cliente.
Alguns exemplos de códigos:
200 OK
• Requisição bem-sucedida, objeto requisitado a seguir nesta mensagem
301 Moved permanently
• Objeto requisitado foi movido, nova localização especificada a seguir nesta
mensagem (Location:)
400 Bad request
• Mensagem de requisição não compreendida pelo servidor
404 Not Found
• Documento requisitado não encontrado neste servidor
505 HTTP version not supported
© 2005 by Pearson Education
2 - 34
2
Estado usuário-servidor: cookies
A maioria dos grandes Web sites utilizam cookies para monitorar os seus
usuários (RFC 2109)
Quatro componentes:
1) Linha de cabeçalho do cookie na mensagem HTTP response
2) Linha de cabeçalho de cookie na mensagem HTTP request
3) Arquivo de cookie mantido no hospedeiro do usuário e manipulado pelo
browser do usuário
4) Banco de dados backend no Web site
Exemplo:
• Susan acessa a Internet sempre do mesmo PC
• Ela visita um site específico de e-commerce pela primeira vez
• Quando a requisição HTTP inicial chega ao site, este cria um ID único e
uma entrada no banco de dados backend para este ID
© 2005 by Pearson Education
2 - 36
Servidor
Cliente
Cookie file
amazon: 1678
ebay: 8734
usual HTTP request msg
usual HTTP response +
Set-cookie: 1678
usual HTTP request msg
cookie: 1678
especificação
do cookie
usual HTTP response msg
Uma semana depois:
Cookie file
amazon: 1678
ebay: 8734
© 2005 by Pearson Education
usual HTTP request msg
cookie: 1678
usual HTTP response msg
2 - 37
sso
ace
o
Cookie file
ebay: 8734
en
de trad
servidor
da a n
do o
cria o ID 1678
s b ba
a c nc
para o usuário
ke o
nd
ac
es
s
2
Cookies: mantendo “estado”
especificação
do cookie
2
Cookies
O que os cookies podem trazer:
• Autorização
• Cartões de compra
• Recomendações
• Estado de sessão do usuário (Web e-mail)
ASIDE
Cookies e privacidade:
• Cookies permitem que sites saibam muito sobre você
• Você pode fornecer nome e e-mail para os sites
• Mecanismos de busca usam redirecionamento e cookies para saberem mais
sobre você
• Companhias de propaganda obtêm informações por meio dos sites
© 2005 by Pearson Education
2 - 38
2
Web caches (proxy server)
Objetivo: atender o cliente sem envolver o servidor Web
originador da informação
• 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
© 2005 by Pearson Education
2 - 39
2
Mais sobre Web caching
• O cache atua tanto no servidor como no cliente
• Tipicamente, o cache é instalado pelo ISP (universidade, companhia,
ISP residencial)
Por que Web caching?
• 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)
© 2005 by Pearson Education
2 - 40
2
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 do roteador institucional para
ir a qualquer servidor de origem e
retornar ao roteador = 2 s
Conseqüências:
• Utilização da LAN = 15%
• Utilização do link de acesso = 100%
• Atraso total = atraso da Internet +
atraso de acesso + atraso da LAN = 2
segundos + minutos + milissegundos
© 2005 by Pearson Education
2 - 41
2
Exemplo de caching
Solução possível
• Aumentar a taxa do enlace de
acesso, para 10 Mbps p.ex.
Conseqüências
• Utilização da LAN = 15%
• Utilização do enlace de acesso
= 15%
• Atraso total = atraso da
Internet + atraso de acesso +
atraso da LAN = 2 segundos +
? ms + ? ms
• Freqüentemente é um
upgrade caro
© 2005 by Pearson Education
10 Mbps
2 - 42
2
Exemplo de caching
Instalação do cache
• Suponha taxa de acertos de 40%
Conseqüência
• 40% das requisições serão satisfeitas
quase que imediatamente
• 60% das requisições serão satisfeitas pelo
servidor de origem
• Utilização do enlace de acesso reduzida
para 60%, resultando em atrasos
insignificantes (como 10 ms)
• Média de atraso total = atraso da
Internet + atraso de acesso + atraso da
LAN = (0.6)*(2.01) segundos + (0,4) *ms
< 1,4 segundos
© 2005 by Pearson Education
2 - 43
2
GET condicional
Servidor
Cliente
• Razão: não enviar objeto se
a versão que o cliente já
possui está atualizada.
HTTP request msg
If-modified-since:
<date>
• Cliente: especifica data da
versão armazenada no
pedido HTTP
• If-modified-since: <date>
HTTP response
HTTP/1.0
304 Not Modified
• Servidor: resposta não
contém objeto se a cópia é
atualizada:
HTTP/1.0 304 Not Modified
HTTP request msg
If-modified-since:
<date>
HTTP response
HTTP/1.1 200 OK
<data>
© 2005 by Pearson Education
2 - 44
Objeto
não
modificado
Objeto
modificado
2
Camada de aplicação
• 2.1 Princípios de aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio electrônico
• SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Compartilhamento de arquivos P2P
• 2.7 Programação de socket com TCP
• 2.8 Programação de socket com UDP
• 2.9 Construindo um servidor Web
© 2005 by Pearson Education
2 - 45
2
FTP: o protocolo de transferência de arquivos
• Transferência de arquivos envolvendo o computador remoto
• Modelo cliente servidor
• Cliente: lado que inicia a transferência (para o recebimento ou envio de arquivos)
• Servidor: hospedeiro remoto
• FTP: RFC 959
• Extensões e atualizações: RFC2228, RFC2640, RFC2773, RFC3659
• FTP servidor: porta 21
© 2005 by Pearson Education
2 - 46
2
FTP: controle separado, conexões de dados
• Ações do cliente FTP
• Contata o servidor FTP na porta TCP/21 para abrir conexão de controle
• Autenticação do cliente ocorre pela conexão de controle
• Seleciona o diretório remoto enviando comandos pela conexão de controle
• Ações do servidor FTP
• Quando recebe um comando para uma transferência de arquivo, 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
© 2005 by Pearson Education
2 - 47
2
FTP comandos, respostas
Exemplos de comandos
• Enviados como 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
125
425
452
Username OK, password required
data connection already open; transfer starting
Can’t open data connection
Error writing file
© 2005 by Pearson Education
2 - 48
2
Extensões do FTP
• Extensions to FTP (RFC 3659, Mar/07)
–
–
–
–
Listagem de diretórios remotos em formato específico
Reinicialização de interrupção de transferência de dados em modo STREAM
Uso de códigos de caracteres diferentes de ASCII
Define uma estrutura opcional de armazenamento virtual de arquivos (NVFS)
• Novos comandos
– REST (Restart)
– SIZE
• Número de bytes que seriam transferidos no formato atual do arquivo
– MDTM (MODIFICATION TIME)
• Saber quando arquivo no NVFS (network virtual file system) foi modificado,
para identificar segurança ao recomeçar transferências interrompidas, por
exemplo.
– MLST e MLSD (Machine Listing )
• Lista diretórios
© 2005 by Pearson Education
2 - 49
2
Camada de aplicação
• 2.1 Princípios de aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio electrônico
• SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Compartilhamento de arquivos P2P
• 2.7 Programação de socket com TCP
• 2.8 Programação de socket com UDP
• 2.9 Construindo um servidor Web
© 2005 by Pearson Education
2 - 50
2
Correio eletrônico
Três componentes principais:
• Agentes de usuário
• Servidores de correio
• Simple mail transfer protocol: SMTP
Agente de usuário
•“leitor de correio”
• Composição, edição, leitura de
mensagens de correio
• Ex.: Eudora, Outlook, elm, Netscape
Messenger
• Mensagens de entrada e de saída são
armazenadas no servidor
© 2005 by Pearson Education
2 - 51
2
Correio eletrônico: servidores de correio
Servidores de correio
• Caixa postal contém mensagens
que chegaram (ainda não lidas)
para o usuário
• Fila de mensagens contém as
mensagens de correio a serem
enviadas
Protocolo SMTP permite aos
servidores de correio trocarem
mensagens entre si
• Cliente: servidor de correio
que envia
• Servidor: servidor de
correio que recebe
© 2005 by Pearson Education
2 - 52
2
Correio eletrônico: SMTP [RFC 821]
• Usa TCP/porta 25 persistente para transferência confiável de
mensagens de correio do cliente ao servidor
• Transferência direta: servidor que envia para o servidor que recebe
• Três fases de transferência
• Handshaking (apresentação)
• Transferência de mensagens
• Fechamento
• Interação comando/resposta
• Comandos: texto ASCII
• Resposta: código de status e frase
• Mensagens devem ser formatadas em código ASCII de 7 bits
© 2005 by Pearson Education
2 - 53
2
Cenário: Alice envia mensagem para Bob
1) Alice usa o agente de usuário (UA) para compor a mensagem “para”
[email protected]
2) O agente de usuário dela envia a mensagem para o seu servidor de correio; a
mensagem é colocada na fila de mensagens.
3) O lado cliente do SMTP abre uma conexão TCP com o servidor de correio do Bob.
4) O cliente SMTP envia a mensagem de Alice pela conexão TCP.
5) O servidor de correio de Bob coloca a mensagem na caixa de correio de Bob.
6) Bob invoca seu agente de usuário para ler a mensagem.
© 2005 by Pearson Education
2 - 54
2
Exemplo de 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
© 2005 by Pearson Education
2 - 55
2
SMTP: palavras finais
• SMTP usa conexões persistentes
• SMTP exige que as mensagens (cabeçalho e corpo) estejam em ASCII de 7 bits
• Servidor SMTP usa CRLF.CRLF para indicar o final da mensagem
Comparação com HTTP:
• HTTP permite receber (pull) enquanto E-mail só envia (push)
• Ambos usam comandos e respostas em ASCII, interação comando/resposta e
códigos de status
• HTTP: cada objeto encapsulado na sua própria mensagem de resposta
• SMTP: múltiplos objetos são enviados numa mensagem multiparte
© 2005 by Pearson Education
2 - 57
2
Formato da mensagem de correio
header
SMTP: protocolo para trocar
mensagens de e-mail
RFC 822: padrão para mensagens
do tipo texto:
• linhas de cabeçalho, ex.:
– To:
– From:
– Subject:
diferente dos comandos
HTTP
• corpo
– a “mensagem”, somente
com caracteres ASCII
© 2005 by Pearson Education
body
2 - 58
linha
em branco
2
Formato das mensagens: extensões multimídia
• MIME: multimedia mail extension, RFC 2045, 2056
• Linhas adicionais no cabeçalho declaram o tipo de conteúdo MIME
Versão da MIME
Método usado para
codificar dados em ASCII
Dados multimídia
tipo, subtipo,
declaração de parâmetro
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
Dados codificados
© 2005 by Pearson Education
2 - 59
2
Protocolos de acesso ao correio
• SMTP: entrega e armazena no servidor do destino
• Protocolo de acesso: recupera mensagens do servidor
• POP: Post Office Protocol [RFC 1939]
• Autorização em claro (agente <-->servidor) e download
• IMAP: Internet Mail Access Protocol [RFC 3501]
• Maiores recursos (mais complexo)
• Manipulação de mensagens armazenadas no servidor
• HTTP: Hotmail , Yahoo! Mail etc.
© 2005 by Pearson Education
2 - 60
2
Protocolo POP3
Cliente abre conexão TCP/110 ao
servidor
Fase de autorização
• comandos do cliente:
• user: declara nome do usuário
• pass: password (em claro)
respostas do servidor
• +OK
• -ERR
Fase de transação
Comandos do cliente:
• list: lista mensagens e
tamanhos
• retr: recupera msg pelo número
• dele: marca para apagar
• quit
Fase de update
Deleta msgs no servidor após quit
© 2005 by Pearson Education
2 - 61
S: +OK POP3 server ready
C: user alice
S: +OK
C: pass hungry
S: +OK user successfully
logged on
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 2 contents>
.
dele 2
quit
+OK POP3 server signing off
2
POP3 (mais) e IMAP
Mais sobre POP3
•O exemplo anterior usa o modo ler-e-apagar (“download-and-delete”)
•
Bob não pode reler o e-mail se ele trocar o cliente
•Poderia usar o modo ler-e-guardar (“download-and-keep”)
•
Permite manter cópias das mensagens em clientes diferentes
• POP3 é stateless através das sessões (simplifica implementação)
IMAP
• Mantém todas as mensagens em um lugar: o servidor
• Permite que o usuário organize as mensagens em pastas
• Permite que o usuário baixe partes de uma mensagem multiparte
•
Útil quando opera sobre conexões lentas
• IMAP mantém o estado do usuário através das sessões
• Nomes em pastas e mapeamentos entre as identificações das
mensagens (ID) e as pastas
© 2005 by Pearson Education
2 - 62
2
Camada de aplicação
• 2.1 Princípios de aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio electrônico
• SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Compartilhamento de arquivos P2P
• 2.7 Programação de socket com TCP
• 2.8 Programação de socket com UDP
• 2.9 Construindo um servidor Web
© 2005 by Pearson Education
2 - 63
2
DNS: Dominain Name System
Pessoas: muitos identificadores:
• RG, nome, passaporte
Internet hospedeiros, roteadores:
• Endereços IP (32 bits) - usados para endereçar datagramas
• “nome”, ex.: gaia.cs.umass.edu - usados por humanos
P.: Como relacionar nomes com endereços IP?
Domain Name System:
• Base de dados distribuída implementada numa hierarquia de muitos
servidores de nomes
• Protocolo de camada de aplicação do hospedeiro
• Roteadores se comunicam com servidores de nomes para resolver nomes
(translação nome/endereço)
• Nota: função interna da Internet, implementada como protocolo da
camada de aplicação
• Complexidade na “borda” da rede
© 2005 by Pearson Education
2 - 64
2
DNS
Serviços do DNS
• Tradução do nome do hospedeiro para o endereço IP
• Hospedeiro aliasing
• Nomes canônicos e alias
mail server aliasing
distribuição de carga
• Servidores Web replicados: estabelece o endereço IP para um nome canônico
Por que não centralizar o DNS?
• Geraria ponto único de falha
• Alto volume de tráfego
• Base centralizada de dados pode estar muito distante do usuário, causando
ineficiência
• Manutenção da base complicada, pois mapeamentos são criados de forma
distribuída
Não é escalável!
© 2005 by Pearson Education
2 - 65
2
Base de dados distribuída, hierárquica
Cliente quer o IP para www.amazon.com; 1a aprox.:
• Cliente consulta um servidor de raiz para encontrar o servidor DNS com
• Cliente consulta o servidor DNS com para obter o servidor DNS com autoridade
para responder pelos mapeamentos do dominio amazon.com
• Cliente consulta o servidor DNS amazon.com para obter o endereço IP para
www.amazon.com
© 2005 by Pearson Education
2 - 66
2
DNS: servidores de nomes raiz
• São contatados pelos servidores de nomes locais quando estes não podem
resolver um nome
• Servidores de nomes raiz:
• Buscam servidores de nomes com autoridade, se o mapeamento do nome
não for conhecido
• Conseguem o mapeamento
• Retornam o mapeamento para o servidor de nomes local
Até 2004, 13 servidores
raiz.
© 2005 by Pearson Education
2 - 67
2
•
•
•
Servidores Raiz
13 nomes de servidores raiz especificados na forma letra.root-servers.net, onde letra varia de A a M.
Seis desses não são servidores únicos, mas vários servidores físicos distribuídos geograficamente
Letra IP address
Nome antigo
Localização do Operador
–
–
–
–
–
–
–
–
–
–
–
–
–
•
ns.internic.net
ns1.isi.edu
c.psi.net
terp.umd.edu
ns.nasa.gov
ns.isc.org
ns.nic.ddn.mil
aos.arl.army.mil
nic.nordu.net
VeriSign
RIPE NCC
ICANN
WIDE Project
VeriSignDulles, Virginia, U.S.BIND
USC-ISIMarina Del Rey, California, U.S.BIND
Cogent Communicationsdistributed using anycastBIND
University of MarylandCollege Park, Maryland, U.S.BIND
NASAMountain View, California, U.S.BIND
ISCdistributed using anycastBIND
Defense Information Systems AgencyColumbus, Ohio, U.S.BIND
U.S. Army Research Lab, Maryland, U.S.NSD
Autonomicadistributed using anycastBIND
distributed using anycastBIND
distributed using anycastNSD
Los Angeles, California, U.S.NSD
distributed using anycastBIND
Não podem ser usados mais nomes devido a limitações de protocolo
–
–
•
A 198.41.0.4
B 192.228.79.201
C 192.33.4.12
D 128.8.10.90
E 192.203.230.10
F 192.5.5.241
G 192.112.36.4
H 128.63.2.53
I 192.36.148.17
J 192.58.128.30
K 193.0.14.129
L 198.32.64.12
M 202.12.27.33
UDP carrega apenas 512 bytes de maneira confiável e um arquivo com mais de 13 nomes de servidores seria maior
que 512 bytes
Os servidores C, F, I, J, K e M agora existem em múltiplas localidades em diferentes continentes usando anúncios
ANYCAST para prover um serviço distribuído.
Para DNS alternativos consulte Alternative DNS root .
© 2005 by Pearson Education
2 - 68
2
Servidores Raiz
• Setembro/2007: 117 servidores raiz, operados por 12 diferentes
organizações
© 2005 by Pearson Education
2 - 69
2
Servidores TLD e com autoridade
Servidores top-level domain (TLD): responsáveis pelos domínios com,
org, net, edu etc e todos os domínios top-level nacionais uk, fr, ca, jp.
Servidores DNS com autoridade (authoritative): hospedam o
mapeamento de nomes para endereço IP dos hospedeiros de uma
organização que podem ser acessados publicamente (ex.: servidor Web
e servidor de correio).
• Podem ser mantidos por uma organização ou provedor de serviços
© 2005 by Pearson Education
2 - 70
2
Servidor de nomes local
• Quando um hospedeiro precisa resolver um
nome/domínio, a pergunta é enviada para seu
servidor DNS local
• Age como um proxy, encaminhando as perguntas para
dentro da hierarquia
• Não pertence estritamente a uma hierarquia
• Cada ISP residencial, companhia ou universidade
possui um, chamado de “servidor de nomes default”
© 2005 by Pearson Education
2 - 71
2
Exemplo
• O hospedeiro em cis.poly.edu quer o
endereço IP para gaia.cs.umass.edu
© 2005 by Pearson Education
2 - 72
2
Consultas recursivas
Consulta recursiva:
• Transfere a tarefa de
resolução do nome para o
servidor de nomes
consultado
• Carga pesada?
recursiva
recursiva
recursiva
Consulta iterativa:
• Servidor contatado
recursiva
responde com o nome de
outro servidor de nomes
para contato
• “eu não sei isto, mas
pergunte a este servidor”
• Normalmente recursiva ao
DNS Local e iterativa aos
outros níveis
© 2005 by Pearson Education
2 - 73
2
DNS: armazenando e atualizando registros
• Uma vez que um servidor de nomes apreende um mapeamento,
ele armazena o mapeamento num registro do tipo cache
• Registros no cache tornam-se obsoletos depois de um certo tempo
• Servidores TLD são tipicamente armazenados em cache nos
servidores de nome locais
Mecanismos de atualização e notificação estão sendo projetados
pelo IETF
• http://www.ietf.org/html.charters/dnsext-charter.html
© 2005 by Pearson Education
2 - 74
2
Registros do DNS
DNS: base de dados distribuída que armazena registros de recursos (RR)
formato dos RR: (name, value, type, ttl)
• Type = A
• name é o nome do hospedeiro
• value é o endereço IP
• Type = CNAME
• name é um “apelido” para algum nome
“canônico” (possui registro A) em value
www.ibm.com é realmente
servereast.backup2.ibm.com
• Type = NS
• name é um domínio (ex.:
foo.com)
• value é o nome do servidor de
nomes com autoridade para
este domínio
• Type = MX
• value é o nome do servidor de correio
associado com name
© 2005 by Pearson Education
2 - 75
2
DNS: protocolo e mensagem
Protocolo DNS: mensagem de consulta e resposta , ambas com o mesmo
formato de mensagem
32 bits
Cabeçalho da msg
• Identificação: 16 bits
(consulta e resposta usam
o mesmo valor)
• Flags:
• Consulta ou resposta
• Recursão desejada
• Recursão disponível
• Resposta é autorizada
© 2005 by Pearson Education
2 - 76
2
Inserindo registros no DNS
• Exemplo: empresa recém-criada “Network Utopia”
• Registrar o nome networkuptopia.com num “registrar” (ex.: Network
Solutions)
• É necessário fornecer ao registrar os nomes e endereços IP dos seus
servidores de nomes autorizados (primário e secundário)
• Registrar insere dois RRs no servidor TLD do domínio com:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
• No servidor com autoridade, inserir um registro Tipo A para
www.networkuptopia.com e um registro Tipo MX para networkutopia.com
• DNS pode ser configurado estaticamente ou através de comando UPDATE
• Como as pessoas obtêm o endereço IP do seu Web site?
• nslookup
© 2005 by Pearson Education
2 - 77
2
Leitura adicional sobre DNS
• Geographic Implications of DNS Infrastructure
Distribution (Cisco Internet Protocol Journal)
– http://www.cisco.com/web/about/ac123/ac147/archived
_issues/ipj_10-1/101_dns-infrastructure.html
© 2005 by Pearson Education
2 - 78
2
Camada de aplicação
• 2.1 Princípios de aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio electrônico
• SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Compartilhamento de arquivos P2P
• 2.7 Programação de socket com TCP
• 2.8 Programação de socket com UDP
• 2.9 Construindo um servidor Web
© 2005 by Pearson Education
2 - 79
2
Compartilhamento de arquivos P2P
Exemplo
• Alice executa a aplicação cliente P2P em seu notebook
• Intermitentemente, conecta-se à Internet; obtém novos endereços IP para
cada conexão
• pede por “Hey Jude”
• a aplicação exibe outros pares que possuem uma cópia de Hey Jude.
• Alice escolhe um dos pares, Bob.
• o arquivo é copiado do PC de Bob para o notebook de Alice: HTTP
• enquanto Alice faz o download, outros usuários fazem upload de Alice.
• o par de Alice é tanto um cliente Web como um servidor Web transiente.
Todos os pares são servidores = altamente escaláveis!
© 2005 by Pearson Education
2 - 80
2
P2P: diretório centralizado
Projeto original “Napster”
1) Quando um parceiro se conecta,
ele informa ao servidor central:
• Endereço IP
• Conteúdo
2) Alice procura por “Hey Jude”
3) Alice requisita o arquivo de Bob
© 2005 by Pearson Education
2 - 81
2
P2P: problemas com diretório centralizado
• Ponto único de falhas
• Gargalo de desempenho
• Infração de copyright
Transferência de arquivo é descentralizada, mas a localização de
conteúdo é altamente centralizado
© 2005 by Pearson Education
2 - 82
2
Query flooding: Gnutella
• Totalmente distribuído, sem servidor central
• Protocolo de domínio público
• Muitos clientes Gnutella implementando o protocolo
Rede de cobertura: gráfico
• Aresta entre parceiros X e Y se há uma conexão TCP entre eles
• Todos os pares ativos e arestas estão na rede de sobreposição
• A aresta não é um enlace físico, mas uma conexão TCP
• Um determinado parceiro será tipicamente conectado a menos de 10
vizinhos na rede de sobreposição
© 2005 by Pearson Education
2 - 83
2
Gnutella: protocolo
• Mensagem de consulta
(query) é enviada pelas
conexões TCP existentes
• Os pares encaminham
a mensagem de consulta
• QueryHit (encontro)
é enviado pelo
caminho reverso
Escalabilidade: flooding de alcance limitado
© 2005 by Pearson Education
2 - 84
2
Gnutella: conectando pares
1. Para se conectar, o parceiro X precisa encontrar algum outro
parceiro na rede Gnutella: utiliza a lista de candidatos
2. X seqüencialmente, tenta fazer conexão TCP com os pares da
lista até estabelecer conexão com Y
3. X envia mensagem de Ping para Y e Y encaminha a mensagem
de Ping aos seus vizinhos
4. Todos os pares que recebem a mensagem de Ping respondem
com mensagens de Pong, incluindo end IP, # de arquivos que
está compartilhando e o total de bytes destes arquivos
5. X recebe várias mensagens de Pong e pode então estabelecer
conexões TCP adicionais aos outros pares que serão vizinhos
© 2005 by Pearson Education
2 - 85
2
Explorando heterogeneidade: KaZaA
• Cada par é um líder de grupo ou
está atribuído a um líder de grupo
• Conexão TCP entre o par e seu
líder de grupo
• Conexões TCP entre alguns
pares de líderes de grupo
• O líder de grupo acompanha o
conteúdo de todos os seus
“discípulos”
© 2005 by Pearson Education
2 - 86
2
KaZaA
• Cada arquivo possui um hash e um descritor
• O cliente envia a consulta de palavra-chave para o seu líder de grupo
• O líder de grupo responde com os encontros (hits):
• Para cada encontro: metadata, hash, endereço IP
• Se o líder de grupo encaminha a consulta para outros líderes de grupo,
eles respondem com os encontros
• O cliente então seleciona os arquivos para download
• Requisições HTTP usando hash como identificador são enviadas aos
pares que contêm o arquivo desejado
© 2005 by Pearson Education
2 - 87
2
Artifícios do KaZaA para desempenho
• Limitações em transferências simultâneas e uso de filas múltiplas,
garantindo um mínimo de banda a cada transferência
• Incentiva prioridades, favorecendo usuários que tenham carregado
mais do que baixado no passado (recompensa)
• Realiza downloads em paralelo, usando cabeçalho “faixa de
bytes” no HTTP (download parcial de arquivo)
© 2005 by Pearson Education
2 - 88
2
Camada de aplicação
• 2.1 Princípios de aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio electrônico
SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Compartilhamento de arquivos P2P
• 2.7 Programação de socket com TCP
• 2.8 Programação de socket com UDP
• 2.9 Construindo um servidor Web
© 2005 by Pearson Education
2 - 89
2
Programação de sockets
Objetivo: aprender a construir aplicações cliente-servidor que se comunicam
usando sockets
Socket API
• Introduzida no BSD4.1 UNIX, 1981
• Explicitamente criados, usados e liberados pelas aplicações
• Paradigma cliente-servidor
• Dois tipos de serviço de transporte via socket API:
• Datagrama não confiável
• Confiável, orientado a cadeias de bytes
SOCKET
Uma interface local, controlada pelo OS, na qual os processos de aplicação
podem tanto enviar quanto receber mensagens de e para outro processo de
aplicação (local ou remoto)
© 2005 by Pearson Education
2 - 90
2
Programação de sockets com TCP
Socket: ponto de comunicação entre o processo de aplicação e o protocolo de
transporte fim-a-fim (UCP or TCP)
Serviço TCP: transferência confiável de bytes de um processo para outro
© 2005 by Pearson Education
2 - 91
2
Programação de sockets com TCP
Cliente deve contatar o servidor
• Processo servidor já deve estar em execução
• Servidor deve ter criado socket (porta) que aceita o contato do cliente
Cliente contata o servidor
• Criando um socket TCP local
• Especificando endereço IP e número da porta do processo servidor
• Quando o cliente cria o socket: cliente TCP estabelece conexão com o
TCP do servidor
Quando contatado pelo cliente, o TCP do servidor cria um novo socket
para o processo servidor comunicar-se com o cliente
• Permite ao servidor conversar com múltiplos clientes
• Conexão TCP identificada pela quádrupla (IP cliente, porta cliente, IP
servidor, porta servidor) (mais no capítulo 3)
Ponto de vista da aplicação
TCP fornece a transferência confiável, em ordem de bytes
(“pipe”) entre o cliente e o servidor
© 2005 by Pearson Education
2 - 92
2
Jargão stream
• Um stream é uma seqüência de caracteres que fluem para dentro ou
para fora de um processo
• Um stream de entrada é agregado a alguma fonte de entrada para o
processo, ex.: teclado ou socket
• Um stream de saída é agregado a uma fonte de saída, ex.: monitor ou
socket
© 2005 by Pearson Education
2 - 93
2
Programação de sockets com TCP
Exemplo de aplicação cliente-servidor:
1) Cliente lê linha da entrada-padrão
do sistema (inFromUser stream),
envia para o servidor via socket
(outToServer stream)
2) Servidor lê linha do socket
3) Servidor converte linha para letras
maiúsculas e envia de volta ao
cliente
4) Cliente lê a linha modificada
através do (inFromServer stream)
Programação de sockets com TCP
© 2005 by Pearson Education
2 - 94
2
Exemplo: cliente Java (TCP)
© 2005 by Pearson Education
2 - 95
2
Interação cliente-servidor TCP
© 2005 by Pearson Education
2 - 96
2
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
stream de entrada
Cria
socket cliente,
conecta ao servidor
Cria
stream de saída
ligado ao socket
© 2005 by Pearson Education
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket("hostname", 6789);
DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());
2 - 97
2
Exemplo: cliente Java (TCP)
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
Cria
stream de entrada
ligado ao socket
sentence = inFromUser.readLine();
Envia linha
para o servidor
outToServer.writeBytes(sentence + '\n');
modifiedSentence = inFromServer.readLine();
Lê linha
do servidor
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
© 2005 by Pearson Education
2 - 98
2
Exemplo: servidor Java (TCP)
import java.io.*;
import java.net.*;
class TCPServer {
Cria
socket de aceitação
na porta 6789
Espera, no socket
de aceitação, por
contato do cliente
Cria stream de
entrada ligado
ao socket
© 2005 by Pearson Education
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()));
2 - 99
2
Exemplo: servidor Java (TCP)
Cria stream de
saída ligado ao
socket
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
Lê linha do
socket
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + '\n';
Escreve linha
para o socket
outToClient.writeBytes(capitalizedSentence);
}
}
}
© 2005 by Pearson Education
Fim do while loop,
retorne e espere por
outra conexão do cliente
2 - 100
2
Camadas de aplicação
• 2.1 Princípios de aplicações de rede
• 2.2 Web e HTTP
• 2.3 FTP
• 2.4 Correio electrônico
• SMTP, POP3, IMAP
• 2.5 DNS
• 2.6 Compartilhamento de arquivos P2P
• 2.7 Programação de socket com TCP
• 2.8 Programação de socket com UDP
• 2.9 Construindo um servidor Web
© 2005 by Pearson Education
2 - 101
2
Programação de sockets com UDP
UDP: não há conexão entre o cliente e o servidor
• Não existe apresentação
• Transmissor envia explicitamente endereço IP e porta de destino em cada
mensagem
• Servidor deve extrair o endereço IP e porta do transmissor de cada
datagrama recebido
UDP: dados transmitidos podem ser recebidos fora de ordem ou perdidos
Ponto de vista da aplicação
UDP fornece a transferência não confiável de grupos de bytes
(datagramas) entre o cliente e oservidor
© 2005 by Pearson Education
2 - 102
2
Interação cliente-servidor: UDP
Cliente
Servidor
(rodando em hostid)
Criar socket port=x, para
requisição entrante:
Criar socket
serverSocket =
DatagramSocket()
serverSocket =
DatagramSocket()
Criar endereço
(hostid, port=x)
Ler requisição de
Enviar requisição de
datagrama clientsocket
serverSocket
Escrevr resposta para
serverSocket
Ler resposta de
especificando o endereço
do hospedeiro cliente e o
número da porta
clientSocket
Fechar
clientSocket
© 2005 by Pearson Education
2 - 103
2
© 2005 by Pearson Education
2 - 106
2
© 2005 by Pearson Education
2 - 107
2
Exemplo: cliente Java (UDP)
import java.io.*;
import java.net.*;
class UDPClient {
public static void main(String args[]) throws Exception
{
Cria
stream de entrada
Cria
socket cliente
Translada
nome do
hospedeiro para
endereço IP
usando DNS
© 2005 by Pearson Education
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 - 108
2
Exemplo: cliente Java (UDP)
Cria datagrama com
dados a enviar,
tamanho, endereço
IP e porta do servidor
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length,
IPAddress, 9876);
clientSocket.send(sendPacket);
Envia datagrama
para servidor
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
clientSocket.receive(receivePacket);
Lê datagrama
do servidor
String modifiedSentence =
new String(receivePacket.getData());
System.out.println("FROM SERVER:" + modifiedSentence);
clientSocket.close();
}
}
© 2005 by Pearson Education
2 - 109
2
Exemplo: servidor Java (UDP)
import java.io.*;
import java.net.*;
class UDPServer {
public static void main(String args[]) throws Exception
Cria
{
socket datagrama
DatagramSocket serverSocket = new DatagramSocket(9876);
na porta 9876
byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];
while(true)
{
Cria espaço para
datagramas recebidos
Recebe
datagrama
© 2005 by Pearson Education
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
2 - 110
2
Exemplo: servidor Java (UDP)
String sentence = new String(receivePacket.getData());
Obtém endereço IP
e número da porta
do transmissor
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
String capitalizedSentence =
sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
Cria datagrama
para enviar ao cliente
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length,
IPAddress, port);
Escreve o
datagrama para
dentro do socket
serverSocket.send(sendPacket);
}
}
}
© 2005 by Pearson Education
Termina o while loop,
retorna e espera por
outro datagrama
2 - 111