Auteur Sujet: Antarctique & satellite : comment rendre l'internet lent utilisable (brr.fyi)  (Lu 840 fois)

0 Membres et 1 Invité sur ce sujet

MaxLebled

  • Abonné Free fibre
  • *
  • Messages: 309
  • Vannes (56)
    • Site web
Un super blog, que je recommande de parcourir, vient de publier un article très intéressant, en anglais : https://brr.fyi/posts/engineering-for-slow-internet

Je vous fais un résumé vite fait :

L'auteur a travaillé sur la gestion SI d'une base en Antarctique. Là-bas, Internet, c'est par satellite, et il n'y a qu'une très faible bande passante (quelques douzaines de mégabits) pour les usages non-scientifiques de presque 1 000 personnes. D'ailleurs, il n'y a même pas de satellite joignable tout court la plupart du temps. La connexion moyenne en bout de chaîne pour un appareil : 750 ms de latence, et entre 2 Kbps (oui, vraiment) et 2 Mbps (avec beaucoup de chance), avec congestion extrême et beaucoup de pertes de paquets.

Avec ce genre de connexion, on s'aperçoit très vite des présuppositions faites par certaines applications, qui les rendent très difficilement utilisables :

  • 20 Mo de Javascript inévitables pour une appli de discussion, mais leur téléchargement bloque complètement si la connexion tousse pendant quelques secondes... et aucune mise en cache de ce qui était déjà téléchargé
  • Timeouts hardcodés
  • Téléchargements de mises à jour sans bouton pause, sans possibilité de reprendre un téléchargement qui échoue en cours de route, sans aucune information
  • etc.

L'auteur a écrit une longue liste de recommandations afin de rendre les connexions (très) lentes et instables compatibles avec ces applications. J'imagine qu'elles sont également très pertinentes vis-à-vis de l'internet mobile avec de mauvaises conditions radio, ou dans des pays en voie de développement.

pju91

  • Abonné Free fibre
  • *
  • Messages: 891
  • 91
Ca me rappelle le client, au début des années 90, qui se plaignait de la lenteur d'une application "client - serveur" sur un réseau local (à l'époque Ethernet 10 Mbits/s).
A l'analyseur de réseau, il était évident que des tables Oracle entières étaient transférées du serveur vers le client, pour un traitement local sur le poste de travail.
Le développeur avait utilisé je ne sais quel outil de développement qui avait masqué les aspects de bas niveau (dont les transferts de données réellement effectués).
Je pense que c'est pareil pour toutes les catégories d'application évoquées dans cet article de brr.fyi, pour lesquelles les "développeurs" qui n'ont pas de connaissance "infrastructure", s'appuient sur des frameworks dont ils ne maîtrisent pas les subtilités de configuration.
« Modifié: 31 mai 2024 à 22:11:56 par pju91 »

trekker92

  • Abonné Free adsl
  • *
  • Messages: 1 065
  • 20 Mo de Javascript inévitables pour une appli de discussion, mais leur téléchargement bloque complètement si la connexion tousse pendant quelques secondes... et aucune mise en cache de ce qui était déjà téléchargé


https://tonsky.me/blog/js-bloat/
31MB pour linkedin. 55 pour Slack. Belles références pour un si lourd casier!
Webconnerie 8.0 quand tu nous tiens.

« Modifié: 01 juin 2024 à 18:25:29 par Hugues »

MaxLebled

  • Abonné Free fibre
  • *
  • Messages: 309
  • Vannes (56)
    • Site web
J'ai été informé par une connaissance que les missions scientifiques utilisent de plus en plus le protocole DTN : https://www.nasa.gov/communicating-with-missions/delay-disruption-tolerant-networking/ (RFC ici : https://www.rfc-editor.org/rfc/rfc9171.html )

Bien entendu ça n'est pas quelque chose d'utilisable ou d'utilisé pour se relier à l'internet public, donc les bases resteront avec du bon vieux TCP/IP.

ericse

  • Abonné Free fibre
  • *
  • Messages: 414
Dans le temps on utilisait un proxy/cache pour compenser le faible débit d'une connexion mutualisée, mais https a tué cette solution technique sans en proposer une alternative.

vivien

  • Administrateur
  • *
  • Messages: 47 561
    • Twitter LaFibre.info
Les exigences sur la confidentialité ont bien évolués (et l'usage que l'on fait d'internet aujourd'hui révèle bien plus de nous qu'il y a 10 ans).

ericse

  • Abonné Free fibre
  • *
  • Messages: 414
Oui https est indispensable pour toutes les données personnalisées, mais l'auteur de l'article se plaint des Mo de javascripts qui sont totalement banalisés et pourraient être sortis du flux chiffré sans aucun problème de confidentialité (au besoin en les signant pour éviter les modifications). Le standard https aurait pu prévoir ce cas de figure, mais je pense que sa généralisation est intervenue après coup et n'était pas prévue initialement.

Paradoxalement, aujourd'hui il aurait une meilleure qualité de connexion en utilisant une machine de rebond, en télémaintenance, car bien que léger initialement, HTML est devenu un protocole lourd avec ses JS et images. D'ailleurs Opera a eu un browser pour mobile (Opera Mini) utilisant un serveur pour compresser fortement les pages HTML avant de les envoyer au téléphone, ça marchait plutôt bien, quelqu'un s'en souvient ?

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 536
  • Lyon (69) / St-Bernard (01)
    • Twitter
J'ai fait le ménage sur toutes les digressions et autres trolls posés sur ce sujet.

N'oubliez pas que nous sommes sur un forum technique et pas sur votre blog personnel, vos petites opinions on s'en fiche un peu.. :)

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 6 047
Dans le temps on utilisait un proxy/cache pour compenser le faible débit d'une connexion mutualisée, mais https a tué cette solution technique sans en proposer une alternative.
On faisait même des serveurs e-mails relais locaux, qui recevaient les e-mails dans la bande passante inutilisée d'une petite connexion mutualisée, même quand l'ordinateur client étai éteint. Idem pour l'envoi d'e-mails : on faisait croire à l'utilisateur qu'il avait bien envoyé son e-mail, alors qu'il était simplement dans un serveur relais local. C'était à l'époque des e-mails non chiffrés.

Paradoxalement, aujourd'hui il aurait une meilleure qualité de connexion en utilisant une machine de rebond, en télémaintenance, car bien que léger initialement, HTML est devenu un protocole lourd avec ses JS et images. D'ailleurs Opera a eu un browser pour mobile (Opera Mini) utilisant un serveur pour compresser fortement les pages HTML avant de les envoyer au téléphone, ça marchait plutôt bien, quelqu'un s'en souvient ?
Les smartphones sous Symbian-OS utilisaient tous ça, et ça fonctionnait vraiment bien, je confirme, même avec les 300kb/s poussifs d'une connexion 3G.
Par contre, ça posait des questions sur l'intégrité et la confidentialité des données...

Leon.

MaxLebled

  • Abonné Free fibre
  • *
  • Messages: 309
  • Vannes (56)
    • Site web
D'ailleurs Opera a eu un browser pour mobile (Opera Mini) utilisant un serveur pour compresser fortement les pages HTML avant de les envoyer au téléphone, ça marchait plutôt bien, quelqu'un s'en souvient ?

J'utilisais énormément ça au lycée sur mon téléphone à clapet et ses applis en J2ME, avec un forfait 500 Mo M6 Mobile (MNVO Orange)... ça fonctionnait super bien ! Mais le Javascript était exécuté côté proxy, et uniquement pendant 2 secondes, donc il y avait des sites qui étaient cassés. Primitif aujourd'hui, mais pour l'époque, ça fonctionnait très bien. Je me demande si ça serait toujours d'une quelconque utilité avec les sites d'aujourd'hui, que ça soit pour ceux sur un forfait éco (50 Mo - 1 Go), ou ceux coincés en Antarctique :)

pju91

  • Abonné Free fibre
  • *
  • Messages: 891
  • 91
On faisait même des serveurs e-mails relais locaux, qui recevaient les e-mails dans la bande passante inutilisée d'une petite connexion mutualisée, même quand l'ordinateur client étai éteint. Idem pour l'envoi d'e-mails : on faisait croire à l'utilisateur qu'il avait bien envoyé son e-mail, alors qu'il était simplement dans un serveur relais local. C'était à l'époque des e-mails non chiffrés.
Si tu te souviens bien, avant même SMTP (et les relais ouverts que tu évoques), il y avait uucp qui permettait d'acheminer des mails en profitant d'un chemin passant par des machines "mieux" connectées. Ca expliquait en particulier la complexité de la configuration du redouté sendmail.cf. Voir par exemple cet HOWTO.