可执行文件

可执行文件（精选6篇）

可执行文件 篇1

引言

“加壳”是指将软件程序加密, 并将一段代码植入到该程序中的技术。在被加壳程序运行时, 所植入的代码获得程序控制权、对被加密的代码进行解密, 并将控制权归还给解密后的程序[1]。“加壳”技术可用于保护软件的版权, 使其免受破解和逆向分析;也可用于恶意程序的免杀, 使其绕过杀毒软件的检测。

“PE结构”是Windows操作系统可执行文件所遵循的结构, 程序的代码保存在PE结构的“代码区段”。本文研究通过复制代码区段的方式将一个PE文件中的代码植入到指定的可执行文件, 使两个PE文件融合以实现 “加壳”的方法。文章内容对软件加壳技术和软件内容安全的研究有积极意义。

一、基于PE融合的“加壳”原理

如图1所示, Windows可执行文件遵循“PE结构”, 每个可执行文件中包含多个“节区” (section) , 如代码节区、数据节区、资源节区等。对程序“加壳”, 首先需要使用加密算法对目标软件 (图1中的“可执行文件”) 的代码区段进行加密, 并将另一段代码 (图中的“Stub程序”) 植入到目标文件中。具体的植入方法, 是在目标文件中建立一个新的节区, 将Stub程序的代码节区内容复制到目标节区中, 并将程序的入口更改为新节区的代码位置。

经过上述处理后, 目标软件被加壳。已加壳的软件在执行时, 被植入到新节区中的Stub程序获得控制权, 该Stub程序使用解密算法对原程序中被加密的节区进行解密, 并通过指令跳转的方式将控制权归还给原程序。上述过程完成了软件的“脱壳”。

二、设计一个“加壳器”

基于上述的“PE融合”原理, 可以设计出一个简单的“加壳器”, 用于对指定的软件进行“加壳”。该加壳器应包含“Stub程序”和“加壳逻辑”两部分, 具体如下所述。

“Stub程序”应实现以下功能:1) 对宿主程序 (即图1中的“已加壳程序”) 的代码节区进行解密。2) 通过跳转指令将程序控制权归还给宿主程序。

“加壳逻辑”应实现以下功能:1) 对被加壳程序的代码节区进行加密。2) 计算Stub代码节区的大小, 并在被加壳程序中开辟同样大小的新节区。3) 将Stub程序的代码节区内容复制到上述的新节区。4) 记录被加壳程序的程序入口、传递给Stub程序, 并将已加壳程序的入口改为被植入的Stub代码节区 (即上述的“新节区”) 。

三、结语

本文研究了通过“PE融合”的方式对软件程序“加壳”的方法, 并在此基础上提出了一个“加壳器”的设计[2]。本文内容对软件加壳技术、软件内容安全的研究有积极意义。在后续的研究过程中, 我们会在本文研究成果的基础上, 通过编程方式实现一个“加壳器”, 并展开对加壳过程中更高级的加密方法 (如加密的同时进行压缩) 的研究。

参考文献

[1]赵北庚.PE头结构逆向分析研究[J].网络安全技术与应用, 2015 (10) .

[2]焦龙龙, 罗森林.PE文件加壳技术研究与实现[J].信息网络安全, 2013 (1) .

可执行文件 篇2

工具: hex editor (例如 Hiew), 大脑(如你平常一般使用)

Ok, 开始工作

使用你熟悉和惯用的十六进制编辑工具(如Hiew)打开Hello.exe， 直接到资源区(.rsrc). 如果使用hiew 则按F8, 再按F6，进入.rsrc。(译注：使用EXESCOPE 参见.rsrc中的pointer to RAW data也表示这个偏移值). 这样，你就看到了IMAGE_RESOURCE_DIRECTORY(资源目录)，它的结构如下：

typedef struct _IMAGE_RESOURCE_DIRECTORY {

ULONG Characteristics;

ULONG TimeDateStamp;

USHORT MajorVersion;

USHORT MinorVersion;

USHORT NumberOfNamedEntries;

USHORT NumberOfIdEntries;

} IMAGE_RESOURCE_DIRECTORY, *PIMAGE_RESOURCE_DIRECTORY;

ULONG = 4 bytes, USHORT = 2 bytes 共16个字节

这些东西对我们没什么大用，但你需要知道，哪里是后面数据的开始. 因此，向前16个字节你会看到一些IMAGE_RESOURCE_DIRECTORY _ENTRies (资源目录入口地址), 它的结构：

typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY {

ULONG Name;

ULONG OffsetToData;

typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY {

以十六进制格式，你将看到(类似的数据):

(译注：为便于分析，翻译时使用了win下的 NOTEPAD 5.2 作为演示样例)

xx 00 00 00 xx 00 00 xx xx 00 00 00 xx 00 00 xx

123456789 10 11 12 13 14 15 16

00008000h: 00 00 00 00 00 00 00 00 04 00 00 00 00 00 08 00 ;

00008010h: 03 00 00 00 50 00 00 80 04 00 00 00 A8 00 00 80 ;

03 00 00 00-50 00 00 80 - 04 00 00 00-A8 00 00 80

12345678

...

每个 IMAGE_RESOURCE_DIRECTORY _ENTRY(资源目录入口) 是 8 字节长。在给出的实例数据中，前8个字节(03-80)对于我们来说并不重要(它通常用于: 图标Icon, 菜单Menu, 对话框Dialog...)，但字节从‘04’到‘80’(参见上面的示意数据，即9-16位)是非常重要的。

从9-16位，其中前4个字节代表名称(对于我们没有用)，第5-8位字节代表偏移量，如果这个重要的标志位即数据的最高位是1, 表示指向另一个IMAGE_RESOURCE_DIRECTORY(资源目录)， 否则，它指向IMAGE_RESOURCE_DATA_ENTRY(真正我们需要发现的位置)。

在我们的例子中，数据是 800000A8 (A8 00 00 80)，最重要的标识位被设置为1(数据最高位)，这表示，A8是从.rsrc区段开始到一个IMG_RES_DIR(资源目录)的偏移量。

经检测，资源段开始的偏移是8000，则在80A6处放置的是另一个IMG_RES_DIR(资源目录)，就像前面提过的，它也不重要，继续跳过16字节，你能看到下一个IMG_RES_DIR_ENTRY(资源目录入口)。

000080a0h: 09 00 00 00 48 02 00 80-00 00 00 00 00 00 00 00 ;

000080b0h: 04 00 00 00 00 00 01 00-01 00 00 00 60 02 00 80 ;

跳过前4个字节，它代表名字，后4个字节是80000260 (60 02 00 80)，标志位依然是1，那继续到8260(8000+260), 那里是下一个IMG_RES_DIR(资源目录),再跳过16字节，又是一个IMG_RES_DIR_ENTRY(资源目录入口)，跳过4字节(名字), 看到数据是00000440.

00008260h: 00 00 00 00 00 00 00 00 04 00 00 00 00 00 01 00 ;

00008270h: 04 08 00 00 40 04 00 00 00 00 00 00 00 00 00 00 ;

好了，标志位为0，因此在00008440(8000+440)处就是我们要找的目标了-IMAGE_RESOURCE_DATA_ENTRY(资源数据入口)，它的结构是

typedef struct _IMAGE_RESOURCE_DATA_ENTRY {

ULONG OffsetToData;

ULONG Size;

ULONG CodePage;

ULONG Reserved;

} IMAGE_RESOURCE_DATA_ENTRY, *PIMAGE_RESOURCE_DATA_ENTRY;

只有前两个域对我们来说是重要的，数据是 0011750 (数据偏移)和 330 (尺寸)，我们一会儿要用到这些数据，因此记下IMAGE_RESOURCE_DATA_ENTRY(资源数据入口)的地址，在我们的实例中是8440.

00008440h: 50 17 01 00 30 03 00 00 E4 04 00 00 00 00 00 00 ; P...0...&.......

数据偏移尺寸

(译注：当尺寸第二位不为0时，数据偏移地址应减去该值 11750-300=0e750，原文未说明，经观察发现，可能不正确，更多细节，参见有关技术资料)

现在，到了0E750，你应该可以在这里看见菜单资源：

0000e750h: 00 00 00 00 10 00 87 65 F6 4E 28 00 26 00 46 00 ; ......‡e&N(.&.F.

0000e760h: 29 00 00 00 00 00 01 00 B0 65 FA 5E 28 00 26 00 ; ).......°eú^(.&.

0000e770h: 4E 00 29 00 09 00 43 00 74 00 72 00 6C 00 2B 00 ; N.)...C.t.r.l.+.

0000e780h: 4E 00 00 00 00 00 02 00 53 62 00 5F 28 00 26 00 ; N.......Sb._(.&.

菜单项的结构

00 00|00 00|10 00| 87 65 F6 4E 28 00 26 00 46 00 ;

属性ID菜单项名称

前两个字节 C 不知道用途，可能仅起分隔符作用

3-4字节- 属性 (描述见后)

5-6字节- 菜单项的ID (对于弹出菜单，此项不代表ID)

从第7字节开始 C 菜单项名称 (当是弹出菜单时，名字从第5个字节开始)

注意一个例外: 在开始的菜单项之前，有两个空(Null)字节作为开始标识

特性 C 我仅仅列出比较重要的属性，完整的列表无法从winuser.h或网站上获知

0800 C Separator(分隔符)

0000 C Enabled(允许)

0001 C Grayed(变灰)

0002 C Disabled(禁止)

0010 C Popup(弹出)

0080 C End(结束)

菜单项的分割符，看起来象这样:

00 00 | 00 08 | 00 00

属性名称字符串 (仅仅两个空字节)

例如，菜单项如下

00 00 00 00 | 90 00 | 26 00 46 00 69 00 6C 00 65 00

00 00 | 80 00 | 69 00 45 00 26 00 78 00 69 00 74 00

你可以看到第一个菜单项的属性是 90 = 80 | 10 表示是弹出菜单项，并且结束，

第二个属性仅是 80 = End. 它不是弹出菜单, 因此它肯定是子菜单。

现在，我们要加菜单项，首先应该知道它象是什么样子，如一个OPEN菜单项应该象这样：

00 00 | 00 00 |70 00| 26 00 4F 00 70 00-65 00 6E 00

属性ID&Open

你看，ID是 0070, 但它可以是任何未被使用的值. ‘O’字符前的(&)号将使得‘O’具有下划线以及可以键入字母‘O’来激活相关菜单项

现在再设置一个‘Close’关闭菜单项:

00 00 | 01 00 |71 00 | 26 00-43 00 6C 00-6F 00 73 00-65 00

属性ID&Close

你可以看到，属性是0001(表示灰色)，ID值是自定义的。

在我的演示程序中(一个简单的Hello World应用程序示范，仅有2个菜单项，它使用MS VC++编写)我在发现我的菜单资源后的位置找到了一块空间(通常是被‘0’填充的区域)，在

6960，因此我写了一个文件菜单，插入‘Open’和‘Close’菜单项. 最后是一个退出菜单项‘Exit’ ，它们的样子如下:

00 00 00 00-90 00 26 00-46 00 69 00-6C 00 65 00

00 00 00 00-70 00 26 00-4F 00 70 00-65 00 6E 00

00 00 01 00-71 00 26 00-43 00 6C 00-6F 00 73 00

65 00 00 00-80 00 69 00-45 00 26 00-78 00 69 00

74 00 00 00

现在w, 写下6960,它指向一个44(十六进制)字节的区域，

现在，回到刚才提到的那个地址(在演示的NOTEPAD里是0E750，在我的HELLO WORLD里是61F0，指向的地址是000067C8，尺寸是22)，你应该已经记下来了，将它的内容改为新的地址(从 000067C8 到 00006960，尺寸. 然后改变尺寸，从 22 到 44)。现在保存程序再运行它，我是可以看见我的‘Open’和‘Close’菜单项了。如何，你明白了吗?

有一件事情需要提醒你，当你希望在一个可执行文件中，添加菜单项时，可能需要改变相关的段(section)尺寸，这方面的资料，你可以比较容易的在网上查到。如果你高兴，你可以在某个程序的‘退出’菜单项前加上一道分隔符.

感谢你们大家

作者：FENRI

有关资料，请参见:

可知行文件格式(The Portable Executable File Format - by Johannes Plachy)

可执行文件 篇3

一、文件内容与载体的关系解读

(一)信息与载体的不可分离性。

从古代档案到传统纸质档案到现代档案,信息内容与载体始终紧密联系、不可分离。电子文件有多种载体依附形式,常见的有磁带、软盘、光盘、硬盘。在这些载体之中,文件的信息是以代码形式记录的。也就是说,原生数字信息是以二进制形式存在的,具有虚拟文件的特征,没有像传统的文件一样有实体载体、存取是实实在在、摸得着看得见的载体。但是这种虚拟性文件的原始数据是存在电脑的磁盘、硬盘里的数据,它的存储载体是服务器。由此,电子文件的信息内容并不能脱离载体而存在,相反,用户一定要在特定载体上才能完成对文件内容的读取。

(二)信息与载体的可迁移性。

作为信息与载体可分离论的支持者,冯惠玲教授认为电子文件信息与载体之间可以分离,可分离性是电子文件诸特点中最为核心的特点。这个观点其实恰恰是对信息与载体间的不可分离性及可迁移性的最大支持。“可分离性”主要表现出电子文件及其信息没有固定的存储地点、蕴含不同载体、可实现网络异地传输等特点。这本质上是电子文件信息可以在不同载体间迁移,是信息与载体的非对称一对多关系,而不是与载体分离。或许是电子信息在不同载体间的传递过程让学者们产生信息与载体可分离的印象,然而事实上,从电子信息的传递是通过光缆等设施进行的,且不说这些光缆设施本身也是载体,单说在这个传递过程中,光缆运输的并非信息,而是信号,这些信号只有到达另一个终端并被正确解码后才再次成为机器可读的信息。因此,电子文件信息与载体的“可分离性”的表述不符合电子文件信息特征,而电子文件信息的“可迁移性”的表述更能切合其信息可以在不同载体间迁移的内涵。

二、电子文件保持原始性的管理措施

(一)形成过程中电子文件原始性的保持。

电子文件的形成需要经过起草、修改、定稿、签发、打字、校对等手续,原始性认定工作应该从这个阶段就开始,因为只有在这个阶段明确了电子文件最初生成时的状态。这个过程中保持电子文件的原始性的具体措施有:首先,电子文件的制作系统过程要权责分明。权利要有所限制,责任要明确规定。每一环节的电子文件经手者都要清楚自己的职权范围,使文件的每一次变动都做到事后有迹可查。这样就能够在行政管理方面使电子文件的原始性得到保障。其次,使用专有的电子公文生成处理系统。特定的软件开发系统需要部门单位与专业的软件开发公司进行合作,再对办公人员进行培训使用,这样能够在技术层面保障电子文件的安全性和专业度。最后,防写措施。在电子文件最终形成后,通过系统软件将电子文件设置为只读状态。使用户只能读取文件信息,未经授权的人员没有修改权。

(二)传递过程中电子文件原始性的保持。

首先,采取加密防护,确保数据传递安全。其次,设置防火墙,隔离非法涉密者。防火墙技术是是针对Internet网络不安全因素所采取的一种保护措施。顾名思义,防火墙就是用来阻挡外部不安全因素影响的内部网络屏障,其目的就是防止外部网络用户未经授权的访问。它可以控制进、出两个方向的通信,可有效保护网络及网络信息安全。最后,对于电子文件可能在传递中受损的问题,应该经常检查系统软件的兼容性以及检查设备的老化程度,对系统和设备要定时维修更新。而对于接收到受损电子文件的情况,应该马上联系发文机关,让其重新补发。

(三)电子文件的接收和保存。

为使电子文件在转化为档案以后的原始记录性无论是从内容上还是载体上的一致性都不加改变,目前,电子文件的永久保存问题普遍受到世界范围内各政府、学界、企业的关注。Inter PARES项目是一个目前已有28个国家或地区在内的国际性合作组织。这个组织的目标是永久保存以数字形成的文件的真实性,并通过提供依据标准、政策、战略和行动指南确保用户对使用内容的信任。专业性、国际化的项目组织的成立对于推动保护电子文件的真实性作用和意义都是巨大的。文书工作者和档案工作者可以多借鉴组织或学术机构的最新理论、技术成果,优化自身工作。

参考文献

[1].傅荣校.化繁为简:从档案机构角度看如何保障电子文件的真实性[J].档案学通讯,2015.2

可执行文件 篇4

答：你可以在记事本当中输入如下内容：

//////// 以下为记事本中内容，不含此行 ////////

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT.exe]

@=exefile

Content Type=application/x-msdownload

[HKEY_CLASSES_ROOT.exePersistentHandler]

@={098f2470-bae0-11cd-b579-08002b30bfeb}

//////// 以上为记事本中内容，不含此行 ////////

完成后另存为.reg注册表文件(任意命名，例如exe.reg)，然后双击并导入文件，

可执行文件 篇5

据互联网调研机构统计,在我国P2P(Peer-to-Peer)流量峰值在白天最高达到因特网流量的60%以上,在夜间甚至超过90%。由于目前大部分P2P文件共享系统在设计其通信协议时,主要设计目标是让用户获得高速的数据传输速度,没有考虑实际网络拓扑结构,导致P2P系统中的一个逻辑hop可能跨越整个网络直径甚至多个不同网络。这不可避免的造成P2P流量被大量扩散到骨干网中,长时间占据着宝贵的骨干网带宽资源,很容易造成网络拥塞从而严重影响网络性能,导致因特网中的某些传统业务无法正常运行,给网络运营商带来了极大的难题。

为解决该问题,目前的做法一般是检测出P2P流量并对之进行限制[1,2],但这种做法会导致客户流失,并非运营商所乐见。事实上,P2P计算模式本身并没有缺陷,给运营商带来的问题主要是由当前P2P软件在设计上的缺陷造成的。例如在Gnutella中,一个请求进入网络的节点由根服务器随机指定几个系统中已存在的节点与之建立连接;在Kazaa中,一个请求加入网络的节点由根服务器随机选择一个超级节点作为其连接节点。在这些系统中,节点请求某个文件时可能会从网络距离很大的节点中获取,而事实上与节点邻近的节点中可能就存在该文件。在这种情况下P2P系统给骨干网带来很多不必要的流量(特别是网间流量);而且从距离较远的节点中获取文件并不明智,距离越远意味着延迟更大,一般情况下文件传输速率也越低。一些后继P2P系统,如Pastry[3]和Tapestry[4],虽然在节点请求加入网络时会首先探测该节点与侯选连接节点间的通信链路情况,选择通信质量最佳节点作为请求入网节点的处理节点;但是,由于其出发点是为P2P节点获得高传输速率,无视网络的物理拓扑结构,采用这种方式仍然无法解决大量的P2P流量扩散到骨干网中的问题。文献[9]提出了一种在结构化P2P层叠网(如Pastry和Tapestry)中通过选择邻近文件交换节点进行文件交换,从而避免流量扩散的方法,但该方法要求控制文件在虚拟网络中节点的分布,一般只能在对网络节点有完全控制权的企业内部使用。本文系统的设计思想与文献[9]类似,但本文采用了一种与网络运营商分层网络架构相适应的树形P2P层叠网结构,构造了一种面向整个互联网、可将P2P流量尽可能地控制在本地网络的P2P文件共享系统。

2 节点组织方法

因特网是全球最大的互联网络系统,它由一系列独立的自治系统(Autonomous System)使用边界网关协议互联而成;其设计原则是分而治之,分层管理。在中国,因特网主要由六大网络互联构成[8],其中CHINANET和CNCNET是主要为公众提供服务的网络,它们都在多个城市建立城域主干网并用覆盖全国的高带宽核心网络进行连接。由于本文主要讨论P2P流量的本地化,因此从网络运营商的角度出发,本文将自治系统内部网络结构抽象为三层体系结构,即覆盖全国的骨干网、省市(大区)核心网以及接入网,如图1所示。在图中终端用户分为两类,其一为局域网用户,例如大学中的计算机一般属于此类;另一类为ADSL用户,该类用户主要是中国电信或中国网通等运营商的宽带用户。本文试图根据节点所属的自治系统及其地理位置信息构造反映上述网拓扑结构的P2P文件共享系统,以此在节点有文件请求时首先考察能否在该节点所属的低层网络中(例如首先考虑节点所在的城域网)被满足,如果可以则该次请求产生的流量就不会被扩散到上一级别的网络,否则再逐级向上层网络扩散。

基于上述分析,本文根据节点网络拓扑距离的远近程度将P2P文件共享系统中的节点分组,我们称这种划分产生的P2P节点组为簇,P2P流量只有在簇内节点无法满足时才扩散到簇外。实际上将网络中的机器聚簇以提供更高服务质量的做法,在传统的C/S业务模式中(如网页浏览)已有研究,例如文献[5,6,7]给出了将客户端机器聚簇以便在特定地点设置服务器镜像或缓存代理的方法。但这些方法无法直接应用到P2P层叠网的组网中,因为其聚簇的粒度要么太大[5],要么太小[6][7],缺乏根据节点规模进行自适应聚簇划分的能力;簇中的节点太多,将导致簇的头节点无力处理众多节点的数据请求,而簇内节点太少将使系统中簇的数量太多而使管理困难。为此,我们给出了一种适用于P2P网络的自适应多层节点聚簇方法,该方法不仅可以使拓扑距离接近的节点落于同一簇内,而且可以保证节点簇具有合理的规模。

图2给出了本文P2P文件共享系统的总体结构图。在图中节点泛指所有加入到P2P虚拟网络系统中的机器,这些机器在其组成的P2P虚拟网络中共享文件。从图2可以看出,系统中的节点被聚集于不同的蔟中,每个簇由一个头节点进行管理。节点簇的层次数随着网络中节点的规模而递增,例如在图2中CNCNET由于节点数较少,所有节点位于第一层聚簇中,而CHINANET则由于节点数量较多总共包含了三层子簇。为便于区分不同类型的头节点,我们将包含子簇的头节点称为超级头节点(Super Head Peer,简称SHP),不包含子簇的头节点称为普通头节点(Common Head Peer,简称CHP)。根节点实质上也是一个头节点(SHP),该节点管理的簇即为整个P2P文件共享系统,根节点可由网络运营商设置一个或一组服务器作为系统中的永久性节点。下面我们讨论该虚拟网络的形成和维持过程。

2.1节点加入系统

节点通过向根节点发送消息请求加入P2P文件共享系统,根节点接收到该节点(Join Peer,简称JP)的连网请求后,其首要任务是根据JP的IP地址判断其所属的第一层聚簇(运营商网络),其后或者建立节点所属的第一层聚簇或者将该入网请求转发给其所属第一层聚簇的头节点。为完成上述功能,根节点必须判定节点所属的运营商网络,为此根节点必须拥有IP地址分配机构分配给各运营商的IP地址信息;我们从IP地址分配机构APNIC的数据库中获得了各运营商所拥有的IP地址段信息,结合JP的IP地址根节点即可确定其所属的运营商网络。判定JP所属的第一层聚簇后,根节点必须根据节点所属第一层聚簇的状态做出相应处理,为此根节点必须维护第一层聚簇的相关信息。根节点采用三元组(O,C,B)记录其所需的第一层聚簇信息,其中O是第一层聚簇的编号,C和B分别存储当前头节点和后备头节点的IP地址以及计算资源信息;设置后备头节点的目的是防备由于当前头节点突然离开而引起网络故障,我们将后备头节点的个数设置为2。根节点根据上文算法返回的O值,检查对应编号的三元组中C值是否为空(为空表示该编号簇尚未建立),若为空将当前节点设置为其所在第一层聚簇的头节点——将其IP地址及计算资源属性存入C中,否则,将节点的连网请求信息转发给C所指的头节点,由其进行后继处理。

头节点接收上层头节点转发的节点连网请求消息后处理方式不同:CHP直接将JP置为子节点而SHP根据JP的IP地址判定其所属的下一层子簇后将该入网请求信息转发给该子簇的头节点,由其进行处理,这种处理方式上的差异导致这两类头节点所需维护的数据亦存在区别。CHP直接管理网络中的普通节点,它使用二元组(P,S)记录其子节点信息,其中P是节点IP地址,S为节点的资源属性集合;为便于进行子簇分裂,CHP将其所有子节点对应的二元组,按照P从小到大排列形成子节点信息表CL。接收到其上层SHP转发的节点连网请求消息后,CHP首先计算其P值,然后根据该值将其插入到子节点信息表的适当位置。SHP采用四元组(O,MP,C,B)记录每个子簇的信息,其中O是子簇编号,MP记录子簇所含子节点的最大IP地址,C和B分别存储子簇当前头节点和后备头节点的IP地址以及计算资源信息,当前编号最大的子簇其MP值为:255.255.255.255,所有子簇记录按其编号大小排列形成子簇信息表HL。SHP节点收到JP入网请求后,取节点IP地址根据公式1计算出其T值,按子簇编号从低到高检查是否有T< MT,第一个满足该条件的子簇即为JP所属子簇。确定JP所属的CHP后,由CHP节点向节点返回加入网络成功信息。在此过程各级头节点根据需要可能将JP选为后备头节点。

2.2节点离开系统

节点离开系统具有正常退出与异常离开两种方式。正常退出指用户启动了正常退出程序以使节点退出P2P层叠网,采用这种退出方式时根据节点在层叠网中角色有以下两种处理过程:1)退出节点是普通节点,此时节点向其CHP发送退出网络请求,CHP收到该请求后在子节点列表中删除该节点对应的记录,并向节点返回退出成功信息即可;2)退出节点是头节点,此时则首先要进行头节点切换(使后备头节点成为头节点),切换成功后新头节点向其上层SHP发送前头节点退出网络信息,SHP收到该消息后修改对应子簇的头节点信息,至此头节点退出网络过程完成。

节点异常离开指由于网络或机器故障等原因导致节点在网络中失效,此时节点不会向其头节点发送退出网络信息,头节点必须根据节点的心跳信息侦知节点已经失效(认为节点退出网络),并启动相应的处理。为此,节点加入P2P虚拟网络后,必须向其头节点发送心跳来表明自己的状态,并通过接收头节点的心跳回复信息获得头节点的状态;通过这种方式使整个层叠网的状态得到维护并对失效节点及时进行处理。如果头节点连续三个周期没有收到其管辖子节点的心跳信息则认为该子节点已异常离开网络,此时,如果头节点是CHP则将该子节点信息从其子节点列表中删除,如果头节点是SHP则必须启动头节点切换,之后SHP删除子簇列表中该失效头节点的对应记录。

2.3簇的分裂与合并

随着网络中节点的持续加入,层叠网中的CHP管理的子节点数将超过阀值(设为H1),此时CHP将进行子簇分裂,分裂方式有两种:1)CHP生成两个新的子簇,把子节点均分到这两个子簇中;2)CHP生成一个兄弟簇,并从子节点信息表中划出下半部分子节点到该簇中,图3给出了这两种分裂方式示意图。CHP采用哪种分裂方式由其上层SHP决定,CHP在进行分裂之前首先询问其上层SHP可否采用第二种分裂方式;SHP检查其管理的子簇数量是否已达到最大限值(设为H2),如尚未达到则允许CHP采用第二种分裂方式,否则CHP只能采用第一种分裂方式。CHP使用一个状态变量记录其当前子节点数量,当该变量超过阀值并持续一段时间后启动子簇分裂过程。与子簇分裂相对应,随着层叠网中节点的退出,某个CHP节点管辖的节点数将较少甚至为0,此时将对某些节点数较少的子簇进行合并,合并过程为分裂过程的逆过程。

从上文的介绍中我们可以看出子簇是否需要分裂以及采用何种方式进行分裂是由阀值H1 和H2决定的。H1 表示的是CHP可管理的最大子节点数,在P2P层叠网相对稳定时,CHP的主要负担是接收子节点的心跳信息,为避免CHP负担太重,我们取H1为254。子节点的心跳信息采用TCP连接发送,每个心跳信息包只需要标识出包类型即可并不需要包含任何数据,因此其大小为41字节(20字节的IP报头+20字节的TCP报头+1字节的包类型标识),因此CHP在维护网络状态方面的带宽花费为 (41×8×256)/60=1.4Kbps。显然,即便对于使用ADSL方式连网的机器该带宽消耗也在可忽略不计范围内。取H1为254的另一个原因是此时子簇正好可容纳一个C类网段。H1 表示的是SHP可管理的最大子簇数,由于我国目前的省级行政区数量为32个,为使运营商网络中各个省的节点可以独立形成子簇,我们取H2为32,因此SHP节点最多仅有32个子节点,其在网络状态维护方面的带宽消耗基本可忽略。

3基于簇的文件搜索

上文我们给出了系统中节点的组网方法,本节我们将给出在系统中节点请求文件时获取文件提供节点的方法,图4给出了该过程示意图。当节点r请求某一文件时,它将向其所在子簇的CHP(图4中节点1)发送文件搜索请求,CHP节点接收该请求后检查其管辖子节点中是否存在该请求文件,如果存在且拥有该文件的节点个数足以为文件请求节点提供适当的服务质量保证(例如可以保证一定的文件下载速率),则CHP节点将选中的资源提供节点返回给文件请求节点,由文件请求节点向这些资源提供节点获取文件即可。

如果CHP在其管辖的子簇中无法找到请求文件或者拥有该文件的节点数量不足,则CHP将文件请求信息发送给其上层SHP节点(图4中的节点2),同时告之SHP需要的文件服务节点数。SHP节点收到该文件搜索请求后,首先将该请求转发给节点3(即子簇1的左兄弟簇),如果节点3返回搜索结果后节点数量满足要求,则节点2将该搜索结果返回给节点1,节点1将搜索结构汇合后发送给文件请求节点r ;如果节点3的返回文件服务节点数少于请求的节点数,那么节点2将文件请求再转发给节点4(即子簇1的右兄弟节点),节点4返回搜索结果后如仍不能满足要求,则节点2再次将文件请求信息转发给节点3的左兄弟节点和节点4的右兄弟节点,如果文件服务节点数量一直不足则节点2将按该顺序遍历所有子簇。如果节点2搜索完所有子簇后,仍不能获取足够的服务节点数,则将该文件请求转发给其上层SHP(节点5),节点5采取与节点2同样的方式逐次请求节点6、7等头节点管辖的子簇中的节点提供文件服务节点,如果节点5仍无法返回给节点2足够的文件服务节点,则节点5将向其上层SHP节点转发文件请求,如果文件请求一直无法得到满足则该过程可递归进行直至根节点。采用这种方法可以保证如果文件请求节点所在的子簇或其相近子簇中存在请求文件时可优先成为服务节点,从而使P2P流量尽可能地发生在网络拓扑距离相对较近的节点之间。

4性能分析

为评估本文所给出的P2P文件共享方法在流量本地化控制以及服务质量方面的性能,我们进行了广泛的仿真实验,比较分析了本文所给方法与其它P2P文件共享方法(如Gnutella等随机选择服务节点的方法)在流量扩散程度方面的性能差异。仿真平台中采用的物理网络拓扑结构如图1所示。为增加仿真的真实性,我们从APNIC数据库中随机选取了CHINANET和CNCNET各5个IP地址段,这些IP地址段共包含了约九千个IP地址,我们假设每个IP地址对应一个节点。我们假设由这些节点构成的P2P虚拟网络中共包含2000个大小为400MB的视频文件,这些文件按照Zipf规律(为便于处理,实际上我们对采用的是近似的Zipf分布:假设2000个文件中的前30%的热点文件被70%的节点拥有)分布在虚拟网络的节点中;每个节点可以拥有0至10个文件。网络中节点的文件请求也遵循上述近似Zipf分布。基于上述场景,我们仿真了两种P2P虚拟网络,其一为类似Gnutella的无结构随机选择文件服务节点的P2P网络,其二即为本文提出的基于簇的P2P文件共享受系统。假设每个大文件被分为4000个100KB的文件块,每个服务节点为文件请求节点提供部分文件块;文件请求节点由仿真平台随机选取,被选取的节点按照Zipf分布随机选定所需要的文件。

图5给出上述两类P2P系统中发生10个、20个、40个、80个、120个以及185个文件共享请求时的网络流量分布状况,其中图5(a)给出了属于同一IP地址段中节点之间发生的流量情况,图5(b)给出了同一网络内部同省(或直辖市)节点之间发生的流量情况,图5(c)给出了同一网络内部跨省(或直辖市)节点之间发生的流量情况,图5(d)给出了属于不同网络的节点之间发生的流量情况。从图中可以看出,与随机选择文件服务节点的方法相比,本文方法可将大量流量(增加至少3倍)限制在属于同一IP地址段或属于同一个省市的节点之间(图5(a)和(b));同时极大的减少同一运营商网络内部的跨省流量(图5(c));并基本避免了网间流量即采用本文方法网间流量趋于零(图5(d))。显然,在流量的本地化控制性能方面本文方法与其它不考虑P2P节点网络距离的方法相比优势明显,约可将80%左右的流量控制在运营商省级网络范围。

5结束语

本文在分析现有P2P软件系统弊端的基础上,结合我国目前因特网的拓扑结构以及网络的管理特点,给出了一种面向运营商可控制P2P流量的P2P文件共享系统。通过与传统的P2P文件共享系统进行性能方面的仿真比较,结果表明本文给出的方法在P2P流量的本地化控制方面具有优越的性能。基于本文研究成果,本文的下一步目标是面向运营商开发一体化的P2P计算平台,基于该平台可开发多种类型的P2P业务,从而结束目前P2P流量难于监管的局面,促进P2P计算的健康发展。

摘要：目前大部分P2P文件共享系统由于在设计时没有考虑实际网络的拓扑结构,导致巨大的P2P流量挤占了宝贵的骨干网资源,使P2P计算遭到网络运营商的排斥。为解决上述问题,本文从运营商的角度出发,在深入分析我国互联网络的基础上,给出了一种自适应多层节点聚簇构建P2P文件共享系统的方法,该方法可将绝大部分的P2P流量限制在本地网络内,阻止P2P流量向上层网络扩散。仿真结果表明,本文方法可将80以上的P2P流量限制在运营商省级网络范围内。

关键词：P2P层叠网,节点自适应聚簇,P2P流量控制,基于簇的文件搜索

参考文献

[1]Shen Fuke,Change Pan,Ren Xiaoli.Research of P2P Traffic Identification Based on BP Neural Network.Third International Con-ference on Intelligent Information Hiding and Multimedia Signal Processing,2007.

[2]韦安明,洪波,程时端等.高速网络中P2P流量检测及控制方法.北京邮电大学学报,2007,(05):

[3]Antony Rowstron and Peter Druschd.Pastry:scalable,decentralized object location and routing for large-scale peer-to-peer sys-tems.IFTP/ACM International Conference on Distributed Systems Platforms,2001.

[4]Ben Y.Zhao,John Kubiatowicz,Anthony D.Joseph.Tapestry:an infrastructure for fault-toleran wide-area location and rou-ting.UCB Technical Report UCB/CSD--01--1141,April2001.

[5]Hancong Duan,Xianliang Lu,Hui Tang etc..Proximity Neighbor Selection in Structured P2P Network.Proceedings of The SixthIEEE International Conference on Computer and Information Technology,September2006.

[6]P.Barford,J.Cai,J.Gast.Cache placement methods based on client demand clustering.Proceedings of IEEE INFOCOM02,New York,June2002.

[7]A.Bestavros,S.Mehrotra.DNS-based Internet client clustering and characterization.Proceedings of the4thIEEE Workshop on Workload Characterization,Austin,TX,USA,December2001.

[8]B.Krishnamurthy,J.Wang.On network-aware clustering of web clients.Proceedings of ACM SIGCOMM00,Stockholm,Sweden,August2000.

可执行文件 篇6

关键词：分布式,虚拟磁盘,可扩展,分布式文件系统

1 分布式虚拟磁盘

对于分布式文件系统来说, 服务器端的存储系统应该是有着良好的全局访问特性、良好的性能、巨大的存储容量、可以使得多个客户端进行访问、以及易于维护的特性, 本文所讨论的分布式虚拟磁盘就是基于这样的一个目标来设计, 它由一组拥有物理磁盘的服务器通过网络连接构成。对于使用者而言, 他所看到的是一个虚拟磁盘, 它可以提供高可靠性的存储服务, 这个虚拟磁盘对于所有的用户都可见, 也就是说所有的client共享同一个Virtual Disk。Client可以在需要的时候创建一个虚拟磁盘来弥补容量或者性能的不足, 换句话说, 任何需要的资源比如物理磁盘、服务器都可以被自动的并入虚拟磁盘服务当中。

一个虚拟磁盘类似于一个容器, 它也是以块为读写单位, 这种虚拟磁盘的设置可以使得我们能够将磁盘的物理存储空间从客户端中独立出来, 这样就可以在多个client当中共享同一个物理资源并且能够很容易的提供快照这样的服务。该虚拟磁盘提供一种更底层的文件访问接口, 在它之上可以实现诸如分布式文件系统等客户端。

分布式虚拟磁盘的整体架构是由多个分散在各处的分布存储服务器组合起来的形成的一个单一的、以block为单位的存储设备。客户端将它视作多个虚拟磁盘的集合, 并且通过RPC (远程过程调用) 来访问分布式虚拟磁盘提供的服务。Clients需要记住当前一些mapping的信息来决定将读和写操作分派到那个server当中去。

Server会维护一些当前存储系统的一些信息, 和当前所挂载的虚拟磁盘等信息, 这些信息会在整个分布式虚拟磁盘的系统当中 (多个server) 当中进行冗余备份, 由全局状态模块来确保该信息的完整和一致性, 在当前的实现当中这些信息的大小不会超过1M, 同时利用了Paxos分布式一致性算法来完成这一实现。

2 分布式文件系统

在分布式虚拟磁盘的基础之上, 我们可以实现一种简单的、可扩展的分布式文件系统。它采用两层架构底层就采用我们所讨论过的虚拟磁盘来实现服务器端分布式的存储, 在上层给用户提供一种服务, 多个用户通过使用这个服务来实现文件内容的共享。

2.1 分布式文件系统设计概要

该分布式文件系统通过一个全局统一的锁服务器来同步各个客户端对整个系统的访问, 最大限度的保证文件的完整性和一致性。总的来说一个可扩展的分布式文件系统应该有如下特点:

(1) 所有的用户应该看到的是同样的文件拷贝, 或者说是文件映像。

(2) 服务器端应该非常容易的进行维护和扩容, 通常的管理和维护操作应该不会对客户端的使用造成影响。

(3) 新client的添加相对简单, 管理员不需要关心用户文件存放的具体位置。

(4) 能够在一定程度上实现用户文件的版本管理和备份, 使得用户可以恢复一部分被删除的文件。

(5) 系统的异常、备份、恢复都不会对用户的使用造成影响, 这些维护操作对用户来说都是透明的。

用户的应用程序用过操作系统提供的标准文件访问函数就能够访问我们的分布式文件系统, 一旦与服务器的通信链接建立起来之后, 所有的客户端就能够看到同样的文件映射, 他们都存储在云端 (虚拟磁盘) , 同时, 如果任何一个客户端对某个文件的访问其它用户都会察觉到。

在用户的客户机上会运行我们的分布式文件系统服务, 这个服务会接管操作系统中文件系统的访问操作, 然后向一个虚拟的设备当中 (虚拟磁盘) 进行文件的读写。这个虚拟设备对用户隐藏了实现细节, 让用户觉得对分布式文件系统的操作和本地磁盘无异。

如图1所示了虚拟磁盘的布局图, 该图中标识除了虚拟磁盘空间的空间分配布局结构。

第一个区域存储了该虚拟磁盘的一些配置信息, 这个空间被分配了大概1T的空间, 但实际上它所占用的空间非常少。第二个区域存储日志信息, 每一个文件存储服务器都会在该部分得到自己的日志空间来记录log。第三个区域来记录磁盘的分配状况, 用bitmap的形式标识哪些部分是可以使用的那些已经被占用, 每一个服务器都会在这个区域中拥有一块自己的bitmap区域。这部分的大小大概为3TB。第四个区域用来保存文件的节点信息, 每一个文件都需要一个节点来保存一些元数据, 比如说时间戳、真正存放数据的指针等等, 如果是符号链接的话那么就直接将文件的内容保存在节点中。这个节点的设计和磁盘的物理块大小相同。这个区域的大小为1TB, 由于每个node的大小为512字节, 因此可以容纳231个节点。第五个区域是为存放每个文件的开始64K的数据所准备的, 如果一个文件的大小超过了64K, 那么剩余的部分就会被存放在大数据块区域, 这个区域的大小为247字节。剩下的区域就是大容量存储块了, 每一块有1TB的存储空间。

目前这样设计的限制是只能支持224个不超过 (64K+1TB) 的大文件存储, 这样的设计对于目前来说是够用的, 如果需要改变分布式文件系统的服务器也能够提供不同的虚拟磁盘来满足日益增长的需求。

2.2 分布式文件系统的日志和恢复机制

该分布式文件系统使用一种称之为预写入重做机制来记录文件的元数据日志, 对文件的实体数据并不记录log, 这样可以最大限度的提高系统的效率, 并且减少系统的负载。

虚拟磁盘的每一个服务器都有一块私有的日志空间, 当服务器需要更新文件的元数据的时候, 将会首先在内存中创建描述这个更新的记录。这些在内存中的日志记录会定期的按照请求的先后顺序写入虚拟磁盘当中。

为了能够有效的区分每一份日志的开始和结束, 我们给日志的每一个数据块进行编号也就是说每512个字节成为一个单元并给它按递增的顺便编号。这样的处理就可以根据当前的序号和上一个序号的大小来判断一份日志是否结束。如果递增的顺序被打破, 那么日志就到此结束。

系统能够处理多份日志, 为了保证日志记录和恢复工作的有效性, 我们还需要注意这么几个细节问题:第一, 同步锁协议的设计, 在后面的讨论我们能够看到所有对同一数据块的更新操作是被序列化的, 也就是说对于任一数据块最多只有一份日志保存了不完整的元数据信息。第二, 恢复系统仅仅只恢复没有完全更新的日志记录, 在每一个512字节的元数据块当中都有一个版本号记录。像目录这种跨越多个元数据块的信息会有多个版本号。当日志更新的时候会记录一个新的版本号, 所以在恢复的时候仅仅只是更新数据块的版本号小于日志信息版本号的那部分数据。第三, 由于只记录元数据的日志信息, 为了防止元数据块所占用的位置被真正的数据块所覆盖从而导致版本号信息不准确, 我们在虚拟磁盘当中为元数据块指定了专门的位置以防和真正的数据区产生冲突。系统的底层用虚拟磁盘来实现存储, 这样可以利用前面所讨论的虚拟磁盘的容错和恢复机制来进行系统的恢复。

3 小结

本文主要介绍了分布式虚拟磁盘和文件系统设计的基本原理, 它们是云计算和云存储的基础架构, 在此理论基础之上我们能够实现一个可扩展的分布式文件系统, 并能够进一步的研究其实现细节、分布式处理问题以及并行算法的设计与实现。

参考文献

[1]Edward K.Lee and Chandramohan A.Thekkath;Petal:Distributed Virtual Disks.Systems Research Center Digital Equipment Corporation.

[2]Chandramohan A.Thekkath.Timothy Mann;Edward K.Lee.Frangipani:A Scalable Distributed File System.

[3]陈惟康, 杜松.分布式存储中数据放置策略的研究[J].计算机应用与软件, 2009 (01) .

[4]吴华, 杨安祺.分布式文件系统中恢复机制的研究[J].科技与创新, 2006 (24) .