Moitos xa escoitaron que Cloud4Y é un provedor de nube empresarial. Polo tanto, non falaremos de nós mesmos, senón que compartiremos unha pequena historia sobre como tivemos problemas para acceder a algúns sitios e que provocou isto.
Un bo día, o departamento de mercadotecnia queixouse aos enxeñeiros de que cando se traballaba a través do terminal nos navegadores, algúns sitios tardaban moito tempo en cargarse. En particular, vk.com é vital para eles. Recibimos o sinal e comezamos a descubrir cal era o problema.
Entón, a situación: provedor de Internet Megafon, sistema operativo do servidor Windows, navegador Firefox. Se abres VKontakte con Windows 10 normal, o sitio cargarase en 10-100 ms. Se tentamos abrir con Windows Server 2012/16/19, o atraso é de ata 15 segundos, ou incluso máis.
Tomaron , e a través del comezaron a elaborar posibles versións do que estaba a suceder.
Proba a hipótese número 1: un problema co servidor de terminal.
Non confirmado. Ao probar a apertura da páxina a través doutro servidor da mesma rede, o problema persistiu.
Proba a hipótese número 2 - o problema está na pasarela.
Non confirmado. Observouse que nos portátiles locais todo se abre de xeito sinxelo e rápido. Pero ao mesmo tempo, o problema persiste para terminais (e servidores internos). Xogamos coa configuración ICMP nas interfaces externas e internas; non axudou.
É estraño dalgún xeito.
Desde un portátil local o sitio non se ralentiza.
Desde a máquina de dixitalización interna (terminal para a dixitalización): non se ralentiza.
Pero o marketing é lento. Desorde!
Sigamos adiante.
Proba a hipótese #3 - Problema de DNS.
Non confirmado. Lanzamos o píxel a través do DNS público (8.8.8.8), a mesma historia. O problema é claramente visible a primeira vez que tiras este píxel no modo de incógnito, por exemplo.
Existe a sospeita de que o problema depende en gran medida do navegador. En FF o píxel sempre se conxela, en chrome ao primeiro inicio de sesión. O marketing queda atascado todo o tempo en todos os navegadores.
Proba a hipótese #4 - Algo co modelo do SO.
Non confirmado. Implementamos un Windows Server 2016 limpo e realizamos a proba desde a rede .0. Temos un problema. Trasladamos á rede .200, o problema persistiu. É dicir, a porta da rede é .0. nada que ver con iso. Non obstante, os portátiles desta rede non teñen este problema. É dicir, a porta da rede é .200. nada que ver con iso tampouco.
É dicir, non é unha cuestión do modelo do SO. A máquina virtual diminúe mentres se carga o píxel. Pero se instalas nela unha VPN (tarxeta de rede separada) e envías tráfico a través dela, todo funciona moi rápido (como debería ser). Vemos que hai dúas opcións que poden causar un problema: unha pasarela na oficina ou un operador de Internet na oficina.
Pero pode Megafon cortar específicamente o acceso ao píxel VKontakte? Non, é unha especie de tontería. Imos tentar cavar un pouco máis.
Hipótese de proba número 5 - VMware Tools é a culpa de todo.
Non confirmado. Non se observan efectos nocivos. Tentamos cambiar a configuración da tarxeta, pero tampouco funcionou. TTL cambiou - sen efecto. Ben, xeralmente non está claro cal é a diferenza entre Windows 10 e Windows Server. Pero hai unha diferenza. Como a historia co gopher.
Levamos bastante tempo lidando co problema. Por suposto, buscamos en Google situacións similares, pero non atopamos nada. Así que actuamos sen pedirnos, elaborando todas as versións posibles. Realizamos probas desde un portátil con Windows 2016 para asegurarnos de que a virtualización e así por diante non fosen a culpa da ralentización ao cargar o píxel. Cambiamos todas as opcións posibles da tarxeta de rede e da pila IP. Probamos un montón de cousas. Pero o problema seguía sendo, e o marketing entrou e esixiu que todo se arranxase.
Despois dun tempo, por fin atopamos onde estaba enterrado o can. Todo era sobre as opcións
netsh interface tcp setglobal ecncapability=desactivado
Esta opción está desactivada por defecto nos sistemas operativos Windows de escritorio e habilitada por defecto nos sistemas operativos do servidor. En canto o desactivamos na sala de servidores, todo ábrese ao instante, igual que no escritorio. Puidemos confirmar este problema dende o provedor que nos proporciona Internet na oficina (Megafon), a través da Internet móbil de Megafon (se o compartes desde o teu teléfono e te conectas a través de Windows Server), a través de Yota, probámolo nalgunhas zonas de Moscova e este problema estaba presente en todas partes. Cando se traballaba noutros operadores, o acceso ao sitio era instantáneo.
Este é un esbozo, como dixo unha figura política destacada. En principio, o problema xa está solucionado, pero interésanos moito: ocorreu só aquí ou é un desastre de gran envergadura que afecta a empresas doutras cidades? Se este caso non é illado, Megafon debería pensar en resolver este problema. Despois de todo, a opción ECN (ecncapability) está habilitada nos servidores de forma predeterminada e leva moito tempo descubrir de que se trata.
Como comprobar? Si, igual que nós. Usando o navegador Firefox tentamos abrir calquera páxina en vk.com e de novo usando ctrl+f5. Se hai un problema, haberá un atraso constante, se non hai problema, o sitio abrirase ao instante.
Que máis podes ler no blog?
→
→
→
→
→
Subscríbete ao noso -canle, para non perder o seguinte artigo! Escribimos non máis de dúas veces por semana e só por negocios.
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Estás experimentando un atraso na carga a través de Windows Server?
-
4,8%Si, leva moito tempo cargar2
-
50,0%Non, todo voa21
-
45,2%O problema non está na configuración, senón nos comerciantes19
Votaron 42 usuarios. 35 usuarios abstivéronse.
Fonte: www.habr.com