Capítulo 2 Camada de Aplicaçãoadriano/aulas/redes/2016/Redes-I/2... · UNESP - IBILCE - SJRP - Curso de Redes de Computadores Capítulo 2 Prof. Dr. Adriano Mauro Cansian 3 unesp

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  O que conhecer:

•  Aspectos conceituais dos protocolos de aplicação.

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

q  Como conhecer: •  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

q  Como é feita a programação de aplicações de rede. •  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. •  Rodam em hosts.

•  Ou seja, nos sistemas finais.

•  Trocam mensagens para implementar a aplicação.

•  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  Um protocolo da camada de aplicação define como os processos de aplicação

trocam mensagens:

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

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

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

•  Semântica dos campos. •  Define o significado da informação nos campos (em cada parte).

•  Regras. •  Definem quando e como um processo envia e responde

mensagens.


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  Um 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: •  Inicia contato com o server

•  Aquele que “chama”. •  Solicita serviço do servidor.

Servidor: •  Provê o serviço requisitado ao cliente. •  Fica “ouvindo” à espera de pedidos de conexão.

•  Isso é uma convenção.


rede enlace física


rede enlace física

Pedido

Resposta




11

Protocolos da camada de aplicação API - Aplication Program Interface:

•  Interface de programação de aplicações.

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

q APIs à definidas pelos RFCs. q Socket (= tomada).

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


12

q  O socket pode ser entendido como a porta de saída e entrada do processo:

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

•  Quando um processo quer emitir uma mensagem a um outro processo em um outro host, entrega a mensagem para o socket.

•  O processo supõe que há um infra-estrutura de transporte no outro lado, 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


14


− Perguntas / exercícios: •  Como um processo identifica outro?




Comunicação lógica client-server

15


16

Exemplo de comunicação lógica de um processo com

conexão TCP, por intermédio dos sockets.

buffering

buffering




17

Como um processo identifica outro ? Pergunta: Como um processo pode “identificar” o outro

processo com o qual quer se comunicar? q  Endereço IP do host do outro processo.

•  Por enquanto: o IP ADDRESS é um valor de 32-bits que identifica unicamente o sistema de extremidade.

–  (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.9!q  “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”.

18




19

Os principais protocolos de aplicação


http

HiperText Transport Protocol e a Web

20




21

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

•  Consiste de “objetos” •  Endereçada por um URL:

Universal Resource Locator. 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


22

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




23

Operação do protocolo http:

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

servidor, na porta 80. •  Cria socket

2.) Servidor aceita conexão do cliente.

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


24

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

1a. Cliente http inicia conexão TCP ao servidor http (processo) em www.unesp.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.unesp.br espera por 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…




25

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ões não-persistente e persistente (1) Conexão http não persistente (obsoleta): q  HTTP/1.0 q  Servidor:

•  Analisa pedido, •  Responde, e •  Encerra conexão TCP.

q  Cliente: •  Solicita cada objeto referenciado na resposta.

q  Repete o ciclo para cada objeto. q  2 RTTs para trazer cada objeto

(RTT = round trip time = tempo de ida e volta).

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

26




Conexões não-persistente e persistente

Conexão http persistente: 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 Cliente envia pedidos para todos objetos referenciados, assim que recebe o HTML base .

q Menos RTTs, e menos partida lenta.

27

A maioria de browsers usa conexões TCP paralelas.


28

Conexão não-persistente (1) q  O cliente HTTP inicia uma conexão TCP com o servidor.

q  O cliente emite mensagem de requisição HTTP usuário através do socket associado com a conexão do TCP que foi estabelecida.

q  Servidor HTTP recebe o request através do socket associado com a conexão estabelecida, recupera o objeto (index.html) de seu armazenamento, encapsula o objeto em uma mensagem HTTP de resposta, e emite a mensagem de resposta ao cliente através do socket.

q  O servidor diz ao cliente para fechar a conexão TCP.

q  O cliente recebe a mensagem de resposta. A conexão TCP termina. A mensagem indica que o objeto encapsulado é um arquivo HTML. O cliente extrai o arquivo da mensagem de resposta, analisa, e encontra referências a 10 objetos do JPEG.

q  As primeiras quatro etapas são repetidas então para cada um dos objetos JPEG referenciados.




29

Conexão não-persistente (2) q  Quando o browser recebe uma página, mostra a página ao usuário

q  Dois browsers diferentes podem interpretar (isto é, mostrar ao usuário) um webpage de maneiras diferentes. •  O HTTP não define como uma webpage é interpretada por um cliente.

•  As especificações do HTTP (RFC1945 e RFC2616) definem somente o protocolo de comunicação entre o programa HTTP do cliente e o programa HTTP do servidor.

q  Nas etapas das conexões não persistentes, cada conexão do TCP é fechada depois que o servidor envia o objeto: a conexão não persiste para outros objetos.

q  Cada conexão TCP transporta exatamente uma mensagem de pedido e uma mensagem de resposta. No nosso exemplo, quando um usuário requisita uma página, 11 conexões TCP são geradas.


Conexão não-persistente (3)

30




31

Round Trip Time (1) q  Quantidade de tempo gasta entre cliente solicitar um arquivo HTML até

que o arquivo esteja recebido?

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.

q  RTT inclui os atrasos de propagação, de enfileiramento e de processamento em routers e comutadores intermediários.

q  Usuário clica num hyperlink. Isto faz com que o browser inicie uma conexão do TCP entre o browser e o web server.

q  Envolve um “three-way handshake”: o cliente emite uma mensagem TCP ao servidor, o servidor reconhece e responde com uma mensagem. Finalmente, o cliente confirma de volta ao servidor.


32

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.

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

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




33

Conexão persistente (1) q  Cada objeto sofre dois RTTs:

•  um RTT para estabelecer a conexão TCP, e

•  um RTT para solicitar e receber um objeto.

q  Cada objeto sofre do “partida lenta”(slow start) do TCP.

q  Com as conexão persistente, o servidor deixa a conexão TCP aberta após ter emitido uma resposta.

q  Os pedidos e as respostas subseqüentes 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)

34




Não-persistente X persistente

35


36

Conexão persistente (2) q Duas versões de conexões persistentes: q sem pipelining (paralelismo) e com pipelining.

•  Sem pipelining: o cliente emite um pedido novo somente quando a resposta precedente foi recebida.

•  Com pipelining: o cliente emite um pedido assim que encontrar uma referência.

•  É o default para HTTP/1.1.




37

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.


38

Mensagem http de requisição (1)

Formato geral de uma mensagem de requisição




39

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


40

Mensagem http de resposta (1)

Formato geral de uma mensagem de RESPOSTA

Note a diferença nestes campos




41

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


42

Códigos de status da resposta http

q  Aparecem na primeira linha da mensagem de resposta cliente-servidor. •  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.




43

HTML (HyperText Markup Language)

q  HTML: uma linguagem simples para hipertexto •  começou como versão simples de SGML. •  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>!

q  Vários formatos •  listas de bullets, listas ordenadas, listas de definição •  tabelas •  Frames •  Etc... Etc...


44

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 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. •  Cada aplicação pode ter a sua própria linguagem, que é

traduzida para uma linguagem universal XML. q O objetivo dos webservices é a comunicação de

aplicações através da Internet.

45


46

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





47

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


48

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




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 ?

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




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.

51


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

52




SPDY 3.1 Google e HTTP/2

53

•  Versão mais recente do protocolo SPDY 3.1, é suportada apenas pelos navegadores Chrome e Opera, mas o Firefox a suporta a partir da versão (27).

•  SPDY versão anterior (versão 3) é suportada pelo Internet Explorer 11 e pelo Firefox desde a versão 15.

•  3.1 é suportado pelas versões móveis desses navegadores e pelo navegador padrão do Android desde a versão Android 3.0.

•  Do lado dos servidores, existe um módulo para o Apache httpd que ativa suporte ao protocolo: o mod_spdy

•  O Servidor nginx também tem suporte à versão 3.1 do protocolo desde sua versão 1.5.10, sem necessidade de plugins.

•  Em Java, o servidor Jetty já suporta o protocolo nas versões mais recentes

•  Tomcat já conta com um suporte experimental em sua versão 8.

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


SPDY e HTTP/2 Compatibilidade em março/2015

54

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




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

55


FTP

File Transfer Protocol

56




57

FTP: o protocolo de transferência de arquivos

q  FTP - File Transfer Protocol: definido pelo [RFC 959] q  Transferir arquivo de / para hospedeiro 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.

58

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.

59


FTP Active Open (default)

60

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

“servidor” para o servidor.




FTP Active Open e firewall

61


FTP Passive Open

62

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

63

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

64




Correio Eletrônico

SMTP e outros protocolos de aplicação

65


66

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.

•  É o mais usado.

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

67

MUA


Correio Eletrônico: servidores Servidores de correio q  Fila de mensagens:

•  Contém mensagens de saída (a serem enviadas).

q  Caixa de correio: •  Contém mensagens de chegada (ainda não lidas) pelo usuário.

q  Protocolo SMTP •  Entre servidores para transferir mensagens de correio.

•  Cliente: máquina servidor de correio que envia. •  “Servidor”: servidor de correio que recebe.

68




69

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.


70

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




71

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

q  Pesquisar a respeito das mensagens de protocolo mais usadas no SMTP.


72

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




IMAP x POP3

73 Veja: http://www.vanemery.com/Protocols/SMTP/smtp.html


Como funciona tudo junto:

74

MAA

MSA - Message Submission Agent




DNS

Domain Name System

75


76

DNS: Domain Name System (1) Pessoas:

•  Possuem muitos identificadores: •  CPF, No. de Passaporte, RG, NOME, etc...

Dispositivos na Internet: •  Dispositivos Internet (hosts, roteadores, etc...) usam números. •  Endereço IP (32 bits): usado para endereçar datagramas. •  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?




77

DNS: Domain Name System (2)

q  (1) Uma base de dados distribuída implementada em uma hierarquia de muitos servidores de nomes (nameservers).

q  (2) Um protocolo da camada de aplicação que permite que os hosts e os servidores de nomes se comuniquem, de modo a fornecer o serviço de tradução → “resolver”.

Resolver nome = traduzir nome em endereço IP.

q  Os servidores de nomes (nameservers) são frequentemente máquinas Unix que rodam o software Berkeley Internet Name Domain (Bind).

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


78

Servidores de nomes DNS

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

Servidor de nomes local: •  Cada provedor, empresa ou

instituição tem servidor de nomes local (default)

•  Pedido DNS de um host vai primeiro ao servidor de nomes local.

Servidor de nomes autoritativo: •  Para o host: guarda nome,

endereço IP dele. •  Pode realizar tradução nome/

endereço para este nome.

Por quê não centralizar o DNS?

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.




Consulta e resolução de DNS (1)

79



80





81


82

DNS: uso de cache, atualização de dados q  Uma vez um servidor qualquer aprende um

mapeamento, ele o coloca numa cache local. •  Futuras consultas são resolvidas usando

dados da cache. •  Entradas no cache são sujeitas a temporização

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




DNS: Servidores raiz (root servers) q  Procurado por servidor local que não consegue

resolver. q  Servidor raiz (root server):

•  Procura servidor autoritativo. •  Obtém tradução. •  Devolve mapeamento ao servidor local.

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.

83


DNS Root servers de A até M

84




DNS Root servers de A até M

85


DNS Root servers & mirrors

86

http://root-servers.org/

Exercício: o que é o AS112 ?




87

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

q  Tipo=NS •  nome é domínio (p.ex.

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

servidor de nomes autoritativo para este domínio

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

q  Tipo=A •  nome é nome de hospedeiro •  valor é endereço IP

q  Tipo=CNAME •  nome é nome alternativo

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

•  valor é o nome canônico

q  Tipo=MX •  nome é domínio •  valor é nome do

servidor de correio para este domínio.


88

Cabeçalho de mensagem q  identification: ID de 16 bit para pedido,

resposta ao pedido usa mesmo ID q  flags:

•  pedido ou resposta •  recursão desejada •  recursão permitida •  resposta é autoritativa

•  Protocolo DNS: •  Mensagens pedido e

resposta, ambas com o mesmo formato de mensagem

http://www.troyjessup.com/headers/




89

DNS: protocolo e mensagens

campos nome, tipo num pedido

RRs em resposta ao pedido

registros para servidores

autoritativos

info adicional “relevante” que pode ser usada


Compartilhamento de arquivos

Aplicações P2P

90




Modelo Cliente / Servidor q Modelo mais usado na Internet.

•  Dependente de servidores bem configurados em com informação acessível.

q Não explora o potencial de computação distribuída proveniente da Rede. •  A existência de um ou milhares de computadores é

indiferente na interação de um usuário típico com a rede.

q PCs clientes com capacidade considerável ficam “escondidos”, formando um exército com alto potencial.


Compartilhamento de arquivos 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 outros peers que possuem uma cópia da

música. • Alice escolhe um dos pares: Bob. • O arquivo é copiado do PC 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 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. •  Pode usar o DNS para balancear carga entre servidores. •  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  Quantidade exponencial de adeptos.


Características P2P (2) q  Cada participante age como cliente e

servidor ao mesmo tempo (servent). q  Cada cliente “paga” a sua participação

fornecendo acesso a (alguns de) seus recursos.




Características P2P (3) q Sem coordenação central. q Sem banco de dados central. q Sem local único de falha ou gargalo. q Nenhum ponto (peer) tem visão global do sistema. q Comportamento global definido por interações

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


Principais vantagens q  Escalabilidade

•  Não há gargalo para crescimento. q  Robustez

•  Não há ponto de falha único. q  Flexibilidade

•  Auto-configuração / configuração dinâmica.




Escalabilidade de arquiteturas P2P q  Considere: us: taxa de upload do servidor. ui: taxa de upload do nó i. di: taxa de download do nó i. F: tamanho do arquivo em bits. N: número de pares que querem uma cópia do arquivo.


Cliente servidor q  Transmitir uma cópia do arquivo para cada um dos N pares.

•  Ou seja, transmitir um total de NF 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:

102

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




P2P 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 é:

103

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 •  us= 10u •  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. q Tamanho típico de 256 Kbytes. q Enquanto faz o download de blocos também faz

o upload para outros pares. q Pode sair e voltar com apenas um subconjunto

de blocos.

105


BitTorrent- funcionamento

106




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

107


Tracker e pares vizinhos q Chamam-se pares vizinhos os pares com quem

se consegue estabelecer a 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.

110




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)

111


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

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

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

112




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.

113


Alguns termos de BitTorrent

114

•  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).




Distributed Hash Tables (DHTs)

•  Vamos 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.

•  No sistema P2P, cada par só manterá um pequeno subconjunto da totalidade (chave, valor).

•  Permitiremos que qualquer par consulte o banco de dados distribuído com uma chave em particular.


Distributed Hash Tables (DHTs) •  O banco de dados distribuído, então, localizará

os pares que possuem os pares (chave, valor) correspondentes e retornará os pares chave‑valor ao consultante.

•  Qualquer par também poderá inserir novos pares chave-valor no banco de dados.

•  Esse banco de dados distribuído é considerado como uma tabela hash distribuída •  (DHT — Distributed Hash Table).




Hash Convencional e DHT

117

•  Cada posição de uma tabela hash normal é agora um peer que é o responsável por ter o objeto.

•  Procura na estrutura por uma chave "k", dado uma função de hash H, então H(k) deve retornar o mesmo objeto, ou seja, deve retornar X.


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




Armazenamento de chave: q  O primeiro nó a formar o anel é o Peer 1. q  O Peer 1 define o maior valor da chave que ele irá

armazenar. §  Exemplo: o Peer 1 define-se responsável pelas chaves de 1 a

49.

q  Cada chave é armazenada no nó cuja posição é: •  O menor valor, tal que este nó seja maior ou igual a chave

E •  Maior do que o maior item de dados do nó anterior.

q  Quando o maior valor do nó for atingido, o ciclo recomeça (aritmética de módulo N).

Para aritmética modular veja http://en.wikipedia.org/wiki/Modular_arithmetic

119


120

q  Exemplo: o Peer1 tem a responsabilidade do intervalo compreendido desde a chave 1 até a chave 49.

q  Peer100 tem de 50 a 99 e Peer 150 de 100 a 150.

Créditos / Figura: Prof. Vladimir M. Rocha http://www.ime.usp.br/~vmoreira/DHT.html




DHT: Funcionamento (1) q Cada nó deve “conhecer” pelo menos uma

cópia do(s) objeto(s) que foi colocado na sua faixa de hash. •  Nós armazenam os objetos que são

mapeados para a sua faixa de hash. •  Nós armazenam apontadores para os objetos

na sua faixa. •  Nós armazenam apontadores para seus

próximos nós. (sucessores – exercício: ver livro).


DHT: Funcionamento (2)

q Para cada objeto, o nó cuja faixa cobre o objeto deve ser alcançável por um caminho “curto”. •  A partir de qualquer outro nó.




Entrada na DHT (1)

123

•  Quando um peer entra ou sai da DHT: •  Protocolos atualizam as chaves e as

responsabilidades dos peers.

1.  "Hashear" o IP em uma id que esteja no intervalo das chaves.

(ou algum identificador próprio do Peer). Como exemplo no desenho a seguir: entrada na DHT do Peer 180.


Entrada na DHT (2)

124

2. Atualizar as responsabilidades. •  Dentro do anel formado no DHT, o Peer 180 ficará

entre o Peer 150 e o Peer 200. •  Peer 180 passa a ser responsável pelas chaves 151

até 179. •  Peer 200 passa a ter as chaves do 180 até 200.

•  As chaves são redistribuídas pelos nós.. 3.  Atualizar os links:

•  Para que os outros Peers conheçam o novo membro. •  Forma de fazer isso depende da implementação.




125

Entrada do peer 180

•  Peer 180 terá as chaves do 151 até 179 •  Peer 200 passa a ter as chaves do 180 até 200


Busca de chave

126

q Cada nó tem uma “finger table”.

§  Contendo os nós que armazenam as chaves N+1, N+2, N+4, N+8, . . . N + 2n

§  N é a própria chave do nó.

q Para encontrar uma chave:

q Procura na finger table o nó que é o mais próximo possível da chave procurada, sem ultrapassa-la, e envia a pergunta para aquele nó.

q Este Nó repete o processo, até chegar ao nó que mantém a chave procurada.

q A resposta é enviada para o nó que iniciou a procura.




Busca da chave 54 a partir do nó 8

127

Lembrar que cada item de dados é armazenado no nó cuja posição é o menor valor, tal que este nó seja maior ou igual ao item de dados chave

Figura fonte: http://www.cs.rit.edu/~ark/fall2011/730/module04/notes.shtml


Redes Overlay

Rede Overlay

Rede Física

enlace físico

enlace virtual




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

129


Algumas aplicações usando DHT

130

•  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




131

Programação com sockets

Como funcionam as aplicações cliente/servidor


132

Programação com sockets

API Sockets q  Surgiu em BSD4.1 UNIX, 1981 q  Explicitamente criados, usados

e liberados por aplicações. q  Paradigma cliente/servidor q  Dois tipos de serviço de

transporte via API Sockets •  Datagrama não confiável •  Fluxo de bytes, confiável

Uma interface (uma “porta”), local ao hospedeiro, criada

por e pertencente à aplicação, e controlado pelo SO, através

da qual um processo de aplicação pode tanto enviar

como receber mensagens de/para outro processo de

aplicação (remoto ou local)

socket

Meta: aprender construir aplicação cliente/servidor que se comunica usando sockets.




133

Programação com sockets usando TCP

Socket: 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 com buffers, variáveis

socket

controlado pelo programador de

aplicação controlado

pelo sistema operacional

estação ou servidor

processo

TCP com buffers, variáveis

socket

controlado pelo programador de aplicação

controlado pelo sistema operacional

estação ou servidor

internet


134

Cliente deve contactar servidor: q  Processo servidor deve antes

estar em execução q  Servidor deve antes ter criado

socket (porta) que aguarda contato do cliente

Cliente contacta servidor por: q  Criar socket TCP local ao

cliente q  Especificar endereço IP,

número de porta do processo servidor

q  Quando cliente cria socket: TCP do cliente estabelece conexão ao servidor TCP

q  Quando contactado pelo cliente, servidor TCP cria socket novo processo servidor poder se comunicar com o cliente. •  Permite que o servidor

converse com múltiplos clientes.

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

(“tubo”) entre cliente e servidor

ponto de vista da aplicação





135


Exemplo de aplicaçao cliente-servidor:

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

q  Servidor lê linha do socket. q  Servidor converte linha para

letra maiúscula, e devolve para o cliente.

q  Cliente lê linha modificado do socket (fluxo doServidor), imprime-a

Input stream: seqüência de bytes para dentro do processo.

Output stream: seqüência de bytes

para fora do processo.

socket do cliente

doUsuário

pparaServidor

doServidor


136

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.




137

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

Documents

Capítulo 2 Camada de Aplicaçãoadriano/aulas/redes/2016/Redes-I/2... · UNESP - IBILCE - SJRP - Curso de Redes de Computadores Capítulo 2 Prof. Dr. Adriano Mauro Cansian 3 unesp