Atualmente, estou usando uma caixa do Windows, executando o Chrome 27 no canal dev, e tenho o que acredito ser um número incomumente grande de conexões de escuta conectadas ao processo.
O comando a seguir retorna 268 portas de atendimento:
netstat -aon|find /i /c "11692"
( onde neste caso 11692 é o processo principal do chrome )
É assim que algumas das portas se parecem com o netstat:
UDP 0.0.0.0:62483 : 11692
UDP 0.0.0.0:62486 : 11692
UDP 0.0.0.0:62487 : 11692
UDP 0.0.0.0:62488 : 11692
UDP 0.0.0.0:62489 : 11692
UDP 0.0.0.0:62492 : 11692
UDP 0.0.0.0:62493 : 11692
UDP 0.0.0.0:62494 : 11692
UDP 0.0.0.0:62495 : 11692
UDP 0.0.0.0:62496 : 11692
UDP 0.0.0.0:62498 : 11692
UDP 0.0.0.0:62499 : 11692
UDP 0.0.0.0:62500 : 11692
UDP 0.0.0.0:62501 : 11692
UDP 0.0.0.0:62502 : 11692
UDP 0.0.0.0:62503 : 11692
UDP 0.0.0.0:62504 : 11692
UDP 0.0.0.0:62505 : 11692
UDP 0.0.0.0:62506 : 11692
UDP 0.0.0.0:62509 : 11692
UDP 0.0.0.0:62510 : 11692
UDP 0.0.0.0:62511 : 11692
UDP 0.0.0.0:62512 : 11692
UDP 0.0.0.0:62513 : 11692
UDP 0.0.0.0:62541 : 11692
UDP 0.0.0.0:62542 : 11692
UDP 0.0.0.0:62543 : 11692
UDP 0.0.0.0:62544 : 11692
UDP 0.0.0.0:62545 : 11692
UDP 0.0.0.0:62547 : 11692
UDP 0.0.0.0:62786 : 11692
UDP 0.0.0.0:62787 : 11692
UDP 0.0.0.0:62789 : 11692
UDP 0.0.0.0:62790 : 11692
UDP 0.0.0.0:62791 : 11692
UDP 0.0.0.0:62792 : 11692
UDP 0.0.0.0:62793 : 11692
UDP 0.0.0.0:62794 : 11692
UDP 0.0.0.0:62796 : 11692
UDP 0.0.0.0:62797 : 11692
UDP 0.0.0.0:62798 : 11692
UDP 0.0.0.0:62799 : 11692
UDP 0.0.0.0:62800 : 11692
UDP 0.0.0.0:62801 : 11692
UDP 0.0.0.0:62802 : 11692
UDP 0.0.0.0:62803 : 11692
UDP 0.0.0.0:62805 : 11692
UDP 0.0.0.0:62806 : 11692
UDP 0.0.0.0:62807 : 11692
UDP 0.0.0.0:62808 : 11692
UDP 0.0.0.0:62809 : 11692
UDP 0.0.0.0:62810 : 11692
UDP 0.0.0.0:62812 : 11692
UDP 0.0.0.0:62813 : 11692
UDP 0.0.0.0:62814 : 11692
UDP 0.0.0.0:62815 : 11692
UDP 0.0.0.0:62817 : 11692
UDP 0.0.0.0:62818 : 11692
UDP 0.0.0.0:62820 : 11692
UDP 0.0.0.0:62821 : 11692
UDP 0.0.0.0:62822 : 11692
UDP 0.0.0.0:62823 : 11692
UDP 0.0.0.0:62824 : 11692
UDP 0.0.0.0:62825 : 11692
UDP 0.0.0.0:62826 : 11692
UDP 0.0.0.0:62827 : 11692
UDP 0.0.0.0:62828 : 11692
UDP 0.0.0.0:62829 : 11692
UDP 0.0.0.0:62830 : 11692
UDP 0.0.0.0:64681 : 11692
UDP 0.0.0.0:64682 : 11692
UDP 0.0.0.0:64683 : 11692
UDP 0.0.0.0:65017 : 11692
Talvez esteja faltando alguma coisa na minha leitura do netstat, mas isso parece incomumente alto.
Este é um problema repetido. A única coisa necessária para evocar o grande número de portas ouvindo é iniciar o Chrome. Além disso, quando eu fecho o Chrome, sempre pelo menos um processo ainda está em execução após o fechamento do navegador e parece ser executado indefinidamente ( esse não é o processo associado ao grande número de portas abertas - ou pelo menos não por si só) como o portas desaparecem quando eu fecho o navegador ).
Alguém sabe:
- Se isso é normal?
- Se não é normal, o que poderia explicar isso?
- Como eu pude descobrir mais informações sobre o que realmente está acontecendo?
Eu tenho o Wireshark instalado, mas isso sempre parece confundir meu entendimento, e ainda não senti vontade de tentar entendê-lo. Além disso, o log de eventos do Windows não revela nada.
Observe que essa não é uma duplicata da pergunta Por que o Google precisa de tantas portas abertas? como essas portas não são dedicadas a - e não parecem estar relacionadas a - nenhum site.
Desde já, obrigado.
Respostas:
DNS assíncrono no Chrome, leia mais sobre ele em The Chromium Projects
Resumindo: o Chrome usa resoluções DNS síncronas nativas do Windows por padrão, o que significa que ele deve aguardar sucessivamente por todas as resoluções, independentemente de quantas guias estiverem carregando simultaneamente, o que adicionará um atraso perceptível ao carregamento, dependendo da ordem em que resolverem novas hosts. Uma solução proposta era tornar esse componente assíncrono, pois esse Chrome precisava ignorar o componente DNS nativo do Windows, adicionar um próprio e, assim, abrir mais algumas portas UDP quando necessário.
Esse comportamento, na pergunta principal, deve-se ao fato de o componente estar em estágio de desenvolvimento e, portanto, parecerá ter muitas conexões, sendo irrestrito e um desperdício de recursos. Isso estava acontecendo apenas se o usuário alterasse manualmente um sinalizador no Chrome para ativar esse recurso, geralmente reservado para desenvolvedores ou colaboradores. Consulte "Resposta obsoleta" para obter uma explicação sobre como acessar em versões mais antigas do Chrome.
Para as versões mais recentes do Chrome, posso dizer para a v43, esse comportamento foi corrigido e agora usa menos portas UDP, dependendo do número de hosts desconhecidos que ele precisa resolver, caso contrário, usará resoluções em cache e terá menos portas abertas.
Até onde eu sei, as versões atuais do Chrome não têm um sinalizador para ativá-lo, ele existe e pode ser ativado por meio de uma opção no chrome.exe. Por padrão, está desativado .
Edite os atalhos do Chrome e adicione --enable-async-dns após o destino chrome.exe " , separe-os por um espaço. No Windows 7, para um atalho fixo, clique com o botão direito do mouse no pino, no menu lado direito, clique com o botão direito do mouse no atalho do Google Chrome acima da opção Soltar este programa ... e acesse suas propriedades, edite o destino lá.
Para descobrir se o DNS assíncrono está ativado, acesse chrome: // net-internals / # dns e deve haver uma listagem chamada Internal DNS client enabled: true ou false
Resposta obsoleta (opção existe em versões mais antigas, cerca de 27):
Digite isso na barra de endereço do Google Chrome:
Role a lista e verifique se " DNS assíncrono interno " está desativado.
fonte