LISTA DE EXERCÍCIOS – REDES

Nome: Débora Moreira Castro (22102829)

1) Quais são os métodos de requisição disponíveis no protocolo HTTP 1.1? Descreva

a diferença entre eles.

No protocolo HTTP 1.1, os métodos de requisição, também conhecidos como "verbos",

definem a ação que o cliente deseja realizar no recurso especificado pelo URL. Cada
método tem um propósito específico e é utilizado de maneira distinta. Aqui estão os
métodos de requisição HTTP 1.1 mais comuns e suas diferenças:

● GET: Solicita a representação de um recurso específico. GET deve apenas

recuperar dados e não tem efeito colateral, o que significa que fazer várias
solicitações GET idênticas deve produzir o mesmo resultado.

● POST: Utilizado para submeter dados para serem processados (por exemplo, de um
formulário HTML) para o recurso especificado. Os dados submetidos com o método
POST podem resultar na criação de um novo recurso ou na modificação de um
existente.

● PUT: Envia dados para substituir o recurso especificado. Diferentemente do POST, o

PUT é idempotente, o que significa que várias solicitações idênticas devem resultar
no mesmo estado do recurso que uma única solicitação.

● DELETE: Remove o recurso especificado. Uma vez que um recurso é excluído,

tentativas subsequentes de acessá-lo com um GET devem retornar um erro
(normalmente, 404 Not Found).

● HEAD: Similar ao método GET, mas solicita apenas a linha de status e os

cabeçalhos de resposta, sem o corpo do recurso. Isso é útil para recuperar
metadados sobre o recurso ou para verificar a validade de links ou a modificação do
recurso sem baixar todo o conteúdo.

● OPTIONS: Descreve as opções de comunicação disponíveis para o recurso de

destino, permitindo ao cliente determinar os métodos de requisição e outras opções
suportadas por um recurso.

● TRACE: Realiza um teste de loopback de chamada junto com o caminho para o

recurso de destino. Isso é útil para fins de diagnóstico, permitindo ao cliente ver o
que está sendo recebido no outro extremo da cadeia de requisição e responder.

● CONNECT: Utilizado para estabelecer um túnel para o servidor identificado pelo

recurso de destino. Geralmente, é usado para criar uma conexão segura HTTPS
através de um proxy HTTP.
Cada um desses métodos é projetado para realizar uma função específica dentro do
paradigma de comunicação cliente-servidor do HTTP. A escolha do método depende da
ação que o cliente deseja realizar e do efeito esperado dessa ação no recurso de destino.

2) Quais são os códigos de resposta de uma mensagem HTTP (versão 1.1)?

Os códigos de resposta HTTP, especificados na versão 1.1 do protocolo, são códigos de

status numéricos de três dígitos enviados pelo servidor ao cliente para indicar o resultado
de uma solicitação (request). Estes códigos são agrupados em cinco classes, cada uma
identificada pelo primeiro dígito do código de status:

● 1xx - Respostas Informativas:

○ 100 Continue: A solicitação inicial do cliente foi recebida e o processo pode
continuar.
○ 101 Switching Protocols: O servidor concorda em mudar o protocolo
conforme solicitado pelo cliente.

● 2xx - Respostas de Sucesso:

○ 200 OK: A solicitação foi bem-sucedida e a resposta contém o recurso
solicitado.
○ 201 Created: A solicitação foi bem-sucedida e um novo recurso foi criado.
○ 202 Accepted: A solicitação foi aceita para processamento, mas o
processamento não foi concluído.
○ 204 No Content: A solicitação foi bem-sucedida, mas o servidor não tem
conteúdo para enviar na resposta.

● 3xx - Redirecionamentos:
○ 301 Moved Permanently: O recurso solicitado foi movido permanentemente
para uma nova URL.
○ 302 Found: O recurso solicitado foi temporariamente movido para uma nova
URL.
○ 304 Not Modified: O recurso não foi modificado desde a última solicitação do
cliente.

● 4xx - Erros do Cliente:

○ 400 Bad Request: A solicitação não pode ser processada pelo servidor
devido a uma aparente falha do cliente.
○ 401 Unauthorized: A autenticação é necessária para acessar o recurso.
○ 403 Forbidden: O servidor se recusa a autorizar a operação.
○ 404 Not Found: O recurso solicitado não foi encontrado no servidor.
○ 405 Method Not Allowed: O método solicitado é conhecido pelo servidor, mas
foi desabilitado e não pode ser utilizado.

● 5xx - Erros do Servidor:

○ 500 Internal Server Error: Ocorreu um erro genérico no servidor.
○ 501 Not Implemented: O servidor não suporta a funcionalidade necessária
para cumprir a solicitação.
 ○ 502 Bad Gateway: O servidor, enquanto atuando como gateway ou proxy,
recebeu uma resposta inválida do servidor upstream.
○ 503 Service Unavailable: O servidor não está pronto para lidar com a
solicitação, geralmente por estar sobrecarregado ou em manutenção.

Cada código de resposta fornece informações essenciais sobre o resultado de uma

solicitação HTTP, permitindo que clientes e servidores tomem ações apropriadas com base
no status da comunicação.

3) Qual a diferença entre HTTP persistente com paralelismo e HTTP persistente sem
paralelismo? Qual dos dois é usado pelo HTTP 1.1 ?

O HTTP persistente refere-se à capacidade de realizar várias solicitações e respostas HTTP

sobre uma única conexão TCP, o que melhora a eficiência da comunicação ao reduzir a
sobrecarga de abrir e fechar conexões múltiplas. Há duas maneiras de se utilizar o HTTP
persistente: com paralelismo e sem paralelismo.

No HTTP persistente sem paralelismo, também conhecido como conexão persistente

sequencial, as solicitações são feitas uma após a outra sobre a mesma conexão TCP. O
cliente envia uma solicitação e espera pela resposta do servidor antes de enviar a próxima
solicitação. Isso reduz a latência comparada ao modelo não persistente, porque evita a
sobrecarga de estabelecer uma nova conexão TCP para cada solicitação/resposta. No
entanto, ainda pode haver atrasos consideráveis se muitas solicitações forem feitas
consecutivamente, pois cada solicitação só pode ser enviada após a resposta completa da
solicitação anterior.

No HTTP persistente com paralelismo, o cliente pode enviar várias solicitações em rápida
sucessão, sem esperar por uma resposta após cada solicitação. Isso é alcançado abrindo
várias conexões TCP paralelas entre o cliente e o servidor, ou utilizando o pipelining em
uma única conexão TCP, onde o cliente envia várias solicitações em sequência antes de
receber as respostas correspondentes. O paralelismo permite uma utilização mais eficiente
da conexão, reduzindo ainda mais o tempo total necessário para processar várias
solicitações e respostas.

O HTTP 1.1 utiliza conexões persistentes por padrão, o que significa que a conexão TCP
entre o cliente e o servidor permanece aberta após uma solicitação/resposta, a menos que
seja explicitamente fechada por um dos lados. No entanto, o HTTP 1.1 não especifica o uso
obrigatório de paralelismo. Embora o HTTP 1.1 introduza a capacidade de pipelining (enviar
várias solicitações sem esperar por cada resposta correspondente), essa funcionalidade
apresentou problemas práticos relacionados à ordem de resposta e ao gerenciamento de
erros, fazendo com que não fosse amplamente adotada ou recomendada na prática.

Na realidade, a maioria dos navegadores modernos e servidores web utiliza conexões

HTTP 1.1 persistentes sem pipelining, optando por abrir várias conexões paralelas quando
necessário para melhorar o desempenho. Isso equilibra a eficiência da persistência de
conexões com a necessidade de carregar rapidamente recursos da web compostos por
múltiplos elementos (como imagens, scripts e folhas de estilo).
4) Falso ou verdadeiro?
a. Suponha que um usuário requisite uma página Web que consiste em texto e
duas imagens. Para essa página, o cliente enviará uma mensagem de requisição e
receberá três mensagens de resposta?
b. Duas páginas Web distintas (por exemplo, www.mit.edu/research.html e
www.mit.edu/students.html) podem ser enviadas pela mesma conexão persistente.
c. Com conexões não persistentes entre browser e servidor de origem, é
possível que um único segmento TCP transporte duas mensagens de requisição
HTTP
d. O cabeçalho Date: na mensagem de resposta HTTP indica a última vez que o
objeto de resposta foi modificado.

a. Falsa. Para uma página Web que consiste em texto e duas imagens, o cliente
normalmente enviará uma mensagem de requisição HTTP para o HTML da página e, após
processar o HTML e descobrir as imagens necessárias, enviará requisições HTTP
adicionais para cada imagem. Assim, para essa página, o cliente enviaria três mensagens
de requisição (uma para o HTML e uma para cada imagem) e receberia três mensagens de
resposta (uma resposta para cada requisição). Portanto, o cliente envia uma requisição para
cada recurso necessário, não apenas uma para todos os recursos.

b. Verdadeira. Duas páginas Web distintas podem ser enviadas pela mesma conexão
persistente HTTP. O HTTP 1.1, que utiliza conexões persistentes por padrão, permite que
múltiplas requisições e respostas HTTP sejam enviadas através da mesma conexão TCP
para melhorar a eficiência, reduzindo a necessidade de abrir novas conexões para cada
recurso solicitado. Isso é particularmente útil para recursos hospedados no mesmo domínio,
como é o caso do exemplo dado.

c. Falsa. Com conexões não persistentes (também conhecidas como conexões "fechar após
cada resposta"), cada conexão TCP é usada para enviar uma única requisição e receber
uma única resposta. Após a resposta ser recebida, a conexão é fechada. Portanto, não é
possível que um único segmento TCP transporte duas mensagens de requisição HTTP, já
que cada requisição/resposta requer sua própria conexão TCP em um modelo de conexão
não persistente.

d. Falsa. O cabeçalho Date: na mensagem de resposta HTTP indica a data e a hora em que
a mensagem de resposta foi gerada pelo servidor, não a última vez que o objeto de
resposta foi modificado. O cabeçalho que indica a última vez que o objeto foi modificado é o
Last-Modified:. O cabeçalho Date: serve para outros propósitos, como sincronização de
tempo e validação de cache, mas não informa diretamente sobre a última modificação do
recurso solicitado.

5) Pesquisar os números de portas para todos os protocolos padronizados.

Os números de portas são divididos em três faixas: as portas bem conhecidas (0-1023), as
portas registradas (1024-49151) e as portas dinâmicas ou privadas (49152-65535). Segue a
lista de alguns dos números de portas para protocolos padronizados mais conhecidos
conforme definido pela Internet Assigned Numbers Authority (IANA).

● FTP (File Transfer Protocol)

○ Porta 20: FTP (dados)
○ Porta 21: FTP (controle)
● SSH (Secure Shell)
○ Porta 22
● Telnet
○ Porta 23
● SMTP (Simple Mail Transfer Protocol)
○ Porta 25
● DNS (Domain Name System)
○ Porta 53
● HTTP (Hypertext Transfer Protocol)
○ Porta 80
● POP3 (Post Office Protocol version 3)
○ Porta 110
● IMAP (Internet Message Access Protocol)
○ Porta 143
● HTTPS (HTTP Secure)
○ Porta 443
● SMTPS (SMTP Secure)
○ Porta 465
● IMAPS (IMAP Secure)
○ Porta 993
● POP3S (POP3 Secure)
○ Porta 995

6) Qual a diferença entre aplicações de redes e protocolos de camada de aplicação de

rede?

A distinção entre aplicações de redes e protocolos de camada de aplicação é fundamental

na arquitetura de comunicações de redes. Este contraste pode ser compreendido
examinando a função e o propósito que cada um desempenha dentro do ecossistema de
comunicação de dados.

As aplicações de redes constituem o conjunto de software que emprega capacidades de

rede para realizar tarefas específicas orientadas ao usuário final. Estas aplicações são
implementadas no topo da pilha de protocolos de rede e são projetadas para atender a
requisitos funcionais específicos, como transferência de dados, comunicação em tempo
real, gestão de recursos distribuídos, e assim por diante. Exemplos destas aplicações
incluem, mas não se limitam a, sistemas de gerenciamento de bancos de dados
distribuídos, plataformas de e-commerce, clientes de correio eletrônico, e navegadores web.
A funcionalidade fornecida por essas aplicações é acessível ao usuário através de
interfaces gráficas ou de linha de comando.
Os protocolos de camada de aplicação, por outro lado, definem as regras e procedimentos
de comunicação especificamente na camada de aplicação da pilha de protocolos. Eles são
os componentes fundamentais que possibilitam a interoperabilidade entre diferentes
aplicações de redes ao estabelecer convenções para troca de mensagens, formatação de
dados, procedimentos de autenticação e autorização, e outros aspectos críticos da
comunicação de dados. Protocolos como o Hypertext Transfer Protocol (HTTP), Simple Mail
Transfer Protocol (SMTP), File Transfer Protocol (FTP), e o Extensible Messaging and
Presence Protocol (XMPP) são exemplos desses conjuntos de regras, cada um adaptado a
necessidades específicas de comunicação, como navegação web, transferência de emails,
transferência de arquivos e mensagens instantâneas, respectivamente.

Em resumo, enquanto as aplicações de redes são implementações de software que

realizam funções específicas para o usuário final, utilizando as capacidades da rede, os
protocolos de camada de aplicação são os conjuntos de regras que definem como a
comunicação é efetuada entre essas aplicações em uma rede. Os protocolos de camada de
aplicação são, portanto, essenciais para a definição dos métodos de comunicação e
intercâmbio de dados entre as aplicações, garantindo a aderência a padrões que
possibilitam a interoperabilidade entre sistemas heterogêneos.

7) Qual a quantidade típica de conexões TCP paralelas que são abertas pelos
browsers?

A quantidade de conexões TCP paralelas que os navegadores modernos abrem para

otimizar o carregamento de páginas da web pode variar, principalmente devido às melhorias
nos próprios protocolos e à evolução das práticas recomendadas de desenvolvimento web.
Tradicionalmente, os navegadores limitavam o número de conexões TCP simultâneas para
um único domínio para evitar sobrecarga no servidor e na rede. Esse limite era geralmente
definido pelos próprios navegadores e pelas especificações de protocolos como o
HTTP/1.1.

Quando o HTTP/1.1 foi amplamente adotado, a maioria dos navegadores limitava o número
de conexões TCP paralelas por domínio a cerca de 6 a 8. Esse limite era uma melhoria em
relação ao HTTP/1.0, que não tinha conexões persistentes por padrão, e ajudava a
equilibrar a eficiência do carregamento da página com a justiça no uso dos recursos do
servidor e da rede.

Com a introdução do HTTP/2, os navegadores e servidores começaram a suportar

multiplexação de solicitações e respostas em uma única conexão TCP. Isso significa que,
teoricamente, apenas uma conexão TCP por domínio seria necessária para carregar todos
os recursos de uma página da web, pois o HTTP/2 pode enviar várias solicitações em
paralelo sobre a mesma conexão. Isso reduz a necessidade de várias conexões TCP e
melhora o uso dos recursos, além de reduzir a latência.

Na prática, o número exato de conexões TCP que um navegador abre pode depender de
vários fatores, incluindo:
 ● Políticas específicas do navegador: Diferentes navegadores podem implementar
diferentes limites de conexão e políticas de gerenciamento de conexões.
● Restrições do servidor: Alguns servidores podem limitar o número de conexões
simultâneas de um único cliente.
● Condições da rede: As condições de rede entre o cliente e o servidor podem
influenciar o gerenciamento de conexões.
● Conteúdo da página da web: Páginas da web que requerem recursos de múltiplos
domínios (como CDN, serviços de terceiros) podem levar a um número maior de
conexões TCP simultâneas, cada uma para um domínio diferente.

Embora o HTTP/2 e técnicas modernas de otimização da web tenham reduzido a

necessidade de múltiplas conexões TCP paralelas por domínio, o número exato pode variar
dependendo do navegador, do conteúdo da página, das políticas do servidor e das
condições de rede. Os desenvolvedores de navegadores e os padrões da web continuam
evoluindo para melhorar a eficiência da comunicação em rede, reduzindo a necessidade de
conexões TCP paralelas enquanto otimizam o desempenho do carregamento da página.

8) Quais são os métodos padronizados para requisição de páginas WEB?

Para requisição de páginas web, o protocolo HTTP (Hypertext Transfer Protocol) define um
conjunto de métodos de requisição (ou "verbos"), cada um indicando uma ação diferente
que deve ser realizada no recurso especificado. Métodos estes já descritos na primeira
questão e que são definidos na especificação do protocolo HTTP, sendo a versão mais
recente detalhada no HTTP/1.1 e aprimorada no HTTP/2. Cada método serve a um
propósito específico na comunicação web, permitindo a realização de diferentes tipos de
operações em recursos na internet.

9) Qual o tamanho típico das mensagens recebidas pelo protocolo HTTP?

O tamanho das mensagens recebidas pelo protocolo HTTP pode variar significativamente
dependendo do conteúdo da mensagem e do recurso solicitado. Não existe um "tamanho
típico" fixo para mensagens HTTP, pois elas podem conter uma ampla gama de dados,
desde uma simples página HTML de texto até arquivos grandes, como vídeos ou pacotes
de software. Aqui estão alguns fatores que influenciam o tamanho das mensagens HTTP:

● Cabeçalhos HTTP
As mensagens HTTP incluem cabeçalhos que fornecem metadados sobre a requisição ou a
resposta. Os cabeçalhos podem variar em número e tamanho, incluindo informações como
tipo de conteúdo, codificação, cookies, e instruções de cache. Em geral, os cabeçalhos de
uma mensagem HTTP podem variar de algumas centenas de bytes a vários kilobytes,
dependendo da complexidade da requisição ou resposta e da quantidade de metadados
transmitidos.

● Corpo da Mensagem
O corpo da mensagem HTTP, que contém os dados reais do recurso solicitado (por
exemplo, HTML, JSON, imagens, vídeos), pode variar de zero bytes (como em algumas
respostas GET ou HEAD, onde o corpo está vazio) a vários gigabytes para grandes
transferências de arquivos. Para páginas web típicas, o corpo da resposta pode variar de
alguns kilobytes a vários megabytes, incluindo HTML, CSS, JavaScript e outros recursos
incorporados, como imagens.

● Tipos de Conteúdo
O tipo de conteúdo solicitado afeta significativamente o tamanho da mensagem HTTP:
○ Páginas HTML podem variar de alguns KB a centenas de KB.
○ Imagens e arquivos multimídia (como vídeos) podem variar de pequenos KB
para imagens otimizadas para a web até vários MB ou até GB para vídeos de
alta qualidade.
○ APIs REST que retornam dados em formatos JSON ou XML geralmente
produzem mensagens na faixa de KB a MB, dependendo da quantidade de
dados solicitados.

● Compressão
Muitos servidores e clientes HTTP suportam compressão de dados (por exemplo, gzip ou
deflate) para reduzir o tamanho das mensagens transmitidas. A compressão pode diminuir
significativamente o tamanho do corpo da mensagem, especialmente para textos e marcas
de linguagem (como HTML, CSS e JavaScript), tornando o tamanho da mensagem
transmitida menor do que o tamanho do recurso original não comprimido.

Portanto, o tamanho das mensagens recebidas pelo protocolo HTTP varia amplamente com
base no tipo de conteúdo solicitado, na presença e tamanho dos cabeçalhos HTTP, e na
aplicação de técnicas de compressão. Isso reflete a flexibilidade do protocolo HTTP em lidar
com uma ampla gama de necessidades de comunicação na web.

10) Descrever 20 campos padronizados do protocolo HTTP.

O protocolo HTTP define uma série de cabeçalhos que podem ser usados nas mensagens
de requisição e resposta para fornecer informações sobre a transação HTTP. Aqui estão 20
campos de cabeçalho padrão e suas funções básicas:

1. Host: Especifica o domínio e a porta (opcional) para a qual a requisição está sendo
enviada. É obrigatório em requisições HTTP/1.1.

2. User-Agent: Contém informações sobre o navegador do cliente, permitindo que o

servidor identifique o tipo de cliente que está fazendo a requisição.

3. Accept: Indica os tipos de mídia que o cliente está disposto a receber, como text/html
ou image/jpeg.

4. Accept-Encoding: Informa ao servidor quais codificações de conteúdo, como gzip ou

deflate, o cliente suporta para compressão.

5. Accept-Language: Especifica as preferências de idioma do cliente, permitindo que o

servidor selecione a versão linguística apropriada de um recurso.
 6. Content-Type: Indica o tipo de mídia do corpo da requisição ou resposta, como
application/json ou multipart/form-data.

7. Content-Length: O tamanho do corpo da requisição ou resposta em bytes. É

essencial para que o receptor saiba quando a mensagem terminou.

8. Content-Encoding: Especifica qualquer codificação aplicada ao corpo da mensagem,

como compressão ou codificação.

9. Authorization: Contém credenciais para autenticar o cliente no servidor,

frequentemente usadas em APIs ou áreas restritas.

10. Cookie: Envia informações armazenadas pelo servidor como um cookie no

navegador do cliente, útil para manter estados entre as requisições.

11. Set-Cookie: Instrui o cliente a armazenar um cookie. É usado pelo servidor na

resposta.

12. Cache-Control: Diretivas para mecanismos de cache tanto no pedido quanto na

resposta, como no-cache ou max-age.

13. Connection: Controla se a conexão de rede permanecerá aberta após a conclusão

da transação atual, com valores típicos como keep-alive ou close.

14. Date: A data e hora em que a mensagem foi enviada.

15. Expires: Uma data/hora após a qual a resposta é considerada obsoleta, indicando ao
cliente quando um novo recurso deve ser solicitado.

16. If-Modified-Since: Permite uma requisição condicional para um recurso que só será
enviado se o recurso foi modificado desde a data especificada.

17. Location: Indica a URL para a qual uma requisição deve ser redirecionada. É usado
em respostas com códigos de status de redirecionamento, como 301 ou 302.

18. Referer: Indica a URL da página anterior que linkou para a página atual, útil para
análises da web e rastreamento de referência.

19. Server: Fornece informações sobre o software do servidor que está lidando com a
requisição.

20. Transfer-Encoding: Especifica a forma de codificação usada para transferir o corpo

da mensagem de forma segura ao receptor, como chunked.

Estes campos de cabeçalho permitem uma comunicação detalhada e eficaz entre o cliente
e o servidor no protocolo HTTP, controlando aspectos como autenticação, negociação de
conteúdo, gerenciamento de estado e cache.
11) Qual a importância de um Proxy/Cache em uma estrutura de rede?

Em uma estrutura de rede, um servidor proxy/cache desempenha papéis cruciais que

contribuem significativamente para a eficiência, segurança e gestão da rede. Aqui estão
algumas das principais razões que destacam sua importância:

● Melhoria da Eficiência e Redução de Latência

Um servidor proxy/cache pode armazenar cópias locais de conteúdo da web
frequentemente acessado. Quando um cliente solicita um recurso que já está armazenado
no cache, o proxy pode fornecer esse conteúdo diretamente, reduzindo a latência (pois o
conteúdo é entregue mais rapidamente do que se fosse solicitado diretamente ao servidor
de origem) e diminuindo a carga sobre a largura de banda da internet, já que o conteúdo
não precisa ser baixado repetidamente da origem.

● Controle de Acesso e Filtragem de Conteúdo

Os servidores proxy podem ser configurados para restringir o acesso a determinados sites
ou conteúdos da internet, implementando políticas de uso da web. Eles podem bloquear
acesso a sites inadequados ou não seguros e registrar as atividades de navegação na web,
permitindo que as organizações monitorem e controlem como a internet é utilizada dentro
da rede.

● Balanceamento de Carga
Em ambientes com múltiplos servidores, um proxy pode distribuir as solicitações dos
clientes entre vários servidores, equilibrando a carga de trabalho e melhorando a
disponibilidade e a redundância. Isso ajuda a evitar que qualquer servidor único se torne um
ponto de sobrecarga, garantindo uma experiência de usuário mais consistente e confiável.

● Anonimato e Privacidade
Um servidor proxy pode ocultar o endereço IP real do cliente, fazendo com que as
solicitações ao servidor de destino pareçam originar do proxy. Isso pode ser usado para
aumentar a privacidade dos usuários ou para contornar restrições baseadas em
geolocalização, permitindo o acesso a conteúdo que de outra forma estaria bloqueado.

● Segurança
Além de filtrar conteúdo, um proxy pode oferecer recursos de segurança adicionais, como a
inspeção de conteúdo para identificar e bloquear malware ou ataques de phishing. Ao
examinar o tráfego que passa através dele, um servidor proxy pode atuar como uma
barreira entre a rede interna e ameaças externas.

● Caching Condicionado e Otimização de Conteúdo

Além de simplesmente armazenar e servir cópias de conteúdo, um proxy/cache pode
modificar ou otimizar o conteúdo conforme necessário antes de entregá-lo ao cliente. Isso
pode incluir a compressão de dados para acelerar a transmissão ou a modificação de
cabeçalhos HTTP para melhor controle de cache nos clientes.
Em resumo, um servidor proxy/cache é uma peça fundamental na arquitetura de rede que
pode melhorar significativamente a performance, a segurança e a gestão do tráfego de
internet, proporcionando uma experiência de navegação mais eficiente, segura e controlada
para os usuários finais.

12) Qual a diferença entre proxy e cache?

Embora os termos "proxy" e "cache" sejam frequentemente usados em contextos

relacionados e possam coexistir no mesmo dispositivo ou software, eles se referem a
funções distintas na gestão do tráfego de rede. A principal diferença entre eles reside no
propósito e na maneira como manipulam os dados de rede.

Um proxy atua como intermediário entre um cliente (por exemplo, um navegador da web) e
um servidor de destino (por exemplo, um servidor web). Quando um cliente faz uma
requisição através de um proxy, este último encaminha a requisição ao servidor de destino
em nome do cliente. Da mesma forma, quando o servidor de destino responde, o proxy
encaminha a resposta de volta ao cliente. Os proxies podem servir a vários propósitos,
incluindo:

● Controle de Acesso: Restringir ou permitir acesso a determinados sites ou serviços

com base em políticas de rede.
● Filtragem de Conteúdo: Bloquear acesso a conteúdo considerado inadequado ou
perigoso.
● Anonimato: Ocultar a identidade real do usuário (seu endereço IP) dos servidores de
destino.
● Balanceamento de Carga: Distribuir as requisições de entrada entre vários
servidores para otimizar o uso de recursos e melhorar a resposta.

Cache, por outro lado, é uma técnica utilizada para armazenar temporariamente cópias de
conteúdo frequentemente acessado para acelerar o acesso subsequente a esse conteúdo.
Quando um conteúdo é solicitado pela primeira vez, ele é armazenado (ou "cacheado")
localmente. Se o mesmo conteúdo for solicitado novamente, ele pode ser entregue
rapidamente a partir do armazenamento local (cache), sem a necessidade de buscar
novamente o conteúdo no servidor de origem. Isso reduz a latência, diminui a carga nos
servidores de origem e economiza largura de banda. O caching pode ser realizado em
vários níveis, incluindo:

● Cache do Navegador: Armazenamento local de conteúdo no navegador do usuário.

● Cache de Proxy: Quando integrado a um proxy, armazena conteúdo para acelerar o
acesso de múltiplos usuários que passam pelo mesmo proxy.
● Cache de CDN (Rede de Distribuição de Conteúdo): Distribui o cache
geograficamente em vários pontos para otimizar a entrega de conteúdo aos usuários
globais.

Muitos servidores proxy incluem funcionalidades de caching como parte de suas

capacidades. Neste caso, eles não apenas atuam como intermediários, encaminhando as
requisições e respostas entre clientes e servidores, mas também armazenam cópias de
conteúdo frequentemente solicitado. Assim, quando um conteúdo é solicitado novamente, o
proxy com cache pode entregar o conteúdo diretamente do seu armazenamento local,
melhorando o desempenho e reduzindo a carga sobre a infraestrutura da rede.

Em resumo, enquanto um proxy foca na intermediação das comunicações entre cliente e

servidor, implementando controle de acesso, anonimato, filtragem e balanceamento de
carga, o cache se concentra em armazenar conteúdo para acelerar o acesso futuro a esse
conteúdo.

13) Quais são os principais servidores de Proxy/Cache disponíveis para

implementação? Descreva as principais vantagens e desvantagens de pelo menos
dois deles.

Há uma variedade de servidores de proxy/cache disponíveis para implementação, cada um

com suas próprias características, vantagens e desvantagens. Alguns dos mais conhecidos
incluem Squid, Varnish, Nginx, e Apache Traffic Server.

● Squid
○ Vantagens:
■ Flexibilidade: Squid oferece uma ampla gama de configurações e é
capaz de lidar tanto com caching quanto com proxy reverso. Isso
permite uma implementação personalizada baseada em
necessidades específicas.
■ Controle de Acesso: Possui recursos avançados de controle de
acesso, permitindo aos administradores definir regras detalhadas
sobre quem pode acessar quais recursos na internet.
■ Compatibilidade: Funciona em muitos sistemas operacionais,
incluindo Linux, Windows e UNIX, tornando-o uma solução versátil
para diversos ambientes.
■ Redução de Latência e Economia de Largura de Banda: Como
qualquer sistema de cache eficaz, ajuda a reduzir a latência de
acesso a recursos frequentemente solicitados e economizar largura
de banda.

○ Desvantagens:
■ Complexidade de Configuração: A flexibilidade do Squid pode ser
uma desvantagem para alguns, pois sua configuração pode ser
complexa e exigir uma curva de aprendizado acentuada.
■ Desempenho com Conteúdo Dinâmico: Embora seja eficaz no
caching de conteúdo estático, o Squid pode não ser a melhor opção
para sites com conteúdo altamente dinâmico sem ajustes e
configurações adicionais.

● Varnish
○ Vantagens:
■ Alto Desempenho: Varnish é conhecido por seu alto desempenho,
especialmente em sites com tráfego elevado. Ele é capaz de servir
 conteúdo extremamente rápido, graças ao seu armazenamento em
memória.
■ Flexibilidade com VCL: A Varnish Configuration Language (VCL)
permite aos usuários escrever regras de caching muito detalhadas,
tornando o Varnish extremamente flexível e poderoso para manipular
como o conteúdo é cacheado e servido.
■ Suporte a Conteúdo Dinâmico: Com sua capacidade de tratar
diferentes tipos de conteúdo e sua flexibilidade através da VCL, o
Varnish pode ser otimizado para lidar eficientemente com o caching
de conteúdo dinâmico.

○ Desvantagens:
■ Complexidade: Assim como o Squid, a flexibilidade e o poder do
Varnish podem tornar sua configuração complexa, exigindo
conhecimento técnico aprofundado para otimizar totalmente o
desempenho.
■ Armazenamento Principalmente em Memória: Enquanto armazenar
dados em memória permite acesso rápido ao conteúdo, isso também
significa que o Varnish pode exigir uma quantidade significativa de
RAM, o que pode aumentar os custos operacionais para servidores
com grande volume de dados cacheados.

Ambos Squid e Varnish são ferramentas poderosas para melhorar o desempenho de

aplicações web através do caching, cada um com suas próprias particularidades que podem
atender melhor a diferentes cenários de uso. A escolha entre eles deve levar em
consideração as necessidades específicas do ambiente em questão, incluindo tipos de
conteúdo servido, expectativas de tráfego, recursos de hardware disponíveis e a expertise
técnica da equipe de implementação e manutenção.

14) Descreva 5 políticas de substituição de arquivos em Cache.

As políticas de substituição de cache são algoritmos utilizados para decidir quais itens
devem ser removidos do cache quando é necessário espaço para novos itens. Essas
políticas são cruciais para o desempenho do cache, pois influenciam diretamente a
eficiência do cache em termos de taxa de acertos (hits) e falhas (misses). Aqui estão cinco
políticas de substituição de cache comumente usadas:

1. Least Recently Used (LRU)

A política LRU remove o item que não foi acessado há mais tempo. Ela pressupõe que se
um item não foi utilizado recentemente, é menos provável que seja utilizado no futuro. LRU
é implementado tipicamente usando uma lista encadeada de itens de cache, com itens
recentemente acessados movidos para o início da lista e itens mais antigos movidos para o
final. Quando o espaço é necessário, os itens no final da lista (os menos recentemente
usados) são removidos.

2. Least Frequently Used (LFU)

LFU elimina o item com a menor contagem de acessos, sob a suposição de que itens
menos acessados no passado serão menos solicitados no futuro. Diferentemente do LRU,
que considera o tempo desde o último acesso, LFU leva em conta a frequência total de
acessos desde que o item foi adicionado ao cache. Esse método pode ser mais justo com
itens acessados frequentemente, mas que temporariamente não foram utilizados.

3. First In, First Out (FIFO)

FIFO é uma das políticas mais simples, removendo itens na ordem em que foram
adicionados, independentemente da frequência ou recência de acesso. Embora seja fácil de
implementar, não necessariamente reflete a importância ou a utilidade dos itens de cache, o
que pode levar a uma menor eficácia do cache.

4. Random Replacement (RR)

Como o nome sugere, RR seleciona aleatoriamente um item para ser removido quando o
espaço é necessário. Essa abordagem não requer manutenção de registros de acessos ou
ordem de chegada, tornando-a simples e de baixo custo em termos de recursos
computacionais. No entanto, a seleção aleatória também significa que itens importantes
podem ser removidos prematuramente.

5. Segmented LRU (SLRU)

SLRU é uma variação do LRU que divide o cache em duas segmentações: uma para itens
recentemente acessados e outra para itens acessados menos recentemente. Quando um
item é acessado, ele é movido para a segmentação de itens recentemente acessados. A
substituição ocorre primeiro na segmentação de menos acesso. Isso permite que SLRU
combine a recência e a frequência de acesso para tomar decisões de substituição mais
informadas.

Cada uma dessas políticas de substituição tem seus próprios prós e contras, e a escolha
entre elas depende das características específicas do aplicativo e dos padrões de acesso
aos dados. Considerações incluem a previsibilidade do acesso aos dados, os recursos do
sistema disponíveis e o impacto da substituição de cache no desempenho geral do
aplicativo.

15) Fazer um resumo de como configurar os servidores de DNS em uma rede

corporativa, utilizando qualquer distribuição Linux.

Configurar um servidor DNS em uma rede corporativa com uma distribuição Linux envolve
essencialmente quatro grandes etapas, realizadas de maneira abstrata e sem entrar nos
detalhes técnicos ou comandos específicos:

1. Instalar o Software DNS: Escolha e instale um software de servidor DNS, como o

BIND, que é um dos mais populares e amplamente suportados nas distribuições
Linux. Esta etapa prepara o servidor para realizar tarefas de DNS.

2. Configurar o Servidor DNS: Defina as configurações básicas do servidor DNS,

incluindo a criação de zonas DNS que o servidor irá gerenciar. Cada zona DNS
 representa um domínio pelo qual o servidor DNS será autoritativo, controlando assim
como os nomes de domínio dentro dessas zonas são resolvidos.

3. Criar e Configurar Arquivos de Zona: Para cada zona definida, crie um arquivo de
zona correspondente. Esses arquivos contêm registros DNS específicos que
mapeiam nomes de domínio para endereços IP, subdomínios e outras informações
necessárias para a resolução de nomes dentro do domínio.

4. Testar e Validar a Configuração: Após configurar o servidor e as zonas DNS, é

importante testar a configuração para garantir que tudo está funcionando conforme
esperado. Isso inclui verificar se o servidor DNS está respondendo às consultas
corretamente e se os nomes de domínio estão sendo resolvidos para os endereços
IP certos.

Durante o processo, é crucial manter as considerações de segurança em mente, garantindo

que o servidor DNS esteja protegido contra potenciais abusos e ataques. Além disso, a
manutenção contínua, como a atualização do software DNS e a revisão das configurações
de zona, é essencial para a operação confiável e segura do servidor DNS numa rede
corporativa.

16) Quem é o responsável no Brasil pelo registro de nomes “.br” ? E, quem é

responsável pelo domínio genérico “.com”?

No Brasil, o registro de nomes de domínio sob o ccTLD (Country Code Top Level Domain)
".br" é administrado pelo NIC.br (Núcleo de Informação e Coordenação do Ponto BR). O
NIC.br é uma entidade civil sem fins lucrativos que implementa as decisões e projetos do
Comitê Gestor da Internet no Brasil (CGI.br), incluindo a manutenção dos registros de
domínios ".br" e a alocação de espaço de endereçamento IP no país.

Quanto ao domínio genérico ".com", ele é administrado por várias empresas de registro
acreditadas pela ICANN (Internet Corporation for Assigned Names and Numbers), uma
organização sem fins lucrativos responsável pela coordenação global do sistema de
identificação único da internet, incluindo nomes de domínio. A VeriSign, por exemplo, é a
principal entidade responsável pela operação dos servidores de nomes de domínio ".com".

A ICANN desempenha um papel fundamental na administração e coordenação dos espaços

de nomes de domínio da internet, assegurando a operação estável e segura da rede. Ela
acredita e supervisiona uma variedade de registradores em todo o mundo que oferecem o
registro de domínios ".com" aos usuários finais.

17) Da perspectiva de um usuário, qual é a diferença entre o modo ler-e-apagar e o

modo ler-e-guardar no POP3? Como o servidor de email identifica a opção escolhida
pelo usuário?

O Protocolo de Agência de Correio Versão 3 (POP3) é um protocolo padrão usado por

clientes de email para recuperar mensagens de um servidor de email. Ele oferece duas
opções principais para o manuseio de emails: o modo "ler-e-apagar" (ou "delete") e o modo
"ler-e-guardar" (ou "leave on server"). A diferença entre esses modos reside em como as
mensagens são gerenciadas no servidor após serem acessadas pelo cliente.

No modo ler-e-apagar, depois que o usuário baixa as mensagens para o seu cliente de
email local (como Microsoft Outlook, Mozilla Thunderbird, etc.), essas mensagens são
removidas do servidor de email. Este modo é útil para usuários que acessam seu email de
um único dispositivo e querem economizar espaço no servidor de email, garantindo que
suas caixas de entrada não fiquem cheias. No entanto, se o usuário tentar acessar o email
de um dispositivo diferente, as mensagens previamente baixadas não estarão disponíveis,
já que foram apagadas do servidor.

No modo ler-e-guardar, as mensagens permanecem no servidor mesmo depois de serem

baixadas pelo cliente de email. Isso permite que o usuário acesse suas mensagens de
múltiplos dispositivos, já que as mensagens continuam disponíveis no servidor para serem
baixadas novamente ou acessadas via outro cliente de email ou serviço webmail. Este
modo é particularmente útil para usuários que utilizam vários dispositivos para acessar seus
emails. Contudo, pode levar ao rápido enchimento do espaço de armazenamento no
servidor, especialmente se muitas mensagens ou anexos grandes forem recebidos
regularmente.

A escolha entre ler-e-apagar ou ler-e-guardar é configurada no cliente de email, e não no

servidor. Quando o cliente de email se conecta ao servidor POP3 para recuperar as
mensagens, ele segue as configurações especificadas pelo usuário:

● Para o modo ler-e-apagar, o cliente de email emite o comando DELE para o servidor
POP3 para cada mensagem após o download, indicando que a mensagem deve ser
marcada para exclusão no servidor.
● Para o modo ler-e-guardar, o cliente simplesmente não emite o comando DELE após
o download das mensagens, deixando-as intactas no servidor.

Essa flexibilidade permite que os usuários configurem seu acesso ao email de acordo com
suas necessidades de mobilidade e armazenamento, mas também requer que eles
gerenciem ativamente seu espaço de armazenamento no servidor de email para evitar
atingir limites de capacidade.