capítulo 2: camada de aplicação capítulo 2: roteiro princípios das aplicações de rede –...

1

Capítulo 2: Camada de Aplicação

Metas do capítulo: ● aspectos conceituais e de

implementação de protocolos de aplicação em redes– paradigma cliente

servidor– modelos de serviço

● aprender sobre protocolos através do estudo de protocolos populares do nível da aplicação

Mais metas do capítulo● protocolos específicos:

– HTTP– FTP– SMTP / POP3 / IMAP– DNS

● a programação de aplicações de rede– programação usando sockets

2

Capítulo 2: Roteiro

● Princípios das aplicações de rede– Arquitetura da aplicação– Comunicação entre processos– O que definem os protocolos da camada de aplicação– Quais os serviços demandados pela aplicação– Serviços fornecidos pelos protocolos de transporte–

3

Lista de aplicações populares

● email● bate-papo● Redes sociais● gamming on-line● web● ....

4

Paradigma cliente-servidor (C-S)

Apl. de rede típica tem duas partes: cliente e servidor aplicação

transporterede

enlacefísica

aplicaçãotransporte

redeenlacefísica

Cliente:➘ inicia contato com o servidor (“fala

primeiro”)➘ solicita serviço do servidor➘ para WWW, cliente implementado

no browser; para correio no leitor de mensagens

Servidor:➘ provê ao cliente o serviço requisitado➘ p.ex., servidor WWW envia página

solicitada; servidor de correio entrega mensagens

pedido

resposta

5

• Não há um ponto central que oferece um serviço;

• Pares de Sistemas finais quaisquer se comunicam diretamente;

• Pares têm autonomia para escolher com quem eles vão se conectar;

● Conexão e desconexão são eventos corriqueiros.

• Ex.: Gnutella, BitTorrent

Altamente escaláveis mas difíceis de gerenciar

Paradigma Par a par (P2P)

6

Napster• Transferência de arquivo P2P• Busca centralizada de arquivos:

• Conteúdo de registro dos pares no servidor central• Consulta de pares no mesmo servidor central para localizar o

conteúdo

Instant messaging• Bate-papo entre dois usuários é P2P• Detecção/localização centralizada de presença:

• Usuário registra seu endereço IP com o servidor central quando fica on-line

• Usuário contata o servidor central para encontrar endereços IP dos vizinhos

Híbrida de cliente-servidor e P2P

7

Comunicação entre processos na rede➘ processos se comunicam enviando

ou recebendo mensagens através de um socket (TOMADA);

➘ socket➼ O processo emissor joga a

mensagem por seu socket;➼ O processo emissor assume

que há uma infra-estrutura de transporte no lado oposto do socket que irá transmitir a mensagem até o socket do processor receptor;

processo

TCP combuffers,Variáveis

socket

host ou servidor

processo

TCP combuffers,Variáveis

socket

host ou servidor

Internet

Controlado pelo OS

Controlado pelo Desenvolvedor da aplicação

➘ API: (1) escolhe do protocolo de transporte; (2) habilidade para fixar alguns parâmetros (voltamos mais tarde a este assunto)

8

Identificando processos:➘ Para que um processo

possa receber mensagens, ele precisa ter um identificador;

➘ Cada host tem um endereço único de 32(IPv4)/128(IPv6) bits – endereço IP;

➘ Q: O endereço IP de um host no qual um processo está executando é suficiente para identificar este processo?

➘ Resposta: Não, muitos processos podem estar em execução em um mesmo host

➘ O identificador inclue tanto o endereço IP como também o número de porta associado com o processo no host;

➘ Exemplo de número de portas:

➼ Servidor HTTP: 80➼ Servidor de Correio: 25

➘ Voltaremos a este assunto mais tarde

9

Exemplo: Tráfego Capturado, IPs e Portas

10

Comunicação entre processos: Contextualizando

➘ Um processo é um programa que executa num hospedeiro (host).

➘ 2 processos no mesmo hospedeiro se comunicam usando comunicação entre processos definida pelo sistema operacional (SO).

➘ 2 processos em hospedeiros distintos se comunicam usando um protocolo da camada de aplicação.

11

Camada de aplicação define:➘ Tipo das mensagens

trocadas: ex, mensagens de requisição & resposta

➘ Sintaxe das mensagens: quais os campos de uma mensagem & como estes são delineados;

➘ Semântica dos campos: qual o significado das informações nos campos;

➘ Regras: definem quando e como os processos enviam & respondem mensagens;

Protocolos de domínio público:

➘ Definidos por RFCs➘ Garante

interoperabilidade➘ ex, HTTP, SMTPProtocolos proprietários:➘ ex, Skype

12

Aplicações e protocolos da camada de aplicação

Aplicação: processos distribuídos em comunicação

– executam em hospedeiros no “espaço de usuário”

– trocam mensagens para implementar a aplicação

– p.ex., correio, transf. de arquivo, WWW

Protocolos da camada de aplicação– uma “parte” da aplicação– define mensagens trocadas por apls

e ações tomadas– usam serviços providos por

protocolos de camadas inferiores (TCP, UDP)


redeenlacefísica


redeenlacefísica


redeenlacefísica

13

De que serviço de transporte uma aplicação precisa?

Transferência Confiável de dados

● algumas apls (p.ex. áudio) podem tolerar algumas perdas

● outras (p.ex., www, email) requerem transferência 100% confiável

Timing (Sensibilidade temporal)

● algumas apls (p.ex., telefonia Internet, jogos interativos) requerem baixo retardo para serem “viáveis”

Largura de banda➘ algumas apls (p.ex.,

multimídia) requerem quantia mínima de banda para serem “viáveis”

➘ outras apls (“apls elásticas”) conseguem usar qualquer quantia de banda disponível

Segurança➘ Garantir sigilo as mensagens

transportadas.➘ Integridade dos dados

14

Requisitos do serviço de transporte de apls comuns

Aplicação

transferência de arqscorreio

documentos WWWáudio/vídeo de

tempo realáudio/vídeo gravado

jogos interativosapls financeiras

Whatsapp

Perdas

sem perdassem perdassem perdastolerante

tolerantetolerantesem perdas

Banda

elásticaelásticaelásticaáudio: 5Kb-1Mbvídeo:10Kb-5Mbcomo anterior> alguns Kbpselástica

Sensibilidade temporal

nãonãonãosim, 100’s mseg

sim, alguns segssim, 100’s msegsim e não

15

Serviços providos por protocolos de transporte Internet

serviço TCP:● orientado a conexão: negociação e

definição da conexão (setup) requerida entre cliente, servidor

● transporte confiável entre processos remetente e receptor

● controle de fluxo: remetente não vai sobrecarregar o receptor

● controle de congestionamento: reduz a atividade do remetente quando a rede está sobrecarregada

● não provê: garantias temporais ou de banda mínima

serviço UDP:● transferência de dados não

confiável entre processos remetente e receptor

● não provê: setup da conexão, confiabilidade, controle de fluxo, controle de congestionamento, garantias temporais ou de banda mínima

P: Qual é o interesse em ter um UDP?

16

Apls Internet: seus protocolos e seus protocolos de transporte

Aplicação Protocolo Aplicação Protocolo Transporte

correio eletrônico smtp [RFC 821] TCP

accesso terminal remoto

telnet [RFC 854] TCP

WWW http [RFC 2068] TCP

transferência de arquivos

ftp [RFC 959] TCP

streaming multimídia proprietário(p.ex. RealNetworks)

TCP ou UDP

servidor de arquivo remoto

NFS TCP

telefonia Internet Proprietário, Aberto(p.ex., Skype, Hangout)

UDP ou TCP

17

WWW e HTTP: conceitos

● Página WWW:– consiste de “objetos”– endereçada por uma URL

● Quase todas as páginas WWW consistem de:– página base HTML, e– vários objetos referenciados.

● URL tem duas partes: nome de hospedeiro, e nome de caminho:

● Agente de usuário para WWW se chama de browser:– Internet Explorer– Firefox, Chrome

● Servidor para WWW se chama “servidor WWW”:– Apache (domínio público)– MS Internet Information

Server (IIS)

18

Protocolo HTTP: visão geral

HTTP: hypertext transfer protocol

● protocolo da camada de aplicação para WWW

● modelo cliente/servidor– cliente: browser que

pede, recebe, “visualiza” objetos WWW

– servidor: servidor WWW envia objetos em resposta a pedidos

● http1.0: RFC 1945● http1.1: RFC 2616

PC executaExplorer

Servidor executandoservidor WWW

do ICOMPMac executa

Navigator

pedido http

pedido http

resposta http

resposta http

19

Mais sobre o protocolo HTTP

HTTP: serviço de transporte TCP:

● cliente inicia conexão TCP (cria socket) ao servidor, porta 80

● servidor aceita conexão TCP do cliente

● mensagens HTTP são trocadas entre browser e servidor WWW

● encerra conexão TCP

HTTP é “sem estado”● servidor não mantém

informação sobre pedidos anteriores do cliente

Protocolos que mantêm “estado” são complexos!

➘ história passada (estado) tem que ser guardada

➘ Caso servidor/cliente parem de executar, suas visões do “estado” podem ser inconsistentes, devendo então ser reconciliadas

Nota

20

Conexões HTTPHTTP: não persistente➘ No máximo um objeto

é enviado em uma conexão TCP;

➘ HTTP/1.0 usa conexões não persistentes

HTTP: persistente➘ Múltiplos objetos podem

ser enviados numa única conexão TCP entre o servidor e o cliente;

➘ HTTP/1.1 usa conexões persistentes no modo default;

21

Ex: HTTP não-persistenteSupondo que usuário digita a URL

www.algumauniv.br/algumdepartamento/inicial.index

1a. Cliente http inicia conexão TCP com o servidor http (processo) www.algumauniv.br. Porta 80 é padrão para servidor http.

2. cliente http envia mensagem de pedido de http (contendo URL) através do socket da conexão TCP. A mensagem indica que o cliente deseja o objeto algumdepartamento/inicial.index

1b. servidor http no hospedeiro www.algumauniv.br espera por conexão TCP na porta 80. “aceita” conexão, avisando ao cliente

3. servidor http recebe mensagem de pedido, formula mensagem de resposta contendo objeto solicitado (algumdepartamento/inicial.index), envia mensagem via sockettempo

(contém texto, referências a 10

imagens jpeg)

22

Ex: HTTP não-persistente (cont.)

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 jpeg

4. servidor http encerra conexão TCP .

tempo

23

Tempo de RespostaDefinição de RTT: tempo gasto

para um pacote viajar entre cliente E servidor em caminho completo;

Tempo de resposta:➘ um RTT para iniciar a conexão

TCP➘ um RTT para a requisição HTTP

e para que alguns bytes da resposta HTTP sejam recebidos

➘ tempo de transmissão do arquivo

total = 2RTT+tempo de transmissão

Tempo para transmitir arquivo

Inicia conexão TCP RTT

requisição do arquivo

RTT

Arquivo recebido

tempo tempo

24

Para o caso de conexões HTTP não-persistente

➘ servidor analisa pedido, responde, e encerra conexão TCP ➘ requer 2 RTTs para trazer cada objeto

➘ mas os browsers geralmente abrem conexões TCP paralelas para trazer cada objeto

25

Para o caso de conexões HTTP persistente➘ servidor mantém conexão aberta

depois de enviar a resposta;

➘ mensagens HTTP subsequentes entre os mesmos cliente/servidor são enviadas por esta conexão;

➘ na mesma conexão TCP: servidor analisa pedido, responde, analisa novo pedido e assim por diante

Persistente sem pipelining:➘ Cliente só faz nova

requisição quando a resposta de uma requisição anterior foi recebida;

➘ um RTT para cada objetoPersistente com pipelining:➘ default in HTTP/1.1➘ O cliente envia a requisição

assim que encontra um objeto;

➘ Um pouco mais de um RTT para trazer todos os objetos

26

Mensagem de pedido HTTP: formato geral

29

Formato de mensagem HTTP: pedido

● Dois tipos de mensagem HTTP: pedido, resposta● mensagem de pedido HTTP:

– ASCII (formato legível por pessoas)

GET /diretorio/pagina.html HTTP/1.1 Host: www.ufam.edu.brConnection: closeUser-agent: Mozilla/5.0 Accept-language:En-us,us;

(carriage return (CR), line feed(LF) adicionais)

linha do pedido

linhas docabeçalho

Carriage return, line feed indica fim

de mensagem

30

Formato de mensagem HTTP: resposta

HTTP/1.1 200 OK Date: Thu, 01 Jun 2016 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 May 2016 …... Content-Length: 6821 Content-Type: text/html dados dados dados dados ...

linha de status(protocolo,

código de status,frase de status)

linhas decabeçalho

dados, p.ex., arquivo html

solicitado

31

Códigos de status da resposta HTTP

200 OK– sucesso, objeto pedido segue mais adiante nesta mensagem

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

404 Not Found– documento pedido não se encontra neste servidor

505 HTTP Version Not Supported– versão de http do pedido não usada por este servidor

Na primeira linha da mensagem de resposta servidor->cliente. Alguns códigos típicos:

32

Bad Request, Exemplo

33

Bad Request, Real Exemplo

34

Bad Request, Corrigido

35

Interação usuário-servidor: GET condicional

● Meta: não enviar objeto se cliente já tem (no cache) versão atual

● cliente: especifica data da cópia no cache no pedido httpIf-modified-since:

<date>● servidor: resposta não contém

objeto se cópia no cache é atual: HTTP/1.1 304 Not

Modified

cliente servidor

msg de pedido httpIf-modified-since:

<date>

resposta httpHTTP/1.1

304 Not Modified

objeto não

modificado

msg de pedido httpIf-modified-since:

<date>

resposta httpHTTP/1.1 200 OK

…<data>

objeto modificado

40









41

FTP: o protocolo de transferência de arquivos

● 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

transferênciado arquivo FTP

servidor

Interface do usuário

FTP

cliente FTP

sistema de arquivos local

sistema de arquivos remoto

usuário na

estação

42

FTP: conexões separadas p/ controle, dados

● Cliente FTP contacta servidor ftp na porta 21, especificando TCP como protocolo de transporte

● Cliente obtem autorização através da conexão de controle;

● O cliente acessa o diretório remoto através do envio de comandos pela conexão de controle;

● Quando o servidor recebe um comando para transferência de arquivo, o servidor abre uma conexão TCP com o cliente;

● Depois de transferir o arquivo a conexão é finalizada;

cliente FTP

servidor FTP

conexão de controleTCP, porta 21

conexão de dados TCP, porta 20

➘ são abertas duas conexões TCP paralelas:

➼ controle: troca comandos, respostas entre cliente, servidor.

“controle fora da banda”➼ dados: dados de arquivo

de/para servidor

43

FTP: comandos, respostas

Comandos típicos:● enviados em texto ASCII pelo canal

de controle● USER nome● PASS senha● LIST devolve lista de arquivos no

directório corrente● RETR arquivo recupera (lê)

arquivo remoto● STOR arquivo armazena

(escreve) arquivo no hospedeiro remoto

Códigos de retorno típicos● código e frase de status (como para

http)● 331 Username OK,

password required● 125 data connection

already open; transfer starting

● 425 Can’t open data connection

● 452 Error writing file

44

FTP e a Segurança

● SFTP – usa o protocolo SSH para criar um canal seguro de transferência de arquivos– Usa apenas a porta 22

● FTPS – usa o protocolo SSH + certificados digitais– Usa portas 21 e outras criadas acima de 1024.

45









46

Correio Eletrônico

Três grandes componentes: ● agentes de usuário (AU) ● servidores de correio● SMTP: simple mail transfer

protocol

Agente de Usuário● a.k.a. “leitor de correio”● compor, editar, ler mensagens de

correio● p.ex., Eudora, Outlook,

ThunderBird● mensagens de saída e chegada são

armazenadas no servidor

caixa de correio do usuário

fila demsg de saída

agente de

usuário

servidor de correio

agente de

usuário

SMTP

SMTP

SMTP

agente de

usuário

agente de

usuário

agente de

usuárioagente de

usuário

servidor de correio

servidor de correio

47

Correio Eletrônico: servidores de correio

Servidores de correio ● caixa de correio contém

mensagens de chegada (ainda não lidas) p/ usuário

● fila de mensagens contém mensagens de saída (a serem enviadas)

● protocolo SMTP entre servidores de correio para transferir mensagens de correio– cliente: servidor de correio

que envia– “servidor”: servidor de

correio que recebe

servidor de correio

agente de

usuário

SMTP

SMTP

SMTP

agente de

usuário

agente de

usuário

agente de

usuárioagente de

usuário

servidor de correio

servidor de correio

48

Protocolos de accesso ao correio

● SMTP: entrega/armazenamento no servidor do receptor● protocolo de accesso 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.

servidor de correio do remetente

SMTP SMTP POP3 ouIMAP

servidor de correiodo receptor

agente de

usuário

agente de

usuário

49

Cenário: Alice envia msg para Bob1) Alice usa AU para compor a

mensagem e enviá-la para [email protected]

2) O AU da Alice envia a mensagem para o seu servidor de correio; a msg é colocada na fila de mensagens;

3) O cliente SMTP abre uma conexão TCP com o servidor de correio do Bob

4) SMTP cliente envia a msg da Alice através da conexão TCP;

5) Servidor de correio de Bob coloca a msg na caixa de correio de Bob;

6) Bob invoca o seu AU para ler a sua msg;

agente usuário

servidorcorreio

servidorcorreio agente

usuário

1

2 3 4 56

50

Interação SMTP típica S: 220 doces.br C: HELO consumidor.br S: 250 Hello consumidor.br, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Voce gosta de chocolate? C: Que tal sorvete? C: . S: 250 Message accepted for delivery C: QUIT S: 221 doces.br closing connection

51

Correio Eletrônico: SMTP [RFC 821]

● 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 (apresentação)– 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

52

Experimente você uma interação SMTP :

● telnet nomedoservidor 25● veja resposta 220 do servidor● entre comandos HELO, MAIL FROM, RCPT TO, DATA,

QUIT

estes comandos permite que você envie correio sem usar um cliente (leitor de correio)

53

SMTP: últimas palavras

● SMTP usa conexões persistentes● smtp requer que a mensagem

(cabeçalho e corpo) sejam em ASCII de 7-bits

● algumas cadeias de caracteres não são permitidas numa mensagem (p.ex, acentos(é)). Logo a mensagem pode ter que ser codificada (normalmente em base-64 ou “quoted printable”)

● servidor SMTP usa CRLF.CRLF para reconhecer o final da mensagem

Comparação com http● HTTP : pull (puxar)● email: push (empurrar)

● ambos tem interação comando/resposta, códigos de status em ASCII

● HTTP: cada objeto é encapsulado em sua própria mensagem de resposta

● SMTP: múltiplos objetos de mensagem enviados numa mensagem de múltiplas partes

54

Formato de uma mensagem

SMTP: protocolo para trocar msgs de correio

RFC 822: padrão para formato de mensagem de texto:

● linhas de cabeçalho, p.ex.,– To:– From:– Subject:

diferentes dos comandos de SMTP!

● corpo– a “mensagem”, somente de

caracteres ASCII

cabeçalho

corpo

linha em branco

55

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: [email protected] To: [email protected]: Imagem de uma bela torta MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg

base64 encoded data ..... ......................... ......base64 encoded data

tipo, subtipo dedados multimídia,

declaração parâmetros

método usadop/ codificar dados

versão MIME

Dados codificados

56

Tipos MIME Content-Type: tipo/subtipo; parâmetros

Text● subtipos exemplos: plain, html

● charset=“iso-8859-1”, ascii

Image● subtipos exemplos : jpeg, gif

Video● subtipos exemplos : mpeg, quicktime

Audio● subtipos exemplos : basic

(8-bit codificado mu-law), 32kadpcm (codificação 32 kbps)

Application● outros dados que precisam ser

processados por um leitor para serem “visualizados”

● subtipos exemplos : msword, octet-stream

57

Tipo MultipartFrom: [email protected] To: [email protected]: Imagem de uma bela torta MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789Content-Transfer-Encoding: quoted-printableContent-Type: text/plain

caro Bernardo, Anexa a imagem de uma torta deliciosa.--98766789Content-Transfer-Encoding: base64Content-Type: image/jpeg

base64 encoded data ..... ......................... ......base64 encoded data --98766789--

58

IMAP

➘ Usa o modo: “ler-e-guardar” que posibilita acessar mensagens de vários clientes;

➘ Mantém todas as mensagens em um único lugar: servidor;➘ Permite que o usuário organize suas msgs em pastas remotas

como se fosse locais;➘ IMAP mantém estado dos usuários durante as sessões:

➼ Nomes e pastas e mapeia os IDs das msgs e o nome das pastas;

59

Protocolo POP3

fase de autorização● comandos do cliente:

– user: declara nome– pass: senha

● servidor responde– +OK– -ERR

fase de transação, cliente:● list: lista números das msgs● retr: recupera msg por

número● dele: apaga msg● 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 ana S: +OK C: pass faminta S: +OK user successfully logged on

60

DNS: Domain Name System

Pessoas: muitos identificadores:– CPF, nome, no. da Identidade

hospedeiros, roteadores Internet :

– endereço IP (32 bit) - usado p/ endereçar datagramas

– “nome”, ex., solimoes.icomp.ufam.edu.br - usado por gente

P: como mapear entre nome e endereço IP?

Domain Name System:● base de dados distribuída

implementada na hierarquia de muitos servidores de nomes

● protocolo de camada de aplicação permite que hospedeiros, roteadores, servidores de nomes se comuniquem para resolver nomes (tradução endereço/nome)– note: função imprescindível da

Internet implementada como protocolo de camada de aplicação

– complexidade na borda da rede

61

DNS

● Roda sobre UDP e usa a porta 53

● Especificado nas RFCs 1034 e 1035 e atualizado em outras RFCs.

● Outros serviços:– apelidos para hospedeiros

(aliasing)– apelido para o servidor de

mails– distribuição da carga

62

Servidores de nomes DNS

A dinâmica de comunicação➘ Cliente faz requisição usado UDP;➘ Servidor responde após algum atraso.Por que não centralizar o DNS? mas antes...

● ponto único de falha● volume de tráfego● base de dados centralizada e distante● manutenção (da BD)

Não é escalável!

63


O Princípio: Nenhum servidor mantém todos os mapeamentos nome-para-endereço IP.

A dinâmica geral: ● Cliente DNS consulta servidor raiz;● Cliente DNS consulta servidor TLD;● Cliente DNS consulta servidor oficial.

64


servidores raiz(root DNS servers):– São 13 ao todo;– Conhecem endereços dos servidores TLD

66


servidores de nomes oficial(authoritative DNS servers):– responde por solicitações DNS para uma organização (amazon.com,

google.com);– guarda nome, endereço IP de hospedeiros;– pode realizar tradução nome/endereço.

servidor TLD(Top-Level Domain DNS servers): ➼ tem conhecimento de domínios de último nível(.com, .edu,

.gov, .org, e .net);➼ tem também conhecimento dos domínios de último nível do

tipo país(.br, .fr, .it, .uk, e .ca)

67

Mas e Mais...Servidor DNS Local

➘ Não pertence a hierarquia de servidores DNS;

➘ Cada provedor, empresa tem um servidor de nomes local (default);

● Pedido DNS de hospedeiro vai primeiro ao servidor de nomes local;

68

Exemplo simples do DNS

hospedeiro vod.icomp.ufam.edu.br requer endereço IP de www.cs.columbia.edu;

solicitantevod.icomp.ufam.edu.br

www.cs.columbia.edu

servidor de nomes raiz

servidor oficialdns.columbia.edu

servidor localmutum.ufam.edu.br

1

23

4

5

6

7

8

servidor TLD

69

Exemplo de DNS

Servidor TLD:● pode não conhecer o

servidor de nomes oficial

● pode conhecer servidor de nomes intermediário: a quem contatar para descobrir o servidor de nomes oficial


www.cs.columbia.edu


1

2

56

7

4

servidor oficialcs.columbia.edu

servidor intermediáriosaell.cc.columbia.edu

3

10

servidor de nomes raiz

servidor TLD

9

8

70

Práticas: NSLOOKUP

● Determine o nome canônico do seu servidor de e-mail● Descubra o nome do servidor web do icomp● Realize, por 5 vezes, a resolução de www.google.com

– Quantos endereços IP diferentes foram informados nas suas consultas?

– Se foi mais de um, que tipo de serviço o DNS está prestando?

71

DNS: Tipos de Consultas

consulta recursiva:● transfere a

responsabilidade de resolução do nome para o servidor de nomes contatado

consulta interativa:● servidor consultado

responde com o nome de um servidor de contato

● “Não conheço este nome, mas pergunte para esse servidor”

1

23

4

5 6

7

8

consulta interativa

servidor de nomes raíz


servidor intermediáriosaell.cc.columbia.edu

servidor oficialcs.columbia.edu


www.cs.columbia.edu

72

DNS: uso de cache, atualização de dados

● uma vez que um servidor qualquer aprende um mapeamento, ele o coloca numa cache local– futuras consultas são resolvidas usando dados da

cache– entradas na cache são sujeitas a temporização

(desaparecem depois de um certo tempo)ttl = time to live (sobrevida)

73

Registros DNS

DNS: BD distribuído contendo registros de recursos (RR)

● Tipo=NS– nome é domínio (p.ex.

foo.com.br)– valor é endereço IP de

servidor oficial de nomes para este domínio

formato RR: (nome, valor, tipo, sobrevida)

➘ Tipo=A➼ nome é nome de hospedeiro➼ valor é o seu endereço IP

➘ Tipo=CNAME➼ nome é nome alternativo

(alias) para algum nome “canônico” (verdadeiro)

➼ valor é o nome canônico

➘ Tipo=MX➼ nome é domínio ➼ valor é nome do servidor de

correio para este domínio

74

DNS: protocolo e mensagens

protocolo DNS: mensagens de pedido e resposta, ambas com o mesmo formato de mensagem

cabeçalho de msg➘ identificação: ID de 16 bit

para pedido, resposta ao pedido usa mesmo ID

➘ flags:➼ pedido ou resposta➼ recursão desejada➼ recursão permitida➼ resposta é oficial

75

DNS: protocolo e mensagens

campos de nome, e de tipo num pedido

RRs em respostaao pedido

registros para outrosservidores oficiais

info adicional “relevante” que pode ser usada:

O caso da consulta de MX

http://www.cs.columbia.edu/

76







– HTTP– FTP– SMTP / POP3 / IMAP– DNS– P2P


77

Arquitetura P2P Pura

● Não requer servidor sempre conectado

● Comunicação entre sistemas finais ocorre diretamente

● Pares estão conectados de forma intermitente e mudam de endereço IP

● Três tópicos:– Distribuição de Arquivo– Busca pela informação– Skype: Caso de Estudo

peer-peer

http://www.google.com/

78

Tempo de distribuição do arquivo: C-S

us

u2d1 d2u1

uN

dN

Servidor

Rede(com banda abundante)

F● Servidor envia N cópias

sequencialmente:– NF/us segundos

● cliente i leva F/di segundos para efetuar download

Aumenta linearmente com N(para N grande)

= dcs = max { NF/us, F/min(di) }i

Tempo para distribuir F para N clientes usando Abordagem c-s

79

Distribuição de Arquivo: C-S vs P2P

Questão : Quanto tempo para distribuir um arquivo de UM servidor para N pares?

us

u2d1 d2u1

uN

dN

Servidor

Rede (com banda abundante)

Arquivo, tamanho F

us: banda de upload servidor

ui: banda de upload do par i

di: Banda de download do par i

80

Tempo de distribuição do arquivo: P2P

us

u2d1 d2u1

uN

dN

Servidor

Rede (com Banda abundante)

F● servidor deve enviar uma

cópia: F/us segundos ● cliente i leva F/di segundos

para realizar download● NF bits deve ser baixados

(agregado)❒ A taxa de upload do sistema: us + Σui

dP2P = max { F/us, F/min(di) , NF/(us + Σui) }i

81

C-S vs. P2P: ExemploTaxa upload dos Clientes = u, F/u = 1 hora, us = 10u, dmin ≥ us

82

Distribuição de Arquivo: BitTorrent

tracker: registra pares participam no torrent

torrent: grupo de pares trocando pedaços de arquivos

obtém listade pares

Troca de chunks

par

❒ Distribuição de arquivo P2P

83

BitTorrent (1)

Arquivo dividido em chunks de 256KB.● par junta-se ao torrent:

– Não possui chunks, mas irá acumulá-los ao longo do tempo– Registra-se no tracker para obter a lista de pares, conecta-se

ao subconj de pares (“vizinhos”)● Enquanto faz download, par faz upload de chunks para outros

pares. ● Pares podem entrar e sair● Uma vez que um par possui o arquivo inteiro, ele pode (egoísta)

sair ou (altruísta) permanecer

84

BitTorrent (2)

Obtendo Chunks● Em qq instante de tempo,

diferentes pares possuem diferentes subconjuntos de chunks do arquivo;

● periodicamente, um par(Alice) pergunta para cada vizinho pela lista de chunks que eles possuem;

● Alice envia requisições para os chunks que estão faltando– Os raros têm prioridade

Enviando Pedaços: tit-for-tat❒ Alice envia chunks para quatro

vizinhos atualmente enviando a ela chunks a altas taxas Re-avalia os top 4 a cada 10

segs.❒ Cada 30 segs: seleciona

randomicamente outro par, inicia envio de chunks O novo par escolhido pode se

juntar aos “top 4” “optimistically unchoke”

85

BitTorrent: Tit-for-tat, como funciona???

86

BitTorrent: Tit-for-tat(1) Alice “optimistically unchokes” Bob(2) Alice torna-se um dos fornecedores “top 4” de Bob; Bob mostra reciprocidade(3) Bob torna-se um dos fornecedores “top 4” de Alice

Com altas taxas de upload,pode-se achar melhores parceiros trocadores & obter o arquivo mais rapidamente.

87

P2P Qualquer, Técnicas para localizar informação

88

P2P: buscando informação

Compartilhamento de arq. (eg e-mule)

● Índice dinamicamente registra localização dos arquivos que os pares compartilham.

● Pares precisam dizer ao sistema o que está sendo compartilhado.

● Pares buscam no índice para determinar onde os arquivos podem ser encontrados

Mensagem Instantânea ● Índice mapeia nomes para

localizações.● Quando usuário começa

uma aplicação IM, a aplicação precisa informar ao índice a sua localização

● Pares buscam no índice para determinar o endereço IP do usuário.

Sistema de índice do P2P: mapeia info para localização do par(localização = Endereço IP & número de porta)

89

P2P: diretório centralizado

“Napster” projeto original 1) Quando um dos pares se

conecta, ele informa ao servidor central :

– Endereço IP– conteúdo

2) Alice procura por “Escreve ai, by Luan Vesgo Santana”

3) Alice requisita o arquivo de Bob

Servidor de diretório

centralizadopares

Alice

Bob

1

1

1

12

3

90

P2P: problemas com diretórios centralizados● Ponto único de falha –

queda do diretório significa inviabilidade do sistema;

● Gargalo de desempenho – limitado pelo recursos do servidor;

● Fácil identificar violação dos direitos autorais e punir dono do serviço;

transferência de arquivo é descentralizada, mas localização de conteúdo é totalmente centralizada

91

P2P: Inundação de consultas (query flooding)

● Completamente distribuído– Sem servidor central

● Usado pelo Gnutella;

● Cada par indexa somente arquivos que tem para compartilhar;

A rede sobreposta: grafo● A aresta entre um par X e Y se existe uma conexão TCP;● Todos os pares ativos e as arestas forma a rede sobreposta;● Aresta: enlace virtual (não físico); ● Um par conecta-se com < 10 vizinhos na rede sobreposta.

92

P2P: consulta por inundação

Query

QueryHit

Query

Query

QueryHit

Query

Query

QueryHit

❒ Mensagem com a consultaenviada sobre conexõesTCP existentes❒ Pares repassammensagem consulta❒ Respostaenviada pelo caminhoreverso

Escalabilidade:limitar escopoda inundação

93

P2P: chegada (bootstrap)

join

1. O par que chega(ALICE) deve encontrar outro par na rede Gnutella: usa lista de pares candidatos

2. Alice tenta sequencialmente estabelecer conexão TCP com pares candidatos até que uma conexão seja aberta(BOB)

3. Inundação: Alice envia Mensagens Ping para Bob; Bob repassa mensagem Ping para seus vizinhos de rede (que repassam para os vizinhos deles….)

❒ Pares que recebem mensagens Ping respondem para Alice com mensagem Pong

1. Alice recebe várias mensagens Pong, e pode então estabelecer conexões TCP adcionais

94

P2P: mais...inundação

Prós● pares possuem

responsabilidades semelhantes;

● Extremamente descentralizado;

Contras● Tráfego excessivo de

consultas● Raio da consulta: pode

não ser o suficiente para obter o conteúdo, quando este existir;

● Necessário conhecer um nó de entrada;

95

P2P: Explorando heterogenidade, diretório descentralizado

● Um nó é um líder de grupo ou é um nó liderado;

● O líder do grupo conhece o conteúdo em nós liderados;

● Os pares consultam o líder do grupo;

● O par líder pode consultar outros nós líder.

Par qualquer

Par líder do grupo

Relacionamento de vizinhançana rede de cobertura

96

Mais sobre diretório descentralizado

Vantagens da abordagem● Nenhum servidor centralizado;

– O serviço de localização é distribuído entre os pares – Mais dificuldade de se ter falhas;

Desvantagem da abordagem● Necessário nó de entrada● O líder do grupo pode ficar sobrecarregado;

97

P2P Estudo de Caso: Skype

● Aplicação P2P: pares de usuários se comunicando.

● Protocolo proprietário (engenharia reversa)

● Overlay hierarquica com Super Nós

● Índice mapeia usernames para endereço IP; distribuído nos Super nós

Clientes Skype (SC)

Supernós (SN)

Skype login no servidor

98

Pares são repassadores

● Problema quando Alice e Bob estão atrás de “NATs”. – NAT impede que um par de

fora da rede inicie uma chamada um um par que esteja dentro da rede

● Solução:– Usando SN de Alice e Bob,

repassador é escolhido– Cada par inicia uma sessão

com o repassador. – Pares podem se comunicar,

passando pelo NAT, através do repassador

99

Questões

● O que é uma rede de sobreposição em um sistema de compartilhamento de arquivos P2P? E;a inclui roteadores ? O que são as arestas da rede de sobreposição?

● Na sua opinião, por que as aplicações de compartilhamento de arquivos P2P são tão populares? Será por que distribuem música e vídeo gratuitamente ou por que seu número imenso de servidores atende eficientemente uma demanda massiva de megabytes? Ou será pelas duas razões?

100

Cache WWW (servidor-procurador)

➘ usuário configura browser: acessos WWW via Proxy

➘ cliente envia todos pedidos http ao Proxy

➼ se objeto estiver na cache do Proxy, este o devolve imediatamente na resposta http

➼ senão, solicita objeto do servidor de origem, depois devolve resposta http ao cliente

Meta: atender pedido do cliente sem envolver servidor de origem

clienteServidor-

Proxy

cliente

pedido http

pedido http

resposta http

resposta http

pedido http

resposta http

pedido httpresposta http

Servidorde origem

Servidorde origem

101

Mais sobre Web cache➘ Cache atua tanto como cliente

quanto como servidor;➼ Cache pode fazer

verificação no cabeçalho HTTP usando o campo If-modified-since :

➘ Tipicamente as caches web são instalados em ISPs (universidades, companhias, ISP residencial)

Por quê usar cache WWW?➘ tempo de resposta menor:

cache “mais próximo” do cliente

➘ diminui tráfego aos servidores distantes

➼ muitas vezes o enlace que liga a rede da instituição ou do provedor à Internet é um gargalo.

102

Exemplo de Cache (1)

Suposições● Tamanho médio do objeto = 100,000

bits● Taxa média de requisição do browser

da instituição para os servidores de origem = 15/seg

● Atraso do roteador da instituição para qualquer servidor de origem e de volta para o roteador = 2 seg

Conseqüências● Utilização da LAN = 15%● Utilização do enlace de acesso = 100%● Atraso total = atraso Internet + atraso de

acesso + atraso LAN = 2 seg + minutos + milisegundos

Servidoresde origem

Internet pública

rede dainstituição LAN 10 Mbps

enlace de accesso 1.5 Mbps

cache dainstituição

103

Exemplo cache (2)

Solução possível● Aumentar a banda do enlace de

acesso para 10 MbpsConseqüências

● utilização LAN = 15%● Utilização do enlace de acesso = 15%● Atraso total = atraso Internet +

atraso de acesso + atraso LAN = 2 sec + msecs + msecs

● Geralmente um upgrade de link é custo$o

Servidoresde origem

Internet pública


enlace de accesso 10 Mbps


104

Exemplo cache(3)

Instala cache● Suponha que a taxa de hits é .4

Conseqüência● 40% das requisições são satisfeitas

pela cache;● Utilização do enlace de acesso

reduzido para 60%, resultando em atrasos desprezíveis;

● Atraso total = atraso Internet + atraso de acesso + atraso = .6*2 sec + .6*.01 seg + millisegundos < 1.3 seg

Servidoresde origem

Internet pública


enlace de accesso 1.5 Mbps


105

Programação com sockets

API Sockets ● apareceu no BSD4.1 UNIX em

1981● são explicitamente criados,

usados e liberados por apls● paradigma cliente/servidor● dois tipos de serviço de

transporte via API Sockets– datagrama não confiável – fluxo de bytes, confiável

uma interface (uma “porta”), local ao hospedeiro, criada por e pertencente à aplicação, e controlado pelo SO, através da qual um processo de aplicação pode tanto enviar como receber mensagens para/de outro processo de aplicação (remoto ou local)

socket

Meta: aprender a construir aplicações cliente/servidor que se comunicam usando sockets

106

Programação com sockets usando TCP

Socket: uma porta entre o processo de aplicação e um protocolo de transporte fim-a-fim (UDP ou TCP)

Serviço TCP: transferência confiável de bytes de um processo para outro

processo

TCP combuffers,variáveis

socket

controlado peloprogramador de

aplicaçãocontrolado

pelo sistemaoperacional

estação ouservidor

processo

TCP combuffers,variáveis

socket

controlado peloprogramador deaplicaçãocontroladopelo sistemaoperacional

estação ouservidor

internet

107

Cliente deve contactar servidor● processo servidor deve antes

estar em execução● servidor deve antes ter criado

socket (porta) que aguarda contato do cliente

Cliente contacta servidor para:● criar socket TCP local ao cliente● especificar endereço IP, número

de porta do processo servidor

● Quando cliente cria socket: TCP do cliente estabelece conexão com TCP do servidor

● Quando contatado pelo cliente, o TCP do servidor cria socket novo para que o processo servidor possa se comunicar com o cliente– permite que o servidor converse

com múltiplos clientes

TCP provê transferência confiável, ordenada de bytes

(“pipe”) entre cliente e servidor

ponto de vista da aplicação

Programação com sockets usando TCP

108

Comunicação entre sockets

109

Exemplo de aplicação cliente-servidor

➘ cliente lê linha da entrada padrão (fluxo doUsuário), envia para servidor via socket (fluxo paraServidor)

➘ servidor lê linha do socket➘ servidor converte linha para

letras maiúsculas, devolve para o cliente

➘ cliente lê linha modificada do socket (fluxo doServidor), imprime-a

par

a S

ervi

dor

para rede da rede

doS

erv

ido

r

doU

suá

rio

teclado monitor

Process

clientSocket

TCPsocket

fluxo de entrada: seqüência de bytespara dentro do processo

fluxo de saída: seqüência de bytes para fora do processo

processocliente

TCP socketcliente

110

Interações cliente/servidor usando o TCP

aguarda chegada de pedido de conexãosocketConexão =socketRecepção.accept()

cria socket,porta=x, parareceber pedido:

socketRecepção = ServerSocket ()

cria socket,abre conexão a nomeHosp, porta=xsocketCliente =

Socket()

fechasocketConexão

lê resposta desocketCliente

fechasocketCliente

Servidor (executa em nomeHosp) Cliente

Envia pedido usandosocketClientelê pedido de

socketConexão

escreve resposta para socketConexão

TCP setup da conexão

111

Exemplo: cliente Java (TCP)

import java.io.*; import java.net.*; class ClienteTCP {

public static void main(String argv[]) throws Exception { String frase; String fraseModificada;

BufferedReader doUsuario = new BufferedReader(new InputStreamReader(System.in));

Socket socketCliente = new Socket(”nomeHosp", 6789);

DataOutputStream paraServidor = new DataOutputStream(socketCliente.getOutputStream());

Criafluxo de entrada

Criasocket de cliente,

conexão ao servidorCria

fluxo de saídaligado ao socket

112

Exemplo: cliente Java (TCP), cont.

BufferedReader doServidor = new BufferedReader(new InputStreamReader(socketCliente.getInputStream()));

frase = doUsuario.readLine();

paraServidor.writeBytes(frase + '\n');

fraseModificada = doServidor.readLine();

System.out.println(”Do Servidor: " + fraseModificada);

socketCliente.close(); } }

Criafluxo de entradaligado ao socket

Envia linhaao servidor

Lê linhado servidor

113

Exemplo: servidor Java (TCP)

import java.io.*; import java.net.*;

class servidorTCP {

public static void main(String argv[]) throws Exception { String fraseCliente; String fraseMaiusculas;

ServerSocket socketRecepcao = new ServerSocket(6789); while(true) { Socket socketConexao = socketRecepcao.accept();

BufferedReader doCliente = new BufferedReader(new InputStreamReader(socketConexao.getInputStream()));

Cria socketpara recepçãona porta 6789

Aguarda, no socketpara recepção, o

contato do clienteCria fluxo de

entrada, ligadoao socket

114

Programação com sockets usando UDP

UDP: não tem “conexão” entre cliente e servidor

● não tem “handshaking”● remetente coloca

explicitamente endereço IP e porta do destino

● servidor deve extrair endereço IP, porta do remetente do datagrama recebido

UDP: dados transmitidos podem ser recebidos fora de ordem, ou perdidos

UDP provê transferência não confiável de grupos de bytes (“datagramas”) entre cliente e servidor

ponto de vista da aplicação

115

Exemplo: servidor Java (TCP), cont

DataOutputStream paraCliente = new DataOutputStream(socketConexao.getOutputStream());

fraseCliente= doCliente.readLine();

fraseMaiusculas= fraseCliente.toUpperCase() + '\n';

paraClient.writeBytes(fraseMaiusculas); } } }

Lê linhado socket

Cria fluxode saída, ligado

ao socket

Escreve linhaao socket

Final do laço while,volta ao início e aguardaconexão de outro cliente

116

Interações cliente/servidor usando o UDP

fechasocketCliente

Servidor (executa em nomeHosp)

lê resposa dosocketCliente

cria socket,socketCliente = DatagramSocket()

Cliente

cria, endereça (nomeHosp, porta=x,envia pedido em datagramausando socketCliente

cria socket,porta=x, parapedido que chega:socketServidor = DatagramSocket()

lê pedido dosocketServidor

escreve resposta ao socketServidorespecificando endereçoIP, número de porta do cliente

117

Cliente UDP

118

Exemplo: cliente Java (UDP)

env

iaP

ack

et

para rede da redere

cebe

Pac

ket

doU

suá

rio

teclado monitor

Process

clientSocket

pacoteUDP

fluxode entrada

pacoteUDP

UDPsocket

Saída: envia pacote (UDP envia “byte stream”)

Entrada: recebe pacote (UDP recebe “byte stream”)

processocliente

socket UDP cliente

119

Exemplo: cliente Java (UDP)

import java.io.*; import java.net.*; class clienteUDP { public static void main(String args[]) throws Exception { BufferedReader do Usuario= new BufferedReader(new InputStreamReader(System.in)); DatagramSocket socketCliente = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName(”nomeHosp"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String frase = doUsuario.readLine();

sendData = frase.getBytes();

Criafluxo de entrada

Cria socket de cliente

Traduz nome de hospedeiro ao

endereço IP usando DNS

120

Exemplo: cliente Java (UDP) cont.

DatagramPacket pacoteEnviado = new DatagramPacket(dadosEnvio, dadosEnvio.length,

IPAddress, 9876); socketCliente.send(pacoteEnviado); DatagramPacket pacoteRecebido = new DatagramPacket(dadosRecebidos, dadosRecebidos.length); socketCliente.receive(pacoteRecebido); String fraseModificada = new String(pacoteRecebido.getData()); System.out.println(”Do Servidor:" + fraseModificada); socketCliente.close(); }

}

Cria datagrama com dados para enviar,

comprimento, endereço IP, portaEnvia datagrama

ao servidor

Lê datagramado servidor

121

Servidor UDP

122

Exemplo: servidor Java (UDP)

import java.io.*; import java.net.*; class servidorUDP { public static void main(String args[]) throws Exception { DatagramSocket socketServidor = new DatagramSocket(9876); byte[] dadosRecebidos = new byte[1024]; byte[] dadosEnviados = new byte[1024]; while(true) { DatagramPacket pacoteRecebido = new DatagramPacket(dadosRecebidos,

dadosRecebidos.length);

socketServidor.receive(pacoteRecebido);

Cria socketpara datagramas

na porta 9876

Aloca memória parareceber datagrama

Recebedatagrama

123

Exemplo: servidor Java (UDP), cont

String frase = new String(pacoteRecebido.getData()); InetAddress IPAddress = pacoteRecebido.getAddress(); int porta = pacoteRecebido.getPort(); String fraseEmMaiusculas = frase.toUpperCase();

dadosEnviados = fraseEmMaiusculas.getBytes(); DatagramPacket pacoteEnviado = new DatagramPacket(dadosEnviados, dadosEnviados.length, IPAddress, porta); socketServidor.send(pacoteEnviado); } }

}

Obtém endereço IP, no. de porta

do remetente

Escrevedatagramano socket

Fim do laço while,volta ao início e aguardachegar outro datagrama

Cria datagrama p/ enviar ao cliente

124

Servidor Web Simples

● Funções do servidor Web:– Trata apenas um pedido HTTP por vez– Aceita e examina o pedido HTTP– Recupera o arquivo pedido do sistema de arquivos

do servidor– Cria uma mensagem de resposta HTTP

consistindo do arquivo solicitado precedido por linhas de cabeçalho

– Envia a resposta diretamente ao cliente– Depois de criado o servidor, pode-se requisitar um

arquivo utilizando um browser;

125

Servidor Web Simples

import java.io.*;import java.net.*;import java.util.*;

class WebServer { public static void main(String argv[]) throws Exception { String requestMessageLine; String fileName;

ServerSocket listenSocket = new ServerSocket(6789); Socket connectionSocket = listenSocket.accept();

BufferedReader inFromClient = new BufferedReader(new InputStreamReader( connectionSocket.getInputStream()));

DataOutputStream outToClient = new DataOutputStream( connectionSocket.getOutputStream());

Contém a classe StringTokenizer que é

usada para examinar o pedido

Aguarda conexãodo cliente

Primeira linha da mensagemde pedido HTTP e

Nome do arquivo solicitado

Cria fluxo de Entrada

Cria fluxo de Saída

126

Servidor Web Simples, cont

requestMessageLine = inFromClient.readLine();

StringTokenizer tokenizedLine = new StringTokenizer(requestMessageLine); if (tokenizedLine.nextToken().equals("GET")){ fileName = tokenizedLine.nextToken(); if (fileName.startsWith("/") == true ) fileName = fileName.substring(1);

File file = new File(fileName); int numOfBytes = (int) file.length();

FileInputStream inFile = new FileInputStream ( fileName);

byte[] fileInBytes = new byte[]; inFile.read(fileInBytes);

Lê a primeira linha dopedido HTTP que deveria

ter o seguinte formato:GET file_name HTTP/1.0

Examina a primeira linha da mensagem para extrair

o nome do arquivo

Associa o fluxo inFile ao arquivo fileName

Determina o tamanho doarquivo e constrói um vetor

de bytes do mesmo tamanho

127

Servidor Web Simples, cont

outToClient.writeBytes( "HTTP/1.0 200 Document Follows\r\n");

if (fileName.endsWith(".jpg")) outToClient.writeBytes("Content-Type: image/jpeg\r\n"); if (fileName.endsWith(".gif")) outToClient.writeBytes("Content-Type: image/gif\r\n"); outToClient.writeBytes("Content-Length: " + numOfBytes + "\r\n"); outToClient.writeBytes("\r\n");

outToClient.write(fileInBytes, 0, numOfBytes); connectionSocket.close(); }

else System.out.println("Bad Request Message"); }}

Transmissão do cabeçalho da resposta

HTTP.

Inicia a construção damensagem de resposta

128

Programação de Sockets: referências

Tutorial sobre linguagem C (audio/slides): ➘ “Unix Network Programming” (J. Kurose),http://manic.cs.umass.edu.

Tutoriais sobre Java:➘ “Socket Programming in Java: a tutorial,”

http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html

129

Capítulo 2: Resumo

● Requisitos do serviço de aplicação:– confiabilidade, banda, retardo

● paradigma cliente-servidor ● modelo de serviço do transporte

– orientado a conexão, confiável da Internet: TCP

– não confiável, datagramas: UDP

Terminamos nosso estudo de aplicações de rede!➘ Protocolos específicos:

➼ http➼ ftp➼ smtp, pop3, imap➼ dns

➘ programação c/ sockets➼ implementação

cliente/servidor➼ usando sockets tcp, udp

➘ Distribuição de conteúdo:➼ caches, CDNs➼ P2P

130

Capítulo 2: Resumo

● troca típica de mensagens pedido/resposta:– cliente solicita info ou serviço– servidor responde com dados,

código de status● formatos de mensagens:

– cabeçalhos: campos com info sobre dados (metadados)

– dados: info sendo comunicada

Mais importante: aprendemos sobre protocolos

➘ msgs de controle X dados➼ na banda, fora da banda

➘ centralizado X descentralizado ➘ s/ estado X c/ estado➘ transferência de msgs

confiável X não confiável ➘ “complexidade na borda da

rede”➘ segurança: autenticação

131

Rotas para Acesso a Prodam

132

Rotas para Acesso a Bemol

capítulo 2: camada de aplicação capítulo 2: roteiro princípios das aplicações de rede –...

Documents