Depois de fazer mais testes, descobri outra coisa que acontece (e acontece com mais frequencia, aparentemente, do que o que eu descrevi no texto anterior) com minha conexão: Existe um problema com a implementação do protocolo TCP/IP no dito proxy da Telefonica. Vou explicar com fantoches (pra ver se o pessoal da TeleAfonica entende):

Quem conhece provavelmente já reconheceu, mas essa é uma imagem do programa de monitoramento Ethereal, que eu usei pra fazer a captura dos pacotes e diagnosticar o problema. Essa imagem (chamemos de fig.1) mostra uma conexão completa e sem problemas. Meu IP foi escondido pelas tarjas pretas, por motivos óbvios. Vamos ao passo-a-passo:

toda comunicação que use o protocolo TCP começa da mesma forma:

1 - o cliente (no caso, o meu computador) pede ao servidor a abertura de uma conexao (ou sincronia), que acontece com o envio de um pacote com o flag SYN ligado (destacado em azul).

2 - O servidor, ao receber meu pedido (chamemos de "pacote SYN"), me envia uma mensagem dizendo que recebeu meu pedido e que está disposto a abrir a conexão. Isso acontece com o envio (pelo servidor) de um pacote com as flags SYN e ACK (do inglês "acknowledge", "entendido", e destacado em amarelo). Chamemos esse passo de "pacote SYN/ACK".

3 - O cliente (meu computador) responde ao servidor com uma mensagem dizendo que recebi sua resposta (com apenas a flag ACK ligada). Chamemos esse passo de "pacote ACK".

A isso se dá o nome de "three-way handshake", ou "aperto de mão em 3 etapas".

Imediatamente depois disso o cliente, no caso do protocolo HTTP, faz o pedido do conteúdo que deseja receber (a linha destacada em azul escuro), o servidor envia a resposta e a conexão é encerrada (pela troca de pacotes com a flag FIN ligada).

Pela definição do protocolo TCP, ao passar certa quantidade de tempo sem o recebimento da resposta esperada (timeout) para um devido pacote, esse pacote é re-enviado, assumindo que o pacote foi perdido. E é exatamente isso que causa o problema nos servidores da Telefonica, como demonstrado a seguir:

Essa imagem (fig.2) mostra uma conexão problemática, causada pelo erro na implementação TCP do cace da Telefonica. Vamos recapitular:

1 - o cliente (meu computador) pede ao servidor a abertura de uma conexão, com o envio do "pacote SYN".

2 - cerca de 3 segundos após o envio do primeiro pacote, e sem receber resposta, o cliente re-envia o "pacote SYN", com as mesmas características do anterior. Ele assumiu que o pacote foi perdido.

3 - o cliente recebe do servidor o "pacote SYN/ACK", sinalizando a abertura da conexão do lado do servidor.

4 - o cliente envia ao servidor o "pacote ACK", finalizando o "three-way handshake" e abrindo a conexão.

5 - o cliente faz o pedido do conteúdo desejado, utilizando o protocolo HTTP.

6 - aqui está o problema - o cliente recebe um segundo "pacote SYN/ACK", mas este é inválido - já existe uma conexão com essas configurações. Algo está errado.

7 - o cliente respode ao servidor com um "pacote RST" (de reset), pedindo que a conexão de onde se originou o pacote número 6 seja terminada.

O problema é que essa conexão é exatamente a conexão de onde o cliente espera receber o conteúdo pedido pelo protocolo HTTP (tem os mesmos endereços e portas), e a conexão é encerrada abruptamente (connection reset by peer), causando o erro que impossibilita que as páginas de web sejam visualizadas. A única maneira de conseguir acessar as páginas sem encontrar o erro é "fugir" do proxy HTTP da Telefonica (já que este simplesmente captura todo o tráfego para portas de HTTP), configurando no navegador um servidor proxy externo. E isso é ilustrado na próxima (e última) imagem:

Essa imagem (fig.3) mostra uma conexão com o mesmo reenvio do "pacote SYN" da anterior, mas com a resposta adequada do Servidor (um servidor proxy Squid externo, configurado no navegador):

1 - o cliente (meu computador) pede ao servidor a abertura de uma conexão, com o envio do "pacote SYN".

2 - cerca de 3 segundos depois, sem ter recebido resposta, o cliente re-envia o "pacote SYN", com as mesmas características do anterior. Ele assumiu a perda do pacote anterior.

3 - o cliente recebe do servidor a confirmação da abertura da conexão, o "pacote SYN/ACK".


A partir daí, acontece o mesmo que aconteceu no primeiro exemplo: o cliente pede o conteúdo (pelo protocolo HTTP), o recebe e a conexão é finalizada.

Reparem que, nesse exemplo, o segundo "pacote SYN" foi simplesmente ignorado pelo servidor - ele sabe que já existe uma abertura de conexão em andamento para o endereço e porta do cliente, e assume que o segundo pacote recebido é uma retransmissão. E é exatamente esse o comportamento esperado.

Eu, o usuário, fui obrigado (pela telefônica) não só a diagnosticar o problema como a documentá-lo. E a esperar (sem esperança, por mais paradoxal que pareça) uma solução por parte da empresa. Os servidores em questão são provavelmente antigos, e é possível que uma simples atualização do software resolva esse e muitos outros problemas da rede. Até lá nós, usuários PAGANTES dos serviços da Telefonica, somos prejudicados e tratados como imbecis. Mas eu vou deixar minhas reclamações dos últimos atendimentos da Telefonica pra outra hora. Prefiro conseguir dormir essa noite.