Capítulo 2 Camada de Aplicação

Texto

(1)

Capítulo 2

Camada de Aplicação

Computer Networking:

A Top Down Approach, 5th 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

(2)
(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

(4)

Capítulo 2: Camada de Aplicação

Objetivos:

Conceitual, aspectos de implementação dos protocolos de aplicação

Modelos de

serviço da camada de transporte

Modelo Cliente x Servidor

Modelo Peer-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

(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

(6)

Criando uma aplicação de rede

Escreva programas que

Executem em sistemas finais diferentes

Comuniquem-se via rede

e.x., o software de um

servidor web comunica-se com o software de um browser

Poucos softwares são escritos para os dispositivos no núcleo da rede

Os dispositivos do núcleo não executam aplicações do

usuário

Aplicações nos sistemas finais permitem um rápido

application transport

network data link physical

application transport

network data link

physical application

transport network data link physical

(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

(8)

Arquiteturas de aplicação

Cliente-Servidor

Peer-to-peer (P2P)

Híbrido de Cliente-Servidor e P2P

(9)

Arquitetura Cliente-Servidor

Servidor:

Sempre “on”

Endereço IP permanente

Fazendas de servidores para fins de escalabilidade Cliente:

Comunica com o servidor

Pode ser conectado de modo intermitente

Pode possuir endereço IP dinâmico

Não se comunica

diretamente com outro cliente

cliente/servidor

(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

(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

(12)

Híbrido de Cliente-Servidor e P2P

Skype

Aplicação P2P de voz sobre IP (VoiP)

Servidor centralizado: permite encontrar o endereço de um parceiro remoto;

Conexão cliente-cliente: direta (sem passar pelo servidor) Mensagem Instantânea

Conversa entre dois usuários (P2P)

Serviço centralizado: deteção/localização da presença do cliente

• Usuários registram seus endereços IP no

servidor central quando eles tornam-se “on-

line”

(13)

Processos comunicantes

Processo: programa em execução no host

Dentro de um mesmo host, dois processos comunicam-se através do uso da comunicação entre-processos

(definida pelo OS)

Processos em hosts diferentes comunicam- se através da troca de mensagens

Processo cliente:

processo que inicia a comunicação

Processo servidor:

processo que espera ser contactado

Nota: aplicações P2P

possuem processos

clientes & processos

servidores

(14)

Sockets

Processo envia/recebe mensagens para/do seu socket

O socket é análogo a uma porta

o processo emissor empurra a mensagem através da porta

o processo emissor confia na infra-estrutura de transporte do outro lado da porta que leva a mensagem ao socket do processo receptor.

processo

TCP com buffers, variáveis

socket

host ou servidor

processo

TCP com buffers, variáveis

socket host ou servidor

Internet

Controlado pelo OS Controlado pelo desenvolvedor da aplicação

API: (1) escolha do protocolo de transporte; (2)

(15)

Identificação dos processos

Para receber mensagens os processos devem possuir um identificador

O host possui um endereço IP de 32-bits

Q: o endereço IP do host no qual o

processo executa é suficiente para

identificar o processo?

(16)

Identificação dos processos

R: Não, já que

muitos processos podem estar

executando no mesmo host

identificador inclui o

endereço IP e o número da porta associada ao

processo no host.

Exemplos de portas:

Servidor HTTP: 80

Servidor de e-mail: 25

Para enviar mensagens HTTP ao servidor web gaia.cs.umass.edu:

Endereço Ip: 128.119.245.12

(17)

Protocolo da camada de aplicação define:

Tipos das mensagens trocadas,

e.x., requisição (request), resposta (response)

Sintaxe da mensagem:

Quais campos fazem parte da mensagem, ordem e

tamanho dos campos

Semântica da mensagem

Significado da informação nos campos

Regras para quando e como os processos reagem à

troca de mensagens

Protocolos de domínio público:

Definidos em RFCs

Permite a

interoperabilidade

e.x., HTTP, SMTP Protocolos proprietários:

e.x., Skype

(18)

Quais serviços de transporte as aplicações necessitam?

Perda de dados

Algumas aplicações (e.x., áudio) podem tolerar alguma perda

Outras aplicações (e.x., transferência de arquivos,

telnet) requerem 100% para a transferência confiável de

dados

Temporização

Algumas aplicações (ex. Telefonia na Internet, jogos

interativos) requerem

Bandwidth

Algumas aplicações (e.x. multimídia) requerem uma

quantidade mínima de banda para serem

“efetivas”

Outras aplicações (“aplic. elásticas)

utilizam qualquer banda

que eles obtêm

(19)

Requisitos de algumas aplicações relativamente ao serviço de transporte

Aplicação Transf. de arquivo e-mail Documentos Web Áudio/vídeo em

teleconferência

Áudio/vídeo armazenado

Jogos interativos Mensagem instantânea

Perda de dados Sem perda Sem perda Sem perda Tolerante Tolerante Tolerante Sem perda

Bandwidth elástico

elástico elástico

áudio: 5kbps-1Mbps vídeo:10kbps-5Mbps igual ao de cima

Alguns kbps a mais elástico

Sensibilidade ao tempo

não não não

sim, 100’s msec

sim, alguns secs

sim, 100’s msec sim e não

(20)

Protocolos de transporte na Internet

Serviço TCP:

Orientado à conexão: requer o estabelecimento da

conexão entre os processos cliente e servidor

Transporte confiável: entre os processos emissor e

receptor

Controle de fluxo: o emissor não deve sobrecarregar o receptor

Controle de

congestionamento: regular o emissor quando a rede está sobrecarregada

Serviço UDP:

Transferência não-

confiável de dados entre os processos emissor e receptor

Não suporta:

estabelecimento de conexão, controle defluxo, controle de congestionamento, temporizações, ou garantia de banda

(21)

Aplicações Internet: protocolos de aplicação & de transporte

Applicação e-mail Acesso de terminal remoto Web Transferência de arquivos Fluxo multimídia Telefonia Internet

Protocolo da

camada de aplicação SMTP [RFC 2821]

Telnet [RFC 854]

HTTP [RFC 2616]

FTP [RFC 959]

proprietário

(e.g. RealNetworks) proprietary

(e.g., Vonage,Dialpad)

Protocolo de

transporte associado TCP

TCP TCP TCP

TCP or UDP

tipicamente UDP

(22)

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

(23)

Web e HTTP

Inicialmente algumas definições

página Web consiste de objetos

Objeto pode ser um arquivo HTML, imagem JPEG, applet Java, arquivo de áudio, …

Página Web consiste de um arquivo HTML que inclui referências a outros objetos

Cada objeto é endereçável através de uma URL

Exemplo URL:

www.someschool.edu/someDept/pic.gif

Nome do host Nome do caminho (path)

(24)

Descrição do HTTP

HTTP: hypertext transfer protocol

Protocolo de aplicação da Web

Modelo cliente x servidor

cliente: browser usado para requisitar,

receber, apresentar objetos Web

servidor: servidor Web envia objetos em

resposta às requisições

HTTP 1.0: RFC 1945

PC executando Int. Explorer

Servidor executando

Servidor Apache Web Mac executando

Requisição HTTP

Requisição HTTP Resposta HTTP

Resposta HTTP

(25)

Descrição HTTP (continuação)

Utiliza TCP:

Cliente inicia conexão TCP (cria socket) com o

servidor, porta 80

Servidor aceita pedido de conexão TCP do cliente

Troca de mensagens HTTP entre o browser (cliente HTTP) e o servidor Web (servidor HTTP)

encerramento da conexão TCP

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.

(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”

(27)

HTTP Não-Persistente

Suponha 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)

(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

(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 de tranmissão do arquivo Inicia conexão

TCP

RTT Requisita o arquivo

RTT Arquivo recebido

tempo tempo

(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

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

(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.1 Host: www.someschool.edu

User-agent: Mozilla/4.0 Connection: 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

(32)

Mensagem de requisição HTTP: formato

geral

(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

(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

(35)

Mensagem de resposta HTTP

HTTP/1.1 200 OK Connection close

Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix)

Last-Modified: Mon, 22 Jun 1998 …...

Content-Length: 6821 Content-Type: text/html

data data data data data ...

Linha de status

Cabeçalho

dado, e.x., Arquivo HTML

requisitado

(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 servidor

404 Não encontrado

Aparecem na primeira linha da mensagem de resposta servidor ->cliente

Alguns exemplos de códigos:

(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 em cis.poly.edu

telnet cis.poly.edu 80

2. comando de requisição GET HTTP:

GET /~ross/ HTTP/1.1 Host: cis.poly.edu

Ao entrar este comando (bater duas vezes o carriage return), voce envia uma requisição GET mínima mas

completa ao Servidor HTTP

3. Analise a resposta enviada pelo servidor HTTP!

(38)

Olhando o HTTP em ação-Exemplos

Exemplo telnet

Exemplo Wireshark (ferramenta livre de

monitoramento de redes)

(39)

Estado do usuário: cookies

Vários sítios Web utilizam pequenos arquivos

chamados cookies Quatro situações:

1) Cookie é gerado no sítio Web na primeira conexão e guardado em base de dados.

2) Cookie é inserido no

cabeçalho da mensagem de resposta HTTP

3) Cookie é armazenado e

gerenciado pelo browser no host do usuário

4) Cookie é enviado pelo

browser ao servidor a cada nova requisição HTTP

Exemplo:

Susan sempre acessa a

Internet através do mesmo PC

Visita um sítio específico de e-comércio pela primeira vez

Quando a requisição HTTP inicial chega no destino, o sítio cria:

ID único

Entrada na base de dados para o ID

e devolve tais informações na forma de um arquivo cookie.

(40)

Cookies: mantendo o “estado”

cliente servidor

resposta http customizada

Arquivo cookie

Uma semana após:

requisição http cookie: 1678

cookie accesso

ebay 8734 requisição http Servidor Amazon cria ID 1678

para o usuário cria

entrada

resposta http Set-cookie: 1678 ebay 8734

amazon 1678

Base de dados

requisição http cookie: 1678

accesso

(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

(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

(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)

(44)

Exemplo de caching

Servidores de origem

Internet Pública

institucionalRede 10 Mbps LAN Enlace de acesso 1 Mbps

Suponha:

Tamanho médio objeto = 100.000

Taxa média de requisições dos bits 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

(45)

Exemplo de caching (cont)

Solução possível

Aumentar a banda do acesso do enlace para, p. ex., 10 Mbps

consequência

Utilização da LAN =

= 100.000 x 15 / 10.000.000 = 15%

Utilization do enlace de acesso =

= 100.000 x 15 / 10.000.000 = 15%

Atraso total = atraso da LAN + atraso do acesso + atraso Internet

= 10 ms + 10 ms + 2 s = 2,02 s

Trata-se, em geral, de um

“upgrade” caro!

Servidores de origem

Internet Pública

institucionalRede 10 Mbps LAN Enlace de acesso 1 Mbps -> 10 Mbps

(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 + Cache

Servidores de origem

Internet Pública

institucionalRede 10 Mbps LAN Enlace de acesso 1 Mbps

(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 msg If-modified-since: <date>

HTTP response HTTP/1.0 304 Not Modified

Objeto não modificado

HTTP request msg If-modified-since: <date>

HTTP response HTTP/1.1 200 OK

<data>

Objeto modificado

(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

(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 arquivo

Servidor FTP Interface de

usuário FTP

Cliente FTP

Sistema de Arquivo local

Sistema de Arquivo remoto usuário

(50)

FTP: separa fluxo de controle e fluxo de dados

Conexão de controle TCP porta 21

• 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

(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

(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

(53)

Correio eletrônico

Três componentes principais:

Agentes do usuário

Servidores de e-mail

Protocolo de transferência de e-mail: SMTP

Agente do usuário

Conhecido como “leitor de 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 de mensagens de saída

Servidor de e-mail

Agente usuáriodo

SMTP SMTP SMTP

Agente usuáriodo

Agente usuáriodo

Agente usuáriodo

Agente usuáriodo Agente

do

Servidor de e-mail

Servidor de e-mail

(54)

Correio eletrônico: servidores de e-mail

Servidores de e-mail

Mailbox: contém as

mensagens enviadas para o usuário

Fila de mensagens: contém as mensagens de saída (a serem enviadas)

Protocolo SMTP: protocolo tipo cliente-servidor entre os servidores de e-mail para troca de mensagens

“cliente”: servidor emissor do e-mail

Servidor de e-mail

Agente usuáriodo

SMTP SMTP SMTP

Agente usuáriodo

Agente usuáriodo

Agente usuáriodo

Servidor de e-mail

Servidor de e-mail

(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

(56)

Servidor de e-mail Servidor

de e-mail

Cenário: Alice envia mensagens para Bob

1) Alice usa o agente (UA)

para compor a mensagem e enviar “to”

bob@someschool.edu

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 Agentedo

(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: <alice@crepes.fr>

S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu>

S: 250 bob@hamburger.edu ... 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

(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

(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

(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

cabeçalho

body

Linha em branco CRLFCRLF

(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: alice@crepes.fr To: bob@hamburger.edu

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ídia tipo, subtipo, Método usado para codificação do dado Versão MIME

dado codificado

(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)

Servidor de e-mail emissor

SMTP SMTP Protocolo de acesso

Servidor de e-mail receptor

Agente usuáriodo

Agente usuáriodo

(63)

Protocolo POP3

Fase de autorização

Comandos do cliente:

user: declara username

pass: password

Respostas do servidor

+OK

-ERR

Fase de transação, cliente:

list: lista número da mensagem

retr: recupera mensagem pelo número

dele: deleta

quit

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

(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

(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

(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

(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

(68)

Servidores DNS Root

Servidores DNS .com Servidores DNS .org Servidores DNS .edu

Servidores DNS poly.edu

Servidores DNS umass.edu

Servidores

DNS yahoo.com Servidores DNS amazon.com

Servidores DNS pbs.org

Base de dados Hierárquica e distribuída

Cliente deseja IP para www.amazon.com; 1

a

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

(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, CA

f 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, VA

c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA

h ARL Aberdeen, MD j Verisign, ( 21 locations)

(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.

Network Solutions mantém servidores TLD .com

Educause mantém TLD .edu

Servidores DNS autoridades:

Servidores DNS das organizações são autoridades para

fornecimento do mapeamento IP para o nome dos servidores da organização (e.x., Web, mail).

Podem ser mantidos pelas organizações ou pelo provedor de serviço

(71)

Servidor de Nome Local

Na verdade, não pertence à hierarquia do DNS

cada ISP (ISP residencial, empresa, universidade) possui um.

Também chamado de “default name server”

Quando um host faz uma consulta DNS, a consulta é encaminhada ao seu servidor DNS local

Atua como um proxy encaminhando a consulta na hierarquia

(72)

requesting host

cis.poly.edu

root DNS server

local DNS server

dns.poly.edu

1

2 3

4 5

6

authoritative DNS server dns.cs.umass.edu

8 7

TLD DNS server

Exemplo de resolução de nome através do DNS

Host em cis.poly.edu deseja o endereço IP para

gaia.cs.umass.edu Consulta iterativa:

Servidor contactado responde com o nome do servidor a ser

contactado

“Eu não conheço este nome mas pergunte a

(73)

requesting host

cis.poly.edu

gaia.cs.umass.edu

root DNS server

local DNS server

dns.poly.edu

1

2

5 4 6

authoritative DNS server dns.cs.umass.edu

7

8

TLD DNS server

Consulta recursiva:

3

Transfere o ônus da resolução de nome ao servidor contactado

Exemplo de resolução de nome DNS

(74)

DNS: caching e atualização dos registros

Uma vez que qualquer servidor de nomes aprende um mapeamento, ele faz o cache deste mapeamento

As entradas do cache possuem validade por um tempo (timeout) desaparecendo após

expirado este tempo

Parte do conteúdo dos servidores TLD em geral encontra-se no cache dos servidores locais

• Isso evita a necessidade de contactar os

(75)

Registros DNS

DNS: base de dados distribuída armazenando “resource records” (RR)

Type=NS

Nome é domínio (e.x. foo.com)

Valor é o hostname do servidor autoridade para este domínio

Formato RR:

(name, value, type, ttl)

Type=A

Nome é hostname

Valor é endereço IP

Type=CNAME

name é um alias para algum nome canônico (nome real)

www.ibm.com é, na realidade,

servereast.backup2.ibm.com

Valor corresponde ao nome canônico

Type=MX

value é o nome do servidor de e-mail associado ao name

(76)

DNS: protocolo, mensagens

Protocolo DNS : mensagens de consulta e

resposta, ambas possuem o mesmo formato Cabeçalho da mensagem

identificação: 16 bits para consulta; resposta usa o mesmo

identificador

flags:

consulta ou resposta

demanda de recursão

recursão disponível

(77)

DNS: protocolo, mensagens

Nome, tipo da consulta

RRs na resposta a uma consulta Registros para servidores autoridades

Informação adicional

(78)

Inserindo registros no DNS

Exemplo: novo domínio “Network Utopia”

Registro do nome networkuptopia.com no DNS (e.g., Network Solutions)

Fornece nome e endereço IP do servidor de nomes autoridade (deve haver primário e secundário)

É preciso inserir 2 registros RRs no servidor TLD:

(networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)

Criar registros do Tipo A no servidor autoridade para

o servidor web www.networkutopia.com e do Type MX

(79)

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

(80)

P2P: Compartilhamento de arquivo

Exemplo

Alice executa uma aplicação P2P no seu notebook

Intermitentemente

conecta-se à Internet;

obtém um novo endereço IP a cada acesso

Pergunta por “Hey Jude”

A aplicação informa outros “peers” que

possuem uma cópia de Hey

Alice escolhe um dos

“peers”, Bob.

Uma cópia do arquivo é

trazida do PC do Bob para o notebook da Alice: HTTP

Enquanto Alice faz o

download, outros usuários realizam uploading do

notebook da Alice.

Os pares da Alice são,

simultaneamente, um cliente e um Servidor.

Todos os pares são servidores

= alta escalabilidade!

(81)

P2P: diretório centralizado

Projeto original do “Napster”

1) Quando um peer conecta- se, ele informa ao

servidor central:

Endereço IP

conteúdo

2) Alice pergunta por “Hey Jude”

3) Alice requisita arquivo da máquina do Bob

centralized directory server

peers

Alice

Bob

1

1

1 2 1

3

(82)

P2P: problemas relacionados a um diretório centralizado

Ponto único de falha

Gargalo no desempenho

Problemas de copyright: a ação da lei é óbvia

A transferência do arquivo é descentralizada, mas a localização do conteúdo é altamente centralizada

(83)

Gnutella: inundação

Completamente distribuída

Não possui servidor central

Protocolo de domínio público

Muitos clientes

Gnutella implementam o protocolo

Rede overlay: grafo

Arco entre os pares X e Y caso exista uma

conexão TCP entre eles

Todos os pares ativos e os arcos formam uma rede overlay

arco: enlace virtual (não físico)

Um “peer” conecta-se, tipicamente, com < 10 vizinhos overlay.

(84)

Gnutella: protocolo

Query QueryHit

Query

Query QueryHit

Query

Query QueryHit

File transfer:

HTTP

mensagem de query nas conexões TCP existentes

os pares encaminham a mensagem de Query

mensagem de QueryHit

enviada no caminho reverso

Escalabilidade:

Limitada pelo esquema

(85)

Gnutella: associação do Peer

1.

Ao associar-se, o peer Alice precisa encontrar um outro peer Gnutella na rede: utiliza a lista de candidatos a “peers”

2.

Alice tenta, sequencialmente, conexões TCP com os candidatos “peers” até o “set up” com Bob

3.

Flooding: Alice envia mensagem de Ping para Bob; Bob encaminha a mensagem para os seus vizinhos overlay.

Pares ao receberem a mensagem Ping de Alice respondem com mensagem Pong

4.

Alice recebe várias mensagens do tipo Pong e pode, portanto, estabelecer conexões

TCP adicionais

Desassociação de um Peer: veja a lista de

exercícios!

(86)

Overlay Hierárquico

Situa-se entre a indexação centralizada e a abordagem baseada em inundação

Cada peer é um líder de grupo ou é atribuído a um líder de grupo.

Conexão TCP entre o peer e o seu líder de grupo.

Conexões TCP entre alguns pares de líderes de grupo.

Líder de grupo pesquisa o

conteúdo no seus liderados Peer comum

(87)

P2P Estudo de caso: Skype

P2P (pc-to-pc, pc- to-phone, phone-to- pc) Voice-Over-IP (VoIP)

também IM

Protocolo proprietário (algumas pistas

obtidas via

engenharia reversa)

Overlay hierárquico

Clientes Skype (SC)

Super nó (SN)

Skype

Servidor de login

(88)

Skype: Realizando uma chamada

Usuário inicia o Skype

Skype login server

SC registra-se no SN

Lista de SNs de bootstrap

SC realiza o login (authenticate)

Call: SC contacta o SN e fornece o ID do destino

SN contacta outros SNs

(protocolo desconhecido, talvez por inundação) para encontrar o addr do destino; retorna o addr

(89)

Estudo de Caso P2P: BitTorrent

tracker: registra os peers participantes de um torrent

torrent: grupo de peers que estão trocando pedaços de um arquivo

Obtém a

lista de peers

Negociando partes do arquivo

peer

Distribuição de arquivo P2P

(90)

BitTorrent (1)

O arquivo é divido em pedaços (chunks) de 256KB.

Peer ao associar-se a um torrent:

Não possui “chunks”, mas irá acumulá-los com o tempo

Registra-se com o “tracker” para obter a lista dos “peers” e conecta-se ao sub-conjunto dos pares (“neighbors”)

Enquanto faz o download, o peer realiza o upload para outros pares.

Peers podem ir e vir

Imagem

Referências

temas relacionados :