分享
 
 
 

网络机器人(Robots): 是福还是祸?

王朝other·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

网络机器人(Robots): 是福还是祸?

Martijn Koster, NEXOR

April 1995

[1997: Updated links and addresses]

Codehunter[程式猎人]翻译

摘要

机器人在万维网上使用已经有一年多了(相对于1995年)。在这段时间中,它们担当着有用的任务,同时也对网络造成了很大的破坏。本文着重研究机器人在资源收寻方面的优势以及劣势。讨论和比较一些标新立异的资源收寻策略。最后得出结论,在很长的一段时间内,机器人将被广泛的使用,但是随着网络的增大,这些机器人将会变得缺乏效率并且会出现更多的问题。

引言

在过去的几年中万维网[1]已经变得非常大众化了,现在她已经成为因特网上主要的信息发布的平台。随着网络站点和文档不断的增加,经由手工点击超联接的方法浏览网页资源已经变得不可能了,更不用说是一种有效率的资源探索的方法了。

这个问题促使了自动浏览“机器人”的实验。网络机器人是一个通过得到文档然后分析出网页超链接结构,以得到的文档为参考,周而复始得到所有文档的程序。这些程序有时被叫做“蜘蛛”,“网络漫游者”或“网络蠕虫”。这些名字或许很吸引人,但它可能会使人误解,“蜘蛛”和“网络漫游者”给人一种它自己能自动移动的印象,而“网络蠕虫”能自己繁殖,就好像声名狼藉的因特网蠕虫病毒[2]。事实上机器人作为一个单独的软件系统,它仅仅是通过标准的环球网协议从远程站点获取信息的工具。

机器人的用处

机器人能处理很多有用的工作。

统计分析

第一个机器人[3]被用来发现并计数WEB服务器的数目。其他统计包括每个服务器的文档平均数,某些类型文件的比例,网页大小的平均数,网络互联的程度等

维护

一个很重要的难点是维护导航到其他网页的超文本结构,当这些被涉及的网页被移动了,这些联接可能会成为变成“死联接”(dead link)。 现在还没有一个统一的机构来主动通知网页维护人员来修改联接。一些服务器,如CERN HTTPD,能够纪录因死联接而造成得失败请求,根据死链接找到网页,然后手工解决。这种方法不太实用,事实上当网站作者注意到这些时他们只能发现网页包含了坏联接,在许多情况下用户是靠电子邮件通知他们的。

机器人可以校验索引,诸如MOMspider [4],能够帮助作者定位那些死联接,同时帮助超文本结构的维护。机器人也能够帮助维护网页内容,一般通过检测HTML [5]的一致性,一致设计方针,有秩序的更新等等。但这不是普通的惯例。正如可提出证据加以证明的那样,这种功能应该被集成到HTML开发环境中,当文档改变时,这些检测能被重复执行,这些问题很快能被解决了。

镜像

镜像是一个维护FTP档案的流行技术。一个镜像通过FTP拷贝整个目录树,并且规律的得到已经被改变的文档。镜像允许你分享这些文件,减少因主机错误而导致的多余拷贝,并能加快访问速度,减少访问费用,实现离线浏览。

在没有出现成熟的镜象工具时机器人能够被用来镜像网站。有些机器人能够得到一个子目录的文件并储存到本地。但是它不能轻易的更新那些被改动的网页。第二个问题是那些被拷贝的网页需要重写:那些已经被镜像的网页可能需要改变超联接的指向,那些关系到未被镜像的页面的联接需要展开成绝对联接。从性能考虑对镜像工具的需求是尽量减少对成熟的高速缓存服务器[6]到来的依赖,选择性的更新,能够保证一个缓存的文档被更新,并且能够最大程度的自维护。不管用什么方法,我们期望镜像工具能及时的被开发出来。

探索资源

也许机器人最令人兴奋的应用是探索资源。在任何人们不能够拷贝大量信息的场所,最能够吸引人的就是让计算机做这些工作,一些机器人囊括了大量的网页,并提供了访问这些信息的搜索引擎。

这就意味着一个网络用户能够联合浏览和查找来定位一个信息,这种方法胜于单独依靠浏览;即使数据库不能包含你所需要的项目,它可能包含相关与目标信息的网页。

第二个优势是这些数据库能够自动而规律的更新,因此死链接将被察觉并删除。这和手工维护文档比较锁碎和不全面,形成了鲜明的对比。机器人的探索资源的功能将在下文做更深的讨论。

组合使用

一个机器人能够处理多项任务,如RBSE Spider [7]能够统计分析得到的文档也提供了资源探索的功能。令人遗憾的是像这种组合功能的机器人是如此的稀少。

运作的花费和危险

机器人的使用带来了很高的代价,特别当他们工作在遥远的英特网上。在这些段落中我们将看到机器人在环球网中昂贵的需求所带来的危险。

网络资源和服务器负荷

机器人需要相当可观的带宽。首先机器人的运作需要不断的额外延长周期,常常是一个月。为了加快执行速度许多机器人同步执行,导致在一定时间内带宽总是处于高使用状态。如果机器人在短时间内做了大量的文件获取(“快速开火rapid fire“),就连远程的网络也能感觉到网络资源的紧张。这能够导致其他用户暂时性的带宽不足,特别是在地带宽的链路中,比如英特网还没有一个成熟的处理负载平衡的协议。

习惯上,因特网已经被认识到是免费的,个人用户无需为他的操作支付费用。这个理解是建立在未经详细调查的基础上的,特别像公司的用户就能直接感觉到网络使用同花费的关系。一个公司能够感觉到为他们的(潜在的)客户服务是值这些花费的,但是自动传输的机器人却不能够体会到这些费用。

除了微网络的需求,机器人还对服务器提出了外加需要。依赖于频繁的从服务器请求文档能够导致一个相当大的负载,这将导致对其他网络用户的访问服务下降。特别当这个主机还被用来做其他目的是,是完全不能接受的。这里是一个试验,笔者运行了一个模拟程序,同时在他的服务器上获取20个文件,服务器同时运行着Plexus服务/Sun 4/330(SUN公司的计算机型号)。在几分钟内机器慢的像一个爬虫,并且不能做任何事。其实就是连续的获取所导致的结果。仅仅在我写本文的这个星期,一个机器人用快速开火的方法访问了我的站点。过了170个连续的获取后,我的服务器崩溃了。

这些事实显示快速开火应该要避免。不幸的是一些流行的浏览器(如Netscape)也因为能够并发地获取在线图片而忽略了这个问题。环球网协议,HTTP[8],已经显示出这种传输的低效率,新制订协议将改正这些问题[10]。

更新的内务操作

我们已经提及机器人能够自动更新数据库。但是不幸的是在环球网上还没有一个有效的文档更新控制机制;没有一个请求能够确定某一组URL(统一资源定位符)已经被移动了,删除了或更改了。(译者注:HTTP1.0已经加入获取最后更改时间的请求)。

错误的执行

新开发的机器人尤其会增加主机和网络的过度劳累。即使协议和URL的发送是正确的,并且机器人也正确的处理了相应协议(包括一些高级的特性如重定位(redirection)),还是会出现不可预料的问题。

笔者已经观察到同样的机器人访问他的服务器。虽然在某些情况下,这是由一些使用网站的人为了测试而导致的(代替一个本地服务器),在某些情况下显然是因为松散的执行。重复的获取一般发生在某一方没有存储对地址的访问历史(这是不可原谅的),或者是当机器人不能辨别出那些语法上相同的URL,如不同的域名指向同一个IP地址,或URL不能被机器人规范,如"foo/bar/../baz.html" 和"foo/baz.html"是一样的.

一些机器人会得到一些他们不能处理并忽略掉的文档类型,如GIF和附言。

还有一些危险是,有一些接近无限的网页空间。举个例子一个脚本返回一个网页,由这个网页链接到一个更深层的网页。如开始于"/cgi-bin/pit/",链接到"/cgi-bin/pit/a/", "/cgi-bin/pit/a/a/", 等等。因此这些URL空间能够欺骗机器人使它陷入其中,这种陷阱通常被叫做“黑洞”。关于机器人排斥(Exclusion)的一些标准在下文将作讨论。

编写目录问题

由机器人产生的资源搜索数据库很流行是无可厚非的。用户根据一定规则来使用这个数据库用来定位资源。然而,机器人在网络资源探索的适用性方面的限制还有一些争议。

网络中有太多的信息,而且它都是动态。

判断一个获取信息途径的效率的尺度是 "查全率(recall)",即实际上被发现的所有有关的文件的分数。 Brian Pinkerton [15] 规定的查全率在因特网指数标定系统中是正确的, 就好像发现相关的文档一样不是问题.然而,如果一把英特网上整套可利用的数据视为一种基础,并非由机器人产生的数据库,查全率不可能是高的,如同数据的数量是巨大的,而且变化很时常发生一样。当网络生长,因此在实践中机器人数据库不可能包含特别细节的资源,随着环球网的增长情况将变得更坏。

决定什么信息是包含的或者排斥的

机器人不能自动决定是否一个给定的网页应该被包含在他的索引中。WEB服务器可能为那些与本地上下文相关的文档(如一个内部的图书馆索引),他们仅仅是暂时存在,或为了其他目的。从某种程度上说, 当机器人在操作的时候可能没有被识别的时候,对机器人是否包括一些网页的决定也依赖于使用者。在实践中机器人最后几乎存储所有文件。注意即使一个机器人能够决定是否在他的数据库中排斥一个特殊的网页,但是他们已经花费了得到这个文件的费用;机器人对这个高花费文档的忽略是非常浪费的。

试图减轻这种情况,一些机器人组织已经采用了“机器人排斥标准”。这个标准描述了使用一个简单的文本文件,把它放在服务器众所周知的地方("/robots.txt")来指定那方面的URL空间应该被机器人过滤掉(见图一)。这个方法也能够用来避免机器人陷入黑洞。个人机器人能够给他一个特殊的指令,就好像某些机器人可以比其他机器人更敏感,或他们知道专门研究一个特殊的领域。这个标准是非官方的,但他实施起来非常简单,并且有相当大的公众压力来促使机器人准守。

决定怎样遍历网站是一个相关的问题。给定的大多数WEB服务器是层次组织的,一个广度优先(breadth-first)遍历从顶层到有限的深度或许能够比深度优先(depth-first)更快的发现一个更大的范围和更多同一层的文档和服务器,这种方法更适合资源的探索。然而,深度优先的遍历可能更容易发现那些能够链接到其他地址的个人主页,潜在的新的地址,新的服务器,因此可能更容易发现新的站点。

# /robots.txt for http://www.site.com/

User-agent: * # attention all robots:

Disallow: /cyberworld/map # infinite URL space

Disallow: /tmp/ # temporary files

Figure 1: An example robots.txt file

概括文档

概括文档和索引网页完全不同。早期的机器人只是简单的存储文档的标题和锚的描述文本,但是新的机器人使用了更高级的机制,全盘考虑整个文档的内容。

这些方法有一些很好的概括标准,能够自动应用到所有网页,但是对作者来说这种方法和手工标定一样不是很有效率。HTML提供了一个机制能够在文档上附上META信息,只要指定一个<META>元素,如"<meta name= "Keywords" value= "Ford Car Maintenance">.然而,指定这个值的属性的标记没有被语义学定义,这个状况严重的制约了这个标记的接受度,而这个机制却非常有用的。

获得文档的总数同查询到的相关文档的比例,这个值的准确度很低。高级特性如布尔运算(Boolean operators),加权匹配(weighted matches)如广域信息服务系统(WAIS),或相关性反馈(relevance feedback)能够降低这个值得准确度,因特网给我带来的巨大信息更加重了这个问题。

文档分类

环球网用户经常需要一个主题层次文档。GENVL[17]允许手工维护主题层次,这方面很多问题的介绍超出了本文所讨论的范围。机器人能够呈现一个主题层次的视图是非常有用的,但是这需要一些自动档案分类的机制[18]。

上文讨论的META标记给作者提供了一种归档他们自己文档的机制。当分类系统使用时怎样应用它就成为问题了。连传统的图书馆也没有使用单一的标准系统,而采用了其中的一些,并且采用了他们自己协定来实施它。在环球网上实施统一解决方案是没有希望的。

确定文档的结构

也许最困难的是网络不是由一组一成不变的相同意义的文件组成。通常服务器是由一组网页集合而成: 有欢迎页, 也许是含有表格的网页, 也许含有背景, 还有一些有个别的特殊数据。服务供给者在欢迎页上宣布各种服务。机器人并没有什么方法来区别这些网页,它可能发现一个链接比如一个数据或一个背景图像,这样编入索引中的文件并非是那些主要的页。这样的事情就能发生:机器人储存了关于"The Perl FAQ"的一些林乱子集的地址,而并非是它所涉及的内容。|如果在网络中网页之间没有链接,那么这个问题是可以被避免的。

以上问题描述的是网页内容是有特殊的意义的,仅仅依靠一个访问结构,而脱离的上下文,往往理解是错误的。例如一个网页描述了一个项目的目标可能是关于"The project",没有完整详细的名字,或给了一个链接到欢迎页的链接。另一个问题是已经删除的URL.通常系统管理员在重组织他们的URL结构时,他们会提供一个机制来向后兼容以前的URL结构,来防止坏链接。在一些服务器上,这个机制可能用重定向来实现,当用户访问旧的URL时HTTP返回一个新的URL个用户。然而符号链接不可能告诉机器人这些链接的不同。一个索引机器人会存储这些被反对的链接,系统管理员提供向后兼容的机制是产生这种情况的必要条件。

一个相关的问题是机器人可能会索引一个镜像,而不是原始站点。如果镜像和原始内容都访问了,则数据库就有了双份信息,并且带宽也会被重复获取而浪费。如果仅仅索引了镜像,那么用户所访问到的可能就不是最新更新的信息了。

规范

我们已经看到机器认识很有用得,但是它需要很高的带宽,并且他们在索引全球网时还有一些基本原则问题。因此一个机器人作者在开发和部署一个机器人时需要权衡这些问题。这已经成为一个伦理上的问题了“一个机器人的操作的花费对其他人是否是正当的?”。这是一个灰色的领域,人们对此有着广泛的争议。

当一些可接受争议最初变成事实后 (在一些机器人加倍服务器上的负荷的事件之後)开发机器人的作家揭露一组指导方针 [19],如一个第一步要识别问题而且促进理解。这些指导方针的概述如下所示:

重新考虑:你是否真的需要一个机器人;

责任:确定机器人能被服务器管理员识别,并且能够容易的联系作者;

在本地机器上测试;

适中的资源消耗:防止快速发射,消除多余的没必要的获取;

遵循机器人排斥标准;

监视操作:不断的察看机器人的日志;

共享成果: 使得器人原始成果或一些高级成果能被别的机器人共享

David Eichman [20]对服务器代理(这个机器人建立的基于面向公众的信息)和用户代理(这个机器人只是为了单一用户入客户端机器人)做了一个更深远的区别,并且已经从道德规范的角度作了高级的鉴别和区分。

事实上许多机器人的开发者已经处理了这些指导方针,并且渴望最小化这些影响。机器人邮件列表加速了这些新的问题的讨论,并且这些关于机器人的公众看法的活动邮件列表提供了一个有效的压制机器人的行为的团体[21]。

机器人领域的成熟意谓着会有更少的事情来扰乱的数据供给者。尤其机器人的排斥标准意谓着那些不允许机器人的人能阻止它的访问。然而,随着英特网的逐渐增加,特别在环球网上更多的机器人的出现是不可避免的,出现一些没有适当行为的机器人也是有可能的。

资源获取的两个可供选择的方法

机器人有望继续被用在因特网信息的获取上。然而,我们看到了在机器人的使用中会出现这些实际问题,基本原则问题和伦理问题,探究一些可供选择的方法是值得的,如ALIWEB [22]和Harvest [23].

ALIWEB有一个简单的模型来为人们在网上分布索引服务,基于Archie [24]。在这个模型中,索引信息的集合在网上任何主机上都有效。仅仅索引本地资源,而非第三方的资源。在ALIWEB上,这种模型使用了IAFA 模板 [25],这种模板的信息资源类型基于简单文本格式(见图2)。这种模板能被手工生成,或者自动创建,例如在一个文档树中列出标题和META元素。ALIWEB 的收集引擎通过普通的WEB访问协议来得到这些索引文件,并且把这些文件组合到一个可查询的数据库中。注意它不是一个机器人,它不是递归的得到文档来生成索引的。

Template-Type: SERVICE

Title: The ArchiePlex Archie Gateway

URL:

/public/archie/archieplex/archieplex.html

Description: A Full Hypertext interface to Archie.

Keywords: Archie, Anonymous FTP.

Template-Type: DOCUMENT

Title: The Perl Page

URL:

/public/perl/perl.html

Description: Information on the Perl Programming Language.

Includes hypertext versions of the Perl 5 Manual

and the latest FAQ.

Keywords: perl, programming language, perl-faq

图 2: 一个 IAFA 索引文件

这个方法有一些优点。人工建立索引的质量和自动更新的机制相结合。这种信息的集成远高于传统的“活动表” "hotlists",仅仅维护本地的索引信息。因为这些信息是计算机可读的格式,查找接口能够提供额外的方法来约束查询。仅得到索引信息,这样网络费用就非常少。模型和索引文件的简单使得信息提供者能够立刻参与。

这种方法有一些劣势。手工维护索引信息给信息提供者带来了巨大的负担,但好在实际中主服务器的索引信息不需要频繁的改动。从TITLE和META标记生成索引的系统已经在实验中,但是这将需要一个本地机器人,并且索引的质量是令人担忧的。另一个限制是当前的信息提供商不得不将它的索引信息文件在一个中央登记处注册,这就限制了可伸缩性。最后是更新的效率没有优化,当索引文件中仅仅一个记录改变了,也要被整个获取。

ALIWEB从1993年10月使用至今,它的成绩已经受到赞扬。主要操作的困难在于对其缺乏了解;最初人们经常试图去注册他们的自己的HTML文件而不是IAFA索引文件。另一个问题是ALIWEB作为一个个人项目它是运行在分时基础上的并且没有收到任何资金,因此发展比较缓慢。

Harvest 是一个分布式的资源探索的系统由Internet Research Task Force Research Group on Resource Discovery (IRTF-RD)发行,并提供了一个自动索引文档内容的软件系统,高效率的复制并储存远程主机上的索引信息,最后通过一个接口来查询这些数据。最初对这个系统的反应是很肯定的。

Harvest的一个不利条件是它是一个大而复杂的系统需要相当可观的人力和计算资源,这个劣势使得它离那些信息提供者很远。

Harvest的使用为交互式的现存数据库形成一个普通的平台大概是最令人激动的方面。Harvest非常直接的为其它系统提供了和它交互工作的平台;试验证明ALIWEB能作为Harvest的一个代理程序。这个机制给了ALIWEB储存和查找Harvest的功能,并提供Harvest一个低费用的入口机制。

在资源探索方面这两个系统作为机器人的替代品是非常吸引人的:ALIWEB 提供一个简单而高级的索引, Harvest提供了使用低级信息进行全面的索引系统。然而,没有一个系统是针对第三方的,是消极的参与,为此机器人将被期望继续在这个目的而使用,除了和其它系统合作的场合例如像ALIWEB 和 Harvest那样。

结论

在今天的万维网上,机器人被用来实现许多不同的目标,包括全球资源的探索。在机器人的应用中有一些应用的基本原则的和伦理有关的问题。随着机器人的增长应用的问题和伦理有关的问题已经作为一种经验,但是有可能会继续导致一些偶然的问题。基本原则的问题限制了机器人的发展。其他方法如ALIWEB和Harvest非常有效率,并能给作者一个管理自己站点索引信息的平台。我们期望这样的系统将流行起来,并将和机器人交互式工作。然而在很长的一段时间里机器人在环球网上遍历探索资源将变得非常缓慢,昂贵,并且效率低下。

参考

Ø Berners-Lee, T., R. Cailliau, A. Loutonen, H.F.Nielsen and A. Secret. "The World-Wide Web". Communications of the ACM, v. 37, n. 8, August 1994, pp. 76-82.

Ø Seeley, Donn. "A tour of the worm". USENINX Association Winter Conference 1989 Proceedings, January 1989, pp. 287-304.

Ø Gray, M. "Growth of the World-Wide Web," Dec. 1993. <URL: http://www.mit.edu:8001/aft/sipb/user/mkgray/ht/web-growth.html >

Ø Fielding, R. "Maintaining Distributed Hypertext Infostructures: Welcome to MOMspider's Web". Proceedings of the First International World-Wide Web Conference, Geneva Switzerland, May 1994.

Ø Berners-Lee, T., D. Conolly at al., "HyperText Markup Language Spacification 2.0". Work in progress of the HTML working group of the IETF. <URL: ftp://nic.merit.edu/documents/internet-drafts/draft-ietf-html-spec-00.txt >

Ø Luotonen, A., K. Altis. "World-Wide Web Proxies". Proceedings of the First International World-Wide Web Conference, Geneva Switzerland, May 1994.

Ø Eichmann, D. "The RBSE Spider - Balancing Effective Search against Web Load". Proceedings of the First International World-Wide Web Conference, Geneva Switzerland, May 1994.

Ø Berners-Lee, T., R. Fielding, F. Nielsen. "HyperText Transfer Protocol". Work in progress of the HTTP working group of the IETF. <URL: ftp://nic.merit.edu/documents/internet-drafts/draft-fielding-http-spec-00.txt >

Ø Spero, S. "Analysis of HTTP Performance problems" July 1994 <URL: http://sunsite.unc.edu/mdma-release/http-prob.html >

Ø Spero, S. "Progress on HTTP-NG". <URL: http://info.cern.ch/hypertext/www/Protocols/HTTP-NG/http-ng-status.html >

Ø De Bra, P.M.E and R.D.J. Post. "Information Retrieval in the World-Wide Web: Making Client-based searching feasable". Proceedings of the First International World-Wide Web Conference, Geneva Switzerland, May 1994.

Ø Spetka, Scott. "The TkWWW Robot: Beyond Browsing". Proceedings of the Second International World-Wide Web Conference, Chicago United States, October 1994.

Ø Slade, R., "Risks of client search tools," RISKS-FORUM Digest, v. 16, n. 37, Weds 31 August 1994.

Ø Riechen, Doug. "Intelligent Agents". Communications of the ACM Vol. 37 No. 7, July 1994.

Ø Pinkerton, B., "Finding What PEople Want: Experiences with the WebCrawler," Proceedings of the Second International World-Wide Web Conference, Chicago United States, October 1994.

Ø Koster, M., "A Standard for Robot Exclusion," < URL: http://www.robotstxt.org/wc/exclusion.html >

Ø McBryan, A., "GENVL and WWWW: Tools for Taming the Web," Proceedings of the First International World-Wide Web Conference, Geneva Switzerland, May 1994.

Ø Kent, R.E., Neus, C., "Creating a Web Analysis and Visualization Environment," Proceedings of the Second International World-Wide Web Conference, Chicago United States, October 1994.

Ø Koster, Martijn. "Guidelines for Robot Writers". 1993. <URL: http://www.robotstxt.org/wc/guidelines.html >

Ø Eichmann, D., "Ethical Web Agents," "Proceedings of the Second International World-Wide Web Conference, Chicago United States, October 1994.

Ø Koster, Martijn. "WWW Robots, Wanderers and Spiders". <URL: http://www.robotstxt.org/wc/robots.html >

Ø Koster, Martijn, "ALIWEB - Archie-Like Indexing in the Web," Proceedings of the First International World-Wide Web Conference, Geneva Switzerland, May 1994.

Ø Bowman, Mic, Peter B. Danzig, Darren R. Hardy, Udi Manber and Michael F. Schwartz. "Harvest: Scalable, Customizable Discovery and Access System". Technical Report CU-CS-732-94, Department of Computer Science, University of Colorado, Boulder, July 1994. <URL: http://harvest.cs.colorado.edu/>

Ø Deutsch, P., A. Emtage, "Archie - An Electronic Directory Service for the Internet", Proc. Usenix Winter Conf., pp. 93-110, Jan 92.

Ø Deutsch, P., A. Emtage, M. Koster, and M. Stumpf. "Publishing Information on the Internet with Anonymous FTP". Work in progress of the Integrated Internet Information Retrieval working group. <URL: ftp://nic.merit.edu/documents/internet-drafts/draft-ietf-iiir-publishing-02.txt >

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有