- Das Internet am South Pole war auf begrenzte Satellitenverbindungen angewiesen und nur einige Stunden pro Tag verfügbar; Stand Oktober 2023 mussten Community-Nutzer hohe Latenz, geringe Bandbreite und sporadische Ausfälle hinnehmen
- Unter realen Bedingungen lagen die Round-Trip-Latenzen bei etwa 750 ms, der Jitter bei mehreren Sekunden, die Geschwindigkeiten zwischen einigen kbps und 2 Mbps; dazu kamen Überlastung, Queueing, Paketverluste und Vorrang für andere Dienste, wodurch die Netzwerkannahmen gewöhnlicher Apps leicht zusammenbrachen
- Große JavaScript-Bundles, hart codierte Timeouts, verworfene Fortschritte, Cache-Invalidierung und nicht fortsetzbare eingebaute Downloader führten dazu, dass Apps auf langsamen Verbindungen von selbst scheiterten
- Wenn Bytes – wenn auch langsam – weiterfließen, sollte man warten; mit Chunk-Übertragung, Fortsetzen, Statusanzeigen, dynamischen Timeouts und manuellen Download-Links lassen sich kleine Ziele wie Textnachrichten oder Updates dennoch erreichen
- Die Antarktis ist ein Extremfall, aber auch Schiffe auf See, Forschungsstationen im Gebirge, instabiles Wi‑Fi, minderwertige WISPs und Zugänge über Telefonleitungen können ähnliche Einschränkungen haben; deshalb braucht es Designs, die den Fortschritt der Nutzer nicht behindern
Einschränkungen der Internetumgebung am South Pole
- Schon die Bereitstellung von Internet am South Pole ist eine nicht triviale technische Aufgabe, und die Auswahl nutzbarer Satelliten in Polarregionen ist begrenzt
- Als öffentliche Quelle gibt es die Seite South Pole Satellite Communications
- Die Schwierigkeiten, traditionelle Glasfaserkabel bis zum antarktischen Kontinent zu verlegen, wurden auch im 2021 Antarctic Subsea Cable Workshop behandelt
- Die NSF veröffentlichte eine Mitteilung zu Starlink bei McMurdo und Palmer, aber Stand Oktober 2023 gab es keine vergleichbare Ankündigung für die South Pole Station
- McMurdo teilte sich bis vor Kurzem mit fast 1.000 Menschen sowie diversen wissenschaftlichen und operativen Workloads eine aggregierte Bandbreite von nur einigen Dutzend Mbps für die gesamte Station
- Die gesamte Basis teilte sich also weniger Bandbreite, als eine einzelne Person in einem typischen 4G-Mobilfunknetz in US-Vororten erhalten könnte
- Am South Pole bestand nur dann Verbindung, wenn ein Satellit über den Horizont kam und die Station für dessen Nutzung freigegeben war; durch den Unterschied zwischen Stern- und Sonnenzeit verschob sich der Satellitenplan meist um etwa 4 Minuten pro Tag nach vorn
- Die von Nutzern empfundene Latenz unterschied sich stark von gewöhnlichen Internet-Erfahrungen
- Die Round-Trip-Latenz zu Zielen auf dem US-Festland lag bei etwa 750 ms
- Das ist etwa das Zehnfache der bis zu 75 ms Round-Trip-Latenz zwischen Ost- und Westküste der USA
- Und etwa das Dreißigfache der maximal 25 ms, die man von einer typischen Kabel- oder Glasfaserverbindung zuhause zu großen CDNs erwarten würde
- Verglichen mit den etwa 3 ms vom GPON-Glasfaseranschluss des Autors zuhause zu Fastly, Cloudflare, CloudFront, Akamai und Google war der South Pole mehr als 250-mal langsamer
Bedingungen, denen Community-Nutzer tatsächlich ausgesetzt waren
- Stand Oktober 2023 konnten Personen, die das Internet am South Pole privat beziehungsweise für Community-Zwecke nutzten, auf folgende Bedingungen treffen
- durchschnittliche Round-Trip-Latenz von etwa 750 ms, dazu Jitter von mehreren Sekunden zwischen Paketen
- Geschwindigkeiten am Endgerät von einigen kbps bis zu 2 Mbps an sehr guten Tagen
- starke Überlastung, Queueing und Paketverluste
- begrenzte Verfügbarkeit, häufige Dropouts und gelegentliche Verdrängung durch priorisierte Dienste
- In bestimmten Situationen traten sogar Bedingungen wie 40 kbps, 1.000 ms Latenz, bis zu 2.000 ms Jitter, 10 % Paketverlust und alle paar Minuten ein kompletter Ausfall von 15 Sekunden auf
- Da operativer Traffic stark priorisiert wurde, waren Community-Nutzer auf die Restkapazität angewiesen
- Funktionen wie Videoanrufe in Echtzeit waren praktisch nicht zu erwarten, aber manche Apps konnten immerhin Textnachrichten von wenigen Bytes senden und empfangen
- Web- und App-Engineering, das langsame oder sporadische Verbindungen nicht berücksichtigt, verschlechterte die Nutzbarkeit zusätzlich
Fallbeispiel: Eine kollaborative Web-App, die 20 MB JavaScript verlangte
- Eine Enterprise-Kollaborationsplattform musste für die Darstellung der Hauptansicht fast 20 MB JavaScript herunterladen
- Seit dem letzten Zugriff war die App aktualisiert worden, wodurch alle Browser-Assets im Cache veraltet waren und neu geladen werden mussten
- Browser und Protokolle können Überlastung bei langsamem Internet bis zu einem gewissen Grad selbst handhaben, aber diese App brach das Laden aufgrund eigener Fehlerschwellen ab
- Wenn sie nicht innerhalb einer von Entwicklern vorgegebenen Zeit oder Zahl an Wiederholungen vollständig geladen war, stoppte die App
- Es erfolgte eine Weiterleitung auf eine Fehlerseite
- Bereits erzielter Ladefortschritt ging verloren
- Beim nächsten Versuch wurden aggressive Maßnahmen zur Cache-Invalidierung angewendet
- Im Kern war diese App eine Messaging-App, und nachdem sie einmal gestartet war, bestand die eigentliche Nutzlast beim Chatten mit Freunden aus wenigen Bytes
- Die Internetleistung am South Pole lag genau an der Grenze dessen, was die Entwickler noch als „akzeptabel“ angesehen hatten, und Nutzer mussten immer wieder aktualisieren und dasselbe JavaScript erneut laden
- Hätte man die nötige Übertragung einfach weiterlaufen lassen, wäre sie innerhalb von 15 Minuten fertig gewesen; in der Praxis dauerte es aber manchmal Stunden
- In einem erfolgreichen Fall wurden 809 HTTP-Anfragen gestellt, 51,4 MB übertragen und nach 26,5 Minuten Ladezeit per 1,8 KB großem HTTPS-POST eine 6-Byte-Nachricht gesendet
- Wäre die App so gestaltet gewesen, dass sie weiter wartet, solange Daten – wenn auch langsam – fließen, hätte man unnötige Neuübertragungen und Bandbreitenverschwendung reduzieren können
Probleme mit hart codierten Timeouts und großen Einzelübertragungen
- Feste Annahmen darüber, wie schnell eine Nutzlast übertragen wird oder wie viel in einer einzelnen Anfrage gesendet werden kann, können Apps auf langsamen Verbindungen unbrauchbar machen
- Wenn man erkennen kann, dass weiter Bytes fließen, sollte man die Übertragung nicht abbrechen – egal wie langsam –, sondern den aktuellen Zustand in der UI anzeigen
- Wenn ein HTTPS-Aufruf fehlschlägt, sollte mit längeren Timeouts erneut versucht werden, und große Daten sollten in kleinere Chunks aufgeteilt übertragen werden
- Der Fortschritt pro Chunk sollte verfolgt werden
- Fehlgeschlagene kleine Teile sollten separat wiederholt oder fortgesetzt werden können
- Langsamer, stetiger inkrementeller Fortschritt ist sicherer als der Versuch, große Daten auf einmal zu senden
- Wenn HTTPS-Aufrufe weiterhin scheitern, sollte man nicht blind denselben Aufruf wiederholen, sondern DNS, ICMP, HTTP ohne TLS oder HTTPS zu einem bekannten Healthy-Endpunkt prüfen und dem Nutzer den Zustand mitteilen
-
Fehler beim Download von Metadaten beim Start
- Eine beliebte Desktop-App lud beim Start Konfigurationsinformationen von der Website des Herstellers und nutzte dafür einen hart codierten Timeout für den HTTPS-Aufruf
- Schlug dieser Aufruf fehl, lud die App nicht und wiederholte denselben Versuch mit denselben Parametern endlos; der Ladebildschirm erklärte die Ursache nicht
- Am South Pole konnte der Aufruf mit genug Wiederholungen irgendwann durchkommen, aber ein einzelner Timeout-Wert machte eine Enterprise-App fast unbenutzbar
- Besser wären schrittweises Backoff mit langem Timeout, Verbindungsprüfungen, Anzeige der Ursache, Nutzung von Cache- oder Standardkonfigurationen sowie ein manueller Download- und Installationspfad gewesen
-
Der Kontrast zwischen zwei Chat-Apps
- Eine bekannte Chat-App nutzte für die Initialisierung von WebSockets einen hart codierten Timeout von 10 Sekunden
- Da dafür TCP-Handshake, TLS-Session, WebSocket-Einrichtung und anfängliches Signaling nötig waren, konnte das unter Bedingungen wie am South Pole mit mehreren Sekunden pro Round Trip leicht länger als 10 Sekunden dauern
- Nach Ablauf des Timeouts funktionierte die App nicht mehr und fiel in einen langen Backoff-Zustand; die UX zeigte die Situation nicht klar an
- Eine konkurrierende Chat-App funktionierte selbst unter extrem schlechten Netzwerkbedingungen deutlich besser
- Sie nutzte mehrere Strategien für Netzwerkanfragen
- Sie verwendete offene Verbindungen aktiv wieder
- Sie passte Timeouts dynamisch an
- Sie wählte Wiederholungsintervalle bei Fehlern intelligent
- Sie zeigte den aktuellen Netzwerkzustand klar an
- Beide Apps übertrugen in der Praxis nur wenige Bytes Klartext, aber wegen unterschiedlicher Netzwerkannahmen unterschieden sich die Bedingungen, unter denen sie nutzbar waren
Inkrementelle Übertragung und fortsetzbare Uploads
- brr.fyi ist ein statischer Jekyll-Blog, dessen Assets in S3 gespeichert und über CloudFront ausgeliefert werden
- Statische Dateien werden lokal auf dem Laptop gebaut
- Sie werden direkt zu S3 hochgeladen
- Es gibt keinen Server, keine QA-Umgebung, kein Build-System, keine automatischen Hooks und keine dynamischen Elemente
- Ein mit Blick auf die Einschränkungen am South Pole erstelltes Python-Publishing-Skript lud Assets über die S3-API in kleinen Chunks hoch
- Es erkannte fehlgeschlagene Uploads und setzte sie fort, ohne den Fortschritt zu verlieren
- Eine neue Version wurde erst veröffentlicht, wenn alle Dateien sicher hochgeladen waren
- Das Ganze war in rund 200 Zeilen Python umgesetzt
- Nutzer kommerzieller Blogging-Plattformen oder sozialer Medien mussten beim Hochladen großer Dateien ihre Zeit oft so planen, dass ein Erfolg innerhalb eines einzelnen Satellitenfensters möglich war
- Scheiterte der Upload, musste oft mehrfach neu versucht werden
- Häufig war unklar, ob der Inhalt hochgeladen war, ob der Upload beendet war oder ob man erneut auf „Post“ klicken durfte
- Wenn ein Chunk-POST fehlschlägt, aber später mit minimalem Verlust wiederholt oder fortgesetzt werden kann, lassen sich Uploads bequem in kleinen KB-Portionen über freie Zeitfenster hinweg sammeln
Anforderungen an eingebaute Downloader
- Wenn eine App einen eigenen Downloader baut, muss er ein hohes Qualitätsniveau erreichen; andernfalls ist er bei langsamem Internet massiv frustrierend oder scheitert fatal
- Wo möglich sollten Nutzer den eingebauten Downloader umgehen und Dateien direkt herunterladen können
- Manuelle Download-Links sind nützlich
- Wenn möglich ist ein Link zur Differenz-Patch-Datei, die die App ohnehin laden wollte, besser als nur ein Link zum kompletten Installer
- Die Vorteile manueller Download-Links sind klar
- Nutzer können einen robusteren Downloader wie den Browser wählen
- Eine Datei lässt sich einmal herunterladen und dann auf mehrere Geräte verteilen
- Der Download kann auf einem anderen Computer erfolgen als dem, auf dem die App läuft
- Nutzer können Downloads passend zu ihren Einschränkungen planen oder verwalten
- Am South Pole gibt es kein 24/7-Internet; selbst wenn täglich ein Download-Fenster von vier Stunden existiert, gibt es keine Möglichkeit, einen Download in einem Stück abzuschließen, wenn die in dieser Zeit übertragbare Datenmenge kleiner ist als die Größe der Nutzlast
- Vielen eingebauten Downloadern fehlen Pause/Fortsetzen, Statusmeldungen, Retry-Logik, Fortschrittsverfolgung und sie haben teils Beschränkungen wie Download-Zeitlimits, was bei langsamem Internet über die Nutzbarkeit der gesamten App entscheidet
Warum der Download-Manager des Browsers als Maßstab gilt
- Der Download-Manager moderner Webbrowser setzt einen hohen Standard, an dem sich eingebaute Downloader messen lassen müssen
- Unterbrechen, pausieren und fortsetzen
- Fehlgeschlagene Downloads erneut versuchen
- Anzeige von aktuellem Status, Geschwindigkeit und verbleibender Zeit
- Wahl des Speicherorts und Möglichkeit, Dateien zu kopieren
- Kein willkürlicher Performance-Cutoff
- Selbst wenn ein Nutzer mehrere GB mit 60 kbps herunterladen möchte, erlaubt der Browser das
- Wenn eine App keine Browser-Funktionalität auf diesem Niveau implementieren kann, sollte sie zumindest die Original-URL bereitstellen, damit der Download im Browser erfolgen kann
Fallbeispiel macOS-Updates
- macOS-Updates waren am South Pole besonders belastend
- Minor-OS-Updates hatten meist eine Patchgröße von 0,5 bis 1,5 GB
- Major-OS-Upgrades gelegentlich mehr als 6 GB
- Zusätzliche Tools wie Xcode lagen ebenfalls oft bei mehreren GB
- Wenn alle macOS-Geräte Updates direkt von Apple beziehen, wird viel Bandbreite verschwendet
- Der eingebaute macOS-Updater bot wenig Kontrolle, und an die zugrunde liegenden Patch-Dateien kam man nicht leicht heran
- Bei Abbruch oder Fehler setzte er nicht immer intelligent fort und verlor mitunter den Fortschritt
- Die macOS-Caching-Server-Funktion von Apple hätte theoretisch die Last senken können, indem jeder Patch nur einmal zum South Pole geladen worden wäre
- In der Praxis musste jedoch jedes Client-MacBook zunächst einen HTTPS-Aufruf an Apple zur Aushandlung von Cache-Parametern erfolgreich durchführen
- Scheiterte dieser Aufruf, lud der Client-Mac den Patch ohne Benachrichtigung oder Retry direkt von öffentlichen Apple-Servern
- Am South Pole scheiterte dieser erste Verhandlungsaufruf häufig, wodurch die Caching-Funktion wenig nutzbar war
- Vollständige Installer ließen sich über auf Mr. Macintosh gesammelte Links direkt von Apple beziehen und dann langsam, aber sorgfältig herunterladen und innerhalb der Station verteilen
- Der vollständige Installer war 12 GB groß, und der Download konnte mehrere Tage dauern, war aber zuverlässig
- Apple-Silicon-Macs versuchten selbst bei Updates per vollständigem Installer zusätzliche Inhalte wie Firmware- oder Rosetta-Updates von 1 bis 2 GB direkt von Apple nachzuladen
- Es gab keine Möglichkeit, das zu umgehen oder zwischenzuspeichern
- Mitunter wurde dieser Download an eine separate Komponente von macOS übergeben, sodass der Fortschritt nicht in der Installations-UI erschien
- Das führte dazu, dass ein Bildschirm mit „32 Minuten verbleibend“ über Stunden stehen blieb, während im Hintergrund 1 GB geladen wurde
- Nötig wären bereitgestellte Patch-Links, besseres Pause/Fortsetzen und Statusmanagement, vollständige Installer mit den Zusatzkomponenten für Apple Silicon sowie mehr Zuverlässigkeit und Kontrolle beim Caching-Server
Fallbeispiel Samsung-Android-OS-Updates
- Das OS-Update-Tool auf Samsung-Android-Smartphones war ein Beispiel dafür, dass langsames oder intermittierendes Internet nicht mitgedacht wurde
- Die Update-UI zeigte weder Geschwindigkeit noch numerischen Fortschritt, Pause, Abbrechen, Dateigröße oder einen Weg zum separaten Download der Dateien
- Wenn ein Download fehlschlug, konnte er nicht fortgesetzt werden und begann wieder bei null
- Am South Pole ließ sich ein vollständiges OS-Update nicht innerhalb eines einzelnen Satellitenpasses herunterladen; bei Verbindungsabbruch musste der Vorgang daher scheitern und komplett neu starten
- In der Praxis wurde kurz vor dem Wegfall der Internetverbindung das Smartphone vollständig ausgeschaltet und beim nächsten Satellitenpass wieder eingeschaltet, um eine Fehlermeldung des Downloads zu vermeiden
- So ließ sich der Download über mehrere Satellitenpässe hinweg aufteilen und abschließen
- Solche Workarounds sollten nicht nötig sein
- Die Update-App von Verizon für macOS und Windows sollte theoretisch OS-Updates über einen Computer aufspielen können, war in der Praxis aber fehleranfällig, unzuverlässig und nutzte ebenfalls einen eigenen eingebauten Downloader
- Der Kern des Problems ist, dass von Herstellern bereitgestellte Werkzeuge für Endnutzer bei langsamem Internet unzureichende Funktionen bieten
Kleine App-Updates und der Kontrast zu Microsoft Office for Mac
- Der eingebaute Updater einer kleinen Desktop-App bot auf langsamen Verbindungen nicht einmal die grundlegenden nötigen Funktionen
- Pause-Button
- Abbrechen-Button
- Fortschrittsanzeige
- Anzeige von Geschwindigkeit oder Restzeit
- Zugriff auf die Original-URL
- Fortschrittsverfolgung und natürliches Fortsetzen unterbrochener Downloads
- Schon allein ein manueller Download-Link hätte die Situation für South-Pole-Nutzer deutlich verbessert
- Der Auto-Updater einer anderen App bot zwar einen Abbrechen-Button und visuelle Fortschrittsanzeige, aber keine Pause, keinen numerischen Fortschritt oder Geschwindigkeitswert, keinen Zugriff auf die Original-URL und keine Fortsetzungsfunktion
- Der Auto-Updater von Microsoft Office for Mac war selbst am South Pole ein gutes Beispiel
- Pause-Button
- Abbrechen-Button
- Fortschrittsanzeige
- Anzeige von Geschwindigkeit und verbleibender Zeit
- Natürliches Fortsetzen unterbrochener Downloads
- Eine Original-URL wäre noch besser gewesen, aber die Oberfläche war gut genug, um selbst am South Pole brauchbar zu sein
Praktische Designprinzipien für Nutzer mit langsamem Internet
- Funktionen, die in Umgebungen mit schnellem Internet wie kleine Auslassungen wirken, werden bei langsamem Internet schnell zu massiven Hindernissen
- Apps sollten so entworfen sein, dass Nutzer nicht wegen eines einzigen festen Timeouts in einer Schleife landen, in der sie nicht einmal ein paar Bytes Text senden können
- Mögliche Designprinzipien sind einfach
- Nicht abbrechen, solange sich Bytes bewegen
- Große Nutzlasten in Chunks aufteilen
- Fortschritt auch bei Fehlern erhalten
- Den Netzwerkzustand für Nutzer klar sichtbar machen
- Manuelle Download-Links anbieten, wenn der eingebaute Downloader nicht ausreicht
- Der South Pole ist ein Grenzfall, aber auch Inmarsat-Verbindungen auf Schiffen, Thales MissionLink und Iridium Certus an Gebirgsforschungsstandorten, instabiles Wi‑Fi, falsch konfigurierte Router, minderwertige WISPs und Nutzer mit veralteten Einwahlverbindungen über Telefonleitungen können ähnliche Einschränkungen erleben
- Entwickler müssen nicht jede Extrembedingung optimieren, aber sie sollten zumindest verhindern, dass ihr Produkt den Fortschritt von Nutzern mit langsamer Verbindung aktiv behindert
1 Kommentare
Hacker-News-Kommentare
Dieser Beitrag spricht mir sehr aus der Seele. Ich bin zwar nicht in der Antarktis, sondern in Peking, aber ich kämpfe immer noch mit dem Internet.
Hinter der Great Firewall muss man kreativ werden, und auch VPNs funktionieren nur gelegentlich. Jedes VPN hinterlässt Spuren, sodass die Heuristiken und das Machine Learning der Firewall sie irgendwann erkennen; selbst vom Staat erlaubte VPNs werden in politisch sensiblen Zeiten „sanft“ eingeschränkt.
Selbst wenn man schließlich verbunden ist, ist die Verbindung nicht stabil, und es ist extrem schmerzhaft, wertvolle Pakete für nutzlose Web-App-/React-Roundtrips zu verschwenden.
Manche Entwickler sollten wohl eine Zeitreise ins Jahr 2005 machen und versuchen, nach den Maßstäben dieser Zeit zu entwickeln, um zu lernen, wie man Dinge schlank hält. Falls Zeitreisen nicht möglich sind, sollten sie in den Entwicklertools bitte die Drosselung aktivieren, auf 3G stellen und prüfen, ob ihre Web-App das aushält.
Ich teste Projekte immer unter begrenzter Bandbreite. Denn genau wie bei Barrierefreiheit führt das Befolgen guter Praktiken nicht nur für Nutzer mit schlechter Verbindung, sondern für alle zu einer besseren User Experience.
Eine weitere häufig verpasste Chance ist, Single-Page-Apps offline-first zu bauen.
Ich widerspreche der grundsätzlichen Aussage nicht unbedingt, aber modernes JavaScript ist tatsächlich ziemlich gut darin, langsames Internet in Server-Client-„Anwendungen“ zu handhaben. Es ist nur nicht leicht, und es gibt online kaum Material, das jemand, der mit Google/GPT codet, als Grundlage für ein Projekt nehmen könnte.
Das liegt auch daran, dass es online zu viele schlechte JavaScript-Ressourcen gibt, aber auch daran, dass Organisationen, die so arbeiten, ihr Wissen nicht teilen. Auch wir haben keinen Grund, Wettbewerbern Informationen zu liefern, daher gibt es exakt 0 öffentliche Materialien zu unserer Arbeitsweise.
Das ist ein interessantes Training darin, nutzlose Roundtrips in Technologien zu reduzieren, die erwarten, für alles Roundtrips zu verwenden.
Ich bekomme immer noch etwa 1–10 Mbit/s, meist abhängig von der Tageszeit, und habe kaum Verbindungsprobleme.
Aus viel Erfahrung mit dem Pendeln in unterirdischen öffentlichen Verkehrsmitteln (sporadisch, überlastet) und aus der Zeit, in der ich in Australien gelebt und gearbeitet habe, kann ich mit Sicherheit sagen: Für Menschen ohne „ideale“ Netzwerkbedingungen sind die meisten Dienste miserabel.
In der London Underground fällt besonders auf, dass die meisten Apps wirklich schlecht mit einem Netzwerk umgehen, das ungefähr alle zwei Minuten abbricht und wiederkommt. Zwischen den Stationen ist die Verbindung weg, und wenn ein Zug mit 500 Fahrgästen gleichzeitig eine Verbindung aufbauen will, dauert allein das Verbinden mit jedem Access Point etwa 15 Sekunden.
In Australien ist man im Grunde von überall 200 ms entfernt. Das mag nach wenig klingen, zeigt aber sehr deutlich, welche Apps über N+1-Request-Probleme stolpern.
Die einzige App, die immer beeindruckt, ist WhatsApp. Nach einer erneuten Verbindung funktioniert sie als Erste, lässt bis kurz vor dem Abbruch noch als Letzte Traffic durch, und selbst mit Latenz fühlen sich Anrufe ziemlich schnell an.
WhatsApp ist tatsächlich wahrscheinlich einer der wenigen Dienste, die Server in Australien bereitgestellt haben. 200 ms wirken wie ein starkes Signal für interkontinentalen Traffic.
Die meisten globalen Unternehmen deployen höchstens in drei Regionen: USA (us-east, us-central, us-east+us-east), Europa (west-europe) und, vergleichsweise selten, Fernost (us-west oder Japan).
Orte wie Südafrika, Südamerika und Australien müssen ihre Daten daher normalerweise aus einer dieser Regionen holen, was wegen physikalischer Grenzen mindestens 200 ms Latenz verursacht.
Australien trifft es besonders hart. Selbst wenn es theoretisch ein dediziertes Deployment in der eigenen Jurisdiktion gibt, stehen die tatsächlichen Server oft auf einem ganz anderen Kontinent (US-Westküste oder Japan), sodass Nutzer die Performance-Auswirkungen von Paketen erleben, die um die halbe Erde reisen.
Weil diese Perspektive tief in den Entwicklungszielen verankert war, hatte WhatsApp meiner Meinung nach gute Gründe, in vielen Ländern der Welt zum führenden Messenger zu werden.
Wenn ich eine .jpg-URL im Browser öffne, um ein Bild anzusehen, dauert es viel länger als wenn ich zu termux wechsle und
wgetausführe, und manchmal kommt es zu einem Timeout. Das habe ich sowohl mit Firefox als auch mit Chrome-basierten Browsern erlebt.Zur Einordnung: Auch ein
wget-Download dauert über die Mobilfunkverbindung normalerweise 10 bis 30 Sekunden.Ich verstehe nicht, warum Berlin das so gemacht hat. Man könnte doch einfach im Zug Internet bereitstellen.
Wenn das Netzwerk ständig abbricht, funktioniert der Großteil des Internets wirklich miserabel.
Ich reise viel, und langsames Internet ist ziemlich verbreitet. Selbst jetzt sind meine mobilen Daten aufgebraucht, und ich bin auf 8 kbps gedrosselt.
Websites, die nur Text auf der Seite haben, sollten eigentlich schnell sein, aber viele sind es nicht. Hacker News ist extrem schnell, aber die Google-API-Dokumentation öffnet sich gar nicht.
Das schlimmste Problem ist, dass die meisten UIs langsame Requests nicht berücksichtigen. Buttons fühlen sich an, als wären sie kaputt, und Dinge, die keine Megabytes an Daten brauchen sollten, benötigen Minuten zum Laden oder schlagen fehl. Die gesamte Google-Maps-UI geht kaputt.
Ich wünschte, Entwickler würden stärker für langsames Internet entwerfen und testen. Stattdessen bekommen wir datenhungrige Websites, die nur auf schnellen Firmen-Laptops und mit schnellem Internet gut funktionieren.
In diesem Zusammenhang: Ich verdiene meinen Lebensunterhalt mit dem Betrieb von Websites, und der Wechsel zu einem Static Site Generator war in Sachen Produktivität eine meiner besten Entscheidungen. Statt dass die Latenz des CMS in jede Aufgabe hineinwirkt, kann ich Textdateien sogar komplett offline extrem schnell bearbeiten und, sobald ich online bin, nur die Änderungen pushen. Das verändert alles.
Heute scheint es nicht viel zu bringen, 500 MB Google-Maps-Cache aufs Handy zu laden. Es holt sich immer noch alles und poppt verspätet auf.
Eine meiner Domains wird derzeit als „gefährlich“ markiert, weil ich keine aktuelle WordPress-Version verwendet habe.
Im Grunde trifft jeder gesendete Request eine AppEngine-App, die Python-Code ausführt und HTML zurückgibt. Deshalb sollte es eigentlich schnell wirken, ist es in der Praxis aber nicht.
Ich bin in Großbritannien, und der Ping zu news.ycombinator.com liegt bei 147 ms. Vermutlich, weil es kein CDN nutzt und in den USA gehostet wird.
Dagegen liegt der Ping zu cloud.google.com bei 8 ms.
Hacker News ist zwar eine einfache Seite mit wenig JavaScript, aber es kann andere Faktoren geben, die sie für Nutzer in manchen Regionen langsam erscheinen lassen. Selbst in einer privilegierten Umgebung mit einer XGS-PON-Glasfaserleitung mit symmetrischen 8 Gbit/s.
Ich habe einmal beim Trampen jemanden mitgenommen, der gerade vom Eis heruntergekommen war, und er sagte, der Blogautor schreibe zwar hervorragend, sei bei den Leuten in seiner Umgebung aber durchaus etwas unbeliebt gewesen, weil er beim Hochladen von Bildern oft die ohnehin begrenzte Bandbreite belegte.
Allerdings habe die Verwaltung den PR-Wert erkannt, weshalb er Vorrang bekam. Ich fand, das passte gut zur Diskussion über langsames Internet.
Das Handy in der Tasche könnte unnötig die gesamte verfügbare Bandbreite nutzen; und selbst wenn jemand ein 720p-Video schaut, das gerade so abspielbar ist, kann die Person dahinter, die laden möchte, möglicherweise nicht einmal 480p sehen. Man selbst merkt es wegen des Puffers nicht, während die andere Person aufgibt, bevor ihr Puffer ausreichend gefüllt ist.
Mindestens bräuchte es wohl eine Nutzungsabrechnung, die zeigt, welcher Prozentsatz des Traffics der letzten Stunde an einen selbst ging, und welcher Prozentsatz einem zugestanden hätte, wenn alle gleich viel benötigt hätten, verglichen mit einem Richtwert aus verfügbarer Bandbreite geteilt durch die Zahl der verbundenen Nutzer.
Darüber hinaus wäre auch ein System denkbar, das alle auf niedriger Priorität belässt, bis sie einen Button „Ja, ich kenne die Bandbreite, die ich in den nächsten [X≤24] Stunden verbrauchen werde, und brauche sie tatsächlich“ drücken; danach würde die QoS-Priorität der MAC-/IP-Adresse auf normal angehoben.
Solche Situationen schreien nach Local-first-Anwendungen und entsprechenden Lösungen, und genau dafür wurde das Internet ursprünglich geschaffen [1][2].
Die Leute sind auf Salesforces Werbespruch „No Software“ hereingefallen, obwohl er dem Fundament und Geist des Internets frontal widerspricht. Seit 1969 waren Mbps über den größten Teil der Internetgeschichte die Ausnahme, nicht der Standard, und die erste Killer-App, E-Mail-Messaging — vermutlich bis heute die beste Internet-App — ist local-first [3].
Ironischerweise ist auch die Anwendung, über deren Probleme der Autor klagt, eine Messenger-App.
[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...
Ich habe über mehrere Jahre viel an Networking-Themen gearbeitet und Zeit damit verbracht, meine eigene „langsames Internet“-Umgebung zum Laufen zu bringen. Nicht so spannend wie McMurdo, aber ich habe in internationalen Flugzeugen, in Zügen durch abgelegene Gegenden, in miserablen Landhotels und sogar in Tunneln gechattet und YouTube-Videos angesehen.
Wenn man Zugriff auf ein universelles Computing-Gerät hat, die Stromversorgung stemmen kann (solche Geräte brauchen eher viel Strom) und bereit ist, selbst etwas zu bauen, empfehle ich NNCP [1]. NNCP kann Daten entgegennehmen, in Stücke zerlegen und versenden. Es enthält auch ein Synchronisationsprotokoll, das noise über TCP nutzt, und sendet, indem es fehlgeschlagene Stücke erneut versucht. Da kein TLS nötig ist, braucht der Verbindungsaufbau nur 1,5 RTT.
NNCP kann Daten über die Standardeingabe an ein Remote-Programm weiterreichen. Ich habe einen YouTube-Downloader sowie Slack-, Telegram- und Discord-Bots gebaut, die eingehende Daten lesen und mit dem jeweiligen Dienst interagieren. Auf der lokalen Maschine laufen ein Matrix-Server (Dendrite) und Bots; über NNCP werden die Daten an den passenden Remote-Dienst gesendet.
Man sollte hoffen oder ausprobieren, dass MTU/MSS entlang der Strecke möglichst niedrig sind, damit Wiederholungen auf TCP-Ebene häufig möglich sind. Aber diese Konfiguration hat mich fast überall kaum im Stich gelassen und Medienkonsum sowie Chatten ermöglicht.
Das Ärgerlichste auf internationalen Flügen ist, dass NNCP-Endpunkte nicht geografisch verteilt sind. Je nach Flugroute und dem tatsächlichen Weg, den Pakete bis zum Endpunkt nehmen, können Latenz und Jitter stark steigen. Normalerweise versuche ich, einen NNCP-Endpunkt in der Nähe des Zielorts zu haben, aber aus Sicht des Bord-WLANs kann die tatsächliche Route miserabel sein. NNCP unterstützt inzwischen Yggdrasil, was das abmildern und auch bei der Kontrolle von MTU-Problemen helfen könnte; ich habe Ygg unter solchen Bedingungen aber noch nicht ausprobiert.
[1]: http://www.nncpgo.org/
Ich habe auf einem Schiff im Südpazifik ähnliche Erfahrungen gemacht wie der Autor. Es gab Starlink, aber wegen des hohen Stromverbrauchs (über 60 W) haben wir es nicht oft genutzt. Stattdessen kauften wir lokale SIM-Karten und hatten an manchen Orten 4G, an anderen EDGE (2G).
EDGE selbst ist auf dem Papier nicht besonders schlecht. Es liefert einige Dutzend Kilobit pro Sekunde. In der Praxis war es deutlich schlechter. Ich erlebte, dass Apps, die gut funktioniert hätten, wenn sie nur berücksichtigt hätten, dass Laden nicht Millisekunden, sondern Minuten dauern kann, wegen kurzer Timeouts scheiterten.
Verbindungen mit niedriger Bandbreite und hoher Latenz sollten Teil regelmäßiger Softwaretests sein. Unter Linux gibt es dafür netem (https://wiki.linuxfoundation.org/networking/netem).
Ein Problem, das der anonyme Blogger nicht hatte, waren getaktete Verbindungen. Wegen der Kosten waren Betriebssystem- oder App-Upgrades nahezu unmöglich. Zum Glück erreichten wir alle paar Wochen einen Ort mit unbegrenzter Verbindung und konnten solche Dinge dort erledigen. Dafür wurde ich sehr vertraut damit, unter verschiedenen Betriebssystemen Verbindungen als getaktet/nicht getaktet zu markieren, alle automatischen Updates abzuschalten und die kostbare Bandbreite zu sparen.
Und wenn von „lokalen SIM-Karten“ die Rede ist, heißt das wohl, dass ihr auf Inseln an Land gegangen seid, um sie zu kaufen. Mich würde interessieren, wo es in den 2020ern nur 2G gab. Ich kann kaum glauben, dass es im Südpazifik noch solche Orte gibt.
Man muss die Perspektive wahren. Manche Projekte überspringen sogar das Testen einer Web-App in mehreren Browsern, weil es als Verschwendung und nicht zu rechtfertigender Aufwand gilt. Und das, obwohl es trivial ist, es in die Testmatrix aufzunehmen, und es nur ein UI-Problem ist.
Engineering unter Berücksichtigung langsamer Internetverbindungen ist weiterhin wirklich wichtig und wird von den meisten Softwareentwicklern stark unterschätzt. Aber Low-Earth-Orbit-Satellitensysteme (Starlink, insbesondere StarLink) haben das Kernproblem inzwischen praktisch gelöst.
Im September/Oktober 2023 bin ich die Nordostpassage (von Alaska nach Norwegen) gefahren, und selbst auf einem Schiff weit oberhalb des Polarkreises konnte ich trotz Wolken, Entfernung zum Land und Eis FaceTime-Videoanrufe führen. Das war zur selben Zeit, in der der Autor in der Antarktis war.
Was auch immer die Einschränkung war: Am Ende geht es um den Servicevertrag und darum, ein Terminal vor Ort zu haben. Polare Abdeckung ist relativ selten, aber die Bevölkerungsdichte ist extrem gering, also reicht sie trotzdem aus.
https://satellitemap.space/
Langsames Internet kann vieles bedeuten; eine Bedeutung davon sind Verbindungsprobleme. Bei verbindungsorientierten Protokollen wie TCP bedeutet das eine Verlangsamung durch Paketverlust, bei Fire-and-forget-Protokollen wie UDP heißt es, dass Nachrichten nicht ankommen. Langsamkeit kann also eine niedrige Übertragungsrate sein, aber auch kurze Aussetzer nach momentweise hohem Durchsatz.
Ein robuster Ansatz für langsame Netzwerke ist die Unterstützung eines Offline-Modus. Sämtliches Push/Pull von Daten wird als asynchrone Transaktion entworfen, und Daten-Pushs werden lokal gecacht und erneut versucht, sobald es möglich ist. Dadurch entstehen zusätzliche Anforderungen wie Versionsverwaltung und Konfliktlösung.
Daraus ergeben sich zwangsläufig auch mehr UI-Anforderungen: manuelle Synchronisierung/Aktualisierung, Anzeige des Netzwerkstatus, Deaktivieren sinnloser Aktionen bei Verbindungsabbruch und vorausschauendes Laden, damit die Nutzung auch offline möglich ist.
Irgendwann möchte ich in einer Welt nach dem langsamen Internet leben, aber das ist noch viele Jahre entfernt. Nebenbei: Das XS hatte ein Intel-Modem, das bekanntermaßen schlechter war als Qualcomms Flaggschiffe aus dieser Zeit.
Ich lebe an einem der am dichtesten besiedelten Orte der Welt, voller 5G-Antennen und Wi‑Fi-Stationen, aber man merkt immer noch, wenn schlampig gebaute Websites bei langsamen oder instabilen Verbindungen scheitern.
Geostationäre Satelliten stehen am Pole zu nah am Horizont, daher ist die polare Abdeckung begrenzt. Der Pole nutzt alte geostationäre Satelliten mit wenig Treibstoff und relativ hoher Bahnneigung und kann deshalb nur etwa 6 Stunden pro Tag kommunizieren.
Zeitplan: https://www.usap.gov/technology/1935/
Regierungen werden weder ein unzensiertes Web noch ein US-Unternehmen als Internet-Gateway wollen. Sie werden die Netze innerhalb ihres bestehenden Hoheitsgebiets beibehalten, und das Geschwindigkeitsproblem bleibt relevant.
Man muss auch die Zahl der Menschen weltweit berücksichtigen, deren einziger Internetzugang ein 100-Dollar-Android-Handy mit alter Software und begrenzter CPU ist.
Es gibt einen IETF-Entwurf, der HTTP für effiziente Zustandssynchronisierung erweitert und so die User Experience in langsamen Netzwerken verbessern könnte: https://news.ycombinator.com/item?id=40480016
Das Braid Protocol ermöglicht es mehreren Synchronisationsalgorithmen, über ein gemeinsames Netzwerkprotokoll interoperabel zu sein; die Netzwerk-Nachrichten beliebiger Synchronizer können darauf abgebildet werden. Die aktuelle Braid-Spezifikation fügt HTTP zwei Synchronisationsdimensionen hinzu.
Level 0: heutiges HTTP
Level 1: Abonnements mit Push-Updates
Level 2: P2P-Konsistenz (Patches, Versionen, Merges)
Heutige Synchronizer verwenden unterschiedliche Protokolle, aber ihre Netzwerk-Nachrichten transportieren dieselben Arten von Informationen: Versionen in der Zeit, Positionen im Raum und Patches von Raumbereichen über Zeitintervalle hinweg. Die Komposition beliebiger Patch-Mengen bildet eine mathematische Struktur namens Braid: Verzweigen, Zusammenführen und Neuordnen von Raum über die Zeit.
Die Hoffnung sprudelt ewig.
Weniger Roundtrips zu machen und weniger aufgeblähte Dinge zu bauen ist nicht schwer, sondern eigentlich viel einfacher. Bloat existiert aus ganz anderen Gründen.
Manchmal fällt Bloat bei schnellem Internet nahe am Rechenzentrum und großzügig ausgestatteten Maschinen nicht auf. Man kann das leicht simulieren, aber das Unternehmen muss sich dafür interessieren. Ad-Tech und das Umfeld kümmern sich im Allgemeinen kaum um kleine Nutzergruppen. Eigentlich ist der einzige Grund, sich für Endnutzer zu interessieren, dass sie den echten Kunden, also den Werbekunden, Umsatz bringen.
Wir, die Apps, Websites usw. bauen, sollten daran denken, dass viele Menschen nicht mit dem schnellen WLAN oder Glasfaseranschluss verbunden sind, den wir selbst nutzen.
In Großbritannien haben einige Anbieter mit der 3G-Abschaltung begonnen. Manche lassen 2G als stromsparende Alternative bestehen, nach dem Motto, man solle jetzt eben 4G/5G nutzen. Das Problem ist, dass 4G noch nicht überall verfügbar ist und bis vor Kurzem in manchen Gegenden nur 3G-Signal brauchbar war.
Dadurch fällt man nun häufiger ungewollt auf 2G/EDGE zurück, und vieles bleibt einfach stehen. Viele Apps werden nicht in Szenarien mit langsamen Verbindungen, hoher Latenz und starkem Paketverlust getestet.
Versuch mal, dich mit Google Maps über 2G navigieren zu lassen, dann weißt du Bescheid :(