Camada de Aplicação Teleprocessamento e Redes Instituto de Informática – UFG Prof. Fábio M....

Camada de Aplicação

Teleprocessamento e Redes

Instituto de Informática – UFGProf. Fábio M. Costa

(slides baseados em [Kurose&Ross2003])

Cap. 2: Camada de Aplicação 2

Parte 2: Camada de Aplicação

Nossos objetivos: conceitual, aspectos de

implementação de protocolos de aplicação para redes paradigma cliente-

servidor modelos de serviço

aprenda sobre protocolos examinando algumas aplicações populares

Outros objetivos do capítulo protocolos específicos:

http ftp smtp pop dns

programação de aplicações de rede socket API


Aplicações e Protocolo de Aplicação

Aplicação: processos distribuídos que comunicam entre si rodam nos computadores

(hosts) da rede como programas de usuário

trocam mensagens entre si para realização da aplicação

e.x., email, ftp, Web

Protocolos de aplicação fazem parte das aplicações definem mensagens trocadas

e as ações tomadas usam serviços de

comunicação das camadas inferiores

aplicaçãotransporte

redeenlacefísica


redeenlacefísica


redeenlacefísica


Aplicações de Rede

Processo: programa executando num host.

dentro do mesmo host: interprocess communication (definido pelo SO).

processos executando em diferentes hosts se comunicam com um protocolo da camada de aplicação

agente usuário: software que interfaceia com o usuário de um lado e com a rede de outro. implementa protocolo

da camada de aplicação

Web: browser E-mail: leitor de correio streaming áudio/vídeo:

media player


Paradigma Cliente-ServidorAplicações de rede típicas têm duas

partes: cliente and servidoraplicaçãotransporte

redeenlacefísica


redeenlacefísica

Cliente: inicia comunicação com o

servidor (“fala primeiro”) tipicamente solicita serviços do

servidor, Web: cliente implementado no

browser; e-mail: leitor de correio

pedido

resposta

Servidor: fornece os serviços solicitados pelo cliente e.x., Web server envia a página Web

solicitada, servidor de e-mail envia as mensagens, etc.


Interfaces de Programação

API: application programming interface

define a interface entre a camada de aplicação e de transporte

socket: Internet API dois processos se

comunicam enviando dados para o socket e lendo dados de dentro do socket

Q: Como um processo “identifica” o outro processo com o qual ele quer se comunicar? IP address do

computador no qual o processo remoto executa

“port number” - permite ao computador receptor determinar o processo local para o qual a mensagem deve ser entregue.


Serviços de Transporte

Perda de dados algumas aplicações (e.x.,

aúdio) podem tolerar alguma perda

outras aplicações (e.x., transferência de arquivos, telnet) exigem transferência de dados 100% confiável

Temporização algumas aplicações (e.x.,

telefonia Internet, jogos interativos) exigem baixos atrasos para operarem

Banda Passante algumas aplicações (e.x.,

multimedia) exigem uma banda mínima para serem utilizáveis

outras aplicações (“aplicações elásticas”) melhoram quando a banda disponível aumenta


Requisitos de Transporte de Aplicações Comuns

Applicação

transf. de arquivose-mail

documentos Webáudio/vídeo tempo real

áudio/vídeo armazenadojogos interativos

comércio eletrônico

Perdas

sem perdassem perdastolerantetolerante

tolerantetolerantesem perda

Banda

elásticaelásticaelásticaaúdio: 5Kb-1Mbvídeo:10Kb-5Mbigual à anterior Kbps elástica

Sensível ao Atraso

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

sim, segundossim, 100’s msecsim


Serviços de Transporte da Internet

serviço TCP: orientado á conexão: conexão

requerida entre cliente e servidor transporte confiável dados perdidos

na transmissão são recuperados controle de fluxo: compatibilização

de velocidade entre o transmissor e 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.


Aplicações e Protocolos de Transporte da Internet

Aplicação

e-mailacesso de terminais remotos

Web transferência de arquivos

streaming multimedia

servidor de arquivos remototelefonia Internet

Protocolo de Aplicação

smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959]RTP ou proprietario(e.g. RealNetworks)NFSRTP ou proprietary(e.g., Vocaltec)

Protocolo deTransporte

TCPTCPTCPTCPTCP ou UDP

TCP ou UDPtipicamente UDP


Protocolo HTTP

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

server: envia objetos em resposta a pedidos

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

PC rodandoExplorer

Servidorrodando

NCSA Webserver

Mac rodandoNetscapeNavigator

http request

http re

quest

http response

http re

sponse


Protocolo HTTP

http - protocolo de transporte: 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!

necessidade de organizar informações passadas

se ocorrer um queda do sistema, as informações podem ser perdidas ou gerar inconsistências entre o cliente e o servidor


Exemplo de OperaçãoUsuá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 client envia uma mensagem de requisição http (contendo a URL) para o socket da conexão TCP

1b. servidor http no host www.someSchool.edu esperando pela conexão TCP na porta 80. “aceita” conexão, notificando o cliente

3. servidor http recebe mensagem de pedido, constrói a mensagem de resposta contendo o objeto solicitado (someDepartment/home.index), envia mensagem para o socket

tempo

(contém referência a 10 imagens jpeg)


Exemplo (cont.)

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


Conexões persistentes e não-persistentes

Não-persistente http/1.0: servidor analisa

pedido, envia resposta e fecha a conexão TCP

2 RTTs para obter um objeto Conexão TCP solicitação e

transferência do objeto cada transferência sofre por

causa do mecanismo de slow-start do TCP

muitos browsers abrem várias conexões paralelas

Persistente modo default para htp/1.1 na mesma conexão TCP são

trazidos vários objetos o cliente envia pedido para

todos os objetos referenciados tão logo ele recebe a página HTML básica.

poucos RTTs, menos slow start.


Formato das Mensagens

dois tipos de mensagens HTTP: request, response

mensagem de requisição http (request): 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 decabeçalho

Carriage return, line feed

indica fim da mensagem


HTTP request: formato geral


Formatos HTTP: response

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 decabeçalho

dados, e.x., arquivo html


HTTP response: formato geral

version status phrase


Códigos de status das respostas

200 OK requisição bem sucedida, objeto solicitado vem em seguida

301 Moved Permanently objeto requisitado foi movido; a nova localização é

especificada a seguir na mensagem

400 Bad Request mensagem de requisição não entendida pelo servidor

404 Not Found documento requisitado não encontrado neste servidor

505 HTTP Version Not Supported


HTTP Cliente: faça você mesmo!

1. Telnet para um servidor Web:

Abre conexão TCP para a porta 80(porta default do servidor http) em www.eurecom.fr.Qualquer coisa digitada é enviada para a porta 80 em www.eurecom.fr

telnet www.eurecom.fr 80

2. Digite um pedido GET http:

GET /~ross/index.html HTTP/1.0 Digitando isto (tecle carriagereturn duas vezes), você envia estepedido HTTP GET mínimo (mas completo) ao servidor http

3. Examine a mensagem de resposta enviada pelo servidor http!


HTML (HyperText Markup Language)

HTML: uma linguagem simples para hipertexto começou como versão simples de SGML construção básica: cadeias (strings) de texto anotadas

Construtores de formato operam sobre cadeias <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.ufg.br”> saiba mais sobre a UFG </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 aniversário

</A>


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) CGI - Common Gateway

Interface scripts CGI escondem acesso

a diferentes serviços servidor WWW atua como

gateway universal

Outras tecnologias: ASP, JSP, PHP, ...

clienteWWW

servidorWWW

Sistema deinformação

GET/POST formulário

resposta: HTML


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

acesso aos documentos do servidor

sem estado: cliente deve apresentar autorização com cada pedido

autorização: tipicamente nome, senha authorization: linha de

cabeçalho no pedido se não for apresentada

autorização, servidor nega accesso, e coloca no cabeçalho da respostaWWW authenticate:

cliente servidor

msg de pedido http comum

401: authorization req.WWW authenticate:


+ Authorization:linemsg de resposta http

comum

tempo

Browser guarda nome e senha paraevitar que sejam pedidos ao usuário a cada acesso.


+ Authorization:linemsg de resposta http

comum


Cookies

gerados e lembrados pelo servidor, usados mais tarde para: autenticação lembrar preferencias

dos usuários ou prévias escolhas

servidor envia “cookie” ao cliente na resposta HTTPSet-cookie: 1678453

cliente apresenta o cookie em pedidos posteriorescookie: 1678453

cliente servidorusual http request msg

usual http response +Set-cookie: uid

usual http request msgcookie: uid

usual http response msg

usual http request msgcookie: uid

usual http response msg

açãoespecíficado cookie

açãoespecífica do cookie

Gera resposta+

ID único (uid)p/ cookie


Conditional GET: armazenando no cliente

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 do cliente está atualizada: HTTP/1.0 304 Not Modified

cliente servidor

http request msgIf-modified-since:

<date>

http responseHTTP/1.0

304 Not Modified

objeto não

modificado

http request msgIf-modified-since:

<date>

http responseHTTP/1.1 200 OK

<data>

objeto modificado


ftp: o protocolo de transferência de arquivos

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: host remoto ftp: RFC 959 ftp servidor: porta 21

transferência de arquivos

FTPservidor

FTPinterface

de usuário

FTPcliente

sistema de arquivos local

sistema de arquivos remoto

user at host


ftp: controle separado, conexões de dados

cliente ftp contata o servidor ftp na porta 21, especificando TCP como protocolo de transporte

duas conexões TCP paralelas são abertas: controle: troca de comandos

e respostas entre cliente e servidor.

“controle out of band” dados: dados do arquivo

trocados com o servidor servidor ftp mantém o

“estado”: diretório corrente, autenticação anterior

FTPcliente

FTPservidor

TCP conexão de controleporta 21

TCP conexão de dadosporta 20


ftp comandos, respostas

Exemplos de comandos: Enviados em texto ASCII

através do canal de controle

USER username PASS password LIST retorna listagem dos

arquivos no diretório atual RETR filename recupera

(obtém) o arquivo (GET) STOR filename armazena o

arquivo no host remoto (PUT)

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


Correio Eletrônico

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 que chegam e saem

são armazenadas em filas no servidor

caixa postal

fila de saída de mensagem

mailserver

agenteusuário

agenteusuário

agenteusuário

servidorde correio

agenteusuário

agenteusuário

servidor de correio

agenteusuário

SMTP

SMTP

SMTP


Correio eletrônico: servidores de correio

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 eles “cliente”: servidor de

correio que envia “servidor”: servidor de

correio que recebe

mailserver

agenteusuário

agenteusuário

agenteusuário

servidorde correio

agenteusuário

agenteusuário

servidor de correio

agenteusuário

SMTP

SMTP

SMTP


Correio Eletrônico: smtp [RFC 821]

usa TCP para transferência confiável de mensagens de correio do cliente para o servidor, através da porta 25

transferência direta: do servidor que envia para o servidor que recebe

três fases de trasnferê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


Exemplo de interação SMTP

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


Tente o SMTP você mesmo:

telnet <nome do servidor> 25 veja resposta 220 do servidor envie comandos HELO, MAIL FROM, RCPT TO,

DATA, QUIT como no exemplo anterior

a seqüência acima permite enviar um e-mail sem usar o agente de usuário do rementente


SMTP: palavras finais SMTP usas conexões

persistentes SMTP exige que as

mensagens (cabeçalho e corpo) estejam em ASCII de 7 bits

algumas seqüências de caracteres não são permitidas no corpo das mensagens (ex., CRLF.CRLF). Assim mensagens genéricas têm que ser codificadas (usualmente em “base-64” ou “quoted printable”)

Servidor SMTP usa CRLF.CRLF para indicar o final da mensagem

Comparação com http: http: modelo pull email: modelo 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


Formato das Mensagens

smtp: protocolo para trocar mensagens de e-mail

RFC 822: padrão para mensagens do tipo texto:

linhas de cabeçalho, e.g., To: From: Subject:

não confudir com os comandos SMTP !

corpo a “mensagem”, ASCII

somente com caracteres

cabeçalho

corpo da mensagem

linha em branco


Formato das Mensagens: extensões multimedia 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

tipo, subtipo edeclaração de parâmetro

dos dados multimídia

método usadopara codificar dados

versão de MIMEutilizada

dados codificados


Tipos MIMEContent-Type: type/subtype; parâmetros

Text exemplo de subtipos:

plain, html

Image exemplo de subtipos: jpeg,

gif

Audio exemplo de subtipos: basic

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

Video exemplo de subtipos: mpeg,

quicktime

Application outros dados que devem

ser processados pelo leitor antes de serem apresentados “visualmente”

exemplo de subtipos: msword, octet-stream


Tipo Multiparte: Mensagens com múltiplos objetos de tipos diferentes

From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789Content-Transfer-Encoding: quoted-printableContent-Type: text/plain

Dear Bob, Please find a picture of a crepe.--98766789Content-Transfer-Encoding: base64Content-Type: image/jpeg

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

1a. parte: texto

2a. parte: imagem

delimitador


Formato das mensagens recebidas Servidor de correio do destino (que recebe

a mensagem) adiciona a linha de cabeçalho Received:

Received: from crepes.fr by hamburger.edu;12 Oct 98 15:27:39 GMT

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


Protocolos de acesso ao correio

SMTP: entrega e armazena as mensagens 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]• mais recursos (mais complexo)• permite a manipulação de mensagens armazenadas no servidor (ex.: organizá-las

em diretórios) HTTP: Hotmail , Yahoo! Mail, etc.

agenteusuário

servidor de correio da origem

agenteusuário

SMTP SMTP POP3 orIMAP

servidor decorreio do destino


protocolo POP3

fase de autorização comandos do cliente:

user: declara nome do usuário

pass: password respostas do servidor

+OK -ERR

fase de transação 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: (blah blah blah ... S: .....................) S: . C: dele 1 C: retr 2 S: (blah blah blah ... S: .....................) 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


DNS: Domain Name System

Pessoas: muitos identificadores: RG, nome, passaporte

Hosts e roteadores na Internet: endereços IP (32 bit) -

usados para endereçar datagramas

“nome”, ex., gaia.cs.umass.edu - usados por humanos

Q: Como 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 host, roteadores se comunicam com servidores de nomes para resolver nomes (tradução nome/endereço) nota: função interna da

Internet, implementada como um protocolo da camada de aplicação

complexidade na “borda” da rede


Servidores de Nomes DNS Nenhum servidor tem todos os

mapeamentos de nomes para endereços IP

servidores de nomes locais: cada ISP ou empresa tem um

servidor de nomes local (default)

Consultas dos computadores locais ao DNS vão primeiro para o servidor de nomes local

servidor de nomes autoritativo: para um computador:

armazena o nome e o endereço IP daquele computador

pode realizar mapeamentos de nomes para endereços para aquele nome de computador

Porque não centralizar o DNS?

ponto único de falha volume de tráfego base de dados distante manutenção

Não cresce junto com a rede!isto é: não seria escalável


DNS: Servidores de Nomes Raiz são contactados pelos servidores de nomes locais que não podem resolver

um nome servidor de nomes raiz::

busca servidores de nomes autoritativos se o mapeamento do nome não for conhecido

obtém o mapeamento retorna o mapeamento para o servidor de nomes local

b USC-ISI Marina del Rey, CAl ICANN Marina del Rey, CA

e NASA Mt View, CAf Internet Software C. Palo Alto, CA

i NORDUnet Stockholm

k RIPE London

m WIDE Tokyo

a NSI Herndon, VAc PSInet Herndon, VAd U Maryland College Park, MDg DISA Vienna, VAh ARL Aberdeen, MDj NSI (TBD) Herndon, VA

existem 13 servidores de nomes raiz no mundo (2002)


DNS: exemplo simples

host surf.eurecom.fr quer o endereço IP de gaia.cs.umass.edu

1. contacta seu servidor DNS local, dns.eurecom.fr

2. dns.eurecom.fr contata o servidor de nomes raiz, se necessário

3. o servidor de nomes raiz contata o servidor de nomes autoritativo, dns.umass.edu, se necessário

computador solicitantesurf.eurecom.fr

gaia.cs.umass.edu

servidor de nomes raiz

servidor de nomesautoritativo

dns.umass.edu

servidor de nomes localdns.eurecom.fr

1

23

4

5

6


DNS: exemplo

Servidor de nomes raiz:

pode não conhecer o servidor de nomes autoritativo para um certo nome

pode conhecer: servidor de nomes intermediário: aquele que deve ser contactado para encontrar o servidor de nomes autoritativo


gaia.cs.umass.edu



1

23

4 5

6


dns.cs.umass.edu

servidor de nomesintermediáriodns.umass.edu

7

8


DNS: consultas encadeadas

consulta recursiva: transfere a tarefa de

resolução do nome para o servidor de nomes consultado

carga pesada?

consulta encadeada: servidor contactado

responde com o nome de outro servidor de nomes para contato

“Eu não sei isto ,mas pergunte a este servidor”


gaia.cs.umass.edu



1

23

4

5 6


dns.cs.umass.edu

servidor de nomesintermediáriodns.umass.edu

7

8

consulta encadeada


DNS: armazenando e atualizando registros

Uma vez que um servidor de nomes apreende um mapeamento, ele armazena o mapeamento num registro do tipo cache registro da cache tornam-se obsoletos

(desapareçem) depois de um certo tempo Tradicionalmente: registros são armazenados

estaticamente ex.: a partir de um arquivo de configuração

RFC 2136: mecanismos de atualização dinâmica estão sendo projetados pelo IETF Dynamic DNS updates: adicionar ou remover registros

dinamicamente http://www.ietf.org/html.charters/dnsind-charter.html

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


registros do DNSDNS: base de dados distribuída que armazena registros de recursos (RRs)

Type=NS name é um domínio (ex.

foo.com) value é o endereço IP do

servidor de nomes autoritativo para este domínio

formato dos RRs: (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) Ex.: www.ibm.com é realmente servereast.backup2.ibm.com value é o nome canônico

Type=MX value é o nome canônico do

servidor de correio associado com name


DNS: protocolo e mensagens

protocolo DNS: mensagen de consulta e resposta , ambas com o mesmo formato de mensagem

cabeçalho da mensagem identificação: número de 16

bit para a consulta, resposta usa o mesmo número

flags: consulta ou resposta recursão desejada recursão disponível resposta é autoritativa


Campos de nome e tipo para uma consulta

RRs de respostaa uma consulta

registros para servidores autoritativos

informação adicionalque pode ser útil

Ex.: se answer é do tipo “MX”,additional info poderá conter

um RR do tipo “A” com oendereço IP do servidor de e-mail

DNS: protocolo e mensagens


Programação de Sockets

API de Sockets introduzida no BSD4.1 UNIX,

1981 sockets são 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 fluxo

de bytes

uma interface local, criada e possuída pelas aplicações

controlada pelo OS

uma “porta” através qual os processos de aplicação podem tanto enviar quanto receber mensagens de e para outro processo de aplicação (local ou remoto)

socket

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


Programação de Sockets com TCP

Socket: uma porta entre o processo de aplicação e o 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 com buffers,

variáveis

socket

controlado pelocriador da aplicação

controlado pelosistema

operacional

host ouservidor

processo

TCP combuffers,

variáveis

socket

host ouservidor

internet

controlado pelocriador da aplicação

controlado pelosistemaoperacional



Cliente deve contactar o servidor

processo servidor já deve estar executando antes de ser contactado

servidor deve ter criado um socket (porta) que aceita o contato do cliente

Como o cliente contacta 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 contactado 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

TCP fornece a transferência confiável (fluxo de bytes ordenados)

(“pipe”) entre o cliente e oservidor

ponto de vista da aplicação


Exemplo de aplicação cliente-servidor:

cliente lê uma linha da entrada padrão do sistema (stream inFromUser) , envia para o servidor via socket (stream outToServer)

servidor lê a linha do socket servidor converte linha para

letras maiúsculas e envia de volta ao cliente

cliente lê a linha modificada através do sockete (stream inFromServer)

ou

tTo

Se

rve

r

para rededa rede

inF

rom

Se

rve

r

inF

rom

Use

r

teclado monitor

clientSocket

inputstream

inputstream

outputstream

TCPsocket

stream de entrada: seqüência de bytespara dentro do processostream de saída:

seqüência de bytes para fora do processo

processocliente

TCP socketcliente



Interação Cliente/servidor: TCP

espera por pedidode conexão entranteconnectionSocket =welcomeSocket.accept()

cria socket,porta=x, parasolicitação entrante:welcomeSocket =

ServerSocket()

cria socket,conecta com hostid, porta=x:clientSocket =

Socket()

fechaconnectionSocket

lê resposta declientSocket

fechaclientSocket

Servidor(executando em hostid)

Cliente

envia pedido usandoclientSocketlê pedido de

connectionSocket

escreve resposta paraconnectionSocket

TCP estab. de conexão


Exemplo: cliente Java (TCP)

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());

Criastream de entrada

Cria socket cliente,

conecta ao servidor

Criastream de saídaligada ao socket


Exemplo: cliente Java (TCP), cont.

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(); } }


ligada ao socket

Envia linhapara o servidor

Lê linha do servidor


Exemplo: servidor Java (TCP)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()));

Criasocket de aceitação

na porta 6789

Espera, no socketde aceitação por

contato do cliente

Cria stream deentrada, ligado

ao socket


Exemplo: servidor Java (cont)

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 linhapara o socket

Fim do while loop,retorne e espere poroutra conexão do cliente


Programaçaõ de Sockets com UDP

UDP: não há conexão entre o cliente e o servidor

não existe apresentação (handshaking)

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 foram de ordem ou perdidos

ponto de vista da aplicaçãoUDP fornece a transferência

não confiável de grupos de bytes (“datagramas”) entre o cliente e o

servidor


Interação Cliente/servidor: UDP

fechaclientSocket

Servidor(executando em hostid)

lê resposta declientSocket

cria socket,clientSocket = DatagramSocket()

Cliente

Cria endereço (hostid, port=x),envia datagrama de pedido usando clientSocket

cria socket,porta=x, para solicitação entrante:serverSocket = DatagramSocket()

lê pedido de:serverSocket

escreve resposta paraserverSocketespecificando endereçodo host cliente enúmero da porta


Exemplo: cliente Java (UDP)

sen

dP

ack

et

para rede da redere

ceiv

eP

ack

et

inF

rom

Use

r

teclado monitor

Process

clientSocket

pacoteUDP

streamde entrada

pacoteUDP

UDPsocket

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

Entrada: recebe pacote (TCP receberia “byte stream”)

processocliente

socket UDP cliente


Exemplo: cliente Java (UDP)

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();


Criasocket cliente

Traduz nome do host para

endereço IPusando DNS


Exemplo: cliente Java (UDP), cont.

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

tamanho, endereço IPe porta

Envia datagramapara servidor

Lê datagramado servidor


Exemplo: servidor Java (UDP)

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);

Criasocket datagrama

na porta 9876

Cria espaço paradatagramas recebidos

Recebedatagram

a


Exemplo: servidor Java, (cont.)

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 poroutro datagrama

Cria datagramapara enviar ao cliente


Programação de Sockets: referências

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

Tutoriais sobre sockets em Java: “Socket Programming in Java: a tutorial,”http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html

http://manic.cs.umass.edu/

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

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


Construção de um Servidor Web Simplificado

Ingredientes: Protocolo HTTP + Sockets Funcionalidade:

Trata apenas uma requisição HTTP Aceita e interpreta a requisição Obtém o arquivo requisitado a partir do sistema

de arquivos local (do servidor Web) Cria uma mensagem de resposta HTTP: Linhas

de cabeçalho + arquivo requisitado Envia a resposta diretamente para o cliente Fecha conexão e termina


Construção de um Servidor Web Simplificado Cliente: Navegador Web padrão

Netscape, IE, Konqueror, etc. Exemplo de requisição:

URL: http://somehost.somewhere.br:6789/somefile.html

host e porta: usados p/ estab. conexão com servidor

Requisição:GET /somefile.html HTTP/1.0


WebServer.java (1)

import java.io.*;import java.net.*;import java.util.*;class WebServer {

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

String requestMessageLine;ServerSocket listenSocket = new ServerSocket(6789);Socket connectionSocket = listenSocket.accept();BufferedReader inFromClient =

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

Socket paraespera de conexões

Socket de conexão c/ clienteStream

para receber

dados via socket


WebServer.java (2)

DataOutputStream outToClient =new DataOutputStream(

connectionSocket.getOutputStream());requestMessageLine = inFromClient.readLine();StringTokenizer tokenizedLine =

new StringTokenizer( requestMessageLine);if (tokenizedLine.nextToken().equals(“GET”)){

fileName = tokenizedLine.nextToken();if (fileName.startsWith(“/”) == true)

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

Stream para enviar dados através do

socket

Lê requisição do cliente

Separa os tokens da requisição

Verifica se comando é

GET

Obtém o nome do arquivo

Obtém o tamanho

do arquivo


WebServer.java (3)

FileInputStream inFile = new FileInputStream(fileName);

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

“HTTP/1.0 200 Document Follows\r\n”);if (fileName.endsWith(“.jpg”))

outToClient.writeBytes(“Content-Type: image/jpeg\r\n”);

if (fileName.endsWith(“.gif”))outToClient.writeBytes(“Content-Type:

image/gif\r\n”);

Lê o arquivo

requisitado

Envia a primeira linha do cabeçalho da resposta

Segunda linha (content-type)

depende do tipo do arquivo

requisitado (jpeg ou gif)


WebServer.java (4)

outToClient.writeBytes(“Content-Length: “ +numOfBytes + “\r\n”);

outToClient.writeBytes(“\r\n”);outToClient.write(fileInBytes, 0, numOfBytes);connectionSocket.close();

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

}}

Envia a 3a. linha do

cabeçalho

Linha em branco para separar o cabeçalho do corpo da msg

Envia o arquivo

requisitado

Fecha a conexão com

o cliente


WebServer.java: O que Falta?

Aceitar múltiplas requisições Cada requisição processada por uma thread

diferente Tratar outros tipos de conteúdo (linha de

cabeçalho Content-type:) Suporte para demais comandos (POST,

HEAD) Suporte para demais tipos de mensagem

de resposta (Bad request, Not found, etc.) O que mais?


Distribuição de Conteúdo

Web Caches (ou Web Proxies)

Redes de Distribuição de Conteúdo (CDNs)

Redes “Peer-to-Peer”


Web Caches (proxy server)

usuário configura o browser: acesso à Web é feito através de um proxy

cliente envia todos os pedidos http para o proxy se o objeto existe no proxy (web

cache): proxy retorna o objeto caso contrário, o proxy solicita

o objeto ao servidor original e então envia o objeto ao cliente.

proxy guarda o objeto em sua cache

Objetivo: atender o cliente sem envolver o servidor Web originador da informação

cliente

Proxyserver

cliente

http re

quest

http re

sponse

http request http request

http response http response

servidororiginal

servidororiginal


Porque Web Caching?

armazenamento está “perto” do cliente (ex., na mesma rede)

menor tempo de resposta

reduz o tráfego para servidores distantes links externos podem

ser caros e facilmente congestionáveis

servidoresoriginais

Internetpública

redeinstitucional 10 Mbps LAN

enlace de acesso1.5 Mbps

cache institucional


Análise simplificada

Tamanho médio dos objetos requisitados: 100.000 bits

15 requisições / segundo “Atraso da Internet”: 2s Atraso total:

LAN + acesso + Internet Intensidade de tráfego na

LAN:

Intens. de tráf. no acesso:

Congestionamento no enlace de acesso: atraso crescente

servidoresoriginais

Internetpública



(15 reqs/s) . (100kbits/req)/(10Mbps) = 0,15

(15 reqs/s) . (100kbits/req)/(1,5Mbps) = 1


Análise: Com o Proxy

Taxa de acerto: 0,4 40% dos acessos: via

proxy• Atraso da LAN (0,01s)

60% dos acessos: servidor original

• Intes. tráf. no acesso: 0,6• Atraso: 2,01s

Atraso médio:

Na média, melhor do que um simples upgrade da “largura de banda” do enlace de acesso (e.g., para 10Mbps) Verificar!

servidoresoriginais

Internetpública



cache institucional

0,4*(0,01s) + 0,6*(2,01s) = 1,2s


Caches Cooperativas

Múltiplos níveis de caches institucional, ISP, nacional

Caches de mais alto nível população de usuários maior maior taxa de acerto

ICP: Internet Caching Protocol uma forma eficiente para

uma cache consultar outra se esta possui o objeto

cliente

cache institucional

cache do ISP

cache nacional

Req.

Resp.

Req. Resp.

Req. Resp.

servidororiginalReq.

Resp.


Caches Cooperativas

Outra técnica: Cluster de caches cada cache: um sub-conjunto dos objetos cliente (navegador) mapeia a URL sobre uma

tabela de espalhamento (hash), que determina qual das caches deve ser consultada

CARP: Cache Array Routing Protocol

cliente

hash(URL)cluster

de caches


Outros Meios de Distribuição de Conteúdo

Redes de Distribuição de Conteúdo Seção 2.9.2, K&R 2nd Edition (em Inglês)

Compartilhamento de arquivos em redes de sobreposição (overlay networks) do tipo Peer-to-Peer Seção 2.9.3, K&R 2nd Edition (em Inglês)


Redes de Distribuição de Conteúdo

Contrastando as Abordagens: Web Caches: o provedor de acesso (ISP)

arca com os custos de uma maior eficiência de acesso à Web para seus clientes

CDNs - Um modelo diferente: Provedor de conteúdo contrata uma empresa de

distribuição de conteúdo, a qual mantém a rede de distribuíção

Custo fica sob a responsabilidade do provedor de conteúdo



Provedor envia conteúdo para o nodo de distribuição da CDN

CDN replica o conteúdo nos seus diversos servidores de distribuição

Requisições de usuários são servidas pelo servidor com o melhor tempo de resposta mais próximo do usuário

servidororiginal

nodo dedistribuição

servidorde distribuiçãona Am. do Sul servidor

de distribuiçãona Europa

servidorde distribuição

na Am. do Norte



Como o navegador sabe qual o servidor de distribuição com o melhor tempo de resposta? Provedor original do

conteúdo serve a página principal do site

Demais páginas são marcadas com o nome de domínio da CDN

• serão servidas pela CDN Requisições do cliente são

redirecionadas pelo DNS

Página principal

(index.html)

Objeto referenciado

http://www.cdn.com/www.foo.com/

img.gif

Objeto referenciado

http://www.cdn.com/www.foo.com/

filme.mpeg

Distribuído pelo servidor original

Distribuído pela CDN



Redirecionamento via DNS

CDN configura o servidor de DNS autoritativo para responder de acordo com o IP do cliente

Tomando como base: tabelas de roteamento da Internet estatísticas de desempenho da rede


Redes “Peer-to-Peer”

Idéia geral Não há um servidor (ou servidores) de

conteúdo centralizado Alto nível de escalabilidade

Cada computador ligado à rede é capaz de prover e requisitar conteúdo

Exemplo: Compartilhamento de arquivos MP3 em redes

como Napster, Kazaa, Gnutella


Redes de Sobreposição (Overlay) Uma rede lógica construída sobre a Internet Conecta os vários computadores em uma

rede peer-to-peer Estrutura altamente dinâmica: nodos

podem ser inseridos ou removidos a todo tempo


Redes Peer-to-Peer

Problema básico: Descobrir quais peers contêm o conteúdo desejado

Diretório Centralizado (ex.: Napster)

Diretório Distribuído (ex.: KaZaA)

Inundação de consultas (query flooding)


Parte 2: Sumário

exigências dos serviços de aplicação: confiabilidade, banda

passante, atraso paradigma cliente-servidor modelo do serviço de

transporte da Internet l orientado à conexão,

confiável: TCP não confiável, datagramas:

UDP

Nosso estudo das aplicações está agora completo!

protocolos especificos: http ftp smtp, pop3 dns

programação de sockets implementação

cliente/servidor usando sockets tcp, udp


Parte 2: Sumário

tipica 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

Mais importante: características dos protocolos

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” segurança: autenticação

Camada de Aplicação Teleprocessamento e Redes Instituto de Informática – UFG Prof. Fábio M....

Documents

Transcript of Camada de Aplicação Teleprocessamento e Redes Instituto de Informática – UFG Prof. Fábio M....