遅いインターネットのためのエンジニアリング：南極でユーザーの不便を減らす方法
(brr.fyi)- South Poleのインターネットは限られた衛星リンクに依存し、1日のうち数時間しか接続できず、2023年10月時点でコミュニティ利用者は高遅延・低帯域・断続的な切断を受け入れる必要があった
- 実際の環境は往復遅延約750ms、数秒単位のジッター、数kbps〜2Mbpsの速度で、混雑・キューイング・パケット損失・サービスの優先占有が重なり、一般的なアプリのネットワーク前提を簡単に壊していた
- 大きなJavaScriptバンドル、ハードコードされたタイムアウト、進捗の破棄、キャッシュ無効化、再開不能な内蔵ダウンローダーは、遅いリンク上でアプリが自ら失敗する要因になっていた
- バイトが遅くても流れているなら待ち、チャンク転送・再開・状態表示・動的タイムアウト・手動ダウンロードリンクを提供すれば、テキストメッセージやアップデートのような小さな目標は達成できた
- 南極は極端な事例だが、海上船舶、山岳研究拠点、不安定なWi‑Fi、品質の低いWISP、電話線ベースの接続利用者も同様の制約を受けうるため、ユーザーの進行を妨げない設計が必要である
South Poleのインターネット環境の制約
- South Poleでインターネットを提供すること自体が自明ではないエンジニアリング課題であり、極地で使える衛星の選択肢は限られている
- 公開資料として South Pole Satellite Communications ページがある
- 南極大陸まで従来型の光ファイバーを引く難しさは 2021 Antarctic Subsea Cable Workshop でも扱われている
- NSFはMcMurdoとPalmerのStarlinkに関する発表を行ったが、2023年10月時点でSouth Pole Stationについて同様の発表はなかった
- McMurdoでは最近までほぼ1,000人と複数の科学・運用ワークロードが、基地全体で数十Mbps程度の集約帯域を共有していた
- 米国郊外の一般的な4Gセルラーネットワークで個人が得られる帯域より少ない量を、基地全体で分け合っていたことになる
- South Poleは、衛星が地平線上に現れ、基地に利用許可が与えられた時間帯にのみ接続でき、衛星スケジュールは恒星時と太陽時の差のため、概ね1日あたり約4分ずつ前倒しになっていた
- ユーザーが体感する遅延は一般的なインターネット体験と大きく異なっていた
- 米国本土の宛先までの往復遅延は約750ms
- 米国東海岸・西海岸間の往復遅延最大75msの約10倍
- 一般家庭のケーブル・光回線から主要CDNまでに期待される最大25msの約30倍
- 筆者の家庭用GPON光回線でFastly、Cloudflare、CloudFront、Akamai、Googleまで約3msだったのと比べると、South Poleは250倍以上である
コミュニティ利用者が実際に直面した条件
- 2023年10月時点でSouth Poleでコミュニティ用途にインターネットを使う個人は、次のような条件に置かれうる
- 平均往復遅延約750ms、パケット間ジッターは数秒超
- エンドユーザー端末基準で数kbpsから、非常に良い日で2Mbpsまでの速度
- 深刻な混雑、キューイング、パケットドロップ
- 限られた可用性、頻繁なドロップアウト、ときどき発生するサービスの優先占有
- 特定の状況では、40kbps、1,000ms遅延、最大2,000msジッター、10%のパケット損失、数分ごとに15秒の完全断絶といった条件も見られた
- 運用トラフィックが強く優先されるため、コミュニティ利用者は余剰容量に依存していた
- リアルタイムのビデオ会議のような機能は期待しにくいが、一部のアプリでは数バイトのテキスト送受信は可能だった
- 遅い、あるいは断続的なリンクを考慮していないWeb・アプリのエンジニアリングが、使い勝手をさらに悪化させていた
20MBのJavaScriptを要求したコラボレーションWebアプリの事例
- あるエンタープライズ向けコラボレーションプラットフォームは、メイン画面を描画するためにJavaScriptだけでほぼ20MBをダウンロードする必要があった
- 前回アクセス以降にアプリが更新され、ブラウザキャッシュ内のアセットがすべて古くなって再ダウンロードが必要だった
- ブラウザとプロトコルは遅いインターネット上でもある程度は輻輳制御を処理するが、このアプリは独自の失敗条件で読み込みを打ち切っていた
- 開発者が定めた時間や再試行回数の範囲内に完全に読み込めないとアプリが停止する
- エラーページへリダイレクトされる
- それまでの読み込み状態が失われる
- 次回再試行時には強いキャッシュ無効化措置が適用される
- このアプリは本質的にはメッセージングアプリであり、起動後に友人とチャットする際の実際のコンテンツペイロードはバイト単位だった
- South Poleのインターネット性能は、開発者が「許容可能」と見なした境界線上にあり、ユーザーは何度もリロードして同じJavaScriptを再取得する羽目になった
- 必要な転送をそのまま継続させれば15分以内に終えられたはずだが、実際には数時間かかることもあった
- 成功例では809件のHTTPリクエスト、51.4MBの転送、26.5分の読み込みの末に、1.8KBのHTTPS POSTで6バイトのメッセージを送っていた
- アプリが、データが遅くても流れている限り待ち続ける設計であれば、不要な再転送と帯域の無駄を減らせたはずである
ハードコードされたタイムアウトと大きな単一転送の問題
- ペイロードがどれだけ速く送れるか、1回のリクエストでどれだけ多く送れるかという固定前提は、遅いリンク上でアプリを壊しかねない
- バイトが流れていることを観測できるなら、どれだけ遅くても転送を打ち切らず、現在の状況をUIに表示するほうがよい
- HTTPS呼び出しが失敗したら、より長いタイムアウトで再試行し、大きなデータは小さなチャンクに分けて送るべきである
- チャンクごとの進捗を追跡する必要がある
- 失敗した小さな部分だけを再試行または再開できる必要がある
- 大きなデータを一度に送ろうとするより、遅くても着実な増分進行のほうが安全である
- HTTPS呼び出しが繰り返し失敗するなら、同じ呼び出しを盲目的に繰り返すのではなく、DNS、ICMP、TLSなしのHTTP、既知の正常エンドポイントへのHTTPSなどを確認し、ユーザーに状態を伝えるべきである
-
起動時のメタデータダウンロード失敗
- ある人気デスクトップアプリは起動時にベンダーWebサイトから設定情報を取得し、そのHTTPS呼び出しにハードコードされたタイムアウトを使っていた
- この呼び出しが失敗するとアプリは読み込まれず、同じパラメータで永久に再試行し、ロード画面は原因を示さなかった
- South Poleでは試し続ければ最終的に通ることもあったが、たった1つのタイムアウト値のせいで、エンタープライズ級アプリがほぼ使えなくなっていた
- より良い挙動は、長いタイムアウトによる段階的バックオフ、接続状態の確認、原因表示、キャッシュや既定設定の利用、手動ダウンロードとインストール経路の提供だった
-
2つのチャットアプリの対比
- ある人気チャットアプリはWebSocket初期化に10秒のハードコードタイムアウトを使っていた
- TCPハンドシェイク、TLSセッション、WebSocket設定、初期シグナリングがすべて必要であり、South Poleのように各往復に数秒かかる条件では10秒を超えうる
- タイムアウトするとアプリは動作せず、長いバックオフ状態に入り、UXも状況を明確に示さなかった
- 競合するチャットアプリは、極端に悪いネットワーク条件でもよりうまく動作した
- 複数のネットワークリクエスト戦略を使う
- 開いた接続を積極的に再利用する
- タイムアウトを動的に調整する
- 失敗時の再試行間隔を賢く選ぶ
- 現在のネットワーク状態を明確に表示する
- 両アプリとも実際に送っていたのはプレーンテキスト数バイトにすぎないが、ネットワーク前提の違いによって使える条件が変わっていた
増分転送と再開可能なアップロード
- brr.fyiは静的なJekyllブログであり、アセットはS3に保存されCloudFrontで配信されている
- 静的ファイルはローカルのノートPCでビルドされる
- S3へ直接アップロードされる
- サーバー、QA環境、ビルドシステム、自動フック、動的要素はない
- South Poleの制約を考慮して作られたPythonの公開スクリプトは、S3 APIを使ってアセットを小さなチャンク単位でアップロードした
- 失敗したアップロードを検知し、進捗を失わずに再開する
- すべてのファイルが安全にアップロードされるまで新バージョンを公開しない
- 約200行のPythonで実装されている
- 商用ブログプラットフォームやSNSに大きなファイルを上げる利用者は、衛星利用可能時間内で一度に成功する可能性に合わせてタイミングを調整する必要があった
- 失敗すれば何度も再試行する必要があった
- コンテンツが上がったのか、アップロードが完了したのか、もう一度「Post」を押してよいのか不明確なこともあった
- チャンクPOSTが失敗しても、後で最小限の損失で再試行・再開できるなら、数KBずつでも都合のよい時間に積み上げてアップロードできる
内蔵ダウンローダーが満たすべき基準
- アプリが独自のダウンローダーを作るなら高い品質が必要であり、そうでなければ遅いインターネット上で深刻に不便、あるいは致命的に失敗する
- 可能であれば、ユーザーは内蔵ダウンローダーを迂回して直接ファイルを取得できるべきである
- 手動ダウンロードリンクの提供が有用である
- 可能なら、完全なインストーラーよりもアプリが取得しようとしていた差分パッチファイルへのリンクのほうが望ましい
- 手動ダウンロードリンクの利点は明確である
- ユーザーはブラウザのような、より堅牢なダウンローダーを選べる
- ファイルを一度取得して複数デバイスに共有できる
- アプリが動いているコンピューターとは別のコンピューターで取得できる
- ユーザーは自身の制約に合わせてダウンロードを予約・管理できる
- South Poleには24時間インターネットがないため、毎日4時間のダウンロード可能時間があっても、その時間内に取得できるデータ量がペイロードサイズより小さければ、一度で完了させる方法はない
- 多くの内蔵ダウンローダーは、一時停止・再開、状態通知、再試行ロジック、進捗追跡が不十分で、ダウンロード時間制限のような制約もあり、遅いインターネットではアプリ全体の可用性を左右する
ブラウザのダウンロードマネージャーが基準点である理由
- 現代のWebブラウザのダウンロードマネージャーは、内蔵ダウンローダーが比較されざるを得ない高い基準を提供している
- 中断、一時停止、再開機能
- 失敗したダウンロードの再試行
- 現在の状態、速度、残り時間の表示
- 保存先の選択とファイルコピーのしやすさ
- 任意の性能カットオフがない
- ユーザーが60kbpsで数GBのファイルを受け取ろうとしても、ブラウザはそれを許容する
- アプリがブラウザ並みの機能を実装できないなら、少なくともユーザーがブラウザで取得できる元のURLを提供するほうがよい
macOSアップデートの事例
- macOSアップデートはSouth Poleでは特に負担が大きかった
- マイナーOSアップデートのパッチサイズは通常0.5〜1.5GB
- メジャーOSアップグレードのパッチはときに6GB超
- Xcodeのような追加ツールも数GBになることが多い
- すべてのmacOSデバイスがAppleから直接アップデートを取得すると、帯域が大きく無駄になる
- macOS内蔵アップデータは制御性が低く、基礎となるパッチファイルを簡単に入手する方法もなかった
- キャンセルや失敗時に常に賢く再開するわけではなく、進捗を失うことがあった
- AppleのmacOSキャッシュサーバー機能は、理論上は各パッチをSouth Poleへ1回だけダウンロードさせることで負担を減らせたはずである
- 実際には各クライアントMacBookがキャッシュパラメータ交渉のためAppleへのHTTPS呼び出しを成功させる必要があった
- この呼び出しが失敗すると、クライアントMacは通知や再試行なしにAppleの共有サーバーから直接パッチを取得した
- South Poleではこの初期交渉呼び出しが頻繁に失敗し、キャッシュ機能は役に立たなかった
- 完全なインストーラーは Mr. Macintosh にまとめられたリンク経由でAppleから取得でき、これを遅くても慎重にダウンロードして基地内配布できた
- 完全インストーラーは12GBで、ダウンロードには数日かかることもあったが、信頼性はあった
- Apple Silicon Macは、完全インストーラーで更新しても、ファームウェアやRosetta更新など追加コンテンツ1〜2GBをAppleから直接取得しようとした
- これを回避またはキャッシュする方法はなかった
- ダウンロードがmacOSの別コンポーネントへ移り、インストールUIに進捗が反映されないこともあった
- 「残り32分」の画面が数時間表示されたまま、バックグラウンドで1GBをダウンロードしている状況が発生した
- 必要なパッチリンクの提供、一時停止・再開と状態管理の強化、完全インストーラーへのApple Silicon向け追加項目の同梱、キャッシュサーバーの信頼性と制御性の改善が必要だった
Samsung Android OSアップデートの事例
- Samsung AndroidスマートフォンのOSアップデートツールは、遅い、あるいは断続的なインターネットを考慮していない例だった
- アップデートUIには速度表示、数値進捗、一時停止、キャンセル、ファイルサイズ表示、別途ダウンロード用ファイルへのアクセス方法がなかった
- ダウンロードが失敗すると再開できず、最初からやり直しになった
- South Poleでは1回の衛星パス内にOSアップデート全体を取得できないため、接続が切れると必ず失敗し、最初からやり直しになった
- 実際には、インターネットが切れる直前にスマートフォンの電源を完全に切り、次の衛星パスで再度起動することでダウンロード失敗判定を避けていた
- この方法で複数の衛星パスにまたがってダウンロードを分割完了できた
- こうした回避策は本来不要であるべき異常な解決法だった
- VerizonのmacOS・Windows向けアップデートアプリは、理論上はコンピューターからOSアップデートを書き込めるが、実際にはバグが多く信頼性が低く、独自の内蔵ダウンローダーを使っていた
- 問題の核心は、ベンダーが一般ユーザー向けに提供するツールが、遅いインターネット利用者に対して機能不足である点にある
小さなアプリ更新とMicrosoft Office for Macの対比
- ある小規模なデスクトップアプリの内蔵アップデータには、遅いリンクで必要となる基本機能が欠けていた
- 一時停止ボタン
- キャンセルボタン
- 進捗表示
- 速度や残り時間の表示
- 元のURLへのアクセス
- 進捗追跡と中断ダウンロードの自然な再開
- このアプリは手動ダウンロードリンクを提供するだけでも、South Poleの利用者にとって大きく改善したはずである
- 別のアプリの自動アップデータにはキャンセルボタンと視覚的な進捗表示はあったが、一時停止、数値進捗・速度、元URLへのアクセス、再開機能が不足していた
- Microsoft Office for Macの自動アップデータは、South Poleでも良い事例だった
- 一時停止ボタン
- キャンセルボタン
- 進捗表示
- 速度と残り時間の表示
- 中断ダウンロードの自然な再開
- 元のURLを提供していればさらに良かったが、インターフェースは十分に良く、South Poleでも実用的だった
遅いインターネット利用者のための実務的な設計原則
- 高速インターネット環境では小さな欠落に見える機能も、遅いインターネットでは重大な障害になりうる
- アプリは、たった1つの固定タイムアウトのせいでユーザーが数バイトのテキストすら送れないループに陥らないよう設計されるべきである
- ありうる設計原則は単純である
- バイトが動いているなら中断しない
- 大きなペイロードはチャンクに分ける
- 失敗しても進捗を保持する
- ネットワーク状態をユーザーに明確に示す
- 内蔵ダウンローダーが不十分なら手動ダウンロードリンクを提供する
- South Poleはエッジケースではあるが、海上船舶のInmarsat環境、山岳研究拠点のThales MissionLinkやIridium Certus、不安定なWi‑Fi、設定不良のルーター、品質の低いWISP、古い電話線ベースのダイヤルアップ利用者も同様の制約に直面しうる
- 開発者があらゆる極端な状況を最適化する必要はないが、製品が遅い接続の利用者の進行を積極的に妨げないようにする努力は必要である
1件のコメント
Hacker News のコメント
この記事はかなり刺さった。南極ではなく北京にいるのだが、インターネットには今も苦労している
グレート・ファイアウォールの内側にいると創意工夫が必要で、VPN もたまにしか動かない。VPN ごとに痕跡が残るため、ファイアウォールのヒューリスティックや機械学習にいずれ検出されるし、国家が認めた VPN でさえ、政治的に敏感な時期には「穏やかに」制限される
結局つながっても安定せず、貴重なパケットを役に立たない Web アプリ／React の往復リクエストに浪費するのが本当に苦痛
一部の開発者は 2005 年ごろにタイムトラベルして、その時代の基準で開発してみないと、軽く作る方法を学べないのではないか。タイムトラベルが無理なら、せめて開発者ツールの速度制限を有効にして 3G に設定し、自分の Web アプリが耐えられるか確認してほしい
いつもプロジェクトを限られた帯域幅でテストしていた。アクセシビリティと同じで、良いプラクティスに従えば、接続の悪いユーザーだけでなく、すべてのユーザーにとってより良いユーザー体験になるからだ
よく見落とされるもう一つの機会は、シングルページアプリをオフラインファーストにすること
全体の趣旨に必ずしも反対しているわけではないが、現代の JavaScript はサーバー・クライアント型の「アプリケーション」で遅いインターネットに対処するうえで、実際にはかなり優れている。ただし簡単ではなく、Google/GPT でコーディングする人がプロジェクトの土台にできるようなオンライン資料はほとんどない
これはオンライン上にひどい JavaScript 資料が多すぎるせいでもあるが、こういうやり方で働いている組織が共有しない影響も大きい。私たちも競合に情報を渡す理由がないので、作業方法に関する公開資料は 0 件だ
何にでも往復リクエストを使うことを前提にした技術で、無駄な往復を減らす面白い訓練になる
今でも 1〜10Mbit/s くらいは出ており、だいたい時間帯によって変わるが、接続の問題はほとんどない
地下公共交通機関での通勤経験が多く（断続的・混雑）、オーストラリアで暮らして働いたこともある立場から、「理想的な」ネットワーク条件でない人たちにとって、ほとんどのサービスはひどいと自信を持って言える
London Underground では、ほとんどのアプリが約 2 分ごとに切れてはつながるネットワークを本当にうまく扱えないことが特に目立つ。駅間で切れ、乗客 500 人を乗せた列車が同時に接続しようとするため、各アクセスポイントにつながるだけでも 15 秒ほどかかる
オーストラリアでは、基本的にあらゆる場所から200ms離れている。大したことではないように見えるかもしれないが、どのアプリが N+1 リクエスト問題につまずくかを非常によくあぶり出す
いつも感心する唯一のアプリは WhatsApp だ。再接続後に最初に動き、切れる直前まで最後までトラフィックを通し、レイテンシがあっても通話がかなり速く感じられる
WhatsApp は実際にオーストラリアにサーバーをデプロイしている珍しいサービスの一つである可能性が高い。200ms は大陸間トラフィックであることを示す強いシグナルに見える
ほとんどのグローバル企業は、多くても 3 地域、つまり米国（us-east、us-central、us-east+us-east）、欧州（west-europe）、そして比較的まれに極東（us-west または日本）にしかデプロイしない
そのため南アフリカ、南米、オーストラリアのような場所では、通常これらの地域のどれかからデータを取得する必要があり、物理的な限界によって最低でも 200ms のレイテンシが生じる
オーストラリアは特に影響が大きい。理論上は管轄内に専用デプロイがあっても、実際のサーバーがまったく別の大陸（米国西海岸や日本）にあることが多く、ユーザーはパケットが地球を半周することによる性能への影響をそのまま受ける
そうした視点が開発目標に深く組み込まれていたからこそ、WhatsApp が世界各国で代表的なメッセンジャーになった十分な理由があるのだと思う
ブラウザで .jpg URL を開いて画像を見ようとすると、termux に切り替えて
wgetを実行するよりはるかに時間がかかり、時にはタイムアウトする。Firefox と Chrome 系ブラウザの両方で経験したちなみに
wgetのダウンロードでも、モバイル接続では通常 10〜30 秒かかるBerlin がなぜこうしたのか理解できない。単に列車内にインターネットを提供すればよいのに
ネットワークが絶えず切れると、インターネットの大半は本当にひどい動作になる
旅行することが多いが、遅いインターネットはかなりよくある。今もモバイルデータを使い切って、8kbpsに制限されている。
単にページにテキストだけがあるWebサイトなら速いはずだが、そうでないところが多い。Hacker Newsはものすごく速いが、Google APIドキュメントはまったく開かない。
いちばん悪い問題は、ほとんどのUIが遅いリクエストを考慮していないことだ。ボタンが壊れているように感じられ、メガバイト単位のデータが必要ないはずのものでも読み込みに数分かかったり失敗したりする。Google MapsのUI全体が壊れる。
開発者には、遅いインターネットをもっと設計・テストに取り入れてほしい。現実には、速い会社支給ノートPCと高速インターネットでだけうまく動く、データ食いのWebサイトが生まれている。
関連して、Webサイト運営で生計を立てているが、静的サイトジェネレーターへ移行したのは生産性の面で最高の選択の一つだった。CMSの遅延があらゆる作業に染み出す代わりに、完全オフラインでもテキストファイルを非常に高速に編集でき、オンラインになったら変更分だけpushすればよい。状況が一変した。
最近は、スマートフォンにGoogle Mapsのキャッシュを500MBダウンロードしても意味がないように思える。相変わらずすべてを取りに行き、後から遅れて表示される。
最新版のWordPressを使っていなかったという理由で、現在、自分のドメインの一つが「危険」と表示されている。
基本的に送られるすべてのリクエストがAppEngineアプリに届き、そのアプリがPythonコードを実行してHTMLを返す。だから速そうに見えるはずなのに、実際にはそうではない。
英国にいるが、news.ycombinator.comまでのpingは147msだ。CDNを使わず米国でホストされているためだと思われる。
一方でcloud.google.comのpingは8msだ。
Hacker NewsはシンプルでJavaScriptの少ないページだが、地域によってはユーザーに遅く感じさせる別の要因もあり得る。上下対称8Gbpsを提供するXGS-PON光回線を使う恵まれた環境でもそうだ。
氷床から降りてきたばかりの人をヒッチハイク中に乗せたことがあるが、彼が言うには、そのブログ執筆者は文章は素晴らしいものの、画像アップロード中に、もともと限られている帯域幅を食い潰すことが多く、周囲の人たちからある程度嫌われていたらしい。
ただし、管理側が広報価値を認めていたため、優先権を得ていたという。遅いインターネットの議論とうまく重なる話だと思った。
ポケットの中のスマートフォンが不要に利用可能な帯域幅をすべて使っているかもしれないし、720p動画を見ていてなんとか再生できる程度だとしても、その後ろで読み込もうとしている人は480pすら見られないかもしれない。本人にはバッファがあるので気づかず、相手はバッファが十分たまる前に諦めてしまう可能性がある。
少なくとも、直近1時間のトラフィックのうち何％が自分に向かったのか、そして利用可能帯域幅を接続ユーザー数で割った基準値と比べ、全員が同等に必要としていたなら自分の取り分は何％だったのかを知らせる使用量会計があるべきだと思う。
さらに、「はい、今後[X≤24]時間で使う帯域幅を把握しており、実際に必要です」というボタンを押すまでは全員を低い優先度にしておき、押したらMAC/IPアドレスのQoS優先度を通常に上げるシステムも可能に見える。
こうした状況は、ローカルファーストアプリケーションと解決策が必要だと叫んでいるし、そもそもインターネットが作られた理由もその方向にある [1][2]。
人々はSalesforceの「No Software」という広告文句にだまされたが、これはインターネットの基盤と精神に真っ向から反している。1969年からのインターネット史の大半において、Mbpsは例外であって標準ではなかったし、最初のキラーアプリであるメールメッセージングは（おそらく今でも最高のインターネットアプリだが）ローカルファーストだ [3]。
皮肉なことに、筆者が嘆いていた問題のアプリケーションもメッセンジャーアプリだ。
[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...
数年にわたってネットワーク関連の作業を多くしてきて、自分なりの「遅いインターネット」環境を動かすのに時間を使ってきた。McMurdoほど興味深くはないが、国際線の飛行機、辺境を走る列車、ひどい田舎のホテル、トンネルの中でもチャットしたりYouTube動画を見たりしていた
汎用コンピューティングデバイスにアクセスでき、電力もまかなえて（こうした機器は電力をかなり食う）、自分で作る気があるなら、NNCPをおすすめする [1]。NNCPはデータを受け取り、分割して送信できる。TCP上でnoiseを使う同期プロトコルも含まれており、失敗した断片をリトライしながら送る。TLSが不要なので、接続確立は1.5 RTTで済む
NNCPはデータを標準入力としてリモートプログラムに渡せる。YouTubeダウンローダー、Slackボット、Telegramボット、Discordボットを作って、入ってくるデータを読み取り、それぞれのサービスとやり取りさせた。ローカルマシンにはMatrix（Dendrite）サーバーとボットを立てておき、NNCP経由で適切なリモートサービスへデータを送る
経路上のMTU/MSSはできるだけ低くしてTCPレベルの再送が頻繁に起きられることを望む、あるいは実験してみる必要があるが、この構成はどこへ行ってもほとんど失敗したことがなく、メディア消費とチャットを可能にしてくれる
国際線でいちばん腹立たしい点は、NNCPエンドポイントが地理的に分散していないことだ。飛行ルートと、エンドポイントまでパケットが実際に通る経路によって、レイテンシとジッターが大きく増えることがある。通常は目的地の近くにNNCPエンドポイントを置こうとするが、機内Wi‑Fiでは実際の経路がひどい場合がある。NNCPはいまではYggdrasil対応があり、これを緩和し、MTU問題の制御にも役立つ可能性があるが、こうした条件でYggを使ったことはない
[1]: http://www.nncpgo.org/
南太平洋の船上で、投稿者と似た経験をした。Starlinkはあったが消費電力が高く（60W以上）、あまり頻繁には使わなかった。代わりに現地のSIMカードを買い、場所によっては4G、場所によってはEDGE（2G）を使った
EDGE自体は仕様上はそれほど悪くない。毎秒数十キロビットは出る。実際にはずっと悪かった。読み込みがミリ秒ではなく数分かかる可能性があることだけ考慮していればうまく動いたはずのアプリが、短いタイムアウトのせいで失敗するのを経験した
低帯域・高遅延の接続は、ソフトウェアの定期テストに含めるべきだ。Linuxにはそれを可能にするnetem（https://wiki.linuxfoundation.org/networking/netem）がある
匿名のブログ筆者にはなかった問題として、従量課金の接続があった。費用のため、OSやアプリのアップグレードはほとんど不可能だった。幸い、数週間に一度は無制限接続のある場所に到着し、そうした作業ができた。その代わり、複数のOSで接続を従量制／非従量制として表示し、自動更新をすべて切って、貴重な帯域を節約する方法には非常に詳しくなった
それに「現地のSIMカード」ということは、そのSIMを買いに島へ上陸したという意味だろうが、2020年代にどこで2Gしか使えなかったのか気になる。南太平洋にまだそんな場所が残っているとは信じがたい
視点を保つべきだ。プロジェクトによっては、複数ブラウザでWebアプリをテストすることすら無駄で、正当化できないコストだとして省く。テストマトリクスに入れるのが些細で、UIだけの問題であってもそうだ
遅いインターネットを考慮したエンジニアリングは今でも本当に重要で、ほとんどのソフトウェア開発者に大きく過小評価されていると思う。ただし、低軌道衛星システム（Starlink、特に Starlink）は、いまや中核的な問題を事実上解決している
2023年9〜10月に北極航路（アラスカからノルウェー）を通ったが、北極圏のはるか上の船上でも、雲や陸地からの距離、氷があるにもかかわらず FaceTime のビデオ通話ができた。筆者が南極にいた時期と同じだ
制約が何であれ、結局はサービス契約と端末を現地に持ち込む問題だ。極地のカバレッジは相対的にはまばらだが、人口が極端に少ないので、それでも十分だ
https://satellitemap.space/
遅いインターネットには複数の意味があり、その一つは接続の問題だ。TCP のようなコネクション指向プロトコルでは、パケットロスによって遅くなるということであり、UDP のような投げっぱなしのプロトコルでは、メッセージが届かないという意味になる。したがって「遅い」とは低い転送速度の場合もあれば、一瞬高いスループットが出たあとに短く途切れる形の場合もある
遅いネットワークに対処する堅牢なアプローチの一つは、オフラインモードのサポートだ。すべてのデータの push/pull を非同期トランザクションとして設計し、データの push はローカルにキャッシュして、可能になったときに再試行する方式だ。そうすると、バージョン管理や競合解決といった追加要件が生じる
自然に UI 要件も増える。手動同期/更新、ネットワーク状態の表示、ネットワークが切れたときに意味のない操作を無効化すること、オフラインでも使えるように先読みしておくことなどが必要になる
いつか遅いインターネット後の世界で暮らしたいが、まだ何年も先だ。ちなみに XS は、その時代の Qualcomm フラッグシップより劣るとされていた Intel モデムを搭載していた
世界で最も人口密度が高い場所の一つに住んでいて、5G アンテナと Wi-Fi ステーションは大量にあるが、雑に作られたウェブサイトが遅い接続や断続的な接続で倒れるのは今でも実感する
静止軌道衛星は Pole からだと地平線に近すぎるため、極地カバレッジが制限される。Pole では燃料が少なく軌道傾斜角が比較的大きい古い静止軌道衛星を使っており、そのため24時間のうち約6時間しか通信できない
スケジュール: https://www.usap.gov/technology/1935/
政府は、検閲されていないウェブや、米国企業がインターネットのゲートウェイになることを望まないだろう。今持っている領土内のネットワークを維持するはずで、速度の問題は引き続き有効だ
世界中には、インターネットへのアクセス手段が、古いソフトウェアと限られた CPU を搭載した100ドルの Android フォンだけという人たちもいることを考慮すべきだ
遅いネットワークでユーザー体験を改善できる、効率的な状態同期のために HTTP を拡張する IETF 草案提案がある: https://news.ycombinator.com/item?id=40480016
Braid Protocol は、複数の同期アルゴリズムが共通のネットワークプロトコル上で相互運用できるようにし、どの同期器のネットワークメッセージもその上へ変換できる。現在の Braid 仕様は HTTP に2つの同期次元を追加する
Level 0: 現在の HTTP
Level 1: push 更新のある購読
Level 2: P2P 一貫性（パッチ、バージョン、マージ）
現在の同期器はそれぞれ異なるプロトコルを使っているが、ネットワークメッセージは同じ種類の情報を運ぶ。時間上のバージョン、空間上の位置、時間範囲にわたる空間領域のパッチだ。任意のパッチ集合の合成は braid という数学的構造をなす。時間に沿った空間の分岐、マージ、並べ替えである
希望は永遠に湧き続ける
ラウンドトリップを減らし、膨れ上がっていないものを作るのは難しくなく、むしろずっと簡単だ。肥大化はまったく別の理由で存在している
ときには、データセンターに近い高速インターネットと余裕のあるマシンでは、肥大化が目立たない。簡単にシミュレーションできるが、会社が気にかける必要がある。概して広告技術とその周辺は、小さなユーザー集団にはほとんど関心がない。実際、エンドユーザーに関心を持つ唯一の理由も、彼らが本当の顧客、つまり広告主に売上をもたらすからだ
アプリやウェブサイトなどを作る私たちは、自分たちが使っている高速 Wi-Fi や光回線につながっていない人が多いことを忘れてはいけない
英国では一部の通信事業者が3G の終了を始めた。場所によっては低電力の代替手段として 2G を残すが、今後は 4G/5G を使えということだ。問題は 4G がまだどこでも使えるわけではなく、少し前までは一部地域では 3G の電波だけがまともだったことだ
そのため、望まずに 2G/EDGE に落ちることがより頻繁になり、多くのものが単に止まってしまう。多くのアプリは、遅く、レイテンシが高く、パケットロスが大きいシナリオでテストされていない
2G で Google Maps を使って道案内を試せば答えが分かる :(