O servidor não retornará algumas solicitações para um único ISP

Question

Eu tenho um servidor Linode que não retorna pedidos GET aleatórios para o meu provedor usual (mas nunca fica preso ao mesmo de cada vez). Se eu mudar de provedor ou usar o Opera VPN , tudo funciona bem.

Linode diz que tudo parece ok para eles. Os recursos do servidor são bons (é um servidor de desenvolvimento que está sendo usado apenas para testes no momento, portanto, um tráfego muito leve e sobrecarga). Eles dizem para verificar com o meu provedor. Meu ISP diz que tudo parece bom para eles, mas eles terão engenheiros para analisar isso.

Como estou esperando uma resposta do ISP 'não encontramos nada', estou tentando encontrar evidências objetivas do que está acontecendo com meu conhecimento muito limitado de diagnosticar isso. Eu espanquei o Wireshark e comecei o diagnóstico.

Se eu usar o problema ISP, do ponto de vista do navegador, é um pouco aleatório. Às vezes, uma página é carregada bem, às vezes carrega bem, mas outros recursos não carregam (css, js, jpeg etc.). Às vezes, a própria página não é carregada e permanece "carregando" indefinidamente, sem uma resposta do servidor.

Diagnóstico:

http.time > 1 em Wireshark confirmou que o problema não é tanto tempo limite quanto tempo de carregamento, mais que uma solicitação seja carregada ou não.

Meus cabeçalhos não mostram nada incomum, por exemplo:

GET /theme/css/style.css HTTP/1.1
Host:site.com
Accept:text/css,*/*;q=0.1
Accept-Language:en-ie
Accept-Encoding:gzip, deflate
Connection:keep-alive
Pragma:no-cache
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30
Referer:http%3a//site.com/section/
DNT:1
Cache-Control:no-cache

Quando eu capturar com o Wireshark , não vejo muito feedback quando uma solicitação fica no navegador. No entanto, da última vez que tentei, recebi uma solicitação de reoccuração de:

localhost   server  TCP 66  [TCP Retransmission] 61162 → 80 [FIN, ACK]

transmitido a cada minuto, até terminar com [RST, ACK] no final, embora o navegador ainda mostrasse a página presa no carregamento.

Mais informações:

• O cache foi desativado em todos os testes, mas o cache foi esvaziado também, bem como o dns de limpeza.
• Isso é provavelmente irrelevante, pois esse resultado está acontecendo em todos os dispositivos e navegadores na rede, usando a conexão padrão do provedor de serviços de Internet.
• Qualquer outro ISP ou VPN que eu testei carrega todas as solicitações do servidor usando os mesmos dispositivos e navegadores.
• Eu restaurei o firmware do modem e do roteador, de acordo com o procedimento de diagnóstico padrão do meu ISP
• Tentei mudar o DNS para o Google.
• Eu atualizei todos os pacotes no servidor (que é o Ubuntu executando o Apache)
• Além dessas atualizações serem executadas após o início desse problema, não alterei nenhuma configuração ou atualização no servidor. Está em funcionamento há cerca de dois meses e isso começou a acontecer há dois dias.
• O diagnóstico está sendo feito em http regular
• Eu faço muitos pedidos para o servidor para fins de desenvolvimento e, perguntando ao meu ISP se isso poderia ter acionado algum sinalizador de atividade - eles me garantiram que não há nada parecido com isso.
• Não posso listar o servidor aqui, infelizmente.
• não tenho problemas com outros sites.
• A velocidade e a latência do ISP não são um problema.
• Todos os três virtualhosts em execução no servidor são afetados, embora existam apenas para redirecionar subdomínios ou solicitações http para https, pois o mesmo domínio é usado em todo o processo.

Atualizar

Diagnóstico:

Eu tentei executar verbose curl solicitações para ativos individuais no servidor (um jpeg neste caso). Meu pedido para baixar o jpeg correu ok as três primeiras vezes, a única anomalia (a menos que seja esperado?) É que a quantidade de bytes que estão sendo baixados para o mesmo arquivo seria alterada em algumas solicitações. Por exemplo:

pedido de curl 1:

< Content-Type: image/jpeg
< 
{ [2642 bytes data]
* Curl_http_done: called premature == 0
100  384k  100  384k    0     0   994k      0 --:--:-- --:--:-- --:--:--  995k

pedido de curl 2:

< Content-Type: image/jpeg
< 
{ [1194 bytes data]
* Curl_http_done: called premature == 0
100  384k  100  384k    0     0   852k      0 --:--:-- --:--:-- --:--:--  853k

pedido de curvar 3:

< Content-Type: image/jpeg
< 
{ [2642 bytes data]
 26  384k   26  101k    0     0   493k      0 --:--:-- --:--:-- --:--:--  493k
* Curl_http_done: called premature == 0
100  384k  100  384k    0     0  1000k      0 --:--:-- --:--:-- --:--:-- 1000k

E a quarta solicitação não faria o download do arquivo, reportaria um erro ou fecharia a conexão. O mesmo comportamento que vejo no navegador. Os bytes de dados estão presos em um temporizador em execução, aproximando-se de 2 minutos agora:

 Content-Type: image/jpeg
< 
{ [1194 bytes data]
  5  384k    5 22914    0     0     66      0  1:39:18  0:05:43  1:33:35     0

Parece que a solicitação está chegando ao servidor e as comunicações posteriores não chegam até mim. Aqui está a última solicitação completa (30 segundos depois):

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying (IP ADDRESS)...
* TCP_NODELAY set
  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0* Connected to serverdomain.com (IP ADDRESS) port 80 (#0)
  0     0    0     0    0     0      0      0 --:--:--  0:00:06 --:--:--     0> GET /images/user/176131.jpg HTTP/1.1
> Host: serverdomain.com
> User-Agent: curl/7.51.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Fri, 18 Aug 2017 14:04:20 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Last-Modified: Thu, 17 Aug 2017 09:04:47 GMT
< ETag: "60048-556ef4de2cad8"
< Accept-Ranges: bytes
< Content-Length: 393288
< Connection: close
< Content-Type: image/jpeg
< 
{ [1194 bytes data]
  5  384k    5 22914    0     0     50      0  2:11:05  0:07:36  2:03:29     0