dht去中心化

㈠ 如何建立一个完整可用的安全大数据平台

“
要建立一个大数据系统，我们需要从数据流的源头跟踪到最后有价值的输出，并在现有的Hadoop和大数据生态圈内根据实际需求挑选并整合各部分合适的组件来构建一个能够支撑多种查询和分析功能的系统平台。这其中既包括了对数据存储的选择，也涵盖了数据线上和线下处理分离等方面的思考和权衡。此外，没有任何一个引入大数据解决方案的商业应用在生产环境上承担的起安全隐患。

1
计算框架篇
大数据的价值

只有在能指导人们做出有价值的决定时，数据才能体现其自身的价值。因此，大数据技术要服务于实际的用途，才是有意义的。一般来说，大数据可以从以下三个方面指导人们做出有价值的决定：

报表生成（比如根据用户历史点击行为的跟踪和综合分析、 应用程序活跃程度和用户粘性计算等）；

诊断分析（例如分析为何用户粘性下降、根据日志分析系统为何性能下降、垃圾邮件以及病毒的特征检测等）；

决策（例如个性化新闻阅读或歌曲推荐、预测增加哪些功能能增加用户粘性、帮助广告主进行广告精准投放、设定垃圾邮件和病毒拦截策略等）。

图 1

进一步来看，大数据技术从以下三个方面解决了传统技术难以达成的目标（如图1）：

在历史数据上的低延迟（交互式）查询，目标是加快决策过程和时间， 例如分析一个站点为何变缓慢并尝试修复它；

在实时数据上的低延迟查询，目的是帮助用户和应用程序在实时数据上做出决策， 例如实时检测并阻拦病毒蠕虫（一个病毒蠕虫可以在1.3秒内攻击1百万台主机）；

更加精细高级的数据处理算法，这可以帮助用户做出“更好”的决策， 例如图数据处理、异常点检测、趋势分析及其他机器学习算法。

蛋糕模式

从将数据转换成价值的角度来说，在Hadoop生态圈十年蓬勃成长的过程中，YARN和Spark这二者可以算得上是里程碑事件。Yarn的出现使得集群资源管理和数据处理流水线分离，大大革新并推动了大数据应用层面各种框架的发展（SQL on Hadoop框架, 流数据，图数据，机器学习）。

它使得用户不再受到MapRece开发模式的约束，而是可以创建种类更为丰富的分布式应用程序，并让各类应用程序运行在统一的架构上，消除了为其他框架维护独有资源的开销。就好比一个多层蛋糕，下面两层是HDFS和Yarn, 而MapRece就只是蛋糕上层的一根蜡烛而已，在蛋糕上还能插各式各样的蜡烛。

在这一架构体系中，总体数据处理分析作业分三块（图2），在HBase上做交互式查询（Apache Phoenix, Cloudera Impala等）， 在历史数据集上编写MapRece程序抑或利用Hive等做批处理业务， 另外对于实时流数据分析Apache Storm则会是一种标准选择方案。

虽然Yarn的出现极大地丰富了Hadoop生态圈的应用场景，但仍存有两个显而易见的挑战：一是在一个平台上需要维护三个开发堆栈；二是在不同框架内很难共享数据，比如很难在一个框架内对流数据做交互式查询。这也意味着我们需要一个更为统一和支持更好抽象的计算框架的出现。

图 2

一统江湖

Spark的出现使得批处理任务，交互式查询，实时流数据处理被整合到一个统一的框架内（图3），同时Spark和现有的开源生态系统也能够很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。 通过启用内存分布数据集，优化迭代工作负载， 用户能够更简单地操作数据，并在此基础上开发更为精细的算法，如机器学习和图算法等。

有三个最主要的原因促使Spark目前成为了时下最火的大数据开源社区（拥有超过来自200多个公司的800多个contributors）：

Spark可以扩展部署到超过8000节点并处理PB级别的数据，同时也提供了很多不错的工具供应用开发者进行管理和部署；

Spark提供了一个交互式shell供开发者可以用Scala或者Python即时性试验不同的功能；

Spark提供了很多内置函数使得开发者能够比较容易地写出低耦合的并且能够并发执行的代码，这样开发人员就更能集中精力地为用户提供更多的业务功能而不是花费时间在优化并行化代码之上。

当然Spark也和当年的MapRece一样不是万灵药，比如对实时性要求很高的流数据处理上Apache Storm还是被作为主流选择， 因为Spark Streaming实际上是microbatch（将一个流数据按时间片切成batch,每个batch提交一个job）而不是事件触发实时系统，所以虽然支持者们认为microbatch在系统延时性上贡献并不多，但在生产环境中和Apache Storm相比还不是特别能满足对低延时要求很高的应用场景。

比如在实践过程中， 如果统计每条消息的平均处理时间，很容易达到毫秒级别，但一旦统计类似service assurance（确保某条消息在毫秒基本能被处理完成）的指标， 系统的瓶颈有时还是不能避免。

但同时我们不能不注意到，在许多用例当中，与流数据的交互以及和静态数据集的结合是很有必要的, 例如我们需要在静态数据集上进行分类器的模型计算，并在已有分类器模型的基础上，对实时进入系统的流数据进行交互计算来判定类别。

由于Spark的系统设计对各类工作（批处理、流处理以及交互式工作）进行了一个共有抽象，并且生态圈内延伸出了许多丰富的库（MLlib机器学习库、SQL语言API、GraphX）, 使得用户可以在每一批流数据上进行灵活的Spark相关操作，在开发上提供了许多便利。

Spark的成熟使得Hadoop生态圈在短短一年之间发生了翻天覆地的变化， Cloudera和Hortonworks纷纷加入了Spark阵营，而Hadoop项目群中除了Yarn之外已经没有项目是必须的了（虽然Mesos已在一些场合替代了Yarn）, 因为就连HDFS，Spark都可以不依赖。但很多时候我们仍然需要像Impala这样的依赖分布式文件系统的MPP解决方案并利用Hive管理文件到表的映射，因此Hadoop传统生态圈依然有很强的生命力。

另外在这里简要对比一下交互式分析任务中各类SQL on Hadoop框架，因为这也是我们在实际项目实施中经常遇到的问题。我们主要将注意力集中在Spark SQL, Impala和Hive on Tez上, 其中Spark SQL是三者之中历史最短的，论文发表在15年的SIGMOD会议上， 原文对比了数据仓库上不同类型的查询在Shark（Spark最早对SQL接口提供的支持）、Spark SQL和Impala上的性能比较。

也就是说， 虽然Spark SQL在Shark的基础上利用Catalyst optimizer在代码生成上做了很多优化，但总体性能还是比不上Impala, 尤其是当做join操作的时候， Impala可以利用“predicate pushdown”更早对表进行选择操作从而提高性能。

不过Spark SQL的Catalyst optimizer一直在持续优化中，相信未来会有更多更好的进展。Cloudera的Benchmark评测中Impala一直比其他SQL on Hadoop框架性能更加优越，但同时Hortonworks评测则指出虽然单个数据仓库查询Impala可以在很短的时间内完成，但是一旦并发多个查询Hive on Tez的优势就展示出来。另外Hive on Tez在SQL表达能力也要比Impala更强（主要是因为Impala的嵌套存储模型导致的）， 因此根据不同的场景选取不同的解决方案是很有必要的。

图 3

各领风骚抑或代有才人出？

近一年比较吸引人眼球的Apache Flink（与Spark一样已有5年历史，前身已经是柏林理工大学一个研究性项目，被其拥趸推崇为继MapRece, Yarn，Spark之后第四代大数据分析处理框架）。 与Spark相反，Flink是一个真正的实时流数据处理系统，它将批处理看作是流数据的特例，同Spark一样它也在尝试建立一个统一的平台运行批量，流数据，交互式作业以及机器学习，图算法等应用。

Flink有一些设计思路是明显区别于Spark的，一个典型的例子是内存管理，Flink从一开始就坚持自己精确的控制内存使用并且直接操作二进制数据，而Spark一直到1.5版本都还是试用java的内存管理来做数据缓存，这也导致了Spark很容易遭受OOM以及JVM GC带来的性能损失。

但是从另外一个角度来说, Spark中的RDD在运行时被存成java objects的设计模式也大大降低了用户编程设计门槛， 同时随着Tungsten项目的引入，Spark现在也逐渐转向自身的内存管理， 具体表现为Spark生态圈内从传统的围绕RDD（分布式java对象集合）为核心的开发逐渐转向以DataFrame(分布式行对象集合)为核心。

总的来说，这两个生态圈目前都在互相学习，Flink的设计基因更为超前一些，但Spark社区活跃度大很多，发展到目前毫无疑问是更为成熟的选择，比如对数据源的支持（HBase, Cassandra, Parquet, JSON, ORC）更为丰富以及更为统一简洁的计算表示。另一方面，Apache Flink作为一个由欧洲大陆发起的项目，目前已经拥有来自北美、欧洲以及亚洲的许多贡献者，这是否能够一改欧洲在开源世界中一贯的被动角色，我们将在未来拭目以待。

2
NoSQL数据库篇
NoSQL数据库在主流选择上依旧集中在MongoDB, HBase和Cassandra这三者之间。在所有的NoSQL选择中，用C 编写的MongoDB几乎应该是开发者最快也最易部署的选择。MongoDB是一个面向文档的数据库，每个文档／记录／数据（包括爬取的网页数据及其他大型对象如视频等）是以一种BSON（Binary JSON）的二进制数据格式存储, 这使得MongoDB并不需要事先定义任何模式, 也就是模式自由（可以把完全不同结构的记录放在同一个数据库里）。

MongoDB对于完全索引的支持在应用上是很方便的，同时也具备一般NoSQL分布式数据库中可扩展，支持复制和故障恢复等功能。 MongoDB一般应用于高度伸缩性的缓存及大尺寸的JSON数据存储业务中，但不能执行“JOIN”操作，而且数据占用空间也比较大，最被用户诟病的就是由于MongoDB提供的是数据库级锁粒度导致在一些情况下建索引操作会引发整个数据库阻塞。一般来说，MongoDB完全可以满足一些快速迭代的中小型项目的需求。

下面来主要谈谈Cassandra和HBase之间的比较选择。Cassandra和HBase有着截然不同的基因血统。HBase和其底层依赖的系统架构源自于著名的Google FileSystem（发表于2003年）和Google BigTable设计（发表于2006年）， 其克服了HDFS注重吞吐量却牺牲I/O的缺点，提供了一个存储中间层使得用户或者应用程序可以随机读写数据。

具体来说，HBase的更新和删除操作实际上是先发生在内存MemStore中， 当MemStore满了以后会Flush到StoreFile, 之后当StoreFile文件数量增长到一定阈值后会触发Compact合并操作，因此HBase的更新操作其实是不断追加的操作，而最终所有更新和删除数据的持久化操作都是在之后Compact过程中进行的。

这使得应用程序在向内存MemStore写入数据后，所做的修改马上就能得到反映，用户读到的数据绝不会是陈旧的数据，保证了I/O高性能和数据完全一致性； 另一方面来说， HBase基于Hadoop生态系统的基因就已经决定了他自身的高度可扩展性、容错性。

在数据模型上，Cassandra和HBase类似实现了一个key-value提供面向列式存储服务，其系统设计参考了 Amazon Dynamo (发表于2007年) 分布式哈希（DHT）的P2P结构（实际上大部分Cassandra的初始工作都是由两位从Amazon的Dynamo组跳槽到Facebook的工程师完成)，同样具有很高的可扩展性和容错性等特点。

除此之外， 相对HBase的主从结构，Cassandra去中心化的P2P结构能够更简单地部署和维护，比如增加一台机器只需告知Cassandra系统新节点在哪，剩下的交给系统完成就行了。同时，Cassandra对多数据中心的支持也更好，如果需要在多个数据中心进行数据迁移Cassandra会是一个更优的选择。

Eric Brewer教授提出的经典CAP理论认为任何基于网络的数据共享系统，最多只能满足数据一致性、可用性、分区容忍性三要素中的两个要素。实际分布式系统的设计过程往往都是在一致性与可用性上进行取舍，相比于HBase数据完全一致性的系统设计，Cassandra选择了在优先考虑数据可用性的基础上让用户自己根据应用程序需求决定系统一致性级别。

比如：用户可以配置QUONUM参数来决定系统需要几个节点返回数据才能向客户端做出响应，ONE指只要有一个节点返回数据就可以对客户端做出响应，ALL指等于数据复制份数的所有节点都返回结果才能向客户端做出响应，对于数据一致性要求不是特别高的可以选择ONE，它是最快的一种方式。

从基因和发展历史上来说，HBase更适合用做数据仓库和大规模数据处理与分析（比如对网页数据建立索引）， 而Cassandra则更适合用作实时事务和交互式查询服务。Cassandra在国外市场占有比例和发展要远比国内红火， 在不少权威测评网站上排名都已经超过了HBase。目前Apache Cassandra的商业化版本主要由软件公司DataStax进行开发和销售推广。另外还有一些NoSQL分布式数据库如Riak, CouchDB也都在各自支持的厂商推动下取得了不错的发展。

虽然我们也考虑到了HBase在实际应用中的不便之处比如对二级索引的支持程度不够（只支持通过单个行键访问，通过行键的范围查询，全表扫描），不过在明略的大数据基础平台上，目前整合的是依然是HBase。

理由也很简单，HBase出身就与Hadoop的生态系统紧密集成，其能够很容易与其他SQL on Hadoop框架（Cloudera Impala, Apache Phoenix, or Hive on Tez）进行整合，而不需要重新部署一套分布式数据库系统，而且可以很方便地将同样的数据内容在同一个生态系统中根据不同框架需要来变换存储格式（比如存储成Hive表或者Parquet格式）。

我们在很多项目中都有需要用到多种SQL on Hadoop框架，来应对不同应用场景的情况，也体会到了在同一生态系统下部署多种框架的简便性。 但同时我们也遇到了一些问题， 因为HBase项目本身与HDFS和Zookeeper系统分别是由不同开源团队进行维护的，所以在系统整合时我们需要先对HBase所依赖的其他模块进行设置再对HBase进行配置，在一定程度上降低了系统维护的友好性。

目前我们也已经在考虑将Cassandra应用到一些新的客户项目中，因为很多企业级的应用都需要将线上线下数据库进行分离，HBase更适合存储离线处理的结果和数据仓库，而更适合用作实时事务和并发交互性能更好的Cassandra作为线上服务数据库会是一种很好的选择。

3
大数据安全篇
随着越来越多各式各样的数据被存储在大数据系统中，任何对企业级数据的破坏都是灾难性的，从侵犯隐私到监管违规，甚至会造成公司品牌的破坏并最终影响到股东收益。给大数据系统提供全面且有效的安全解决方案的需求已经十分迫切：

大数据系统存储着许多重要且敏感的数据，这些数据是企业长久以来的财富

与大数据系统互动的外部系统是动态变化的，这会给系统引入新的安全隐患

在一个企业的内部，不同Business Units会用不同的方式与大数据系统进行交互，比如线上的系统会实时给集群推送数据、数据科学家团队则需要分析存储在数据仓库内的历史数据、运维团队则会需要对大数据系统拥有管理权限。

因此为了保护公司业务、客户、财务和名誉免于被侵害，大数据系统运维团队必须将系统安全高度提高到和其他遗留系统一样的级别。同时大数据系统并不意味着引入大的安全隐患，通过精细完整的设计，仍然能够把一些传统的系统安全解决方案对接到最新的大数据集群系统中。

一般来说，一个完整的企业级安全框架包括五个部分：

Administration: 大数据集群系统的集中式管理，设定全局一致的安全策略

Authentication: 对用户和系统的认证

Authorization：授权个人用户和组对数据的访问权限

Audit：维护数据访问的日志记录

Data Protection：数据脱敏和加密以达到保护数据的目的

系统管理员要能够提供覆盖以上五个部分的企业级安全基础设施，否则任何一环的缺失都可能给整个系统引入安全性风险。

在大数据系统安全集中式管理平台这块，由Hortonworks推出的开源项目Apache Ranger就可以十分全面地为用户提供Hadoop生态圈的集中安全策略的管理，并解决授权(Authorization)和审计(Audit)。例如，运维管理员可以轻松地为个人用户和组对文件、数据等的访问策略，然后审计对数据源的访问。

与Ranger提供相似功能的还有Cloudera推出的Apache Sentry项目，相比较而言Ranger的功能会更全面一些。

而在认证（Authentication）方面, 一种普遍采用的解决方案是将基于Kerberos的认证方案对接到企业内部的LDAP环境中， Kerberos也是唯一为Hadoop全面实施的验证技术。

另外值得一提的是Apache Knox Gateway项目，与Ranger提高集群内部组件以及用户互相访问的安全不同，Knox提供的是Hadoop集群与外界的唯一交互接口，也就是说所有与集群交互的REST API都通过Knox处理。这样，Knox就给大数据系统提供了一个很好的基于边缘的安全（perimeter-based security）。

基于以上提到的五个安全指标和Hadoop生态圈安全相关的开源项目， 已经足已证明基于Hadoop的大数据平台我们是能够构建一个集中、一致、全面且有效的安全解决方案。
我市再ITjob管网上面找的

㈡ eMule eD2K和Kad 有什么联系和区别如果只连接eD2K，对下载有什么影响

eD2k网络是基于服务器的，你需要连接到服务器并从服务器索引/查找用户或者文件。
Kad是基于分布式哈希表（DHT）的分布式网络，也就是完全依靠用户之间互相连接形成的网络，通过其它用户的帮助来索引/查找用户或者文件。
通俗一点说，eD2k网络相当于广播电台，Kad网络相当于群众口口相传。
只连接eD2k，你所能查找到的来源会减少很多，特别是现在P2P网络去中心化日益激进的今天。实际上目前可用的eD2k服务器已经没剩几个了，而且在不久的将来可能会彻底消失。届时必须依靠Kad网络由大家手拉手分享信息。

㈢ 什么是P2P软件目前那种P2P软件好用而且病毒少

P2P普及系列之一

拓扑结构是指分布式系统中各个计算单元之间的物理或逻辑的互联关系，结点之间的拓扑结构一直是确定系统类型的重要依据。目前互联网络中广泛使用集中式、层次式等拓扑结构，Interne本身是世界上最大的非集中式的互联网络，但是九十年代所建立的一些网络应用系统却是完全的集中式的系统、很多Web应用都是运行在集中式的服务器系统上。集中式拓扑结构系统目前面临着过量存储负载、Dos攻击等一些难以解决的问题。

P2P系统一般要构造一个非集中式的拓扑结构，在构造过程中需要解决系统中所包含的大量结点如何命名、组织以及确定结点的加入/离开方式、出错恢复等问题。

根据拓扑结构的关系可以将P2P研究分为4种形式：中心化拓扑（Centralized Topology）；全分布式非结构化拓扑（Decentralized Unstructured Topology）；全分布式结构化拓扑（Decentralized Structured Topology，也称作DHT网络）和半分布式拓扑（Partially Decentralized Topology）。

其中，中心化拓扑最大的优点是维护简单发现效率高。由于资源的发现依赖中心化的目录系统，发现算法灵活高效并能够实现复杂查询。最大的问题与传统客户机/服务器结构类似，容易造成单点故障，访问的“热点”现象和法律等相关问题，这是第一代P2P网络采用的结构模式，经典案例就是著名的MP3共享软件Napster。

Napster是最早出现的P2P系统之一，并在短期内迅速成长起来。Napster实质上并非是纯粹的P2P系统，它通过一个中央服务器保存所有Napster用户上传的音乐文件索引和存放位置的信息。当某个用户需要某个音乐文件时，首先连接到Napster服务器，在服务器进行检索，并由服务器返回存有该文件的用户信息；再由请求者直接连到文件的所有者传输文件。

Napster首先实现了文件查询与文件传输的分离，有效地节省了中央服务器的带宽消耗，减少了系统的文件传输延时。这种方式最大的隐患在中央服务器上，如果该服务器失效，整个系统都会瘫痪。当用户数量增加到105或者更高时，Napster的系统性能会大大下降。另一个问题在于安全性上，Napster并没有提供有效的安全机制。

在Napster模型中，一群高性能的中央服务器保存着网络中所有活动对等计算机共享资源的目录信息。当需要查询某个文件时，对等机会向一台中央服务器发出文件查询请求。中央服务器进行相应的检索和查询后，会返回符合查询要求的对等机地址信息列表。查询发起对等机接收到应答后，会根据网络流量和延迟等信息进行选择，和合适的对等机建立连接，并开始文件传输。

这种对等网络模型存在很多问题，主要表现为：
(1)中央服务器的瘫痪容易导致整个网络的崩馈，可靠性和安全性较低。
(2)随着网络规模的扩大，对中央索引服务器进行维护和更新的费用将急剧增加，所需成本过高。
(3)中央服务器的存在引起共享资源在版权问题上的纠纷，并因此被攻击为非纯粹意义上的P2P网络模型。对小型网络而言，集中目录式模型在管理和控制方面占一定优势。但鉴于其存在的种种缺陷，该模型并不适合大型网络应用。

P2P普及系列之二

Pastry是微软研究院提出的可扩展的分布式对象定位和路由协议，可用于构建大规模的P2P系统。在Pastry中，每个结点分配一个128位的结点标识符号(nodeID) ，所有的结点标识符形成了一个环形的nodeID空间，范围从0到2128 - 1 ，结点加入系统时通过散列结点IP地址在128位nodeID空间中随机分配。

在MIT，开展了多个与P2P相关的研究项目：Chord，GRID和RON。Chord项目的目标是提供一个适合于P2P环境的分布式资源发现服务，它通过使用DHT技术使得发现指定对象只需要维护O(logN)长度的路由表。

在DHT技术中，网络结点按照一定的方式分配一个唯一结点标识符(Node ID) ，资源对象通过散列运算产生一个唯一的资源标识符(Object ID) ，且该资源将存储在结点ID与之相等或者相近的结点上。需要查找该资源时，采用同样的方法可定位到存储该资源的结点。因此，Chord的主要贡献是提出了一个分布式查找协议，该协议可将指定的关键字(Key) 映射到对应的结点(Node) 。从算法来看，Chord是相容散列算法的变体。MIT GRID和RON项目则提出了在分布式广域网中实施查找资源的系统框架。

T&T ACIRI中心的CAN(Content Addressable Networks) 项目独特之处在于采用多维的标识符空间来实现分布式散列算法。CAN将所有结点映射到一个n维的笛卡尔空间中，并为每个结点尽可能均匀的分配一块区域。CAN采用的散列函数通过对(key, value) 对中的key进行散列运算，得到笛卡尔空间中的一个点，并将(key, value) 对存储在拥有该点所在区域的结点内。CAN采用的路由算法相当直接和简单，知道目标点的坐标后，就将请求传给当前结点四邻中坐标最接近目标点的结点。CAN是一个具有良好可扩展性的系统，给定N个结点，系统维数为d，则路由路径长度为O(n1/d) ，每结点维护的路由表信息和网络规模无关为O(d) 。

DHT类结构最大的问题是DHT的维护机制较为复杂，尤其是结点频繁加入退出造成的网络波动（Churn）会极大增加DHT的维护代价。DHT所面临的另外一个问题是DHT仅支持精确关键词匹配查询，无法支持内容/语义等复杂查询。

半分布式结构（有的文献称作 Hybrid Structure）吸取了中心化结构和全分布式非结构化拓扑的优点，选择性能较高（处理、存储、带宽等方面性能）的结点作为超级点（英文文献中多称作：SuperNodes, Hubs)，在各个超级点上存储了系统中其他部分结点的信息，发现算法仅在超级点之间转发，超级点再将查询请求转发给适当的叶子结点。半分布式结构也是一个层次式结构，超级点之间构成一个高速转发层，超级点和所负责的普通结点构成若干层次。最典型的案例就是KaZaa。

KaZaa是现在全世界流行的几款p2p软件之一。根据CA公司统计，全球KaZaa的下载量超过2.5亿次。使用KaZaa软件进行文件传输消耗了互联网40%的带宽。之所以它如此的成功，是因为它结合了Napster和Gnutella共同的优点。从结构 上来说，它使用了Gnutella的全分布式的结构，这样可以是系统更好的扩展，因为它无需中央索引服务器存储文件名，它是自动的把性能好的机器成为SuperNode，它存储着离它最近的叶子节点的文件信息，这些SuperNode,再连通起来形成一个Overlay Network. 由于SuperNode的索引功能，使搜索效率大大提高。

P2P普及系列之三

全分布非结构化网络在重叠网络（overlay）采用了随机图的组织方式，结点度数服从"Power-law"[a][b]规律，从而能够较快发现目的结点，面对网络的动态变化体现了较好的容错能力，因此具有较好的可用性。同时可以支持复杂查询，如带有规则表达式的多关键词查询，模糊查询等，最典型的案例是Gnutella。

Gnutella是一个P2P文件共享系统，它和Napster最大的区别在于Gnutella是纯粹的P2P系统，没有索引服务器，它采用了基于完全随机图的洪泛（Flooding）发现和随机转发（Random Walker）机制。为了控制搜索消息的传输，通过TTL (Time To Live)的减值来实现。具体协议参照〔Gnutella协议中文版〕

在Gnutella分布式对等网络模型N中，每一个联网计算机在功能上都是对等的，既是客户机同时又是服务器，所以被称为对等机(Servent，Server+Client的组合)。

随着联网节点的不断增多，网络规模不断扩大，通过这种洪泛方式定位对等点的方法将造成网络流量急剧增加，从而导致网络中部分低带宽节点因网络资源过载而失效。所以在初期的Gnutella网络中，存在比较严重的分区，断链现象。也就是说，一个查询访问只能在网络的很小一部分进行，因此网络的可扩展性不好。所以，解决Gnutella网络的可扩展性对该网络的进一步发展至关重要。

由于没有确定拓扑结构的支持，非结构化网络无法保证资源发现的效率。即使需要查找的目的结点存在发现也有可能失败。由于采用TTL（Time-to-Live）、洪泛（Flooding）、随机漫步或有选择转发算法，因此直径不可控，可扩展性较差。

因此发现的准确性和可扩展性是非结构化网络面临的两个重要问题。目前对此类结构的研究主要集中于改进发现算法和复制策略以提高发现的准确率和性能。

全分布非结构化网络在重叠网络（overlay）采用了随机图的组织方式，结点度数服从"Power-law"[a][b]规律，从而能够较快发现目的结点，面对网络的动态变化体现了较好的容错能力，因此具有较好的可用性。同时可以支持复杂查询，如带有规则表达式的多关键词查询，模糊查询等，最典型的案例是Gnutella。

Gnutella是一个P2P文件共享系统，它和Napster最大的区别在于Gnutella是纯粹的P2P系统，没有索引服务器，它采用了基于完全随机图的洪泛（Flooding）发现和随机转发（Random Walker）机制。为了控制搜索消息的传输，通过TTL (Time To Live)的减值来实现。具体协议参照〔Gnutella协议中文版〕

在Gnutella分布式对等网络模型N中，每一个联网计算机在功能上都是对等的，既是客户机同时又是服务器，所以被称为对等机(Servent，Server+Client的组合)。

随着联网节点的不断增多，网络规模不断扩大，通过这种洪泛方式定位对等点的方法将造成网络流量急剧增加，从而导致网络中部分低带宽节点因网络资源过载而失效。所以在初期的Gnutella网络中，存在比较严重的分区，断链现象。也就是说，一个查询访问只能在网络的很小一部分进行，因此网络的可扩展性不好。所以，解决Gnutella网络的可扩展性对该网络的进一步发展至关重要。

由于没有确定拓扑结构的支持，非结构化网络无法保证资源发现的效率。即使需要查找的目的结点存在发现也有可能失败。由于采用TTL（Time-to-Live）、洪泛（Flooding）、随机漫步或有选择转发算法，因此直径不可控，可扩展性较差。

因此发现的准确性和可扩展性是非结构化网络面临的两个重要问题。目前对此类结构的研究主要集中于改进发现算法和复制策略以提高发现的准确率和性能。

P2P普及系列之四

半分布式结构的优点是性能、可扩展性较好，较容易管理，但对超级点依赖性大，易于受到攻击，容错性也受到影响。下表比较了4种结构的综合性能，比较结果如表1-1所示。

比较标准／拓扑结构 中心化拓扑 全分布式非结构化拓扑 全分布式结构化拓扑 半分布式拓扑
可扩展性 差 差 好 中
可靠性 差 好 好 中
可维护性 最好 最好 好 中
发现算法效率 最高 中 高 中
复杂查询 支持 支持 不支持 支持

表1：4种结构的性能比较

P2P普及系列之五

国外开展P2P研究的学术团体主要包括P2P工作组(P2PWG) 、全球网格论坛(Global Grid Forum ，GGF) 。P2P工作组成立的主要目的是希望加速P2P计算基础设施的建立和相应的标准化工作。P2PWG成立之后，对P2P计算中的术语进行了统一，也形成相关的草案，但是在标准化工作方面工作进展缓慢。目前P2PWG已经和GGF合并，由该论坛管理P2P计算相关的工作。GGF负责网格计算和P2P计算等相关的标准化工作。

从国外公司对P2P计算的支持力度来看，Microsoft公司、Sun公司和Intel公司投入较大。Microsoft公司成立了Pastry项目组，主要负责P2P计算技术的研究和开发工作。目前Microsoft公司已经发布了基于Pastry的软件包SimPastry/ VisPastry。Rice大学也在Pastry的基础之上发布了FreePastry软件包。

在2000年8月，Intel公司宣布成立P2P工作组，正式开展P2P的研究。工作组成立以后，积极与应用开发商合作，开发P2P应用平台。2002年Intel发布了. Net基础架构之上的Accelerator Kit (P2P加速工具包) 和P2P安全API软件包，从而使得微软. NET开发人员能够迅速地建立P2P安全Web应用程序。

Sun公司以Java技术为背景，开展了JXTA项目。JXTA是基于Java的开源P2P平台，任何个人和组织均可以加入该项目。因此，该项目不仅吸引了大批P2P研究人员和开发人员，而且已经发布了基于JXTA的即时聊天软件包。JXTA定义了一组核心业务：认证、资源发现和管理。在安全方面，JXTA加入了加密软件包，允许使用该加密包进行数据加密，从而保证消息的隐私、可认证性和完整性。在JXTA核心之上，还定义了包括内容管理、信息搜索以及服务管理在内的各种其它可选JXTA服务。在核心服务和可选服务基础上，用户可以开发各种JXTA平台上的P2P应用。

P2P实际的应用主要体现在以下几个方面：

P2P分布式存储
P2P分布式存储系统是一个用于对等网络的数据存储系统，它可以提供高效率的、鲁棒的和负载平衡的文件存取功能。这些研究包括：OceanStore，Farsite等。其中，基于超级点结构的半分布式P2P应用如Kazza、Edonkey、Morpheus、Bittorrent等也是属于分布式存储的范畴，并且用户数量急剧增加。

计算能力的共享
加入对等网络的结点除了可以共享存储能力之外，还可以共享CPU处理能力。目前已经有了一些基于对等网络的计算能力共享系统。比如SETI@home。目前SETI@home采用的仍然是类似于Napster的集中式目录策略。Xenoservers向真正的对等应用又迈进了一步。这种计算能力共享系统可以用于进行基因数据库检索和密码破解等需要大规模计算能力的应用。

P2P应用层组播
应用层组播，就是在应用层实现组播功能而不需要网络层的支持。这样就可以避免出现由于网络层迟迟不能部署对组播的支持而使组播应用难以进行的情况。应用层组播需要在参加的应用结点之间实现一个可扩展的，支持容错能力的重叠网络，而基于DHT的发现机制正好为应用层组播的实现提供了良好的基础平台。
Internet间接访问基础结构（Internet Indirection Infrastructure）。

为了使Internet更好地支持组播、单播和移动等特性，Internet间接访问基础结构提出了基于汇聚点的通信抽象。在这一结构中，并不把分组直接发向目的结点，而是给每个分组分配一个标识符，而目的结点则根据标识符接收相应的分组。标识符实际上表示的是信息的汇聚点。目的结点把自己想接收的分组的标识符预先通过一个触发器告诉汇聚点，当汇聚点收到分组时，将会根据触发器把分组转发该相应的目的结点。Internet间接访问基础结构实际上在Internet上构成了一个重叠网络，它需要对等网络的路由系统对它提供相应的支持。

P2P技术从出现到各个领域的应用展开，仅用了几年的时间。从而证明了P2P技术具有非常广阔的应用前景。

P2P普及系列之六

随着P2P应用的蓬勃发展，作为P2P应用中核心问题的发现技术除了遵循技术本身的逻辑以外，也受到某些技术的发展趋势、需求趋势的深刻影响。

如上所述，DHT发现技术完全建立在确定性拓扑结构的基础上，从而表现出对网络中路由的指导性和网络中结点与数据管理的较强控制力。但是，对确定性结构的认识又限制了发现算法效率的提升。研究分析了目前基于DHT的发现算法，发现衡量发现算法的两个重要参数度数（表示邻居关系数、路由表的容量）和链路长度（发现算法的平均路径长度）之间存在渐进曲线的关系。

研究者采用图论中度数(Degree)和直径(Diameter)两个参数研究DHT发现算法，发现这些DHT发现算法在度数和直径之间存在渐进曲线关系，如下图所示。在N个结点网络中，图中直观显示出当度数为N时，发现算法的直径为O(1)；当每个结点仅维护一个邻居时，发现算法的直径为O(N)。这是度数和直径关系的2种极端情况。同时，研究以图论的理论分析了O(d)的度和O(d)的直径的算法是不可能的。

从渐进曲线关系可以看出，如果想获得更短的路径长度，必然导致度数的增加；而网络实际连接状态的变化造成大度数邻居关系的维护复杂程度增加。另外，研究者证明O(logN)甚至O(logN/loglogN)的平均路径长度也不能满足状态变化剧烈的网络应用的需求。新的发现算法受到这种折衷关系制约的根本原因在于DHT对网络拓扑结构的确定性认识。

非结构化P2P系统中发现技术一直采用洪泛转发的方式，与DHT的启发式发现算法相比，可靠性差，对网络资源的消耗较大。最新的研究从提高发现算法的可靠性和寻找随机图中的最短路径两个方面展开。也就是对重叠网络的重新认识。其中，small world特征和幂规律证明实际网络的拓扑结构既不是非结构化系统所认识的一个完全随机图，也不是DHT发现算法采用的确定性拓扑结构。

实际网络体现的幂规律分布的含义可以简单解释为在网络中有少数结点有较高的“度”，多数结点的“度”较低。度较高的结点同其他结点的联系比较多，通过它找到待查信息的概率较高。

Small-world[a][b]模型的特性：网络拓扑具有高聚集度和短链的特性。在符合small world特性的网络模型中，可以根据结点的聚集度将结点划分为若干簇(Cluster)，在每个簇中至少存在一个度最高的结点为中心结点。大量研究证明了以Gnutella为代表的P2P网络符合small world特征，也就是网络中存在大量高连通结点，部分结点之间存在“短链”现象。

因此，P2P发现算法中如何缩短路径长度的问题变成了如何找到这些“短链”的问题。尤其是在DHT发现算法中，如何产生和找到“短链”是发现算法设计的一个新的思路。small world特征的引入会对P2P发现算法产生重大影响。

P2P普及系列之七

有DHT算法由于采用分布式散列函数，所以只适合于准确的查找，如果要支持目前Web上搜索引擎具有的多关键字查找的功能，还要引入新的方法。主要的原因在于DHT的工作方式。

基于DHT的P2P系统采用相容散列函数根据精确关键词进行对象的定位与发现。散列函数总是试图保证生成的散列值均匀随机分布，结果两个内容相似度很高但不完全相同的对象被生成了完全不同的散列值，存放到了完全随机的两个结点上。因此，DHT可以提供精确匹配查询，但是支持语义是非常困难的。

目前在DHT基础上开展带有语义的资源管理技术的研究还非常少。由于DHT的精确关键词映射的特性决定了无法和信息检索等领域的研究成果结合，阻碍了基于DHT的P2P系统的大规模应用。

P2P发现技术中最重要的研究成果应该是基于small world理论的非结构化发现算法和基于DHT的结构化发现算法。尤其是DHT及其发现技术为资源的组织与查找提供了一种新的方法。

随着P2P系统实际应用的发展，物理网络中影响路由的一些因素开始影响P2P发现算法的效率。一方面，实际网络中结点之间体现出较大的差异，即异质性。由于客户机/服务器模式在Internet和分布式领域十几年的应用和大量种类的电子设备的普及，如手提电脑、移动电话或PDA。这些设备在计算能力、存储空间和电池容量上差别很大。另外，实际网络被路由器和交换机分割成不同的自治区域，体现出严密的层次性。

另一方面，网络波动的程度严重影响发现算法的效率。网络波动（Churn、fluctuation of network）包括结点的加入、退出、失败、迁移、并发加入过程、网络分割等。DHT的发现算法如Chord、CAN、Koorde等都是考虑网络波动的最差情况下的设计与实现。由于每个结点的度数尽量保持最小，这样需要响应的成员关系变化的维护可以比较小，从而可以快速恢复网络波动造成的影响。但是每个结点仅有少量路由状态的代价是发现算法的高延时，因为每一次查找需要联系多个结点，在稳定的网络中这种思路是不必要的。

同时，作为一种资源组织与发现技术必然要支持复杂的查询，如关键词、内容查询等。尽管信息检索和数据挖掘领域提供了大量成熟的语义查询技术，由于DHT精确关键词映射的特性阻碍了DHT在复杂查询方面的应用。

P2P普及系列之八

Internet作为当今人类社会信息化的标志,其规模正以指数速度高速增长.如今Internet的“面貌”已与其原型ARPANET大相径庭,依其高度的复杂性,可以将其看作一个由计算机构成的“生态系统”.虽然Internet是人类亲手建造的,但却没有人能说出这个庞然大物看上去到底是个什么样子,运作得如何.Internet拓扑建模研究就是探求在这个看似混乱的网络之中蕴含着哪些还不为我们所知的规律.发现Internet拓扑的内在机制是认识Internet的必然过程,是在更高层次上开发利用Internet的基础.然而,Internet与生俱来的异构性动态性发展的非集中性以及如今庞大的规模都给拓扑建模带来巨大挑战.Internet拓扑建模至今仍然是一个开放性问题,在计算机网络研究中占有重要地位.

Internet拓扑作为Internet这个自组织系统的“骨骼”,与流量协议共同构成模拟Internet的3个组成部分,即在拓扑网络中节点间执行协议,形成流量.Internet拓扑模型是建立Internet系统模型的基础,由此而体现的拓扑建模意义也可以说就是Internet建模的意义,即作为一种工具,人们用其来对Internet进行分析预报决策或控制.Internet模型中的拓扑部分刻画的是Internet在宏观上的特征,反映一种总体趋势,所以其应用也都是在大尺度上展开的.对Internet拓扑模型的需求主要来自以下几个方面1) 许多新应用或实验不适合直接应用于Internet,其中一些具有危害性,如蠕虫病毒在大规模网络上的传播模拟;(2) 对于一些依赖于网络拓扑的协议(如多播协议),在其研发阶段,当前Internet拓扑只能提供一份测试样本,无法对协议进行全面评估,需要提供多个模拟拓扑环境来进行实验;(3) 从国家安全角度考虑,需要在线控制网络行为,如美国国防高级研究计划局(DARPA)的NMS(network modeling and simulation)项目。

随机网络是由N个顶点构成的图中，可以存在条边，我们从中随机连接M条边所构成的网络。还有一种生成随机网络的方法是，给一个概率p，对于中任何一个可能连接，我们都尝试一遍以概率p的连接。如果我们选择M = p，这两种随机网络模型就可以联系起来。对于如此简单的随机网络模型，其几何性质的研究却不是同样的简单。随机网络几何性质的研究是由Paul，Alfréd Rényi和Béla Bollobás在五十年代到六十年代之间完成的。随机网络在Internet的拓扑中占有很重要的位置。

随机网络参数
描述随机网络有一些重要的参数。一个节点所拥有的度是该节点与其他节点相关联的边数，度是描述网络局部特性的基本参数。网络中并不是所有节点都具有相同的度，系统中节点度的分布情况，可以用分布函数描述，度分布函数反映了网络系统的宏观统计特征。理论上利用度分布可以计算出其他表征全局特性参数的量化数值。

聚集系数是描述与第三个节点连接的一对节点被连接的概率。从连接节点的边的意义上，若为第i个节点的度，在由k.个近邻节点构成的子网中，实际存在的边数E(i)与全部k.个节点完全连接时的总边数充的比值定义为节点i的聚集系数。

emule很不错，不过不要用verycd版的，有搜索限制，用官方原版的更好。
bt下载也很好
参考资料:http://www.p2psky.com/tech/article2976.html

㈣ 磁力下载的好处

显而易见的好处是，整个下载网络的可靠性提高了，每一个节点都是可以被替代的。另一个好处是，审查变得更困难了，因为每次下载的路径都是不一样的，而且每个节点都是动态变化的，导致实际上无法追踪谁在下载。此外，magnet URI只是一个字符串，非常容易传播，根本无法禁止。
现在BT下载的多款软件已经更新均采用了最新的BT磁力链接(magnet)方式，类似电馿的ED2K链接，放弃了需要BT种子才能下载的传统方式，现在您不需要下载种子文件，只要有磁力链接就可以下载BT了。
现在µTorrent等下载工具都有磁力下载，你可以试试。
磁力下载是BT的进化。最早期的BT就是一个种子（seed），它是由一个待发布文件外加一些tracker经过计算得到的一个文件，通过BT的网络吸收营养，最后长成一棵大树。这个种子需要水壶（tracker服务器）不断的浇灌才能成长。Tracker服务器是早期下载中必须的角色。它工作的过程是这样的：
Client向tracker发一个HTTP的GET请求，并把它自己的信息放在GET的参数中；这个请求的大致意思是：我是xxx（一个唯一的ID），我想下载yyy文件，我的IP是aaa，我用的端口是bbb。
tracker对所有Client的信息进行维护，当它收到一个请求后，首先把Client的信息记录下来（如果已经记录在案，那么就检查是否需要更新），然后将一部分参与下载同一个文件（一个Tracker服务器可能同时维护多个文件的下载）的另一个Client的信息返回给对方。
Client在收到Tracker的响应后，就能获取其它Client的信息，那么它就可以根据这些信息，与其它Client建立连接，从它们那里下载文件片断。
水壶不总是会工作，偶尔也罢工偷懒，偶尔也会被人惦记上，于是，为了摆脱对水壶的依赖，DHT（Distributed Hash Table，分布式哈希表）和PEX(Peer Exchange，节点信息交换)技术就出现了。
2005年，BT软件开始引入这种技术，在BT中被称为DHT协议。DHT是一种分布式存储方法。DHT的作用是找到那些与本机正在下载（上传）相同文件的对端主机（Peer），当然，实现这一过程并不依赖 Tracker服务器。在DHT网络中的每个客户端负责一个小范围的路由，并负责存储一小部分数据，从而实现整个DHT网络的寻址和存储。这种信息获取方 式保证了整个网络没有单个的中心，即使一个节点下线，依然可以通过其他节点来获取文件，因此也就不需要Tracker服务器来告诉你，其他节点在什么地方。
虽然DHT解决了去中心化的问题，但要在没有“中心协调员”（Tracker）的情况下实现高效寻址，就要借助PEX。PEX所提供的功能有点类似于以前的Tracker服务器，但工作方式却非常不同。举个例子，我叫D，我有A需要的东西，但是A不认识我，A只认识B，B只认识C，我只认识C，这样A就可以通过B--C，从而找到我。现在Tracker服务器的功能已经可以被DHT+PEX所取代。
磁力链接（Magnet URI）出场了。如果说现实中，待发布的文件就是一个人，我们如何找到他？指纹，是的，每个人都有一个独一无二的指纹，指纹所蕴含的信息，足以找到这个人，而磁力链接（Magnet URI）就是描述这个指纹的一段信息，注意，是一段信息而已，仅仅存在于精神世界的信息。所以，没有人能消灭它！于是我们看到了现在一个全新的BT世界，DHT+PEX网络和 Magnet Link取代了种子和Tracker服务器，没有了中心协调员，连根源都没有了，它实现了真正的人人平等。

㈤ 请问一下，BT下载里面的DHT技术到底是什么意思

DHT网路的介绍

DHT网路的介绍

评论：新版Bitcomet发布，DHT加深反盗难度
本文已发表于《电脑商情报•家用电脑》

2005年6月8日，著名的BT下载软体Bitcomet升级到版本0.59。这次的升级与以往不同，它包含著里程碑式的改变——其开始“支援连入公用DHT网路，实现无Tracker下载”。联想到此前另一著名BT用户端Azureus从2.3.0.0，以及BT官方的BitTorrent从Beta 4.1.0开始使用的"trackerless" torrents，BT下载已经进入崭新的DHT时代。

那麼，DHT究竟为BT带来了什麼？我们采访了Bitcomet的作者灿烂微笑，并将在此文中加以剖析。

一、实战新版Bitcomet

目前国内用户使用最多的BT用户端就是Bitcomet，因此我们在这裏也以它为例讲解DHT网路的使用。

默认情况下，无须做任何设置BitComet即可自动连接并使用DHT网路。启动软体，它会使用和TCP埠号相同的UDP埠进行DHT网路连接。此时，用户可以在Bitcomet的状态条上得到DHT网路连接的状态。

当然，如果要顺利使用DHT功能，除了连接DHT网路之外，还需要档的发布者在制作种子的时候就打开DHT选项。单击功能表“档”－“制作Torrent档”，在弹出的视窗中，就可以调节是否让种子使用DHT网路，共有三种选择。

“使用公用DHT网路(推荐)”表示种子同时使用Tracker伺服器和公用DHT网路来寻找用户，列表框中可以填写传统Tracker伺服器位址或者DHT网路节点位址，也可以只填其中一种，也可以什麼都不填。什麼都不填代表仅仅使用DHT网路，自动连接节点；只填写DHT网路节点代表仅仅使用DHT网路，而且默认连接这几个填写的节点；只填写Tracker代表同时使用Tracker和DHT网路，自动连接Tracker伺服器和节点；同时填写Tracker和DHT网路节点代表同时使用Tracker和DHT网路，而且默认连接这几个Tracker伺服器和节点。总之，此种方式下的BT种子将采取尽可能多的方式进行连接，因此建议种子制作者保持这个默认选项，列表框中像往常一样填写一两个普通的Tracker伺服器地址。

另外两个选择：“不使用公用DHT网路(优先使用Tracker伺服器)”表示在不能链结上Tracker伺服器的情况下使用DHT网路功能，如果能链结上Tracker伺服器，就不使用DHT网路功能；“仅从Tracker伺服器获取用户资讯(禁用DHT及用户来源交换)”则代表禁止使用公用DHT网路以及用户来源交换来寻找用户，完全禁用DHT网路功能，相当於Azureus软体的“安全Torrent”。

如果你不想用Bitcomet的DHT网路功能，则可以在“选项”－“高级设置”中去掉“自动添加DHT网路作为备用Tracker”，并在其下的“网路连接”中去掉“允许加入到公用DHT网路”前面的勾。

在Azureus和BitTorrent Beta中制作支援DHT功能的种子，以及使用DHT网路同样简单，只不过它们的DHT网路功能都没有Bitcomet这麼强大。因此Bitcomet可以同时支援DHT网路和Tracker伺服器，而其他两种软体同时只能支援这两者之一。

有关BT之DHT网路的使用，还请参看我的另外一篇文章－－实战BT之DHT网路。

二、DHT技术让反盗版更加困难？

在多数人眼中，任何P2P技术的改进都与版权的博奕脱不了干系，DHT网路能够引起如此注目亦是如此。

确实，BT采用DHT网路后，反盗版将变得更加困难。因为在此之前，用户进行BT下载时，必需首先连接上Tracker伺服器，根据所获得的正在进行下载和上传的用户列表，才能够进行正常的档交换。这样的话，只需封禁掉提供Tracker服务的网站，便可以截断盗版传播的途径。DHT网路则不同，由於此时互联网中任何一个运行BT用户端的用户都可以作为DHT网路中的节点，因此即使封禁掉那些提供Tracker服务的网站，用户还是能够通过全球范围的逻辑DHT网路分享档，反盗版就无从谈起。除非让世界上的人都不上网，或宣布使用BT软体为重罪。

不过，在我们对Bitcomet作者的采访中，他否认了DHT网路是为了更好的传播盗版。他指出，DHT网路的“主要优势是稳定性，本来Tracker伺服器人多了很容易宕机，但是DHT网路没有这个问题，再多的人也没事”。

这一切还是印证著那句话——“技术从来都是一把双刃剑”。在批判BT助长盗版气焰的同时，我们也应该看到，BT也正在日渐成为合法作品传播的途径。由於无法承受大流量的访问，一些免费和共用软体（如Foobar2000等）开始采用BT方式分发，大型的合法软体——Linux系统，更是将BT作为主要的分发管道。这种良性的应用可能会为BitTorrent带来一定的法律保护，使BT下载商业化甚至合法化。

而随著DHT技术的采用，这种应用还将向纵深发展。虽然它加重了反盗版的难度，但也将使合法分发各种文件更加容易。事物就是如此辩证，但笔者相信P2P软体一定能够寻求到一个更加合理的应用。

三、主要优势在於稳定－－采访Bitcomet作者“灿烂微笑”

Bitcomet 0.59发布笠日，我们有幸通过MSN Messenger采访了Bitcomet的作者“灿烂微笑”（网名），请他来谈一下使用DHT网路后的BT：

问：BT的各个用户端软体是从什麼时候开始用DHT的？它与eMule中的Kad有何不同？
答：BitTorrent是5月份开始测试DHT的，Azureus比较早，但糟糕的是它们两个不互通。eMule中的Kad也是DHT的一种，不过它的实现协议与BT中的并不相同，所以不能互通。 Bitcomet中的DHT与BitTorrent是相容的。

问：为何会出现不互通的现像呢？
答：开发者不同，而且在这个DHT问题上互相之间没有协调好，所以就成了现在这样。更糟糕的是Azureus的DHT代码很长，我却找不到协议文档。

问：对一个用户来说，它获得一个使用DHT网路的种子后，启动Bitcomet进行下载，这时软体是如何连接的？
答：用户打开软体以后就连入网路了，启动使用DHT网路的种子的任务后，Bitcomet就会在DHT网路中搜索。种子上如果有默认节点，那麼可以帮助没有连入网路的用户通过那些节点连入网路，如果下载者已经联入DHT网路了，种子裏填写的节点就不需要了。Bitcomet内置了2个节点，分别是node://router.bittorrent.com:6881和node://router.bitcomet.net:554。其实任何一个长期线上的用户都可以做个好节点。

问：如果这两个长期线上的内置节点出现问题时，是不是就连接不上DHT网路了？
答：不会，这个只是最初的连接用的，如果它们都失效了，那麼1.曾经连上过DHT的用户保存了其他节点，所以只要不要很长时间不用，应该还可以连上；2.新的用户可以通过打开带有DHT节点的种子连入。

问：那麼，DHT网路相比Tracker伺服器来说，有什麼主要的优势？是不是以前下载时，种子只是同时连接同一台Tracker伺服器的下载者，而现在却可以搜索整个DHT网路中，得到更多的源？
答：主要优势是稳定性，本来Tracker伺服器人多了很容易宕机，但是DHT网路没有这个问题，再多的人也没事。如果是单个档的种子，确实也有你说的好处。

问：刚才你说Emule也用DHT，那麼相比之下，BT协议在技术上的优势是什麼呢？
答：应该说BT的DHT才刚开始，eMule应该测试了有1年左右了，BT的优势可能还是原来的吧，就是对新的东西分享比较快。

问：你是如何看待BT下载和软体版权问题的？
答：这个……有难度啊！BT本来只是一种不错的P2P网路技术，我觉得它的流行也代表了一种市场需要吧，说明通过互联网分发作品的可能的价值。虽然目前BT有些被滥用了，不过我想这种P2P技术应该能够寻求到一个更加合理的应用，就像Skype的创始人原来做的是Kazza一样。

问：再问一个读者关心的问题，你认为BT伤硬碟麼？
答：软体刚出来的时候，没有任何缓冲，完全大范围随机地按16K来读写硬碟，所以确实对硬碟不好（不过要速度快的时候才有影响）。当然后来就在软体裏面做缓存了，这个问题就基本不存在了。

问：最后一个问题，你自己经常使用BT下载吗？
答：我很久没用了（很出乎意料吧），不过感觉DHT很好玩，现在的乐趣更多是在编写软体上了。

DHT网路

DHT的全称是Distributed Hash Table，即分散式哈希表技术，是一种分散式存储方法。这种网路不需要中心节点伺服器，而是每个用户端负责一个小范围的路由，并负责存储一小部分资料，从而实现整个DHT网路的定址和存储。和中心节点伺服器不同，DHT网路中的各节点并不需要维护整个网路的资讯，而是只在节点中存储其临近的后继节点资讯，大幅减少了带宽的占用和资源的消耗。DHT网路还在与关键字最接近的节点上复制备份冗余资讯，避免了单一节点失效问题。

形象地，我们可以把整个DHT网路想像成一个大城市，那麼每个用户端，就好比城市裏各个角落的地图，上面绘制了附近区域的地形情况，把这些地图一汇总，城市的全貌就出来了。

而DHT所采用的演算法中最出名的是Kademlia，eMule早在一年多前就开始采用，Bitcomet、Azureus和BitTorrent只是步其后尘，同样使用Kademlia演算法的DHT。不过它们各自的实现协议不尽相同，因此不能相互相容（BitComet与BitTorrent相容，Azureus更像eMule，但与其他都不相容）。

Tracker

Tracker是指运行於伺服器上的一个服务程式，也称Tracker伺服器。这个程式能够追踪到底有多少人同时在下载或上传同一个档。用户端连上Tracker伺服器，就会获得一个正在下载和上传的用户的资讯列表（通常包括IP位址、埠、用户端ID等资讯），根据这些资讯，BT用户端会自动连上别的用户进行下载和上传。

㈥ 1. P2P的特点是什么 2. 基于DHT的Chord环的原理是什么

你好，我们知道区块链网络中多采用P2P网络来进行节点连接和节点之间的消息通信。这里对P2P网络的优缺点做个简单汇总，
1、网络中节点的可扩展性
在P2P网络中，节点可以随意的添加和删除。新的节点添加到网络中，一般通过种子节点接入网络，同时种子节点将新节点广播给其他节点并进行连接。
2、去中心化
在P2P网络中，不存在客户端与服务器这样的严格区分，同时每个节点又充当着客户端和服务器。各个节点之间是平等的，只要接入网络，任意节点都能够将消息通知给网络中的每个节点。

㈦ 什么叫做P2P

下载——鼠标轻点几下即可完成的操作！迅雷、Bitcomet、电骡、风播.......大家使用的下载工具五花八门，但仔细研究这些主流的下载工具，它们都围绕着一个核心的技术名词——P2P。如何能够最快最完整地得到你想下载的资源呢？那么，你就不得不了解当今最火爆的P2P下载技术。

一、认识P2P

1998年，18岁的肖恩·范宁为了解决室友如何在网上找音乐的问题而开发了Napster软件，在短时间内就拥有了8000万的用户！它带给我们新的体验，改变了我们的生活，Napster也理所当然地成为了P2P技术诞生的标志，从此以后，P2P开始了极富生命力的发展。

[图1]P2P为英文Peer to Peer的简写，意为对等网络，简单地说就是互联网上的每台计算机都可以作为一个节点来与其他节点直接进行通讯，它又可以分为少量依赖Server、完全依赖Server和完全不依赖Server三种方式。P2P让人们通过互联网直接交互，每台计算机既充当着服务器又充当着客户端的角色。使用P2P模式进行下载可在下载同一文件的同时将已下载的部分数据传递给其它的计算机，将上传的开销分摊到各个下载者那里，这样“下载人数越多，下载速度越快”（P2P下载原理如图1所示）。

P2P下载最大的优点是下载速度不再受服务器带宽及下载人数的限制，它充分利用了传统下载方式空闲的上传带宽。但P2P下载也有一些缺点，如：长期霸占带宽资源可导致内网通信中断，如果“种子”过期则无法下载。

二、主流的P2P软件

目前，众多P2P下载工具已经给用户带来了各种便利，比较有特色的包括：Bitcomet、迅雷、Emule（电骡）、风播等。下面就这几种软件进行深入的比较，以便大家能够对P2P 技术有更深刻的认识。

Bitcomet：BT下载的全称是Bit Torrent，而Bitcomet是美国人Bram cohen 在2001年开发的一个开源和开放协议的下载工具，其技术特点是简单有效，设计十分精巧，而且比起老前辈 Napster、Kazaa 、Gnutella 等来，由于有了MFTP多源下载技术，速度提升十分快。

迅雷：它2004年出现，开始是与Flashget 网际快车类似的下载工具，由于迅雷兼容了传统的FTP和HTTP下载技术，同时支持P2SP 技术，所以下载速率得到不少提升。

Emule（电骡）：它实际是源于电驴EDonkey，两者的协议基本相同，只不过后来由不同的开源组织进行维护。电骡最大的优点是可以支持软件内搜索，而且可以搜索到的资源很多。

风播：它是2006年出现的一个新兴的P2P视频点播软件，不仅仅支持常规下载，而且还支持在下载的同时观看影视节目。所以我们不必等待几小时到影片下载完毕再观看。最重要的是风播兼容BT协议和Torrent种子文件，所以节目源非常丰富。

三、下载技术大比武

1．如何找到下载文件

P2P技术的实现原理其实基本是一样的，打个比方，我要和某个不认识的朋友通信，但我不知道对方的联系方式，最简单的方式就是我和对方都在一个我们共同知道的地方留下联系方式。在P2P网络中，这个共同知道的地方就是目录服务器。每个客户端首先需要登录到目录服务器上，在登录的时候客户端需要将自己拥有的资源向服务器汇报一下，这样当其他客户端希望下载某个资源时，只需要向服务器查询一下拥有该资源的客户端IP地址和端口，然后直接联系客户端即可。在BT和风播中，目录服务器被称为Tracker；在电骡中，目录服务器被称为电骡服务器，迅雷也有类似的中央控制服务器。

当前，已经出现了纯P2P技术，就是无需目录服务器的DHT动态哈希表技术，BT、风播、电骡均支持。DHT技术实际上也是一种特殊的目录服务器，只不过把中央目录服务器变为很多小目录服务器。由于细节比较复杂，就不在这里继续讨论了。

2．如何让下载的人越多速度越快

P2P下载速度快的秘密就是MFTP（多源下载）技术，可以将下载速率提高至少10倍。MFTP技术的核心有三点：一是要将资源文件分割成等长的分片，这样便于标记和处理；二是客户端之间必须互相了解对方都有哪些文件分片，这样便于互通有无，达到边下载边上传的目的；三是客户端收到一个分片后，必须有机制可以校验该分片是正确的，否则如果一个分片错误会导致整个资源文件损坏。

BT和风播采用的分片是可以调整的，是从64KB到8MB不等，一般在512KB至1MB之间，电骡是9.28MB。迅雷也有类似的分片技术，但是不支持在下载的同时上传。分片大小对下载效率还是有影响的，一般来说，分片大了，客户端之间互相交互所消耗的流量也会比较小，因为客户端互相交互分片信息也是需要数据包的，但是分片大了，会导致传输效率下降。

有些用户使用BT和风播的时候，不明白Torrent 种子文件是什么，其实种子文件记录的信息很大一部分就是每个文件分片的校验和。而电骡的文件校验和又在哪里呢？大家可以打开电骡的Temp目录，里面有一个后缀名为part.met的文件，里面就包含了校验和。

3．如何搜索到下载资源

这里所说的资源搜索其实主要是资源的展示方面，也就是平时我们如何找到我们想下载的资源文件。
电骡是依靠服务器和客户端两种搜索方式，电骡依靠强制共享，将每个骡友的部分硬盘目录及文件共享出去，在电骡启动时候，它会将我们电脑的共享目录上报到电骡服务器上，这样其他骡友就可以直接到服务器上进行搜索了。

BT、迅雷、风播基本上是依靠到Web服务器上搜索资源文件或检索资源文件，在BT和风播中，打开种子文件即可下载。而迅雷是保存了FTP或HTTP的原始链接，打开链接以后启动下载功能。

4．坏人算法与好人算法

有朋友问，为什么我用电骡下载某个文件即使源很多，下载速度也特别慢呢？这就要从P2P分享率谈起，分享率是P2P世界的一个非常重要的指标，分享率指上传和下载的比值。

不同的P2P技术对于解决分享率有不同的处理方式。大致可以分为两种：坏人算法和好人算法。所谓坏人算法和好人算法其实是一种假设，坏人算法假定所有的客户端都是自私的，但是为了大家都来贡献自己的力量，制定了一个规则：如果不共享，就要遭受一定的惩罚；好人算法默认每个客户端都会按照自己能力尽量上传。

在电骡的网络中，采用了一种信用机制，当你上传流量很多的时候，你就获得比较高的信用值，从其他人那里获取流量的可能性就加大。每个电骡会维护一个服务队列，当我向别人请求数据时候，别人会根据我的信用等级进行排队，信用等级越低，排队越靠后。因此，老电骡们由于上传多，积分也高，下载速度就比较快；而新手由于上传少，积分低，下载速度也相对比较慢。

BT采用的是坏人算法，客户端定时会计算对方是否给自己流量，如果对方不给我流量，我会将对方阻塞掉。这样迫使对方必须提供一定的上传带宽。

迅雷采用的主要还是好人算法，每个客户端不可以控制自己不向别人贡献流量。风播采用好人算法和坏人算法相结合的方式。

5．调度算法

调度算法是所有P2P技术的核心，不同的厂商有不同的实现方式，一般都是技术机密。对于BT、电骡、迅雷来说，一般采用乱序下载算法，这是迅速利用客户端上传带宽比较有效的方式。风播为了实行在线播放，调度算法完全不同于其他P2P软件，是一种顺序和乱序的结合算法。

假设做种的Seed 有1、2、3、4、5 五个分片，如果按照传统的HTTP或FTP下载方式，Peer1和Peer2 向Seed 都从文件头部的分片1开始请求，那么极端的后果就是P2P无法实行，因为Peer1和Peer2还是把压力加在Seed上（原理如图2所示）。

但是如果采用乱序下载就不一样了，Peer1 从Seed获取分片1，Peer2从Seed获取分片2，它们相互就可以从对方获取自己没有的数据，P2P 方式就很容易发挥作用（原理如图3所示）。

对于P2P下载，乱序方式解决得很好。但是对于流媒体，必须要求文件分片是顺序获取，风播采用了一种乱序和顺序相结合的方式来解决该问题，也就是整个文件的获取方式，基本上是顺序方式获取，但是具体每个分片，又采用乱序方式获取，这样就取得了下载速度和顺序观看影片的平衡。

㈧ 求助NS2下如何仿真P2P里面的chord算法，现在十分迷茫

P2P的一个常见问题是如何高效的定位节点，也就是说，一个节点怎样高效的知道在网络中的哪个节点包含它所寻找的数据，如下图：

对此，有三种比较典型的来解决这个问题。

Napster：使用一个中心服务器接收所有的查询，服务器告知去哪下载其所需要的数据。存在的问题是中心服务器单点失效导致整个网络瘫痪。

Gnutella：使用消息洪泛（message
flooding）来定位数据。一个消息被发到系统内每一个节点，直到找到其需要的数据为止。当然，使用生存时间（TTL）来限制网络内转发消息的数量。存在的问题是消息数与节点数成线性关系，导致网络负载较重。

SN型：现在大多数采用所谓超级节点（Super
Node），SN保存网络中节点的索引信息，这一点和中心服务器类型一样，但是网内有多个SN，其索引信息会在这些SN中进行传播，所以整个系统的崩溃几率就会小很多。尽管如此，网络还是有崩溃的可能。

现在的研究结果中，Chord、Pastry、CAN和Tapestry等常用于构建结构化P2P的分布式哈希表系统（Distributed Hash
Table，DHT）。

DHT的主要思想是：首先，每条文件索引被表示成一个(K,
V)对，K称为关键字，可以是文件名（或文件的其他描述信息）的哈希值，V是实际存储文件的节点的IP地址（或节点的其他描述信息）。所有的文件索引条目(即所有的（K,
V）对)组成一张大的文件索引哈希表，只要输入目标文件的K值，就可以从这张表中查出所有存储该文件的节点地址。然后，再将上面的大文件哈希表分割成很多局部小块，按照特定的规则把这些小块的局部哈希表分布到系统中的所有参与节点上，使得每个节点负责维护其中的一块。这样，节点查询文件时，只要把查询报文路由到相应的节点即可（该节点维护的哈希表分块中含有要查找的(K,V)对）。

这里介绍的Chord算法就是解决网络内节点定位问题的一种P2P协议。它通过多个节点跳转找到我们所查找的资源：

我们先看看它是如何进行的，随后再总结其特点和操作特征，以及一些实现。

1.Chord里面的基本要素

节点ID：NID（node
identifier），表示一个物理机器，m位的一个数字（m要足够大以保证不同节点的NID相同的几率小的可以忽略不计），由节点机器的IP地址通过哈希操作得到。

资源ID；KID（key
identifiers），原为键ID，其实际表示一个资源（因为Key与一个资源value哈希绑定），故在本文中统称资源ID（这样比较直观），m位的一个数字（m要足够大以保证不同资源的KID相同的几率小的可以忽略不计），由Key通过哈希操作得到。

常哈希函数：较之一般哈希函数，节点的加入和离开对整个系统影响最小，另外还有一些优势在此不赘述。在Chord中使用SHA-1来进行常哈希计算。

Chord环：Chord
Ring，NID和KID被分配到一个大小为2^m的环上，用于资源分配（给某一个节点）和节点分布，以及资源定位（注：在这个环上的ID为0--2^m-1）。首先我们说资源分配，资源被分配到NID>=KID的节点上，这个节点成为k的后继节点，是环上从k起顺时针方向的第一个节点，记为successor(k)。而节点分布则顺时针将节点N由大到小放在这个环上。例如下边这幅图：

这是一个m=6的环，其中有10个节点，5个资源，K10的后继节点为N14，也就是说K10被分配给了N14。

2.Chord资源定位（Key
Location）

资源定位是Chord协议的核心功能，为了便于理解，我们先介绍一个简单的资源定位方法，然后再介绍这个可伸缩的资源定位方法。

简单方法：

考虑如下场景：节点n寻找KID为id的资源，此时节点n首先问询是否在下一个节点上（find_successor），这要看资源k的KID是否在该节点NID和下一个节点的NID之间，若在则说明资源k被分配给了下一个节点，若不在则在下一个节点上发起同样的查询，问询下下一个点是否有该资源。如此迭代下去，用伪代码定义这个操作：

n.find_successor(id)
if (id є (n; successor])
return
successor;
else
// 将查询沿着环进行下去
return
successor.find_successor(id);

例如下图：

节点N8寻找K54这个资源，N8.find_successor(K54)发现下一个节点N14不合符54є (8;
14]，于是N14发起同样的搜索，然后一跳一跳后直到节点N56满足54є (51; 56]，于是得知资源K54在N56这个节点上。

在一个有N个节点的环上，这样的查找方法显然在最坏的时候要查找N次才能得到所需资源的位置，查找次数与节点个数成线性关系。显然，这样的效率不给力，所以Chord使用了可伸缩资源定位的方式来提高效率。

可伸缩方法：

在每个节点N上都维护了最多有m项（m为ID的位数）的路由表（称为finger
table），用来定位资源。这个表的第i项是该节点的后继节位置，至少包含到2^(i-1)后的位置。还是延续上边的例子：

节点N8的路由表中，左边那一栏包含了N8+1到N8+32（2^5-1）的位置，右边那一栏每个位置对应的实际存在的节点。比如N8+1-N14，表示在N8后的第一个位置上的资源由N14来负责。这样记录有以下优势：

每个节点只包含全网中一小部分节点的信息。

每个节点对于临近节点负责的位置知道的更多，比如N8节点对于N14负责的位置知道3处，而对N21负责的位置只知道1处。

路由表通常不包含直接找到后继节点的信息，往往需要询问其他节点来完成。

当在某个节点上查找资源时，首先判断其后继节点是不是就持有该资源，若没有则直接从该节点的路由表从最远处开始查找，看哪一项离持有资源的节点最近（发现后跳转），若没有则说明本节点自身就有要寻找的资源。如此迭代下去。

例如：节点N8寻找K54这个资源

首先，在N8上查找后继节点为N14，发现K54并不符合54є (8;
14]的要求，那么直接在N8的路由表上查找符合这个要求的表项（由远及近查找），此时N8的路由表为：

我们发现路由表中最远的一项N8+32--N42满足42є (8;
54]，则说明N42这个点离持有K54这个资源的节点最近（因为N42在该路由表中离N8这个节点最远），那么此时跳到N42这个节点上继续查找。N42的后继节点为N48，不符合54є
(42; 48]的要求，说明N48不持有资源54，此时，开始在N42的路由表上查找：

N42节点的路由表为：

我们由远及近开始查找，发现N42+8--N51满足51є (42;
54]，则说明N51这个点离持有K54这个资源的节点最近，那么此时跳到N51这个节点上继续查找。N51节点的后继节点为N56，符合54є (51;
56]，此时定位完成，N56持有资源节点K54。

用伪代码表示：

// 查询节点n后继节点。
n.find_successor(id)
if (id є (n;
successor])
return successor;
else n0 =
closest_preceding_node(id);
return n0.find successor(id);

// search
the local table for the highest
// predecessor of
id
n.closest_preceding_node(id)
for i = m downto 1
if (finger[i] є
(n; id))
return finger[i];
return n;

经证明，最多经过O(log N)次查找就能找到一个资源。

3.Chord的节点加入

Chord通过在每个节点的后台周期性的进行stabilization询问后继节点的前序节点是不是自己来更新后继节点以及路由表中的项。

有三个操作：
join(n0) ：n加入一个Chord环，已知其中有一个节点n0.

Stabilize():
n查询其后继节点的前序节点P来决定P是否应该是n的后续节点，也就是说当p不是n本身时，说明p是新加入的，此时将n的后继节点设置为p。

Notify(n0): n0通知n它的存在，若此时n没有前序节点或，n0比n现有的前序节点更加靠近n，则n将其设置为前序节点。

Fix_fingers(): 修改路由表。

具体的，例如：

这是原先的结构：

现在N26节点要加入系统，首先它指向其后继N32，然后通知N32，N32接到通知后将N26标记为它的前序节点（predecessor）。如下图：

然后N26修改路由表，如下图：

下一次N21运行stabilize()询问其后继节点N32的前序节点是不是还是自己，此时发现N32的前序节点已经是N26：

于是N21就将后继节点修改为N26，并通知N26自己已经将其设置为后继节点，N26接到通知后将N21设置为自己的前序节点。

这个加入操作会带来两方面的影响：

1)正确性方面：当一个节点加入系统，而一个查找发生在stabilization结束前，那么此时系统会有三个状态：

A.所有后继指针和路由表项都正确时：对正确性没有影响。

B.后继指针正确但表项不正确：查找结果正确，但速度稍慢（在目标节点和目标节点的后继处加入非常多个节点时）。如下图：

C.后继指针和路由表项都不正确：此时查找失败，Chord上层的软件会发现数据查找失败，在一段时间后会进行重试。

总结一下：节点加入对数据查找没有影响。

2)效率方面：当stabilization完成时，对查找效率的影响不会超过O(log N)
的时间。当stabilization未完成时，在目标节点和目标节点的后继处加入非常多个节点时才会有性能影响。可以证明，只要路由表调整速度快于网络节点数量加倍的速度，性能就不受影响。

4.Chord节点失败的处理

我们可以看出，Chord依赖后继指针的正确性以保证整个网络的正确性。但如图，若N14, N21,
N32同时失效，那么N8是不会知道N38是它新的后继节点。为了防止这样的情况，每个节点都包含一个大小为r的后继节点列表，一个后续节点失效了就依次尝试列表中的其他后继节点。可以证明，在失效几率为1/2的网络中，寻找后继的时间为O(log
N) 。

5.Chord的特征和应用

特征：去中心化，高可用度，高伸缩性，负载平衡，命名灵活。

应用：全球文件系统、命名服务、数据库请求处理、互联网级别的数据结构、通信服务、事件通知、文件共享。

http://blog.csdn.net/foreverdengwei/article/details/6179438

㈨ 什么是ipfs

星际文件系统IPFS（InterPlanetary File System）是一个面向全球的、点对点的分布式版本文件系统目标是为了补充甚至是取代目前统治互联网的超文本传输协议（HTTP），将所有具有相同文件系统的计算设备连接在一起。它的文件一直都可以使用，您可以浏览相关电影等。
个人觉得就是想试试最好托管，因为IPFS挖矿主要因素是宽带和位置，进行抢单。家用矿机其实根本抢不到单子，自然没什么收益。目前ipfs还没上主网，所以现在的矿机基本上都在推广阶段，性价比是比较好的时间段。ipfs上线主网之后的未来收益还是值得期待的。
不知道说矿机名字会不会有广告嫌疑，反正有个叫“壹五叁IPFS矿机”的经过比较之后还不错，保证本津、挖矿策略智能（ipfs是需要调整挖矿策略的）
最近还和这个团队的人聊了聊，觉得还是靠谱，年级都不大，所以理想化、具有精神吧

㈩ APP宣称自己利用区块链技术而发展出来，什么是真正的区块链技术

区域块链一词比较抽象，理解难度较大，第一次听到这个词语之后，许多人感觉晦涩难懂，其实简单点来说，虽然是一个分布账单，将不同的交易，用不同的账单呈现出来，这就是区块链，当然这些都是我个人看法。

真正的区块链要懂得方便迅速，现在社会发展较快，人们已经适应快节奏的生活，所以区块链也要投其所好，知道人们想要什么东西。

所以区块链就我们个人而言，它是一个比较抽象的名词，但是随着时间的推移和发展，这个名字会被大家越来越熟悉，慢慢的也会走入我们的生活。当然区块链这个名词会越来越完善，同时也会越来越清晰，不会像现在这么抽象，当然随着时间的发展，他的真面目也会揭开，变得不再那么神秘，同时走进我们大众的视野，这些对于区块链的发展都是至关重要的。