Olá pessoal!
Em contato, Nikita é engenheira de sistemas da SEMrush . Hoje vou falar sobre como enfrentamos a tarefa de garantir a estabilidade de nosso serviço semrush.com na China e quais problemas encontramos durante sua implementação (dada a localização de nosso data center na costa leste dos EUA).
Esta será uma ótima história, dividida em vários artigos. Vou lhe contar como tudo aconteceu conosco: desde um serviço completamente inoperante da China até o desempenho do serviço no nível de sua versão americana para americanos. Eu prometo que será interessante e útil. Então vamos lá.
Problemas chineses na Internet
Até a pessoa mais distante das especificidades da administração de rede pelo menos uma vez ouviu falar sobre o grande firewall chinês . Isso parece legal, não é? Mas o que é, como realmente funciona é uma questão bastante complicada. Na Internet, você pode encontrar muitos artigos sobre isso, mas do ponto de vista técnico, o dispositivo desse firewall não está descrito em nenhum lugar. O que, no entanto, não é surpreendente. Confesso imediatamente que, com base nos resultados do ano de trabalho, não sei dizer exatamente como isso funciona, mas posso contar sobre meus comentários e conclusões práticas. E começaremos com rumores sobre esse firewall.
Existem muitos rumores sobre esse mesmo firewall. Vamos reunir os principais e mais interessantes deles em uma lista:
- Google, Facebook, Twitter e outros serviços similares estão bloqueados e não funcionam na China.
- Qualquer tráfego que sai da China e para a China é analisado e limitado pelo aprendizado de máquina (no caso de tráfego suspeito), o que diminui bastante a velocidade (tráfego) que passa pela fronteira.
- As agências de inteligência chinesas decifram qualquer tráfego criptografado que atravessa seu firewall.
- Túneis VPN, túneis IPSEC são instáveis, caem e são constantemente bloqueados.
- Quanto mais simples a criptografia, mais simples a frase secreta usada para a codificação de autenticação / tráfego, mais rapidamente ela passa pelo firewall chinês.
Aqui está o que conseguimos descobrir sobre esses rumores:
- Google, Facebook, Twitter e outros serviços similares estão realmente bloqueados (seu KO), mas muitos domínios técnicos do Google, por exemplo, não são banidos e funcionam (o mesmo gstatic.com). Isso leva à conclusão: não corte de forma imprudente todo o Google e outros recursos que parecem estar bloqueados, aparentemente bloqueados.
- Qualquer tráfego que atravessa a fronteira realmente adiciona um atraso sério ao seu tempo. Veja os dois resultados. Um site, uma página, simples obter curl . A primeira medição da própria China (a bela cidade de Shenzhen). A segunda congelou fora de Hong Kong (tem soberania e não há firewall entre ela e o mundo). A distância entre as cidades em uma linha reta é de cerca de 30-40 km.
nikita@china-shenzhen:~
Preste atenção ao time_connect . E, em geral, você vê o resultado: o firewall adiciona 4 segundos extras, que são monstruosamente longos.
- VPNs e túneis IPSEC caem com frequência. Falarei sobre isso um pouco mais tarde e com mais detalhes. Os servidores VPN usados pelos usuários são bloqueados ao longo do tempo (geralmente dentro de um dia após o início do uso).
- Há uma opinião recebida de pessoas que vivem na China de que quanto mais fácil a criptografia do tráfego, mais rápido ele passa pela fronteira, porque é fácil entender que não há nada ilegal nela. E assim como o tráfego "limpo" ganha mais largura de banda e velocidade, e o tráfego "sujo", que não produz nada, recebe um passe mais lento, pelo contrário. Por exemplo, trarei curl para 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/s
A diferença é de 5 segundos para um tempo total de carregamento de 13 bytes. Ao fazer esse teste várias vezes, você pode ver que o GET on HTTP é concluído em geral no mesmo horário, sempre, enquanto o HTTPS, o site às vezes responde em 3, 5, 10 e até 17 segundos. Às vezes, ocorrem erros de SSL:
Unknown SSL protocol error in connection to ifconfig.co:443.
Então, o que temos:
- Os problemas criados pelo firewall chinês descrito acima.
- Pings para recursos externos e túneis internos desaparecem periodicamente.
- A latência entre dois pontos está mudando constantemente, e muitas vezes é simplesmente imprevisível. Ao conectar diferentes cidades / regiões, você espera que, com base na localização geográfica das regiões, o atraso seja menor e você obtenha exatamente a situação oposta.
- Os canais de Internet e comunicação são rápidos ou lentos. Existe uma ligeira dependência da hora do dia e do dia da semana, mas nem sempre.
- As consultas de DNS para o mundo exterior da China às vezes excedem o tempo limite permitido.
A imagem aparece simplesmente "excelente".
O data center, como eu disse, fica no leste dos EUA, e todo o SEMrush consiste em dezenas de produtos interconectados, back-end, front-ends, bancos de dados e tudo isso no data center e nas nuvens. Como uma equipe de administradores de sistema, fomos incumbidos de um pequeno esforço para começar a trabalhar rapidamente na China.
Tivemos que responder a uma pergunta importante: podemos sobreviver com um pouco de sangue e resolver todos os problemas associados à Internet e firewall chineses no nível de rede / nuvem / servidor?
Começamos obtendo uma licença ICP .
Licença ICP
Para poder colocar seu serviço na China (China Continental) e realizar testes, você deve primeiro obter uma licença de domínio ICP.
Se o tráfego do usuário do seu site for encerrado na China continental e se o seu domínio não tiver uma licença ICP, o tráfego será bloqueado no lado do provedor / hospedagem. Curiosamente, um provedor específico se encaixa na licença do ICP, seja Cloudflare ou Alibaba Cloud. Portanto, se você recebeu uma licença de ICP para Cloudflare e hospedou seu site com eles, não poderá migrar "sem interrupções" para o Alibaba Cloud. Será necessário adicionar mais uma hospedagem a esta licença.
Tendo recebido uma licença de domínio ICP, pudemos criar e implementar idéias e soluções técnicas específicas.
Soluções de teste
Porém, antes de criar diretamente as opções de armazenamento temporário, girar os botões, otimizar o site e sua velocidade, você precisa escolher uma ferramenta para testá-lo para ver o que nossas ações melhoram ou pioram o trabalho do site.
Nossa ferramenta de teste precisava atender a dois requisitos principais:
- ele deve poder executar testes da China,
- Ele deve ter testes de navegador.
Então encontramos o ponto de partida ! Eles têm excelente cobertura com pontos de teste em todo o mundo. Na China, por meio dessa ferramenta, você também pode executar testes em 100.500 províncias. Em cada um, vários fornecedores diferentes + a capacidade de fazer testes de Backbone (algo como uma máquina virtual em um data center) e testes de Lastmile (o mais próximo possível das condições do usuário, também conhecido como estação de trabalho). O último tipo de teste é mais caro.
Tendo concluído um contrato de um ano (você não pode fazer menos), começamos a estudar a ferramenta. Francamente, ficamos agradavelmente surpreendidos com a sua funcionalidade. Você pode executar:
- Testes de DNS
- Testes na Web (navegador, GET / POST simples, emulação de um cliente móvel, etc.),
- Verificações transacionais (por exemplo, login),
- Testes de API
- Ping, traceroute, NTP, etc.
Você não pode listar tudo. E o mais importante, cada teste pode ser bem personalizado, adicionando vários cabeçalhos e outros parâmetros. A saída é uma enorme quantidade de informações que descrevem completamente seu teste. Se falamos do mais interessante para nós (testes do navegador), o resultado inclui:
- Conectar, Aguardar, Carregar, SSL, Hora DNS,
- TTFB, TTLB, Documento concluído, Tempo de renderização, Carregamento DOM,
- Resposta (algo próximo ao Tempo até o primeiro byte), Resposta da página da Web (algo próximo ao Tempo até o último byte),
- Qualquer percentil, tempo médio, mediano
- Etc.
Consequentemente, todas essas métricas ajudam você a ver as alterações e entender se elas se tornaram melhores. Analisamos principalmente Resposta, Resposta da página da Web, mediana, percentis 75 e 95 .
Uma questão importante que está no ar desde o início: é possível acreditar no Catchpoint ? Essa ferramenta reflete a velocidade real de carregamento do site na China de diferentes cidades ou é apenas algum tipo de teste no vácuo que não tem nada a ver com a experiência real do usuário?
Esse é um grande problema, porque estar na Rússia é quase impossível descobrir de maneira confiável como o site da China funciona. Ao fazer o proxy socks por meio de uma máquina virtual, você obtém um carregamento do site em alguns minutos no final, o que é simplesmente inaceitável para testes; portanto, a única opção para testes manuais é o GETs de curl e simples do console com medição de tempo. Isso ajuda, porque esse teste reflete a velocidade da solução de rede e, se houver testes no navegador, é muito bom.
Mais tarde, fomos à China e nos certificamos de que o Catchpoint é confiável, reflete com bastante precisão os indicadores reais de velocidade.
Cloudflare china network
Como usamos com sucesso o Cloudflare para o domínio principal semrush.com, decidimos experimentar imediatamente seu recurso chamado China Network . Esta opção é ativada apenas para sites corporativos mediante solicitação e por uma taxa. Também está disponível apenas para sites que possuem a licença ICP apropriada, na qual o Cloudflare é especificado como provedor. Após sua inclusão, o “CDN chinês” do Cloudflare fica disponível para o site - o tráfego das regiões chinesas chega ao próximo CF de PoP (Points of Presence) e é entregue à origem por meio de suas redes ou redes de fornecedores / parceiros.
O esquema desta bancada de testes é apresentado abaixo.
Esta é uma ótima opção para nós. Acontece que o segundo domínio também será para CF, que não adiciona o número de soluções usadas na empresa e praticamente não complica a infraestrutura.
Fizemos os testes do navegador e foi o que aconteceu:
Diamantes vermelhos são arquivos de teste. Os arquivos abaixo são erros de DNS (resolvem o tempo limite). As falhas acima são tempos limite.
Tempo de atividade: 86,6
Mediana: 18s
75 Percentil: 29.3s
95 Percentil: 60s
A mediana, após remover o download do reCaptcha (um serviço do Google bloqueado na China), caiu de 28 para 18 segundos. Mesmo assim, esses são indicadores terríveis, já que o mesmo teste para semrush.com (dos EUA) deu menos de 10 segundos para 95% dos usuários (dos EUA) na mesma página (estática + dinâmica).
Em cada teste, você pode ver o Waterfall e outros parâmetros mais detalhados. Começamos a investigar as causas dos erros e, se o tempo limite for menor ou menos claro: a Internet na China “está diminuindo e depois se afastando”; por isso, a velocidade de conexão e carregamento de recursos do exterior é instável e desigual; os erros de DNS nos surpreenderam bastante. . Descobrimos que os PoPs da Cloudflare estão localizados na China, o endereço do site é resolvido para um único IP anycast, mas os servidores DNS são usados pelos EUA, e é por isso que as consultas DNS são forçadas a atravessar a fronteira e, às vezes, falham.
Depois de esclarecer essa pergunta com a CF, verificou-se que eles não têm seus próprios servidores DNS na China e ainda não se sabe quando será.
Portanto, decidimos testar apenas o DNS do Cloudflare e alteramos o mecanismo do Cloudflare do nosso site para o modo " Somente DNS ". Esse é o modo quando o Cloudflare não faz proxy do tráfego por si mesmo, o que significa que ele não fornece proteção DDoS, CDN e outros recursos e funciona no modo de um servidor DNS normal.
Este suporte é mostrado esquematicamente na figura a seguir. A figura leva em consideração o conhecimento emergente de que o servidor DNS do Cloudflare está atrás do firewall.
No Catchpoint, executamos testes GET simples (sem navegador) que mostravam muitas falhas. A razão para eles foram os mesmos erros de DNS.
Começamos a depurar esses erros usando dig e descobrimos que o endereço é determinado corretamente na primeira solicitação e, mediante solicitação repetida, obtemos SERVFAIL e não é encontrado a cada vez. De repente, o que é isso?
root@iZwz97n2wgbp61qucbfrjsZ:~
Ao solicitar servidores Cloudflare NS diretamente, não existem tais erros:
root@iZwz97n2wgbp61qucbfrjsZ:~
Isso significa que o problema está do lado do servidor DNS "local" ou do servidor provedor.
Investigações posteriores mostraram que obtemos o SERVFAIL na resolução do registro AAAA .
Aconteceu que, quando o Cloudflare solicitou um registro AAAA que não estava no domínio, o Cloudflare respondeu com um registro A , que é um erro e incompatibilidade RFC. Por esse motivo, o resolvedor local ( xxxx ) não gostou disso e respondeu SERVFAIL . No log abaixo, esse comportamento é claramente visível:
root@iZwz97n2wgbp61qucbfrjsZ:~
Enviamos um relatório de bug do Cloudflare, que foi corrigido depois de um tempo. Acabou sendo interessante: no momento, ainda não há suporte para IPv6 na China; portanto, o Cloudflare não pôde fornecer seu endereço IPv6 em resposta a uma solicitação de um registro AAAA . No final, tudo foi decidido para que a China Cloudflare começasse a responder a NODATA a esses pedidos.
Portanto, os erros de DNS nos testes do Catchpoint diminuíram drasticamente, mas não até o fim. Os tempos limite também não desapareceram:
E começamos a procurar outra solução.
Na próxima parte, mostrarei como testamos a nuvem chinesa Alibaba , como, com a ajuda de um pouco de Nginx "mágico", conseguimos criar rapidamente soluções PoC (Prova de Conceito), como criamos soluções Multi-Cloud, uma das quais, em última análise, ajudou muito acelerar o serviço da China.
Fique atento!
Todas as peças
Parte 2
Parte 3