- L’Internet du South Pole reposait sur des liaisons satellite limitées, avec une connexion disponible seulement quelques heures par jour ; en octobre 2023, les utilisateurs de la communauté devaient composer avec une forte latence, une faible bande passante et des coupures intermittentes
- Les conditions réelles combinaient une latence aller-retour d’environ 750 ms, une gigue de plusieurs secondes, des débits allant de quelques kbit/s à 2 Mbit/s, ainsi que congestion, files d’attente, pertes de paquets et préemption de service, ce qui cassait facilement les hypothèses réseau des applications courantes
- De gros bundles JavaScript, des timeouts codés en dur, l’abandon de la progression, l’invalidation du cache et des téléchargeurs intégrés non résumables faisaient partie des facteurs qui amenaient les applications à échouer d’elles-mêmes sur une liaison lente
- Si les octets continuent à circuler, même lentement, il faut attendre ; avec l’envoi par blocs, la reprise, l’affichage de l’état, des timeouts dynamiques et des liens de téléchargement manuel, de petits objectifs comme des messages texte ou des mises à jour restent atteignables
- L’Antarctique est un cas extrême, mais les navires en mer, les sites de recherche en montagne, le Wi‑Fi instable, les WISP de mauvaise qualité et les utilisateurs sur lignes téléphoniques peuvent subir des contraintes similaires ; il faut donc une conception qui ne bloque pas la progression de l’utilisateur
Contraintes de l’environnement Internet au South Pole
- Fournir Internet au South Pole est en soi un défi d’ingénierie non trivial, et les options satellite utilisables en région polaire sont limitées
- Une ressource publique existe : la page South Pole Satellite Communications
- Les difficultés liées au raccordement de l’Antarctique par fibre optique traditionnelle ont aussi été abordées lors du 2021 Antarctic Subsea Cable Workshop
- La NSF a publié une annonce concernant Starlink à McMurdo et Palmer, mais en octobre 2023 aucune annonce comparable ne concernait la South Pole Station
- Jusqu’à récemment, McMurdo partageait entre près de 1 000 personnes et de nombreuses charges de travail scientifiques et opérationnelles une bande passante agrégée de l’ordre de quelques dizaines de Mbit/s pour toute la base
- Toute la base se partageait donc moins de bande passante que ce qu’un individu peut généralement obtenir sur un réseau cellulaire 4G en banlieue américaine
- Le South Pole n’était connecté que lorsque le satellite passait au-dessus de l’horizon et que la station était autorisée à l’utiliser ; en raison de l’écart entre temps sidéral et temps solaire, les créneaux satellite avançaient généralement d’environ 4 minutes par jour
- La latence ressentie par les utilisateurs était très différente d’une expérience Internet ordinaire
- La latence aller-retour vers une destination sur le territoire continental des États-Unis était d’environ 750 ms
- Soit environ 10 fois les 75 ms maximum de latence aller-retour entre les côtes Est et Ouest des États-Unis
- Soit environ 30 fois les 25 ms maximum attendus depuis une connexion câble ou fibre domestique vers un grand CDN
- À comparer aux quelque 3 ms mesurées depuis une fibre GPON domestique vers Fastly, Cloudflare, CloudFront, Akamai et Google : le South Pole était plus de 250 fois plus élevé
Conditions réellement rencontrées par les utilisateurs de la communauté
- En octobre 2023, une personne utilisant Internet au South Pole pour des usages communautaires pouvait rencontrer les conditions suivantes
- Latence aller-retour moyenne d’environ 750 ms, avec une gigue entre paquets dépassant plusieurs secondes
- Débits côté terminal allant de quelques kbit/s jusqu’à 2 Mbit/s lors des très bons jours
- Forte congestion, mise en file d’attente et pertes de paquets
- Disponibilité limitée, coupures fréquentes et préemptions occasionnelles du service
- Dans certaines situations, on observait aussi des conditions comme 40 kbit/s, 1 000 ms de latence, jusqu’à 2 000 ms de gigue, 10 % de pertes de paquets et des coupures complètes de 15 secondes toutes les quelques minutes
- Le trafic opérationnel étant fortement prioritaire, les utilisateurs de la communauté dépendaient de la capacité restante
- Les fonctions comme la visioconférence en temps réel étaient difficiles à envisager, mais certaines applications permettaient d’envoyer et recevoir quelques octets de texte
- Une ingénierie web et applicative qui ne tient pas compte des liaisons lentes ou intermittentes dégradait encore davantage l’utilisabilité
Exemple d’une application web collaborative exigeant 20 Mo de JavaScript
- Une plateforme collaborative d’entreprise devait télécharger près de 20 Mo de JavaScript rien que pour afficher son écran principal
- Depuis la précédente connexion, l’application avait été mise à jour, tous les assets en cache du navigateur étaient périmés et devaient être retéléchargés
- Le navigateur et les protocoles gèrent dans une certaine mesure le contrôle de congestion sur Internet lent, mais cette application interrompait le chargement à cause de ses propres conditions d’échec
- Si elle n’était pas entièrement chargée dans le délai ou le nombre de tentatives fixé par les développeurs, l’application s’arrêtait
- Elle redirigeait vers une page d’erreur
- L’état du chargement déjà effectué était perdu
- Lors de la tentative suivante, une forte invalidation du cache était appliquée
- Cette application était essentiellement une application de messagerie, et une fois lancée, le contenu réellement échangé lors d’une discussion avec un ami se comptait en octets
- Les performances Internet du South Pole se situaient à la limite de ce que les développeurs avaient jugé « acceptable », et l’utilisateur devait rafraîchir plusieurs fois la page en retéléchargeant le même JavaScript
- Si le transfert nécessaire avait simplement été laissé se poursuivre, il aurait pu se terminer en moins de 15 minutes, mais en pratique il fallait parfois plusieurs heures
- Dans un cas réussi, 809 requêtes HTTP, 51,4 Mo transférés et 26,5 minutes de chargement ont abouti à un POST HTTPS de 1,8 Ko pour envoyer un message de 6 octets
- Si l’application avait été conçue pour continuer à attendre tant que les données circulaient, même lentement, elle aurait pu réduire les retransferts inutiles et le gaspillage de bande passante
Problèmes des timeouts codés en dur et des gros transferts monolithiques
- Des hypothèses fixes sur la vitesse de transmission d’une charge utile ou la quantité pouvant être envoyée dans une seule requête peuvent casser une application sur une liaison lente
- Si l’on peut mesurer que les octets circulent, mieux vaut ne pas interrompre le transfert, même très lent, et afficher la situation actuelle dans l’UI
- Si un appel HTTPS échoue, il faut réessayer avec un timeout plus long, et découper les grosses données en petits blocs
- La progression doit être suivie bloc par bloc
- Il faut pouvoir réessayer ou reprendre uniquement la petite partie qui a échoué
- Une progression incrémentale lente mais régulière est plus sûre qu’une tentative d’envoi d’un gros volume en une seule fois
- Si les appels HTTPS continuent d’échouer, au lieu de répéter aveuglément le même appel, il faut vérifier le DNS, ICMP, HTTP sans TLS, HTTPS vers un endpoint connu comme sain, etc., puis informer l’utilisateur de l’état
-
Échec du téléchargement des métadonnées au démarrage
- Une application desktop populaire téléchargeait au démarrage des informations de configuration depuis le site du fournisseur et utilisait un timeout codé en dur pour l’appel HTTPS
- Si cet appel échouait, l’application ne se chargeait pas, réessayait indéfiniment avec les mêmes paramètres, et l’écran de chargement n’indiquait pas la cause
- Au South Pole, en persistant, l’appel pouvait finir par passer, mais une seule valeur de timeout rendait une application de niveau entreprise presque inutilisable
- Un meilleur comportement aurait consisté à effectuer un repli progressif avec des timeouts plus longs, vérifier l’état de la connexion, afficher la cause, utiliser le cache ou les paramètres par défaut, et fournir un chemin de téléchargement et d’installation manuel
-
Contraste entre deux applications de chat
- Une application de chat populaire utilisait un timeout codé en dur de 10 secondes pour l’initialisation WebSocket
- Comme il faut un handshake TCP, une session TLS, la configuration WebSocket et la signalisation initiale, 10 secondes pouvaient être dépassées dans des conditions comme celles du South Pole, où chaque aller-retour prend plusieurs secondes
- Une fois le timeout dépassé, l’application cessait de fonctionner et entrait dans un long backoff, tandis que l’UX n’expliquait pas clairement la situation
- Une application de chat concurrente fonctionnait mieux même dans des conditions réseau extrêmement mauvaises
- Elle utilisait plusieurs stratégies de requêtes réseau
- Elle réutilisait activement les connexions ouvertes
- Elle ajustait dynamiquement les timeouts
- Elle choisissait intelligemment l’intervalle entre les nouvelles tentatives après un échec
- Elle affichait clairement l’état réseau actuel
- Dans les deux cas, il ne s’agissait en réalité que de transmettre quelques octets de texte brut, mais les différences d’hypothèses réseau changeaient les conditions dans lesquelles l’application restait utilisable
Transfert incrémental et uploads résumables
- brr.fyi est un blog Jekyll statique, dont les assets sont stockés dans S3 et servis par CloudFront
- Les fichiers statiques sont générés sur un ordinateur portable local
- Ils sont uploadés directement vers S3
- Il n’y a pas de serveur, d’environnement QA, de système de build, de hooks automatiques ni d’éléments dynamiques
- Le script de publication Python conçu en tenant compte des contraintes du South Pole uploadait les assets vers l’API S3 par petits blocs
- Il détectait les uploads échoués et reprenait sans perdre la progression
- Il ne publiait pas la nouvelle version tant que tous les fichiers n’étaient pas uploadés en sécurité
- Il était implémenté en environ 200 lignes de Python
- Les utilisateurs qui publiaient de gros fichiers sur des plateformes de blogging commerciales ou sur les réseaux sociaux devaient ajuster leur timing pour avoir une chance de réussir d’un seul coup pendant la fenêtre satellite
- En cas d’échec, il fallait réessayer plusieurs fois
- Il n’était pas toujours clair si le contenu avait été envoyé, si l’upload était terminé, ou s’il était possible d’appuyer à nouveau sur « Post »
- Si un POST par blocs échoue mais peut être réessayé ou repris plus tard avec une perte minimale, il devient possible d’accumuler et d’uploader quelques Ko à la fois, au moment qui convient
Critères que doit satisfaire un téléchargeur intégré
- Si une application crée son propre téléchargeur, elle doit atteindre un haut niveau de qualité ; sinon, sur Internet lent, l’expérience devient très pénible ou échoue de façon critique
- Dans la mesure du possible, l’utilisateur doit pouvoir sortir du téléchargeur intégré et récupérer directement le fichier
- Fournir un lien de téléchargement manuel est utile
- Si possible, un lien vers le fichier de patch différentiel que l’application voulait télécharger est préférable à l’installateur complet
- Les avantages d’un lien de téléchargement manuel sont clairs
- L’utilisateur peut choisir un téléchargeur plus robuste, comme celui du navigateur
- Le fichier peut être téléchargé une fois puis partagé entre plusieurs appareils
- Il peut être téléchargé depuis un autre ordinateur que celui sur lequel tourne l’application
- L’utilisateur peut planifier ou gérer le téléchargement en fonction de ses contraintes
- Comme il n’y a pas d’Internet 24 h/24 au South Pole, même avec une fenêtre quotidienne de 4 heures, si les données transférables pendant cette période sont inférieures à la taille de la charge utile, il n’existe aucun moyen de terminer en une seule fois
- Beaucoup de téléchargeurs intégrés manquent de pause/reprise, de notifications d’état, de logique de nouvelle tentative et de suivi de progression, et imposent parfois des contraintes comme une limite de temps de téléchargement ; sur Internet lent, cela détermine l’utilisabilité de toute l’application
Pourquoi le gestionnaire de téléchargements du navigateur sert de référence
- Le gestionnaire de téléchargements des navigateurs web modernes offre un niveau élevé auquel les téléchargeurs intégrés seront inévitablement comparés
- Interruption, pause et reprise
- Nouvelle tentative après un téléchargement échoué
- Affichage de l’état actuel, de la vitesse et du temps restant
- Choix de l’emplacement d’enregistrement et possibilité de copier le fichier
- Absence de coupure arbitraire liée aux performances
- Même si un utilisateur veut télécharger un fichier de plusieurs Go à 60 kbit/s, le navigateur l’autorise
- Si une application ne peut pas implémenter des fonctionnalités au niveau du navigateur, il vaut au moins mieux fournir l’URL d’origine pour que l’utilisateur puisse télécharger avec son navigateur
Exemple des mises à jour macOS
- Les mises à jour macOS étaient particulièrement lourdes au South Pole
- La taille des patchs de mises à jour mineures de l’OS est généralement de 0,5 à 1,5 Go
- Les patchs de mises à niveau majeures de l’OS dépassent parfois 6 Go
- Des outils supplémentaires comme Xcode pèsent souvent plusieurs Go
- Si chaque appareil macOS télécharge directement ses mises à jour depuis Apple, la bande passante est fortement gaspillée
- Le programme de mise à jour intégré de macOS offrait peu de contrôle, et il n’existait pas de moyen simple d’obtenir les fichiers de patch sous-jacents
- En cas d’annulation ou d’échec, il ne reprenait pas toujours intelligemment et la progression pouvait être perdue
- La fonction de serveur de cache macOS d’Apple pouvait en théorie réduire la charge en ne téléchargeant chaque patch qu’une seule fois vers le South Pole
- En pratique, chaque MacBook client devait réussir un appel HTTPS vers Apple pour négocier les paramètres de cache
- Si cet appel échouait, le Mac client téléchargeait directement le patch depuis les serveurs publics d’Apple, sans notification ni nouvelle tentative
- Au South Pole, cet appel de négociation initial échouait souvent, ce qui rendait le cache peu utile
- Les installateurs complets pouvaient être téléchargés depuis Apple via les liens rassemblés sur Mr. Macintosh, puis distribués localement sur la base après un téléchargement lent mais soigneusement géré
- L’installateur complet pesait 12 Go, et le téléchargement pouvait prendre plusieurs jours, mais il était fiable
- Même lorsqu’ils étaient mis à jour avec l’installateur complet, les Mac Apple Silicon tentaient encore de télécharger directement depuis Apple 1 à 2 Go de contenu supplémentaire, comme des mises à jour de firmware ou de Rosetta
- Il n’existait pas de moyen de contourner ou de mettre en cache cela
- Le téléchargement passait parfois à un composant distinct de macOS, sans que la progression apparaisse dans l’UI d’installation
- Un écran indiquant « 32 minutes restantes » pouvait rester affiché pendant des heures pendant qu’1 Go se téléchargeait en arrière-plan
- Il fallait fournir les liens de patch nécessaires, renforcer pause/reprise et gestion de l’état, inclure les éléments supplémentaires pour Apple Silicon dans l’installateur complet, et améliorer la fiabilité ainsi que le contrôle du serveur de cache
Exemple des mises à jour d’OS Samsung Android
- L’outil de mise à jour de l’OS des téléphones Samsung Android illustrait un cas ne tenant pas compte d’un Internet lent ou intermittent
- L’UI de mise à jour n’affichait ni vitesse, ni progression chiffrée, ni pause, ni annulation, ni taille de fichier, ni moyen d’accéder au fichier pour un téléchargement séparé
- Si le téléchargement échouait, il ne pouvait pas être repris et recommençait depuis le début
- Au South Pole, il était impossible de télécharger toute la mise à jour de l’OS lors d’un seul passage satellite ; lorsque la connexion se coupait, l’échec était inévitable et il fallait repartir de zéro
- En pratique, la solution consistait à éteindre complètement le téléphone juste avant la coupure d’Internet, puis à le rallumer au passage satellite suivant pour éviter que le téléchargement soit marqué comme échoué
- Cette méthode permettait de répartir le téléchargement sur plusieurs passages satellite
- Ce contournement était une solution anormale qui ne devrait pas être nécessaire
- L’application de mise à jour Verizon pour macOS et Windows permet théoriquement de flasher la mise à jour de l’OS depuis un ordinateur, mais en pratique elle était très boguée, peu fiable et utilisait son propre téléchargeur intégré
- Le cœur du problème est que les outils grand public fournis par les fabricants offrent des fonctionnalités insuffisantes aux utilisateurs disposant d’un Internet lent
Contraste entre de petites mises à jour d’applications et Microsoft Office for Mac
- Le téléchargeur intégré d’une petite application desktop manquait des fonctionnalités de base nécessaires sur une liaison lente
- Bouton pause
- Bouton annuler
- Affichage de la progression
- Affichage de la vitesse ou du temps restant
- Accès à l’URL d’origine
- Suivi de la progression et reprise naturelle d’un téléchargement interrompu
- Un simple lien de téléchargement manuel aurait déjà nettement amélioré l’expérience des utilisateurs du South Pole pour cette application
- Le téléchargeur automatique d’une autre application proposait un bouton d’annulation et une barre de progression visuelle, mais manquait de pause, de progression chiffrée, de vitesse, d’accès à l’URL d’origine et de reprise
- Le téléchargeur automatique de Microsoft Office for Mac était un bon exemple même au South Pole
- Bouton pause
- Bouton annuler
- Affichage de la progression
- Affichage de la vitesse et du temps restant
- Reprise naturelle d’un téléchargement interrompu
- Il aurait été encore meilleur avec l’URL d’origine, mais son interface était suffisamment bonne pour rester utilisable au South Pole
Principes pratiques de conception pour les utilisateurs d’Internet lent
- Des fonctionnalités qui semblent être de petits manques sur Internet rapide peuvent devenir des obstacles majeurs sur Internet lent
- Une application doit être conçue pour éviter qu’un seul timeout fixe enferme l’utilisateur dans une boucle où il ne peut même pas envoyer quelques octets de texte
- Les principes possibles sont simples
- Ne pas interrompre tant que les octets circulent
- Découper les grosses charges utiles en blocs
- Préserver la progression même en cas d’échec
- Afficher clairement l’état réseau à l’utilisateur
- Si le téléchargeur intégré est insuffisant, fournir un lien de téléchargement manuel
- Le South Pole est un cas limite, mais des contraintes similaires peuvent toucher les environnements Inmarsat de navires en mer, Thales MissionLink et Iridium Certus sur des sites de recherche en montagne, le Wi‑Fi instable, les routeurs mal configurés, les WISP de mauvaise qualité ou encore les utilisateurs d’accès commuté sur d’anciennes lignes téléphoniques
- Les développeurs n’ont pas besoin d’optimiser tous les scénarios extrêmes, mais ils doivent faire l’effort d’éviter que leur produit n’empêche activement la progression des utilisateurs sur connexions lentes
1 commentaires
Commentaires Hacker News
Cet article me parle beaucoup. Je ne suis pas en Antarctique, mais à Pékin, et Internet me fait encore souffrir
Derrière le Grand Firewall, il faut recourir à des méthodes créatives, et les VPN ne fonctionnent que par intermittence. Chaque VPN laisse des traces, si bien que les heuristiques et le machine learning du pare-feu finissent par les détecter ; même les VPN autorisés par l’État sont « doucement » restreints lors des périodes politiquement sensibles
Au final, même quand on est connecté, ce n’est pas stable, et c’est très pénible de gaspiller de précieux paquets dans des allers-retours inutiles de webapps/React
Certains développeurs devraient faire un voyage dans le temps vers 2005 et développer selon les critères de l’époque pour apprendre à faire léger. À défaut de voyage dans le temps, j’aimerais vraiment qu’ils activent la limitation de débit dans les outils de développement, la règlent sur 3G, puis vérifient si leur webapp tient le coup
Je teste toujours les projets avec une bande passante limitée. Comme pour l’accessibilité, suivre les bonnes pratiques améliore l’expérience utilisateur pour tout le monde, pas seulement pour les personnes avec une mauvaise connexion
Une autre occasion souvent manquée consiste à concevoir les applications single-page en offline-first
Je ne m’oppose pas forcément à l’idée générale, mais le JavaScript moderne est en réalité plutôt bon pour gérer un Internet lent dans des « applications » serveur-client. Ce n’est simplement pas facile, et il existe très peu de ressources en ligne sur lesquelles quelqu’un qui code avec Google/GPT pourrait s’appuyer comme base de projet
C’est en partie dû au fait qu’il y a énormément de mauvais contenus JavaScript en ligne, mais aussi au fait que les organisations qui travaillent ainsi ne partagent pas. Nous-mêmes n’avons aucune raison de donner des informations à nos concurrents, donc il y a 0 ressource publique sur notre façon de travailler
C’est un entraînement intéressant pour réduire les allers-retours inutiles dans des technologies qui s’attendent à en faire pour tout
J’obtiens encore environ 1 à 10 Mbit/s, et cela dépend surtout de l’heure ; je n’ai quasiment pas de problèmes de connexion
Ayant beaucoup d’expérience des trajets en transports souterrains (intermittents et saturés), et ayant vécu et travaillé en Australie, je peux dire avec assurance que la plupart des services sont médiocres pour les personnes qui ne bénéficient pas de conditions réseau « idéales »
Dans le London Underground, il est particulièrement frappant de voir à quel point la plupart des apps gèrent mal un réseau qui se coupe puis revient environ toutes les 2 minutes. Il disparaît entre les stations, et comme un train de 500 passagers essaie de se connecter en même temps, se connecter à chaque point d’accès prend aussi environ 15 secondes
En Australie, on est globalement à 200 ms de partout. Ça peut paraître anodin, mais cela révèle très bien quelles apps trébuchent sur des problèmes de requêtes N+1
La seule app qui m’impressionne toujours est WhatsApp. C’est la première à refonctionner après une reconnexion, la dernière à laisser passer du trafic juste avant une coupure, et les appels semblent assez rapides même avec de la latence
WhatsApp est probablement l’un des rares services à avoir réellement déployé des serveurs en Australie. 200 ms ressemblent fortement à un signal de trafic intercontinental
La plupart des entreprises mondiales déploient au mieux dans trois régions : les États-Unis (us-east, us-central, us-east+us-east), l’Europe (west-europe) et, plus rarement, l’Extrême-Orient (us-west ou Japon)
Ainsi, des endroits comme l’Afrique du Sud, l’Amérique du Sud et l’Australie doivent généralement récupérer leurs données depuis l’une de ces régions, ce qui impose au minimum 200 ms de latence en raison des limites physiques
L’Australie est particulièrement touchée. Même lorsqu’il existe en théorie un déploiement dédié dans la juridiction, les serveurs réels se trouvent souvent sur un tout autre continent (côte ouest des États-Unis ou Japon), et les utilisateurs subissent donc pleinement l’impact sur les performances de paquets qui font la moitié du tour du monde
Comme cette perspective était profondément intégrée à ses objectifs de développement, je pense que cela explique largement pourquoi WhatsApp est devenu la messagerie de référence dans de nombreux pays
Quand j’ouvre une URL .jpg dans le navigateur pour voir une image, cela prend beaucoup plus longtemps que de passer par termux et d’exécuter
wget, et parfois ça finit en timeout. Je l’ai constaté à la fois dans Firefox et dans les navigateurs de la famille ChromeÀ titre de référence, même un téléchargement avec
wgetprend généralement 10 à 30 secondes sur une connexion mobileJe ne comprends pas pourquoi Berlin a fait ça. Il suffirait de fournir Internet dans les trains
Quand le réseau se coupe en permanence, la plupart d’Internet fonctionne vraiment très mal
Je voyage beaucoup et l’Internet lent est assez courant. En ce moment encore, j’ai épuisé mon forfait de données mobiles et je suis limité à 8 kb/s
Les sites web qui ne contiennent que du texte sur la page devraient être rapides, mais beaucoup ne le sont pas. Hacker News est ultra-rapide, mais la documentation des API Google ne s’ouvre même pas
Le pire problème, c’est que la plupart des UI ne prennent pas en compte les requêtes lentes. Les boutons donnent l’impression d’être cassés, et des choses qui ne devraient pas nécessiter des mégaoctets de données prennent plusieurs minutes à charger, ou échouent. Toute l’UI de Google Maps se désagrège
J’aimerais que les développeurs conçoivent et testent davantage pour l’Internet lent. À la place, on obtient des sites web voraces en données qui ne fonctionnent bien que sur des ordinateurs portables d’entreprise rapides et avec une connexion rapide
À ce sujet, je gagne ma vie en exploitant des sites web, et passer à un générateur de site statique a été l’une des meilleures décisions en termes de productivité. Au lieu que la latence du CMS s’infiltre dans chaque tâche, je peux modifier très rapidement des fichiers texte même totalement hors ligne, puis pousser seulement les changements quand je suis de nouveau en ligne. Ça change la donne
Aujourd’hui, même télécharger 500 Mo de cache Google Maps sur son téléphone ne semble servir à rien. Il va quand même tout récupérer, et les éléments apparaissent en retard
L’un de mes domaines est actuellement signalé comme « dangereux » parce que je n’utilisais pas une version récente de WordPress
En gros, chaque requête envoyée atteint une app AppEngine, qui exécute du code Python pour renvoyer du HTML. On pourrait donc penser que ce serait rapide, mais en pratique ça ne l’est pas
Je suis au Royaume-Uni, et j’ai un ping de 147 ms vers news.ycombinator.com. Cela semble dû au fait qu’il n’utilise pas de CDN et est hébergé aux États-Unis
En revanche, cloud.google.com a un ping de 8 ms
Hacker News est une page simple avec peu de JavaScript, mais d’autres facteurs peuvent la rendre lente pour certains utilisateurs selon leur région. Même dans un environnement privilégié avec une connexion fibre XGS-PON offrant 8 Gb/s symétriques
J’ai une fois pris en stop quelqu’un qui venait tout juste de descendre de la calotte glaciaire, et il disait que l’auteur de ce blog écrivait très bien, certes, mais qu’il s’était attiré une certaine inimitié des gens autour de lui parce que ses téléversements d’images consommaient souvent une bande passante déjà limitée
Cela dit, l’administration avait compris sa valeur promotionnelle, donc il bénéficiait d’une priorité. J’ai trouvé que ça s’inscrivait bien dans la discussion sur l’Internet lent
Le téléphone dans votre poche peut utiliser inutilement toute la bande passante disponible, et même si vous regardez une vidéo en 720p qui arrive tout juste à se lire, la personne qui essaie de charger quelque chose derrière vous peut ne même pas pouvoir regarder du 480p. Vous ne vous en rendez pas compte parce que vous avez du buffer, tandis que l’autre peut abandonner avant d’en avoir accumulé assez
Il faudrait au minimum une comptabilité d’usage indiquant quel pourcentage du trafic de la dernière heure vous a été attribué, et, par rapport à une valeur de référence calculée en divisant la bande passante disponible par le nombre d’utilisateurs connectés, quel aurait été votre pourcentage si tout le monde avait eu des besoins équivalents
On pourrait même imaginer un système où tout le monde reste en basse priorité jusqu’à appuyer sur un bouton du type « Oui, je sais quelle bande passante je vais utiliser pendant les [X≤24] prochaines heures et j’en ai réellement besoin », ce qui ferait alors remonter la priorité QoS de son adresse MAC/IP à la normale
Ce genre de situation appelle clairement des applications local-first et des solutions de ce type, et c’est d’ailleurs l’une des raisons pour lesquelles Internet a été créé au départ [1][2]
Les gens se sont fait avoir par le slogan publicitaire « No Software » de Salesforce, alors qu’il va frontalement à l’encontre des fondations et de l’esprit d’Internet. Depuis 1969 et pendant la majeure partie de l’histoire d’Internet, les débits en Mbps ont été l’exception, pas la norme, et la première killer app, la messagerie électronique — probablement encore aujourd’hui la meilleure application d’Internet — est local-first [3]
Ironie du sort, l’application problématique que déplore l’auteur est elle aussi une app de messagerie
[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...
Pendant des années, j’ai beaucoup travaillé sur le réseau, et j’ai passé du temps à faire fonctionner mon propre environnement d’« Internet lent ». Ce n’est pas aussi fascinant que McMurdo, mais j’ai pu discuter et regarder des vidéos YouTube dans des vols internationaux, des trains traversant des régions isolées, des hôtels ruraux médiocres, et même dans des tunnels.
Si vous avez accès à un appareil de calcul polyvalent, que vous pouvez assumer l’alimentation électrique (ce genre de matériel a tendance à beaucoup consommer) et que vous êtes prêt à le monter vous-même, je recommande NNCP [1]. NNCP peut recevoir des données, les découper en morceaux, puis les envoyer. Il inclut aussi un protocole de synchronisation utilisant noise par-dessus TCP, qui envoie les morceaux en réessayant ceux qui ont échoué. Comme il n’a pas besoin de TLS, l’établissement de connexion ne coûte que 1,5 RTT.
NNCP peut fournir des données via l’entrée standard à un programme distant. J’ai créé un téléchargeur YouTube, des bots Slack, Telegram et Discord qui lisent les données entrantes et interagissent avec les services correspondants. Sur la machine locale, je fais tourner un serveur Matrix (Dendrite) et des bots, et j’envoie les données au service distant approprié via NNCP.
Il faut souhaiter, ou tester, que le MTU/MSS sur le trajet soit aussi bas que possible afin que les retransmissions au niveau TCP puissent se produire fréquemment, mais cette configuration m’a presque toujours évité les échecs où que j’aille, et m’a permis de consommer des médias et de discuter.
Le plus agaçant sur les vols internationaux, c’est que les endpoints NNCP ne sont pas répartis géographiquement. Selon la trajectoire du vol et le chemin réellement emprunté par les paquets jusqu’à l’endpoint, la latence et la gigue peuvent fortement augmenter. En général, j’essaie de placer un endpoint NNCP près de la destination, mais avec le Wi‑Fi à bord, le routage réel peut être très mauvais. NNCP prend désormais en charge Yggdrasil, ce qui pourrait atténuer ce problème et aider aussi à contrôler les soucis de MTU, mais je n’ai jamais utilisé Ygg dans ces conditions.
[1]: http://www.nncpgo.org/
J’ai vécu une expérience similaire à celle de l’auteur sur un bateau dans le Pacifique Sud. Il y avait Starlink, mais nous l’utilisions rarement à cause de sa forte consommation électrique (plus de 60 W). À la place, nous achetions des cartes SIM locales et utilisions la 4G à certains endroits, EDGE (2G) à d’autres.
Sur le papier, EDGE en soi n’est pas si mauvais. On obtient quelques dizaines de kilobits par seconde. En pratique, c’était bien pire. J’ai vu des applications qui auraient bien fonctionné si elles avaient simplement tenu compte du fait que le chargement pouvait prendre des minutes plutôt que des millisecondes, échouer à cause de timeouts trop courts.
Les connexions à faible bande passante et forte latence devraient faire partie des tests réguliers des logiciels. Sous Linux, netem (https://wiki.linuxfoundation.org/networking/netem) permet de le faire.
Un problème que l’auteur du blog anonyme n’avait pas était celui des connexions facturées à l’usage. À cause du coût, les mises à jour du système d’exploitation ou des applications étaient quasiment impossibles. Heureusement, toutes les quelques semaines, nous arrivions dans un endroit avec une connexion illimitée et pouvions faire ce genre d’opérations. En contrepartie, je suis devenu très familier avec la manière de marquer une connexion comme limitée ou non limitée sur plusieurs systèmes d’exploitation, de désactiver toutes les mises à jour automatiques et d’économiser une bande passante précieuse.
Et si vous parlez de « cartes SIM locales », cela veut dire que vous débarquiez sur une île pour les acheter ; je me demande donc où, dans les années 2020, on ne trouvait que de la 2G. J’ai du mal à croire qu’il reste encore de tels endroits dans le Pacifique Sud.
Il faut garder le sens des proportions. Certains projets sautent même les tests d’une web app sur plusieurs navigateurs, en considérant que c’est une perte de temps et un coût injustifié, alors que l’ajouter à la matrice de tests est trivial et ne concerne que l’UI.
L’ingénierie qui tient compte d’un Internet lent reste vraiment importante, et me semble très largement sous-estimée par la plupart des développeurs logiciel. Mais les systèmes de satellites en orbite basse (Starlink, en particulier StarLink) ont désormais, de fait, résolu le problème central.
En septembre-octobre 2023, j’ai emprunté la route arctique (de l’Alaska à la Norvège) et, même sur un navire très au nord du cercle polaire, malgré les nuages, la distance à la terre et la glace, j’ai pu passer des appels vidéo FaceTime. C’était à la même période que celle où l’auteur se trouvait en Antarctique.
Quelle qu’ait été la contrainte, au final, c’est une question de contrat de service et d’acheminement d’un terminal sur place. La couverture polaire est relativement clairsemée, mais comme la population y est extrêmement faible, elle reste suffisante.
https://satellitemap.space/
Un Internet lent peut vouloir dire plusieurs choses, dont l’une est un problème de connectivité. Avec des protocoles orientés connexion comme TCP, cela signifie des ralentissements dus à la perte de paquets ; avec des protocoles du type « envoyer et oublier » comme UDP, cela signifie que le message n’arrive pas. La lenteur peut donc être un faible débit, ou bien une forme de coupures brèves après des pics de débit momentanés.
Une approche robuste pour gérer les réseaux lents consiste à prendre en charge un mode hors ligne. Il s’agit de concevoir tous les push/pull de données comme des transactions asynchrones, et de mettre en cache localement les push de données pour réessayer quand c’est possible. Cela entraîne des exigences supplémentaires, comme la gestion des versions et la résolution des conflits.
Naturellement, les exigences côté UI augmentent aussi : synchronisation/actualisation manuelle, indication de l’état du réseau, désactivation des actions dénuées de sens quand le réseau est coupé, préchargement pour que l’application reste utilisable hors ligne, etc.
J’aimerais un jour vivre dans le monde d’après l’Internet lent, mais il reste encore plusieurs années. À noter que le XS embarquait un modem Intel, réputé inférieur aux fleurons Qualcomm de l’époque.
Je vis dans l’un des endroits les plus densément peuplés au monde, avec des antennes 5G et des bornes Wi‑Fi partout, mais je ressens toujours le fait que des sites web mal conçus s’écroulent dès que la connexion est lente ou intermittente.
Les satellites géostationnaires sont trop proches de l’horizon au pôle, ce qui limite la couverture polaire. Le pôle utilise de vieux satellites géostationnaires avec peu de carburant et une inclinaison orbitale relativement élevée, ce qui fait qu’il ne peut communiquer qu’environ 6 heures sur 24.
Planning : https://www.usap.gov/technology/1935/
Les gouvernements ne voudront pas d’un web non censuré, ni qu’une entreprise américaine devienne la passerelle Internet. Ils conserveront les réseaux dont ils disposent sur leur territoire, et la question de la vitesse restera pertinente.
Il faut aussi tenir compte, dans le monde entier, du nombre de personnes dont le seul moyen d’accéder à Internet est un téléphone Android à 100 dollars, avec des logiciels obsolètes et un CPU limité.
Il existe une proposition de brouillon IETF visant à étendre HTTP pour une synchronisation d’état efficace, afin d’améliorer l’expérience utilisateur sur les réseaux lents : https://news.ycombinator.com/item?id=40480016
Braid Protocol permet à plusieurs algorithmes de synchronisation d’interopérer sur un protocole réseau commun, et les messages réseau de n’importe quel synchroniseur peuvent être traduits dessus. La spécification actuelle de Braid ajoute deux dimensions de synchronisation à HTTP.
Niveau 0 : HTTP aujourd’hui
Niveau 1 : abonnements avec mises à jour push
Niveau 2 : cohérence P2P (patchs, versions, fusion)
Les synchroniseurs actuels utilisent des protocoles différents, mais leurs messages réseau transportent le même type d’informations : une version dans le temps, une position dans l’espace, et un patch d’une région spatiale sur un intervalle de temps. La composition d’un ensemble arbitraire de patchs forme une structure mathématique appelée braid : des embranchements, fusions et réordonnancements de l’espace au fil du temps.
L’espoir jaillit éternellement.
Réduire les allers-retours et construire des choses moins boursouflées n’est pas difficile ; c’est même bien plus simple. La lourdeur existe pour de tout autres raisons.
Parfois, avec un Internet rapide près des datacenters et des machines généreusement dimensionnées, cette lourdeur ne se voit pas. On peut facilement la simuler, mais il faut que l’entreprise s’en préoccupe. En général, l’adtech et tout ce qui gravite autour s’intéressent très peu aux petits groupes d’utilisateurs. En réalité, la seule raison de s’intéresser aux utilisateurs finaux est qu’ils génèrent du chiffre d’affaires pour les vrais clients : les annonceurs.
Nous qui créons des apps, des sites web, etc., devons nous rappeler que beaucoup de gens ne sont pas connectés au Wi‑Fi rapide ou à la fibre que nous utilisons.
Au Royaume-Uni, certains opérateurs ont commencé à arrêter la 3G. Certains conservent la 2G comme solution de secours basse consommation, mais l’idée est désormais de passer à la 4G/5G. Le problème, c’est que la 4G n’est pas encore disponible partout, et que jusqu’à récemment, dans certaines zones, seul le signal 3G était correct.
On retombe donc plus souvent, sans le vouloir, en 2G/EDGE, et beaucoup de choses se bloquent tout simplement. Beaucoup d’apps ne sont pas testées dans des scénarios lents, à forte latence et avec beaucoup de perte de paquets.
Essayez de trouver votre chemin avec Google Maps en 2G, et vous comprendrez :(