 |
| Bellacosa Mainframe e a missao explorar o crawlers |
☕ Um Café no Bellacosa Mainframe
GET, TCP/IP, Cache e Crawlers: a Aventura de um Padawan na Masmorra Secreta do Blogspot
Imagine a seguinte cena.
Você publica um artigo magnífico no Blogspot. O texto possui COBOL, mainframe, nostalgia, simuladores em JavaScript, imagens, referências históricas e, naturalmente, café.
Então alguém acessa a página.
Parece simples:
O usuário digitou o endereço, apertou Enter e a página apareceu.
Mas isso é apenas o que os olhos humanos conseguem enxergar.
Nos bastidores, uma expedição inteira foi convocada.
O navegador precisa descobrir onde está o servidor, negociar uma conexão, estabelecer segurança, pedir a página, receber dados, consultar caches, baixar imagens, executar scripts, registrar métricas e talvez enfrentar uma horda de crawlers provenientes de Singapura.
É praticamente um episódio de KonoSuba.
O navegador é Kazuma: só queria uma tarefa simples.
O DNS é Aqua: deveria resolver tudo rapidamente, mas às vezes demora, falha ou aponta para o lugar errado.
O TCP é Darkness: insiste em receber todos os golpes, confirmar cada pacote e garantir que ninguém ficou para trás.
O cache é Megumin: guarda energia por bastante tempo e, quando decide agir, entrega tudo de uma vez.
E os crawlers?
Os crawlers são o exército de sapos gigantes.
Você nunca sabe exatamente de onde vieram, por que chegaram em tantos e o que pretendem fazer com sua página.
1. O que realmente acontece quando alguém abre uma página?
Vamos imaginar que um visitante abra:
https://eljefemidnightlunch.blogspot.com/2026/08/exemplo.html
Antes de receber o artigo, o navegador precisa executar várias etapas:
interpretar a URL;
consultar o DNS;
encontrar o endereço IP;
criar uma conexão de rede;
negociar TLS e HTTPS;
enviar uma requisição HTTP;
receber a resposta;
interpretar o HTML;
buscar CSS, JavaScript, imagens e fontes;
executar scripts;
renderizar a página;
eventualmente enviar dados para ferramentas de métricas.
Quando o usuário finalmente vê o título do artigo, dezenas ou centenas de operações já ocorreram.
A web parece instantânea porque tudo isso normalmente acontece em milissegundos.
No entanto, instantâneo não significa simples.
2. A URL: o mapa entregue ao aventureiro
Uma URL pode ser dividida em várias partes:
https://eljefemidnightlunch.blogspot.com/2026/08/exemplo.html
Temos:
https
É o protocolo utilizado.
eljefemidnightlunch.blogspot.com
É o nome do host.
/2026/08/exemplo.html
É o caminho do recurso solicitado.
Também poderíamos ter parâmetros:
?utm_source=linkedin&utm_campaign=artigo
Ou fragmentos:
#capitulo-3
O fragmento normalmente é utilizado apenas dentro do navegador. Ele não precisa necessariamente ser enviado ao servidor.
Já os parâmetros podem participar da requisição e mudar o conteúdo entregue.
Por exemplo:
?m=1
Pode indicar uma versão adaptada para dispositivos móveis.
3. DNS: “Aqua, onde fica esse servidor?”
O computador não trabalha diretamente com nomes como:
blogspot.com
Ele trabalha com endereços IP.
Portanto, antes de acessar a página, o navegador precisa perguntar:
Qual é o endereço IP associado a este domínio?
Essa consulta é feita pelo DNS, o Domain Name System.
O DNS funciona como uma enorme lista telefônica distribuída da internet.
Em vez de memorizar algo como:
142.250.xxx.xxx
você utiliza:
blogspot.com
O processo pode envolver:
cache do navegador;
cache do sistema operacional;
cache do roteador;
servidor DNS do provedor;
servidores DNS recursivos;
servidores autoritativos.
Se o endereço já estiver armazenado em cache, a resposta pode ser praticamente imediata.
Caso contrário, diferentes servidores podem ser consultados até que o endereço correto seja encontrado.
Aqua, em teoria, deveria apenas responder:
O servidor está ali.
Na prática, ela pode tropeçar na própria túnica, reclamar do domínio e culpar o roteador.
4. IP não é identidade absoluta
Um endereço IP identifica um ponto de origem ou saída na rede, mas não representa necessariamente uma única pessoa.
Um mesmo IP pode corresponder a:
uma residência;
uma empresa inteira;
uma operadora de telefonia;
um proxy;
uma VPN;
uma rede corporativa;
um data center;
milhares de usuários atrás de NAT;
um robô de indexação;
uma infraestrutura de nuvem.
Esse detalhe é fundamental ao interpretar estatísticas.
Ver mil acessos provenientes do mesmo país não significa, obrigatoriamente, mil leitores humanos.
Também não significa que mil máquinas distintas acessaram a página.
Pode ser:
uma única plataforma distribuída;
um serviço de pré-visualização;
um mecanismo de segurança;
um crawler;
uma CDN;
um proxy automatizado;
um data center executando milhares de requisições.
Na internet, localização geográfica é uma estimativa, não uma certidão de nascimento.
5. O protocolo TCP/IP: a estrada da aventura
Quando falamos em TCP/IP, estamos falando de uma família de protocolos usada para transportar informações pela rede.
De forma didática, podemos imaginar camadas.
Camada de aplicação
Aqui estão protocolos como:
HTTP;
HTTPS;
DNS;
SMTP;
FTP;
SSH.
É a camada onde vive a requisição GET.
Camada de transporte
Aqui encontramos principalmente:
TCP;
UDP;
QUIC.
O TCP fornece uma comunicação confiável e ordenada.
Camada de internet
Aqui está o IP, responsável pelo endereçamento e roteamento dos pacotes.
Camada de acesso à rede
É onde aparecem tecnologias como:
Ethernet;
Wi-Fi;
fibra;
redes móveis;
interfaces físicas e lógicas.
O modelo real possui inúmeras sutilezas, mas essa divisão ajuda o Padawan a visualizar a jornada.
6. O TCP: Darkness protegendo cada pacote
O TCP, Transmission Control Protocol, é utilizado para transportar dados de forma confiável.
Antes da troca principal de informações, normalmente ocorre o famoso handshake de três etapas:
Cliente -> SYN -> Servidor
Cliente <- SYN-ACK <- Servidor
Cliente -> ACK -> Servidor
Em linguagem de aventureiro:
Cliente:
Posso iniciar uma conversa?
Servidor:
Sim. Eu ouvi você. Você consegue me ouvir?
Cliente:
Consigo. Vamos começar.
Somente depois dessa negociação a comunicação TCP tradicional está estabelecida.
Darkness aprovaria o protocolo.
O TCP aceita ser atingido por:
perda de pacotes;
duplicações;
atrasos;
congestionamento;
reordenação.
E ainda assim tenta garantir que os dados cheguem corretamente.
7. Uma requisição não viaja como um bloco único
Quando o navegador solicita uma página, os dados não atravessam a internet como um pergaminho indivisível.
Eles são divididos em unidades menores.
Dependendo da camada e do contexto, usamos nomes como:
dados;
segmentos;
pacotes;
datagramas;
quadros.
Simplificando:
a aplicação produz os dados;
o TCP divide o conteúdo em segmentos;
o IP encapsula os segmentos em pacotes;
a rede transmite os quadros;
o destino reorganiza tudo.
Uma página HTML de 100 KB pode ser enviada em muitos pacotes.
Uma imagem de 2 MB exigirá ainda mais.
Cada pacote pode seguir rotas diferentes, embora normalmente exista alguma estabilidade durante a conexão.
No destino, os dados são reorganizados.
É como enviar um manual de JCL pelo correio, página por página, numerando cada folha para que Darkness confira se nenhuma foi perdida.
8. Pacotes “excitam” outros sistemas na internet?
A resposta mais precisa é:
Eles podem acionar sistemas intermediários, mas não criam espontaneamente cópias permanentes por toda parte.
Durante o caminho, uma requisição pode passar por:
roteadores;
firewalls;
balanceadores;
proxies;
sistemas de detecção de intrusão;
CDNs;
gateways;
equipamentos de operadoras;
plataformas de mitigação de ataques.
Esses componentes podem:
encaminhar pacotes;
registrar metadados;
contar tráfego;
inspecionar cabeçalhos;
detectar comportamento suspeito;
bloquear requisições;
redirecionar conexões;
responder usando cache;
alimentar sistemas de observabilidade.
No entanto, um roteador comum não costuma guardar uma cópia completa de cada página indefinidamente.
Ele analisa o necessário para encaminhar o pacote e prossegue.
Outros equipamentos, porém, podem registrar:
endereço IP;
horário;
porta;
protocolo;
volume transferido;
origem e destino;
decisão de segurança;
duração da conexão.
Ou seja, o tráfego pode deixar rastros operacionais em diversos pontos.
Mas isso não significa que cada pacote está sendo copiado eternamente por toda a internet.
9. TLS e HTTPS: entrando na masmorra com armadura
Em uma URL HTTPS, existe uma etapa adicional de segurança.
Antes de trocar o conteúdo HTTP, cliente e servidor negociam uma conexão criptografada usando TLS.
Nessa fase, o navegador:
verifica o certificado;
confere o domínio;
negocia algoritmos criptográficos;
estabelece chaves de sessão;
prepara um canal protegido.
Depois disso, a requisição HTTP trafega dentro da conexão criptografada.
Sem HTTPS, alguém posicionado entre o usuário e o servidor poderia, dependendo da rede:
ler o conteúdo;
alterar a resposta;
injetar código;
capturar cookies;
manipular redirecionamentos.
Com HTTPS, o conteúdo fica protegido contra leitura e alteração por intermediários comuns.
Ainda assim, alguns metadados podem permanecer observáveis, como:
IP de origem;
IP de destino;
quantidade aproximada de dados;
duração da conexão;
horário;
frequência das requisições.
Criptografia protege o conteúdo, mas não torna a comunicação invisível.
Kazuma ainda pode entrar disfarçado na cidade, mas os guardas percebem que alguém atravessou o portão.
10. Finalmente, a requisição GET
Depois de DNS, TCP e TLS, o navegador pode enviar algo conceitualmente semelhante a:
GET /2026/08/exemplo.html HTTP/1.1
Host: eljefemidnightlunch.blogspot.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: pt-BR
Accept-Encoding: gzip, br
Connection: keep-alive
A primeira linha diz:
GET /2026/08/exemplo.html HTTP/1.1
Isso significa:
Quero obter o recurso localizado nesse caminho usando HTTP.
O cabeçalho:
Host: eljefemidnightlunch.blogspot.com
informa qual domínio está sendo solicitado.
Isso é importante porque um mesmo endereço IP pode hospedar muitos domínios.
O User-Agent tenta identificar o tipo de cliente.
Exemplo:
User-Agent: Mozilla/5.0
Pode representar:
Chrome;
Firefox;
Edge;
um navegador automatizado;
um crawler fingindo ser navegador;
uma ferramenta de linha de comando modificada.
O User-Agent é uma declaração, não uma prova.
Qualquer robô pode escrever:
User-Agent: SouHumanoConfiaEmMim/1.0
E isso não transforma o crawler em um leitor tomando café.
11. O método GET
O método GET é utilizado principalmente para solicitar uma representação de um recurso.
Exemplos:
GET /artigo.html
GET /imagem.jpg
GET /script.js
GET /feed/posts/default
Em princípio, GET deveria ser seguro e não alterar o estado principal do servidor.
Isso significa que abrir uma página não deveria:
apagar dados;
criar pedidos;
alterar senhas;
publicar comentários;
transferir dinheiro.
Entretanto, sistemas mal projetados podem usar GET incorretamente para ações que alteram estado.
Esse é um problema de arquitetura e segurança.
Também dizemos que GET deveria ser idempotente: executar a mesma solicitação diversas vezes deveria produzir o mesmo efeito essencial sobre o servidor.
A resposta pode mudar porque o conteúdo foi atualizado, mas o simples ato de consultar não deveria causar uma nova alteração a cada acesso.
12. A resposta HTTP
O servidor pode responder:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Encoding: br
Cache-Control: private, max-age=0
Date: Thu, 06 Aug 2026 15:00:00 GMT
E depois enviar o HTML.
O código:
200 OK
indica sucesso.
Outros códigos comuns incluem:
301 Moved Permanently
Recurso movido permanentemente.
302 Found
Redirecionamento temporário.
304 Not Modified
O conteúdo não mudou; o cliente pode usar o cache.
403 Forbidden
Acesso negado.
404 Not Found
Recurso não encontrado.
429 Too Many Requests
Muitas requisições em pouco tempo.
500 Internal Server Error
Erro interno do servidor.
503 Service Unavailable
Serviço temporariamente indisponível.
Um crawler sério observa esses códigos.
Um crawler mal comportado vê um 429 e reage como Aqua:
Isso é discriminação contra divindades!
13. A primeira requisição não carrega a página inteira
O HTML inicial normalmente referencia outros recursos:
<link rel="stylesheet" href="estilo.css">
<script src="simulador.js"></script>
<img src="vesuvio.jpg" alt="Vesúvio">
O navegador precisa realizar novas requisições.
Por exemplo:
GET /estilo.css
GET /simulador.js
GET /vesuvio.jpg
Uma única visita pode gerar dezenas ou centenas de requisições.
Além do conteúdo visível, podem ser carregados:
fontes;
ícones;
bibliotecas JavaScript;
imagens externas;
widgets;
anúncios;
scripts de análise;
comentários;
vídeos incorporados;
iframes;
arquivos JSON;
mapas;
rastreadores.
Portanto:
Uma visualização de página não equivale a uma única requisição de rede.
Esse ponto é essencial para interpretar logs.
14. HTML recebido não significa página visualizada
Um cliente pode realizar um GET e baixar o HTML sem:
renderizar a página;
executar JavaScript;
carregar imagens;
permanecer nela;
rolar o conteúdo;
compreender o texto;
ser humano.
Ferramentas como curl, por exemplo, podem obter a página:
curl https://exemplo.blogspot.com/pagina.html
O servidor registrará a solicitação.
Mas não houve uma visita humana no sentido tradicional.
O mesmo vale para:
crawlers;
verificadores de links;
scanners de segurança;
agregadores;
serviços de cache;
sistemas de pré-visualização;
indexadores;
robôs de IA;
monitores de disponibilidade.
O servidor vê a requisição.
Ele não vê diretamente a intenção.
15. Blogspot: quem realmente atende a solicitação?
Em uma página hospedada no Blogspot, a requisição não vai para um computador escondido embaixo da mesa do blogueiro.
Ela chega à infraestrutura do Google.
Essa infraestrutura pode incluir:
DNS distribuído;
balanceamento de carga;
servidores de borda;
caches;
proxies;
sistemas de segurança;
plataformas de publicação;
armazenamento distribuído;
redes globais de entrega.
O usuário pede o artigo.
A infraestrutura decide de onde e como entregá-lo.
O conteúdo pode ser servido por um ponto geograficamente próximo.
Também pode ser entregue a partir de cache, sem que o sistema precise reconstruir a página do zero.
Para o blogueiro, isso é excelente.
Você consegue publicar milhares de artigos sem manter:
servidores;
discos;
certificados;
firewalls;
balanceadores;
links redundantes;
geradores;
nobres cavaleiros de plantão.
A infraestrutura cuida disso.
O lado menos transparente é que o dono do blog não possui acesso a todos os logs detalhados do ambiente.
Você observa principalmente aquilo que as ferramentas disponibilizam.
16. Cache: Megumin guardando uma explosão
Cache é uma cópia temporária de um conteúdo armazenada para acelerar acessos futuros.
O cache pode existir em vários lugares:
navegador;
sistema operacional;
proxy;
CDN;
infraestrutura do provedor;
aplicação;
servidor;
crawler.
Imagine que uma imagem seja acessada milhares de vezes.
Sem cache, cada acesso exigiria buscar novamente a imagem no armazenamento principal.
Com cache:
o primeiro acesso busca o recurso;
uma cópia é armazenada;
acessos posteriores recebem a cópia;
o servidor principal trabalha menos;
a resposta chega mais rápido.
Megumin passa horas acumulando mana.
Quando alguém pede o recurso, ela grita:
CACHE EXPLOSION!
E entrega o arquivo em poucos milissegundos.
17. Cache do navegador
O navegador pode armazenar localmente:
imagens;
CSS;
JavaScript;
fontes;
respostas HTTP.
Ao visitar a página novamente, ele pode reutilizar esses recursos.
Assim, a segunda visita pode gerar menos tráfego que a primeira.
Mas existem diferentes possibilidades.
Reutilização direta
O navegador considera a cópia ainda válida e não consulta o servidor.
Revalidação
O navegador pergunta se o recurso mudou.
Pode enviar:
If-None-Match: "abc123"
ou:
If-Modified-Since: Thu, 06 Aug 2026 12:00:00 GMT
Se não houve alteração, o servidor responde:
304 Not Modified
Nesse caso, o navegador reutiliza o conteúdo armazenado.
18. Cache intermediário e CDN
Uma CDN, Content Delivery Network, mantém cópias do conteúdo em vários pontos da rede.
Um leitor no Brasil pode receber uma imagem de um servidor próximo.
Um crawler em Singapura pode receber a mesma imagem de outro ponto da infraestrutura.
Isso melhora:
velocidade;
escalabilidade;
resiliência;
redução de latência;
proteção contra picos.
Também cria uma consequência importante para observabilidade:
Nem toda entrega precisa chegar ao mesmo servidor de origem.
Algumas respostas podem ser atendidas na borda.
Isso torna a visão do tráfego mais distribuída.
19. Uma página “quente” pode ser tratada de forma diferente?
Sim.
Sistemas modernos podem identificar recursos populares e ajustar seu comportamento operacional.
Uma página muito solicitada pode:
permanecer mais tempo em cache;
ser replicada em mais pontos da CDN;
receber prioridade de otimização;
ser pré-carregada;
despertar mecanismos de proteção;
entrar em sistemas de detecção de tendências;
receber mais visitas de crawlers;
aparecer em filas de processamento.
Isso não significa que a internet inteira decidiu vigiar a página.
Significa que diferentes sistemas respondem aos sinais de demanda.
Em termos de mainframe:
Um dataset acessado o tempo todo recebe mais atenção operacional que um arquivo esquecido em uma fita de 1994.
20. Observabilidade: enxergando a masmorra
Observabilidade é a capacidade de compreender o estado de um sistema a partir dos dados que ele produz.
Os três pilares clássicos são:
logs;
métricas;
traces.
Também podemos acrescentar:
eventos;
perfis;
dados de experiência do usuário;
sinais de segurança.
21. Logs
Logs registram eventos individuais.
Exemplo simplificado:
2026-08-06T12:00:01 GET /artigo.html 200 145ms IP=203.0.113.10
Isso pode informar:
data e hora;
método;
URL;
código de resposta;
duração;
endereço IP;
User-Agent;
volume transferido;
referenciador.
Um log é parecido com o SYSLOG do z/OS.
Ele registra o que aconteceu.
Mas nem sempre explica sozinho por que aconteceu.
22. Métricas
Métricas são valores agregados ao longo do tempo.
Exemplos:
Requisições por minuto
Taxa de erro
Latência média
Percentil 95
Volume transferido
Número de visitantes
País de origem
Tempo de permanência
No mundo mainframe, podemos comparar métricas a dados encontrados em:
RMF;
SMF;
WLM;
estatísticas de CICS;
informações de Db2;
relatórios de performance.
Você não analisa cada instrução individual.
Você procura padrões.
23. Traces
Traces acompanham uma requisição enquanto ela atravessa diferentes componentes.
Por exemplo:
Navegador
↓
CDN
↓
Proxy
↓
Aplicação
↓
Banco de dados
↓
Resposta
Cada etapa pode possuir um identificador correlacionado.
Em sistemas modernos, isso ajuda a descobrir onde ocorreu o atraso.
No Blogspot, o proprietário do blog não costuma ter acesso a um trace distribuído completo da infraestrutura do Google.
Você enxerga apenas parte da aventura.
É como participar de uma missão com Kazuma e receber somente o relatório escrito por Aqua.
Tecnicamente existe informação.
Mas alguns detalhes importantes desapareceram misteriosamente.
24. Ferramentas de analytics não enxergam a mesma coisa
Duas ferramentas podem apresentar números diferentes porque medem eventos diferentes.
O contador do Blogspot pode registrar uma visualização em determinado ponto da infraestrutura.
Uma ferramenta JavaScript pode contar apenas quando:
o HTML chegou;
o script foi baixado;
o JavaScript foi executado;
o navegador não bloqueou o rastreamento;
a conexão permitiu enviar o evento.
Um crawler que baixa somente o HTML pode aparecer em uma ferramenta e não aparecer em outra.
Um bloqueador de anúncios pode impedir o script de analytics.
Um navegador pode abandonar a página antes do envio da métrica.
Uma CDN pode atender o conteúdo antes de algum ponto de medição.
Portanto:
Contadores diferentes não necessariamente estão errados. Eles podem estar observando camadas diferentes.
25. O perigo do “tempo de permanência”
Medir tempo de permanência parece simples, mas não é.
Um script pode iniciar um cronômetro quando a página carrega.
Depois, pode registrar eventos em:
5 segundos;
10 segundos;
30 segundos;
60 segundos;
5 minutos.
Exemplo:
setTimeout(() => registrar("permaneceu_5s"), 5000);
setTimeout(() => registrar("permaneceu_30s"), 30000);
Mas o que isso realmente prova?
Prova que:
o JavaScript foi executado;
a aba continuou viva;
o temporizador conseguiu disparar;
o evento foi enviado.
Não prova necessariamente que:
o usuário leu;
a aba estava visível;
havia uma pessoa olhando;
o visitante entendeu o conteúdo.
Um crawler com navegador headless pode executar JavaScript.
Uma aba abandonada pode ficar aberta por horas.
Um usuário real pode ler rapidamente e sair antes do primeiro temporizador.
Observabilidade mede sinais.
Sinais precisam ser interpretados.
26. Como melhorar a medição de permanência
Uma medição mais robusta pode combinar:
tempo;
visibilidade da aba;
movimento de rolagem;
interação;
foco da janela;
execução de JavaScript;
envio do evento final.
A Page Visibility API permite verificar se a aba está visível:
if (document.visibilityState === "visible") {
console.log("Página visível");
}
Também podemos observar mudanças:
document.addEventListener("visibilitychange", () => {
console.log(document.visibilityState);
});
Para verificar rolagem:
window.addEventListener("scroll", () => {
console.log("Houve rolagem");
});
Para identificar interação:
document.addEventListener("click", () => {
console.log("Houve clique");
});
Ainda assim, nenhum desses sinais é prova absoluta de humanidade.
Um bot sofisticado pode simular todos eles.
O objetivo não é alcançar certeza perfeita.
O objetivo é aumentar a qualidade da classificação.
27. O que é um crawler?
Crawler é um software que acessa páginas automaticamente.
Ele pode:
descobrir conteúdo;
seguir links;
indexar páginas;
verificar atualizações;
extrair metadados;
construir pré-visualizações;
analisar segurança;
arquivar páginas;
alimentar mecanismos de busca;
coletar conteúdo para modelos e sistemas de IA.
Também recebe nomes como:
spider;
bot;
web crawler;
indexador;
scraper;
robot.
Nem todo bot é crawler.
Nem todo crawler é malicioso.
Nem todo crawler é bem-comportado.
28. Crawlers de mecanismos de busca
Mecanismos de busca utilizam crawlers para:
descobrir URLs;
baixar páginas;
interpretar conteúdo;
seguir links;
detectar atualizações;
indexar informações;
decidir quando retornar.
Um crawler pode encontrar uma página através de:
links externos;
sitemap;
feed Atom;
RSS;
links internos;
envio manual;
páginas de índice;
menções em redes sociais.
Ao encontrar uma URL nova, ele pode colocá-la em uma fila.
Depois, outro sistema visita a página.
Posteriormente, outro componente pode processar imagens, JavaScript ou conteúdo estruturado.
Portanto, aquilo que parece “uma visita do buscador” pode envolver múltiplas requisições realizadas por diferentes componentes.
29. O feed do Blogspot como mapa de tesouro
O Blogspot oferece feeds que podem expor postagens e atualizações.
Um crawler pode consultar o feed para descobrir:
novos artigos;
títulos;
datas;
URLs;
resumos;
autores;
marcadores.
Isso é eficiente.
Em vez de vasculhar milhares de páginas, o robô pergunta:
O que mudou desde minha última visita?
Depois, acessa apenas os itens relevantes.
Um feed pode não aparecer como uma visualização tradicional de página.
Mas ele pode provocar visitas posteriores aos artigos listados.
É como Megumin localizar uma masmorra pelo mapa e depois convencer o grupo inteiro a visitá-la.
30. Crawlers que executam JavaScript
No passado, muitos crawlers liam basicamente o HTML inicial.
Hoje, alguns mecanismos conseguem renderizar páginas usando navegadores automatizados.
Eles podem:
executar JavaScript;
montar o DOM;
aguardar recursos;
carregar conteúdo dinâmico;
capturar links criados por scripts;
observar dados estruturados;
renderizar a aparência final.
Entretanto, isso custa mais processamento.
Por isso, uma plataforma pode usar duas fases:
baixar o HTML rapidamente;
renderizar JavaScript posteriormente.
Esse comportamento ajuda a explicar acessos separados no tempo.
Primeiro surge uma requisição rápida.
Depois, outra visita mais longa pode carregar recursos adicionais.
Não é necessariamente o mesmo processo ou a mesma máquina.
31. Headless browser: um humano sem cabeça
Um navegador headless é um navegador completo sem interface gráfica visível.
Ferramentas como essa podem:
abrir páginas;
executar JavaScript;
clicar;
rolar;
capturar telas;
preencher formulários;
aguardar temporizadores.
Para o servidor, um headless browser pode se parecer muito com um visitante humano.
Ele aceita cookies.
Executa scripts.
Carrega imagens.
Permanece 30 segundos.
E ainda assim não existe ninguém lendo o artigo.
É o Cavaleiro Sem Cabeça da observabilidade.
32. Crawlers de IA
Sistemas de inteligência artificial podem usar crawlers ou coletores para:
descobrir conteúdo;
indexar páginas;
recuperar informações;
produzir respostas;
atualizar bases de busca;
construir conjuntos de treinamento, quando permitido e aplicável.
O comportamento varia conforme a organização.
Alguns bots se identificam claramente.
Outros podem utilizar infraestrutura compartilhada.
Existem também serviços intermediários que coletam conteúdo para múltiplos clientes.
Assim, um acesso aparentemente vindo de um data center pode não revelar diretamente qual sistema final solicitou a página.
33. Pré-visualização de redes sociais
Quando alguém cola um link em uma rede social, serviço de mensagens ou aplicativo, a plataforma pode visitar a página automaticamente.
Ela procura metadados como:
<meta property="og:title" content="Título">
<meta property="og:description" content="Descrição">
<meta property="og:image" content="imagem.jpg">
Esse robô cria a prévia com:
título;
imagem;
descrição;
nome do site.
Portanto, apenas colar um link em uma conversa pode gerar uma requisição.
O destinatário nem abriu a página ainda.
Mesmo assim, o servidor já recebeu uma visita automatizada.
34. Verificadores de segurança
Aplicativos e empresas podem examinar links antes de permitir que o usuário os abra.
Eles verificam:
malware;
phishing;
redirecionamentos;
conteúdo suspeito;
reputação do domínio;
arquivos maliciosos.
Um único link enviado por e-mail pode ser acessado por vários sistemas de segurança.
Primeiro pelo gateway da empresa.
Depois pelo antivírus.
Depois pelo navegador protegido.
Depois pelo usuário.
Nas estatísticas, parecem quatro visitantes.
Na realidade, havia uma pessoa e três guardas desconfiados.
35. Crawlers de SEO
Ferramentas de SEO podem visitar páginas para verificar:
títulos;
descrições;
links quebrados;
velocidade;
headings;
dados estruturados;
tamanho de imagens;
canonical;
sitemap;
indexabilidade.
Algumas operam a partir de grandes data centers.
Elas podem gerar milhares de requisições em pouco tempo.
Se o blog possui quatro mil postagens e o crawler decide mapear tudo, o resultado pode ser impressionante.
Especialmente se cada postagem carregar dezenas de recursos.
36. Por que Singapura aparece tanto?
Uma concentração de tráfego em Singapura pode ter várias explicações:
data centers localizados no país;
serviços de nuvem;
proxies;
plataformas de segurança;
crawlers regionais;
infraestrutura de entrega;
empresas globais utilizando endereços registrados ali;
bancos de dados de geolocalização imprecisos.
Não devemos concluir automaticamente:
Quatro mil moradores de Singapura descobriram meu artigo sobre ICETOOL às três da manhã.
É uma hipótese encantadora.
Mas estatisticamente devemos manter Darkness longe do vinho da comemoração.
É mais provável que parte do tráfego venha de infraestrutura automatizada.
Para investigar, precisamos correlacionar:
horário;
página acessada;
User-Agent;
frequência;
intervalo entre requisições;
execução de JavaScript;
carregamento de recursos;
tempo de permanência;
comportamento de navegação.
37. Padrões típicos de crawlers
Um crawler pode apresentar comportamentos como:
acessos em intervalos regulares;
alta velocidade;
muitas páginas em sequência;
ausência de rolagem;
ausência de cliques;
tempo extremamente curto;
User-Agent identificável;
acesso ao
robots.txt;consulta a sitemap e feeds;
preferência por páginas antigas e novas;
repetição de requisições;
ausência de imagens;
ausência de JavaScript.
Porém, nenhum sinal isolado é definitivo.
Um usuário com conexão ruim pode parecer robô.
Um robô sofisticado pode parecer humano.
A análise deve ser probabilística.
38. Robots.txt: a placa na entrada da masmorra
O arquivo robots.txt informa preferências para crawlers.
Exemplo:
User-agent: *
Disallow: /area-privada/
Isso significa:
Crawlers cooperativos, por favor, não acessem essa área.
Mas robots.txt não é uma barreira de segurança.
É uma convenção.
Bots maliciosos podem ignorá-lo.
Nunca coloque informações sigilosas em uma página acreditando que o robots.txt impedirá o acesso.
Seria como escrever:
Dragões, favor não entrar.
E esperar conformidade regulatória da parte do dragão.
39. Robots.txt não impede indexação em todos os casos
Existe uma diferença entre:
bloquear rastreamento;
impedir indexação;
impedir acesso.
Se uma URL bloqueada for encontrada por links externos, um mecanismo pode conhecer sua existência mesmo sem rastrear seu conteúdo.
Para orientar a não indexação, usa-se normalmente uma diretiva apropriada, como:
<meta name="robots" content="noindex">
Mas o crawler precisa acessar a página para enxergar essa diretiva.
Para conteúdo realmente privado, utilize autenticação e controle de acesso.
Nunca dependa apenas de metatags ou robots.txt.
40. Segurança: o blog também pode ser alvo
Mesmo um blog estático pode enfrentar:
scraping excessivo;
bots;
comentários com spam;
links maliciosos;
tentativas de phishing;
injeções em widgets;
bibliotecas JavaScript comprometidas;
conteúdo externo inseguro;
iframes suspeitos;
abuso de formulários;
roubo de sessão.
O Blogspot protege grande parte da infraestrutura.
Mas o autor ainda precisa cuidar do conteúdo que adiciona.
Especialmente:
scripts externos;
widgets;
iframes;
códigos copiados;
bibliotecas de terceiros;
formulários;
enlaces desconhecidos.
41. O perigo dos scripts externos
Um código como:
<script src="https://site-desconhecido.example/script.js"></script>
entrega muito poder ao domínio externo.
O script pode:
ler o DOM;
alterar a página;
registrar cliques;
coletar informações;
redirecionar usuários;
inserir anúncios;
carregar outros scripts.
Se o fornecedor for comprometido, seu blog pode ser afetado.
Prefira:
fornecedores conhecidos;
poucos scripts;
HTTPS;
código revisado;
dependências necessárias;
recursos hospedados de forma confiável.
Kazuma ensina:
Nunca aceite um artefato mágico de uma pessoa que o encontrou atrás de uma taverna.
42. Iframes: uma janela para outra dimensão
Um iframe incorpora outra página:
<iframe src="https://exemplo.com"></iframe>
O conteúdo interno pode gerar suas próprias requisições.
Portanto, carregar uma postagem com cinco iframes pode abrir várias sessões de rede independentes.
Cada iframe pode:
resolver DNS;
negociar HTTPS;
baixar HTML;
executar scripts;
carregar imagens;
enviar analytics;
criar cookies, conforme as regras do navegador.
O visitante abriu uma página.
Mas a página abriu cinco pequenos portais dimensionais.
Vanir aprovaria o modelo de negócios.
43. Uma cascata temporizada de iframes
Imagine um script que abre páginas em sequência:
0 segundos
5 segundos
10 segundos
30 segundos
Tecnicamente, cada carregamento pode gerar uma nova requisição GET.
Se cada estágio cria ou altera um iframe, o navegador pode:
cancelar o conteúdo anterior;
iniciar uma nova navegação;
reutilizar conexões;
consultar cache;
executar os scripts da nova página;
gerar métricas separadas.
É possível que ferramentas de analytics contem essas páginas individualmente.
No entanto, isso não representa interesse genuíno do usuário.
É tráfego provocado pelo próprio código.
Além de distorcer métricas, pode:
aumentar consumo de rede;
prejudicar desempenho;
confundir crawlers;
criar comportamento parecido com manipulação;
incomodar o visitante;
acionar mecanismos de proteção;
gerar números sem valor analítico.
Como experimento controlado, pode ser interessante.
Como estratégia permanente, deve ser usado com extremo cuidado.
44. O carregamento de 0 segundos e o de 30 segundos
Se uma página é carregada imediatamente e outra após 30 segundos, elas podem ser contabilizadas separadamente.
Tudo depende de:
como o iframe é implementado;
qual ferramenta mede o acesso;
se o primeiro carregamento foi concluído;
se o script de analytics executou;
se a navegação seguinte cancelou eventos;
se a resposta veio de cache;
se a aba permaneceu ativa.
Uma ferramenta no lado do servidor pode registrar ambos os GETs.
Uma ferramenta JavaScript pode perder o primeiro evento se a página for substituída antes do envio.
Uma ferramenta pode deduplicar acessos semelhantes.
Outra pode considerar cada URL uma visualização diferente.
Não existe um contador universal observando a verdade absoluta.
Cada sistema enxerga sua própria camada.
45. Cache pode esconder uma requisição?
Sim e não.
Se o navegador possui uma cópia válida e reutiliza o recurso sem consultar o servidor, o servidor de origem pode não receber uma nova requisição.
Porém, o navegador ainda “carregou” o recurso do ponto de vista da página.
Se houver revalidação, o servidor poderá receber uma requisição condicional e responder 304.
Se uma CDN atender o pedido, a origem pode não perceber cada acesso individual.
Se o analytics roda no navegador, ele pode registrar uma visualização mesmo quando o HTML ou imagens vieram de cache.
Por isso os números divergem.
É a velha diferença entre:
recurso solicitado;
recurso entregue;
página renderizada;
evento de analytics enviado;
visita humana.
46. HTTP/2 e HTTP/3: a guilda evoluiu
No HTTP/1.1, navegadores frequentemente utilizavam múltiplas conexões para carregar recursos em paralelo.
HTTP/2 trouxe multiplexação: várias requisições podem compartilhar uma única conexão.
HTTP/3 utiliza QUIC sobre UDP e incorpora recursos modernos de transporte e segurança.
Isso significa que a relação:
uma requisição = uma conexão TCP
não é sempre verdadeira.
Uma mesma conexão pode transportar diversos recursos.
Além disso, conexões podem ser reutilizadas.
Portanto, contar conexões não equivale a contar páginas.
Contar pacotes também não equivale a contar usuários.
Contar usuários continua sendo a missão de nível impossível que Kazuma jamais deveria ter aceitado.
47. Keep-Alive
Com conexão persistente, o navegador pode reutilizar a mesma sessão para solicitar:
HTML
CSS
JavaScript
Imagem 1
Imagem 2
Fonte
Isso reduz a necessidade de novos handshakes.
O resultado é menor latência e melhor desempenho.
Em vez de Darkness bater na porta da cidade para cada objeto, ela permanece na entrada dizendo:
Ainda estamos juntos. Pode mandar o próximo monstro.
48. Compressão
Servidores podem comprimir conteúdo antes de enviá-lo.
Cabeçalhos como:
Accept-Encoding: gzip, br
indicam formatos aceitos.
A resposta pode conter:
Content-Encoding: br
HTML, CSS e JavaScript costumam comprimir muito bem.
Uma página de 200 KB pode trafegar usando bem menos bytes.
Imagens JPEG e PNG normalmente já possuem compressão própria.
Comprimir novamente pode trazer pouco benefício.
49. Latência
Latência é o tempo necessário para os dados atravessarem o caminho entre cliente e servidor.
Ela é influenciada por:
distância;
qualidade da rede;
roteamento;
congestionamento;
número de handshakes;
DNS;
TLS;
tempo de processamento;
cache;
perda de pacotes.
Um servidor rápido do outro lado do planeta ainda pode apresentar atraso perceptível.
É por isso que CDNs são tão valiosas.
Elas aproximam o conteúdo do usuário.
50. Time to First Byte
TTFB, Time to First Byte, mede quanto tempo decorre entre a solicitação e a chegada do primeiro byte da resposta.
Ele inclui componentes como:
DNS;
conexão;
TLS;
viagem pela rede;
espera;
processamento do servidor.
TTFB alto pode indicar:
servidor lento;
distância elevada;
congestionamento;
cache ausente;
infraestrutura ocupada.
Mas não mede o tempo total de renderização.
Uma página pode ter TTFB excelente e ainda demorar por causa de:
imagens enormes;
JavaScript pesado;
iframes;
fontes;
widgets;
scripts externos.
51. Observabilidade no lado do cliente
JavaScript pode medir diversos eventos usando APIs do navegador.
Exemplo:
window.addEventListener("load", () => {
console.log("Página carregada");
});
A Performance API pode fornecer informações mais detalhadas:
const nav = performance.getEntriesByType("navigation")[0];
console.log({
dns: nav.domainLookupEnd - nav.domainLookupStart,
conexao: nav.connectEnd - nav.connectStart,
resposta: nav.responseEnd - nav.responseStart,
total: nav.loadEventEnd - nav.startTime
});
Esses dados ajudam a entender a experiência do navegador.
Mas devem ser usados com responsabilidade.
Evite coletar informações desnecessárias ou identificáveis.
Observabilidade não deve virar vigilância.
52. Privacidade
Ao analisar visitantes, colete apenas o necessário.
Tenha cuidado com:
endereços IP;
identificadores persistentes;
cookies;
fingerprinting;
localização;
histórico de navegação;
dados pessoais;
combinações que identifiquem indivíduos.
Uma análise útil pode trabalhar com dados agregados:
País aproximado
Faixa de permanência
Tipo de navegador
Página acessada
Horário
Execução ou não de JavaScript
Quanto mais granular o rastreamento, maior a responsabilidade.
O objetivo deve ser entender o sistema, não perseguir aventureiros pela cidade de Axel.
53. Como diferenciar humano, crawler simples e navegador automatizado
Podemos construir uma classificação aproximada.
Crawler simples
Características possíveis:
recebe apenas HTML;
não carrega imagens;
não executa JavaScript;
permanece poucos milissegundos;
visita muitas URLs rapidamente;
identifica-se no User-Agent.
Navegador automatizado
Pode:
executar JavaScript;
carregar imagens;
esperar temporizadores;
rolar a página;
simular interações;
aceitar cookies.
Visitante humano
Pode:
navegar de forma irregular;
rolar seletivamente;
clicar em links;
alternar abas;
voltar depois;
permanecer tempos variáveis;
cometer movimentos imprevisíveis.
Entretanto, essas categorias se sobrepõem.
A melhor abordagem é calcular uma pontuação de probabilidade, não declarar uma verdade absoluta.
54. Exemplo de classificação simples
Podemos imaginar uma pontuação:
Executou JavaScript: +2 pontos
Permaneceu 30 segundos: +2
Rolou a página: +2
Clicou: +3
Carregou imagens: +1
Visitou 100 páginas em 1 minuto: -5
User-Agent conhecido como bot: -5
Resultado:
6 ou mais: provável humano
1 a 5: indeterminado
0 ou menos: provável automação
Isso é apenas um exemplo didático.
Bots sofisticados podem enganar o sistema.
Usuários reais podem ser classificados incorretamente.
Nunca use uma regra assim isoladamente para decisões críticas.
55. País e permanência
Separar acessos por país e tempo pode revelar padrões interessantes.
Exemplo:
Brasil:
0–5s: 200
5–30s: 150
30s+: 300
Singapura:
0–5s: 4000
5–30s: 800
30s+: 20
Esse padrão poderia sugerir automação rápida.
Agora imagine:
Singapura:
0–5s: 4000
5–30s: 3500
30s+: 3000
Isso poderia indicar:
navegador automatizado;
página deixada aberta;
infraestrutura de análise;
teste sintético;
execução prolongada de JavaScript.
Ainda não provaria audiência humana.
Mas seria um indício diferente.
56. O comportamento temporal é valioso
Bots costumam ser consistentes.
Humanos costumam ser caóticos.
Um robô pode acessar:
12:00:00
12:00:05
12:00:10
12:00:15
Um humano pode acessar:
12:00:03
12:02:47
12:09:21
13:18:02
Padrões excessivamente regulares podem indicar automação.
Também vale observar:
mesma sequência de URLs;
mesmos intervalos;
mesmo tamanho de resposta;
repetição diária;
acessos em blocos;
comportamento exatamente sincronizado.
Você gosta de padrões.
E a web é uma floresta inteira deles.
57. Crawlers não são necessariamente inimigos
Um crawler pode trazer benefícios:
indexar seu artigo;
aumentar descoberta;
atualizar resultados de busca;
criar pré-visualizações;
encontrar links quebrados;
arquivar conteúdo;
alimentar ferramentas de pesquisa.
Bloquear todos os bots seria como expulsar todos os aventureiros da guilda porque alguns quebraram as cadeiras da taverna.
O ideal é distinguir:
bots úteis;
bots neutros;
bots excessivos;
bots maliciosos.
58. O que torna um crawler educado?
Um crawler bem-comportado costuma:
identificar-se;
respeitar
robots.txt;limitar frequência;
evitar sobrecarregar servidores;
armazenar cache;
usar requisições condicionais;
respeitar códigos 429 e 503;
fornecer informações sobre sua finalidade.
Um crawler agressivo pode:
ocultar identidade;
ignorar regras;
alterar User-Agent;
rotacionar IPs;
acessar milhares de páginas;
baixar repetidamente o mesmo conteúdo;
provocar carga desnecessária.
No Blogspot, boa parte da defesa operacional é responsabilidade da infraestrutura do Google.
Mas o tráfego ainda pode aparecer em estatísticas.
59. Segurança em camadas
A segurança da página pode ser entendida em camadas.
Rede
Proteção contra:
interceptação;
ataques volumétricos;
conexões maliciosas.
Transporte
TLS protege o conteúdo da comunicação.
Plataforma
O Blogspot gerencia:
servidores;
atualizações;
infraestrutura;
disponibilidade;
parte das defesas.
Aplicação
O autor deve cuidar de:
scripts;
widgets;
iframes;
links;
formulários;
conteúdo incorporado.
Conta
É necessário proteger:
senha;
recuperação;
autenticação multifator;
sessões;
permissões.
O maior firewall do mundo não ajuda se alguém roubar a conta do autor.
60. A conta Google é a chave do castelo
Para proteger o blog:
use autenticação em dois fatores;
revise dispositivos conectados;
evite senhas reutilizadas;
desconfie de páginas falsas;
revise permissões de aplicativos;
mantenha e-mail e telefone de recuperação atualizados;
evite extensões de navegador suspeitas.
Um invasor com acesso à conta pode:
alterar postagens;
inserir scripts;
apagar conteúdo;
redirecionar visitantes;
modificar o tema;
incluir administradores.
Isso é muito mais perigoso que um crawler lendo artigos públicos.
61. Backup continua sendo necessário
Mesmo em uma plataforma gerenciada, mantenha cópias do conteúdo.
A regra 3-2-1 continua excelente:
três cópias;
dois tipos de mídia;
uma cópia fora do ambiente principal.
Faça backup de:
postagens;
tema;
imagens originais;
scripts;
documentos-fonte;
metadados importantes.
Blogspot não elimina a necessidade de preservação.
Ele apenas transfere parte da operação da infraestrutura.
Um Padawan prudente nunca confia seu Holocron a uma única nave.
62. O que um GET informa ao mundo?
Uma requisição GET pode revelar, dependendo da camada:
IP de origem;
destino;
horário;
URL, para quem termina a conexão HTTPS;
User-Agent;
idioma preferido;
referenciador;
cookies;
formatos aceitos;
volume transferido;
padrão de navegação.
Intermediários comuns em uma conexão HTTPS não enxergam necessariamente todo o conteúdo HTTP em texto claro.
Mas o navegador e o servidor enxergam.
Serviços adicionados à página também podem receber informações.
Por exemplo, uma imagem hospedada externamente faz o navegador contatar outro domínio.
Esse domínio pode observar a requisição daquela imagem.
63. Recursos externos aumentam a superfície de observação
Suponha que uma página carregue:
HTML do Blogspot;
imagem de um serviço externo;
fonte de outro domínio;
vídeo do YouTube;
contador gratuito;
widget meteorológico;
script de compartilhamento.
O visitante não conversa apenas com o Blogspot.
Ele conversa com vários fornecedores.
Cada um pode possuir:
logs;
cookies;
métricas;
políticas;
mecanismos de cache;
sistemas de segurança.
Quanto mais dependências externas, maior a complexidade.
Também aumenta a chance de:
lentidão;
falha;
bloqueio;
divergência de métricas;
coleta de dados;
quebra futura.
64. Contadores gratuitos
Contadores gratuitos costumam variar muito.
Alguns registram apenas:
número de visualizações;
visitantes aproximados;
país;
navegador;
sistema operacional.
Outros podem capturar:
URL;
referenciador;
resolução;
idioma;
horário;
duração;
IP ou hash;
eventos de navegação.
O problema é que você precisa confiar no fornecedor.
Antes de utilizar um contador, analise:
política de privacidade;
reputação;
HTTPS;
scripts carregados;
cookies;
retenção de dados;
transparência;
impacto no desempenho.
Um contador gratuito pode ser gratuito porque o produto real é a informação coletada.
Kazuma chamaria isso de:
Missão sem recompensa, porém com contrato escrito em letra minúscula.
65. Seu experimento do pote de mel
Uma página criada para observar crawlers funciona como um pequeno honeypot de pesquisa.
Ela pode possuir:
pouca divulgação;
links controlados;
marcadores temporais;
eventos JavaScript;
URLs únicas;
recursos específicos.
Quando surgem acessos inesperados, você consegue estudar:
velocidade de descoberta;
origem aproximada;
frequência;
execução de scripts;
permanência;
sequência de navegação.
Isso pode revelar ecossistemas automatizados interessantes.
Porém, devemos distinguir um honeypot experimental de uma armadilha maliciosa.
O objetivo deve ser observar, não atacar, explorar ou coletar dados pessoais indevidos.
66. Como uma URL secreta pode ser descoberta?
Mesmo sem divulgação pública, uma URL pode vazar ou ser descoberta através de:
sitemap;
feed;
links internos;
tema do blog;
JavaScript;
histórico de navegação sincronizado;
extensões;
serviços de segurança;
pré-visualizadores;
ferramentas de analytics;
indexadores;
logs de terceiros;
referenciadores;
mecanismos de descoberta da própria plataforma.
Uma URL publicada em uma página pública raramente é verdadeiramente secreta.
Se o conteúdo não pode ser visto, ele deve exigir autenticação.
“Não divulgar o link” não é controle de acesso.
67. A reutilização de conteúdo
Quando uma página é acessada, diferentes sistemas podem reutilizar o conteúdo de formas distintas:
cache temporário;
indexação;
snippets de busca;
pré-visualizações;
arquivamento;
análise de segurança;
treinamento ou recuperação de IA, conforme políticas e permissões;
agregação de feeds;
monitoramento.
Essa reutilização não ocorre porque os pacotes “se reproduzem” por magia.
Ela ocorre porque aplicações recebem o conteúdo e tomam decisões.
O pacote é apenas o mensageiro.
Quem replica, armazena e processa são os sistemas nas extremidades ou intermediários autorizados.
68. Pacotes não têm memória própria
Um pacote IP não sabe:
se a página é famosa;
se o conteúdo é COBOL;
se o visitante é humano;
se o artigo ficou “quente”;
se deve chamar outro crawler.
Ele contém informações necessárias para transporte.
Quem interpreta contexto são sistemas superiores.
Por exemplo:
CDN conta acessos;
algoritmo identifica popularidade;
crawler agenda revisita;
mecanismo de busca aumenta frequência;
firewall detecta anomalia;
analytics gera relatório.
A inteligência não está no pacote.
Está nos sistemas que observam o fluxo.
69. O efeito cascata da popularidade
Uma página pode entrar em um ciclo:
é publicada;
aparece no feed;
crawler encontra;
mecanismo indexa;
resultado aparece na busca;
usuários acessam;
redes sociais geram previews;
outros crawlers descobrem;
ferramentas de SEO analisam;
sistemas de IA recuperam;
caches são preenchidos;
novas referências surgem.
Nesse sentido, uma requisição pode indiretamente contribuir para outras.
Não porque o TCP replicou o pacote.
Mas porque o acesso gerou sinais e registros em aplicações.
Uma faísca pode chamar atenção.
A faísca não criou o incêndio sozinha.
Megumin, porém, certamente alegará que foi responsável por tudo.
70. O que significa uma página estar “quente”?
“Quente” pode significar:
acessada frequentemente;
recentemente atualizada;
crescendo em popularidade;
recebendo links;
sendo compartilhada;
apresentando padrão anormal;
consumindo muitos recursos.
Diferentes sistemas tratam calor de maneiras diferentes.
Uma CDN pode manter o conteúdo em cache.
Um buscador pode rastrear com maior frequência.
Um sistema de segurança pode aumentar inspeção.
Um algoritmo de recomendação pode testar a página para mais usuários.
Uma ferramenta de observabilidade pode disparar alertas.
Não existe um termômetro único da internet.
Existem milhares de termômetros independentes.
71. Correlação não é causalidade
Suponha que você publique uma página.
Cinco minutos depois, aparecem cem acessos.
Isso não prova que um crawler específico causou todos eles.
Pode haver:
feed atualizado;
sitemap processado;
pré-visualização;
compartilhamento;
cache warming;
monitoramento;
robô da plataforma;
crawler externo.
A investigação precisa comparar:
tempos;
cabeçalhos;
padrões;
URLs;
países;
recursos carregados;
comportamento JavaScript.
Sherlock Holmes diria:
Quando eliminamos o impossível, precisamos tomar cuidado para não chamar de certeza aquilo que ainda é apenas provável.
72. Um modelo mental para o Padawan
Sempre separe a análise em cinco perguntas.
1. Quem pediu?
Possibilidades:
humano;
navegador automatizado;
crawler simples;
proxy;
serviço de segurança;
CDN;
ferramenta de SEO.
2. O que foi pedido?
HTML;
imagem;
JavaScript;
feed;
sitemap;
iframe;
metadado.
3. Onde foi atendido?
navegador;
cache local;
CDN;
proxy;
servidor de origem;
plataforma.
4. O que foi medido?
GET;
resposta;
JavaScript;
visualização;
evento;
sessão;
tempo.
5. O que podemos concluir?
certeza;
forte indício;
possibilidade;
hipótese;
informação insuficiente.
Essa disciplina evita transformar números estranhos em teorias cósmicas prematuras.
73. Um exemplo completo da jornada
Vamos acompanhar uma visita.
O usuário abre a página.
Etapa 1 — DNS
O navegador procura o IP do domínio.
Etapa 2 — Conexão
Cria uma conexão com a infraestrutura.
Etapa 3 — TLS
Negocia criptografia e valida o certificado.
Etapa 4 — GET
Solicita o HTML.
Etapa 5 — Cache
A infraestrutura verifica se possui uma cópia pronta.
Etapa 6 — Resposta
Envia o HTML com código 200.
Etapa 7 — Parse
O navegador interpreta o documento.
Etapa 8 — Recursos
Baixa CSS, imagens, JavaScript e iframes.
Etapa 9 — Execução
Scripts iniciam simuladores, contadores e temporizadores.
Etapa 10 — Renderização
A página aparece.
Etapa 11 — Observabilidade
Eventos são enviados a ferramentas de métricas.
Etapa 12 — Interação
O usuário rola, clica ou abandona a aba.
Cada etapa pode falhar.
Cada etapa pode ser medida por uma ferramenta diferente.
74. E se for um crawler simples?
O crawler pode:
consultar DNS;
abrir conexão;
negociar HTTPS;
enviar GET;
receber HTML;
extrair links;
encerrar.
Ele talvez não carregue:
imagens;
CSS;
scripts;
iframes.
Nesse caso:
o contador do servidor pode registrar;
o JavaScript de permanência não executa;
o Google Analytics pode não registrar;
o tempo observado pode ser inferior a um segundo.
Isso explicaria muitos acessos rápidos.
75. E se for um crawler com navegador?
Ele pode:
abrir a página;
executar JavaScript;
carregar imagens;
esperar 30 segundos;
capturar o DOM;
extrair conteúdo;
encerrar.
Nesse caso, ele pode disparar seus temporizadores.
Sua ferramenta pode concluir:
Visitante permaneceu 30 segundos.
Mas o visitante era um processo automatizado.
A duração separa alguns bots simples.
Não separa todos os bots.
76. E se for uma pré-visualização?
Um serviço pode:
solicitar o HTML;
procurar Open Graph;
baixar a imagem principal;
criar o cartão;
encerrar.
Talvez não execute todo o JavaScript.
Talvez faça múltiplas requisições.
Talvez repita o processo para atualizar a prévia.
O usuário ainda não clicou.
Mesmo assim, as estatísticas podem mostrar atividade.
77. O crawler lê o conteúdo inteiro?
Depende.
Ele pode:
baixar tudo;
interromper após certo tamanho;
ignorar partes;
extrair apenas texto;
focar nos metadados;
renderizar a página;
seguir somente alguns links;
armazenar uma representação parcial.
Também pode respeitar limites internos de:
tempo;
tamanho;
profundidade;
prioridade;
orçamento de rastreamento.
Um artigo gigantesco pode ser baixado por completo, parcialmente ou processado em estágios.
78. Crawl budget
Mecanismos de busca possuem recursos limitados.
Eles não podem visitar todas as páginas da internet continuamente.
Por isso, calculam prioridades.
Fatores possíveis incluem:
popularidade;
frequência de atualização;
qualidade percebida;
velocidade do servidor;
erros;
estrutura interna;
duplicidade;
importância da URL.
Um blog com milhares de páginas pode não ser rastreado integralmente todos os dias.
O crawler escolhe missões.
E, como Kazuma, tenta evitar as que parecem custar muito e recompensar pouco.
79. Links internos ajudam crawlers
Uma boa estrutura interna facilita a descoberta.
Use:
categorias;
marcadores;
páginas de índice;
links entre artigos;
breadcrumbs;
sitemap;
títulos descritivos.
Isso ajuda tanto humanos quanto robôs.
Uma página órfã, sem links, é mais difícil de descobrir.
Mas ainda pode aparecer por feed, sitemap ou serviços externos.
80. JavaScript demais pode dificultar a aventura
Um crawler capaz de renderizar JavaScript ainda possui custos e limites.
Se o conteúdo principal depende completamente de scripts complexos, pode ocorrer:
atraso na indexação;
renderização incompleta;
falha de execução;
conteúdo invisível para crawlers simples;
pior desempenho em dispositivos modestos.
Para artigos do Blogspot, mantenha o conteúdo principal em HTML.
Use JavaScript para:
interatividade;
animações;
simuladores;
melhorias.
Não esconda todo o texto essencial dentro de um script.
A espada deve continuar sendo uma espada mesmo quando o encantamento falha.
81. Conteúdo estruturado
Dados estruturados ajudam mecanismos a compreender o conteúdo.
Exemplo:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "GET, TCP/IP e Crawlers",
"description": "Guia didático sobre redes e observabilidade."
}
</script>
Isso não garante posicionamento.
Mas fornece contexto.
É como entregar ao aventureiro:
nome da missão;
nível recomendado;
recompensa;
localização;
risco de sapos gigantes.
Sem isso, ele precisa deduzir tudo sozinho.
82. O que não fazer em nome de métricas
Evite:
recarregar páginas artificialmente;
abrir dezenas de iframes invisíveis;
simular permanência falsa;
disparar eventos sem interação;
criar loops de navegação;
mascarar tráfego automatizado;
coletar dados excessivos;
inserir scripts desconhecidos.
Essas práticas podem:
distorcer seus próprios experimentos;
prejudicar usuários;
aumentar consumo;
acionar defesas;
reduzir confiança;
confundir mecanismos de busca.
A melhor observabilidade começa com dados honestos.
Caso contrário, você vira o próprio monstro que estava tentando estudar.
83. Um laboratório ético para estudar crawlers
Você pode criar uma página experimental com:
URL exclusiva;
texto explicando o experimento;
marcações temporais;
eventos agregados;
ausência de dados pessoais;
links controlados;
recursos leves;
duração limitada.
Métricas possíveis:
HTML solicitado
JavaScript executado
Evento em 5 segundos
Evento em 30 segundos
Página visível
Rolagem detectada
Clique detectado
País aproximado
User-Agent resumido
Evite armazenar identificadores individuais por tempo desnecessário.
O objetivo é estudar padrões gerais.
Não identificar pessoas.
84. Exemplo de script didático de observação
<script>
(() => {
const estado = {
iniciouEm: Date.now(),
rolou: false,
clicou: false,
visivel: document.visibilityState === "visible"
};
window.addEventListener("scroll", () => {
estado.rolou = true;
}, { once: true });
document.addEventListener("click", () => {
estado.clicou = true;
}, { once: true });
document.addEventListener("visibilitychange", () => {
estado.visivel = document.visibilityState === "visible";
});
function registrar(faixa) {
const dados = {
faixa,
tempoMs: Date.now() - estado.iniciouEm,
rolou: estado.rolou,
clicou: estado.clicou,
visivel: estado.visivel
};
console.log("Observabilidade:", dados);
}
setTimeout(() => registrar("5s"), 5000);
setTimeout(() => registrar("30s"), 30000);
})();
</script>
Esse exemplo apenas registra no console.
Para enviar dados a um servidor, seria necessário um endpoint adequado e uma política de privacidade coerente.
85. sendBeacon ao sair
Eventos tradicionais podem ser cancelados quando a aba fecha.
A API sendBeacon foi criada para enviar pequenos volumes de telemetria de forma mais confiável:
navigator.sendBeacon(
"/endpoint",
JSON.stringify({
evento: "saida",
tempo: Date.now()
})
);
Mas no Blogspot você não possui automaticamente um endpoint próprio para receber esses dados.
Seria necessário usar um serviço externo.
Isso adiciona:
dependência;
custo;
privacidade;
segurança;
manutenção.
Nem toda métrica merece uma arquitetura distribuída.
Às vezes, uma planilha e um café resolvem.
86. A diferença entre monitoramento e observabilidade
Monitoramento responde perguntas conhecidas:
o blog está disponível?
quantos acessos ocorreram?
a taxa de erro aumentou?
o tempo de resposta piorou?
Observabilidade ajuda a investigar perguntas novas:
por que Singapura gerou quatro mil acessos?
por que o HTML foi contado, mas o JavaScript não?
por que houve tráfego sem permanência?
por que certas páginas são revisitadas em intervalos regulares?
Monitoramento verifica o painel.
Observabilidade permite formular hipóteses.
É a diferença entre olhar o alarme do CICS e investigar o SMF até encontrar o programa que iniciou o caos.
87. Não existe visão completa
O dono de uma página não enxerga:
todos os roteadores;
todos os proxies;
todos os caches;
todos os logs;
todos os sistemas de segurança;
todas as decisões dos crawlers;
toda a infraestrutura do provedor.
Você observa uma projeção.
O visitante também observa outra.
O Google observa outra.
O provedor de internet observa outra.
Cada camada possui parte da verdade.
Um bom investigador não confunde o pedaço disponível com o universo inteiro.
88. A grande lição sobre números
Suponha que o painel mostre:
4.000 acessos de Singapura
1.000 carregamentos completos
200 execuções de JavaScript
30 permanências acima de 30 segundos
Isso pode significar:
muitas requisições simples;
poucos navegadores completos;
poucos eventos prolongados;
mistura de bots e humanos;
bloqueio de scripts;
respostas atendidas por cache;
ferramentas medindo pontos diferentes.
Não devemos dizer:
O painel está errado.
Nem:
São quatro mil leitores.
A conclusão responsável seria:
Houve quatro mil eventos classificados como acesso de Singapura por determinada ferramenta. Apenas uma parte apresentou sinais compatíveis com carregamento completo e permanência.
Essa frase é menos emocionante.
Mas é tecnicamente muito mais poderosa.
89. Checklist do Padawan investigador
Ao encontrar tráfego estranho, verifique:
quais URLs foram acessadas;
em quais horários;
qual foi a frequência;
quais países apareceram;
se o JavaScript executou;
se imagens foram carregadas;
se houve rolagem;
se houve cliques;
se a aba ficou visível;
se o padrão se repetiu;
se o acesso veio após feed ou sitemap;
se houve compartilhamento;
se o User-Agent se identificou;
se o comportamento parece regular;
se diferentes ferramentas concordam.
Depois, formule hipóteses.
Nunca comece pela conclusão.
90. O paralelo com o mainframe
Toda essa discussão parece moderna, mas o espírito é antigo.
No mainframe também perguntamos:
quem iniciou a transação?
qual recurso foi acessado?
quanto tempo levou?
qual subsistema respondeu?
houve cache?
ocorreu contenção?
o evento foi humano ou batch?
qual log possui a verdade?
o dado foi contabilizado em qual camada?
No CICS:
Uma transação não é apenas uma tela.
Na web:
Uma visita não é apenas uma página.
No z/OS, você correlaciona:
job;
step;
programa;
dataset;
SMF;
WLM;
Db2;
CICS.
Na web, você correlaciona:
URL;
sessão;
IP;
User-Agent;
tempo;
recurso;
cache;
evento JavaScript;
origem.
A tecnologia muda.
O método investigativo permanece.
91. O mainframe secreto por trás da internet
A internet é distribuída, caótica e global.
Mas sua operação continua baseada em princípios familiares:
filas;
protocolos;
buffers;
logs;
identificadores;
códigos de retorno;
controle de acesso;
recuperação;
desempenho;
capacidade;
rastreabilidade.
Um código HTTP 500 não está tão distante de um return code inesperado.
Um timeout lembra uma transação CICS aguardando recurso.
Um crawler agressivo lembra um job batch lendo datasets sem descanso.
Uma CDN lembra um mecanismo de distribuição e cache.
Um trace distribuído lembra a correlação de registros SMF.
No fundo, toda infraestrutura séria termina se comportando como um mainframe que aprendeu a usar tênis coloridos.
92. Conclusão: o GET que abriu um portal
Quando alguém acessa uma página do Blogspot, o navegador não simplesmente “abre um texto”.
Ele inicia uma expedição.
O DNS encontra o destino.
O TCP organiza a comunicação.
O IP transporta pacotes.
O TLS protege o caminho.
O HTTP envia o GET.
A infraestrutura do Google localiza ou produz a resposta.
O cache acelera a entrega.
O navegador interpreta HTML, CSS e JavaScript.
Ferramentas de observabilidade registram partes da jornada.
Crawlers, serviços de segurança, pré-visualizadores e indexadores podem repetir o processo sem qualquer leitor humano.
Uma requisição pode gerar sinais.
Esses sinais podem alimentar caches, filas, índices, mecanismos de segurança e sistemas de análise.
Mas os pacotes não possuem vontade própria.
Eles não decidem que uma página é importante.
Eles apenas transportam mensagens.
Quem decide são os sistemas construídos ao redor deles.
A grande habilidade do Padawan não é decorar cada cabeçalho HTTP.
É aprender a fazer perguntas corretas:
Quem enviou a requisição?
Qual recurso foi realmente carregado?
Em qual camada ocorreu a contagem?
O JavaScript executou?
A resposta veio de cache?
O comportamento é humano, automatizado ou apenas inconclusivo?
Ao dominar essas perguntas, você deixa de enxergar “quatro mil acessos misteriosos”.
Você passa a enxergar:
fluxos;
camadas;
padrões;
hipóteses;
evidências.
E esse é o momento em que o Padawan percebe que nunca esteve apenas escrevendo um blog.
Ele construiu um pequeno observatório na borda da internet.
Kazuma olha para os gráficos.
Aqua comemora quatro mil leitores em Singapura.
Darkness pede para ser atingida por mais pacotes TCP.
Megumin prepara uma nova cascata de iframes.
E o velho Mestre Bellacosa, segurando uma xícara de café, apenas responde:
Calma, aventureiros. Primeiro vamos conferir os logs.
