Capítulo 2 Camada de Aplicação

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

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

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

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

•

…

•

…

•

…

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

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

Arquiteturas de aplicação

•

Cliente-Servidor

•

Peer-to-peer (P2P)

•

Híbrido de Cliente-Servidor e P2P

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

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

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

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”

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

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)

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?

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

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

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

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

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

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

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

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)

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

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.

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”

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)

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

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

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

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

Mensagem de requisição HTTP: formato

geral

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

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

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

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:

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!

Olhando o HTTP em ação-Exemplos

•

Exemplo telnet

•

Exemplo Wireshark (ferramenta livre de

monitoramento de redes)

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.

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

DNS: protocolo, mensagens

Nome, tipo da consulta

RRs na resposta a uma consulta Registros para servidores autoridades

Informação adicional

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

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

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!

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

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

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.

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

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!

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}

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

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

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

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