Redes de Computadores II

Robson Siscoutto

[email protected]

Camada de Aplicação

1
 Camada de Aplicação

Nossos objetivos: Outros objetivos do capítulo

◼ conceitual, aspectos de ◼ protocolos específicos:
implementação de protocolos ◼ http
de aplicação para redes ◼ ftp
◼ paradigma cliente-servidor ◼ smtp
◼ modelos de serviço ◼ pop
◼ dns

◼ aprenda sobre protocolos ◼ programação de aplicações de rede

◼ socket API
examinando algumas
aplicações populares
 Aplicações e Protocolo de Aplicação

Aplicações de rede: processos distribuídos em comunicação

◼ rodam nos computadores usuários da rede como aplicação
transporte
programas de usuário rede
enlace
física
◼ trocam mensagens para realização da aplicação
◼ e.x., email, ftp, Web

Protocolos de aplicação
◼ fazem parte das aplicações
◼ HTTP, SMTP, POP3, …
aplicação
◼ definem mensagens trocadas e as ações tomadas aplicação
transporte
transporte
rede
rede
◼ usam serviços de comunicação das camadas enlace
enlace
física
física
inferiores
 Aplicações de Rede
Processo: programa ◼ agente usuário: software que
interfaceia com o usuário de um lado e
executando num host.
com a rede de outro.
◼ implementa protocolo da camada de
◼ dentro do mesmo host: aplicação
interprocess communication
◼ Web: browser
(definido pelo OS).
◼ Netscape, IE, ….
◼ E-mail: leitor de correio
◼ processos executando em ◼ MSOutlook, …
diferentes hosts se
◼ streaming audio/video: media player
comunicam com um
protocolo da camada de
aplicação
 Paradigma Cliente-Servidor
Aplicações de rede típicas têm duas
partes: cliente and servidor aplicação
transporte
rede
enlace
Cliente: física

• inicia comunicação com o servidor pedido

(“fala primeiro”)
• tipicamente solicita serviços do
servidor, resposta
• Web: cliente implementado no browser;
e-mail: leitor de correio
aplicação
transporte
Servidor: rede
enlace
• fornece os serviços solicitados ao cliente física

• e.x., Web server envia a página Web solicitada,

servidor de e-mail envia as mensagens, etc.
 Interfaces de Programação

API: application programming interface Q: Como um processo “identifica” o

outro processo com o qual ele
◼ define a interface entre a camada de
quer se comunicar?
aplicação e de transporte
◼ IP address do computador no
qual o processo remoto executa
◼ socket: Internet API
◼ dois processos se comunicam enviando
◼ “port number” - permite ao
dados para o socket e lendo dados de computador receptor determinar
dentro do socket o processo local para o qual a
mensagem deve ser entregue.
 Serviços de Transporte
Temporização
◼ algumas aplicações (e.x., telefonia Internet,
Perda de dados
jogos interativos) exigem baixos atrasos
◼ algumas aplicações (e.x., aúdio) podem
para operarem
tolerar alguma perda
◼ Aplicações interativas em tempo real:
◼ outras aplicações (e.x., transferência de telefonia na Internet, ambientes virtuais,
arquivos, telnet) exigem transferência de teleconferencia, jogos multiusuário, …
dados 100% confiável

Largura de Banda
• algumas aplicações (e.x., multimedia) exigem uma banda mínima para serem utilizáveis
– Voz: 32Kbps
• outras aplicações (“aplicações elasticas”) melhoram quando a banda disponível aumenta
– Coreio eletronico, transferencia de aquivos, acesso remoto e transferencias Web, ….
 Requisitos de Transporte de Aplicações Comuns

Applicação Perdas Banda Sensível ao Atraso

file transfer sem perdas elástica não

e-mail sem perdas elástica não
Web documents tolerante elástica não
real-time audio/video tolerante aúdio: 5Kb-1Mb sim, 100’s msec
vídeo:10Kb-5Mb
stored audio/video tolerante igual à anterior sim, segundos
jogos interativos tolerante Kbps sim, 100’s msec
e-business sem perda elástica sim
 Serviços de Transporte da Internet
serviço TCP: serviço UDP:
◼ transferência de dados não
◼ orientado á conexão: conexão requerida entre
confiável entre os processos
cliente e servidor transmissor e receptor
◼ transporte confiável dados perdidos na
transmissão são recuperados ◼ não oferece: estabelecimento de
conexão, confiabilidade, controle
◼ controle de fluxo: compatibilização de velocidade
de fluxo e de congestionamento,
entre o transmissor e o receptor garantia de temporização e de
◼ controle de congestionamento : protege a rede banda mínima.
do excesso de tráfego

◼ não oferece: garantias de temporização; de

banda mínima; taxa de transmissão minima;
 Aplicações e Protocolos de Transporte da Internet

Protocolo de Protocolo de
Aplicação Aplicação Transporte

e-mail smtp [RFC 821] TCP

acesso de terminais remotos telnet [RFC 854] TCP
Web http [RFC 2068] TCP
transferência de arquivos ftp [RFC 959] TCP
streaming multimedia RTP ou proprietario TCP ou UDP
(e.g. RealNetworks)
servidor de arquivos remoto NSF TCP ou UDP
telefonia Internet RTP ou proprietary tipicamente UDP
(e.g., Vocaltec)
 Protocolo HTTP
http: hypertext transfer protocol
◼ protocolo da camada de aplicação da Web

◼ modelo cliente/servidor PC rodando

Explorer
◼ cliente: browser que solicita, recebe e
apresenta objetos da Web
Servidor
◼ server: envia objetos em resposta a rodando
NCSA Web
pedidos
server
◼ http1.0: RFC 1945
Mac rodando
◼ http1.1: RFC 2068 Navigator
 Protocolo HTTP

http: protocolo de transporte TCP: http é “stateless” Sem Estado

◼ o servidor não mantém informação
◼ cliente inicia conexão TCP (cria socket) sobre os pedidos passados pelos
clientes;
para o servidor na porta 80
◼ Reenvia novamente sempre que
◼ servidor aceita uma conexão TCP do solicitado;

cliente

◼ mensagens http (mensagens do Protocolos que mantém informações de

estado são complexos!
protocolo de camada de aplicação) são
• necessidade de organizar informações
trocadas entre o browser (cliente http) passadas
e o servidor Web (servidor http) • se ocorrer um crash as informações
podem ser perdidas ou gerar
◼ A conexão TCP é fechada inconsistências entre o cliente e o
servidor
 Exemplo de Operação
Usuário entra com a URL: (contém referência a
www.someSchool.edu/someDepartment/home.index 10 imagens jpeg)

1a. cliente http inicia conexão TCP

ao servidor http (processo) em 1b. servidor http no host
www.someSchool.edu. Porta 80 www.someSchool.edu esperando
é a default para o servidor http pela conexão TCP na porta 80.
. “aceita” conexão, notificando o cliente

2. cliente http client envia http request

message (contendo a URL) para o
socket da conexão TCP 3. servidor http recebe mensagem de
pedido, forma response message
contendo o objeto solicitado
(someDepartment/home.index),
envia mensagem para o socket

tempo
 Exemplo (cont.)
4. servidor http fecha conexão TCP.

5. cliente http recebe mensagem

de resposta contendo o arquivo
html, apresenta o conteúdo
html. Analisando o arquivo
tempo html encontra 10 objetos jpeg
referenciados

6. Passos 1-5 são repetidos para cada um

dos 10 objetos jpeg.
Conexões persistentes e não-persistentes
Não-persistente
◼ http/1.0: servidor analisa pedido, envia
resposta e fecha a conexão TCP
◼ 2*RTTs para obter um objeto
◼ 1 para inicial Conexão TCP – 3way
◼ 1 para solicitação e
transferência/recebimento do
objeto (primeiros bytes)
◼ + o tempo de transferir o arquivo
◼ cada transferência sofre por causa do
mecanismo de slow-start do TCP
◼ Transferencia lenta no inicio da
transmissão
◼ muitos browser abrem várias conexões
paralelas
◼ RTT – round-tripe time: tempo de
viagem de ida e volta
Conexões persistentes e não-persistentes
Conexões persistentes e não-persistentes

Persistente
◼ modo default para htp/1.1

◼ na mesma conexão TCP são trazidos vários objetos (pipeline)

◼ o cliente envia pedido para todos os objetos referenciados tão logo ele
recebe a página HTML básica

◼ Poucos RTTs, menos slow start.

◼ Pode ser necessário apenas um RTT para todos os objetos referenciados mais o tempo para
transmitir os arquivos

◼ Os objetos são solicitados em sequência, sem esperar a resposta à solicitação anterior

Conexões persistentes e não-persistentes
Conexões persistentes e não-persistentes
 Formato das Mensagens HTTP
◼ dois tipos de mensagens HTTP: request, response
◼ http request message:
◼ ASCII (formato legível para humanos)
linha de pedido/Requisição
(comandos GET, POST, HEAD;
GET /somedir/page.html HTTP/1.0
URL e versão do HTTP)
Host: www.someschool.edu
linhas de User-agent: Mozilla/4.0
cabeçalho Accept: text/html, image/gif,image/jpeg
Accept-language:fr
Carriage return,
line feed (extra carriage return, line feed)
(indica fim da mensagem)
 Formato das Mensagens HTTP
◼ dois tipos de mensagens HTTP: request, response
◼ http request message:
◼ ASCII (formato legível para humanos)

Mesmo usando a GET /somedir/page.html HTTP/1.1

versão 1.1, a Host: www.someschool.edu
conexão pode ser User-agent: Mozilla/4.0
fechada por Connection: close
objeto usando a Accept-language:fr
opção
Connection: carriage return (CR),
close line feed(LF) adicionais)
Space sp: significa que a linha ainda
continua. Em oposição ao cr/lf. HTTP request: formato geral
Linhas
Requisição

Linhas
cabeçalho

Linha em branco cr=carriage return, if=ine feed

Corpo da Entidade

◼ Linhas de requisição: Método: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT
◼ HEAD: Usado para depuração de servidores HTTP;
◼ POST – Páginas Web frequentemente contêm um formulário de entrada – Conteúdo é enviado para o servidor no corpo da mensagem - Alternativa: Campos do formulário no URL – Usa
o método GET – Conteúdo é enviado para o servidor no campo URL

◼ Linhas cabeçalho: connect, close, User-Agent (tipo de browser),

 formatos HTTP: response
linha de status (protocol/Ver CódigoSstatus FraseSstatus)

HTTP/1.0 200 OK
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
linhas de cabeçalho Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html

Corpo da entidade data data data data data ...

(dados, p.ex., arquivo
html solicitado)
formatos HTTP: response

200 OK
◼ request succeeded, requested object later in
this message
301 Moved Permanently
◼ requested object moved, new location
specified later in this message (Location:)
400 Bad Request
◼ request message not understood by server
404 Not Found
◼ requested document not found on this server
505 HTTP Version Not Supported
Exemplo
 HTTP/2
◼ HTTP/1.0 - Uma requisição por conexão TCP
◼ HTTP/1.1 - Sequência de requisições por conexão
◼ Melhora em relação ao 1.0, mas ainda pode ter problemas de bloqueio na
cabeceira da fila (HOL - head-of-line blocking)

Clientes que precisam fazer muitas o O bloqueio HOL é um bloqueio que ocorre na porta de entrada.
Este bloqueio ocorre quando dois ou mais pacotes são destinados
requisições acabam usando múltiplas a uma mesma porta de saída mais alta. Se o pacote1 de uma porta

conexões com o servidor para

de entrada mais alta for o escolhido a ser enviado primeiro, o
outro pacote2 deverá esperar. O problema ocorre quando existem
conseguir paralelismo e, outros pacotes3 entre eles a serem enviados para outras portas de
saídas abaixo da que os pacotes 1 e 2 desejam. Estes também
consequentemente, redução do atraso deverão ser bloqueados. Este bloqueio é chamado de HOL.
o Em um comutador com fila de entrada - um pacote que está nessa
fila deve esperar pela transferência através do elemento de
comutação (mesmo que sua porta de saída esteja livre) porque ele
está bloqueado por outro pacote na cabeça da fila.
 HTTP/2
◼ Além disso...
◼ Cabeçalho HTTP é verboso
◼ Janela de congestionamento do TCP enche rapidamente
◼ Latência aumenta rapidamente com múltiplas requisições

◼ HTTP/2
◼ Permite a intercalação de requisições e respostas na mesma
conexão
◼ Usa codificação do cabeçalho HTTP
HTTP/2 se torna mais amigável à rede
já que um número menor de conexões
TCP é necessário
 Cookies – RFC 2109
◼ Razão: obter informações do usuário
◼ Gerados e lembrados pelo servidor, cliente servidor
usados mais tarde para: usual http request msg ação
◼ autenticação usual http response +
específica
◼ lembrar preferencias dos usuários ou Set-cookie: # do cookie
prévias escolhas
◼ Uma maneira de guardar estados
usual http request msg
cookie: # ação
específica
◼ servidor envia “cookie” ao cliente na usual http response msg do cookie
resposta HTTP
Set-cookie: 1678453
usual http request msg
ação
cookie: #
específica
◼ cliente apresenta o cookie em pedidos usual http response msg do cookie
posteriores
cookie: 1678453
 Cookies – RFC 2109
◼ Quatro componentes principais:
◼ Linha de cabeçalho do cookie na mensagem de resposta HTTP
◼ Linha de cabeçalho do cookie na mensagem de pedido HTTP
◼ Arquivo do cookie mantido na estação do usuário e gerenciado pelo navegador do usuário
◼ Banco de Dados de retaguarda no sítio Web

◼ Arquivo cookie – Arquivo pequeno (~4kB) de strings

Conditional GET: armazenando no cliente
servidor
◼ Razão: não enviar objeto cliente
se a versão que o cliente http request msg
já possui está atualizada. If-modified-since:
objeto
<date>
◼ cliente: specifica data da não
versão armazenada no http response modificado
pedido HTTP HTTP/1.0
304 Not Modified
If-modified-since:
<date>
◼ servidor: resposta não http request msg
contém objeto se a cópia é If-modified-since:
<date> objeto
atualizada: modificado
HTTP/1.0 304 Not http response
Modified HTTP/1.1 200 OK
<data>
 Web Caches (proxy server)
Objetivo: atender o cliente sem envolver o servidor Web
originador da informação
servidor
original

◼ usuário configura o browser: Proxy

acesso Web é feito através server
de um proxy cliente

◼ cliente envia todos os

pedidos http para o web
cache
◼ se o objecto existe no web
cache: web cache returna o
objecto cliente
servidor
◼ ou o web cache solicita original
objecto do servidor original,
então envia o objeto ao
cliente.
 Porque Web Caching?
servidores
originais
Internet
◼ armazenamento está “perto” pública
do cliente (ex., na mesma rede)
◼ menor tempo de resposta
◼ reduz o tráfego para servidor enlace de acesse
1.5 Mbps
distante
rede
◼ links externos podem ser caros e institucional
10 Mbps LAN
facilmente congestionáveis

cache
institucional
 Protocolo HTTP

◼ HTTP ( Hyper Text Transfer Protocol )

◼ Implementa autenticação básica -
entre servidor Web para que um cliente Web;
◼ cliente Web recebe um nome de usuário e senha do navegador da
Web ou de usuário do aplicativo Web
◼ encaminha o nome de usuário e senha para o servidor Web
◼ codifica a senha usando o algoritmo de base64 , o que não é seguro

◼ Confidencialidade na transmissão....????? Não

existe esta confidencialidade pois os dados são
transmitidos em formato texto, apesar de algumas
codificações não é garantida tal
confidencialidade...
 Protocolo HTTPS

httpS - Hyper Text Transfer Protocol Secure (portas 443 ou 8443)

◼ protocolo de transferência de hipertexto seguro) também chamado de HTTP over
Transport Layer Security - TLS)
◼ baseado em comunicação segura através de criptografia SSL/TLS bidirecional e a
utilização de certificados para autenticação (certificado de chave pública).
◼ Trata-se assim de um protocolo recomendado para sites que manipulem
informação confidencial;
◼ Utiliza criptografia Tradicional (Simétrica) e Moderna (Assimétrica – par de chaves
publicas e privadas)
 ftp: o protocolo de transferência de arquivos
RFC 959

FTP transferência de
FTP FTP
interface cliente arquivos
servidor
de usuário
user
at host sistema de sistema de
arquivos arquivos remoto
local

◼ transferência de arquivos de e para o computador remoto

◼ modelo cliente servidor
◼ cliente: lado que inicia a transferência (seja de ou para o lado remoto)
◼ servidor: host remoto
 ftp: controle separado, conexões de dados
◼ cliente ftp contata o servidor ftp na porta 21, especificando TCP
como protocolo de transporte TCP conexão de controle
porta 21

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

◼ controle: troca de comandos e respostas entre cliente e TCP conexão de dados
FTP porta 20 FTP
servidor. Porta 21. cliente servidor

“controle out of band”

◼ dados: dados do arquivo trocados com o servidor – Porta 20
◼ servidor ftp mantém o “estado”: diretório corrente,
autenticação anterior
◼ Modos de Transferência:
◼ ASCII
No FTP ativo (normal), o cliente abre uma conexão de controle na porta 21 para o servidor, e
◼ binário sempre que o cliente pede dados do servidor, o servidor abre uma sessão de TCP na porta 20.
No FTP passivo, o cliente abre as sessões de dados e usa um número de porta provida pelo
servidor.
 ftp comandos, respostas

Exemplos de comandos: Exemplos de códigos de retorno

◼ envie um texto ASCII sobre canal de ◼ código de status e frase (como no http)
controle
◼ 331 Username OK, password required
◼ USER username
◼ PASS password ◼ 125 data connection already open;
◼ LIST transfer starting
◼ retorna listagem do arquivo no diretório atual
◼ GET filename ◼ 425 Can’t open data connection
◼ recupera (obtém) o arquivo
◼ PUT filename ◼ 452 Error writing file
◼ armazena o arquivo no host remoto
 Correio Eletrônico fila de
saída de mensagem
caixa postal
Três componentes principais: agente
◼ agentes de usuário usuário

◼ servidores de correio servidor

agente
de correio
◼ simple mail transfer protocol: smtp usuário

SMTP mail
Agente de usuário server agente
◼ “leitor de correio” SMTP usuário

◼ composição, edição, leitura de mensagens

de correio SMTP
agente
servidor
◼ ex., Eudora, Outlook, elm, Netscape de correio
usuário
Messenger
◼ mensagens de entrada e de saída são agente
usuário
armazenadas no servidor
agente
usuário
 Correio eletrônico: servidores de correio
Servidores de Correio
agente
◼ caixa postal contém mensagens usuário
que chegaram (ainda não lidas) servidor
agente
para o usuário de correio
usuário
◼ fila de mensagens contém as
SMTP
mensagens de correio a serem mail
server agente
enviadas
usuário
◼ protocolo smtp permite aos SMTP
servidores de correio trocarem
SMTP
mensagens entre eles servidor
agente
usuário
◼ cliente: servidor de correio de correio

que envia
agente
◼ “servidor”: servidor de correio usuário
que recebe agente
usuário
 Correio Eletrônico: smtp [RFC 821]
◼ usa TCP para transferência confiável de mensagens de correio do cliente ao servidor, porta 25

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

◼ três fases de trasnferência

◼ handshaking (apresentação)

◼ transferência de mensagens

◼ fechamento

◼ interação comando/resposta

◼ comandos: texto ASCII

◼ resposta: código de status e frase

◼ mensagens devem ser formatadas em código ASCII de 7 bits

 Exemplo de interação SMTP
S: 220 hamburger.edu SMTP
C: HELO crepes.fr • Utiliza comandos para fazer a comunicação
S: 250 Hello crepes.fr, pleased to meet you entre servidores
– Exemplos
C: MAIL FROM: <[email protected]>
• HELO
S: 250 [email protected]... Sender ok • MAIL FROM
C: RCPT TO: <[email protected]> • RCPT TO
S: 250 [email protected] ... Recipient ok • DATA
• QUIT
C: DATA
• VRFY
S: 354 Enter mail, end with "." on a line by itself • Respostas do servidor são numéricas
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
 SMTP: palavras finais
◼ SMTP usas conexões persistentes Comparação com http:
◼ http: pull
◼ SMTP exige que as mensagens (cabeçalho e
corpo) estejam em ASCII de 7 bits ◼ email: push

◼ ambos usam comandos e

◼ algumas seqüências de caracteres não são respostas em ASCII, interação
permitidas nas mensagens (ex., comando / resposta e códigos de
CRLF.CRLF). Assim mensagens genéricas status
têm que ser codificadas (usualmente em
“base-64” ou “quoted printable”) ◼ http: cada objeto encapsulado na
sua própria mensagem de
resposta
◼ Servidor SMTP usa CRLF.CRLF para indicar
◼ smtp: múltiplos objetos são
o final da mensagem
enviados numa mensagem
multiparte
 Formato das Mensagens
smtp: protocolo para trocar
mensagens de e-mail header
linha
RFC 822: padrão para mensagens em branco
do tipo texto ASCII:
body
◼ linhas de cabeçalho, e.g.,
◼ To:
◼ From:
◼ Subject:
INCLUSÃO DE CHECKSUM NO CORPO DA MENSAGEM
◼ Received Para verificar a integridade de uma mensagem (incluindo qualquer
diferente dos comandos SMTP! anexos nele) a soma de verificação da mensagem deve ser
calculada e anexado ao início da mensagem. A mensagem então será
◼ corpo parecido com o seguinte:

◼ a “mensagem”, ASCII somente com <CHECKSUM TYPE=XX>checksum_string_aqui<CHECKSUM>

caracteres ........................................
.......[O CORPO DA MENSAGEM ESTÁ CONTIDO AQUI].
Formato das Mensagens: extensões multimedia

◼ MIME: multimedia mail extension, RFC 2045, 2056

◼ linhas adicionais no cabeçalho declaram o tipo de
conteúdo MIME
From: [email protected]
MIME versão To: [email protected]
Subject: Picture of yummy crepe.
método usado MIME-Version: 1.0
para codificar dados Content-Transfer-Encoding: base64
Content-Type: image/jpeg
multimedia data
tipo, subtipo, base64 encoded data .....
declaração de parâmetro .........................
......base64 encoded data
dados codificados
 Tipos MIME
Content-Type: type/subtype; parâmetros

Text Video
◼ exemplo de subtipos: plain, html ◼ exemplo de subtipos: mpeg,
quicktime

Image
◼ exemplo de subtipos: jpeg, gif Application
◼ outros dados que devem ser
Audio processados pelo leitor antes de
serem apresentados “visualmente”
◼ exemplo de subtipos: basic
(codificado 8-bit -law ), 32kadpcm ◼ exemplo de subtipos: msword,
octet-stream
(codificação 32 kbps)
Tipo Multiparte
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789

--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain

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

base64 encoded data .....

.........................
......base64 encoded data
--98766789--
Protocolos de acesso ao correio
SMTP SMTP POP3 or agente
agente
usuário IMAP usuário

servidor de servidor de
correio da origem correio do destino

◼ SMTP: entrega e armazena no servidor do destino

◼ Protocolo de acesso: recupera mensagens do servidor
◼ POP3: Post Office Protocol [RFC 1939]: porta 995
◼ autorização (agente <-->servidor) e download
◼ IMAP: Internet Mail Access Protocol [RFC 1730]: porta 993 (ssl) ou 143
◼ maiores recursos (mais complexo)
◼ manipulação de mensagens armazenadas no servidor
◼ HTTP: Hotmail , Yahoo! Mail, etc.
 protocolo POP3 S: +OK POP3 server ready
C: user alice
S: +OK
fase de autorização C: pass hungry
◼ comandos do cliente: S: +OK user successfully logged on
◼ user: declara nome do usuário
C: list
◼ pass: password S: 1 498
◼ respostas do servidor S: 2 912
S: .
◼ +OK
C: retr 1
◼ -ERR S: <message 1 contents>
S: .
fase de transação, cliente: C: dele 1
◼ list: lista mensagens e tamanhos C: retr 2
◼ retr: recupera mensagem pelo número S: <message 1 contents>
S: .
◼ dele: apaga
C: dele 2
◼ quit C: quit
S: +OK POP3 server signing off
 DNS: Domain Name System (Utiliza UDP e porta 53)

Pessoas: muitos identificadores: Domain Name System:

◼ RG, nome, passporte ◼ base de dados distribuída implementada numa

hierarquia de muitos servidores de nomes
Internet hosts, roteadores:
◼ protocolo de camada de aplicação host,
◼ endereços IP (32 bit) - usados para
roteadores se comunicam com servidores de
endereçar datagramas
nomes para resolver nomes (translação
◼ “nome”, ex., gaia.cs.umass.edu - usados
nome/endereço)
por humanos
◼ nota: função interna da Internet,
Q: relacionar nomes com endereços IP? implementeda como protocolo da camada de
aplicação

◼ complexidade na “borda” da rede

 DNS: Domain Name System (Utiliza UDP e porta 53)

Porque não centralizar o

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

Locais
Não cresce junto com a ou
rede! oficiais
 Servidores de Nomes DNS

◼ Servidores TLD (Top-level Domain)

◼ Controlados pelos registradores apontados pelo ICANN

◼ Responsáveis por:
◼ Domínios como com, org, net, edu, ...
◼ Todos os domínios de países como br, uk, fr, ca, jp

◼ Network Solutions manteve servidores para domínio .com

◼ Monopólio até 1999

◼ NIC.br (Registro.br) para domínio .br

◼ (NIC.br = Núcleo de Informação e Coordenação do Ponto BR)
 Servidores de Nomes DNS
◼ nenhum servidor tem todos os mapeamentos de nomes para endereços IP

servidores de nomes locais ou servidor de nomes padrão:

◼ cada ISP ou empresa tem um servidor de nomes local (default)

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

◼ O servidor local é quem consulta os demais servidores da hierarquia

servidor de nomes autoritativo ou oficiais:

◼ para um computador: armazena o nome e o endereço IP daquele computador

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

◼ Podem ser mantidos pelas organizações ou pelo provedor de acesso

 DNS: Servidores de Nomes Raiz
◼ são contatados pelos servidores de nomes locais que não podem resolver um nome
◼ Controlados pelo ICANN (Internet Corporation for Assigned Names and Numbers)
◼ Ao receber uma consulta Procura o servidor responsável pelo mapeamento no nível imediatamente inferior
◼ servidores de nomes raiz:
◼ buscam servidores de nomes autoritativos se o mapeamento do nome não for conhecido
◼ conseguem o mapeamento
◼ returnam o mapeamento para o servidor de nomes local

a NSI Herndon, VA
c PSInet Herndon, VA k RIPE London
d U Maryland College Park, MD i NORDUnet Stockholm
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA
m WIDE Tokyo existem 13 servidores de nomes
e NASA Mt View, CA
f Internet Software C. Palo Alto,
raiz no mundo
CA

b USC-ISI Marina del Rey, CA

l ICANN Marina del Rey, CA
 DNS: exemplo simples servidor de nomes
raiz

2 4
host surf.eurecom.fr quer o 3
5
endereço IP de
gaia.cs.umass.edu

1. contata seu servidor DNS local,

dns.eurecom.fr servidor de nomes local servidor de nomes autoritativo
dns.eurecom.fr dns.umass.edu

2. dns.eurecom.fr contata o servidor de 1 6

nomes raiz se necessário

3. o servidor de nomes raiz contata o

computador solicitante
servidor de nomes autoritativo, surf.eurecom.fr
gaia.cs.umass.edu
dns.umass.edu, se necessário
 DNS: exemplo servidor de nomes
raiz

Servidor de nomes raiz: 2 6

7 3
◼ pode nãso conhecer o servidor de
nomes autoritativo para um certo
nome
servidor de nomes local servidor de nomes intermediário
dns.eurecom.fr dns.umass.edu
◼ pode conhecer: servidor de
4 5
1
nomes intermediário: aquele que 8

deve ser contactado para servidor de nomes autoritativo

dns.cs.umass.edu
encontrar o servidor de nomes computador solicitante
surf.eurecom.fr
autoritativo
gaia.cs.umass.edu
 DNS: consultas encadeadas servidor de nomes
raiz

consulta Recursiva: consulta

2
3 encadeada
◼ transfere a tarefa de resolução do
nome para o servidor de nomes 4
consultado
7
◼ Maior carga em servidores de maior
altura servidor de nomes local servidor de nomes intermediário
dns.eurecom.fr dns.umass.edu
consulta Encadeada ou Interativa: 5 6
1 8
◼ servidor contactado responde com o
nome de outro servidor de nomes
servidor de nomes autoritativo
para contato dns.cs.umass.edu
◼ “Eu não sei isto ,mas pergunte a este computador solicitante
surf.eurecom.fr
servidor”
◼ Adotado na Internet gaia.cs.umass.edu
 DNS: armazenando e atualizando registros

◼ Uma vez que um servidor de nomes apreende um mapeamento, ele

armazena o mapeamento num registro to tipo cache
◼ registro do cache tornam-se obsoletos (desapareçem) depois de um
certo tempo → Geralmente, 2 dias

◼ Endereços dos servidores TLD

◼ Armazenados no cache dos servidores de nomes locais
◼ Servidores raiz acabam não sendo visitados com muita frequência

◼ Mecanismos de atualização e notificação estão sendo projetados pelo IETF

◼ RFC 2136 - http://www.ietf.org/html.charters/dnsind-charter.html
 Registros do DNS
DNS: base de dados distribuída que armazena registros de recursos (RR)
nome: Domínio ao qual o registro se aplica
formato dos RR: (name, value, type,ttl) TTL: Indicação da estabilidade do registro
classe: Indicação sobre o significado do
registro
• Type=A • Na maioria dos casos é IN de Internet
– name é o nome do computador tipo: Tipo do registro
– value é o endereço IP valor: Depende do tipo do registro

◼ Type=NS
◼ name é um domínio (ex. foo.com)
◼ value é o endereço IP do servidor
• Type=CNAME
de nomes autoritativo para este – name é um “apelido” para algum
domínio nome “canônico” (o nome real)
www.ibm.com é realmente
• Type=MX
servereast.backup2.ibm.com
– value é o nome do servidor de
correio associado com name – value é o nome canônico
 DNS: protocolo e mensagens
Protocolo DNS: mensagen de consulta e resposta , ambas
com o mesmo formato de mensagem

cabeçalho da msg
• identificação: número de 16 bit
para consulta, resposta usa o
mesmo número
• flags:
– consulta ou resposta
– recursão desejada
– recursão disponível
– resposta é autoritativa
DNS: protocolo e mensagens
 Programação de Sockets
Objetivo: aprender a construir aplicações cliente/servidor
que se comunicam usando sockets

Socket API
socket
◼ introduzida no BSD4.1 UNIX, 1981
◼ explicitamente criados, usados e liberados pelas
aplicações uma interface local, criada e possuída pelas
◼ paradigma cliente/servidor aplicações,
◼ dois tipos de serviço de transporte via socket API: controlada pelo OS (uma “porta”) na qual os
◼ datagrama não confiável (UDP) processo de aplicação podem tanto enviar
◼ confiável, orientado a cadeias de bytes (TCP) quanto receber mensagens de e para outro
processo de aplicação (local ou remoto)
 Programação de Sockets com TCP

Socket: uma porta entre o processo de aplicação e

o protocolo de transporte fim-a-fim (UDP or TCP)
serviço TCP: trnasferência confiável de bytes de
um processo para outro

controlado pelo
controlado pelo processo processo
criador da aplicação
criador da aplicação
socket socket
TCP com TCP com controlado pelo
controlado pelo
sistema buffers, buffers, sistema
internet variáveis
operacional variáveis operacional

host o host ou
servidor servidor
 Programação de Sockets com TCP
Cliente deve contactar o servidor ◼ Quando o cliente cria o socket:
◼ processo servidor já deve estar cliente TCP estabelece conexão
executando antes de ser com o TCP do servidor
contactado ◼ Quando contactado pelo cliente,
◼ servidor deve ter criado socket o TCP do servidor cria um novo
(porta) que aceita o contato do socket para o processo servidor
cliente comunicar-se com o cliente
◼ permite o servidor conversar
Cliente contata o servidor através
de: com múltiplos clientes
◼ criando um socket TCP local
ponto de vista da aplicação
◼ especificando endereço IP e
TCP fornece a transferência
número da porta do processo
confiável, em ordem de bytes
servidor
(“pipe”) entre o cliente e o
servidor
 Programação de Sockets com TCP
teclado monitor

Exemplo de aplicação cliente-

servidor:

inFromUser
◼ cliente lê linha da entrada padrão input
stream
do sistema (inFromUser stream) processo
Process stream de entrada:
, envia para o servidor via socket cliente seqüência de bytes
(outToServer stream) para dentro do processo
stream de saída:
◼ servidor lê linha do socket seqüência de bytes
◼ servidor converte linha para letras para fora do processo

inFromServer
maiúsculas e envia de volta ao

outToServer
output input
cliente stream stream

◼ cliente lê a linha modificada

TCP socket
através do (inFromServer clientSocket
cliente TCP
stream) socket

para rede da rede

 Interação Cliente/servidor: TCP
Servidor (executando em hostid) Cliente
cria socket,
port=x, para
solicitação entrante:
welcomeSocket =
ServerSocket()

TCP cria socket,

espera por pedido
de conexão entrante
estabel. de conexão conecta com hostid, port=x
connectionSocket = clientSocket =
welcomeSocket.accept() Socket()

envia pedido usando

lê pedido de clientSocket
connectionSocket

escreve resposta para

connectionSocket lê resposta de
clientSocket
fecha
connectionSocket fecha
clientSocket
 Exemplo: cliente Java (TCP)
import java.io.*;
import java.net.*;
class TCPClient {

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

{
String sentence;
String modifiedSentence;
Cria
stream de entrada BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Cria
socket cliente, Socket clientSocket = new Socket("hostname", 6789);
conecta ao servidor
Cria DataOutputStream outToServer =
stream de saída new DataOutputStream(clientSocket.getOutputStream());
ligado ao socket
 Exemplo: cliente Java (TCP), cont.

Cria BufferedReader inFromServer =

stream de entrada new BufferedReader(new
ligado ao socket InputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();

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

para o servidor
modifiedSentence = inFromServer.readLine();
Lê linha
do servidor
System.out.println("FROM SERVER: " + modifiedSentence);

clientSocket.close();

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

class TCPServer {

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

{
String clientSentence;
Cria String capitalizedSentence;
socket de aceitação
ServerSocket welcomeSocket = new ServerSocket(6789);
na porta 6789
while(true) {
Espera, no socket
de aceitação por Socket connectionSocket = welcomeSocket.accept();
contato do cliente
BufferedReader inFromClient =
Cria stream de new BufferedReader(new
entrada, ligado InputStreamReader(connectionSocket.getInputStream()));
ao socket
 Exemplo: servidor Java (cont)

Cria stream de
saída, ligado ao DataOutputStream outToClient =
socket new DataOutputStream(connectionSocket.getOutputStream());
Lê linha do
socket clientSentence = inFromClient.readLine();

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

Escreve linha
outToClient.writeBytes(capitalizedSentence);
para o socket
}
}
} Fim do while loop,
retorne e espere por
outra conexão do cliente
 Programaçaõ de Sockets com UDP
UDP: não há conexão entre o cliente e
o servidor
◼ não existe apresentação
◼ transmissor envia explicitamente ponto de vista da aplicação
endereço IP e porta de destino em UDP fornece a transferência
cada mensagem não confiável de grupos de bytes
(“datagramas”) entre o cliente e o
◼ servidor deve extrair o endereço IP servidor
e porta do transmissor de cada
datagrama recebido
◼ UDP: dados transmitidos podem ser
recebidos foram de ordem ou
perdidos
 Interação Cliente/servidor: UDP
Servidor (executando hostid) Cliente

cria socket, cria socket,

port=x, para clientSocket =
solicitação entrante: DatagramSocket()
serverSocket =
DatagramSocket()
Cria, endereço (hostid, port=x,
envia datagrama de pedido
usando clientSocket
lê pedido de:
serverSocket

escreve resposta para

serverSocket
especificando endereço lê resposta de
do host cliente e clientSocket
número da porta fecha
clientSocket
Exemplo: cliente Java (UDP)
teclado monitor

inFromUser
stream
de entrada

processo
Process Entrada: recebe
cliente
pacote (TCP recebe
Saída: envia pacote “byte stream”)
(TCP envia “byte

receivePacket
sendPacket
stream”) pacote pacote
UDP UDP

socket UDP
clientSocket
cliente UDP
socket

para rede da rede

 Exemplo: cliente Java (UDP)
import java.io.*;
import java.net.*;

class UDPClient {
public static void main(String args[]) throws Exception
{
Cria
stream de entrada BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Cria
socket cliente DatagramSocket clientSocket = new DatagramSocket();
Translada
nome do host para InetAddress IPAddress = InetAddress.getByName("hostname");
endereço IP
usando DNS byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];

String sentence = inFromUser.readLine();

sendData = sentence.getBytes();
 Exemplo: cliente Java (UDP), cont.
Cria datagrama com
dados a enviar, DatagramPacket sendPacket =
tamanho, endereço IP new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
porta
Envia datagrama clientSocket.send(sendPacket);
para servidor
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
Lê datagrama clientSocket.receive(receivePacket);
do servidor
String modifiedSentence =
new String(receivePacket.getData());

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

clientSocket.close();
}
}
 Exemplo: servidor Java (UDP)
import java.io.*;
import java.net.*;

class UDPServer {
public static void main(String args[]) throws Exception
Cria {
socket datagrama
DatagramSocket serverSocket = new DatagramSocket(9876);
na porta 9876
byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];

while(true)
{
Cria espaço para
DatagramPacket receivePacket =
datagramas recebidos
new DatagramPacket(receiveData, receiveData.length);
Recebe serverSocket.receive(receivePacket);
datagrama
 Exemplo: servidor Java, (cont.)
String sentence = new String(receivePacket.getData());
Obtém endereço IP
InetAddress IPAddress = receivePacket.getAddress();
e número da porta
do transmissor
int port = receivePacket.getPort();

String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes();
Cria datagrama
DatagramPacket sendPacket =
para enviar ao cliente
new DatagramPacket(sendData, sendData.length, IPAddress,
port);
Escreve o
datagrama para serverSocket.send(sendPacket);
dentro do socket }
}
} Termina o while loop,
retorna e espera por
outro datagrama
 Criação de Java threads

◼ Criação pelo método extends Thread

77
 Criação de Java threads

◼ Criação pelo método implements Runnable

78
 Programação de Sockets: referências

◼ PROGRAMANDO UM PROTOCOLO UTILIZANDO SOCKETS EM C

◼ https://blog.pantuza.com/artigos/programando-um-protocolo-utilizando-
sockets
◼ https://pessoal.dainf.ct.utfpr.edu.br/jeansimao/Fundamentos2/APITCPIP/Tu
torial%20-%20Programacao%20C++%20TCP-IP%20-
%20Marcelo%20Hiroshi%20Sugita.pdf

◼ Tutoriais sobre Java:

◼ “Socket Programming in Java: a tutorial,”
https://www.javatpoint.com/socket-programming
 Bibliografia
◼ James F. Kurose e Keith W. Ross
◼ Redes de Computadores e a Internet:

◼ Andrew S. Tanenbaum
◼ Redes de Computadores

◼ SOUSA, Lindeberg Barros de

◼ Redes de computadores: dados, voz e imagem

◼ Comer, Douglas E.,

◼ Interligação de Redes Com Tcp/ip
80