Hola a todos!
En contacto Nikita es ingeniero de sistemas de SEMrush . Hoy les contaré cómo enfrentamos la tarea de garantizar la estabilidad de nuestro servicio semrush.com en China, y qué problemas encontramos durante su implementación (dada la ubicación de nuestro centro de datos en la costa este de los EE. UU.).
Esta será una gran historia, dividida en varios artículos. Te diré cómo sucedió todo con nosotros: desde un servicio de China que no funciona hasta el desempeño del servicio al nivel de su versión estadounidense para estadounidenses. Prometo que será interesante y útil. Entonces vamos.
Problemas de internet chinos
Incluso la persona más distante de los detalles de la administración de la red al menos una vez escuchó sobre el Gran Firewall chino . Uhh, eso suena bien, ¿eh? Pero lo que es, cómo funciona realmente es una pregunta bastante complicada. En Internet puede encontrar muchos artículos sobre esto, pero desde un punto de vista técnico, el dispositivo de este firewall no se describe en ninguna parte. Lo cual, sin embargo, no es sorprendente. Inmediatamente confieso que, en base a los resultados del año de trabajo, no puedo decir exactamente cómo funciona, pero sí puedo contar mis comentarios y conclusiones prácticas. Y comenzaremos con rumores sobre este firewall.
Hay muchos rumores sobre este mismo firewall. Recopilemos los principales y más interesantes de ellos en una lista:
- Google, Facebook, Twitter y otros servicios similares están bloqueados y no funcionan en China.
- Cualquier tráfico que vaya más allá de China y hacia China es analizado y limitado por el aprendizaje automático (en el caso de tráfico sospechoso), que lo ralentiza en gran medida (el tráfico) que pasa por la frontera.
- Las agencias de inteligencia chinas descifran el tráfico encriptado que pasa a través de su firewall.
- Los túneles VPN, los túneles IPSEC son inestables, caen y están constantemente bloqueados.
- Cuanto más simple es el cifrado, más simple es la frase de contraseña utilizada para la autenticación / cifrado de tráfico, más rápido pasa el cortafuegos chino.
Esto es lo que hemos logrado descubrir sobre estos rumores:
- Google, Facebook, Twitter y otros servicios similares están realmente bloqueados (su KO), pero muchos dominios técnicos de Google, por ejemplo, no están prohibidos y funcionan (el mismo gstatic.com). Esto lleva a la conclusión: no recorte imprudentemente todos los recursos de Google y otros que parecen estar bloqueados, aparentemente bloqueados.
- Cualquier tráfico que pase por la frontera realmente agrega un serio retraso a su tiempo. Mira los dos resultados. Un sitio, una página, simple get curl . La primera medición de China (la hermosa ciudad de Shenzhen). El segundo se congeló afuera de Hong Kong (tiene soberanía y no hay un cortafuegos entre este y el mundo). La distancia entre ciudades en línea recta es de unos 30-40 km.
nikita@china-shenzhen:~
Presta atención a time_connect . Y en general, ves el resultado: el firewall agrega 4 segundos adicionales, que es monstruosamente largo.
- Las VPN y los túneles IPSEC caen a menudo. Hablaré de esto un poco más tarde y con más detalle. Los servidores VPN que utilizan los usuarios se bloquean con el tiempo (generalmente dentro de un día después del inicio del uso).
- Se ha recibido la opinión de personas que viven en China de que cuanto más fácil es el cifrado del tráfico, más rápido pasa a través de la frontera, porque es fácil entender que no hay nada ilegal en él. Y así como el tráfico "limpio" obtiene más ancho de banda y velocidad, y el tráfico "sucio", que no distingue nada, obtiene un pase más lento por el contrario. Por ejemplo, traeré curl a ifconfig.co usando los protocolos HTTPS y HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3 time_namelookup: 0.004305 time_connect: 0.397465 time_appconnect: 5.149305 time_pretransfer: 5.149393 time_redirect: 0.000000 time_starttransfer: 5.568847 ---------- time_total: 5.568893 ---------- size_download: 13 Bytes speed_download: 2.000B/s curl -o /dev/null -w@curl_time "http://ifconfig.co/" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28 time_namelookup: 0.004282 time_connect: 0.212457 time_appconnect: 0.000000 time_pretransfer: 0.212484 time_redirect: 0.000000 time_starttransfer: 0.450565 ---------- time_total: 0.450620 ---------- size_download: 13 Bytes speed_download: 28.000B/s
La diferencia es de 5 segundos para un tiempo de carga total de 13 bytes. Al hacer esta prueba varias veces, puede ver que GET en HTTP se completa en general al mismo tiempo cada vez, mientras usa HTTPS, el sitio a veces responde en 3, 5, 10 e incluso 17 segundos. A veces se producen errores de SSL:
Unknown SSL protocol error in connection to ifconfig.co:443.
Entonces lo que tenemos:
- Los problemas creados por el firewall chino descritos anteriormente.
- Pings a los recursos externos y dentro de los túneles desaparecen periódicamente.
- La latencia entre dos puntos cambia constantemente y, a menudo, es simplemente impredecible. Al conectar diferentes ciudades / regiones, espera que, según la ubicación geográfica de las regiones, el retraso sea menor y obtenga exactamente la situación opuesta.
- Internet y los canales de comunicación son rápidos o lentos. Hay una ligera dependencia de la hora del día y el día de la semana, pero no siempre.
- Las consultas de DNS al mundo exterior desde China a veces exceden el tiempo de espera permitido.
La imagen parece simplemente "excelente".
El centro de datos, como ya dije, está en el este de los EE. UU., Y todo el SEMrush consta de docenas de productos interconectados, backends, frontends, bases de datos y todo esto en el centro de datos y en las nubes. Como equipo de administradores de sistemas, nos encargaron un pequeño esfuerzo para comenzar a trabajar rápidamente en China.
Tuvimos que responder una pregunta importante: ¿podemos salir con un poco de sangre y resolver todos los problemas asociados con Internet y firewall chinos en el nivel de red / nube / servidor?
Comenzamos obteniendo una licencia ICP .
Licencia ICP
Para poder colocar su servicio dentro de China (China continental) y realizar pruebas, primero debe obtener una licencia de dominio ICP.
Si el tráfico de usuarios de su sitio se termina dentro de China continental, y si su dominio no tiene una licencia ICP, su tráfico se bloqueará en el lado del proveedor / alojamiento. Curiosamente, un proveedor específico se ajusta a la licencia ICP, ya sea Cloudflare o Alibaba Cloud. Por lo tanto, si recibió una licencia ICP para Cloudflare y alojó su sitio con ellos, entonces no podrá mudarse "sin problemas" a Alibaba Cloud. Será necesario agregar un hosting más a esta licencia.
Después de recibir una licencia de dominio ICP, pudimos encontrar e implementar ideas y soluciones técnicas específicas.
Soluciones de prueba
Pero antes de crear directamente las opciones para la puesta en escena, girar los mandos, optimizar el sitio y su velocidad, debe elegir una herramienta para probarlo y ver qué acciones mejoran o empeoran el trabajo del sitio.
Nuestra herramienta de prueba tenía que cumplir con dos requisitos principales:
- debería poder realizar pruebas desde China,
- Debe tener pruebas de navegador.
¡Así que encontramos el punto de captura ! Tienen una excelente cobertura con puntos de prueba en todo el mundo. En China, a través de esta herramienta, también puede ejecutar pruebas desde 100,500 provincias. En cada uno, varios proveedores diferentes + la capacidad de hacer pruebas de Backbone (algo así como una máquina virtual en un centro de datos) y pruebas de Lastmile (lo más cerca posible de las condiciones del usuario, también conocido como estación de trabajo). El último tipo de prueba es más costoso.
Habiendo concluido un contrato de un año (no se puede hacer menos), comenzamos a estudiar la herramienta. Francamente, nos sorprendió gratamente su funcionalidad. Puedes ejecutar:
- Pruebas de DNS
- Pruebas web (navegador, GET / POST simple, emulación de un cliente móvil, etc.),
- Cheques transaccionales (por ejemplo, inicio de sesión),
- Pruebas de API
- Ping, traceroute, NTP, etc.
No puedes enumerar todo. Y lo más importante, cada prueba se puede personalizar bastante bien agregando un montón de encabezados y otros parámetros. El resultado es una gran cantidad de información que describe completamente su prueba. Si hablamos de lo más interesante para nosotros (pruebas de navegador), el resultado incluye:
- Conectar, esperar, cargar, SSL, hora DNS,
- TTFB, TTLB, documento completo, tiempo de procesamiento, carga DOM,
- Respuesta (algo parecido al Tiempo hasta el primer byte), Respuesta de la página web (algo parecido al Tiempo hasta el último byte),
- Cualquier percentil, promedio, tiempo medio
- Etc.
En consecuencia, todas estas métricas lo ayudan a ver los cambios y comprender si ha mejorado. Observamos principalmente la respuesta, la respuesta de la página web, la mediana, los percentiles 75 y 95 .
Una pregunta importante que ha estado en el aire desde el principio: ¿es posible creer en Catchpoint ? ¿Esta herramienta refleja la velocidad de carga real del sitio en China desde diferentes ciudades o es solo una especie de prueba en el vacío que no tiene nada que ver con la experiencia real del usuario?
Este es un gran problema, porque estar en Rusia es casi imposible saber de manera confiable cómo funciona el sitio desde China. Al hacer el proxy de calcetines a través de una máquina virtual, al final se carga el sitio web en un par de minutos, lo cual es simplemente inaceptable para las pruebas, por lo que la única opción para las pruebas manuales es obtener GETs curvos y simples desde la consola con medición de tiempo. Esto ayuda, porque esta prueba refleja la velocidad de la solución de red, y si hay pruebas de navegador, es muy buena.
Más tarde, fuimos a China nosotros mismos y nos aseguramos de que se pueda confiar en Catchpoint, ya que refleja con bastante precisión los indicadores reales de velocidad.
Red china de Cloudflare
Como utilizamos con éxito Cloudflare para el dominio principal de semrush.com, decidimos probar de inmediato su función llamada China Network . Esta opción está habilitada solo para sitios de Enterprise a pedido y por una tarifa. También está disponible solo para sitios que tienen la licencia ICP apropiada, en la que Cloudflare se especifica como el proveedor. Después de que se enciende, un "CDN chino" de Cloudflare está disponible para el sitio: el tráfico de las regiones chinas aterriza en el próximo PoP (Puntos de Presencia) CF, y luego se entrega al origen a través de sus redes o redes de proveedores / socios.
El esquema de este banco de pruebas se presenta a continuación.
Esta es una gran opción para nosotros. Resulta que el segundo dominio también será para CF, que no agrega la cantidad de soluciones utilizadas en la empresa, y tampoco complica prácticamente la infraestructura.
Ejecutamos las pruebas del navegador, y esto es lo que sucedió:
Los diamantes rojos son archivos de prueba. Los siguientes archivos son errores de DNS (tiempo de espera resuelto). Los fallos anteriores son tiempos de espera.
Tiempo de actividad: 86.6
Mediana: 18 años
75 Percentil: 29.3s
Percentil 95: años 60
La mediana, después de eliminar la descarga de reCaptcha (un servicio de Google bloqueado en China), disminuyó de 28 a 18 segundos. Pero aún así, estos son indicadores terribles, dado que la misma prueba para semrush.com (de EE. UU.) Dio menos de 10 segundos para el 95% de los usuarios (de EE. UU.) A la misma página (estadísticas + dinámica).
En cada prueba, puede ir a ver Cascada y otros parámetros más detallados. Comenzamos a investigar las causas de los errores, y si durante los tiempos de espera todo está menos o menos claro: Internet en China "se está cayendo, luego se está yendo", debido a esto la velocidad de conexión y carga de recursos desde el extranjero es inestable y desigual, entonces los errores de DNS nos sorprendieron enormemente. . Descubrimos que los PoP de Cloudflare están ubicados en China, la dirección del sitio se resuelve en una sola IP de difusión ilimitada, pero los servidores DNS son utilizados por los EE. UU., Es por eso que las consultas DNS se ven obligadas a cruzar la frontera, por lo que a veces fallan.
Después de aclarar esta pregunta con CF, resultó que no tienen sus propios servidores DNS en China , y aún se desconoce cuándo será.
Por lo tanto, decidimos probar solo DNS de Cloudflare y cambiamos el mecanismo de Cloudflare para nuestro sitio al modo " Solo DNS ". Este es un modo en el que Cloudflare no representa el tráfico proxy a través de sí mismo, lo que significa que no proporciona protección DDoS, CDN y otras características, y funciona en el modo de un servidor DNS normal.
Este soporte se muestra esquemáticamente en la siguiente figura. La figura tiene en cuenta el conocimiento emergente de que el servidor DNS de Cloudflare está detrás del firewall.
En Catchpoint, ejecutamos pruebas GET simples (sin navegador) que mostraron muchos fallos. La razón de ellos fueron los mismos errores de DNS.
Comenzamos a depurar estos errores usando dig y descubrimos que la dirección se determina correctamente en la primera solicitud, y en la solicitud repetida recibimos SERVFAIL y no se encuentra cada vez. ¿Qué es de repente?
root@iZwz97n2wgbp61qucbfrjsZ:~
Al solicitar servidores Cloudflare NS directamente, no existen tales errores:
root@iZwz97n2wgbp61qucbfrjsZ:~
Esto significa que el problema está del lado del servidor DNS "local" o del servidor del proveedor.
Investigaciones posteriores mostraron que recibimos SERVFAIL sobre la resolución del registro AAAA .
Resultó que cuando Cloudflare solicitó un registro AAAA que no estaba en el dominio, Cloudflare respondió con un registro A , que es un error de RFC y falta de coincidencia. Debido a que el solucionador local ( xxxx ) no le gustó esto, y respondió SERVFAIL . En el registro a continuación, este comportamiento es claramente visible:
root@iZwz97n2wgbp61qucbfrjsZ:~
Enviamos un informe de error de Cloudflare, y lo arreglaron después de un tiempo. Resultó ser interesante: en la actualidad, todavía no hay soporte IPv6 en China, por lo que Cloudflare no pudo dar su dirección IPv6 en respuesta a una solicitud de un registro AAAA . Al final, todo se decidió de modo que para China Cloudflare comenzó a responder NODATA a tales solicitudes.
Entonces, los errores de DNS en las pruebas de Catchpoint disminuyeron drásticamente, pero no hasta el final. Los tiempos de espera tampoco desaparecieron:
Y comenzamos a buscar otra solución.
En la siguiente parte, contaré cómo probamos la nube china de Alibaba , cómo con la ayuda de un pequeño Nginx "mágico" pudimos crear rápidamente soluciones PoC (Prueba de concepto), cómo creamos soluciones Multi-Cloud, una de las cuales finalmente ayudó mucho acelerar el servicio de China.
Estén atentos!
Todas las partes
Parte 2
Parte 3