Capítulo 2
Redes de computadores e a
Internet
Camada
de
aplicação
2
© 2005 by Pearson Education 2 - 2
 2.1 Princípios de aplicações de rede
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio electrônico
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Compartilhamento de arquivos P2P
 2.7 Programação de socket com TCP
 2.8 Programação de socket com UDP
 2.9 Construindo um servidor Web
Camada de aplicação
2
© 2005 by Pearson Education 2 - 3
Nossos objetivos:
 Conceitual, aspectos de implementação de protocolos de aplicação de redes
 Modelos de serviço da camada de transporte
 Paradigma cliente-servidor
 Paradigma peer-to-peer
 Aprender sobre protocolos examinando protocolos da camada de aplicação
populares:
 HTTP
 FTP
 SMTP/ POP3/ IMAP
 DNS
 Programação de aplicações de rede
 Socket API
Parte 2: Camada de aplicação
2
© 2005 by Pearson Education 2 - 4
 E-mail
 Web
 Mensagem instantânea
 Login remoto
 P2P file sharing
 Jogos de rede multi-usuário
 Streaming stored videoclipes
 Telefonia via Internet
 Videoconferência em tempo real
 Computação paralela massiva
Algumas aplicações de rede
2
© 2005 by Pearson Education 2 - 5
Escrever programas que
 Executem sobre diferentes sistemas
finais e
 Se comuniquem através de uma rede.
 Ex.: Web – software de servidor Web
se comunicando com software do
browser.
Nenhum software é escrito para
dispositivos no núcleo da rede
 Dispositivos do núcleo da rede não
trabalham na camada de aplicação
 Esta estrutura permite um rápido
desenvolvimento de aplicação
Criando uma nova aplicação de rede
2
© 2005 by Pearson Education 2 - 6
 2.1 Princípios de aplicações de rede
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio electrônico SMTP, POP3, IMAP
 2.5 DNS
 2.6 Compartilhamento de arquivos P2P
 2.7 Programação de socket com TCP
 2.8 Programação de socket com UDP
 2.9 Construindo um servidor Web
Camada de aplicação
2
© 2005 by Pearson Education 2 - 7
 Cliente-servidor
 Peer-to-peer (P2P)
 Híbrida de cliente-servidor e P2P
Arquiteturas de aplicação
2
© 2005 by Pearson Education 2 - 8
Arquitetura cliente-servidor
Clientes:
 Comunicam-se com o servidor
 Pode ser conectado
intermitentemente
 Pode ter endereço IP dinâmico
 Não se comunicam
diretamente uns com os outros
Servidor:
 Hospedeiro sempre ativo
 Endereço IP permanente
 Fornece serviços
solicitados pelo cliente
2
© 2005 by Pearson Education 2 - 9
 Nem sempre no servidor
 Sistemas finais arbitrários
comunicam-se diretamente
 Pares são intermitentemente
conectados e trocam endereços IP
 Ex.: Gnutella
Altamente escaláveis mas difíceis
de gerenciar
Arquitetura P2P pura
2
© 2005 by Pearson Education 2 - 10
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
2
© 2005 by Pearson Education 2 - 11
Processo: programa executando num hospedeiro
 Dentro do mesmo hospedeiro: dois processos se comunicam usando
comunicação interprocesso (definido pelo OS)
 Processos em diferentes hospedeiros se comunicam por meio de troca
de mensagens
 Processo cliente: processo que inicia a comunicação
 Processo servidor: processo que espera para ser contatado
Nota: aplicações com arquiteturas P2P possuem processos cliente
e processos servidor
Comunicação de processos
2
© 2005 by Pearson Education 2 - 12
 Um processo envia/recebe
mensagens para/de seu socket
 O socket é análogo a uma porta
 O processo de envio empurra a
mensagem para fora da porta
 O processo de envio confia na
infra-estrutura de transporte
no outro lado da porta que leva
a mensagem para o socket no
processo de recepção.
 API: (1) escolha do protocolo de transporte; (2) habilidade para fixar
poucos parâmetros (será explicado mais tarde)
Sockets
2
© 2005 by Pearson Education 2 - 13
 Para um processo receber mensagens, ele deve ter um identificador
 Um hospedeiro possui um único endereço IP de 32 bits
 P.: O endereço IP do hospedeiro onde o processo está executando é suficiente
para identificar o processo?
 R.: Não, muitos processos podem estar em execução no mesmo hospedeiro.
 O identificador inclui o endereço IP e o número da porta associada ao processo
no hospedeiro
 Exemplos de números de porta:
 Servidor HTTP: 80
 Servidor de Correio: 25
 (mais detalhes serão mostrados mais tarde)
Processos de endereçamento
2
© 2005 by Pearson Education 2 - 14
 Tipo das mensagens trocadas, mensagens de requisição e resposta
 Sintaxe dos tipos de mensagem: os campos nas mensagens e como são
delineados
 Semântica dos campos, ou seja, significado da informação nos campos
 Regras para quando e como os processos enviam e respondem às mensagens
Protocolos de domínio público:
 Definidos nas RFCs
 Recomendados para interoperabilidade
 Ex.: HTTP, SMTP
Protocolos proprietários:
 Ex.: KaZaA
O protocolo da camada de aplicação define
2
© 2005 by Pearson Education 2 - 15
Perda de dados
 Algumas aplicações (ex.: áudio) podem tolerar alguma perda
 Outras aplicações (ex.: transferência de arquivos, telnet) exigem transferência de dados
100% confiável
Temporização
 Algumas aplicações (ex.: telefonia Internet, jogos interativos) exigem baixos atrasos para
serem “efetivos
Banda passante
 Algumas aplicações (ex.: multimídia) exigem uma banda mínima para serem “efetivas”
 Outras aplicações (“aplicações elásticas”) melhoram quando a banda disponível aumenta”
De qual serviço de transporte uma aplicação necessita?
2
© 2005 by Pearson Education 2 - 16
Aplicação
file transfer
e-mail
Web documents
real-time áudio/vídeo
stored áudio/video
jogos interativos
e-business
Perdas
sem perdas
sem perdas
tolerante
tolerante
tolerante
tolerante
sem perda
Banda
elástica
elástica
elástica
aúdio: 5 Kb-1 Mb
vídeo:10 Kb-5
Mb
igual à anterior
kbps
elástica
Sensível ao atraso
não
não
não
sim, 100’s mseg
sim, segundos
sim, 100’s mseg
sim
Requisitos de transporte de aplicação comuns
2
© 2005 by Pearson Education 2 - 17
Serviço TCP:
 Orientado à conexão: conexão requerida entre processos cliente e servidor
 Transporte confiável entre os processor de envio e recepção
 Controle de fluxo: o transmissor não sobrecarrega o receptor
 Controle de congestionamento: protege a rede do excesso de tráfego
Não oferece: garantias de temporização e de banda mínima
Serviço UDP:
 Transferência de dados não confiável entre os processos transmissor e receptor
 Não oferece: estabelecimento de conexão, confiabilidade, controle de fluxo e
de congestionamento, garantia de temporização e de banda mínima.
P.: Por que ambos? Por que existe o UDP?
Serviços dos protocolos de transporte da Internet
2
© 2005 by Pearson Education 2 - 18
Aplicação
e-mail
acesso de terminais remotos
Web
transferência de arquivos
streaming multimídia
servidor de arquivos remoto
telefonia Internet
Protocolo de
aplicação
smtp [RFC 821]
telnet [RFC 854]
http [RFC 2068]
ftp [RFC 959]
RTP ou proprietário
(ex.: RealNetworks)
NSF
RTP ou proprietário
(ex.: Vocaltec)
Protocolo de
transporte
TCP
TCP
TCP
TCP
TCP ou UDP
TCP ou UDP
tipicamente UDP
Aplicação e protocolos de transporte da Internet
2
© 2005 by Pearson Education 2 - 19
 2.1 Princípios de aplicações de rede
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio electrônico
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Compartilhamento de arquivos P2P
 2.7 Programação de socket com TCP
 2.8 Programação de socket com UDP
 2.9 Construindo um servidor Web
Camada de aplicação
2
© 2005 by Pearson Education 2 - 20
Primeiro alguns jargões
 Página Web consiste de objetos
 Objeto pode ser arquivo HTML, imagem JPEG, Java applet, arquivo
de áudio,…
 A página Web consiste de arquivo-HTML base que inclui vários
objetos referenciados
 Cada objeto é endereçado por uma URL
 Exemplo de URL:
www.someschool.edu/someDept/pic.gif
Nome do hospedeiro Nome do caminho
Web e HTTP
2
© 2005 by Pearson Education 2 - 21
HTTP: hypertext transfer protocol
 Protocolo da camada de aplicação
da Web
 Modelo cliente/servidor
 Cliente: browser que solicita,
recebe e apresenta objetos da Web
 Servidor: envia objetos em
resposta a pedidos
 HTTP 1.0: RFC 1945
 HTTP 1.1: RFC 2068
Visão geral do HTTP
2
© 2005 by Pearson Education 2 - 22
Utiliza TCP:
 Cliente inicia conexão TCP (cria socket) para o servidor na porta 80
 Servidor aceita uma conexão TCP do cliente
 mensagens HTTP (mensagens do protocolo de camada de aplicação) são
trocadas entre o browser (cliente HTTP) e o servidor Web (servidor HTTP)
 A conexão TCP é fechada
HTTP é “stateless”
 O servidor não mantém informação sobre os pedidos passados pelos clientes
Protocolos que mantêm informações de “estado” são complexos!
 Histórico do passado (estado) deve ser mantido
 Se o servidor/cliente quebra, suas visões de “estado” podem ser
inconsistentes, devendo ser reconciliadas
Visão geral do HTTP
2
© 2005 by Pearson Education 2 - 23
HTTP não persistente
 No máximo, um objeto é enviado sobre uma conexão TCP
 O HTTP/1.0 utiliza HTTP não persistente
HTTP persistente
 Múltiplos objetos podem ser enviados sobre uma conexão
 TCP entre o cliente e o servidor
 O HTTP/1.1 utiliza conexões persistentes em seu modo padrão
Conexões HTTP
2
© 2005 by Pearson Education 2 - 24
Usuário entra com a URL: www.someSchool.edu/someDepartment/home.index
1a. Cliente HTTP inicia conexão
TCP ao servidor HTTP
(processo) em
www.someSchool.edu. Porta
80 é a default para o
servidor HTTP.
2. Cliente HTTP envia HTTP
request message (contendo a
URL) para o socket da conexão
TCP
1b. Servidor HTTP no hospedeiro
www.someSchool.edu
esperando pela conexão TCP
na porta 80. “Aceita” conexão,
notificando o cliente
3. Servidor HTTP recebe
mensagem de pedido, forma
response message contendo o
objeto solicitado
(someDepartment/home.index)
, envia mensagem para o
socket
Tempo
(contém texto,referências a 10 imagens jpeg)
HTTP não persistente
2
© 2005 by Pearson Education 2 - 25
5. Cliente HTTP recebe mensagem de
resposta contendo o arquivo html,
apresenta o conteúdo html.
Analisando o arquivo html, encontra
10 objetos jpeg referenciados
6. Passos 1-5 são repetidos para
cada um dos 10 objetos jpeg.
4. Servidor HTTP fecha conexão
TCP.
Tempo
HTTP não persistente
2
© 2005 by Pearson Education 2 - 26
Definição de RRT: tempo para
enviar um pequeno pacote
que vai do cliente para o
servidor e retorna.
Tempo de resposta:
 Um RTT para iniciar a
conenexão TCP
 Um RTT para requisição
HTTP e primeiros bytes da
resposta HTTP para
retorno
 Tempo de transmissão de
arquivo
Modelagem do tempo de resposta
Total = 2RTT+ tempo de transmissão
2
© 2005 by Pearson Education 2 - 27
Características do HTTP persistente:
 Requer 2 RTTs por objeto
 OS deve manipular e alocar recursos do hospedeiro para cada conexão TCP
Mas os browsers freqüentemente abrem conexões TCP paralelas para buscar
objetos referenciados
HTTP persistente
 Servidor deixa a conexão aberta após enviar uma resposta
 Mensagens HTTP subseqüentes entre o mesmo cliente/servidor são enviadas
pela conexão
Persistente sem pipelining:
 O cliente emite novas requisições apenas quando a resposta anterior for
recebida
 Um RTT para cada objeto referenciado
Persistente com pipelining:
 Padrão no HTTP/1.1
 O cliente envia requisições assim que encontra um objeto referenciado
 Tão pequeno como um RTT para todos os objetos referenciados
HTTP persistente
2
© 2005 by Pearson Education 2 - 28
Carriage return,
line feed
indica fim da mensagem
 Dois tipos de mensagens HTTP: request, response
 HTTP request message:
 ASCII (formato legível para humanos)
GET /somedir/page.html HTTP/1.0
User-agent: Mozilla/4.0
Accept: text/html, image/gif,image/jpeg
Accept-language:fr
(extra carriage return, line feed)
Linha de pedido
(comandos GET, POST,
HEAD )
Linhas de
cabeçalho
Mensagem HTTP request
2
© 2005 by Pearson Education 2 - 29
Mensagem HTTP request: formato geral
2
© 2005 by Pearson Education 2 - 30
Método Post:
 Página Web freqüentemente inclui entrada de formulário
 A entrada é enviada para o servidor no corpo da entidade
Método URL:
 Utiliza o método GET
 A entrada é enviada no campo de URL da linha de requisição:
www.somesite.com/animalsearch?monkeys&banana
Entrada de formulário
2
© 2005 by Pearson Education 2 - 31
HTTP/1.0
 GET
 POST
 HEAD
 Pede para o servidor deixar o objeto requisitado fora da resposta
HTTP/1.1
 GET, POST, HEAD
 PUT
 Envia o arquivo no corpo da entidade para o caminho especificado
no campo de URL
 DELETE
 Apaga o arquivo especificado no campo de URL
Tipos de métodos
2
© 2005 by Pearson Education 2 - 32
HTTP/1.0 200 OK
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
Linha de status
(protocolo
código de status
frase de status)
Linhas de
cabeçalho
Dados, ex.:
arquivo html
Mensagem HTTP response
2
© 2005 by Pearson Education 2 - 33
Na primeira linha da mensagem de resposta servidor  cliente.
Alguns exemplos de códigos:
200 OK
 Requisição bem-sucedida, objeto requisitado a seguir nesta mensagem
301 Moved permanently
 Objeto requisitado foi movido, nova localização especificada a seguir nesta
mensagem (Location:)
400 Bad request
 Mensagem de requisição não compreendida pelo servidor
404 Not Found
 Documento requisitado não encontrado neste servidor
505 HTTP version not supported
Códigos de status das respostas
2
© 2005 by Pearson Education 2 - 34
1.Telnet para um servidor Web:
Abre conexão TCP para a porta 80
(porta default do servidor HTTP) em cis.poly.edu.
Qualquer coisa digitada é enviada
para a porta 80 em cis.poly.edu
2.Digite um pedido GET HTTP:
Digitando isso (tecle carriage
return duas vezes), você envia este
pedido HTTP GET mínimo (mas
completo) ao servidor HTTP
3.Examine a mensagem de resposta enviada pelo servidor HTTP!
GET /~ross/ HTTP/1.1
host: cis.poly.edu
telnet cis.poly.edu 80
HTTP cliente: faça você mesmo!
2
© 2005 by Pearson Education 2 - 35
A maioria dos grandes Web sites utilizam cookies
Quatro componentes:
1) Linha de cabeçalho do cookie na mensagem HTTP response
2) Linha de cabeçalho de cookie na mensagem HTTP request
3) Arquivo de cookie mantido no hospedeiro do usuário e manipulado pelo
browser do usuário
4) Banco de dados backend no Web site
Exemplo:
 Susan acessa a Internet sempre do mesmo PC
 Ela visita um site específico de e-commerce pela primeira vez
 Quando a requisição HTTP inicial chega ao site, este cria um ID único e
uma entrada no banco de dados backend para este ID
Estado usuário-servidor: cookies
2
© 2005 by Pearson Education 2 - 36
Cliente Servidor
usual HTTP request msg
usual HTTP response +
Set-cookie: 1678
usual HTTP request msg
cookie: 1678
usual HTTP response msg
usual HTTP request msg
cookie: 1678
usual HTTP response msg
especificação
do cookie
especificação
do cookie
servidor
cria o ID 1678
para o usuário
entrada no
banco
de
dados backend
acesso
a
c
e
s
s
o
Cookie file
amazon: 1678
ebay: 8734
Cookie file
ebay: 8734
Cookie file
amazon: 1678
ebay: 8734
Uma semana depois:
Cookies: mantendo “estado”
2
© 2005 by Pearson Education 2 - 37
O que os cookies podem trazer:
 Autorização
 Cartões de compra
 Recomendações
 Estado de sessão do usuário (Web e-mail)
ASIDE
Cookies e privacidade:
 Cookies permitem que sites saibam muito sobre você
 Você pode fornecer nome e e-mail para os sites
 Mecanismos de busca usam redirecionamento e cookies para saberem mais
sobre você
 Companhias de propaganda obtêm informações por meio dos sites
Cookies
2
© 2005 by Pearson Education 2 - 38
 Usuário configura o browser:
acesso Web é feito por meio de
um proxy
 Cliente envia todos os pedidos
HTTP para o Web cache
 Se o objeto existe no Web
cache: Web cache retorna o
objeto
 Ou o Web cache solicita
objeto do servidor original e
então envia o objeto ao
cliente
Objetivo: atender o cliente sem envolver o servidor Web
originador da informação
Web caches (proxy server)
2
© 2005 by Pearson Education 2 - 39
 O cache atua tanto no servidor como no cliente
 Tipicamente, o cache é instalado pelo ISP (universidade, companhia,
ISP residencial)
Por que Web caching?
 Reduz o tempo de resposta para a requisição do cliente.
 Reduz o tráfego num enlace de acesso de uma instituição.
 A densidade de caches na Internet habilita os “fracos” provedores de
conteúdo a efetivamente entregarem o conteúdo (mas fazendo P2P
file sharing)
Mais sobre Web caching
2
© 2005 by Pearson Education 2 - 40
Suponha:
 Tamanho médio objeto = 100.000 bits
 Taxa média de requisições dos
browsers da instituição para os
servidores de origem = 15/s
 Atraso do roteador institucional para
ir a qualquer servidor de origem e
retornar ao roteador = 2 s
Conseqüências:
 Utilização da LAN = 15%
 Utilização do link de acesso = 100%
 Atraso total = atraso da Internet +
atraso de acesso + atraso da LAN = 2
segundos + minutos + milissegundos
Exemplo de caching
2
© 2005 by Pearson Education 2 - 41
Solução possível
 Aumentar a largura de banda do
enlace de acesso, como, 10 Mbps
Conseqüências
 Utilização da LAN = 15%
 Utilização do enlace de acesso =
15%
 Atraso total = atraso da Internet +
atraso de acesso + atraso da LAN
= 2 segundos + msegs + msegs
 Freqüentemente é um upgrade
caro
Exemplo de caching
2
© 2005 by Pearson Education 2 - 42
Exemplo de caching
Instalação do cache
 Suponha que a taxa de acertos seja .4
Conseqüência
 40% das requisições serão satisfeitas
quase que imediatamente
 60% das requisições serão satisfeitas pelo
servidor de origem
 Utilização do enlace de acesso reduzida
para 60%, resultando em atrasos
insignificantes (como 10 mseg)
 Média de atraso total = atraso da
Internet + atraso de acesso + atraso da
LAN = .6*(2.01) segundos +
milissegundos < 1,4 segundos
2
© 2005 by Pearson Education 2 - 43
 Razão: não enviar objeto se
a versão que o cliente já
possui está atualizada.
 Cliente: especifica data da
versão armazenada no
pedido HTTP
 If-modified-since: <date>
 Servidor: resposta não
contém objeto se a cópia é
atualizada:
HTTP/1.0 304 Not Modified
Cliente Servidor
HTTP request msg
If-modified-since:
<date>
HTTP response
HTTP/1.0
304 Not Modified
Objeto
não
modificado
HTTP request msg
If-modified-since:
<date>
HTTP response
HTTP/1.1 200 OK
<data>
Objeto
modificado
GET condicional
2
© 2005 by Pearson Education 2 - 44
 2.1 Princípios de aplicações de rede
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio electrônico
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Compartilhamento de arquivos P2P
 2.7 Programação de socket com TCP
 2.8 Programação de socket com UDP
 2.9 Construindo um servidor Web
Camada de aplicação
2
© 2005 by Pearson Education 2 - 45
 Transferência de arquivos de e para o computador remoto
 Modelo cliente servidor
 Cliente: lado que inicia a transferência (seja de ou para o lado remoto)
 Servidor: hospedeiro remoto
 FTP: RFC 959
 FTP servidor: porta 21
FTP: o protocolo de transferência de arquivos
2
© 2005 by Pearson Education 2 - 46
 Cliente FTP contata o servidor FTP na porta 21 especificando o TCP como
protocolo de transporte
 Cliente obtém autorização pela conexão de controle
 Cliente procura o diretório remoto enviando comandos pela conexão de controle
 Quando o servidor recebe um comando para uma transferência de arquivo, ele
abre uma conexão de dados TCP para o cliente
 Após a transferência de um arquivo, o servidor fecha a conexão
 Servidor abre uma segunda conexão de dados TCP para transferir outro arquivo
 Conexão de controle: “fora da banda”
 Servidor FTP mantém “estado”: diretório atual, autenticação anterior
FTP: controle separado, conexões de dados
2
© 2005 by Pearson Education 2 - 47
Exemplos de comandos:
 Envie um texto ASCII sobre canal de controle
 USER username
 PASS password
 LIST retorna listagem do arquivo no diretório atual
 RETR filename recupera (obtém) o arquivo
 STOR filename armazena o arquivo no hospedeiro remoto
Exemplos de códigos de retorno
 Código de status e frase (como no HTTP)
 331 Username OK, password required
 125 data connection already open; transfer starting
 425 Can’t open data connection
 452 Error writing file
FTP comandos, respostas
2
© 2005 by Pearson Education 2 - 48
 2.1 Princípios de aplicações de rede
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio electrônico
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Compartilhamento de arquivos P2P
 2.7 Programação de socket com TCP
 2.8 Programação de socket com UDP
 2.9 Construindo um servidor Web
Camada de aplicação
2
© 2005 by Pearson Education 2 - 49
Três componentes principais:
 Agentes de usuário
 Servidores de correio
 Simple mail transfer protocol: SMTP
Agente de usuário
“leitor de correio”
 Composição, edição, leitura de
mensagens de correio
 Ex.: Eudora, Outlook, elm, Netscape
Messenger
 Mensagens de entrada e de saída são
armazenadas no servidor
Correio eletrônico
2
© 2005 by Pearson Education 2 - 50
Servidores de correio
 Caixa postal contém mensagens
que chegaram (ainda não lidas)
para o usuário
 Fila de mensagens contém as
mensagens de correio a serem
enviadas
Protocolo SMTP permite aos
servidores de correio trocarem
mensagens entre si
 Cliente: servidor de correio
que envia
 “servidor”: servidor de
correio que recebe
Correio eletrônico: servidores de correio
2
© 2005 by Pearson Education 2 - 51
Correio eletrônico: SMTP [RFC 821]
 Usa TCP para transferência confiável de mensagens de correio do
cliente ao servidor, porta 25
 Transferência direta: servidor que envia para o servidor que recebe
 Três fases de transferência
 Handshaking (apresentação)
 Transferência de mensagens
 Fechamento
 Interação comando/resposta
 Comandos: texto ASCII
 Resposta: código de status e frase
 Mensagens devem ser formatadas em código ASCII de 7 bits
2
© 2005 by Pearson Education 2 - 52
1) Alice usa o agente de usuário (UA) para compor a mensagem e “para”
bob@someschool.edu
2) O agente de usuário dela envia a mensagem para o seu servidor de correio; a
mensagem é colocada na fila de mensagens.
3) O lado cliente do SMTP abre uma conexão TCP com o servidor de correio do Bob.
4) O cliente SMTP envia a mensagem de Alice pela conexão TCP.
5) O servidor de correio de Bob coloca a mensagem na caixa de correio de Bob.
6) Bob invoca seu agente de usuário para ler a mensagem.
Cenário: Alice envia mensagem para Bob
2
© 2005 by Pearson Education 2 - 53
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
Exemplo de interação SMTP
2
© 2005 by Pearson Education 2 - 54
 telnet nome do servidor 25
 Veja resposta 220 do servidor
 Envie comandos HELO, MAIL FROM, RCPT TO, DATA, QUIT
a seqüência acima permite enviar um comando sem usar o agente
de usuário do remetente
Tente o SMTP você mesmo
2
© 2005 by Pearson Education 2 - 55
SMTP: palavras finais
 SMTP usa conexões persistentes
 SMTP exige que as mensagens (cabeçalho e corpo) estejam em ASCII de 7 bits
 Servidor SMTP usa CRLF.CRLF para indicar o final da mensagem
Comparação com HTTP:
 HTTP: pull
 E-mail: push
 Ambos usam comandos e respostas em ASCII, interação comando/resposta e
códigos de status
 HTTP: cada objeto encapsulado na sua própria mensagem de resposta
 SMTP: múltiplos objetos são enviados numa mensagem multiparte
2
© 2005 by Pearson Education 2 - 56
SMTP: protocolo para trocar
mensagens de e-mail
RFC 822: padrão para mensagens
do tipo texto:
• linhas de cabeçalho, ex.:
– To:
– From:
– Subject:
diferente dos comandos
HTTP
• corpo
– a “mensagem”, ASCII
somente com caracteres
header
body
linha
em branco
Formato da mensagem de correio
2
© 2005 by Pearson Education 2 - 57
 MIME: multimedia mail extension, RFC 2045, 2056
 Linhas adicionais no cabeçalho declaram o tipo de conteúdo MIME
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
Dados multimídia
tipo, subtipo,
declaração de parâmetro
Método usado
para codificar dados
Versão da MIME
Dados codificados
Formato das mensagens: extensões multimídia
2
© 2005 by Pearson Education 2 - 58
 SMTP: entrega e armazena no servidor do destino
 Protocolo de acesso: recupera mensagens do servidor
 POP: Post Office Protocol [RFC 1939]
 Autorização (agente <-->servidor) e download
 IMAP: Internet Mail Access Protocol [RFC 1730]
 Maiores recursos (mais complexo)
 Manipulação de mensagens armazenadas no servidor
 HTTP: Hotmail , Yahoo! Mail etc.
Protocolos de acesso ao correio
2
© 2005 by Pearson Education 2 - 59
Fase de autorização
 comandos do cliente:
 user: declara nome do usuário
 pass: password
respostas do servidor
 +OK
 -ERR
Fase de transação, cliente:
 list: lista mensagens e tamanhos
 retr: recupera mensagem pelo
número
 dele: apaga
 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 alice
S: +OK
C: pass hungry
S: +OK user successfully
logged on
Protocolo POP3
2
© 2005 by Pearson Education 2 - 60
Mais sobre POP3
 O exemplo anterior usa o modo “download-and-delete”
 Bob não pode reler o e-mail se ele trocar o cliente
 “download-and-keep”: cópias das mensagens em clientes diferentes
 POP3 é stateless através das sessões
IMAP
 Mantém todas as mensagens em um lugar: o servidor
 Permite que o usuário organize as mensagens em pastas
 IMAP mantém o estado do usuário através das sessões:
 Nomes das pastas e mapeamentos entre os IDs da mensagem e o nome da pasta
POP3 (mais) e IMAP
2
© 2005 by Pearson Education 2 - 61
 2.1 Princípios de aplicações de rede
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio electrônico
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Compartilhamento de arquivos P2P
 2.7 Programação de socket com TCP
 2.8 Programação de socket com UDP
 2.9 Construindo um servidor Web
Camada de aplicação
2
© 2005 by Pearson Education 2 - 62
Pessoas: muitos identificadores:
 RG, nome, passaporte
Internet hospedeiros, roteadores:
 Endereços IP (32 bits) - usados para endereçar datagramas
 “nome”, ex.: gaia.cs.umass.edu - usados por humanos
P.: Relacionar nomes com endereços IP?
Domain Name System:
 Base de dados distribuída implementada numa hierarquia de muitos
servidores de nomes
 Protocolo de camada de aplicação hospedeiro, roteadores se comunicam com
servidores de nomes para resolver nomes (translação nome/endereço)
 Nota: função interna da Internet, implementada como protocolo da
camada de aplicação
 Complexidade na “borda” da rede
DNS: Dominain Name System
2
© 2005 by Pearson Education 2 - 63
DNS
DNS services
 Nome do hospedeiro para tradução de endereço IP
 Hospedeiro aliasing
 Nomes canônicos e alias
mail server aliasing
distribuição de carga
 Servidores Web replicados: estabelece o endereço IP para um nome canônico
Por que não centralizar o DNS?
 Ponto único de falha
 Volume de tráfego
 Base centralizada de dados distante
 Manutenção
Não é escalável!
2
© 2005 by Pearson Education 2 - 64
Cliente quer o IP para www.amazon.com; 1a
aprox.:
 Cliente consulta um servidor de raiz para encontrar o servidor DNS com
 Cliente consulta o servidor DNS com para obter o servidor DNS amazon.com
 Cliente consulta o servidor DNS amazon.com para obter o endereço IP para
www.amazon.com
Base de dados distribuída, hierárquica
2
© 2005 by Pearson Education 2 - 65
 São contatados pelos servidores de nomes locais que não podem resolver
um nome
 Servidores de nomes raiz:
 Buscam servidores de nomes autorizados se o mapeamento do nome não
for conhecido
 Conseguem o mapeamento
 Retornam o mapeamento para o servidor de nomes local
Existem 13 servidores
de nomes raiz no
mundo
DNS: servidores de nomes raiz
2
© 2005 by Pearson Education 2 - 66
Servidores top-level domain (TLD): responsáveis pelos domínios com, org, net,
edu etc e todos os domínios top-level nacionais uk, fr, ca, jp.
 Network Solutions mantém servidores para o TLD “com” TLD
 Educause para o TLD “edu”
Servidores DNS autorizados: servidores DNS de organizações, provêm nome de
hospedeiro autorizado para mapeamentos IP para servidores de organizações
(ex.: Web e mail).
 Podem ser mantidos por uma organização ou provedor de serviços
Servidores TLD e autoritários
2
© 2005 by Pearson Education 2 - 67
 Não pertence estritamente a uma hierarquia
 Cada ISP (ISP residencial, companhia, universidade) possui um
 Também chamado de “servidor de nomes default”
 Quando um hospedeiro faz uma pergunta a um DNS, a pergunta é
enviada para seu servidor DNS local
 Age como um proxy, encaminhando as perguntas para dentro da
hierarquia
Servidor de nomes local
2
© 2005 by Pearson Education 2 - 68
 O hospedeiro em cis.poly.edu
quer o endereço IP para
gaia.cs.umass.edu
Exemplo
2
© 2005 by Pearson Education 2 - 69
Consulta recursiva:
 Transfere a tarefa de
resolução do nome para o
servidor de nomes
consultado
 Carga pesada?
Consulta encadeada:
 Servidor contatado
responde com o nome de
outro servidor de nomes
para contato
 “eu não sei isto, mas
pergunte a este servidor”
Consultas recursivas
2
© 2005 by Pearson Education 2 - 70
Uma vez que um servidor de nomes apreende um mapeamento, ele
armazena o mapeamento num registro do tipo cache
 Registro do cache tornam-se obsoletos (desaparecem) depois de um certo
tempo
 Servidores TLD são tipicamente armazenados em cache nos servidores de
nome locais
Mecanismos de atualização e notificação estão sendo projetados pelo IETF
 RFC 2136
 http://www.ietf.org/html.charters/dnsind-charter.html
DNS: armazenando e atualizando registros
2
© 2005 by Pearson Education 2 - 71
Registros do DNS
DNS: base de dados distribuída que armazena registros de recursos (RR)
 Type = NS
 name é um domínio (ex.:
foo.com)
 value é o endereço IP do servidor
de nomes autorizados para este
domínio
formato dos RR: (name, value, type,ttl)
 Type = A
 name é o nome do computador
 value é o endereço IP
 Type = CNAME
 name é um “apelido” para algum
nome “canônico” (o nome real)
www.ibm.com é realmente
servereast.backup2.ibm.com
 value é o nome canônico
 Type = MX
 value é o nome do servidor de
correio associado com name
2
© 2005 by Pearson Education 2 - 72
DNS: protocolo e mensagem
Protocolo DNS: mensagem de consulta e resposta , ambas com o mesmo formato de
mensagem
Cabeçalho da msg
 Identificação: número de 16 bits
para consulta, resposta usa o
mesmo número
 Flags:
 Consulta ou resposta
 Recursão desejada
 Recursão disponível
 Resposta é autorizada
2
© 2005 by Pearson Education 2 - 73
DNS: protocolo e mensagens
Camada de aplicação
2
© 2005 by Pearson Education 2 - 74
Inserindo registros no DNS
 Exemplo: empresa recém-criada “Network Utopia”
 Registrar o nome networkuptopia.com num “registrar” (ex.: Network
Solutions)
 É necessário fornecer ao registrar os nomes e endereços IP do seu servidor
nomes autorizados (primário e secundário)
 Registrar insere dois RRs no servidor TLD do domínio com:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
 No servidor autorizado, inserir um registro Tipo A para
www.networkuptopia.com e um registro Tipo MX para networkutopia.com
 Como as pessoas obtêm o endereço IP do seu Web site?
Camada de aplicação
2
© 2005 by Pearson Education 2 - 75
 2.1 Princípios de aplicações de rede
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio electrônico
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Compartilhamento de arquivos P2P
 2.7 Programação de socket com TCP
 2.8 Programação de socket com UDP
 2.9 Construindo um servidor Web
Camada de aplicação
2
© 2005 by Pearson Education 2 - 76
Exemplo
 Alice executa a aplicação cliente P2P em seu notebook
 Intermitentemente, conecta-se à Internet; obtém novos endereços IP para
cada conexão
 pede por “Hey Jude”
 a aplicação exibe outros pares que possuem uma cópia de Hey Jude.
 Alice escolhe um dos pares, Bob.
 o arquivo é copiado do PC de Bob para o notebook de Alice: HTTP
 enquanto Alice faz o download, outros usuários fazem upload de Alice.
 o par de Alice é tanto um cliente Web como um servidor Web transiente.
Todos os pares são servidores = altamente escaláveis!
Compartilhamento de arquivos P2P
2
© 2005 by Pearson Education 2 - 77
Projeto original “Napster”
1) Quando um par se conecta, ele
informa ao servidor central:
 Endereço IP
 Conteúdo
2) Alice procura por “Hey Jude”
3) Alice requisita o arquivo de Bob
P2P: diretório centralizado
2
© 2005 by Pearson Education 2 - 78
 Ponto único de falhas
 Gargalo de desempenho
 Infração de copyright
Transferência de arquivo é descentralizada, mas a localização de conteúdo é altamente centralizado
P2P: problemas com diretório centralizado
2
© 2005 by Pearson Education 2 - 79
 Totalmente distribuído
 Sem servidor central
 Protocolo de domínio público
 Muitos clientes Gnutella implementando o protocolo
Rede de cobertura: gráfico
 Aresta entre o par X e o Y se não há uma conexão TCP
 Todos os pares ativos e arestas estão na rede de sobreposição
 aresta não é um enlace físico
 Um determinado par será tipicamente conectado a <10 vizinhos na rede de
sobreposição
Query flooding: Gnutella
2
© 2005 by Pearson Education 2 - 80
Gnutella: protocolo
 Mensagem de consulta
(query) é enviada pelas
conexões TCP existentes
 Os pares encaminham
a mensagem de consulta
 QueryHit (encontro)
é enviado pelo
caminho reverso
Escalabilidade: flooding de alcance limitado
2
© 2005 by Pearson Education 2 - 81
1.Para conectar o par X, ele precisa encontrar algum outro par na
rede Gnutella: utiliza a lista de pares candidatos
2.X seqüencialmente, tenta fazer conexão TCP com os pares da lista
até estabelecer conexão com Y
3.X envia mensagem de Ping para Y; Y encaminha a mensagem de
Ping.
4.Todos os pares que recebem a mensagem de Ping respondem com
mensagens de Pong.
5.X recebe várias mensagens de Pong. Ele pode então estabelecer
conexões TCP adicionais.
Desconectando pares: veja o problema para trabalho de casa!
Gnutella: conectando pares
2
© 2005 by Pearson Education 2 - 82
 Cada par é ou um líder de grupo
ou está atribuído a um líder de
grupo
 Conexão TCP entre o par e
seu líder de grupo
 Conexões TCP entre alguns
pares de líderes de grupo
 O líder de grupo acompanha o
conteúdo em todos os seus
“discípulos”
Explorando heterogeneidade: KaZaA
2
© 2005 by Pearson Education 2 - 83
 Cada arquivo possui um hash e um descritor
 O cliente envia a consulta de palavra-chave para o seu líder de grupo
 O líder de grupo responde com os encontros:
 Para cada encontro: metadata, hash, endereço IP
 Se o líder de grupo encaminha a consulta para outros líderes de grupo,
eles respondem com os encontros
 O cliente então seleciona os arquivos para download
 Requisições HTTP usando hash como identificador são enviadas
aos pares que contêm o arquivo desejado
KaZaA
2
© 2005 by Pearson Education 2 - 84
 Limitações em uploads simultâneos
 Requisita enfileiramento
 Incentiva prioridades
 Realiza downloads em paralelo
Artifícios do KaZaA
2
© 2005 by Pearson Education 2 - 85
 2.1 Princípios de aplicações de rede
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio electrônico
SMTP, POP3, IMAP
 2.5 DNS
 2.6 Compartilhamento de arquivos P2P
 2.7 Programação de socket com TCP
 2.8 Programação de socket com UDP
 2.9 Construindo um servidor Web
Camada de aplicação
2
© 2005 by Pearson Education 2 - 86
Objetivo: aprender a construir aplicações cliente-servidor que se comunicam
usando sockets
Socket API
 Introduzida no BSD4.1 UNIX, 1981
 Explicitamente criados, usados e liberados pelas aplicações
 Paradigma cliente-servidor
 Dois tipos de serviço de transporte via socket API:
 Datagrama não confiável
 Confiável, orientado a cadeias de bytes
SOCKET
Uma interface local, criada por aplicações,
controlada pelo OS (uma “porta”) na qual os processos de aplicação podem
tanto enviar quanto receber mensagens de e para outro processo de aplicação
(local ou remoto)
Programação de sockets
2
© 2005 by Pearson Education 2 - 87
Programação de sockets com TCP
Socket: uma porta entre o processo de aplicação e o protocolo de transporte
fim-a-fim (UCP or TCP)
Serviço TCP: transferência confiável de bytes de um processo para outro
2
© 2005 by Pearson Education 2 - 88
Cliente deve contatar o servidor
 Processo servidor já deve estar em execução
 Servidor deve ter criado socket (porta) que aceita o contato do cliente
Cliente contata o servidor
 Criando um socket TCP local
 Especificando endereço IP e número da porta do processo servidor
 Quando o cliente cria o socket: cliente TCP estabelece conexão com o
TCP do servidor
Quando contatado pelo cliente, o TCP do servidor cria um novo socket
para o processo servidor comunicar-se com o cliente
 Permite ao servidor conversar com múltiplos clientes
 Números da porta de origem são usados para distinguir o cliente (mais
no capítulo 3)
Ponto de vista da aplicação
TCP fornece a transferência confiável, em ordem de bytes
(“pipe”) entre o cliente e o servidor
Programação de sockets com TCP
2
© 2005 by Pearson Education 2 - 89
 Um stream é uma seqüência de caracteres que fluem para dentro ou para
fora de um processo
 Um stream de entrada é agregado a alguma fonte de entrada para o
processo, ex.: teclado ou socket
 Um stream de saída é agregado a uma fonte de saída, ex.: monitor ou
socket
Jargão stream
2
© 2005 by Pearson Education 2 - 90
Exemplo de aplicação cliente-servidor:
1) Cliente lê linha da entrada-padrão
do sistema (inFromUser stream),
envia para o servidor via socket
(outToServer stream)
2) Servidor lê linha do socket
3) Servidor converte linha para letras
maiúsculas e envia de volta ao
cliente
4) Cliente lê a linha modificada através
do (inFromServer stream)
Programação de sockets com TCP
Programação de sockets com TCP
2
© 2005 by Pearson Education 2 - 91
Interação cliente-servidor TCP
2
© 2005 by Pearson Education 2 - 92
import java.io.*;
import java.net.*;
class TCPClient {
public static void main(String argv[]) throws Exception
{
String sentence;
String modifiedSentence;
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Socket clientSocket = new Socket("hostname", 6789);
DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());
Cria
stream de entrada
Cria
socket cliente,
conecta ao servidor
Cria
stream de saída
ligado ao socket
Exemplo: cliente Java (TCP)
2
© 2005 by Pearson Education 2 - 93
Exemplo: cliente Java (TCP)
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));
sentence = inFromUser.readLine();
outToServer.writeBytes(sentence + 'n');
modifiedSentence = inFromServer.readLine();
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
Cria
stream de entrada
ligado ao socket
Envia linha
para o servidor
Lê linha
do servidor
2
© 2005 by Pearson Education 2 - 94
import java.io.*;
import java.net.*;
class TCPServer {
public static void main(String argv[]) throws Exception
{
String clientSentence;
String capitalizedSentence;
ServerSocket welcomeSocket = new ServerSocket(6789);
while(true) {
Socket connectionSocket = welcomeSocket.accept();
BufferedReader inFromClient =
new BufferedReader(new
InputStreamReader(connectionSocket.getInputStream()))
Cria
socket de aceitação
na porta 6789
Espera, no socket
de aceitação, por
contato do cliente
Cria stream de
entrada ligado
ao socket
Exemplo: servidor Java (TCP)
2
© 2005 by Pearson Education 2 - 95
DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + 'n';
outToClient.writeBytes(capitalizedSentence);
}
}
}
Lê linha do
socket
Cria stream de
saída ligado ao
socket
Escreve linha
para o socket
Fim do while loop,
retorne e espere por
outra conexão do cliente
Exemplo: servidor Java (TCP)
2
© 2005 by Pearson Education 2 - 96
 2.1 Princípios de aplicações de rede
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio electrônico
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Compartilhamento de arquivos P2P
 2.7 Programação de socket com TCP
 2.8 Programação de socket com UDP
 2.9 Construindo um servidor Web
Camadas de aplicação
2
© 2005 by Pearson Education 2 - 97
UDP: não há conexão entre o cliente e o servidor
 Não existe apresentação
 Transmissor envia explicitamente endereço IP e porta de destino em cada
mensagem
 Servidor deve extrair o endereço IP e porta do transmissor de cada
datagrama recebido
UDP: dados transmitidos podem ser recebidos fora de ordem ou perdidos
Ponto de vista da aplicação
UDP fornece a transferência não confiável de grupos de bytes
(datagramas) entre o cliente e oservidor
Programação de sockets com UDP
2
© 2005 by Pearson Education 2 - 98
Interação cliente-servidor: UDP
2
© 2005 by Pearson Education 2 - 99
Exemplo: cliente Java (UDP)
2
© 2005 by Pearson Education 2 - 100
import java.io.*;
import java.net.*;
class UDPClient {
public static void main(String args[]) throws Exception
{
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
DatagramSocket clientSocket = new DatagramSocket();
InetAddress IPAddress =
InetAddress.getByName("hostname");
byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];
String sentence = inFromUser.readLine();
sendData = sentence.getBytes();
Cria
stream de entrada
Cria
socket cliente
Translada
nome do
hospedeiro para
endereço IP
usando DNS
Exemplo: cliente Java (UDP)
2
© 2005 by Pearson Education 2 - 101
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length,
IPAddress, 9876);
clientSocket.send(sendPacket);
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
clientSocket.receive(receivePacket);
String modifiedSentence =
new String(receivePacket.getData());
System.out.println("FROM SERVER:" + modifiedSentence);
clientSocket.close();
}
}
Cria datagrama com
dados a enviar,
tamanho, endereço
IP porta
Envia datagrama
para servidor
Lê datagrama
do servidor
Exemplo: cliente Java (UDP)
2
© 2005 by Pearson Education 2 - 102
import java.io.*;
import java.net.*;
class UDPServer {
public static void main(String args[]) throws Exception
{
DatagramSocket serverSocket = new DatagramSocket(9876);
byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];
while(true)
{
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
Cria
socket datagrama
na porta 9876
Cria espaço para
datagramas recebidos
Recebe
datagrama
Exemplo: servidor Java (UDP)
2
© 2005 by Pearson Education 2 - 103
String sentence = new String(receivePacket.getData());
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
String capitalizedSentence = sentence.toUpperCase();
sendData = capitalizedSentence.getBytes();
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress
port);
serverSocket.send(sendPacket);
}
}
}
Obtém endereço IP
e número da porta
do transmissor
Escreve o
datagrama para
dentro do socket
Termina o while loop,
retorna e espera por
outro datagrama
Cria datagrama
para enviar ao cliente
Exemplo: servidor Java (UDP)
2
© 2005 by Pearson Education 2 - 104
 2.1 Princípios de aplicações de rede
 2.2 Web e HTTP
 2.3 FTP
 2.4 Correio electrônico
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Compartilhamento de arquivos P2P
 2.7 Programação de socket com TCP
 2.8 Programação de socket com UDP
 2.9 Construindo um servidor Web
Camada de aplicação
2
© 2005 by Pearson Education 2 - 105
 Manipule uma requisição HTTP
 Aceite a requisição
 analise o cabeçalho
 Vobtenha um arquivo requisitado do sistema de arquivo do servidor
 Crie uma mensagem de resposta HTTP:
 Linhas de cabeçalho + arquivo
 Envie a resposta para o cliente
 Após criar o servidor, você pode requisitar um arquivo usando um
browser (ex.: IE explorer)
 Veja o texto para mais detalhes
Construindo um servidor Web simples
2
© 2005 by Pearson Education 2 - 106
Nosso estudo de aplicações está completo agora!
 Arquiteturas de aplicação
 Cliente-servidor
 P2P
 Híbrida
 Exigências dos serviços de aplicação:
 Confiabilidade, banda passante, atraso
 Modelo do serviço de transporte da Internet l
 Orientado à conexão, confiável: TCP
 Não confiável, datagramas: UDP
 Protocolos específicos:
 HTTP
 FTP
 SMTP, POP, IMAP
 DNS
 Programação de sockets
Resumo
2
© 2005 by Pearson Education 2 - 107
Mais importante: características dos protocolos
 Típica troca de mensagens comando/resposta:
 Cliente solicita informação ou serviço
 Servidor responde com dados e código de status
 Formatos das mensagens:
 Cabeçalhos: campos que dão informações sobre os dados
 Dados: informação sendo comunicada
 Controle vs. dados
 In-band, out-of-band
 Centralizado vs. descentralizado
 Stateless vs. stateful
 Transferência de mensagens confiável vs. não confiável
 “complexidade na borda da rede”
Resumo

Mais conteúdo relacionado

PPTX
Camada de aplicação parte1
PDF
PPT
Apresentação de sd2
PDF
Samba, Squid, FTP, DHCP1
PDF
Cap 02.pdf
ODP
Prog web 00-modelo-cliente_servidor_web
ODP
Prog web 00-modelo-cliente_servidor_web
PPTX
Informática Windows com questões de cincurso publico
Camada de aplicação parte1
Apresentação de sd2
Samba, Squid, FTP, DHCP1
Cap 02.pdf
Prog web 00-modelo-cliente_servidor_web
Prog web 00-modelo-cliente_servidor_web
Informática Windows com questões de cincurso publico

Semelhante a apostila Servidores Web-camada de aplicação.ppt (20)

PDF
02 - Aplicação-Transporte.pdf
PPT
Camada De Aplicação
PPTX
Camada de-aplicao
PPTX
Redes de Computadroes Camada de aplicação
DOCX
Http (hyper text transfer protocol)
PDF
02 - Redesssssssssssssssssssssssssssssss.pdf
PDF
ssssssssssssssssssssssssssssssssssssssssssssssss.pdf
PDF
Cap06a
PDF
Redes de computadores 2 - Protocolos
PDF
Redes de Computadores 2 - Conceitos Gerais
PDF
Samba, Squid, FTP, DHCP2
PPT
Conceitos associado às redes
PDF
Mini Curso - Redes de Computadores
PDF
PPTX
Tcpip
PPTX
Aula05 camada de aplicação
PPTX
2016-redes-E.pptx
PPTX
Protocolos de aplicação
PPTX
02 Network Reference Model.af Modelo OSI
PDF
Protocolo tcp ip
02 - Aplicação-Transporte.pdf
Camada De Aplicação
Camada de-aplicao
Redes de Computadroes Camada de aplicação
Http (hyper text transfer protocol)
02 - Redesssssssssssssssssssssssssssssss.pdf
ssssssssssssssssssssssssssssssssssssssssssssssss.pdf
Cap06a
Redes de computadores 2 - Protocolos
Redes de Computadores 2 - Conceitos Gerais
Samba, Squid, FTP, DHCP2
Conceitos associado às redes
Mini Curso - Redes de Computadores
Tcpip
Aula05 camada de aplicação
2016-redes-E.pptx
Protocolos de aplicação
02 Network Reference Model.af Modelo OSI
Protocolo tcp ip
Anúncio

Mais de FranciscoNeto353211 (18)

PPT
0840-servidoreswebluisbastos1-170111193108.ppt
PPT
02-Algoritmos.ppt logica de programação.com
PPT
JavaSemanaInfo.ppt java logica de programacao
PPT
IPF_GuiaEstudosPrimeiraSemana.ppt muito otima
PPT
IPF_ApresentacaoDisciplinaIntroducaoProgramacao_Ferias.ppt
PPTX
Apresentação Aula Logica Intro aos Algoritmos I modulo.pptx
PPTX
Apresentação Aula Logica de Programação I mod Ferramenta Visualg.pptx
PPT
Introducao Estrutura de Dados CETIPPT.ppt
PDF
edaula01pdf de estrutura de dados e algoritmos
PPT
geografia7_brasil_diversidades_regionais.ppt
PPT
geografia6_litosfera_atmosfera_hidrosfera.ppt
PPT
geografia_conhecendo_o_planeta_terra.ppt
PDF
AULA_21___GEST_O_DA_INOVA__O_3_15592522169242_10352 (1).pdf
PDF
Tecnologia-da-Informação-e-do-Conhecimento-18-28.pdf
PDF
Arquitetura_Computadores_COR_Capa_ficha_20110126.pdf.pdf
PDF
ELETRICIDADE_BASICA_UTFPR.PDF VOLTADO PRA INFORMATICA
PPT
Informatica instrumental software e sistemas operacionais
PDF
AULA_21___GEST_O_DA_INOVA__O_3_15592522169242_10352 (1).pdf
0840-servidoreswebluisbastos1-170111193108.ppt
02-Algoritmos.ppt logica de programação.com
JavaSemanaInfo.ppt java logica de programacao
IPF_GuiaEstudosPrimeiraSemana.ppt muito otima
IPF_ApresentacaoDisciplinaIntroducaoProgramacao_Ferias.ppt
Apresentação Aula Logica Intro aos Algoritmos I modulo.pptx
Apresentação Aula Logica de Programação I mod Ferramenta Visualg.pptx
Introducao Estrutura de Dados CETIPPT.ppt
edaula01pdf de estrutura de dados e algoritmos
geografia7_brasil_diversidades_regionais.ppt
geografia6_litosfera_atmosfera_hidrosfera.ppt
geografia_conhecendo_o_planeta_terra.ppt
AULA_21___GEST_O_DA_INOVA__O_3_15592522169242_10352 (1).pdf
Tecnologia-da-Informação-e-do-Conhecimento-18-28.pdf
Arquitetura_Computadores_COR_Capa_ficha_20110126.pdf.pdf
ELETRICIDADE_BASICA_UTFPR.PDF VOLTADO PRA INFORMATICA
Informatica instrumental software e sistemas operacionais
AULA_21___GEST_O_DA_INOVA__O_3_15592522169242_10352 (1).pdf
Anúncio

apostila Servidores Web-camada de aplicação.ppt

  • 1. Capítulo 2 Redes de computadores e a Internet Camada de aplicação
  • 2. 2 © 2005 by Pearson Education 2 - 2  2.1 Princípios de aplicações de rede  2.2 Web e HTTP  2.3 FTP  2.4 Correio electrônico  SMTP, POP3, IMAP  2.5 DNS  2.6 Compartilhamento de arquivos P2P  2.7 Programação de socket com TCP  2.8 Programação de socket com UDP  2.9 Construindo um servidor Web Camada de aplicação
  • 3. 2 © 2005 by Pearson Education 2 - 3 Nossos objetivos:  Conceitual, aspectos de implementação de protocolos de aplicação de redes  Modelos de serviço da camada de transporte  Paradigma cliente-servidor  Paradigma peer-to-peer  Aprender sobre protocolos examinando protocolos da camada de aplicação populares:  HTTP  FTP  SMTP/ POP3/ IMAP  DNS  Programação de aplicações de rede  Socket API Parte 2: Camada de aplicação
  • 4. 2 © 2005 by Pearson Education 2 - 4  E-mail  Web  Mensagem instantânea  Login remoto  P2P file sharing  Jogos de rede multi-usuário  Streaming stored videoclipes  Telefonia via Internet  Videoconferência em tempo real  Computação paralela massiva Algumas aplicações de rede
  • 5. 2 © 2005 by Pearson Education 2 - 5 Escrever programas que  Executem sobre diferentes sistemas finais e  Se comuniquem através de uma rede.  Ex.: Web – software de servidor Web se comunicando com software do browser. Nenhum software é escrito para dispositivos no núcleo da rede  Dispositivos do núcleo da rede não trabalham na camada de aplicação  Esta estrutura permite um rápido desenvolvimento de aplicação Criando uma nova aplicação de rede
  • 6. 2 © 2005 by Pearson Education 2 - 6  2.1 Princípios de aplicações de rede  2.2 Web e HTTP  2.3 FTP  2.4 Correio electrônico SMTP, POP3, IMAP  2.5 DNS  2.6 Compartilhamento de arquivos P2P  2.7 Programação de socket com TCP  2.8 Programação de socket com UDP  2.9 Construindo um servidor Web Camada de aplicação
  • 7. 2 © 2005 by Pearson Education 2 - 7  Cliente-servidor  Peer-to-peer (P2P)  Híbrida de cliente-servidor e P2P Arquiteturas de aplicação
  • 8. 2 © 2005 by Pearson Education 2 - 8 Arquitetura cliente-servidor Clientes:  Comunicam-se com o servidor  Pode ser conectado intermitentemente  Pode ter endereço IP dinâmico  Não se comunicam diretamente uns com os outros Servidor:  Hospedeiro sempre ativo  Endereço IP permanente  Fornece serviços solicitados pelo cliente
  • 9. 2 © 2005 by Pearson Education 2 - 9  Nem sempre no servidor  Sistemas finais arbitrários comunicam-se diretamente  Pares são intermitentemente conectados e trocam endereços IP  Ex.: Gnutella Altamente escaláveis mas difíceis de gerenciar Arquitetura P2P pura
  • 10. 2 © 2005 by Pearson Education 2 - 10 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
  • 11. 2 © 2005 by Pearson Education 2 - 11 Processo: programa executando num hospedeiro  Dentro do mesmo hospedeiro: dois processos se comunicam usando comunicação interprocesso (definido pelo OS)  Processos em diferentes hospedeiros se comunicam por meio de troca de mensagens  Processo cliente: processo que inicia a comunicação  Processo servidor: processo que espera para ser contatado Nota: aplicações com arquiteturas P2P possuem processos cliente e processos servidor Comunicação de processos
  • 12. 2 © 2005 by Pearson Education 2 - 12  Um processo envia/recebe mensagens para/de seu socket  O socket é análogo a uma porta  O processo de envio empurra a mensagem para fora da porta  O processo de envio confia na infra-estrutura de transporte no outro lado da porta que leva a mensagem para o socket no processo de recepção.  API: (1) escolha do protocolo de transporte; (2) habilidade para fixar poucos parâmetros (será explicado mais tarde) Sockets
  • 13. 2 © 2005 by Pearson Education 2 - 13  Para um processo receber mensagens, ele deve ter um identificador  Um hospedeiro possui um único endereço IP de 32 bits  P.: O endereço IP do hospedeiro onde o processo está executando é suficiente para identificar o processo?  R.: Não, muitos processos podem estar em execução no mesmo hospedeiro.  O identificador inclui o endereço IP e o número da porta associada ao processo no hospedeiro  Exemplos de números de porta:  Servidor HTTP: 80  Servidor de Correio: 25  (mais detalhes serão mostrados mais tarde) Processos de endereçamento
  • 14. 2 © 2005 by Pearson Education 2 - 14  Tipo das mensagens trocadas, mensagens de requisição e resposta  Sintaxe dos tipos de mensagem: os campos nas mensagens e como são delineados  Semântica dos campos, ou seja, significado da informação nos campos  Regras para quando e como os processos enviam e respondem às mensagens Protocolos de domínio público:  Definidos nas RFCs  Recomendados para interoperabilidade  Ex.: HTTP, SMTP Protocolos proprietários:  Ex.: KaZaA O protocolo da camada de aplicação define
  • 15. 2 © 2005 by Pearson Education 2 - 15 Perda de dados  Algumas aplicações (ex.: áudio) podem tolerar alguma perda  Outras aplicações (ex.: transferência de arquivos, telnet) exigem transferência de dados 100% confiável Temporização  Algumas aplicações (ex.: telefonia Internet, jogos interativos) exigem baixos atrasos para serem “efetivos Banda passante  Algumas aplicações (ex.: multimídia) exigem uma banda mínima para serem “efetivas”  Outras aplicações (“aplicações elásticas”) melhoram quando a banda disponível aumenta” De qual serviço de transporte uma aplicação necessita?
  • 16. 2 © 2005 by Pearson Education 2 - 16 Aplicação file transfer e-mail Web documents real-time áudio/vídeo stored áudio/video jogos interativos e-business Perdas sem perdas sem perdas tolerante tolerante tolerante tolerante sem perda Banda elástica elástica elástica aúdio: 5 Kb-1 Mb vídeo:10 Kb-5 Mb igual à anterior kbps elástica Sensível ao atraso não não não sim, 100’s mseg sim, segundos sim, 100’s mseg sim Requisitos de transporte de aplicação comuns
  • 17. 2 © 2005 by Pearson Education 2 - 17 Serviço TCP:  Orientado à conexão: conexão requerida entre processos cliente e servidor  Transporte confiável entre os processor de envio e recepção  Controle de fluxo: o transmissor não sobrecarrega o receptor  Controle de congestionamento: protege a rede do excesso de tráfego Não oferece: garantias de temporização e de banda mínima Serviço UDP:  Transferência de dados não confiável entre os processos transmissor e receptor  Não oferece: estabelecimento de conexão, confiabilidade, controle de fluxo e de congestionamento, garantia de temporização e de banda mínima. P.: Por que ambos? Por que existe o UDP? Serviços dos protocolos de transporte da Internet
  • 18. 2 © 2005 by Pearson Education 2 - 18 Aplicação e-mail acesso de terminais remotos Web transferência de arquivos streaming multimídia servidor de arquivos remoto telefonia Internet Protocolo de aplicação smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] RTP ou proprietário (ex.: RealNetworks) NSF RTP ou proprietário (ex.: Vocaltec) Protocolo de transporte TCP TCP TCP TCP TCP ou UDP TCP ou UDP tipicamente UDP Aplicação e protocolos de transporte da Internet
  • 19. 2 © 2005 by Pearson Education 2 - 19  2.1 Princípios de aplicações de rede  2.2 Web e HTTP  2.3 FTP  2.4 Correio electrônico  SMTP, POP3, IMAP  2.5 DNS  2.6 Compartilhamento de arquivos P2P  2.7 Programação de socket com TCP  2.8 Programação de socket com UDP  2.9 Construindo um servidor Web Camada de aplicação
  • 20. 2 © 2005 by Pearson Education 2 - 20 Primeiro alguns jargões  Página Web consiste de objetos  Objeto pode ser arquivo HTML, imagem JPEG, Java applet, arquivo de áudio,…  A página Web consiste de arquivo-HTML base que inclui vários objetos referenciados  Cada objeto é endereçado por uma URL  Exemplo de URL: www.someschool.edu/someDept/pic.gif Nome do hospedeiro Nome do caminho Web e HTTP
  • 21. 2 © 2005 by Pearson Education 2 - 21 HTTP: hypertext transfer protocol  Protocolo da camada de aplicação da Web  Modelo cliente/servidor  Cliente: browser que solicita, recebe e apresenta objetos da Web  Servidor: envia objetos em resposta a pedidos  HTTP 1.0: RFC 1945  HTTP 1.1: RFC 2068 Visão geral do HTTP
  • 22. 2 © 2005 by Pearson Education 2 - 22 Utiliza TCP:  Cliente inicia conexão TCP (cria socket) para o servidor na porta 80  Servidor aceita uma conexão TCP do cliente  mensagens HTTP (mensagens do protocolo de camada de aplicação) são trocadas entre o browser (cliente HTTP) e o servidor Web (servidor HTTP)  A conexão TCP é fechada HTTP é “stateless”  O servidor não mantém informação sobre os pedidos passados pelos clientes Protocolos que mantêm informações de “estado” são complexos!  Histórico do passado (estado) deve ser mantido  Se o servidor/cliente quebra, suas visões de “estado” podem ser inconsistentes, devendo ser reconciliadas Visão geral do HTTP
  • 23. 2 © 2005 by Pearson Education 2 - 23 HTTP não persistente  No máximo, um objeto é enviado sobre uma conexão TCP  O HTTP/1.0 utiliza HTTP não persistente HTTP persistente  Múltiplos objetos podem ser enviados sobre uma conexão  TCP entre o cliente e o servidor  O HTTP/1.1 utiliza conexões persistentes em seu modo padrão Conexões HTTP
  • 24. 2 © 2005 by Pearson Education 2 - 24 Usuário entra com a URL: www.someSchool.edu/someDepartment/home.index 1a. Cliente HTTP inicia conexão TCP ao servidor HTTP (processo) em www.someSchool.edu. Porta 80 é a default para o servidor HTTP. 2. Cliente HTTP envia HTTP request message (contendo a URL) para o socket da conexão TCP 1b. Servidor HTTP no hospedeiro www.someSchool.edu esperando pela conexão TCP na porta 80. “Aceita” conexão, notificando o cliente 3. Servidor HTTP recebe mensagem de pedido, forma response message contendo o objeto solicitado (someDepartment/home.index) , envia mensagem para o socket Tempo (contém texto,referências a 10 imagens jpeg) HTTP não persistente
  • 25. 2 © 2005 by Pearson Education 2 - 25 5. Cliente HTTP recebe mensagem de resposta contendo o arquivo html, apresenta o conteúdo html. Analisando o arquivo html, encontra 10 objetos jpeg referenciados 6. Passos 1-5 são repetidos para cada um dos 10 objetos jpeg. 4. Servidor HTTP fecha conexão TCP. Tempo HTTP não persistente
  • 26. 2 © 2005 by Pearson Education 2 - 26 Definição de RRT: tempo para enviar um pequeno pacote que vai do cliente para o servidor e retorna. Tempo de resposta:  Um RTT para iniciar a conenexão TCP  Um RTT para requisição HTTP e primeiros bytes da resposta HTTP para retorno  Tempo de transmissão de arquivo Modelagem do tempo de resposta Total = 2RTT+ tempo de transmissão
  • 27. 2 © 2005 by Pearson Education 2 - 27 Características do HTTP persistente:  Requer 2 RTTs por objeto  OS deve manipular e alocar recursos do hospedeiro para cada conexão TCP Mas os browsers freqüentemente abrem conexões TCP paralelas para buscar objetos referenciados HTTP persistente  Servidor deixa a conexão aberta após enviar uma resposta  Mensagens HTTP subseqüentes entre o mesmo cliente/servidor são enviadas pela conexão Persistente sem pipelining:  O cliente emite novas requisições apenas quando a resposta anterior for recebida  Um RTT para cada objeto referenciado Persistente com pipelining:  Padrão no HTTP/1.1  O cliente envia requisições assim que encontra um objeto referenciado  Tão pequeno como um RTT para todos os objetos referenciados HTTP persistente
  • 28. 2 © 2005 by Pearson Education 2 - 28 Carriage return, line feed indica fim da mensagem  Dois tipos de mensagens HTTP: request, response  HTTP request message:  ASCII (formato legível para humanos) GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr (extra carriage return, line feed) Linha de pedido (comandos GET, POST, HEAD ) Linhas de cabeçalho Mensagem HTTP request
  • 29. 2 © 2005 by Pearson Education 2 - 29 Mensagem HTTP request: formato geral
  • 30. 2 © 2005 by Pearson Education 2 - 30 Método Post:  Página Web freqüentemente inclui entrada de formulário  A entrada é enviada para o servidor no corpo da entidade Método URL:  Utiliza o método GET  A entrada é enviada no campo de URL da linha de requisição: www.somesite.com/animalsearch?monkeys&banana Entrada de formulário
  • 31. 2 © 2005 by Pearson Education 2 - 31 HTTP/1.0  GET  POST  HEAD  Pede para o servidor deixar o objeto requisitado fora da resposta HTTP/1.1  GET, POST, HEAD  PUT  Envia o arquivo no corpo da entidade para o caminho especificado no campo de URL  DELETE  Apaga o arquivo especificado no campo de URL Tipos de métodos
  • 32. 2 © 2005 by Pearson Education 2 - 32 HTTP/1.0 200 OK Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data ... Linha de status (protocolo código de status frase de status) Linhas de cabeçalho Dados, ex.: arquivo html Mensagem HTTP response
  • 33. 2 © 2005 by Pearson Education 2 - 33 Na primeira linha da mensagem de resposta servidor  cliente. Alguns exemplos de códigos: 200 OK  Requisição bem-sucedida, objeto requisitado a seguir nesta mensagem 301 Moved permanently  Objeto requisitado foi movido, nova localização especificada a seguir nesta mensagem (Location:) 400 Bad request  Mensagem de requisição não compreendida pelo servidor 404 Not Found  Documento requisitado não encontrado neste servidor 505 HTTP version not supported Códigos de status das respostas
  • 34. 2 © 2005 by Pearson Education 2 - 34 1.Telnet para um servidor Web: Abre conexão TCP para a porta 80 (porta default do servidor HTTP) em cis.poly.edu. Qualquer coisa digitada é enviada para a porta 80 em cis.poly.edu 2.Digite um pedido GET HTTP: Digitando isso (tecle carriage return duas vezes), você envia este pedido HTTP GET mínimo (mas completo) ao servidor HTTP 3.Examine a mensagem de resposta enviada pelo servidor HTTP! GET /~ross/ HTTP/1.1 host: cis.poly.edu telnet cis.poly.edu 80 HTTP cliente: faça você mesmo!
  • 35. 2 © 2005 by Pearson Education 2 - 35 A maioria dos grandes Web sites utilizam cookies Quatro componentes: 1) Linha de cabeçalho do cookie na mensagem HTTP response 2) Linha de cabeçalho de cookie na mensagem HTTP request 3) Arquivo de cookie mantido no hospedeiro do usuário e manipulado pelo browser do usuário 4) Banco de dados backend no Web site Exemplo:  Susan acessa a Internet sempre do mesmo PC  Ela visita um site específico de e-commerce pela primeira vez  Quando a requisição HTTP inicial chega ao site, este cria um ID único e uma entrada no banco de dados backend para este ID Estado usuário-servidor: cookies
  • 36. 2 © 2005 by Pearson Education 2 - 36 Cliente Servidor usual HTTP request msg usual HTTP response + Set-cookie: 1678 usual HTTP request msg cookie: 1678 usual HTTP response msg usual HTTP request msg cookie: 1678 usual HTTP response msg especificação do cookie especificação do cookie servidor cria o ID 1678 para o usuário entrada no banco de dados backend acesso a c e s s o Cookie file amazon: 1678 ebay: 8734 Cookie file ebay: 8734 Cookie file amazon: 1678 ebay: 8734 Uma semana depois: Cookies: mantendo “estado”
  • 37. 2 © 2005 by Pearson Education 2 - 37 O que os cookies podem trazer:  Autorização  Cartões de compra  Recomendações  Estado de sessão do usuário (Web e-mail) ASIDE Cookies e privacidade:  Cookies permitem que sites saibam muito sobre você  Você pode fornecer nome e e-mail para os sites  Mecanismos de busca usam redirecionamento e cookies para saberem mais sobre você  Companhias de propaganda obtêm informações por meio dos sites Cookies
  • 38. 2 © 2005 by Pearson Education 2 - 38  Usuário configura o browser: acesso Web é feito por meio de um proxy  Cliente envia todos os pedidos HTTP para o Web cache  Se o objeto existe no Web cache: Web cache retorna o objeto  Ou o Web cache solicita objeto do servidor original e então envia o objeto ao cliente Objetivo: atender o cliente sem envolver o servidor Web originador da informação Web caches (proxy server)
  • 39. 2 © 2005 by Pearson Education 2 - 39  O cache atua tanto no servidor como no cliente  Tipicamente, o cache é instalado pelo ISP (universidade, companhia, ISP residencial) Por que Web caching?  Reduz o tempo de resposta para a requisição do cliente.  Reduz o tráfego num enlace de acesso de uma instituição.  A densidade de caches na Internet habilita os “fracos” provedores de conteúdo a efetivamente entregarem o conteúdo (mas fazendo P2P file sharing) Mais sobre Web caching
  • 40. 2 © 2005 by Pearson Education 2 - 40 Suponha:  Tamanho médio objeto = 100.000 bits  Taxa média de requisições dos browsers da instituição para os servidores de origem = 15/s  Atraso do roteador institucional para ir a qualquer servidor de origem e retornar ao roteador = 2 s Conseqüências:  Utilização da LAN = 15%  Utilização do link de acesso = 100%  Atraso total = atraso da Internet + atraso de acesso + atraso da LAN = 2 segundos + minutos + milissegundos Exemplo de caching
  • 41. 2 © 2005 by Pearson Education 2 - 41 Solução possível  Aumentar a largura de banda do enlace de acesso, como, 10 Mbps Conseqüências  Utilização da LAN = 15%  Utilização do enlace de acesso = 15%  Atraso total = atraso da Internet + atraso de acesso + atraso da LAN = 2 segundos + msegs + msegs  Freqüentemente é um upgrade caro Exemplo de caching
  • 42. 2 © 2005 by Pearson Education 2 - 42 Exemplo de caching Instalação do cache  Suponha que a taxa de acertos seja .4 Conseqüência  40% das requisições serão satisfeitas quase que imediatamente  60% das requisições serão satisfeitas pelo servidor de origem  Utilização do enlace de acesso reduzida para 60%, resultando em atrasos insignificantes (como 10 mseg)  Média de atraso total = atraso da Internet + atraso de acesso + atraso da LAN = .6*(2.01) segundos + milissegundos < 1,4 segundos
  • 43. 2 © 2005 by Pearson Education 2 - 43  Razão: não enviar objeto se a versão que o cliente já possui está atualizada.  Cliente: especifica data da versão armazenada no pedido HTTP  If-modified-since: <date>  Servidor: resposta não contém objeto se a cópia é atualizada: HTTP/1.0 304 Not Modified Cliente Servidor HTTP request msg If-modified-since: <date> HTTP response HTTP/1.0 304 Not Modified Objeto não modificado HTTP request msg If-modified-since: <date> HTTP response HTTP/1.1 200 OK <data> Objeto modificado GET condicional
  • 44. 2 © 2005 by Pearson Education 2 - 44  2.1 Princípios de aplicações de rede  2.2 Web e HTTP  2.3 FTP  2.4 Correio electrônico  SMTP, POP3, IMAP  2.5 DNS  2.6 Compartilhamento de arquivos P2P  2.7 Programação de socket com TCP  2.8 Programação de socket com UDP  2.9 Construindo um servidor Web Camada de aplicação
  • 45. 2 © 2005 by Pearson Education 2 - 45  Transferência de arquivos de e para o computador remoto  Modelo cliente servidor  Cliente: lado que inicia a transferência (seja de ou para o lado remoto)  Servidor: hospedeiro remoto  FTP: RFC 959  FTP servidor: porta 21 FTP: o protocolo de transferência de arquivos
  • 46. 2 © 2005 by Pearson Education 2 - 46  Cliente FTP contata o servidor FTP na porta 21 especificando o TCP como protocolo de transporte  Cliente obtém autorização pela conexão de controle  Cliente procura o diretório remoto enviando comandos pela conexão de controle  Quando o servidor recebe um comando para uma transferência de arquivo, ele abre uma conexão de dados TCP para o cliente  Após a transferência de um arquivo, o servidor fecha a conexão  Servidor abre uma segunda conexão de dados TCP para transferir outro arquivo  Conexão de controle: “fora da banda”  Servidor FTP mantém “estado”: diretório atual, autenticação anterior FTP: controle separado, conexões de dados
  • 47. 2 © 2005 by Pearson Education 2 - 47 Exemplos de comandos:  Envie um texto ASCII sobre canal de controle  USER username  PASS password  LIST retorna listagem do arquivo no diretório atual  RETR filename recupera (obtém) o arquivo  STOR filename armazena o arquivo no hospedeiro remoto Exemplos de códigos de retorno  Código de status e frase (como no HTTP)  331 Username OK, password required  125 data connection already open; transfer starting  425 Can’t open data connection  452 Error writing file FTP comandos, respostas
  • 48. 2 © 2005 by Pearson Education 2 - 48  2.1 Princípios de aplicações de rede  2.2 Web e HTTP  2.3 FTP  2.4 Correio electrônico  SMTP, POP3, IMAP  2.5 DNS  2.6 Compartilhamento de arquivos P2P  2.7 Programação de socket com TCP  2.8 Programação de socket com UDP  2.9 Construindo um servidor Web Camada de aplicação
  • 49. 2 © 2005 by Pearson Education 2 - 49 Três componentes principais:  Agentes de usuário  Servidores de correio  Simple mail transfer protocol: SMTP Agente de usuário “leitor de correio”  Composição, edição, leitura de mensagens de correio  Ex.: Eudora, Outlook, elm, Netscape Messenger  Mensagens de entrada e de saída são armazenadas no servidor Correio eletrônico
  • 50. 2 © 2005 by Pearson Education 2 - 50 Servidores de correio  Caixa postal contém mensagens que chegaram (ainda não lidas) para o usuário  Fila de mensagens contém as mensagens de correio a serem enviadas Protocolo SMTP permite aos servidores de correio trocarem mensagens entre si  Cliente: servidor de correio que envia  “servidor”: servidor de correio que recebe Correio eletrônico: servidores de correio
  • 51. 2 © 2005 by Pearson Education 2 - 51 Correio eletrônico: SMTP [RFC 821]  Usa TCP para transferência confiável de mensagens de correio do cliente ao servidor, porta 25  Transferência direta: servidor que envia para o servidor que recebe  Três fases de transferência  Handshaking (apresentação)  Transferência de mensagens  Fechamento  Interação comando/resposta  Comandos: texto ASCII  Resposta: código de status e frase  Mensagens devem ser formatadas em código ASCII de 7 bits
  • 52. 2 © 2005 by Pearson Education 2 - 52 1) Alice usa o agente de usuário (UA) para compor a mensagem e “para” [email protected] 2) O agente de usuário dela envia a mensagem para o seu servidor de correio; a mensagem é colocada na fila de mensagens. 3) O lado cliente do SMTP abre uma conexão TCP com o servidor de correio do Bob. 4) O cliente SMTP envia a mensagem de Alice pela conexão TCP. 5) O servidor de correio de Bob coloca a mensagem na caixa de correio de Bob. 6) Bob invoca seu agente de usuário para ler a mensagem. Cenário: Alice envia mensagem para Bob
  • 53. 2 © 2005 by Pearson Education 2 - 53 S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, 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: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection Exemplo de interação SMTP
  • 54. 2 © 2005 by Pearson Education 2 - 54  telnet nome do servidor 25  Veja resposta 220 do servidor  Envie comandos HELO, MAIL FROM, RCPT TO, DATA, QUIT a seqüência acima permite enviar um comando sem usar o agente de usuário do remetente Tente o SMTP você mesmo
  • 55. 2 © 2005 by Pearson Education 2 - 55 SMTP: palavras finais  SMTP usa conexões persistentes  SMTP exige que as mensagens (cabeçalho e corpo) estejam em ASCII de 7 bits  Servidor SMTP usa CRLF.CRLF para indicar o final da mensagem Comparação com HTTP:  HTTP: pull  E-mail: push  Ambos usam comandos e respostas em ASCII, interação comando/resposta e códigos de status  HTTP: cada objeto encapsulado na sua própria mensagem de resposta  SMTP: múltiplos objetos são enviados numa mensagem multiparte
  • 56. 2 © 2005 by Pearson Education 2 - 56 SMTP: protocolo para trocar mensagens de e-mail RFC 822: padrão para mensagens do tipo texto: • linhas de cabeçalho, ex.: – To: – From: – Subject: diferente dos comandos HTTP • corpo – a “mensagem”, ASCII somente com caracteres header body linha em branco Formato da mensagem de correio
  • 57. 2 © 2005 by Pearson Education 2 - 57  MIME: multimedia mail extension, RFC 2045, 2056  Linhas adicionais no cabeçalho declaram o tipo de conteúdo MIME From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data Dados multimídia tipo, subtipo, declaração de parâmetro Método usado para codificar dados Versão da MIME Dados codificados Formato das mensagens: extensões multimídia
  • 58. 2 © 2005 by Pearson Education 2 - 58  SMTP: entrega e armazena no servidor do destino  Protocolo de acesso: recupera mensagens do servidor  POP: Post Office Protocol [RFC 1939]  Autorização (agente <-->servidor) e download  IMAP: Internet Mail Access Protocol [RFC 1730]  Maiores recursos (mais complexo)  Manipulação de mensagens armazenadas no servidor  HTTP: Hotmail , Yahoo! Mail etc. Protocolos de acesso ao correio
  • 59. 2 © 2005 by Pearson Education 2 - 59 Fase de autorização  comandos do cliente:  user: declara nome do usuário  pass: password respostas do servidor  +OK  -ERR Fase de transação, cliente:  list: lista mensagens e tamanhos  retr: recupera mensagem pelo número  dele: apaga  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 alice S: +OK C: pass hungry S: +OK user successfully logged on Protocolo POP3
  • 60. 2 © 2005 by Pearson Education 2 - 60 Mais sobre POP3  O exemplo anterior usa o modo “download-and-delete”  Bob não pode reler o e-mail se ele trocar o cliente  “download-and-keep”: cópias das mensagens em clientes diferentes  POP3 é stateless através das sessões IMAP  Mantém todas as mensagens em um lugar: o servidor  Permite que o usuário organize as mensagens em pastas  IMAP mantém o estado do usuário através das sessões:  Nomes das pastas e mapeamentos entre os IDs da mensagem e o nome da pasta POP3 (mais) e IMAP
  • 61. 2 © 2005 by Pearson Education 2 - 61  2.1 Princípios de aplicações de rede  2.2 Web e HTTP  2.3 FTP  2.4 Correio electrônico  SMTP, POP3, IMAP  2.5 DNS  2.6 Compartilhamento de arquivos P2P  2.7 Programação de socket com TCP  2.8 Programação de socket com UDP  2.9 Construindo um servidor Web Camada de aplicação
  • 62. 2 © 2005 by Pearson Education 2 - 62 Pessoas: muitos identificadores:  RG, nome, passaporte Internet hospedeiros, roteadores:  Endereços IP (32 bits) - usados para endereçar datagramas  “nome”, ex.: gaia.cs.umass.edu - usados por humanos P.: Relacionar nomes com endereços IP? Domain Name System:  Base de dados distribuída implementada numa hierarquia de muitos servidores de nomes  Protocolo de camada de aplicação hospedeiro, roteadores se comunicam com servidores de nomes para resolver nomes (translação nome/endereço)  Nota: função interna da Internet, implementada como protocolo da camada de aplicação  Complexidade na “borda” da rede DNS: Dominain Name System
  • 63. 2 © 2005 by Pearson Education 2 - 63 DNS DNS services  Nome do hospedeiro para tradução de endereço IP  Hospedeiro aliasing  Nomes canônicos e alias mail server aliasing distribuição de carga  Servidores Web replicados: estabelece o endereço IP para um nome canônico Por que não centralizar o DNS?  Ponto único de falha  Volume de tráfego  Base centralizada de dados distante  Manutenção Não é escalável!
  • 64. 2 © 2005 by Pearson Education 2 - 64 Cliente quer o IP para www.amazon.com; 1a aprox.:  Cliente consulta um servidor de raiz para encontrar o servidor DNS com  Cliente consulta o servidor DNS com para obter o servidor DNS amazon.com  Cliente consulta o servidor DNS amazon.com para obter o endereço IP para www.amazon.com Base de dados distribuída, hierárquica
  • 65. 2 © 2005 by Pearson Education 2 - 65  São contatados pelos servidores de nomes locais que não podem resolver um nome  Servidores de nomes raiz:  Buscam servidores de nomes autorizados se o mapeamento do nome não for conhecido  Conseguem o mapeamento  Retornam o mapeamento para o servidor de nomes local Existem 13 servidores de nomes raiz no mundo DNS: servidores de nomes raiz
  • 66. 2 © 2005 by Pearson Education 2 - 66 Servidores top-level domain (TLD): responsáveis pelos domínios com, org, net, edu etc e todos os domínios top-level nacionais uk, fr, ca, jp.  Network Solutions mantém servidores para o TLD “com” TLD  Educause para o TLD “edu” Servidores DNS autorizados: servidores DNS de organizações, provêm nome de hospedeiro autorizado para mapeamentos IP para servidores de organizações (ex.: Web e mail).  Podem ser mantidos por uma organização ou provedor de serviços Servidores TLD e autoritários
  • 67. 2 © 2005 by Pearson Education 2 - 67  Não pertence estritamente a uma hierarquia  Cada ISP (ISP residencial, companhia, universidade) possui um  Também chamado de “servidor de nomes default”  Quando um hospedeiro faz uma pergunta a um DNS, a pergunta é enviada para seu servidor DNS local  Age como um proxy, encaminhando as perguntas para dentro da hierarquia Servidor de nomes local
  • 68. 2 © 2005 by Pearson Education 2 - 68  O hospedeiro em cis.poly.edu quer o endereço IP para gaia.cs.umass.edu Exemplo
  • 69. 2 © 2005 by Pearson Education 2 - 69 Consulta recursiva:  Transfere a tarefa de resolução do nome para o servidor de nomes consultado  Carga pesada? Consulta encadeada:  Servidor contatado responde com o nome de outro servidor de nomes para contato  “eu não sei isto, mas pergunte a este servidor” Consultas recursivas
  • 70. 2 © 2005 by Pearson Education 2 - 70 Uma vez que um servidor de nomes apreende um mapeamento, ele armazena o mapeamento num registro do tipo cache  Registro do cache tornam-se obsoletos (desaparecem) depois de um certo tempo  Servidores TLD são tipicamente armazenados em cache nos servidores de nome locais Mecanismos de atualização e notificação estão sendo projetados pelo IETF  RFC 2136  http://www.ietf.org/html.charters/dnsind-charter.html DNS: armazenando e atualizando registros
  • 71. 2 © 2005 by Pearson Education 2 - 71 Registros do DNS DNS: base de dados distribuída que armazena registros de recursos (RR)  Type = NS  name é um domínio (ex.: foo.com)  value é o endereço IP do servidor de nomes autorizados para este domínio formato dos RR: (name, value, type,ttl)  Type = A  name é o nome do computador  value é o endereço IP  Type = CNAME  name é um “apelido” para algum nome “canônico” (o nome real) www.ibm.com é realmente servereast.backup2.ibm.com  value é o nome canônico  Type = MX  value é o nome do servidor de correio associado com name
  • 72. 2 © 2005 by Pearson Education 2 - 72 DNS: protocolo e mensagem Protocolo DNS: mensagem de consulta e resposta , ambas com o mesmo formato de mensagem Cabeçalho da msg  Identificação: número de 16 bits para consulta, resposta usa o mesmo número  Flags:  Consulta ou resposta  Recursão desejada  Recursão disponível  Resposta é autorizada
  • 73. 2 © 2005 by Pearson Education 2 - 73 DNS: protocolo e mensagens Camada de aplicação
  • 74. 2 © 2005 by Pearson Education 2 - 74 Inserindo registros no DNS  Exemplo: empresa recém-criada “Network Utopia”  Registrar o nome networkuptopia.com num “registrar” (ex.: Network Solutions)  É necessário fornecer ao registrar os nomes e endereços IP do seu servidor nomes autorizados (primário e secundário)  Registrar insere dois RRs no servidor TLD do domínio com: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)  No servidor autorizado, inserir um registro Tipo A para www.networkuptopia.com e um registro Tipo MX para networkutopia.com  Como as pessoas obtêm o endereço IP do seu Web site? Camada de aplicação
  • 75. 2 © 2005 by Pearson Education 2 - 75  2.1 Princípios de aplicações de rede  2.2 Web e HTTP  2.3 FTP  2.4 Correio electrônico  SMTP, POP3, IMAP  2.5 DNS  2.6 Compartilhamento de arquivos P2P  2.7 Programação de socket com TCP  2.8 Programação de socket com UDP  2.9 Construindo um servidor Web Camada de aplicação
  • 76. 2 © 2005 by Pearson Education 2 - 76 Exemplo  Alice executa a aplicação cliente P2P em seu notebook  Intermitentemente, conecta-se à Internet; obtém novos endereços IP para cada conexão  pede por “Hey Jude”  a aplicação exibe outros pares que possuem uma cópia de Hey Jude.  Alice escolhe um dos pares, Bob.  o arquivo é copiado do PC de Bob para o notebook de Alice: HTTP  enquanto Alice faz o download, outros usuários fazem upload de Alice.  o par de Alice é tanto um cliente Web como um servidor Web transiente. Todos os pares são servidores = altamente escaláveis! Compartilhamento de arquivos P2P
  • 77. 2 © 2005 by Pearson Education 2 - 77 Projeto original “Napster” 1) Quando um par se conecta, ele informa ao servidor central:  Endereço IP  Conteúdo 2) Alice procura por “Hey Jude” 3) Alice requisita o arquivo de Bob P2P: diretório centralizado
  • 78. 2 © 2005 by Pearson Education 2 - 78  Ponto único de falhas  Gargalo de desempenho  Infração de copyright Transferência de arquivo é descentralizada, mas a localização de conteúdo é altamente centralizado P2P: problemas com diretório centralizado
  • 79. 2 © 2005 by Pearson Education 2 - 79  Totalmente distribuído  Sem servidor central  Protocolo de domínio público  Muitos clientes Gnutella implementando o protocolo Rede de cobertura: gráfico  Aresta entre o par X e o Y se não há uma conexão TCP  Todos os pares ativos e arestas estão na rede de sobreposição  aresta não é um enlace físico  Um determinado par será tipicamente conectado a <10 vizinhos na rede de sobreposição Query flooding: Gnutella
  • 80. 2 © 2005 by Pearson Education 2 - 80 Gnutella: protocolo  Mensagem de consulta (query) é enviada pelas conexões TCP existentes  Os pares encaminham a mensagem de consulta  QueryHit (encontro) é enviado pelo caminho reverso Escalabilidade: flooding de alcance limitado
  • 81. 2 © 2005 by Pearson Education 2 - 81 1.Para conectar o par X, ele precisa encontrar algum outro par na rede Gnutella: utiliza a lista de pares candidatos 2.X seqüencialmente, tenta fazer conexão TCP com os pares da lista até estabelecer conexão com Y 3.X envia mensagem de Ping para Y; Y encaminha a mensagem de Ping. 4.Todos os pares que recebem a mensagem de Ping respondem com mensagens de Pong. 5.X recebe várias mensagens de Pong. Ele pode então estabelecer conexões TCP adicionais. Desconectando pares: veja o problema para trabalho de casa! Gnutella: conectando pares
  • 82. 2 © 2005 by Pearson Education 2 - 82  Cada par é ou um líder de grupo ou está atribuído a um líder de grupo  Conexão TCP entre o par e seu líder de grupo  Conexões TCP entre alguns pares de líderes de grupo  O líder de grupo acompanha o conteúdo em todos os seus “discípulos” Explorando heterogeneidade: KaZaA
  • 83. 2 © 2005 by Pearson Education 2 - 83  Cada arquivo possui um hash e um descritor  O cliente envia a consulta de palavra-chave para o seu líder de grupo  O líder de grupo responde com os encontros:  Para cada encontro: metadata, hash, endereço IP  Se o líder de grupo encaminha a consulta para outros líderes de grupo, eles respondem com os encontros  O cliente então seleciona os arquivos para download  Requisições HTTP usando hash como identificador são enviadas aos pares que contêm o arquivo desejado KaZaA
  • 84. 2 © 2005 by Pearson Education 2 - 84  Limitações em uploads simultâneos  Requisita enfileiramento  Incentiva prioridades  Realiza downloads em paralelo Artifícios do KaZaA
  • 85. 2 © 2005 by Pearson Education 2 - 85  2.1 Princípios de aplicações de rede  2.2 Web e HTTP  2.3 FTP  2.4 Correio electrônico SMTP, POP3, IMAP  2.5 DNS  2.6 Compartilhamento de arquivos P2P  2.7 Programação de socket com TCP  2.8 Programação de socket com UDP  2.9 Construindo um servidor Web Camada de aplicação
  • 86. 2 © 2005 by Pearson Education 2 - 86 Objetivo: aprender a construir aplicações cliente-servidor que se comunicam usando sockets Socket API  Introduzida no BSD4.1 UNIX, 1981  Explicitamente criados, usados e liberados pelas aplicações  Paradigma cliente-servidor  Dois tipos de serviço de transporte via socket API:  Datagrama não confiável  Confiável, orientado a cadeias de bytes SOCKET Uma interface local, criada por aplicações, controlada pelo OS (uma “porta”) na qual os processos de aplicação podem tanto enviar quanto receber mensagens de e para outro processo de aplicação (local ou remoto) Programação de sockets
  • 87. 2 © 2005 by Pearson Education 2 - 87 Programação de sockets com TCP Socket: uma porta entre o processo de aplicação e o protocolo de transporte fim-a-fim (UCP or TCP) Serviço TCP: transferência confiável de bytes de um processo para outro
  • 88. 2 © 2005 by Pearson Education 2 - 88 Cliente deve contatar o servidor  Processo servidor já deve estar em execução  Servidor deve ter criado socket (porta) que aceita o contato do cliente Cliente contata o servidor  Criando um socket TCP local  Especificando endereço IP e número da porta do processo servidor  Quando o cliente cria o socket: cliente TCP estabelece conexão com o TCP do servidor Quando contatado pelo cliente, o TCP do servidor cria um novo socket para o processo servidor comunicar-se com o cliente  Permite ao servidor conversar com múltiplos clientes  Números da porta de origem são usados para distinguir o cliente (mais no capítulo 3) Ponto de vista da aplicação TCP fornece a transferência confiável, em ordem de bytes (“pipe”) entre o cliente e o servidor Programação de sockets com TCP
  • 89. 2 © 2005 by Pearson Education 2 - 89  Um stream é uma seqüência de caracteres que fluem para dentro ou para fora de um processo  Um stream de entrada é agregado a alguma fonte de entrada para o processo, ex.: teclado ou socket  Um stream de saída é agregado a uma fonte de saída, ex.: monitor ou socket Jargão stream
  • 90. 2 © 2005 by Pearson Education 2 - 90 Exemplo de aplicação cliente-servidor: 1) Cliente lê linha da entrada-padrão do sistema (inFromUser stream), envia para o servidor via socket (outToServer stream) 2) Servidor lê linha do socket 3) Servidor converte linha para letras maiúsculas e envia de volta ao cliente 4) Cliente lê a linha modificada através do (inFromServer stream) Programação de sockets com TCP Programação de sockets com TCP
  • 91. 2 © 2005 by Pearson Education 2 - 91 Interação cliente-servidor TCP
  • 92. 2 © 2005 by Pearson Education 2 - 92 import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream()); Cria stream de entrada Cria socket cliente, conecta ao servidor Cria stream de saída ligado ao socket Exemplo: cliente Java (TCP)
  • 93. 2 © 2005 by Pearson Education 2 - 93 Exemplo: cliente Java (TCP) BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); outToServer.writeBytes(sentence + 'n'); modifiedSentence = inFromServer.readLine(); System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } } Cria stream de entrada ligado ao socket Envia linha para o servidor Lê linha do servidor
  • 94. 2 © 2005 by Pearson Education 2 - 94 import java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence; ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())) Cria socket de aceitação na porta 6789 Espera, no socket de aceitação, por contato do cliente Cria stream de entrada ligado ao socket Exemplo: servidor Java (TCP)
  • 95. 2 © 2005 by Pearson Education 2 - 95 DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + 'n'; outToClient.writeBytes(capitalizedSentence); } } } Lê linha do socket Cria stream de saída ligado ao socket Escreve linha para o socket Fim do while loop, retorne e espere por outra conexão do cliente Exemplo: servidor Java (TCP)
  • 96. 2 © 2005 by Pearson Education 2 - 96  2.1 Princípios de aplicações de rede  2.2 Web e HTTP  2.3 FTP  2.4 Correio electrônico  SMTP, POP3, IMAP  2.5 DNS  2.6 Compartilhamento de arquivos P2P  2.7 Programação de socket com TCP  2.8 Programação de socket com UDP  2.9 Construindo um servidor Web Camadas de aplicação
  • 97. 2 © 2005 by Pearson Education 2 - 97 UDP: não há conexão entre o cliente e o servidor  Não existe apresentação  Transmissor envia explicitamente endereço IP e porta de destino em cada mensagem  Servidor deve extrair o endereço IP e porta do transmissor de cada datagrama recebido UDP: dados transmitidos podem ser recebidos fora de ordem ou perdidos Ponto de vista da aplicação UDP fornece a transferência não confiável de grupos de bytes (datagramas) entre o cliente e oservidor Programação de sockets com UDP
  • 98. 2 © 2005 by Pearson Education 2 - 98 Interação cliente-servidor: UDP
  • 99. 2 © 2005 by Pearson Education 2 - 99 Exemplo: cliente Java (UDP)
  • 100. 2 © 2005 by Pearson Education 2 - 100 import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); Cria stream de entrada Cria socket cliente Translada nome do hospedeiro para endereço IP usando DNS Exemplo: cliente Java (UDP)
  • 101. 2 © 2005 by Pearson Education 2 - 101 DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } } Cria datagrama com dados a enviar, tamanho, endereço IP porta Envia datagrama para servidor Lê datagrama do servidor Exemplo: cliente Java (UDP)
  • 102. 2 © 2005 by Pearson Education 2 - 102 import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) { DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); Cria socket datagrama na porta 9876 Cria espaço para datagramas recebidos Recebe datagrama Exemplo: servidor Java (UDP)
  • 103. 2 © 2005 by Pearson Education 2 - 103 String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress port); serverSocket.send(sendPacket); } } } Obtém endereço IP e número da porta do transmissor Escreve o datagrama para dentro do socket Termina o while loop, retorna e espera por outro datagrama Cria datagrama para enviar ao cliente Exemplo: servidor Java (UDP)
  • 104. 2 © 2005 by Pearson Education 2 - 104  2.1 Princípios de aplicações de rede  2.2 Web e HTTP  2.3 FTP  2.4 Correio electrônico  SMTP, POP3, IMAP  2.5 DNS  2.6 Compartilhamento de arquivos P2P  2.7 Programação de socket com TCP  2.8 Programação de socket com UDP  2.9 Construindo um servidor Web Camada de aplicação
  • 105. 2 © 2005 by Pearson Education 2 - 105  Manipule uma requisição HTTP  Aceite a requisição  analise o cabeçalho  Vobtenha um arquivo requisitado do sistema de arquivo do servidor  Crie uma mensagem de resposta HTTP:  Linhas de cabeçalho + arquivo  Envie a resposta para o cliente  Após criar o servidor, você pode requisitar um arquivo usando um browser (ex.: IE explorer)  Veja o texto para mais detalhes Construindo um servidor Web simples
  • 106. 2 © 2005 by Pearson Education 2 - 106 Nosso estudo de aplicações está completo agora!  Arquiteturas de aplicação  Cliente-servidor  P2P  Híbrida  Exigências dos serviços de aplicação:  Confiabilidade, banda passante, atraso  Modelo do serviço de transporte da Internet l  Orientado à conexão, confiável: TCP  Não confiável, datagramas: UDP  Protocolos específicos:  HTTP  FTP  SMTP, POP, IMAP  DNS  Programação de sockets Resumo
  • 107. 2 © 2005 by Pearson Education 2 - 107 Mais importante: características dos protocolos  Típica troca de mensagens comando/resposta:  Cliente solicita informação ou serviço  Servidor responde com dados e código de status  Formatos das mensagens:  Cabeçalhos: campos que dão informações sobre os dados  Dados: informação sendo comunicada  Controle vs. dados  In-band, out-of-band  Centralizado vs. descentralizado  Stateless vs. stateful  Transferência de mensagens confiável vs. não confiável  “complexidade na borda da rede” Resumo

Notas do Editor

  • #78: Esse slide está com um erro no original. A lozalização de conteúdo é centralizada e não descentralizada