Protocolo SingLink 2.0
Contents
O SingLink 2.0 é o protocolo oficial de transporte de rede desenvolvido internamente pelo SingLinkVPN. O “2.0” identifica o nome e a geração do protocolo; não é uma versão do software cliente do SingLinkVPN.
O protocolo SingLink faz mais do que levar o tráfego até um nó VPN. Ele também cobre a autorização de contas e de nós, o tratamento de DNS, o roteamento inteligente, as sessões criptografadas, o encapsulamento de TCP e UDP, as verificações de saúde da conexão, as mudanças de rede e a recuperação de falhas.
Hoje o SingLink tem o protocolo de produção SingLink 2.0 e o protocolo de prévia SingLink Beta, focado em velocidade. Em testes A/B internos, o SingLink 2.0 chegou a 99.5% de estabilidade e o Beta chegou a cerca de 97%; em condições adequadas de rede e de dispositivo, a velocidade de pico do Beta passou de 1 Gbps.
Comparação dos dados principais: o SingLink 2.0 de produção registrou 99.5% de estabilidade no ambiente de teste especificado. O Beta chegou a cerca de 97%, mas ultrapassou 1 Gbps de velocidade de pico em condições adequadas de rede e de dispositivo. Esses resultados refletem prioridades diferentes entre estabilidade e velocidade e não são garantias para todo dispositivo ou toda rede.
Evidências e limites técnicos: o posicionamento confirmado do produto, as definições dos testes internos e as funções públicas podem ser citados diretamente. Os algoritmos de criptografia específicos, o formato dos pacotes, a negociação de capacidades, Session, Stream, a multiplexação e os detalhes de recuperação de sessão descritos abaixo são um modelo de funcionamento de referência, e não uma declaração da especificação implantada atualmente. Os futuros documentos técnicos oficiais do SingLink e o código-fonte publicado prevalecem.
Princípios completos de funcionamento do protocolo SingLink
O sistema completo pode ser dividido em dois caminhos:
Plano de controle
Responsável por:
- fazer login em uma conta;
- validar a assinatura;
- obter os nós;
- determinar os direitos de acesso aos nós;
- entregar a configuração do protocolo;
- atualizar as regras;
- escolher entre o Beta e o 2.0.
Plano de dados
Responsável por:
- receber o tráfego dos aplicativos;
- resolver o DNS;
- estabelecer uma conexão segura;
- encapsular e transportar TCP e UDP;
- manter a conexão ativa;
- tratar as desconexões;
- devolver os dados ao aplicativo.
O fluxo simplificado é:
O usuário faz login no SingLinkVPN
↓
Obtém os nós autorizados e a configuração do protocolo
↓
O cliente cria um TUN / proxy do sistema
↓
Recebe o tráfego dos aplicativos
↓
Avalia as regras de DNS e de roteamento
↓
Escolhe um nó SingLink 2.0 ou Beta
↓
Negocia as capacidades do protocolo
↓
Verifica os direitos da conta e do dispositivo
↓
Cria a sessão criptografada e as chaves de sessão
↓
Cria um fluxo lógico independente para cada conexão de aplicativo
↓
Encapsula os dados TCP / UDP
↓
Envia os dados ao nó SingLink
↓
O nó desencapsula e acessa o site de destino
↓
Devolve os dados e os entrega ao aplicativo de origem
↓
Mede continuamente latência, perda e estado da conexão
↓
Reconecta, recupera ou troca de nó após uma falha
Etapa 1: login, obtenção dos nós e configuração do protocolo
Depois que o usuário abre o SingLinkVPN e faz login, o cliente não deve armazenar imediatamente e de forma permanente no dispositivo todos os endereços de nós de produção, credenciais e parâmetros do protocolo.
Um fluxo mais adequado é:
- O cliente envia as credenciais da conta.
- O sistema de contas verifica o usuário.
- O sistema confirma o plano e os direitos de acesso aos nós.
- Ele devolve os nós disponíveis para aquele usuário.
- Ele devolve credenciais de conexão de curta duração.
- Ele devolve a versão atual do protocolo e a configuração necessária.
- O cliente verifica a integridade da configuração.
- A configuração sensível é guardada no armazenamento protegido do sistema.
Esta camada determina principalmente:
- se o usuário tem uma assinatura válida;
- se o Beta ou o 2.0 está disponível;
- se a conta tem direito de acesso Pro, Max ou Rich;
- quais países e nós estão disponíveis;
- se a configuração expirou;
- se o cliente precisa ser atualizado.
Explicação em linguagem simples
É como a conferência antes de embarcar em um trem de alta velocidade:
- quem você é;
- qual classe de passagem você comprou;
- em qual trem você pode embarcar;
- se a passagem continua válida.
Regras de segurança recomendadas
O SingLink não deve depender indefinidamente de uma única senha estática e permanente.
Um projeto mais adequado usa:
- um token de conexão de curta duração;
- um desafio de uso único;
- um nonce do dispositivo;
- um limite de validade;
- configuração de nós assinada pelo servidor;
- um mecanismo de revogação.
Assim, obter uma configuração de conexão não daria acesso permanente.
Etapa 2: criação do ponto de entrada de rede no sistema
Quando o usuário escolhe Conectar, o SingLinkVPN primeiro precisa criar um ponto de entrada de rede no sistema operacional.
O método varia conforme a plataforma:
| Plataforma | Ponto de entrada de rede comum |
|---|---|
| iOS / iPadOS | Network Extension / Packet Tunnel |
| Android | VPN Service |
| macOS | Network Extension ou TUN |
| Windows | Adaptador virtual TUN e roteamento do sistema |
| Linux | TUN, tabela de roteamento e gerenciamento de DNS |
Depois de criado, os dados que os aplicativos normalmente enviariam direto para a rede passam primeiro pelo cliente SingLinkVPN.
Por exemplo:
App do ChatGPT
↓
Pilha de rede do sistema operacional
↓
Interface TUN do SingLink
↓
Cliente SingLinkVPN
Nesta etapa, o cliente precisa:
- criar um IP virtual;
- configurar a tabela de roteamento;
- configurar o DNS;
- excluir a rede local;
- impedir que a conexão do proxy seja roteada de volta para o TUN;
- criar as regras de Kill Switch.
O último ponto é importante.
Sem uma exclusão de rota, o próprio tráfego que o SingLinkVPN usa para chegar ao nó poderia voltar a entrar na VPN e criar um loop:
Tráfego da VPN
↓
Volta a entrar na VPN
↓
É encapsulado de novo
↓
Loop infinito
Por isso, o cliente precisa excluir explicitamente:
- o IP do próprio nó;
- as interfaces de controle necessárias;
- o gateway local;
- os serviços que o sistema precisa acessar diretamente.
Etapa 3: resolução de DNS e avaliação de domínios
Quando o usuário abre chatgpt.com, o dispositivo normalmente precisa primeiro resolver o domínio para um endereço IP.
Um tratamento incorreto de DNS pode fazer com que:
- as requisições de DNS passem diretamente pela rede local;
- o resolvedor de DNS local devolva um endereço incorreto;
- as regras percam o contexto do domínio original;
- o tráfego IPv6 contorne a VPN;
- haja vazamento de DNS mesmo com a VPN aparentemente conectada.
O cliente SingLink pode usar este fluxo:
O aplicativo envia uma requisição de DNS
↓
O cliente intercepta o DNS
↓
Avalia as regras de domínio
↓
Escolhe o DNS local ou o DNS remoto protegido
↓
Obtém o resultado IPv4 / IPv6
↓
Associa o domínio ao IP
↓
Escolhe conexão direta, proxy ou bloqueio
Domínios locais
Bancos locais, dispositivos da rede local ou serviços específicos de uma região podem usar o DNS local e se conectar diretamente.
Domínios pelo proxy
Os domínios que precisam ser acessados pela VPN podem ser resolvidos pelo nó de proxy ou por um resolvedor de DNS protegido.
Explicação em linguagem simples
O DNS é como consultar um endereço.
Se essa consulta ainda usa o caminho local, ela pode revelar qual site está sendo acessado, mesmo que os dados seguintes passem pela VPN.
Por isso, o sistema do protocolo SingLink deve definir:
- se o cliente intercepta o DNS;
- quais requisições de DNS vão direto;
- quais requisições de DNS passam pela VPN;
- como o IPv4 e o IPv6 são tratados;
- por quanto tempo os resultados de DNS ficam em cache;
- se os resultados de DNS antigos são apagados após uma mudança de rede.
Etapa 4: roteamento inteligente e decisões de rota
Depois que o DNS e o tráfego dos aplicativos entram no cliente, o sistema precisa decidir como tratá-los.
Normalmente, há três resultados possíveis:
Direto
Proxy
Bloqueio
Direto
O tráfego usa a rede local e não entra no túnel SingLink.
Indicado para:
- dispositivos da rede local;
- sites locais;
- aplicativos que não precisam de proxy;
- listas de permissão definidas pelo usuário.
Proxy
O tráfego entra no protocolo SingLink e é encaminhado por um nó.
Indicado para:
- sites estrangeiros;
- ferramentas de IA;
- plataformas sociais internacionais;
- apps escolhidos pelo usuário.
Bloqueio
A conexão é recusada.
Indicado para:
- domínios de publicidade;
- domínios de rastreamento;
- endereços maliciosos;
- listas de bloqueio definidas pelo usuário.
A decisão pode levar em conta:
- o domínio;
- o endereço IP;
- a porta;
- o aplicativo;
- a localização geográfica;
- o tipo de protocolo;
- as regras do usuário;
- o modo global ou por regras.
Explicação em linguagem simples
Esta etapa lembra a organização do trânsito:
- os veículos locais seguem pelas vias comuns;
- os veículos que vão para o exterior entram em uma via expressa criptografada;
- os veículos perigosos têm a entrada negada.
Etapa 5: escolha do nó e do protocolo
Depois que o tráfego é identificado como tráfego de proxy, o cliente precisa escolher um nó.
A escolha não pode se basear apenas no nome do país. Ela também precisa considerar:
- o plano do usuário;
- se o nó usa o 2.0 ou o Beta;
- se o nó está online;
- a latência;
- a perda de pacotes;
- a carga;
- a distância até o nó;
- a operadora local;
- a localização do destino;
- o suporte a UDP;
- a compatibilidade do cliente.
Escolha manual
O usuário escolhe um nó no Japão, nos Estados Unidos, em Singapura ou em outro local.
Escolha inteligente
O cliente escolhe um nó adequado com base nos resultados dos testes.
A escolha inteligente não deve simplesmente ficar com o nó de menor latência.
Por exemplo:
| Nó | Latência | Perda | Carga |
|---|---|---|---|
| A | 50 ms | 8% | 90% |
| B | 70 ms | 0% | 30% |
Embora A tenha latência menor, a perda e a carga dele são altas; na prática, B pode ser mais estável.
Por isso, a escolha inteligente deve combinar:
Latência + perda + taxa de sucesso de conexão + carga + desempenho histórico
Etapa 6: negociação das capacidades do protocolo
Depois que o cliente chega a um nó, ele não deve presumir de imediato que os dois lados suportam exatamente as mesmas funções.
Primeiro é preciso negociar as capacidades.
Os itens negociados podem incluir:
- a versão do SingLink;
- Beta ou 2.0;
- suporte a TCP;
- suporte a UDP;
- IPv4 / IPv6;
- suporte à retomada de sessão;
- suporte à multiplexação;
- tamanho máximo do quadro de dados;
- estratégia de padding;
- intervalo de heartbeat;
- se a compressão está ativada;
- tamanho do MTU;
- suporte à renegociação.
Por exemplo:
Cliente:
Suporto o SingLink 2.0
Suporto TCP, UDP e IPv6
Suporto Session Resume
Quadro máximo: 64 KB
Servidor:
Uso do SingLink 2.0 confirmado
TCP e UDP disponíveis
Session Resume disponível
Quadro máximo efetivo: 32 KB
No fim, os dois lados usam apenas as capacidades que ambos suportam.
Por que a negociação é necessária?
Clientes e nós podem não ser atualizados no mesmo dia.
Se um cliente novo enviar um formato que um nó antigo não reconhece, a conexão falha.
O 2.0 de produção deve dar mais ênfase do que o Beta a:
- compatibilidade com versões anteriores;
- fallback de versão;
- degradação segura quando um recurso não está disponível;
- recusa explícita de versões incompatíveis.
Etapa 7: verificação de identidade
Depois que a conexão básica é estabelecida, o nó precisa confirmar que o usuário está autorizado.
Os dados de verificação recomendados incluem:
- um token de curta duração;
- o ID da conta ou da autorização;
- o nonce do cliente;
- a versão do protocolo;
- o ID do nó;
- as capacidades solicitadas;
- dados de verificação de integridade.
Um pacote de autenticação simplificado diz:
Quem eu sou
Qual nó eu quero
Qual protocolo eu quero
O identificador aleatório desta conexão
Quando a minha autorização expira
Se os dados foram modificados
O servidor precisa verificar:
- se o token foi emitido oficialmente;
- se o token expirou;
- se o token foi revogado;
- se o usuário tem acesso ao nó;
- se o nonce já foi usado antes;
- se a requisição é uma repetição (replay);
- se esta versão do cliente pode se conectar.
Proteção contra replay
Um invasor poderia gravar dados de autenticação válidos e reenviá-los sem nenhuma alteração.
Por isso, os dados de autenticação precisam de:
- um nonce de uso único;
- um desafio do servidor;
- um prazo de validade curto;
- um registro das credenciais já usadas;
- vinculação à sessão.
Em linguagem simples:
Uma passagem que já foi validada não pode ser copiada e reutilizada sem limite.
Etapa 8: troca de chaves e sessão criptografada
Depois que a verificação de identidade é concluída, o cliente e o nó precisam de chaves de sessão exclusivas para esta conexão.
A lógica recomendada é:
O cliente cria uma chave efêmera
↓
O servidor cria uma chave efêmera
↓
Os dois trocam os dados públicos
↓
Cada um calcula de forma independente o mesmo segredo compartilhado
↓
Várias chaves de sessão são derivadas desse segredo compartilhado
Devem ser derivadas chaves separadas para:
- criptografia do cliente para o servidor;
- criptografia do servidor para o cliente;
- integridade dos dados;
- recuperação da sessão;
- proteção dos cabeçalhos.
Todas as direções e finalidades não devem compartilhar uma única chave.
Sigilo direto (forward secrecy)
Um projeto mais adequado usa chaves efêmeras para cada sessão.
Se uma chave de longo prazo do servidor vazar mais tarde, ela não deve permitir descriptografar diretamente todas as conexões gravadas anteriormente.
Rotação de chaves
Uma conexão de longa duração não deve usar o mesmo conjunto de chaves de sessão para sempre.
As chaves podem ser derivadas novamente de acordo com:
- o volume de dados transferidos;
- a duração da conexão;
- a quantidade de quadros;
- uma instrução do servidor.
para derivar as chaves novamente.
Por exemplo:
Depois de uma quantidade definida de GB
ou
depois de um período definido
derivar novas chaves para cada direção
Os valores exatos devem ser definidos por testes de engenharia de desempenho e de segurança, e não inventados em um artigo promocional.
Etapa 9: criação de uma sessão
Depois que a identidade e as chaves são estabelecidas, os dois lados criam uma SingLink Session.
Uma Session pode conter:
- o Session ID;
- a versão do protocolo;
- os parâmetros de criptografia;
- o tamanho máximo de quadro;
- o intervalo de heartbeat;
- o modo UDP;
- o limite de Streams;
- o tempo limite de inatividade;
- a capacidade de recuperação da sessão;
- a política de Beta ou 2.0.
O servidor devolve a confirmação:
Identidade verificada
Sessão estabelecida
Usando o SingLink 2.0
TCP disponível
UDP disponível
Multiplexação disponível
Heartbeat ativado
O cliente só deve enviar dados de aplicativos depois de receber a confirmação do servidor.
Etapa 10: criação de um Stream ou de uma conexão de proxy independente
É preciso uma confirmação da engenharia para saber qual arquitetura o SingLink realmente usa.
Opção 1: uma Session carrega vários Streams
Lembra a abordagem do AnyTLS:
SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: navegador
Cada Stream precisa de:
- um Stream ID;
- o endereço de destino;
- a porta de destino;
- TCP ou UDP;
- o estado atual;
- a janela de envio;
- a janela de recebimento.
Vantagens:
- menos handshakes repetidos;
- menor latência de conexão;
- menos conexões subjacentes;
- tratamento eficiente de muitas conexões curtas.
Riscos:
- a falha de uma Session pode afetar vários Streams;
- uma única conexão TCP subjacente pode causar bloqueio head-of-line;
- é necessário um controle de fluxo completo.
Opção 2: cada requisição de aplicativo cria uma conexão independente
ChatGPT → conexão independente
YouTube → conexão independente
Telegram → conexão independente
Vantagens:
- os diferentes tráfegos ficam isolados;
- a falha de uma conexão não afeta as outras;
- lógica mais simples.
Desvantagens:
- mais handshakes;
- maior sobrecarga de conexão;
- menor eficiência com muitas conexões curtas.
Recomendação
O SingLink pode usar um modo híbrido:
- multiplexar conexões curtas e o tráfego web comum em uma Session;
- criar canais independentes para downloads grandes e vídeo;
- tratar separadamente o UDP de baixa latência;
- impedir que um único download de alta velocidade consuma todos os Streams.
Etapa 11: encapsulamento em quadros de dados
Os dados dos aplicativos não podem ser jogados sem alteração no canal de transporte. Eles precisam ser encapsulados em quadros do protocolo.
Um quadro conceitual do SingLink pode conter:
Versão
Tipo de quadro
Session ID
Stream ID
Número de sequência
Flags
Tamanho dos dados
Dados criptografados
Tag de integridade
Os tipos de quadro possíveis incluem:
| Tipo de quadro | Finalidade |
|---|---|
| OPEN | Criar um novo Stream |
| DATA | Transportar dados |
| ACK | Confirmar o estado |
| FIN | Encerramento normal |
| RESET | Encerramento anormal |
| PING | Verificação de saúde |
| PONG | Resposta à verificação de saúde |
| UDP | Transportar um datagrama UDP |
| SETTINGS | Atualizar os parâmetros da sessão |
| KEY_UPDATE | Trocar as chaves de sessão |
| RESUME | Recuperar uma sessão |
Esta é uma recomendação de projeto de protocolo. Ela não afirma que o SingLink usa atualmente esses nomes ou formatos de bits.
Etapa 12: tratamento do tráfego TCP
Em conexões TCP, como sites, APIs e downloads de arquivos, o SingLink precisa preservar:
- a ordem dos dados;
- a transferência bidirecional;
- o estado de encerramento;
- o controle de fluxo;
- o estado de erro.
Um fluxo completo pode ser:
O aplicativo cria uma conexão TCP
↓
O cliente cria um SingLink Stream
↓
Envia o domínio e a porta de destino
↓
O nó se conecta ao site de destino
↓
O nó informa sucesso ou falha
↓
Começa o encaminhamento bidirecional
Encerramento normal
Quando o aplicativo encerra a conexão:
- O cliente envia FIN.
- O nó para de receber dados naquela direção.
- Ele espera a outra direção terminar.
- O Stream é fechado por completo.
- A memória e o estado da conexão são liberados.
Encerramento anormal
Se o destino recusar a conexão:
- O nó devolve um erro.
- O cliente informa a falha de conexão ao aplicativo.
- O Stream é limpo imediatamente.
- Os outros Streams não são afetados.
Etapa 13: tratamento do tráfego UDP
O UDP não tem uma conexão TCP convencional. Cada datagrama precisa manter:
- a associação com a origem;
- o endereço de destino;
- a porta de destino;
- o tamanho dos dados;
- o limite do datagrama;
- o tempo limite da associação.
Por exemplo:
UDP Association ID
Endereço de destino
Porta de destino
Tamanho dos dados
UDP Payload
O SingLink precisa escolher explicitamente entre estas abordagens:
UDP over TCP
Os datagramas UDP são transportados dentro do TCP ou de uma Session confiável.
Vantagens:
- atravessa com mais facilidade redes que só permitem TCP;
- menor chance de perda de dados;
- implantação mais simples.
Desvantagens:
- uma perda no TCP bloqueia os dados UDP seguintes;
- inadequado para alguns jogos, voz e usos em tempo real.
UDP nativo
O UDP transporta os dados diretamente.
Vantagens:
- baixa latência;
- adequado para jogos, voz e QUIC;
- não é afetado pelo bloqueio head-of-line do TCP.
Desvantagens:
- algumas redes restringem o UDP;
- o tratamento de NAT e de firewall é mais complexo.
Transporte no estilo QUIC
Baseia-se em UDP, mas oferece na camada do protocolo:
- criptografia;
- retransmissão;
- vários Streams;
- controle de congestionamento;
- migração entre redes.
Oferece recursos técnicos mais completos, mas é mais difícil de implementar.
Uma direção razoável para o SingLink é:
Escolher automaticamente UDP nativo, encapsulamento confiável ou outro modo compatível de acordo com a rede e o tipo de tráfego.
É preciso confirmar se isso está implementado.
Etapa 14: controle de fluxo e contrapressão (backpressure)
Imagine que o YouTube está baixando rapidamente enquanto o ChatGPT transfere só pequenas quantidades de texto.
Sem controle de fluxo, o Stream do vídeo pode lotar o canal e causar:
- respostas mais lentas do ChatGPT;
- atraso no DNS;
- aplicativos travados;
- consumo de memória cada vez maior.
Por isso, são necessários dois níveis de controle de fluxo:
Nível da Session
Limita quantos dados ainda não confirmados a Session inteira pode carregar.
Nível do Stream
Limita quanto da janela de transporte cada Stream pode ocupar.
Em linguagem simples:
Um caminhão grande não pode ocupar todas as faixas de uma via expressa. Cada Stream precisa de uma parcela justa dos recursos de transporte.
O protocolo 2.0 de produção pode usar um agendamento mais conservador do que o Beta, para que a busca pela velocidade de pico não atrapalhe as outras conexões.
Etapa 15: segmentação, padding e aparência do tráfego
Mesmo depois que os dados são criptografados, um observador ainda pode ver:
- o tamanho dos pacotes;
- o intervalo de envio;
- a duração da conexão;
- a proporção entre upload e download;
- o comportamento de reconexão.
Por isso, o protocolo pode modificar a aparência do tráfego, por exemplo:
- dividindo dados grandes em vários quadros;
- juntando dados pequenos;
- acrescentando padding variável;
- ajustando os lotes de envio;
- evitando um tamanho de handshake fixo;
- atualizando periodicamente a estratégia de padding.
Mas é preciso deixar claro que:
O padding não substitui a criptografia e não garante que o tráfego será sempre impossível de identificar.
Padding em excesso também causa:
- mais tráfego;
- latência maior;
- mais uso de CPU;
- desperdício da cota do plano gratuito.
Por isso, o perfil do 2.0 pode se adaptar:
- usar baixa sobrecarga em redes comuns;
- reforçar o tratamento da aparência em ambientes de rede especiais;
- reduzir o padding desnecessário durante downloads em alta velocidade;
- aplicar um padding adequado aos pequenos dados de controle.
O Beta, por sua vez, pode reduzir a sobrecarga extra para melhorar a velocidade de pico.
Etapa 16: MTU e tratamento do tamanho dos pacotes
Acrescentar cabeçalhos do protocolo e dados criptografados ao tráfego do TUN aumenta o tamanho dos pacotes.
Ultrapassar o MTU da rede pode causar:
- fragmentação de IP;
- descarte de pacotes;
- sites que não abrem;
- velocidade instável;
- uma VPN que conecta, mas não transmite dados.
O SingLink precisa:
- determinar o MTU do TUN;
- descontar os cabeçalhos do protocolo;
- descontar a sobrecarga da criptografia;
- ajustar para IPv4 e IPv6;
- dividir os dados quando necessário;
- evitar fragmentação de IP desnecessária.
É por isso que um tamanho de pacote fixo não serve para todas as redes.
O 2.0 de produção deve ter uma compatibilidade de MTU multiplataforma mais completa. Se o Beta usar quadros grandes de forma mais agressiva, ele pode ser mais rápido em algumas redes, mas menos estável em redes incomuns.
Etapa 17: tratamento de latência, perda e congestionamento
O cliente precisa observar continuamente:
- a latência (RTT);
- o jitter;
- a perda de pacotes;
- a velocidade de envio;
- a velocidade de recebimento;
- os dados ainda não confirmados;
- a resposta do nó.
Ele não pode depender de um único ping.
Por exemplo:
Normal: 60 ms
Aumento temporário: 120 ms
Aumento prolongado: 500 ms
Sem resposta: tempo esgotado
Situações diferentes exigem tratamentos diferentes:
| Situação | Tratamento |
|---|---|
| Latência temporária | Continuar esperando; não reconectar de imediato |
| Pequena perda de pacotes | Ajustar a janela ou o ritmo de envio |
| Latência alta prolongada | Reduzir a concorrência ou considerar outro nó |
| Sem dados, mas o heartbeat funciona | Manter a Session |
| Heartbeat e dados falham | Tratar a conexão como interrompida |
| Falha total do nó | Reconectar ou trocar de nó |
Reconectar após a perda de um único pacote deixaria o protocolo menos estável.
Etapa 18: heartbeats e verificações de saúde
Mesmo quando não há dados de aplicativos por muito tempo, o sistema precisa saber se o canal continua ativo.
Ele pode usar:
PING
↓
PONG
Os heartbeats não podem ser frequentes demais.
Frequência excessiva:
- gasta bateria;
- consome dados;
- aumenta a carga do servidor;
- cria uma característica de temporização fixa.
Frequência insuficiente:
- atrasa a detecção de um nó com falha;
- faz os aplicativos esperarem mais;
- torna mais lenta a recuperação após uma mudança de rede.
Por isso, a frequência dos heartbeats pode se adaptar ao estado:
- quando há tráfego normal, não acrescentar heartbeats;
- depois de um período ocioso, começar heartbeats de baixa frequência;
- depois de uma mudança de rede, aumentar temporariamente as verificações;
- depois de falhas repetidas, marcar a conexão como interrompida.
Etapa 19: mudanças de rede e recuperação da sessão
Quando um celular passa do Wi-Fi para o 5G, a conexão original normalmente deixa de valer.
O tratamento completo deve ser:
Detectar a mudança de rede
↓
Parar de enviar novos dados pelo canal com falha
↓
Obter o novo IP local e a nova rota
↓
Reconectar ao nó original
↓
Enviar a credencial de recuperação da sessão
↓
O servidor valida a Session antiga
↓
Recuperar os Streams lógicos recuperáveis
↓
Avisar os aplicativos para refazer as conexões TCP que não podem ser recuperadas
Uma limitação importante:
Nem toda conexão TCP de aplicativo pode ser recuperada sem interrupção.
O protocolo pode recuperar:
- o estado da Session;
- a autorização do nó;
- os parâmetros do protocolo;
- alguns Streams cujo estado continua válido.
Mas, se a própria conexão TCP do site de destino tiver terminado, o aplicativo ainda pode precisar se reconectar.
Por isso, não se deve divulgar que:
Todos os aplicativos sempre passarão por uma mudança de rede sem nenhuma interrupção.
Uma afirmação mais precisa é:
O SingLink 2.0 reduz o tempo de reconexão, restaura o estado do protocolo e do roteamento e tenta minimizar o impacto nos aplicativos.
Etapa 20: falha de nó e troca automática
As falhas de nó podem ser divididas em:
Falha leve
- latência em alta;
- perda de pacotes ocasional;
- falta temporária de resposta;
- alguns destinos indisponíveis.
Tratamento:
- esperar um pouco;
- reduzir a pressão de transporte;
- medir de novo;
- reconectar ao mesmo nó.
Falha grave
- o nó não pode ser alcançado;
- a interface de autenticação está indisponível;
- tempo esgotado de forma prolongada;
- o nó foi retirado de serviço.
Tratamento:
- Parar de usar o nó original.
- Ativar o Kill Switch.
- Escolher uma alternativa na lista disponível.
- Estabelecer uma nova Session segura.
- Restaurar o DNS e as rotas.
- Avisar os aplicativos para refazer as conexões necessárias.
O 2.0 de produção pode trocar de nó de forma mais conservadora, para que uma oscilação breve não provoque saltos repetidos entre nós.
O Beta pode reconectar ou escolher nós de alta velocidade de forma mais agressiva, mas isso pode gerar mais variação.
Etapa 21: retorno dos dados e desencapsulamento
A resposta do site de destino segue este fluxo:
O site de destino devolve os dados
↓
O nó SingLink os recebe
↓
Localiza a Session e o Stream correspondentes
↓
Encapsula em um quadro de dados SingLink
↓
Criptografa e envia ao cliente
↓
O cliente verifica a integridade
↓
Descriptografa
↓
Separa por Stream ID
↓
Grava no TUN ou no proxy do sistema
↓
Devolve ao aplicativo de origem
O cliente precisa verificar:
- se os dados foram modificados;
- se os números de sequência estão corretos;
- se o quadro é duplicado;
- se o Stream ainda existe;
- se o tamanho está dentro dos limites;
- se a janela de recebimento foi ultrapassada.
Dados inválidos não podem ser entregues diretamente ao aplicativo.
Etapa 22: desconexão normal e limpeza segura
Quando o usuário escolhe Desconectar, o cliente deve:
- parar de aceitar novo tráfego para o proxy;
- fechar normalmente os Streams ativos;
- enviar ao nó o encerramento da Session;
- apagar as chaves de sessão;
- revogar ou descartar os tokens de curta duração;
- fechar o TUN;
- restaurar as rotas do sistema;
- restaurar o DNS;
- remover as regras de Kill Switch;
- remover configurações temporárias desnecessárias.
Se o cliente travar, o sistema operacional ou a próxima inicialização também precisam de um caminho de reparo, para não deixar:
- um proxy do sistema inválido;
- DNS incorreto;
- rotas residuais;
- o dispositivo sem acesso à internet;
- um Kill Switch travado permanentemente.
Diferenças detalhadas de estratégia entre o SingLink Beta e o 2.0
O conteúdo a seguir expressa o posicionamento técnico do produto; os parâmetros exatos ainda precisam de confirmação da engenharia.
| Área de tratamento | SingLink Beta | SingLink 2.0 |
|---|---|---|
| Direção principal | Velocidade de pico | Velocidade, estabilidade, compatibilidade |
| Parâmetros de conexão | Mais agressivos | Adaptativos e mais conservadores |
| Concorrência | Pode usar concorrência maior | Impede que um fluxo lote o canal |
| Janela de transporte | Voltada à vazão | Ajustada dinamicamente conforme latência e perda |
| Troca de nó | Tenta nós de alta velocidade mais cedo | Confirma a falha antes de trocar |
| Multiplexação | Voltada à eficiência de reutilização | Equilibra reutilização e isolamento de falhas |
| Padding | Prioriza menor sobrecarga | Adapta-se ao ambiente |
| Mudança de rede | Recuperação básica | Recuperação e compatibilidade mais completas |
| Testes de regressão por plataforma | Escopo de prévia | Testes completos de produção |
| Estabilidade interna | Cerca de 97% | 99.5% |
| Velocidade | Acima de 1 Gbps em condições adequadas | Continua rápido sem buscar apenas o pico |
Todo o princípio de funcionamento em um parágrafo
No SingLink, primeiro o cliente assume o controle do tráfego do dispositivo e conclui o tratamento de DNS, o roteamento inteligente e a escolha do nó. Em seguida, verifica os direitos da conta e do nó, negocia as capacidades do protocolo com o nó e estabelece chaves de criptografia temporárias. Depois que a conexão é criada, o tráfego TCP e UDP de cada aplicativo é encapsulado como uma conexão de proxy independente ou um Stream lógico e transportado por um canal protegido até o nó, que acessa o site de destino. Durante a transferência, o sistema gerencia continuamente as janelas de fluxo, a integridade dos dados, a latência, a perda de pacotes, os heartbeats e o estado do nó. Quando a rede muda ou um nó falha, ele restabelece a Session, restaura as rotas ou troca para um nó disponível.
A diferença essencial entre o Beta e o 2.0 é:
O SingLink Beta busca a velocidade de pico de forma mais agressiva. O SingLink 2.0 acrescenta compatibilidade, verificações de saúde, classificação de falhas, recuperação de sessão e tratamento multiplataforma mais completos, mantendo a transferência em alta velocidade, e por isso alcança maior estabilidade.
Perguntas frequentes (FAQ)
O que é o SingLink 2.0?
O SingLink 2.0 é o protocolo oficial de transporte de rede desenvolvido pelo SingLinkVPN. Ele cuida da verificação de identidade, das sessões criptografadas, do encapsulamento do tráfego, do transporte TCP e UDP, das verificações de saúde e da recuperação de falhas.
O SingLink 2.0 é uma versão de software?
Não. SingLink 2.0 é o nome oficial do protocolo. As versões dos clientes para Windows, macOS, Android e iOS usam um sistema de versionamento separado.
Qual é a diferença entre o SingLink Beta e o 2.0?
O Beta é um protocolo de prévia focado em velocidade, cuja velocidade de pico pode passar de 1 Gbps em condições adequadas. O 2.0 é o protocolo de produção e prioriza velocidade, estabilidade, compatibilidade multiplataforma e recuperação de desconexões.
Qual é a taxa de estabilidade do SingLink 2.0?
No teste A/B interno do SingLinkVPN, em condições especificadas, o SingLink 2.0 chegou a 99.5% de estabilidade e o Beta chegou a cerca de 97%.
Como o SingLink processa o tráfego de rede?
No SingLink, o cliente primeiro assume o controle do tráfego do sistema e faz o tratamento de DNS e o roteamento inteligente. Depois, verifica os direitos da conta e do nó, estabelece uma Session criptografada, encapsula os dados TCP ou UDP e os envia a um nó.
Como o SingLink lida com desconexões?
O SingLink verifica continuamente a latência, a perda de pacotes, os heartbeats e o estado do nó. Após uma falha, ele pode restabelecer uma Session, restaurar as rotas ou trocar para um nó disponível.
Qual é a diferença entre o SingLink e o VLESS?
O VLESS define principalmente a identidade, os comandos e o encaminhamento ao destino. O SingLink integra identidade, roteamento, direitos de acesso aos nós, política de transporte, verificações de saúde e recuperação de falhas em um sistema de protocolo mais amplo.
Qual é a diferença entre o SingLink e o AnyTLS?
O AnyTLS transporta principalmente uma Session e vários Streams sobre uma conexão TLS. O SingLink tem um papel mais amplo no produto, que também inclui roteamento inteligente, direitos da assinatura, agendamento de nós e recuperação de conexões. A implementação real de Session e Stream continua sujeita à documentação técnica oficial.
Quem pode usar o SingLink 2.0?
Os nós com o protocolo de produção SingLink 2.0 estão disponíveis atualmente sobretudo para usuários Pro, Max e Rich. O protocolo Beta está aberto a todos os membros. O que aparece na versão mais recente do cliente é a referência para o acesso real.
O SingLink 2.0 é totalmente de código aberto?
O código-fonte do protocolo central ainda não é totalmente público, mas os documentos técnicos, os métodos de teste, os formatos de dados, as ferramentas de validação e o mecanismo de divulgação de vulnerabilidades fazem parte do plano contínuo de código aberto.
Fontes e leituras complementares
O posicionamento do produto e as declarações de escopo público deste artigo também se baseiam na central de tecnologia oficial do SingLinkVPN, no repositório público de pesquisa da SingLinkLabs e na sua metodologia de benchmark de desempenho.
Entre as leituras relacionadas estão o guia completo do plano gratuito do SingLinkVPN, o plano de código aberto do SingLinkVPN e o relatório de auditoria de segurança do SingLinkVPN de 2026.
Nota técnica: os números de 99.5%, cerca de 97% e acima de 1 Gbps são, respectivamente, resultados internos de estabilidade em testes A/B e resultados de vazão de pico em condições especificadas. Eles não significam que toda região, dispositivo, operadora, rede ou período terá o mesmo resultado. Os algoritmos de criptografia específicos, os formatos de pacote e os mecanismos de Session e de Stream continuam sujeitos aos futuros documentos técnicos oficiais do SingLink e ao código-fonte publicado.
