capítulo 2: camada de aplicação - instituto de …nfonseca/arquivos/cap2.pdfaplicações e...

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

implementação de protocolos de aplicação em redes

ü paradigma cliente servidor

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

ü HTTPü FTPü SMTP / POP3 / IMAP

DNS

2: Camada de Aplicação 1

paradigma cliente servidor

ü modelos de serviçoØ aprenda sobre protocolos

através do estudo de protocolos populares do nível da aplicação

ü DNS

Ø a programação de aplicações de rede

ü programação usando sockets

Aplicações de rede: algum jargão

Ø Um processo é um programa que executa num hospedeiro (host).

Ø 2 processos no mesmo hospedeiro se comunicam usando comunicação entre

Ø Um agente de usuário (UA) é uma interface entre o usuário e a aplicação de rede.

ü WWW: browser


usando comunicação entre processos definida pelo sistema operacional (SO).

Ø 2 processos em hospedeiros distintos se comunicam usando um protocolo da camada de aplicação.

ü WWW: browserü Correio:

leitor/compositor de mensagens

ü streaming audio/video: tocador de mídia

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

Aplicação: processos distribuídos em comunicação

ü executam em hospedeiros no “espaço de usuário”

ü trocam mensagens para implementar a aplicaçãop.ex., correio, transf. de

aplicaçãotransporte

redeenlacefísica


ü p.ex., correio, transf. de arquivo, WWW

Protocolos da camada de aplicaçãoü uma “parte” da aplicaçãoü define mensagens trocadas

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

protocolos de camadas inferiores (TCP, UDP)


redeenlacefísica


redeenlacefísica

Camada de aplicação define:

Ø Tipo das mensagens trocadas: ex, mensagens de requisição & resposta

Ø Sintaxe das mensagens: quais os campos de uma mensagem & como estes

Protocolos de domínio público:

Ø Definidos por RFCsØ Garante

interoperabilidade


mensagem & como estes são delineados;

Ø Semântica dos campos: qual o significado das informações nos campos;

Ø Regras: definem quando e como os processos enviam & respondem mensagens;

interoperabilidadeØ ex, HTTP, SMTPProtocolos proprietários:Ø ex, KaZaA

• Cliente-servidor

• Peer-to-peer (P2P)

• Híbrida de cliente-servidor e P2P

Arquiteturas de aplicação


• Híbrida de cliente-servidor e P2P

Paradigma cliente-servidor (C-S)

Apl. de rede típica tem duas partes: cliente e servidor


redeenlacefísicaCliente:

Ø inicia contato com o servidor (“fala primeiro”)

Ø tipicamente solicita serviço do

pedido



redeenlacefísica

Ø tipicamente solicita serviço do servidor

Ø para WWW, cliente implementado no browser; para correio no leitor de mensagens

Servidor:Ø provê ao cliente o serviço

requisitadoØ p.ex., servidor WWW envia

página solicitada; servidor de correio entrega mensagens

resposta

Arquitetura cliente-servidor

Clientes:

Servidor:• Hospedeiro sempre ativo• Endereço IP permanente• Fornece serviços solicitados pelo cliente


Clientes:• Comunicam-se com o servidor• Pode ser conectado intermitentemente

• Pode ter endereço IP dinâmico• Não se comunicam diretamente uns com os

outros

Classification of Servers

Ø Concurrent connectionless serverØ Concurrent connection-oriented serverØ Iterative connectionless serverØ Iterative connection-oriented server

8

Ø Iterative connection-oriented server

Chapter 6: Application Layer

• Nem sempre no servidor• Sistemas finais arbitrários comunicam-se diretamente

• Pares são intermitentemente conectados e trocam endereços IP

• Ex.: Gnutella

Arquitetura P2P pura


• Ex.: Gnutella

Altamente escaláveis mas difíceis de gerenciar

Napster• Transferência de arquivo P2P• Busca centralizada de arquivos:

• Conteúdo de registro dos pares no servidor central• Consulta de pares no mesmo servidor central para localizar o

conteúdo

Híbrida de cliente-servidor e P2P


Instant messaging• Bate-papo entre dois usuários é P2P• Detecção/localização centralizada de presença:

• Usuário registra seu endereço IP com o servidor central quando fica on-line

• Usuário contata o servidor central para encontrar endereços IP dos vizinhos

Processo: programa executando num hospedeiro• Dentro do mesmo hospedeiro: dois processos se comunicam usando comunicação interprocesso (definido pelo OS)

• Processos em diferentes hospedeiros se comunicam por meio de troca de mensagens

Comunicação de processos


mensagens

• Processo cliente: processo que inicia a comunicação

• Processo servidor: processo que espera para ser contatado

Nota: aplicações com arquiteturas P2P possuem processos cliente e processos servidor

Comunicação entre processos na redeØ processos se comunicam

enviando ou recebendo mensagens através de um socket;

Ø socketü O processo emissor joga a

mensagem por seu socket;processo

socket

host ou

servidor

processo

socket

host ou

servidor

Controlado pelo

Desenvolvedor

da aplicação


mensagem por seu socket;ü O processo emissor assume

que há uma infra-estrutura de transporte no lado oposto do socket que irá transmitir a mensagem até o socket do processor receptor;

TCP com

buffers,

Variáveis

TCP com

buffers,

Variáveis

Internet

Controlado

pelo OS

Ø API: (1) escolhe do protocolo de transporte; (2) habilidade para fixar alguns parâmetros (voltamos mais tarde a este assunto)

Identificando processos:Ø Para que um processo

possa receber mensagens, ele precisa ter um identificador;

Ø Cada host tem um endereço único de 32 bits – endereço IP;

Ø O identificador inclui tanto o endereço IPcomo também o número de porta associado com o processo no host;

Ø Exemplo de número de


– endereço IP;Ø Q: O endereço IP de um

host no qual um processo está executando é suficiente para identificar este processo?

Ø Resposta: Não, muitos processos podem estar em execução em um mesmo host

Ø Exemplo de número de portas:

ü Servidor HTTP: 80ü Servidor de Correio: 25

Ø Voltaremos a este assunto mais tarde

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

podem tolerar algumas perdas

Ø outras (p.ex., transf. de arquivos, telnet) requerem transferência 100%

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

multimídia) requerem quantia mínima de banda para serem “viáveis”

Ø outras apls (“apls elásticas”)


transferência 100% confiável

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

telefonia Internet, jogos interativos) requerem baixo retardo para serem “viáveis”

Ø outras apls (“apls elásticas”) conseguem usar qualquer quantia de banda disponível

Requisitos do serviço de transporte de apls comuns

Aplicação

transferência de arqscorreio

documentos WWWáudio/vídeo de

Perdas

sem perdassem perdassem perdastolerante

Banda

elásticaelásticaelásticaáudio: 5Kb-1Mb

Sensibilidade temporal

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


áudio/vídeo detempo real

áudio/vídeo gravadojogos interativosapls financeiras

tolerante

tolerantetolerantesem perdas

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

sim, 100’s mseg

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

Serviços providos por protocolos de transporte Internet

serviço TCP:Ø orientado a conexão:

negociação e definição da conexão (setup) requerida entre cliente, servidor

Ø transporte confiável entre processos remetente e

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

confiável entre processos remetente e receptor

Ø não provê: setup da conexão, confiabilidade, controle de


Ø transporte confiável entre processos remetente e receptor

Ø controle de fluxo: remetente não vai sobrecarregar o receptor

Ø controle de congestionamento:estrangular remetente quando a rede está sobrecarregada

Ø não provê: garantias temporais ou de banda mínima

confiabilidade, controle de fluxo, controle de congestionamento, garantias temporais ou de banda mínima

P: Qual é o interesse em ter um UDP?

Apls Internet: seus protocolos e seus protocolos de transporte

Aplicação

correio eletrônicoaccesso terminal remoto

WWW transferência de arquivos

Protocolo da camada de apl

smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959]

Protocolo de transporte usado

TCPTCPTCPTCP


transferência de arquivosstreaming multimídia

servidor de arquivo remototelefonia Internet

ftp [RFC 959]proprietário(p.ex. RealNetworks)NSFproprietário(p.ex., Vocaltec)

TCPTCP ou UDP

TCP ou UDPtipicamente UDP

WWW e HTTP: algum jargão

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

Ø Quase todas as páginas WWW consistem de:

Ø Agente de usuário para WWW se chama de browser:

ü MS Internet Explorerü Netscape Communicator

Servidor para WWW se


WWW consistem de:ü página base HTML, eü vários objetos

referenciados.

Ø URL tem duas partes: nome de hospedeiro, e nome de caminho:

Ø Servidor para WWW se chama “servidor WWW”:

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

Server (IIS)

www.someschool.edu/someDept/pic.gif

nome do host nome do caminho

Web Naming and Addressing

Ø Uniform Resource Identifier (RFC 2396)Ø Uniform Resource Locator (RFC 1738)Ø Uniform Resource Name (RFC 2141)

19

http:

ftp:

gopher:

etc.

urn:URLs

URNs

URNs


Uniform Resource IdentifierØ What is URI?

ü A compact string of characters for identifying an abstract or physical resource.

Ø URI syntax:ü Absolute URI: <scheme>:<scheme-specific-part>ü Generic URI: <scheme>://<authority><path>?<query>URI examples:

20

Ø URI examples:ü http://speed.cis.nctu.edu.tw/~ydlin/index.html#Booksü http://www.google.com/search?q=linuxü ftp://ftp.cis.nctu.edu.tw/Documents/IETF/rfc2300~2399/r

fc2396.txtü mailto: [email protected]ü news: comp.os.linuxü telnet://bbs.cis.nctu.edu.tw/ü ../icons/logo.gif


Uniform Resource LocatorØ What is URL?

ü A compact string representation of the location for a resource that is available via the Internet

Ø URL syntax:ü <service>://<user>:<password>@<host>:<port>/<url-path>

Service Description

21

Service Description

ftp File Transfer protocol

http Hypertext Transfer Protocol

gopher The Gopher protocol

mailto Electronic mail address

news USENET news

nntp USENET news using NNTP access

telnet Reference to interactive sessions

wais Wide Area Information Servers

file Host-specific file names

prospero Prospero Directory Service


Uniform Resource Locator (cont.)Ø Some URL examples:

ü http://www.cis.nctu.edu.tw/chinese/ccg/titleMain.gif

ü ftp://john:[email protected]/projects/book.txt

22

k.txtü nntp://news.cis.nctu.edu.tw/cis.course.computer-

networks/5238ü telnet://mail.cis.nctu.edu.tw:110/ü mailto: [email protected]


Uniform Resource Name

Ø What is URN? ü A name that identifies a resource of unit of information independent of its location

Ø URN syntax:ü <URN> ::= "urn:" <NID> ":" <NSS>ü NID: Namespace Identifier

23

ü NID: Namespace Identifierü NSS: Namespace Specific String

Ø URN examples:ü urn:path:/A/B/C/doc.htmlü urn:ans:cis.nctu.edu.tw/ydlin/Resourceü urn:isbn:0-201-56317-7

Ø URN resolutioin:ü http://www.isbn.com/0-201-56317-7


Protocolo HTTP: visão geral

HTTP: hypertext transfer protocol

Ø protocolo da camada de aplicação para WWW

Ø modelo cliente/servidor

PC executaExplorer


ü cliente: browser que pede, recebe, “visualiza” objetos WWW

ü servidor: servidor WWW envia objetos em resposta a pedidos

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

Servidor executandoservidor WWW do NCSA

Mac executaNavigator

Mais sobre o protocolo HTTP

HTTP: serviço de transporte TCP:

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

HTTP é “sem estado”Ø servidor não mantém

informação sobre pedidos anteriores do cliente

Protocolos que mantêm Nota


Ø servidor aceita conexão TCP do cliente

Ø mensagens HTTP (mensagens do protocolo da camada de apl) trocadas entre browser (cliente HTTP) e servidor e WWW (servidor HTTP)

Ø encerra conexão TCP

Protocolos que mantêm “estado” são complexos!

Ø história passada (estado) tem que ser guardada

Ø Caso servidor/cliente parem de executar, suas visões do “estado” podem ser inconsistentes, devendo então ser reconciliadas

Nota

Conexões HTTPHTTP: não persistenteØ No máximo um objeto

é enviado em uma conexão TCP;

Ø HTTP/1.0 usa conexões não

HTTP: persistenteØ Múltiplos objetos podem

ser enviados numa única conexão TCP entre o servidor e o cliente;

Ø HTTP/1.1 usa conexões


conexões não persistentes

Ø HTTP/1.1 usa conexões persistentes no modo default;

Ex: HTTP não-persistenteSupomos que usuário digita a URL

www.algumaUniv.br/algumDepartmento/inicial.index

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

1b. servidor http no hospedeiro www.algumaUniv.br espera por conexão TCP na porta 80. “aceita” conexão, avisando ao

(contém texto,

referências a 10

imagens jpeg)


2. cliente http envia mensagem de pedido de http (contendo URL) através do socket da conexão TCP. A mensgem indica qeu o cliente deseja o objeto someDepartment/home.index

conexão TCP na porta 80. “aceita” conexão, avisando ao cliente

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

tempo

Ex: HTTP não-persistente (cont.)

5. cliente http recebe mensagem de resposta contendo arquivo html, visualiza html. Analisando arquivo html, encontra 10 objetos jpeg referenciados

4. servidor http encerra conexão TCP .


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

tempo

Tempo de RespostaDefinição de RTT: tempo para

enviar um pequeno pacote para viajar do cliente para o servidor e retornar;

Tempo de resposta:Ø um RTT para iniciar a

conexão TCP

Inicia

conexão

TCP RTT

requisição


um RTT para iniciar a conexão TCP

Ø um RTT para a requisição HTTP e para que alguns bytes da resposta HTTP sejam recebidos

Ø tempo de transmissão do arquivo

total = 2RTT+tempo de transmissão

Tempo para

transmitir

arquivo

requisição

do arquivo

RTT

Arquivo

recebido

tempo tempo

HTTP persistenteHTTP não-persistente:Ø servidor analisa pedido,

responde, e encerra conexão TCPØ requer 2 RTTs para trazer cada

objetoØ mas os browsers geralmente

abrem conexões TCP paralelas para trazer cada objeto

Persistente sem pipelining:Ø Cliente só faz nova

requisição quando a resposta de uma requisição anterior foi recebida;

Ø um RTT para cada objetoPersistente com pipelining:

default in HTTP/1.1


para trazer cada objetoHTTP- persistenteØ servidor mantém conexão aberta

depois de enviar a resposta;Ø mensagens HTTP subsequentes

entre o o mesmos cliente/servidor são enviadas por esta conexão;

Ø na mesma conexão TCP: servidor analisa pedido, responde, analisa novo pedido e assim por diante

Ø default in HTTP/1.1Ø O cliente envia a requisição

assim que encontra um objeto;

Ø Um pouco mais de um RTT para trazer todos os objetos

Características do HTTP persistente:• Requer 2 RTTs por objeto• OS deve manipular e alocar recursos do hospedeiro para cada conexão TCPMas os browsers freqüentemente abrem conexões TCP paralelas para buscar objetos referenciados

HTTP persistente• Servidor deixa a conexão aberta após enviar uma resposta• Mensagens HTTP subseqüentes entre o mesmo cliente/servidor são enviadas pela conexão

Persistente sem pipelining:

HTTP persistente


Persistente sem pipelining:• O cliente emite novas requisições apenas quando a resposta anterior for recebida

• Um RTT para cada objeto referenciadoPersistente com pipelining:• Padrão no HTTP/1.1• O cliente envia requisições assim que encontra um objeto referenciado• Tão pequeno como um RTT para todos os objetos referenciados

Formato de mensagem HTTP: pedido

Ø Dois tipos de mensagem HTTP: pedido, respostaØ mensagem de pedido HTTP:

ü ASCII (formato legível por pessoas)

linha do pedido(comandos GET,


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 indica fim

de mensagem

Mensagem de pedido HTTP: formato geral


Tipos de Requisição

Método Post:Ø A página Web

geralmente inclue um formulário para entrada de dados;

Método URL:Ø Usa método GETØ A requisição é enviada


entrada de dados;Ø A requisição é enviada

para o servidor no corpo da entidade;

Ø A requisição é enviada para o servidor no campo URL da linha de requisição;

www.somesite.com/animalsearch?monkeys&banana

Tipos de Métodos

HTTP/1.0Ø GETØ POSTØ HEAD

Pede ao servidor que

HTTP/1.1Ø GET, POST, HEADØ PUTØ DELETE

Remove o arquivo


ü Pede ao servidor que deixe de fora da resposta o objeto solicitado; geralmente é usado para depuração;

ü Remove o arquivo especificado no campo URL;

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

linha de status(protocolo,

código de status,frase de status)

linhas decabeçalho


Content-Length: 6821

Content-Type: text/html

dados dados dados dados ...

cabeçalho

dados, p.ex., arquivo htmlsolicitado

Códigos de status da resposta HTTP

200 OK

ü sucesso, objeto pedido segue mais adiante nesta mensagem301 Moved Permanently

ü objeto pedido mudou de lugar, nova localização

Na primeira linha da mensagem de resposta servidor->cliente. Alguns códigos típicos:


ü 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

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 pelo servidor http !

Open Source Implementation 6.3: ApacheØ Introduction to Apache:

ü Open-Source Web server originally based on NCSA server

ü Available on over 160 varieties of Unix -- and Windows NT

39

Windows NTü Over 58% of Internet Web servers run Apache or an Apache derivative


Apache Server Life Cycle

Ø On Unix systems, Apache creates multiple processes to handle requests.

Ø The Windows and OS/2 ports are multithreaded..

40Chapter 6: Application Layer

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)


ü <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>


ü 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>

Extensible Markup Language

Ø What is XML?ü A pared-down version of SGML, designed especially for Web documents.

Ø Why XML?How to use XML?

43

Ø How to use XML?ü Traditional data processingü Document-driven programming (DDP)ü Archiving ü Binding


Extensible HyperText Markup Language

Ø What is XHTML?ü A hybrid between HTML and XML specifically designed for Net device displays.

Ø Why XHTML?Ø Using XHTML with other W3C tag sets:

44

Ø Using XHTML with other W3C tag sets:ü XHTML for structural markup of documents ü SMIL for multimedia ü MathML for mathematics ü SVG for scalable vector graphics ü XForms for smart web forms


Cache WWW (servidor-procurador)

Ø usuário configura browser: acessos WWW via procurador

Ø cliente envia todos pedidos http ao procurador

Meta: atender pedido do cliente sem envolver servidor de origem

clienteServidor-procurador

Servidorde origem


pedidos http ao procurador

ü se objeto no cache do procurador, este o devolve imediatamente na resposta http

ü senão, solicita objeto do servidor de origem, depois devolve resposta http ao cliente

clienteServidorde origem

Mais sobre Web cache

Ø Cache atua tanto como cliente como servidor;

Ø Cache pode fazer ferificação no cabeçalho HTTP usando o campo If-modified-since :

Por quê usar cache WWW?Ø tempo de resposta menor:

cache “mais próximo” do cliente

Ø diminui tráfego aos


modified-since :ü Questão: a cache deve

correr o risco e enviar objetos solicitados sem verificação?

ü São usadas heurísticas;Ø Tipicamente os caches web

são instalados em ISPs (universidades, companhias, ISP residencial)

Ø diminui tráfego aos servidores distantes

ü muitas vezes é um gargalo o enlace que liga a rede da instituição ou do provedor à Internet

Exemplo de Cache (1)AssumptionsØ Tamanho médio do objeto =

100,000 bitsØ Taxa média de requisição do

browser da instituição para os servidores de origem = 15/seg

Ø Atraso do roteador da

Servidoresde origem

Internetpública

enlace de accesso


Ø Atraso do roteador da instituição para qualquer servidor de origem e de volta para o roteador = 2 seg

ConseqüênciasØ Utilização da LAN = 15%Ø Utilização do enlace de acesso =

100%Ø Atraso total = atraso Internet +

atraso de acesso + atraso LAN= 2 seg + minutos + milisegundos

rede dainstituição LAN 10 Mbps

enlace de accesso 1.5 Mbps

cache dainstituição

Exemplo cache (2)Solução possívelØ Aumentar a banda do enlace

de acesso para 10 MbpsConseqüênciasØ utilização LAN = 15%Ø Utilização do enlace de acesso =

15%

Servidoresde origem

Internetpública

enlace de accesso


Utilização do enlace de acesso = 15%

Ø Atraso total = atraso Internet + atraso de acesso + atraso LAN = 2 sec + msecs + msecs

Ø Geralmente um upgrade caro


enlace de accesso 10 Mbps


Exemplo cache(3)

Instala cacheØ Suponha que a taxa de hits é .4ConseqüênciaØ 40% das requisições são

satisfeitas quase que imediatamente;60% das requisições são

Servidoresde origem

Internetpública

enlace de accesso


Ø 60% das requisições são satisfeitas pelo servidor;

Ø Utilização do enlace de acesso deduzido para 60%, resultando resulting em atrasos desprezíveis (digamos 10 mseg)

Ø Atraso total = atraso Internet + atraso de acesso + atraso = .6*2 sec + .6*.01 seg + millisegundos < 1.3 sg


enlace de accesso 1.5 Mbps


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

Ø Meta: não enviar objeto se cliente já tem (no cache) versão atual

Ø cliente: especifica data da

cliente servidor

msg de pedido httpIf-modified-since:

<date>

resposta httpHTTP/1.0

objeto não

modificado


Ø cliente: especifica data da cópia no cache no pedido httpIf-modified-since:

<date>

Ø servidor: resposta não contém objeto se cópia no cache é atual: HTTP/1.0 304 Not

Modified

HTTP/1.0

304 Not Modified

msg de pedido httpIf-modified-since:

<date>

resposta httpHTTP/1.1 200 OK

…

<data>

objeto modificado

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

Ø Formulários processados usando scripts CGI (programas que executam no servidor WWW)

ü CGI - Common Gateway Interface

ü scripts CGI escondem


Ø Resposta enviada como página HTML dinâmica

ü scripts CGI escondem acesso a diferentes serviços

ü servidor WWW atua como gateway universal

cliente

WWW

servidor

WWWSistema de

informação

GET/POST

formulário

resposta:

HTML

Interação usuário-servidor: autenticaçãoMeta 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

cliente servidormsg de pedido http comum

401: authorization req.WWW authenticate:

msg de pedido http comum


senhaü authorization: linha de

cabeçalho no pedidoü se não for apresentada

autorização, servidor nega acesso, e coloca no cabeçalho da respostaWWW 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

Interação usuário-servidor: cookies, mantendo o “estado”

Exemplo:ü Susan acessa a Internet sempre usando o mesmo

PC;ü Ela visita um site de comércio eletrônico pela

primeira vez;


primeira vez;ü Quando a requisição HTTP inicial chega ao site, é

criado um ID único e uma entrada no bando de dados para este ID;

ü servidor envia “cookie” ao cliente na msg de resposta

ü cliente apresenta cookie nos pedidos posterioresü servidor casa cookie- apresentado com a info

guardada no servidor

A grande maioria dos sites Web usa cookiesQuatro componentes:

1) linha de cabeçalho do cookie na mensagem de resposta HTTP;

2) linha de cabeçalho do cookie na mensagem de requisição HTTP



requisição HTTP3) Arquivo de cookie mantido na máquina do usuário

e gerenciado por seu browser;4) Banco de dados no site Web

cliente servidorrequisição http comum

resposta http comum +Set-cookie: 1678

requisição http comum

servidorcria ID

1678 para o usuário

Arquivo Cookie

Arquivo Cookie

ebay: 8734



requisição http comumcookie: 1678

resposta http comum

requisição http comumcookie: 1678

resposta http comum

Açãoespecífica do cookie

Açãoespecífica do cookie

Arquivo Cookie

amazon: 1678

ebay: 8734

Arquivo Cookie

amazon: 1678

ebay: 8734

Uma semana depois:

O que cookie pode trazer?

Ø autorizaçãoØ shopping cartsØ recomendações

Cookies e privacidade:Ø O uso de cookies permite

que o site “aprenda” muita coisa sobre você

Ø Você deve fornecer nome e e-mail para os sites;

Nota



Ø recomendaçõesØ Estado de sessões de

usuários (Web e-mail)

e e-mail para os sites;Ø Ferramentas de buscas

usam redirecionamento & cookies para aprender ainda mais;

Ø Agências de publicidade obtém suas informações através dos sites;

FTP: o protocolo de transferência de arquivos

transferênciado arquivo FTP

servidor

Interface do usuário

FTP

cliente FTP

sistema de arquivos local

sistema de arquivos remoto

usuário na

estação


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

ü cliente: lado que inicia transferência (pode ser de ou para o sistema remoto)

ü servidor: hospedeiro remotoØ ftp: RFC 959Ø servidor ftp: porta 21

local remoto

FTP: conexões separadas p/ controle, dados

Ø Cliente FTP contacta servidor ftp na porta 21, especificando TCP como protocolo de transporte

Ø Cliente obtem autorização através da conexão de controle;

cliente FTP

servidor FTP

conexão de controleTCP, porta 21

conexão de dados TCP, porta 20

Ø são abertas duas conexões


através da conexão de controle;Ø O cliente acessa o diretório

remoto através do envio de comandos pela conexão de controle;

Ø Quando o servidor recebe um comando para transferência de arquivo, o servidor abre uma conexão TCP com o cliente;

Ø Depois de transferir o arquivo a conexão é finalizada;

Ø são abertas duas conexões TCP paralelas:

ü controle: troca comandos, respostas entre cliente, servidor.“controle fora da banda”

ü dados: dados de arquivo de/para servidor

FTP: comandos, respostas

Comandos típicos:Ø enviados em texto ASCII pelo

canal de controleØ USER nome

Ø PASS senha

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

para http)Ø 331 Username OK, password

required

125 data connection


Ø LIST devolve lista de arquivos no directório corrente

Ø RETR arquivo recupera (lê) arquivo remoto

Ø STOR arquivo armazena (escreve) arquivo no hospedeiro remoto

Ø 125 data connection

already open; transfer

starting

Ø 425 Can’t open data

connection

Ø 452 Error writing file

Correio Eletrônico

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

protocol

caixa de correio do usuário

fila demsg de saída

agente

servidor de correio

agente de

usuário

SMTP

SMTP

agente de

usuário

servidor de correio


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 chegada

são armazenadas no servidor

agente de

usuário

SMTP

SMTP

agente de

usuário

agente de

usuárioagente de

usuário

servidor de correio

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ém mensagens de saída (a serem enviadas)

servidor de correio

agente de

usuário

SMTP

SMTP

agente de

usuário

servidor de correio


mensagens de saída (a serem enviadas)

Ø protocolo SMTP entre servidores de correio para transferir mensagens de correio

ü cliente: servidor de correio que envia

ü “servidor”: servidor de correio que recebe

SMTP

SMTP

agente de

usuário

agente de

usuárioagente de

usuário

servidor de correio

de correio

Correio Eletrônico: SMTP [RFC 821]

Ø usa TCP para a transferência confiável de msgs do correio do cliente ao servidor, porta 25

Ø transferência direta: servidor remetente ao servidor receptor

Ø três fases da transferênciahandshaking (cumprimento)


ü 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

Cenário: Alice envia msg para Bob1) Alice usa UA para compor a

mensagem e enviá-la para [email protected]

2) O UA da Alice envia a mensagem para o seu servidor de correio; a msg é colocada na fila de mensagens;

4) SMTP cliente envia a msg da Alice através da conexão TCP;

5) Servidor de correio de Bob coloca a msg na caixa de correio de Bob;

6) Bob invoca o seu UA para ler a sua msg;


mensagens;3) O cliente SMTP abre uma

conexão TCP com o servidor de correio do Bob

6) Bob invoca o seu UA para ler a sua msg;

agente usuário

servidorcorreio

servidorcorreio agente

usuário

1

2 3 4 56

Interação SMTP típicaS: 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


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 sem usar um cliente (leitor de correio)

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 caracteres não são permitidas numa

Comparação com httpØ HTTP : pull (puxar)Ø email: push (empurrar)

Ø ambos tem interação comando/resposta, códigos


não são permitidas numa mensagem (p.ex., CRLF.CRLF). Logo a mensagem pode ter que ser codificada (normalmente em base-64 ou “quoted printable”)

Ø servidor SMTP usa CRLF.CRLF para reconhecer o final da mensagem

comando/resposta, códigos de status em ASCII

Ø HTTP: cada objeto é encapsulado em sua própria mensagem de resposta

Ø SMTP: múltiplos objetos de mensagem enviados numa mensagem de múltiplas partes

Formato de uma mensagem

SMTP: protocolo para trocar msgs de correio

RFC 822: padrão para formato de mensagem de texto:

Ø linhas de cabeçalho, p.ex.,ü To:

cabeçalho

corpo

linha em branco


ü To:ü From:ü Subject:diferentes dos comandos de

SMTP!Ø corpo

ü a “mensagem”, somente de caracteres ASCII

corpo

Formato de uma mensagem: extensões para multimídiaØ MIME: multimedia mail extension, RFC 2045, 2056Ø linhas adicionais no cabeçalho da msg declaram tipo do

conteúdo MIME

From: [email protected]

To: [email protected]ão MIME


To: [email protected]

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

Dados codificados

Tipos MIME Content-Type: tipo/subtipo; parâmetros

TextØ subtipos exemplos: plain,

html

Ø charset=“iso-8859-1”,

ascii

AudioØ subtipos exemplos : basic

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

Application


ImageØ subtipos exemplos : jpeg,

gif

VideoØ subtipos exemplos : mpeg,

quicktime

ApplicationØ outros dados que precisam

ser processados por um leitor para serem “visualizados”

Ø subtipos exemplos : msword, octet-stream

Tipo MultipartFrom: [email protected]

To: [email protected]

Subject: Imagem de uma bela torta MIME-Version: 1.0

Content-Type: multipart/mixed; boundary=98766789

--98766789

Content-Transfer-Encoding: quoted-printable

Content-Type: text/plain

caro Bernardo,


caro Bernardo,

Anexa a imagem de uma torta deliciosa.

--98766789

Content-Transfer-Encoding: base64

Content-Type: image/jpeg

base64 encoded data .....

.........................

......base64 encoded data

--98766789--

Protocolos de accesso ao correio

Ø SMTP: entrega/armazenamento no servidor do receptor

servidor de correio do remetente

SMTP SMTP POP3 ouIMAP

servidor de correiodo receptor

agente de

usuário

agente de

usuário


Ø 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.

Protocolo POP3

fase de autorizaçãoØ comandos do cliente:

ü user: declara nomeü pass: senha

Ø servidor respondeü +OK

C: list

S: 1 498

S: 2 912

S: .

S: +OK POP3 server ready

C: user ana

S: +OK

C: pass faminta

S: +OK user successfully logged on


ü +OK

ü -ERR

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

msgsØ retr: recupera msg por

númeroØ dele: apaga msgØ quit

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

POP3 e IMAPMais sobre POP3Ø O exemplo anterior usa o

modo “ler-e-apagar”.Ø Bob não pode reler suas

msgs se ele mudar de cliente;POP3 não mantém estado;

IMAPØ Usa o modo: “ler-e-

guardar” que posibilita acessar mensagens de vários clientes;

Ø Mantém todas as mensagens em um único lugar: servidor;

Ø Permite que o usuário organize suas msgs em


Ø POP3 não mantém estado; organize suas msgs em pastas remotas como se fosse locais;

Ø IMAP mantém estado dos usuários durante as sessões:

ü Nomes e pastas e mapeia os IDs das msgs e o nome das pastas;

DNS: Domain Name System

Pessoas: muitos identificadores:

ü CPF, nome, no. da Identidade

hospedeiros, roteadores Internet :

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


Internet :ü endereço IP (32 bit) -

usado p/ endereçar datagramas

ü “nome”, ex., jambo.ic.uff.br - usado por gente

P: como mapear entre nome e endereço IP?

permite que hospedeiros, roteadores, servidores de nomes se comuniquem para resolvernomes (tradução endereço/nome)

ü note: função imprescindível da Internet implementada como protocolo de camada de aplicação

ü complexidade na borda da rede

DNS

Ø Roda sobre UDP e usa a porta 53

Ø Especificado nas RFCs 1034 e 1035 e atualizado em outras

Ø Outros serviços:ü apelidos para

hospedeiros (aliasing)ü apelido para o servidor

de mailsdistribuição da carga


atualizado em outras RFCs. ü distribuição da carga

Pessoas: muitos identificadores:• RG, nome, passaporte

Internet hospedeiros, roteadores:• Endereços IP (32 bits) - usados para endereçar datagramas• “nome”, ex.: gaia.cs.umass.edu - usados por humanos

P.: Relacionar nomes com endereços IP?

Domain Name System:• Base de dados distribuída implementada numa hierarquia de muitos

DNS: Domain Name System


• Base de dados distribuída implementada numa hierarquia de muitos servidores de nomes

• Protocolo de camada de aplicação hospedeiro, roteadores se comunicam com servidores de nomes para resolver nomes (translação nome/endereço)• Nota: função interna da Internet, implementada como protocolo da camada de aplicação

• Complexidade na “borda” da rede

Servidores de nomes DNS

Ø Nenhum servidor mantém todos os mapeamento nome-para-endereço IP

servidor de nomes local:ü cada provedor, empresa tem

servidor de nomes local (default)

Por que não centralizar o DNS?

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


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

primeiro ao servidor de nomes local

servidor de nomes oficial:ü p/ hospedeiro: guarda nome,

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

nome/endereço para este nome

Ø base de dados centralizada e distante

Ø manutenção (da BD)

Não é escalável!

DNS: Servidores raizØ procurado por servidor local que não consegue resolver o

nomeØ servidor raiz:

ü procura servidor oficial se mapeamento é desconhecidoü obtém tradução

devolve mapeamento ao servidor local


ü devolve mapeamento ao servidor local

b USC-ISI Marina del Rey, CA

l ICANN Marina del Rey, CA

e NASA Mt View, CA

f Internet Software C. Palo Alto,

CA

i NORDUnet Stockholm

k RIPE London

m WIDE Tokyo

a NSI Herndon, VA

c PSInet Herndon, VA

d U Maryland College Park, MD

g DISA Vienna, VA

h ARL Aberdeen, MDj NSI (TBD) Herndon, VA

13 servidores raíz no mundo

Base de dados distribuída, hierárquica


Cliente quer o IP para www.amazon.com; 1a aprox.:• Cliente consulta um servidor de raiz para encontrar o servidor DNS com• Cliente consulta o servidor DNS com para obter o servidor DNS amazon.com• Cliente consulta o servidor DNS amazon.com para obter o endereço IP para www.amazon.com

Servidores top-level domain (TLD): responsáveis pelos domínios com, org, net, edu etc e todos os domínios top-level nacionais uk, fr, ca, jp.• Network Solutions mantém servidores para o TLD “com” TLD• Educause para o TLD “edu”

Servidores TLD e autoritários


Servidores DNS autorizados: servidores DNS de organizações, provêm nome de hospedeiro autorizado para mapeamentos IP para servidores de organizações (ex.: Web e mail).• Podem ser mantidos por uma organização ou provedor de serviços

Top Level DomainsDomain Description

com Commercial organizations, such as Intel (intel.com).

org Non-profit organizations, such as WWW consortium (w3.org).

gov Government organizations, reserved for U.S government such as National Science Foundation (nsf.gov).

edu Educational organizations, such as UCLA (ucla.edu).

net Networking organizations, such as Internet Assigned Numbers Authority which maintains the DNS root servers (gtld-servers.net) .

81

which maintains the DNS root servers (gtld-servers.net) .

int Organizations established by international treaties between governments. For example, International Telecommunication Union (itu.int).

Mil Reserved exclusively for the United States Military. For example, Network Information Center, Department of Defense (nic.mil).

Two-letter country code

The two-letter country code top level domains (ccTLDs) are based on the ISO 3166-1 two-letter country codes. Examples are tw (Taiwan), uk (United Kingdom).

arpa Mostly unused now, except for the in-addr.arpa domain, which is used to maintain a database for reverse DNS queries.

Others Such as .biz (business), .name (for individuals), .info (similar with .com).


• O hospedeiro em cis.poly.edu

Exemplo


• O hospedeiro em cis.poly.edu quer o endereço IP para gaia.cs.umass.edu

Consulta recursiva:• Transfere a tarefa de resolução do nome para o servidor de nomes consultado

• Carga pesada?

Consulta encadeada:•

Consultas recursivas


Consulta encadeada:• Servidor contatado responde com o nome de outro servidor de nomes para contato

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

Uma vez que um servidor de nomes apreende um mapeamento, ele armazena o mapeamento num registro do tipo cache• Registro do cache tornam-se obsoletos (desaparecem) depois de um certo tempo• Servidores TLD são tipicamente armazenados em cache nos servidores de nome locais

DNS: armazenando e atualizando registros


servidores de nome locais

Mecanismos de atualização e notificação estão sendo projetados pelo IETF• RFC 2136• http://www.ietf.org/html.charters/dnsind-charter.html

Registros do DNS

DNS: base de dados distribuída que armazena registros de recursos (RR)

formato dos RR: (name, value, type,ttl)

• Type = A• name é o nome do computador• value é o endereço IP

• Type = CNAME• name é um “apelido” para algum nome “canônico” (o nome real)


• Type = NS• name é um domínio (ex.: foo.com)• value é o endereço IP do servidor de nomes autorizados para este domínio

• value é o endereço IP nome “canônico” (o nome real)www.ibm.com é realmenteservereast.backup2.ibm.com

• value é o nome canônico

• Type = MX• value é o nome do servidor de correio associado com name

DNS: protocolo e mensagem

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

Cabeçalho da msg• Identificação: número de 16 bits para consulta, resposta usa o mesmo número

• Flags:


• Flags:• Consulta ou resposta• Recursão desejada • Recursão disponível• Resposta é autorizada

Camada de aplicação


DNS: protocolo e mensagens

• Exemplo: empresa recém-criada “Network Utopia”• Registrar o nome networkuptopia.com num “registrar” (ex.: Network Solutions)• É necessário fornecer ao registrar os nomes e endereços IP do seu servidor nomes autorizados (primário e secundário)• Registrar insere dois RRs no servidor TLD do domínio com:

(networkutopia.com, dns1.networkutopia.com, NS)

Camada de aplicação


Inserindo registros no DNS

(networkutopia.com, dns1.networkutopia.com, NS)

(dns1.networkutopia.com, 212.212.212.1, A)

• No servidor autorizado, inserir um registro Tipo A para www.networkuptopia.com e um registro Tipo MX para networkutopia.com

• Como as pessoas obtêm o endereço IP do seu Web site?

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

Ø uma vez que um servidor qualquer aprende um mapeamento, ele o coloca numa cache localü futuras consultas são resolvidas usando dados da cache

ü entradas na cache são sujeitas a temporização (desaparecem depois de um certo tempo)


entradas na cache são sujeitas a temporização (desaparecem depois de um certo tempo)ttl = time to live (sobrevida)

Ø estão sendo projetados pela IETF mecanismos de atualização/notificação dos dados

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

Registros DNSDNS: BD distribuído contendo registros de recursos (RR)

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

Ø Tipo=Aü nome é nome de hospedeiro

Ø Tipo=CNAMEü nome é nome alternativo

(alias) para algum nome


Ø Tipo=NSü nome é domínio (p.ex.

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

servidor oficial de nomes para este domínio

nome é nome de hospedeiroü valor é o seu endereço IP (alias) para algum nome

“canônico” (verdadeiro)ü valor é o nome

canônico

Ø Tipo=MXü nome é domínioü valor é nome do servidor de

correio para este domínio

DNS: protocolo e mensagensprotocolo DNS: mensagens de pedido e resposta, ambas com o

mesmo formato de mensagem

cabeçalho de msgØ identificação: ID de 16 bit

para pedido, resposta ao pedido usa mesmo ID


para pedido, resposta ao pedido usa mesmo ID

Ø flags:ü pedido ou respostaü recursão desejadaü recursão permitidaü resposta é oficial

DNS: protocolo e mensagens

campos de nome, e de tipo num pedido

RRs em respostaao pedido


ao pedido

registros para outrosservidores oficiais

info adicional “relevante” que pode ser usada

Programação com sockets

API Sockets Ø apareceu no BSD4.1 UNIX

em 1981são explicitamente criados,

uma interface (uma “porta”), local ao

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

socket

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


Ø são explicitamente criados, usados e liberados por apls

Ø paradigma cliente/servidorØ dois tipos de serviço de

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

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)

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

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 contatar o servidor• Processo servidor já deve estar em execução• Servidor deve ter criado socket (porta) que aceita o contato do cliente

Cliente contata o servidor • Criando um socket TCP local• Especificando endereço IP e número da porta do processo servidor• Quando o cliente cria o socket: cliente TCP estabelece conexão com o TCP do servidor

Quando contatado pelo cliente, o TCP do servidor cria um novo socket para

Programação de sockets com TCP


Quando contatado pelo cliente, o TCP do servidor cria um novo socket para o processo servidor comunicar-se com o cliente• Permite ao servidor conversar com múltiplos clientes• Números da porta de origem são usados para distinguir o cliente (mais no capítulo 3)

Ponto de vista da aplicaçãoTCP fornece a transferência confiável, em ordem de bytes

(“pipe”) entre o cliente e o servidor

• Um stream é uma seqüência de caracteres que fluem para dentro ou para fora de um processo

• Um stream de entrada é agregado a alguma fonte de entrada para o processo, ex.: teclado ou socket

Jargão stream


• Um stream de saída é agregado a uma fonte de saída, ex.: monitor ou socket

Exemplo de aplicação cliente-servidor:

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

2) Servidor lê linha do socket



2) Servidor lê linha do socket

3) Servidor converte linha para letras maiúsculas e envia de volta ao cliente

4) Cliente lê a linha modificada através do (inFromServer stream)


Comunicação entre sockets


Exemplo de aplicação cliente-servidor

Ø cliente lê linha da entrada padrão (fluxo doUsuário), envia para servidor via socket (fluxo paraServidor)

Ø servidor lê linha do socketØ servidor converte linha para

doU

suário

teclado monitor

Process fluxo de entrada: seqüência de bytespara dentro do

processocliente


Ø servidor converte linha para letras maiúsculas, devolve para o cliente

Ø cliente lê linha modificada do socket (fluxo doServidor), imprime-a d

o U

suário

para rede da rede

para

Serv

idor

clientSocket

TCPsocket

para dentro do processofluxo de saída:

seqüência de bytes para fora do processo

TCP socketcliente

Interações cliente/servidor usando o TCP

aguarda chegada de

cria socket,porta=x, para

receber pedido:socketRecepção =

ServerSocket ()

cria socket,abre conexão a nomeHosp, porta=x

Servidor (executa em nomeHosp) Cliente

TCP setup da conexão


aguarda chegada de pedido de conexãosocketConexão =socketRecepção.accept()

abre conexão a nomeHosp, porta=xsocketCliente =

Socket()

fechasocketConexão

lê resposta desocketCliente

fechasocketCliente

Envia pedido usandosocketClientelê pedido de

socketConexão

escreve resposta para socketConexão

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

String fraseModificada;

BufferedReader doUsuario =

new BufferedReader(new InputStreamReader(System.in));

Socket socketCliente = new Socket(”nomeHosp", 6789);

DataOutputStream paraServidor = new DataOutputStream(socketCliente.getOutputStream());

Criafluxo de entrada

Criasocket de cliente,

conexão ao servidorCria

fluxo de saídaligado ao socket

Exemplo: cliente Java (TCP), cont.

BufferedReader doServidor =

new BufferedReader(new

InputStreamReader(socketCliente.getInputStream()));

frase = doUsuario.readLine();

Criafluxo de entradaligado ao socket

Envia linha


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

fraseModificada = doServidor.readLine();

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

socketCliente.close();

}

}

Envia linhaao servidor

Lê linhado servidor

Exemplo: servidor Java (TCP)import java.io.*;

import java.net.*;

class servidorTCP {


{

String fraseCliente;

StringfFraseMaiusculas; Cria socket


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(); Lê linha

do socket

Cria fluxode saída, ligado

ao socket


fraseEmMaiusculas= fraseCliente.toUpperCase() + '\n';

paraClient.writeBytes(fraseEmMaiusculas);

}

} }

Escreve linhaao socket

Final do laço while,volta ao início e aguardaconexão de outro cliente

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

UDP provê transferência não confiável de grupos

ponto de vista da aplicação


e porta do destinoØ servidor deve extrair

endereço IP, porta do remetente do datagrama recebido

UDP: dados transmitidos podem ser recebidos fora de ordem, ou perdidos

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

Interações cliente/servidor usando o UDP

Servidor (executa em nomeHosp)

cria socket,

socketCliente = DatagramSocket()

Cliente

cria, endereça (nomeHosp, porta=x,

cria socket,porta=x, para

pedido que chega:socketServidor = DatagramSocket()


fechasocketCliente

lê resposa dosocketCliente

cria, endereça (nomeHosp, porta=x,

envia pedido em datagramausando socketCliente

lê pedido dosocketServidor

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

Cliente UDP


Exemplo: cliente Java (UDP)

doU

suário

teclado monitor

Process

fluxo

de entrada

envia pacote

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

processocliente


envia

Packet

para rede da rede

recebeP

acket

clientSocket

pacote

UDP

pacote

UDP

UDPsocket

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

“byte stream”)

socket UDP cliente

Exemplo: cliente Java (UDP)

import java.io.*;

import java.net.*;

class clienteUDP {

public static void main(String args[]) throws Exception

{

BufferedReader do Usuario=

Criafluxo de entrada


BufferedReader do Usuario=

new BufferedReader(new InputStreamReader(System.in));

DatagramSocket socketCliente = new DatagramSocket();

InetAddress IPAddress = InetAddress.getByName(”nomeHosp");

byte[] sendData = new byte[1024];

byte[] receiveData = new byte[1024];

String frase = doUsuario.readLine();

sendData = frase.getBytes();

fluxo de entrada

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

Cria datagrama com dados para enviar,

comprimento, endereço IP, porta

Envia datagramaao servidor


new DatagramPacket(dadosRecebidos, dadosRecebidos.length);

socketCliente.receive(pacoteRecebido);

String fraseModificada =

new String(pacoteRecebido.getData());

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

socketCliente.close();

}

}

Lê datagramado servidor

Servidor UDP


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

Cria socketpara datagramas

na porta 9876


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

na porta 9876

Aloca memória parareceber datagrama

Recebedatagrama

Exemplo: servidor Java (UDP), contString frase = new String(pacoteRecebido.getData());

InetAddress IPAddress = pacoteRecebido.getAddress();

int porta = pacoteRecebido.getPort();

String fraseEmMaiusculas = frase.toUpperCase();

Obtém endereço IP, no. de porta do remetente


dadosEnviados = fraseEmMaiusculas.getBytes();

DatagramPacket pacoteEnviado =

new DatagramPacket(dadosEnviados,

dadosEnviados.length, IPAddress, porta);

socketServidor.send(pacoteEnviado);

}

}

}

Escrevedatagramano socket

Fim do laço while,volta ao início e aguardachegar outro datagrama

Cria datagrama p/enviar ao cliente

Servidor Web Simples

Ø Funções do servidor Web:ü Trata apenas um pedido HTTP por vezü Aceita e examina o pedido HTTPü Recupera o arquivo pedido do sistema de arquivos do servidor


arquivos do servidorü Cria uma mensagem de resposta HTTP consistindo do arquivo solicitado precedido por linhas de cabeçalho

ü Envia a resposta diretamente ao clienteü Depois de criado o servidor, pode-se requisitar um arquivo utilizando um browser;

Servidor Web Simplesimport java.io.*;

import java.net.*;

import java.util.*;

class WebServer {


{

String requestMessageLine;

String fileName;

Contém a classe StringTokenizer que éusada para examinar

o pedido

Primeira linha da mensagemde pedido HTTP e

Nome do arquivo solicitado


String fileName;

ServerSocket listenSocket = new ServerSocket(6789);

Socket connectionSocket = listenSocket.accept();

BufferedReader inFromClient =

new BufferedReader(new InputStreamReader(

connectionSocket.getInputStream()));

DataOutputStream outToClient =

new DataOutputStream(connectionSocket.getOutputStream());

Aguarda conexãodo cliente

Nome do arquivo solicitado

Cria fluxo de Entrada

Cria fluxo de Saída

Servidor Web Simples, cont

requestMessageLine = inFromClient.readLine();

StringTokenizer tokenizedLine =

new StringTokenizer(requestMessageLine);

if (tokenizedLine.nextToken().equals("GET")){

fileName = tokenizedLine.nextToken();

Lê a primeira linha dopedido HTTP que deveriater o seguinte formato:

GET file_name HTTP/1.0

Examina a primeira linha da mensagem para extrair

o nome do arquivo


fileName = tokenizedLine.nextToken();

if (fileName.startsWith("/") == true )

fileName = fileName.substring(1);

File file = new File(fileName);

int numOfBytes = (int) file.length();

FileInputStream inFile = new FileInputStream (

fileName);

byte[] fileInBytes = new byte[];

inFile.read(fileInBytes);

o nome do arquivo

Associa o fluxo inFile

ao arquivo fileName

Determina o tamanho doarquivo e constrói um vetorde bytes do mesmo tamanho

Servidor Web Simples, cont

outToClient.writeBytes(

"HTTP/1.0 200 Document Follows\r\n");

if (fileName.endsWith(".jpg"))

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

if (fileName.endsWith(".gif"))

outToClient.writeBytes("Content-Type:

image/gif\r\n");

Transmissão do cabeçalho da resposta

HTTP.

Inicia a construção damensagem de resposta


image/gif\r\n");

outToClient.writeBytes("Content-Length: " + numOfBytes +

"\r\n");

outToClient.writeBytes("\r\n");

outToClient.write(fileInBytes, 0, numOfBytes);

connectionSocket.close();

}

else System.out.println("Bad Request Message");

}}

HTTP.

Programação de Sockets: referências

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

Tutoriais sobre Java:


Tutoriais sobre Java:Ø “Socket Programming in Java: a tutorial,”

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

P2P compartilhamento de arquivos

ExemploØ Alice executa a aplicação

cliente P2P no seu notebookØ Interminentemente

conecta com a Internet; adquire um endereço IP

Ø Alice escolhe um dos nós, Bob.

Ø Arquivo é copiado do nó do Bob para o nó (notebook) da Alice: HTTP

Ø Enquanto Alice copia o arquivo do nó de Bob, outros usuários copiam os


adquire um endereço IP para cada conexão;

Ø Requisita “Hey Jude”Ø A aplicação apresenta

vários nós que possuem uma cópia de “Hey Jude.

outros usuários copiam os arquivos do nó da Alice;

Ø O nó daAlice é um cliente web como também um servidor web temporário.

Todos os nós são servidores = extremamente escalável!

P2P: diretório centralizado

“Napster” projeto original 1) Quando um dos pares se

conecta, ele informa ao servidor central :

ü Endereço IP

Servidor de diretório

centralizadopares

Bob

1

1


ü Endereço IPü conteúdo

2) Alice procura por “Hey Jude”

3) Alice requisita o arquivo de Bob

Alice

1

12

3

P2P: problemas com diretórios centralizados

Ø Único ponto de falhaØ Gargalo de

desempenhoØ Infringe-se Copyright

transferência de arquivo é descentralizada, mas localizar conteúdo é totalmente descentralizada


P2P: diretório descentralizado

Ø Cada par ou é um líder de grupo ou pertence ao grupo de um líder;

Ø O líder do grupo localiza o conteúdo em


localiza o conteúdo em todos os seus filhos;

Ø Os pares consultam o líder do grupo; o par líder pode consultar outros nós pares que também são líder;

Par qualquer

Par líder do grupo

Relacionamento de vizinhançana rede de cobertura

Mais sobre diretório descentralizado

Rede de coberturaØ Os pares são nósØ Arestas entre os pares e o

seu líder;Ø Arestas entre alguns nós

pares líderes de grupos;

Vantagens da abordagemØ Nenhum servidor

centralizado;ü O serviço de localização é

distribuído entre os pares


pares líderes de grupos;Ø Vizinhos virtuaisNó bootstrapØ O par conectado ou faz

parte de um grupo de um líder ou é um par líder de grupo;

distribuído entre os pares ü Mais dificuldade de se ter

falhas;

Desvantagem da abordagemØ Necessário nó bootstrapØ O líder do grupo pode ficar

sobrecarregado;

P2P: fluxo de consultas (query flooding)Ø Gnutella Ø Sem hierarquiaØ Mensagem joinØ Usa o nó bootstrap para

aprender sobre os outros

Ø Envia a “pergunta ou consulta”para os vizinhos;

Ø Vizinhos reencaminham as mensagens;

Ø Se o par consultado possui o objeto, envia uma mensagem de volta para o par originador da


volta para o par originador da consulta;

join

Chapter 2: Application layer

r 2.1 Principles of network applications � app architectures� app requirements

r 2.2 Web and HTTP

r 2.6 P2P applicationsr 2.7 Socket programming

with TCPr 2.8 Socket programming

with UDP

2: Application Layer 125

r 2.2 Web and HTTPr 2.4 Electronic Mail

� SMTP, POP3, IMAP

r 2.5 DNS

with UDP

Pure P2P architecture

r no always-on serverr arbitrary end systems

directly communicater peers are intermittently

connected and change IP

peer-peer


connected and change IP addresses

r Three topics:� File distribution� Searching for information� Case Study: Skype

File Distribution: Server-Client vs P2PQuestion : How much time to distribute file from one server to N peers?

Server

us: server upload bandwidth

ui: peer i upload bandwidth


us

u2d1d2

u1

uN

dN

Network (with abundant bandwidth)

File, size F

bandwidth

di: peer i download bandwidth

File distribution time: server-client

us

u2d1 d2

u1

uN

dN

Server


Fr server sequentially sends N copies:� NF/us time

r client i takes F/di time to download


uNclient i takes F/di time to download

increases linearly in N(for large N)

= dcs = max { NF/us, F/min(di) }i

Time to distribute Fto N clients using

client/server approach

File distribution time: P2P

us

u2d1 d2

u1

uN

dN

Server


Fr server must send one copy: F/us time

r client i takes F/di time to download

r NF bits must be


uNr NF bits must be downloaded (aggregate)r fastest possible upload rate: us + Σui

dP2P = max { F/us, F/min(di) , NF/(us + Σui) }i

2.5

3

3.5M

inim

um

Dis

trib

ution T

ime P2P

Client-Server

Server-client vs. P2P: example

Client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us


0

0.5

1

1.5

2

0 5 10 15 20 25 30 35

N

Min

imum

Dis

trib

ution T

ime

File distribution: BitTorrent

tracker: tracks peers participating in torrent

torrent: group of peers exchanging chunks of a file

r P2P file distribution


obtain listof peers

trading chunks

peer

BitTorrent (1)

r file divided into 256KB chunks.r peer joining torrent:

� has no chunks, but will accumulate them over time


has no chunks, but will accumulate them over time� registers with tracker to get list of peers, connects to subset of peers (“neighbors”)

r while downloading, peer uploads chunks to other peers.

r peers may come and gor once peer has entire file, it may (selfishly) leave or

(altruistically) remain

BitTorrent (2)Pulling Chunksr at any given time,

different peers have different subsets of file chunksperiodically, a peer

Sending Chunks: tit-for-tatr Alice sends chunks to four

neighbors currently sending her chunks at the highest rate� re-evaluate top 4 every 10 secs


r periodically, a peer (Alice) asks each neighbor for list of chunks that they have.

r Alice sends requests for her missing chunks� rarest first

10 secsr every 30 secs: randomly

select another peer, starts sending chunks� newly chosen peer may join top 4

� “optimistically unchoke”

BitTorrent: Tit-for-tat(1) Alice “optimistically unchokes” Bob(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates(3) Bob becomes one of Alice’s top-four providers


With higher upload rate, can find better trading partners & get file faster!

Distributed Hash Table (DHT)

r DHT = distributed P2P databaser Database has (key, value) pairs;

� key: ss number; value: human name� key: content type; value: IP address� key: content type; value: IP address

r Peers query DB with key� DB returns values that match the key

r Peers can also insert (key, value) peers

DHT Identifiers

r Assign integer identifier to each peer in range [0,2n-1].� Each identifier can be represented by n bits.

r Require each key to be an integer in same range.Require each key to be an integer in same range.r To get integer keys, hash original key.

� eg, key = h(“Led Zeppelin IV”)� This is why they call it a distributed “hash” table

How to assign keys to peers?

r Central issue:� Assigning (key, value) pairs to peers.

r Rule: assign key to the peer that has the closest ID.closest ID.

r Convention in lecture: closest is the immediate successor of the key.

r Ex: n=4; peers: 1,3,4,5,8,10,12,14; � key = 13, then successor peer = 14� key = 15, then successor peer = 1

1

3

4

15

Circular DHT (1)

5

810

12

r Each peer only aware of immediate successor and predecessor.

r “Overlay network”

Circle DHT (2)

0001

00111111

Who’s resp

for key 1110 ?I am

O(N) messageson avg to resolvequery, when thereare N peers

0100

0101

10001010

1100

1110

1110

1110

1110

1110

1110

Define closestas closestsuccessor

Circular DHT with Shortcuts1

3

4

512

15

Who’s resp for key 1110?

r Each peer keeps track of IP addresses of predecessor, successor, short cuts.

r Reduced from 6 to 2 messages.r Possible to design shortcuts so O(log N) neighbors, O(log

N) messages in query

5

810

12

Peer Churn1

3

4

512

15

•To handle peer churn, require each peer to know the IP address of its two successors. • Each peer periodically pings its two successors to see if they are still alive.

r Peer 5 abruptly leavesr Peer 4 detects; makes 8 its immediate successor;

asks 8 who its immediate successor is; makes 8’s immediate successor its second successor.

r What if peer 13 wants to join?

5

810

12

P2P Case study: Skype

r inherently P2P: pairs of users communicate.

r proprietary application-layer protocol (inferred via

Skype clients (SC)

Supernode (SN)

Skype login server


protocol (inferred via reverse engineering)

r hierarchical overlay with SNs

r Index maps usernames to IP addresses; distributed over SNs

(SN)

Peers as relays

r Problem when both Alice and Bob are behind “NATs”. � NAT prevents an outside

peer from initiating a call to insider peer


to insider peerr Solution:

� Using Alice’s and Bob’s SNs, Relay is chosen

� Each peer initiates session with relay.

� Peers can now communicate through NATs via relay

P2P: mais sobre fluxo de consultas

PrósØ pares possuem

responsabilidades semelhantes: não existem líderes de

ContrasØ Tráfico excessivo de

consultasØ Raio da consulta: pode

não ser o suficiente


existem líderes de grupo;

Ø Extremamente descentralizado;

Ø Nenhum par mantem informações de diretório;

não ser o suficiente para obter o conteúdo, quando este existir;

Ø Manutenção de uma rede de cobertura;

Ø Necessário nó bootstrap

Capítulo 2: Resumo

Ø Requisitos do serviço de aplicação:

ü confiabilidade, banda, retardo

Ø paradigma cliente-servidor

Terminamos nosso estudo de aplicações de rede!Ø Protocolos específicos:

ü httpü ftpü smtp, pop3, imap


Ø paradigma cliente-servidor Ø modelo de serviço do

transporte ü orientado a conexão,

confiável da Internet: TCPü não confiável, datagramas:

UDP

smtp, pop3, imapü dns

Ø programação c/ socketsü implementação

cliente/servidorü usando sockets tcp, udp

Ø Distribuição de conteúdo:ü caches, CDNsü P2P

Capítulo 2: Resumo

Ø troca típica de mensagens pedido/resposta:

ü cliente solicita info ou serviçoü servidor responde com dados,

Mais importante: aprendemos sobre protocolos

Ø msgs de controle X dadosü na banda, fora da banda

Ø centralizado X descentralizado


ü servidor responde com dados, código de status

Ø formatos de mensagens:ü cabeçalhos: campos com info

sobre dados (metadados)ü dados: info sendo comunicada

Ø 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