Prof V Vargas, IST
Aplicações
03/11/11, Pg 1/11
Aplicações
{Applications.doc}
1. [07T1,10E2.4] Diga quais os métodos que conhece para delimitação de PDUs (Protocol Data Units) ao nível
dos protocolos da camada de aplicação na Internet. Para cada método, apresente um exemplo de um protocolo
de aplicação conhecido onde esse método seja aplicado.
R: Delimitação de PDUs significa precisar onde começam e onde acabam os campos que compõem uma PDU. Eis
alguns métodos em vigor:
- utilizar formato fixo: campos por ordem pré-definida e de comprimento pré-definido;
- utilizar campos de comprimento variável; o respectivo termo é indicado, no caso, por:
- aposição de um padrão "proibido" no interior do valor;
- associação a cada porção do valor de uma marca more-flag ("continua-no-proximo-episódio"/"The_End");
- prefixação do valor por um campo explicitando o seu comprimento em bytes.
- em casos em que os campos são opcionais/de-ordem-não-fixa, precedê-los de um identificador/cod-op único.
Exemplos de utilização pela camada aplicação da Internet:
Formato fixo é utilizado, nomeadamente, por:
DNS: os primeiros bytes (Identif, Flags, Nos de Questões e de Respostas, etc.) do cabeçalho das mensagens
Aposição de um padrão "proibido" é utilizado, nomeadamente, por:
HTTP, que utiliza GET space Pathname space version CRLF (em que CR=Carriage Return e LF=Line Feed)
MAIL, que utiliza ´.´ numa única linha para terminar o texto da mensagem;
Utilização de More-flag é utilizada, nomeadamente, por FTP, na transferência de ficheiros:
Os Dados são veiculados em Segmentos-TCP com FIN=0, após o que executa close da conexão, que na prática se
realiza enviando um Segmento-TCP com FIN=1.
Prefixação do valor por um "Value-Length" é utilizado, nomeadamente, por:
HTTP, que utiliza Content-Length para especificar o número de bytes do documento transportado;
DNS, que, por ex., codifica mega.ist.utl.pt em 4mega3ist3utl2pt0;
Preceder um campo por um identificador/cod-op é utilizado, nomeadamente, por:
HTTP, que utiliza Host: www.etc CRLF body
SMTP, que utiliza MAIL FROM: address CRLF RECPT TO: address CRLF
2. [08T1.2] Explique como é feita a delimitação de PDUs (Protocol Data Units) ao nível do protocolo HTTP para
os casos em que: i) as PDUs não contêm dados de Aplicação e; ii) as PDUs contêm dados de Aplicação.
R: Delimitação de PDUs ao nível do HTTP:
i) Só existe Cabeçalho (Header):
1) campos precedidos de keywords, como seja Host: info, User-Agent: info
2) campos terminados por space ou Carriage-Return+Line-Feed
O cabeçalho finda com uma linha em branco, isto é, com, apenas, Carriage-Return+Line-Feed.
ii) Existe Cabeçalho e Dados:
O cabeçalho preenche-se como na alínea anterior
Os dados seguem o cabeçalho, onde consta um campo Content-length.
Web / HTTP
3. Considere o seguinte pedido HTTP:
GET /somedir/page.html HTTP/1.0
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/4.0
Explique o significado de cada uma das linhas do pedido.
4. Considere o seguinte fragmento de uma resposta HTTP:
HTTP/1.1 301 Moved Permanently
Date: Tue, 19 Oct 2004 17:30:00 GMT
Location: http://rci.tagus.ist.utl.pt/lab/
Connection: close
Explique o significado de cada uma das linhas apresentadas na resposta
5. [08E1.1] O protocolo HTTP prevê a utilização do comando GET condicional. Diga para que serve (referindo
um cenário de aplicação), quais as linhas de cabeçalho específicas deste comando e que tipos de resposta são
possíveis.
R: Considere-se um Programa de Navegação (Browser) requerendo um Objecto a um proxy/cache da Web.
1. Se o Objecto aí não reside ainda, ele envia GET ao pertinente Servidor; quando o Objecto chegar, memoriza-o, a ele
e ao último momento em que foi alterado (Date-last-modified).
2. Caso contrário, ele envia GET condicional com uma linha de cabeçalho
específica: o atributo “If-modifed-since” reportando aquele último momento.
Trata-se de conferir se o Objecto é ainda válido ou se precisa ser actualizado
(pelo Objecto no Servidor). O Servidor pode responder com dois tipos de
resposta:
- declarando meramente “Not modified” (vidé Apps02.f)
- ou enviando a versão mais recente desse Objecto e o último momento
em que foi alterado.
Ex.: Aceda a http://web.ist.utl.pt/ist10898/public/Proofs/index.php. Depois,
volte a aceder-lhe antes e depois de 16 de Janeiro: o resultado é diferente, na
última vez, a Pag será actualizada…
6. Considere um servidor HTTP em funcionamento. Num dado instante, o servidor tem exactamente 10 clientes
ligados, todos eles pretendendo fazer um GET do mesmo objecto em HTTP/1.1. Dos 10 clientes, 3 já
transferiram o objecto, 2 estão a transferir o objecto e 5 ainda não transferiram o objecto. Quantas ligações TCP
tem o servidor HTTP estabelecidas? Quantos sockets TCP e UDP tem o servidor abertos?
R: Há 11 sockets TCP: 10 para as ligações dos clientes ligados ao servidor, e 1 para escutar ligações. O servidor HTTP
não usa sockets UDP, pelo que tem 0 (zero) sockets UDP
7. Indique três vantagens da utilização de caches web.
R: Reduz o tempo de resposta para pedidos do cliente; reduz tráfego nas linhas; permite aos fornecedores de conteúdos
com linhas de baixo ritmo que efectivamente forneçam conteúdos
8. Para que servem os cookies no protocolo HTTP? Dê um exemplo de uma aplicação que beneficie do uso de
cookies.
9. [09E3.3] Considere o uso de Cookies em sessões Web/http.
9.1. Qual a motivação para o uso de Cookies? Indique duas Aplicações onde poderá ser útil o uso de Cookies.
9.2. Exemplifique a utilização das linhas de cabeçalho ‘Cookie’ e ‘SetCookie‘ numa sessão Web.
9.3. Quem é que, em geral, fixa o valor de um Cookie?
9.4. Quais as consequências que poderão advir se o utilizador do browser proceder ao disable dos Cookies?
Haverá alguma vantagem em tal procedimento?
9.5. Avalie o uso de endereços-IP como alternativa ao uso de Cookies.
R1: Um Cookie é uma pequena informação salvaguardada no computador com o Programa de Navegação – e que ele
envia ao Servidor-Web; com isso, possibilita-lhe pesquisar informação a propósito do utilizador em causa – que aí foi
coleccionada e associada a esse Cookie. Aplicações onde Cookies podem ser úteis: 1) Compras electrónicas (o utilizador
pode ir designando os itens que pretende adquirir – e fá-lo em página distintas -, e o Servidor associa-os a um mesmo
Cookie); 2) Preenchimento de um formulário repartido por múltiplas páginas.
R2. O Servidor concebe um Cookie e envia-o ao Programa de Navegação, utilizando uma linha do cabeçalho HTTP, por
ex.: Set Cookie: name=xpto. O Programa de Navegação memoriza (não obrigatoriamente) esse Cookie – e, de cada vez que
vier a aceder àquele Servidor, envia-lho, mediante uma linha do cabeçalho HTTP, por ex.: Cookie: name=xpto.
R3: O Servidor
R4: Sem Cookies, torna-se difícil a vida a Aplicações que a ele recorrem. Poderá convir proceder ao disable dos Cookies,
nomeadamente para salvaguardar a privacidade do utilizador.
R5: Endereços-IP não são uma tão boa solução, porquanto:
- o mesmo Utilizador pode estar interessado em começar a fazer compras em um computador e continuar em outro com outro endereço-IP;
- e o mesmo endereço-IP poderá ser utilizado por utilizadores diferentes, que poderão querer comprar coisas distintas.
10.  Pretende-se estimar o tempo necessário à recuperação de um documento da Web. O documento é constituído
por um objecto HTML base que referencia três imagens. A dimensão do objecto-base e das imagens é
desprezável, o que significa que os tempos de transmissão dos objectos são também desprezáveis. O tempo-deida-e-volta entre o local onde acede à Web e o local onde se encontra o documento é representado por RTT.
Qual o tempo necessário para recuperar o
documento,
10.1. se usar HTTP não-persistente sem sessões
TCP paralelas?
10.2. se usar HTTP não-persistente com sessões
TCP paralelas?
10.3. se usar HTTP persistente (com pipelining)?
Resolução:
Conforme ao método seguido na resolução de
problemas anteriores similares, a primeira etapa é:
desenhar um diagrama temporal que esquematize
fielmente a situação descrita. O diagrama temporal
correspondente à situação descrita encontra-se
esquematizado em Web01. Nele, o Cliente e o depositário
do documento são designados respectivamente de A e B.
Foi tido em consideração o seguinte:
O protocolo utilizado é HTTP, que se suporta em TCP;
pelo que, em ordem a recuperar o objecto-base, há que
estabelecer primeiro uma conexão-TCP entre A e B. Ela é iniciada no instante T0; RTT segundos depois, em T1, chega o
correspondente accept... De imediato, A envia uma mensagem-HTTP (Get), referindo o objecto-base; B replica devolvendo
esse Objecto e (tratando-se de HTTP não-persistente) desencadeando de imediato o fecho da conexão-TCP. Em T2,
chega a A o objecto-base.
Para obter a primeira imagem referenciada, segue-se um procedimento análogo: estabelecimento de uma conexão-TCP,
imediatamente seguida de uma mensagem Get referindo essa imagem; e subsequente devolução dessa imagem, e
terminação da conexão-TCP… Para obter as duas imagens seguintes, repete-se o procedimento…
A partir do diagrama temporal, a resposta à questão proposta volve-se em simples geometria euclideana: trata-se de
determinar quanto tempo medeia entre T0 e T6. Ele será o somatório dos tempos parciais [T0 a T1] + [T1 a T2] +[T2 a T3] +[T3
a T4] … [T5 a T6], que se volve em 4 * (2 * RTT) = 8 RTT.
Para a resolução da segunda alínea, a primeira etapa
é, de novo: desenhar um diagrama temporal que
esquematize fielmente a situação descrita.
Ele vem a ser muito semelhante ao anterior, cfr fig Web02.
A diferença é o que acontece após a recepção do
Objecto-base, em T2: o Cliente de imediato dá início ao
estabelecimento de três conexões-TCP com o Servidor, B;
e, quando receber os subsequentes accept, em T3,
despacha de imediato três mensagens Get referindo as
várias imagens, uma por cada conexão; B replica com a
devolução das imagens e a terminação das conexõesTCP…
A partir do diagrama temporal, a resposta à questão
proposta volve-se em simples geometria euclideana: tratase de determinar quanto tempo medeia entre T0 e T4. Ele
será o somatório dos tempos parciais [T0 a T1] + [T1 a T2]
+[T2 a T3] +[T3 a T4], que se volve em 2 * (2 * RTT) = 4 RTT.
Para a resolução da terceira alínea, a primeira etapa é, de
novo: desenhar um diagrama temporal que esquematize
fielmente a situação descrita.
Ele vem a ser muito semelhante ao anterior, cfr fig Web03. A diferença é o que acontece após a recepção do Objecto-base,
em T2: em HTTP persistente, o Servidor não fecha logo a conexão quando devolve o Objecto solicitado; pelo que, e
utilizando-se HTTP paralelo (com "pipelining"), o Cliente pode despachar de imediato três mensagens Get referindo as
várias imagens, todas pela conexão já estabelecida; B replica com a devolução das imagens…
A partir do diagrama temporal, a resposta à questão proposta volve-se em simples geometria euclideana: trata-se de
determinar quanto tempo medeia entre T0 e T4. Ele será o somatório dos tempos parciais [T0 a T1] + [T1 a T2] +[T2 a T4], que
se volve em ((2 + 1 )* RTT) = 3 RTT.
Abra-se um parêntesis: no contexto de HTTP-persistente, é também concebível a alternativa série (não-pipelining). Qual
seria, nesse caso, o tempo necessário para recuperar o documento? O leitor pode verificar que ele monta a (2+3)*RTT = 5
RTT.
11. Repita o problema anterior considerando que o tempo de transmissão de cada objecto, quando a linha não é
utilizada para transmitir mais nenhum tráfego, é T. Exceptua-se o primeiro objecto a ser transferido em cada
ligação, caso em que a transmissão demora 2*T, visto o protocolo de transporte utilizado ter um arranque lento
Resposta:
1. HTTP não-persistente sem sessões TCP paralelas: 2*RTT+2T + 3 * (2*RTT+T)
2. HTTP não-persistente com sessões TCP paralelas: 2*RTT+2T + 2*RTT + 3*2T
\3. HTTP persistente (com pipelining): 2*RTT+2T + RTT + 3*T
12. Pretende-se estimar o tempo mínimo necessário para obter um documento da Web utilizando um proxy. O
documento é constituído por 3 objectos: o objecto base HTML e duas imagens referenciadas no objecto base. O
browser está ligado ao proxy por uma linha com tempo de propagação 1 ms, e o proxy está ligado ao servidor
HTTP por uma linha com tempo de propagação 20 ms. Estas duas linhas são bidireccionais com o mesmo ritmo
de transmissão, sendo o tempo mínimo de transmissão numa linha do objecto base HTML de 8 ms e o tempo
mínimo de transmissão numa linha de cada imagem de 80 ms. Admita que o browser só pode pedir as imagens
quando receber completamente o objecto base. Admita que inicialmente o proxy não tem nenhum objecto
guardado em cache. Admita que, quando o proxy está a receber um objecto, pode guardá-lo na cache em disco e
simultaneamente transmiti-lo para o cliente que o pediu, sem qualquer atraso adicional. Admita que o utilizador
sabe o endereço IP do servidor, indicando-o no browser. A dimensão dos pacotes de estabelecimento de
ligação, de confirmação de estabelecimento de ligação e de envio dos pedidos HTTP é desprezável. Os tempos
de processamento dos pacotes são também desprezáveis.
12.1. Sabendo que cada imagem tem 100000 bytes, qual o ritmo de transmissão das linhas em bit/seg?
12.2. Sabendo que a velocidade de propagação nas linhas é de
200000 km/seg, qual a distância entre o proxy e o servidor HTTP?
12.3. Admitindo que é utilizado HTTP/1.1 com pipelining em todos
os pedidos, apresente um diagrama temporal que ilustre as
interacções entre o browser, proxy e servidor HTTP.
12.4. Nas condições da alínea anterior, qual o tempo mínimo que
demora a obter o documento da Web (intervalo de tempo desde que
o browser inicia o pedido até que recebe completamente todas as
componentes do documento)?
Resposta: RTransmissão=100*103*8/(80*10-3)=10 Mbps.
VPropagacao=(200*103)*(20*10-3)=4000Km
TMin=3*RTTCliente-proxy+3*RTTproxy-server+(8+2*80)10-3,
com RTTCliente-proxy= 2*10-3 e RTTproxy-server =2*20*10-3⇒ TMin=294 mseg.
13.  [2007/09] Pretende-se estimar o tempo mínimo necessário para obter um documento da Web. O documento
é constituído por 6 objectos: o objecto base HTML e cinco imagens referenciadas no objecto base. O browser
está ligado ao servidor HTTP por uma única linha com RTT de 20 ms. O tempo mínimo de transmissão na linha
do objecto base HTML é de 8 ms e o tempo mínimo de transmissão na linha de cada imagem é de 80 ms.
Admita que o browser só pode pedir as imagens quando receber completamente o objecto base. Admita que o
utilizador sabe o endereço IP do servidor, indicando-o no browser. A dimensão dos pacotes de estabelecimento
de ligação, de confirmação de estabelecimento de ligação e de envio dos pedidos HTTP é desprezável. Os
tempos de processamento dos pacotes são também desprezáveis. Não há mais tráfego nenhum na rede.
13.1. Ilustrando a situação com um diagrama temporal, qual o tempo necessário para obter o documento (todos
os objectos), se utilizar HTTP não persistente com um máximo de 4 ligações paralelas?
13.2. Ilustrando a situação com um diagrama temporal, qual o tempo necessário para obter o documento (todos
os objectos), se utilizar HTTP/1.1 com pipelining em todos os pedidos?
R: T1= [2 * RTT + 8] + [2 * RTT + 4 * 80] + [2 * RTT + 80] = 528 mseg
(ou, se a 5ª imagem for pedida logo após ser recebida a 1ª,
apenas T1= [2 * RTT + 8] + [2 * RTT + 4 * 80] + [80], já que 2 * RTT
< 3 *80)
T2= [2 * RTT + 8] + RTT + 5 * 80 = 468 mseg
14. [09T1.2] Suponha que o tempo de transmissão de um objecto base
HTML e três imagens por ele referenciadas, usando o protocolo HTTP
1.1 (com ligações persistentes, ligações paralelas e com pipelining de
pedidos), é de 30 ms. Assuma que o tamanho dos ficheiros
correspondentes à página base e às imagens é desprezável. Qual seria o
tempo de transmissão do mesmo objecto base e das mesmas imagens
se usassemos o protocolo HTTP 1.0 (sem ligações persistentes, sem
ligações paralelas e com as mesmas condições na rede)?
R: 30/3 * 8 = 80 ms (cfr fig Apps02.c)
15. [09E2.3] Considere um Cliente acedendo a um Página da Web cujo Objecto-base se encontra localizado num
Servidor E; esse Objecto referencia três imagens, duas delas
localizadas também em E, mas a terceira situada num outro
servidor, W. Qual a latência da transmissão (do Objecto
base e respectivas imagens)? Admita que o tempo de
transmissão do Objecto-base é de 5 ms, e o de cada Imagem
é de 15 ms. O RTT entre o Cliente e cada servidor é de 20
ms Utiliza-se HTTP 1.1 (com ligações persistentes, ligações
paralelas e com pipelining de pedidos).
R: 20 * 3 + 5 + 15 * 3 = 110 ms, cfr fig Web06.b
(É aceitável a resposta 3 * 20 + 5 + Max {2*15;20+15} = 100
ms)
16. [10T1.1] Pretende-se estimar o tempo mínimo necessário
para obter um documento da Web constituído por quatro
objectos - que estão distribuídos por dois Servidores, W e E:
um objecto base HTML (em W) e três imagens nele
referenciadas (a primeira em W e as outras duas em E). O
RTT mínimo entre o browser e qualquer dos Servidores é de
1,5 ms. Os tempos de transmissão do objecto base e das sucessivas imagens são de, respectivamente, 2, 4, 6 e 3
ms. Admita o seguinte:
- o browser só pode pedir as imagens após receber o objecto base, e
conhece o endereço-IP dos Servidores;
- são desprezáveis: a dimensão dos pacotes de estabelecimento de
ligação, de envio dos pedidos HTTP, assim como os tempos de
processamento dos pacotes;
- não há mais tráfego nenhum na rede.
Ilustrando a situação com um diagrama temporal, qual o tempo
necessário para obter o documento (todos os objectos), se utilizar
HTTP/1.1 com pipelining em todos os pedidos?
R: 1,5*3+2+4+6+3=19,5 ms
17.  Suponha que um servidor Web aloja um número muito grande M de objectos Web. A frequência de acesso
ao i-ésimo objecto mais popular vem dada pela lei de Zipf:
fi = k / i, para 1 ≤ i ≤ M, e com k a constante de normalização.
Para minimizar o tráfego Web na linha de saída,
o administrador de rede de uma empresa decide
instalar um sistema de cache onde armazena os
objectos mais populares.
17.1. Tomando M = 200000, qual a fracção de
objectos que deve ser armazenada internamente
em cache, para que a taxa de sucesso (hit rate)
não seja inferior a 70%? (Pode usar a
aproximação Σ 1/i = ln N + 0,577157, com i = 1 ,
2 , … , N).
17.2. Tendo como objectivo minimizar o tráfego
Web na linha de saída, comente a opção de
armazenar os objectos mais populares.
Resposta:
Que se entende por frequência de acesso a um objecto? Considere-se um conjunto de 1000 acessos ao servidor Web;
ao objecto Obj1, ter-se-ão feito N1 acessos; ao objecto Obj2, ter-se-ão feito N2 acessos; e assim por diante… A frequência
de acesso a Obj1 terá sido f1=N1/1000; a frequência de acesso a Obj2 terá sido f2=N2/1000…
Repare-se: somando as frequências de acesso, obter-se-á exactamente 1:
Σ fI =f1+ f2+… fM =
(N1+…+ NM) / 1000 = 1000 / 1000=1.
Atendendo ao enunciado, fi = k / i, o somatório acima volve-se em Σ k / i = 1, de que se deduz k = 1 / (Σ 1 / i), e por
conseguinte
k ≈ 1/ (ln 200000 + 0,577157).
Pretendendo-se que a taxa de sucesso não seja inferior a 70%, trata-se então de determinar o menor inteiro X para o qual
f1+ f2+… fX≥ 70%, ou seja, k Σ 1/i ≥ 70% e enfim
ln X + 0,577157 ≥ 0,7 * (ln 200000 + 0,577157),
que conduz a X≈4321. Determinado esse valor X, então a resposta será X/200000 * 100% ≈2,16%
DNS
18. [07E2.2] Explique para que servem os Resource Records de Servidores DNS das classes A, CNAME e NS.]
R: A: Indica o endereço IPv4 de alguma máquina referida pelo seu Nome
ex.: dns.xpto.utl.pt A 123.123.123.123
CNAME: Indica o Nome correcto correspondente à mnemónica referida
ex.: [email protected] CNAME [email protected]
NS: Indica uma máquina que é Servidor de Nomes do Domínio referido
ex.: xpto.utl.pt NS dns.xpto.utl.pt
19. [07E3.2] Suponha que se pretendia criar um novo domínio, designado “NovoDominio.com”. Diga
justificando quais seriam, no mínimo, os novos Resource Records (RRs) que teriam que ser criados para o
efeito, no âmbito do protocolo DNS. Explicite esses RRs, explicando claramente os seus campos.
R: Ter-se-ia que criar os Registos identificando o HostName que é Servidor de Nomes e o respectivo endereço-IP:
NovoDominio.com.
NS dns.NovoDominio.com.
dns.NovoDominio.com.
A
123.123.123.123
20. [08T1.1] Considere o seguinte fragmento de uma Tabela de Resource Records de um Servidor de Nomes
(DNS):
universe.pt.
universe.pt.
universe.pt.
universe.pt.
andromeda
sun.stars
SOA
NS
NS
NS
A
A
…..
sun.stars
andromeda
halebopp.comets
11.11.11.11
11.22.33.44
sirius.stars
encke.comets
halley.comets
stars
comets
www
ftp
dns.stars
dns.comets
A
A
A
NS
NS
CNAME
CNAME
CNAME
CNAME
11.22.33.45
55.66.77.88
55.66.77.89
dns.stars
dns.comets
sirius.stars
halley.comets
encke.comets
halley.comets
20.1. Qual o endereço do Servidor de Nomes do Domínio "stars"? Suponha que se pretendia que este servidor
passasse a ter, também, o endereço 98.76.54.32. Qual/quais o(s) Resource Records que deveriam ser
inseridos na Tabela?
20.2. Admita que pretende criar um Domínio "galaxy" em Universe.pt.; as máquinas "andromeda" e
"pollux.stars" (com endereço 11.22.33.46) ficarão sendo os respectivos Servidores de Nomes. Escreva os
Resource Records que deverão ser introduzidos na Tabela.
R: a1: 55.66.77.88, pois: stars → dns.stars → encke.comets → 55.66.77.88
a2: encke.comets
A
98.76.54.32
b: galaxy
NS andromeda
galaxy
NS pollux.stars
pollux.stars
A
11.22.33.46
21. [08E1.2] Explique como pode o sistema DNS (Domain Name System) ser utilizado para dividir a carga entre
servidores de aplicação replicados. Se preferir, ilustre a sua resposta com um exemplo demonstrativo.
R: Num Servidor-DNS, a um Servidor de Aplicação, como seja www, podem estar associados vários registos ‘A’. Eis um
ex.:
www
86400
IN
CNAME sirius.stars
sirius.stars
86400
IN
A
221.255.255.30
sirius.stars
86400
IN
A
221.255.255.31
sirius.stars
86400
IN
A
221.255.255.32
Então, e seguindo o ex., quando o Servidor-DNS for solicitado a devolver o endereço-IP do Servidor de Páginas-Web…
- na primeira vez, devolve 221.255.255.30; à segunda, devolve 221.255.255.31; à terceira, devolve 221.255.255.32; à
quarta, volta a devolver 221.255.255.30; e assim sucessivamente…
- a consequência é: o primeiro internauta acede via 221.255.255.30; o segundo acede via 221.255.255.31; etc.
22. [09T1.1] Um programa de utilizador invoca “gethostbyname (www.google.com)” (ou a versão mais
recomendada actualmente, getaddrinfo). Como resposta, obtém ‘209.85.135.99’. Depois, invoca
“gethostbyaddr (209.85.135.99)” e obtém ‘mu-in-f99.google.com’. Algum tempo mais tarde, executa o mesmo
programa e observa que gethostbyname/getaddrinfo devolve ‘209.85.135.103’. Diga justificando, quais
seriam, no mínimo, os Resource Records (RRs) que a base de dados do servidor DNS deveria conter, de forma
a levá-lo a responder da forma referida às solicitações feitas.
R:
www. google.com
86400 IN A
209.85.135.99
86400 IN A
209.85.135.103
99.135.85.209.in_addr.arpa 86400 IN PTR mu-in-f99.google.com
(É aceitável mu-in-f99.google.com
86400 IN A 209.85.135.99)
23. [07T1] Considere que um Servidor de Nomes Local foi inquirido
em ordem à resolução de um Nome que de momento não se encontra
na sua cache. A subsequente consulta envolve mais três Servidores
de Nomes, pela ordem {A, B, C}. Considere que não há erros e que
são desprezáveis as dimensões de todos os pacotes e os tempos de
processamento. Os tempos de ida-e-volta (RTTs) entre as entidades
referidas são dados em mseg pela tabela junta. De forma a demorar-se o menor tempo na resolução do Nome
em causa, a(s) query(ies) produzida(s) por A deverá(ão) ser iterativa(s) ou recursiva(s) ? Nesse caso, qual é esse
tempo?
R: Iterativa, pois TIterativa=TAB+TAC=30+5 e TRecursiva=TAB+TBC=30+20=50. TResolução=20+35=55
24.  Suponha que se pretende recuperar uma página HTML, com determinado URL. Contudo, o endereço-IP do
servidor HTTP que aloja a página não está guardado na sua estação; pelo que é necessário recorrer ao DNS.
Suponha, então, que é necessário consultar n servidores DNS, até obter o endereço-IP do servidor que contém a
página desejada, e suponha também que a pesquisa é recursiva. O tempo-de-ida-e-volta entre a estação e o
servidor DNS local é RTT1, e o tempo-de-ida-e-volta entre o (i-1)ésimo e o iésimo servidor DNS é RTTi. O
tempo-de-ida-e-volta entre a estação e o servidor RTTP é RTT0. Desprezando a dimensão da página HTML,
diga qual o tempo necessário à sua recuperação.
Resolução:
Conforme ao método seguido na
resolução de problemas anteriores
similares, a primeira etapa é: desenhar
um diagrama temporal que esquematize
fielmente a situação descrita. O diagrama
temporal que corresponde à situação
descrita encontra-se esquematizado em
Web04. Foi tido em consideração o
seguinte:
No instante T0, a estação envia um
request ao servidor-DNS local, DNS1; no
instante T1, ele chega a esse servidor; de
imediato, ele envia um request ao servidor-DNS seguinte, DNS2; e assim sucessivamente… até que, ao ser interrogado o
n-ésimo servidor-DNS, este devolve um reply. Ele é propagado, de DNS em DNS, até atingir a estação… Esta, então,
estabelece uma conexão-TCP com o servidor do documento HTML pretendido, e, após o envio de uma mensagem Get,
obtém esse documento (Repare-se: no contexto "HTTP", é imprescindível estabelecer uma conexão-TCP antes de enviar
o Get; mas, no contexto "DNS", tal não é assim: o request não requere o estabelecimento de uma conexão…).
A partir do diagrama temporal, a resposta à questão proposta volve-se em simples geometria euclideana: trata-se de
determinar quanto tempo medeia entre T0 e T2n+4. Ele será o somatório dos tempos parciais [T0 a T2n] + [T2n a T2n+2] +[T2n+2
a T2n+4], que se volve em Σ RTTi + 2 RTT0.
(Repare-se que o tempo entre Tn-1 e Tn+1é de RTTn; o tempo entre Tn-2 e Tn+2é de RTTn-1+ RTTn)
25. [06E3] Pretende-se estimar o tempo necessário à recuperação de um documento da Web. O documento é
constituído por um objecto HTML base que referencia cinco imagens. A dimensão do objecto base e das
imagens é desprezável, o que significa que os tempos de transmissão dos objectos são também desprezáveis.
Suponha que emprega HTTP não-persistente sem sessões TCP paralelas. O tempo-de-ida-e-volta entre o local
onde acede à Web e o local onde se encontra o documento é representado por RTT0. Suponha ainda que o
endereço IP do servidor HTTP que aloja a página não está guardado na sua estação, pelo que é necessário
recorrer ao DNS através da consulta,
no total, de N servidores, até obter o
endereço IP do servidor HTTP.
Assuma que a pesquisa DNS é
recursiva. Desprezando a dimensão da
página HTML determine, através de
um diagrama temporal, qual o tempo
necessário até à sua recuperação na
totalidade.
(Relativamente
aos
restantes tempos-de-ida-e-volta que
são necessários para a resolução do
problema, indique esses tempos
através da variável RTT juntamente
com um índice adequado, por forma a
que se perceba claramente a que
entidades se referem esses tempos.)
R: Σ RTTi + 2 * RTT0 (1+5); a fig Web06.a
mostra o Diagrama Temporal.
26.  [2007/09] Considere que uma aplicação no computador surf.eurecom.fr pretende aceder a um
servidor no computador gaia.cs.umass.edu. Para isso, a aplicação consulta vários servidores de nomes,
pela ordem ilustrada na figura Apps01.a. Considere as dimensões de todos os pacotes desprezáveis, os tempos de
processamento desprezáveis e que não há erros.
Os tempos de ida-e-volta (RTTs) entre as entidades referidas são dados em ms pela tabela.
26.1. Classifique os pedidos a cada servidor de nomes como recursivos ou iterativos.
26.2. Quanto
tempo
demora a aplicação a
resolver o endereço
IP do servidor?
26.3. Quanto
tempo
demoraria
a
aplicação a resolver
o endereço IP do
servidor se todos os
pedidos
fossem
recursivos?
R:
O pedido ao servidor de
nomes raiz é iterativo, os
outros são recursivos.
T2= 1 + 300 + 90 + 12 =
403 mseg; T3 = 1 + 300 + 250 + 12 = 563 mseg.
27. Considere que duas aplicações clientes nos computadores C1
e C2, na mesma rede local, pretendem aceder a um servidor
no computador S. O endereço IP do servidor S não está
guardado nem no computador C1 nem em C2, pelo que tem
de ser resolvido através do DNS. O computador C1 é o
primeiro a resolver o endereço de S, e logo depois o
computador C2 tenta resolver o mesmo endereço. Ambos
usam o mesmo servidor de DNS local (Local Name Server),
que não sabe nada sobre o endereço do computador S. O
servidor de DNS raiz (root name server) sabe qual o
servidor DNS intermédio (intermediate name server) que
sabe qual o servidor DNS oficial (authoritative name
server) de S. As dimensões de todos os pacotes são desprezáveis, os tempos de processamento são desprezáveis
e não há erros. Os tempos de ida-e-volta (RTTs) entre as entidades referidas são dados em ms pela tabela
Apps03.a.
27.1. Quanto tempo demora C1 a obter o endereço IP de S, admitindo que todos os pedidos são recursivos?
27.2. Quanto tempo demoraria C1 a obter o endereço IP de S, se
os pedidos ao servidor raiz fossem iterativos, e os restantes
pedidos fossem recursivos?
27.3. Após C1 já ter obtido o endereço IP de S, quanto tempo
demora C2 a obter o endereço IP de S, nas condições da alínea
1?
R:
T1
=
RTTC1-DNSlocal+RTTDNSlocal-DNSraiz+RTTDNSraizDNSintermédio+RTTDNSintermédio-DNSOficial= 371 mseg
T2 = RTTC1-DNSlocal+RTTDNSlocal-DNSraiz+RTTDNSlocal-DNSintermédio+RTTDNSintermédioDNSOficial= 321 mseg
T3 = RTTC2= 1 mseg
28. [07E1] Pretende-se estimar o tempo necessário à recuperação de
um documento da Web, acedido através de um computador A. O
documento é constituído por um objecto HTML base que
referencia 10 imagens. A dimensão do objecto base e das imagens é desprezável. Suponha que emprega HTTP
persistente. O tempo-de-ida-e-volta entre o computador A e o local onde se encontra o documento é 10 ms.
Suponha ainda que o endereço IP do servidor HTTP que aloja a página não está guardado no computador A,
pelo que é necessário recorrer ao DNS através da consulta do Servidor de Nomes Local (SNL) e mais 5
servidores de nomes, S1, S2, S3, S4 e S5, até obter o endereço IP do servidor HTTP. Assuma que a pesquisa
DNS entre o SNL e os restantes servidores é iterativa. Tendo em conta que o tempo de ida-e-volta (RTT) entre o
computador A e o SNL é 2 ms e os restantes tempos de RTT entre os vários servidores de nomes são os
apresentados na tabela abaixo, determine através de um diagrama temporal qual o tempo necessário até à
recuperação do documento. Assuma que não há perdas, nem erros e os tempos de processamento são
desprezáveis. Os tempos são dados em ms.
SNL
S1
S2
S3
S4
S5
SNL
5
10
10
20
25
10
20
30
40
S1
15
20
30
S2
25
40
S3
60
S4
S5
R: 2 + [5 + 10 + 10 + 20 + 25] + 3* 10 = 102 mseg (cfr fig Apps02.b)
29. [10E1.3] Enunciado análogo a [07E1], mas: 1) o objecto HTML base referencia 5 imagens; 2) O tempo-de-idae-volta entre A e o local onde se encontram todos os objectos é 5 ms; 3) o tempo de ida-e-volta (RTT) entre os
vários servidores de nomes são os apresentados na tabela abaixo; 4) usa-se HTTP com pipelining dos pedidos.
SNL S1 S2 S3 S4 S5
SNL
10
20
30
25
35
20
40
40
50
S1
15
25
35
S2
35
45
S3
50
S4
R: 2 + 10 + 20 + 30 + 25 + 35] + 3 * 5 = 137 ms (cfr fig Apps02.b)
30. [09E1.3] Um fenómeno indesejado no correio electrónico (e-mail) é o denominado “Spam”, i.e., chegada de
mensagens não solicitadas. Suponha o seguinte método para o combater: aquando da recepção de uma
mensagem, contactam-se Servidores do tipo DNSBLs (DNS Black-Lists). É-lhes enviado o endereço de origem
dessa mensagem, subentendendo-se a interrogação: “Esse endereço consta da listagem nesse Servidor?”. Em
caso afirmativo, a mensagem é considerada “Spam”. De notar que existem múltiplos DNSBLs espalhados pelo
Planeta – e não são cópia uns dos outros! Pelo que pode acontecer que somente em um deles conste aquele
endereço
Assuma então um cenário em
que, aquando da recepção de
uma mensagem, o agente de email interroga três desses
DNSBLs. Fá-lo “em difusão”
(i.e., logo após enviar um
request, emite os demais
request, sem aguardar que
chegue um reply). Observa-se
que os requests são enviados
por ordem decrescente dos
RTTs
–
que
são
de,
respectivamente, 20, 25 e 30 ms (os valores de RTT incluem todos os atrasos possíveis que estão envolvidos na
comunicação ida-e-volta). Admita que a capacidade de todas as ligações intermédias entre o agente e os
DNSBLs é idêntica, que request e reply são suportados por UDP e que o tempo de transmissão de um request é
10 ms. Admita também que são desprezáveis os tempos de processamento nos DNSBLs e que não ocorrem
perdas de segmentos. Diga quanto tempo, no máximo, é expectável que o receptor de uma mensagem tenha que
esperar para saber se se trata ou não de “Spam”, nos seguintes casos
30.1. Tempo de transmissão de um reply é de 8 ms. [Ex: 0.5]
30.2. Tempo de transmissão de um reply é de 4 ms. [Ex: 0.5]
R: 1) 10+30+3*8=64 ms 2) 30+20+4=54 ms
TraceRoute
31. [08E3.2] Considere dois hosts, W e E, separados por
quatro nós de comutação (pelo menos), como se
ilustra na fig Apps04.b. O RTT entre qualquer par de
nós adjacentes é de 80 ms. Admita que os datagramas que
suportam o comando traceroute seguem a rota com menos saltos
(hops). Considere desprezáveis os tempos de transmissão desses
datagramas, os tempos de processamento nos nós e os tempos de
propagação nas linhas que interligam os hosts aos respectivos
nós. Admita que um operador em W invoca “traceroute E”.
Qual o tempo mínimo necessário para que lhe apareça no ecran o
resultado completo dessa invocação?
R: ( 1 + 2 + 3 ) * 80 = 480 ms (cfr fig Web02.b)
Correio Electrónico
32. Distinga as situações em que são utilizados os protocolos SMTP e POP3
R: O SMTP (Simple Mail Transfer Protocol) é utilizado para enviar mensagens de correio electrónico para servidores de
correio. O POP3 (Post Office Protocol) é utilizado para uma aplicação de leitura de correio ir buscar mensagens de correio
electrónico à caixa de correio existente no servidor de correio onde é armazenado o correio de um dado utilizador
Peer-to-Peer
33. Considere os sistemas de partilha de ficheiros "Peer-to-Peer". Indique duas formas diferentes de descobrir um
ficheiro que se pretende obter.