大家好！我写这篇文章的时候还在南极洲，但在完成之前我就离开了。

我在整理旧草稿时，发现这篇文章几乎已经完成。

这篇文章与brr.fyi上通常的内容有些不同，但它反映了我的软件/IT工程背景。

我希望人们发现这是对在带宽受限环境中使用互联网的现实情况的有趣一瞥。

请注意，我大约在7个月前写了这篇文章的大部分内容，所以IT环境可能已经发生了变化。

欢迎回来，特别增加一篇关于为慢速互联网的工程化的帖子！

在我在南极洲工作的14个月期间，我只能通过美国南极计划提供的极其有限的一系列卫星链路访问互联网。

在我进一步讨论之前，这篇文章需要一个特别的警告，超出了我通常的免责声明：

尽管我是美国南极计划内的IT工作者，但我在这篇文章中讨论的所有内容都是基于公开可获得的信息，或者基于我作为生活在冰上的普通参与者自己的观察。

我没有在写这篇文章时使用任何内部访问或非公开信息。

作为我的雇佣条件，我同意了一套关于公开披露非公开信息技术材料的限制。我完全打算遵守这些限制。这些限制是普通且典型的美国政府合同工作的一部分。

我不太可能能够回答我在这篇文章中讨论的问题。我已经非常小心地写了我能够写的尽可能多的内容，没有透露有关政府IT系统的非公开信息。

好的？我们开始吧。

…实际上等等，对不起，还有一个免责声明。

这些信息反映了我在南极洲的个人经历，从2022年8月至2022年12月在麦克默多，然后是从2022年12月至2023年11月在南极点。

技术发展迅速，我不认为我自己的特定经历的情况会随着时间的推移而持续。在未来的年份里，一旦我早已忘记了这篇文章，请不要让我对南极洲的IT体验从这里展示的快照演变感到生气。

好的，终于开始了。

在南极点获得任何互联网都不是一件小事！如果你感到无聊，可以查看公共USARP.gov网站上的南极点卫星通信页面，了解一下极地使用的有限的卫星选择。

如果你感兴趣，也许还可以看看2021年南极海底电缆研讨会，了解一下与在大陆上运行传统光纤相关的一些障碍。

我绝对没有权威去推测南极洲连通性的未来！ 说真的。我是一个大型、复杂组织中的低级、季节性IT工作者。不要给我发邮件，告诉我你改进南极洲互联网接入的想法——我没有办法处理它们。

我同意大家对这个问题的普遍共识：对改善美国南极研究站的连通性有极大的兴趣。我会谨慎地推测，总有一天，会有工程解决方案来解决这些问题。改进的连通性最终会到达南极洲，无论是通过增强的卫星技术还是通过大陆上光纤的到来。

但是——那个世界只会在未来的某个时候存在。目前，南极洲的连通性极其有限。我所说的是什么意思？

直到最近，在麦克默多，几乎一千人，加上许多科学项目和运营工作量，都依赖于一系列链接，这些链接为整个站点提供了几十兆比特每秒的最大聚合速度。相比之下，这比每个人单独在美国郊区典型的4G蜂窝网络上可以获得的带宽合计还要少。

情况正在好转！NSF最近宣布了一些关于麦克默多和帕尔默的Starlink的重要发展。

我知道麦克默多和帕尔默的实地体验现在比一年前好多了。

但是——截至2023年10月，南极点的情况仍然相当糟糕。据我所知，关于Starlink的类似发展尚未宣布给南极点站。

截至2023年10月，南极点有上述限制，加上只有当卫星在地平线以上升起，站点被授权使用它们时，一天只有几个小时的连通性。由于恒星时间和太阳（民用）时间之间的差异，卫星时间表通常每天向前（更早）移动约4分钟。

当前的卫星时间表可以在线找到，在公共USARP.gov网站上的南极点卫星通信页面上。这是2023年10月两周的时间表示例：

_南极点卫星时间表，2023年10月的两周。

这些与外界的小间歇性链接由极点的所有人共享，用于运营、科学和社区/士气使用。

使问题更加复杂的是这种连通性的不可避免的物理特性。这些卫星在高轨道上，数千英里高。这意味着高延迟。如果你使用过像HughesNet或ViaSat这样的消费级卫星产品，你会理解。

从我在南极点的舱室，大约750毫秒往返，数据包才能到达和来自美国的地面目的地。这大约是美国东西海岸之间往返延迟的十倍（高达75毫秒）。而且这是你家中的有线或光纤连接到大多数主要内容分发网络的健康连接的预期延迟的三十倍（高达25毫秒）。

说真的，我无法强调这有多令人震惊。在我家里的公寓里，在GPON光纤上，到Fastly、Cloudflare、CloudFront、Akamai和Google的往返大约是3毫秒。在南极点，延迟超过二百五十倍。

我无法更深入地讨论USARP如何进行优先级排序、整形等，因为我没有被授权分享这些细节。可以说，如果你是一个习惯于在带宽受限环境中工作的企业网络工程师，你会对用于管理南极连通性的设备、工具和技术感到宾至如归。

任何个人如果想在2023年10月的南极点使用互联网进行社区使用，可能面临：

• 平均大约750毫秒的往返延迟，数据包之间的抖动有时超过几秒钟。
• 对最终用户设备可用的速度，从几kbps（是的，你读得对）到非常好的一天的2mbps。
• 极端的拥塞、排队和数据包丢失，远远超过即使是在家里最糟糕的过载ISP链接或受缓冲膨胀影响的路由器的数据包丢失。
• 有限的可用性，频繁的中断和偶尔的服务优先权。

这些限制极大地影响了现代网络体验！有些是不可避免的。上面描述的链接特性确实非常糟糕。但是——很多最终用户的影响是由未能考虑到慢速/间歇性链接的网络和应用程序工程引起的。

如果你是一个应用程序开发者，你能告诉我，你的应用程序在40kbps可用带宽、1000ms延迟、偶尔高达2000ms的抖动、10%的数据包丢失和每几分钟完全15秒的连接中断的链接上表现如何吗？

可能不太好！然而——这就是我在南极点遇到的现实世界性能参数。通常比这更好，但这种情况确实发生，而且发生的频率足够高，值得认真对待。

当您在南极点有一个小小的管道供高优先级运营需求以及数十个社区用户共享时，就会发生这种情况。运营需求被积极优先考虑，社区则吸收剩下的所有资源。

我在这里不是期待奇迹！显然，没有任何客户端工程可以使实时视频会议在这些条件下工作。但是——进出一些文本字节应该仍然可能！我知道这是可能的，因为一些应用程序仍然可以做到。其他的则不行。

详细，现实世界的例子

一天在南极点，我试图在浏览器中加载$enterprisecollaborationplatform>的网站。它太大了！它需要加载将近20MB的Javascript，仅仅为了渲染主屏幕！当然，自上次加载以来，该应用程序已经更新了，所以我浏览器的所有缓存资产都已过期，必须重新下载。

好的！它很慢，但至少最终会工作…对吧？浏览器在处理慢速互联网方面做得相当不错。在幕后，底层协议在拥塞控制方面做得相当不错。我应该得到稳定的数据涓涓细流。这将受到客户端和服务器之间协商的发送和接收窗口的影响，这些窗口基于链接上的当前拥塞水平，并且受到中间件沿途进行的任何整形的进一步影响。

这是一个复杂的Web应用程序，所以应用程序开发者还需要实现他们自己的一些重试逻辑。这允许在个别资产失败时恢复，特别是对于长时间的多秒总连接中断。但最终，只要有足够的时间，传输应该完成。

不幸的是，这就是事情崩溃并变得非常烦人的地方。开发者在应用程序中某个地方实现了一个全局失败触发器。如果应用程序没有在开发者指定的参数内完全加载（时间？重试次数？我不确定。），那么应用程序停止，放弃，将你重定向到一个错误页面，放弃了你已经取得的所有加载进度，并对下次重试实施了积极的缓存破坏对策。

_应用程序加载不够快，开发者决定应用程序应该放弃而不是继续缓慢加载。

我无法告诉你这有多令人沮丧！南极点的连通性永远不会满足使用强大地面互联网连接的工程师设定的性能期望。硬编码一个单一的、静态的、全局的期望，即20MB的Javascript应该花多长时间下载，这不是一个好主意。为什么不让我按照自己的节奏加载呢？当我到达时我会到达。_只要数据还在移动，无论多慢，就让它运行。

但是——开发者决定，如果应用程序没有在他们设定的参数内加载，我就根本不能使用它。并且要明确——这主要是一个消息应用程序。当应用程序运行并且我与朋友聊天时，实际的内容负载以字节为单位。

事实证明，我们在南极点的互联网性能正是应用程序开发者认为“可接受”的边缘。所以，如果我不断重新加载页面，如果我不断让它重新下载相同的20MB的Javascript，如果我不断忍受开发者的缓存破坏花招，最终它会在人为的失败标准之前完成。

这意味着我浪费了额外的带宽进行所有这些无用的重新加载，而且有时需要几个小时才能使用该应用程序。尽管如此，如果顺其自然，我可以在15分钟内完成必要的数据传输。几个小时（和羞耻的数量的重试Javascript）之后，我终于能够向朋友们发送一个简短的基于文本的消息。

_经过大量重试后，Web应用程序加载成功。809个HTTP请求，51.4MB的数据传输，加载时间为26.5分钟…

_…所有这些都是为了我可以发送一个1.8KB的HTTPS POST…

_…包含一个6字节的消息。

这个Web应用程序真的需要是20MB吗？所有加载的内容中有哪些可以推迟到需要时再加载，或者包含在“可选”的附加包中？是否有一个“精简”版本，适用于带宽受限的用户？

在我在南极洲的14个月里，我收集了几十个这样的应用程序的例子，它们内置的人为限制使它们变得不可用或几乎不可用。

在这篇文章的其余部分，我将概述我的一些主要挫折，并说明我原本希望看到的可以缓解问题的情况。

我理解并不是每个应用程序都能够实现所有这些！如果你是一个刚刚起步的小应用程序，我不期望你把所有的开发时间都花在为南极洲的怪人优化上。

是的，南极洲是一个边缘情况！是的，750毫秒/10%的数据包丢失/40kbps确实相当极端。但南极点并不是特别糟糕。还有一些商业船只完全依赖于旧的Inmarsat解决方案，在海上时只有几百宝贵的kbps数据。现在有人在深山中的偏远研究站，试图使用Thales MissionLink通过Iridium Certus网络以几十kbps的速度加载你的应用程序。有些人背后是配置错误的路由器，有些人有不稳定的wifi，有些人被困在提供劣质服务的临时WISP上。还有一些人仍在使用退化的铜电话线上的拨号互联网连接。

这些人值得你考虑。至少，你应该努力避免积极干扰他们使用你的产品的能力。

那么，不再多说，这里有一些在南极点经常让我感到痛苦的开发模式的例子。

硬编码超时，硬编码块大小

如上例所示，不要硬编码你关于给定负载需要多长时间传输，或者你可以在单个请求中传输多少的假设。

1. 如果你有能力测量字节是否在流动，并且它们在流动，就随它们去，不管多慢。也许可以显示一些UI来指示正在发生什么。
2. 如果你正在进行HTTPS调用，如果调用失败，可以回退到更长的超时。也许在当前网络条件下，它只是需要更多时间。
3. 如果你在单个HTTPS调用中传输大量数据有困难，就把它分解。将内容分成小块，一次传输小部分，并勤奋地跟踪进度，以允许恢复和重试小部分，而不会丢失迄今为止的所有进度。缓慢、稳定、逐步的进展比一次性尝试传输大量数据要好。
4. 如果你不能成功完成HTTPS调用，做一些故障排除。尝试DNS、ICMP、HTTP（不带TLS）、HTTPS到已知的良好状态端点等。这些信息可能有助于故障排除，而且比盲目重试相同的端到端HTTPS调用要好。这个HTTPS调用需要很多幕后的东西正常工作。显然它没有，所以你应该努力找出原因并让用户知道。

示例1 - 应用程序内元数据下载

一个流行的桌面应用程序试图在启动时从供应商的网站下载一些配置信息。HTTPS调用有一个硬编码的超时。如果失败，应用程序将无法加载。 它只会不断地用相同的参数重试相同的调用，永远。它会停留在加载页面上，不告诉你出了什么问题。我通过阅读日志确认了这是正在发生的事情。

_商业桌面应用程序的调试日志摘录，显示请求在15秒后超时。

幸运的是，如果你不断尝试，调用最终会在我在南极点经历的网络条件下通过。

令人沮丧的是，只是一个硬编码的超时值，在其他方面完全功能正常且企业级的应用程序中，可以使它几乎无法使用。开发者本可以：

1. 回退到越来越长的超时，尝试获得成功的结果。
2. 进行一些连接故障排除，以推断出当前网络环境的更多信息，并相应地做出响应。
3. 显示UX来解释正在发生什么。
4. 如果无法获得实时配置，使用缓存或默认值配置，而不是简单地拒绝加载。
5. 提供一种机制，让用户手动下载并安装所需数据，绕过应用程序内置的（和天真的）下载逻辑。

示例2 - 聊天应用程序

一个流行的聊天应用程序（“应用程序#1”）维护一个websocket来发送和接收数据。该websocket初始化过程使用了一个硬编码的10秒超时。在冷启动时，当网络条件特别拥挤时，websocket设置有时需要超过10秒！我们必须完成一个完整的TCP握手，然后设置TLS会话，然后设置websocket，然后在websocket上进行初始信号传输。记住 - 在某些条件下，南极点的每次单独往返都需要几秒钟！

如果10秒超时到期，应用程序就根本无法工作。它会进入一个非常长的退避状态，然后重试。UX并没有清楚地显示正在发生什么。

_聊天应用程序#1的调试日志摘录，显示硬编码的10秒超时。我们确实在这个时候有互联网接入 - 它只是太拥挤了，无法在这个时间框架内完成整个TCP握手 + TLS协商 + websocket设置 +请求。再过几秒钟，它可能就完成了。

另一方面，竞争对手的聊天应用程序（“应用程序#2”）在极其退化的网络条件下做得非常好！它有多种策略来发送网络请求，以抵御某些类型的退化。它积极重用开放的连接。它动态调整超时。在失败的情况下，它智能地选择重试节奏。而且，在整个过程中，它都有清晰的UX来解释当前的网络状态。

最终结果是，我通常可以在我无法使用应用程序#1的网络条件下使用应用程序#2。它们都只是传输纯文本！只是几个实际的字节内容！即使当我无法使用应用程序#2时，它至少告诉我它正在尝试做什么。应用程序#1写得天真，内置了关于连通性的假设，在南极点根本不成立。应用程序#2写得好，它对遇到的野外条件做出了优雅的响应。

示例3 - 增量传输

有机会谈谈我自己的博客发布工具链！

你现在正在阅读的网站是一个静态的Jekyll博客。资源存储在S3上，并通过CloudFront提供服务。我在笔记本电脑上本地构建静态文件，然后直接上传到S3。没什么花哨的。没有服务器，没有QA环境，没有构建系统，没有自动钩子，没有动态的东西。

鉴于南极点的极端连通性限制，我编写了一个Python脚本，用于在具有挑战性的环境中发布到S3。它使用S3 API以小部分上传资源。它检测并恢复失败的上传，而不会丢失进度。它等待一切安全上传后再发布新版本。

如果我能做到这一点，作为一个无偿、单独工作的人，为我的小小爱好博客，在200行Python中……那么你的工程团队肯定能做到这一点，为你们的旗舰Web应用程序。

通过一些积极的工程，可以带来惊人的可用性改进。我在极点有博客的朋友，他们经常在商业平台上分享大文件到社交媒体。他们必须仔细安排他们的一天，以最大化在卫星窗口期间成功“一次性”上传的可能性，使用他们平台的工程不良的发布工具。通常需要几次重试，整个过程中的每一步都不总是清楚的（内容是否实时？上传完成了吗？可以安全地/我应该再次点击“发布”吗？）。

与此同时，我能够收集我能找到的任何连通性。我在这里和那里上传了几千字节，只要方便。如果一个特定的分块POST失败了，没关系！我可以稍后再试或恢复，损失的进度很小。一旦一切都完成了并且准备好了，我可以安全地发布新版本。

_我为这个博客定制的发布脚本，以处理间歇性和不可靠的互联网。

自带下载

如果你要在应用程序中内置下载器，你必须满足一个很高的质量标准。 否则，它将以极其烦人或灾难性的方式失败。

如果我要给出一条建议：让用户尽可能使用自己的下载器，而不是你的应用程序内下载器。

提供手动下载链接，理想情况下是链接到应用程序将要下载的任何差异补丁文件。不要因为应用程序内补丁下载器不能满足他们的需求，就惩罚用户下载完整的安装程序。

这有以下好处：

1. 如果你的下载器失败，用户仍然可以使用他们选择的更强大的下载器手动获取文件，例如网络浏览器。
2. 用户可以一次性下载文件，并与多个设备共享。
3. 用户可以在运行应用程序的计算机以外的计算机上下载文件。
4. 用户有灵活性，可以根据他们面临的任何限制来安排或管理下载。

为什么在考虑南极点的用户时，这一切都如此重要？

在南极点下载是可能的，但它们受到独特的限制。最大的限制是没有24x7互联网。当我在那里时，我知道我们会在特定时间失去互联网访问！

这是一个令人沮丧的现实：对于大多数执行自己下载的应用程序，我们对这种已知的连通性中断无能为力。我们只能坐在那里看着它失败，经常看着所有的进度丢失。

假设我每天有一个4小时的窗口，在这个窗口期间我可以进行（非常慢！！）下载。如果在这4小时内我可以下载的总数据量少于我正在下载的有效载荷的总大小，那么我就无法一次性完成下载！我必须将其分在多个互联网窗口中。通常应用程序不会让我这样做。

更不用说访问在那段时间内可能是不可靠的！如果底层连接断开了，我必须重新开始下载怎么办？如果我的计划变了，我需要暂停怎么办？我不想浪费到目前为止所取得的任何宝贵进展。

许多现代应用程序都包括自己的自制的、手工制作的、应用程序内的下载器，用于大型负载。通过“应用程序内下载器”，我指的是用于自动更新、补丁、内容数据库更新等的系统。这里的共同主题是应用程序透明地为您下载内容，而您不会被暴露到底层细节，如URL或原始文件。这包括UI模式，如检查更新、点击此处下载新版本等。

_一个流行的聊天应用程序的应用程序内下载通知。这个应用程序显然想要在后台下载83MB的数据！这在南极点很难。UI会适应极点的独特限制吗？

不幸的是，这些应用程序内下载器大多数都没有为任务做好准备！它们中的许多缺乏暂停/恢复功能、状态通知、重试逻辑和进度跟踪。它们中的许多有令人沮丧的限制，如下载负载的时间限制。虽然这些问题在快速互联网领域只是小烦恼，但在南极点，它们可以使应用程序完全或几乎完全无法使用。

_不幸的是，这是一个响亮的“不”。没有速度指示，没有ETA，没有暂停按钮，没有取消按钮，没有URL指示（这样我们可以手动下载），也没有获取底层文件的方式。

面对这些界面总是令人沮丧，因为我知道将会浪费多少时间，以及数据传输。

_该死，失败了！这是意料之中的 - 一个不间断的83MB下载很难。不幸的是，所有进度都丢失了，现在它甚至没有提供重试的补丁 - 下载大小增加到了133MB，这是完整安装程序的大小。

每个包含应用程序内下载器的应用程序都必须与一个非常高的可用性标准竞争：网络浏览器。

想想看！每个现代网络浏览器都包含一个下载管理器，其中包含中止、暂停和恢复功能。它允许你重试失败的下载（假设内容URL不包括过期令牌）。它清楚地显示你当前的状态、下载速度和剩余估计时间。它允许你选择保存底层文件的位置，所以如果需要，你可以复制它。而且 - 它不包括任意的性能截止！如果你真的想以60kbps的速度下载一个多GB的文件，那就去做吧！

_来自主要网络浏览器的全功能下载体验。从供应商的网站下载应用程序安装程序。注意状态、速度、剩余估计时间、完整URL和暂停/取消按钮。

_上述下载的已部分下载的文件。

这里有一些应用程序内下载器给我们造成痛苦的更多例子。

示例1 - macOS更新

macOS更新的巨大规模众所周知。这有时即使在家里也很令人烦恼，在南极点情况更糟。

次要操作系统更新的补丁大小通常在0.5到1.5GB之间。主要操作系统升级补丁有时超过6GB。额外的工具，如Xcode，通常有多个GB。

_叹气，我在南极点的个人macOS设备上又有一个1GB的补丁。

如果南极点的每个macOS设备都直接从苹果下载这些更新，我们将浪费大量的带宽。而内置的macOS下载器当然希望我们这样做！看看这个界面 - 控件很少，没有办法突破并轻松获取底层补丁文件。如果我取消了下载，或者出于某种原因失败了，它并不总是智能地恢复。有时，我失去了所有的进度。

现在 - 苹果确实在macOS中内置了一个缓存服务器功能。从理论上讲，这应该可以减轻一些负担！我们应该能够利用这个功能确保每个补丁只下载到南极点一次，然后客户端Mac将击中缓存。

在我的业余时间，我用我的几个自己的苹果设备试验了这个功能。实际上，这个功能仍然要求每个客户端Macbook直接成功进行HTTPS调用到苹果，以协商缓存参数。如果这个调用失败了，它经常失败（因为硬编码的短超时！！！），那么客户端Mac就直接从公共苹果服务器获取补丁。没有重试，没有通知。客户端Mac单方面决定绕过缓存，没有任何追索权，甚至没有通知用户。实际上，在南极点，最初的缓存协商调用经常失败，以至于缓存功能没有用处。

我们能做的是，从苹果获取完整的安装程序（12GB！）。链接到完整安装程序包的链接方便地汇总在Mr. Macintosh博客上。我们可以缓慢而谨慎地将完整的安装程序下载到南极点：节流，以低背景优先级，使用强大、中断容忍的工具，支持缓存和暂停或失败传输的恢复。一旦我们有了文件，我们可以在站点上分发。这个过程可能需要几天时间，但是它是可靠的。

_精心而谨慎地下载到南极点的macOS完整安装程序。

但即使这样，也没有解决问题！如果客户端Mac是Apple Silicon，它仍然坚持直接从苹果下载额外的内容，即使你使用完整的、12GB的安装程序运行更新。没有办法绕过或缓存这一点。如果操作系统更新需要某些类型的固件更新或Apple Silicon Mac的Rosetta更新，那么每个Apple Silicon客户端Mac仍然会在安装过程中直接从苹果下载1-2GB的数据。

更糟糕的是，下载过程有时被外包给macOS的一个单独组件，该组件甚至没有向安装程序报告进度！在南极点安装macOS更新意味着盯着一个窗口说“安装中，剩余32分钟”，几个小时过去了，而macOS的一个子组件在后台下载一个无法缓存的千兆字节数据。

苹果天真地假设1GB的下载会如此之快，以至于他们没有费心将下载速度反馈纳入更新程序的时间估计。他们没有预见到人们会从一个地方安装macOS更新，那里的千兆字节下载可能需要几个小时，如果不是几天。

你不能缓存它，你也不能直接使用网络浏览器（或其他机制）下载它。你必须让苹果的下载器直接来做。当然，没有暂停按钮。这对用户来说是一个重大不便，也是对带宽的重大浪费，因为每个单独的客户端Mac都要一次性、不间断地下载1-2GB的数据。

苹果可以让用户明显更好的方法，对于慢速或以其他方式奇怪的互联网：

1. 计算所需的补丁，然后给我们一个下载链接，这样我们就可以在外面下载苹果的下载器。
2. 改进内置的更新下载工具，增加暂停/恢复功能和智能状态管理，以确保进度不会丢失。
3. 修复完整安装程序，使其包含所有内容，包括目前排除的所有项目，如适用于Apple Silicon Mac的固件和Rosetta更新。如果它包含了一切，那将更有用。我可以下载一次，然后分发，而不必担心每台Mac仍然需要从苹果获取额外的数据。
4. 改进苹果缓存服务器功能，使其在直接互联网访问不可靠的情况更加可靠。给我们更多的控制权，以便我们可以强制Mac使用它，并使缓存服务器能够主动下载我们知道将来需要的项目。

就目前而言，帮助南极点的人们进行macOS更新是一个巨大的麻烦。

示例2 - 三星安卓手机操作系统更新

我的三星安卓手机定期接收操作系统更新。这些更新包括相关的安卓补丁，以及三星UI和其他操作系统组件的更新。

更新程序是一个特别糟糕的例子，它没有考虑到慢速/间歇性互联网使用情况。

_在南极点为我三星安卓手机下载操作系统更新。

首先，基础情况。没有速度指示器，没有数字进度指示器（计算移动条上的像素真是好运气），没有暂停按钮，没有取消按钮，没有文件大小指示器，也没有获取底层文件的方法来单独下载。

其次 - 如果下载失败，它不能恢复。它将重新开始。

在实践中，在南极点，手机无法在单次卫星通过时下载整个操作系统更新。所以 - 它不可避免地会在连通性丢失时失败，我不得不重新开始。

我能够完成这个任务的唯一方法是在互联网访问丢失之前完全关闭手机，然后在下一次卫星通过时重新打开。这个技巧让手机在没有互联网的期间不会放弃下载，因为它完全关闭了。它从未有机会失败。通过这样做，我可以跨越多个卫星通过来分散下载，我能够完成下载。

这是一个荒谬的变通方法！我本不应该不得不这样做。

我的美国运营商（Verizon）确实提供了一个适用于macOS和Windows的可下载应用程序，理论上应该允许我从计算机上刷写操作系统更新，而不是依赖手机来下载补丁。实际上，Verizon应用程序更糟糕。错误多，不可靠，而且还坚持使用自己的应用程序内下载器来获取更新文件（叹……）。

我相信有一种方法我可以手动获取图像并刷写它们。这不是邀请一群安卓爱好者给我发电子邮件，解释引导程序和APKs和ROMs和侧载等等。那不是重点。重点是 - 供应商为慢速互联网用户所提供的主流工具完全不足，这很令人沮丧。

示例3 - 小应用程序自动更新程序

一个小桌面应用程序有一个用于更新的应用程序内下载器。你能发现问题吗？

_正在下载应用程序内更新。

让我们数一数：

1. 没有暂停按钮。
2. 没有取消按钮。
3. 没有任何进度指示器。
4. 没有速度/剩余时间指示器。
5. 没有办法获取底层URL，以便我可以使用自己的下载器。
6. 没有进度跟踪，也没有优雅地恢复中断的下载。

这实际上是我最喜欢的桌面应用程序之一！以这种方式指出它们的问题真是遗憾。一个快速、简单的改进方法，让这在南极点的用户来说好多了，就是提供手动下载链接。然后，开发者就不需要重新实现我的浏览器提供的所有漂亮的下载功能。我可以只使用我的浏览器。

示例4 - 另一个应用程序自动更新程序

再来一个！

_正在下载另一个应用程序内更新。

让我们数一下问题：

1. 没有暂停按钮。
2. 没有数字进度/速度指示器。
3. 没有办法获取底层URL，以便我可以使用自己的下载器。
4. 没有进度跟踪，也没有优雅地恢复中断的下载。

它确实有一些优点：

1. 取消按钮。
2. 视觉进度指示器。

但是 - 总的来说，对于慢速或间歇性互联网访问的用户来说，仍然是一种令人沮丧的用户体验。

示例5 - 适用于Mac的Microsoft Office

值得称赞的是 - 微软在Office for Mac中内置了一个非常好的自动更新程序！看看这个：

_在南极点下载适用于macOS的Office更新。

看看所有这些漂亮的功能！

1. 暂停按钮！
2. 取消按钮！
3. 进度指示器！
4. 速度和剩余时间指示器！
5. 优雅地恢复中断的下载！

唯一能让这个更好的是提供一个链接来获取底层URL，这样我就可以用自己的下载器。但是，鉴于这个界面有多好，即使是在南极点，我也不介意使用它。

结论

我希望我在这篇文章中展示的例子有助于说明，在家里的小疏忽或功能不足如何成为重大问题，在互联网慢的地方。

再次强调，我不是要求每个应用程序开发者花大量的时间优化像南极点这样的边缘情况。

我当然也不是要求人们创造奇迹。截至2023年10月，南极点的互联网接入是慢的。我不指望沉浸式互动流媒体在我所描述的条件下工作，但如果应用程序足够弹性，能够上传或下载一些文本字节就好了。不幸的是，情况往往并非如此，应用程序因为不明智的硬编码超时而陷入循环。

我希望每个人都觉得这有帮助，或者至少觉得有趣。

再次感谢每一个跟随我在南极洲旅行的人！我已经离开冰面大约六个月了，翻阅我在这里的旧帖子让我回忆起了美好的时光。

我希望目前的越冬人员都表现良好，希望每个人都在享受极夜。如果2023年冬季的鸡蛋供应和消费速度与之前一样，他们应该很快就要完成最后一颗鸡蛋。

我不能保证会有更多的内容，但我确实有一些其他半成品帖子放在我的草稿中。我们拭目以待！