-
摘要:
随着近年IPv6网络的迅猛发展，针对IPv6的网络测量和安全分析逐步成为热门的研究课题，这其中一项最基础、最关键的工作是通过网络扫描获取大量的IPv6活跃地址. 然而IPv6庞大的地址空间和稀疏的活跃主机分布使得传统的暴力扫描工具（如ZMap和MASSCAN等）无法直接使用. 例如在万兆带宽条件下，可5 min内扫描IPv4全网的ZMap扫描器若对IPv6进行全网扫描，仍需要花费上亿年的时间. 针对大规模IPv6网络扫描所面临的效率低下问题，研究人员提出了一系列针对IPv6网络的扫描方法，提升了当前IPv6网络资产发现、识别和风控的能力. 对这些基于目标生成的IPv6网络扫描方法进行了分类、梳理和总结，分析了各扫描方法的优缺点及适用场景. 通过实网扫描实验，对比了多种扫描策略的命中率、边际效益和时间花销等性能情况. 最后给出了对IPv6网络扫描研究的思考并对未来的研究方向进行了展望.
Abstract:With the rapid evolution of IPv6 in recent years, the significance of IPv6 network measurement and security analysis has grown substantially. Obtaining a substantial number of active IPv6 addresses has become a fundamental and critical task in this domain. However, the sheer size of the IPv6 address space and the sparsely distributed nature of active hosts present challenges that render brute-force scanning tools, such as ZMap and MASSCAN. While ZMap can scan the entire IPv4 network in just 5 minutes with a 10-gigabit bandwidth, it would take hundreds of millions of years to scan the entire IPv6 network using similar methods. In response to this challenge and in a bid to enhance the efficiency of IPv6-wide scans, researchers have introduced a series of innovative search strategies tailored to IPv6 scans. These strategies aim to enhance the ability to discover assets and mitigate risks within the IPv6 network. We undertake the task of categorizing, organizing, and summarizing the target generation-based scanning approaches proposed by researchers in this field. We conduct a comprehensive analysis, comparing the hit rate, marginal benefit, and time costs of state-of-the-art solutions through real-network scan experiments. Furthermore, we provide valuable insights into the current landscape and emerging trends in IPv6 target generation scanning techniques. By doing so, we contribute to a deeper understanding of IPv6 network analysis and security, ultimately fostering advancements in this critical area of networking research.
-
Gartner指出2022年将有75%的企业数据在边缘侧产生[1]，IDC预测2025年将有416亿个边缘侧设备实现互联数据量达79.4 ZB[2]. 由于云计算的实时性差、带宽受限、高能耗、维护费用高、隐私安全等问题[3-7]，将不能应对边缘侧如此海量的设备与数据,使对用户服务的有效提供面临严峻挑战，促使边缘计算的蓬勃发展[8]. 边缘计算将计算、存储等资源下沉至用户侧，以其低时延、动态性、移动性以及位置感知等特征,在智能医疗、智能家居、军事及农业等领域发挥了重要作用[9-13]. 随着通用设备的不断普及、专用设备的不断下沉、虚拟化及中间件技术的飞速发展、设备性能的不断提升以及基础设施运营商的大力投入等[13]，催生出大量可在边缘侧进行训练与推理的边缘协同技术架构，如FATE,Paddle-Lite,TensorFlow Lite等[14]，借助多样化的边缘设备协同能力，使单设备下的多业务场景、多设备下的复杂智能业务场景发展迅速. 各种云、边、端间协同技术的不断进步[15-16]与各种机器学习模型训练优化技术、轻量化技术[17]的深入研究，促进了边缘智能（edge intelligence, EI）相关方向的飞速发展.边缘智能或智慧边缘计算是指借助边缘侧辅助实现机器学习模型的训练与推理的一系列智能化方法，使智能更加高效、贴近用户、解决人工智能“最后一公里”问题[18-22]. 边缘协同智能则指在边缘智能的基础上进一步通过边缘节点间的协同，融合边缘计算资源（网络、计算、存储、感知、应用等）核心能力实现的智能. 从其生命周期来看，可划分为训练阶段、推理阶段以及模型的部署更新，而本文则聚焦于其中的推理阶段.
本文第1节对边缘智能侧重于从协同推理角度的发展简史以及整体过程进行纵向总结，引出目前边缘协同推理涉及到的关键技术，描绘出边缘协同推理在边缘协同智能中的整体位置，并给出2个分类标准，将边缘协同推理的智能化方法与边缘协同推理的整体架构，与已有文献进行比较，突出本文贡献；第2节从协同角度根据分类标准对已有的协同推理阶段、部署更新等问题进行总结并结合边缘计算资源特点对不同技术进行横向比较与分析；第3节聚焦于对边缘协同推理在动态场景下的挑战进行总结，本文提到的动态场景[23]包括有地理位置带来的环境变化、边缘计算资源发散、网络拓扑的变化、服务性能波动大、节点频繁交换导致服务或系统吞吐量的动态变化以及应用、网络、设备等带来的不确定性，标准不统一的场景.并对未来值得关注的研究方向进行初步探讨；第4节总结本文.
1. 边缘协同推理概述
1.1 边缘协同智能发展
图1展示的是在谷歌学术上使用“edge intelligence”关键词进行检索，得到的关于边缘智能的文献数量与年份对应的发展趋势. 从图1来看，截止2020年，边缘智能的发展正处于爆发期，还未达到平稳发展期.
进一步，通过对Web of Science中以关键词“edge intelligen”检索得到的239篇文献进行分析，本文将边缘协同智能划分为3个阶段：萌芽期、技术储备期以及爆发期.本文关注的边缘协同推理在图2中同时给出了所涉及到的推理过程中使用的核心技术及其在边缘智能发展过程中的关键时间节点，从中也可以观察到，人工智能领域涌现出的新技术会极快的同步应用到边缘智能中（图2中相同形状图标表示同一类型技术），如神经网络架构搜索（neural architecture search, NAS）与计算能力受限的硬件资源结合后演变为神经网络架构实现搜索（neural architecture and implementation search, NAIS）.技术突破的关键问题是如何在资源受限的边缘计算场景中应用新技术.这些协同推理关键技术极大促进了边缘智能的发展，下文将在边缘智能的基础上，结合图1、图2，重点对这些关键技术进行归纳总结并同时从协同角度给出分析.
边缘协同智能萌芽期（2003—2012年）. “edge intelligence”一词最初源自有线网络传输场景，主要目标是提升网络的可靠性、智能性[24-25]. 随着移动通信技术的发展,多媒体为代表的各类服务在网络中呈爆发态势，用户的移动性给各类服务的管理带来挑战,边缘协同智能被应用于移动用户的管理,主要目标是提升服务管理效率、降低时延[26-27]. 而此时对如何利用分布式网络中的资源还未形成系统性认识，多为简单的智能算法相互组合，节点间协同性不强，未涉及到与深度学习技术的结合，能支持的智能业务有限.
边缘协同智能技术储备期（2012—2016年）. 该阶段随着深度学习技术的迅速发展，大量引人注目的成果不断涌现，如2012年的AlexNet[28]和2015年的Inception[29]分别在ImageNet比赛中取得了令人瞩目的成果.随后，更加轻量化的深度学习模型处理技术被不断提出，并应用到边缘设备上，使边缘设备具有了智能化的推理能力[30].随着深度学习与边缘计算不断融合，基于边缘协同的智能处理方案开始显现，如在跌倒检测应用中在边缘设备和边缘服务器之间对智能检测算法进行简单拆分[31].同时，云原生的虚拟化容器技术，如Docker，也开始迅速发展.此时与深度学习结合的边缘智能开始成为主流，一些中间件、虚拟化技术也飞速发展，但还未出现以边缘计算资源特点与深度学习模型结构融合的推理方法.
边缘协同智能爆发期（2017年以后）. 得益于上个阶段的技术储备，该时期大量的深度学习模型与边缘计算结合，众多边缘协同智能处理方案迅速增长，如边缘计算场景下的分布式协同训练[32]、联邦学习[33]；基于模型切割、早期退出等技术的分布式协同推理[34-35]、浅层的宽度学习系统[36]与虚拟化技术的结合,使边缘协同智能的快速落地成为可能，极大减轻了不同设备间的运维成本[37-38]. 现阶段用于边缘协同推理的场景复杂多样，用于推理的基础服务或架构还未形成稳定发展的趋势，表现出应用层所具有的多样化特点.
结合边缘智能当前所处的阶段可以看出，其目前正处快速发展阶段，这也说明边缘协同推理方向存在众多问题与挑战，由于目前未对边缘协同推理形成整体概貌，有必要对其进行进一步分析，对相关技术进行归类划分，指明未来的发展方向.
1.2 边缘协同推理的整体过程
边缘协同推理利用节点间的协同，通过不同的训练优化手段，获取用于协同推理的模型并结合场景的资源特点等信息在训练节点或边缘设备等资源上完成部署. 如图3所示，按照边缘协同推理在边缘协同智能中的生命周期位置来看，推理阶段与训练阶段相互结合，是一个不断往复循环、不断提升的过程. 根据推理业务需求，其中还可能涉及模型的更新部署（本文“更新”特指替换服务中的推理模型，而非训练阶段的梯度等的更新）.
![]()
图 3 边缘协同推理关键技术、过程及应用场景Figure 3. Key techniques, processes and application scenarios of edge collaborative inference通过训练得到的模型往往不能直接应用到推理场景，需要额外的模型处理步骤.根据模型的生命周期以及推理场景的资源特点，训练阶段可采用的优化手段有模型选择、模型量化、早期退出、神经网络架构（实现）搜索等.推理阶段可对模型进行2次处理，结合早期退出、模型量化、神经网络架构（实现）搜索等方式对模型进行进一步修改，以及在支持节点协同的情况下,采用模型切割、模型选择等技术对模型进行2次无损处理；在推理阶段的后期，由于时间、业务、数据等的变化涉及到模型的更新，此时多借助重新训练模型、在线学习等技术.
除此之外，通过图3还可看出，边缘计算场景的资源异构性会涉及到不同的推理架构适用性问题. 目前来看推理架构的选择通常与特定的推理模型处理技术相关.本文将从推理的智能化方法与架构2个角度对现有研究展开讨论. 值得一提的是，目前边缘计算方面有着众多优秀的工作，由于篇幅所限，本文主要针对边缘协同中推理阶段的模型处理、更新部署以及运行推理的架构进行阐述.
1.3 与已有综述研究的比较以及本文的贡献
由于推理过程中所用机器学习模型规模大、复杂性高，限制了推理关键技术在边缘计算场景下的训练与应用.目前，有研究者针对模型的推理内容进行了总结.文献[39]探讨了分布式机器学习的发展，讨论了其系统性挑战以及利用高性能计算加速和提高可扩展性的方法，描述了一种分布式机器学习的参考架构,基于此给出了各个阶段的常用算法.文献[40]总结了分布式协同优化中的热点研究方向，包括加速优化算法、非凸优化算法和无梯度优化算法，并结合实际应用场景进行了展望.文献[41]回顾了物联网场景中能够支持机器学习的模型在低性能硬件上执行的主要技术，比较了深度学习、RNN、GAN等可在边缘设备上实现的机器学习算法和这类算法下沉到边缘的过程；作为底层支持，还介绍了基于边缘服务器的架构、支持AI的物联网无线标准、卸载技术、隐私问题处理和训练阶段的边缘实现.文献[42]在深度学习的基础知识和最新技术的基础上，分析了在边缘设备上执行深度神经网络训练和深度学习模型推理的方法和架构，并探讨了在边缘部署深度学习的未来与挑战.文献[43]在文中讨论了加速深度学习推理的不同结构与方法，分为仅设备端执行、仅边缘服务器执行和中间方案3种，以及在边缘设备上训练深度学习模型，重点关注了多设备和隐私处理的分布式训练.文献[18]在概述了深度学习和边缘智能的基本概念与定义后，针对深度学习模型在网络边缘进行训练/推理的总体架构、框架和新兴关键技术作出了介绍.
文献[18，39−43]关注深度神经网络模型压缩与加速技术，并针对边缘设备中的训练和推理作出了总结，与之不同的是，本文充分调研了近几年来边缘智能相关的文献，从动态场景角度，重点关注节点间协同的推理处理方式，分别从推理模型与架构的角度进行描述，总结了用于边缘协同推理的核心技术发展，对边缘智能中训练和推理相关技术面临的机遇与挑战做出了展望.
本文贡献有5个方面：
1）按照关键技术的发展脉络，对边缘协同智能发展史进行了梳理；
2）对边缘协同推理进行分类，将其划分为边缘协同推理的智能化方法与架构；
3）对边缘协同推理中的模型轻量化技术进行归纳整理及分析，并横向比较了不同技术的适用范围；
4）对边缘协同推理中的架构进行归纳整理，分析了不同架构的优缺点及适用场景讨论；
5）除了对每种技术进行单独分析外，本文还对边缘协同推理的共性问题进行了分析，并指出其值得发展的研究方向.
2. 边缘协同推理核心智能化方法与架构
将边缘智能中的协同推理阶段现有研究划分为2个方面：推理智能化方法与架构. 智能化方法指的是与推理任务相关的智能化方法，本文主要针对深度学习（或深度神经网络）. 架构指运行推理任务的底层网络拓扑结构. 通过对智能化方法的观察与分析，归纳出用于边缘协同推理的核心技术；通过对已有工作在架构角度的抽象，归纳出目前协同推理在部署及运行时的特点、适用场景及不足之处.
2.1 边缘协同推理的智能化方法
主流的深度神经网络模型大小通常为几兆字节甚至几百兆字节，计算量较高给低配置的边缘节点带来了挑战[44]，因此需要考虑如何在边缘节点上对模型进行部署. 一般而言，边缘计算中的各个资源指标是有限的，这就导致在给定的约束条件下会存在多个可行解，需要考虑对存储、计算、通信、能耗、隐私等的“折中”方案，实现“折中”的过程涉及模型的处理方式，主要是对模型进行轻量化的优化技术. 本节就目前相关主流技术进行归纳整理，并在协同推理角度进行分析.
2.1.1 模型切割
深度神经网络模型多具有良好的内部结构，如图4所示，按照模型的内部结构可通过纵切、横切及混切等方式将模型切分成不同粒度且具有相互依赖关系的模型切片[45]，之后将切片按照依赖关系分别部署在云及边缘端. 如采用纵切方式的DeepThings[46-47]，横切方式的Neurosurgeon[34]、MoDNN[48]、Cogent[49]. 混切方式的DeepX[50]、AOFL[51]、CRIME[52]、 DeepSlicing[53]，以模型切割为主压缩等其他轻量化方法为辅的Edgent[54]， ADCNN[55]等，通过优化资源（能耗、通信或计算等）的代价函数对模型内部的切割点进行枚举，以寻找满足用户或系统需求的切割方案.模型切割技术在保证模型推理精度不变的前提下，能更好的适应边缘计算. 但由于边缘计算中涉及资源分布广泛、性能不一，尤其是在动态场景下资源地理分布范围广，造成所面临的环境时刻发生变化且不唯一；网络规模变大造成网络拓扑变化；边缘计算场景中计算资源不集中，靠近用户侧，资源发散；应用、网络、设备的异构性等边缘计算资源类型多；由于同一节点运行多种类型服务的情况，资源分配困难使得网络拥堵，服务器波动大；故障频率高、性能波动大、节点协调困难、服务调整趋于被动，存在滞后性并需要分布式思维解决等问题.切割技术中需要引起关注的是切割的整体过程，其中包括切割的执行者、切割时的参考依据如何获取、切片的依赖关系映射、切片更新时间及频率等，这决定了切割的方案在边缘计算环境中的适用性及稳定性，表1给出了不同方法的模型切割过程中涉及的关键步骤的比较.
表 1 模型切割方法比较Table 1. Comparison of Model Partition Methods方法 模型切割执行者 切割的依据收集方式 切片依赖关系处理/服务发现方式 切片更新方式 优化目标 运行时涉及
的切片数量DeepThings[46-47] 网关（gateway） 周期性收集节点状态 网关统一调度 节点拥有完整模型 内存、通信 ≥2 ADCNN[55] 中心节点（central node） 基于历史任务执行时延估计 中心节点调度 节点拥有完整模型 时延、通信 ≥2 Neurosurgeon[34] 客户端 实时观测当前网络、能耗状态 IP绑定（固定） 节点拥有完整模型 能耗（时延） 2 MoDNN[48] 中心节点（group owner） 节点注册到中心节点时获取 中心节点调度 部署一次,无更新 时延 ≥2 DeepX[50] 中心节点（execution planner） 实时收集与线性回归预测 中心节点调度 每次运行推断重新生成执行计划 能耗、内存 ≥2 AOFL[51] 云端或中心节点 周期性收集节点状态 IP绑定（固定） 重新部署 时延、通信 ≥2 CRIME[52] 任意节点 节点实时交互 直接邻居集合 节点拥有完整模型 时延、能耗 ≥2 DeepSlicing[53] 主节点调度（master） 基于历史任务执行时延估计 中心节点调度 节点拥有完整模型 时延、内存 ≥2 Edgent[54] 主节点（边缘服务器） 观测的历史网络数据 IP绑定(固定) 重新部署 准确率、时延 2 文献[45] 中心节点 实时收集节点状态 IP绑定（固定） 节点拥有完整模型 内存 ≥2 Cogent[49] 中心节点（DDPG adgent） 周期性收集节点状态 Kubernetes提供的静态虚拟IP绑定
(固定)重新部署 准确率、时延 2 文献[56−57] 边缘服务器（server） 根据模型及优化目标折中分析 IP绑定（固定） 重新部署 计算、通信时延 2 通过表1可以看出，由于边缘计算资源的可用性会发生变化，因此涉及切片的重新部署. 主流方式多采用中心节点对其他边缘节点状态进行收集，从而作为模型重新切割的依据，之后将模型切片下发到边缘节点. 这种收集节点状态的形式默认对所有的边缘节点具有感知能力，但这个前提并不适用于边缘计算尤其是动态场景[55,58]. 在模型的重新切割及部署上，涉及2个关键问题：1）模型或数据可支持的并行度对推理速度产生重要影响，由于模型的内部结构采用横切的方式，在并行度上很难提升；纵切虽然可极大提升并行度，但一般会带来数据依赖的问题，因此设计适合纵切的模型是一个重要的研究方向，如考虑计算复用、设计可用于无数据依赖切割的模型等[45,55]. 2）部署方案更新的频率较高会带来过高的代价，既包括切片本身也包含所涉及的其他组件；此外，切片更新过程中可能会面临无法提供服务问题带来的服务抖动，此时可参考经典的任务冗余（副本）技术解决. 节点拥有整个模型是避免针对同一模型重新切割带来的反复下发调度，提升协同推理灵活性的关键. 但对于运行内存不足的节点而言，拥有整个模型存在较大阻碍，此时可借助其他轻量化技术对模型进行压缩或考虑辅助存储、网络存储的形式减少频繁更新切片带来的额外代价，此外，在线学习、感知学习[59]等实时更新模型的学习方式也值得关注.
除了关注模型切片的部署之外，推理时切片间依赖关系的处理也值得关注，如根据网络状态自适应决定相邻切片间数据或张量（tensor）的压缩率[56-60]以应对紧张的通信资源. 在切片间的依赖关系路由或服务发现上，目前多数都采用固定的IP映射的方式，或采用解析节点进行，当部署的切片所涉及的节点数量过多时，固定的IP映射的方式尤其不适合于动态的边缘计算环境，采用解析节点则引入了额外的解析时间[61]，数据命名网络可为此方面问题提供解决方案[62]. 此外，多用户方面的协同推理还有所欠缺，目前的解决方案多针对单个场景，涉及的应用不多，用户量不多，默认的是边缘服务器资源充足的场景. 当面临多用户、多应用时，由于边缘计算的地理分布特点，云计算中资源的按需扩展很难在边缘侧实现，这会导致资源紧张，使服务满足不了用户或企业需求，此时可参考计算复用的思想，如多场景共用通用模型的部分切片[63]. 虽然依据模型的内部结构对模型进行切分的研究成果较为丰富，但多数模型切片部署方案针对的是边缘计算资源状态相对稳定或基于瞬时状态的静态场景，其稳定性易受动态场景影响而出现系统瓶颈，可以参考的方案是从模型的鲁棒性入手，当存在某个瓶颈节点时可直接跳过部分子切片或神经元[64-65]. 在具体的场景中，由于节点的资源是相对有限的，节点算力存在差异而且处于动态变化中，这增大了对于恰当的模型分割点的选择难度. 无论横切还是纵切的切割方式，划分计算任务时如果不能有效结合节点算力差异，导致任务分配下发不合理，那么节点间的协同效率也会受到较大影响. 另外在节点协同处理问题的情境中，网络状态的处理也十分重要，不仅会直接影响到模型切割的结果，在执行推理的过程中，产生的通信延迟也会明显影响推理服务质量[66]. 同时现有的模型切割方式存在策略的选择不够全面，为了实现协同，难以兼顾推理效果、推理延迟、服务能耗等问题.
2.1.2 模型压缩[67]
由于边缘节点内存、计算能力、能耗等有限，模型的鲁棒性、稀疏性等允许我们通过张量分解方法对张量降秩处理[68]；通过剪枝剔除影响小的参数对模型进行压缩[17,64]；通过量化方法降低权重和中间计算结果的位宽[69-70]，进一步降低模型在内存与计算量上的需求，文献[17,64,68−70]方法属于软件优化，在其应用于具体的边端设备时，由于模型的多样性与一些加速芯片的架构特点并不匹配，甚至可能存在“内存墙”问题，在模型的推理速度及能耗提升上还存在阻碍[71]，为了进一步有效利用资源，结合资源特点进行定制化的压缩，软硬件协同优化[72-73]也值得关注.
在软件优化方面，除了与训练过程结合生成低稀疏性的紧致模型外，还包括对已有模型的处理，处理技术主要包含剪枝与量化2种技术. 对剪枝而言，从模型的结构出发，可分别对滤波器（filter）[74]、通道（channel）[75-76]、神经元[77]等分别或混合[78]进行压缩处理. 在剪枝粒度上，主要包含非结构化剪枝与结构化剪枝2种. 非结构化剪枝删除任意位置的权重，其特点是粒度细、压缩率高，如在多次迭代过程中删除冗余参数的知识蒸馏方法[79]. 但非结构化剪枝并不能显著降低计算量且因存在的稀疏性带来额外开销，需要定制化加速器才能完成计算加速. 结构化剪枝中剪枝粒度大，具有良好的加速效果，如通过后继层对前驱层的重要性反馈删除影响小的通道[75]，但此类方法压缩率相对较低. 这促进了对混合粒度的剪枝方法研究，如满足一定结构规则性的基于模式的剪枝方案对卷积内核进行修剪以满足特定模式[80]. 剪枝操作通常会给推理精度带来不利影响，目前主流方法多采用重新训练的方式解决这个问题[74]，但对重新训练而言，由于计算代价大，重新训练比较适用于精度及效率具有重要意义的场景[70]，即需要评估模型部署后所带来的收益与重新训练的代价后才考虑是否选择重新训练.
对量化而言，由于模型的参数量巨大,低位宽的数据表示方法可以极大压缩模型尺寸，提升推理速度. 根据取值范围，可将量化分为2值量化、3值量化[81]、线性量化、非线性量化[82]，其本质是多对一的映射问题. 2值量化方法中，主要是将权重映射为1和−1[69]，将激活值映射为1和0[83]；3值量化主要是在2值量化基础上引入额外的0来增强所能表达的状态空间[84-85]；线性量化则主要将原始权重数据量化为连续的对硬件友好的定点[86-90]；非线性量化通常没有特定的映射规则,也有学者称其为参数共享[91]，如使用不同的哈希映射对网络每一层进行压缩[92]；使用k-means聚类实现相近参数的压缩[67,93]，将最近邻居量化到相同位宽[94]等. 由于数据表示的精度上存在损失，因此，量化方法会对推理精度带来一定影响. 同样的，也可通过重新训练提升推理精度[94]，进一步地，为了充分贴合硬件的计算性能，可通过编译器的指令优化使算法级压缩与硬件资源优化相融合[80]，从而达到在可移植的基础上进一步提升推理速度的目的.
在软硬件协同优化方面，硬件敏感的神经结构搜索（hardware-aware neural architecture search, HNAS）成为热点，不同于软件层面的模型压缩方法，HNAS将硬件资源与模型同时考虑在内实现定制化压缩. 定制化的压缩方案极大提升了推理性能. 但有些硬件的结构是可重塑或定制化的，如FPGA. 因此，好的模型压缩方法还需要考虑如何在一个可变的硬件上进行充分压缩，如NAIS，NAIS方法所面对的搜索空间既包含模型本身又包含硬件特点，实现最优的部署需要较高的代价，针对此问题，文献[95]设计了一种可微分的方法来加速该过程；同时，由于模型稀疏性普遍存在,设计高效的跳零架构，直接跳过冗余的零值计算.加速计算过程[96]以及存内计算（processing in memory）[97]等也值得关注.
现有大多数方案都基于固定或基于历史数据分析的资源分配，在资源不稳定的情况下，推理运行时的效果也值得关注. 该方面可结合硬件进行实时压缩，考察激活值的稀疏性、动态的压缩激活值. 如，通过区分图像敏感区域，自适应地选择不同的激活值和权重量化位宽[98]，通过对输入数据按照取值范围编/解码，实现多通道自适应压缩[99]等. 这方面的研究目前不多，尤其是在边缘计算场景下值得关注.
小结与分析：可以看出，模型压缩涉及范围广泛，从模型的内部结构出发，包含了模型不同的组成部分，从使用的场景出发包含了与硬件资源结合时的优化，单独一个方法很难适用于不同的场景，方法的适用性对边缘计算场景而言至关重要. 由于涉及的资源分布广泛，节点性能存在很大差异，仅靠人工设计网络结构及压缩的方式很难普及，通过软硬件协同的网络压缩自动化方法值得我们进一步挖掘.然而，目前对模型进行压缩及更新替换的多数方法皆通过高性能服务器或云等远端进行[100]，在不具备这种条件的场景，如野外、战场、隐私安全要求高的环境或通信代价大的场景，需要设备间的协同来完成更新. 但由于边缘计算场景资源异构性的存在，当前压缩方法及精度表示多种多样，在不同设备间移植的兼容性需要进一步考虑.
就量化方法而言，虽然保留了完整的模型，但不同硬件由于功耗上的设计使其可表示的数值精度存在很大差异[101]，固定位宽的表示方式可能并不适用于临近的所有协同节点，这种情况下接收到的模型与资源的匹配度无法达到最优，2.1.2节提到的多种优化方法也就无法发挥作用，再次压缩处理的模型是否满足需求甚至能否再次训练值得关注. 值得一提的是在边缘协同推理场景，受限资源的分配及调度粒度至关重要，该问题将决定“腾出资源做合适的任务”等资源调度及优化的发展. 除此之外，还需要注意的是，边缘节点的可用资源是不同的、动态变化的，现有的压缩方法对此的适应性存在空白，亟待解决.
2.1.3 模型选择/早期退出
如图5和图6所示，模型选择指首先训练具有不同尺寸大小的模型，之后结合推理场景，自适应地选择合适的模型用于离线推理. 早期退出（early exit）与模型选择相似，不同之处在于早期退出除了最终的输出层之外，还可通过中间层输出结果,避免数据流经整个网络，并可以实现参数共享[18].
早期退出（典型的如BranchyNet[102]）通过增加多个推理分支提升模型推理速度. 由于多分支的加入，相比模型切割带来了更多可能性，如文献[32]针对云边协同场景提出分布式深度神经网络（distributed deep neural network，DDNN），以分支为切割点，将切割点的两侧分别部署在边缘端与云端. 与模型选择类似，由于具有多个推理分支，退出点的选择是决定边缘协同推理在云端还是边缘端进行推理的关键. 早期退出通过分支选择器计算分支可信度来决定推理的退出点. 可信度可通过计算Softmax输出层的熵大小或额外增加可信度决策模型得到，如文献[103]提出AO（authentic operation）模块，为每种类型的推理任务建立了个性化的决策阈值，文献[104−105]针对连续多推理请求场景（视频分析），考虑可满足时延要求的退出点，以是否满足时延要求设计收益函数，并以此作为分支选择依据，按照请求的先后次序进行推理，并给出了按先后次序（ordered scheduling structure）调度可以得到的一个最优结果的证明.
在验证方面，如何快速地对所提早期退出算法进行验证是实现快速迭代的前提，文献[106]提出了一款基于MATLAB的DeepFogSim仿真平台，DeepFogSim以能耗-时延为优化目标，模拟云—边—端协同场景，并支持部分资源动态性. 我们前期对目前已有的大量开源边缘计算仿真平台进行了归纳整理，或可为快速验证想法提供有效的技术候选方案[14]. 同时，针对动态场景特点，我们也研发了开源的仿真平台EasiEI[107].
在模型选择方面，简单的形式是同时准备2种尺寸的模型分别部署在边缘侧与云端，边缘侧用于初步的推理，当推理结果的可信度不满足给定的阈值时，则选择云端进行推理[108-109]. 由于模型训练的架构、网络结构不同，在推理时延、能耗以及精度等有所差异，在同一场景下，如何在不同的模型之间进行选择是首先需要考虑的问题，即模型选择器（model selector），如以降低推理时延为目标，通过前置专用的预测模型[110-112]识别输入数据，自动选择合适的推理模型.在不同场景下，尤其是在资源紧张的边缘计算场景下，单终端节点可能面临多任务推理场景或多租户场景. 此时不同任务之间的竞争、调度等易导致服务质量下降. 这方面的研究主要是对不同领域的模型进行智能选择或模型融合[100,106,108,113]. 如文献[63]结合迁移学习共享了部分计算用于支持不同场景的推理任务.
小结与分析：可以看出，模型选择与早期退出都涉及到如何根据给定的优化目标进行决策的问题，在决策过程中需要针对目标设置合理的阈值.然而，优化目标一般是推理精度与能耗、时延等的折中. 由于边缘计算场景众多、资源类型不一，自动化地确定阈值是该类轻量化方法能否适应不同场景的关键，尤其是在推理过程中，阈值的确定应当根据当前的运行状况进行动态改变.文献[54]考虑了节点协同时网络的动态性，提前计算出不同的早期退出点与切割点候选方案，在推理过程中结合网络变化实时调整推理方案，利用多节点协同共同保证推理精度，满足了一定的实时性.但早期退出方法的退出点数量受限于模型层数，在资源已经受限的边缘协同环境中，由于节点算力差异与变化，按照退出点进行切割然后采用协同推理的方式无法提供更加灵活、更细粒度的资源分配控制，这方面还需要进一步提升. 与其他技术，如模型压缩结合或可提供潜在的解决方案. 在模型选择方面，通过协同方式有效获取节点特点、节点运行状态是选择合适模型的关键. 一种可行的方式是结合不同节点的历史数据与推理模型的算子、结构等来训练用于评估推理效果的模型，近期研究nn-Meter[114]根据不同类型边缘节点的特点，对在不同节点上进行推理的时延进行预测取得了不错的效果，该研究或可为在边缘节点上如何选择更好的模型提供支持. 除时延指标外，还有能耗等指标值得考虑.
适用于边缘计算场景的轻量化技术还需要根据场景需求对多种技术进行融合.如在时延及推理精度都具有高要求的工业物联网领域，关注的是如何将轻量级模型运行在单个节点或尽可能地降低多节点协同推理时带来的网络代价，此时可将早期退出与模型切割结合，将一部分推理请求提前过滤[115]；在计算代价大的场景，可考虑将量化与早期退出结合，压缩计算量[94]；当支持节点协同时，可考虑将模型切割、量化与重训练结合[55]，从模型尺寸、推理精度方面一起优化，实现更加高效的分布式协同推理；对于动态场景而言，由于节点负载、网络负载的不断变化会导致部署时所采用的优化目标不满足资源约束，多数解决方案通过将完整的模型存储在每个节点上，通过观测当前的系统状态实时调整协同推理的部署方案，以此来满足资源约束.
2.2 整体架构
仅通过云与端实现的推理场景受多方面制约，难在复杂的业务场景中发挥作用，主要表现在对带宽密集型业务的原始数据或中间数据传输代价大、隐私安全要求高的业务数据传输敏感；所处环境恶劣的业务与云端连接不稳定或限制上行带宽；传输链路过长容易出现故障；端侧能耗限制较强等. 这在智能驾驶、在线交易以及军事等领域十分普遍. 边缘协同推理通过云、边等资源联邦，克服数据传输、隐私安全、运行环境等存在的问题，对推理任务“就近”解决. 文献[8]指出,“边缘”是一个连续统，那么，协同推理的架构主要关注点则是如何调集连续统中的资源. 本文按照资源及数据的协同处理方式，从云与边的角度对边缘协同推理进行分析.
从中心化计算与否出发，为了便于在逻辑上描述，此处将云端或边缘服务器端统称为云端，将终端节点或具有计算能力的边端节点统称为边端. 如图7所示，目前主流的用于进行边缘协同推理的框架主要包含4类. 采用模型切割方式的云边协同推理（图7（a））与边边协同推理（图7（b））、基于模型选择的云边协同推理（图7（c））以及基于多个不同任务场景的多模型结果聚合的边边协同推理（图7（d））. 其中图7（b）基于模型切割的边边协同推理架构根据任务处理的流程及网络拓扑结构又可分为2类：根据模型切割时子切片依赖图形成的网状拓扑与以协调节点或推理请求者为中心的呈放射状的星状拓扑.
![]()
图 7 主流的边缘计算协同推理架构Figure 7. Mainstream of collaborative inference framework in edge computing其中图7（a）基于模型切割的云边协同推理依据模型切割技术，将模型分解为具有先后以来关系的不同切片，分别部署在边端与云端. 边端将部分中间结果经过处理后发送至云端完成后续的计算，最终由云端返回推理结果.考虑的指标主要包含隐私安全、通信代价与计算代价的联合优化. 边端除了对数据预处理[115]、计算一部分中间输出结果外，还可与早期退出结合[54,116]，将一部分具有推理功能的分支部署在边端，当边端推理结果不满足需求时，通过云端更深层次的模型进行推理.该类架构从逻辑上看仅存在一个云与边之间的切割点. 如文献[34,49,54,56−57]等所述，模型主要切分为2部分，分别部署在边端与云端. 由于切片数量的减少，简化了网络拓扑，利于观测网络中的动态变化和协同推理的实时调整. 如文献[54]根据可用带宽自适应地划分移动设备和边缘服务器之间的深度神经网络（DNN）计算，由于推理速度受到移动设备上其他计算任务的限制，不足以满足严格的时延要求，因此又引入了早退机制来进一步降低延迟. 除带宽外,节点负载状况也需要关注[116]，文献[117]基于动态场景，包括传输带宽变化与节点计算能力变化，提出建立可靠性指标，评估了时延约束下模型的可靠性.
其中图7（b）基于模型切割的边边协同推理在不具备云端支持，同时单个节点资源不足的场景下，可将模型切片映射或动态调整到到不同的节点，通过节点间的协同完成推理. 该类方式可自发地通过协同交互处理任务，多涉及资源性能受限节点、节点间具有网络连接，关注的指标主要包括能耗、时延、内存等，较适用于动态场景（资源、环境动态变化）下的单方资源受限、无云端控制或控制存在一定阻碍等场景.该类架构从逻辑上看模型存在多个切割点，所涉及的切片数量多大于2个，较基于模型切割的云边协同推理更为灵活. 根据调度方式的不同，逻辑上的网络拓扑可分为网状拓扑与星状拓扑. 网状拓扑的部署方式一般事先固定，按照切片的先后依赖顺序查找后继节点，应对复杂的动态场景能力弱；星状拓扑在部署上一般通过中心协调点（或推理请求节点）对切片按照先后依赖顺序不断收集中间结果并转发到其他节点进行调度（参见表1中的切片依赖关系处理/服务发现方式)，灵活性较网状拓扑更强，但调度频繁易使代价过高.
其中图7（c）基于模型选择的云边协同推理与模型切割与早期退出结合的云边协同类似，基于模型选择的云边协同推理在边端具有完整的推理能力，不同的是边端所运行的推理模型是完整的. 该类架构下一般是针对同一场景训练2个大小不同尺寸的模型，如借助知识蒸馏技术分别部署在云端与边端. 由于边端的模型尺寸小、推理能力相对较弱，因此在推理精度不可靠的情况下会将推理请求转发至云端进行更为精确的推理[118].该类架构边端与云端的链接是否可靠取决于边端的模型推理精度是否满足需求，本质上由边端的性能决定. 如文献[119]提出在边端运行小模型（SNN），云端（边缘服务器）运行DNN，由边端根据自身运行状态（模型复杂度、推理精度、数据质量、计算能力和通信带宽等）选择是否通过云端获取推理结果.
其中图7（d）基于多模型结果聚合的边边协同推理与多数将推理请求发往云端思路不同，该类架构在概念上与决策级的信息融合相近，中心节点（或推理请求节点）将推理请求下发给多个边端，每个边端具有某一特定任务或领域的推理能力，之后通过汇总来自多个边端的推理结果得出最终结论.不同于基于模型选择的云边协同推理中的场景有限，基于多模型结果聚合的边边协同推理能适应的场景更加多样，这种类似于任务冗余的形式能够提供较高粒度的可靠性及并行性支持.如文献[120]提出基于竞争机制和选择性学习方法，在边端每个节点上运行其所擅长的不同领域的模型，利用多节点的协同，实现多边端协同推理.但由于一个推理请求会同时广播给多个边端，边边协同推理主要关注的是推理精度及速度，在能耗及通信方面值得进一步提升，可通过额外的选择器对多个边端是否执行进行提前筛选[121].
小结与分析：基于2.2节分类及分析可以看出，从推理结果最终的出处来看，边缘计算协同推理架构可分为2类.一类是用户发出推理请求，多节点通过处理协同推理过程中的中间数据，最终由云端或边端中的单个节点得出推理结果，该类思想与向云端卸载任务一致，如图7（a）~（c）所述.另一类是由边端汇总来自其他多个边端或云端的多个推理结果，之后对比评判得出最终的推理结果，该类思想可参考云端将推理任务卸载到边端或众包，如图7（d）所述.从整体云边端角度分析，第1类涉及对模型的压缩、剪枝、量化、切割等过程，第2类则涉及多边端推理结果融合. 表2给出了不同的架构所采用的关键技术、针对的问题及其适用场景的比较.
表 2 不同架构的比较Table 2. Comparison of Different Architectures序号 名称 关键结合技术 针对的问题 适用场景 1 基于模型切割的云边协同推理 模型切割、数据压缩、量化、
矩阵分解/压缩、早期退出边端设备能耗、算力有限、
能耗与时延“折中”有云端支撑、数据预处理、
隐私、负载实时调整2 基于模型切割的边边协同推理 模型切割、数据压缩、量化、
矩阵分解/压缩与云端链接不可靠、单节点资
源受限、能耗与时延“折中”无云端支撑、单节点资源不足
且有邻居节点、通信代价低3 基于模型选择的云边协同推理 数据压缩、模型压缩、知识蒸馏 边端设备推理精度不可靠 推理精度高可信、边端节点
资源相对充足4 基于多模型结果聚合的边边协同推理 数据/模型融合、数据压缩、
异/同步通信协同推理并行度低、
推理精度不可靠多场景协同推理、边端节点资源
充足、对时延要求相对较低对于云计算，目前的分布式架构所利用的资源丰富，推理效果好（推理精度高且推理速度快）是关注的重点，而能耗并非核心关注问题.边缘协同推理由于其资源特点，在推理效果好的前提下同时期望得到低代价的部署方案，其所处的复杂环境决定了这是一个“折中”问题. 节点状态、环境及用户等会对问题的解产生动态性影响，使资源的状态发生变化. 为了更好地提升资源利用率，同时确保服务的有效性，就需要对资源进行重新调度或部署.然而，边缘协同推理属于计算及带宽密集型的复杂业务，所处环境多样,用户不一，具有极大的不确定性[122-123]，不同的调度方式在复杂性及时效性或准确性上存在差异，产生的运维代价不同，服务有效性与资源利用率存在冲突.
在资源调度与控制方面，由于边端设备类型众多,资源涉及多方且参与意愿不同，在协同推理时若非采用资源预分配的手段，很难达到实时的最优协同推理.而资源预分配恰恰是需要统一调度的，这意味着会存在资源上的过度消耗、竞争，调度周期也不好确定，无法及时有效处理多方请求. 因此，对所有资源实现统一调度与控制是不现实的，这导致了推理过程中资源募集能力不一，加剧了边缘协同推理的难度.
从涉及的网络计算资源来看，2节点是分水岭，节点数量影响了调度服务对网络环境、节点负载等的感知能力及处理能力，最终反映在任务调度的实时性上. 单节点自身资源可以支持推理服务的运行，但可靠性差；2节点协同交互简单，方便管理,但不够健壮，处理任务时可调动的资源有限；多节点鲁棒性强，适合动态场景，但模型复杂，管理及优化困难. 目前，2节点主要应用在云边端协同场景，多节点更多应用于IoT场景[45].
因此，边缘协同推理与众多应用层的服务类似，服务表现碎片化、多角度，很难提供一个通用的基础架构. 如智慧城市场景，单独的轨迹数据处理就涉及到乘客、司机、城市规划、交通等诸多角度[124]. 可以看出，对于边缘协同推理的框架而言，调度是否灵活、推理过程是否具有弹性、能否支持多设备（用户）并发推理及并行需求是关键. 除此之外，由于在推理过程中可能涉及到不同类型信息的融合，是否可快速移植支持异构平台，如借助虚拟化技术；是否融合异构网络，如智能家居中的各种传感器网络[125]，也值得关注.随着时间的推移，还会涉及到推理模型的更新问题. 目前来看，这方面主要依据联邦学习[126]或重新部署的形式，更新的频率及更新的代价与更新后能否带来好的收益值得关注.
边缘计算表现出广泛的异构性、动态性，使不同的优化技术应用在“连续统”中，不同类型的边缘节点上存在巨大挑战[127]，这些节点往往运行多种基础服务. 目前多数方案都仅关注在模型角度，完整的协同推理过程除了AI模型外还涉及其他服务，如可靠性保障、数据中间传输、数据存储、日志追踪等的基础支撑服务，尽管多数轻量化技术在时延方面可以满足一些场景需求，但涉及的模块过多时推理服务的稳定性值得进一步研究[128].
3. 边缘协同推理在动态场景下的挑战与展望
本文从边缘智能出发，简要描述了其发展过程. 着重从边缘协同角度对模型推理阶段涉及到的关键技术进行了归纳总结，并从动态场景的角度分别进行了分析. 截至目前,边缘协同智能依然处于快速发展阶段，其大体分为2类：一类是基于原有的智能化方法与边缘计算资源特点不断结合（如深度神经网络架构实现搜索、混合精度量化）；另一类是直接从边缘计算产生的方法（或称边缘原生方法，如模型选择）结合边缘计算资源的特点（地理分布、异构性、动态性等）.目前还存在诸多挑战，下面介绍几个值关注与讨论的方向:
1）推理模型与动态性的适应问题. 以往优化算法较适用于云计算中同质化资源，其资源状态变化不大，一般按需分配、按需扩展，利于结合业务对负载实时调控.然而，在应对具有一定规模的呈地理分布的边缘节点时，由于边缘节点相对于云计算节点的可控性不强，且存在资源异构性及动态性，使当前边缘协同推理智能化的主流方法中还存在一些值得进一步关注的问题，如模型切割技术的整体或部分更新问题；模型压缩技术在不同节点间的可移植性及再训练问题；模型选择/早期退出在面对资源变化时的不同模型问题；分支切换灵活性及资源分配粒度问题. 同时，如2.2节所述，尽管目前已经呈现出不同技术的融合态势，但在协同环境下，边缘协同推理智能化方法依旧面临许多共性问题，如已部署模型的更新替换频率及兼容性问题、动态资源变化与所运行模型（或部分）资源需求的匹配问题、额外的中心调度或部署代价问题等.
2）在边缘协同推理验证方面，动态场景建模将促进协同推理相关方法的良性发展. 动态场景下的边缘计算普遍存在硬件故障、系统及软件的负载变化、人为与环境因素的影响、地理分布广泛以及服务状态复杂多变易受影响等特点，运维成为一大挑战.纵观已有研究，在验证思路时多数通过实际的生产场景，或较为简单的代价评估模型模拟，缺乏动态场景特点上的考虑. 造成这种现状的原因，一是生产场景对于广泛的研究人员并不容易可及，二是模拟场景考虑的影响因素不够全面，在边缘协同推理的有效性评估上还存在困难，给边缘协同智能的落地带来一定阻碍. 除此之外，边缘协同推理作为完整应用，还涉及各种网络、计算中间件的运行，这些中间件无一不需要大量的资源来维护. 因此，提供一个可信的动态仿真场景值得研究.
3）在边缘原生方法方面，在线学习与边缘计算的结合或可为边缘协同智能提供更广阔的适用场景. 目前多数研究或工作将训练与推理分开，界线清晰,较适合于资源丰富且动态性不强的场景. 但对于涉及计算、网络等资源存在限制且动态的场景，单独的训练过程并不适用，如何利用有限的资源对推理模型进行在线更新值得研究，相关研究领域或可参考感知计算、触觉网络等.
4. 结 语
边缘协同推理具有极大的应用价值，目前，正处于快速发展期，但清晰而又统一的处理方法尚未形成，值得我们重点研究. 本文对边缘协同智能的发展历史进行了简要回顾，对推理过程中涉及到的关键技术进行了归纳整理. 通过对不同关键技术的纵向总结、适用场景分析以及技术间的对比等，重点从动态场景角度提出了边缘协同推理存在的挑战与值得发展的方向. 整体来看，边缘协同推理目前还有极大的发展空间，我们未来的研究工作重点将放在动态场景建模以及动态场景下的边缘协同推理可靠性保障方面.
作者贡献声明：王睿设计了论文框架、调研文献、指导论文写作并修改论文;齐建鹏和陈亮负责文献调研、撰写及修改部分论文；杨龙补充完善论文.
-
![]()
图 2 使用层次聚类算法进行IPv6空间划分的示例
Figure 2. An example of IPv6 space partitioning using hierarchical clustering algorithms
![]()
图 3 不同发包量下各目标生成扫描方法命中率和边际效益对比
Figure 3. Comparison of hit rate and marginal benefit of each target generation scanning algorithm with various probing budget
表 1 使用主动方式获取IPv6地址的主要来源
Table 1 Main Sources of Obtaining IPv6 Addresses Using Active Measurement
下载: 导出CSV
表 2 典型目标生成算法技术对比
Table 2 Technologies Comparison of Typical Target Generation Algorithms
扫描算法 目标生成算法 生成算法
复杂度论文中最大
种子集数量论文中最大
发包量是否开源
（实现语言）适用扫描
场景6GAN[40] GAN 难以估计 5.0×104 0.05×106 是(Python) 小规模 6Gen[41] AHC O(n3) 10.0×104 1.00×106 否(C++) 小规模 6Tree[42] DHC O(nlogn) 40.0×104 1500.00 ×106是(C++) 中等规模 6Forest[44] DHC+EL Ω(nlogn) 140.0×104 500.00×106 是(Python) 中等规模 6Hit[46] DHC+RL Ω(nlogn) 10.0×104 10.00×106 是(Python) 小规模 AddrMiner[47] DHC+RL Ω(nlogn) 100.0×104 50.00×106 否(Python) 小规模 6Scan[48] DHC O(nlogn) 367.0×104 1500.00 ×106是(C++) 中等规模 HMap6[30] HC(AHC+DHC) O(nlogn) 568.9×104 7808.00 ×106是(C++) 大规模
下载: 导出CSV
表 3 种子集属性信息
Table 3 Characteristic Messages of Seedsets
种子集 种子数量 涵盖国家/地区数量 涵盖自治域数量 SICMPv6 569×104 200 16435 SUDP53 258×104 197 13476 STCP_ACK80 43×104 148 4638
下载: 导出CSV
表 4 目标生成算法在不同种子集下生成不同维度数的子空间数量
Table 4 Subspace Numbers with Different Dimension Numbers Generated by Target Generation Algorithms with Different Seedsets
生成算法 SICMPv6 SUDP53 STCP_ACK80 1维 2维 3维 4维 1维 2维 3维 4维 1维 2维 3维 4维 AHC 47.54×104 39.83×104 18.09×104 11.06×104 17.54×104 13.77×104 7.49×104 5.59×104 0.61×104 1.06×104 1.57×104 1.21×104 DHC 3.32×104 3.21×104 2.62×104 1.72×104 1.88×104 1.54×104 1.83×104 1.22×104 0.49×104 0.22×104 0.34×104 0.22×104 HC 47.71×104 40.42×104 19.56×104 11.92×104 17.60×104 14.22×104 8.72×104 6.27×104 0.66×104 1.13×104 1.66×104 1.32×104
下载: 导出CSV
表 5 各目标生成算法扫描结果对比
Table 5 Comparison of Scanning Results of Each Target Generation Algorithm
种子集 探测预
算个数目标生成算法 发现/80
前缀总数量命中率/% SICMPv6 78.1亿 HMap6 25.47×106 0.33 6Gen 22.76×106 0.29 6Scan 15.08×106 0.19 6Forest 12.98×106 0.17 6Tree 12.91×106 0.17 SUDP53 41.1亿 HMap6 8.35×106 0.20 6Gen 7.89×106 0.19 6Scan 6.24×106 0.15 6Forest 4.11×106 0.10 6Tree 4.19×106 0.10 STCP_ACK80 8.60亿 HMap6 4.14×106 0.48 6Gen 3.65×106 0.42 6Scan 3.65×106 0.42 6Forest 3.47×106 0.40 6Tree 3.37×106 0.39 合计 127.8亿 HMap6 29.39×106 0.23 6Gen 26.27×106 0.21 6Scan 17.40×106 0.14 6Forest 14.98×106 0.12 6Tree 14.90×106 0.12
下载: 导出CSV
表 6 各目标生成扫描算法的时间开销
Table 6 Time Cost of Each Target Generation Scanning Algorithm
种子集 目标生
成算法子空间生成
时间花销扫描时间
花销总时间
花销SICMPv6 HMap6 43 s 22 h50 min10 s 22 h50 min53 s 6Gen 56 h24 min36 s 22 h48 min15 s 79 h12 min51 s 6Scan 23 s 22 h50 min11 s 22 h50 min34 s 6Forest 30 s 22 h49 min15 s 22 h49 min45 s 6Tree 23 s 22 h49 min13 s 22 h49 min36 s SUDP53 HMap6 19 s 12 h8 min43 s 12 h9 min2 s 6Gen 5 h43 min12 s 12 h5 min51 s 17 h49 min3 s 6Scan 10 s 12 h9 min21 s 12 h9 min31 s 6Forest 11 s 12 h10 min 12 h10 min11 s 6Tree 10 s 12h10 min21 s 12h10 min31 s STCP_ACK80 HMap6 7 s 2 h34 min7 s 2 h34 min14 s 6Gen 1 min35 s 2 h30 min54 s 2 h32 min29 s 6Scan 4 s 2 h33 min51 s 2 h33 min55 s 6Forest 4 s 2 h32 min12 s 2 h32 min16 s 6Tree 4 s 2 h35 min3 s 2 h35 min7 s
下载: 导出CSV
-
[1] Dhamdhere A, Luckie M, Huffaker B, et al. Measuring the deployment of IPv6: Topology, routing and performance[C]//Proc of the 12th ACM Internet Measurement Conf (IMC). New York: ACM, 2012: 537−550
[2] 李果,何林,宋光磊,等. 基于种子地址的IPv6地址探测技术综述[J]. 电信科学,2019,35(12):24−37 Li Guo, He Lin, Song Guanglei, et al. Survey of IPv6 address probing technology based on seed address[J]. Telecom Science, 2019, 35(12): 24−37 (in Chinese)
[3] Durumeric Z, Wustrow E, Halderman J A, et al. ZMap: Fast Internet-wide scanning and its security applications[C]//Proc of the 22nd USENIX Security Symp (USENIX Security). Berkeley, CA: USENIX Association, 2013: 605–620
[4] Graham R D. MASSCAN: Mass IP port scanner[CP/OL]. [2023-09-20].https://github.com/robertdavidgraham/masscan
[5] Matherly J. Shodan: The search engine for Internet-connected devices[EB/OL]. [2023-09-20].https://www.shodan.io
[6] Durumeric Z, Adrian D, Mirian A, et al. A search engine backed by Internet-wide scanning[C]//Proc of the 22nd ACM SIGSAC Conf on Computer and Communications Security (CCS). New York: ACM, 2015: 542–553
[7] Fan Xun, Heidemann J. Selecting representative IP addresses for Internet topology studies[C]//Proc of the 10th ACM Internet Measurement Conf (IMC). New York: ACM, 2010: 411–423
[8] Gasser O, Scheitle Q, Gebhard S, et al. Scanning the IPv6 Internet: Towards a comprehensive hitlist [J]. arXiv preprint, arXiv: 1607.05179, 2016
[9] Song Guanglei, He Lin, Wang Zhiliang, et al. Towards the construction of global IPv6 Hitlist and efficient probing of IPv6 address space[C]//Proc of the 28th IEEE/ACM Int Symp on Quality of Service (IWQoS). Piscataway, NJ: IEEE, 2020: 11–20
[10] Huz G, Bauer S, Claffy K, et al. Experience in using MTURK for network measurement[C]//Proc of the 15th ACM SIGCOMM Workshop on Crowdsourcing and Crowdsharing of Big (Internet) Data. New York: ACM, 2015: 27–32
[11] Lone Q, Luckie M, Korczynski M, et al. Using crowdsourcing marketplaces for network measurements: The case of spoofer[C]//Proc of the 18th Network Traffic Measurement and Analysis Conf (TMA). Piscataway, NJ: IEEE, 2018: 10–18
[12] Varvello M, Blackburn J, Naylor D, et al. EYORG: A platform for crowdsourcing Web quality of experience measurements[C]//Proc of the 12th Int Conf on Emerging Networking Experiments and Technologies (CoNEXT). New York: ACM, 2016: 399–412
[13] Gont F, Chown T. RFC 7707 Network Reconnaissance in IPv6 Networks[S/OL]. 2016 [2023-09-20].https://datatracker.ietf.org/doc/rfc7707/
[14] Strowes S D. Bootstrapping active IPv6 measurement with IPv4 and public DNS [J]. arXiv preprint, arXiv: 1710.08536, 2017
[15] Fiebig T, Borgolte K, Hao Shuang, et al. Something from nothing (there): Collecting global IPv6 datasets from DNS[C]//Proc of the 17th Passive and Active Measurement Conf (PAM). Berlin: Springer, 2017: 30–43
[16] Fiebig T, Borgolte K, Hao Shuang, et al. In rDNS we trust: Revisiting a common data-source’s reliability[C]//Proc of the 18th Passive and Active Measurement Conf (PAM). Berlin: Springer, 2018: 131–145
[17] Borgolte K, Hao S, Fiebig T, et al. Enumerating active IPv6 hosts for largescale security scans via DNSSEC-signed reverse zones[C]//Proc of the 18th IEEE Symp on Security and Privacy (S&P). Piscataway, NJ: IEEE, 2018: 770–784
[18] Gasser O, Scheitle Q, Foremski P, et al. Clusters in the expanse: Understanding and unbiasing IPv6 Hitlists[C]//Proc of the 18th ACM Internet Measurement Conf (IMC). New York: ACM, 2018: 364–378
[19] Rapid7. DNS records (ANY)[EB/OL]. [2023-09-20].https://scans.io/study/sonar.fdns
[20] Addy Y. Bitnodes API[EB/OL]. [2023-09-20].https://bitnodes.earn.com/
[21] Alexa. The top sites on the Web[EB/OL]. [2023-09-20].https://www.alexa.com/topsites
[22] Statvoo. Website analytics and reviews[EB/OL]. [2023-09-20].https://statvoo.com
[23] Cisco. Cisco umbrella[EB/OL]. [2023-09-20].https://umbrella.cisco.com
[24] PremiumDrops. Domain zone file and zone changes downloads[EB/OL]. [2023-09-20].https://www.premiumdrops.com/zones.html
[25] CAIDA. IPv6 topology[EB/OL]. [2023-09-20]. http://www.caida.org/data/active/ipv6_allpref_topology_dataset.xml
[26] RIPE. RIPE NCC Atlas[EB/OL]. [2023-09-20].https://atlas.ripe.net
[27] Rye E C, Beverly R. Discovering the IPv6 network periphery[C]//Proc of the 20th Passive and Active Measurement Conf (PAM). Berlin: Springer, 2020: 3–18
[28] Luckie M. Scamper: A scalable and extensible packet prober for active measurement of the Internet[C]//Proc of the 10th ACM Internet Measurement Conf (IMC). New York: ACM, 2010: 239–245
[29] Beverly R, Durairajan R, Plonka D, et al. In the IP of the beholder: Strategies for active IPv6 topology discovery[C]//Proc of the 18th ACM Internet Measurement Conf (IMC). New York: ACM, 2018: 308–321
[30] Hou Bingnan, Cai Zhiping, Wu Kui, et al. Search in the expanse: Towards active and global IPv6 hitlists[C]//Proc of the 23rd IEEE Int Conf on Computer Communications (INFOCOM). Piscataway, NJ: IEEE, 2023: 10–20
[31] Hu Qinwen, Brownlee N. How interface ID allocation mechanisms are performed in IPv6[C]//Proc of the 14th ACM Int Conf on Emerging Networking Experiments and Technologies Student Workshop (CoNEXT Workshop). New York: ACM, 2014: 26–27
[32] RIPE. RIPEstat data API[EB/OL]. 2021 [2023-09-20].https://stat.ripe.net/docs/data_api/
[33] Barnes R, Altmann R, Kerr D. Mapping the great void smarter scanning for IPv6 [R/OL]. 2012 [2023-09-20].https://www.caida.org/workshops/isma/1202/slides/aims1202_rbarnes.pdf
[34] Gasser. IPv6 Hitlist service[EB/OL]. [2023-09-20].https://ipv6hitlist.github.io/
[35] Ullrich J, Kieseberg P, Krombholz K, et al. On reconnaissance with IPv6: A pattern-based scanning approach[C]//Proc of the 10th IEEE Int Conf on Availability, Reliability and Security (ARES). Piscataway, NJ: IEEE, 2015: 186–192
[36] Foremski P, Plonka D, Berger A. Entropy/IP: Uncovering structure in IPv6 addresses[C]//Proc of the 16th ACM Internet Measurement Conf (IMC). New York: ACM, 2016: 167–181
[37] Narten T, Jinmei T, Thomson S. RFC 4862 IPv6 stateless address autoconfiguration [S/OL]. 2007 [2023-09-23].https://www.rfc-editor.org/rfc/rfc4862
[38] Cui Tianyu, Gou Gaopeng, Xiong Gang. 6GCVAE: Gated convolutional variational autoencoder for IPv6 target generation[C]//Proc of the 24th Pacific-Asia Conf on Knowledge Discovery and Data Mining. Berlin: Springer, 2020: 609–622
[39] Cui Tianyu, Xiong Gang, Gou Gaopeng, et al. 6VecLM: Language modeling in vector space for IPv6 target generation[C]//Proc of the 21st European Conf on Machine Learning and Knowledge Discovery in Databases. Berlin: Springer, 2021: 192–207
[40] Cui Tianyu, Gou Gaopeng, Xiong Gang, et al. 6GAN: IPv6 multi-pattern target generation via generative adversarial nets with reinforcement learning[C]//Proc of the 21st IEEE Int Conf on Computer Communications (INFOCOM). Piscataway, NJ: IEEE, 2021: 11–20
[41] Murdock A, Li F, Bramsen P, et al. Target generation for Internet-wide IPv6 scanning[C]//Proc of the 17th ACM Internet Measurement Conf (IMC). New York: ACM, 2017: 242–253
[42] Liu Zhizhu, Xiong Yinqiao, Liu Xie, et al. 6Tree: Efficient dynamic discovery of active addresses in the IPv6 address space[J]. Computer Networks, 2019, 155(1): 31−46
[43] Yang Tao, Hou Bingnan, Cai Zhiping, et al. 6Graph: A graph-theoretic approach to address pattern mining for Internet-wide IPv6 scanning[J]. Computer Networks, 2022, 203(1): 108−130
[44] Yang Tao, Hou Bingnan, Zhou Tongqing, et al. 6Forest: An ensemble learning-based approach to target generation for Internet-wide IPv6 scanning[C]//Proc of the 22nd IEEE Int Conf on Computer Communications (INFOCOM). Piscataway, NJ: IEEE, 2022: 1679–1688
[45] Zirngibl J, Steger L, Sattler P, et al. Rusty clusters? Dusting an IPv6 research foundation[C]//Proc of the 22nd ACM Internet Measurement Conf (IMC). New York: ACM, 2022: 395–409
[46] Hou Bingnan, Cai Zhiping, Wu Kui, et al. 6Hit: A reinforcement learning-based approach to target generation for Internet-wide IPv6 scanning[C]//Proc of the 21st IEEE Int Conf on Computer Communications (INFOCOM). Piscataway, NJ: IEEE, 2021: 11–20
[47] Song Guanglei, Yang Jiahai, He Lin, et al. AddrMiner: A comprehensive global active IPv6 address discovery system[C]//Proc of the 22nd USENIX Annual Technical Conf (ATC). Berkeley, CA: USENIX Association, 2022: 309–326
[48] Hou Bingnan, Cai Zhiping, Wu Kui, et al. 6Scan: A high-efficiency dynamic Internet-wide IPv6 scanner with regional encoding[J]. IEEE/ACM Transactions on Networking, 2023, 99(1): 1−16
[49] Hou Bingnan. HMap6 IPv6 Hitlists[EB/OL]. [2023-09-20].https://hbn1987.github.io/HMap6.github.io/
[50] Beverly R. Yarrp’ing the Internet: Randomized high-speed active topology discovery[C]//Proc of the 16th ACM Internet Measurement Conf (IMC). New York: ACM, 2016: 413–420
[51] Huang Yuchen, Rabinovich M, Al-Dalky R. FlashRoute: Efficient traceroute on a massive scale[C]//Proc of the 20th ACM Internet Measurement Conf (IMC). New York: ACM, 2020: 443–455
[52] Spring N, Mahajan R, Wetherall D. Measuring ISP topologies with rocketfuel[J]. ACM SIGCOMM Computer Communication Review, 2002, 32(4): 133−145 doi: 10.1145/964725.633039
[53] MaxMind. Geolite API[EB/OL]. [2023-09-20]. http://dev.maxmind.com/geoip/legacy/geolite/
[54] MaxMind. IP2Location[EB/OL]. [2023-09-20]. http://lite.ip2location.com
[55] Fontugne R, Pelsser C, Aben E, et al. Pinpointing delay and forwarding anomalies using large-scale traceroute measurements[C]//Proc of the 17th ACM Internet Measurement Conf (IMC). New York: ACM, 2017: 15–28
[56] Padmanabhan R, Schulman A, Dainotti A, et al. How to find correlated Internet failures[C]//Proc of the 19th Passive and Active Measurement Conf (PAM). Berlin: Springer, 2019: 210–227
[57] Hou Bingnan, Hou Changshen, Zhou Tongqing, et al. Detection and characterization of network anomalies in large-scale RTT time series[J]. IEEE Transactions on Network and Service Management, 2021, 18(1): 793−806 doi: 10.1109/TNSM.2021.3050495
[58] Czyz J, Luckie M, Allman M, et al. Don’t forget to lock the back door! A characterization of IPv6 network security policy[C]//Proc of the 16th Network and Distributed System Security Symp (NDSS). Berkeley, CA: USENIX Association, 2016: 13–25
[59] Li Xiang, Liu Baojun, Zheng Xiaofeng, et al. Fast IPv6 network periphery discovery and security implications[C]//Proc of the 51st IEEE/IFIP Int Conf on Dependable Systems and Networks (DSN). Piscataway, NJ: IEEE, 2021: 88–100
[60] Durumeric Z, Kasten J, Bailey M, et al. Analysis of the HTTPS certificate ecosystem[C]//Proc of the 13th ACM Internet Measurement Conf (IMC). New York: ACM, 2013: 291–304
[61] Durumeric Z, Li F, Kasten J, et al. The matter of heartbleed[C]//Proc of the 14th ACM Internet Measurement Conf (IMC). New York: ACM, 2014: 475–488
[62] Durumeric Z, Adrian D, Mirian A, et al. Neither snow nor rain nor MITM..: An empirical analysis of email delivery security[C]//Proc of the 15th ACM Internet Measurement Conf (IMC). New York: ACM, 2015: 27–39
[63] Holz R, Amann J, Mehani O, et al. TLS in the wild: An Internet-wide analysis of TLS-based protocols for electronic communication[C]//Proc of the 16th Network and Distributed System Security Symp (NDSS). Berkeley, CA: USENIX Association, 2016: 13–25
[64] Kuhrer M, Hupperich T, Bushart J, et al. Going wild: Large-scale classification of open DNS resolvers[C]//Proc of the 15th ACM Internet Measurement Conf (IMC). New York: ACM, 2015: 355–368
[65] Pearce P, Jones B, Li F, et al. Global measurement of DNS manipulation[C]//Proc of the 26th USENIX Security Symp (USENIX Security). Berkeley, CA: USENIX Association, 2017: 307–323
[66] Springall D, Durumeric Z, Halderman J A. FTP: The forgotten cloud[C]//Proc of the 46th IEEE/IFIP Int Conf on Dependable Systems and Networks (DSN). Piscataway, NJ: IEEE, 2016: 503–513
[67] Li F, Durumeric Z, Czyz J, et al. You’ve got vulnerability: Exploring effective vulnerability notifications[C]//Proc of the 25th USENIX Security Symp (USENIX Security). Berkeley, CA: USENIX Association, 2016: 1033–1050
[68] Feng Xuan, Li Qiang, Wang Haining, et al. Acquisitional rule-based engine for discovering Internet-of-thing devices[C]//Proc of the 27th USENIX Security Symp (USENIX Security). Berkeley, CA: USENIX Association, 2018: 327–341
[69] 李振宇,丁勇,袁方,等. 基于IPv6网络的移动目标防御与访问控制融合防护方法[J]. 计算机研究与发展,2022,59(5):1105−1119 doi: 10.7544/issn1000-1239.20211118 Li Zhenyu, Ding Yong, Yuan Fang, et al. An integrated protection method of moving target defense and access control based on IPv6 network[J]. Journal of Computer Research and Development, 2022, 59(5): 1105−1119 (in Chinese) doi: 10.7544/issn1000-1239.20211118
[70] Geoffrey A, Antonio M E, Jedidiah R C. Detecting TCP/IP connections via IPID Hash collisions[J]. Proceedings on Privacy Enhancing Technologies, 2019, 4(1): 311−328
[71] Feng Xuan, Fu Chuangpu, Li Qi, et al. Off-path TCP exploits of the mixed IPID assignment[C]//Proc of the 20th ACM SIGSAC Conf on Computer and Communications Security (CCS). New York: ACM, 2020: 1323–1335
[72] Feng Xuewei, Li Qi, Sun Kun, et al. PMTUD is not panacea: Revisiting IP fragmentation attacks against TCP[C]//Proc of the 22nd Network and Distributed System Security Symp (NDSS). Berkeley, CA: USENIX Association, 2022: 12–25
[73] Li Guangyu, Zhang Menghao, Guo Chen, et al. IMap: Fast and scalable in-network scanning with programmable switches[C]//Proc of the 19th USENIX Symp on Networked Systems Design and Implementation (NSDI). Berkeley, CA: USENIX Association, 2022: 667–681
-
期刊类型引用(2)
1. 郭宇星，姚凯旋，王智强，温亮亮，梁吉业. 基于特征拓扑融合的黑盒图对抗攻击. 计算机科学. 2024(01): 355-362 . 
百度学术
2. 武阳，刘靖. 面向图像分析领域的黑盒对抗攻击技术综述. 计算机学报. 2024(05): 1138-1178 . 百度学术
其他类型引用(2)
计量
- 文章访问数: 241
- HTML全文浏览量: 55
- PDF下载量: 75
- 被引次数: 4
