- SPEAR 实验室构建真实系统并进行测量，以解决边缘计算和现代互联网协议中的性能差距。
- 低轨卫星网络在缺乏本地地面基础设施和集成的 DNS/CDN 协调时，内容交付表现不佳。
- 互联网测量显示，像多路径 TCP 这样的协议在现实世界的部署仍然有限，原因是中间件不兼容。
随着边缘计算和卫星连接重塑互联网，像 Nitinder Mohan 博士 这样的研究人员正在重新思考网络在现实世界中的表现。Mohan 博士是 电气工程、数学与计算机科学系 的助理教授，隶属于 代尔夫特理工大学。他领导着边缘赋能互联网系统与协议 (SPEAR) 实验室，其研究重点是边缘计算、下一代网络协议、互联网范围的测量以及关键应用的部署和管理。凭借学术和应用系统研究的双重背景，Mohan 博士的工作弥合了学术研究与当今及未来互联网运营现实之间的差距。
Q1. 作为 SPEAR 实验室的负责人，您能否简要介绍一下它的核心关注领域，特别是在边缘计算方面？您认为目前最大的挑战是什么？
Mohan：我领导着边缘赋能互联网系统与协议实验室，即 SPEAR 实验室。尽管实验室本身相对较新，但其背后的研究自完成博士学业以来一直在进行。我们的工作处于边缘计算系统与大规模互联网测量的交汇点。
实验室的核心动机是理解并解决传统云计算和互联网技术开始融合的方式。虽然这种融合在概念上正在发生，我们仍然观察到从事云系统工作的人员与专注互联网基础设施的人员之间存在明显的分歧。随着计算资源越来越靠近最终用户，这种差距变得更加明显。近年来，计算服务器不再仅仅位于遥远的数据中心。它们越来越多地被部署在 ISP 网络内部，就在边缘。
与此同时，互联网本身也在发展。它不再仅仅是连接用户到远程服务器的工具。现在它包括中间元素，如中间盒，可以在数据传输过程中执行计算。当我们考虑像云游戏、增强现实和虚拟现实这样的新应用时，这种演变变得尤为重要。这些应用要求极低的延迟，不能再依赖于所有处理都在一个中心位置进行的传统模型。相反，它们要求计算发生在离用户更近的地方，甚至可能在网络路径本身上。
这种转变带来了明显的挑战。现代应用的需求与当前网络基础设施的能力之间日益不匹配。在 SPEAR 实验室，我们通过构建支持边缘计算的实际系统来解决这个问题，重点关注编排。与此同时，我们进行互联网范围的测量，以更好地理解网络在实践中的行为。我们大规模研究传输协议性能、ISP 性能和应用性能。
这本质上是一个循环——我们构建系统，测量其性能，然后根据所得结果改进这些系统。
Nitinder Mohan 博士，代尔夫特理工大学助理教授
我们利用这些测量的发现来改进我们设计的系统。这是一个持续的循环。我们构建系统，观察它们在互联网上的表现，并利用这些见解使其在现实环境中更加有效。
另请阅读：边缘计算与云计算：有何区别？
另请阅读：德国电信设立主权云部门
Q2. 您提到 TCP 等传统协议在现代环境中表现吃力。在低轨卫星网络的背景下，您认为最关键的性能差距是什么？
Mohan：在讨论传输控制协议（TCP）的挑战之前，先解释一下低轨卫星互联网的实际工作原理会很有帮助。有一种普遍的看法认为，这些网络完全在太空中运行，只需绕过传统的地面基础设施就能提供更好的连接。其理念是，一旦卫星部署并绕地球运行，用户就不再依赖本地基站或政府资助的基础设施。如果卫星覆盖足够密集，人们认为他们应该能够在任何地方获得互联网接入。
然而，我们的测量和深入分析表明，这种假设并不准确。实际上，低轨卫星网络仍然非常依赖地面。卫星本质上充当移动基站。您的设备不是连接到传统的塔，而是连接到卫星，然后卫星将数据通过地面站传回地球。从那里，流量传输到存在点（POP），然后进入更广泛的互联网。
这种架构意味着，如果卫星运营商没有足够的地面站或分布良好的存在点，整体网络性能将会很差。我们在 星链（Starlink） 扩张的早期阶段观察到了这一点。即使他们发射了大量卫星，非洲和亚洲等地区的用户仍然经历着较差的连接。主要原因是缺乏本地地面基础设施。为了改善这一点，星链不得不大力投资，获得许可证、部署新的地面站，并在这些地区建立对等互联安排，以减少延迟并提高整体性能。
另请阅读：星链收到澳大利亚监管机构的警告
现在，我们看到更多的低轨运营商进入这个领域。像 OneWeb 和 Kuiper 这样的公司也在准备发射许多卫星。随着它们的发展，我们预期会看到各种不同的方法和性能结果。虽然地面网络继续支持移动和光纤连接，但卫星网络被定位为在偏远或服务不足地区更易获得或更具弹性的选择。然而，在幕后，两种系统都依赖于类似的回传基础设施。
然而，它们的运营方式截然不同。卫星链路有其自身的特点。与传统网络相比，它们涉及更频繁的切换、可变的延迟和不同的吞吐量模式。这种可变性使 TCP 等协议难以良好运行，因为 TCP 最初是为稳定、可预测的连接而设计的。
例如，如果您查看星链在美国或欧洲等地区的性能，可能会看到延迟在 30 到 40 毫秒范围内。但在非洲部分地区等地面基础设施仍在建设的地区，延迟可能更加不一致。这主要是由于地面站容量有限，以及在传输过程中需要频繁在卫星之间切换。
现有的传输和路由协议在低轨卫星网络中根本无法良好运行。
Nitinder Mohan 博士，代尔夫特理工大学助理教授
传统的传输和路由协议不适应这些条件。因此，性能会受到影响。为了克服这个问题，我们需要更好的方法来集成地面和卫星网络。只有让这些系统更有效地协作，我们才能构建一个在不同地区和用例中提供一致性能的网络。
另请阅读：Skynopy 为卫星地面站网络融资 1600 万美元
Q3. 您关于将低轨卫星网络与现有互联网运营相结合的研究有哪些早期发现或有希望的方向？
Mohan：我们观察到的一点是，低轨卫星运营商展示其网络性能的方式与实际对端到端用户体验的影响之间存在脱节。大多数运营商倾向于只展示到最近存在点的延迟数据。例如，在星链网站上，你会看到精美插图的地图，显示各个国家的延迟约为 30 毫秒。从表面上看，网络表现良好。
然而，这些数字只反映了到达存在点的时间，而不是用户流量实际目的地的延迟。在实践中，到应用服务器的完整路径可能要长得多、复杂得多。这正是我们在 SPEAR 实验室密切研究的内容，我们有兴趣了解如何优化端到端的应用性能，而不仅仅是第一跳。
以内容交付为例。想象一下尼日利亚的用户使用低轨卫星连接。如果运营商没有在该地区投资地面基础设施，用户的流量可能通过星际链路路由到最近的可用地面站，可能在欧洲。然后，它在法兰克福这样的城市离开卫星网络。但如果请求的内容在尼日利亚本地托管，流量就会通过地面网络返回以到达本地服务器。一旦获取了内容，它就会以相同的低效路径反向传输——回到法兰克福，然后通过卫星链路返回给用户。
这个过程增加了不必要的延迟，造成了糟糕的用户体验。它还凸显了一个更深层次的问题。我们当前的互联网基础设施是基于对地理接近度和路由的假设，而这些假设在卫星环境中不再适用。像 DNS 解析和内容交付网络这样的系统是为地面环境构建的，在这种环境中，确定用户的位置并相应地提供内容相对简单。
低轨网络打破了这种模式。根据卫星连接到地面的位置，用户的流量可能看起来来自一个完全不同的地区。这使得有效交付内容或适当放置计算服务变得困难。
随着用户位置变得越来越不可预测，提供一致的性能需要空间和地面基础设施之间更紧密的集成。
Nitinder Mohan 博士，代尔夫特理工大学助理教授
为了解决这个问题，我们需要卫星和地面系统之间更好的集成。这包括向低轨卫星运营商开放更多地面基础设施——如 CDN 节点和边缘计算资源。通过更好的协调，我们可以在用户、内容和计算服务之间创建更准确的映射，这将有助于在不同地区提供更快、更一致的体验。
Q4. 您还从事大规模互联网测量工作。您的结果是否曾与传统上关于互联网或其协议在实践中的表现的假设相矛盾？
Mohan：是的，这也是我们测量工作的关键动机之一。关于互联网协议或技术应该如何表现存在许多假设，但当我们在规模上测试这些假设时，现实往往大相径庭。
一个明显的例子来自我们早期关于边缘计算的工作，该成果最终在 HotNets 2020 上发表。当时，有很多关于边缘计算如何减少延迟的讨论。许多人认为，将计算部署在离用户更近的地方会自动带来更快的响应时间。为了测试这一点，我们在七大云提供商中进行了大规模测量。我们绘制了全球用户通过蜂窝、Wi-Fi 和光纤网络连接到最近数据中心的路径。目的是了解用户正在经历什么样的延迟，以及将计算移近是否会产生显著影响。
我们发现，大部分延迟来自接入网络，比如用户的蜂窝或 Wi-Fi 连接。一旦流量到达回传网络，到云数据中心的延迟已经很低了。在欧洲和美国等地，云提供商直接与大型 ISP 对等互联，因此改进空间不大。如果边缘计算的目标仅仅是降低延迟，那可能不是正确的理由。相反，边缘计算更适合于提高应用性能或构建分布式系统。现在这一认识得到了更广泛的接受。
另一个例子是我们对多路径 TCP 的研究，这是一种让设备同时使用 Wi-Fi 和移动数据的协议。它于 2020 年标准化，但我们发现它的采用非常有限。互联网上的许多中间盒不识别协议头，要么阻止连接，要么做出错误响应。有些甚至发送虚假的确认，这可能会带来安全风险。实际上，只有少数供应商在使用它，而且大部分部署来自 苹果。由于苹果放弃使用，使用量已经下降。我们将所有测量数据在 mptcp.io 上开源，以便人们了解使用情况的变化。这表明，仅仅标准化是不够的。一个协议还需要在整个互联网上的兼容性才能在实际中使用。