HTTPS lento / expirado enquanto o HTTP está funcionando normalmente

Question

tl: dr: o tráfego http funciona de maneira confiável e rápida, enquanto o tráfego de https não é confiável ou é extremamente lento (tempos de carregamento de 2 a 5 minutos). Detalhes abaixo.

Ei falha no servidor, eu tenho uma boa para você. Este é o começo da segunda semana em um novo local que se expandiu para incluir um 15º escritório regional na semana anterior à contratação.

O novo escritório está usando uma conexão MPLS celular temporária enquanto esperamos que as equipes recebam uma linha dura. O novo escritório está usando o mesmo hardware e firmware para mpls que o outro escritório 14, verificado várias vezes.

A filtragem da Web e o firewall ocorrem no nosso DC, que não está nesse novo local de escritório. Eu quero chamá-lo de rede hub e spoke, mas desde que eu fui contratado durante uma "limpeza" e a documentação é esparsa e eu nunca trabalhei em um ambiente tão complexo antes que eu não possa ter certeza.

O problema:

Os usuários têm um punhado de sites https que precisam usar para fazer seu trabalho. Esses sites não serão carregados regularmente, se tudo isso acontecer. Se eu tivesse que colocar um número nele, eles carregariam uma das 50 tentativas e não carregariam a próxima página. Uma parte estranha disso é que os cabeçalhos (navegador) e o URL serão carregados quase todas as vezes, mas nada mais será carregado além disso.

Enquanto isso, o http carrega normalmente.

Há um servidor (DC, servidor de arquivos, DNS) neste escritório (como todos os outros ramos) e tem problemas de replicação que podem estar relacionados a esse problema.

Verificamos o seguinte:

• AV / firewalls desativados em hosts
• Podemos fazer ping nos sites em questão o tempo todo
• Alteramos as configurações de SSL / TLS no IE várias vezes
• No filtro da Web, os registros mostram que todos os sites HTTPS estão autorizados a este ramo
• No firewall, os logs mostram que todo o tráfego HTTPS está sendo enviado através / não verificado para este ramo
• Nosso provedor MPLS encontrou um misconfig no roteador HQ MPLS, "fixo" isso, mas isso não forneceu qualquer alteração
• tráfego do pcap'd de uma estação de trabalho de teste; comunicação para esses sites existe, mas os hosts remotos enviam vidas por 5 minutos antes redefinindo a conexão que é quando vemos uma "página não pode ser exibido "erro

Eu ajustei, ajustei, toquei, leio logs, verificação dupla / tripla, chamo ISP e pesquiso por 4 dias, tentando tudo que posso encontrar e nada mudou (pior ou melhor).

Meu último pensamento é que pode ser a conexão MPLS celular lenta (1-3 Mbps; 12 usuários / 12 telefones VoIP / 1 servidor), mas eu continuo descartando isso porque eu sinto que isso também se apresentaria no tráfego HTTP.

    

Answer 1

Que bom que você tem uma solução para isso. Com base no que você descreveu, isso soa como um problema Descoberta do buraco negro da MTU do caminho .

Essencialmente, você pode ter um roteador em sua rota para a Internet que tenha um MTU menor que o padrão de 1500 Bytes (1500 provavelmente sendo usado por seus clientes e pelos servidores da Web com os quais eles estão conversando). Normalmente, isso não é um problema, porque quando um roteador recebe um pacote que é muito grande para enviar sua interface de próximo salto, ele solta o pacote e envia um pacote ICMP Fragmentation Needed de volta ao remetente. Este pacote ICMP inclui a MTU correta para que o remetente possa enviar todos os pacotes futuros no tamanho correto.

Os problemas surgem se os pacotes Fragmentation Required estiverem sendo descartados - talvez um roteador no caminho de encaminhamento tenha uma política excessivamente agressiva de controle de acesso. Isso faz com que o remetente envie pacotes grandes que são descartados, mas nenhum feedback está sendo enviado de volta - o remetente continuará tentando retransmitir os pacotes.

Se você observar isso no lado do cliente, não verá nenhum tráfego do remetente e começará a enviar testes do Keep Alive.

Da mesma forma que você descreveu, muitas vezes você descobrirá que o handshake TCP e a solicitação inicial GET passam pelo OK porque esses pacotes são geralmente pequenos. Não é até que o remetente tenha que começar a enviar pacotes de tamanho completo para que o problema se torne aparente.

Se este é o problema que você está enfrentando, você deve informar com veemência quem for responsável pelos roteadores no caminho de encaminhamento para NÃO descartar os pacotes ICMP Fragmentation Required - fazer isso pode e vai quebrar as coisas.

    

Answer 2

Encontramos um trabalho por aí (já que essa é uma conexão temporária ... por que não). Reduzir a MTU para 1200 na estação de trabalho e nas NICs do servidor eliminou completamente esse problema e acelerou as velocidades em cerca de duas vezes (passou de 1 a 3 Mbps para 5 a 7 Mbps).