上世纪末期，基于
C/S模式的思想，人们发展了HTTP、FTP等应用层协议。然而C/S模式的弊端很明显：服务器的负载过大，下载速率过慢。基于上述背景，有人结合P2P网络与负载均衡的思想，提出P2P下载模式。
背景
网络下载
提起网络下载领域，你应该首先会想到基于TCP/IP协议簇的C/S模式。这种模式希望每一个客户机都与服务器建立TCP连接，服务器轮询监听TCP连接并依次响应，如下图：
上世纪末期，基于C/S模式的思想，人们发展了HTTP、FTP等应用层协议。然而C/S模式的弊端很明显：服务器的负载过大，下载速率过慢。随着互联网规模的增大以及客户对于下载数据大小，下载速率等需求的上升，这些弊端被不断放大。
P2P 下载原理
基于上述背景，有人结合P2P网络与负载均衡的思想，提出P2P下载模式。这种模式不再把所有的下载压力丢给服务器，服务器只负责传递文件元数据，真正的文件下载连接建立在客户机与客户机之间。同时一个文件可以被分片为多个块，同一个文件中不同的块可以在不同的客户机之上下载，使得下载文件在P2P网络中动态流通，大幅提升了下载效率，如下图：
去中心化的P2P下载基于DHT技术，它采用分布式全网方式来进行信息的存储和检索。所有信息均以哈希表条目形式加以存储，这些条目被分散地存储在各个节点上，从而以全网方式构成一张巨大的分布式哈希表。在此基础上做到对单服务器的去中心化，哈希表负责对负载的分摊，将全网负载均摊到多个机器之上。
Dragonfly简介及架构概述
Dragonfly是一款基于 P2P 的智能镜像和文件分发工具。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在应用分发、缓存分发、日志分发和镜像分发等领域被大规模使用。
原理
Dragonfly结合C/S架构与P2P架构的优点。它提供面向客户的C/S架构下载模式。同时它也提供面向服务器集群的P2P回源模式，与传统P2P不同的是，对等网络建立在Scheduler内部，目标是最大化P2P内部下载效率，如下图：
架构简介
Dragonfly面向镜像分发和文件分发，结合P2P网络和服务器集群的思想，向用户提供稳定的、高效的下载服务。Dragonfly希望在服务器内部构建P2P网络，将服务器的不同主机节点分为 Manager、Scheduler、Seed Peer 以及 Peer 四个角色，分别提供不同的功能。
其中Manager提供总体配置功能，拉取其他角色的配置并相互通信。Scheduler提供下载调度功能，其调度结果直接影响下载速率。Seed Peer负责回源下载，从外部网络中拉取所需的镜像或文件。Peer作为C/S架构中的服务器，通过多种协议向客户提供下载功能。架构图如下：
其中，Seed Peer支持使用多种协议从外部网络中回源下载，同时也支持当作集群当中一个Peer使用。Peer提供基于多种协议的下载服务，也提供为镜像仓库或其他下载任务的代理服务。
组件详解
Manager
Manager在多P2P集群部署的时候扮演管理者的角色，提供前端控制台方便用户进行可视化操作P2P集群。其主要提供动态配置管理、维护集群稳定性以及维护多套P2P集群的关联关系等功能。对于维护集群整体稳定性Manager和各个服务保持Keepalive保证能够在实例异常情况下将异常实例进行剔除。动态配置管理可以在Manager上面操作各个组件的控制单元，比如控制Peer和Seed Peer的负载数，Scheduler调度Parent的个数等。Manager也可以维护多套P2P集群关联关系，一个Scheduler Cluster、一个Seed Peer Cluster和若干个Peer组成一个完整的P2P集群，当然不同P2P集群可以是网络隔离的。正常情况下采用一个机房一套P2P集群，统一由一个Manager管理多个P2P集群。
Scheduler
Scheduler主要工作就是为当前下载节点寻找最优父节点并触发Seed Peer进行回源下载。在适当时候让Peer进行回源下载。Scheduler在启动时，先向Manager注册，注册成功后初始化动态配置客户端，并从Manager拉取动态配置，接下来启动Scheduler自身所需的服务。
Scheduler的核心就是选取一组最优Parent节点供当前下载Peer进行下载。Scheduler面向Task，一次Task就是一次完整的下载任务，在Scheduler中存储Task信息和相应P2P下载网络的DAG。调度过程是首先过滤异常Parent节点，根据多维度进行过滤，比如判断该Peer是否是BadNode，判断逻辑为假设每个节点的响应时长都遵循正态分布，若一个节点目前的响应时长处于 6σ 范围之外，那么认为该节点是BadNode，剔除该节点。再根据历史下载特征值对剩余待定Parent节点进行打分，返回一组分数最高的Parent提供给当前Peer进行下载。
Seed Peer和Peer
Seed Peer和Peer有很多相似之处。他们都是基于Dfdaemon，不同的是Seed Peer采用Seed Peer模式，支持主动触发回源下载。Peer采用Peer模式，作为C/S架构中的服务器向用户提供下载功能，支持被Scheduler被动触发回源下载。这表明Peer和Seed Peer的关系不是固定的，一个Peer可以通过回源使自己成为Seed Peer，Seed Peer也可以改动运行状态变为Peer，Scheduler会动态地对相应DAG进行改动。另外Seed Peer和Peer都需要参与调度下载过程当中，Scheduler可能会选取Seed Peer或者Peer作为父节点向其他Peer提供下载功能。
Dfstore 和 Dfcache
Dfcache是dragonfly的缓存客户端，它与dfdaemon通信并对P2P网络中的文件进行操作，其中P2P网络充当缓存系统。可以在Scheduler中存储相应Task和DAG。
Dfstore是dragonfly存储客户端. 其可以依赖不同类型的对象存储服务作为Backend，提供稳定的存储方案，现在支持S3和OSS。Dfstore依赖Backend对象存储服务结合P2P本身的加速特点。可做到快写快读，并且能够节省回源以及跨机房流量，减少源站压力。
优势
稳定性
Dragonfly会自动隔离异常节点来提高下载稳定性，Dragonfly中各个组件通过Keepalive与Manager进行联系，Manager能够保证返回给Peer的Scheduler地址和返回给Scheduler的Seed Peer地址都是可用的。不可用的Scheduler和Seed Peer不会被Manager推给需要进行下载任务的Peer或Scheduler，从而达到隔离异常节点的目的，这也是实例维度的异常隔离，如下图：
另外Dragonfly在调度时以Task为单位，也确保了整个调度过程的稳定性。在收到一个新的Task调度请求之后，Scheduler触发Seed Peer进行回源下载；在收到一个已有Task的调度请求之后，Scheduler调度最优Parent Peer集合返回给Peer。这个逻辑确保了无论Task是否下载过，Dragonfly都可以对其进行处理。此外在Scheduler调度过程中，对响应时长过慢的Peer，认为目前是异常节点，将不会作为Parent Peer被返还。这也是Task维度的异常隔离。
高效性
Dragonfly采用P2P进行服务端内部的回源，P2P下载本身即分摊负载，将每个服务端节点的负载降到最低，有以下几个细节保证了Dragonfly下载的高效性：
-
Scheduler通过为每个可能的Parent打分，返回给Peer目前局部最优的Parent集合，Peer基于此集合做下载。 -
下载过程基于
Task，每个Task将待下载文件分为多个Piece，Peer拿到了最优的Parent之后，向此集合广播每个Piece的下载请求，集合中的Parent收到该请求后返回给Peer对应Piece的元信息，Peer将第一个收到的Piece元信息所对应的Parent Peer作为该Piece的实际下载源。该做法考虑到Scheduler返回可用Parent到触发下载这段时间内可能的变化，同时对不同的Piece，允许Peer向不同的下载源获取数据。 -
Dfdaemon分为Seed Peer模式和Peer模式，允许Seed Peer和Peer进行切换，可以根据实际需求改变作为Seed Peer和Peer的机器数目，动态调整更适应实际情况。
简单易用
Dragonfly提供Helm Charts、Docker Compose、Docker Image以及二进制的多种部署方式。用户可以快速一键部署进行一次简单POC，并且也可以基于Helm Charts进行大规模生产部署。当然Dragonfly各个服务都有完善的Metrics也提供现成的Granafa模版，方便用户观察P2P的流量走势。
Dragonfly作为CNCF在镜像加速领域标准解决方案，结合Dragonfly子项目Nydus进行按需加载可以最大限度提升镜像下载速度，未来我们也会继续努力建设镜像加速领域的生态链。感谢所有参与到社区建设的同学，希望有更多对镜像加速领域或P2P感兴趣的同学加入（文末扫描二维码或搜索钉钉群号：44701621进群交流）到我们的社区当中。