- El internet del South Pole dependía de enlaces satelitales limitados y estaba conectado solo unas horas al día; a octubre de 2023, los usuarios de la comunidad tenían que tolerar alta latencia, bajo ancho de banda y cortes intermitentes
- El entorno real combinaba una latencia de ida y vuelta de unos 750 ms, jitter de varios segundos, velocidades de unos pocos kbps a 2 Mbps, congestión, colas, pérdida de paquetes y prioridad de servicios, lo que rompía fácilmente los supuestos de red de las apps comunes
- Grandes bundles de JavaScript, timeouts hardcodeados, descarte del progreso, invalidación de caché y descargadores integrados que no permiten reanudar eran factores que hacían que las apps fallaran por sí solas en enlaces lentos
- Si los bytes siguen fluyendo, aunque sea lentamente, conviene esperar; con transferencias por chunks, reanudación, indicadores de estado, timeouts dinámicos y enlaces de descarga manual, objetivos pequeños como mensajes de texto o actualizaciones sí eran alcanzables
- La Antártida es un caso extremo, pero barcos en altamar, sitios de investigación en montaña, Wi‑Fi inestable, WISP de baja calidad y usuarios con acceso por línea telefónica pueden sufrir restricciones similares, por lo que se necesita un diseño que no bloquee el progreso del usuario
Restricciones del entorno de internet en el South Pole
- Proveer internet en el South Pole es en sí mismo un desafío de ingeniería no trivial, y las opciones de satélite que se pueden usar en las regiones polares son limitadas
- Como material público existe la página South Pole Satellite Communications
- La dificultad de llevar fibra óptica tradicional hasta el continente antártico también se trató en el 2021 Antarctic Subsea Cable Workshop
- Aunque la NSF hizo un anuncio relacionado con Starlink en McMurdo y Palmer, a octubre de 2023 no había un anuncio similar para la South Pole Station
- McMurdo, hasta hace poco, compartía entre casi 1,000 personas y varias cargas de trabajo científicas y operativas un ancho de banda agregado de decenas de Mbps para toda la base
- Es una situación en la que toda la base comparte menos ancho de banda del que una persona puede obtener en una red celular 4G típica de un suburbio de Estados Unidos
- El South Pole solo tenía conexión cuando un satélite subía sobre el horizonte y la base tenía autorización para usarlo; por la diferencia entre el tiempo sideral y el tiempo solar, el horario de los satélites generalmente se adelantaba unos 4 minutos por día
- La latencia percibida por los usuarios era muy distinta de la experiencia normal de internet
- La latencia de ida y vuelta hasta destinos en el territorio continental de Estados Unidos era de unos 750 ms
- Aproximadamente 10 veces más que los hasta 75 ms de latencia de ida y vuelta entre las costas este y oeste de Estados Unidos
- Aproximadamente 30 veces más que los hasta 25 ms esperados desde una conexión residencial típica de cable o fibra hasta los principales CDN
- Comparado con los alrededor de 3 ms desde la fibra GPON de la casa del usuario hasta Fastly, Cloudflare, CloudFront, Akamai y Google, el South Pole era más de 250 veces mayor
Condiciones reales que enfrentaban los usuarios de la comunidad
- A octubre de 2023, una persona que usaba internet con fines comunitarios en el South Pole podía enfrentar estas condiciones
- Latencia promedio de ida y vuelta de unos 750 ms, con jitter entre paquetes de varios segundos
- Velocidades desde unos pocos kbps hasta 2 Mbps en un día muy bueno, medidas en el dispositivo del usuario final
- Congestión intensa, colas y descarte de paquetes
- Disponibilidad limitada, caídas frecuentes y ocasionales prioridades de servicio que desplazaban el tráfico
- En ciertas situaciones también aparecían condiciones como 40 kbps, 1,000 ms de latencia, hasta 2,000 ms de jitter, 10% de pérdida de paquetes y cortes completos de 15 segundos cada pocos minutos
- Como el tráfico operativo recibía una prioridad fuerte, los usuarios de la comunidad dependían de la capacidad sobrante
- Funciones como videoconferencias en tiempo real eran difíciles de esperar, pero en algunas apps sí era posible enviar y recibir textos de apenas unos bytes
- La ingeniería web y de apps que no consideraba enlaces lentos o intermitentes empeoraba aún más la usabilidad
Caso de una web app colaborativa que requería 20 MB de JavaScript
- Una plataforma colaborativa empresarial tenía que descargar casi 20 MB solo de JavaScript para renderizar la pantalla principal
- Desde el acceso anterior, la app se había actualizado y todos los assets en caché del navegador habían quedado obsoletos, por lo que había que descargarlos de nuevo
- El navegador y los protocolos manejan hasta cierto punto el control de congestión en internet lento, pero esta app cortaba la carga por sus propias condiciones de falla
- Si no terminaba de cargar dentro del tiempo o la cantidad de reintentos definidos por el desarrollador, la app se detenía
- Redirigía a una página de error
- Se perdía el estado de carga ya avanzado
- En el siguiente reintento se aplicaban medidas fuertes de invalidación de caché
- En esencia, esta app era una app de mensajería, y después de ejecutarse, al chatear con amigos, la carga útil real del contenido era de apenas bytes
- El rendimiento de internet del South Pole estaba justo en el límite que el desarrollador consideró “aceptable”, y el usuario tenía que refrescar varias veces y volver a descargar el mismo JavaScript
- Si se hubiera dejado continuar la transferencia necesaria, podía terminar en menos de 15 minutos, pero en la práctica a veces tomaba horas
- En un caso exitoso, se hicieron 809 solicitudes HTTP, se transfirieron 51.4 MB, se cargó durante 26.5 minutos y luego se envió un mensaje de 6 bytes mediante un POST HTTPS de 1.8 KB
- Si la app hubiera estado diseñada para seguir esperando mientras los datos fluyeran, aunque fuera lentamente, se habrían reducido retransmisiones innecesarias y desperdicio de ancho de banda
El problema de los timeouts hardcodeados y las transferencias grandes de una sola vez
- Las suposiciones fijas sobre qué tan rápido se transferirá una carga útil o cuánto se puede enviar en una sola solicitud pueden romper una app en enlaces lentos
- Si se puede medir que los bytes siguen fluyendo, conviene no interrumpir la transferencia sin importar lo lenta que sea, y mostrar la situación actual en la UI
- Si una llamada HTTPS falla, se debe reintentar con un timeout más largo, y los datos grandes deben dividirse en chunks pequeños
- Se debe rastrear el progreso por chunk
- Debe ser posible reintentar o reanudar solo la parte pequeña que falló
- Un progreso incremental lento y constante es más seguro que intentar enviar grandes datos de una sola vez
- Si las llamadas HTTPS siguen fallando, en lugar de repetir ciegamente la misma llamada conviene revisar DNS, ICMP, HTTP sin TLS, HTTPS hacia un endpoint conocido en buen estado, etc., e informar el estado al usuario
-
Falla al descargar metadatos al iniciar
- Una app de escritorio popular descargaba información de configuración desde el sitio web del proveedor al iniciar y usaba un timeout hardcodeado para la llamada HTTPS
- Si esa llamada fallaba, la app no cargaba y reintentaba eternamente con los mismos parámetros; la pantalla de carga no informaba la causa
- En el South Pole, si se insistía, eventualmente podía pasar, pero un único valor de timeout volvía casi inutilizable una app de nivel empresarial
- Un mejor comportamiento habría sido degradar gradualmente con timeouts más largos, revisar el estado de conexión, mostrar la causa, usar caché o configuración predeterminada, y ofrecer una ruta de descarga e instalación manual
-
Contraste entre dos apps de chat
- Una app de chat popular usaba un timeout hardcodeado de 10 segundos para inicializar WebSocket
- Como se requerían el handshake TCP, la sesión TLS, la configuración de WebSocket y la señalización inicial, en condiciones como las del South Pole, donde cada ida y vuelta podía tomar varios segundos, se podían superar los 10 segundos
- Al vencerse el timeout, la app no funcionaba y entraba en un estado de backoff largo; la UX no mostraba la situación con claridad
- Una app de chat competidora funcionaba mejor incluso con condiciones de red extremadamente malas
- Usaba varias estrategias de solicitudes de red
- Reutilizaba activamente conexiones abiertas
- Ajustaba los timeouts dinámicamente
- Elegía de forma inteligente los intervalos de reintento ante fallas
- Mostraba claramente el estado actual de la red
- Ambas apps en realidad transmitían apenas unos bytes de texto plano, pero la diferencia en sus supuestos de red cambiaba las condiciones en las que podían usarse
Transferencia incremental y cargas reanudables
- brr.fyi es un blog estático con Jekyll, cuyos assets se almacenan en S3 y se sirven mediante CloudFront
- Los archivos estáticos se compilan en una laptop local
- Se suben directamente a S3
- No hay servidor, entorno de QA, sistema de build, hooks automáticos ni elementos dinámicos
- El script de publicación en Python creado teniendo en cuenta las restricciones del South Pole subía assets mediante la API de S3 en chunks pequeños
- Detectaba cargas fallidas y las reanudaba sin perder el progreso
- No publicaba una nueva versión hasta que todos los archivos se hubieran subido de forma segura
- Estaba implementado en unas 200 líneas de Python
- Los usuarios que subían archivos grandes a plataformas comerciales de blogs o redes sociales tenían que ajustar el momento según la probabilidad de que la carga terminara de una vez dentro de la ventana satelital
- Si fallaba, tenían que reintentar varias veces
- A veces no estaba claro si el contenido había subido, si la carga había terminado o si era seguro volver a presionar “Post”
- Si un POST por chunks falla pero luego se puede reintentar o reanudar con pérdidas mínimas, es posible ir acumulando cargas de unos pocos KB en momentos convenientes
Criterios que deben cumplir los descargadores integrados
- Si una app crea su propio descargador, necesita un nivel alto de calidad; de lo contrario, en internet lento será muy incómoda o fallará de forma crítica
- Cuando sea posible, el usuario debería poder salir del descargador integrado y descargar el archivo directamente
- Es útil ofrecer un enlace de descarga manual
- Si es posible, es mejor un enlace al archivo de parche diferencial que la app intentaba bajar que al instalador completo
- Las ventajas de un enlace de descarga manual son claras
- El usuario puede elegir un descargador más robusto, como el navegador
- Puede descargar el archivo una vez y compartirlo con varios dispositivos
- Puede descargarlo en una computadora distinta de aquella donde se ejecuta la app
- Puede programar o administrar la descarga según sus propias restricciones
- Como en el South Pole no hay internet las 24 horas, aunque haya una ventana diaria de descarga de 4 horas, si los datos que se pueden recibir durante ese tiempo son menores que el tamaño de la carga útil, no hay forma de completarla de una sola vez
- Muchos descargadores integrados carecen de pausa y reanudación, avisos de estado, lógica de reintentos y seguimiento de progreso, y también tienen restricciones como límites de tiempo de descarga, por lo que determinan si toda la app será usable en internet lento
Por qué el gestor de descargas del navegador es el punto de referencia
- Los gestores de descargas de los navegadores web modernos ofrecen un estándar alto con el que inevitablemente se comparan los descargadores integrados
- Funciones de interrupción, pausa y reanudación
- Reintento de descargas fallidas
- Visualización del estado actual, la velocidad y el tiempo restante
- Elección de ubicación de guardado y posibilidad de copiar el archivo
- Sin cortes arbitrarios por rendimiento
- Si un usuario quiere descargar un archivo de varios GB a 60 kbps, el navegador se lo permite
- Si una app no puede implementar funciones al nivel del navegador, al menos conviene ofrecer la URL original para que el usuario pueda descargarla con el navegador
Caso de las actualizaciones de macOS
- Las actualizaciones de macOS eran especialmente pesadas en el South Pole
- El tamaño de los parches de actualizaciones menores del OS suele ser de 0.5 a 1.5 GB
- Los parches de upgrades mayores del OS a veces son de 6 GB o más
- Herramientas adicionales como Xcode también suelen ocupar varios GB
- Si todos los dispositivos macOS descargan las actualizaciones directamente desde Apple, se desperdicia mucho ancho de banda
- El actualizador integrado de macOS daba poco control y no había una forma sencilla de obtener los archivos de parche subyacentes
- Si se cancelaba o fallaba, no siempre reanudaba de forma inteligente, y a veces se perdía el progreso
- La función de servidor de caché de macOS de Apple, en teoría, podía reducir la carga haciendo que cada parche se descargara al South Pole una sola vez
- En la práctica, cada MacBook cliente tenía que completar correctamente una llamada HTTPS a Apple para negociar los parámetros de caché
- Si esa llamada fallaba, el Mac cliente descargaba el parche directamente desde los servidores públicos de Apple sin aviso ni reintento
- En el South Pole, esta llamada inicial de negociación fallaba con frecuencia, por lo que la función de caché no resultaba útil
- El instalador completo podía descargarse desde Apple mediante enlaces reunidos en Mr. Macintosh, y luego distribuirse dentro de la base después de descargarlo lenta pero cuidadosamente
- El instalador completo era de 12 GB, y la descarga podía tardar varios días, pero era confiable
- Aunque se actualizara una Mac con Apple Silicon usando el instalador completo, intentaba descargar directamente desde Apple 1 a 2 GB adicionales de contenido, como actualizaciones de firmware o Rosetta
- No había forma de evitarlas ni de cachearlas
- A veces la descarga pasaba a otro componente de macOS y el progreso no se reflejaba en la UI de instalación
- Se daba una situación en la que la pantalla de “32 minutos restantes” se mantenía durante horas mientras se descargaba 1 GB en segundo plano
- Hacía falta ofrecer enlaces a los parches necesarios, fortalecer la pausa, reanudación y gestión de estado, incluir los componentes adicionales para Apple Silicon en el instalador completo, y mejorar la confiabilidad y el control del servidor de caché
Caso de las actualizaciones del OS en Samsung Android
- La herramienta de actualización del OS de los teléfonos Samsung Android era un ejemplo de no considerar internet lento o intermitente
- La UI de actualización no mostraba velocidad, progreso numérico, pausa, cancelación, tamaño de archivo ni una forma de acceder al archivo para descarga separada
- Si la descarga fallaba, no podía reanudarse y empezaba de nuevo desde cero
- En el South Pole no era posible descargar una actualización completa del OS dentro de una sola pasada satelital, así que si se cortaba la conexión necesariamente fallaba y había que volver a empezar
- En la práctica, se evitaba que la descarga se marcara como fallida apagando por completo el teléfono justo antes de que se cortara internet y volviéndolo a encender en la siguiente pasada satelital
- Con este método se podía completar la descarga dividida en varias pasadas satelitales
- Este rodeo era una solución anómala que no debería ser necesaria
- La app de actualización de Verizon para macOS y Windows, en teoría, permite flashear actualizaciones del OS desde una computadora, pero en la práctica tenía muchos bugs, era poco confiable y usaba su propio descargador integrado
- El núcleo del problema es que las herramientas para usuarios finales provistas por el proveedor ofrecen funciones insuficientes para usuarios con internet lento
Contraste entre actualizaciones de apps pequeñas y Microsoft Office for Mac
- El actualizador integrado de una pequeña app de escritorio carecía de funciones básicas necesarias en enlaces lentos
- Botón de pausa
- Botón de cancelar
- Indicador de progreso
- Velocidad o tiempo restante
- Acceso a la URL original
- Seguimiento del progreso y reanudación natural de descargas interrumpidas
- Esta app habría mejorado mucho para usuarios del South Pole con solo ofrecer un enlace de descarga manual
- El actualizador automático de otra app tenía botón de cancelar e indicador visual de progreso, pero le faltaban pausa, progreso y velocidad numéricos, acceso a la URL original y reanudación
- El actualizador automático de Microsoft Office for Mac fue un buen ejemplo incluso en el South Pole
- Botón de pausa
- Botón de cancelar
- Indicador de progreso
- Velocidad y tiempo restante
- Reanudación natural de descargas interrumpidas
- Habría sido mejor si ofreciera la URL original, pero la interfaz era lo suficientemente buena como para poder usarse razonablemente en el South Pole
Principios prácticos de diseño para usuarios con internet lento
- Funciones que en un entorno de internet rápido parecen pequeñas omisiones pueden convertirse en obstáculos importantes en internet lento
- Las apps deben diseñarse para que un timeout fijo no deje al usuario atrapado en un bucle en el que ni siquiera puede enviar unos pocos bytes de texto
- Los principios de diseño posibles son simples
- Si los bytes se están moviendo, no interrumpir
- Dividir las cargas útiles grandes en chunks
- Preservar el progreso aunque haya fallas
- Mostrar claramente al usuario el estado de la red
- Si el descargador integrado es insuficiente, ofrecer un enlace de descarga manual
- El South Pole es un caso límite, pero entornos Inmarsat en barcos en altamar, Thales MissionLink e Iridium Certus en sitios de investigación de montaña, Wi‑Fi inestable, routers mal configurados, WISP de baja calidad y usuarios con dial-up sobre líneas telefónicas antiguas pueden sufrir restricciones similares
- Los desarrolladores no tienen que optimizar para todas las situaciones extremas, pero sí deben esforzarse para que el producto no bloquee activamente el progreso de usuarios con conexiones lentas
1 comentarios
Opiniones de Hacker News
Este artículo me pegó mucho. No estoy en la Antártida, sino en Beijing, pero sigo sufriendo por Internet.
Detrás del Gran Cortafuegos hay que usar métodos creativos, y las VPN solo funcionan de vez en cuando. Cada VPN deja huellas, así que la heurística y el aprendizaje automático del cortafuegos terminan detectándolas, e incluso las VPN permitidas por el Estado se restringen “suavemente” en momentos políticamente sensibles.
Al final, aunque logres conectarte, no es estable, y duele demasiado desperdiciar paquetes valiosos en webapps inútiles o en idas y vueltas de React.
Algunos desarrolladores deberían viajar en el tiempo a más o menos 2005 y desarrollar con los estándares de esa época para aprender a hacer cosas ligeras. Si no se puede viajar en el tiempo, ojalá al menos activen el throttling en las herramientas de desarrollo, lo pongan en 3G y comprueben por favor si su webapp aguanta.
Siempre pruebo los proyectos con ancho de banda limitado. Al igual que con la accesibilidad, seguir buenas prácticas mejora la experiencia de usuario para todos, no solo para quienes tienen mala conexión.
Otra oportunidad que se suele pasar por alto es hacer que las aplicaciones de una sola página sean offline-first.
No necesariamente me opongo al punto general, pero JavaScript moderno en realidad es bastante bueno para lidiar con Internet lento en “aplicaciones” servidor-cliente. Eso sí, no es fácil hacerlo bien, y casi no hay material en línea que alguien que programa con Google/GPT pueda usar como base para un proyecto.
Esto se debe en parte a que hay demasiado material pésimo sobre JavaScript en línea, pero también influye que las organizaciones que trabajan así no lo comparten. Nosotros tampoco tenemos razones para pasarles información a la competencia, así que hay 0 materiales públicos sobre nuestra forma de trabajar.
Se vuelve un ejercicio interesante para reducir idas y vueltas inútiles en tecnologías que esperan usar round trips para todo.
Aún así consigo alrededor de 1 a 10 Mbit/s, por lo general depende de la hora del día, y casi no tengo problemas de conexión.
Como alguien con mucha experiencia viajando en transporte público subterráneo (intermitente y congestionado), y que vivió y trabajó en Australia, puedo decir con confianza que la mayoría de los servicios son pésimos para quienes no tienen condiciones de red “ideales”.
En el London Underground es especialmente evidente que la mayoría de las apps manejan muy mal una red que se corta y vuelve aproximadamente cada 2 minutos. Se corta entre estaciones, y como un tren con 500 pasajeros intenta conectarse al mismo tiempo, también tarda unos 15 segundos en conectarse a cada punto de acceso.
En Australia, en general estás a 200 ms de todo. Puede parecer poca cosa, pero deja muy en claro qué apps se tropiezan con problemas de solicitudes N+1.
La única app que siempre impresiona es WhatsApp. Es la primera en funcionar después de reconectarse, la última en dejar pasar tráfico justo antes de cortarse, y las llamadas se sienten bastante rápidas incluso con latencia.
Es muy probable que WhatsApp sea uno de los pocos servicios que realmente desplegó servidores en Australia. 200 ms parece una señal fuerte de tráfico intercontinental.
La mayoría de las empresas globales despliegan, como mucho, en tres regiones: Estados Unidos (us-east, us-central, us-east+us-east), Europa (west-europe) y, con bastante menos frecuencia, Lejano Oriente (us-west o Japón).
Por eso lugares como Sudáfrica, Sudamérica y Australia normalmente tienen que traer los datos desde una de esas regiones, y por límites físicos eso implica una latencia mínima de 200 ms.
Australia se ve especialmente afectada. Incluso si en teoría hay un despliegue dedicado en su jurisdicción, muchas veces los servidores reales están en un continente completamente distinto (la costa oeste de EE. UU. o Japón), así que los usuarios sufren directamente el impacto de rendimiento de que los paquetes den media vuelta al mundo.
Creo que, como esa perspectiva estaba profundamente integrada en sus objetivos de desarrollo, hubo razones de sobra para que WhatsApp se convirtiera en el mensajero principal en muchos países del mundo.
Cuando intento abrir una URL .jpg en el navegador para ver una imagen, tarda mucho más que pasarme a termux y ejecutar
wget, y a veces se agota el tiempo de espera. Me pasó tanto en Firefox como en navegadores basados en Chrome.Como referencia, incluso una descarga con
wgetnormalmente tarda entre 10 y 30 segundos en la conexión móvil.No entiendo por qué Berlín lo hizo así. Bastaría con ofrecer Internet dentro de los trenes.
Cuando la red se corta constantemente, la mayor parte de Internet funciona realmente mal.
Viajo mucho y el internet lento es bastante común. Ahora mismo me quedé sin datos móviles y estoy limitado a 8 kbps.
Un sitio web que solo tiene texto en la página debería ser rápido, pero muchos no lo son. Hacker News es rapidísimo, pero la documentación de Google API ni siquiera abre.
El peor problema es que la mayoría de las interfaces no contemplan solicitudes lentas. Los botones se sienten como si estuvieran rotos, y cosas que no deberían necesitar megabytes de datos tardan minutos en cargar o fallan. Toda la interfaz de Google Maps se rompe.
Ojalá los desarrolladores diseñaran y probaran más pensando en internet lento. En cambio, terminamos con sitios web devoradores de datos que solo funcionan bien en laptops corporativas rápidas y con internet rápido.
Relacionado con eso, me gano la vida operando sitios web, y pasarme a un generador de sitios estáticos fue una de las mejores decisiones en productividad. En vez de que la latencia del CMS se filtre en cada tarea, puedo editar archivos de texto rapidísimo incluso totalmente offline y, cuando vuelvo a estar en línea, solo hago push de los cambios. Cambia las reglas del juego.
Hoy en día, descargar 500 MB de caché de Google Maps en el teléfono parece no servir de nada. Igual sigue trayendo todo y apareciendo tarde.
Ahora mismo uno de mis dominios aparece marcado como “peligroso” por no usar una versión reciente de WordPress.
Básicamente, cada solicitud que se envía llega a una app de AppEngine, y esa app ejecuta código Python para devolver HTML. Por eso uno esperaría que fuera rápida, pero en la práctica no lo es.
Estoy en el Reino Unido y el ping a news.ycombinator.com es de 147 ms. Parece ser porque no usa CDN y está alojado en EE. UU.
En cambio, cloud.google.com tiene un ping de 8 ms.
Hacker News es una página simple y con poco JavaScript, pero puede haber otros factores que la hagan sentirse lenta para usuarios de ciertas regiones. Incluso en un entorno privilegiado con fibra XGS-PON simétrica de 8 Gbps.
Una vez, haciendo autostop, llevé a alguien que acababa de bajar de la capa de hielo, y me dijo que, aunque ese autor del blog escribía muy bien, se ganó cierto rechazo de la gente alrededor porque muchas veces consumía el ya limitado ancho de banda subiendo imágenes.
Aun así, según dijo, le daban prioridad porque la parte administrativa reconocía su valor promocional. Me pareció que encajaba muy bien con la discusión sobre el internet lento.
El teléfono en el bolsillo podría estar usando innecesariamente todo el ancho de banda posible, y aunque alguien esté viendo un video a 720p que apenas logra reproducirse, quien intenta cargar algo detrás quizá ni siquiera pueda ver 480p. La primera persona no se da cuenta porque tiene buffer, y la otra puede rendirse antes de que su buffer se llene lo suficiente.
Como mínimo debería haber una contabilidad de uso que te diga qué porcentaje del tráfico de la última hora fue para ti, y compararlo con el valor de referencia de ancho de banda disponible dividido entre la cantidad de usuarios conectados, para saber qué porcentaje te habría tocado si todos lo necesitaran por igual.
Más aún, parece posible un sistema que mantenga a todos en baja prioridad hasta que presionen un botón de “sí, sé cuánto ancho de banda usaré durante las próximas [X≤24] horas y realmente lo necesito”, y al hacerlo suba la prioridad QoS de su dirección MAC/IP a normal.
Situaciones así piden a gritos aplicaciones local-first y soluciones de ese tipo, que además son parte de la razón por la que se creó internet en primer lugar [1][2].
La gente cayó en el eslogan publicitario “No Software” de Salesforce, pero eso va directamente en contra de los fundamentos y el espíritu de internet. Desde 1969, durante la mayor parte de la historia de internet, los Mbps fueron la excepción, no la norma, y la primera killer app, la mensajería por email —probablemente todavía la mejor app de internet— es local-first [3].
Irónicamente, la aplicación problemática de la que se queja el autor también es una app de mensajería.
[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...
Durante varios años trabajé bastante en temas de redes y dediqué tiempo a hacer funcionar mi propio entorno de “internet lento”. No es tan interesante como McMurdo, pero he chateado y visto videos de YouTube en vuelos internacionales, trenes que pasan por lugares remotos, hoteles rurales pésimos e incluso dentro de túneles.
Si tienes acceso a un dispositivo de cómputo de propósito general, puedes costear la energía (este tipo de equipo suele consumir bastante) y estás dispuesto a armarlo tú mismo, recomiendo NNCP [1]. NNCP puede recibir datos, fragmentarlos y luego enviarlos. También incluye un protocolo de sincronización que usa noise sobre TCP, y envía reintentando los fragmentos fallidos. Como no necesita TLS, establecer la conexión solo toma 1.5 RTT.
NNCP puede alimentar datos desde la entrada estándar a un programa remoto. Armé un descargador de YouTube, un bot de Slack, un bot de Telegram y un bot de Discord para que leyeran los datos entrantes e interactuaran con esos servicios. En la máquina local tengo corriendo un servidor Matrix (Dendrite) y bots, y envío los datos al servicio remoto correspondiente mediante NNCP.
Conviene que el MTU/MSS en la ruta sea lo más bajo posible para que haya reintentos frecuentes a nivel TCP, o al menos hay que experimentar con eso, pero esta configuración casi nunca me ha fallado a donde vaya y me permite consumir medios y chatear.
Lo más molesto en vuelos internacionales es que los endpoints de NNCP no están distribuidos geográficamente. Según la ruta del vuelo y la ruta real que siguen los paquetes hasta el endpoint, la latencia y el jitter pueden aumentar mucho. Normalmente intento poner un endpoint de NNCP cerca del destino, pero en Wi‑Fi de avión la ruta real puede ser terrible. NNCP ahora tiene soporte para Yggdrasil, lo que podría mitigar esto y también ayudar a controlar problemas de MTU, pero no he usado Ygg en estas condiciones.
[1]: http://www.nncpgo.org/
En un barco en el Pacífico Sur tuve una experiencia parecida a la del autor. Había Starlink, pero no lo usábamos con frecuencia por su alto consumo de energía (más de 60 W). En cambio compramos tarjetas SIM locales y en algunos lugares usamos 4G, y en otros EDGE (2G).
EDGE en sí no es tan malo sobre el papel. Da decenas de kilobits por segundo. En la práctica fue mucho peor. Vi apps que habrían funcionado bien si solo hubieran considerado que la carga podía tardar minutos en vez de milisegundos, pero fallaban por timeouts demasiado cortos.
Las conexiones de bajo ancho de banda y alta latencia deberían formar parte de las pruebas regulares del software. En Linux existe netem (https://wiki.linuxfoundation.org/networking/netem), que permite hacerlo.
Un problema que el autor anónimo del blog no tuvo fueron las conexiones medidas por consumo. Por el costo, actualizar el sistema operativo o las apps era casi imposible. Por suerte, cada pocas semanas llegábamos a un lugar con conexión ilimitada y podíamos hacerlo. A cambio, me volví muy familiar con cómo marcar conexiones como medidas/no medidas en varios sistemas operativos, desactivar todas las actualizaciones automáticas y ahorrar ese preciado ancho de banda.
Y si dices “tarjetas SIM locales”, supongo que bajaron a alguna isla a comprarlas; me da curiosidad saber dónde en los años 2020 solo había 2G. Me cuesta creer que todavía queden lugares así en el Pacífico Sur.
Hay que mantener la perspectiva. Algunos proyectos incluso omiten probar una webapp en varios navegadores porque lo consideran un desperdicio y un costo injustificado, aunque añadirlo a la matriz de pruebas sea trivial y se trate solo de un problema de UI.
Creo que diseñar teniendo en cuenta internet lento sigue siendo realmente importante y está muy subestimado por la mayoría de los desarrolladores de software. Pero los sistemas de satélites de órbita baja (Starlink, en particular StarLink) ya resolvieron en la práctica el problema central.
En septiembre-octubre de 2023 pasé por la ruta del Ártico (de Alaska a Noruega) y, incluso en un barco muy por encima del círculo polar ártico, pude hacer videollamadas por FaceTime pese a las nubes, la distancia a tierra y el hielo. Fue en la misma época en que el autor estaba en la Antártida.
Cualquiera que haya sido la restricción, al final es cuestión del contrato de servicio y de llevar terminales al lugar. La cobertura polar es relativamente escasa, pero la población es extremadamente baja, así que aun así alcanza.
https://satellitemap.space/
“Internet lento” puede significar varias cosas, y una de ellas son los problemas de conectividad. En protocolos orientados a conexión como TCP, es lentitud por pérdida de paquetes; en protocolos de “disparar y olvidar” como UDP, significa que el mensaje no llega. Por eso, la lentitud puede ser una baja tasa de transferencia, o también una forma de cortes breves después de picos momentáneos de alto throughput.
Un enfoque robusto para lidiar con redes lentas es dar soporte a modo offline. Consiste en diseñar todos los push/pull de datos como transacciones asíncronas, y cachear localmente los envíos de datos para reintentarlos cuando sea posible. Esto genera requisitos adicionales como control de versiones y resolución de conflictos.
Naturalmente, también aumentan los requisitos de UI. Se necesita sincronización/actualización manual, indicación del estado de la red, deshabilitar acciones que no tienen sentido cuando se corta la red, precarga para que algo pueda usarse incluso sin conexión, etc.
Algún día me gustaría vivir en un mundo posterior al internet lento, pero todavía faltan varios años. Como referencia, el XS trae un módem Intel, conocido por ser inferior a los Qualcomm insignia de esa época.
Vivo en uno de los lugares con mayor densidad de población del mundo, lleno de antenas 5G y estaciones Wi‑Fi, pero todavía se nota cuando un sitio web mal hecho se cae con conexiones lentas o intermitentes.
Los satélites geoestacionarios están demasiado cerca del horizonte vistos desde el Polo, así que la cobertura polar es limitada. El Polo usa satélites geoestacionarios viejos, con poco combustible y una inclinación orbital relativamente grande; por eso solo puede comunicarse unas 6 horas de cada 24.
Horario: https://www.usap.gov/technology/1935/
Los gobiernos no van a querer una web sin censura ni que una empresa estadounidense sea la puerta de entrada a internet. Mantendrán las redes dentro del territorio que ya controlan, y el problema de la velocidad seguirá siendo válido.
También hay que considerar la cantidad de personas en todo el mundo cuyo único medio de acceso a internet es un teléfono Android de 100 dólares con software viejo y CPU limitada.
Hay una propuesta de borrador del IETF para extender HTTP con sincronización eficiente de estado, que podría mejorar la experiencia de usuario en redes lentas: https://news.ycombinator.com/item?id=40480016
Braid Protocol permite que varios algoritmos de sincronización interoperen sobre un protocolo de red común, y que los mensajes de red de cualquier sincronizador puedan traducirse a él. La especificación actual de Braid agrega dos dimensiones de sincronización a HTTP.
Nivel 0: HTTP actual
Nivel 1: suscripciones con actualizaciones push
Nivel 2: consistencia P2P (parches, versiones, merges)
Hoy los sincronizadores usan protocolos distintos, pero los mensajes de red transmiten el mismo tipo de información: versiones en el tiempo, ubicaciones en el espacio y parches de regiones espaciales a lo largo de rangos temporales. La composición de un conjunto arbitrario de parches forma una estructura matemática llamada braid: ramificaciones, merges y reordenamientos del espacio a través del tiempo.
La esperanza brota eternamente.
Reducir los round trips y hacer cosas menos infladas no es difícil; en realidad es mucho más fácil. La hinchazón existe por razones totalmente distintas.
A veces, con internet rápido cerca del data center y máquinas generosas, la hinchazón no se nota. Se puede simular fácilmente, pero la empresa tiene que preocuparse. En general, la tecnología publicitaria y su ecosistema casi no prestan atención a grupos pequeños de usuarios. De hecho, la única razón por la que les importan los usuarios finales es que generan ingresos para los clientes reales: los anunciantes.
Quienes hacemos apps, sitios web y demás debemos recordar que mucha gente no está conectada al Wi‑Fi rápido ni a la fibra que usamos nosotros.
En el Reino Unido, algunas operadoras empezaron a apagar 3G. En ciertos lugares dejan 2G como alternativa de bajo consumo, pero básicamente el mensaje es usar 4G/5G. El problema es que 4G todavía no funciona en todas partes, y hasta hace poco en algunas zonas la única señal decente era 3G.
Por eso ahora es más frecuente caer sin querer a 2G/EDGE, y muchas cosas simplemente se detienen. Muchas apps no se prueban en escenarios lentos, con alta latencia y mucha pérdida de paquetes.
Prueba buscar una ruta en Google Maps con 2G y tendrás la respuesta :(