Como rompemos o Grande Firewall da China (Parte 3)

Oi!
Todas as boas histórias chegam ao fim. E nossa história sobre como criamos uma solução para ultrapassar rapidamente o Firewall Chinês não é exceção. Portanto, apresso-me em compartilhar com vocês o último, a parte final sobre este assunto.

Na parte anterior falamos sobre muitos bancos de testes que criamos e quais resultados eles deram. E decidimos o que seria bom adicionar CDN! para viscosidade em nosso esquema.

Vou contar como testamos o Alibaba Cloud CDN, o Tencent Cloud CDN e o Akamai e o que descobrimos. E claro, vamos resumir.

Alibaba Nuvem CDN

Estamos hospedados no Alibaba Cloud e usamos IPSEC e CEN deles. Seria lógico tentar primeiro as suas soluções.

Alibaba Cloud tem dois tipos de produtos que podem nos servir: CDN и DCDN. A primeira opção é um CDN clássico para um domínio específico (subdomínio). A segunda opção representa Rota Dinâmica para CDN (eu chamo de CDN dinâmico), pode ser habilitado no modo Full-site (para domínios curinga), também armazena em cache o conteúdo estático e acelera o conteúdo dinâmico sobre si mesmo, ou seja, a dinâmica da página também será carregada através do provedor redes rápidas. Isso é importante para nós, porque basicamente nosso site é dinâmico, usa muitos subdomínios e é mais conveniente configurar um CDN uma vez para o “asterisco” - *.semrushchina.cn.

Já tínhamos visto este produto nas fases iniciais do nosso projecto chinês, mas ainda não estava a funcionar e os criadores prometeram que o produto estaria em breve disponível para todos os clientes. E ele fez.

No DCDN você pode:

• configure a terminação SSL com seu certificado,
• permitir a aceleração de conteúdo dinâmico,
• configurar com flexibilidade o cache de arquivos estáticos,
• limpar o cache,
• encaminhar soquetes de web,
• habilite a compactação e até mesmo o embelezador HTML.

Em geral, tudo é igual aos adultos e aos grandes provedores de CDN.

Depois de especificada a Origem (local para onde irão os servidores de borda CDN), resta criar um CNAME para o asterisco, referenciando all.semrushchina.cn.w.kunluncan.com (este CNAME foi recebido no console do Alibaba Cloud) e o CDN funcionará.

Com base nos resultados dos testes, este CDN nos ajudou muito. As estatísticas são mostradas abaixo.

Solução
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

São resultados muito bons, principalmente se você compará-los com os números iniciais. Mas sabíamos que o teste do navegador da versão americana do nosso site www.semrush.com é executado nos EUA em média 8.3s (um valor muito aproximado). Há espaço para melhorias. Além disso, também houve fornecedores de CDN que foram interessantes de testar.

Assim, passamos suavemente para outro gigante no mercado chinês - Tencent.

Nuvem Tencent

A Tencent está apenas desenvolvendo sua nuvem - isso pode ser visto em um pequeno número de produtos. Ao usá-lo, queríamos testar não apenas o CDN, mas também a infraestrutura de rede como um todo:

• eles têm algo semelhante ao CEN?
• Como o IPSEC funciona para eles? É rápido, qual é o tempo de atividade?
• eles têm Anycast?

Vejamos essas questões separadamente.

CEN analógico

Tencent tem um produto Rede de conexão à nuvem (CCN), permitindo conectar VPCs de diferentes regiões, incluindo regiões dentro e fora da China. O produto agora está em beta interno e você precisa criar um ticket solicitando conexão com ele. Aprendemos com o suporte que as contas globais (não estamos falando de cidadãos ou entidades legais chinesas) não podem participar do programa de testes beta e, em geral, conectar uma região dentro da China com uma região fora dela. 1-0 a favor de Ali Cloud

IPSEC

A região mais ao sul da Tencent é Cantão. Montamos um túnel e o conectamos à região de Hong Kong no GCP (então essa região já estava disponível). O segundo túnel em Ali Cloud, de Shenzhen a Hong Kong, também foi construído ao mesmo tempo. Descobriu-se que através da rede Tencent a latência para Hong Kong é geralmente melhor (10ms) do que de Shenzhen para Hong Kong e Ali (120ms - o quê?). Mas isso não acelerou em nada o trabalho do site que visa trabalhar através da Tencent e deste túnel, o que por si só foi um facto surpreendente e mais uma vez provou o seguinte: latência - para a China este não é um indicador que realmente valha a pena prestando atenção ao desenvolver uma solução para passar pelo firewall chinês.

Aceleração Anycast da Internet

Outro produto que permite trabalhar via IP anycast é AIA. Mas também não está disponível para contas globais, por isso não vou falar sobre isso, mas saber que tal produto existe pode ser útil.

Mas o teste CDN mostrou alguns resultados bastante interessantes. O CDN da Tencent não pode ser habilitado em um site completo, apenas em domínios específicos. Criamos domínios e enviamos tráfego para eles:

Descobriu-se que este CDN tem a seguinte função: Otimização do tráfego transfronteiriço. Esse recurso deverá reduzir custos quando o tráfego passar pelo firewall chinês. Como Origin O endereço IP do Google GLB (GLB anycast) foi especificado. Assim, queríamos simplificar a arquitetura do projeto.

Os resultados foram muito bons - no nível do Ali Cloud CDN, e em alguns lugares ainda melhores. Isto é surpreendente, porque se os testes forem bem sucedidos, pode-se abandonar uma parte significativa da infraestrutura, túneis, CEN, máquinas virtuais, etc.

Não nos alegramos por muito tempo, pois um problema foi revelado: os testes no Catchpoint falharam para o provedor de Internet China Mobile. De qualquer local, recebemos um tempo limite por meio do CDN da Tencent. A correspondência com o suporte técnico não levou a nada. Tentamos resolver esse problema por cerca de um dia, mas nada funcionou.

Eu estava na China naquele momento, mas não consegui encontrar Wi-Fi público na rede deste provedor para verificar pessoalmente o problema. Caso contrário, tudo parecia rápido e bom.
No entanto, devido ao facto da China Mobile ser uma das três maiores operadoras, fomos forçados a devolver o tráfego para Ali CDN.
Mas, no geral, esta foi uma solução bastante interessante que merece mais testes e solução de problemas para esse problema.

Akamai

O último provedor de CDN que testamos foi Akamai. Este é um grande provedor que tem sua rede na China. Claro, não poderíamos superar isso.

Desde o início, combinamos com a Akamai um período de teste para que pudéssemos trocar o domínio e ver como funcionaria na rede deles. Descreverei o resultado de todos os testes na forma de “O que gostei” e “O que não gostei” e também darei os resultados dos testes.

Do que você gostou?

• O pessoal da Akamai foi muito prestativo em todas as dúvidas e nos acompanhou em todas as etapas dos testes. Estávamos constantemente tentando melhorar algo do nosso lado. Eles deram bons conselhos técnicos.
• Akamai é cerca de 10-15% mais lenta que nossa solução via Ali Cloud CDN. O que é impressionante é que no Origin for Akamai especificamos o endereço IP do GLB, o que significa que o tráfego não passou pela nossa solução (potencialmente poderíamos abandonar parte da infraestrutura). Mesmo assim, os resultados dos testes mostraram que esta solução é pior que a nossa versão atual (resultados comparativos abaixo).
• Testado Origin GLB e Origin na China. Ambas as opções são aproximadamente iguais.
• Tem Rota certa (otimização automática de roteamento). Você pode hospedar um objeto de teste no Origin e os servidores Akamai Edge tentarão captá-lo (GET normal). Para essas solicitações, são medidas a velocidade e outras métricas, com base nas quais a rede Akamai otimiza as rotas para que o tráfego seja mais rápido para o nosso site e ficou claro que a ativação desse recurso realmente teve um forte impacto na velocidade do site.
• Versionar a configuração na interface web é legal. Você pode comparar as versões, veja as diferenças. Veja versões anteriores.
• Você pode lançar uma nova versão primeiro apenas na rede Akamai Staging - a mesma rede da produção, só que desta forma não afetará usuários reais. Para este teste, você precisa falsificar os registros DNS em sua máquina local.
• Velocidade de download muito rápida através de sua rede para grandes arquivos estáticos e, aparentemente, quaisquer outros arquivos. Um arquivo do cache “frio” é recuperado muitas vezes mais rápido do que o mesmo arquivo do cache “frio” do Ali CDN. Do cache “quente”, a velocidade já é a mesma, mais ou menos.

Teste 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

Teste 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

Percebemos que a situação do exemplo acima depende de vários fatores. No momento em que escrevo este ponto, fiz o teste novamente. Os resultados para ambas as plataformas foram aproximadamente os mesmos. Isto diz-nos que a Internet na China, mesmo para grandes operadores e fornecedores de nuvens, comporta-se de forma diferente de vez em quando.

Ao ponto anterior, acrescentarei uma grande vantagem para a Akamai: se Ali mostrar flashes semelhantes de alto desempenho e desempenho muito baixo (isso se aplica a Ali CDN, Ali CEN e Ali IPSEC), então Akamai, sempre, não importa como eu testo a rede deles, tudo funciona de forma estável.
A Akamai tem muita cobertura na China e trabalha através de muitos fornecedores.

O que não gostou:

• Não gosto da interface web e da forma como funciona - é muito pobre. Mas basicamente você se acostuma (provavelmente).
• Os resultados dos testes são piores do que o nosso site.
• Existem mais erros durante os testes do que em nosso site (tempo de atividade abaixo).
• Não temos nossos próprios servidores DNS na China. Portanto, há muitos erros nos testes devido ao tempo limite de resolução do DNS.
• Eles não fornecem seus intervalos de IP -> não há como registrar os corretos set_real_ip_from em nossos servidores.

Métricas (~3626 execuções; todas as métricas, exceto Tempo de atividade, em ms; estatísticas para um período):

Provedor CDN
Mediana
75%
95%
Resposta
Resposta da página da web
Uptime
DNS
Contato
Espere
Ver
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

Distribuição por percentil (em 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

A conclusão é esta: a opção Akamai é viável, mas não oferece a mesma estabilidade e velocidade que nossa própria solução aliada ao Ali CDN.

Pequenas notas

Alguns momentos não foram incluídos na história, mas gostaria de escrever sobre eles também.

Pequim + Tóquio e Hong Kong

Como disse acima, testamos um túnel IPSEC para Hong Kong (HK). Mas também testamos o CEN para HK. Custa um pouco menos, e fiquei pensando como funcionaria entre cidades com distância de ~100 km. Acabou sendo interessante que a latência entre essas cidades seja 100ms maior do que na nossa versão original (para Taiwan). Velocidade e estabilidade também foram melhores para Taiwan. Como resultado, deixamos HK como região IPSEC de backup.

Além disso, tentamos instalar a seguinte instalação:

• rescisão de clientes em Pequim,
• IPSEC e CEN para Tóquio,
• no Ali CDN o servidor em Pequim foi indicado como origem.

Este esquema não era tão estável, embora em termos de velocidade geralmente não fosse inferior à nossa solução. Em relação ao túnel, tenho visto quedas intermitentes até para o CEN, que deveria estar estável. Portanto, voltamos ao esquema antigo e desmontamos essa encenação.

Abaixo estão estatísticas sobre latência entre diferentes regiões para diferentes canais. Talvez alguém esteja interessado nisso.

IPsec
Ali cn-Pequim <—> GCP Ásia-Nordeste1 — 193ms
Ali cn-shenzhen <—> GCP ásia-leste2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

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

Informações gerais sobre a Internet na China

Além dos problemas com a Internet descritos no início, na primeira parte do artigo.

• A Internet na China é bastante rápida por dentro.
  • A conclusão foi feita com base em testes de redes Wi-Fi públicas em diversos locais onde essas redes são utilizadas por um grande número de pessoas.
  • As velocidades de download e upload para servidores dentro da China foram de cerca de 20 Mbit/s e 5-10 Mbit/s, respectivamente.
  • A velocidade para servidores fora da China é simplesmente escassa, inferior a 1 Mbit/s.
• A Internet na China não é muito estável.
  • Às vezes, os sites podem abrir rapidamente, às vezes lentamente (na mesma hora do dia em dias diferentes), desde que a configuração não mude. Observamos isso com o exemplo de semrushchina.cn. Isso pode ser atribuído ao Ali CDN, que também funciona dessa e daquela forma dependendo da hora do dia, da posição das estrelas, etc.
• A Internet móvel está em quase todos os lugares 4G ou 4G+. Pegue no metrô, nos elevadores - enfim, em qualquer lugar.
• É um mito que os usuários chineses confiem apenas em domínios na zona .cn. Aprendemos isso diretamente com os usuários.
  • Você pode ver como http://baidu.cn redirecionar para www.baidu.com (também na China continental).
• Muitos recursos estão de fato bloqueados. Primitivo: google.com, Facebook, Twitter. Mas muitos recursos do Google funcionam (é claro, nem em todos os Wi-Fi e VPN não são usados ​​(no lado do roteador também, isso é certo).
• Muitos domínios “técnicos” de empresas bloqueadas também estão funcionando. Isso significa que você nem sempre deve cortar de forma imprudente todos os recursos do Google e outros recursos aparentemente bloqueados. Você precisa procurar alguma lista de domínios proibidos.
• Eles têm apenas três operadoras principais de Internet: China Unicom, China Telecom, China Mobile. Existem ainda mais pequenos, mas a sua quota de mercado é insignificante

Bônus: diagrama de solução final

Total

Um ano se passou desde o início do projeto. Começamos com o fato de que nosso site geralmente se recusava a funcionar normalmente na China e simplesmente GET curl demorava 5.5 segundos.

Então, com estes indicadores na primeira solução (Cloudflare):

Solução
Uptime
Mediana
75 percentil
95 percentil

Cloudflare
86.6
18s
30s
60s

Finalmente alcançamos os seguintes resultados (estatísticas do último mês):

Solução
Uptime
Mediana
75 percentil
95 percentil

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

Como você pode ver, ainda não conseguimos atingir 100% de tempo de atividade, mas encontraremos algo e depois contaremos os resultados em um novo artigo :)

Respeito a quem leu as três partes até o fim. Espero que você tenha achado tudo isso tão interessante quanto eu quando fiz isso.

PS Partes anteriores

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

Fonte: habr.com