Olá a todos!
Aqui é o Nikita — engenheiro de sistemas da empresa SEMrush. Hoje vou contar como enfrentamos o desafio de garantir a estabilidade do nosso serviço semrush.com na China e quais problemas encontramos durante o processo (considerando a localização do nosso data center na costa leste dos Estados Unidos).
Esta será uma grande história, dividida em várias partes. Contarei como tudo isso aconteceu conosco: desde um serviço totalmente inoperante na China até a performance do serviço comparável à versão americana para os americanos. Prometo que será interessante e útil. Então, vamos lá.
Problemas da internet chinesa
Mesmo a pessoa mais distante da administração de redes já ouviu falar pelo menos uma vez do Grande Firewall da China. Uau, parece legal, não? Mas o que é isso e como realmente funciona é uma pergunta bastante complexa. Na internet, é possível encontrar muitos artigos sobre isso, mas, do ponto de vista técnico, a estrutura desse firewall não é descrita em nenhum lugar. O que, aliás, não é surpreendente. Posso confessar que, após um ano de trabalho, não serei capaz de dizer exatamente como ele funciona, mas posso compartilhar minhas observações e conclusões práticas. E começaremos com os rumores sobre este firewall.
Há muitos rumores sobre esse firewall. Vamos reunir os principais e mais interessantes em uma única lista:
- Google, Facebook, Twitter e outros serviços semelhantes estão bloqueados e não funcionam na China.
- Qualquer tráfego que vá para FORA da China e PARA a China é analisado e restrito por meio de aprendizado de máquina (em caso de tráfego suspeito), o que desacelera muito esse tráfego que atravessa a fronteira.
- Os serviços secretos chineses conseguem hackear qualquer tráfego criptografado que passe pelo seu firewall.
- Túneis VPN e túneis IPSEC são instáveis, caem e são constantemente bloqueados.
- Quanto mais simples for a criptografia, mais simples for a frase secreta usada para autenticação / criptografia do tráfego, mais rápido ele passa pelo firewall chinês.
Aqui está o que conseguimos descobrir sobre esses rumores:
- Google, Facebook, Twitter e outros serviços semelhantes estão realmente bloqueados (seu K0), mas muitos domínios técnicos do Google, como gstatic.com, não estão banidos e funcionam. A conclusão é que não se deve excluir sem critério todos os recursos do Google e outros que parecem estar bloqueados.
- Qualquer tráfego que ultrapassa a fronteira realmente adiciona um atraso significativo ao seu tempo. Veja dois resultados. Um site, uma página, um simples GET. curlO primeiro teste é feito diretamente da China (a linda cidade de Shenzhen). O segundo teste é feito do lado de fora, de Hong Kong (que tem soberania e não há firewall entre ele e o mundo). A distância entre as cidades em linha reta é de aproximadamente 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sPreste atenção em time_connect. E em geral, você vê o resultado: o firewall adiciona 4 segundos extras, o que é absurdamente longo.
- VPNs e túneis IPSEC realmente costumam cair. Vou falar sobre isso mais adiante e em mais detalhes. Os servidores VPN usados pelos usuários, com o tempo, são bloqueados (geralmente dentro de um dia após o início do uso).
- Há uma opinião, baseada em depoimentos de pessoas que vivem na China, de que quanto mais simples a criptografia do tráfego, mais rápido ele passa pela fronteira, pois é fácil perceber que não há nada ilegal. E o tráfego 'limpo' obtém mais largura de banda e velocidade, enquanto o tráfego 'sujo', que é difícil de entender, tem um retorno mais lento. Para exemplo, vou citar o CURL até ifconfig.co usando os protocolos HTTPS e HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
time_namelookup: 0.004305
time_connect: 0.397465
time_appconnect: 5.149305
time_pretransfer: 5.149393
time_redirect: 0.000000
time_starttransfer: 5.568847
----------
time_total: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
time_namelookup: 0.004282
time_connect: 0.212457
time_appconnect: 0.000000
time_pretransfer: 0.212484
time_redirect: 0.000000
time_starttransfer: 0.450565
----------
time_total: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/sA diferença de 5 segundos no tempo total de download de 13 bytes. Ao realizar esse teste várias vezes, pode-se notar que o GET em HTTP geralmente conclui em tempos similares, enquanto em HTTPS o site às vezes responde em 3, 5, 10 e até 17 segundos. Às vezes ocorrem erros SSL:
Erro de protocolo SSL desconhecido na conexão com ifconfig.co:443.
Então, o que temos:
- Os problemas causados pelo firewall chinês, descritos acima.
- Os pings para recursos externos e dentro dos túneis às vezes falham.
- A latência entre dois pontos muda constantemente e muitas vezes é imprevisível. Ao conectar diferentes cidades/regiões, espera-se que a latência seja menor devido à localização geográfica, mas se obtém o oposto.
- A internet e as linhas de comunicação funcionam tanto rápido quanto devagar. Há uma leve dependência do horário e do dia da semana, mas não sempre.
- As consultas DNS para o mundo exterior a partir da China às vezes ultrapassam o limite de tempo permitido.
A imagem se revela simplesmente "excelente".
O data center, como já mencionei, está na costa leste dos EUA, e todo o SEMrush é composto por dezenas de produtos interconectados, back-ends, front-ends, bancos de dados, e tudo isso nos data centers e na nuvem. Nossa equipe de administradores de sistema foi encarregada de começar a trabalhar na China com o mínimo de esforço.
Precisávamos responder a uma pergunta importante: poderíamos resolver todos os problemas relacionados à internet e ao firewall chinês com um mínimo de esforço, no nível da rede/nuvem/servidores?
Começamos obtendo .
licença ICP
Para poder hospedar seu serviço dentro da China Continental e realizar testes, primeiro é necessário obter uma licença ICP para o domínio.
Se o tráfego do usuário do seu site for interrompido dentro da China continental, e se o seu domínio não tiver uma licença ICP, seu tráfego será bloqueado pelo provedor/host. Curiosamente, a licença ICP é vinculada a um provedor específico, seja Cloudflare ou Alibaba Cloud. Portanto, se você obteve uma licença ICP para Cloudflare e hospedou seu site com eles, não será possível
Após obter a licença ICP para o domínio, conseguimos idealizar e implementar ideias e soluções técnicas específicas.
Testando soluções
Mas antes de criar efetivamente as opções de staging, ajustar as configurações, otimizar o desempenho do site e sua velocidade, é necessário escolher uma ferramenta para testes, para entender quais de nossas ações melhoram ou, ao contrário, prejudicam o funcionamento do site.
Nossa ferramenta de teste deve cumprir dois requisitos principais:
- ela deve ser capaz de executar testes a partir da China,
- ela deve suportar testes de navegador.
Assim, encontramos ! Eles têm uma excelente cobertura de pontos de teste em todo o mundo. Na China, através dessa ferramenta, é possível executar testes de 100500 províncias. Em cada uma, diferentes provedores + a possibilidade de realizar Backbone-testes (algo semelhante a uma virtualização em um data center) e Lastmile-testes (maximamente próximos às condições do usuário, ou seja, estações de trabalho). Este último tipo de teste custa mais caro.
Após fechar um contrato anual (não é possível menos), começamos a explorar a ferramenta. Para ser sincero, ficamos agradavelmente surpresos com sua funcionalidade. É possível executar:
- Testes de DNS,
- Testes Web (navegador, simples GET/POST, simulação de cliente móvel, etc.),
- Verificações transacionais (por exemplo, login),
- Testes de API,
- Ping, traceroute, NTP, etc.
É impossível enumerar tudo. E o mais importante, cada teste pode ser bastante personalizado, adicionando um conjunto de cabeçalhos e outros parâmetros. O resultado é uma quantidade enorme de informações, completamente descrevendo seu teste. Falando do que é mais interessante para nós (testes de navegador), o resultado inclui:
- Conexão, Espera, Carregamento, SSL, tempo de DNS,
- TTFB, TTLB, Document complete, Render time, DOM load,
- Resposta (algo próximo ao Time To First Byte), Resposta da página Web (algo próximo ao Time To Last Byte),
- Qualquer percentil, Tempo Médio, Mediana
- E assim por diante.
Assim, todas essas métricas ajudam a ver as mudanças e a entender se houve melhora. Nós, principalmente, observamos Resposta, Resposta da Página, Mediana, Percentis 75 e 95.
Uma pergunta importante que pairava desde o início: é possível confiar na Catchpoint?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Isso é um grande problema, porque estando na Rússia, é praticamente impossível saber com precisão como um site funciona a partir da China. Usando um socks-proxy através de uma máquina virtual, o carregamento do site leva alguns minutos, o que é inaceitável para testes; portanto, a única opção de teste manual permanece sendo o curl e simples GETs no console com medição de tempo. Isso ajuda, pois esse teste reflete bem a velocidade da solução de rede, e se houver testes de navegador, melhor ainda.
Mais tarde, fomos à China e confirmamos que é possível confiar na Catchpoint, ela reflete com bastante precisão os indicadores reais de velocidade.
Rede China da Cloudflare
Como utilizamos com sucesso a Cloudflare para o domínio principal semrush.com, decidimos imediatamente testar sua funcionalidade chamada . Esta opção é ativada apenas para sites Enterprise mediante solicitação separada e pagamento adicional. Ela também está disponível apenas para sites que possuem a licença ICP correspondente, na qual a Cloudflare é indicada como provedora. Após a ativação, o site tem acesso ao "CDN chinês" da Cloudflare — o tráfego das regiões chinesas é direcionado ao PoP (Pontos de Presença) mais próximo da CF, e então é entregue até a origem através de suas redes ou redes de provedores/parceiros.
O esquema deste ambiente de testes é apresentado abaixo.
Para nós, essa é uma ótima opção. Assim, o segundo domínio também ficará sob a CF, o que não aumenta a quantidade de soluções utilizadas na empresa, além de praticamente não complicar a infraestrutura.
Realizamos os testes de navegador, e aqui estão os resultados:
Os losangos vermelhos representam falhas nos testes. As falhas na parte inferior são erros de DNS (timeout de resolução). As falhas na parte superior são timeouts.
Uptime: 86,6
Mediana: 18s
Percentil 75: 29,3s
Percentil 95: 60s
A mediana, após remover a carga reCaptcha (serviço do Google, bloqueado na China), caiu de 28 para 18 segundos. Mas ainda são indicadores horríveis, considerando que o mesmo teste para semrush.com (dos EUA) forneceu menos de 10 segundos para 95% dos usuários (dos EUA) na mesma página (estática + dinâmica).
É possível acessar cada teste e visualizar Waterfall e outros parâmetros mais detalhados. Começamos a investigar as causas dos erros, e se para os timeouts tudo é mais ou menos compreensível: a internet na China “vai e volta”, o que faz com que a velocidade de conexão e o carregamento de recursos do exterior sejam instáveis e variáveis, as falhas de DNS nos surpreenderam bastante. Descobrimos que PoP na Cloudflare realmente estão na China, o endereço do site resolve em um IP anycast, mas os servidores DNS utilizados são americanos, o que faz com que as consultas DNS tenham que passar pela fronteira, resultando em falhas às vezes.
Ao esclarecer essa questão com a CF, descobrimos que eles não têm seus próprios servidores DNS na China, e ainda não se sabe quando terão.
Portanto, decidimos testar apenas o DNS da Cloudflare e mudamos o mecanismo de operação da Cloudflare para o nosso site para o modo “Apenas DNS”. Este é um modo em que a Cloudflare não proxy o tráfego por meio dela, o que significa que não fornece proteção DDoS, CDN e outras funcionalidades, funcionando como um servidor DNS comum.
Este stand é apresentado esquematicamente na próxima figura. Na figura, são consideradas as novas informações sobre os servidores DNS da Cloudflare atrás do firewall.
Na Catchpoint, executamos testes GET simples (não baseados em navegador), que mostraram muitas falhas. A causa delas eram os mesmos erros de DNS.
Começamos a depurar esses erros com o dig e descobrimos que, na primeira consulta, o endereço é determinado corretamente, mas a cada nova consulta recebemos SERVFAIL e não encontrado. Por que isso?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn tem o endereço 220.170.186.192
Host semrushchina.cn não encontrado: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn tem o endereço 220.170.186.192
Host semrushchina.cn não encontrado: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn tem o endereço 220.170.186.192
Host semrushchina.cn não encontrado: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn tem o endereço 220.170.186.192
Host semrushchina.cn não encontrado: 2(SERVFAIL)Ao consultar diretamente os servidores NS da Cloudflare, tais erros não ocorrem:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Usando o servidor de domínio:
Nome: ray.ns.cloudflare.com.
Endereço: 173.245.59.138#53
Apelidos:
semrushchina.cn tem o endereço 220.170.186.192
semrushchina.cn tem o endereço 220.170.186.192
Usando o servidor de domínio:
Nome: ray.ns.cloudflare.com.
Endereço: 173.245.59.138#53
Apelidos:
semrushchina.cn tem o endereço 220.170.186.192
semrushchina.cn tem o endereço 220.170.186.192Assim, o problema está do lado do servidor DNS “local” ou do servidor do provedor.
Uma investigação posterior mostrou que SERVFAIL recebemos na resolução registros AAAA.Descobrimos que ao fazer a consulta na Cloudflare
Descobriu-se que ao fazer um pedido ao Cloudflare AAAA-registro que não existe no domínio, o Cloudflare respondeu A-com um erro que é uma inconsistência com o RFC. Isso fez com que o resolvedor local (x.x.x.x) não gostasse, e ele respondeu SERVFAIL. O comportamento está claramente visível no log abaixo:
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @x.x.x.x
;; opções globais: +cmd
;; Obteve resposta:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: versão: 0, flags:; udp: 4096
;; SEÇÃO DE QUESTÃO:
;semrushchina.cn. IN AAAA
;; Tempo de consulta: 334 msec
;; SERVIDOR: x.x.x.x#53(x.x.x.x)
;; QUANDO: Ter Aug 14 23:38:50 CST 2018
;; TAMANHO DA MSG recebida: 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; opções globais: +cmd
;; Obteve resposta:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; AVISO: recursão solicitada, mas não disponível
;; OPT PSEUDOSECTION:
; EDNS: versão: 0, flags:; udp: 512
;; SEÇÃO DE QUESTÃO:
;semrushchina.cn. IN AAAA
;; SEÇÃO DE RESPOSTA:
semrushchina.cn. 300 IN A 220.170.186.192
;; Tempo de consulta: 185 msec
;; SERVIDOR: 173.245.58.105#53(173.245.58.105)
;; QUANDO: Ter Aug 14 23:43:03 CST 2018
;; TAMANHO DA MSG recebida: 60
Enviamos um relatório de bug ao Cloudflare, e eles resolveram isso após algum tempo. Resultou interessante: atualmente, na China ainda não há suporte a IPv6, por isso o Cloudflare não conseguia fornecer seu endereço IPv6 na resposta ao pedido AAAA-de registros. No final, tudo foi resolvido, de modo que o Cloudflare passou a responder NODATA para tais pedidos.
Assim, os erros de DNS nos testes do Catchpoint diminuíram drasticamente, mas não completamente. Os timeouts também não desapareceram:
E começamos a procurar outra solução.
Na próxima parte, contarei como testamos a nuvem chinesa Alibaba Cloud, como com um pouco de "magic" do Nginx conseguimos criar rapidamente soluções PoC (Prova de Conceito), como criamos soluções Multi-Cloud, uma das quais acabou ajudando muito a acelerar o serviço da China.
Fique atento!
Próximas partes
Fonte: habr.com
