Cómo atravesamos el Gran Cortafuegos chino (parte 3)

Hola
Cualquier buena historia termina. Y nuestra historia sobre cómo se nos ocurrió una solución al rápido paso del Firewall chino no es una excepción. Por lo tanto, me apresuro a compartir con ustedes la última parte final sobre este tema.


En la parte anterior, hablamos sobre muchos bancos de pruebas inventados por nosotros y qué resultados dieron. ¡Y nos decidimos por el hecho de que sería bueno agregar un CDN! para viscosidad en nuestro circuito.


Te diré cómo probamos Alibaba Cloud CDN, Tencent Cloud CDN y Akamai, y con qué terminé. Y, por supuesto, para resumir.



Alibaba Cloud CDN


Estamos alojados en Alibaba Cloud, usamos IPSEC y CEN de ellos. Sería lógico probar sus soluciones primero.


Alibaba Cloud tiene dos tipos de productos que pueden ser adecuados para nosotros: CDN y DCDN . La primera opción es un CDN clásico para un dominio específico (subdominio). La segunda opción es Dynamic Route para CDN (lo llamo Dynamic CDN), se puede activar en modo de sitio completo (para dominios comodín), también almacena en caché las estadísticas y acelera el contenido dinámico en sí mismo, es decir, la dinámica de la página también se cargará rápidamente proveedor de red. Esto es importante para nosotros, porque básicamente nuestro sitio es dinámico, utiliza muchos subdominios y es más conveniente configurar CDN una vez para la "estrella" - * .semrushchina.cn.


Ya vimos este producto en las primeras etapas de nuestro proyecto chino, pero aún no funcionó, y los desarrolladores prometieron que el producto estaría disponible para todos los clientes muy pronto. Y se hizo.


En DCDN, puedes:


  • configurar la terminación SSL con su certificado,
  • habilitar la aceleración de contenido dinámico,
  • configurar flexiblemente el almacenamiento en caché de archivos estáticos,
  • hacer purga de caché,
  • tirar tomas web,
  • habilite la compresión e incluso el embellecedor HTML.

En general, todo es como adultos y grandes proveedores de CDN.


Después de que se indique Origen (el lugar donde irán los servidores periféricos de CDN), queda por crear un CNAME para el asterisco, que se vincula a all.semrushchina.cn.w.kunluncan.com (este CNAME se obtuvo en la consola Alibaba Cloud) y CDN funcionará


Según los resultados de la prueba, este CDN nos ayudó mucho. Las estadísticas se dan a continuación.


SoluciónTiempo de actividadMediana75 percentilPercentil 95
Flama de nube86,618s30s60s
IPsec99,7918s21s30s
Cen99,7516s21s27s
CEN / IPsec + GLB99,7913s16s25s
Ali CDN + CEN / IPsec + GLB99,7510s12.8s17.3s

Estos son muy buenos resultados, especialmente si los comparamos con las cifras al principio. Pero sabíamos que la prueba del navegador de la versión estadounidense de nuestro sitio www.semrush.com estaba funcionando en los EE. UU. En promedio durante 8.3 segundos (un valor muy aproximado). Hay mucho por lo que luchar. Además, había proveedores de CDN que estaban interesados ​​en las pruebas.


Así que nos trasladamos sin problemas a otro gigante en el mercado chino: Tencent .


Nube tencent


Tencent solo está desarrollando su nube, esto es evidente en una pequeña cantidad de productos. En el curso de su uso, queríamos probar no solo su CDN, sino también la infraestructura de red en su conjunto:


  • ¿Tienen algo similar al CEN?
  • ¿Cómo funciona IPSEC para ellos? ¿Es rápido, qué es el tiempo de actividad?
  • ¿Tienen alguna difusión?


Analizaremos estas preguntas por separado.


CEN analógico


Tencent tiene un producto de red de conexión en la nube ( CCN ) que le permite interconectar VPC de diferentes regiones, incluidas las regiones dentro y fuera de China. El producto ahora se encuentra en la versión beta interna y debe crear un ticket con una solicitud para conectarse. Gracias al soporte, aprendimos que las cuentas globales (no sobre ciudadanos chinos y entidades legales) no pueden participar en el programa de pruebas beta y generalmente conectan la región dentro de China con la región exterior. 1-0 a favor de Ali Cloud


IPSEC


La región más meridional de Tencent es Guangzhou . Construimos un túnel y lo conectamos con la región de Hong Kong en el PCG (entonces esta región ya estaba disponible). También levantaron el segundo túnel a Ali Cloud desde Shenzhen a Hong Kong al mismo tiempo. Resultó que a través de la red de latencia Tencent, Hong Kong es generalmente mejor (10 ms) que de Shenzhen a Hong Kong a Ali (120 ms, ¿qué?). Pero esto no aceleró el trabajo del sitio, destinado a trabajar a través de Tencent y este túnel, lo que en sí mismo fue un hecho sorprendente y una vez más demostró lo siguiente: latencia: para China esto no es un indicador al que realmente deba prestar atención al desarrollar una solución para pasar a los chinos cortafuegos


Aceleración de Internet Anycast


Otro producto que le permite trabajar a través de cualquier IP de difusión es AIA . Pero también es inaccesible para las cuentas globales, por lo que no lo contaré, pero saber que tal producto existe puede ser útil.


Pero la prueba de CDN mostró resultados bastante interesantes. La CDN de Tencent no se puede habilitar en un sitio completo, solo en dominios específicos. Tenemos dominios y comenzamos el tráfico en ellos:



Resultó que este CDN tiene la siguiente función: Optimización del tráfico transfronterizo . Esta característica debería reducir los costos cuando el tráfico fluye a través del firewall chino. Como origen , se especificó la dirección IP de Google GLB (GLB anycast). Por eso queríamos simplificar la arquitectura del proyecto.


Los resultados fueron muy buenos, a nivel de Ali Cloud CDN, y en algunos lugares incluso mejores. Esto es sorprendente, porque si las pruebas tienen éxito, puede abandonar una parte importante de la infraestructura, túneles, CEN, máquinas virtuales, etc.


No estuvimos contentos por mucho tiempo, porque el problema fue revelado: las pruebas en Catchpoint falsificaron para el proveedor de Internet China Mobile. Desde cualquier lugar, obtuvimos un tiempo de espera a través de la CDN de Tencent. La correspondencia con el soporte técnico no condujo a nada. Aproximadamente un día tratamos de resolver este problema, pero no surgió nada.


Estaba en China en ese momento, pero no pude encontrar Wi-Fi público en la red de este proveedor para verificar el problema personalmente. De lo contrario, todo parecía rápido y bueno.
Sin embargo, debido al hecho de que China Mobile es uno de los tres operadores más grandes, nos vimos obligados a devolver el tráfico a Ali CDN.
Pero en general, esta fue una solución bastante interesante, que merece más pruebas y solución de problemas de este problema.


Akamai


El último proveedor de CDN que probamos es Akamai . Este es un gran proveedor que tiene su propia red en China. Por supuesto, no pudimos superarlo.



Desde el principio, acordamos con Akamai un período de prueba para que podamos cambiar el dominio y ver cómo funcionará en su red. Describiré el resultado de todas las pruebas en forma de "Lo que me gustó" y "Lo que no me gustó", así como los resultados de la prueba.


¿Qué te gustó?


  • Los muchachos de Akamai ayudaron mucho en todos los asuntos y nos acompañaron en todas las etapas de las pruebas. Constantemente tratando de mejorar algo de su lado. Dieron buenos consejos técnicos.
  • Akamai funciona entre un 10 y un 15% más lento que nuestra solución a través de Ali Cloud CDN. Es impresionante que en Origin hayamos especificado la dirección IP GLB para Akamai, es decir, el tráfico no pasó por nuestra solución (potencialmente puede abandonar parte de la infraestructura). Pero aún así, los resultados de la prueba mostraron que esta solución es peor que nuestra versión actual (resultados comparativos a continuación).
  • Probado tanto Origin GLB como Origin en China. Ambas opciones son casi iguales.
  • Hay una ruta segura (optimización de enrutamiento automático). Puede alojar el objeto de prueba en Origin, y el servidor Akamai Edge intentará recogerlo (GET normal). Para estas consultas, se miden la velocidad y otras métricas, sobre la base de las cuales la red de Akamai optimiza las rutas para que el tráfico vaya más rápido a nuestro sitio y se puede ver que la inclusión de esta característica realmente tuvo un gran efecto en la velocidad del sitio.
  • La versión de la configuración en la interfaz web es genial. Puede hacer Comparar para las versiones, ver diff. Ver versiones anteriores.
  • Puede implementar la nueva versión primero solo en la red de Akamai Staging: la misma red que la producción, solo que de esta manera no afecta a los usuarios reales. Para esta prueba, debe falsificar registros DNS en la máquina local.
  • Velocidad de descarga muy rápida a través de su red de grandes estadísticas y, aparentemente, de cualquier otro archivo. Un archivo del caché "en frío" se toma varias veces más rápido que el mismo archivo del caché "frío" Ali CDN. Desde el caché "activo", la velocidad ya es más o menos igual.

Prueba Ali CDN:


root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 5757k 0 5757k 0 0 513k 0 --:--:-- 0:00:11 --:--:-- 526k time_namelookup: 0.004286 time_connect: 0.030107 time_appconnect: 0.117525 time_pretransfer: 0.117606 time_redirect: 0.000000 time_starttransfer: 0.840348 ---------- time_total: 11.208119 ---------- size_download: 5895467 Bytes speed_download: 525999.000B/s 

Prueba de Akamai:


 root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 5757k 0 5757k 0 0 1824k 0 --:--:-- 0:00:03 --:--:-- 1825k time_namelookup: 0.509005 time_connect: 0.528261 time_appconnect: 0.577235 time_pretransfer: 0.577324 time_redirect: 0.000000 time_starttransfer: 1.327013 ---------- time_total: 3.154850 ---------- size_download: 5895467 Bytes speed_download: 1868699.000B/s 

Notamos que la situación del ejemplo anterior depende de varios factores. En el momento de escribir esto, realicé la prueba nuevamente. Los resultados para ambas plataformas fueron aproximadamente los mismos. Esto nos dice que Internet en China, incluso para grandes operadores y proveedores de la nube, se comporta de manera diferente de vez en cuando.


Agregaré una gran ventaja a Akamai al párrafo anterior: si Ali muestra tales destellos de alto rendimiento y muy bajo (esto se aplica a Ali CDN, Ali CEN y Ali IPSEC), entonces en Akamai cada vez, no importa cómo pruebe su red, todo Funciona de manera estable.
Akamai realmente tiene mucha cobertura en China y trabaja a través de muchos proveedores.


Lo que no le gustó:


  • No me gusta la interfaz web y el esquema de trabajo, estos son cero. Pero básicamente te acostumbras (probablemente).
  • Los resultados de las pruebas son peores que nuestro sitio.
  • Hay más errores durante las pruebas que en nuestro sitio (tiempo de actividad a continuación).
  • No hay servidores DNS en China. Desde aquí hay muchos errores en las pruebas debido al tiempo de espera de resolución de DNS.
  • No proporcione sus rangos de IP -> no hay forma de registrar el set_real_ip_from correcto en nuestros servidores.

Métricas (~ 3626 ejecuciones; todas las métricas excepto Tiempo de actividad en ms; estadísticas durante un período de tiempo):


Proveedor de CDNMediana75%95%RespuestaRespuesta a la página webTiempo de actividadDNSConectarEsperaCargaSSL
Ali CDN919510749174891,71510,74599,5315717927479200
Akamai978311887198882,35211,55098,98042491 91140838150

Distribución percentil (en ms):


PercentilAkamaiAli CDN
107,0926,942
207.7757,583
308.4468.092
409,1468,596
509,7839.195
60 6010,4979,770
7011,37110,383
8012,67011,255
9015,88213,165
10091,59291,596

La conclusión es esta: la opción con Akamai es viable, pero no ofrece los mismos indicadores de estabilidad y velocidad que nuestra propia solución, junto con Ali CDN.


Notas pequeñas


Algunos puntos no se incluyeron en la historia, pero también me gustaría escribir sobre ellos.


Beijing + Tokio y Hong Kong


Como dije anteriormente, probamos el túnel IPSEC a Hong Kong (HK). Pero también probamos CEN antes de HK. Cuesta un poco más barato, y fue interesante cómo funcionará entre ciudades con una distancia de ~ 100 km. Resultó ser interesante que la latencia entre estas ciudades es 100ms mayor que en nuestra versión original (para Taiwán). La velocidad, la estabilidad también fue mejor para Taiwán. Como resultado, dejamos HK como una región IPSEC de respaldo.


Además, intentamos generar una instalación de este tipo:


  • terminación de clientes en Beijing,
  • IPSEC y CEN a Tokio,
  • en Ali, el CDN figuraba como el servidor de origen en Beijing.

Este esquema no era tan estable, aunque en términos de velocidad en general no era inferior a nuestra solución. En cuanto al túnel, vi caídas periódicas incluso para CEN, que se suponía que era estable. Por lo tanto, volvimos al antiguo esquema y desmantelamos esta puesta en escena.


A continuación se muestran las estadísticas sobre la latencia entre diferentes regiones en diferentes canales. Quizás alguien esté interesado en ello.


IPsec
Ali cn-beijing <--> PCG asia-noreste1 - 193ms
Ali cn-shenzhen <--> GCP asia-east2 - 91ms
Ali cn-shenzhen <--> GCP us-east4 - 200ms


Cen
Ali cn-beijing <---> Ali ap-noreste-1 - 54ms (!)
Ali cn-shenzhen <---> Ali cn-hongkong - 6ms (!)
Ali cn-shenzhen <---> Ali us-east1 - 216ms


Información general sobre Internet en China


Como una adición a los problemas con Internet, descritos al principio, en la primera parte del artículo.


  • Internet en China es bastante rápido por dentro.
    • La conclusión se hace sobre la base de probar redes públicas de Wi-Fi en varios lugares donde estas redes son utilizadas por una gran cantidad de personas.
    • Las velocidades de descarga y carga a los servidores dentro de China fueron de alrededor de 20 Mbps y 5-10 Mbps, respectivamente.
    • La velocidad de los servidores fuera de China es miserable, menos de 1 Mbps.
  • Internet en China no es muy estable.
    • A veces, los sitios pueden abrirse rápidamente, a veces lentamente (a la misma hora del día en días diferentes), siempre que la configuración no cambie. Observamos esto con el ejemplo de semrushchina.cn. Esto se puede atribuir a Ali CDN, que también funciona de esta manera y que, según la hora del día, la posición de las estrellas, etc.
  • Internet móvil está casi en todas partes 4G o 4G +. Capturas en el metro, ascensores, en resumen, en todas partes.
  • El hecho de que los usuarios chinos solo confíen en dominios en la zona .cn es un mito. Aprendimos esto directamente de los usuarios.
    • Puede ver cómo http://baidu.cn redirige a www.baidu.com (también en China continental).
  • Muchos recursos están realmente bloqueados. Primitivo: google.com, Facebook, Twitter. Pero muchos recursos de Google funcionan (por supuesto, no todas las redes Wi-Fi y VPN se usan al mismo tiempo (también en el lado del enrutador, eso es seguro).
  • Muchos dominios "técnicos" de corporaciones bloqueadas también funcionan. Esto significa que no siempre debe cortar imprudentemente todos los recursos de Google y otros recursos aparentemente bloqueados. Debe buscar una lista de dominios prohibidos.
  • Solo tienen tres proveedores principales de Internet: China Unicom, China Telecom, China Mobile. Incluso hay otros más pequeños, pero su cuota de mercado es insignificante.

Bonificación: esquema de decisión final



Resumen


Ha pasado un año desde el inicio del proyecto. Comenzamos diciendo que nuestro sitio, en principio, se negaba a trabajar normalmente desde China, pero simplemente el RETOCIMIENTO tardó 5.5 segundos.


Luego, con dichos indicadores en la primera decisión (Cloudflare):


SoluciónTiempo de actividadMediana75 percentilPercentil 95
Flama de nube86,618s30s60s

Como resultado, llegamos a los siguientes resultados (estadísticas del último mes):


SoluciónTiempo de actividadMediana75 percentilPercentil 95
Ali CDN + CEN / IPsec + GLB99,868.8s9.5s13.7s

Como puede ver, el tiempo de actividad en 100% aún no se ha logrado, pero se nos ocurrirá algo y luego le informaremos sobre los resultados en un nuevo artículo :)


Al que ha leído las tres partes hasta el final: respeto. Espero que estén tan interesados ​​como yo cuando hice esto.


PD Piezas anteriores


Parte 1
Parte 2

Source: https://habr.com/ru/post/459024/


All Articles