derrubei a latencia do meu rustdesk de 350ms pra 20ms

lembra do meu cloud computer na hostinger? aquela vps de 32gb q virou meu "pc na nuvem" com xfce + nomachine, acessada do tablet. pois entao, tava funcionando tao bem q eu resolvi testar o rustdesk como alternativa.

e ai veio o presente indesejado. 350ms de delay. mexer no mouse era tipo pilotar um robo em marte. (T_T)

essa é a historia de como eu descobri o pq e resolvi.

suspeito nº1, tailscale

a primeira hipotese obvia era o tailscale. eu uso ele na vps e no tablet, entao talvez o trafego tivesse indo por um relay (derp) em vez de conexao direta. e os primeiros sinais apontavam pra isso.

$ tailscale status
100.91.150.32   samsung-sm-a065m   miuna@   android   -

o - no final significa "sem conexao direta", ou seja, derp relay. fazia sentido, pq meu tablet tava no 4g, atras de cgnat, e o nat traversal podia ta falhando.

$ tailscale ping 100.91.150.32
pong from samsung-sm-a065m (100.91.150.32) via [2804:389:c0fe:320b:...]:44826 in 592ms

mas o pong trouxe um detalhe importante. o [2804:389:...] é um ipv6 brasileiro, e o via [...] indica caminho direto, nao derp. ou seja o tailscale nao era o vilao. a latencia tava no caminho fisico, e 592ms numa rota brasil → brasil é anormal.

suspeito nº2, peering ipv6 ruim

vps no brasil, eu no brasil, 592ms de latencia. isso cheira ao classico problema de roteamento ipv6 no pais, onde provedor manda trafego nacional dar uma volta internacional antes de entregar.

a teoria parecia solida, mas um teste simples derrubou ela.

o rdp e o nomachine, pelo mesmo caminho tablet → vps, funcionavam perfeitamente.

se a rede fosse o problema, td protocolo sofreria igual. a latencia alta era especifica do rustdesk.

o verdadeiro culpado era o relay publico

foi ai q a ferramenta certa apareceu. rodei isso na vps.

$ sudo ss -tup | grep rustdesk
tcp  ESTAB  185.173.110.139:44987   40.160.225.24:21117  users:(("rustdesk",...))

a porta 21117 é o servidor de relay do rustdesk. e o ip 40.160.225.24 é da akamai/linode. ou seja, a sessao inteira fazia esse desvio aqui.

tablet → relay publico do rustdesk (fora do brasil) → vps

é a arquitetura do rustdesk. diferente do rdp ou nomachine, q conectam direto no ip do servidor, o rustdesk funciona com id + servidores publicos deles. se o hole punching falha (comum em cgnat de operadora movel), ele silenciosamente joga tudo pro relay mais proximo, q pode ta geograficamente longe.

a solucao foi subir o relay na propria vps

ai veio a ideia q resolveu tudo. subir meu proprio servidor rustdesk na propria vps. como o relay roda na mesma maquina da sessao, mesmo "relayado" a latencia extra é praticamente zero. e como a vps tem ip publico dedicado, o tablet alcança ela direto, sem depender de nat traversal, sem depender da infra dos outros. (⌐■_■)

sudo mkdir -p /opt/rustdesk-server && cd /opt/rustdesk-server

sudo docker run -d --name hbbs \
  -p 21115:21115 -p 21116:21116 -p 21116:21116/udp \
  -v $PWD/hbbs:/root \
  --restart unless-stopped \
  rustdesk/rustdesk-server hbbs

sudo docker run -d --name hbbr \
  -p 21117:21117 \
  -v $PWD/hbbr:/root \
  --restart unless-stopped \
  rustdesk/rustdesk-server hbbr

depois é so configurar o id server nos dois lados (vps e tablet) com o ip da vps e a chave publica gerada.

cat hbbs/id_ed25519.pub

abri as portas no firewall da hostinger (21115 a 21117 tcp, 21116 udp) e reconectei.

resultado

verificacao pos-mudanca.

$ sudo ss -tup | grep rustdesk
# agora a conexao usa o ip da PROPRIA vps

e o overlay de stats do proprio rustdesk no tablet confirmou. delay caiu de 350ms pra 20ms. (☆▽☆)

mais fluido q o nomachine, com a vantagem do rustdesk. open source, multiplataforma e totalmente sob meu controle.

agora tenho um desktop remoto no tablet q parece local, rodando numa vps q ja tava parada, custando zero a mais. ᕙ( •̀ ᗜ •́ )ᕗ