2: Camada de Aplicação 1 Capítulo 2 Camada de Aplicação Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2009. 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. Thanks and enjoy! JFK/KWR All material copyright 1996-2009 J.F Kurose and K.W. Ross, All Rights Reserved
124
Embed
Capítulo 2 Camada de Aplicaçãomarco/cursos/ea074_14_1/slides/2014-Capitulo2.pdf2: Camada de Aplicação 21 Aplicações Internet: protocolos de aplicação & de transporte Applicação
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
2: Camada de Aplicação 1
Capítulo 2 Camada de Aplicação
Computer Networking: A Top Down Approach, 5th edition. Jim Kurose, Keith RossAddison-Wesley, July 2009.
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.
Thanks and enjoy! JFK/KWR
All material copyright 1996-2009J.F Kurose and K.W. Ross, All Rights Reserved
2: Camada de Aplicação 22
2: Camada de Aplicação 3
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 4
Capítulo 2: Camada de AplicaçãoObjetivos: • Conceitual, aspectos
de implementação dos protocolos de aplicação Modelos de
serviço da camada de transporte
Modelo Cliente x Servidor
Modelo Peer-to-Peer (Peer2Peer)
• 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
2: Camada de Aplicação 5
Algumas aplicações de rede• E-mail• Web• Sistema de Mensagem
instantânea (Instant Messaging)
• Login remoto• Compartilhamento de
arquivo P2P• Jogos de rede multi-
usuários• Vídeo sob demanda
• Voz sobre IP (VoiP)• Vídeo-conferência• Computação GRID• …• …• …
2: Camada de Aplicação 6
Criando uma aplicação de redeEscreva 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
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
2: Camada de Aplicação 7
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 8
Arquiteturas de aplicação
• Cliente-Servidor• Peer-to-peer (P2P)• Híbrido de Cliente-Servidor e P2P
2: Camada de Aplicação 9
Arquitetura Cliente-ServidorServidor:
Sempre “on” Endereço IP permanente Fazendas de servidores
para fins de escalabilidadeCliente:
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
cliente/servidor
2: Camada de Aplicação 10
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 11
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
Altamente escalável mas difícil de gerenciar
P2P
2: Camada de Aplicação 12
Híbrido de Cliente-Servidor e P2PSkype
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 “on-line”
• Usuário contacta o servidor central para obter o endereço IP dos pares
2: Camada de Aplicação 13
Processos comunicantesProcesso: 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 comunicam-se através da troca de mensagens
Processo cliente: processo que inicia a comunicação
Processo servidor: processo que espera ser contactado
• 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
HTTP é “stateless”• Servidor não mantém
qualquer informação sobre as requisições anteriores do cliente
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
Obs.
2: Camada de Aplicação 26
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
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”
2: Camada de Aplicação 27
HTTP Não-PersistenteSuponha que o usuário entre a seguinte URL
www.someSchool.edu/someDepartment/home.index
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
(contém texto e referências p/10
Imagens jpeg)
2: Camada de Aplicação 28
HTTP não-persistente (cont.)
5. Cliente HTTP recebe a 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
4. Servidor HTTP server fecha a conexão TCP .
tempo
2: Camada de Aplicação 29
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
Tempo detranmissãodo arquivo
Inicia conexãoTCP
RTTRequisitao arquivo
RTT
Arquivorecebido
tempo tempo
2: Camada de Aplicação 30
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
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
2: Camada de Aplicação 31
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)
GET /somedir/page.html HTTP/1.1Host: www.someschool.edu User-agent: Mozilla/4.0Connection: close Accept-language:fr
(carriage return, line feed extras)
Linha de requisição(comandos GET,
POST, HEAD)
cabeçalho
Carriage return, line feed
indicam o fim da mensagem
2: Camada de Aplicação 32
Mensagem de requisição HTTP: formato geral
2: Camada de Aplicação 33
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 34
Tipos de métodos
HTTP/1.0• GET• POST• HEAD
Similar ao Get. O servidor não retorna o objeto especificado (usado para debugging)
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
2: Camada de Aplicação 35
Mensagem de resposta HTTP
HTTP/1.1 200 OK Connection closeDate: 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 ...
Linha de status
Cabeçalho
dado, e.x., Arquivo HTML
requisitado
2: Camada de Aplicação 36
Códigos de status nas mensagens de resposta HTTP
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 servidor404 Não encontrado
Documento requisitado não encontrado no servidor505 Versão HTTP Version não suportada
Aparecem na primeira linha da mensagem de resposta servidor ->cliente
Alguns exemplos de códigos:
2: Camada de Aplicação 37
Acessando um servidor HTTP via linha de comandos
1. Comando telnet para um servidor Web:abre conexão TCP na porta 80(porta default do servidor Web) em cis.poly.edu.Qualquer comando é enviado para a porta 80 emcis.poly.edu
telnet cis.poly.edu 80
2. comando de requisição GET HTTP:GET /~ross/ HTTP/1.1Host: cis.poly.edu
Ao entrar este comando (bater duasvezes o carriage return), voce enviauma requisição GET mínima mas completa ao Servidor HTTP
3. Analise a resposta enviada pelo servidor HTTP!
2: Camada de Aplicação 38
Olhando o HTTP em ação-Exemplos
• Exemplo telnet• Exemplo Wireshark (ferramenta livre de
monitoramento de redes)
2: Camada de Aplicação 39
Estado do usuário: cookiesVá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
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 IDe devolve tais informações na forma de um arquivo cookie.
2: Camada de Aplicação 40
Cookies: mantendo o “estado”
cliente servidor
resposta http customizada
resposta http customizada
Arquivo cookie
Uma semana após:
requisição http cookie: 1678
cookieaccesso
ebay 8734requisição http Servidor Amazon
cria ID 1678 para o usuário cria
entradaresposta http Set-cookie: 1678
ebay 8734amazon 1678
ebay 8734amazon 1678
Base dedados
requisição httpcookie: 1678
accesso
cookie
2: Camada de Aplicação 41
Cookies (cont.)O quê os cookies oferecem:• autorização• cartões de compra• recomendações• estado da sessão do
usuário
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
Obs
2: Camada de Aplicação 42
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 43
Mais sobre o cache Web• O cache atua tanto como
cliente como servidor• Tipicamente, o cache é
instalado pelo ISP (universidade, companhia, ISP residencial)
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)
2: Camada de Aplicação 44
Exemplo de caching Servidores de
origem
InternetPública
Redeinstitucional 10 Mbps LAN
Enlace de acesso1 Mbps
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 45
Exemplo de caching (cont)Solução possível• Aumentar a banda do acesso do
enlace para, p. ex., 10 Mbpsconsequê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!
Servidores deorigem
InternetPública
Redeinstitucional 10 Mbps LAN
Enlace de acesso1 Mbps -> 10 Mbps
2: Camada de Aplicação 46
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)
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
Cacheinstitucional
Servidores deorigem
InternetPública
Redeinstitucional 10 Mbps LAN
Enlace de acesso1 Mbps
2: Camada de Aplicação 47
GET condicional
• 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
Cliente Servidor
HTTP request msgIf-modified-since: <date>
HTTP responseHTTP/1.0
304 Not Modified
Objeto não
modificado
HTTP request msgIf-modified-since: <date>
HTTP responseHTTP/1.1 200 OK
<data>
Objeto modificado
2: Camada de Aplicação 48
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 49
FTP: the file transfer protocol
• 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
Transf. de arquivoServidor
FTP
Interface de usuário
FTP
ClienteFTP
Sistema deArquivo local
Sistema deArquivo remoto
usuário
2: Camada de Aplicação 50
FTP: separa fluxo de controle e fluxo de dados
ClienteFTP
ServidorFTP
Conexão de controle TCPporta 21
Conexão TCP de dadosporta 20
• 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
2: Camada de Aplicação 51
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 52
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 53
Correio eletrônicoTrê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 e-
mail”• 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
Mailbox do usuário
Fila demensagens de saída
Servidorde e-mail
Agentedo
usuário
SMTP
SMTP
SMTP
Agentedo
usuário
Agentedo
usuário
Agentedo
usuário
Agentedo
usuárioAgente
do usuário
Servidorde e-mail
Servidorde e-mail
2: Camada de Aplicação 54
Correio eletrônico: servidores de e-mailServidores 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
Servidorde e-mail
Agentedo
usuário
SMTP
SMTP
SMTP
Agentedo
usuário
Agentedo
usuário
Agentedo
usuário
Agentedo
usuárioAgente
do usuário
Servidorde e-mail
Servidorde e-mail
2: Camada de Aplicação 55
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 56
Servidorde e-mail
Servidorde e-mail
Agentedo
usuário
Cenário: Alice envia mensagens para Bob1) Alice usa o agente (UA)
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
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
1
2 3 4 56
Agentedo
usuário
2: Camada de Aplicação 57
Exemplo de uma interação SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection
2: Camada de Aplicação 58
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 59
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
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
2: Camada de Aplicação 60
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 !)
• body mensagem codificada com
caracteres ASCII de 7 bits
cabeçalho
body
Linhaem brancoCRLFCRLF
2: Camada de Aplicação 61
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
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
Dado multimídiatipo, subtipo,
Método usado para codificação do dado
Versão MIME
dado codificado
2: Camada de Aplicação 62
Protocolos de acesso ao e-mail
• 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.
Servidor de e-mailemissor
SMTP SMTP Protocolode acesso
Servidor de e-mailreceptor
Agentedo
usuário
Agentedo
usuário
2: Camada de Aplicação 63
Protocolo POP3Fase 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
C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off
S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on
2: Camada de Aplicação 64
POP3 e IMAP
Mais sobre o POP3• Exemplo anterior utiliza o
modo “download and delete”.
• Bob não pode reler o e-mail caso ele troque de cliente
• “Download-and-keep”: cópias das mensagens em clientes diferentes
• POP3 é do tipo “stateless”
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
2: Camada de Aplicação 65
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 66
DNS: Domain Name System
Pessoas: vários identificadores: RG, name, #cic, …
Hosts Internet, roteadores: Endereço IP (32 bits) –
usado para endereçamento de datagramas
“nome”, e.x., ww.yahoo.com – usado por humanos
Q: como mapear nomes e endereços IP?
Domain Name System:• Base de dados distribuída
implementada através de uma hierarquia de vários servidores de nomes
• Protocolo de aplicação permite que hosts e servidores de nomes comuniquem-se para resolução de nomes (tradução nome/endereço) nota: função do núcleo da
Internet mas implementada como um protocolo de camada de aplicação
2: Camada de Aplicação 67
DNS 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!
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 68
Servidores DNS Root
Servidores DNS .com Servidores DNS .org Servidores DNS .edu
Servidores DNSpoly.edu
Servidores DNSumass.edu
ServidoresDNS yahoo.com
Servidores DNSamazon.com
Servidores DNSpbs.org
Base de dados Hierárquica e distribuída
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 69
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
13 servidores de nome raiz no mundo!b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
e NASA Mt View, CAf Internet Software C. Palo Alto, CA (and 36 other locations)
i Autonomica, Stockholm (plus 28 other locations)
k RIPE London (also 16 other locations)
m WIDE Tokyo (also Seoul, Paris, SF)
a Verisign, Dulles, VAc Cogent, Herndon, VA (also LA)d U Maryland College Park, MDg US DoD Vienna, VAh ARL Aberdeen, MDj Verisign, ( 21 locations)
2: Camada de Aplicação 70
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.
• 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 97
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 98
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 99
1
3
4
5
810
12
15
DHT Circular (1)
• Cada peer é ciente somente do sucessor e do predecessor imediatos.
• “Exemplo de uma Rede Overlay”
2: Camada de Aplicação 100
DHT Circular (2)
0001
0011
0100
0101
10001010
1100
1111
Quem é o responsávelpela chave 1110 ?
Sou eu!
O(N) mensagens namédia para resolveruma consulta (query)quando existem Npeers
1110
1110
1110
1110
1110
1110
2: Camada de Aplicação 101
DHT Circular com Atalhos
• 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
13
4
5
810
12
15
Quem é o responsável pela chave 1110?
2: Camada de Aplicação 102
Dinâmica dos Peers
• 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?
1
3
4
5
810
12
15
• Para gerenciar a dinâmica dos peers,requere-se que cada peer conheça oendereço IP dos seus 2 sucessores. • Cada peer faz um ping periodica-mente para os seus dois sucessorespara verificar se ambos ainda estão vivos.
2: Camada de Aplicação 103
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 104
Programação 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
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
socket
Objetivo: aprender como desenvolver aplicações cliente/servidor que se comunicam via socket
2: Camada de Aplicação 105
Programação de socket via TCPSocket: 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
processo
TCP combuffers,variáveis
socket
Controlado pelo programador
Controlado peloSO
host ouservidor
processo
TCP combuffers,variáveis
socket
Controlado peloprogramador
Controlado peloSO
host ouservidor
internet
2: Camada de Aplicação 106
Programação de socket com TCPCliente 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
Cliente contacta o servidor via:• Criação de um socket TCP local
ao cliente• Especificação do endereço IP e
do número da porta associados ao processo servidor
• Quando cliente cria o socket: o cliente TCP estabelece uma conexão com o servidor TCP
• 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)
O TCP provê uma transferênciaconfiável e ordenada de bytes
(“pipe”) entre o cliente e o servidor
Ponto de vista da aplicação
2: Camada de Aplicação 107
Interação cliente/servidor via socket: TCP
Espera um pedidode conexãoconnectionSocket =welcomeSocket.accept()
cria socket,porta=x, para receberas requisições:welcomeSocket =
ServerSocket()
Cria socket e conecta aohostid, porta=xclientSocket =
Socket()
encerraconnectionSocket
Lê resposta declientSocket
encerraclientSocket
Servidor (executando no hostid) Cliente
Envia requisição viaclientSocketLê a requisição do
connectionSocket
Responde para connectionSocket
TCP Setup da conexão
2: Camada de Aplicação 108
client TCP socket
Stream: jargão• um stream é uma
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
ou
tToS
erv
er
para a rededa rede
inF
rom
Se
rve
r
inF
rom
Use
r
teclado monitor
Processo cliente
client
input
stream
inputstream
outputstream
2: Camada de Aplicação 109
Programação de socket com TCPExemplo 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 socket3) Servidor converte a linha para maiúscula e envia de
volta para o cliente4) Cliente lê a linha modificada via socket
(inFromServer stream) e imprime
2: Camada de Aplicação 110
Exemplo: Cliente Java (TCP)import java.io.*; import java.net.*; class TCPClient {