Capítulo 2 Camada de Aplicação - Bem-vindo!adriano/aulas/redes/2017/Redes1/... · Prof. Dr. Adriano Mauro Cansian 2 unesp - IBILCE - SJRP 3 Conceitos Fundamentais Aplicações:

UNESP - IBILCE - SJRP - Curso de Redes de Computadores Capítulo 2

Prof. Dr. Adriano Mauro Cansian 1

unesp - IBILCE - SJRP

1

Curso de Redes de Computadores

Adriano Mauro Cansian

[email protected]

Capítulo 2 Camada de Aplicação


2

Capítulo 2: Camada de Aplicação Metas do capítulo: q  Conhecer:

•  Aspectos conceituais dos protocolos de aplicação.

•  Modelo cliente-servidor. •  Modelos de serviço.

q  Como: •  Estudar os protocolos mais

comuns da camada da aplicação.

Veremos: q  Protocolos específicos:

•  Web: HTTP •  Transf. Arquivos: FTP •  Email: SMTP & POP3 •  Nomes de hosts: DNS

•  Compartilhamento: P2P. •  Os sockets.




3

Conceitos Fundamentais

Aplicações: clientes, servidores, processos, portas, sockets e mais…


4

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

distribuídos que se comunicam. •  Trocam mensagens. •  Rodam nos sistemas

finais. •  Muitos exemplos:

•  Correio eletrônico, transferência de arquivos, web, login remoto, games, vídeo, IoT, VoIP, etc...

q  Internet cresceu muito em complexidade.

aplicação transporte

rede enlace física


rede enlace física


rede enlace física

Cliente

Cliente

Servidor




5

Protocolos de aplicação q  Protocolo da camada de aplicação:

• Não é a aplicação. –  É APENAS uma parte da aplicação.

O protocolo de aplicação: define mensagens trocadas por aplicações, e ações as tomadas em sua resposta.

•  Usam serviços providos por protocolos de camadas inferiores.

Os processos, em dois sistemas de de borda diferentes, se comunicam

logicamente trocando mensagens.

q  Um processo emissor cria e emite mensagens na rede; q  Um processo receptor recebe estas mensagens.

•  E, eventualmente, responde emitindo mensagens de volta.


6

Protocolos de aplicação q  Protocolo da camada de aplicação:

• Não é a aplicação. –  É APENAS uma parte da aplicação.

O protocolo de aplicação: define mensagens trocadas por aplicações, e ações as tomadas em sua resposta.

•  Usam serviços providos por protocolos de camadas inferiores.

Os processos, em dois sistemas de de borda diferentes, se comunicam

logicamente trocando mensagens.

q  Um processo emissor cria e emite mensagens na rede; q  Um processo receptor recebe estas mensagens.

•  E, eventualmente, responde emitindo mensagens de volta.




7

O que faz um protocolo de aplicação: q  Mensagens da camada de aplicação definem:

•  Tipos de mensagens trocadas. •  Exemplo: mensagens do requisição e mensagens de resposta.

•  Sintaxe dos vários tipos de mensagem. •  Definem os campos da mensagem, e como são delimitados.

•  Exemplo: campos é o header e do corpo da mensagem.

•  Semântica dos campos. •  Define o significado da informação nos campos.

•  Regras. •  Quando e como um processo envia e responde mensagens.

(Na verdade todos as camadas definem tipos, sintaxe, semântica e regras)


Aplicações de rede: DEFINIÇÕES (1) - processo q  Um processo é um programa que roda num host.

q  Dois processos no mesmo host se comunicam usando comunicação entre processos no SO. •  Interprocess comunnication.

•  Definida pelo sistema operacional.

•  (Não discutido nessa disciplina. Veja Sistemas Operacionais.)

q  Dois processos em hosts distintos se comunicam usando um protocolo da camada de transporte.

•  É nisso que estamos interessados em redes de computadores.

8




Aplicações de rede: DEFINIÇÕES (2) – U.A.

q  Agente de usuário (UA): •  É uma interface entre o usuário e a aplicação de rede.

q  Exemplos: •  WWW: browser.

•  Correio eletrônico: leitor / compositor de mensagens.

•  Streaming: player de mídia.

q Não é o protocolo de aplicação, apesar de conter implementação do protocolo.

9


10

Aplicações de rede: DEFINIÇÕES (3) Paradigma cliente-servidor

Aplicação de rede típica tem duas partes: cliente e servidor

Cliente: •  É aquele que “chama”. •  Solicita serviço do servidor.

Servidor: •  Fornece o serviço. •  Fica “ouvindo” à espera de pedidos de conexão.


rede enlace física


rede enlace física

Pedido

Resposta




11

Protocolos da camada de aplicação

q API - Aplication Program Interface: •  Interface de programação de aplicações.

•  Define a interface entre a aplicação e camada de transporte.

q APIs à definidas pelos RFCs.

q Socket

•  Dois processos se comunicam enviando dados para um socket , ou lendo dados de um socket.


12

q  Socket funciona como porta de entrada e saída do processo:

•  Um processo emite e recebe mensagens da rede, através de seus sockets.

•  Entrega a mensagem para o socket. O processo sabe que há um infra-estrutura de transporte, a

qual transportará a mensagem até a porta do processo do destino.

O processo não precisa se preocupar como a mensagem será transportada.

Comunicação pelos sockets (1)




13

Comunicação pelos sockets (2)

− Pergunta: •  Como um processo identifica outro?


14

Exemplo de comunicação lógica de um processo com conexão TCP, por intermédio dos sockets.

buffering

buffering




15

Como um processo identifica outro ? q  Endereço IP do host do outro processo.

•  O IP é um valor de 32-bits que identifica unicamente o sistema.

–  (Pode ser um IPv6 com 64 bits – discutido mais adiante na camada de redes)

•  Ou: identifica unicamente a interface (placa) que conecta o host à Internet.

200.145.9.9q  “Número de porta” : permite que o hospedeiro

receptor determine para qual processo deve ser entregue a mensagem. Exemplo: Porta 80.

200.145.9.9:80 (RFC 1700 - Portas well-known ou WKS)


De que tipo de transporte uma aplicação precisa?

q  Quando se desenvolve uma aplicação escolhe-se um dos protocolos disponíveis para transporte.

q Como escolher? 1.  Avaliar os serviços fornecidos pelos protocolos

disponíveis do transporte. 2.  Escolher o protocolo com as características que

melhor se adaptem às necessidades da aplicação.

q Programador decide a melhor opção. q Por exemplo:

•  “Com Conexão” ou “Sem Conexão”.

16




17

Os principais protocolos de aplicação


http

HiperText Transport Protocol

18




19

Web: html, clientes e servidores. q  Páginas WWW consistem

de página base HTML, e vários objetos referenciados.

q URL tem duas partes: nome do host, e path.

q UA para web: •  browser:

•  Chrome. •  Firefox. •  Safari, etc...

q Servidor para web: •  Apache. •  Internet Information

Server (IIS). •  Outros...

gww.acmesecurity.org/themes/noprob/logo_cnpq.png


20

WWW: o protocolo http

http: Hypertext Transfer Protocol q  Protocolo da camada de aplicação

para WWW. q  Modelo cliente-servidor

•  cliente: browser que solicita, recebe (“visualiza”) objetos WWW.

•  servidor: servidor WWW envia objetos em resposta a pedidos.

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

•  (visto adiante)

PC rodando IE browser

Servidor executando

servidor WWW

Apache Mac rodando

Safari

pedido http

pedido http

resposta http

resposta http




21

Operação do protocolo http:

Usa transporte TCP: 1.) Cliente inicia conexão TCP ao

servidor, na porta 80.

2.) Servidor aceita conexão.

3.) Troca mensagens http (mensagens do protocolo) entre browser (cliente http) e web server (servidor http).

4.) Encerra conexão TCP.

“sem estado” (“stateless”)

q  Servidor não mantém informação sobre pedidos anteriores do cliente.

Protocolos que mantêm “estado” são mais complexos. •  O histórico passado (estado) tem que ser mantido. •  Demanda recursos maiores. •  São chamados de Protocolos “Statefull”.


22

Exemplo de http (1) Exemplo: Um usuário digita a URL http://www.xpto.com.br/index.html

1a. Cliente http inicia conexão TCP ao servidor http (processo) em www.xpto.com.br.

Porta 80 é padrão para servidor http.

2. cliente http envia mensagem de pedido de http (contendo URL) através do socket da conexão TCP

1b. servidor http no hospedeiro www.xpto.com.br aguarda conexão TCP na porta 80. “Aceita” conexão, avisando ao cliente

3. servidor http recebe mensagem de pedido, elabora mensagem de resposta contendo objeto solicitado (index.html), e envia mensagem via socket.

tempo

Exemplo: contém texto e mais referências a 10

imagens jpeg

Continua…




23

Exemplo de http (2)

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

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

4. servidor http encerra conexão TCP .

tempo E então, repete e continua...


Conexão http não-persistente (1) HTTP/1.0 conexão http não-persistente (depreciada):

q Cliente: Abre conexão à solicita objeto

q Servidor: •  Analisa pedido à Responde à Encerra conexão TCP.

q Cliente: Solicita cada objeto referenciado na resposta.

•  Repete o ciclo para cada objeto.

•  2 RTTs para trazer cada objeto (RTT = round trip time = tempo de ida e volta).

•  Transferência de cada objeto sofre de partida lenta.

24




Conexão http não-persistente (2)

25


26

Conceito de RTT - Round Trip Time (1)

q  Tempo round-trip-time (RTT), é o tempo gasto para um pacote viajar do cliente ao servidor, e então voltar ao cliente.

•  É o tempo de ida e volta cliente - servidor. •  RTT inclui os atrasos de propagação, de enfileiramento e de

processamento em routers e comutadores intermediários.

q  Exemplo numa conexão web: quando se clica num hyperlink. Isto faz com que o browser inicie uma conexão do TCP entre o browser e o web server. •  Envolve um “three-way handshake” TCP para estabelecer a

conexão.




27

Conceito de RTT - Round Trip Time (2)

q  Mais um RTT decorre após as duas primeiras partes do three-way handshake.

•  Após ter terminado as primeiras duas partes do handshake, o cliente emite a mensagem de requisição HTTP na conexão TCP, e o TCP “agrega” a última confirmação (a terceira parte do three-way handshake) na mensagem do pedido. Uma vez a mensagem do pedido chega no usuário, o usuário emite o arquivo HTML na conexão do TCP.

•  Esta interação HTTP “request-response” gasta outro RTT.

q  Assim, o tempo de resposta total é 2RTTs, mais o tempo da transmissão do arquivo HTML pelo servidor.


TCP 3-Way Handshaking

28

http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm




Conexão http persistente (1) q Default no HTTP/1.1. q Na mesma conexão TCP: servidor analisa

pedido, responde, analisa novo pedido, etc... •  Não fecha a conexão.

q Menos RTTs, e menos partida lenta.

29

Os browsers atuais usam conexões TCP paralelas. (com pipeline – veremos em seguida)


30

Conexão http persistente (2) q O servidor deixa a conexão TCP aberta após

ter emitido uma resposta.

q  Os pedidos e as respostas subsequentes entre o mesmos cliente e servidor podem ser emitidos na mesma conexão.

q  Uma webpage inteira (no exemplo, o arquivo HTML base e as 10 imagens) pode ser emitido sobre uma única conexão persistente do TCP.




Conexão persistente (2)

31


Não-persistente X persistente

32




33

Conexão persistente e Pipelining q Duas versões de conexões persistentes:

•  sem pipelining (paralelismo) e com pipelining.

q Sem pipelining: •  O cliente emite um pedido novo somente quando a

resposta precedente foi recebida.

q Com pipelining: •  O cliente emite um pedido assim que encontrar uma

referência.

•  É o default para HTTP/1.1.


http sem pipeline x com pipeline

34




Formato das Mensagens HTTP

35


36

Formato das mensagens HTTP

q Dois tipos de mensagem http: •  Requisição (Request)

•  Resposta (Reply)

q Mensagem http: formato ASCII •  Mensagens são legíveis sem necessidade de interpretador.




37

Mensagem http de requisição (1)

Formato geral de uma mensagem de requisição


38

Mensagem http de requisição (2)

GET /dir/page.html HTTP/1.1 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:en

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

linha do pedido (comandos GET, POST, HEAD)

linhas do cabeçalho

Carriage return, line feed indica fim

de mensagem




39

Mensagem http de resposta (1)

Formato geral de uma mensagem de RESPOSTA

Note a diferença nestes campos


40

Mensagem http de resposta (2)

HTTP/1.1 200 OK Date: Thu, 06 Jan 2014 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Dec 2013…... Content-Length: 6821 Content-Type: text/html dados dados dados dados ...

linha de status (protocolo,

código de status, frase de status)

linhas de cabeçalho

dados. Por ex: conteúdo do arquivo html

solicitado

frase de status código de status




41

Códigos de status da resposta http

q  Aparecem na primeira linha da mensagem de resposta. •  Alguns códigos típicos:

200 OK •  Sucesso. Objeto pedido segue mais adiante nesta mensagem.

301 Moved Permanently •  Objeto pedido mudou de lugar, nova localização especificado mais

adiante nesta mensagem (Location:)

400 Bad Request •  Mensagem de pedido não entendida pelo servidor.

404 Not Found •  Documento pedido não se encontra neste servidor.

505 HTTP Version Not Supported •  Versão de http do pedido não aceita por este servidor.


42

HTML (HyperText Markup Language)

q  HTML: uma linguagem simples para hipertexto •  construção básica: cadeias de texto.

q  Construtores de formato operam sobre cadeias •  <b> .. </b> bold (negrito)

•  <H1 ALIGN=CENTER> ..título centrado .. </H1>

•  <BODY bgcolor=white text=black link=red ..> .Texto... </BODY>




43

Formulários e páginas dinâmicas na web (interação bidirecional e integração com banco de dados)

q  Formulários transmitem informação do cliente browser ao servidor.

q  HTTP permite enviar formulários ao servidor.

q  Resposta enviada como página HTML dinâmica.

q  Páginas dinâmicas: processadas usando scripts ou outro tipo de código.

q  Acessam programas que rodam no servidor WWW. •  permitem acesso a diferentes

serviços. •  servidor WWW atua como

gateway universal.

cliente WWW

servidor WWW

Sistema de informação

GET/POST formulário

resposta: HTML


Webservices q Solução utilizada para integração de sistemas e

comunicação entre aplicações diferentes. •  Permite que novas aplicações possam interagir outras já

existentes.

•  Permite que sistemas desenvolvidos em plataformas diferentes sejam compatíveis.

q São componentes que permitem às aplicações enviar e receber dados em formato XML.

q O objetivo dos webservices é a comunicação de aplicações através da Internet.

44




45

Web: autenticação q  Autenticação: controle de acesso

ao servidor. q  Sem estado: cliente deve apresentar

autorização em cada pedido. q  Autorização: tipicamente nome e

senha. •  authorization: linha de cabeçalho

no pedido. •  Se não for apresentada

autorização, servidor nega acesso, e coloca no cabeçalho da resposta

WWW authenticate:

cliente servidor msg de pedido http comum

401: authorization req. WWW authenticate:

msg de pedido http comum + Authorization:line

msg de resposta http comum

tempo Browser: faz cache do username e senha para evitar que sejam pedidos ao usuário a cada acesso.

msg de pedido http comum + Authorization:line



46

Web: cookies q  Servidor envia “cookie” ao

cliente na msg de resposta Set-cookie: 1678453

q  Cliente apresenta cookie nos pedidos posteriores cookie: 1678453

q  Servidor casa o cookie apresentado com a info guardada no servidor.

•  Autenticação.

•  Lembrando preferências do usuário, opções anteriores, etc…

cliente servidor

resposta http comum+ Set-cookie: #

msg de pedido http comum cookie: # Ação

específica do cookie

msg de pedido http comum


msg de pedido http comum cookie: #

Ação específica do cookie msg de resposta http comum




Ainda Cookies q  Maioria do sites armazenam informações básicas,

como endereços IP e preferências sobre idiomas, cores, navegação, clicks, etc... •  Portais como o Gmail e o Hotmail, nomes de usuários e senhas

de email também podem fazer parte dos Cookies.

q  Entre os parâmetros dos cookies estão: o tempo de vida (a data para o cookie "expirar a validade") e o domínio, ou grupo de páginas a que o cookie se aplica. •  Por exemplo, é possível fazer com que um cookie seja aplicado

apenas a endereços iniciados por um determinado prefixo, de maneira que esse mesmo cookie não se aplique a determinadas páginas.

47


48




49

cache proxy

q  Usuário configura browser: acessos WWW via procurador (proxy).

q  Cliente envia todos pedidos http ao procurador. •  Se objeto está no cache do

procurador, este o devolve imediatamente na resposta http.

•  Senão, solicita objeto do servidor de origem, armazena e depois devolve resposta http ao cliente.

Meta: atender pedido do cliente sem envolver servidor de origem.

cliente Servidor

proxy

cliente

pedido http

pedido http

resposta http

resposta http

pedido http

resposta http

pedido http resposta http

Servidor de origem

Servidor de origem


50

Por que usar cache WWW ?

q  Suposição: cache está “próximo” do cliente (por exemplo na mesma rede).

q  Tempo de resposta menor.

q  Diminui tráfego aos servidores distantes, •  Muitas vezes é o gargalo é o

enlace (link) que liga a rede da instituição até a Internet.

Servidores de origem

Internet pública

rede da instituição LAN 10 Mbps

enlace de accesso 2 Mbps

cache da instituição




51

GET condicional e aplicação em proxies

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

q  Cliente: especifica data da cópia em cache no pedido http If-modified-since:

<date>

q  Servidor: resposta não contém objeto se a cópia no cache é atual: HTTP/1.1 304 Not

Modified

cliente servidor

msg de pedido http If-modified-since:

<date>

resposta http HTTP/1.1

304 Not Modified

objeto não

modificado

msg de pedido http If-modified-since:

<date>

resposta http HTTP/1.1 200 OK

…

<data>

objeto modificado


HTTP/2 e SPDY q Google: Proposta do SPDY. q Pode ser considerado como uma “camada a

mais” no protocolo HTTP. •  Características originais do protocolo HTTP

(cabeçalhos, métodos etc.) são compatíveis.

q O SPDY propõe que cabeçalhos e todos os dados são transmitidos obrigatoriamente compactados e criptografados.

q Melhoria de cerca de 40% na performance. •  Maiores ganhos são registrados em conexões piores.

52




HTTP/2 e SPDY q  No HTTP 1.1, para melhorar a performance, habilita-se

o GZIP no servidor para comprimir os dados das respostas (habilitada explicitamente) •  No HTTP 2.0, o GZIP é padrão e obrigatório.

q  SPDY será descontinuado em favor do http2 q  No HTTP 2.0, os headers são binários e comprimidos

usando um algoritmo chamado HPACK. •  Diminui significativamente o volume de dados trafegados nos

headers.

q  SPDY obriga o uso de HTTPS e conexões seguras. •  HTTP/2 considera não obrigar ssl (em análise).

q  O Facebook e o Twitter já usam o protocolo SPDY.

53

http://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2/

https://www.tunetheweb.com/performance-test/


HTTP/2 Compatibilidade com browsers em abril/2017

54

SPDY será descontinuado em favor do http2 Ver : http://caniuse.com/#feat=http2

http://caniuse.com/#feat=spdy




CDN – Content Delivery Network

55

http://www.cdnreviews.com/


CDN – Content Delivery Network

56

http://www.cdnreviews.com/




Para se aprofundar em http: q  Learn http project - http://project67555.appspot.com/http.html

q  Detailed Explanation of HTTP Headers.

•  http://djce.org.uk/dumprequest

q  The difference between HTTP 1.0 and HTTP 1.1

•  http://www8.org/w8-papers/5c-protocols/key/key.html

q HTTP/2 e HTTP/2 Frequently Asked Questions

•  https://http2.github.io/

•  https://http2.github.io/faq/

(links verificados em 14.4.2017)

57


FTP

File Transfer Protocol

58




59

FTP: o protocolo de transferência de arquivos

q  FTP - File Transfer Protocol: definido pelo [RFC 959] q  Transferir arquivo de / para dispositivo remoto.

q  Modelo cliente / servidor:

•  cliente: lado que inicia transferência.

•  servidor: host remoto.

transferência do arquivo

Servidor

FTP Interface

do usuário FTP

cliente FTP

sistema de arquivos local

sistema de arquivos remoto

Humano


FTP: conexões separadas para controle e dados q  São abertas 2 conexões TCP paralelas:

•  Controle: troca comandos, respostas entre cliente, servidor. •  Porta 21/TCP (servidor).

•  Chamado de “Controle fora da banda” (outband control). •  Dados: de / para servidor

•  Porta 20/TCP (servidor).

q  Servidor ftp mantém “estado” (Statefull) •  Mantém, dentre outros: diretório atual e autenticação realizada.

60

cliente FTP

servidor FTP

(1) conexão de controle TCP, porta 21

(2) conexão de dados TCP, porta 20

FTP: Outband control

y x 21

20




FTP: conexões separadas para controle e dados Modo padrão: Active Open.

61


FTP Active Open (default)

62

Cliente informa porta onde receberá dados: torna-se um processo

“servidor” para o servidor.




FTP Active Open e firewall

63


FTP Passive Open

64

http://securitywing.com/active-vs-passive-ftp-mode/

Servidor informa porta (randômica) onde receberá dados, e cliente abre

(conecta) canal de dados TCP.

Randômica 1024 ~ 65535

Randômicas 1024 ~ 65535




Exemplo: Fluxo FTP Passive Open

65

Porta 20 não é usada em modo passive open

Randômicas 1024 ~ 65535


FTP: comandos e respostas Comandos típicos: q  Enviados em texto ASCII pelo canal de controle.

•  USER nome •  PASS senha •  LIST devolve lista de arquivos no diretório corrente •  RETR arquivo recupera (lê) arquivo remoto •  STOR arquivo armazena (escreve) arquivo no host remoto.

Códigos de retorno típicos: q  código e frase de status (como para http).

•  331 Username OK, password required •  125 data connection already open; transfer starting •  425 Can’t open data connection •  452 Error writing file

66




Correio Eletrônico

SMTP e outros protocolos

67


68

Correio Eletrônico (1) Três grandes componentes:

1.  Agentes de usuário: q  Mail User Agent (MUA).

2.  Agente de transporte. q  Mail Transport Agent (MTA). •  Protocolo de correio eletrônico.

•  SMTP: Simple Mail Transfer Protocolo. •  Implementado pelo MTA.

•  MTA: SMTP não é o único, apesar de ser o padrão da Internet.

3.  Agente de entrega (MDA ou MAA). •  Mail Delivery Agent (POP3 / IMAP)




Correio Eletrônico (2) MUA - Agente de Usuário q  Conhecido como “leitor de e-mail”. q  É o lado “cliente”. q  Compor, editar, ler mensagens de correio q  Exemplo: Outlook, Firebird, Mac Mail, Pine, e outros. q  Mensagens de saída e chegada são armazenadas no servidor.

69

MUA


70

Correio Eletrônico: SMTP [RFC 821]

q  Usa TCP para a transferência confiável de mensagens. •  Porta 25/TCP

q  Transferência direta: remetente ao servidor receptor. q  3 fases da transferência:

•  1 – Handshaking (cumprimento). •  NÃO confundir com handshaking do TCP !!

•  2 – Transferência das mensagens. •  3 – Encerramento.

q  Interação comando/resposta •  Comandos: são em texto ASCII. •  Resposta: envia código e frase de status.

q  Mensagens precisam ser em ASCII de 7-bits.




71

Interação SMTP típica S: 220 doces.br C: HELO consumidor.br S: 250 Hello consumidor.br, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Eu gostaria de comprar alguns doces. C: Você tem uma lista de preços? Obrigada. –Ana. C: . S: 250 Message accepted for delivery C: QUIT S: 221 doces.br closing connection


72

( Exercício: experimente uma interação SMTP com seu servidor de e-mail. )

q  % telnet nomedoservidor.algumlugar.br 25

q  Observe a resposta 220 do servidor q  Entre comandos HELO, MAIL FROM, RCPT TO, DATA,

QUIT, HELP.

q  Estes comandos permitem que você envie correio sem usar um cliente (leitor de correio). •  Basta conhecer o formato das mensagens do protocolo.




73

Protocolos de acesso ao correio armazenado

q  SMTP: entrega para armazenamento no servidor do receptor.

q  Protocolo de acesso ao correio: MDA ou MAA (recupera do servidor).

q  MDA – Mail Delivery Agent / MAA - Mail Access Agent

•  POP3: Post Office Protocol [RFC 1939]

•  Autorização (agente - servidor) e transferência.

•  IMAP: Internet Mail Access Protocol [RFC 1730]

•  Mais comandos e mais opções (mais complexo).

•  Manuseio de mensagens armazenadas no servidor.

servidor de correio do remetente

SMTP SMTP POP3 ou IMAP

servidor de correio do receptor

MUA

MUA

MAA MDA

MTA

MTA


DNS

Domain Name System

74




75

DNS: Domain Name System (1) Pessoas:

•  CPF, No. de Passaporte, RG, NOME, etc...

Dispositivos na Internet: •  Dispositivos Internet são identificados por números. •  Endereço IP (32 bits): •  Usado para endereçar datagramas (“pacotes”) IP.

•  Será detalhado no estudo da camada de rede.

•  “Nome” : é usado por humanos.

•  www.unesp.br = 200.145.9.9

Como mapear entre nome e endereço IP?


76

DNS: Domain Name System (2)

q  É composto por: •  Uma base de dados distribuída implementada em uma

hierarquia de servidores de nomes (nameservers).

•  Um protocolo da camada de aplicação que permite que os dispositivos e os servidores de nomes se comuniquem, de modo a fornecer o serviço de tradução → “resolução de nome”.

“Resolver” um nome = traduzir nome em endereço IP.

q  O protocolo do DNS funciona sobre UDP e usa a porta 53.




Servidores de nomes DNS (1) Por quê não centralizar a resolução de nomes?

q  Antigamente: arquivo /etc/hosts.txt https://en.wikipedia.org/wiki/Hosts_(file) q  Ponto único de falha. q  Volume de tráfego. q  Base de dados centralizada seria distante. q  Dificuldade de Manutenção da BD.

Ou seja: problemas de escalabilidade.

77 http://www.softpanorama.org/DNS/history.shtml (24/3/2016)


Servidores de nomes DNS (2) q  Nenhum servidor mantém todos os mapeamento

nome-para-endereço IP. q  Servidor de nomes local:

•  Cada provedor, empresa ou instituição tem servidor de nomes local – chamado de “servidor recursivo”

•  Pedido DNS de um host vai primeiro ao servidor recursivo.

q  Servidor de nomes autoritativo: •  É o que contém a base de dados oficial do domínio. •  Pode realizar tradução nome/endereço para o domínio que

serve.

78




Consulta e resolução de DNS (3)

79


80

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

q  Uma vez um servidor qualquer aprende um mapeamento, ele o coloca numa cache local.

•  Consultas posteriores são resolvidas usando dados da cache.

q Entradas no cache são sujeitas a temporização (removidas depois de certo tempo) •  ttl = time to live (sobrevida).




DNS: Servidores raiz (root servers) (1) q  Consultado por servidor recursivo que não tem cache de uma

consulta. q  Servidor raiz (root server):

•  Indica o servidor autoritativo para uma consulta. •  Indicando o endereço IP do servidor de nível mais baixo que pode

responder a consulta.

Exemplo: uma consulta sobre a resolução de www.acme.com.br feita para um servidor raiz, recebe de

retorno o IP do(s) servidor(es) tem autoridade para responder pelo .BR (registro.br)

Devolve este mapeamento ao servidor recursivo.

81


DNS: Servidores raiz (root servers) q  Representado pelo “.”

q  Existem 13 de servidores raiz no mundo.

q  Seus endereços IP são fixos e raramente mudam.

q  São representados por “letras” de A até M.

q  Cada servidor “letra” tem vários espelhos espalhados pelo mundo.

82




DNS Root servers de A até M

83


DNS Root servers de A até M

84




DNS Root servers & mirrors

85

http://root-servers.org/

Exercício: o que é o AS112 ?


Compartilhamento de arquivos

Aplicações P2P

86




Modelo Cliente / Servidor q Modelo mais usado na Internet.

q Mas não explora o potencial de computação distribuída proveniente da Rede.

Dispositivos com capacidade considerável ficam subutilizados na Internet, formando uma base com

com alto potencial de processamento e armazenamento.


Modelo P2P Exemplo: • Alice executa a aplicação cliente P2P em seu notebook.

•  Intermitentemente à conecta-se à Internet; •  Obtém novo endereço IP para cada conexão.

• Procura por um determinado arquivo de uma música. • A aplicação exibe parceiros que tem uma cópia da

música. • Alice escolhe um dos parceiros: Bob. • O arquivo é copiado de Bob para o notebook de Alice: •  Enquanto Alice faz o download, outros usuários usam

upload da máquina de Alice. Todos os pares são servidores = altamente escaláveis!




Naspter

q Primeiro programa de compartilhamento massivo de arquivos através de P2P.

q Shawn Fanning. •  Primeira versão: 1999

•  Popularidade: início de 2000.

•  Pico: 2001 à 8 M users/dia ≈ 20 M músicas / dia.

•  No início de 2001 não resistiu a uma série de ações legais e o serviço foi fechado em março.

•  Batalha judicial com a RIAA*

•  Novembro de 2002 à direitos vendidos para a Roxio. * Recording Industry Association of America.


Napster – funcionamento simplificado

1.  Cliente se conecta com servidor e envia a sua lista de arquivos compartilhados.

•  Junto com IP e outros dados.

2.  Cliente envia palavras-chave para fazer busca na lista completa.

3.  Cliente testa taxa de transmissão dos pares que têm o arquivo solicitado (ping).

4.  Peers respondem (pong). 5.  O arquivo é transferido diretamente entre os

pares.




Napster - Problemas q Servidor centralizado

•  Ponto único de falhas. •  Sujeito a congestionamentos. •  Sob controle total do Napster.

•  Apenas ilusão de liberdade.

q Nenhuma segurança: •  Sem criptografia. •  Sem autenticação. •  Sem privacidade (identidade é revelada).


Definição de sistema P2P q  Classe de aplicações que aproveita

recursos disponíveis nas bordas da rede. •  Armazenamento. •  Tempo de CPU. •  Bandwidth. •  Conteúdo. •  Presença humana.

Compartilhamento de recursos e serviços computacionais, diretamente entre sistemas.




Características P2P (1)

q  Sistemas distribuídos sem controle centralizado ou organização hierárquica.

q  Software executado em cada par (peer) é equivalente em funcionalidade.

q  Cada participante age como cliente e servidor ao mesmo tempo (servent).


Características P2P (2) q Sem coordenação central.

q Sem banco de dados central.

q Sem ponto único de falha ou gargalo.

q Nenhum ponto (peer) tem visão global do sistema.

q Todos os dados e serviços são acessíveis de qualquer ponto.

q Pontos são autônomos.

q Pontos e conexões não precisam ser confiáveis.




Rede de overlay

95

Os pares da rede P2P formam uma rede sobreposta à rede IP


Redes Overlay

Rede Overlay

Rede Física

enlace físico

enlace virtual




Escalabilidade de arquiteturas P2P

97


Transmissão de um arquivo us : taxa upload do server.

ui : taxa de upload do host i.

di : taxa de download do host i.

F : tamanho do arquivo em bits. N : número de hosts (pares) que querem uma cópia do arquivo.




No modelo Cliente - Servidor q  Transmitir uma cópia do arquivo para cada um dos N pares.

•  Transmitir um total de (N x F ) bits. •  Como a taxa de upload do servidor é de us, o tempo para

distribuição do arquivo deve ser pelo menos NF/us.

q  dmin: menor capacidade de download de um par. •  Par com menor taxa não pode obter todos os F bits do arquivo

em menos do que F/dmin segundos.

q  Então, no pior caso, temos:

q  Consideraremos este limite inferior como o tempo real:

99

Dcs ≥maxNFus, Fdmin

"#$

%&'

Dcs =maxNFus, Fdmin

!"#

$%&

Para N grande, o tempo será dado por NF/us. Então: se N aumenta em mil pares, o tempo

para distribuir para todos os pares aumentará mil vezes


No modelo P2P (1) q Servidor – melhor caso:

•  upload de pelo menos uma cópia – tempo: F/us

q Nó: cada cliente faz o download de uma cópia •  Tempo de download do cliente mais lento: F/dmin

•  Todos os nós: download agregado de NF bits

q Taxa máxima de upload (banda) do sistema:

100

us + uii=1

N

∑

taxa de upload mais rápida possível




No modelo P2P (2) q  No início, apenas o servidor tem o arquivo. q  Então, no caso da arquitetura P2P o tempo mínimo de

distribuição do arquivo F é de F/us •  Um bit enviado pelo servidor pode não precisar ser enviado

novamente, visto que os pares podem redistribuir este bit.

q Fica como exercício mostrar que o tempo mínimo real de distribuição P2P é:

101

DP2P =maxFus, Fdmin

, NF

us + uii=1

N

∑

⎧

⎨⎪⎪

⎩⎪⎪

⎫

⎬⎪⎪

⎭⎪⎪

Ver livro: tópico 2.6.1 - pag. 106 a 109 (K&R - 6ª. Ed)


Tempo de distribuição q  Nesse exemplo:

•  Considere que todos os pares tem taxa de upload u. •  Definimos que F/u = 1 hora (Supomos: us= 10u e dmin ≥ us )




BitTorrent q Torrent: todos os pares que participam da

distribuição de um arquivo.

q Pares de um torrent fazem o download de blocos de tamanho igual do arquivo entre si. •  Tamanho típico de 256 Kbytes no bloco.

q Enquanto faz o download de blocos também faz o upload para outros pares.

q Pode entrar e sair com apenas um subconjunto de blocos.

103


BitTorrent - tracker q  Tracker: nó de infraestrutura que cada torrent possui. q  Quando um par chega em um torrent, ele se registra

com o tracker. •  Periodicamente informa que ainda está vivo na rede.

q  O Tracker mantém um registro de todos os pares que participam do torrent.

q  Quando um novo par chega: tracker seleciona aleatoriamente um subconjunto de pares participantes e envie os endereços IP.

q  O novo par tenta estabelecer conexões simultâneas com todos.

104




BitTorrent - funcionamento

105


Tracker e pares vizinhos q Pares vizinhos: nós com quem se consegue

estabelecer uma conexão. Pares vizinhos de Alice




Tracker e pares vizinhos q De tempos em tempos Alice pede a cada um de

seus pares vizinhos a lista de quais blocos que eles tem. •  Se Alice tiver L vizinhos, ela terá L listas de blocos.

q  Com essa informação, Alice emitirá pedidos de blocos que ela não tem.

A qualquer momento, Alice tem um subconjunto de blocos, e saberá quais blocos seus vizinhos tem.

Duas decisões importantes: 1.  Quais blocos deve solicitar de início a

seus vizinhos. 2.  A quais vizinhos deve enviar os blocos

solicitados.


Rarest first e unchoked 1. Quais blocos deve solicitar de início? q  Técnica rarest first (mais raro primeiro).

•  Determinar quais são os mais raros entre vizinhos.

•  Blocos mais raros distribuídos mais depressa.

•  Equalizar o número de cópias de cada bloco.

2. A quais vizinhos deve enviar?

q  Algoritmo de troca inteligente. •  Priorizar vizinhos que enviam com maior taxa.

•  Mede continuamente a taxa de recepção e determina os 4 pares que fornecem taxa mais alta.

•  Pares unchoked (não sufocado). •  A cada 10 seg recalcula as taxas e eventualmente modifica os 4 pares

unchoked. 108




Optimistic unchoked q A cada 30 seg Alice escolhe um vizinho

adicional ao acaso e envia blocos a ele (Bob). •  Alice pode se tornar um dos 4 melhores

transmissores de Bob. •  Nesse caso, Bob começa a enviar dados para Alice. •  Se a taxa for alta o suficiente, Bob pode se tornar um

dos 4 melhores para Alice.

q Pares que fazem uploads em taxas compatíveis tendem a se encontrar.

q Mecanismos de incentivo para troca: •  Tit-for-tat (olho por olho)

109


Optimistic unchoked

110

Com taxa de upload mais alta, pode achar parceiros com melhor negociação e

obter arquivo mais rápido!




Sufocados q Todos os demais pares além dos 4 pares “top”

e um par de experiência aleatória estão sufocados.

•  Não recebem nenhum bloco de Alice.

q No BitTorrent existem outros mecanismos que não serão discutidos aqui: •  Uso de mini-blocos, pipelining, primeira seleção

aleatória, modo end-game e modo anti-snubbing.

111


O Que há num arquivo de torrent q Campos encontrados em um arquivo torrent:

•  announce: informa qual tracker que trata da distribuição do arquivo;

•  announce-list: informa eventuais trackers auxiliares;

•  comment: comentário inserido pelo criador do torrent;

•  created by: informa com qual software o torrent foi criado;

•  info: contém todos os dados referentes ao arquivo, como nome, tamanho, código de verificação de integridade (hash), etc.

112




Alguns termos de BitTorrent

113

•  Seed (semeador): é o nome dado a cada máquina que possui o arquivo *completo* que está sendo compartilhado. É necessário que haja pelo menos um seed para que o compartilhamento ocorra integralmente;

•  Peer (ponto, nó): termo que indica cada computador que compartilha arquivos. Quando você está baixando algo pelo BitTorrent, seu computador assume o papel de um peer, ou seja, de um ponto ou nó nesta rede;

•  Leecher ("sugador"): este termo faz referência aos computadores que ainda estão baixando arquivos ou que já o baixaram completamente, mas por alguma razão não o estão compartilhando;

•  Tracker (rastreador): servidor que mantém o controle de comunicação entre todos os seeds e peers. O tracker não tem uma cópia do arquivo, muito menos interfere diretamente no compartilhamento.

•  Swarm (enxame): nome dado ao conjunto de computadores que está compartilhando o mesmo arquivo.

•  Exemplo: se o arquivo video.avi estiver sendo compartilhado por 8 seeds e por 34 peers, o swarm do arquivo contém 42 computadores (8 seeds + 34 peers).


Exercício: Distributed Hash Tables (DHTs)

•  Considerar como montar uma versão distribuída, P2P, de um banco de dados, que guardará os pares (chave, valor) por milhões de nós.




Distributed Hash Table (DHT)

q DHT = banco de dados P2P distribuído

q Banco de dados tem duplas (chave, valor) ( chave: número CPF; valor: nome )

( chave: título música; valor: endereço IP )

q Os pares consultam BD com a chave •  BD retorna valor que dá match com a chave

q Pares podem inserir duplas (chave, valor)


ID do DHT

q DHT atribui identificador inteiro de n bits a cada par no intervalo [0,2n - 1].

(chave, valor) ßà ID •  Exige que cada chave seja um inteiro no mesmo

intervalo.

q Chaves: função hash h(k) da chave original. •  Exemplo: chave = h(“Pink Floyd The Wall”)

•  Por isso que a chamamos de tabela “hash” distribuída

Uma função hash é um algoritmo que mapeia dados de comprimento variável para dados de comprimento fixo. Os valores retornados por uma função hash são chamados valores hash




Como atribuir chaves aos pares?

q  Ideia básica: •  Converter cada chave em um inteiro. •  Atribuir inteiro a cada peer. •  Colocar o par (chave, valor) no peer mais próximo à

chave (no peer que tem o ID mais próximo). q Convenção: nó mais próximo é o sucessor

imediato da chave. q Exemplo: n= 4; pares: [0,24 - 1] = [0,15]

1, 3, 4, 5, 8, 10, 12, 15 •  chave = 13 à par sucessor = 14 •  chave = 15 à par sucessor = 1


DHT é um Anel (circular) q Maioria das implementações existentes:

§  Consideram a DHT como um anel. §  Cada Peer é uma posição da tabela. §  Essa tabela está ordenada pelas chaves de

forma ascendente.

118




1

3

4

5

8 10

12

15

DHT circular

q Cada par só conhece sucessor e predecessor imediato.

q Forma uma “rede de sobreposição”


Consulta DHT q Lembrando:

•  Item de dado com chave k é mapeado em nó com menor identificador k <= ID.

q suc(k): denominado nó sucessor da chave k.

q Consulta: Lookup(k) deve retornar endereço de suc(k). •  Cada peer conhece sucessor e predecessor

imediatos em uma rede de sobreposição.

120




Consulta DHT

121

O(N) mensagens em média para resolver consulta,

quando há N pares


DHT com atalhos

122

•  Cada peer conhece sucessor, predecessor e atalhos. • Exemplo: redução de 6 para 2 mensagens. • É possível desenhar atalhos para que existam O(log(n)) vizinhos, O(log(n)) mensagens em consultas.




Peer Churn

q Peers entram e saem da rede (churn).

q Cada peer conhece seus dois sucessores.

q Cada peer “pinga” seus dois sucessores para verificar se continuam online.

q Se o sucessor imediato sai, realoca segundo sucessor como imediato.

123


Peer Churn - saída q Peer 5 sai.

q Peer 4 transforma 8 em seu sucessor imediato e pergunta ao 8 qual é seu sucessor.

q Peer 4 torna sucessor de 8 (o peer 10) seu segundo sucessor.

124




Peer Churn - entrada q Peer 13 quer entrar: gera um identificador ID. q Consulta algum nó para saber qual ponto da rede

deve entrar: quem será seu sucessor e predecessor.

q Transferência das responsabilidades de dados de 15 para 13.

125

1

3

4

8 10

12

15

13


Estudo de caso do P2P: Skype

q  inerentemente P2P: pares de usuários se comunicam.

q  protocolo próprio da camada de aplicação (deduzido por engenharia reversa)

q  sobreposição hierárquica com SNs

q  índice compara usernames com endereços IP; distribuído por SNs

Clientes Skype (SC)

supernó (SN)

servidor de login Skype




Estudo de caso do P2P: Skype Pares como retransmissores q  problema quando Alice e Bob

estão atrás de “NATs” •  NAT impede que um par de

fora inicie uma chamada para um par de dentro da rede

q  solução: •  usando os SNs de Alice e de

Bob, o retransmissor é escolhido

•  cada par inicia a sessão com retransmissão.

•  pares agora podem se comunicar através de NATs com retransmissão


Protocolos e implementações DHT •  Kademlia •  Apache Cassandra •  BATON Overlay •  Mainline DHT -

Standard DHT •  Usado pelo BitTorrent

•  Baseado em Kademlia.

•  CAN •  (Content Addressable Network)

•  Chord •  Koorde •  Aerospike •  Pastry •  P-Grid •  Tapestry •  TomP2P

128




Algumas aplicações usando DHT

129

•  BTDigg: BitTorrent DHT search engine •  cjdns: routing engine for mesh-based networks •  CloudSNAP: a decentralized web application deployment platform •  Codeen: web caching •  Coral Content Distribution Network •  FAROO: peer-to-peer Web search engine •  Freenet: a censorship-resistant anonymous network •  GlusterFS: a distributed file system used for storage virtualization •  GNUnet: Freenet-like distribution network including a DHT implementation •  I2P: An open-source anonymous peer-to-peer network. •  I2P-Bote: serverless secure anonymous e-mail. •  JXTA: open-source P2P platform •  Oracle Coherence: data grid built on top of a Java DHT implementation •  Retroshare: a Friend-to-friend network •  YaCy: a distributed search engine •  Tox: an instant messaging system intended to function as a Skype replacement •  Twister: a microblogging peer-to-peer platform •  Perfect Dark: a peer-to-peer file-sharing application from Japan


130

Sockets

Como funcionam as aplicações cliente/servidor




API sockets

API Sockets q  Application Program Interface

q  Surgiu em BSD4.1 UNIX, 1981

q  Explicitamente criados, usados e liberados por aplicações.

q  Baseia-se no modelo cliente - servidor

q  Dois tipos de serviço de transporte via API Sockets •  Datagrama não confiável (UDP)

•  Fluxo de bytes, confiável (TCP)

131


132

Programação com sockets

•  Uma interface (uma “porta”) local do dispositivo,

criada pela aplicação por, e pertencente a esta,

que é controlada pelo Sistema Operacional. •  Através desta interface de sofwtare um processo

de aplicação pode tanto enviar como receber

mensagens de/para outro processo de aplicação,

seja ele remoto ou local.

socket




133

Programação com sockets

Socket: uma porta entre o processo de aplicação e um protocolo de transporte fim-a-fim

(UDP ou TCP)

processo

com buffers, variáveis

socket

controlado pelo programador de

aplicação controlado

pelo sistema operacional

estação ou servidor

processo

com buffers, variáveis

socket

controlado pelo programador de aplicação

controlado pelo sistema operacional

estação ou servidor

internet


134

Capítulo 2: Sumário

q  Requisitos do serviço de aplicação: •  Confiabilidade, banda,

retardo. q  Paradigma cliente-servidor. q  Modelo de serviço do

transporte orientado a conexão, confiável da Internet: TCP.

q  Modelo não confiável: datagramas UDP.

Terminamos nosso estudo de aplicações de rede!

q  Protocolos específicos: •  HTTP •  FTP. •  SMTP, IMAP e POP3. •  DNS. •  P2P.

q  Sockets •  Implementação cliente/

servidor. •  Usando sockets tcp, udp.




135

Capítulo 2: Sumário

q  Troca típica de mensagens em pedido/resposta: •  Cliente solicita info ou serviço. •  Servidor responde com dados, e

código de status. q  Formatos de mensagens:

•  Cabeçalhos: campos com informações sobre dados (metadados).

•  Dados: informação sendo comunicada.

Mais importante - aprendemos de protocolos:

q  Msgs de controle X dados. •  na banda, fora da banda

q  Centralizado X descentralizado

q  Sem estado X com estado q  Transferência de msgs

confiável X não confiável q  “Complexidade na borda da

rede”.


Atividades recomendadas

Programação com Sockets

136

Rec

omen

dado




Programação de sockets

API socket q  introduzida no BSD4.1 UNIX

em 1981 q  criada, usada e liberada

explicitamente pelas apls. q  paradigma cliente-servidor q  dois tipos de serviços de

transporte por meio da API socket: •  UDP •  TCP

Uma interface criada pela aplicação e controlada

pelo SO (uma “porta”) na qual o processo da

aplicação pode enviar e receber mensagens para/

de outro processo da aplicação

socket

Objetivo: aprender a criar aplicação cliente-servidor que se comunica usando sockets

Rec

omen

dado


Fundamentos de programação de socket

q  servidor deve estar rodando antes que o cliente possa lhe enviar algo

q  servidor deve ter um socket (porta) pelo qual recebe e envia segmentos

q da mesma forma, o cliente precisa de um socket

q  socket é identificado localmente com um número de porta •  semelhante ao número

de apartamento de um prédio

q  cliente precisa saber o endereço IP do servidor e o número de porta do socket

Rec

omen

dado




Programação de socket com UDP

UDP: sem “conexão” entre cliente e servidor

q  sem “handshaking” q  emissor conecta de forma

explícita endereço IP e porta do destino a cada segmento

q  SO conecta endereço IP e porta do socket emissor a cada segmento

q  Servidor pode extrair endereço IP, porta do emissor a partir do segmento recebido

ponto de vista da aplicação

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

(“datagramas”) entre cliente e servidor

Nota: A terminologia oficial para um pacote UDP é “datagrama”. Nesta aula, usamos “segmento UDP” em

seu lugar.

Rec

omen

dado


Exemplo em curso

q cliente: •  usuário digita linha de texto •  programa cliente envia linha ao servidor

q servidor: •  servidor recebe linha de texto •  coloca todas as letras em maiúsculas •  envia linha modificada ao cliente

q cliente: •  recebe linha de texto •  apresenta

Rec

omen

dado




Interação de socket cliente/servidor: UDP servidor (rodando em hostid)

fecha clientSocket

lê datagrama de clientSocket

create socket,

clientSocket = DatagramSocket()

cliente

Cria datagrama com IP do servidor e port = x; envia datagrama

por clientSocket

create socket, port = x.

serverSocket = DatagramSocket()

lê datagrama de serverSocket

escreve resposta em serverSocket

indicando endereço do cliente, número de

porta

Rec

omen

dado


Exemplo: cliente Java (UDP)

Saída: envia pacote (lembre-se de que TCP enviou “cadeia de bytes”)

Entrada: recebe pacote (lembre-se

de que TCP recebeu “cadeia

de bytes”)

socket UDP do cliente

Rec

omen

dado




import java.io.*; import java.net.*;

class UDPClient {

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

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

DatagramSocket clientSocket = new DatagramSocket();

InetAddress IPAddress = InetAddress.getByName("hostname");

byte[ ] sendData = new byte[1024];

byte[ ] receiveData = new byte[1024];

String sentence = inFromUser.readLine();

sendData = sentence.getBytes();

cria cadeia de entrada

cria socket do cliente

traduz hostname para endereço IP

usando DNS

Rec

omen

dado


DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876);

clientSocket.send(sendPacket);

DatagramPacket receivePacket =

new DatagramPacket(receiveData, receiveData.length);

clientSocket.receive(receivePacket);

String modifiedSentence = new String(receivePacket.getData());

System.out.println("FROM SERVER:" + modifiedSentence);

clientSocket.close(); }

}

cria datagrama com dados a enviar,

tamanho, end. IP, porta

envia datagrama ao servidor

lê datagrama do servidor

Rec

omen

dado




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

cria socket de datagrama na porta 9876

cria espaço para datagrama recebido

recebe datagrama

Rec

omen

dado


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 end. IP # porta do

emissor

escreve datagrama no socket

fim do loop while, retorna e espera outro datagrama

cria datagrama p/ enviar ao cliente R

ecom

enda

do




Observações e perguntas sobre UDP q cliente e servidor usam DatagramSocket q IP e porta de destino são explicitamente

conectados ao segmento. q O que acontece se mudarmos clientSocket e

serverSocket para “mySocket”? q O cliente pode enviar um segmento ao servidor

sem saber o endereço IP e/ou número de porta do servidor?

q Múltiplos clientes podem usar o servidor?

Rec

omen

dado


Programação de socket usando TCP

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

processo

TCP com buffers, variáveis

socket

controlado pelo desenvolvedor

da aplicação controlado

pelo sistema operacional

hospedeiro ou servidor

processo

TCP com buffers, variáveis

socket

controlado pelo desenvolvedor da aplicação

controlado pelo sistema operacional

hospedeiro ou servidor

Internet

Rec

omen

dado




Programação de socket com TCP

cliente deve contactar servidor q  processo servidor primeiro

deve estar rodando q  servidor deve ter criado

socket (porta) que aceita contato do cliente

cliente contacta servidor: q  criando socket TCP local ao

cliente q  especificando endereço IP, #

porta do processo servidor q  quando cliente cria socket:

cliente TCP estabelece conexão com servidor TCP

q  quando contactado pelo cliente, servidor TCP cria novo socket para processo servidor se comunicar com cliente •  permite que servidor fale

com múltiplos clientes •  números de porta de origem

usados para distinguir clientes (mais no Cap. 3)

TCP oferece transferência de bytes confiável, em ordem

(“pipe”) entre cliente e servidor

ponto de vista da aplicação

Rec

omen

dado


Interação de socket cliente/servidor: TCP

espera requisição da conexão que chega

connectionSocket = welcomeSocket.accept()

cria socket, porta = x, para

requisição que chega: welcomeSocket =

ServerSocket() cria socket,

conexão com hostid, porta = x clientSocket =

Socket()

fecha connectionSocket

lê resposta de clientSocket

fecha clientSocket

servidor (rodando em hostid) Cliente

envia requisição usando clientSocket lê requisição de

connectionSocket escrever resposta em

connectionSocket

estabelecimento da conexão TCP

Rec

omen

dado




Jargão de cadeia

q  uma cadeia é uma sequência de caracteres que flui para dentro ou fora de um processo.

q  uma cadeia de entrada está conectada a uma fonte de entrada para o processo, p. e., teclado ou socket.

q  uma cadeia de saída está conectada a uma fonte de saída, p. e., monitor ou socket.

socket TCP cliente

Processo cliente

Rec

omen

dado


Exemplo de apl. cliente-servidor: 1) cliente lê linha da entrada padrão

(cadeia inFromUser), envia ao servidor via socket (cadeia outToServer)

2) servidor lê linha do socket 3) servidor converte linha para

maiúsculas, envia de volta ao cliente 4) cliente lê, imprime linha modificada

do socket (cadeia inFromServer)

Programação de socket com TCP

Rec

omen

dado




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

cria cadeia de entrada

cria socket cliente, conexão

com servidor cria cadeia de

saída conectada ao socket

Rec

omen

dado


BufferedReader inFromServer = new BufferedReader(new

InputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();

outToServer.writeBytes(sentence + '\n');

modifiedSentence = inFromServer.readLine();

System.out.println("FROM SERVER: " + modifiedSentence);

clientSocket.close();

} }

cria cadeia de entrada conectada

ao socket

envia linha ao servidor

lê linha do servidor

Rec

omen

dado




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

cria socket de apresentação na

porta 6789

espera no socket de apresentação pelo

contato do cliente

cria cadeia de entrada, conectada

ao socket

Rec

omen

dado


DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());

clientSentence = inFromClient.readLine();

capitalizedSentence = clientSentence.toUpperCase() + '\n';

outToClient.writeBytes(capitalizedSentence);

} } }

lê linha do socket

cria cadeia de saída, conectada

ao socket

escreve linha no socket

fim do loop while, retorna e espera outra

conexão do cliente

Rec

omen

dado

Documents

Capítulo 2 Camada de Aplicação - Bem-vindo!adriano/aulas/redes/2017/Redes1/... · Prof. Dr. Adriano Mauro Cansian 2 unesp - IBILCE - SJRP 3 Conceitos Fundamentais Aplicações: