Como rompemos o gran firewall chinés (parte 3)

Ola!
Todas as boas historias chegan ao seu fin. E a nosa historia sobre como creamos unha solución para pasar rapidamente o firewall chinés non é unha excepción. Por iso, apúrome a compartir convosco o último, a parte final sobre este tema.

Na parte anterior falamos de moitos bancos de probas cos que chegamos e que resultados deron. E decidimos o que sería bo engadir CDN! para a viscosidade no noso esquema.

Vouche contar como probamos Alibaba Cloud CDN, Tencent Cloud CDN e Akamai, e o que acabamos. E por suposto, imos resumir.

Alibaba Cloud CDN

Estamos aloxados en Alibaba Cloud e usamos IPSEC e CEN desde eles. Sería lóxico probar as súas solucións primeiro.

Alibaba Cloud ten dous tipos de produtos que poden adaptarnos: CDN и DCDN. A primeira opción é unha CDN clásica para un dominio específico (subdominio). A segunda opción representa Ruta dinámica para CDN (Eu chámolle CDN dinámico), pódese activar no modo Sitio completo (para dominios comodíns), tamén almacena en caché contido estático e acelera o contido dinámico por si mesmo, é dicir, a dinámica da páxina tamén se cargará a través do fornecedor. redes rápidas. Isto é importante para nós, porque basicamente o noso sitio é dinámico, usa moitos subdominios e é máis conveniente configurar un CDN unha vez para o "asterisco" - *.semrushchina.cn.

Xa viramos este produto nas etapas anteriores do noso proxecto chinés, pero entón aínda non funcionaba e os desenvolvedores prometeron que o produto pronto estaría dispoñible para todos os clientes. E fíxoo.

En DCDN podes:

• configurar a terminación SSL co seu certificado,
• permitir a aceleración do contido dinámico,
• configurar de forma flexible o almacenamento en caché de ficheiros estáticos,
• purgar a caché,
• reenviar sockets web,
• habilite a compresión e incluso o embellecedor HTML.

En xeral, todo é o mesmo que cos adultos e os grandes provedores de CDN.

Despois de especificar a orixe (o lugar onde irán os servidores de borde CDN), só queda crear un CNAME para o asterisco, facendo referencia all.semrushchina.cn.w.kunluncan.com (este CNAME recibiuse na consola Alibaba Cloud) e o CDN funcionará.

Segundo os resultados das probas, este CDN axudounos moito. As estatísticas móstranse a continuación.

decisión
Uptime
Mediana
75 percentil
95 percentil

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

Son moi bos resultados, sobre todo se os comparas cos números que tiñan ao principio. Pero sabiamos que a proba do navegador da versión americana do noso sitio web www.semrush.com execútase desde EE. UU. nunha media de 8.3 segundos (un valor moi aproximado). Hai marxe de mellora. Ademais, tamén había provedores de CDN que eran interesantes para probar.

Así que pasamos sen problemas a outro xigante no mercado chinés - Tencent.

Tencent Cloud

Tencent só está a desenvolver a súa nube; isto pódese ver nun pequeno número de produtos. Mentres o usamos, queriamos probar non só a súa CDN, senón tamén a súa infraestrutura de rede no seu conxunto:

• teñen algo parecido ao CEN?
• Como funciona IPSEC para eles? É rápido, cal é o tempo de actividade?
• teñen Anycast?

Vexamos estas preguntas por separado.

CEN analóxico

Tencent ten un produto Cloud Connect Network (CCN), que che permite conectar VPC de diferentes rexións, incluídas rexións dentro e fóra de China. O produto está agora en versión beta interna e cómpre crear un ticket que solicite conectarse a el. Co apoio aprendemos que as contas globais (non estamos a falar de cidadáns chineses ou persoas xurídicas) non poden participar no programa de probas beta e, en xeral, conectar unha rexión dentro de China cunha rexión fóra. 1-0 a favor de Ali Cloud

IPSEC

A rexión máis meridional de Tencent é Cantón. Montamos un túnel e conectámolo á rexión de Hong Kong en GCP (daquela esta rexión xa estaba dispoñible). O segundo túnel en Ali Cloud de Shenzhen a Hong Kong tamén se levantou ao mesmo tempo. Resultou que a través da rede Tencent a latencia a Hong Kong é xeralmente mellor (10 ms) que desde Shenzhen a Hong Kong ata Ali (120 ms - que?). Pero isto non acelerou de ningún xeito o traballo do sitio destinado a traballar a través de Tencent e este túnel, que en si mesmo foi un feito sorprendente e demostrou unha vez máis o seguinte: latencia - para China, este non é un indicador que realmente valga a pena. prestando atención ao desenvolver unha solución para pasar o firewall chinés.

Aceleración de Internet Anycast

Outro produto que che permite traballar a través de anycast IP é AIA. Pero tampouco está dispoñible para as contas globais, polo que non che falarei, pero saber que existe tal produto pode ser útil.

Pero a proba CDN mostrou uns resultados bastante interesantes. O CDN de Tencent non se pode activar nun sitio completo, só en dominios específicos. Creamos dominios e enviamos tráfico a eles:

Resultou que este CDN ten a seguinte función: Optimización do tráfico transfronteirizo. Esta función debería reducir os custos cando o tráfico pasa polo firewall chinés. Como Orixe Especificouse o enderezo IP de Google GLB (GLB anycast). Así, queriamos simplificar a arquitectura do proxecto.

Os resultados foron moi bos, ao nivel de Ali Cloud CDN, e nalgúns lugares aínda mellores. Isto é sorprendente, porque se as probas teñen éxito, pódese abandonar unha parte importante da infraestrutura, túneles, CEN, máquinas virtuais, etc.

Non nos alegramos por moito tempo, xa que se revelou un problema: as probas en Catchpoint fallaron para o provedor de Internet China Mobile. Desde calquera localización recibimos un tempo de espera a través do CDN de Tencent. A correspondencia co soporte técnico non levou a nada. Tentamos resolver este problema durante aproximadamente un día, pero nada funcionou.

Estaba en China nese momento, pero non puiden atopar wifi pública na rede deste provedor para verificar o problema persoalmente. Se non, todo parecía rápido e ben.
Non obstante, debido ao feito de que China Mobile é un dos tres maiores operadores, vímonos obrigados a devolver o tráfico a Ali CDN.
Pero, en xeral, esta foi unha solución bastante interesante que merece probas máis longas e resolución de problemas deste problema.

Akamai

O último provedor de CDN que probamos foi Akamai. Este é un gran provedor que ten a súa rede en China. Por suposto, non puidemos pasar.

Desde o principio, acordamos con Akamai un período de proba para que puidésemos cambiar o dominio e ver como funcionaría na súa rede. Describirei o resultado de todas as probas en forma de "O que me gustou" e "O que non me gustou", e tamén darei os resultados da proba.

O que me gustou:

• Os rapaces de Akamai foron moi útiles en todas as preguntas e acompañáronnos en todas as fases das probas. Tentabamos constantemente mellorar algo do noso lado. Deron bos consellos técnicos.
• Akamai é un 10-15 % máis lento que a nosa solución a través de Ali Cloud CDN. O impresionante é que en Origin for Akamai especificamos o enderezo IP do GLB, o que significa que o tráfico non pasou pola nosa solución (potencialmente poderiamos abandonar parte da infraestrutura). Pero aínda así, os resultados das probas mostraron que esta solución é peor que a nosa versión actual (resultados comparativos a continuación).
• Probou Origin GLB e Origin en China. Ambas opcións son aproximadamente iguais.
• Ten Ruta segura (optimización automática de rutas). Podes aloxar un obxecto de proba en Origin e os servidores de Akamai Edge tentarán recollelo (GET normal). Para estas solicitudes, mídense a velocidade e outras métricas, en función das cales a rede Akamai optimiza as rutas para que o tráfico vaia máis rápido para o noso sitio e estaba claro que habilitar esta función realmente tivo un forte impacto na velocidade do sitio.
• A versión da configuración na interface web é xenial. Podes facer Comparar para versións, mirar a diferenza. Ver versións anteriores.
• Podes lanzar unha nova versión primeiro só na rede de Akamai Staging: a mesma rede que a produción, só que deste xeito non afectará aos usuarios reais. Para esta proba, debes falsificar os rexistros DNS na túa máquina local.
• Velocidade de descarga moi rápida a través da súa rede para ficheiros estáticos grandes e, ao parecer, calquera outro ficheiro. Un ficheiro da caché "fría" obtén moitas veces máis rápido que o mesmo ficheiro da caché "fría" de Ali CDN. Desde a caché "quente", a velocidade xa é a mesma, máis ou menos.

Proba 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

Proba 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

Observamos que a situación do exemplo anterior depende de varios factores. No momento de escribir este punto, realicei a proba de novo. Os resultados para ambas plataformas foron aproximadamente os mesmos. Isto indícanos que Internet en China, mesmo para grandes operadores e provedores de nube, compórtase de forma diferente de cando en vez.

Para o punto anterior, engadirei unha gran vantaxe para Akamai: se Ali mostra destellos similares de alto rendemento e rendemento moi baixo (isto aplícase a Ali CDN, Ali CEN e Ali IPSEC), entón Akamai, cada vez, non importa. como comprobo a súa rede, todo funciona de forma estable.
Akamai ten moita cobertura en China e traballa a través de moitos provedores.

O que non me gustou:

• Non me gusta a interface web nin o seu funcionamento: é tan pobre. Pero basicamente te acostumas (probablemente).
• Os resultados das probas son peores que o noso sitio.
• Hai máis erros durante as probas que no noso sitio (tempo de funcionamento a continuación).
• Non temos os nosos propios servidores DNS en China. Polo tanto, hai moitos erros nas probas debido ao tempo de espera de resolución de DNS.
• Non proporcionan os seus intervalos de IP -> non hai forma de rexistrar os correctos set_real_ip_from nos nosos servidores.

Métricas (~3626 execucións; todas as métricas excepto Tempo de actividade, en ms; estatísticas para un período de tempo):

Provedor de CDN
Mediana
75%
95%
Resposta
Resposta da páxina web
Uptime
DNS
Conectar
Espere
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 porcentual (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

A conclusión é a seguinte: a opción de Akamai é viable, pero non proporciona a mesma estabilidade e velocidade que a nosa propia solución xunto con Ali CDN.

Pequenas notas

Algúns momentos non foron incluídos na historia, pero tamén me gustaría escribir sobre eles.

Pequín + Tokio e Hong Kong

Como dixen anteriormente, probamos un túnel IPSEC a Hong Kong (HK). Pero tamén probamos CEN a HK. Custa un pouco menos e preguntábame como funcionaría entre cidades cunha distancia de ~100 km. Resultou interesante que a latencia entre estas cidades sexa 100 ms maior que na nosa versión orixinal (a Taiwán). A velocidade e a estabilidade tamén foron mellores para Taiwán. Como resultado, deixamos HK como rexión IPSEC de reserva.

Ademais, tentamos instalar a seguinte instalación:

• rescisión de clientes en Pequín,
• IPSEC e CEN a Tokio,
• en Ali CDN indicouse o servidor de Pequín como orixe.

Este esquema non era tan estable, aínda que en termos de velocidade xeralmente non era inferior á nosa solución. En canto ao túnel, vin caídas intermitentes incluso para o CEN, que debería ser estable. Por iso, volvemos ao antigo esquema e desmontamos esta posta en escena.

A continuación móstranse estatísticas sobre a latencia entre as distintas rexións para as distintas canles. Quizais alguén lle interese.

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

CEN
Ali cn-beijing <—> Ali ap-northeast-1 — 54 ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6 ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216 ​​ms

Información xeral sobre Internet en China

Como complemento aos problemas con Internet descritos ao principio, na primeira parte do artigo.

• Internet en China é bastante rápido dentro.
  • A conclusión foi baseada en probar redes Wi-Fi públicas en varios lugares onde estas redes son utilizadas por un gran número de persoas.
  • As velocidades de descarga e carga aos servidores de China foron de aproximadamente 20 Mbit/s e 5-10 Mbit/s, respectivamente.
  • A velocidade dos servidores fóra de China é simplemente escasa, menos de 1 Mbit/s.
• Internet en China non é moi estable.
  • Ás veces, os sitios poden abrirse rapidamente, outras lentamente (á mesma hora do día en días diferentes), sempre que a configuración non cambie. Observámolo co exemplo de semrushchina.cn. Isto pódese atribuír a Ali CDN, que tamén funciona deste xeito e doutro segundo a hora do día, a posición das estrelas, etc.
• Internet móbil está case en todas partes 4G ou 4G+. Cóllao no metro, nos ascensores, en resumo, en todas partes.
• É un mito que os usuarios chineses só confían nos dominios da zona .cn. Aprendemos isto directamente dos usuarios.
  • Podes ver como http://baidu.cn redirecciona a www.baidu.com (tamén na China continental).
• Moitos recursos están realmente bloqueados. Primitivo: google.com, Facebook, Twitter. Pero moitos recursos de Google funcionan (por suposto, non en todos os Wi-Fi e VPN non se usa (tamén no lado do enrutador, iso é seguro).
• Tamén están funcionando moitos dominios "técnicos" de corporacións bloqueadas. Isto significa que non sempre debes cortar temerariamente todos os recursos de Google e outros aparentemente bloqueados. Debes buscar algunha lista de dominios prohibidos.
• Só teñen tres operadores principais de Internet: China Unicom, China Telecom, China Mobile. Hai aínda máis pequenos, pero a súa cota de mercado é insignificante

Bonificación: diagrama da solución final

Total

Xa pasou un ano dende o inicio do proxecto. Comezamos co feito de que o noso sitio xeralmente negábase a funcionar normalmente desde China, e simplemente GET curl tardou 5.5 segundos.

Despois, con estes indicadores na primeira solución (Cloudflare):

decisión
Uptime
Mediana
75 percentil
95 percentil

Cloudflare
86.6
18s
30s
60s

Finalmente chegamos aos seguintes resultados (estatísticas do último mes):

decisión
Uptime
Mediana
75 percentil
95 percentil

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

Como podes ver, aínda non puidemos acadar o 100% de tempo de actividade, pero inventaremos algo e, a continuación, contarémosche os resultados nun novo artigo :)

Respecto aos que leron as tres partes ata o final. Espero que vos parecera todo isto tan interesante como eu cando o fixen.

PS Partes anteriores

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

Fonte: www.habr.com