在「Engineering for Slow Internet (brr.fyi)」這邊看到的，這幾天還蠻紅的文章，在講網路受限的情況下要怎麼想辦法：「Engineering for Slow Internet」，作者是南極洲計畫 (USAP) 的 IT (目前已經回美國本土)。
主要的技術限制有幾個，第一個是對外網路的時間是有限的，因為受限於經過上空的衛星是有限的，這是 2023 年十月的一些資料：
可以看到主要是 DSCS (五顆服役中，但不是每科都有經過南極上空) 與 TDRS-6。
這個是物理限制，沒有 workaround 可以做，所以所有人都得照著對應的時段安排傳輸。不過應該有其他的衛星可以隨時聯絡 (emergency channel)，畢竟算是半個軍事計畫？
Hacker News 上也有人討論到 Starlink 好像還是有一些衛星會飛過南極洲，但不確定是否有 relay 的能力，如果有的話似乎也能考慮看看？(不過可能會需要客製天線，畢竟緯度的關係，設備需要的工作溫度區間不太一樣)
另外一個大問題是 latency，平均的 latency 是 750ms，而且 jitter 會到數秒：
Round-trip latency averaging around 750 milliseconds, with jitter between packets sometimes exceeding several seconds.
第三個是速度，一般使用者的平均網路速度大約是個位數的 kbps 到狀況好的時候大約是 2mbps，差不多是 1990 年代數據機的速度：
Available speeds, to the end-user device, that range from a couple kbps (yes, you read that right), up to 2 mbps on a really good day.
文章基本上就是圍繞這些問題在討論。
因為 latency 過高，而很多應用程式 (web 或是 app) 寫死 timeout，所以造成網路明明就有慢慢在傳輸資料，你放著慢慢傳遲早會傳完，但卻因為超時而失敗。
另外因為頻寬有限的問題，沒有提供續傳機制 (app 裡面沒做，或是沒有提供檔案直接讓有技術能力的人下載，像是 wget -c 這樣的工具) 就很容易因為失敗浪費頻寬。
另外是遇到軟體更新機制 (像是安全性更新) 無法下載檔案後直接安裝，都會有裝到一半中間要連網的事情。
另外一塊是現在太多工具太肥大，一個簡單的功能要先下載一包 20MB javascript 之類的 (然後換算一下前面提到的頻寬，在網路最好的情況下得花 80 秒下載這包 javascript)。
如果你的使用者族群包括了這類網路狀況不是很好的地區，這篇提到的蠻多東西都還蠻值得參考的。
