Upload
lycong
View
221
Download
1
Embed Size (px)
Citation preview
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)
aplicaçãotransporte
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
aplicaçãotransporte
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
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
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
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
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
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
Servidores de nomes DNS
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 de nomes DNS
servidores raiz(root DNS servers):– São 13 ao todo;– Conhecem endereços dos servidores TLD
66
Servidores de nomes DNS
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
solicitantevod.icomp.ufam.edu.br
www.cs.columbia.edu
servidor localmutum.ufam.edu.br
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 localmutum.ufam.edu.br
servidor intermediáriosaell.cc.columbia.edu
servidor oficialcs.columbia.edu
solicitantevod.icomp.ufam.edu.br
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
76
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– P2P
● a programação de aplicações de rede– programação usando sockets
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
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
rede dainstituição LAN 10 Mbps
enlace de accesso 10 Mbps
cache dainstituição
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
rede dainstituição LAN 10 Mbps
enlace de accesso 1.5 Mbps
cache dainstituição
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