¡Hola a todos!
En contacto, Nikita — ingeniero de sistemas de la empresa SEMrush. Hoy les contaré sobre cómo enfrentamos la tarea de garantizar la estabilidad de nuestro servicio semrush.com en China y los problemas con los que nos enfrentamos durante su ejecución (considerando la ubicación de nuestro centro de datos en la costa este de EE. UU.).
Esta será una gran historia, dividida en varios artículos. Les contaré cómo todo fue para nosotros: desde un servicio que no funcionaba en absoluto desde China hasta indicadores de rendimiento del servicio a nivel de su versión estadounidense para estadounidenses. Prometo que será interesante y útil. Así que, ¡vamos!
Problemas de internet en China
Incluso la persona más alejada de la especificidad de la administración de redes ha oído hablar al menos una vez de El Gran Firewall Chino. Uuuu, suena genial, ¿verdad? Pero ¿qué es, cómo funciona realmente? — es una pregunta bastante compleja. En Internet, se pueden encontrar muchos artículos dedicados a esto, pero desde una perspectiva técnica, la estructura de este firewall no se describe en ninguna parte. Lo cual, por supuesto, no es sorprendente. Debo admitir que, después de un año de trabajo, no podré decir exactamente cómo funciona, pero puedo compartir mis observaciones y conclusiones prácticas. Y empezaremos con los rumores sobre este firewall.
Hay muchos rumores sobre este mismo firewall. Vamos a recopilar los principales y más interesantes en una lista:
- Google, Facebook, Twitter y otros servicios similares están bloqueados y no funcionan en China.
- Cualquier tráfico que va FUERA de China y A China es analizado y restringido mediante aprendizaje automático (en caso de tráfico sospechoso), lo que lo ralentiza notablemente (el tráfico) al pasar por la frontera.
- Los servicios de inteligencia chinos pueden romper cualquier tráfico encriptado que pase por su firewall.
- Los túneles VPN, los túneles IPSEC son inestables, se caen y se bloquean constantemente.
- Cuanto más simple sea la encriptación, cuanto más simple sea la frase de acceso utilizada para la autenticación/encriptación del tráfico, más rápido pasará por el firewall chino.
Esto es lo que hemos logrado descubrir sobre estos rumores:
- Google, Facebook, Twitter y otros servicios similares están realmente bloqueados (su K.O.), pero muchos dominios técnicos de Google, por ejemplo, no están bloqueados y funcionan (como gstatic.com). De aquí se deduce que no se debe eliminar sin pensar todos los recursos de Google y otros que parecen estar bloqueados.
- Cualquier tráfico que cruce la frontera realmente añade un retardo considerable a su tiempo. Observa dos resultados. Un sitio, una página, simple GET curl’om. La primera medición es desde China (la hermosa ciudad de Shenzhen). La segunda medición es desde fuera, en Hong Kong (que tiene soberanía, y entre él y el mundo no hay firewall). La distancia entre las ciudades es de aproximadamente 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Recibido % Transferido Velocidad Media Tiempo Tiempo Tiempo Actual
Dload Upload Total Gastado Queda Velocidad
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Recibido % Transferido Velocidad Media Tiempo Tiempo Tiempo Actual
Dload Upload Total Gastado Queda Velocidad
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sPresta atención a time_connect. En general, ves el resultado: el firewall añade 4 segundos extra, lo cual es extremadamente largo.
- Los túneles VPN e IPSEC realmente caen con frecuencia. De esto hablaré más adelante y con más detalle. Los servidores VPN que utilizan los usuarios son bloqueados con el tiempo (normalmente dentro de un día después de que comienzan a usarse).
- Hay una opinión de personas que viven en China que dice que cuanto más simple es la encriptación del tráfico, más rápido pasa por la frontera, porque es fácil entender que no hay nada ilegal en él. Y de igual manera, el tráfico “limpio” recibe más ancho de banda y velocidad de paso, mientras que el tráfico “sucio”, en el que no se puede distinguir nada, obtiene un paso más lento. Como ejemplo, citaré curl hacia ifconfig.co a través del protocolo 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/sLa diferencia de 5 segundos en el tiempo total de carga de 13 bytes. Al realizar esta prueba varias veces, se puede observar que la solicitud GET por HTTP se completa en un tiempo bastante constante, mientras que en HTTPS el sitio a veces responde en 3, 5, 10 e incluso 17 segundos. A veces se producen errores de SSL:
Error desconocido de protocolo SSL en la conexión a ifconfig.co:443.
Entonces, ¿qué tenemos:
- Los problemas causados por el firewall chino, como se describió anteriormente.
- Los pings a recursos externos y dentro de túneles se pierden periódicamente.
- La latencia entre dos puntos cambia constantemente y a menudo es simplemente impredecible. Al conectar distintas ciudades/regiones, esperas que, dadas las ubicaciones geográficas de las regiones, la latencia sea menor, pero obtienes exactamente lo contrario.
- Internet y las conexiones funcionan de forma rápida a veces y de forma lenta en otras. Hay una pequeña dependencia del momento del día y del día de la semana, pero no siempre.
- Las consultas DNS al exterior desde China a veces superan el tiempo de espera permitido.
El panorama que se dibuja es simplemente "excelente".
El centro de datos, como mencioné, está en el este de EE. UU., y todo SEMrush consiste en decenas de productos interconectados, backend, frontend, bases de datos, y todo esto en el centro de datos y en la nube. Como equipo de administradores de sistemas, se nos planteó el desafío de comenzar a trabajar rápidamente en China con un esfuerzo mínimo.
Teníamos que responder a una pregunta importante: ¿podemos resolver todos los problemas asociados con Internet chino y el firewall a nivel de red/nube/servidores de manera eficiente?
Comenzamos con la obtención de .
Licencia ICP
Para poder alojar nuestro servicio en China continental y realizar pruebas, primero es necesario obtener la licencia ICP para el dominio.
Si el tráfico de los usuarios de su sitio web se termina dentro de China continental y su dominio no tiene licencia ICP, su tráfico será bloqueado por el proveedor/host. Es interesante que la licencia ICP especifique un proveedor concreto, ya sea Cloudflare o Alibaba Cloud. Por lo tanto, si obtuvo una licencia ICP para Cloudflare y alojó su sitio con ellos, posteriormente no podrá migrar "sin problemas" a Alibaba Cloud. Tendrá que añadir otro hosting a esta licencia.
Al obtener la licencia ICP para el dominio, pudimos concebir e implementar ideas y soluciones técnicas específicas.
Pruebas de soluciones
Pero antes de crear variaciones de staging, ajustar configuraciones, optimizar el rendimiento del sitio y su velocidad, es necesario elegir una herramienta para su prueba, con el fin de ver qué acciones mejoran o, por el contrario, perjudican el funcionamiento del sitio.
Nuestra herramienta para pruebas debía cumplir con dos requisitos principales:
- debe poder realizar pruebas desde China,
- debe tener pruebas basadas en navegador.
Así encontramos ! Tienen una excelente cobertura de puntos de prueba en todo el mundo. A través de esta herramienta, también se pueden realizar pruebas desde 100500 provincias en China. En cada una, varios proveedores diferentes + la posibilidad de hacer pruebas Backbone (algo similar a una virtualización en el centro de datos) ypruebas Lastmile (maximizada en condiciones de usuario, también conocida como estación de trabajo). El último tipo de pruebas es más costoso. Al firmar un contrato anual (no se puede hacer por menos), comenzamos a estudiar la herramienta. Debo admitir que nos sorprendió gratamente su funcionalidad. Se pueden realizar:Pruebas DNS,
Pruebas web (basadas en navegador, simple GET/POST, emulación de cliente móvil, etc.),
- Verificaciones transaccionales (por ejemplo, inicio de sesión),
- Pruebas API,
- Ping, traceroute, NTP, etc.
- No se puede enumerar todo. Y lo más importante, cada prueba se puede personalizar bastante bien, añadiendo varios encabezados y otros parámetros. El resultado es una gran cantidad de información que describe completamente su prueba. En lo que respecta a lo más interesante para nosotros (pruebas basadas en navegador), los resultados incluyen:
- Conexión, Espera, Carga, SSL, tiempo DNS,
TTFB, TTLB, Documento completo, Tiempo de renderizado, carga del DOM,
- Respuesta (algo cercano al Tiempo hasta el primer byte), Respuesta de página web (algo cercano al Tiempo hasta el último byte),
- Cualquier percentil, promedio, tiempo medio
- Y demás.
- Cualquier percentil, promedio, tiempo mediano
- Etc.
Por lo tanto, todas estas métricas ayudan a ver los cambios y entender si ha mejorado. Principalmente, nos enfocamos en Response, Webpage Response, Median, Percentiles 75 y 95.
Una pregunta importante que ha estado en el aire desde el principio: ¿se puede confiar en Catchpoint?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Este es un gran problema, porque estando en Rusia es prácticamente imposible averiguar con precisión cómo funciona un sitio web de China. Al hacer un socks-proxy a través de una máquina virtual, el resultado es que la carga del sitio se toma un par de minutos, lo que es inaceptable para las pruebas; por lo tanto, la única opción para la prueba manual son curl y simples GET desde la consola con medición de tiempo. Esto ayuda, porque esta prueba refleja bien la velocidad de la solución de red, y si también hay pruebas de navegador, aún mejor.
Más tarde, nosotros mismos viajamos a China y nos aseguramos de que se puede confiar en Catchpoint, ya que refleja con bastante precisión las métricas reales de velocidad.
Red de Cloudflare China
Dado que para el dominio principal semrush.com usamos con éxito Cloudflare, decidimos probar de inmediato su función llamada . Esta opción se activa solo para sitios de Enterprise mediante una solicitud separada y por un costo adicional. También está disponible solo para sitios que tienen la licencia ICP correspondiente, donde Cloudflare está indicado como proveedor. Una vez activada, el sitio tiene acceso a la "CDN china" de Cloudflare: el tráfico de las regiones chinas aterriza en el PoP (Puntos de Presencia) más cercano de CF y luego se entrega a través de sus redes o las de los proveedores/colaboradores hasta el origen.
El esquema de este banco de pruebas se presenta a continuación.
Para nosotros, esta es una excelente opción. Resulta que el segundo dominio también estará bajo CF, lo que no aumenta la cantidad de soluciones utilizadas en la empresa y casi no complica la infraestructura.
Hicimos pruebas de navegador y esto es lo que obtuvimos:
Los rombos rojos son falls de las pruebas. Las falls de abajo son errores de DNS (timeout de resolución). Las falls de arriba son timeouts.
Uptime: 86.6
Mediana: 18s
Percentil 75: 29.3s
Percentil 95: 60s
La mediana, después de eliminar la carga de reCaptcha (un servicio de Google bloqueado en China) bajó de 28 a 18 segundos. Pero aun así, son métricas horribles, teniendo en cuenta que la misma prueba para semrush.com (desde EE.UU.) daba menos de 10 segundos para el 95% de los usuarios (desde EE.UU.) en la misma página (estática + dinámica).
Se puede acceder a cada prueba y ver Waterfall y otros parámetros más detallados. Comenzamos a investigar las causas de los errores, y aunque para los tiempos de espera todo está más o menos claro: internet en China "a veces se conecta, a veces se desconecta", por lo que la velocidad de conexión y la carga de recursos del extranjero son inestables y desiguales, los errores de DNS nos sorprendieron mucho. Descubrimos que PoP en realidad están en China, la dirección del sitio se resuelve en una IP anycast, pero los servidores DNS utilizados son estadounidenses, lo que obliga a las consultas DNS a cruzar la frontera, por lo que a veces fallan.
Aclarando esta cuestión con CF, se supo que no tienen sus propios servidores DNS en China, y cuándo los tendrán — aún es desconocido.
Por lo tanto, decidimos probar solo el DNS de Cloudflare y cambiamos el mecanismo de funcionamiento de Cloudflare para nuestro sitio a modo de "Solo DNS". Este es un modo en el que Cloudflare no proxy el tráfico, lo que significa que no proporciona protección contra DDoS, CDN y otras características, y opera en modo de servidor DNS normal.
Este stand se presenta esquemáticamente en la siguiente imagen. La imagen tiene en cuenta el nuevo conocimiento de que los servidores DNS de Cloudflare están detrás del firewall.
En Catchpoint ejecutamos pruebas GET simples (no browser-based), que mostraron muchos fallos. La causa de estos fueron los mismos errores de DNS.
Empezamos a depurar estos errores con ayuda de dig y descubrimos que en la primera consulta la dirección se determina correctamente, pero en las consultas subsiguientes obtenemos cada vez SERVFAIL y no encontrado. ¿De dónde viene esto?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn tiene dirección 220.170.186.192
Host semrushchina.cn no encontrado: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn tiene dirección 220.170.186.192
Host semrushchina.cn no encontrado: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn tiene dirección 220.170.186.192
Host semrushchina.cn no encontrado: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn tiene dirección 220.170.186.192
Host semrushchina.cn no encontrado: 2(SERVFAIL)Al consultar los servidores NS de Cloudflare directamente, no hay tales errores:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Utilizando el servidor de dominio:
Nombre: ray.ns.cloudflare.com.
Dirección: 173.245.59.138#53
Alias:
semrushchina.cn tiene dirección 220.170.186.192
semrushchina.cn tiene dirección 220.170.186.192
Utilizando el servidor de dominio:
Nombre: ray.ns.cloudflare.com.
Dirección: 173.245.59.138#53
Alias:
semrushchina.cn tiene dirección 220.170.186.192
semrushchina.cn tiene dirección 220.170.186.192Así que el problema está del lado del servidor DNS "local" o del servidor del proveedor.
Investigaciones posteriores mostraron que SERVFAIL recibimos en la resolución registrosAAAA.
Resultó que al consultar a Cloudflare AAAA-registro que no existe en el dominio, Cloudflare respondió A-con un registro, lo cual es un error y una discrepancia con el RFC. Por lo que al resolvedor local (x.x.x.x) no le gustó y respondió SERVFAIL. En el registro a continuación, este comportamiento se observa claramente:
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @x.x.x.x
;; opciones globales: +cmd
;; Se obtuvo respuesta:
;; ->>HEADER<<- opcode: QUERY, estado: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, RESPUESTA: 0, AUTORIDAD: 0, ADICIONAL: 1
;; SECCIÓN PSEUDOOPT:
; EDNS: versión: 0, flags:; udp: 4096
;; SECCIÓN DE PREGUNTAS:
;semrushchina.cn. IN AAAA
;; Tiempo de consulta: 334 mseg
;; SERVIDOR: x.x.x.x#53(x.x.x.x)
;; CUANDO: Mar Ago 14 23:38:50 CST 2018
;; TAMAÑO MSG recibido: 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; opciones globales: +cmd
;; Se obtuvo respuesta:
;; ->>HEADER<<- opcode: QUERY, estado: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, RESPUESTA: 1, AUTORIDAD: 0, ADICIONAL: 1
;; ADVERTENCIA: se solicitó recursión pero no está disponible
;; SECCIÓN PSEUDOOPT:
; EDNS: versión: 0, flags:; udp: 512
;; SECCIÓN DE PREGUNTAS:
;semrushchina.cn. IN AAAA
;; SECCIÓN DE RESPUESTAS:
semrushchina.cn. 300 IN A 220.170.186.192
;; Tiempo de consulta: 185 mseg
;; SERVIDOR: 173.245.58.105#53(173.245.58.105)
;; CUANDO: Mar Ago 14 23:43:03 CST 2018
;; TAMAÑO MSG recibido: 60
Enviamos un informe de error a Cloudflare, y lo corrigieron después de un tiempo. Resultó interesante: actualmente en China aún no hay soporte para IPv6, por lo que Cloudflare no podía proporcionar su dirección IPv6 en la respuesta a la consulta AAAA-registro. Al final, todo se resolvió de tal manera que para China Cloudflare comenzó a responder NODATA a tales consultas.
Así que los errores de DNS en las pruebas de Catchpoint disminuyeron drásticamente, pero no del todo. Los timeouts tampoco desaparecieron:
Y comenzamos a buscar otra solución.
En la próxima parte contaré cómo probamos la nube china Alibaba Cloud, cómo, con un poco de 'magia' de Nginx, pudimos crear rápidamente PoC (Prueba de Concepto) soluciones, cómo creamos soluciones Multi-Cloud, una de las cuales al final ayudó mucho a acelerar el servicio desde China.
¡Estén atentos!
Próximas partes
Fuente: habr.com
