🥇Cómo superamos el Gran Firewall de China (parte 3)

¡Hola!
Todas las buenas historias llegan a su fin. Y nuestra historia sobre cómo ideamos una solución para sortear el Gran Firewall de China no es una excepción. Por eso, me apresuro a compartir con ustedes la última, parte final sobre este tema.

En la parte anterior hablamos sobre muchos bancos de pruebas que ideamos y cuáles fueron los resultados que obtuvimos. Y nos detuvimos en que sería buena idea añadir ¡CDN! para mejorar nuestra estrategia.

Les contaré cómo probamos Alibaba Cloud CDN, Tencent Cloud CDN y Akamai, y en qué finalmente nos decidimos. Y, por supuesto, haremos un resumen.

Alibaba Cloud CDN

Estamos alojados en Alibaba Cloud, usamos IPSEC y CEN de ellos. Por lo tanto, lo lógico es probar primero sus soluciones.

Alibaba Cloud tiene dos tipos de productos que podrían servirnos: CDN y DCDN. La primera opción es un CDN clásico para un dominio específico (subdominio). La segunda opción se traduce como Dynamic Route for CDN (la llamo CDN dinámico), se puede habilitar en modo Full-site (para dominios wildcard), también almacena en caché los archivos estáticos y acelera el contenido dinámico, es decir, la dinámica de la página también se cargará a través de las rápidas redes del proveedor. Esto es importante para nosotros porque nuestra web es principalmente dinámica, utiliza muchos subdominios, y es más conveniente configurar el CDN una vez para "asterisco" — *.semrushchina.cn.

Ya habíamos visto este producto en etapas anteriores de nuestro proyecto en China, pero en ese momento aún no estaba funcionando, y los desarrolladores prometieron que pronto estaría disponible para todos los clientes. Y ya está aquí.

En DCDN se puede:

configurar la terminación de SSL con su propio certificado,
habilitar la aceleración del contenido dinámico,
personalizar la caché de archivos estáticos,
realizar purgas de caché,
pasar websockets,
activar la compresión y hasta HTML Beautifier.

En general, todo como en los grandes y serios proveedores de CDN.

Después de que se indique el Origin (el lugar al que irán los servidores de edge de CDN), solo queda crear un CNAME para el asterisco que apunte a all.semrushchina.cn.w.kunluncan.com (este CNAME fue obtenido en la consola de Alibaba Cloud), y el CDN funcionará.

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

Solución
Tiempo de actividad
Mediana
Percentil 75
Percentil 95

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

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

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

Estos son resultados muy buenos, especialmente si se comparan con las cifras del principio. Pero sabíamos que la prueba del navegador de la versión estadounidense de nuestro sitio web www.semrush.com se realiza desde EE. UU. en un promedio de 8.3s (un valor muy aproximado). Hay un camino por recorrer. Además, había otros proveedores de CDN que era interesante probar.

Así que pasamos suavemente a otro gigante en el mercado chino — Tencent.

Tencent Cloud

Tencent está desarrollando su nube — esto se nota por la pequeña cantidad de productos. Durante su uso, queríamos probar no solo su CDN, sino también, en general, la infraestructura de red:

¿tienen algo parecido a CEN?
¿cómo funciona IPSEC para ellos? ¿Es rápido, cuál es el uptime?
¿tienen Anycast?

Analizaremos estas preguntas por separado.

Análogo a CEN

Tencent tiene un producto Cloud Connect Network (CCN), que permite conectar VPC entre diferentes regiones, incluyendo regiones dentro y fuera de China. El producto está actualmente en beta interna y se debe crear un ticket solicitando unirse a ella. Del soporte técnico nos enteramos que las cuentas globales (no se refiere a ciudadanos de China ni a entidades legales) no pueden participar en el programa de beta testing 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 al sur de Tencent es — Cantón. Creamos un túnel y lo conectamos con la región de Hong Kong en GCP (en ese momento esta región ya estaba disponible). También levantamos simultáneamente un segundo túnel en Ali Cloud desde Shenzhen a Hong Kong. Resultó que a través de la red de Tencent, la latencia hacia Hong Kong es, en general, mejor (10ms), que desde Shenzhen a Hong Kong en Ali (120ms — ¿qué?). Pero esto no aceleraba la carga del sitio, que estaba diseñado para funcionar a través de Tencent y este túnel, lo cual fue un hecho sorprendente y una vez más probaba lo siguiente: la latencia — para China esto no es un indicador que realmente merezca la pena considerar al desarrollar una solución para pasar el firewall chino.

Anycast Internet Acceleration

Otro producto que permite trabajar a través de IP anycast es — AIA. Pero también está indisponible para cuentas globales, así que no hablaré sobre él, aunque saber que existe puede ser útil.

Sin embargo, la prueba del CDN mostró resultados bastante interesantes. No se puede activar el CDN de Tencent en un sitio completo, solo en dominios específicos. Registramos dominios y les dirigimos tráfico:

Resultó que este CDN tiene esta función: Optimización del tráfico transfronterizo. Esta función debe reducir los costos al pasar el tráfico a través del firewall chino. Como Origen se especificó la dirección IP del GLB de Google (GLB anycast). Así queríamos simplificar la arquitectura del proyecto.

Los resultados fueron muy buenos, a la par con Ali Cloud CDN, y en algunos casos incluso mejores. Esto es sorprendente, porque si las pruebas tienen éxito, se podría prescindir de una parte importante de la infraestructura, túneles, CEN, virtuales, etc.

No disfrutamos de este éxito durante mucho tiempo, ya que surgió un problema: las pruebas en Catchpoint fallaban para el proveedor de internet China Mobile. Desde cualquier ubicación recibíamos un timeout a través de CDN de Tencent. La correspondencia con el soporte técnico no llevó a nada. Intentamos resolver este problema durante aproximadamente un día, pero no logramos nada.

En ese momento, me encontraba en China, pero no pude encontrar Wi-Fi público en la red de este proveedor para verificar el problema personalmente. Aparte de eso, todo parecía rápido y bien.
Sin embargo, dado que el operador China Mobile está entre los tres principales proveedores, nos vimos obligados a devolver el tráfico a Ali CDN.
Pero en general, 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 propia red en China. Por supuesto, no podíamos pasarlo por alto.

Desde el principio, acordamos con Akamai un período de prueba, para que pudiéramos cambiar el dominio y ver cómo funcionaría en su red. Describiré los resultados de todas las pruebas en términos de “Lo que nos gustó” y “Lo que no nos gustó”, así como presentaré los resultados de las pruebas.

Lo que nos gustó:

El equipo de Akamai fue muy servicial con todas las preguntas y nos acompañó en todas las etapas de las pruebas. Siempre intentaban mejorar algo de su lado. Ofrecían buenos consejos técnicos.
Akamai funcionó aproximadamente un 10-15% más lento que nuestra solución a través de Ali Cloud CDN. Es impresionante que, en el Origen para Akamai, especificamos la dirección IP del GLB, lo que significa que el tráfico no pasaba a través de nuestra solución (potencialmente podríamos prescindir de parte de la infraestructura). Pero, sin embargo, los resultados de las pruebas mostraron que esta opción era peor que nuestra opción actual (los resultados comparativos están a continuación).
Se probaron tanto el Origen GLB como el Origen en China. Ambas opciones son prácticamente iguales.
Hay Ruta segura (optimización automática de enrutamiento). Puedes colocar un objeto de prueba en Origin, y los servidores Edge de Akamai intentarán recuperarlo (una solicitud GET normal). Para estas solicitudes se mide la velocidad y otras métricas, con base en las cuales la red de Akamai optimiza las rutas, para que el tráfico fluya más rápido para nuestro sitio y se pueda ver que habilitar esta función realmente afectó significativamente la velocidad de funcionamiento del sitio.
La gestión de versiones de configuración en la interfaz web es genial. Puedes hacer una Comparación para las versiones, ver el diff. Consultar versiones anteriores.
Puedes desplegar una nueva versión primero solo en la red Staging de Akamai — una red idéntica a la de producción, pero este camino no afecta a los usuarios reales. Para esta prueba es necesario realizar un spoofing de registros DNS en la máquina local.
Una velocidad de carga muy rápida a través de su red de gran estática, y, aparentemente, de cualquier otro archivo. Un archivo de la caché 'fría' se recupera mucho más rápido que el mismo archivo de la caché 'fría' de Ali CDN. Desde la caché 'caliente', la velocidad ya es más o menos igual.

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

Hemos notado que la situación del ejemplo anterior depende de varios factores. En el momento de escribir este punto, realicé la prueba nuevamente. Los resultados para ambas plataformas resultaron ser aproximadamente iguales. Esto nos indica que Internet en China, incluso para grandes operadores y proveedores de servicios en la nube, se comporta de manera diferente de vez en cuando.

A este punto, añadiré un gran punto a favor de Akamai: mientras que en Ali se pueden observar picos de alto rendimiento y muy bajos (esto se aplica tanto a Ali CDN como a Ali CEN y Ali IPSEC), en Akamai cada vez que pruebo su red, todo funciona de manera estable.
Akamai realmente tiene una gran cobertura en China y trabaja con muchos proveedores.

Lo que no me gustó:

No me gusta la interfaz web y el esquema de trabajo: son bastante básicos. Pero en principio te acostumbras (supongo).
Los resultados de las pruebas son peores que los de nuestra plataforma.
Hay más errores en las pruebas que en nuestra plataforma (el tiempo de actividad es menor).
No tienen sus propios servidores DNS en China. Esto provoca muchos errores en las pruebas debido a tiempo de espera de resolución DNS.
No proporcionan sus rangos de IP -> no hay posibilidad de configurarlos correctamente. set_real_ip_from en nuestros servidores.

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

Proveedor de CDN
Mediana
75%
95%
Response
Respuesta de la página web
Tiempo de actividad
DNS
Conexión
Esperar
Cargar
SSL

Ali CDN
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
Ali CDN

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 con Akamai es viable, pero no proporciona los mismos niveles de estabilidad y velocidad como nuestra propia solución junto con Ali CDN.

Pequeñas notas

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

Pekín + Tokio y Hong Kong

Como mencioné antes, probamos el túnel IPSEC hasta Hong Kong (HK). Pero también probamos CEN hasta HK. Este es un poco más barato y era interesante ver cómo funcionaba entre ciudades a aproximadamente 100 km de distancia. Resultó interesante que la latencia entre estas ciudades era 100 ms más alta que nuestra opción original (hacia Taiwán). La velocidad y estabilidad también fueron mejores para Taiwán. Al final, dejamos HK como región IPSEC de respaldo.

Además, intentamos establecer una instalación así:

terminación de clientes en Pekín,
IPSEC y CEN hasta Tokio,
en Ali CDN se indicaba como servidor de origen en Pekín.

Este esquema no era tan estable, aunque por velocidad en general no era inferior a nuestra solución. En cuanto al túnel, observé caídas periódicas incluso para CEN, que debería haber sido estable. Por lo tanto, volvimos al esquema antiguo y desmantelamos esta etapa.

A continuación se muestran estadísticas de latencia entre diferentes regiones a través de diferentes canales. Puede que a algunos les interese.

IPsec
Ali cn-beijing GCP asia-northeast1 — 193ms
Ali cn-shenzhen GCP asia-east2 — 91ms
Ali cn-shenzhen GCP us-east4 — 200ms

CEN
Ali cn-beijing Ali ap-northeast-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 de Internet descritos al principio, en la primera parte del artículo.

Internet en China funciona bastante rápido en su interior.
- La conclusión se basa en pruebas de redes Wi-Fi públicas en diversas ubicaciones donde estas redes son utilizadas por un gran número de personas.
- La velocidad de descarga y carga en servidores dentro de China era de aproximadamente 20 Mbps y 5-10 Mbps respectivamente.
- La velocidad hacia servidores fuera de China es simplemente minúscula, menos de 1 Mbps.
Internet en China no es muy estable.
- A veces los sitios pueden cargar rápidamente, otras veces lentamente (a la misma hora del día en diferentes días), siempre que la configuración no cambie. Lo hemos observado con el ejemplo de semrushchina.cn. Esto se puede atribuir a Ali CDN, que también funciona de manera irregular dependiendo de la hora del día, la posición de las estrellas, etc.
Internet móvil es prácticamente 4G o 4G+ en todas partes. Funciona en el metro, ascensores — en resumen, en todas partes.
El mito de que los usuarios chinos solo confían en dominios de la zona .cn es falso. Lo hemos confirmado directamente con los usuarios.
- Se puede ver cómo http://baidu.cn redirige a www.baidu.com (también en la China continental).
Muchos recursos están realmente bloqueados. De manera simple: google.com, Facebook, Twitter. Pero muchos recursos de Google funcionan (por supuesto, no en todas las Wi-Fi y VPN no se utiliza (en el lado del enrutador también, eso es seguro).
Muchos dominios 'técnicos' de corporaciones bloqueadas también funcionan. Esto significa que no siempre se debe eliminar imprudentemente todos los recursos de Google y otros que parecen bloqueados. Es necesario buscar alguna lista de dominios prohibidos.
Tienen solo tres principales operadores de Internet: China Unicom, China Telecom, China Mobile. Hay otros más pequeños, pero su cuota en el mercado es insignificante.

Bonificación: esquema de solución final

Summary

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

Luego, con esas cifras en la primera solución (Cloudflare):

Solución
Tiempo de actividad
Mediana
Percentil 75
Percentil 95

Cloudflare
86.6
18s
30s
60s

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

Solución
Tiempo de actividad
Mediana
Percentil 75
Percentil 95

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

Como se puede ver, lograr un 100% de uptime todavía no ha sido posible, pero encontraremos alguna solución y luego les contaremos los resultados en un nuevo artículo :)

Un respeto a quien haya llegado al final de las tres partes. Espero que todo esto haya sido tan interesante para ustedes como lo fue para mí al hacerlo.