• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Cap2a
 

Cap2a

on

  • 675 views

 

Statistics

Views

Total Views
675
Views on SlideShare
542
Embed Views
133

Actions

Likes
0
Downloads
12
Comments
0

4 Embeds 133

http://stthiaggo.blogspot.com.br 73
http://stthiaggo.blogspot.com 55
http://stthiaggo.blogspot.pt 3
http://feeds.feedburner.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Cap2a Cap2a Presentation Transcript

    • Capítulo 2: Camada de AplicaçãoMetas do capítulo:  aprenda sobre protocolos aspectos conceituais através do estudo de e de implementação protocolos populares da de protocolos de camada de aplicação: aplicação em redes  HTTP  modelos de serviço da  FTP camada de transporte  paradigma cliente  SMTP/ POP3/ IMAP servidor  DNS  paradigma peer-to- peer 2a: Camada de 1
    • Capítulo 2: Roteiro 2.1 Princípios dos protocolos da camada de aplicação 2.2 Web e HTTP 2.3 FTP 2.4 Correio Eletrônico  SMTP, POP3, IMAP 2.5 DNS 2a: Camada de 2
    • Algumas aplicações de rede E-mail  Voz sobre IP Web  Vídeo conferência em Instant messaging tempo real Login remoto  Computação paralela Compartilhamento de em larga escala arquivos P2P  ? Jogos de rede multi-  ? usuários Vídeo-clipes armazenados  ? 2a: Camada de 3
    • Criando uma aplicação de redeProgramas que aplicação transporte rede  Executam em diferentes enlace sistemas finais física  Comunicam-se através da rede  p.ex., Web: servidor Web se comunica com o navegadorProgramas não relacionados ao núcleo da rede  Dispositivos do núcleo da rede aplicação não executam aplicações de aplicação transporte transporte rede usuários rede enlace enlace física  Aplicações nos sistemas finais física permite rápido desenvolvimento e disseminação 2a: Camada de 4
    • Arquiteturas das aplicações Cliente-servidor Peer-to-peer (P2P) Híbrido de cliente-servidor e P2P 2a: Camada de 5
    • Arquitetura cliente-servidor Servidor:  Sempre ligado  Endereço IP permanente  Escalabilidade com server farms Cliente:  Comunica-se com o servidor  Pode estar conectado intermitentemente  Pode ter endereços IP dinâmicos  Não se comunica diretamente com outros clientes 2a: Camada de 6
    • Arquitetura P2P pura Não há servidor sempre ligado Sistemas finais arbitrários se comunicam diretamente Pares estão conectados intermitentemente e mudam endereços IP Exemplo: GnutellaAltamente escalávelPorém, difícil de gerenciar 2a: Camada de 7
    • Híbrido de cliente-servidor e P2PNapster  Transferência de arquivos P2P  Busca de arquivos centralizada: • Pares registram conteúdo no servidor central • Pares consultam o mesmo servidor central para localizar conteúdoInstant messaging  Conversa entre usuários P2P  Localização e detecção de presença centralizadas: • Usuários registram o seu endereço IP junto ao servidor central quando ficam online • Usuários consultam o servidor central para encontrar endereços IP dos contatos 2a: Camada de 8
    • Processos em comunicaçãoProcesso: programa que Processo cliente: processo que inicia a comunicação executa num hospedeiro Processo servidor: processo que processos no mesmo espera para ser contatado hospedeiro se comunicam usando comunicação entre processos definida pelo sistema operacional (SO) processos em hospedeiros  Nota: aplicações com distintos se comunicam trocando mensagens arquiteturas P2P através da rede possuem processos clientes e processos servidores 2a: Camada de 9
    • Sockets Os processos enviam/ host ou host ou servidor recebem mensagens servidor para/dos seus sockets controlado pelo Um socket é análogo a desenvolvedor da uma porta processo aplicação processo  Processo transmissor envia a socket socket mensagem através da porta TCP com TCP com  O processo transmissor Internet buffers, assume a existência da infra- buffers, estrutura de transporte no variáveis variáveis outro lado da porta que faz com que a mensagem chegue ao socket do processo controlado receptor pelo SO API: (1) escolha do protocolo de transporte; (2) habilidade para fixar alguns parâmetros (mais sobre isto posteriormente) 2a: Camada de 10
    • Endereçando os processos Para que um processo  O identificador inclui tanto receba mensagens, ele deve o endereço IP quanto os possuir um identificador números das portas Cada host possui um associadas com o processo endereço IP único de 32 no host. bits  Exemplo de números de P: o endereço IP do host no portas: qual o processo está sendo  Servidor HTTP: 80 executado é suficiente para  Servidor de Correio: 25 identificar o processo?  Mais sobre isto Resposta: Não, muitos posteriormente. processos podem estar executando no mesmo host 2a: Camada de 11
    • Os protocolos da camada deaplicação definem Tipos de mensagens Protocolos de domínio trocadas, ex. mensagens público: de pedido e resposta  definidos em RFCs Sintaxe dos tipos das  Permitem a mensagens: campos presentes nas mensagens interoperação e como são identificados  ex, HTTP e SMTP Semântica dos campos, Protocolos proprietários: i.e., significado da  Ex., KaZaA informação nos campos Regras para quando os processos enviam e respondem às mensagens 2a: Camada de 12
    • De que serviço de transporte umaaplicação precisa?Perda de dados Largura de banda algumas apls (p.ex. áudio) podem tolerar algumas perdas  algumas apls (p.ex., outras (p.ex., transf. de multimídia) requerem arquivos, telnet) requerem quantia mínima de banda transferência 100% confiável para serem “viáveis”  outras apls (“apls elásticas”) conseguem usar qq quantia de banda disponívelTemporização algumas apls (p.ex., telefonia Internet, jogos interativos) requerem baixo retardo para serem “viáveis” 2a: Camada de 13
    • Requisitos do serviço de transporte de apls comuns Sensibilidade Aplicação Perdas Banda temporaltransferência de arqs sem perdas elástica não correio sem perdas elástica não documentos WWW sem perdas elástica não áudio/vídeo de tolerante áudio: 5Kb-1Mb sim, 100’s mseg tempo real vídeo:10Kb-5Mb áudio/vídeo gravado tolerante como anterior sim, alguns segs jogos interativos tolerante > alguns Kbps sim, 100’s mseg apls financeiras sem perdas elástica sim e não 2a: Camada de 14
    • Serviços providos por protocolos de transporte InternetServiço TCP: Serviço UDP: orientado a conexão:  transferência de dados não inicialização requerida entre confiável entre processos cliente e servidor remetente e receptor transporte confiável entre  não provê: estabelecimento processos remetente e receptor da conexão, confiabilidade, controle de fluxo, controle controle de fluxo: remetente não vai “afogar” receptor de congestionamento, garantias temporais ou de controle de banda mínima congestionamento: estrangular remetente quando a rede estiver carregada P: Qual é o interesse em ter um não provê: garantias UDP? temporais ou de banda mínima 2a: Camada de 15
    • Apls Internet: seus protocolos e seus protocolos de transporte Protocolo da Protocolo de Aplicação camada de apl transporte usado correio eletrônico SMTP [RFC 2821] TCP acesso terminal remoto telnet [RFC 854] TCP WWW HTTP [RFC 2616] TCPtransferência de arquivos ftp [RFC 959] TCP streaming multimídia proprietário TCP ou UDP (p.ex. RealNetworks) telefonia Internet proprietário tipicamente UDP (p.ex., Dialpad) 2a: Camada de 16
    • Capítulo 2: Roteiro 2.1 Princípios dos protocolos da camada de aplicação 2.2 Web e HTTP 2.3 FTP 2.4 Correio Eletrônico  SMTP, POP3, IMAP 2.5 DNS 2a: Camada de 17
    • Web e HTTPPrimeiro algum jargão Páginas Web consistem de objetos Objeto pode ser um arquivo HTML, uma imagem JPEG, um applet Java, um arquivo de áudio,… Páginas Web consistem de um arquivo HTML base que inclui vários objetos referenciados Cada objeto é endereçável por uma URL Exemplo de URL: www.someschool.edu/someDept/pic.gif nome do hospedeiro nome do caminho 2a: Camada de 18
    • Protocolo HTTPHTTP: hypertext transfer protocol ped ido protocolo da camada de htt PC executa res p po s ta aplicação da Web Explorer htt p modelo cliente/servidor  cliente: browser que p pede, recebe, “visualiza” o htt did tp Servidor objetos Web pe a ht executando p ost servidor  servidor: servidor Web res WWW envia objetos em do NCSA resposta a pedidos Mac executa HTTP 1.0: RFC 1945 Navigator HTTP 1.1: RFC 2068 2a: Camada de 19
    • Mais sobre o protocolo HTTPUsa serviço de transporte HTTP é “sem estado”  servidor não mantém TCP: informação sobre cliente inicia conexão TCP pedidos anteriores do (cria socket) ao servidor, cliente porta 80 servidor aceita conexão TCP Nota Protocolos que mantêm do cliente “estado” são complexos! mensagens HTTP (mensagens  história passada (estado) do protocolo da camada de tem que ser guardada apl) trocadas entre browser  Caso caia servidor/cliente, (cliente HTTP) e servidor suas visões do “estado” Web (servidor HTTP) podem ser inconsistentes, encerra conexão TCP devem ser reconciliadas 2a: Camada de 20
    • Conexões HTTPHTTP não persistente HTTP persistente No máximo um objeto  Múltiplos objetos é enviado numa podem ser enviados conexão TCP sobre uma única HTTP/1.0 usa o HTTP conexão TCP entre não persistente cliente e servidor  HTTP/1.1 usa conexões persistentes no seu modo default 2a: Camada de 21
    • Exemplo de HTTP não persistente Supomos que usuário digita a URL www.algumaUniv.br/algumDepartmento/inicial.index (contém texto, referências a 10 imagens jpeg) 1a. Cliente http inicia conexão TCP a servidor http (processo) a www.algumaUniv.br. Porta 80 1b. servidor http no hospedeiro www.algumaUniv.br espera por é padrão para servidor http. conexão TCP na porta 80. “aceita” conexão, avisando ao cliente 2. cliente http envia mensagem de pedido de http (contendo URL) através do socket da 3. servidor http recebe mensagem conexão TCP de pedido, formula mensagem de resposta contendo objeto solicitado (algumDepartmento/inicial.index), envia mensagem via sockettempo 2a: Camada de 22
    • Exemplo de HTTP não persistente (cont.) 4. servidor http encerra conexão TCP . 5. cliente http recebe mensagem de resposta contendo arquivo html, visualiza html. Analisando arquivo html, encontra 10 objetos jpeg referenciados 6. Passos 1 a 5 repetidos para cada um dos 10 objetos jpegtempo 2a: Camada de 23
    • Modelagem do tempo derespostaDefinição de RTT (Round Trip Time): intervalo de tempo entre a ida e a volta de um pequeno pacote entre um cliente e um servidor Inicia a conexãoTempo de resposta: TCP um RTT para iniciar a conexão RTT TCP solicita um RTT para o pedido HTTP e o arquivo retorno dos primeiros bytes da RTT tempo para resposta HTTP transmitir o arquivo tempo de transmissão do arquivo arquivo recebidototal = 2RTT+tempo de transmissão tempo tempo 2a: Camada de 24
    • HTTP persistenteProblemas com o HTTP não Persistente sem pipelining: persistente:  o cliente envia um novo requer 2 RTTs para cada objeto pedido apenas quando a SO aloca recursos do host para resposta anterior tiver sido cada conexão TCP recebida os browser freqüentemente  um RTT para cada objeto abrem conexões TCP paralelas referenciado para recuperar os objetos Persistente com pipelining: referenciados  default no HTTP/1.1HTTP persistente  o cliente envia os pedidos o servidor deixa a conexão logo que encontra um objeto aberta após enviar a resposta referenciado mensagens HTTP seguintes  pode ser necessário apenas entre o mesmo cliente/servidor são enviadas nesta conexão um RTT para todos os objetos referenciados 2a: Camada de 25
    • Formato de mensagem HTTP: pedido  Dois tipos de mensagem HTTP: pedido, resposta  mensagem de pedido HTTP:  ASCII (formato legível por pessoas) linha do pedido(comandos GET, GET /somedir/page.html HTTP/1.0 POST, HEAD) Host: www.someschool.edu User-agent: Mozilla/4.0 linhas do Connection: close cabeçalho Accept-language:fr Carriage return, (carriage return (CR), line feed(LF) adicionais) line feed indicam fim de mensagem 2a: Camada de 26
    • Mensagem de pedido HTTP: formatogeral 2a: Camada de 27
    • Tipos de métodosHTTP/1.0 HTTP/1.1 GET  GET, POST, HEAD POST  PUT HEAD  Upload de arquivo contido no corpo da  Pede para o servidor mensagem para o não enviar o objeto caminho especificado no requerido junto com a campo URL resposta (usado p/ debugging)  DELETE  Exclui arquivo especificado no campo URL 2a: Camada de 28
    • Enviando conteúdo de formulárioMétodo POST : Conteúdo é enviado para o servidor no Método GET: corpo da mensagem  Conteúdo é enviado para o servidor no campo URL: www.somesite.com/animalsearch?key=monkeys&max=10 2a: Camada de 29
    • Formato de mensagem HTTP:resposta linha de status (protocolo,código de status, HTTP/1.1 200 OKfrase de status) Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) linhas de Last-Modified: Mon, 22 Jun 1998 …... cabeçalho Content-Length: 6821 Content-Type: text/htmldados, p.ex., dados dados dados dados ...arquivo html solicitado 2a: Camada de 30
    • códigos de status da respostaHTTPNa primeira linha da mensagem de resposta servidor->cliente. Alguns códigos típicos:200 OK  sucesso, objeto pedido segue mais adiante nesta mensagem301 Moved Permanently  objeto pedido mudou de lugar, nova localização especificado mais adiante nesta mensagem (Location:)400 Bad Request  mensagem de pedido não entendida pelo servidor404 Not Found  documento pedido não se encontra neste servidor505 HTTP Version Not Supported  versão de http do pedido não usada por este servidor 2a: Camada de 31
    • Experimente você com HTTP (do ladocliente)1. Use cliente telnet para seu servidor WWW favorito: telnet www.ic.uff.br 80 Abre conexão TCP para a porta 80 (porta padrão do servidor http) a www.ic.uff.br. Qualquer coisa digitada é enviada para a porta 80 do www.ic.uff.br2. Digite um pedido GET HTTP: GET /~michael/index.html HTTP/1.0 Digitando isto (deve teclar ENTER duas vezes), está enviando este pedido GET mínimo (porém completo) ao servidor http3. Examine a mensagem de resposta enviada pelo servidor HTTP ! 2a: Camada de 32
    • Cookies: manutenção do“estado” da conexãoMuitos dos principais sítios Exemplo: Web usam cookies  Suzana acessa aQuatro componentes: Internet sempre do 1) linha de cabeçalho do mesmo PC cookie na mensagem de  Ela visita um sítio resposta HTTP específico de comércio 2) linha de cabeçalho do eletrônico pela primeira cookie na mensagem de pedido HTTP vez 3) arquivo do cookie mantido  Quando os pedidos no host do usuário e iniciais HTTP chegam no gerenciado pelo browser sítio, o sítio cria uma ID do usuário única e cria uma entrada 4) BD de retaguarda no sítio para a ID no BD de Web retaguarda 2a: Camada de 33
    • Cookies: manutenção do “estado” (cont.) cliente servidor arquivo de msg usual pedido http e servidor de ntrad Cookies a resposta usual http + cria a ID 1678 retag no B ua ebay: 8734 Set-cookie: 1678 para o usuário rd D a arquivo de msg usual pedido http Cookies amazon: 1678 cookie: 1678 ação so ebay: 8734 específica aces resposta usual http do cookie souma semana depois: es ac msg usual pedido http arquivo de ação Cookies cookie: 1678 amazon: 1678 específica ebay: 8734 resposta usual http do cookie 2a: Camada de 34
    • Cookies (continuação) notaO que os cookies podem Cookies e privacidade: obter:  cookies permitem que os sítios aprendam muito autorização sobre você carrinhos de compra  você pode fornecer nome e sugestões e-mail para os sítios  mecanismos de busca usam estado da sessão do redirecionamento e cookies usuário (Webmail) para aprender ainda mais  agências de propaganda obtêm perfil a partir dos sítios visitados 2a: Camada de 35
    • Cache Web (servidor proxy) Meta: atender pedido do cliente sem envolver servidor de origem usuário configura Servidor browser: acessos Web via de origem proxy cliente cliente envia todos Servidor ped p pedidos HTTP ao proxy i do proxy htt res h ttp ido tp se objeto no cache do pos ped a ht ost  t ah p proxy, este o devolve ttp res imediatamente na p o htt resposta HTTP did tp pe a ht  senão, solicita objeto do ost p servidor de origem, res depois devolve resposta HTTP ao cliente cliente Servidor de origem 2a: Camada de 36
    • Mais sobre Caches Web Cache atua tanto como Para que fazer cache Web? cliente quanto como  Redução do tempo de servidor resposta para os pedidos Tipicamente o cache é do cliente instalado por um ISP  Redução do tráfego no (universidade, empresa, canal de acesso de uma ISP residencial) instituição  A Internet cheia de caches permitem que provedores de conteúdo “pobres” efetivamente forneçam conteúdo! 2a: Camada de 37
    • Exemplo de cache (1) Servidores de origemHipóteses Tamanho médio de um objeto = Internet 100.000 bits pública Taxa média de solicitações dos browsers de uma instituição para os servidores originais = 15/seg Atraso do roteador institucional para qualquer servidor origem e de enlace de acesso volta ao roteador = 2seg 1,5 MbpsConseqüências rede da Utilização da LAN = 15% instituição LAN 10 Mbps Utilização do canal de acesso = 100% Atraso total = atraso da Internet + atraso de acesso + atraso na LAN = 2 seg + minutos + milisegundos 2a: Camada de 38
    • Exemplo de cache (2) Servidores de origemSolução em potencial Aumento da largura de banda Internet do canal de acesso para, por pública exemplo, 10 MbpsConseqüências Utilização da LAN = 15% enlace de acesso Utilização do canal de acesso 10 Mbps = 15% rede da Atraso total = atraso da instituição LAN 10 Mbps Internet + atraso de acesso + atraso na LAN = 2 seg + msegs + msegs Freqüentemente este é uma ampliação cara 2a: Camada de 39
    • Exemplo de cache (3) Servidores de origemInstale uma cache Assuma que a taxa de acerto Internet seja de 0,4 públicaConseqüências 40% dos pedidos serão atendidos quase que imediatamente enlace de acesso 60% dos pedidos serão servidos 1,5 Mbps pelos servidores de origem rede da Utilização do canal de acesso é instituição reduzido para 60%, resultando LAN 10 Mbps em atrasos desprezíveis (ex. 10 mseg) Atraso total = atraso da Internet + atraso de acesso + cache atraso na LAN = 0,6*2 seg + institucional 0,6*0,01 segs + msegs < 1,3 segs 2a: Camada de 40
    • GET condicional cache servidor Meta: não enviar objeto se msg de pedido http If-modified-since: objeto cliente já tem (no cache) <date> não versão atual resposta http modificado cache: especifica data da HTTP/1.0 cópia no cache no pedido 304 Not Modified http If-modified-since: <date> msg de pedido http servidor: resposta não If-modified-since: objeto <date> contém objeto se cópia no modificado cache é atual: resposta http HTTP/1.1 200 OK HTTP/1.0 304 Not … Modified <data> 2a: Camada de 41
    • Capítulo 2: Roteiro 2.1 Princípios dos protocolos da camada de aplicação 2.2 Web e HTTP 2.3 FTP 2.4 Correio Eletrônico  SMTP, POP3, IMAP 2.5 DNS 2a: Camada de 42
    • FTP: o protocolo de transferênciade arquivos transferência Interface cliente do arquivo FTP do usuário FTP servidor FTP usuário na sistema de sistema de estação arquivos arquivos local remoto  transferir arquivo de/para hospedeiro remoto  modelo cliente/servidor  cliente: lado que inicia transferência (pode ser de ou para o sistema remoto)  servidor: hospedeiro remoto  ftp: RFC 959  servidor ftp: porta 21 2a: Camada de 43
    • FTP: conexões separadas p/ controle, dados cliente FTP contata servidor FTP na porta 21, especificando o TCP como conexão de controle protocolo de transporte TCP, porta 21 O cliente obtém autorização através da conexão de controle O cliente consulta o diretório conexão de dados remoto enviando comandos através cliente TCP, porta 20 servidor da conexão de controle FTP FTP Quando o servidor recebe um comando para a transferência de  O servidor abre uma segunda um arquivo, ele abre uma conexão de dados TCP para o cliente conexão TCP para transferir Após a transmissão de um arquivo o outro arquivo servidor fecha a conexão  Conexão de controle: “fora da faixa”  Servidor FTP mantém o “estado”: diretório atual, autenticação anterior 2a: Camada de 44
    • FTP: comandos, respostasComandos típicos: Códigos de retorno típicos enviados em texto ASCII  código e frase de status (como pelo canal de controle para http) USER nome  331 Username OK, password required PASS senha  125 data connection LIST devolve lista de already open; transfer arquivos no diretório atual starting RETR arquivo recupera  425 Can’t open data (lê) arquivo remoto connection  STOR arquivo armazena 452 Error writing file (escreve) arquivo no hospedeiro remoto 2a: Camada de 45
    • Capítulo 2: Roteiro 2.1 Princípios dos protocolos da camada de aplicação 2.2 Web e HTTP 2.3 FTP 2.4 Correio Eletrônico  SMTP, POP3, IMAP 2.5 DNS 2a: Camada de 46
    • fila de Correio Eletrônico mensagens de saída caixa de agente correio do usuárioTrês grandes componentes: de usuário agentes de usuário (UA) servidor agente servidores de correio de correio de usuário simple mail transfer protocol: SMTP SMTP servidor de correio agenteAgente de Usuário SMTP de usuário a.k.a. “leitor de correio” compor, editar, ler mensagens SMTP agente de correio servidor de de correio usuário p.ex., Eudora, Outlook, elm, Netscape Messenger agente mensagens de saída e chegando de são armazenadas no servidor usuário agente de usuário 2a: Camada de 47
    • Correio Eletrônico: servidores de correio agente Servidores de correio de usuário  caixa de correio contém servidor agente mensagens de chegada de correio de (ainda não lidas) p/ usuário usuário  fila de mensagens contém SMTP servidor mensagens de saída (a serem de correio enviadas) SMTP  protocolo SMTP entre servidores de correio para SMTP transferir mensagens de agente servidor de correio de correio usuário  cliente: servidor de correio que envia agente  “servidor”: servidor de de usuário correio que recebe agente de usuário 2a: Camada de 48
    • Correio Eletrônico:SMTP [RFC 2821] usa TCP para a transferência confiável de msgs do correio do cliente ao servidor, porta 25 transferência direta: servidor remetente ao servidor receptor três fases da transferência  handshaking (cumprimento)  transferência das mensagens  encerramento interação comando/resposta  comandos: texto ASCII  resposta: código e frase de status mensagens precisam ser em ASCII de 7-bits 2a: Camada de 49
    • Cenário: Alice envia uma msg para Bob 1) Alice usa o UA para compor 4) O cliente SMTP envia a uma mensagem “para” mensagem de Alice através da bob@someschool.edu conexão TCP 2) O UA de Alice envia a 5) O servidor de correio de Bob mensagem para o seu servidor coloca a mensagem na caixa de de correio; a mensagem é colocada na fila de mensagens entrada de Bob 3) O lado cliente do SMTP abre 6) Bob chama o seu UA para ler a uma conexão TCP com o mensagem servidor de correio de Bob 1 mail mail server user user server 2 agent agent 3 6 4 5 2a: Camada de 50
    • Interação SMTP típicaS: 220 doces.brC: HELO consumidor.brS: 250 Hello consumidor.br, pleased to meet youC: MAIL FROM: <ana@consumidor.br>S: 250 ana@consumidor.br... Sender okC: RCPT TO: <bernardo@doces.br>S: 250 bernardo@doces.br ... Recipient okC: DATAS: 354 Enter mail, end with "." on a line by itselfC: Voce gosta de chocolate?C: Que tal sorvete?C: .S: 250 Message accepted for deliveryC: QUITS: 221 doces.br closing connection 2a: Camada de 51
    • Experimente uma interação SMTP: telnet nomedoservidor 25 veja resposta 220 do servidor entre comandos HELO, MAIL FROM, RCPT TO, DATA, QUITestes comandos permitem que você envie correio sem usar um cliente (leitor de correio) 2a: Camada de 52
    • SMTP: últimas palavras SMTP usa conexões Comparação com HTTP persistentes  HTTP: pull (puxar) SMTP requer que a mensagem (cabeçalho e corpo) sejam em  SMTP: push (empurrar) ASCII de 7-bits  ambos têm interação servidor SMTP usa comando/resposta, códigos CRLF.CRLF para reconhecer o de status em ASCII final da mensagem  HTTP: cada objeto é encapsulado em sua própria mensagem de resposta  SMTP: múltiplos objetos de mensagem enviados numa mensagem de múltiplas partes 2a: Camada de 53
    • Formato de uma mensagemSMTP: protocolo para trocar msgs de correio cabeçalho linha emRFC 822: padrão para formato branco de mensagem de texto: linhas de cabeçalho, p.ex.,  To: corpo  From:  Subject: diferentes dos comandos de smtp! corpo  a “mensagem”, somente de caracteres ASCII 2a: Camada de 54
    • Formato de uma mensagem: extensões para multimídia  MIME: multimedia mail extension, RFC 2045, 2056  linhas adicionais no cabeçalho da msg declaram tipo do conteúdo MIME From: ana@consumidor.br versão MIME To: bernardo@doces.br Subject: Imagem de uma bela torta método usado MIME-Version: 1.0 p/ codificar dados Content-Transfer-Encoding: base64 Content-Type: image/jpeg tipo, subtipo de dados multimídia, base64 encoded data .....declaração parâmetros ......................... ......base64 encoded data Dados codificados 2a: Camada de 55
    • Tipos MIMEContent-Type: tipo/subtipo; parâmetrosText Audio subtipos exemplos: plain,  subtipos exemplos : basic html (8-bit codificado mu-law), charset=“iso-8859-1”, 32kadpcm (codificação 32 ascii kbps) ApplicationImage  outros dados que precisam subtipos exemplos : jpeg, gif ser processados por um leitor para serem “visualizados”Video  subtipos exemplos : subtipos exemplos : mpeg, msword, octet-stream quicktime 2a: Camada de 56
    • Tipo Multipart From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. --98766789 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data --98766789-- 2a: Camada de 57
    • Protocolos de acesso ao correio agente SMTP SMTP POP3 ou agente de de usuário IMAP usuário servidor de correio servidor de correio do remetente do receptor SMTP: entrega/armazenamento no servidor do receptor protocolo de acesso ao correio: recupera do servidor  POP: Post Office Protocol [RFC 1939] • autorização (agente <-->servidor) e transferência  IMAP: Internet Mail Access Protocol [RFC 1730] • mais comandos (mais complexo) • manuseio de msgs armazenadas no servidor  HTTP: Hotmail , Yahoo! Mail, Webmail, etc. 2a: Camada de 58
    • Protocolo POP3 S: +OK POP3 server ready C: user anafase de autorização S: +OK comandos do cliente: C: pass faminta S: +OK user successfully logged on  user: declara nome  pass: senha C: list servidor responde S: 1 498 S: 2 912  +OK S: .  -ERR C: retr 1fase de transação, cliente: S: <message 1 contents> list: lista números das S: . C: dele 1 msgs C: retr 2 retr: recupera msg por S: <message 1 contents> número S: . dele: apaga msg C: dele 2 quit C: quit S: +OK POP3 server signing off 2a: Camada de 59
    • POP3 (mais) e IMAPMais sobre o POP3 IMAP O exemplo anterior usa o  Mantém todas as modo “download e mensagens num único delete”. lugar: o servidor Bob não pode reler as  Permite ao usuário mensagens se mudar de organizar as mensagens cliente em pastas “Download-e-mantenha”:  O IMAP mantém o estado copia as mensagens em do usuário entre sessões: clientes diferentes  nomes das pastas e mapeamentos entre as IDs POP3 não mantém estado das mensagens e o nome da entre conexões pasta 2a: Camada de 60