分類彙整: 网站应用

使用mod_headers或mod_expires实现缓存

实施这一方法将节省你难以置信数额的带宽，极大地加快你的网站为你的网站访客。基本上，对于图片，CSS ， JavaScript以及其他文件可以通过优化更快的下载，告诉你的网站访问者快取记忆体，为他们在某一段时间内。默认的行为是每一次请求检查文件的last-modified 和/或者 Etag headers。閱讀全文 →

面向站长和网站管理员的Web缓存加速指南[翻译]

2 則留言

这是一篇知识性的文档，主要目的是为了让Web缓存相关概念更容易被开发者理解并应用于实际的应用环境中。为了简要起见，某些实现方面的细节被简化或省略了。如果你更关心细节实现则完全不必耐心看完本文，后面参考文档和更多深入阅读部分可能是你更需要的内容。閱讀全文 →

基于反相代理的Web缓存加速——可缓存的CMS系统设计

發佈留言

作者：车东发表于：2003-06-06 17:06 最后更新于：2007-04-12 11:04
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明。
http://www.chedong.com/tech/cache.html

内容摘要：
对于一个日访问量达到百万级的网站来说，速度很快就成为一个瓶颈。除了优化内容发布系统的应用本身外，如果能把不需要实时更新的动态页面的输出结果转化成静态网页来发布，速度上的提升效果将是显著的，因为一个动态页面的速度往往会比静态页面慢2－10倍，而静态网页的内容如果能被缓存在内存里，访问速度甚至会比原有动态网页有2－3个数量级的提高。

动态缓存和静态缓存的比较
基于反向代理加速的站点规划
基于apache mod_proxy的反向代理加速实现
基于squid的反向代理加速实现
面向缓存的页面设计
应用的缓存兼容性设计：
HTTP_HOST/SERVER_NAME和REMOTE_ADDR/REMOTE_HOST需要用 HTTP_X_FORWARDED_HOST/HTTP_X_FORWARDED_SERVER代替

后台的内容管理系统的页面输出遵守可缓存的设计，这样就可以把性能问题交给前台的缓存服务器来解决了，从而大大简化CMS系统本身的复杂程度。
閱讀全文 →

WordPress 2.3 – 你必须知道的10件事

發佈留言

我们有一个传统，每次 WordPress 社区发布一个新的主要版本，我们都会探讨一些相关的内容。随着 WordPress 2.3 将在 2007年 9月 24日发布，我想依照我们的传统，让你知道一些我认为你应该知道的关于 WordPress 2.3 的事是比较适宜的。这里面有太多的内容，但我无法在本文中全部覆盖，因此如果你是一个开发人员，你应该去查看代码来指出你所发现的新的函数和功能。閱讀全文 →

对永久链接的一些更改

發佈留言

在wordpress中我原来设置的永久链接形式是使用日志的 ID 号(/archives/%post_id%),现在已经改变成/%year%-%monthnum%/%post_id%-%postname%.html了。另外启用了静态化。

参考:

车东的文章Blog的目录结构优化，以及Search Engine Friendly的URL设计

wordpress永久链接的说明

IPv6

3 則留言

　IPv6是Internet Protocol Version 6的缩写，其中Internet Protocol译为“互联网协议”。
　　IPv6是IETF（互联网工程任务组，Internet Engineering Task Force）设计的用于替代现行版本IP协议（IPv4）的下一代IP协议。
　　目前的全球因特网所采用的协议族是TCP/IP协议族。IP是TCP/IP协议族中网络层的协议，是TCP/IP协议族的核心协议。
　　目前IP协议的版本号是4（简称为IPv4），它的下一个版本就是IPv6。IPv6正处在不断发展和完善的过程中，它在不久的将来将取代目前被广泛使用的IPv4。
　　目前我们使用的第二代互联网IPV4技术，核心技术属于美国。它的最大问题是网络地址资源有限，从理论上讲，IPV4技术可使用的IP地址有43亿个，其中北美占有3/4，约30亿个，而人口最多的亚洲只有不到4亿个，中国只有3千多万个，只相当于美国麻省理工学院的数量。地址不足，严重地制约了我国及其他国家互联网的应用和发展。
　　随着电子技术及网络技术的发展，计算机网络将进入人们的日常生活，可能身边的每一样东西都需要连入全球因特网。但是与IPv4一样，IPv6一样会造成大量的IP地址浪费。准确的说，使用IPv6的网络并没有2^128-1个能充分利用的地址。首先，要实现IP地址的自动配置，局域网所使用的子网的前缀必须等于64，但是很少有一个局域网能容纳2^64个网络终端；其次，由于IPv6的地址分配必须遵循聚类的原则，地址的浪费在所难免。
　　但是，如果说IPV4实现的只是人机对话，而IPV6则扩展到任意事物之间的对话，它不仅可以为人类服务，还将服务于众多硬件设备，如家用电器、传感器、远程照相机、汽车等，它将是无时不在，无处不在的深入社会每个角落的真正的宽带网。而且它所带来的经济效益将非常巨大。
　　当然，IPv6并非十全十美、一劳永逸，不可能解决所有问题。IPv6只能在发展中不断完善，也不可能在一夜之间发生，过渡需要时间和成本，但从长远看，IPv6有利于互联网的持续和长久发展。目前，国际互联网组织已经决定成立两个专门工作组，制定相应的国际标准。
与IPV4相比，IPV6具有以下几个优势：
　　
　　一，IPv6具有更大的地址空间。IPv4中规定IP地址长度为32，即有2^32-1（符号^表示升幂，下同）个地址；而IPv6中IP地址的长度为128，即有2^128-1个地址。
　　二，IPv6使用更小的路由表。IPv6的地址分配一开始就遵循聚类（Aggregation）的原则，这使得路由器能在路由表中用一条记录（Entry）表示一片子网，大大减小了路由器中路由表的长度，提高了路由器转发数据包的速度。
　　三，IPv6增加了增强的组播（Multicast）支持以及对流的支持（Flow Control），这使得网络上的多媒体应用有了长足发展的机会，为服务质量（QoS，Quality of Service）控制提供了良好的网络平台。
　　四，IPv6加入了对自动配置（Auto Configuration）的支持。这是对DHCP协议的改进和扩展，使得网络（尤其是局域网）的管理更加方便和快捷。
　　五，IPv6具有更高的安全性。在使用IPv6网络中用户可以对网络层的数据进行加密并对IP报文进行校验，极大的增强了网络的安全性。
IPv6包由IPv6包头（40字节固定长度）、扩展包头和上层协议数据单元三部分组成。
　　IPv6包扩展包头中的分段包头（下文详述）中指名了IPv6包的分段情况。其中不可分段部分包括：IPv6包头、Hop-by-Hop选项包头、目的地选项包头（适用于中转路由器）和路由包头；可分段部分包括：认证包头、ESP协议包头、目的地选项包头（适用于最终目的地）和上层协议数据单元。但是需要注意的是，在IPv6中，只有源节点才能对负载进行分段，并且IPv6超大包不能使用该项服务。

　IPv6包头长度固定为40字节，去掉了IPv4中一切可选项，只包括8个必要的字段，因此尽管IPv6地址长度为IPv4的四倍，IPv6包头长度仅为IPv4包头长度的两倍。
　　其中的各个字段分别为：
　　Version（版本号）：4位，IP协议版本号，值= 6。
　　Traffice Class（通信类别）：8位，指示IPv6数据流通信类别或优先级。功能类似于IPv4的服务类型（TOS）字段。
　　Flow Label（流标记）：20位，IPv6新增字段，标记需要IPv6路由器特殊处理的数据流。该字段用于某些对连接的服务质量有特殊要求的通信，诸如音频或视频等实时数据传输。在IPv6中，同一信源和信宿之间可以有多种不同的数据流，彼此之间以非“0”流标记区分。如果不要求路由器做特殊处理，则该字段值置为“0”。
　　Payload Length（负载长度）：16位负载长度。负载长度包括扩展头和上层PDU，16位最多可表示65，535字节负载长度。超过这一字节数的负载，该字段值置为“0”，使用扩展头逐个跳段（Hop-by-Hop）选项中的巨量负载（Jumbo Payload）选项。
　　Next Header（下一包头）：8位，识别紧跟IPv6头后的包头类型，如扩展头（有的话）或某个传输层协议头（诸如TCP，UDP或着ICMPv6）。　
　　Hop Limit（跳段数限制）：8位，类似于IPv4的TTL（生命期）字段。与IPv4用时间来限定包的生命期不同，IPv6用包在路由器之间的转发次数来限定包的生命期。包每经过一次转发，该字段减1，减到0时就把这个包丢弃。
　　Source Address（源地址）：128位，发送方主机地址。
　　Destination Address（目的地址）：128位，在大多数情况下，目的地址即信宿地址。但如果存在路由扩展头的话，目的地址可能是发送方路由表中下一个路由器接口。
　　IPv6包头设计中对原IPv4包头所做的一项重要改进就是将所有可选字段移出IPv6包头，置于扩展头中。由于除Hop-by-Hop选项扩展头外，其他扩展头不受中转路由器检查或处理，这样就能提高路由器处理包含选项的IPv6分组的性能。
　　通常，一个典型的IPv6包，没有扩展头。仅当需要路由器或目的节点做某些特殊处理时，才由发送方添加一个或多个扩展头。与IPv4不同，IPv6扩展头长度任意，不受40字节限制，以便于日后扩充新增选项，这一特征加上选项的处理方式使得IPv6选项能得以真正的利用。但是为了提高处理选项头和传输层协议的性能，扩展头总是8字节长度的整数倍。
　　目前，RFC 2460中定义了以下6个IPv6扩展头：Hop-by-Hop（逐个跳段）选项包头、目的地选项包头、路由包头、分段包头、认证包头和ESP协议包头：
　　
　　（一）Hop-by-Hop选项包头包含分组传送过程中，每个路由器都必须检查和处理的特殊参数选项。其中的选项描述一个分组的某些特性或用于提供填充。这些选项有：
　　Pad1选项（选项类型为0），填充单字节。
　　PadN选项（选项类型为1），填充2个以上字节。
　　Jumbo Payload选项（选项类型为194），用于传送超大分组。使用Jumbo Payload选项，分组有效载荷长度最大可达4,294,967,295字节。负载长度超过65,535字节的IPv6包称为“超大包”。
　　路由器警告选项（选项类型为5），提醒路由器分组内容需要做特殊处理。路由器警告选项用于组播收听者发现和RSVP（资源预定）协议。

　　（二）目的地选项包头指名需要被中间目的地或最终目的地检查的信息。有两种用法：
　　如果存在路由扩展头，则每一个中转路由器都要处理这些选项。
　　如果没有路由扩展头，则只有最终目的节点需要处理这些选项。
　　
　　（三）路由包头
　　类似于IPv4的松散源路由。IPv6的源节点可以利用路由扩展包头指定一个松散源路由，即分组从信源到信宿需要经过的中转路由器列表。
　　
　　（四）分段包头
　　提供分段和重装服务。当分组大于链路最大传输单元（MTU）时，源节点负责对分组进行分段，并在分段扩展包头中提供重装信息。
　　
　　（五）认证包头
　　提供数据源认证、数据完整性检查和反重播保护。认证包头不提供数据加密服务，需要加密服务的数据包，可以结合使用ESP协议。
　　
　　（六）ESP协议包头
　　提供加密服务。

上层数据单元即PDU，全称为Protocol Data Unit。　　
　　PDU由传输头及其负载（如ICMPv6消息、或UDP消息等）组成。而IPv6包有效负载则包括IPv6扩展头和PDU，通常所能允许的最大字节数为65535字节，大于该字节数的负载可通过使用扩展头中的Jumbo Payload（见上文）选项进行发送。

对评论的一些更改

發佈留言

1.sidebar增加每月最活跃评论员名字及链接,每月自动更新。希望能鼓励读者们踊跃留言讨论。

2.评论去除了nofollow

删除了评论链接中的nofollow

發佈留言

注意:本文已经过期,为了防止spam 目前已经停用了dofollow。

本站删除了评论链接中的nofollow,对于旧的评论已经没有了nofollow！

当新评论发布时可能还会有该属性，但这个属性将在评论发布一段时候后移除(5天)。

nofollow 是 google 几年前提出的一个新属性，目的是减少垃圾留言。此标签相当于告诉搜索引擎，“该链接所指向的网页非我所能控制，对其内容不予置评”，或者简单地说，该链接不是对目标网站或网页的“投票”。这样，搜索引擎在计算目标的网站的Link Popularity时，将会把这个链接排除在外。

目前主流的 Blog 程序，如 WordPress 和 MovableType，均默认为其留言与 trackback 中的链接自动添加 nofollow 属性。

本站为什么去除nofollow

nofollow 属性是为了减少垃圾留言而诞生，但是许多人认为 nofollow 并没有真正解决 Blog 的垃圾留言问题。因为现在的垃圾留言都是机器人生成的，它们不会因为你加了 nofollow 而忽视你

2. 为了评论者，引用者，为了自己。nofollow=不相信。对于留言中的 nofollow 来说，读者帮助你建设了 Blog，你却对搜索引擎说，“我不相信这个读者的评论”，这对评论者不公。对于 Trackback 中的 nofollow 来说，别人在自己的文章中链接了你，给你的链接是没有 nofollow 的，你却回敬人家一个 nofollow，这对引用者不公。而且去掉了 nofollow，会让读者更踊跃的来你的博客中评论、留言，增加了博客的人气。

小心：中国黑客利用贝·布托死讯传毒

發佈留言

　巴基斯坦前总理贝·布托夫人被刺杀不到12个小时，黑客即开始利用这一热点事件进行病毒传播。瑞星公司例行的网络监测发现，用Google引擎搜索”Benazir Bhutto”，排行第三的某英文网站已经证实被植入两个病毒，分别名”Hack.Explolt.Script.JS.Realplayer.b”和”Trojan.DL.Script.JS.Agent.lmj”，用户浏览该网站后就会中毒，中毒电脑会从网上自动下载其它病毒，并且Google自身的安全检测系统没有显示病毒警示信息。

　　据瑞星反病毒专家介绍，该网站利用了前不久公布的Realplayer媒体播放器的漏洞，很多用户还没来得及打好相应的补丁。由于布托夫人遇刺已经成为全球关注的焦点，很多用户将通过Google等搜索引擎搜索观看相关资讯，预计将有大量的用户因此染毒。据了解，带毒网站在雅虎等引擎的排名也非常高。

　　据专家分析，由病毒的编写手法、来源网站、木马植入方式、病毒的危害对象等来看，此带毒网站可能与中国黑客有关。但是，由于在搜索引擎上搜索布托夫人英文名字的主要是国外人士，并且该网站在百度等国内搜索引擎的排名并不高，因此对中国用户的危害相应较弱。专家还没有更多的证据，无法知道此网站是被黑客攻击而植入病毒，还是纯粹由黑客设立的钓鱼网站。

　　利用政治事件、娱乐热点传播病毒，已经成为国内黑客惯常使用的手法，对于此类病毒的防御措施，瑞星反病毒专家介绍说，用户应该安装并及时升级自己的杀毒软件，上网的时候开启即时监控功能，并尽量利用瑞星2008版集成的主动防御功能加固自己的电脑系统。

DNS and BIND

發佈留言

我转载的评价：
本书是介绍bind和dns的权威书籍，由于市面上介绍bind和dns的书比较少，所以本书的
份量也就更重了。本书从dns的基本概念到dns的实现程序bind都作了详细的介绍。如果
你是dns的维护人员，应该通读这本书。如果你想了解一下dns的概念和bind程序的基本
应用，这本书也提供的大量的相关知识。不同层次的人员可根据自已的实际情况选读相关章
节。由于我应用dns只是在局域网内做一下名字解析，应用较浅，所以我只挑了个别章节看
了一下，没有深入dns的高级部份，所以读书笔记也就只包含这部分的内容了。

第一章背景
dns是针对ARPnet的特殊问题发展起来的，在整个20世纪70年代，ARPnet还是一个
有几百台主机的很小很友好的网络。仅仅需要一个名为HOSTS.TXT的文件就能容纳所有需
要了解的主机信息。该文件由SRI(Stanford Research Institute的前身)的网络信息中心
（Network Information Center NIC)负责维护，并从一台主机SRI-NIC上分发到整个网络。
ARPnet的管理员通常定期通过电子邮件的方式将他们的变更通知SRI，同时还定期ftp到
sri-nic，以获取最新的HOSTS文件。但随着ARPnet的增长，这种方法行不通了。流量和负
载使SRI的线路不堪重负；名字冲突，造成网络混乱；在不断扩张的网络上要维护文件的
一致性变得越来越难。关键问题是HOSTS文件的结构不是很好，最终导至了hosts文件的
失败和落伍。
ARPnet的管理者们开始投入研究，为HOSTS.TXT文件寻求继任者。Paul Mockapetris，
当时在南加州大学的信息科学所，负责设计新系统的体系架构。1984年，他发布了描述DNS
的RFC882和RFC883。后来它们被RFC1034和RFC1035所取代，也就是目前的DNS规范。
目前，还有很其它RFC补充RFC1034和RFC1035的内容，它们描述了DNS的安全问题，
实现问题，管理问题等。

DNS 简述
实际上，DNS是一个分布式数据库，它允许对整个数据库的各个部份进行本地控制；同时
整个网络也能通过客户-服务器方式访问每个部份的数据。借助备份和缓存机制，DNS将具
有强壮性和足够的性能。DNS的数据库结构同unix文件系统的结构非常相似，就像一棵倒
着的树。

第二章 DNS是如何工作的
介绍了DNS的工作原理，一些功能和名词。

第三章如何开始工作
获是bind软件
选择一个域名

第四章建立BIND
建立区数据，包括正向解析文件（名字到地址的映射），反向解析文件（地址到名字的映射）。
每个网络都有包含它自已的反向映射数据文件。名字服务器用named.conf配置文件把所有
的区数据文件绑定在一起。

区数据文件
区数据文件中的大部份条目被称为DNS资源记录。DNS查找是不区分大小写的，但大写是
被系统保留的，建议用小写。资源记录必须从一行的第一列开始。在DNS RFC中，表示资
源的记录是按特定顺序排列的，但这不是必须的。顺序如下：
SOA记录指示该区的权威
NS记录列出该区的一个名字服务器
A 名字到地址的映射
PTR 地址到名字的映射
CNAME 规范名字（相对于别名而言）

注释是以“；”号开始的

设置区默认的TTL值。
在8.2版本前，SOA记录中最后一个字段设置区默认的TTL值。在8.2版出来前，公布了
RFC2308,将SOA记录中最后一个字段的含义改为了“否定缓存TTL”，它的意思是一个远
程名字服务器能将区的否定响应缓存多长时间，否定响应是报告某个域名或某个域名的某个
数据类型不存。8.2版及后继版中用$TTL控制语句。名字服务器在查询响应中提供这个值，
允许其它服务器将数据在缓存中存放TTL所指定的时间。如果数据不是经常变动的，可以
考虑把它的值设为几天，1周大概是使之有意义的最大值。1小时会引起不必要的DNS流量。
如：$TTL 3h

SOA记录
表示对于该区数据而言，这个名字服务器是最好的信息来源。根据这个SOA记录，我们的
名字服务器就享有对该区的权威。
movie.edu IN SOA terminator.movie.edu. al.robocop.movie.edu. (
1 ;序列号
3h ;3小时后刷新
1h ;1小时后重试
1w ;1周后期满
1h) ;否定缓存TTL为1小时
IN 代表Internet类
terminator.movie.edu. 代表主名字服务器
al.robocop.movie.edu. 把第一个点号换成@,代表邮件地址，对电脑没意义，只对人有意义

在反解文件的头几行也添加类似的SOA记录。在这些文件中把movie.edu改为
249.249.192.in-addr.arpa

NS记录
在文件中添加的下一条记录是NS记录。这些记录表明区movie.edu有两个名字服务器。这
些名字服务器运行在主机terminator.movie.edu and wormhole.movie.edu上。
movie.edu IN NS terminator.movie.edu
movie.edu IN NS wormhole.movie.edu
同SOA记录一样，也在反解文件中添加记录

地址和别名记录
接下来创建名字到地址的映射
；主机地址
localhost.movie.edu. IN A 127.0.0.1
robocop.movie.edu. IN A 192.249.249.2
terminator.movie.edu. IN A 192.249.249.3
misery.movie.edu. IN A 192.249.253.2
;
;多宿主主机
wormhole.movie.edu. IN A 192.249.249.1
wormhole.movie.edu. IN A 192.249.253.1
;
;别名
bigt.movie.edu. IN CNAME terminator.movie.edu.
wh.movie.edu. IN CNAME wormhole.movie.edu.
wh249.movie.edu IN A 192.249.249.1
wh253.movie.edu IN A 192.249.253.1
像bigt.movie.edu这样的别名不能出现在资源记录的右边。换名话说，在资源记录的数据部
份总是要使用规范名（terminator.movie.edu）。
如果一台主机是多宿主的（具表不止一个网络接口），让每个接口对应一个唯一的别名，再
为这个别名创建一个地址（A）记录，为每个对所有地址都通用的别名创建一个CNAME记
录。能否在所有情况下都使用地址记录而不用CNAME记录呢？大部份程序是可以的，但
sendmail会有问题。sendmail通常用规范名替换邮件首部中所有使用的别名，只有当邮件首
部中的名字有相关的CNAME记录时才进行这种规范化。如果你的别名没有对应的CNAME
记录，你的SENDMAIL就必须知道你的主机所有可能为外界所知的别名，这就要求你对
SENDMAIL进行一些额外的调整。

PTR记录
创建地址到名字的映射，使用PTR资源记录
1.249.249.192.in-addr.arpa. IN PTR wormhole.movie.edu.
2.249.249.192.in-addr.arpa. IN PTR robocop.movie.edu.
3.249.249.192.in-addr.arpa. IN PTR terminator.movie.edu.
对于192.249.253/24也创建类似的数据。

需要设置回送网络的正反解文件。如果没有则查找127.0.0.1就会失败。

根线索（root hint）数据。从ftp.rs.internic.net里上载。

建立BIND配置文件
从版本4到版本8，BIND配置文件的语法变化非常大，版本8到版本9没有变化。可以通
过运行named-bootconf程序把版本4的配置文件转换成版本8的文件。这个程序随BIND源
码一起发布。

h2n工具是一个PERL脚本，用来把HOSTS文件转换成区数据文件。

运行名字服务器
#named

设置本地域名，这样可以直接查找主机名而不用加上域名。有两种方法设置：hostname or
/etc/resolv.conf。在resolv.conf的第一行加入domain movie.edu。或者在terminator主机上
把hostname设置为terminator.movie.edu。不要在名字后加点号。

用远程的名字服务器来查找你的区中的域名,把本地域名作为第一个参数，远程名字服务器
作为第二个参数。如果失败，可能是你的区还没有向你的父名字服务器注册。需与父域管理
员联系，检查区授权。
# nslookup carrie getekeeper.dec.com

运行辅名字服务器
需要再建立一个名字服务器以增强DNS的健壮性。以便分担负荷和容错。在named.conf文
件中定义是主还是辅服务器。主要区别是主名字服务器从区数据文件中读取数据，辅服务器
是通过网络从其它的名字服务器装载数据的，这个过程称为“区传送”（zone transfer）。

建立
在辅名字服务器建立区数据文件目录（/etc/named），并把named.conf,named.root,db.127.0.0
这三个文件拷贝过来。修改配置文件，把域的master改为slave,然后添加一个带主服务器ip
地址的masters行。例如：
zone “movie.edu” in {
type master;
file “db.movie.edu”;
};
改为
zone “movie.edu” in {
type slave;
file”bak.movie.edu”; 如果不想在辅名字服务器上保存区数据文件的备份，可以删除这
行。
masters {192.249.249.3};
};

SOA值
序列号：格式为yyyymmddnn，nn代表这一天是第几次修改。在每次更新了你的区数据后
不要忘了增加序列号的值。辅名字服务器通过比较这个序列号是否加载一份新的区数据拷
贝。
refresh（刷新）：告诉该区的辅名字服务器相隔多久检查该区的数据是否是最新的。
retry（重试）：如果辅名字服务器超过刷新间隔时间后无法访问主服务器，那么它就开始隔
一段时间重试连接一次。这个时间通常比刷新时间短，但也不一定非要这样。
expire（过期或期满）：如果在期满时间内辅名字服务器还不能和主服务器连接上，辅名字服
务器就使用这个我失效。这就意味着辅名字服务器将停止关于该区的回答，因为这些区数据
太旧了，没有用了。设置时间要比刷新和重试时间长很多，以周为单位是较合理的。
否定缓存TTL（生存期）：这个值对来自这个区的权威名字服务器的否定响应都适用。
新版的bind的时间设置灵活了很多，以前只接收以秒为单位（一周有608400秒）。现在可
以用h（小时）,d（天）,w（周）表示。
RFC1537建议顶级名字服务器采用以下值：
refresh 24h
retry 2h
expire 30d
否定缓存ttl 4d
新版8，9改变了区数据传播的方式，轮询的特性还在，但增加了当区数据改变后进行通知
的功能，在15分钟之内通知辅名字服务器，要加载该区的一份新的拷贝了。

多个主服务器
可配置最多十个主名字服务器，以分号分隔。辅名字服务器会依序尝试每个IP地址对应的
主服务器。一直到收到回答为止。但从8.2以后，辅服务器会查询所有的主服务器，从具有
最高序列号的服务器那里传送区数据。

第五章 DNS与电子邮件
DNS与主机表相比的一个优势在于支持高级邮件路由。当邮件收发器只用HOSTS文件工作
时，所能做的最多也就是试着把邮件直接发送到主机的IP地址，如果失败，要么延迟发送，
过一会再重试，要么就将邮件退回给发送者。dns提供一种机制，能为邮件的发送者指定备
份主机，它还允许一台主机为别的主机承担邮件处理任务。
DNS用一种资源类型来实现增强的邮件路由，那就是MX记录。它为一个域名指定一个邮
件交换器。它是一台主机，负责处理或转发该域名的邮件。还定义了一个优先级值，它决定
了邮件收发器使用它们顺序，优值小的先使用。
peets.mpk.ca.us. IN MX 10 relay.hp.com 指定relay.hp.com是peets.mpk.ca.us的邮件交
换器，优先级是10

第六章配置主机
reslov.conf中有五个命令可你使用，domain,search,nameserver,sortlist,options。
domain定义本地域名，从第一行开始，后跟一个空格，然后是本地域名，本地域名后面不
要有点号。
例如：domain movie.ecu
LOCALDOMAIN环境变量也可以设置每个用户的本地域名。
建议使用hostname设置。

search指令
search corp.hp.com paloalto.hp.com hp.com
解析器会首先搜索corp.hp.com，然后是paloalto.hp.com，再是这两个域的父域hp.com。

nameserver指令
默认地，解析器首先查找本地上的名字服务器，也可以通过该指令指示解析器去使用其它主
机的域名服务器。
nameserver 15.32.17.2
nameserver 15.32.17.3 （可指定多个服务器）
注意：在多个nameserver的情况下不要使用回送地址。

sortlist指令
当查询收到的响应包括多个地址时，该设置允许你选择更希望使用的子网和网络。
sortlist 128.32.42.0/255.255.255.0 最多可指定十个优先的子网和网络。

options指令
options debug 设置RES_DEBUG,在标准输出上产生大量调试数据。前提是在编译BIND时
定义了DEBUG参数。
options ndots:2 如果域名参数中的点号大于或等于这个值，那么解析器会在使用搜索列表
之前，先查找这个域名。如果你相信你的用户更有可能输入部份域名而需要使用搜索列表时，
你可以增加这个值。
8.2版引入以下选项
options attempts:2 允许你指定在放弃之前向resolv.conf文件中每个名字服务器发送查询的
次数。
options timeout:2 指定每个对resolv.conf文件中名字服务器的查询的初始超时时间。默认为
5，最大为30。对第二轮以及接下来的几轮查询，解析器会把初始超时时间加倍。再除以
resolv.conf中文件服务器的数量。
options rotate 使你的解析器能使用resolv.conf文件中所有的名字服务器。从而分散负载。默
认只要第一台服务器正常，解析器是不会去查询其它服务器。
options no-check-names 关掉解析器的名字检查功能，默认是打开的。它检查响应的域名是
否合法。
如果你想指定多个选项，可以把它们写成一行：
options attempts:4 timeout:2 ndots:2

第七章维护BIND
BIND9与8一样，也用controls来决定服务器如何监听控制信息的。
controls {
inet * allow {any;} keys {“rndc-key”}
};
这决定了rndc用户要用什么加密密钥来验证身份才能给服务器发送控制信息。如果没有指
定keys，服务器启动时会出错
key “rndc-key” {
algorithm hmac-md5;
secret “xxxxx”;
};
为安全起见，使用包括文件：
include “/etc/rndc.key”。唯一支持的算法是HMAC-MD5。
要使用rndc，你需要创建一个rndc.conf文件告诉rndc要用哪个认证密钥。而哪些名字服务
器要使用它们。
options {
default-server localhost;
default-key “rndc-key”;
};

key “rndc-key” {
algrithm hmac-md5;
secert “xxxxx”;
};

更新区数据文件，两种方法，手工或 h2n。

重新开始一个SOA序列号。改变主服务器序列号，重启，停止辅服务器，删除所有备份区
数据文件。因为备份文件被删除，所以辅服务器就会加载一个新的区数据文件，这个区数据
文件就是最新的。

TXT
xxx IN TXT “this is a test” 限制2K字符串数据

RP 负责人邮件地址
robocop IN RP root.movie.edu

组织文件
当域大的时候，区数据文件就会越来越多，有两个命令可以帮助我们组这些文件:
$ORIGIN 改变一个区数据文件的起点
$INCLUDE 在当前区数据文件中插入一个新文件

改变系统文件的位置，主要是从安全角度考虑。
options {pid-file “server1.pid”;} 改变PID的文件名，可以在一台主机上运行两个名字服务
器。
options {named-xfer “/HOME/….”;} 在9版中没有这个文件。
options {dump-file “/home/yangjing/named/named_dump.db”;} 服务器转储数据库
options {statistics-file “/home/yangjing/named/named.stats”;} 服务器统计数据

日志
有七个级别,允许存在文件中或伸用syslog日志系统。
critical
error
warning
notice
info
debug [level] dns服务器特有
dynamic dns服务器特有

语法如下：
logging {

[ channel channel_name {

( file path_name

[ versions ( number | unlimited ]

[ size size_spec ]

local0 | local1 | local2 | local3 |

local4 | local5 | local6 | local7

| null ;

[ severity ( critical | error | warning | notice |

info | debug [ level ] | dynamic ; ]

[ print-category yes_or_no; ]

[ print-severity yes_or_no; ]

[ print-time yes_or_no; ]

}; ]

[ category category_name {

channel_name; [ channel_name; … ]

}; ]

…

};

example:

logging {
channel my_syslog {
syslog daemon;
severity info;
};
channel my_file {
file “my_named.log” versions 3 size 10k;
severity dynamic;
print-category yes; 在日志中输出附加信息：消息类别，严重性，时间。
print-severity yes;
print-time yes;
};
category default {unll;}; 如果对于某个类别你没有指定任何通道，那么就会把这些消息发
送到default类所分配的通道中。
category statistics {my_syslog;my_file;};
category queries {my_file;};
};

要记录这些日志，还要再打开名字服务器的调试功能。
#rndc trace
versions 3 文件版本，会保存file，file.0,file.1,file.2，如果不设置将有99个版本。在服务
器启动和重新加载时将file.1-file.2,file.0-file.1,file-file.0。
size 10k 文件的大小限制。

default_stderr通道可把信息写到服务器的stderr中。

null通道可以用来丢弃不想要的信息。

bind9类别
general 包括所有未明确分类的信息。
client 处理客户端请求
config 配置文件分析和处理
database 数据库相关信息
dnssec 处理DNSSEC签名响应
lame-servers 发现错误授权
network 网络操作
notify 异步区变动通知
queries 查询日志
resolver 名字解析，包括对来自解析器的递归查询的处理
security 认可/非认可的请求
update 动态更新事件
xfer-in 从远程名字服务器到本地服务器的区传送
xfer-out 从本地到远程的区传送

第八章扩展你的域

第九章担当父域

第十章高级特性
新版BIND8.1.2 9.10有大量的新特性，其中最突出的是支持DNS动态更新，异步区变动通
知（NOTIFY)，以及增量区传送。

地址匹配列表和ACL
acl name {address_match_list;}; 定义一个列表，以后可用name引用
acl “hp-net” {192.168.1.192/26;};
有四个预定义的列表：none，没有任何IP地址；any，所有IP地址；localhost，本地主机的
任一IP地址；localnets，本地主机任一网络接口所在的网络。

第十一章安全
限制查询 allow-query{}
防止未授权的区传送 allow-transfer{}
以最小权限运行bind，-u 以该用户运行， -g 以该组运行，-t 使用chroot()转到的目录。
使用chroot步骤见书例子。

第十二章 nslookup and dig

星星百科

發佈留言

前几天新注册了个pcxingxing.org.ru,现在wiki已经安装完成了。

点此访问星星百科

各大网站域名服务器测评

發佈留言

1、 Sina.com.cn

http://www.dnsstuff.com/tools/dnsreport.ch?domain=sina.com.cn

Parent

INFO NS records at parent serversYour NS records at the parent servers are: ns2.sina.com.cn. [61.172.201.254 ] [TTL=21600] [CN]
ns3.sina.com.cn . [202.108.44.55] [TTL=21600] [CN]
ns1.sina.com.cn. [202.106.184.166] [TTL=21600] [CN]
[These were obtained from cns.cernet.net]

NS INFO Nameservers versions Your nameservers have the following versions: 61.172.201.254: No version info available (refused).
202.108.44.55: No version info available (refused).
202.106.184.166: No version info available (refused).

SOA

WARN SOA Serial NumberWARNING: Your SOA serial number is: 5. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.

WARN SOA MINIMUM TTL valueWARNING: Your SOA MINIMUM TTL is : 600 seconds. This seems low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级：中

Sina.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=sina.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are: ns1.sina.com.cn. [ 202.106.184.166 (NO GLUE)] [CN]
ns2.sina.com.cn. [61.172.201.254 (NO GLUE)] [CN]
ns3.sina.com.cn. [202.108.44.55 (NO GLUE)] [CN]
[These were obtained from l.gtld-servers.net]

WARN Glue at parent nameservers

WARNING. The parent servers (I checked with l.gtld-servers.net.) are not providing glue for all your nameservers. This means that they are supplying the NS records ( host.example.com), but not supplying the A records (192.0.2.53), which can cause slightly slower connections, and may cause incompatibilities with some non-RFC-compliant programs. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of ” ns1.example.org” for the domain “example.com“). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain.

WARN Nameservers on separate class C’s

WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.

INFO Nameservers versionsYour nameservers have the following versions: 202.106.184.166: No version info available (refused).
61.172.201.254 : No version info available (refused).
202.108.44.55: No version info available (refused).

WARN Nameservers on separate class C’s

SOA WARN SOA MNAME Check

WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: sina.com. . However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 900 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA MINIMUM TTL value

WARNING: Your SOA MINIMUM TTL is : 300 seconds. This seems low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级：低

2、 sohu.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=sohu.com

Parent

INFONS records at parent serversYour NS records at the parent servers are:dns.sohu.com. [61.135.131.86] [TTL=172800] [CN]
ns1.sohu.com. [61.135.131.1] [TTL=172800] [CN]
ns3.sohu.com. [220.181.26.168] [TTL=172800] [CN]
[These were obtained from a.gtld-servers.net]

WARN Single Point of Failure

WARNING: Although you have at least 2 NS records, and they appear to point to different physical servers, it appears that they block the ICMP packets used as part of our test, which means that they may share the same firewall. If they share the same firewall, this results in a single point of failure, which could cause all your DNS servers to be unreachable.

INFO Nameservers versionsYour nameservers have the following versions:61.135.131.86: ” ”
61.135.131.1: ” ”
220.181.26.168: ” ”

SOA

FAILSOA MINIMUM TTL value

WARNING: Your SOA MINIMUM TTL is : 60 seconds. This seems very low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.

规范等级：高

3、163.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=163.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are:ns.nease.net. [202.106.185.75] [TTL=172800] [CN]
ns3.nease.net. [220.181.28.3] [TTL=172800] [CN]
[These were obtained from a.gtld-servers.net ]

INFO Nameservers versions Your nameservers have the following versions: 202.106.185.75: “9.2.3”
220.181.28.3: “9.2.3”

SOA

FAILNS agreement on SOA Serial #

ERROR: Your nameservers disagree as to which version of your DNS is the latest (20011937 versus 20011938). This is OK if you have just made a change recently, and your secondary DNS servers haven’t yet received the new information from the master. I will continue the report, assuming that 20011938 is the correct serial #. The serial numbers reported by each DNS server are:
202.106.185.75: 20011938
220.181.28.3: 20011937

WARN SOA Serial Number

WARNING: Your SOA serial number is: 20011938. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.

规范等级：中

nease.net

http://www.dnsstuff.com/tools/dnsreport.ch?domain=nease.net

Parent

INFO NS records at parent serversYour NS records at the parent servers are: ns.nease.net. [202.106.185.75] [TTL=172800] [CN]
ns3.nease.net. [220.181.28.3] [TTL=172800] [CN]
[These were obtained from j.gtld-servers.net]

INFO Nameservers versions Your nameservers have the following versions: 202.106.185.75: “9.2.3”
220.181.28.3: “9.2.3”

SOA

WARN SOA Serial Number

WARNING: Your SOA serial number is: 991160. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 3600000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级：中

4、 tom.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=tom.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are: brown.hutchcity.com. [202.45.84.67] [TTL=172800] [HK]
edns.wyith.net. [202.181.240.44] [TTL=172800] [HK]
ns1.tom.com. [61.135.159.46] [TTL=172800] [CN]
ns2.tom.com. [61.135.159.47] [TTL=172800] [CN]
[These were obtained from f.gtld-servers.net ]

FAILOpen DNS servers

ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn’t happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are: Server 202.45.84.67 reports that it will do recursive lookups. [ test] Server 202.181.240.44 reports that it will do recursive lookups. [ test] Server 61.135.159.46 reports that it will do recursive lookups. [ test] Server 61.135.159.47 reports that it will do recursive lookups. [test] See this page for info on closing open DNS servers.

FAIL Lame nameservers

ERROR: You have one or more lame nameservers. These are nameservers that do NOT answer authoritatively for your domain. This is bad; for example, these nameservers may never get updated. The following nameservers are lame:
202.45.84.67

FAIL Missing nameservers 2

ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are:
brown.hutchcity.com.
edns.wyith.net.

WARN All nameservers report identical NS records

WARNING: Your nameservers report somewhat different answers for your NS records (varying TTL, for example).

INFO Nameservers versions Your nameservers have the following versions: 202.45.84.67: “8.3.4-REL”
202.181.240.44: “4.9.6-REL”
61.135.159.46: “TOM.COM DNS Server 2.00″
61.135.159.47 : “TOM.COM DNS Server 2.00″

规范等级：低

5、qq.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=qq.com

Parent

INFO NS records at parent serversYour NS records at the parent servers are:dns1.imok.net. [219.133.40.202] [TTL=172800] [CN]
dns2.imok.net. [61.152.100.5] [TTL=172800] [CN]
[These were obtained from e.gtld-servers.net ]

WARN Single Point of Failure

WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.

INFO Nameservers versions Your nameservers have the following versions: 219.133.40.202: “9.3.2”
61.152.100.5: “9.3.0rc4”

SOA

WARN SOA MNAME Check

WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: qq.com.. However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 300 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 86400 seconds. This seems a bit low. You should consider increasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级：低

Imok.net

http://www.dnsstuff.com/tools/dnsreport.ch?domain=imok.net

Parent

WARN Single Point of Failure

INFO Nameservers versions Your nameservers have the following versions: 219.133.40.202: “9.3.2”
61.152.100.5: “9.3.0rc4”

SOA

WARN SOA MNAME Check

WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: imok.net. . However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.

WARN SOA REFRESH value

WARNING: Your SOA REFRESH interval is : 360 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.

WARN SOA EXPIRE value

规范等级：低

6、 baidu.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=baidu.com

Parent

INFONS records at parent serversYour NS records at the parent servers are:dns.baidu.com. [202.108.250.228] [TTL=172800] [CN]
ns2.baidu.com. [202.108.249.147] [TTL=172800] [CN]
ns3.baidu.com. [220.181.27.61] [TTL=172800] [CN]
ns4.baidu.com. [220.181.27.62] [TTL=172800] [CN]
[These were obtained from m.gtld-servers.net]

FAIL Missing (stealth) nameservers

FAIL: You have one or more missing (stealth) nameservers. The following nameserver(s) are listed (at your nameservers) as nameservers for your domain, but are not listed at the parent nameservers (therefore, they may or may not get used, depending on whether your DNS servers return them in the authority section for other requests, per RFC2181 5.4.1). You need to make sure that these stealth nameservers are working; if they are not responding, you may have serious problems! The DNS Report will not query these servers, so you need to be very careful that they are working properly. ns1.baidu.com.
This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example).

WARN TCP Allowed

WARNING: One or more of your DNS servers does not accept TCP connections. Although rarely used, TCP connections are occasionally used instead of UDP connections. When firewalls block the TCP DNS connections, it can cause hard-to-diagnose problems. The problem servers are: 202.108.249.147: Error [No response to TCP packets].

220.181.27.61: Error [No response to TCP packets]. 220.181.27.62: Error [No response to TCP packets].

WARN Single Point of Failure

INFO Nameservers versions Your nameservers have the following versions: 202.108.250.228: “diy by bind”
202.108.249.147: “9.2.1 ”
220.181.27.61: “9.2.1”
220.181.27.62: “9.2.1”
FAIL Stealth NS record leakage

Your DNS servers leak stealth information in non-NS requests:
Stealth nameservers are leaked [ns1.baidu.com.]!This can cause some serious problems (especially if there is a TTL discrepancy). If you must have stealth NS records (NS records listed at the authoritative DNS servers, but not the parent DNS servers), you should make sure that your DNS server does not leak the stealth NS records in response to other queries.

SOA

WARN SOA REFRESH value

WARN SOA EXPIRE value

WARNING: Your SOA EXPIRE time is : 2592000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.

规范等级：中

7、 google.com

http://www.dnsstuff.com/tools/dnsreport.ch?domain=google.com

Parent

INFO NS records at parent servers Your NS records at the parent servers are: ns1.google.com. [216.239.32.10] [TTL=172800] [US]
ns2.google.com. [216.239.34.10 ] [TTL=172800] [US]
ns3.google.com. [ 216.239.36.10] [TTL=172800] [US]
ns4.google.com . [216.239.38.10] [TTL=172800] [US]
[These were obtained from k.gtld-servers.net]

INFO Nameservers versions Your nameservers have the following versions: 216.239.32.10: No version info available (refused).
216.239.34.10: No version info available (refused).
216.239.36.10: No version info available (refused).
216.239.38.10: No version info available (refused).

SOA

FAILSOA MINIMUM TTL value

规范等级：中

http://blog.pcstars.tk/2007/11/blog-post_09.html

hosting has been shutdown

發佈留言

今天发现服务器当机了，并且有好几天了，现在已经修复了

每个 Web 站点都必需的十余个文件

發佈留言

原文链接: http://www.ibm.com/developerworks/cn/web/wa-webfiles/index.html

David Mertz, Ph.D ([email protected]), Old Schooler, Gnosis Software, Inc.

2007 年 9 月 24 日

不管开发 Web 站点所用的是何种内容管理系统或 Web 应用程序框架，都应该涵盖一些基本要素。能提供精致的用户界面和丰富的内容固然很棒，但在那之前，首选应该提供用户能查找到并能明了地表达该站点用途的基本文件。

引言

有几个标准的文件是每个 Web 站点都必需的，但在很多时候它们却会被站点忽略。大多数这种文件都与约定有关，而非技术上的要求，但如果不能提供这些文件，就会使站点创建误入歧途。除了 URL 可以通过猜想尝试得到，通常用户很难通过猜想找到其他想要的东西。本文将对这些标准文件逐一简述。

给定的资源究竟如何提供决定于所使用的 Web 服务器层和 Web 应用程序层。在诸如 Apache 这类 “传统” 的、接近静态的服务器内，这些资源很可能就是服务器上的文字文件。但在不同的配置中，它们也有可能是数据库中的某些条目、配置文件中的某些行、服务器进程中的某些类等。本文重点放在用户最终所见之上，而非该如何让其发生。

404.html

当用户使用您的 Web 站点，他们不可避免地都会找寻一些不存在的资源。比起其他原因，这类寻找更多地是由于 URL 的拼写错误而致，但链接过时、后端的错误配置、不同点的 URL 残缺等因素也不容小觑。当资源不可用时，一个很好的做法是提供某种回转页面以协助用户导航到其他有用的页面。一个普通的 “没有找到” 虽然可以让用户知道资源不可用，但却无法帮助他们解决 “下一步如何做” 的问题。

警告：在创建定制的 404.html（或 Web 服务器用来发布定制 “没有找到” 消息的任何其他机制）时，太多的 Web 站点都会被错误地配置成发送 “soft 404” 消息。换句话说，它们会发送一个带常规的 “200 OK” 标题的页面，这仅仅说明了文本的某个地方“不可用”，也许还提到（但不经常）此处有 “404 Error”。应该避免这样做。相反，应该让用户（和他们的 Web 浏览器以及其他工具）省些事，使用确切的状态标题。

about.html

那么，究竟为何要创建 Web 站点呢？没错，需要用一个首页来回答这个问题。但更可能的情况是，首页并不提供这类信息，而只是让用户能够登录、突出站点的 “卖点”、显示某些花哨的内容等等。也许还需要让用户能够从首页导航到 “关于” 页面，如果真是这样，请务必让该信息能够从 http://mysite.example.com/about.html 获得。有些人习惯从此页寻找这类信息。

一个好的 about.html 页面应该能够提供有关站点功能、创建此站点的意图以及用户为何要关注此站点的总览，而且还有可能会有几个链接能够帮用户导航回站点的核心功能。此页无需、而且通常也不应该十分华丽。只需让它保持务实且准确，以便用户能够利用站点所能提供的所有功能。

contact.html

那么，如何联系您呢？借助 about.html，用户可以通过在现有主页上的多次单击获得此信息。不要让用户费太多力气才能找到此信息：将其放置于 http://mysite.example.com/contact.html。为相同的页面同样使用 contacts.html。请引入 .htm 扩展名。名称易得易用。当然，也可以将此信息留在这些单击产生的连串导航屏幕的最后；但为寻找资源提供冗余方案的做法也不错。

网站的版权归谁所有？有可能内容属于您，但您又是谁呢？个人？公司？合伙人？政府机构？如果内容属于公共领域或在自由内容许可的范畴内，那么可能需要告知用户这一点。时下，几乎任何内容都有各自的版权归属：如果您的内容遵从不同的原则，那么就请告知用户。但目前费心提供这类信息的网站还不够多，但为何不将它添加到自己的网站呢？因为总会有些用户会关注这方面的信息。

很明显，不同的页面或资源可能有不同的版权信息。请利用这个页面为用户提供有关如何确定那些个别差异的信息。如果有商标方面的问题，请一并提供。

index.html（和 index.htm）

并不是每个 Web 服务器都实际使用 index.html 文件来描述其主页。根据设置的不同，可能会有 URL 重写、依路径名动态生成等手段。但用户并不关心这些细节！只需让 http://mysite.example.com/index.html 指向主页，即便是为了实现这一目的而必须要使用简单 HTML 重定向。

对了，既然如此，那么就索性让老的 .htm 扩展名也生效吧。如果还觉得不够，就对 index.cgi 也如法炮制吧。

index.rss

很多 Web 内容都可通过 RSS 提供。虽然此种做法并不适用于所有 Web 站点，但对大多数站点而言还是比较有效的。让 RSS 内容独立于特定于用户的配置选项、登录或为特定的信息付费的做法极其合理。因为 RSS 也不能面面俱到。

虽然如此，如果有些东西 可以作为 RSS 提供，那么请尽管这么去做。也许，在 index.rss 给出的不过是 “广告” 内容，有时还会一并提供如何利用 RSS 提要的种种优势的老生常谈。有时又或许是有关 RSS 为何与您的 Web 站点不相关的一个说明。

privacy.html

一旦想要收集用户信息（即使只有用户名或流量日志），就要告知用户您打算如何处理这些信息。围绕 Web 站点创建者和/或用户的权力和责任的法律问题十分复杂 — 我不是一名律师，更无法解决您法律方面的问题。不过，若能考虑到用户的个人私隐，用户还是会感觉到的。而且也许您就应该在此时与律师商谈一下该如何处理用户的数据。

robots.txt

如果不想让 Web 站点上的所有资源都能被自动工具编入索引，就请在 robots.txt 文件内加以说明。但如果确实想让内容都编入索引，也请如实说明。Robots Exclusion Standard 指令并不强制用户：如果的确不想让某些东西可见，就请不要将其放到站点，或者要确保其后有足够的许可保护。不过，所有主要的合法 Web 爬虫引擎都会遵从 robots.txt 内的要求。因此请尽量明确地说明您的意图。

security.html

security.html 的使用并不强制。但如果站点存在安全性问题（比如，从用户那收集了任何敏感的信息），为安全性流程建立文档说明（至少给出大致的概括）不失是个很好的做法。请在此页给出联系信息以防用户存在任何疑问或想要给出如何改进的建议。寻找这些信息应该遵从网站导航选项的整体组织。既然如此，不妨在这个 URL 也放上该资源。

站点地图

如何显示整个 Web 站点的地图还未完全标准化。为制作站点地图而提供的某些东西 总是很有用的，但这些东西究竟详细到何种程度取决于站点的动态程度（或动态的方式）。而且，想要为用户显示的内容也依赖于站点的意图。比如，如果用户没有对资源 X 的使用权限，那么让用户知道资源 X 的存在可能根本就不合适。请根据自己的判断和具体情况，设法提供一些东西。

对于很多站点，提供站点地图只不过是对诸如搜索引擎这类自动机制的支持和友好。Google 在 robots.txt 约定的基础上发布了一个新的约定。总之，可以创建一个 XML 文件来给出站点所提供的所有资源。这有点像一个 “包含列表”，充当了 robots.txt 的 “排除列表” 的补集。

电子邮件地址

只考虑 Web 上的东西还不够。有时 Web 站点的导航工具并不能尽入人意（或者有的用户可能会对您的优雅设计不理解），因此最好让用户也能通过电子邮件联系到您。

请务必在 Web 站点的 contact.html 或其他地方显著地公布联系信息。但也请确保发到一般性的电子邮件地址的邮件能够送达给合适的人员。这至少包括 [email protected]、 [email protected] 和 [email protected]。对于那些 “老辈人”，可能需要让发给 [email protected] 的邮件也能转达到合适之处（但出于安全性原因，可能不是到 “root”）。请加入少许对电子邮件转发进行说明的文字，这些文字应该能清楚表明站点目的。电子邮件地址就像 Web 服务器目录中的符号链接一样易得易用。

参考资料

您可以参阅本文在 developerWorks 全球站点上的英文原文。
同样地，Wikipedia 也有有关 Google 站点地图约定的介绍。
在 Wikipedia 上寻找 Robots Exclusion Standard 的介绍。
在 Apache 里配置定制 404 消息很简单（就如同在 Apache 中配置任何其他东西一样）。对于其他 Web 服务器，可参考 Apache 的文档。
在 Web development 专区的技术库获得更多指导性文章

蓝芒事件

1 則留言

继紫田之后！蓝芒也出现了紫田事件！

蓝芒的事件,吓人一下子又去了1000台服务器,中国的互联网到底怎么了。

DZ在蓝芒的机器算不错的,断线掉,马上启用备用服务器,虽然数据只到凌晨三点的.可事却很佩服它的,因为那么大的数据备份起来确实很吃力,或许事因为去你PW的硬盘事件吧.不过附件也事没办法啦.不过比猪头好多了,数据都没备份,这次糗大了.纵观紫田和蓝芒的事件,看来自己服务器的数据也事要及时备份,也得通知他们备份,不然…

所以啊，同志们还是趁早转移吧，就算被GFWed了，还可以用代理上去，总强过国内被拔网线吧。

TOR使用说明和下载

發佈留言

　Tor的全称是“The Onion Router”号称是“An anonymous Internet communicaton system”。它针对现阶段大量存在的流量过滤、嗅探分析等工具，在JAP之类软件基础上改进的，支持Socks5，并且支持动态代理链（通过Tor访问一个地址时，所经过的节点在Tor节点群中随机挑选，动态变化，由于兼顾速度与安全性，节点数目通常为2-5个），因此难于追踪，有效地保证了安全性。另一方面，Tor 的分布式服务器可以自动获取，因此省却了搜寻代理服务器的精力。
　　将Tor和SocksCap32(SocksCap32可以用FreeCap替代)联合使用，将得到一个永远有效的支持Socks5的代理。由于Socks5的代理实在太难找了，所以Tor实在是一大福音。
　　这个软件使用起来也很简单。Tor的下载地址是 http://tor.eff.org/，先去下载最新版本的TOR和SOCKSCAP32，下载完毕后我们安装TOR，然后我们就可以运行Sockscap32，设置服务器地址为，Socks5:127.0.0.1:9050，然后把你的IE浏览器拉入Sockscap，双击后打开IE，即可通过TOR上网。
　　很多网络软件本身也支持使用代理，因此可以连Sockscap32也可以省了，比如FLASHFXP，QQ等都支持Socks5，只要在代理服务器地址填写127.0.0.1，端口填写9050，即可实现安全上网，那时你的QQ好友会发现你的IP竟然是来自美国呢。

http://blog.pcstars.tk/2006/05/tor.html

搜索

發佈留言

　　信息的飞速增长，使搜索引擎成为人们查找信息的首选工具，Google、百度、中国搜索等大型搜索引擎一直是人们讨论的话题。随着搜索市场价值的不断增加，越来越多的公司开发出自己的搜索引擎，阿里巴巴的商机搜索、8848的购物搜索等也陆续面世，自然，搜索引擎技术也成为技术人员关注的热点。
　　搜索引擎技术的研究，国外比中国要早近十年，从最早的Archie，到后来的Excite，以及altvista、overture、google等搜索引擎面世，搜索引擎发展至今，已经有十几年的历史，而国内开始研究搜索引擎是在上世纪末本世纪初。在许多领域，都是国外的产品和技术一统天下，特别是当某种技术在国外研究多年而国内才开始的情况下。例如操作系统、字处理软件、浏览器等等，但搜索引擎却是个例外。虽然在国外搜索引擎技术早就开始研究，但在国内还是陆续涌现出优秀的搜索引擎，像百度（http://www.baidu.com/）等。目前在中文搜索引擎领域，国内的搜索引擎已经和国外的搜索引擎效果上相差不远。之所以能形成这样的局面，有一个重要的原因就在于中文和英文两种语言自身的书写方式不同，这其中对于计算机涉及的技术就是中文分词。
　　什么是中文分词
　　众所周知，英文是以词为单位的，词和词之间是靠空格隔开，而中文是以字为单位，句子中所有的字连起来才能描述一个意思。例如，英文句子I am a student，用中文则为：“我是一个学生”。计算机可以很简单通过空格知道student是一个单词，但是不能很容易明白“学”、“生”两个字合起来才表示一个词。把中文的汉字序列切分成有意义的词，就是中文分词，有些人也称为切词。我是一个学生，分词的结果是：我是一个学生。
　　中文分词和搜索引擎
　　中文分词到底对搜索引擎有多大影响？对于搜索引擎来说，最重要的并不是找到所有结果，因为在上百亿的网页中找到所有结果没有太多的意义，没有人能看得完，最重要的是把最相关的结果排在最前面，这也称为相关度排序。中文分词的准确与否，常常直接影响到对搜索结果的相关度排序。笔者最近替朋友找一些关于日本和服的资料，在搜索引擎上输入“和服”，得到的结果就发现了很多问题。下面就以这个例子来说明分词对搜索结果的影响，在现有三个中文搜索引擎上做测试，测试方法是直接在Google（http://www.google.com/）、百度（http://www.baidu.com/）上以“和服”为关键词进行搜索：
　　在Google上输入“和服”搜索所有中文简体网页，总共结果507,000条，前20条结果中有14条与和服一点关系都没有。
　　在百度上输入“和服”搜索网页，总共结果为287,000条，前20条结果中有6条与和服一点关系都没有。
　　在中搜上输入“和服”搜索网页，总共结果为26,917条，前20条结果都是与和服相关的网页。
　　这次搜索引擎结果中的错误，就是由于分词的不准确所造成的。通过笔者的了解，Google的中文分词技术采用的是美国一家名叫Basis Technology（http://www.basistech.com/）的公司提供的中文分词技术，百度使用的是自己公司开发的分词技术，中搜使用的是国内海量科技（http://www.hylanda.com/）提供的分词技术。由此可见，中文分词的准确度，对搜索引擎结果相关性和准确性有相当大的关系。
　　中文分词技术
　　中文分词技术属于自然语言处理技术范畴，对于一句话，人可以通过自己的知识来明白哪些是词，哪些不是词，但如何让计算机也能理解？其处理过程就是分词算法。
　　现有的分词算法可分为三大类：基于字符串匹配的分词方法、基于理解的分词方法和基于统计的分词方法。
　　1、基于字符串匹配的分词方法
　　这种方法又叫做机械分词方法，它是按照一定的策略将待分析的汉字串与一个“充分大的”机器词典中的词条进行配，若在词典中找到某个字符串，则匹配成功（识别出一个词）。按照扫描方向的不同，串匹配分词方法可以分为正向匹配和逆向匹配；按照不同长度优先匹配的情况，可以分为最大（最长）匹配和最小（最短）匹配；按照是否与词性标注过程相结合，又可以分为单纯分词方法和分词与标注相结合的一体化方法。常用的几种机械分词方法如下：
　　1）正向最大匹配法（由左到右的方向）；
　　2）逆向最大匹配法（由右到左的方向）；
　　3）最少切分（使每一句中切出的词数最小）。
　　还可以将上述各种方法相互组合，例如，可以将正向最大匹配方法和逆向最大匹配方法结合起来构成双向匹配法。由于汉语单字成词的特点，正向最小匹配和逆向最小匹配一般很少使用。一般说来，逆向匹配的切分精度略高于正向匹配，遇到的歧义现象也较少。统计结果表明，单纯使用正向最大匹配的错误率为1/169，单纯使用逆向最大匹配的错误率为1/245。但这种精度还远远不能满足实际的需要。实际使用的分词系统，都是把机械分词作为一种初分手段，还需通过利用各种其它的语言信息来进一步提高切分的准确率。
　　一种方法是改进扫描方式，称为特征扫描或标志切分，优先在待分析字符串中识别和切分出一些带有明显特征的词，以这些词作为断点，可将原字符串分为较小的串再来进机械分词，从而减少匹配的错误率。另一种方法是将分词和词类标注结合起来，利用丰富的词类信息对分词决策提供帮助，并且在标注过程中又反过来对分词结果进行检验、调整，从而极大地提高切分的准确率。
　　对于机械分词方法，可以建立一个一般的模型，在这方面有专业的学术论文，这里不做详细论述。
　　2、基于理解的分词方法
　　这种分词方法是通过让计算机模拟人对句子的理解，达到识别词的效果。其基本思想就是在分词的同时进行句法、语义分析，利用句法信息和语义信息来处理歧义现象。它通常包括三个部分：分词子系统、句法语义子系统、总控部分。在总控部分的协调下，分词子系统可以获得有关词、句子等的句法和语义信息来对分词歧义进行判断，即它模拟了人对句子的理解过程。这种分词方法需要使用大量的语言知识和信息。由于汉语语言知识的笼统、复杂性，难以将各种语言信息组织成机器可直接读取的形式，因此目前基于理解的分词系统还处在试验阶段。
　　3、基于统计的分词方法
　　从形式上看，词是稳定的字的组合，因此在上下文中，相邻的字同时出现的次数越多，就越有可能构成一个词。因此字与字相邻共现的频率或概率能够较好的反映成词的可信度。可以对语料中相邻共现的各个字的组合的频度进行统计，计算它们的互现信息。定义两个字的互现信息，计算两个汉字X、Y的相邻共现概率。互现信息体现了汉字之间结合关系的紧密程度。当紧密程度高于某一个阈值时，便可认为此字组可能构成了一个词。这种方法只需对语料中的字组频度进行统计，不需要切分词典，因而又叫做无词典分词法或统计取词方法。但这种方法也有一定的局限性，会经常抽出一些共现频度高、但并不是词的常用字组，例如“这一”、“之一”、“有的”、“我的”、“许多的”等，并且对常用词的识别精度差，时空开销大。实际应用的统计分词系统都要使用一部基本的分词词典（常用词词典）进行串匹配分词，同时使用统计方法识别一些新的词，即将串频统计和串匹配结合起来，既发挥匹配分词切分速度快、效率高的特点，又利用了无词典分词结合上下文识别生词、自动消除歧义的优点。
　　到底哪种分词算法的准确度更高，目前并无定论。对于任何一个成熟的分词系统来说，不可能单独依靠某一种算法来实现，都需要综合不同的算法。笔者了解，海量科技的分词算法就采用“复方分词法”，所谓复方，相当于用中药中的复方概念，即用不同的药才综合起来去医治疾病，同样，对于中文词的识别，需要多种算法来处理不同的问题。
　　分词中的难题
　　有了成熟的分词算法，是否就能容易的解决中文分词的问题呢？事实远非如此。中文是一种十分复杂的语言，让计算机理解中文语言更是困难。在中文分词过程中，有两大难题一直没有完全突破。
　　1、歧义识别
　　歧义是指同样的一句话，可能有两种或者更多的切分方法。例如：表面的，因为“表面”和“面的”都是词，那么这个短语就可以分成“表面的”和“表面的”。这种称为交叉歧义。像这种交叉歧义十分常见，前面举的“和服”的例子，其实就是因为交叉歧义引起的错误。“化妆和服装”可以分成“化妆和服装”或者“化妆和服装”。由于没有人的知识去理解，计算机很难知道到底哪个方案正确。
　　交叉歧义相对组合歧义来说是还算比较容易处理，组合歧义就必需根据整个句子来判断了。例如，在句子“这个门把手坏了”中，“把手”是个词，但在句子“请把手拿开”中，“把手”就不是一个词；在句子“将军任命了一名中将”中，“中将”是个词，但在句子“产量三年中将增长两倍”中，“中将”就不再是词。这些词计算机又如何去识别?
　　如果交叉歧义和组合歧义计算机都能解决的话，在歧义中还有一个难题，是真歧义。真歧义意思是给出一句话，由人去判断也不知道哪个应该是词，哪个应该不是词。例如：“乒乓球拍卖完了”，可以切分成“乒乓球拍卖完了”、也可切分成“乒乓球拍卖完了”，如果没有上下文其他的句子，恐怕谁也不知道“拍卖”在这里算不算一个词。
　　2、新词识别
　　新词，专业术语称为未登录词。也就是那些在字典中都没有收录过，但又确实能称为词的那些词。最典型的是人名，人可以很容易理解句子“王军虎去广州了”中，“王军虎”是个词，因为是一个人的名字，但要是让计算机去识别就困难了。如果把“王军虎”做为一个词收录到字典中去，全世界有那么多名字，而且每时每刻都有新增的人名，收录这些人名本身就是一项巨大的工程。即使这项工作可以完成，还是会存在问题，例如：在句子“王军虎头虎脑的”中，“王军虎”还能不能算词？
　　新词中除了人名以外，还有机构名、地名、产品名、商标名、简称、省略语等都是很难处理的问题，而且这些又正好是人们经常使用的词，因此对于搜索引擎来说，分词系统中的新词识别十分重要。目前新词识别准确率已经成为评价一个分词系统好坏的重要标志之一。
　　中文分词的应用
　　目前在自然语言处理技术中，中文处理技术比西文处理技术要落后很大一段距离，许多西文的处理方法中文不能直接采用，就是因为中文必需有分词这道工序。中文分词是其他中文信息处理的基础，搜索引擎只是中文分词的一个应用。其他的比如机器翻译（MT）、语音合成、自动分类、自动摘要、自动校对等等，都需要用到分词。因为中文需要分词，可能会影响一些研究，但同时也为一些企业带来机会，因为国外的计算机处理技术要想进入中国市场，首先也是要解决中文分词问题。在中文研究方面，相比外国人来说，中国人有十分明显的优势。
　　分词准确性对搜索引擎来说十分重要，但如果分词速度太慢，即使准确性再高，对于搜索引擎来说也是不可用的，因为搜索引擎需要处理数以亿计的网页，如果分词耗用的时间过长，会严重影响搜索引擎内容更新的速度。因此对于搜索引擎来说，分词的准确性和速度，二者都需要达到很高的要求。目前研究中文分词的大多是科研院校，清华、北大、中科院、北京语言学院、东北大学、IBM研究院、微软中国研究院等都有自己的研究队伍，而真正专业研究中文分词的商业公司除了海量科技以外，几乎没有了。科研院校研究的技术，大部分不能很快产品化，而一个专业公司的力量毕竟有限，看来中文分词技术要想更好的服务于更多的产品，还有很长一段路。
　　作者：Winter

http://blog.pcstars.tk/2006/02/blog-post_25.html

星星IT资讯

有关最新互联网资讯的IT博客

分類彙整: 网站应用

使用mod_headers或mod_expires实现缓存

面向站长和网站管理员的Web缓存加速指南[翻译]

基于反相代理的Web缓存加速——可缓存的CMS系统设计

WordPress 2.3 – 你必须知道的10件事

对永久链接的一些更改

IPv6

对评论的一些更改

删除了评论链接中的nofollow

小心：中国黑客利用贝·布托死讯传毒

DNS and BIND

星星百科

各大网站域名服务器测评

hosting has been shutdown

每个 Web 站点都必需的十余个文件

蓝芒事件

TOR使用说明和下载

搜索