View
224
Download
0
Category
Preview:
Citation preview
2: Camada de aplicação 1
Camada de Aplicação
transparências baseadas no livro“Computer Networking: A Top-Down Approach Featuring the Internet”
James Kurose e Keith Rosshttp://occawlonline.pearsoned.com/bookbind/pubbooks/kurose-ross1/
2: Camada de aplicação 2
Parte II: Camada de AplicaçãoObjetivos:• aspectos conceituais
de implementação de protocolos de rede
o paradigma cliente-servidor
o modelos de serviço• conhecer protocolos
examinando protocolos de aplicação “populares”
• protocolos específicos: o httpo ftpo smtpo pop o dns
• programando aplicações de rede
o API socket
2: Camada de aplicação 3
Aplicações e protocolos da camada de aplicação
aplicação: processos distribuídos comunicantes
o executam em hosts da rede no “espaço de usuário”
o troca de mensagens para implementar aplicação
o ex. email, ftp, Webprotocolos da camada de
aplicaçãoo uma “peça” de uma aplic.o define mensagens trocadas
pelas aplics e ações tomadaso usa serviços de comunicação
fornecidos pelos protocolos da camada subjacente (TCP, UDP)
aplicaçãotransport
rededata linkphysical
aplicaçãotransport
rededata linkphysical
aplicaçãotransport
rededata linkphysical
2: Camada de aplicação 4
Aplicações de rede: alguns jargões
Processo: programa em execução.
• dentro do mesmo host, dois processos se comunicam usando interprocess communication (definido pelo SO).
• processos executando em hosts diferentes se comunicam com um protocolo da camada de aplicação
• user agent: processoque faz interface entre usuário “acima” e rede“abaixo”. o implementa protocolo
em nível de aplicaçãoo Web: browsero Email: leitor de e-
mailo streaming
audio/video: media player
2: Camada de aplicação 5
Paradigma cliente-servidorAplic. típica de rede tem 2
peças: cliente e servidoraplicaçãotransport
rededata linkphysical
aplicaçãotransport
rededata linkphysical
Cliente:• inicia contato com servidor
tipicamente requisita serviços ao servidor,
• Web: cliente implementado no navegador; e-mail: em leitor de reader
requisição
reply
Servidor:• provê serviço requisitado pelo cliente• ex., servidor Web envia página Web
requisitada, servidor mail entrega e-mail
2: Camada de aplicação 6
Protocolos camada de aplicação (cont).
API: aplication programming interface
• define interface entre aplicação e camada de transporte
• socket: API Interneto 2 processos se comunicam
enviando dados em um socket, lendo dados de um socket
Q: como um processo “identifica” outro processo que ele quer se comunicar?
o endereço IP do host que executa outro processo
o “número de porta” –permite ao host receptor determinar a qual processo local deve ser entregue a mensagem
… muito mais será visto depois...
2: Camada de aplicação 7
Qual serviço de transporte uma aplicação precisa?Perdas de dados• algumas aplics. (ex., áudio)
toleram algumas perdas• outras (ex., transf. arq.,
telnet) requerem transferência dados 100% confiável
Timing• algumas aplics. (ex.
telefonia Internet, jogos interativos) requerem baixo retardo para serem “efetivos”
Largura de banda• algumas aplics. (ex.,
multimídia) requerem quantidade mínima de bandwidth para serem “efetivas”
• outras (“elastic aplics.”) fazem uso da bandwidth que conseguem
2: Camada de aplicação 8
Requisitos de serviço transporte de aplicações
Aplicação
transferência arq.e-mail
Documentos Webreal-time áudio/vídeo
áudio/vídeo armazen.jogos interativos
aplics. financeiras
Perdas dados
sem perdassem perdastolerantetolerante
tolerantetolerantesem perdas
Bandwidth
elásticoelásticoelásticoáudio: 5Kb-1Mbvídeo:10Kb-5Mbigual acimapoucos Kbps elástico
Sensível tempo
nãonãonãosim, 100’s msec
sim, poucos segssim, 100’s mssim e não
2: Camada de aplicação 9
Serviços do protocolo de transporte da Internet
serviço TCP:• orientado a conexão:
necessário setup entre cliente e servidor
• transporte confiável entre processos emissor e receptor
• controle de fluxo: emissor não “inunda” receptor
• controle de congestão: reduz taxa do emissor quando rede está sobrecarregada
• não fornece: garantias de tempo, e largura de banda mínima
serviço UDP:• transferência de dados
não confiável entre processos emissor e receptor
• não fornece: setup de conexão, confiabilidade, controle de fluxo, controle de congestão, garantias de tempo e de largura de banda
2: Camada de aplicação 10
Aplics. da Internet: seus protocolos de aplic. e de transporte
Aplicação
e-mailacesso a terminal remoto
Web transferência de arq.multimídia streaming
servidor de arq. remotoInternet telefonia
Protocolo da camadade aplicação
smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959]proprietário(ex. RealNetorks)NFSproprietário(ex., Vocaltec)
Protocolo transporte subjacente
TCPTCPTCPTCPTCP ou UDP
TCP ou UDPtipicamente UDP
2: Camada de aplicação 11
WWW: algum jargão
• Página WWW:o consiste de “objetos”o endereçada por uma URL
• Quase todas as páginasWWW consistem de:
o página base HTML, eo vários objetos
referenciados.• URL tem duas partes:
nome de hospedeiro, e nome de caminho:
• Agent de usuário paraWWW se chama de browser:
o MS Internet Explorero Netscape Communicator
• Servidor para WWW se chama “servidorWWW”:
o Apache (domínio público)o MS Internet Information
Server (IIS)
www.univ.br/algum-depto/pic.gif
2: Camada de aplicação 12
Web: o protocolo http
http: hypertext transfer protocol
• protocolo da camada de aplicação
• modelo cliente/servidoro cliente: navegador que
requisita, recebe, e “apresenta” objetos Web
o servidor: servidor Webenvia objetos em resposta a requisições
• http1.0: RFC 1945• http1.1: RFC 2068
PC rodandoExplorer
servidor rodandoservidor
NCSA Web
Mac rodandoNavigator
requisição http
requisição http
resposta http
resposta http
2: Camada de aplicação 13
Mais sobre o protocolo http
http: serviço de transporte TCP:
• cliente inicia conexão TCP (cria socket) ao servidor, porta 80
• servidor aceita conexão TCP do cliente
• mensagens http (mensagens do protocolo da camada de apl) trocadas entre browser (cliente http) e servidoreWWW (servidor http)
• encerra conexão TCP
http é “sem estado”• servidor não mantém
informação sobrepedidos anteriores do cliente
Protocolos que mantêm“estado” são complexos!
• história passada (estado) tem que ser guardada
• Caso caia servidor/cliente, suas visões do “estado” podem ser inconsistentes, devem ser reconciliadas
Nota
2: Camada de aplicação 14
Exemplo httpSuponha usuário entra com URL
www.someSchool.edu/someDepartment/home.index
1a. cliente http inicia conexãoTCP para servidor http (processo) emwww.someSchool.edu. Porta80 é a default para servidorhttp.
2. cliente http envia mensagemde requisição http (contendoURL) em um socket de conexão TCP
1b. servidor http no host www.someSchool.eduaguardando por conexão TCP na porta 80 “aceita” conexão, notificando cliente
3. servidor http recebemensagem de requisição, forma mensagem de respostacontendo objeto requisitado(someDepartment/home.index), envia mensagem no socket
tempo
(contém texto, referências para 10
imagens jpeg)
2: Camada de aplicação 15
Exemplo http (cont.)
5. cliente http recebe mensagemcontendo arquivo html, mostrahtml. Analisa arquivo html, encontra 10 objetos jpeg referenciados
6. Passos 1-5 repetidos para cadaum dos 10 objetos
4. servidor http fecha conexãoTCP.
time
2: Camada de aplicação 16
Conexões não persistente e persistente
Não persistente• HTTP/1.0• servidor analisa
pedido, responde, and encerra conexão TCP
• 2 RTTs para trazercada objeto(RTT=round trip time)
• transferência de cada objeto sofre de partida lenta
Persistente• default for HTTP/1.1• na mesma conexão TCP:
servidor analisa pedido, responde, analisa novo pedido,..
• Cliente envia pedidos paratodos objetos referenciadosassim que recebe o HTML base .
• Menos RTTs and menospartida lenta.
A maioria de browsers 1.0 usa connexões TCP paralelas.
2: Camada de aplicação 17
Formato de mensagens http: requisição
• dois tipos de mensagens http: requisição, resposta• mensagem de requisição http:
o ASCII (formato legível para ser-humano)
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 requisição(comandos GET,POST, HEAD)
linhas de cabeçalho
Carriage return, line feed
indicam fim da mensagem
2: Camada de aplicação 18
Msg. de requisição http: formato geral
2: Camada de aplicação 19
Mensagem de formato http: resposta
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
dados dados dados dados dados ...
linha de status(código do protocolo
código do statusfrase do status)
linhas decabeçalho
dados, ex., arquivo
html requisitado
2: Camada de aplicação 20
Códigos de status da resposta http
200 OKo sucesso, objeto pedido segue mais adiante nesta mensagem
301 Moved Permanentlyo objeto pedido mudou de lugar, nova localização
especificado mais adiante nesta mensagem (Location:)400 Bad Request
o mensagem de pedido não entendida pelo servidor404 Not Found
o documento pedido não se encontra neste servidor505 HTTP Version Not Supported
o versão de http do pedido não usada por este servidor
Na primeira linha da mensagem de respostaservidor->cliente. Alguns códigos típicos:
2: Camada de aplicação 21
Simulando um cliente http
1. Dê um telnet para seu servidor Web favorito:Abre conexão TCP para porta 80 (default do servidor http).
2. Digite uma requisição http GET:Teclando isso (pressione Enter 2vezes), você envia uma requisiçãoGET ao servidor http
3. Veja a msg de resposta do servidor http!
telnet www.eurecom.fr 80
GET /~ross/index.html HTTP/1.0
2: Camada de aplicação 22
HTML (HyperText Markup Language)
• HTML: uma linguagem simples para hipertextoo começou como versão simples de SGMLo construção básica: cadéias de texto anotadas
• Construtores de formato operam sobre cadéiaso <b> .. </b> bold (negrito)o <H1 ALIGN=CENTER> ..título centrado .. </H1>o <BODY bgcolor=white text=black link=red ..> .. </BODY>
• vários formatoso listas de bullets, listas ordenadas, listas de definiçãoo tabelaso frames
2: Camada de aplicação 23
Encadeamento de referências
• Referências <A HREF=LinkRef> ... </A>o a componentes do documento local
<A HREF=“importante”> clique para uma dica </A>o a documentos no servidor local
<A HREF=“../index.htm”> voltar ao sumário </A>o a documentos em outros servidores
<A HREF=“http://www.uff.br”> saiba sobre a UFF </A>• Multimídia
o imagem embutida: <IMG SRC=“eclipse”>o imagem externa: <A HREF=“eclipse.gif”> imagem maior </A>o vídeo Mpeg <A HREF=“ByeByeBrasil.mpg”> um bom filme </A>o som <A HREF=“http://www.sons.br/aniv.au”> feliz niver </A>
2: Camada de aplicação 24
Formulários e interação bidirecional
• Formulários transmitem informação do cliente ao servidor
• HTTP permite enviar formulários ao servidor
• Resposta enviada como página HTML dinâmica
• Formulários processados usando scripts CGI (programas que executam no servidor WWW)
o CGI - Common GatewayInterface
o scripts CGI escondem acesso a diferentes serviços
o servidor WWW atua como gateway universal
clienteWWW
servidorWWW
Sistema deinformação
GET/POST formulário
resposta: HTML
2: Camada de aplicação 25
Interação usuário-servidor: autenticaçãoMeta da autenticação: controle de
acesso aos documentos do servidor
• sem estado: cliente deveapresentar autorização com cada pedido
• autorização: tipicamente nome, senhao authorization: linha de
cabeçalho no pedidoo se não for apresentada
autorização, servidor negaaccesso, e coloca no cabeçalho da respostaWWW authenticate:
cliente servidormsg de pedido http comum
401: authorization req.WWW authenticate:
msg de pedido http comum+ Authorization:line
msg de resposta http comum
tempo
Browser guarda nome e senha paraevitar que sejam pedidos ao usuário a cada acesso.
msg de pedido http comum+ Authorization:line
msg de resposta http comum
2: Camada de aplicação 26
Interação usuário-servidor: cookies
• servidor envia “cookie” aocliente na msg de respostaSet-cookie: 1678453
• cliente apresenta cookie nos pedidos posteriorescookie: 1678453
• servidor casa cookie-apresentado com a info guardada no servidor
o autenticaçãoo lembrando preferências
do usuário, opções anteriores
cliente servidor
resposta http comum+Set-cookie: #
msg de pedido http comumcookie: # Ação
específica do cookie
msg de pedido http comum
msg de resposta http comum
msg de pedido http comumcookie: # Ação
específica do cookiemsg de resposta http comum
2: Camada de aplicação 27
Interação usuário-servidor: GET condicional
• Meta: não enviar objeto se cliente já tem (no cache) versão atual
• cliente: especifica data dacópia no cache no pedidohttpIf-modified-since:
<date>
• servidor: resposta não contém objeto se cópia no cache é atual: HTTP/1.0 304 Not
Modified
cliente servidor
msg de pedido httpIf-modified-since:
<date>
resposta httpHTTP/1.0
304 Not Modified
objeto não
modificado
msg de pedido httpIf-modified-since:
<date>
resposta httpHTTP/1.1 200 OK
…
<data>
objeto modificado
2: Camada de aplicação 28
Cache WWW (servidor-procurador)
• usuário configurabrowser: acessos WWW via procurador
• cliente envia todospedidos http ao procurador
o se objeto no cache do procurador, este o devolve imediatamentena resposta http
o senão, solicita objeto do servidor de origem, depois devolve respostahttp ao cliente
Meta: atender pedido do cliente sem envolver servidor de origem
clienteServidor-
procurador
cliente
pedido http
pedido http
resposta http
respostahttp
pedido http
respostahttp
pedido httpresposta http
Servidorde origem
Servidorde origem
2: Camada de aplicação 29
Por quê usar cache WWW?
Suposição: cache está“próximo” do cliente(p.ex., na mesma rede)
• tempo de respostamenor: cache “maispróximo” do cliente
• diminui tráfego aosservidores distantes
o muitas vezes é um gargalo o enlace que ligaa rede da instituição oudo provedor à Internet
Servidoresde origem
Internetpública
rede dainstituição LAN 10 Mbps
enlace de accesso 2 Mbps
cache dainstituição
2: Camada de aplicação 30
ftp: protocolo p/ transfer. de arquivos
• transfere arquivo de/para host remoto• modelo cliente/servidor
o cliente: lado que inicia transferênciao servidor: host remoto
• ftp: RFC 959• servidor ftp: porta 21
file transfer servidorFTP
interfacede FTP
de usuário
clienteFTP
sistema de arq. local
sistema de arquivos remoto
usuário no host
2: Camada de aplicação 31
ftp: conexões separadas para controle e dados• cliente ftp contacta servidor
ftp na porta 21, especificando TCP como protocolo de transporte
• duas conexões TCP abertas em paralelo:
o controle: troca comandos e respostas entre cliente e servidor.
“controle fora da banda”o dados: arquivo de dados
de/para servidor
clienteFTP
servidorFTP
conexão de controle TCPporta 21
conexão de dados TCPporta 20
Comandos simples:• enviados como texto ASCII
usando canal de controle
2: Camada de aplicação 32
ftp comandos, respostas
Exemplos de comandos:• enviados como texto ASCII
usando canal de controle• USER nomeusuário
• PASS senha
• LIST retorna uma lista de arquivos no diretório corrente
• RETR pega arquivo• STOR nomearquivo
armazena arquivo no host remoto
Exemplos de código 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
2: Camada de aplicação 33
Correio Eletrônico
Três grandes componentes:• agentes de usuário• servidores de correio• simple mail transfer protocol:
smtp
Agente de Usuário• a.k.a. “leitor de correio”• compor, editar, ler mensagens
de correio• ex., Eudora, Outlook• mensagens de saída e chegando
são armazenadas no servidor
caixa de correio do usuário
fila demensagens
de saída
agente de
usuário
servidor de correio
agente de
usuário
SMTP
SMTP
SMTP
agente de
usuário
agente de
usuário
agente de
usuárioagente de
usuário
servidor de correio
servidor de correio
2: Camada de aplicação 34
Correio Eletrônico: servidores de correio
Servidores de correio• caixa de correio contém
mensagens de chegada (ainda não lidas) p/ usuário
• fila de mensagens contém mensagens de saída (a serem enviadas)
• protocolo smtp entre servidores de correio para transferir mensagens de correio
o cliente: servidor de correio que envia
o “servidor”: servidor de correio que recebe
servidor de correio
agente de
usuário
SMTP
SMTP
SMTP
agente de
usuário
agente de
usuário
agente de
usuárioagente de
usuário
servidor de correio
servidor de correio
2: Camada de aplicação 35
Correio Eletrônico: smtp [RFC 821]
• usa tcp para a transferência confiável de msgs do correiodo cliente ao servidor, porta 25
• transferência direta: servidor remetente ao servidor receptor
• três fases da transferênciao handshaking (cumprimento)o transferência das mensagenso encerramento
• interação comando/respostao comandos: texto ASCIIo resposta: código e frase de status
• mensagens precisam ser em ASCII de 7-bits
2: Camada de aplicação 36
Interaction smtp típicaS: 220 doces.brC: HELO consumidor.br S: 250 Hello consumidor.br, pleased to meet you C: MAIL FROM: <ana@consumidor.br> S: 250 ana@consumidor.br... Sender ok C: RCPT TO: <bernardo@doces.br> S: 250 bernardo@doces.br ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Voce gosta de chocolate? C: Que tal sorvete? C: . S: 250 Message accepted for delivery C: QUIT S: 221 doces.br closing connection
2: Camada de aplicação 37
Experimente uma interação smtp :
• telnet smtp.das.ufsc.br 25
• veja resposta 220 do servidor• entre comandos HELO, MAIL FROM, RCPT TO,
DATA, QUIT
estes comandos permite que você envie correio sem usar um cliente (leitor de correio)
2: Camada de aplicação 38
smtp: últimas palavras• smtp usa conexões
persistentes• smtp requerque a mensagem
(cabeçalho e corpo) sejam em ascii de 7-bits
• algumas cadeias de caracteresnão são permitidas numamensagem (p.ex., CRLF.CRLF). Logo a mensagem pode ter queser codificada (normalmenteem base-64 ou “quoted printable”)
• servidor smtp usa CRLF.CRLFpara reconhecer o final damensagem
Comparação com http• http: pull (puxar)• email: push (empurrar)
• ambos tem interaçãocomando/resposta, códigosde status em ASCII
• http: cada object é encapsulado em sua própriamensagem de resposta
• smtp: múltiplos objetos de mensagem enviados numa mensagem de múltiplas partes
2: Camada de aplicação 39
Formato de uma mensagem
smtp: protocolo para trocarmsgs de correio
RFC 822: padrão para formatode mensagem de texto:
• linhas de cabeçalho, p.ex.,o To:o From:o Subject:diferentes dos comandos de
smtp!• corpo
o a “mensagem”, somente de caracteres ASCII
cabeçalho
corpo
linha em branco
2: Camada de aplicação 40
Formato de uma mensagem: extensões paramultimídia• MIME: multimedia mail extension, RFC 2045, 2056• linhas adicionais no cabeçalho da msg declaram tipo do
conteúdo MIME
From: ana@consumidor.br To: bernardo@doces.brSubject: Imagem de uma bela torta MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg
base64 encoded data ..... ......................... ......base64 encoded data
tipo, subtipo dedados multimídia,
declaração parâmetros
método usadop/ codificar dados
versão MIME
Dados codificados
2: Camada de aplicação 41
Tipos MIME Content-Type: tipo/subtipo; parâmetros
Text• subtipos exemplos: plain,
html
• charset=“iso-8859-1”,ascii
Image• subtipos exemplos : jpeg,
gif
Video• subtipos exemplos : mpeg,
quicktime
Audio• subtipos exemplos : basic
(8-bit codificado mu-law), 32kadpcm (codificação 32 kbps)
Application• outros dados que precisam
ser processados por um leitor para serem“visualizados”
• subtipos exemplos : msword, octet-stream
2: Camada de aplicação 42
Tipo MultipartFrom: ana@consumidor.br To: bernardo@doces.brSubject: Imagem de uma bela torta MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789
--98766789Content-Transfer-Encoding: quoted-printableContent-Type: text/plain
caro Bernardo, Anexa a imagem de uma torta deliciosa.--98766789Content-Transfer-Encoding: base64Content-Type: image/jpeg
base64 encoded data ..... ......................... ......base64 encoded data --98766789--
2: Camada de aplicação 43
Protocolos de accesso ao correio
• SMTP: entrega/armazenamento no servidor do receptor• protocolo de accesso ao correio: recupera do servidor
o POP: Post Office Protocol [RFC 1939]• autorização (agente <-->servidor) e transferência
o IMAP: Internet Mail Access Protocol [RFC 1730]• mais comandos (mais complexo)• manuseio de msgs armazenadas no servidor
o HTTP: Hotmail , Yahoo! Mail, Webmail, etc.
servidor de correio do remetente
SMTP SMTP POP3 ouIMAP
servidor de correiodo receptor
agente de
usuário
agente de
usuário
2: Camada de aplicação 44
Protocolo POP3fase de autorização• comandos do cliente:
o user: declara nomeo pass: senha
• servidor respondeo +OK
o -ERR
fase de transação, cliente:• list: lista números das
msgs• retr: recupera msg por
número• dele: apaga msg• quit
C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents>S: . C: dele 1 C: retr 2 S: <message 1 contents>S: . C: dele 2 C: quit S: +OK POP3 server signing off
S: +OK POP3 server ready C: user ana S: +OK C: pass faminta S: +OK user successfully logged on
2: Camada de aplicação 45
DNS: Domain Name System
Pessoas: muitos identificadores:
o CPF, nome, no. da Identidade
hospedeiros, roteadores Internet :
o endereço IP (32 bit) -usado p/ endereçar datagramas
o “nome”, ex., das.ufsc.br- usado por gente
P: como mapear entre nome e endereço IP?
Domain Name System:• base de dados distribuída
implementada na hierarquia de muitos servidores de nomes
• protocolo de camada de aplicaçãopermite que hospedeiros, roteadores, servidores de nomes se comuniquem para resolvernomes (tradução endereço/nome)
o obs: função imprescindível da Internet implementada como protocolo de camada de aplicação
o complexidade na borda da rede
2: Camada de aplicação 46
DNS
• Roda sobre UDP e usa a porta 53
• Especificado nas RFCs 1034 e 1035 e atualizado em outras RFCs.
• Outros serviços:o apelidos para
hospedeiros (aliasing)o apelido para o servidor
de mailso distribuição da carga
2: Camada de aplicação 47
Servidores de nomes DNS
• Nenhum servidor mantém todos os mapeamento nome-para-endereço IP
servidor de nomes local:o cada provedor, empresa tem
servidor de nomes local (default)o pedido DNS do host vai primeiro
ao servidor de nomes localservidor de nomes oficial
(com autoridade):o p/ host: guarda nome, endereço
IP deleo pode realizar tradução
nome/endereço para este nome
Por que não centralizar o DNS?
• ponto único de falha• volume de tráfego• base de dados
centralizada e distante• manutenção (da BD)
Não é escalável!
2: Camada de aplicação 48
DNS: Servidores raiz
• procurado por servidor local que não consegue resolver o nome
• servidor raiz:o procura servidor
oficial se mapeamento desconhecido
o obtém traduçãoo devolve
mapeamento ao servidor local
• ~ uma dúzia de servidores raiz no mundo
2: Camada de aplicação 49
Exemplo simples do DNS
host manga.ic.uff.brrequer endereço IP de www.cs.columbia.edu
1. Contata servidor DNS local, pitomba.ic.uff.br
2. pitomba.ic.uff.brcontata servidor raiz, se necessário
3. Servidor raiz contata servidor oficial cs.columbia.edu, se necessário solicitante
manga.ic.uff.brwww.cs.columbia.edu
servidor de nomes raiz
servidor oficialcs.columbia.edu
servidor localpitomba.ic.uff.br
1
23
45
6
2: Camada de aplicação 50
Exemplo de DNS
Servidor raiz:• pode não conhecer o
servidor de nomes oficial
• pode conhecer servidor de nomes intermediário: a quem contatar para descobrir o servidor de nomes oficial
solicitantemanga.ic.uff.br
www.cs.columbia.edu
servidor localpitomba.ic.uff.br
1
23
4 5
6
servidor oficialcs.columbia.edu
servidor intermediáriosaell.cc.columbia.edu
7
8
servidor de nomes raiz
2: Camada de aplicação 51
DNS: consultas interativasconsulta recursiva:• transfere a
responsabilidade de resolução do nome para o servidor de nomes contatado
consulta interativa:• servidor consultado
responde com o nome de um servidor de contato
• “Não conheço este nome, mas pergunte para esse servidor”
1
23
4
5 6
7
8
consulta interativa
servidor de nomes raíz
servidor localpitomba.ic.uff.br
servidor intermediáriosaell.cc.columbia.edu
servidor oficialcs.columbia.edu
solicitantemanga.ic.uff.br
www.cs.columbia.edu
2: Camada de aplicação 52
DNS: uso de cache, atualização de dados• uma vez que um servidor qualquer aprende um
mapeamento, ele o coloca numa cache localo futuras consultas são resolvidas usando dados
da cacheo entradas na cache são sujeitas a temporização
(desaparecem depois de um certo tempo)ttl = time to live (sobrevida)
2: Camada de aplicação 53
Registros DNSDNS: BD distribuída contendo resource records (RR)
• Tipo=NSo nome é domínio (p.ex.
foo.com.br)o valor é endereço IP de
servidor de nomesautoritativo para estedomínio
formato RR: (nome, valor, tipo, sobrevida)
• Tipo=Ao nome é nome de hospedeiroo valor é endereço IP
• Tipo=CNAMEo nome é nome alternativo
(alias) para algum nome“canônico” (verdadeiro)
o valor é o nome canônico
• Tipo=MXo nome é domínioo valor é nome do servidor de
correio para este domínio
2: Camada de aplicação 54
DNS: protocolo, mensagensprotocolo DNS: mensagens pedido e resposta, ambas com o
mesmo formato de mensagem
cabeçalho de msg• identification: ID de 16 bit
para pedido, resposta aopedido usa mesmo ID
• flags:o pedido ou respostao recursão desejadao recursão permitidao resposta é autoritativa
2: Camada de aplicação 55
DNS: protocolo, mensagens
campos nome, tiponum pedido
RRs em respostaao pedido
registros paraservidores autoritativos
info adicional “relevante” que pode ser usada
2: Camada de aplicação 56
Programação com sockets
API Sockets • apareceu no BSD4.1 UNIX
em 1981• são explicitamente criados,
usados e liberados por apls• paradigma cliente/servidor• dois tipos de serviço de
transporte via API Socketso datagrama não confiável o fluxo de bytes, confiável
uma interface (uma “porta”), local ao
hospedeiro, criada por e pertencente à aplicação, e
controlado pelo SO, através da qual um
processo de aplicação pode tanto enviar como
receber mensagens para/de outro processo
de aplicação (remoto ou local)
socket
Meta: aprender a construir aplicações cliente/servidor que se comunicam usando sockets
2: Camada de aplicação 57
Programação com sockets usando TCPSocket: uma porta entre o processo de aplicação e um
protocolo de transporte fim-a-fim (UDP ou TCP)Serviço TCP: transferência confiável de bytes de um
processo para outro
processo
TCP combuffers,variáveis
socket
estação ouservidor
processo
TCP combuffers,variáveis
socket
controlado peloprogramador deaplicação
controladopelo sistemaoperacional
estação ouservidor
internet
2: Camada de aplicação 58
Cliente deve contactar servidor• processo servidor deve antes
estar em execução• servidor deve antes ter
criado socket (porta) que aguarda contato do cliente
Cliente contacta servidor para:• criar socket TCP local ao
cliente• especificar endereço IP,
número de porta do processo servidor
• Quando cliente cria socket: TCP do cliente estabelece conexão com TCP do servidor
• Quando contatado pelo cliente, o TCP do servidor cria socket novopara que o processo servidor possa se comunicar com o cliente
o permite que o servidor converse com múltiplos clientes
TCP provê transferência confiável, ordenada de bytes
(“tubo”) entre cliente e servidor
ponto de vista da aplicação
Programação com sockets usando TCP
2: Camada de aplicação 59
Programação com sockets usando TCP
Exemplo de apl cliente-servidor:• cliente lê linha da entrada
padrão (fluxo doUsuário), envia para servidor via socket (fluxo paraServidor)
• servidor lê linha do socket• servidor converte linha para
letra maiúscula, devolcve parao cliente
• cliente lê linha modificado do socket (fluxo doServidor), imprime-a
Input stream: sequence of bytes into process
Output stream: sequence of bytes out of process
socket do cliente
doUsuário
pparaServidor
doServidor
2: Camada de aplicação 60
Comunicação entre sockets
2: Camada de aplicação 61
Interações cliente/servidor usando o TCP
aguarda chegada de pedido de conexãosocketConexão =socketRecepção.accept()
cria socket,porta=x, parareceber pedido:
socketRecepção =ServerSocket ()
cria socket,abre conexão a nomeHosp, porta=xsocketCliente =
Socket()
fechasocketConexão
lê resposta desocketCliente
fechasocketCliente
Servidor (executa em nomeHosp) Cliente
Envia pedido usandosocketClientelê pedido de
socketConexão
escreve resposta para socketConexão
TCP setup da conexão
2: Camada de aplicação 62
Exemplo: cliente Java (TCP)
import java.io.*; import java.net.*; class ClienteTCP {
public static void main(String argv[]) throws Exception {
String frase; String fraseModificada;
BufferedReader doUsuario = new BufferedReader(new InputStreamReader(System.in));
Socket socketCliente = new Socket(”idHosp", 6789);
DataOutputStream paraServidor = new DataOutputStream(socketCliente.getOutputStream());
Criafluxo de entrada
Criasocket de cliente,
conexão ao servidorCreate
output streamattached to socket
2: Camada de aplicação 63
Exemplo: cliente Java (TCP), cont.
BufferedReader doServidor = new BufferedReader(newInputStreamReader(socketCliente.getInputStream()));
frase = doUsuario.readLine();
paraServidor.writeBytes(frase + '\n');
fraseModificada = doServidor.readLine();
System.out.println(”Do Servidor: " + fraseModificada);
socketCliente.close();
} }
Criafluxo de entradaligado ao socket
Envia linhaao servidor
Lê linhado servidor
2: Camada de aplicação 64
Exemplo: servidor Java (TCP)import java.io.*; import java.net.*;
class servidorTCP {
public static void main(String argv[]) throws Exception {
String fraseCliente; StringfFraseMaiusculas;
ServerSocket socketRecepcao = new ServerSocket(6789);
while(true) {
Socket socketConexao = socketRecepcao.accept();
BufferedReader doCliente = new BufferedReader(newInputStreamReader(socketConexao.getInputStream()));
Cria socketpara recepçãona porta 6789
Aguarda, no socketpara recepção, o
contato do cliente
Cria fluxo deentrada, ligado
ao socket
2: Camada de aplicação 65
Exemplo: servidor Java (TCP), cont
DataOutputStream paraCliente = new DataOutputStream(socketConexão.getOutputStream());
fraseCliente= doCliente.readLine();
fraseEmMaiusculas= fraseCliente.toUpperCase() + '\n';
paraClient.writeBytes(fraseEmMaiusculas); }
} }
Lê linhado socket
Cria fluxode saída, ligado
ao socket
Escreve linhaao socket
Final do elo while,volta ao início e aguardaconexão de outro cliente
2: Camada de aplicação 66
Programação com sockets usando UDP
UDP: não tem “conexão” entre cliente e servidor
• não tem “handshaking”• remetente coloca
explicitamente endereço IP e porta do destino
• servidor deve extrair endereço IP, porta do remetente do datagramarecebido
UDP: dados transmitidos podem ser recebidos fora de ordem, ou perdidos
UDP provê transferência não confiável de grupos de bytes (“datagramas”) entre cliente e servidor
ponto de vista da aplicação
2: Camada de aplicação 67
Interações cliente/servidor usando o UDP
fechasocketCliente
Servidor (executa em nomeHosp)
lê resposta dosocketCliente
cria socket,socketCliente =DatagramSocket()
Cliente
cria, endereça (nomeHosp, porta=x,envia pedido em datagramausando socketCliente
cria socket,porta=x, parapedido que chega:socketServidor =DatagramSocket()
lê pedido dosocketServidor
escreve resposta ao socketServidorespecificando endereçoIP, número de porta do cliente
2: Camada de aplicação 68
Exemplo: cliente Java (UDP)
import java.io.*; import java.net.*;
class clienteUDP { public static void main(String args[]) throws Exception {
BufferedReader do Usuario= new BufferedReader(new InputStreamReader(System.in));
DatagramSocket socketCliente = new DatagramSocket();
InetAddress IPAddress = InetAddress.getByName(”idHosp");
byte[] dadosEnvio = new byte[1024]; byte[] dadosRecebidos = new byte[1024];
String frase = doUsuario.readLine();
dadosEnvio = frase.getBytes();
Criafluxo de enrada
Cria socket de cliente
Traduz nome de hospedeiro ao
endereço IP usando DNS
2: Camada de aplicação 69
Exemplo: cliente Java (UDP) cont.
DatagramPacket pacoteEnviado = new DatagramPacket(dadosEnvio, dadosEnvio.length,
IPAddress, 9876);
socketCliente.send(pacoteEnviado);
DatagramPacket pacoteRecebido = new DatagramPacket(dadosRecebidos, dadosRecebidos.length);
socketCliente.receive(pacoteRecebido);
String fraseModificada = new String(pacoteRecebido.getData());
System.out.println(”Do Servidor:" + fraseModificada); socketCliente.close(); }
}
Cria datagrama com dados para enviar,
comprimento, endereço IP, porta
Envia datagramaao servidor
Lê datagramado servidor
2: Camada de aplicação 70
Exemplo: servidor Java (UDP)
import java.io.*; import java.net.*;
class servidorUDP { public static void main(String args[]) throws Exception
{
DatagramSocket socketServidor = new DatagramSocket(9876);
byte[] dadosRecebidos = new byte[1024]; byte[] dadosEnviados = new byte[1024];
while(true) {
DatagramPacket pacoteRecebido = new DatagramPacket(dadosRecebidos,
dadosRecebidos.length);
socketServidor.receive(pacoteRecebido);
Cria socketpara datagramas
na porta 9876
Aloca memória parareceber datagrama
Recebedatagrama
2: Camada de aplicação 71
Exemplo: servidor Java (UDP), contString frase = new String(pacoteRecebido.getData());
InetAddress IPAddress = pacoteRecebido.getAddress();
int port = pacoteRecebido.getPort();
String fraseEmMaiusculas = frase.toUpperCase();
dadosEnviados = fraseEmMaiusculas.getBytes();
DatagramPacket pacoteEnviado = new DatagramPacket(dadosEnviados,
dadosEnviados.length, IPAddress, porta);
socketServidor.send(pacoteEnviado); }
}
}
Obtém endereço IP, no. de porta
do remetente
Escrevedatagramaao socket
Fim do elo while,volta ao início e aguardachegar outro datagrama
Cria datagrama p/enviar ao cliente
2: Camada de aplicação 72
Capítulo 2: Sumário
• Requisitos do servi;co de aplicação:
o confiabilidade, banda, retardo
• paradigma cliente-servidor • modelo de serviço do
transporte orientado a conexão, confiável daInternet: TCP
o não confiável, datagramas: UDP
Terminamos nosso estudo de aplicações de rede!
• Protocolos específicos:o httpo ftpo smtp, pop3o dns
• programação c/ socketso implementação
cliente/servidoro usando sockets tcp, udp
2: Camada de aplicação 73
Capítulo 2: Sumário
• troca típica de mensagenspedido/resposta:
o cliente solicita info ou serviçoo servidor responde com dados,
código de status• formatos de mensagens:
o cabeçalhos: campos com info sobre dados (metadados)
o dados: info sendo comunicada
Mais importante: aprendemos de protocolos
• msgs de controle X dadoso na banda, fora da banda
• centralizado X descentralizado • s/ estado X c/ estado• transferência de msgs
confiável X não confiável • “complexidade na borda da
rede”• segurança: autenticação
Recommended