Como perfuramos o grande firewall chinês (parte 3)

Oi
Todas as boas histórias terminam. E nossa história sobre como criamos uma solução para a rápida passagem do firewall chinês não é exceção. Portanto, apresso-me em compartilhar com você a última parte final sobre esse tópico.


Na parte anterior, falamos sobre muitos bancos de teste inventados por nós e quais resultados eles deram. E decidimos que seria bom adicionar uma CDN! viscosidade em nosso circuito.


Vou lhe contar como testamos o Alibaba Cloud CDN, Tencent Cloud CDN e Akamai e o que acabei fazendo. E, claro, para resumir.



Alibaba Cloud CDN


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


O Alibaba Cloud possui dois tipos de produtos que podem nos atender: CDN e DCDN . A primeira opção é uma CDN clássica para um domínio específico (subdomínio). A segunda opção significa Rota dinâmica para CDN (eu chamo de CDN dinâmico), pode ser ativada no modo de site completo (para domínios curinga), também armazena em cache a estática e acelera o conteúdo dinâmico, ou seja, a dinâmica da página também carrega rapidamente provedor de rede. Isso é importante para nós, porque basicamente nosso site é dinâmico, usa muitos subdomínios e é mais conveniente configurar a CDN uma vez para a "estrela" - * .semrushchina.cn.


Já vimos esse produto nos estágios iniciais do nosso projeto chinês, mas ele ainda não funcionava, e os desenvolvedores prometeram que o produto estaria disponível para todos os clientes em breve. E ele se tornou.


No DCDN, você pode:


  • configure a terminação SSL com seu certificado,
  • habilitar a aceleração dinâmica de conteúdo,
  • configurar de forma flexível o cache de arquivos estáticos,
  • limpe o cache,
  • jogue soquetes da web,
  • habilite a compactação e até o embelezador de HTML.

Em geral, tudo é como adultos e grandes fornecedores de CDN.


Depois que o Origin (o local para onde os servidores de borda da CDN irão) for indicado, resta criar um CNAME para o asterisco, vinculando a all.semrushchina.cn.w.kunluncan.com (esse CNAME foi obtido no console do Alibaba Cloud) e CDN vai funcionar.


De acordo com os resultados do teste, este CDN nos ajudou muito. As estatísticas são fornecidas abaixo.


SoluçãoUpimeMedianaPercentil 75Percentil 95
Cloudflare86,618 anos30sAnos 60
IPsec99,7918 anos21s30s
Cen99,7516s21s27s
CEN / IPsec + GLB99,7913s16s25s
Ali CDN + CEN / IPsec + GLB99,7510s12.8s17.3s

Estes são resultados muito bons, especialmente se os compararmos com os números que estavam no início. Mas sabíamos que o teste do navegador da versão americana do nosso site www.semrush.com estava funcionando nos EUA em média por 8,3s (um valor muito aproximado). Há muito pelo que lutar. Além disso, havia provedores de CDN interessados ​​em testar.


Por isso, mudamos sem problemas para outro gigante no mercado chinês - a Tencent .


Nuvem Tencent


A Tencent está apenas desenvolvendo sua nuvem - isso é evidente em um pequeno número de produtos. No decorrer de seu uso, queríamos testar não apenas a CDN, mas também a infraestrutura de rede como um todo:


  • Eles têm algo parecido com o CEN?
  • Como o IPSEC funciona para eles? É rápido, o que é tempo de atividade?
  • Eles têm anycast?


Analisaremos essas perguntas separadamente.


CEN analógico


A Tencent possui um produto Cloud Connect Network ( CCN ) que permite interconectar VPCs de diferentes regiões, incluindo regiões dentro e fora da China. Agora, o produto está na versão beta interna e você precisa criar um ticket com uma solicitação para se conectar a ele. Com o suporte, aprendemos que as contas globais (não sobre cidadãos e entidades legais chinesas) não podem participar do programa de testes beta e geralmente conectam a região dentro da China à região externa. 1-0 a favor do Ali Cloud


IPSEC


A região mais ao sul de Tencent é Guangzhou . Construímos um túnel e o conectamos à região de Hong Kong no GCP (então essa região já estava disponível). Eles também levantaram o segundo túnel para Ali Cloud de Shenzhen para Hong Kong ao mesmo tempo. Verificou-se que, através da rede de latência Tencent, Hong Kong é geralmente melhor (10 ms) do que de Shenzhen a Hong Kong e Ali (120 ms - o que?). Mas isso não acelerou o trabalho do site destinado a trabalhar com a Tencent e esse túnel, que por si só era um fato surpreendente e mais uma vez provou o seguinte: latência - para a China, este não é um indicador ao qual você realmente deve prestar atenção ao desenvolver uma solução para passar pelos chineses firewall.


Anycast Internet Acceleration


Outro produto que permite trabalhar com o IP anycast é o AIA . Mas também é inacessível para contas globais, por isso não falarei sobre isso, mas saber que esse produto existe pode ser útil.


Mas o teste CDN mostrou resultados bastante interessantes. A CDN da Tencent não pode ser ativada em um site completo, apenas em domínios específicos. Temos domínios e começamos a trafegar neles:



Verificou-se que este CDN tem a seguinte função: Otimização do tráfego entre fronteiras . Esse recurso deve reduzir os custos quando o tráfego flui através do firewall chinês. Como origem , o endereço IP do Google GLB (GLB anycast) foi especificado. Então, queríamos simplificar a arquitetura do projeto.


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


Não ficamos felizes por muito tempo, porque o problema foi revelado: os testes no Catchpoint falsificaram para o provedor de Internet China Mobile. Em qualquer local, tivemos um tempo limite pela CDN da Tencent. A correspondência com o suporte técnico não levou a nada. Cerca de um dia, tentamos resolver esse problema, mas nada aconteceu.


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


Akamai


O último provedor de CDN que testamos é o Akamai . Este é um grande fornecedor que possui sua própria rede na China. Claro, não podíamos passar por ele.



Desde o início, concordamos com a Akamai em um período de teste para que possamos mudar o domínio e ver como ele funcionará na rede deles. Descreverei o resultado de todos os testes na forma de "O que eu gostei" e "O que eu não gostei", bem como os resultados do teste.


Do que você gostou:


  • Os caras da Akamai ajudaram muito em todos os assuntos e nos acompanharam em todas as etapas dos testes. Constantemente tentando melhorar algo do seu lado. Eles deram bons conselhos técnicos.
  • A Akamai roda cerca de 10 a 15% mais lenta que a nossa solução através do Ali Cloud CDN. É impressionante que no Origin tenha especificado o endereço IP GLB da Akamai, ou seja, o tráfego não passou pela nossa solução (você pode potencialmente abandonar parte da infraestrutura). Ainda assim, os resultados dos testes mostraram que esta solução é pior que a nossa versão atual (resultados comparativos abaixo).
  • Testou o Origin GLB e o Origin na China. Ambas as opções são iguais.
  • Há uma rota segura (otimização automática de roteamento). Você pode hospedar o objeto de teste no Origin, e o servidor Akamai Edge tentará buscá-lo (GET normal). Para essas solicitações, a velocidade e outras métricas são medidas, com base nas quais a rede Akamai otimiza as rotas para que o tráfego acelere em nosso site e pode-se observar que a inclusão desse recurso realmente teve um grande efeito na velocidade do site.
  • A versão da configuração na interface da web é legal. Você pode comparar para versões, consulte diff. Ver versões anteriores.
  • Você pode lançar a nova versão primeiro apenas na rede Akamai Staging - a mesma rede que a produção, mas dessa maneira não afeta usuários reais. Para este teste, você precisa falsificar registros DNS na máquina local.
  • Velocidade de download muito rápida através de sua rede de grandes estáticas e, aparentemente, de quaisquer outros arquivos. Um arquivo do cache "frio" é obtido várias vezes mais rápido que o mesmo arquivo do cache Ali CDN "frio". No cache "quente", a velocidade já é mais ou menos a mesma.

Ali teste 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 da redação deste texto, eu executei o teste novamente. Os resultados para ambas as plataformas foram aproximadamente os mesmos. Isso nos diz que a Internet na China, mesmo para grandes operadoras e provedores de nuvem, se comporta de maneira diferente de tempos em tempos.


Acrescentarei uma grande vantagem à Akamai no parágrafo anterior: se Ali mostrar flashes de alto desempenho e muito baixos (isso se aplica a Ali CDN, Ali CEN e Ali IPSEC), então na Akamai sempre, não importa como eu teste sua rede, tudo funciona de forma estável.
A Akamai realmente tem muita cobertura na China e trabalha com muitos fornecedores.


O que não gostou:


  • Eu não gosto da interface web e do esquema de trabalho - como zero. Mas basicamente você se acostuma (provavelmente).
  • Os resultados dos testes são piores que o nosso site.
  • Há mais erros durante os testes do que em nosso site (tempo de atividade abaixo).
  • Não há servidores DNS na China. A partir daqui, existem muitos erros nos testes devido ao tempo limite da resolução do DNS.
  • Não forneça seus intervalos de IP -> não há como registrar o set_real_ip_from correto em nossos servidores.

Métricas (~ 3626 executadas; todas as métricas, exceto Uptime em ms; estatísticas por um período de tempo):


Fornecedor de CDNMediana75%95%RespostaResposta da página da WebUpimeDNSConectarEsperaCarregarSSL
Ali CDN919510749174891.71510.74599.5315717927479200
Akamai978311887198882.35211.55098.98042491140838150.

Distribuição percentual (em ms):


PercentilAkamaiAli CDN
107.0926.942
207.7757.583
308.4468.092
40.9.1468.596
50.9.7839.195
6010.4979.770
7011.37110.383
8012.67011.255
9015.88213.165
10091.59291.596

A conclusão é a seguinte: a opção com a Akamai é viável, mas não fornece os mesmos indicadores de estabilidade e velocidade da nossa solução, juntamente com o Ali CDN.


Pequenas notas


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


Pequim + Tóquio e Hong Kong


Como eu disse acima, testamos o túnel IPSEC para Hong Kong (HK). Mas também testamos o CEN antes da HK. Custa um pouco mais barato e foi interessante como funcionará entre cidades com uma distância de ~ 100 km. Acabou sendo interessante que a latência entre essas cidades seja 100ms maior que em nossa versão original (para Taiwan). Velocidade, estabilidade também foi melhor para Taiwan. Como resultado, deixamos HK como uma região IPSEC de backup.


Além disso, tentamos criar uma instalação desse tipo:


  • rescisão do cliente em Pequim,
  • IPSEC e CEN para Tóquio,
  • em Ali, a CDN foi listada como o servidor de origem em Pequim.

Esse esquema não era tão estável, embora em termos de velocidade como um todo, não fosse inferior à nossa solução. Quanto ao túnel, vi quedas periódicas até para o CEN, que deveria ser estável. Portanto, retornamos ao esquema antigo e desmontamos esse teste.


Abaixo estão as estatísticas de latência entre diferentes regiões em diferentes canais. Talvez alguém se interesse por isso.


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


Cen
Ali cn-beijing <---> Ali ap-nordeste-1 - 54ms (!)
Ali cn-shenzhen <---> Ali cn-hong kong - 6ms (!)
Ali cn-shenzhen <---> Ali us-east1 - 216ms


Informações gerais sobre a Internet na China


Como complemento aos problemas com a Internet, descritos no início, na primeira parte do artigo.


  • A Internet na China é bem rápida por dentro.
    • A conclusão é feita com base no teste de redes Wi-Fi públicas em vários locais onde essas redes são usadas por um grande número de pessoas.
    • As velocidades de download e upload para servidores na China eram de aproximadamente 20 Mbps e 5-10 Mbps, respectivamente.
    • A velocidade dos servidores fora da China é miserável, menos de 1 Mbps.
  • 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 seja alterada. Observamos isso com o exemplo de semrushchina.cn. Isso pode ser atribuído ao Ali CDN, que também funciona dessa maneira e que, dependendo da hora do dia, da posição das estrelas, etc.
  • A Internet móvel está em quase todos os lugares 4G ou 4G +. Capturas no metrô, elevadores - em suma, em todos os lugares.
  • O fato de os usuários chineses confiarem apenas em domínios na zona .cn é um mito. Aprendemos isso diretamente dos usuários.
    • Você pode ver como o http://baidu.cn é redirecionado para www.baidu.com (também na China continental).
  • Muitos recursos estão realmente bloqueados. Primitivo: google.com, Facebook, Twitter. Mas muitos recursos do Google funcionam (é claro, nem todos os Wi-Fi e VPNs são usados ​​ao mesmo tempo (também no lado do roteador, isso é certo).
  • Muitos domínios "técnicos" de empresas bloqueadas também funcionam. Isso significa que você nem sempre deve cortar de forma imprudente todo o Google e outros recursos aparentemente bloqueados. Você precisa procurar uma lista de domínios proibidos.
  • Eles têm apenas três principais provedores de Internet: China Unicom, China Telecom, China Mobile. Existem ainda menores, mas sua participação no mercado é insignificante

Bônus: esquema de decisão final



Sumário


Um ano se passou desde o início do projeto. Começamos com o fato de que nosso site geralmente se recusava a trabalhar normalmente na China, mas apenas o GET curl levou 5,5 segundos.


Então, com esses indicadores na primeira decisão (Cloudflare):


SoluçãoUpimeMedianaPercentil 75Percentil 95
Cloudflare86,618 anos30sAnos 60

Como resultado, chegamos aos seguintes resultados (estatísticas do último mês):


SoluçãoUpimeMedianaPercentil 75Percentil 95
Ali CDN + CEN / IPsec + GLB99,868.8s9.5s13.7s

Como você pode ver, o tempo de atividade em 100% ainda não foi alcançado, mas criaremos algo e depois falaremos sobre os resultados em um novo artigo :)


Para quem leu todas as três partes até o fim - respeito. Espero que vocês tenham ficado tão interessados ​​quanto eu quando fiz isso.


Peças anteriores PS


Parte 1
Parte 2

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


All Articles