Cómo rompimos el Gran Cortafuegos de China (Parte 3)

Hi!
Todas las buenas historias llegan a su fin. Y nuestra historia sobre cómo se nos ocurrió una solución para superar rápidamente el firewall chino no es una excepción. Por eso, me apresuro a compartir con vosotros el último, la parte final sobre este tema.

En la parte anterior hablamos de muchos bancos de pruebas que se nos ocurrieron y de los resultados que dieron. Y decidimos qué sería bueno agregar. CDN! para la viscosidad en nuestro esquema.

Les contaré cómo probamos Alibaba Cloud CDN, Tencent Cloud CDN y Akamai, y con qué terminamos. Y por supuesto, resumamos.

Cómo rompimos el Gran Cortafuegos de China (Parte 3)

CDN en la nube de Alibaba

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

Alibaba Cloud tiene dos tipos de productos que pueden convenirnos: CDN и DCDN. La primera opción es una CDN clásica para un dominio específico (subdominio). La segunda opción significa Ruta dinámica para CDN (Yo lo llamo CDN dinámico), se puede habilitar en modo de sitio completo (para dominios comodín), también almacena en caché el contenido estático y acelera el contenido dinámico sobre sí mismo, es decir, la dinámica de la página también se cargará a través del proveedor Redes rápidas. Esto es importante para nosotros, porque básicamente nuestro sitio es dinámico, utiliza muchos subdominios y es más conveniente configurar una CDN una vez para el "asterisco" - *.semrushchina.cn.

Ya habíamos visto este producto en las primeras etapas de nuestro proyecto chino, pero aún no funcionaba y los desarrolladores prometieron que el producto pronto estaría disponible para todos los clientes. Y él hizo.

En DCDN puedes:

  • configurar la terminación SSL con su certificado,
  • permitir la aceleración del contenido dinámico,
  • configurar de manera flexible el almacenamiento en caché de archivos estáticos,
  • purgar el caché,
  • enchufes web delanteros,
  • habilite la compresión e incluso el embellecedor HTML.

En general, todo es igual que con los adultos y los grandes proveedores de CDN.

Después de especificar el Origen (el lugar donde irán los servidores perimetrales CDN), todo lo que queda es crear un CNAME para el asterisco, haciendo referencia todo.semrushchina.cn.w.kunluncan.com (este CNAME se recibió en la consola de Alibaba Cloud) y la CDN funcionará.

Según los resultados de las pruebas, esta CDN nos ayudó mucho. Las estadísticas se muestran a continuación.

Solución
Uptime
Mediana
75 percentil
95 percentil

Cloudflare
86.6
Los 18s
Los 30s
Los 60s

IPsec
99.79
Los 18s
Los 21s
Los 30s

CEN
99.75
Los 16s
Los 21s
Los 27s

CEN/IPsec + GLB
99.79
Los 13s
Los 16s
Los 25s

Ali CDN + CEN/IPsec + GLB
99.75
Los 10s
Los 12.8s
Los 17.3s

Estos son muy buenos resultados, especialmente si los comparas con los números al principio. Pero sabíamos que la prueba de navegador de la versión americana de nuestro sitio web www.semrush.com se ejecuta desde EE. UU. en una media de 8.3 segundos (un valor muy aproximado). Hay posibilidad de mejora. Además, también había proveedores de CDN que era interesante probar.

Así que pasamos sin problemas a otro gigante del mercado chino: Tencent.

Nube Tencent

Tencent apenas está desarrollando su nube; esto se puede ver en un pequeño número de productos. Mientras lo usábamos, queríamos probar no sólo su CDN, sino también su infraestructura de red en su conjunto:

  • ¿Tienen algo similar al CEN?
  • ¿Cómo funciona IPSEC para ellos? ¿Es rápido? ¿Cuál es el tiempo de actividad?
  • ¿Tienen Anycast?

Cómo rompimos el Gran Cortafuegos de China (Parte 3)

Veamos estas preguntas por separado.

CEN analógico

Tencent tiene un producto Red de conexión a la nube (CCN), lo que le permite conectar VPC de diferentes regiones, incluidas regiones dentro y fuera de China. El producto ahora se encuentra en versión beta interna y es necesario crear un ticket solicitando conectarse a él. Aprendimos del soporte que las cuentas globales (no estamos hablando de ciudadanos chinos o entidades legales) no pueden participar en el programa de prueba beta y, en general, conectar una región dentro de China con una región fuera. 1-0 a favor de Ali Cloud

IPsec

La región más meridional de Tencent es Cantón. Montamos un túnel y lo conectamos con la región de Hong Kong en GCP (entonces esta región ya estaba disponible). Al mismo tiempo también se construyó el segundo túnel en Ali Cloud de Shenzhen a Hong Kong. Resultó que a través de la red Tencent la latencia hacia Hong Kong es generalmente mejor (10 ms) que desde Shenzhen a Hong Kong a Ali (120 ms, ¿qué?). Pero esto no aceleró de ninguna manera 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 demostró una vez más lo siguiente: la latencia: para China este no es un indicador que realmente valga la pena. prestar atención al desarrollar una solución para pasar el firewall chino.

Aceleración de Internet Anycast

Otro producto que le permite trabajar a través de IP anycast es AFP. Pero tampoco está disponible para cuentas globales, por lo que no les contaré nada al respecto, pero saber que dicho producto existe puede resultar útil.

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

Cómo rompimos el Gran Cortafuegos de China (Parte 3)

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

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

No nos alegramos mucho porque se reveló un problema: las pruebas en Catchpoint para el proveedor de Internet China Mobile fallaron. Desde cualquier ubicación recibimos un tiempo de espera a través del CDN de Tencent. La correspondencia con el soporte técnico no condujo a nada. Intentamos resolver este problema durante aproximadamente un día, pero nada funcionó.

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. Por lo demás, todo parecía rápido y bueno.
Sin embargo, debido a 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 pruebas y solución de problemas más prolongadas.

Akamai

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

Cómo rompimos el Gran Cortafuegos de China (Parte 3)

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

Lo que me gustó

  • Los chicos de Akamai fueron de gran ayuda en todas las preguntas y nos acompañaron en todas las etapas de las pruebas. Intentábamos constantemente mejorar algo de nuestra parte. Dieron buen asesoramiento técnico.
  • Akamai es entre un 10 % y un 15 % más lento que nuestra solución a través de Ali Cloud CDN. Lo impresionante es que en Origin para Akamai especificamos la dirección IP del GLB, lo que significa que el tráfico no pasó por nuestra solución (potencialmente podríamos abandonar parte de la infraestructura). Pero aún así, los resultados de las pruebas mostraron que esta solución es peor que nuestra versión actual (resultados comparativos a continuación).
  • Probado tanto Origin GLB como Origin in China. Ambas opciones son aproximadamente iguales.
  • Hay Ruta segura (optimización automática de enrutamiento). Puede alojar un objeto de prueba en Origin y los servidores Akamai Edge intentarán recogerlo (GET normal). Para estas solicitudes, se miden la velocidad y otras métricas, en función de las cuales la red Akamai optimiza las rutas para que el tráfico vaya más rápido a nuestro sitio y quedó claro que habilitar esta función realmente tuvo un fuerte impacto en la velocidad del sitio.
  • Versionar la configuración en la interfaz web es genial. Puedes comparar versiones, mirar diferencias. Ver versiones anteriores.
  • Puede implementar una nueva versión primero solo en la red Akamai Staging, la misma red que la de producción, solo que de esta manera no afectará a los usuarios reales. Para esta prueba, necesita falsificar los registros DNS en su máquina local.
  • Velocidad de descarga muy rápida a través de su red para archivos estáticos de gran tamaño y, aparentemente, cualquier otro archivo. Un archivo de la caché "fría" se recupera muchas veces más rápido que el mismo archivo de la caché "fría" de Ali CDN. Desde el caché "caliente", la velocidad ya es la misma, más o menos.

Prueba de 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 en el ejemplo anterior depende de varios factores. Al momento de escribir este punto, volví a ejecutar la prueba. Los resultados para ambas plataformas fueron aproximadamente los mismos. Esto nos dice que Internet en China, incluso para los grandes operadores y proveedores de nube, se comporta de manera diferente de vez en cuando.

Al punto anterior, agregaré una gran ventaja para Akamai: si Ali muestra flashes similares de alto rendimiento y muy bajo rendimiento (esto se aplica a Ali CDN, Ali CEN y Ali IPSEC), entonces Akamai, siempre, no importa. Cómo pruebo su red, todo funciona de manera estable.
Akamai tiene mucha cobertura en China y trabaja a través de muchos proveedores.

Lo que no me gustó:

  • No me gusta la interfaz web ni la forma en que funciona: es muy pobre. Pero básicamente te acostumbras (probablemente).
  • Los resultados de las pruebas son peores que los de nuestro sitio.
  • Hay más errores durante las pruebas que en nuestro sitio (tiempo de actividad a continuación).
  • No tenemos nuestros propios servidores DNS en China. Por lo tanto, hay muchos errores en las pruebas debido al tiempo de espera de resolución de DNS.
  • No proporcionan sus rangos de IP -> no hay forma de registrar los correctos set_real_ip_from en nuestros servidores.

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

Proveedor CDN
Mediana
75%
95%
Respuesta
Respuesta de la página web
Uptime
DNS
Contacto
Esperar
Carga
SSL

AliCDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

Distribución por percentil (en ms):

Percentil
Akamai
AliCDN

10
7,092
6,942

20
7,775
7,583

30
8,446
8,092

40
9,146
8,596

50
9,783
9,195

60
10,497
9,770

70
11,371
10,383

80
12,670
11,255

90
15,882
13,165

100
91,592
91,596

La conclusión es la siguiente: la opción de Akamai es viable, pero no proporciona la misma estabilidad y velocidad que nuestra propia solución junto con Ali CDN.

Pequeñas notas

Algunos momentos no fueron incluidos en la historia, pero me gustaría escribir sobre ellos también.

Pekín + Tokio y Hong Kong

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

Además, intentamos instalar la siguiente instalación:

  • terminación de clientes en Beijing,
  • IPSEC y CEN a Tokio,
  • en Ali CDN se indicó como origen el servidor 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, he visto caídas intermitentes incluso para el CEN, que debería ser estable. Por ello, volvimos al antiguo esquema y desmantelamos esta puesta en escena.

A continuación se muestran estadísticas sobre la latencia entre diferentes regiones para diferentes canales. Quizás a alguien le interese.

IPsec
Ali cn-beijing <—> GCP asia-noreste1 — 193ms
Ali cn-shenzhen <—> GCP asia-este2 — 91 ms
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 complemento 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 basó en pruebas de redes Wi-Fi públicas en varios lugares donde estas redes son utilizadas por un gran número de personas.
    • Las velocidades de descarga y carga a servidores dentro de China fueron de aproximadamente 20 Mbit/s y 5-10 Mbit/s, respectivamente.
    • La velocidad de los servidores fuera de China es simplemente escasa, menos de 1 Mbit/s.
  • Internet en China no es muy estable.
    • A veces, los sitios pueden abrirse rápidamente, a veces lentamente (a la misma hora en días diferentes), siempre que la configuración no cambie. Lo observamos con el ejemplo de semrushchina.cn. Esto se puede atribuir a Ali CDN, que también funciona de esta manera dependiendo de la hora del día, la posición de las estrellas, etc.
  • Internet móvil es casi en todas partes 4G o 4G+. Cógelo en el metro, en los ascensores; en resumen, en todas partes.
  • Es un mito que los usuarios chinos sólo confían en los dominios de la zona .cn. Esto lo aprendimos directamente de los usuarios.
    • Puedes ver como http://baidu.cn redirigir a www.baidu.com (también en China continental).
  • De hecho, muchos recursos están bloqueados. Primitivo: google.com, Facebook, Twitter. Pero muchos recursos de Google funcionan (por supuesto, no en todas las redes Wi-Fi y no se utiliza VPN (también en el lado del enrutador, eso es seguro).
  • También funcionan muchos dominios "técnicos" de empresas bloqueadas. Esto significa que no siempre debes eliminar imprudentemente todos los recursos de Google y otros recursos aparentemente bloqueados. Debe buscar alguna lista de dominios prohibidos.
  • Sólo tienen tres operadores principales de Internet: China Unicom, China Telecom y China Mobile. Los hay incluso más pequeños, pero su cuota de mercado es insignificante.

Bonificación: diagrama de solución final

Cómo rompimos el Gran Cortafuegos de China (Parte 3)

Total

Ha pasado un año desde el inicio del proyecto. Comenzamos con el hecho de que nuestro sitio generalmente se negaba a funcionar normalmente desde China, y simplemente GET curl tomó 5.5 segundos.

Luego, con estos indicadores en la primera solución (Cloudflare):

Solución
Uptime
Mediana
75 percentil
95 percentil

Cloudflare
86.6
Los 18s
Los 30s
Los 60s

Finalmente llegamos a los siguientes resultados (estadísticas del último mes):

Solución
Uptime
Mediana
75 percentil
95 percentil

Ali CDN + CEN/IPsec + GLB
99.86
Los 8.8s
Los 9.5s
Los 13.7s

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

Respeto a quienes leyeron las tres partes hasta el final. Espero que todo esto te haya parecido tan interesante como a mí cuando lo hice.

PD Partes anteriores

Часть 1
Часть 2

Fuente: habr.com

Añadir un comentario