当前位置：首页 > NSDI > 正文

【论文推荐】NSDI 2022 开源代码汇总

NSDI
2022-10-24
1679
更新：2022-10-24 09:39:34

> 作者：网络与通信
> 参考网页：https://zhuanlan.zhihu.com/p/541154574

USENIX Symposium on Networked Systems Design and Implementation (NSDI)是计算机网络方向CCF推荐A类会议，NSDI的录用率非常低，一直保持在20%以下，2022年为19.4%，2021年为16%，2020年为18.3%，2019年为14.8%，2018年为15.7%。NSDI 2023有两轮投稿周期，春季截止日期已经过去了，秋季的全文截止日期为2022年9月20日，感兴趣的小伙伴们也可以赶紧准备起来了。整理了NSDI 2022计算机网络相关的提供开源代码的论文，包括13篇论文，希望对相关领域的小伙伴有所帮助。获取这些论文的全文可以私信回复20220715，仅供大家交流学习。欢迎转发和关注！

## **目录：**

[1] Automated Verification of Network Function Binaries

[2] Backdraft: a Lossless Virtual Switch that Prevents the Slow Receiver Problem

[3] Characterizing Physical-Layer Transmission Errors in Cable Broadband Networks

[4] CurvingLoRa to Boost LoRa Network Throughput via Concurrent Transmission

[5] Donar: Anonymous VoIP over Tor

[6] Isolation Mechanisms for High-Speed Packet-Processing Pipelines

[7] Justitia: Software Multi-Tenancy in Hardware Kernel-Bypass Networks

[8] NetHint: White-Box Networking for Multi-Tenant Data Centers

[9] OrbWeaver: Using IDLE Cycles in Programmable Networks for Opportunistic Coordination

[10] Packet Order Matters! Improving Application Performance by Deliberately Delaying Packets

[11] Re-architecting Traffic Analysis with Neural Network Interface Cards

[12] Saiyan: Design and Implementation of a Low-power Demodulator for LoRa Backscatter Systems

[13] Zeta: A Scalable and Robust East-West Communication Framework in Large-Scale Clouds

## **具体内容：**

**[1] Automated Verification of Network Function Binaries**

**作者：**

Solal Pirelli, EPFL; Akvilė Valentukonytė, Citrix Systems; Katerina Argyraki and George Candea, EPFL

**摘要：**

正式验证软件网络功能(NF)的正确性对于网络可靠性是必要的，但现有技术需要完整的源代码并要求使用特定的数据结构。

我们描述了一种验证NF二进制文件的自动化技术，使网络运营商甚至可以在专有代码上使用验证。为了解决桥接NF实现和规范的抽象级别而不用特殊情况下一组数据结构的关键挑战，我们观察到NF使用的数据结构可以建模为映射，并引入一种通用类型来指定NF及其数据结构，“ghost map”。此外，我们观察到NF与其环境之间的交互足以推断控制流和类型，从而消除了对源代码的要求。

我们在Klint中实现了我们的技术，该工具可以在几分钟内验证7个NF二进制文件是否满足其规范，而不会限制开发人员对数据结构的选择。规范是用Python编写的，并使用映射来建模状态。Klint还可以使用最小的操作系统验证整个NF二进制堆栈，一直到NIC驱动程序。因此，操作员可以验证NF二进制文件，无需源代码或调试符号，无需开发人员使用特定的编程语言或数据结构，也无需信任除Klint之外的任何软件。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/pirelli](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/pirelli)

**代码：**

[https://github.com/dslab-epfl/klint](https://link.zhihu.com/?target=https%3A//github.com/dslab-epfl/klint)

**[2] Backdraft: a Lossless Virtual Switch that Prevents the Slow Receiver Problem**

**作者：**

Alireza Sanaee, Queen Mary University of London; Farbod Shahinfar, Sharif University of Technology; Gianni Antichi, Queen Mary University of London; Brent E. Stephens, University of Utah

**摘要：**

用于终端主机网络的虚拟交换机会在接收应用程序的速度不足以消耗数据包时丢弃数据包。这被称为慢接收器问题，这很重要，因为丢包会损害尾部通信延迟并浪费CPU周期，从而导致应用程序级性能下降。此外，解决这个问题具有挑战性，因为应用程序吞吐量在短时间内变化很大，因为它取决于工作负载、内存争用和操作系统线程调度。

本文介绍了Backdraft，一种新的无损虚拟交换机，它通过结合三个新组件来解决接收器速度慢的问题：(1)动态每流队列(DPFQ)以防止HOL阻塞并提供按需内存使用；（2）门铃排队，减少CPU开销；(3)一种新的覆盖网络，避免拥塞扩散。我们在BESS之上实现了Backdraft，并在100 Gbps集群上使用最先进的拥塞控制方案DCTCP和Homa对实际应用程序进行了实验。我们展示了使用Backdraft的应用程序可以在第99个百分位处将尾部延迟降低多达20倍。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/sanaee](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/sanaee)

**代码：**

[https://github.com/Lossless-Virtual-Switching/Backdraft](https://link.zhihu.com/?target=https%3A//github.com/Lossless-Virtual-Switching/Backdraft)

**[3] Characterizing Physical-Layer Transmission Errors in Cable Broadband Networks**

**作者：**

Jiyao Hu, Zhenyu Zhou, and Xiaowei Yang, Duke University

**摘要：**

宽带网络中的丢包率是一个重要的服务质量指标。以前描述宽带性能的工作没有将物理层传输错误引起的丢包与拥塞引起的丢包区分开来。在这项工作中，我们使用区域有线ISP提供的数据调查物理层传输错误。这些数据是在16个月期间从分布在394个混合光纤同轴(HFC)网段的77K+设备收集的。我们提出了一些与网络运营和网络研究相关的发现。我们估计，在FCC的美国宽带测量项目测量的有线ISP中，物理层错误可能导致12%到25%的数据包丢失。不同HFC网段的平均错误丢失率变化超过六个数量级，从O(10−6%)到O(1%)。持续高错误率网络中的用户不会比其他用户报告更多的故障单。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/hu](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/hu)

**代码：**

[https://github.com/zhenyu-zhou/pnm-loss-nsdi22](https://link.zhihu.com/?target=https%3A//github.com/zhenyu-zhou/pnm-loss-nsdi22)

**[4] CurvingLoRa to Boost LoRa Network Throughput via Concurrent Transmission**

**作者：**

Chenning Li, Michigan State University; Xiuzhen Guo, Tsinghua University; Longfei Shangguan, University of Pittsburgh & Microsoft; Zhichao Cao, Michigan State University; Kyle Jamieson, Princeton University.

**摘要：**

LoRaWAN已成为连接物联网设备的一项有吸引力的技术，但它的功能没有发射器之间的明确协调，随着网络的扩展，这可能导致许多数据包冲突。最先进的工作提出了处理这些冲突的各种方法，但大多数功能仅在高信干比(SIR)条件下发挥作用，因此无法扩展到弱接收很容易被强接收掩盖的实际场景来自附近的发射器。在本文中，我们重新审视LoRa的物理层，揭示其底层线性调制从根本上限制了并发LoRa传输的容量和可扩展性。我们表明，通过用非线性替换线性，我们可以提高并发LoRa传输的吞吐量，并使LoRa接收器能够在存在强碰撞信号的情况下成功接收弱传输。这种非线性chirp设计进一步使接收器能够解调完全对齐的冲突符号——这是现有方法都无法处理的情况。我们在基于USRPN210软件定义无线电平台的整体LoRaWAN堆栈中实现这些想法。我们与两个最先进的研究系统和标准LoRaWAN基线的直接比较表明，CurvingLoRa将网络吞吐量提高了1.6-7.6倍，同时不牺牲功率效率和抗噪能力。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/li-chenning](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/li-chenning)

**代码：**

[https://github.com/liecn/CurvingLoRa_NSDI22](https://link.zhihu.com/?target=https%3A//github.com/liecn/CurvingLoRa_NSDI22)

**[5] Donar: Anonymous VoIP over Tor**

**作者：**

Yérom-David Bromberg, Quentin Dufour, and Davide Frey, Univ. Rennes - Inria - CNRS - IRISA; Etienne Rivière, UCLouvain

**摘要：**

我们介绍了DONAR，这是一个通过Tor实现具有良好体验质量(QoE)的匿名VoIP系统。没有单独的Tor链接可以满足VoIP网络要求。DONAR通过在多个链路上传播VoIP流量来弥补这一差距。它结合了主动性能监控、动态链路选择、自适应流量调度和冗余，无需额外的带宽成本。DONAR可实现高QoE：在大多数(86%)5分钟和90分钟通话期间，99%的VoIP数据包延迟保持在360毫秒以下。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/bromberg](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/bromberg)

**代码：**

[https://github.com/CloudLargeScale-UCLouvain/Donar](https://link.zhihu.com/?target=https%3A//github.com/CloudLargeScale-UCLouvain/Donar)

**[6] Isolation Mechanisms for High-Speed Packet-Processing Pipelines**

**作者：**

Tao Wang, New York University; Xiangrui Yang, National University of Defense Technology; Gianni Antichi, Queen Mary University of London; Anirudh Sivaraman and Aurojit Panda, New York University

**摘要：**

数据平面可编程性现在是主流。随着我们发现更多用例，部署需要能够在单个设备中运行多个数据包处理模块。这些可能由独立团队开发，无论是在同一组织内还是来自多个组织。因此，我们需要隔离机制来保证同一设备上的模块不会相互干扰。

本文介绍了Menshen，它是可重构匹配表(RMT)管道的扩展，可强制不同数据包处理模块之间的隔离。Menshen由一组轻量级硬件原语和对开源P4-16参考编译器的扩展组成，它们协同工作以实现这一目标。我们在两个FPGA平台（NetFPGA和Corundum）上对Menshen进行了原型设计。我们展示了我们的设计提供了隔离，并允许加载新模块而不影响已经运行的模块。最后，我们展示了使用FreePDK45nm技术库和SynopsysDC综合软件在ASIC上实现Menshen的可行性，表明我们的设计满足1GHz时钟频率的时序要求，并且需要大约6%的额外芯片面积。我们已经在[https://isolation.quest/](https://link.zhihu.com/?target=https%3A//isolation.quest/)开源了Menshen的硬件和软件的代码。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/wang-tao](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/wang-tao)

**代码：**

[https://isolation.quest/](https://link.zhihu.com/?target=https%3A//isolation.quest/)

**[7] Justitia: Software Multi-Tenancy in Hardware Kernel-Bypass Networks**

**作者：**

Yiwen Zhang, University of Michigan; Yue Tan, University of Michigan and Princeton University; Brent Stephens, University of Illinois at Chicago; Mosharaf Chowdhury, University of Michigan

**摘要：**

内核旁路网络(KBN)正在成为现代数据中心的新规范。虽然基于硬件的KBN将所有数据平面任务卸载到专门的NIC以实现比基于软件的KBN更好的延迟和CPU效率，但它也剥夺了运营商对网络共享策略的控制权。在多租户硬件KBN中提供策略支持带来了独特的挑战——即保持超低延迟和低CPU成本、找到明确定义的中介点以及重新考虑流量整形器。我们提出Justitia以通过三个关键设计方面来应对这些挑战：(i)具有消息级整形的拆分连接，(ii)基于发送方的资源调解以及接收方更新，以及(iii)被动延迟监控。Justitia使用延迟目标作为其旋钮，支持多租户策略，例如可预测的延迟和公平/加权资源共享。我们的评估表明Justitia可以以略微降低利用率为代价有效隔离对延迟敏感的应用程序，并确保其余的吞吐量和带宽不会受到不公平的惩罚。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/zhang-yiwen](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/zhang-yiwen)

**代码：**

[https://github.com/SymbioticLab/Justitia](https://link.zhihu.com/?target=https%3A//github.com/SymbioticLab/Justitia)

**[8] NetHint: White-Box Networking for Multi-Tenant Data Centers**

**作者：**

Jingrong Chen, Duke University; Hong Zhang, University of California, Berkeley; Wei Zhang, Duke University; Liang Luo, University of Washington; Jeffrey Chase, Duke University; Ion Stoica, University of California, Berkeley; Danyang Zhuo, Duke University

**摘要：**

如今，云提供商将其网络资源作为黑匣子提供给其租户，因此云租户对底层网络特征知之甚少。与此同时，数据密集型应用程序越来越多地迁移到云端，这些应用程序既有能力也有动力根据云网络的特点调整其数据传输调度。我们发现黑盒网络抽象和数据密集型应用程序的适应性共同造成了不匹配，导致应用程序性能次优。

本文探讨了解决这种不匹配的白盒方法。我们提出了NetHint，一种云租户和云提供商之间的交互机制，以共同提高应用程序性能。使用NetHint，提供者提供了一个提示——底层网络特征的间接指示（例如，租户虚拟机的链路层网络拓扑、共同定位的租户数量、网络带宽利用率），然后租户的应用程序调整它们的相应的转移时间表。NetHint设计为云租户提供了丰富的网络信息来计算他们的最佳传输计划，同时为云提供商收集和公开这些信息引入了很少的开销。评估结果表明，NetHint将allreduce完成时间、广播完成时间和MapReduce shuffle完成时间的平均性能分别提高了2.7倍、1.5倍和1.2倍。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/chen-jingrong](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/chen-jingrong)

**代码：**

[https://github.com/crazyboycjr/nethint](https://link.zhihu.com/?target=https%3A//github.com/crazyboycjr/nethint)

**[9] OrbWeaver: Using IDLE Cycles in Programmable Networks for Opportunistic Coordination**

**作者：**

Liangcheng Yu, University of Pennsylvania; John Sonchack, Princeton University; Vincent Liu, University of Pennsylvania

**摘要：**

网络运营商经常面临权衡取舍：(a)引入可以提高整体性能的控制/管理平面应用程序，或者(b)使用它本应占用的带宽来传输用户流量。

在本文中，我们介绍了OrbWeaver，这是一个可以利用未使用的网络带宽进行网络内协调的框架。使用真实硬件，我们证明OrbWeaver可以获取此带宽(1)对用户数据包的带宽/延迟几乎没有影响，以及(2)同时提供注入流量的到达间隔时间的保证。通过对三个示例用例的探索，我们表明这种机会性协调抽象足以近似最近提出的系统，而没有任何相关的带宽开销。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/yu](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/yu)

**代码：**

[https://github.com/eniac/OrbWeaver](https://link.zhihu.com/?target=https%3A//github.com/eniac/OrbWeaver)

**[10] Packet Order Matters! Improving Application Performance by Deliberately Delaying Packets**

**作者：**

Hamid Ghasemirahni, Tom Barbette, Georgios P. Katsikas, and Alireza Farshin, KTH Royal Institute of Technology; Amir Roozbeh, KTH Royal Institute of Technology and Ericsson Research; Massimo Girondi, Marco Chiesa, Gerald Q. Maguire Jr., and Dejan Kostić, KTH Royal Institute of Technology

**摘要：**

数据中心越来越多地部署具有高速网络接口的商品服务器，以实现低延迟通信。然而，在高数据速率下实现低延迟关键取决于传入流量如何与系统的缓存交互。当需要以相同方式处理的数据包是连续的，即表现出很高的时间和空间局部性时，缓存可以带来很大的好处。

在本文中，我们系统地研究了时空流量局部性对配备高速网络接口的商品服务器性能的影响。我们的结果表明，（i）各种广泛部署的应用程序的性能显着下降，即使是最轻微的流量局部性缺失，以及（ii）来自我们组织的流量跟踪显示，作为网络协议、驱动程序和底层的流量局部性很差。交换/路由结构及时传播数据包（减少局部性）。为了解决这些问题，我们构建了Reframer，这是一种软件解决方案，可以故意延迟数据包并对其重新排序以增加流量局部性。尽管引入了一些数据包的微秒级延迟，但我们表明Reframer将网络服务链的吞吐量提高了84%，并将Web服务器的流完成时间减少了11%，同时将其吞吐量提高了20%。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/ghasemirahni](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/ghasemirahni)

**代码：**

[https://github.com/hamidgh09/Reframer](https://link.zhihu.com/?target=https%3A//github.com/hamidgh09/Reframer)

**[11] Re-architecting Traffic Analysis with Neural Network Interface Cards**

**作者：**

Giuseppe Siracusano, NEC Laboratories Europe; Salvator Galea, University of Cambridge; Davide Sanvito, NEC Laboratories Europe; Mohammad Malekzadeh, Imperial College London; Gianni Antichi, Queen Mary University of London; Paolo Costa, Microsoft Research; Hamed Haddadi, Imperial College London; Roberto Bifulco, NEC Laboratories Europe

**摘要：**

我们提出了一种方法来提高基于在线机器学习的网络流量分析的可扩展性。我们首先提出用二元神经网络代替广泛使用的用于网络流量分析的监督机器学习模型的案例。然后，我们介绍了NIC上的神经网络(N3IC)，这是一个将二进制神经网络模型编译成可以直接集成到SmartNIC数据平面中的实现的系统。N3IC支持不同的硬件目标，它使用micro-C和P4语言生成数据平面描述。

我们使用与流量识别和异常检测相关的两个用例来实施和评估我们的解决方案。在这两种情况下，与最先进的基于软件的机器学习分类系统相比，N3IC的分类延迟降低了100倍，吞吐量提高了1.5-7倍。这是通过在SmartNIC的数据平面内运行整个流量分析管道来实现的，从而将系统的CPU从任何相关任务中完全解放出来，同时在目标NIC上以线速(40Gbps)转发流量。受到这些结果的鼓舞，我们最终展示了硬件原语的设计和基于FPGA的原型，该硬件原语将二进制神经网络支持添加到NIC数据平面。我们的新原语只需要不到VirteX7FPGA的1-2%的逻辑和内存资源。我们通过实验评估表明，扩展NIC数据平面可以实现更具挑战性的用例，这些用例需要在几微秒内执行在线流量分析。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/siracusano](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/siracusano)

**代码：**

[https://github.com/nec-research/n3ic-nsdi22](https://link.zhihu.com/?target=https%3A//github.com/nec-research/n3ic-nsdi22)

**[12] Saiyan: Design and Implementation of a Low-power Demodulator for LoRa Backscatter Systems**

**作者：**Xiuzhen Guo, Tsinghua University; Longfei Shangguan, University of Pittsburgh & Microsoft; Yuan He, Tsinghua University; Nan Jing, Yanshan University; Jiacheng Zhang, Haotian Jiang, and Yunhao Liu, Tsinghua University

**摘要：**

随着不断发明新的无线通信原语，反向散射系统的无线电范围继续扩大。然而，反向散射信号的误码率和丢包率都随着无线电距离的增加而迅速增加，因此需要接入点和反向散射标签之间通过反馈回路进行协作。不幸的是，反向散射标签的低功耗特性限制了它们解调来自远程接入点的反馈信号的能力，并缩小到这种情况。

本文介绍了用于远程LoRa反向散射系统的超低功耗解调器Saiyan。借助Saiyan，反向散射标签可以以中等功耗解调来自远程接入点的反馈信号，然后在出现丢包时立即执行数据包重传。此外，Saiyan支持速率自适应和信道跳变——这两个PHY层操作对信道效率很重要，但在远程反向散射系统上不可用。我们在两层PCB板上对Saiyan进行原型制作，并评估其在不同环境中的性能。结果表明，与最先进的系统相比，Saiyan在解调范围上实现了3.5-5倍的增益。我们的ASIC模拟表明，赛亚人的功耗约为93.2μW。代码和硬件原理图可以在：[https://github.com/ZangJac/Saiyan](https://link.zhihu.com/?target=https%3A//github.com/ZangJac/Saiyan)找到。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/guo](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/guo)

**代码：**

[https://github.com/ZangJac/Saiyan](https://link.zhihu.com/?target=https%3A//github.com/ZangJac/Saiyan)

**[13] Zeta: A Scalable and Robust East-West Communication Framework in Large-Scale Clouds**

**作者：**

Qianyu Zhang, Gongming Zhao, and Hongli Xu, University of Science and Technology of China; Zhuolong Yu, Johns Hopkins University; Liguang Xie, Futurewei Technologies; Yangming Zhao, University of Science and Technology of China; Chunming Qiao, SUNY at Buffalo; Ying Xiong, Futurewei Technologies; Liusheng Huang, University of Science and Technology of China

**摘要：**

随着分布式应用程序在云上的广泛部署，云网络中的主要流量以东西方向横穿，在数据中心内从服务器流向服务器。现有的通信解决方案与控制平面（例如，预编程模型）或计算节点的位置（例如，传统网关模型）紧密耦合。紧密耦合使得适应快速的网络扩展、响应网络异常（例如突发流量和设备故障）以及保持东西向流量的低延迟变得具有挑战性。

为了解决这个问题，我们设计了Zeta，这是一个可扩展且强大的东西向通信框架，在大规模云中具有网关集群。Zeta将流量转发能力抽象为网关集群层，与控制平面的逻辑和计算节点的位置解耦。具体来说，Zeta采用网关集群来支持大规模网络，应对突发流量。此外，还提出了透明的多IP迁移，以快速从不可预测的故障中恢复系统/设备。我们基于eXpress数据路径(XDP)实现Zeta，并通过对多达10万个容器实例的全面实验来评估其可扩展性和稳健性。我们的评估表明，与最先进的解决方案相比，Zeta将突发视频流量中的99%RTT降低了5.1倍，并将网关恢复速度提高了10.8倍。

**链接：**

[https://www.usenix.org/conference/nsdi22/presentation/zhang-qianyu](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi22/presentation/zhang-qianyu)

**代码：**

[https://github.com/futurewei-cloud/zeta/](https://link.zhihu.com/?target=https%3A//github.com/futurewei-cloud/zeta/)

回顾IWQoS 2022的开源代码 [【论文推荐】IWQoS 2022 开源代码汇总](https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzg3OTEyODQ1OA%3D%3D%26mid%3D2247484438%26idx%3D1%26sn%3D68ad51390da60ddd10cf2d0d8531e17a%26chksm%3Dcf087ef3f87ff7e5fb81e3bdb38fa95582a2eb78ba2aa66c0dc8eab2f5aa7df2080743683278%26scene%3D21%23wechat_redirect)

回顾WCNC 2022的开源代码[【论文推荐】WCNC 2022 开源代码汇总](https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzg3OTEyODQ1OA%3D%3D%26mid%3D2247484434%26idx%3D1%26sn%3D93b7515c7742a66b2f922d0c2e4ac38c%26chksm%3Dcf087ef7f87ff7e12d553dbed73780462e70bc00fb6f884ffe7c20b76673e67fba775f1b2188%26scene%3D21%23wechat_redirect)

回顾INFOCOM 2022的开源代码[【论文推荐】INFOCOM 2022 开源代码汇总](https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzg3OTEyODQ1OA%3D%3D%26mid%3D2247484391%26idx%3D1%26sn%3D751f7a6a47edb03a64324711886e237d%26chksm%3Dcf087902f87ff01422ed411f6bf0c0b9ae42a0966cc11b5792a431d7d5f5ebf1326c21b84d26%26scene%3D21%23wechat_redirect)

获取最全最新的[卫星网络仿真工具和开源代码](https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzg3OTEyODQ1OA%3D%3D%26mid%3D2247484353%26idx%3D1%26sn%3D07ac8b4045f3bc4dd8955f44d0c9f02b%26chksm%3Dcf087924f87ff032d9d63c0a672c06bf37aa7d11580cdeb3165a9e5358128b542fb16c4ff700%26scene%3D21%23wechat_redirect)

> 声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。由于本人水平有限，如有纰漏，请以参考文献文章为准。

NSDI