A perda do acesso russo à Starlink expõe uma diferença importante entre ter satélites em órbita e operar uma rede de internet por satélite confiável. O desafio não é apenas lançar equipamentos: é manter cobertura contínua, entregar capacidade previsível e coordenar terminais, enlaces e software em condições de alta interferência. É nesse contexto que a Rússia acelerou o Rassvet, projeto da empresa aeroespacial Bureau 1440.
Segundo o Olhardigital.com.br, o sistema pretende ampliar as comunicações militares e apoiar a coordenação de drones. A iniciativa também revela uma dependência que o Kremlin tenta reduzir: sem uma infraestrutura própria equivalente, tropas russas chegaram a tentar usar a rede de Elon Musk para fins militares. Para quem trabalha com software, esse caso é um bom lembrete de que conectividade não é um detalhe da aplicação. Ela faz parte da arquitetura.
O que é o Rassvet e por que a Rússia quer uma rede própria
Rassvet significa “aurora” em russo. O projeto da Bureau 1440 busca criar uma constelação de satélites para fornecer comunicação de dados, com aplicações militares entre seus objetivos. No campo de batalha, uma conexão pode transportar imagens de drones, telemetria, comandos e informações para coordenar unidades.
Esse tipo de tráfego exige mais do que velocidade máxima. O sistema precisa oferecer baixa latência, cobertura na área de operação, capacidade para vários terminais e estabilidade suficiente para que uma interrupção não comprometa a missão. Uma rede que funciona bem em uma demonstração, mas perde conexão ao mudar de região ou aumentar o número de usuários, não é uma substituta operacional.
A necessidade de uma alternativa também tem uma dimensão estratégica. Uma infraestrutura controlada por outro país pode estar sujeita a decisões comerciais, políticas ou técnicas externas. Para operações militares, depender de uma rede que não se controla significa aceitar riscos sobre disponibilidade, prioridades de tráfego e acesso.
Como a internet via satélite de órbita baixa funciona
Constelações de órbita baixa, conhecidas como LEO, posicionam satélites muito mais perto da Terra do que os satélites geoestacionários tradicionais. A distância menor pode reduzir a latência e tornar serviços interativos mais práticos, incluindo chamadas, jogos, videoconferências e controle remoto.
Mas um satélite LEO não permanece parado sobre uma região. Ele se desloca rapidamente em relação ao usuário, então a rede precisa transferir a conexão entre satélites e estações terrestres. Esse processo, chamado de handover, deve acontecer sem interromper sessões de dados. Também é necessário coordenar o terminal do usuário, a rede de acesso e os enlaces que encaminham os pacotes até a internet.
Em termos de arquitetura, uma constelação é uma combinação de componentes: satélites, terminais, estações de solo, enlaces entre satélites quando disponíveis, sistemas de controle e mecanismos de roteamento. O desempenho percebido depende do conjunto. A taxa de transmissão de um satélite, isoladamente, não informa qual velocidade um usuário terá na ponta.
Rassvet e Starlink: cuidado ao comparar números de velocidade
O Olhardigital.com.br informa que a primeira geração de equipamentos do Rassvet oferece velocidades de até 1 gigabit por segundo e menciona cerca de 100 gigabits por segundo para a geração atual da Starlink. A diferença parece direta, mas esses valores precisam de contexto antes de serem comparados.
“Velocidade” pode significar capacidade agregada do satélite, capacidade de um enlace, taxa máxima de um terminal ou velocidade efetivamente entregue a cada usuário. São métricas diferentes. Um valor agregado de 100 Gbps, por exemplo, não significa que cada assinante consiga baixar dados nessa taxa. A capacidade é compartilhada e varia conforme cobertura, congestionamento, plano, terminal e condições de rádio.
Na minha leitura, esse é o principal cuidado técnico ao interpretar os números: sem saber exatamente o que foi medido, a comparação pode misturar capacidade de rede com desempenho de acesso. A diferença divulgada ainda aponta para uma distância tecnológica, mas não deve ser traduzida automaticamente em “um usuário da Starlink é cem vezes mais rápido”.
O astrofísico e historiador espacial Jonathan McDowell, citado na cobertura, estima que a próxima geração da Starlink poderá alcançar aproximadamente dez vezes o desempenho da atual. Essa projeção torna a corrida ainda mais exigente. Uma rede concorrente precisa acompanhar não só o sistema disponível hoje, mas também sua evolução em capacidade e escala.
Clayton Swope, do Centro de Estudos Estratégicos e Internacionais, avalia que a Rússia ainda está longe de uma alternativa equivalente. A frase resume o problema: construir satélites é apenas uma parte. O diferencial de uma rede global está na integração entre cobertura, terminais, capacidade, operação e expansão contínua.
Alternativas à Starlink: LEO, GEO e redes especializadas
A Starlink não é a única referência para conectividade via satélite. A OneWeb também opera uma constelação em órbita baixa, com foco importante em conectividade empresarial e institucional. Projetos como o Kuiper, da Amazon, representam outra tentativa de criar uma rede LEO ampla, embora disponibilidade e cobertura dependam do estágio de implantação em cada momento.
Já os satélites geoestacionários, ou GEO, continuam relevantes para regiões remotas e serviços que não exigem resposta rápida. Como ficam muito mais distantes da Terra, tendem a apresentar latência maior. Isso pode ser aceitável para certos acessos e transferência de arquivos, mas atrapalha aplicações interativas e controle em tempo real.
Redes especializadas como a Iridium atendem necessidades diferentes, como comunicação global e mensagens com baixa demanda de dados. Elas não são substitutas diretas de uma rede de banda larga para vídeo de alta resolução. Comparar todas essas opções apenas pelo rótulo “internet por satélite” é como comparar uma conexão móvel, um link dedicado e uma rede de sensores sem considerar o tipo de tráfego.
O impacto para desenvolvedores: trate a conexão como instável
Para quem desenvolve aplicações, o caso do Rassvet tem uma consequência prática: um produto que depende de internet não deve presumir latência constante nem conexão permanente. Isso vale para sistemas militares, mas também para telemedicina, logística, agricultura, monitoramento industrial e equipes que trabalham em regiões remotas.
Em uma rede via satélite, a aplicação pode enfrentar latência variável, perda de pacotes, mudanças de rota, interrupções temporárias e largura de banda compartilhada. O protocolo TCP consegue lidar com retransmissões, mas isso não elimina os efeitos de uma conexão degradada. Uma requisição pode demorar, expirar no cliente e ainda assim ter sido processada no servidor.
Por isso, separar operações de leitura e escrita é essencial. Repetir automaticamente um GET costuma ser seguro. Repetir um pagamento ou uma ordem de controle pode gerar duplicidade. Para operações que alteram estado, use chaves de idempotência no servidor e defina claramente quais erros permitem uma nova tentativa.
Na Prática: retries com timeout e backoff para uma rede instável
O exemplo abaixo implementa tentativas limitadas para uma requisição GET. Ele aplica timeout, espera exponencial e jitter, que adiciona uma variação aleatória ao intervalo. O jitter evita que muitos clientes reconectem ao mesmo tempo depois de uma interrupção e sobrecarreguem o serviço.
async function getWithRetry(url, {
attempts = 4,
timeoutMs = 8000,
baseDelayMs = 500
} = {}) {
let lastError;
for (let attempt = 0; attempt < attempts; attempt++) {
const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), timeoutMs);
try {
const response = await fetch(url, {
method: "GET",
signal: controller.signal
});
if (!response.ok) {
// Em geral, erros 4xx não melhoram com novas tentativas.
if (response.status >= 400 && response.status < 500) {
throw new Error(`Erro HTTP ${response.status}`);
}
throw new Error(`Erro temporário: HTTP ${response.status}`);
}
return await response.json();
} catch (error) {
lastError = error;
if (attempt === attempts - 1) break;
const exponentialDelay = baseDelayMs * (2 ** attempt);
const jitter = Math.random() * baseDelayMs;
await new Promise(resolve =>
setTimeout(resolve, exponentialDelay + jitter)
);
} finally {
clearTimeout(timeout);
}
}
throw lastError;
}Esse código é um ponto de partida, não uma política universal de resiliência. Em produção, eu também registraria duração, número de tentativas, tipo de erro e estado da conexão. Sem métricas, uma aplicação pode parecer “lenta” sem revelar se o problema está no servidor, no enlace ou no próprio cliente.
Para operações de escrita, não basta trocar GET por POST e reaproveitar a função. O servidor precisa aceitar uma chave de idempotência e devolver o resultado original quando receber novamente a mesma operação. A aplicação também deve informar ao usuário se uma ação está pendente, em vez de sugerir que falhou quando o resultado ainda é desconhecido.
Erros comuns ao projetar para internet via satélite
- Assumir que a taxa máxima é a velocidade do usuário: capacidade agregada da rede e throughput por terminal são medidas distintas.
- Configurar timeouts curtos demais: um timeout pensado para fibra pode cancelar operações legítimas em uma conexão de alta latência.
- Repetir qualquer requisição automaticamente: uma escrita pode ser executada duas vezes se o servidor concluiu a operação, mas a resposta se perdeu.
- Sincronizar tudo em tempo real: filas locais e sincronização posterior podem ser melhores quando a conexão oscila.
- Ignorar o custo dos dados: transferir vídeo continuamente pode consumir capacidade que deveria ser reservada para comandos e telemetria crítica.
- Não medir a experiência por região: cobertura, congestionamento e qualidade do enlace variam; uma média global esconde os pontos de falha.
Também é comum confundir baixa latência com disponibilidade. Uma rede LEO pode responder rapidamente quando está conectada, mas ainda enfrentar interrupções, handovers ou congestionamento. Para sistemas críticos, a arquitetura deve prever degradação graciosa: reduzir resolução de vídeo, priorizar mensagens pequenas e armazenar dados até que o enlace volte.
O que o projeto Rassvet ainda precisa provar
A informação disponível aponta para uma diferença relevante de capacidade entre o Rassvet e a Starlink, além de desafios para ampliar a cobertura e manter conexão contínua. Para avaliar o projeto com rigor, será necessário observar resultados operacionais: número de satélites em serviço, disponibilidade por região, desempenho em carga, cobertura dos terminais e comportamento durante transferências entre satélites.
Também importa saber como a rede lida com interferência e falhas. Em qualquer infraestrutura de comunicação, a robustez não aparece apenas no melhor resultado de laboratório. Ela aparece quando o sistema mantém funções prioritárias mesmo com perda de capacidade, interrupção de enlaces ou aumento repentino de demanda.
A lição que levo para projetos de software é simples: não desenhe para a conexão ideal se o sistema precisa funcionar longe dela. Faça filas, defina prioridades, limite tentativas, torne operações críticas idempotentes e registre métricas úteis. A infraestrutura pode mudar; os princípios de resiliência continuam valendo.
Perguntas frequentes sobre Rassvet e internet via satélite
O que é o Rassvet?
É um projeto de rede de satélites da empresa russa Bureau 1440. A iniciativa busca ampliar as comunicações e, segundo a cobertura do Olhardigital.com.br, apoiar aplicações militares como a coordenação de drones.
O Rassvet já é equivalente à Starlink?
Com as informações citadas, não. A fonte descreve uma diferença de capacidade e relata que especialistas consideram a Rússia distante de uma alternativa equivalente. Além disso, cobertura, continuidade e escala também determinam a qualidade de uma rede.
O que significa uma capacidade de 100 Gbps em um satélite?
O número pode representar capacidade agregada, e não a velocidade individual de cada usuário. Para comparar redes, é necessário saber qual métrica foi usada e considerar a capacidade compartilhada entre terminais.
Como um desenvolvedor deve lidar com uma conexão via satélite instável?
Use timeouts adequados, retries limitados com backoff e jitter, filas para sincronização posterior e idempotência para operações de escrita. Também registre latência, erros e tentativas para diagnosticar problemas reais.
Satélites LEO são sempre melhores que GEO?
Não. LEO tende a oferecer menor latência, o que ajuda aplicações interativas. GEO pode atender bem serviços que toleram mais atraso. A escolha depende de cobertura, custo, disponibilidade e tipo de tráfego.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.