- A internet no South Pole dependia de links de satélite limitados e só ficava conectada algumas horas por dia; em outubro de 2023, usuários da comunidade precisavam lidar com alta latência, baixa largura de banda e quedas intermitentes
- No ambiente real, havia cerca de 750 ms de latência de ida e volta, jitter de vários segundos, velocidades de alguns kbps até 2 Mbps, além de congestionamento, enfileiramento, perda de pacotes e preempção de serviço, o que quebrava facilmente as suposições de rede de apps comuns
- Grandes bundles de JavaScript, timeouts codificados, descarte de progresso, invalidação de cache e downloaders embutidos sem retomada faziam os próprios apps falharem em links lentos
- Se os bytes continuarem fluindo, mesmo devagar, vale esperar; com envio em chunks, retomada, indicação de estado, timeouts dinâmicos e links para download manual, metas pequenas como mensagens de texto ou atualizações ainda podem ser concluídas
- A Antártida é um caso extremo, mas navios em alto-mar, postos de pesquisa em montanhas, Wi‑Fi instável, WISPs de baixa qualidade e acessos por linha telefônica também podem enfrentar limitações semelhantes, então é preciso projetar sem bloquear o progresso do usuário
Restrições do ambiente de internet no South Pole
- Fornecer internet no South Pole por si só é um desafio de engenharia nada trivial, e as opções de satélite utilizáveis em regiões polares são limitadas
- Há material público na página South Pole Satellite Communications
- A dificuldade de levar fibra óptica tradicional até o continente antártico também foi discutida no 2021 Antarctic Subsea Cable Workshop
- A NSF fez um anúncio relacionado ao Starlink em McMurdo e Palmer, mas, em outubro de 2023, não havia anúncio semelhante para a South Pole Station
- McMurdo, até recentemente, tinha quase 1.000 pessoas e várias cargas de trabalho científicas e operacionais compartilhando uma largura de banda agregada de apenas algumas dezenas de Mbps para toda a base
- Ou seja, a base inteira dividia menos banda do que uma única pessoa pode obter numa rede celular 4G comum em um subúrbio dos EUA
- O South Pole só ficava conectado quando os satélites subiam acima do horizonte e durante os períodos em que a base tinha permissão de uso; o cronograma dos satélites geralmente adiantava cerca de 4 minutos por dia por causa da diferença entre tempo sideral e solar
- A latência percebida pelos usuários era muito diferente da experiência normal de internet
- Cerca de 750 ms de latência de ida e volta até destinos no território continental dos EUA
- Aproximadamente 10 vezes o máximo de 75 ms de ida e volta entre as costas leste e oeste dos EUA
- Aproximadamente 30 vezes o máximo de 25 ms esperado até grandes CDNs em conexões residenciais comuns de cabo ou fibra
- Em comparação com cerca de 3 ms da fibra GPON doméstica do autor até Fastly, Cloudflare, CloudFront, Akamai e Google, o South Pole era mais de 250 vezes pior
Condições que os usuários da comunidade realmente enfrentavam
- Em outubro de 2023, pessoas usando internet no South Pole para fins comunitários podiam enfrentar as seguintes condições
- Cerca de 750 ms de latência média de ida e volta, com jitter entre pacotes acima de vários segundos
- Velocidades, no dispositivo final do usuário, de alguns kbps até 2 Mbps em dias muito bons
- Congestionamento severo, enfileiramento e perda de pacotes
- Disponibilidade limitada, quedas frequentes e, ocasionalmente, preempção do serviço
- Em certas situações, apareciam condições como 40 kbps, 1.000 ms de latência, até 2.000 ms de jitter, 10% de perda de pacotes e interrupções totais de 15 segundos a cada poucos minutos
- Como o tráfego operacional recebia prioridade forte, usuários da comunidade dependiam da capacidade que sobrava
- Recursos como videoconferência em tempo real eram difíceis de esperar, mas, em alguns apps, ainda era possível enviar e receber mensagens de texto de poucos bytes
- Engenharia web e de apps que não considerava links lentos ou intermitentes tornava a usabilidade ainda pior
Caso de um app web colaborativo que exigia 20 MB de JavaScript
- Uma plataforma corporativa de colaboração precisava baixar quase 20 MB só de JavaScript para renderizar a tela principal
- Como o app havia sido atualizado desde o acesso anterior, todos os ativos no cache do navegador estavam obsoletos e precisavam ser baixados novamente
- O navegador e os protocolos lidam até certo ponto com controle de congestionamento em internet lenta, mas esse app interrompia o carregamento por condições de falha definidas por ele mesmo
- Se não carregasse completamente dentro do tempo ou do número de tentativas definido pelos desenvolvedores, o app parava
- O usuário era redirecionado para uma página de erro
- O estado de carregamento já alcançado desaparecia
- Na tentativa seguinte, eram aplicadas medidas agressivas de invalidação de cache
- No fundo, esse app era um app de mensagens, e, depois de iniciar, o payload real ao conversar com amigos era medido em bytes
- O desempenho de internet no South Pole ficava bem na fronteira do que os desenvolvedores consideravam “aceitável”, então os usuários precisavam recarregar várias vezes e baixar o mesmo JavaScript de novo
- Se a transferência necessária simplesmente fosse deixada continuar, poderia terminar em 15 minutos, mas na prática às vezes levava horas
- Em um caso bem-sucedido, foram 809 requisições HTTP, 51,4 MB transferidos, 26,5 minutos de carregamento e depois um
POSTHTTPS de 1,8 KB para enviar uma mensagem de 6 bytes
- Se o app tivesse sido projetado para continuar esperando enquanto os dados ainda estivessem fluindo, mesmo lentamente, teria reduzido retransmissões desnecessárias e desperdício de banda
O problema dos timeouts codificados e das grandes transferências únicas
- Suposições fixas sobre quão rápido um payload será transmitido, ou quanto pode ser enviado em uma única requisição, podem quebrar apps em links lentos
- Se for possível medir que os bytes continuam fluindo, é melhor não interromper a transferência, por mais lenta que seja, e mostrar a situação atual na UI
- Se uma chamada HTTPS falhar, ela deve ser tentada de novo com timeout maior, e dados grandes devem ser enviados em pequenos chunks
- O progresso por chunk deve ser acompanhado
- Deve ser possível repetir ou retomar apenas a pequena parte que falhou
- Um avanço incremental lento e constante é mais seguro do que tentar enviar uma grande quantidade de uma vez
- Se chamadas HTTPS continuarem falhando, em vez de repetir cegamente a mesma chamada, é melhor verificar DNS, ICMP, HTTP sem TLS, HTTPS para um endpoint conhecido como saudável, e informar o estado ao usuário
-
Falha ao baixar metadados na inicialização
- Um app popular de desktop baixava informações de configuração do site do fornecedor ao iniciar e usava um timeout codificado na chamada HTTPS
- Se essa chamada falhasse, o app não carregava e repetia a mesma tentativa para sempre com os mesmos parâmetros; a tela de carregamento não explicava a causa
- No South Pole, insistir eventualmente podia funcionar, mas um único valor de timeout tornava um app de nível corporativo quase inutilizável
- Um comportamento melhor seria recuo progressivo com timeouts longos, checagem do estado da conexão, exibição da causa, uso de cache ou configuração padrão, e oferta de download e instalação manuais
-
Contraste entre dois apps de chat
- Um app popular de chat usava timeout codificado de 10 segundos para inicialização de WebSocket
- Como era necessário TCP handshake, sessão TLS, configuração de WebSocket e sinalização inicial, em um ambiente como o South Pole, onde cada ida e volta podia levar vários segundos, isso podia passar de 10 segundos
- Quando o timeout estourava, o app não funcionava e entrava em um backoff longo; a UX não deixava a situação clara
- Um app concorrente de chat funcionava melhor mesmo em condições de rede extremamente ruins
- Usava várias estratégias de requisições de rede
- Reaproveitava agressivamente conexões já abertas
- Ajustava timeouts dinamicamente
- Escolhia de forma inteligente os intervalos entre tentativas após falhas
- Mostrava claramente o estado atual da rede
- Nos dois casos, o que se transmitia de fato eram só alguns bytes de texto simples, mas a diferença nas suposições de rede mudava as condições em que o app era utilizável
Transferência incremental e uploads com retomada
- O brr.fyi é um blog estático em Jekyll, com ativos armazenados em S3 e servidos por CloudFront
- Os arquivos estáticos são gerados no notebook local
- São enviados diretamente ao S3
- Não há servidor, ambiente de QA, sistema de build, hooks automáticos nem elementos dinâmicos
- Considerando as limitações do South Pole, o autor criou um script de publicação em Python que fazia upload dos ativos em pequenos chunks via API do S3
- Detectava uploads com falha e retomava sem perder o progresso
- Não publicava a nova versão até que todos os arquivos estivessem enviados com segurança
- Foi implementado em cerca de 200 linhas de Python
- Usuários que quisessem subir arquivos grandes para uma plataforma comercial de blog ou rede social precisavam ajustar o timing às chances de concluir tudo dentro da janela de satélite
- Se falhasse, precisavam tentar várias vezes
- Às vezes não ficava claro se o conteúdo havia sido enviado, se o upload tinha terminado ou se era seguro apertar “Post” de novo
- Se um chunk em
POSTfalhar, mas puder ser repetido ou retomado depois com perda mínima, o usuário consegue enviar o conteúdo aos poucos, alguns KB por vez, quando for conveniente
Critérios que um downloader embutido precisa cumprir
- Se um app for criar seu próprio downloader, ele precisa de um alto nível de qualidade; caso contrário, em internet lenta ele se torna muito incômodo ou falha de forma crítica
- Sempre que possível, o usuário deve poder sair do downloader embutido e baixar o arquivo diretamente
- Oferecer um link para download manual é útil
- Se possível, é ainda melhor fornecer o link para o patch diferencial que o app tentaria baixar, em vez do instalador completo
- As vantagens do link de download manual são claras
- O usuário pode escolher um downloader mais robusto, como o do navegador
- Pode baixar uma vez e compartilhar o arquivo entre vários dispositivos
- Pode baixar em outro computador, não necessariamente aquele em que o app roda
- Pode agendar ou gerenciar o download conforme suas próprias limitações
- No South Pole não havia internet 24 horas por dia; então, mesmo com uma janela diária de 4 horas para download, se a quantidade de dados possível nesse período for menor que o tamanho do payload, não há como concluir de uma vez
- Muitos downloaders embutidos carecem de pausa/retomada, notificação de estado, lógica de retry, acompanhamento de progresso e até impõem limites de tempo de download, o que em internet lenta pode determinar se o app inteiro será utilizável ou não
Por que o gerenciador de downloads do navegador é a referência
- O gerenciador de downloads dos navegadores modernos oferece um padrão alto contra o qual downloaders embutidos inevitavelmente serão comparados
- Interrupção, pausa e retomada
- Nova tentativa de downloads com falha
- Exibição de estado atual, velocidade e tempo restante
- Escolha do local de salvamento e possibilidade de copiar o arquivo
- Nenhum corte arbitrário de desempenho
- Mesmo que o usuário queira baixar um arquivo de vários GB a 60 kbps, o navegador permite
- Se um app não consegue implementar recursos no nível do navegador, o mínimo é fornecer a URL original para que o usuário possa baixar pelo navegador
Caso das atualizações do macOS
- As atualizações do macOS eram especialmente pesadas no South Pole
- Patches menores do sistema normalmente tinham entre 0,5 e 1,5 GB
- Patches de grandes upgrades do sistema às vezes passavam de 6 GB
- Ferramentas adicionais como Xcode também frequentemente tinham vários GB
- Se todos os dispositivos macOS baixassem atualizações diretamente da Apple, haveria grande desperdício de banda
- O atualizador embutido do macOS oferecia pouco controle e não havia uma forma fácil de obter os arquivos de patch subjacentes
- Ao cancelar ou falhar, ele nem sempre retomava de forma inteligente e às vezes perdia o progresso
- Em teoria, o recurso de caching server do macOS poderia reduzir a carga ao fazer cada patch descer ao South Pole apenas uma vez
- Na prática, cada MacBook cliente precisava antes concluir com sucesso uma chamada HTTPS para a Apple para negociar os parâmetros de cache
- Se essa chamada falhasse, o Mac cliente baixava o patch diretamente dos servidores públicos da Apple, sem aviso nem retry
- No South Pole, essa chamada inicial de negociação falhava com frequência, então o recurso de cache não era útil
- Instaladores completos podiam ser baixados da Apple por links reunidos pelo Mr. Macintosh e depois distribuídos na base de forma lenta, porém cuidadosa
- O instalador completo tinha 12 GB, e o download podia levar vários dias, mas era confiável
- Macs Apple Silicon, mesmo atualizados via instalador completo, ainda tentavam baixar diretamente da Apple conteúdo adicional de 1 a 2 GB, como firmware ou atualização do Rosetta
- Não havia forma de contornar ou armazenar isso em cache
- Em alguns casos, o download passava para outro componente do macOS e o progresso não aparecia na UI de instalação
- Surgiam situações em que a tela mostrava “faltam 32 minutos” por horas, enquanto 1 GB era baixado em segundo plano
- Faltavam links para os patches necessários, melhor pausa/retomada e gerenciamento de estado, inclusão dos itens extras para Apple Silicon no instalador completo e melhorias na confiabilidade e no controle do caching server
Caso das atualizações do Android da Samsung
- A ferramenta de atualização de sistema em celulares Samsung Android era um exemplo de produto que não considerava internet lenta ou intermitente
- A UI de atualização não mostrava velocidade, progresso numérico, pausa, cancelamento, tamanho do arquivo nem forma de acessar o arquivo para download separado
- Se o download falhasse, não dava para retomar e tudo começava do zero
- No South Pole, não era possível baixar uma atualização completa do sistema dentro de uma única passagem de satélite; quando a conexão caía, o processo necessariamente falhava e precisava recomeçar do início
- Na prática, a forma de evitar que o celular marcasse o download como fracassado era desligá-lo completamente pouco antes de a internet cair e ligá-lo de novo na próxima passagem do satélite
- Assim, foi possível dividir o download entre várias passagens de satélite até concluir
- Esse tipo de gambiarra não deveria ser necessário
- O app de atualização da Verizon para macOS e Windows teoricamente permite gravar a atualização do sistema pelo computador, mas na prática tinha muitos bugs, baixa confiabilidade e seu próprio downloader embutido
- O ponto central do problema é que as ferramentas comuns fornecidas pelos fabricantes oferecem recursos insuficientes para usuários de internet lenta
Pequenas atualizações de apps e o contraste com o Microsoft Office for Mac
- O atualizador embutido de um pequeno app de desktop carecia de funções básicas necessárias em links lentos
- Botão de pausa
- Botão de cancelar
- Exibição de progresso
- Exibição de velocidade ou tempo restante
- Acesso à URL original
- Rastreamento de progresso e retomada natural de downloads interrompidos
- Só de oferecer um link para download manual esse app já melhoraria muito para usuários no South Pole
- O atualizador automático de outro app tinha botão de cancelar e progresso visual, mas faltavam pausa, progresso numérico e velocidade, acesso à URL original e retomada
- O atualizador automático do Microsoft Office for Mac era um bom exemplo, mesmo no South Pole
- Botão de pausa
- Botão de cancelar
- Exibição de progresso
- Exibição de velocidade e tempo restante
- Retomada natural de downloads interrompidos
- Seria ainda melhor se oferecesse a URL original, mas a interface já era boa o suficiente para funcionar bem até no South Pole
Princípios práticos de projeto para usuários com internet lenta
- Em internet rápida, funcionalidades que parecem pequenos detalhes podem virar obstáculos principais em internet lenta
- Apps devem ser projetados para que um único timeout fixo não prenda o usuário em um loop onde ele nem consegue enviar alguns bytes de texto
- Alguns princípios de projeto possíveis são simples
- Não interromper se os bytes estiverem se movendo
- Dividir payloads grandes em chunks
- Preservar o progresso mesmo quando houver falha
- Mostrar claramente ao usuário o estado da rede
- Se o downloader embutido for insuficiente, oferecer link para download manual
- O South Pole é um caso extremo, mas ambientes Inmarsat em navios, Thales MissionLink e Iridium Certus em postos de pesquisa nas montanhas, Wi‑Fi instável, roteadores mal configurados, WISPs de baixa qualidade e usuários de conexões antigas por linha telefônica também podem enfrentar restrições semelhantes
- Desenvolvedores não precisam otimizar tudo para todos os cenários extremos, mas vale o esforço para que o produto não atrapalhe ativamente o progresso de quem usa conexões lentas
1 comentários
Opiniões do Hacker News
Esse texto me tocou bastante. Não estou na Antártida, estou em Pequim, mas ainda sofro com a internet
Quando se está atrás do Grande Firewall, é preciso usar métodos criativos, e VPN só funciona de vez em quando. Cada VPN deixa rastros, e as heurísticas e o aprendizado de máquina do firewall acabam detectando; até VPNs permitidas pelo Estado são limitadas “suavemente” em períodos politicamente sensíveis
No fim, mesmo quando a conexão funciona, ela não é estável, e é doloroso demais desperdiçar pacotes preciosos em webapps inúteis/idas e voltas do React
Alguns desenvolvedores deveriam viajar no tempo até mais ou menos 2005 e tentar desenvolver pelos padrões daquela época para aprender a fazer coisas leves. Se viagem no tempo não for possível, eu gostaria que pelo menos ativassem o throttling nas ferramentas de desenvolvedor, configurassem para 3G e verificassem, por favor, se o próprio webapp aguenta
Sempre testo projetos com largura de banda limitada. Assim como em acessibilidade, seguir boas práticas resulta em uma experiência de usuário melhor não só para quem tem conexão ruim, mas para todos
Outra oportunidade que muita gente perde é tornar apps de página única offline-first
Não estou necessariamente discordando do ponto geral, mas JavaScript moderno é, na prática, bastante bom para lidar com internet lenta em “aplicações” servidor-cliente. Só que não é fácil fazer isso, e quase não há material online que alguém programando com Google/GPT possa usar como base de um projeto
Isso se deve em parte ao excesso de materiais ruins sobre JavaScript online, mas também ao fato de organizações que trabalham desse jeito não compartilharem. Nós também não temos motivo para entregar informações aos concorrentes, então há 0 material público sobre nossa forma de trabalhar
Acaba sendo um treino interessante para reduzir idas e voltas inúteis em tecnologias que esperam usar round-trips para tudo
Ainda consigo algo em torno de 1 a 10 Mbit/s, geralmente dependendo do horário, e quase não tenho problemas de conexão
Como alguém com bastante experiência de deslocamento em transporte público subterrâneo, com conexão intermitente e congestionada, e que já morou e trabalhou na Austrália, posso afirmar com confiança que a maioria dos serviços é péssima para pessoas que não estão em condições de rede “ideais”
No London Underground, é especialmente evidente como a maioria dos apps lida muito mal com uma rede que cai e volta aproximadamente a cada 2 minutos. A conexão some entre as estações e, quando um trem com 500 passageiros tenta se conectar ao mesmo tempo, até conectar a cada ponto de acesso leva uns 15 segundos
Na Austrália, em geral você está a 200 ms de tudo. Pode parecer pouca coisa, mas isso revela muito bem quais apps tropeçam no problema de requisições N+1
O único app que sempre impressiona é o WhatsApp. Depois de reconectar, é o primeiro a voltar a funcionar; é o último a ainda conseguir passar tráfego pouco antes de a conexão cair; e, mesmo com latência, as chamadas parecem bastante rápidas
É bem provável que o WhatsApp seja um dos raros serviços que de fato implantaram servidores na Austrália. 200 ms parece um forte sinal de tráfego intercontinental
A maioria das empresas globais implanta, no máximo, em três regiões: EUA (us-east, us-central, us-east+us-east), Europa (west-europe) e, relativamente raramente, Extremo Oriente (us-west ou Japão)
Por isso, lugares como África do Sul, América do Sul e Austrália normalmente precisam buscar dados em uma dessas regiões, e as limitações físicas impõem uma latência mínima de 200 ms
A Austrália é especialmente afetada. Mesmo que, em tese, haja uma implantação dedicada na jurisdição, muitas vezes os servidores reais ficam em um continente completamente diferente, como a costa oeste dos EUA ou o Japão, e os usuários sofrem diretamente o impacto de desempenho de pacotes dando meia volta ao mundo
Acho que essa perspectiva ficou profundamente incorporada aos objetivos de desenvolvimento, o que deu ao WhatsApp motivo suficiente para se tornar o mensageiro dominante em vários países do mundo
Quando tento abrir uma URL .jpg no navegador para ver a imagem, demora muito mais do que quando vou para o termux e executo
wget, e às vezes dá timeout. Passei por isso tanto no Firefox quanto em navegadores baseados no ChromeComo referência, mesmo downloads com
wgetnormalmente levam de 10 a 30 segundos na conexão móvelNão entendo por que Berlin fez assim. Bastaria oferecer internet dentro do trem
Quando a rede fica caindo o tempo todo, a maior parte da internet funciona muito mal
Viajo bastante, e internet lenta é algo bem comum. Agora mesmo meus dados móveis acabaram e estou limitado a 8 kbps
Sites que são só texto em uma página deveriam ser rápidos, mas muitos não são. O Hacker News é extremamente rápido, mas a documentação da API do Google nem abre
O pior problema é que a maioria das UIs não leva em conta requisições lentas. Parece que os botões estão quebrados, e coisas que não deveriam precisar de megabytes de dados levam minutos para carregar ou falham. Toda a UI do Google Maps quebra
Eu gostaria que os desenvolvedores projetassem e testassem mais para internet lenta. Em vez disso, acabamos com sites devoradores de dados que só funcionam bem em notebooks corporativos rápidos e internet rápida
Relacionado a isso: ganho a vida operando sites, e migrar para um gerador de sites estáticos foi uma das melhores escolhas em termos de produtividade. Em vez de a latência do CMS contaminar todas as tarefas, posso editar arquivos de texto extremamente rápido, mesmo totalmente offline, e quando volto a ficar online só dou push nas mudanças. Mudou o jogo
Hoje em dia, baixar 500 MB de cache do Google Maps no celular parece não servir para nada. Ele ainda busca tudo e aparece aos trancos depois
Atualmente um dos meus domínios está marcado como “perigoso” porque eu não estava usando um WordPress atualizado
Basicamente, toda requisição enviada chega a um app no AppEngine, que executa código Python e devolve HTML. Então parece que deveria ser rápido, mas na prática não é
Estou no Reino Unido e o ping até news.ycombinator.com é de 147 ms. Parece ser porque ele não usa CDN e é hospedado nos EUA
Já cloud.google.com tem ping de 8 ms
O Hacker News é uma página simples e com pouco JavaScript, mas pode haver outros fatores que o façam parecer lento para usuários de certas regiões. Isso mesmo em um ambiente privilegiado usando uma fibra XGS-PON com 8 Gbps simétricos
Uma vez dei carona, enquanto pegava carona na estrada, a alguém que tinha acabado de descer da calota de gelo, e ele disse que, embora o autor daquele blog escrevesse muito bem, era meio malvisto pelas pessoas ao redor porque muitas vezes consumia a banda já limitada durante uploads de imagens
Mas, segundo ele, a área administrativa reconheceu o valor de divulgação, então ele recebia prioridade. Achei que isso se encaixava bem na discussão sobre internet lenta
O celular no bolso pode estar usando desnecessariamente toda a banda possível, e, se alguém estiver vendo um vídeo em 720p, mesmo que mal esteja reproduzindo, quem tentar carregar algo depois talvez não consiga nem 480p. A própria pessoa pode não perceber por causa do buffer, enquanto a outra pode desistir antes de o buffer encher o suficiente
Parece que deveria haver, no mínimo, uma contabilidade de uso que informe qual porcentagem do tráfego da última hora foi para você e, em comparação com um valor de referência calculado dividindo a largura de banda disponível pelo número de usuários conectados, qual teria sido sua parcela percentual se todos precisassem igualmente
Indo além, parece possível ter um sistema que mantenha todos em baixa prioridade até que a pessoa clique em um botão do tipo “sim, eu sei quanta largura de banda vou usar nas próximas [X≤24] horas e realmente preciso dela”, e então eleve a prioridade de QoS do endereço MAC/IP para normal
Esse tipo de situação está clamando por aplicativos local-first e por soluções desse tipo, e foi para isso que a internet foi criada em primeiro lugar [1][2]
As pessoas caíram no slogan “No Software” da Salesforce, mas isso vai diretamente contra a base e o espírito da internet. Desde 1969, durante a maior parte da história da internet, Mbps era exceção, não padrão, e o primeiro killer app, mensagens por e-mail (provavelmente ainda o melhor app da internet), é local-first [3]
Ironicamente, o aplicativo do qual o autor reclamou também é um app de mensagens
[1] Local-first software: You own your data, in spite of the cloud:
https://www.inkandswitch.com/local-first/
[2] Local-first Software:
https://localfirstweb.dev/
[3] Leonard Kleinrock: Mr. Internet:
https://www.latimes.com/opinion/la-oe-morrison-use24-2009oct...
Ao longo de alguns anos, trabalhei bastante com redes e passei um tempo fazendo meu próprio ambiente de “internet lenta” funcionar. Não é tão interessante quanto McMurdo, mas consegui conversar por chat e assistir a vídeos do YouTube em voos internacionais, trens passando por lugares remotos, hotéis rurais péssimos e até dentro de túneis.
Se você tem acesso a um dispositivo de computação de uso geral, consegue bancar a energia (esses equipamentos costumam consumir bastante) e está disposto a montar você mesmo, recomendo o NNCP [1]. O NNCP consegue receber dados, fragmentá-los e enviá-los. Ele também inclui um protocolo de sincronização que usa noise sobre TCP e envia os dados tentando novamente os fragmentos que falharam. Como não precisa de TLS, estabelecer a conexão leva apenas 1,5 RTT.
O NNCP consegue alimentar dados da entrada padrão para um programa remoto. Criei um downloader do YouTube, bots do Slack, Telegram e Discord para ler os dados recebidos e interagir com esses serviços. Na máquina local, deixei um servidor Matrix (Dendrite) e bots rodando, e envio os dados pelo NNCP para o serviço remoto apropriado.
É preciso desejar, ou testar, que o MTU/MSS no caminho seja o mais baixo possível para que novas tentativas no nível TCP possam acontecer com frequência, mas essa configuração quase nunca falhou comigo onde quer que eu estivesse e permite consumir mídia e conversar.
O ponto mais irritante em voos internacionais é que os endpoints do NNCP não são geograficamente distribuídos. Dependendo da rota do voo e do caminho real que os pacotes percorrem até o endpoint, a latência e o jitter podem aumentar muito. Normalmente tento manter um endpoint NNCP perto do destino, mas, do ponto de vista do Wi‑Fi a bordo, a rota real pode ser péssima. O NNCP agora tem suporte ao Yggdrasil, o que pode mitigar isso e também ajudar a controlar problemas de MTU, mas nunca usei o Ygg nessas condições.
[1]: http://www.nncpgo.org/
Tive uma experiência parecida com a do autor em um barco no Pacífico Sul. Havia Starlink, mas o consumo de energia era alto (60 W ou mais), então não usávamos com frequência. Em vez disso, compramos cartões SIM locais e usamos 4G em alguns lugares e EDGE (2G) em outros.
O EDGE em si não é tão ruim no papel. Dá algumas dezenas de quilobits por segundo. Na prática, foi muito pior. Vi aplicativos que teriam funcionado bem se apenas levassem em conta que o carregamento poderia levar minutos, não milissegundos, falharem por causa de timeouts curtos.
Conexões de baixa largura de banda e alta latência deveriam fazer parte dos testes regulares de software. No Linux, existe o netem (https://wiki.linuxfoundation.org/networking/netem), que permite fazer isso.
Um problema que o autor anônimo do blog não teve foi a conexão tarifada por uso. Por causa do custo, upgrades do sistema operacional ou de apps eram praticamente impossíveis. Felizmente, a cada poucas semanas chegávamos a algum lugar com conexão ilimitada e podíamos fazer essas coisas. Em compensação, fiquei muito familiarizado com como marcar conexões como tarifadas/não tarifadas em vários sistemas operacionais, desativar todas as atualizações automáticas e economizar a preciosa largura de banda.
E, se eram “cartões SIM locais”, isso quer dizer que vocês desembarcaram em uma ilha para comprar o SIM; fico curioso para saber onde, nos anos 2020, só havia 2G. É difícil acreditar que ainda existam lugares assim no Pacífico Sul.
É preciso manter a perspectiva. Alguns projetos pulam até testes de webapp em vários navegadores dizendo que é desperdício e um custo injustificável, mesmo sendo algo trivial de colocar na matriz de testes e apenas um problema de UI.
A engenharia pensada para internet lenta ainda é realmente importante e, na minha opinião, muito subestimada pela maioria dos desenvolvedores de software. Mas os sistemas de satélites de órbita baixa (Starlink, especialmente Starlink) agora praticamente resolveram o problema central
Em setembro-outubro de 2023, passei pela rota do Ártico (do Alasca à Noruega) e, mesmo em um navio muito acima do Círculo Polar Ártico, apesar das nuvens, da distância da terra firme e do gelo, consegui fazer chamadas de vídeo pelo FaceTime. Foi na mesma época em que o autor estava na Antártida
Qualquer que fosse a restrição, no fim é uma questão de contrato de serviço e de levar os terminais até o local. A cobertura polar é relativamente rara, mas a população é extremamente pequena, então ainda é suficiente
https://satellitemap.space/
“Internet lenta” pode significar várias coisas, e uma delas é problema de conexão. Em protocolos orientados a conexão, como TCP, é lentidão causada por perda de pacotes; em protocolos do tipo “envia e esquece”, como UDP, significa que a mensagem não chega. Portanto, a lentidão pode ser uma baixa taxa de transmissão, ou pode assumir a forma de alta vazão momentânea seguida de pequenas interrupções
Uma abordagem robusta para lidar com redes lentas é oferecer suporte a modo offline. É projetar todo push/pull de dados como transações assíncronas e, no caso de push de dados, armazenar em cache localmente e tentar novamente quando possível. Isso traz requisitos adicionais, como controle de versões e resolução de conflitos
Naturalmente, os requisitos de UI também aumentam. Passam a ser necessários sincronização/atualização manual, indicação de status da rede, desativação de ações sem sentido quando a rede cai e carregamento proativo para permitir uso offline
Um dia quero viver em um mundo pós-internet lenta, mas isso ainda está a muitos anos de distância. A propósito, o XS vinha com um modem Intel conhecido por ser inferior aos flagships da Qualcomm daquela época
Moro em um dos lugares mais densamente povoados do mundo, cheio de antenas 5G e estações Wi‑Fi, mas ainda sinto sites malfeitos tombarem em conexões lentas ou intermitentes
Satélites geoestacionários têm cobertura polar limitada porque, no Polo, ficam perto demais do horizonte. O Polo usa satélites geoestacionários antigos, com pouco combustível e inclinação orbital relativamente alta, e por isso só consegue se comunicar por cerca de 6 horas a cada 24 horas
Cronograma: https://www.usap.gov/technology/1935/
Governos não vão querer uma web sem censura nem uma empresa americana servindo como porta de entrada para a internet. Eles vão manter as redes dentro dos territórios que controlam, e o problema de velocidade continuará válido
Também é preciso considerar o número de pessoas no mundo cujo único meio de acesso à internet é um celular Android de US$ 100, com software antigo e CPU limitada
Há uma proposta de rascunho da IETF que estende o HTTP para sincronização eficiente de estado e pode melhorar a experiência do usuário em redes lentas: https://news.ycombinator.com/item?id=40480016
O Braid Protocol permite que vários algoritmos de sincronização interoperem sobre um protocolo de rede comum, e as mensagens de rede de qualquer sincronizador podem ser traduzidas para ele. A especificação atual do Braid adiciona duas dimensões de sincronização ao HTTP
Nível 0: HTTP de hoje
Nível 1: assinaturas com atualizações por push
Nível 2: consistência P2P (patches, versões, merges)
Hoje, sincronizadores usam protocolos diferentes, mas suas mensagens de rede carregam o mesmo tipo de informação: versões no tempo, posições no espaço e patches de regiões espaciais ao longo de intervalos de tempo. A composição de um conjunto arbitrário de patches forma uma estrutura matemática chamada braid: ramificações, merges e reordenações do espaço ao longo do tempo
A esperança brota eternamente
Reduzir requisições de ida e volta e criar algo menos inchado não é difícil; pelo contrário, é muito mais fácil. O inchaço existe por motivos totalmente diferentes
Às vezes, em uma internet rápida perto de datacenters e em máquinas generosas, o inchaço não aparece. É fácil simular isso, mas a empresa precisa se importar. Em geral, a tecnologia de anúncios e seu entorno têm muito pouco interesse em pequenos grupos de usuários. Na verdade, o único motivo para se importarem com o usuário final é que ele gera receita para os clientes reais, ou seja, os anunciantes
Nós que criamos apps, sites etc. precisamos lembrar que muita gente não está conectada ao Wi‑Fi rápido ou à fibra que usamos
No Reino Unido, algumas operadoras começaram a desligar o 3G. Em certos lugares deixam o 2G como alternativa de baixo consumo, mas a ideia agora é usar 4G/5G. O problema é que o 4G ainda não funciona em todos os lugares e, até pouco tempo atrás, em algumas regiões só o sinal 3G era aceitável
Por isso, cair involuntariamente para 2G/EDGE ficou mais comum, e muitas coisas simplesmente travam. Muitos apps não são testados em cenários lentos, com alta latência e grande perda de pacotes
Tente traçar uma rota no Google Maps em 2G e você entenderá :(