Cap2

2: Camada de Aplicação 1

Capítulo 2: Camada de AplicaçãoMetas do capítulo:❒ aspectos conceituais e de

implementação deprotocolos de aplicaçãoem redes

❍ paradigma clienteservidor

❍ modelos de serviço❒ aprenda sobre protocolos

através do estudo deprotocolos populares donível da aplicação

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

❍ http❍ ftp❍ smtp❍ pop❍ dns

❒ a programação deaplicações de rede

❍ programação usando sockets


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

Aplicação: processos distribuídosem comunicação

❍ executem em hospedeirosno “espaço de usuário”

❍ trocam mensagens paraimplementar aplicação

❍ p.ex., correio, transf. dearquivo, WWW

Protocolos da camada de apl.❍ uma “parte” da aplicação❍ define mensagens trocadas

por apls e ações tomadas❍ usam serviços providos por

protocolos de camadasinferiores

aplicaçãotransporte

redeenlacefísica


redeenlacefísica


redeenlacefísica


Aplicações de rede: algum jargão

❒ Um processo é umprograma que executa numhospedeiro.

❒ 2 processos no mesmohospedeiro se comunicamusando communicação entreprocessos definida pelosistema operacional (SO).

❒ 2 processos emhospedeiros distintos secomunicam usando umprotocolo da camada deapalicação.

❒ Um agente de usuário(UA) é uma interfaceentre o usuário e aaplicação de rede.

❍ WWW: browser❍ Correio:

leitor/compositor demensagens

❍ streaming audio/video:tocador de mídia


Paradigma cliente-servidor (C-S)

Apl. de rede típica tem duaspartes: cliente and servidor


redeenlacefísica


redeenlacefísica

Cliente:❒ inicia contato com o servidor

(“fala primeiro”)❒ tipicamente solicita serviço do

servidor❒ para WWW, cliente

implementado no browser; paracorreio no leitor de mensagens

Servidor:❒ provê ao cliente o serviço

requisitado❒ p.ex., servidor WWW envia

página solicitada; servidor decorreio entrega mensagens

pedido

resposta


Protocolos da camada de aplicação (cont).

API: interface deprogramação deaplicações

❒ define interface entreaplicação e camada detransporte

❒ socket (= tomada) : APIda Internet

❍ 2 processos se comunicamenviando dados para umsocket ou lendo dados deum socket

P: como um processo pode“identificar”o outroprocesso com o qualquer se comunicar?

❍ endereço IP dohospedeiro do outroprocesso

❍ “número de porta” -permite que o hospedeiroreceptor determine aqual processo deve serentregue a mensagem

… voltamos mais tarde a este assunto.2: Camada de Aplicação 6

De que serviço de transporte umaaplicação precisa?Perda de dados❒ algumas apls (p.ex. áudio)

podem tolerar algumasperdas

❒ outras (p.ex., transf. dearquivos, telnet) requeremtransferência 100%confiável

Temporização❒ algumas apls (p.ex.,

telefonia Internet, jogosinterativos) requerembaixo retardo para serem“viáveis”

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

multimídia) requeremquantia mínima de bandapara serem “viáveis”

❒ outras apls (“apls elásticas”)conseguem usar qq quantiade banda disponível


Requisitos do serviço de transporte de apls comuns

Aplicação

transferência de arqscorreio

documentos WWWáudio/vídeo de

tempo realáudio/vídeo gravado

jogos interativosapls financeiras

Perdas

sem perdassem perdassem perdastolerante

tolerantetolerantesem perdas

Banda

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

Sensibilidadetemporal

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

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


Serviços providos por protocolos detransporte Internet

serviço TCP:❒ orientado a conexão: setup

requerido entre cliente,servidor

❒ transporte confiável entreprocessos remetente ereceptor

❒ controle de fluxo: remetentenão vai “afogar” receptor

❒ controle decongestionamento:estrangular remetente quandoa rede carregada

❒ não provê: garantiastemporais ou de banda mínima

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

confiável entre processosremetente e receptor

❒ não provê: setup da conexão,confiabilidade, controle defluxo, controle decongestionamento, garantiastemporais ou de bandamínima

P: Qual é o interesse em ter umUDP?


Apls Internet: seus protocolos e seusprotocolos de transporte

Aplicação

correio eletrônicoaccesso terminal remoto

WWW transferência de arquivos

streaming multimídia

servidor de arquivo remototelefonia Internet

Protocolo da camada de apl

smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959]proprietário(p.ex. RealNetworks)NSFproprietário(p.ex., Vocaltec)

Protocolo detransporte usado

TCPTCPTCPTCPTCP ou UDP

TCP ou UDPtipicamente UDP


WWW: algum jargão

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

❒ Quase todas as páginasWWW consistem de:

❍ página base HTML, e❍ vários objetos

referenciados.❒ URL tem duas partes:

nome de hospedeiro, enome de caminho:

❒ Agent de usuário paraWWW se chama debrowser:

❍ MS Internet Explorer❍ Netscape Communicator

❒ Servidor para WWW sechama “servidorWWW”:

❍ Apache (domínio público)❍ MS Internet Information

Server (IIS)

www.univ.br/algum-depto/pic.gif


WWW: o protocolo http

http: hypertext transferprotocol

❒ protocolo da camada deaplicação para WWW

❒ modelo cliente/servidor❍ cliente: browser que

pede, recebe, “visualiza”objetos WWW

❍ servidor: servidorWWW envia objetos emresposta a pedidos

❒ http1.0: RFC 1945❒ http1.1: RFC 2068

PC executaExplorer

Servidor executandoservidor WWW

do NCSA

Mac executaNavigator

pedido http

pedido http

resposta http

resposta http


Mais sobre o protocolo http

http: serviço detransporte TCP:

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

❒ servidor aceita conexão TCPdo cliente

❒ mensagens http (mensagensdo protocolo da camada deapl) 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 docliente

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


Exemplo de httpSupomos que usuário digita a URL

www.algumaUniv.br/algumDepartmento/inicial.index

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

2. cliente http envia mensagemde pedido de http (contendoURL) através do socket daconexão TCP

1b. servidor http no hospedeirowww.algumaUniv.br espera porconexão TCP na porta 80.“aceita” conexão, avisando aocliente

3. servidor http recebe mensagemde pedido, formula mensagemde resposta contendo objetosolicitado(algumDepartmento/inicial.index),envia mensagem via socket

tempo

(contém texto, referências a 10

imagens jpeg)


Exemplo de http (cont.)

5. cliente http recebe mensagemde resposta contendo arquivohtml, visualiza html.Analisando arquivo html,encontra 10 objetos jpegreferenciados

6. Passos 1 a 5 repetidos paracada um dos 10 objetos jpeg

4. servidor http encerra conexãoTCP .

tempo


Conexões não persistente and persistente

Não persistente❒ HTTP/1.0❒ servidor analisa

pedido, responde, andencerra conexão TCP

❒ 2 RTTs para trazercada objeto(RTT=round trip time)

❒ transferência de cadaobjeto sofre departida lenta

Persistente❒ default for HTTP/1.1❒ na mesma conexão TCP:

servidor analisa pedido,responde, analisa novopedido,..

❒ Cliente envia pedidospara todos objetosreferenciados assimque recebe o HTMLbase .

❒ Menos RTTs and menospartida lenta.

A maioria de browsers 1.0 usa connexões TCP paralelas.


formato de mensagem http: pedido

❒ Dois tipos de mensagem http: pedido, resposta❒ mensagem de pedido http:

❍ ASCII (formato legível por pessoas)

GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr

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

linha do pedido(comandos GET, POST, HEAD)

linhas docabeçalho

Carriage return, line feed

indicate fimde mensagem


mensagem de pedido http: formato geral


formato de mensagem 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 ...

linha de status(protocolo,

código de status,frase de status)

linhas decabeçalho

dados, p.ex., arquivo html

solicitado


códigos de status da resposta http

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

301 Moved Permanently❍ objeto pedido mudou de lugar, nova localização

especificado mais adiante nesta mensagem (Location:)400 Bad Request

❍ mensagem de pedido não entendida pelo servidor404 Not Found

❍ documento pedido não se encontra neste servidor505 HTTP Version Not Supported

❍ 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:


Experimente você com http (do lado cliente)

1. Use cliente telnet para seu servidor WWW favorito:Abre conexão TCP para a porta 80(porta padrão do servidor http) a www.ic.uff.br.Qualquer coisa digitada é enviada para aporta 80 do www.ic.uff.br

telnet www.ic.uff.br 80

2. Digite um pedido GET http:GET /~michael/index.html HTTP/1.0 Digitando isto (deve teclar

ENTER duas vezes), está enviandoeste pedido GET mínimo (porém completo) ao servidor http

3. Examine a mensagem de resposta enviado peloservidor http !


HTML (HyperText Markup Language)

❒ HTML: uma linguagem simples para hipertexto❍ começou como versão simples de SGML❍ construção básica: cadéias de texto anotadas

❒ Construtores de formato operam sobre cadéias❍ <b> .. </b> bold (negrito)❍ <H1 ALIGN=CENTER> ..título centrado .. </H1>❍ <BODY bgcolor=white text=black link=red ..> .. </BODY>

❒ vários formatos❍ listas de bullets, listas ordenadas, listas de definição❍ tabelas❍ frames


Encadeamento de referências

❒ Referências <A HREF=LinkRef> ... </A>❍ a componentes do documento local

<A HREF=“importante”> clique para uma dica </A>❍ a documentos no servidor local

<A HREF=“../index.htm”> voltar ao sumário </A>❍ a documentos em outros servidores

<A HREF=“http://www.uff.br”> saiba sobre a UFF </A>❒ Multimídia

❍ imagem embutida: <IMG SRC=“eclipse”>❍ imagem externa: <A HREF=“eclipse.gif”> imagem maior </A>❍ vídeo Mpeg <A HREF=“ByeByeBrasil.mpg”> um bom filme </A>❍ som <A HREF=“http://www.sons.br/aniv.au”> feliz niver </A>


Formulários e interação bidirecional

❒ Formulários transmiteminformação do cliente aoservidor

❒ HTTP permite enviarformulários ao servidor

❒ Resposta enviada comopágina HTML dinâmica

❒ Formulários processados usandoscripts CGI (programas queexecutam no servidor WWW)

❍ CGI - Common GatewayInterface

❍ scripts CGI escondemacesso a diferentes serviços

❍ servidor WWW atua comogateway universal

clienteWWW

servidorWWW

Sistema deinformação

GET/POSTformulário

resposta:HTML 2: Camada de Aplicação 24

Interação usuário-servidor: autenticação Meta da autenticação: controle de

acesso aos documentos doservidor

❒ sem estado: cliente deveapresentar autorização comcada pedido

❒ autorização: tipicamente nome,senha

❍ authorization: linha decabeçalho no pedido

❍ se não for apresentadaautorização, servidor negaaccesso, e coloca nocabeç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



Interação usuário-servidor: cookies

❒ servidor envia “cookie” aocliente na msg de respostaSet-cookie: 1678453

❒ cliente apresenta cookienos pedidos posteriorescookie: 1678453

❒ servidor casa cookie-apresentado com a infoguardada no servidor

❍ autenticação❍ lembrando preferências

do usuário, opçõesanteriores

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 pedido http comumcookie: # Ação

específica do cookiemsg de resposta http comum


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

❒ Meta: não enviar objeto secliente já tem (no cache)versão atual

❒ cliente: especifica data dacópia no cache no pedidohttpIf-modified-since:

<date>

❒ servidor: resposta nãocontém objeto se cópia nocache é 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


Cache WWW (servidor-procurador)

❒ usuário configurabrowser: acessos WWWvia procurador

❒ cliente envia todospedidos http aoprocurador

❍ se objeto no cache doprocurador, este odevolve imediatamentena resposta http

❍ senão, solicita objeto doservidor 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

resposta http

pedido http

resposta http

pedido httpresposta http

Servidorde origem

Servidorde origem


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

❍ muitas vezes é umgargalo o enlace que ligaa rede da instituição oudo provedor à Internet

Servidoresde origem

Internet pública

rede dainstituição LAN 10 Mbps

enlace de accesso 2 Mbps

cache dainstituição


ftp: o protocolo de transferênciade arquivos

❒ transferir arquivo de/para hospedeiro remoto❒ modelo cliente/servidor

❍ cliente: lado que inicia transferência (pode ser de oupara o sistema remoto)

❍ servidor: hospedeiro remoto❒ ftp: RFC 959❒ servidor ftp: porta 21

transferênciado arquivo FTP

servidor

Interfacedo usuário

FTP

cliente FTP

sistema dearquivoslocal

sistema dearquivosremoto

usuáriona

estação


ftp: conexões separadas p/ controle, dados

❒ cliente ftp contata servidorftp na porta 21,especificando TCP comoprotocolo de transporte

❒ são abertas duas conexõesTCP paralelas:

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

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

de/para servidor❒ servidor ftp mantém

“estado”: directório corrente,autenticação realizada

cliente FTP

servidor FTP

conexão de controleTCP, porta 21

conexão de dadosTCP, porta 20


Ftp: comandos, respostas

Comandos típicos:❒ enviados em texto ASCII pelo

canal de controle❒ USER nome

❒ PASS senha

❒ LIST devolve lista de arquivosno directório corrente

❒ RETR arquivo recupera (lê)arquivo remoto

❒ STOR arquivo armazena(escreve) arquivo no hospedeiroremoto

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

para http)❒ 331 Username OK, password

required❒ 125 data connection

already open; transferstarting

❒ 425 Can’t open dataconnection

❒ 452 Error writing file


Correio Eletrônico

Três grandes componentes:❒ agentes de usuário (UA)❒ servidores de correio❒ simple mail transfer protocol:

smtp

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

de correio❒ p.ex., Eudora, Outlook, elm,

Netscape Messenger❒ 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


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émmensagens de saída (a seremenviadas)

❒ protocolo smtp entreservidores de correio paratransferir mensagens decorreio

❍ cliente: servidor decorreio que envia

❍ “servidor”: servidor decorreio 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


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 servidorreceptor

❒ três fases da transferência❍ handshaking (cumprimento)❍ transferência das mensagens❍ encerramento

❒ interação comando/resposta❍ comandos: texto ASCII❍ resposta: código e frase de status

❒ mensagens precisam ser em ASCII de 7-bits


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


Experimente você uma interação smtp :

❒ telnet nomedoservidor 25

❒ veja resposta 220 do servidor❒ entre comandos HELO, MAIL FROM, RCPT TO,

DATA, QUIT

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


smtp: últimas palavras

❒ smtp usa conexõespersistentes

❒ smtp requerque a mensagem(cabeçalho e corpo) sejam emascii 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 “quotedprintable”)

❒ 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 demensagem enviados numamensagem de múltiplaspartes


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.,❍ To:❍ From:❍ Subject:diferentes dos comandos de

smtp!❒ corpo

❍ a “mensagem”, somente decaracteres ASCII

cabeçalho

corpo

linha em branco


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: [email protected]: [email protected]: Imagem de uma bela tortaMIME-Version: 1.0Content-Transfer-Encoding: base64Content-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


Tipos MIMEContent-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 32kbps)

Application❒ outros dados que precisam

ser processados por umleitor para serem“visualizados”

❒ subtipos exemplos :msword, octet-stream


Tipo MultipartFrom: [email protected]: [email protected]: Imagem de uma bela tortaMIME-Version: 1.0Content-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--


Protocolos de accesso ao correio

❒ SMTP: entrega/armazenamento no servidor do receptor❒ protocolo de accesso ao correio: recupera do servidor

❍ POP: Post Office Protocol [RFC 1939]• autorização (agente <-->servidor) e transferência

❍ IMAP: Internet Mail Access Protocol [RFC 1730]• mais comandos (mais complexo)• manuseio de msgs armazenadas no servidor

❍ HTTP: Hotmail , Yahoo! Mail, Webmail, etc.

servidor de correio do remetente

SMTP SMTP POP3 ouIMAP

servidor de correiodo receptor

agente de

usuário

agente de

usuário


Protocolo POP3

fase de autorização❒ comandos do cliente:

❍ user: declara nome❍ pass: senha

❒ servidor responde❍ +OK❍ -ERR

fase de transação, cliente:❒ list: lista números das

msgs❒ retr: recupera msg por

número❒ dele: apaga msg❒ quit

C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off

S: +OK POP3 server ready C: user ana S: +OK C: pass faminta S: +OK user successfully logged on


DNS: Domain Name System

Pessoas: muitosidentificadores:

❍ CPF, nome, no. dePassaporte

hospedeiros, roteadoresInternet :

❍ endereço IP (32 bit) -usado p/ endereçardatagramas

❍ “nome”, e.g.,jambo.ic.uff.br - usadopor gente

P: como mapear entrenome e endereço IP?

Domain Name System:❒ base de dados distribuída

implementada na hierarquia demuitos servidores de nomes

❒ protocolo de camada de aplicaçãopermite hospedeiros, roteadores,servidores de nomescommunicarem para resolvernomes (tradução endereço/nome)

❍ note: função imprescindível daInternet implementada comoprotocolo de camada deaplicação

❍ complexidade na borda da rede


Servidores de nomes DNS

❒ Nenhum servidor mantémtodos os mapeamento nome-para-endereço IP

servidor de nomes local:❍ cada provedor, empresa tem

servidor de nomes local (default)❍ pedido DNS de hospedeiro vai

primeiro ao servidor de nomeslocal

servidor de nomes autoritativo:❍ p/ hospedeiro: guarda nome,

endereço IP dele❍ pode realizar tradução

nome/endereço para este nome

Por quê não centralizar oDNS?

❒ ponto único de falha❒ volume de tráfego❒ base de dados

centralizada e distante❒ manutenção (da BD)

Não é escalável!


DNS: Servidores raíz

❒ procurado por servidorlocal que não consegueresolver o nome

❒ servidor raíz:❍ procura servidor

autoritativo semapeamentodesconhecido

❍ obtém tradução❍ devolve

mapeamento aoservidor local

❒ ~ uma dúzia deservidores raíz nomundo


Exemplo simples do DNS

hospedeiromanga.ic.uff.br requerendereço IP dewww.cs.columbia.edu

1. Contata servidor DNS local,pitomba.ic.uff.br

2. pitomba.ic.uff.brcontata servidor raíz, senecessário

3. Servidor raíz contataservidor autoritativocs.columbia.edu, senecessário

solicitantemanga.ic.uff.br

www.cs.columbia.edu

servidor denomes raíz

servidor autoritativocs.columbia.edu

servidor localpitomba.ic.uff.br

1

23

45

6


Exemplo de DNS

Servidor raíz:❒ pode não conhecer o

servidor de nomesautoritativo

❒ pode conhecerservidor de nomesintermediário: a quemcontactar paradescobrir o servidorde nomes autoritativo


www.cs.columbia.edu


1

23

4 5

6


servidor intermediáriosaell.cc.columbia.edu

7

8



DNS: consultas iteratadas

consulta recursiva:❒ transfere a

responsabilidade dereolução do nome parao servidor de nomescntatado

❒ carga pesada?

consulta iterada:❒ servidor consultado

responde com o nomede um servidor decontato

❒ “Não conheço estenome, mas perguntepara esse servidor”

1

23

4

5 6

7

8

consultaiterrada



servidor intermediáriosaell.cc.columbia.edu



www.cs.columbia.edu


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

❒ uma vez um servidor qualquer aprende ummapeamento, ele o coloca numa cache local❍ futuras consultas são resolvidas usando dados

da cache❍ entradas no cache são sujeitas a temporização

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

❒ estão sendo projetados pela IETF mecanismosde atualização/notificação dos dados

❍ RFC 2136❍ http://www.ietf.org/html.charters/dnsind-charter.html


Registros DNSDNS: BD distribuída contendo resource records (RR)

❒ Tipo=NS❍ nome é domínio (p.ex.

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

servidor de nomesautoritativo para estedomínio

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

❒ Tipo=A❍ nome é nome de hospedeiro❍ valor é endereço IP

❒ Tipo=CNAME❍ nome é nome alternativo

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

❍ valor é o nomecanônico

❒ Tipo=MX❍ nome é domínio❍ valor é nome do servidor de

correio para este domínio2: Camada de Aplicação 52

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:❍ pedido ou resposta❍ recursão desejada❍ recursão permitida❍ resposta é autoritativa


DNS: protocolo, mensagens

campos nome, tiponum pedido

RRs em respostaao pedido

registros paraservidores autoritativos

info adicional “relevante” que pode ser usada


Programação com sockets

API Sockets❒ apareceu em BSD4.1 UNIX,

1981❒ explicitamente criados,

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

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

uma interface (uma“porta”), local ao

hospedeiro, criada por epertencente à aplicação, e

controlado pelo SO,através da qual um

processo de aplicaçãopode tanto enviar como

receber mensagenspara/de outro processo

de aplicação(remoto ou local)

socket

Meta: aprender construir aplicação cliente/servidor quecomunica usando sockets


Programação com sockets usando TCP

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

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

processo

TCP combuffers,variáveis

socket

controlado peloprogramador de

aplicação

controladopelo sistemaoperacional

estação ouservidor

processo

TCP combuffers,variáveis

socket

controlado peloprogramador deaplicação

controladopelo sistemaoperacional

estação ouservidor

internet


Cliente deve contactar servidor❒ processo servidor deve antes

estar em execução❒ servidor deve antes ter

criado socket (porta) queaguarda contato do cliente

Cliente contacta servidor por:❒ criar socket TCP local ao

cliente❒ especificar endereço IP,

número de porta do processoservidor

❒ Quando cliente cria socket: TCPdo cliente estabelece conexãoao servidor TCP

❒ Quando contactado pelo cliente,servidor TCP cria socket novoprocesso servidor poder secomunicar com o cliente

❍ permite que o servidorconverse com múltiplosclientes

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

(“tubo”) entre cliente e servidor

ponto de vista da aplicação




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 dosocket (fluxo doServidor),imprime-a

Input stream: sequence ofbytes into process

Output stream: sequence ofbytes out of process

socket do cliente

doUsuário

pp

ar

aS

er

vi

do

r

do

Se

rv

id

or


Interações cliente/servidor com socket: 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 idHosp, porta=xsocketCliente =

Socket()

fechasocketConexão

lê resposta desocketCliente

fechasocketCliente

Servidor (executa em idHosp) Cliente

Envia pedido usandosocketClientelê pedido de

socketConexão

escreve resposta para socketConexão

TCP setup da conexão


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


Exemplo: cliente Java (TCP), cont.

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

frase = doUsuario.readLine();

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

fraseModificada = doServidor.readLine();

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

socketCliente.close(); } }

Criafluxo de entradaligado ao socket

Envia linhaao servidor

Lê linhado servidor


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(new InputStreamReader(socketConexao.getInputStream()));

Cria socketpara recepçãona porta 6789

Aguarda, no socketpara recepção, o

contato do cliente

Cria fluxo deentrada, ligado

ao socket


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


Programação com sockets usando UDP

UDP: não tem “conexão” entrecliente e servidor

❒ não tem “handshaking”❒ remetente coloca

explicitamente endereço IPe porta do destino

❒ servidor deve extrairendereço IP, porta doremetente do datagramarecebido

UDP: dados transmitidospodem ser recebidos forade 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


Interações cliente/servidor com socket: UDP

fechasocketCliente

Servidor (executa em idHosp)

lê resposa dosocketCliente

cria socket,socketCliente = DatagramSocket()

Cliente

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

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

lê pedido dosocketServidor

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


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


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 comdados para enviar,

comprimento,endereço IP, porta

Envia datagramaao servidor

Lê datagramado servidor


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


Exemplo: servidor Java (UDP), cont String 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çoIP, 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


Capítulo 2: Sumário

❒ Requisitos do servi;code aplicação:

❍ confiabilidade, banda,retardo

❒ paradigma cliente-servidor

❒ modelo de serviço dotransporte orientado aconexão, confiável daInternet: TCP

❍ não confiável,datagramas: UDP

Terminamos nosso estudo de aplicações de rede!

❒ Protocolos específicos:❍ http❍ ftp❍ smtp, pop3❍ dns

❒ programação c/ sockets❍ implementação

cliente/servidor❍ usando sockets tcp, udp


Capítulo 2: Sumário

❒ troca típica demensagenspedido/resposta:

❍ cliente solicita info ouserviço

❍ servidor responde comdados, código de status

❒ formatos de mensagens:❍ cabeçalhos: campos com

info sobre dados(metadados)

❍ dados: info sendocomunicada

Mais importante: aprendemos de protocolos

❒ msgs de controle X dados❍ na banda, fora da banda

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

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

rede”❒ segurança: autenticação

Education

Cap2