╭∩╮（︶︿︶）╭∩╮FreeBSD使用大全FreeBSD╭∩╮（︶︿︶）╭∩╮

probing

设置和使用ipfilter

　　虽然ipfw/natd已经是相当强大的网络地址转换及防火墙系统，然而它还是有一定的缺点存在。其中最重要的一个缺点是natd是使用守护进程的方法来进行地址转换，因为它没有运行在内核中，而是通过divert socket 来和内核通信，这种方式虽然比较灵活，但效率显然要低一些。

　　另外，natd的功能还不能满足有些要求，natd能做静态地址转换和使用一个伪装地址为多个内部地址服务，但其不能从一个给定的地址池中，为内部地址自动分配IP地址。毕竟natd是一个较早的网络地址转换工具，当前的发展已经比较迟缓。但是由于ipfw是FreeBSD系统的一部分，并且过滤和地址转换是由不同的部分来完成的，结构清晰，因此对于大部分情况都很适合，因此一般仍应使用ipfw/natd。

　　如果ipfw/natd不能满足使用者的需要，能避免ipfw/natd缺点的另一个网络地址转换和数据包过滤的工具是ipfilter。虽然FreeBSD是其支持的主要系统，但它其实是一个支持多平台的独立软件，不仅能运行在FreeBSD上，也能运行在其他多种Unix系统中。由于它被包括进FreeBSD基本系统中，因此在FreeBSD 下配置ipfilter同样也非常轻松。

　　ipfilter的网址为http://cheops.anu.edu.au/~avalon/， FreeBSD 3.0之前它不包括在FreeBSD的基本系统中，需要手工设置。

　　由于ipfilter与ipfw同为在内核级对IP数据包进行处理的系统，因此他们相互冲突，不能同时并存在一个内核内，否则内核的TCP/IP功能就不能正常执行。为了使用ipfilter，就需要重新定制内核，删除所有 IPFIREWALL的设置，而添加IPFILTER的设置。

#options                IPFIREWALL
#options                IPDIVERT

options                IPFILTER
options                IPFILTER_LOG

　　选项IPFILTER为支持IPFILTER的基本代码，IPFILTER_LOG为支持IPFILTER的统计记录能力。需要增加这些选项，并注释IPFIREWALL、IPDIVERT及其相关选项。此后，就可以重新定制、安装新内核。然而在重新启动之前，还需要在rc.conf中设置firewall_enable的值为NO，当系统内核不存在IPFIREALL功能又设置了firewall_enable的时候，启动文件就会自动载入支持这个功能的可加载模块ipfw.ko，载入ipfw.ko之后的系统内核就等同于使用IPFIREWALL内核选项的系统，与 ipfilter发生冲突。然而ipfilter仍然需要设置gateway_enable，以打开系统内核的数据包转发功能。

　　使用新内核启动系统之后，如果本地计算机的网络功能正常，此时再使用ipfw就会报告错误。这就能使用ipfilter 来设置包过滤和网络地址转换了。

    * 设置地址转换

　　为了在ipfilter下设置网络地址转换，首先要创建一个地址转换设置文件，例如/etc/ipflter .nat。与ipfw/natd的相似，最基本的用法为使用一个外部地址来转换所有内部地址，此时必须进行端口转换，因此ipfilter.nat中应该包含的NAT规则为：

　　map fxp1 192.168.3.0/24 -> 202.102.245.60/32 portmap tcp/udp 10000:65000

　　这个设置中，首先使用map关键字指明是进行地址转换的设置，此后的fxp1为连接外部网络的网络界面，在这个网络界面上执行数据包的IP地址和端口地址转换，第三个参数为进行转换的内部地址的范围，此后跟随的一个-> 符号表示进行地址转换，第五个参数为要转换为的外部地址，当指定子网掩码长度为32时就表示这只是一个主机而非子网范围，后面portmap关键字对tcp/udp协议进行端口转换，其使用的映射端口范围为在10000到65000之间，也可以对tcp或udp协议分别指定转换端口的范围。

　　如果使用者拥有的不仅是一个主机，而是一个具备多个合法IP地址的子网，这样就能设置使用地址池，为内部向外连接的计算机动态分配合法的外部IP地址，这样的设置更为简单，因为不需要指定portmap进行地址转换。

　　map fxp1 192.168.3.0/24 -> 202.102.245.0/26

　　显然内部计算机的数量显然要多于系统拥有的合法地址的数量，上例中内部地址最多254个，而合法的外部地址仅仅有62个，这样如果向外连接的计算机一多，必然出现地址资源用光的问题。因此动态分配IP一般和端口转换结合起来，以避免出现地址消耗完毕的问题。

　　map规则是用于转换外出数据包的源地址，使得被转换后的地址好象是从外部地址中发起的。而另一个规则rdr 用于转换数据包中的目的地址，这样就能使得一个数据包被转发到某个特定计算机上进行处理，这可用于构建端口映射关系。

　　rdr fxp1 202.102.245.60 port ftp -> 192.168.3.2 port ftp

　　上面的规则将指定ipfilter在fxp1网络界面上将发送给202.102.245.60，端口为ftp 的数据包，转换为发送给内部地址192.168.3.2。

　　rdr的另一个重要用途是可以用以构建透明的代理服务器，普通代理服务器都需要在客户机上进行设置，如果不进行设置，客户机将直接访问Internet上的计算机而不通过代理服务器，然而防火墙可以将这些应用请求转发给代理服务器，完成代理工作。此时对外界发送请求是在内部网络界面fxp0上发起的，因此也要在这里进行地址转换，而使用0.0.0.0/0 代表对所有目的地址，并且是80端口的浏览请求都转发到127.0.0.1上去，而127.0.0.1 必须运行代理服务器软件，以提供代理服务。

　　rdr fxp0 0.0.0.0/0 port 80 -> 127.0.0.1 port 80

　　虽然不是所有的应用代理服务都能使用透明代理的方法来减轻客户设置的负担，但绝大多数代理完全可以使用这种方法，使得客户不需要修改软件设置，就能利用代理服务器，而代理服务器具备大量的缓冲区，能够节约内部网络的Internet 访问流量并加速Internet访问速度。

　　因此，一个简单的不支持透明代理服务器的设置文件ipnat.conf例子为：

map fxp1 192.168.3.0/24 -> 202.102.245.0/26 portmap tcp/udp 10000:65000
map fxp1 192.168.3.0/24 -> 202.102.245.0/26
rdr fxp1 202.102.245.60 port ftp -> 192.168.3.2 port ftp

　　在这样的设置下，tcp和udp在地址资源消耗完毕之后将进行端口转换，而其他协议，如icmp，将直接进行地址转换而不必进行端口转换。此后就可以将这个转换规则加入系统中，需要执行ipnat命令：

# ipnat -C
# ipnat -f /etc/ipnat.conf

　　当前使用-C参数用于清除现有的转换规则，-f用于从配置文件中读取转换规则。设置了转换规则之后，就可以使用-l参数查看当前设置的转换规则和已经激活的转换关系。

# ipnat -l
List of active MAP/Redirect filters:
map fxp1 192.168.3.0/24  -> 202.102.245.0/26  portmap tcp/udp 10000:65000
map fxp1 192.168.3.0/24  -> 202.102.245.0/26
rdr fxp1 202.102.245.60/32 port 21 -> 192.168.3.2 port 21 tcp

List of active sessions:
RDR 192.168.3.2     21    <- -> 202.102.245.60  21    [202.102.245.25 35635] 863
992 0 407
MAP 192.168.3.2     1024  <- -> 202.102.245.60  10000 [202.102.245.25 9999] 8639
93 0 1f09

    * 设置包过滤

　　ipfilter也能很好的完成包过滤任务，它的过滤规则相当复杂。下面为一些简单的过滤设置例子，一般这些过滤规则可以保存在/etc/ipf.conf文件中。

block in log quick all with short
block in log quick all with ipopts

　　block参数用于屏蔽符合过滤条件的数据包，in代表数据包的方向，标识从网络上或其他网络界面上发送到某个网络界面上的数据包，log用于指出该规则过滤的数据包应被记录下来，quick指示ipfilter进行快速过滤处理，符合这个规则的数据包将立即丢弃，all with short标识不完整的IP数据包，数据包的长度太小就没有包含合法的源地址或目标地址，从而无法被ipfilter识别，all with ipopts标志本身带有路由数据的IP数据包，这些IP数据包由于包含自己的路由信息，因此可能会带来网络安全问题。

　　这两句设置用于过滤可能会带来安全问题的短数据包或具备路由信息的数据包。

pass in on fxp0 all
pass out on fxp0 all
pass in on lo0 all
pass out on lo0 all

　　pass用于指定数据包可以通过，out与in相反，标识从网络界面向网络上或其他网络界面发送的数据包，而on fxp0或on lo0标识进行处理的网络界面。这里的设置允许内部网络界面、loopback网络界面可以自由发送和接收数据包。

block in log on fxp1 all
block out log on fxp1 all

　　为了安全起见，除了明确指定可以发送和接收的数据包之外，屏蔽其余的外部网络界面进行数据发送和接收。

block in log quick on fxp1 from 10.0.0.0/8 to any
block in log quick on fxp1 from 192.168.0.0/16 to any
block in log quick on fxp1 from 172.16.0.0/12 to any
block in log quick on fxp1 from 127.0.0.0/8 to any

　　上面的设置明确屏蔽具备内部网络地址的数据包被转发到外部网络去，由于ipfilter中地址转换和包过滤是在同一个系统中完成的，因此不必担心它们会发生冲突问题。

pass out log on fxp1 proto icmp all keep state
pass out log on fxp1 proto tcp/udp from any to any keep state

　　proto用于指定不同的协议，通常可以设置为tcp, udp和icmp。这两行设置允许TCP, UDP, ICMP协议的数据包可以向外发送出去，keep state用于标识建立TCP连接之后的数据包，或者ICMP、UDP的回应数据包，以允许回应数据包能发送回内部网络。

pass in quick on fxp1 proto tcp from any to any port = ftp-data keep state
pass in quick on fxp1 proto tcp from any port = ftp-data to any port > 1023 keep state

　　ftp中将打开额外的端口以进行数据传输，这两个设置允许对ftp数据端口的数据包能够进行转发。

block return-rst in log on fxp1 proto tcp from any to any flags S/SA
block return-icmp(net-unr) in log on fxp1 proto udp from any to any

　　对于其他tcp连接请求，防火墙回应一个RST数据包关闭连接，S/SA标识TCP数据包的标志，S为Syn， A为Ack，而S/SA表示对Syn和Ack中的Syn标志进行检查，这类数据包是用于设定连接的数据包。对UDP请求，防火墙回应网络不可达到的ICMP包。

　　上面的例子将屏蔽外部计算机发向网络内部的数据包，但允许内部向外的发起网络访问。如果要允许外部网络对内的访问，就必须增加其他pass in规则，以使得过滤规则能适应更复杂的情况。为了使上面的设置生效，必须将过滤规则加入到内核中去，这需要使用ipf命令。

# ipf -Fa
# ipf -f  /etc/ipf.conf

　　首先使用-Fa标志清除所有的过滤规则，然后将ipf.conf中的设置加入系统中。此后，可以使用ipfstat来检查ipfilter进行过滤的各种统计信息。

# ipfstat
input packets:                blocked 227 passed 116210 nomatch 68219 counted 0
output packets:                blocked 0 passed 74586 nomatch 20316 counted 0
input packets logged:        blocked 227 passed 24883
output packets logged:        blocked 0 passed 17153
packets logged:        input 0 output 0
log failures:                input 25028 output 17139
fragment state(in):        kept 0        lost 0
fragment state(out):        kept 0        lost 0
packet state(in):        kept 1        lost 0
packet state(out):        kept 14        lost 8
ICMP replies:        160        TCP RSTs sent:        9
Result cache hits(in):        47523        (out):        53694
IN Pullups succeeded:        0        failed:        0
OUT Pullups succeeded:        0        failed:        0
Fastroute successes:        0        failures:        0
TCP cksum fails(in):        0        (out):        0
Packet log flags set: (0x10000000)
        packets passed through filter

　　虽然在规则中指定了log选项，但是缺省时候syslogd并不会记录ipfilter发送的信息。符合规则的数据记录并没有真正被发送到系统日志记录中，必须使用ipmon打开记录功能。

# ipmon -s -n -x

　　由于ipmon使用的是syslog的local0通道，缺省情况下local0通道并没有打开，因此只有很少的错误信息被发送到/var/log/messages文件中。为了打开local0通道，还需要改动syslogd.conf，增加下面的设置，以记录ipfilter的全部记录。

local0.*                /var/log/ipfilter.log

　　为了不让ipfilter的记录发送到/var/log/messages等其他日志文件中，可以在/var/log/messags设置行中添加一个记录local.none。

　　此后，使用touch创建ipfilter.log文件，并重新启动syslogd，就能在/var/log/ipfilter.log中正确记录过滤记录了。当一切都设置完毕之后，就能将ipf和ipnat这两个设置命令放入系统启动文件rc.local，以便每次系统自动启动都能执行防火墙设置。

未完，待续。。。　　

probing

构建防火墙

　　防火墙的主要目标是控制内部网络和外部Internet之间的连接，有限制的允许内部网络中的计算机访问Internet 上的服务，但限制外部网络访问内部计算机。为了实现这个目的，至少需要一个具有两个（或更多）网络界面的计算机，它的一个网络界面连接外部网络，另一个网络界面连接内部网络。然而如何实现限制网络访问的方法却有所不同，主要就可以分为基于IP数据包过滤的防火墙和基于代理的防火墙。ipfw/natd和ipfilter都是基于包过滤和网络地址转换的软件工具，而代理服务器通常通过代理服务器软件来实现。

　　FreeBSD下用于防火墙的最重要的代理软件是fwtk，它提供了多种代理服务器和统一的认证方式。FreeBSD 上也能运行其他的代理服务器，然而那些代理服务器主要用于代理单个协议，不能单独用于构建全面功能的防火墙系统，而fwtk则提供了多种代理服务器，为构建一个完整的防火墙系统提供了基础。然而fwtk不是一个设置完好的防火墙系统，而只是一组构建防火墙的组件。因此要使用fwtk来设定防火墙，仍然是一个复杂的任务。虽然在FreeBSD 下可以使用Ports Collection很方便的编译安装fwtk，但问题的关键是针对具体的服务进行设置。

　　fwtk能在多种Unix系统上运行，很多资料和书籍都已经介绍了其使用和设置方法，这里就不再介绍fwtk 的使用和设置。这里主要介绍基于包过滤和NAT的防火墙系统。

    * 选择防火墙的类型

　　早期的包过滤防火墙只是建立在路由器的基础上，只支持有限的过滤规则，并且不能保持网络连接状态。更关键的问题是，基于路由器的防火墙不能隐藏内部网络的拓扑结构，这样入侵者就比较容易利用包括IP欺骗在内的方式对内部计算机进行攻击。然而，网络地址转换技术可以改变这种情况，使用ipfw/natd或ipfilter可以建立更安全、更高性能的防火墙系统。

　　由于NAT改变了内部计算机的IP地址，因此这种方式也可以称作网络层代理。而其他直接支持应用程序的代理服务器，如squid，fwtk等，被称为应用层代理，应用层代理的好处是可以定义更复杂的访问控制形式，例如针对用户进行认证等，并能提供较详细的日志记录。然而应用层代理的缺点是不方便用户使用，需要对客户端软件进行其他设置，并且不一定会具有所有种类的应用程序的代理程序。

　　代理型防火墙的另一个问题是，无法向外部提供网络服务。这也可以算一个优点，因为向外提供网络服务就必然降低网络安全性，然而实际上网络使用者也希望通过自己的网络向外发布信息，而不只是简单的浏览Internet。当然在提供服务的同时也要保证发布信息服务器的安全，因此希望将其放入防火墙内部。对于需要发布信息的要求，NAT通过映射端口（或地址）就能满足要求，但代理服务器不能。

　　然而，也能设计这样一种代理服务器，它接收Internet上任意（或受限）主机的访问，而将代理这些访问请求访问内部的服务器，这种代理服务器称为反向代理服务器。

　　在不同类型的防火墙之间进行选择主要依赖于不同的需要，一般的情况下，内部网络的使用希望防御外部网络上的入侵者，但又希望能够最大可能的使用各种网络应用程序来访问Internet，而同时也希望系统配置比较简单，这样直接利用FreeBSD提供的ipfw/natd或ipfilter均能满足这种要求，网络地址转换类型的防火墙配置简洁、性能更高，并且对应用程序的支持相当强。

　　有些网络内部计算机的使用比较混乱，因此希望针对用户进行认证控制，此后才允许用户能访问Internet，并还希望能限制用户使用访问Internet的应用种类，进行更复杂的日志记录，这些情况下就应该选用应用层代理服务器fwtk。极端的情况下，只打算对内部用户提供有限种类的Internet服务，那么设置一个专用的应用代理服务器也就满足要求了，例如设置squid代理WWW访问。

　　然而，在FreeBSD上构建防火墙系统是通过系统提供的各种组件进行组合得到的，采取多种组件进行组合，就能构建更复杂的系统。可以根据不同需要，同时利用包过滤、网络地址转换及各种不同应用层代理等多种形式，设置不同复杂程度的防火墙系统，这就是FreeBSD系统的优势。但在这些情况下，由于FreeBSD提供的这些组件并不是单一软件，而是相互独立的多个软件，因此要设置一个完整的防火墙系统，还需要使用者进行复杂的设置。或者还需要管理员使用一些简单的脚本程序以辅助分析系统日志，发送警报，甚至对网络状态进行实时监控，通过迅速改变防火墙设置来保护内部网络系统。

　　通过分析防火墙的日志记录，甚至监控通过防火墙的数据流模式，就可以寻找发生过或正在进行的系统入侵行为（通常可能是服务阻塞、暴力攻击甚至更复杂的特定攻击模式），进而反馈回防火墙系统，以重新调整设置，增强系统安全性。

    * 防火墙的拓扑结构

　　当构建防火墙系统时，首先就要考虑网络的拓扑结构，这将对防火墙的设置产生影响。简单的网络可能只需要一台防火墙设备，而复杂的网络会需要更多的网络设备，包括多个防火墙系统。以下给出了最常使用的几种使用防火墙的网络拓扑，基本上这些拓扑将适合大多数的情况，可以使用这些拓扑来作为建立自己内部网络的参考。

　　最简单的情况为使用具备两个网络界面的一个防火墙来分隔内部与外部网络。这种形式简单易行，适合大部分只需要访问Internet，而不需要对外发布信息的网络。一旦要向外发布信息，那么所提供的服务就会降低网络的安全性，造成相应的安全问题。

　　为了避免在向外提供服务的服务器被侵入之后，影响内部网络的安全性，就需要将对外提供服务的服务器和只访问外部网络的客户计算机分隔到不同的网络上。可以采用上面的方式，防火墙使用三个网络界面，分别用于外部网络、内部网络和提供服务的服务器。

　　使用单个防火墙的网络，网络安全被一台防火墙的安全所限制，更复杂的情况是同时使用多个防火墙系统。例如使用两个防火墙，第一层防火墙与第二层防火墙之间可以放置允许外部访问的服务器，这个区域被称为停火区，即使入侵者进入这个区域，还需要近一步攻击内部防火墙才能接触内部网络。

　　如果这两个防火墙使用不同的技术，如外部防火墙为网络地址转换方式，而内部防火墙为代理服务器方式，这样即使入侵者侵入一个防火墙，但另一个防火墙使用的是完全不同的技术，就给入侵者带来更大的阻碍，提高整个网络的安全性。

　　利用这些工具，网络可以设置的非常安全。事实上当前大部分安全问题仍然来源于人的因素，如管理不善造成的口令泄露等。这就使得正常的安全措施无法正常应用，而带来不可避免的安全问题。

    * PicoBSD

　　软件方式的防火墙系统的一大问题就是由于系统本身能够安装丰富的软件，因此常常同时被用作其他用途，当用作其他用途时就有可能对本身的安全性造成影响。而硬件防火墙使用专有操作系统，只用作网络服务，这保证了它不会受到其他方面的影响。对于用作防火墙的计算机，通常应该专用而不要兼作其他用途。因为防火墙的安全性非常重要，内部网络安全要依赖防火墙的安全来保障，一旦防火墙被入侵，网络安全也就无法保证了。

　　通常安装的FreeBSD系统都具备硬盘，当具备硬盘的FreeBSD用做防火墙系统时，一方面免不了想提供多种复杂的服务，这样系统可能会具备潜在的安全漏洞，另一方面入侵者入侵这个系统之后，可以在系统硬盘上隐藏入侵程序以进一步入侵网络内部。因此对于用作防火墙的FreeBSD系统，最好直接修改系统的rc文件，屏蔽所有的网络服务。另一种方法是可以尝试使用软盘上的FreeBSD系统，这样计算机本身不具备硬盘，可以从管理上杜绝它用作其他使用的机会，同时也节约了资源。此时FreeBSD系统可以不使用硬盘、显示器、键盘，通过串口进行设置，这样的系统可以安装在网络设备的机架上，专门用作防火墙提供安全服务。

　　PicoBSD就是这样的一个小型FreeBSD系统，能够安装在一张软盘上。PicoBSD提供了四个不同的版本：dial、isp、net和router，dial为拨号访问Internet的版本，isp为接受拨号访问的版本，net和router是用于网关和路由器的版本，它们都能够在386处理器和10M内存下运行（dial版本仅仅需要8MB内存）。虽然从FreeBSD的主页上，可以得到预定制好的多种PicoBSD的磁盘镜像，然而由于计算机使用的硬件差异很大，定制好的磁盘镜像不一定适合使用者的计算机硬件，由于软盘容量很小，不能容纳尽可能多的硬件驱动，每个磁盘镜像也不能支持太多的硬件设备，因此就需要根据自己计算机的具体硬件环境定制PicoBSD。

　　要定制PicoBSD，就需要一个安装了全部源代码的FreeBSD系统，并且这个FreeBSD系统的内核要支持伪设备vn及具备对应的设备文件，以便PicoBSD的设置程序能完成磁盘镜像文件的创建工作。PicoBSD 的源代码位于系统的/usr/src/release/picobsd目录下，这个目录中包含编译、配置PicoBSD 的说明，以及不同PicoBSD版本的配置。

　　定制PicoBSD系统要使用的该目录的子目录build中的build脚本，为了制作一个PicoBSD的磁盘镜像，就需要在这个目录下启动build命令。

# cd /usr/src/release/picobsd
# cd build
# ./build

　　build命令使用菜单将让使用者选择不同的PicoBSD的基本版本，如dial、isp、net和router ，根据不同的目的进行选择，此后选择n（no change）就能继续进行制作镜像文件的处理。当这个执行过程结束之后，build子目录下就产生了一个1.44MB的磁盘镜像文件picobsd.bin。此后可以在FreeBSD 下，或者在DOS下将镜像文件写入软盘，则一个单软盘的PicoBSD系统就制作完毕了。

　　build进程将使用/mnt来装载vn0设备，因此必须保证/mnt没有装载其他文件系统，而且vn0设备没有被占用。否则就会遇到错误。

　　然而这样制作的PicoBSD使用的还是缺省的设置，如果要定制PicoBSD系统，就需要更改缺省设置。首先应该根据具体的需要，选择功能相近版本的PicoBSD，再进一步更改硬件设置。每一个PicoBSD版本的设置都位于具有相同名字的子目录下，例如net版本PicoBSD的目录为/usr/src/release/picobsd/net/ ，在这个目录之下的conf子目录为PicoBSD内核的定制目录，而crunch1目录中为最后复制到 PicoBSD系统中的应用程序的名字列表。

　　当需要针对运行防火墙的计算机更改硬件设置时，需要更改conf子目录中的内核设置文件PICOBSD，这个文件就是PicoBSD的内核设置文件，可以删除或增加设置选项，改变对不同硬件设置的支持。如果要更改复制到软盘镜象中的执行程序的数量，就需要更改同样位于该版本目录下的crunch1子目录中的文件。只是注意软盘空间有限，因此只能装载有限的程序。

　　更改完这些设置之后，就可以转回build子目录重新定制PicoBSD，这样产生的镜象文件就为与硬件设置相符合的设置。将镜象文件写入软盘之后，就可以使用这个软盘启动防火墙系统，然后再使用命令行进行手工设置。需要注意的是，此时更改的只是写在内存文件系统MFS中的文件，而不是在软盘中文件，因此一旦系统重新启动，配置就不会保留下来。必须使用update命令将更改后的文件写回磁盘中之后，设置才能保留回磁盘中。

未完，待续。。。　　

probing

第9章 设置WWW服务

　　由于能够提供图形、声音等多媒体数据，WWW已经成为Internet使用者最喜爱的访问方式，当前的大部分 Internet流量均是由WWW浏览产生的。由于这种多媒体浏览方式的帮助，Internet不再仅仅是由专业人员使用，对计算机了解不多的普通使用者也能进入Internet的世界，享受Internet带来的新鲜内容。

　　虽然WWW服务非常之流行，然而要建立一个WWW服务器以提供WWW服务却仍然属于专业领域的任务。当前能够提供WWW服务的软件有很多种，分别运行在不同的操作系统之上，其中有一些软件能够运行在个人使用的Windows桌面系统上，具备图形界面且易于配置，因此很多希望尝试提供WWW服务的使用者常常会安装并试运行过这些系统。然而这些系统基本上是只能提供极其有限的服务能力的系统，如果要想提供一个能够允许正常的Internet访问的服务器系统，至少应该使用Windows NT系统。当要求更高的性能和稳定性系统时，就应该选择Unix。FreeBSD显然是使用Intel平台系统时，可供选择的极其优秀的WWW服务器操作系统。

    *
      基本概念

　　虽然普通使用者只需要了解一些常识性的概念，如URL、HTML等，就能通过浏览器很轻松的访问Internet 上的Web资源。然而要建立一个Web服务器，却需要更多的相关概念，如HTTP、MIME、CGI等，这样才能了解Web服务器的设置参数，以正确设置这些参数建立一个真正可用的服务器系统。

    * 超文本传输协议HTTP

　　用于支持WWW浏览的网络协议为HTTP，这是一种最基本的客户机/服务器的访问协议。浏览器向服务器发送请求，而服务器回应相应的网页。HTTP协议从1990年开始出现，发展到当前的HTTP 1.1标准，已经有了相当多的扩展，然而其最基本的实现是非常简单的，服务器需要进行的额外处理相当少，这也是为什么Web服务器软件如此众多的原因之一。

# 请求方法

通常，HTTP协议使用端口80来提供客户访问，因此也可以使用其他的网络软件，如telnet，模拟客户向服务器发送请求，来查看HTTP的传输方式。

$ telnet webserver 80
Trying 192.168.0.1...
Connected to webserver.
Escape character is '^]'.
GET /index.html

　　当telnet显示了Connect等信息建立了连接之后，服务器就等待使用者输入请求，而不进行任何提示。上例中，使用者输入GET /index.html指令，则服务器立即将相应的网页返回，然后关闭连接。

　　客户程序向服务器发送的请求可以有不同的类型，这样服务器可以根据不同的请求类型进行不同的处理。在HTTP 1.0中，定义了三种最基本的请求类型，GET、POST和HEAD，这些请求方法的实现方式均与上例相同，客户程序用大写指令将请求发送给服务器，后面跟随具体的数据。

　　GET请求最为常见，它后面跟随一个网页的位置，服务器接受请求并返回其请求的页面。除了页面位置作参数之外，请求还可以跟随协议的版本如HTTP/1.0等作为参数，以发送给服务器更多的信息。

　　POST请求要求服务器接收大量的信息，除了POST后面跟随的参数之外，浏览器还会在后面持续发送数据，让服务器进行处理。通常，POST方法是和CGI程序分不开的，服务器应该启动一个CGI程序来处理POST发送来的数据。

　　HEAD请求在客户程序和服务器之间进行交流，而不会返回具体的文档。当使用GET和POST方法时，服务器最后都将结果文档返回给客户程序，浏览器将刷新显示。而HEAD请求则不同，它仅仅交流一些内部数据，这些数据不会影响浏览的过程。因此HEAD方法通常不单独使用，而是和其他的请求方法一起起到辅助作用。一些搜寻引擎使用的自动搜索机器人使用这个方法来获得网页的标志信息，或者进行安全认证时，使用这个方法来传递认证信息。

　　除了这三种最常见的访问方法之外，在HTTP 1.1中还定义了更多的访问方法类型，如PUT，用于将网页放置到正确位置，DELETE用于删除相关文档等。这些方法并不常用，因而大部分Web服务器软件并没有实现他们。然而对于特定场合他们还是非常有用的，例如使用软件编辑网页时，网页编辑器可以使用这些方法，管理不同的网页。

　　如果服务器不支持客户发送的请求方法，服务器将返回错误并立即关闭连接。

# 服务器对HTTP的处理方式

　　HTTP协议的这种请求/回应的模式，使得服务器只能根据客户程序的请求发送回信息，这样的好处是客户具备很大的自由度，可以任意访问服务器上的信息。因此就存在多个客户同时访问一个服务器的问题。

　　在Unix下，由一个守护进程来监视来自客户程序的请求，当守护进程接受到一个请求时，就建立一个新的进程对请求进行处理。通常服务器能创建足够多的新进程来回应客户的请求，然而如果同时发送请求的客户太多，那么服务器就有可能出现超载的情况，创建进程的速度跟不上众多客户发送请求的速度，这样就造成了服务器对外表现反应迟缓。此外，为了提高用户使用浏览器时的性能，现代浏览器还支持并发的访问方式，浏览一个网页时同时建立多个连接，以迅速获得一个网页上的多个图标，这样能更快速完成整个网页的传输。但是对服务器来讲，更增加了瞬间负载。

　　显然，造成这个问题的关键是服务器对HTTP协议的处理方式，一次请求就要建立一个连接，在网页上充满了多个较小的图象文件的时候，那么服务器和客户程序之间的大部分工作是用于建立连接，而真正用于传递数据的工作却很轻松。因此，更好的利用现有连接，减少建立连接的消耗，就需要能在一次连接中回应多个请求。在HTTP 1.1中提供了这种持续连接的方式，而下一代HTTP协议：HTTP-NG更增加了有关会话控制、丰富的内容协商等方式的支持，来提供更高效率的连接。

　　除了针对每次请求都建立一个新进程的处理方式之外，HTTP守护进程也能使用其他的方式处理多个请求，例如使用多线程，或者使用异步方式在不同请求之间进行切换，就能在一个进程内处理多个请求。虽然比起建立新进程来讲，这样消耗的处理器资源略微减少，但是并不能从根本上消除并发访问带来的处理器资源不足的问题。一般使用线程和异步方式的程序较为复杂，不能很容易扩充对新特性的支持，并有可能因为程序内部要自己进行同步等原因也会造成资源消耗。使用这些方式，虽然对处理静态的网页有好处，但对于执行CGI程序，仍然要创建子进程进行处理。因此，大部分运行在Unix上的守护程序仍然使用多进程的方式，这种方式简单却有效。

　　即使对于使用多进程方式进行处理的Web服务器，也有不同的处理方式。Unix系统中提供了超级服务器进程inetd ，因此简单的Web服务器可以使用inetd来启动真正的Web服务器。然而，inetd效率不高，使用in etd的服务器不能用作高负载的服务器系统，因此高负载的Web服务器，本身来监听客户连接请求，并负责启动子进程真正处理客户的请求。

　　如果选择的服务器程序的确需要使用inetd来启动，可以选择与inetd功能相同，但效率更高的超级服务器进程tcpserver，它可以比inetd更高效的启动服务进程。

未完，待续。。。　　

probing

数据处理方式

　　当浏览器通过各种请求方法，试图从服务器获得数据的时候，服务器就必须将正确的数据返回给浏览器。浏览器并不关心服务器是如何进行处理的，服务器可以返回一个预先编辑好的HTML文档，也能根据请求动态生成返回的数据。而WW W的一大特点就是能用来传送多媒体数据，并且这些数据的传送是完全透明的，通过同样的HTTP连接，可以传送不同格式的声音、图象等数据。当服务器仅仅用于返回静态的HTML文档的时候，浏览器能够很容易的识别其数据类型，但当服务器不但用于返回静态的HTML文档，还可以动态返回各种类型的多媒体信息时，浏览器就不能仅仅从URL请求本身上判断服务器将会返回何种数据了。

　　服务器和浏览器之间是采用了另外的方式来标识数据的类型，这种方式下通过在传输真正的数据之前，预先传输一个数据的MIME类型的方法，来标识数据类型。

    * 多媒体文件格式MIME

　　最早的HTTP协议中，并没有附加的数据类型信息，所有传送的数据都被客户程序解释为超文本标记语言HTML 文档，而为了支持多媒体数据类型，HTTP协议中就使用了附加在文档之前的MIME数据类型信息来标识数据类型。

　　MIME意为多目Internet邮件扩展，它设计的最初目的是为了在发送电子邮件时附加多媒体数据，让邮件客户程序能根据其类型进行处理。然而当它被HTTP协议支持之后，它的意义就更为显著了。它使得HTTP传输的不仅是普通的文本，而变得丰富多彩。

　　每个MIME类型由两部分组成，前面是数据的大类别，例如声音audio、图象image等，后面定义具体的种类。

常见的MIME类型
超文本标记语言文本 .html,.html text/html
普通文本 .txt text/plain
RTF文本 .rtf application/rtf
GIF图形 .gif image/gif
JPEG图形 .ipeg,.jpg image/jpeg
au声音文件 .au audio/basic
MIDI音乐文件 mid,.midi audio/midi,audio/x-midi
RealAudio音乐文件 .ra, .ram audio/x-pn-realaudio
MPEG文件 .mpg,.mpeg video/mpeg
AVI文件 .avi video/x-msvideo
GZIP文件 .gz application/x-gzip
TAR文件 .tar application/x-tar

　　Internet中有一个专门组织IANA来确认标准的MIME类型，但Internet发展的太快，很多应用程序等不及IANA来确认他们使用的MIME类型为标准类型。因此他们使用在类别中以x-开头的方法标识这个类别还没有成为标准，例如：x-gzip，x-tar等。事实上这些类型运用的很广泛，已经成为了事实标准。只要客户机和服务器共同承认这个MIME类型，即使它是不标准的类型也没有关系，客户程序就能根据MIME类型，采用具体的处理手段来处理数据。而Web服务器和浏览器（包括操作系统）中，缺省都设置了标准的和常见的MIME类型，只有对于不常见的 MIME类型，才需要同时设置服务器和客户浏览器，以进行识别。

　　由于MIME类型与文档的后缀相关，因此服务器使用文档的后缀来区分不同文件的MIME类型，服务器中必须定义文档后缀和MIME类型之间的对应关系。而客户程序从服务器上接收数据的时候，它只是从服务器接受数据流，并不了解文档的名字，因此服务器必须使用附加信息来告诉客户程序数据的MIME类型。服务器在发送真正的数据之前，就要先发送标志数据的MIME类型的信息，这个信息使用Content-type关键字进行定义，例如对于HTML文档，服务器将首先发送以下两行MIME标识信息,这个标识并不是真正的数据文件的一部分。

　　Content-type: text/html

　　注意，第二行为一个空行，这是必须的，使用这个空行的目的是将MIME信息与真正的数据内容分隔开。

    * CGI与SSI

　　普通服务器返回的文档为静态的HTML文档，文档中的内容为静态的。而很多情况下，需要根据浏览器发送请求时的条件改变浏览器返回的文档的内容。有些情况下，服务器能提供更复杂的功能，如通过浏览器登记用户的信息等，这些情况就要求Web服务器能根据请求运行一些特定的应用程序，来完成更复杂的服务功能。

　　返回动态文档的基本方法是使用通用网关接口CGI，它定义了Web服务器和由它执行的程序共享信息的方法。这样Web服务器可以根据浏览器的请求，在服务器端运行CGI程序，这个程序可以根据HTTP服务器设置的各种环境变量、服务器磁盘文件中保存的相关信息、以及服务器输入的客户端的请求信息，创建动态网页，并通过服务器返回给浏览器。CGI 标准十分简单，一个CGI程序就是一个标准Unix程序，它从命令行参数和标准输入中获得用户在浏览器上输入的信息，使用环境变量获得当前浏览客户的设置情况，最后使用标准输出输出它创建的动态网页。因此可以使用各种编程语言编写 CGI程序，如sh、C或Perl。

　　可以使用C这样的编译型语言来编写CGI程序，也可以使用解释型的语言来编写CGI程序，这两种方法各有优劣。使用C编程效率较高，但由于要处理的内容大部分为文本，因此需要大量的编写、调试工作，效率不高。而解释型语言编写、调试程序比较容易，并且由于大部分解释语言都有强大的内建文本处理功能，本身就比较适合处理文档，因此解释语言在CGI 编写方面有一定的优势。例如Perl语言本身功能就十分强大，是用于CGI编程一种主要编程语言工具。但是解释型的语言本身存在效率问题，服务器执行解释型的CGI程序时首先要将解释语言器载入内存，这增加了服务器的额外开销。

　　CGI需要启动一个额外的CGI程序以创建动态文档，由于每处理一个CGI请求都要启动一个进程，这样就加重了服务器端的负担。另一种产生动态文档的方式是使用服务器端分析文档，HTTP服务器不启动外部CGI程序来产生动态文档，而是由服务器本身分析要返回的html文档，对其中的一些特殊标记进行解释，并根据情况生成为符合HTML语法的具体数据，从而产生动态HTML文档。显然服务器端分析文档需要特殊功能的服务器，因此与CGI不同，并不存在服务器分析文档的标准。常见的服务器端分析方式有SSI、PHP、ASP等，然而由于这并不是标准，Web服务器可以有选择的支持这些特殊功能。

　　最基本的服务器分析文档标准为SSI（Server Side Include），它能快速的处理一些简单的标志，使得创建动态HTML文档更为容易。SSI主要是采用宏替换的方式处理网页，当一个使用SSI处理过的HTML 文件被返回给浏览器时，有些与文档本身相关的信息，如文档最后一次修改时间等原本在HTML文档中使用特殊的标记来表示的信息，都会被替换为正确的数据。

未完，待续。。。　　

probing

安装和设置Apache

　　由于HTTP协议比较简单，因此Web服务器软件相当多，但是性能、可靠性、功能等都非常优秀的却并不是很多。当前最流行的Web服务器软件是Apache，它基于几年前相当流行的一种Web服务器NCSA-httpd，并增加了很多新的特点，以增加功能和提高效率，因此它的使用非常流行。

　　Apache的网址为http://www.apache.org，这里� ... �站点中获得。

　　Apache可以运行在各种操作系统──从Unix到Windows系统上，易于安装和配置，提供了很多较新的特性，例如它支持模块功能，很容易就能通过增加新的模块以增加新的服务器功能。Apache和FreeBSD结合起来，提供了出色的稳定性和性能，非常适合建立重负载的专业Web站点。

　　在FreeBSD上安装Apache服务器非常容易，可以使用Packages Collection安装A pache服务器的二进制版。然而，如果是基于特殊目的而需要调整Apache支持的模块，就需要重新编译Apache 。重新编译可以使用Ports Collection进行编译和安装。

　　在Ports Collection中，提供了好几个版本的Apache服务器，其中一些属于Apache 1.2.x版本，而另一些为Apache 1.3版本，即使是同一个Apache版本，也提供了使用了不同模块支持的 Apache。当前应该选择Apache 1.3版本，第一次安装可以选择基本版本apache13，这个版本中没有提供额外的模块支持，此后当正式使用Apache的时候，会需要加入SSL支持和PHP3支持，因此应该选择 apach13-modssl或apache13-php3版本。其中基本版本apache13和apache13-php3 有预编译的二进制软件包。

    *
      基本安装

　　使用Packages Collection或Ports Collection可以轻松安装Apache服务器。安装时将缺省设置文件复制到了/usr/local/etc/apache目录下，除了这些标准的设置文件之外，这些设置文件还有对应的以.default为后缀的备份，如果万一设置文件被破坏，可以使用这些备份来恢复缺省配置文件。而缺省配置文件中的文档目录为/usr/local/www/data，指向随同软件一起安装的apache文档，CGI程序的目录为/usr/local/www/cgi-bin。

　　在稍早的版本中，缺省配置文件和文档路径并没有直接安装好，而仅仅安装了以.default结尾的备份文件，以及cgi-bin.default,data.default目录。以提醒使用者修改缺省配置文件。将这些.def ault结尾的文件和目录复制为不包括.default后缀的文件和目录就能得到正确的设置。

　　缺省设置并不一定百分之百保证能启动Apache服务器，缺省设置适合绝大多数情况，但不能保证没有特殊情况发生，例如服务器没有正确的配置名字等。一般情况下，不需要更改缺省设置就可以直接启动Apache服务器了，但即使如此，使用者也需要根据自己的实际情况更改设置文件，例如修改管理员的电子邮件地址等。如果Apache服务器不能正常启动，也没有关系，这仅仅说明缺省设置不适合该计算机的实际情况，可以通过调整设置参数来进行修正。

　　Ports Collection安装的缺省设置文件并不是Apache软件包中直接附带的模板文件，而是P ort的维护者根据FreeBSD环境加以更改之后的设置，因此适合大部分FreeBSD环境，基本上不进行改动就能启动Apache。

　　安装完毕之后，就可以尝试启动Apache服务器了，通常可以使用apachectl程序来完成这个操作。

# /usr/local/sbin/apachectl start

　　如果安装的apache为较早的1.2.x系列版本，那么可能不存在apachectl这个管理命令，可以通过安装到/usr/local/etc/rc.d目录中的启动脚本apache.sh来启动Apache。或者直接执行Apache服务器的守护进程程序──httpd。

# /usr/local/etc/rc.d/apache.sh start

　　在提供了apachectl命令的Apache 1.3版本，apache.sh实际是调用这个命令启动和停止服务器。

　　当服务器启动之后，就可以使用浏览器来查看服务器是否回应http请求，可以使用X Window下的Net scpe Navigtor，然而更方便的工具为字符界面的浏览器lynx。对于进行管理和维护来讲，还可以使用te lnet向Web服务器直接发送控制命令，为了验证服务器是否正常运行，不需要请求某个文档，只需要发送HEAD请求就可以了。

$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /http/1.0
HTTP/1.0 200 OK
Date:

　　如果服务器能象这个例子一样回应对80端口的连接请求，并对用户输入的请求命令返回一定的结果，那么就说明A pache服务器安装和运行一切正常。此时如果使用浏览器访问这个使用缺省设置的服务器，那么就将看到Apache的文档。这是因为缺省页面被设置为了Apache文档，此后Web管理员可以将/usr/local/www/data 目录更改为真正要对外发布的网页文档目录，使得系统真正能对外提供Web服务。

未完，待续。。。　　

probing

配置Apache服务器(1)

　　Apache服务器的设置文件位于/usr/local/etc/apache目录下，传统上使用三个配置文件httpd.conf,access.conf和srm.conf，来配置Apache服务器的行为。httpd. conf提供了最基本的服务器配置，是对守护程序httpd如何运行的技术描述；srm.conf是服务器的资源映射文件，告诉服务器各种文件的MIME类型，以及如何支持这些文件；access.conf用于配置服务器的访问权限，控制不同用户和计算机的访问限制；这三个配置文件控制着服务器的各个方面的特性，因此为了正常运行服务器便需要设置好这三个文件。

　　除了这三个设置文件之外，Apache还使用mime.types文件用于标识不同文件对应的MIME类型， magic文件设置不同MIME类型文件的一些特殊标识，使得Apache服务器从文档后缀不能判断出文件的MIME 类型时，能通过文件内容中的这些特殊标记来判断文档的MIME类型。

bash-2.02$ ls -l /usr/local/etc/apache
total 100
-rw-r--r--   1 root  wheel    348 Apr 16 16:01 access.conf
-rw-r--r--   1 root  wheel    348 Feb 13 13:33 access.conf.default
-rw-r--r--   1 root  wheel  30331 May 26 08:55 httpd.conf
-rw-r--r--   1 root  wheel  29953 Feb 13 13:33 httpd.conf.default
-rw-r--r--   1 root  wheel  12441 Apr 19 15:42 magic
-rw-r--r--   1 root  wheel  12441 Feb 13 13:33 magic.default
-rw-r--r--   1 root  wheel   7334 Feb 13 13:33 mime.types
-rw-r--r--   1 root  wheel    383 May 13 17:01 srm.conf
-rw-r--r--   1 root  wheel    357 Feb 13 13:33 srm.conf.default

　　事实上当前版本的Apache将原来httpd.conf、srm.conf与access.conf中的所有配置参数均放在了一个配置文件httpd.conf中，只是为了与以前的版本兼容的原因（使用这三个设置文件的方式来源于NCSA-httpd），才使用三个配置文件。而提供的access.conf和srm.conf文件中没有具体的设置。

　　新版本Apache使用的配置文件为apache.conf，它就等价于httpd.conf。

　　由于在新版本的Apache中，所有的设置都被放在了httpd.conf中，因此只需要调整这个文件中的设置。以下使用缺省提供的httpd.conf为例，解释Apache服务器的各个设置选项。然而不必因为它提供设置的参数太多而烦恼，基本上这些参数都很明确，也可以不加改动运行Apache服务器。但如果需要调整Apache服务器的性能，以及增加对某种特性的支持，就需要了解这些设置参数的含义。

　　关于Apache服务器的性能，在Internet上存在很大的争议，基本上使用过Apache的使用者几乎都不怀疑它的优秀性能，Apache也支撑了很多著名的高负载的网站，但是在商业机构的评测中，Apache往往得分不高。很多人指出，在这些评测中，商业Web服务器及其操作系统往往由其专业公司的工程师进行过性能调整，而Free 的操作系统和Web服务器往往就使用其缺省配置或仅仅作很小的更改。需要指出的是，除了操作系统的性能调整之外，Apache 服务器本身的缺省配置绝不是最优化和最高效的，而是要适应几乎所有种类操作系统、所有种类硬件下的设置，多平台的软件不可能为特定平台和特定硬件提供最优化的缺省配置。因此要使用Apache的时候，性能调整是必不可少的。

　　在商业评测中忽略了的另一个事实是，评测时往往对不同种类的功能进行比较，例如使用Apache的标准CGI 的性能与ISAPI，NSAPI等服务器端API比较，事实上Apache服务器与此可以比较的功能为modperl ，FastCGI，与ASP类似的功能为PHP3等等，只不过由于Apache的开放模式，这些功能是由独立的开发组，作为独立的模块来实现的。但是在评测中，测试人员没有加入相应的模块评测其性能。

    * HTTP守护进程的运行参数

　　httpd.conf中首先定义了一些httpd守护进程运行时需要的参数，来决定其运行方式和运行环境。

　　ServerType standalone

　　ServerType定义服务器的启动方式，缺省值为独立方式standalone，http d服务器将由其本身启动，并驻留在主机中监视连接请求。在FreeBSD下将在启动文件/usr/local/etc /rc.d/apache.sh中自动启动Web服务器，这种方式是推荐设置。

　　启动Apache服务器的另一种方式是inet方式，使用超级服务器inetd监视连接请求并启动服务器。当需要使用inetd启动方式时，便需要更改为这个设置，并屏蔽/usr/local/etc/rc.d/apache .sh文件，以及更改/etc/inetd.conf并重起inetd，那么Apache就能从inetd中启动了。

　　两种方式的区别是独立方式是由服务器自身管理自己的启动进程，这样在启动时能立即启动服务器的多个副本，每个副本都驻留在内存中，一有连接请求不需要生成子进程就可以立即进行处理，对于客户浏览器的请求反应更快，性能较高。而 inetd方式要由inetd发现有连接请求后才去启动http服务器，由于inetd要监听太多的端口，因此反应较慢、效率较低，但节约了没有连接请求时Web服务器占用的资源。因此inetd方式只用于偶尔被访问并且不要求访问速度的服务器上。事实上inetd方式不适合http的突发和多连接的特性，因为一个页面可能包含多个图象，而每个图象都会引起一个连接请求，即使虽然访问人数造成教少，但瞬间的连接请求并不少，这就受到inetd性能的限制，甚至会影响由inetd启动的其他服务器程序。

　　ServerRoot "/usr/local"

　　ServerRoot用于指定守护进程httpd的运行目录，httpd在启动之后将自动将进程的当前目录改变为这个目录，因此如果设置文件中指定的文件或目录是相对路径，那么真实路径就位于这个ServerR oot定义的路径之下。

　　由于httpd会经常进行并发的文件操作，就需要使用加锁的方式来保证文件操作不冲突，由于NFS文件系统在文件加锁方面能力有限，因此这个目录应该是本地磁盘文件系统，而不应该使用NFS文件系统。

　　#LockFile /var/run/httpd.lock

　　LockFile参数指定了httpd守护进程的加锁文件，一般不需要设置这个参数，Apac he服务器将自动在ServerRoot下面的路径中进行操作。但如果ServerRoot为NFS文件系统，便需要使用这个参数指定本地文件系统中的路径。

　　PidFile /var/run/httpd.pid

　　PidFile指定的文件将记录httpd守护进程的进程号，由于httpd能自动复制其自身，因此系统中有多个httpd进程，但只有一个进程为最初启动的进程，它为其他进程的父进程，对这个进程发送信号将影响所有的httpd进程。PidFILE定义的文件中就记录httpd父进程的进程号。

　　ScoreBoardFile /var/run/httpd.scoreboard

　　httpd使用ScoreBoardFile来维护进程的内部数据，因此通常不需要改变这个参数，除非管理员想在一台计算机上运行几个Apache服务器，这时每个Apache服务器都需要独立的设置文件htt pd.conf，并使用不同的ScoreBoardFile。

　　#ResourceConfig conf/srm.conf
　　#AccessConfig conf/access.conf

　　这两个参数ResourceConfig和AccessConfig，就用于和使用srm.conf和access.conf设置文件的老版本Apache兼容。如果没有兼容的需要，可以将对应的设置文件指定为/dev/null，这将表示不存在其他设置文件，而仅使用httpd.conf一个文件来保存所有的设置选项。

　　Timeout 300

　　Timeout定义客户程序和服务器连接的超时间隔，超过这个时间间隔（秒）后服务器将断开与客户机的连接。

　　KeepAlive On

　　在HTTP 1.0中，一次连接只能作传输一次HTTP请求，而KeepAlive参数用于支持HTTP 1.1版本的一次连接、多次传输功能，这样就可以在一次连接中传递多个HTTP请求。虽然只有较新的浏览器才支持这个功能，但还是打开使用这个选项。

　　MaxKeepAliveRequests 100

　　MaxKeepAliveRequests为一次连接可以进行的HTTP请求的最大请求次数。将其值设为0将支持在一次连接内进行无限次的传输请求。事实上没有客户程序在一次连接中请求太多的页面，通常达不到这个上限就完成连接了。

　　KeepAliveTimeout 15

　　KeepAliveTimeout测试一次连接中的多次请求传输之间的时间，如果服务器已经完成了一次请求，但一直没有接收到客户程序的下一次请求，在间隔超过了这个参数设置的值之后，服务器就断开连接。

　　MinSpareServers 5MaxSpareServers 10

　　在使用子进程处理HTTP请求的Web服务器上，由于要首先生成子进程才能处理客户的请求，因此反应时间就有一点延迟。但是，Apache服务器使用了一个特殊技术来摆脱这个问题，这就是预先生成多个空余的子进程驻留在系统中，一旦有请求出现，就立即使用这些空余的子进程进行处理，这样就不存在生成子进程造成的延迟了。在运行中随着客户请求的增多，启动的子进程会随之增多，但这些服务器副本在处理完一次HTTP请求之后并不立即退出，而是停留在计算机中等待下次请求。但是空余的子进程副本不能光增加不减少，太多的空余子进程没有处理任务，也占用服务器的处理能力，因此也要限制空余副本的数量，使其保持一个合适的数量，使得既能及时回应客户请求，又能减少不必要的进程数量。

　　因此就可以使用参数MinSpareServers来设置最少的空余子进程数量， 以及使用参数MaxSpareServers 来限制最多的空闲子进程数量，多余的服务器进程副本就会退出。根据服务器的实际情况来进行设置，如果服务器性能较高，并且也被频繁访问，就应该增大这两个参数的设置。对于高负载的专业网站，这两个值应该大致相同，并且等同于系统支持的最多服务器副本数量，也减少不必要的副本退出。

　　StartServers 5

　　StartServers参数就是用来设置httpd启动时启动的子进程副本数量，这个参数与上面定义的MinSpareServers和MaxSpareServers参数相关，都是用于启动空闲子进程以提高服务器的反应速度的。这个参数应该设置为前两个值之间的一个数值，小于MinSpareServers和大于MaxS pareServers都没有意义。

　　MaxClients 150

　　在另一方面，服务器的能力毕竟是有限的，不可能同时处理无限多的连接请求，因此参数Maxclient s就用于规定服务器支持的最多并发访问的客户数，如果这个值设置得过大，系统在繁忙时不得不在过多的进程之间进行切换来为太多的客户进行服务，这样对每个客户的反应就会减慢，并降低了整体的效率。如果这个值设置的较小，那么系统繁忙时就会拒绝一些客户的连接请求。当服务器性能较高时，就可以适当增加这个值的设置。对于专业网站，应该使用提高服务器效率的策略，因此这个参数不能超过硬件本身的限制，如果频繁出现拒绝访问现象，就说明需要升级服务器硬件了。对于非专业网站，不太在意对客户浏览器的反应速度，或者认为反应速度较慢也比拒绝连接好，就也可以略微超过硬件条件来设置这个参数。

　　这个参数限制了MinSpareServers和MaxSpareServers的设置，它们不应该大于这个参数的设置。

　　MaxRequestsPerChild 30

　　使用子进程的方式提供服务的Web服务，常用的方式是一个子进程为一次连接服务，这样造成的问题就是每次连接都需要生成、退出子进程的系统操作，使得这些额外的处理过程占据了计算机的大量处理能力。因此最好的方式是一个子进程可以为多次连接请求服务，这样就不需要这些生成、退出进程的系统消耗，Apache就采用了这样的方式，一次连接结束后，子进程并不退出，而是停留在系统中等待下一次服务请求，这样就极大的提高了性能。

　　但由于在处理过程中子进程要不断的申请和释放内存，次数多了就会造成一些内存垃圾，就会影响系统的稳定性，并且影响系统资源的有效利用。因此在一个副本处理过一定次数的请求之后，就可以让这个子进程副本退出，再从原始的htt pd进程中重新复制一个干净的副本，这样就能提高系统的稳定性。这样，每个子进程处理服务请求次数由MaxRe questPerChild定义。 缺省的设置值为30，这个值对于具备高稳定性特点的FreeBSD系统来讲是过于保守的设置，可以设置为1000甚至更高，设置为0支持每个副本进行无限次的服务处理。

　　#Listen 3000
　　#Listen 12.34.56.78:80
　　#BindAddress *

　　Listen参数可以指定服务器除了监视标准的80端口之外，还监视其他端口的HTTP请求。由于FreeBSD系统可以同时拥有多个IP地址，因此也可以指定服务器只听取对某个BindAddress< /B>的IP地址的HTTP请求。如果没有配置这一项，则服务器会回应对所有IP的请求。

　　即使使用了BindAddress参数，使得服务器只回应对一个IP地址的请求，但是通过使用扩展的Listen参数，仍然可以让HTTP守护进程回应对其他IP地址的请求。此时Listen参数的用法与上面的第二个例子相同。这种比较复杂的用法主要用于设置虚拟主机。此后可以用VirtualHost参数定义对不同IP的虚拟主机，然而这种用法是较早的HTTP 1.0标准中设置虚拟主机的方法，每针对一个虚拟主机就需要一个IP地址，实际上用处并不大。在HTTP 1.1中，增加了对单IP地址多域名的虚拟主机的支持，使得虚拟主机的设置具备更大的意义。

LoadModule mime_magic_module  libexec/apache/mod_mime_magic.so
LoadModule info_module        libexec/apache/mod_info.so
LoadModule speling_module     libexec/apache/mod_speling.so
LoadModule proxy_module       libexec/apache/libproxy.so
LoadModule rewrite_module     libexec/apache/mod_rewrite.so
LoadModule anon_auth_module   libexec/apache/mod_auth_anon.so
LoadModule db_auth_module     libexec/apache/mod_auth_db.so
LoadModule digest_module      libexec/apache/mod_digest.so
LoadModule cern_meta_module   libexec/apache/mod_cern_meta.so
LoadModule expires_module     libexec/apache/mod_expires.so
LoadModule headers_module     libexec/apache/mod_headers.so
LoadModule usertrack_module   libexec/apache/mod_usertrack.so
LoadModule unique_id_module   libexec/apache/mod_unique_id.so

ClearModuleList
AddModule mod_env.c
AddModule mod_log_config.c
AddModule mod_mime_magic.c
AddModule mod_mime.c
AddModule mod_negotiation.c
AddModule mod_status.c
AddModule mod_info.c
AddModule mod_include.c
AddModule mod_autoindex.c
AddModule mod_dir.c
AddModule mod_cgi.c
AddModule mod_asis.c
AddModule mod_imap.c
AddModule mod_actions.c
AddModule mod_speling.c
AddModule mod_userdir.c
AddModule mod_proxy.c
AddModule mod_alias.c
AddModule mod_rewrite.c
AddModule mod_access.c
AddModule mod_auth.c
AddModule mod_auth_anon.c
AddModule mod_auth_db.c
AddModule mod_digest.c
AddModule mod_cern_meta.c
AddModule mod_expires.c
AddModule mod_headers.c
AddModule mod_usertrack.c
AddModule mod_unique_id.c
AddModule mod_so.c
AddModule mod_setenvif.c

　　Apache服务器的一个重要特性就是其模块化的结构，这不但表现为其能在编译时能通过新的模块加入新的功能，还表现为其模块可以动态加载入http服务程序中，而不必载入不需要的模块。使用Apache的动态加载模块只需要设置好LoadModule和AddModule参数就可以了，这种特性就是Apache的 DSO（Dynamic Shared Object）特性，然而要想充分使用DSO特性仍然不是一个简单的事情，不适当的改动这里的设置就可能造成服务器不能正常启动。因此如果不是要增加或减少服务器提供的功能，就不要改动这里的设置。

　　上面这些列表就显示了FreeBSD下的缺省Apache服务器支持的模块，事实上很多模块是没有必要的，不必要模块不会被载入内存。模块可以静态连接到Apache服务器内部，也可以这样动态加载，将Apache的特性都编译成动态可加载模块是该Port的做法，而不是Apache的缺省做法，这样就以牺牲很小的性能的同时，带来极大的灵活性。

　　因而动态可加载的能力还是对性能有轻微的影响，因此可以重新编译Apache，将自己所需要的功能编译进Apache 服务器内部，可以让系统显得更为干净，效率也有轻微的提高。通常仅仅为了这一个目的就重新编译Apache是没有必要的，如果需要增加其他特性而重新编译Apache，不妨在增加其他模块的同时将所有的模块都静态连接入Apache 服务器。有的使用者更喜欢动态加载模块，那么也不妨全部都使用动态加载模块。

　　这些模块都被Ports Collection放置到/usr/local/libexec/apache目录下，每个模块对应Apache服务器的一个特性。详细解释每个模块的功能需要相当多的篇幅，其中比较重要的特性将在后面相应的地方中进行解释，而具体每个模块的功能及用法就需要查看Apache的文档。

　　#ExtendedStatus On

　　Apache服务器可以通过特殊的HTTP请求，来报告自身的运行状态，打开这个ExtendedStatus 参数可以让服务器报告更全面的运行状态信息。

未完，待续。。。　　

probing

配置Apache服务器(2)

    * 主服务器设置

　　Apache服务器需要各种设置，以定义自己使用各种参数以提供Web服务。对于使用虚拟主机的情况，除了在虚拟主机的定义项中覆盖的设置之外（有的设置必须重新定义），这里的设置也是虚拟主机的缺省设置。

　　Port 80

　　Port定义了Standalone模式下httpd守护进程使用的端口，标准端口是80。这个选项只对于以独立方式启动的服务器才有效，对于以inetd方式启动的服务器则在inetd.conf中定义使用哪个端口。

　　在Unix下使用80端口需要root权限，一些管理员为了安全的原因，认为httpd服务器不可能没有安全漏洞，因而更愿意使用普通用户的权限来启动服务器，这样就不能使用80端口及其他小于1024的端口，而必须使用大于 1024的端口来启动httpd，一般情况下8000或8080也是常用的端口。而Apache httpd服务器本身可以在以root权限打开80端口后再改变为普通用户身份进行运行，这样就减少了危险性，因而就不需要考虑这个安全问题。但是如果普通用户也想安装配置自己的WWW服务器，那么就不得不使用大于1024的端口，当然普通用户不能使用 Ports Collection进行编译安装，而必须手工编译安装。

　　User nobody

　　Group nogroup

　　User和Group配置是Apache的安全保证，Apache在打开端口之后，就将其本身设置为这两个选项设置的用户和组权限进行运行，这样就降低了服务器的危险性。这个选项也只用于 Standalone模式，inetd模式在inetd.conf中指定运行Apache的用户。由于服务器必须执行改变身份的setuid()操作，因此初始进程应该具备root权限，如果是使用非root用户来启动Aapche，这个配置就不会发挥作用。

　　缺省设置为nobody和nogroup，这个用户和组在系统中不拥有文件，保证了服务器本身和由它启动的CGI 进程没有权限更改文件系统。在某些情况下，例如为了运行CGI与Unix交互，也需要让服务器来访问服务器上的文件，如果仍然使用nobody和nogroup，那么系统中将会出现属于nobody的文件，这对于系统安全是不利的，因为其他程序也会以nobody和nogroup的权限执行某些操作，就有可能访问这些nobody拥有的文件，造成安全问题。一般情况下要为Web服务设定一个特定的用户和组，同时在这里更改用户和组设置。

　　ServerAdmin you@your.address

　　配置文件中应该改变的也许只有ServerAdmin， 这一项用于配置WWW服务器的管理员的email地址，这将在HTTP服务出现错误的条件下返回给浏览器，以便让Web使用者和管理员联系，报告错误。习惯上使用服务器上的webmaster作为WWW服务器的管理员，通过邮件服务器的别名机制，将发送到webmaster 的电子邮件发送给真正的Web管理员。

　　#ServerName new.host.name

　　缺省情况下，并不需要指定这个ServerName参数，服务器将自动通过名字解析过程来获得自己的名字，但如果服务器的名字解析有问题（通常为反向解析不正确），或者没有正式的DNS名字，也可以在这里指定I P地址。当ServerName设置不正确的时候，服务器不能正常启动。

　　通常一个Web服务器可以具有多个名字，客户浏览器可以使用所有这些名字或IP地址来访问这台服务器，但在没有定义虚拟主机的情况下，服务器总是以自己的正式名字回应浏览器。ServerName就定义了Web服务器自己承认的正式名字，例如一台服务器名字（在DNS中定义了A类型）为freebsd.exmaple.org.cn，同时为了方便记忆还定义了一个别名（CNAME记录）为www.exmaple.org.cn，那么Apach ... �其书签中使用 freebsd记录下这个服务器的地址，就必须使用ServerName来重新指定服务器的正式名字。

　　DocumentRoot "/usr/local/www/data"

　　DocumentRoot定义这个服务器对外发布的超文本文档存放的路径，客户程序请求的UR L就被映射为这个目录下的网页文件。这个目录下的子目录，以及使用符号连接指出的文件和目录都能被浏览器访问，只是要在URL上使用同样的相对目录名。

　　注意，符号连接虽然逻辑上位于根文档目录之下，但实际上可以位于计算机上的任意目录中，因此可以使客户程序能访问那些根文档目录之外的目录，这在增加了灵活性的同时但减少了安全性。Apache在目录的访问控制中提供了Fol lowSymLinks选项来打开或关闭支持符号连接的特性。


    Options FollowSymLinks
    AllowOverride None

　　Apache服务器可以针对目录进行文档的访问控制，然而访问控制可以通过两种方式来实现，一个是在设置文件 httpd.conf（或access.conf）中针对每个目录进行设置，另一个方法是在每个目录下设置访问控制文件，通常访问控制文件名字为.htaccess。虽然使用这两个方式都能用于控制浏览器的访问，然而使用配置文件的方法要求每次改动后重新启动httpd守护进程，比较不灵活，因此主要用于配置服务器系统的整体安全控制策略，而使用每个目录下的.htaccess文件设置具体目录的访问控制更为灵活方便。

　　Directory语句就是用来定义目录的访问限制的，这里可以看出它的标准语法，为一个目录定义访问限制。上例的这个设置是针对系统的根目录进行的，设置了允许符号连接的选项FollowSymLinks ，以及使用AllowOverride None表示不允许这个目录下的访问控制文件来改变这里进行的配置，这也意味着不用查看这个目录下的相应访问控制文件。

　　由于Apache对一个目录的访问控制设置是能够被下一级目录继承的，因此对根目录的设置将影响到它的下级目录。注意由于AllowOverride None的设置，使得Apache服务器不需要查看根目录下的访问控制文件，也不需要查看以下各级目录下的访问控制文件，直至httpd.conf（或access.conf ）中为某个目录指定了允许Alloworride，即允许查看访问控制文件。由于Apache对目录访问控制是采用的继承方式，如果从根目录就允许查看访问控制文件，那么Apache就必须一级一级的查看访问控制文件，对系统性能会造成影响。而缺省关闭了根目录的这个特性，就使得Apache从httpd.conf中具体指定的目录向下搜寻，减少了搜寻的级数，增加了系统性能。因此对于系统根目录设置AllowOverride None不但对于系统安全有帮助，也有益于系统性能。


    Options Indexes FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all

　　这里定义的是系统对外发布文档的目录的访问设置，设置不同的AllowOverride选项，以定义配置文件中的目录设置和用户目录下的安全控制文件的关系，而Options选项用于定义该目录的特性。

　　配置文件和每个目录下的访问控制文件都可以设置访问限制，设置文件是由管理员设置的，而每个目录下的访问控制文件是由目录的属主设置的，因此管理员可以规定目录的属主是否能覆盖系统在设置文件中的设置，这就需要使用 AllowOverride参数进行设置，通常可以设置的值为：
AllowOverride的设置 对每个目录访问控制文件作用的影响
All 缺省值，使访问控制文件可以覆盖系统配置
None 服务器忽略访问控制文件的设置
Options 允许访问控制文件中可以使用Options参数定义目录的选项
FileInfo 允许访问控制文件中可以使用AddType等参数设置
AuthConfig 允许访问控制文件使用AuthName，AuthType等针对每个用户的认证机制，这使目录属主能用口令和用户名来保护目录
Limit 允许对访问目录的客户机的IP地址和名字进行限制

　　每个目录具备一定属性，可以使用Options来控制这个目录下的一些访问特性设置，以下为常用的特性选项：
Options设置 服务器特性设置
All 所有的目录特性都有效，这是缺省状态
None 所有的目录特性都无效
FollowSymLinks 允许使用符号连接，这将使浏览器有可能访问文档根目录（DocumentRoot）之外的文档
SymLinksIfOwnerMatch 只有符号连接的目的与符号连接本身为同一用户所拥有时，才允许访问，这个设置将增加一些安全性
ExecCGI 允许这个目录下可以执行CGI程序
Indexes 允许浏览器可以生成这个目录下所有文件的索引，使得在这个目录下没有index.html（或其他索引文件）时，能向浏览器发送这个目录下的文件列表

　　此外，上例中还使用了Order、Allow、Deny等参数，这是Limit语句中用来根据浏览器的域名和 IP地址来控制访问的一种方式。其中Order定义处理Allow和Deny的顺序，而Allow、Deny则针对名字或IP进行访问控制设置，上例使用allow from all，表示允许所有的客户机访问这个目录，而不进行任何限制。

　　UserDir public_html

　　当在一台FreeBSD上运行Apache服务器时，这台计算机上的所有用户都可以有自己的网页路径，形如 http://freebsd.example.org.cn/~u ... r的参数即可。

#
#    AllowOverride FileInfo AuthConfig Limit
#    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
#   
#        Order allow,deny
#        Allow from all
#   
#   
#        Order deny,allow
#        Deny from all
#   
#

　　这里可以看到Directory的另一个用法，即可以通过简单的模式匹配方法，针对分布在不同目录下的子目录定义访问控制权限。这样设置就需要Apache服务器对每个路径进行额外的处理，因此就会降低服务器的性能，所以缺省情况并没有打开这种访问限制。

　　这里可以看到另外一个语句Limit，Limit语句就是用来针对具体的请求方法来设定访问控制的，其中可以使用GET、POST等各种服务器支持的请求方法做Limit的参数，来设定对不同请求方法的访问限制。一般可以打开对GET、POST、HEAD三种请求方法，而屏蔽其他的请求方法，以增加安全性。Limit语句中，可以使用Order 、Allow、Deny，Allow和Deny中可以使用匹配的方法针对域名和IP进行限制，只是对于域名是从后向前匹配，对于IP地址则从前向后匹配。

　　DirectoryIndex index.html

　　很多情况下，URL中并没有指定文档的名字，而只是给出了一个目录名。那么Apache服务器就自动返回这个目录下由DirectoryIndex定义的文件，当然可以指定多个文件名字，系统会这个目录下顺序搜索。当所有由DirectoryIndex指定的文件都不存在时，Apache服务器可以根据系统设置，生成这个目录下的所有文件列表，提供用户选择。此时该目录的访问控制选项中的Indexes选项（Options Indexes ）必须打开，以使得服务器能够生成目录列表，否则Apache将拒绝访问。

　　AccessFileName .htaccess

　　AccessFileName定义每个目录下的访问控制文件的文件名，缺省为.htaccess ，可以通过更改这个文件，来改变不同目录的访问控制限制。


    Order allow,deny
    Deny from all

　　除了可以针对目录进行访问控制之外，还可以根据文件来设置访问控制，这就是File语句的任务。使用File 语句，不管文件处于哪个目录，只要名字匹配，就必须接受相应的访问控制。这个语句对于系统安全比较重要，例如上例将屏蔽所有的使用者不能访问.htaccess文件，这样就避免.htaccess中的关键安全信息不至于被客户获取。

　　#CacheNegotiatedDocs

　　缺省情况下如果代理服务器和Apache服务器协商是否缓存其网页，Apache给予否定的回答，不希望自己的网页被代理服务器缓存。然而这样就不能有效的利用代理服务器的优势，因此可以设置CacheNegotiatieDocs 选项， 使得代理服务器可以对网页进行缓存。然而即使不设置这个选项，有的代理服务器（或通过调整设置）也能对网页进行缓存。

　　UseCanonicalName On

　　打开这个UseCanonicalName是Web服务器的标准做法，因为客户发送的大部分请求都是对本服务器的引用，这样服务器就能使用ServerName和Port选项的设置内容构建完整的URL，并回应客户，使浏览器能得到规范的URL。如果将这个参数设置为Off，那么Apache将使用从客户请求中获得服务器的名字和端口值（支持HTTP 1.1的客户的请求中将会有这些信息），重新构建URL。

　　TypesConfig /usr/local/etc/apache/mime.types

　　TypeConfig用于设置保存有不同的MIME类型数据的文件名，在FreeBSD下缺省设置为/usr/local/etc/apache/mime.types。

　　DefaultType text/plain

　　如果Web服务器不能决定一个文档的缺省类型，这通常表示文档使用了非标准的后缀，那么服务器就使用 DefaultType定义的MIME类型将文档发送给客户浏览器。这里的设置为text/plain，这样设置的问题是，如果服务器不能判断出文档的MIME，那么大部分情况下这个文档为一个二进制文档，但使用 text/plain格式发送回去，浏览器将在内部打开它而不会提示保存。因此建议将这个设置更改为 application/octet-stream，这样浏览器将提示用户进行保存。


    MIMEMagicFile /usr/local/etc/apache/magic

　　除了从文件的后缀出发来判断文件的MIME类型之外，Apache还可以进一步分析文件的一些特征，来判断文件的真实MIME类型。这个功能是由mod_mime_magic模块实现的，它需要一个记录各种MIME类型特征的文件，以进行分析判断。上面的设置是一个条件语句，如果载入了这个模块，就必须指定相应的标志文件magic的位置。

　　HostnameLookups Off

　　通常连接时，服务器仅仅可以得到客户机的IP地址，如果要想获得客户机的主机名，以进行日志记录和提供给 CGI程序使用，就需要使用这个HostnameLookups选项，将其设置为On打开DNS反查功能。但是这将使服务器对每次客户请求都进行DNS查询，增加了系统开销，使得反应变慢，因此缺省设置为使用Off关闭此选项。关闭选项之后，服务器就不会获得客户机的主机名，而只能使用IP地址来记录客户。

ErrorLog /var/log/httpd-error.log
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
#CustomLog /var/log/httpd-access.log common
#CustomLog /var/log/httpd-referer.log referer
#CustomLog /var/log/httpd-agent.log agent
CustomLog /var/log/httpd-access.log combined

　　这里定义了系统日志的形式，对于服务器错误记录， 由ErrorLog、LogLevel 来定义不同的错误日志文件及其记录内容。

　　对于系统的访问日志，缺省使用CustomLog参数定义日志的位置，缺省使用combined 参数指定将所有的访问日志放在一个文件中，然而也可以将不同种类的访问日志放在不同的日志记录文件中，这是通过在 CustomLog中指定不同的记录类型来完成的。common表示普通的对单页面请求访问记录，referer表示每个页面的引用记录，可以看出一个页面中包含的请求数，agent表示对客户机的类型记录，显然可以将现有的combined 定义的设置行注释掉，并使用common、referer和agent作为CustomLog的参数，来为不同种类的日志分别指定日志记录文件。

　　显然，LogFormat是用于定义不同类型的日志进行记录时使用的格式， 这里使用了以%开头的宏定义，以记录不同的内容。

　　如果这些参数指定的文件使用的是相对路径，那么就是相对于ServerRoot的路径。

　　ServerSignature On

　　一些情况下，例如当客户请求的网页并不存在时，服务器将产生错误文档，缺省情况下由于打开了 ServerSignature选项，错误文档的最后一行将包含服务器的名字、Apache的版本等信息。有的管理员更倾向于不对外显示这些信息，就可以将这个参数设置为Off，或者设置为Email，最后一行将替换为对ServerAdmin 的Email提示。

Alias /icons/ "/usr/local/www/icons/"

    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all

　　Alias参数用于将URL与服务器文件系统中的真实位置进行直接映射，一般的文档将在DocumentRoot 中进行查询，然而使用Alias定义的路径将直接映射到相应目录下，而不再到DocumentRoot 下面进行查询。因此Alias可以用来映射一些公用文件的路径，例如保存了各种常用图标的icons路径。这样使得除了使用符号连接之外，文档根目录（DocumentRoot）外的目录也可以通过使用了Alias映射，提供给浏览器访问。

　　定义好映射的路径之后，应该需要使用Directory语句设置访问限制。

ScriptAlias /cgi-bin/ "/usr/local/www/cgi-bin/"

    AllowOverride None
    Options None
    Order allow,deny
    Allow from all

　　ScriptAlias也是用于URL路径的映射，但与Alias的不同在于，ScriptAlias是用于映射CGI程序的路径，这个路径下的文件都被定义为CGI程序，通过执行它们来获得结果，而非由服务器直接返回其内容。缺省情况下CGI程序使用cgi-bin目录作为虚拟路径。

　　# Redirect old-URI new-URL

　　Redirect参数是用来重写URL的，当浏览器访问服务器上的一个已经不存在的资源的时候，服务器返回给浏览器新的URL，告诉浏览器从该URL中获取资源。这主要用于原来存在于服务器上的文档，改变了位置之后，而又希望能使用老URL能访问到，以保持与以前的URL兼容。

IndexOptions FancyIndexing
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*
AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core
AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^
DefaultIcon /icons/unknown.gif
#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz
ReadmeName README
HeaderName HEADER
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

　　当一个HTTP请求的URL为一个目录的时候，服务器返回这个目录中的索引文件。但如果一个目录中不存在缺省的索引文件，并且该服务器又许可显示目录文件列表的时候，就会显示出这个目录中的文件列表，为了使得这个文件列表能具有可理解性，而不仅仅是一个简单的列表，就需要前面的这些设置参数。

　　如果使用了IndexOptions FancyIndexing选项，可以让服务器产生的目录列表中针对各种不同类型的文档引用各种图标。而哪种文件使用哪种图标，则使用下面的 AddIconByEncoding、AddIconByType以及AddIcon来定义，分别依据MIME的编码、类型以及文件的后缀来判断使用何种图标。如果不能确定文档使用的图标，就使用 DefaultIcon定义的缺省图标。

　　同样，使用AddDescription可以为不同类型的文档加入不同的描述。并且，服务器还在目录下，查询使用ReadmeName和HeaderName定义的文件（自动加上. html后缀，如果没有发现，再使用.txt后缀进行搜索），如果发现了这些文件，就在文件列表之前首先显示这些文件的内容，以使得普通目录列表具备更大的可理解性。

　　IndexIgnore让服务器在列出文件列表时忽略相应的文件， 这里使用模式配置的方式定义文件名。

AddEncoding x-compress Z
AddEncoding x-gzip gz

　　AddEncoding用于告诉一些使用压缩的MIME类型，这样可以让浏览器进行解压缩操作。

AddLanguage en .en
AddLanguage fr .fr
AddLanguage de .de
AddLanguage da .da
AddLanguage el .el
AddLanguage it .it
LanguagePriority en fr de

　　一个HTML文档可以同时具备多个语言的版本，如对于file1.html文档可以具备file1.html.en、file1.html.fr 等不同的版本，每个语言后缀必须使用AddLanguage进行定义。这样服务器可以针对不同国家的客户，通过与浏览器进行协商，发送不同的语言版本。而LanguagePriority 定义不同语言的优先级，以便在浏览器没有特殊要求时，按照顺序使用不同的语言版本回应对file1.html 的请求。这个国际化的能力实际的应用并不多。

#AddType application/x-httpd-php3 .phtml
#AddType application/x-httpd-php3-source .phps

　　AddType参数可以为特定后缀的文件指定MIME类型，这里的设置将覆盖mime.types中的设置。

　　#AddHandler cgi-script .cgi

　　AddHandler是用于指定非静态的处理类型，用于定义文档为一个非静态的文档类型，需要进行处理，再向浏览器返回处理结果。例如上面注释中的设置是将以.cgi结尾的文件设置为cgi-script类型，那么服务器将启动这个CGI程序以进行处理。如果需要在前面AliasScript定义的路径之外执行CGI程序，就需要使用这个参数进行设置，此后以.cgi结尾的文件将被当作CGI程序执行。

　　在配置文件、这个目录中的.htaccess以及其上级目录的.htaccess中必须允许执行CGI程序，这需要通过Options ExecCGI参数设定。

#AddType text/html .shtml
#AddHandler server-parsed .shtml

　　另外一种动态进行处理的类型为server-parsed，由服务器自身预先分析网页内的标记，将标记更改为正确的HTML标识。由于server-parsed需要对text/html类型的文档进行处理，因此首先定义了对应的.shtml为text/html类型。

　　然而要支持SSI，还要首先要在配置文件（或.htaccess）中使用Options Includes允许该目录下的文档可以为SSI类型，或使用Options IncludesNOExec让执行普通的SSI标志，但不执行其中引用的外部程序。

　　另一种指定server-parsed类型的方式为使用XBitBack设置选项，如果将XBitHack设置为On，服务器将检查所有text/html类型的文档（包括.html后缀的文档），如果发现文件属性具备执行位 “x"，则服务器就认为它是服务器分析文档，需要服务器进行处理。推荐使用AddHandler进行设置，而将XBitBack 设置为Off，因为使用XBitBack将对所有的HTML文档都执行额外的检查，降低了效率。

#AddHandler send-as-is asis
#AddHandler imap-file map
#AddHandler type-map var

　　上面被注释的AddHandler用于支持Apache服务器的asis、map和var处理能力。

# Action media/type /cgi-script/location
# Action handler-name /cgi-script/location

　　因为Apache内部提供的处理功能有限，因此可以使用Action为服务器定义外部程序作为可处理的动态文档类型，这些外部程序与标准CGI程序相同，都是对输入的数据处理之后，再输出不同MIME类型的结果。例如要定义一个对特殊后缀wri都先执行wri2txt进行处理操作，再返回结果的操作，可以使用：

                Action windows-writer /bin/wri2txt
                AddHandler windows-writer wri

　　更进一步，可以直接使用Action定义对某个MIME类型预先进行处理操作，这需要例子中第一种格式的Action 参数设置方式。这样设置方式就不再需要额外的AddHandler用来将处理操作与文件后缀联系起来，而是使用Action直接处理MIME类型的文件。但如果文档后缀没有正式的MIME类型，还需要先定义一个MIME类型。

#MetaDir .web


#MetaSuffix .meta

　　Meta信息是在文档发送给客户之前，预先发送给客户浏览器一些数据，因此浏览器可以通过HEAD请求来访问这些Meta信息而不必真正通过GET来返回全部文档数据。服务器通常发送给浏览器的是一些标准的HTTP头信息，如果要想增加额外的信息，就需要使用MetaDir来定义Meta数据存放的目录， 而MetaS uffix用于指定包含Meta数据的文件后缀。

#ErrorDocument 500 "The server made a boo boo.
#ErrorDocument 404 /missing.html
#ErrorDocument 404 /cgi-bin/missing_handler.pl
#ErrorDocument 402 http://some.other_server.com/subscription_info.html

　　如果客户请求的网页不存在，或者没有访问权限等情况发生时，服务器将产生一个错误代码，同时也将回应客户浏览器一个标识错误的网页。ErrorDocument就用于设置当出现哪个错误时应该回应客户浏览器那些内容，ErrorDocument的第一个参数为错误的序号，第二个参数为回应的数据，可以为简单的文本，本地网页，本地CGI程序，以及远程主机上的网页。

BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0

　　BrowserMatch命令为特定的客户程序，设置特殊的参数，以保证对老版本浏览器的兼容性，并支持新浏览器的新特性。

#
#    SetHandler server-status
#    Order deny,allow
#    Deny from all
#    Allow from .your_domain.com
#
#
#    SetHandler server-info
#    Order deny,allow
#    Deny from all
#    Allow from .your_domain.com
#
#
#    Deny from all
#    ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
#

　　用于设置访问控制的设置主要是针对目录和文件进行设置的，然而也可以针对不同的URL进行访问控制的设置，这样就不必担心ScriptAlias、Alias是否将路径设置到了受控制的目录之外了。针对URL进行控制的语句为 Location语句，这样不但能对服务器上的文件、CGI提供保护，此外，它还能保护不能找到对应文件，而是由服务器本身提供的特殊功能URL。http://servername/server-status� ... o用于报告Apache 服务器的统计信息。与此相关的设置还有ExtendedStatus参数，可以让服务器输出更详细的的报告。

#
#ProxyRequests On
#
#
#    Order deny,allow
#    Deny from all
#    Allow from .your_domain.com
#
#ProxyVia On
#CacheRoot "/usr/local/www/proxy"
#CacheSize 5
#CacheGcInterval 4
#CacheMaxExpire 24
#CacheLastModifiedFactor 0.1
#CacheDefaultExpire 1
#NoCache a_domain.com another_domain.edu joes.garage_sale.com

#

　　Apache服务器本身就具备代理的功能，然而这要求加载入mod_proxy模块。这能使用IfModule语句进行判断，如果存在mod_proxy模块，就使用ProxyRequests打开代理支持。此后的Directory用于设置对Proxy功能的访问权限设置，以及用于设置缓冲的各个参数设置。

    * 虚拟主机

#NameVirtualHost 12.34.56.78:80
#NameVirtualHost 12.34.56.78
#
#    ServerAdmin webmaster@host.some_domain.com
#    DocumentRoot /www/docs/host.some_domain.com
#    ServerName host.some_domain.com
#    ErrorLog logs/host.some_domain.com-error_log
#    CustomLog logs/host.some_domain.com-access_log common
#

#
#

　　缺省设置文件中的这些内容是用于设置命名基础的虚拟主机服务器时使用。其中NameVirtualHost 来指定虚拟主机使用的IP地址，这个IP地址将对应多个DNS名字，如果Apache使用了Listen 参数控制了多个端口，那么就可以在这里加上端口号以进一步进行区分对不同端口的不同连接请求。此后，使用 VirtualHost语句，使用NameVirtualHost指定的IP地址作参数，对每个名字都定义对应的虚拟主机设置。

　　虚拟主机是在一台Web服务器上，可以为多个单独域名提供Web服务，并且每个域名都完全独立，包括具有完全独立的文档目录结构及设置，这样域名之间完全独立，不但使用每个域名访问到的内容完全独立，并且使用另一个域名无法访问其他域名提供的网页内容。

　　虚拟主机的概念对于ISP来讲非常有用，因为虽然一个组织可以将自己的网页挂在具备其他域名的服务器上的下级往址上，但使用独立的域名和根网址更为正式，易为众人接受。传统上，必须自己设立一台服务器才能达到单独域名的目的，然而这需要维护一个单独的服务器，很多小单位缺乏足够的维护能力，更为合适的方式是租用别人维护的服务器。ISP也没有必要为一个机构提供一个单独的服务器，完全可以使用虚拟主机能力，使服务器为多个域名提供Web服务，而且不同的服务互不干扰，对外就表现为多个不同的服务器。

　　有两种设定虚拟主机的方式，一种是基于HTTP 1.0标准，需要一个具备多IP地址的服务器，再配置DNS 服务器，给每个IP地址以不同的域名，最后才能配置Apache的配置文件，使服务器对不同域名返回不同的Web文档。由于这需要使用额外的IP地址，对每个要提供服务的域名都要使用单独的IP地址，因此这种方式实现起来问题较多。

　　可以在一个网络界面上绑定多个IP地址，FreeBSD下需要使用ifconfig的alias参数来进行这个配置，但此时会影响网络性能。

　　HTTP 1.1标准在协议中规定了对浏览器和服务器通信时，服务器能够跟踪浏览器请求的是哪个主机名字。因此可以利用这个新特性，使用更轻松的方式设定虚拟主机。这种方式不需要额外的IP地址，但需要新版本的浏览器支持。这种方式已经成为建立虚拟主机的标准方式。

　　要建立非IP基础的虚拟主机，多个域名是不可少的配置，因为每个域名就对应一个要服务的虚拟主机。因此需要更改DNS服务器的配置，为服务器增加多个CNAME选项，如：

freebsd                        IN         A                     192.168.1.64
vhost1                         IN         CNAME                 freebsd
vhost2                         IN         CNAME                 freebsd

　　基本的设置选项都是为了freebsd主机设定的，如果要为vhost1和vhost2设定虚拟主机，就要使用VirtualHost语句定义不同的选项，在语句中可以使用配置文件前面中的大部分选项，而可以重新定义几乎所有的针对服务器的设置。

NameVirtualHost 192.168.1.64

DocumentRoot /usr/local/www/data
ServerName  freebsd.example.org.cn


DocumentRoot /vhost1
ServerName  vhost1.example.org.cn


DocumentRoot /vhost2
ServerName  vhost2.example.org.cn

　　这里需要注意的是，VirtualHost的参数地址一定要和NameVirtualHost定义的地址相一致，必须保证所有的值严格一致，Apache服务器才承认这些定义是为这个IP地址定义的虚拟主机。

　　此外，定义过NameVirtualHost之后，那么对这个IP地址的访问都被区分不同的虚拟主机进行处理，而对其他IP地址的访问，例如127.0.0.1，才应用前面定义的缺省选项。

未完，待续。。。　

probing

服务器的安全控制

　　Apache提供的各种特性非常丰富，主要是由于其采用的是模块化的结构，这样就很容易进行分布式开发。 Internet上的众多开发者为Apache提供了各种各样的能力，使其能具备其他的Web服务器不能与之相比的能力。在服务器所具备的众多特性中，安全控制的特性最为有用。

    *
      对IP地址和域名的控制

　　Apache服务器可以基于IP地址和基于用户对访问服务器进行控制。在设置文件httpd.conf（或 access.conf）中，这些访问控制的设置是放置在Directory、File和Location语句中的，分别针对主机上的目录、文件以及URI进行存取控制。然而，由于不是每个使用者都可以随便更改系统Web服务器的设置文件，并能重新启动服务器的，因此在设置文件中的控制语句只是提供了基本的访问控制策略，而更灵活的方式是通过各个文档目录中的访问控制文件来实现的。

　　为了在需要访问控制的每个目录下都设置访问控制文件，首先要在系统配置文件中设置这个访问控制文件及其访问作用。需要使用AccessFileName定义访问控制文件的名字，缺省它被设置为.htaccess。缺省设置文件将在针对根目录及/usr/local/www/data这个文档根目录的访问控制语句中设置AllowOverride None ，这就意味着不允许这个目录及其子目录中的访问控制文件起作用，为了使得访问控制文件发挥作用，必须针对需要设置访问控制的目录设置AllowOverride All或其他有部分访问控制功能的选项，此时该目录及其子目录下的访问控制文件也会发挥作用。

　　AllowOverride All将允许.htaccess文件能改变所有的访问控制功能，如果仅仅希望目录的所有者只控制部分访问控制功能，可以使用AllowOverride的其他设置选项，那样.htaccess只能使用允许的设置选项。

　　要在.htaccess文件中针对IP地址和域名进行控制，就需要使用访问控制语句的Limit语句。因此就要求httpd.conf中必须允许控制文件使用Limit功能，对应的设置为AllowOverride Limit选项（或All选项）。

　　Limit语句可以使用不同的参数，这些参数为HTTP协议的请求方法，如使用<limit GET> 限制HTTP协议中的GET方法，<limit POST>限制http协议中的POST方法，使用</limit>标识这个控制段的结束。对于一般的情况，可以对大部分客户打开GET、POST和HEAD 请求，而关闭PUT、DELETE等其他更复杂且不常用的请求。

　　如果在.htaccess中没有使用Limit语句指定具体的访问方法，那么就表示访问控制命令将对所有的请求方法都进行控制。

　　Order定义服务器查询访问控制的顺序，当设置为Order Allow, Deny的时候将先处理Allow 语句，再处理Deny语句。Order Deny, Allow的处理顺序相反。由于这两种不同的方式代表不同的访问控制策略，Order deny, allow和deny from all合作，是用于只允许设置过的客户机访问服务器，而Order allow, deny和allow from all合作，是允许所有的客户机访问，而仅仅屏蔽部分具有恶意的网络地址。

　　在每个Allow或Deny命令中，可以使用域名（从后向前匹配）、IP（从前向后匹配），all（代表所有主机）来标识Internet上的计算机。这里是一个例子：

order deny, allow
deny from all
allow from 192.168.1.
allow from example.org.cn
allow from 127.

　　这个例子是一个专有网络的例子，它采用的封闭式策略，以保证服务器的安全性。对于对整个 Internet开放的公共Web服务器，那么采取的策略应该与之相反。

未完，待续。。。　　

probing

基于用户的访问控制

　　更严格、有效的控制方法还是基于用户和对应的口令对浏览客户进行控制。这使得对这个目录进行强制性的保护，浏览器用户必须输入合法的用户名和正确的口令才能浏览网页。如果要针对用户对访问服务器的客户进行控制，首先就要设置访问控制文件为对用户进行认证，因此要允许目录访问控制文件中具备AuthConfig的设置。

　　设置用户认证需要为这个目录指定AuthName、AuthType和AuthUserFile 指令，AuthUserFile定义一个口令文件，那么此后就可以使用require valid-user命令让客户输入名字和正确的口令，根据这个口令文件对用户的身份进行验证。AuthName定义这个认证的标识，用于返回给浏览器用户，起到提示作用。AuthType定义使用的认证加密类型，通常使用 Basic，即使用Unix的标准加密算法进行加密。

AuthUserFile /usr/local/etc/htpasswd
AuthName SecurityAuth
AuthType Basic
require vaild-user

　　这个例子里，使用/usr/local/etc/htpasswd作口令文件，使用Basic的加密认证方法，并定义AuthName为SecurityAuth。

　　虽然浏览器访问每个使用这种认证方式保护的网页都需要先进行认证，然而不会每访问一次网页都让用户输入用户名和口令，因为浏览器会将用户输入的用户和口令数据保存起来，每次需要认证的时候就自动进行认证操作。由于认证是通过H EAD请求来完成的，因此它不会影响浏览器显示的网页。然而，用户有可能使用浏览器访问了多个不同的对用户进行认证的网页，那么浏览器就会保存了多个不同的用户和口令对，当自动进行认证的时候，浏览器必须区分出应该使用哪个用户名和口令进行认证，而区分就是通过AuthName的值进行的，服务器将首先将AuthName的值传递给客户浏览器，此后浏览器就能发送正确的用户和口令进行认证了。

　　要使用口令文件来认证合法用户，首先就必须生成这个口令文件。当认证类型为Basic时，口令文件与Unix 的passwd文件非常类似，甚至可以直接使用系统passwd文件来作认证文件，当然由于现代Unix使用了sha dow技术，/etc/passwd中并没有保存真实的加密口令，因此直接使用系统passwd文件进行认证只能适合那些没有使用shadow技术的Unix系统。而使用shadow技术的Unix系统的真实口令文件（FreeBSD 下为master.passwd）被保护起来，读取它需要root权限，而Web服务器通常以普通用户的权限运行，不能直接使用系统口令对用户进行认证。如果强制使用root权限启动httpd守护进程来访问shadow之后的口令，那么必然会带来严重的安全漏洞。

　　因此一般使用与系统口令相分离的口令文件来认证Web服务器用户，这样即使口令被泄露，并被破译，造成的安全影响也很小，不至于影响系统的正常运行。可以使用Apache附带的htpasswd命令来创建口令文件，并设置用户及其口令。

$ htpasswd -c .htpasswd user1
Adding Password for user1
New password:
Re-type new password:

　　htpasswd的-c选项告诉htpasswd创建一个新口令文件为.htpasswd，如果没有这个选项，htpasswd就将用户及其口令加入已经存在的口令文件中。此后的参数就是口令文件名和需要增加或改变口令的用户名。

　　为了便于管理，可以进一步将这些用户分组，组文件的每一行定义了一个组及其成员的名字，然后在.htaccess 中使用AuthGroupFile指定这个目录使用的组文件的名字，例如：

group1: user1 user2 user3 user4

　　这条内容创建了一个口令组group1，包括user1,user2,user3,user4成员。

　　除了可以使用require valid-user要求输入的用户必须为口令文件中的合法用户之外，也可以设置要求只有特定的合法用户才能访问的目录，这就需要使用require user或require group指令。例如使用require user user1要求只有user1用户才能访问，使用require group g roup1就要求必须是group1组的合法成员才能访问。针对具体用户和组的访问控制就进一步增加了访问控制的灵活性。

　　当基于用户的认证和基于地址的认证综合使用时，可以通过使用satify参数指定不同的限制条件，如果设置 satify all，那么必须同时通过用户和地址认证才能访问网页，而设置satify any，只需要通过一个认证客户就能访问这个目录了。缺省情况下Satify参数的值为all。下面为一个综合了地址认证和用户认证的.htaccess 的例子，这个例子允许private.site的计算机可以不需认证访问这台服务器，而其他位置的用户必须是 group1组中的合法用户，或者是user1、user2、user3用户，才能访问这台服务器。

AuthUserFile /usr/local/etc/.htpasswd
AuthGroupFile /usr/local/etc/.htgroup
AuthName SecurityAuth
AuthType Basic

<Limit HEAD GET POST>
order deny,allow
deny from all
allow from private.site
require group group1
require user user1 user2 user3
</Limit>

satify any

    * 其他认证方式

　　Apache使用AuthType指定加密的方式，AuthType设为Basic时为使用命令htpasswd 创建口令文件并进行口令加密。然而这种方式有两个缺点，一个为浏览器将在Internet上使用明文发送用户名和口令信息，另一个是htpasswd的口令文件为普通文本文件，这样当用户数目较多时，查找用户的效率就很低。

　　为了弥补安全性的缺点，可以将AuthType设置为Digest，这样就会使用Digest鉴别方式进行认证，此时认证口令文件要使用AuthDigestFile来规定，而口令文件必须使用另一个加密程序htdigest 产生和维护，而hdigest的使用方法和htpasswd相同。在Digest认证方式下，浏览器不会直接发送口令的明文信息，而是在传输口令之前先使用MD5算法进行编码处理。注意，不是所有类型的浏览器都支持Digest类型的鉴别方式的，只有在浏览器和服务器同时都支持Digest方式时，这种认证才可行。

　　AuthType为Basic时，是使用系统加密方法，一般是使用DES算法，但在FreeBSD下有可能是使用的MD5算法，但除非管理员希望在不同系统间共享口令文件，否则不必考虑他们使用的到底是何种算法。需要与其他系统兼容时，可以重新安装DES算法。但在系统使用时重新安装加密算法，就无法重建整个口令文件，因此不推荐在系统使用过程中更换认证算法，而应该在系统安装时就确定使用的认证算法。

　　为了减少用户数量较多时服务器的处理开销，就必须使用数据库技术，这是因为数据库使用了索引技术，对数据的查找就比较快速。Unix下最简单的数据库为使用系统提供的DB（或DBM）库进行创建数据库文件的技术，Apache 服务器中使用模块mod_auth_db.so对这种数据库口令文件提供支持。htpasswd产生的文本文件在有几百个用户时就会花费相当大的服务器开销，而DBM格式的认证方式可以高效的支持上万个用户。

　　BSD风格的Unix系统通常使用DB库，而其他Unix通常使用DBM库。因此其他Unix使用的命令和设置中应该为dbm而非db。

　　为了支持这种认证方式，应载入mod_auth_db.so模块，使用Ports Collection安装的Apache服务器缺省情况就支持这个模块而不需要改动。可以让Apache同时支持多种认证方式，而不会发生冲突。

　　此外，配置文件中的认证方式也需要改变，首先要创建数据库文件，这会在通过使用dbmmanage命令第一次增加用户时创建。

# dbmmanage /usr/local/etc/users adduser user1 pass123

　　这个命令将创建/usr/local/etc/usersdbm数据库文件，并使用pass123为口令在数据库中增加用户user1。然后就可以针对现有的数据库文件，增加、删除和查看用户信息了：

# dbmmanage /usr/local/etc/httpd/usersdbm delete user2
# dbmmanage /usr/local/etc/httpd/usersdbm view

　　在拥有了数据库文件和用户数据之后，就可以使用这种认证方式了：

AuthName DBMTest
AuthType Basic
AuthDBUserFile /usr/local/etc/usersdbm
require  valid-user

　　可以使用dbmmanage命令也可以用来管理组，例如将user1加入group1组，但必须添加用户的同时进行设置，需要使用dhmmanage的另一个参数：

　　# dbmmanage /usr/local/etc/users adduser user1 pass123 group1

　　这样就能使用AuthDBGroupFile和require group1进行认证管理。

　　除了使用DBM之外，Apache还可以配置成与匿名ftp认证方式类似的方式，或者使用mSql、Oracle 等SQL数据库进行认证，或者使用Kerboros、LDAP服务器进行认证，这些认证方式更为强大，能使Web 认证与其他网络服务的认证方式相统一。但是这些额外的认证方式必须使用相应的认证模块进行支持。

未完，待续。。。　　

probing

安全连接方式SSL

　　通常的连接方式中，通信是以非加密的形式在网络上传播的，这就有可能被非法窃听到，尤其是用于认证的口令信息。为了避免这个安全漏洞，就必须对传输过程进行加密。对HTTP传输进行加密的协议为HTTPS，它是通过SSL（安全Socket层）进行HTTP传输的协议，不但通过公用密钥的算法进行加密保证传输的安全性，而且还可以通过获得认证证书CA，保证客户连接的服务器没有被假冒。

　　使用公用密钥的方式可以保证数据传输没有问题，但如果浏览器客户访问的站点被假冒，这也是一个严重的安全问题。这个问题不属于加密本身，而是要保证密钥本身的正确性问题。要保证所获得的其他站点公用密钥为其正确的密钥，而非假冒站点的密钥，就必须通过一个认证机制，能对站点的密钥进行认证。当然即使没有经过认证，仍然可以保证信息传输安全，只是客户不能确信访问的服务器没有被假冒。如果不是为了提供电子商务等方面对安全性要求很高的服务，一般不需要如此严格的考虑。

　　虽然Apache服务器不支持SSL，但Apache服务器有两个可以自由使用的支持SSL的相关计划，一个为Apache-SSL，它集成了Apache服务器和SSL，另一个为Apache+mod_ssl，它是通过可动态加载的模块mod_ssl来支持SSL，其中后一个是由前一个分化出的，并由于使用模块，易用性很好，因此使用范围更为广泛。还有一些基于Apache并集成了SSL能力的商业Web服务器，然而使用这些商业Web服务器主要是北美，这是因为在那里SSL使用的公开密钥的算法具备专利权，不能用于商业目的，其他的国家不必考虑这个专利问题，而可以自由使用SSL。

　　虽然通常mod_ssl以及其他复杂的Apache模块都提供了详细的编译安装说明，并提供了非常有用的脚本程序和Makefile来帮助使用者进行安装。然而为Web服务器增加一个模块并不是一个简单而易于描述的任务，幸运的是，FreeBSD提供了Ports Collection，让使用者不必关系每一步安装细节就能安装好这个模块。

　　如果不打算使用Ports Collection来安装mod_ssl，那么事情就略微麻烦一些，必须自己手工下载Apache的源代码，以及mod_ssl的代码，按照说明一步步的编译安装。

　　Apache+mod_ssl依赖于另外一个软件：openssl，它是一个可以自由使用的SSL实现，首先需要安装这个Port（由于专利的影响，这些软件无法制作为可以直接安装的二进制软件包，必须使用Ports Collection 安装）。openssl位于/usr/ports下面的security子目录下，当下载其源程序之前，需要设置环境变量USA_RESIDENT为NO，以避开专利纷争。

# USA_RESIDENT=NO; export USA_RESIDENT
# cd /usr/ports/security/openssl
# make; make install

　　安装好openssl之后，就可以安装Apache+mod_ssl了。然而为了安装完全正确，需要清除原先安装的Apache服务器的其他版本，并且还要清除所有的设置文件及其缺省设置文件，以避免出现安装问题。最好也删除 /usr/local/www目录（或更名），以便安装程序能建立正确的初始文档目录。如果是一台没有安装过Apache 服务器的新系统，就可以忽略这个步骤，而直接安装Apache+mod_ssl了。

　　删除旧有文件之后，便可进入相应目录，启动安装和编译进程。

# cd /usr/ports/www/apache13+mod_ssl
# make ; make install
# make certifaction=custom

　　最后一个make用于生成认证证书，由于这个Port直接生成了httpd.conf等缺省文件（如果安装的时候没有httpd.conf等文件存在），因此可以直接启动新的服务器而不需要设置，如果启动过程因为设置文件的不合适而导致一些小问题，请参照前面对标准Apache服务器的设置说明作出相应修改。

# /usr/local/sbin/apachectl startssl

　　此时使用start参数为仅仅启动普通Apache的httpd守护进程，而不启动其SSL能力，而startssl 才能启动Apache的SSL能力。如果之前Apache的守护进程正在运行，便需要使用stop参数先停止服务器运行。

　　然后，就可以启动netscape或其他支持SSL的浏览器，输入URL为：https://ssl_server/ 来查看服务器是否有相应，https使用的缺省端口为443，如果一切正常，服务器将返回mod_ssl的使用手册，讲解SSL以及mod_ssl的技术及其使用方法。

未完，待续。。。