主题：中国顶级门户网站架构分析

首先声明，下面的内容都是我个人根据一些工具形成的猜想。并不保证和现实中各大门户网站所用的架构一摸一样，不过我认为八九不离十了^_^ 。

整篇文章我想分2个部分来讲：第一部分是分析国内2大顶级门户网站首页和频道的初步的基本构架。第二部分我将自己做的实验文档记录下来。希望每个SA心里都能有这样的架构。

新浪和搜狐在国内的知名度可谓无人不知无人不晓。他们每天的点击率都在千万以上。这样大的访问量对于新浪和搜狐来说怎样利用有限的资源让网民获得最快的速度成为首要的前提，毕竟现在网络公司已经离开了烧钱的阶段，开始了良性发展，每一笔钱砸下去都需要一定回响才行的。另一方面，技术人员要绞尽脑汁，不能让用户老是无法访问、或者访问速度极慢。这样就算有再好的编辑、再好的销售，他们也很难将广告位卖出去，等待他们的将是关门。当然这些情况都没有发生，因为他们的技术人员都充分的利用了现有资源并将他们发挥到了极至。说到底就是用squid做web cache server，而apache在squid的后面提供真正的web服务。当然使用这样的架构必须要保证主页上大部分都是静态页面。这就需要程序员的配合将页面在反馈给客户端之前将页面全部转换成静态页面。好了基本架构就这样，下面说说我怎么猜到的以及具体的架构：

法宝之一：nslookup

实战：

nslookup www.sina.com.cn
Server: ns-px.online.sh.cn
Address: 202.96.209.5

Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses: 61.172.201.230, 61.172.201.231, 61.172.201.232, 61.172.201.233
61.172.201.221, 61.172.201.222, 61.172.201.223, 61.172.201.224, 61.172.201.225
61.172.201.226, 61.172.201.227, 61.172.201.228, 61.172.201.229
Aliases: www.sina.com.cn, jupiter.sina.com.cn

这里可以看到新浪在首页上用到了那么多IP，开始有人会想果然新浪财大气粗啊。其实不然，继续往下看：

nslookup news.sina.com.cn
Server: ns-px.online.sh.cn
Address: 202.96.209.5

Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses: 61.172.201.228, 61.172.201.229, 61.172.201.230, 61.172.201.231
61.172.201.232, 61.172.201.233, 61.172.201.221, 61.172.201.222, 61.172.201.223
61.172.201.224, 61.172.201.225, 61.172.201.226, 61.172.201.227
Aliases: news.sina.com.cn, jupiter.sina.com.cn

细心的人可以发现了news这个频道的ip数和首页上一样，而且IP也完全一样。也就是这些IP在sina的DNS上的名字都叫taurus.sina.com.cn，那些IP都是这个域的A记录。而news,sports,jczs.news。。。都是CNAME记录。用DNS来做自动轮询。还不信，再来一个，就体育频道好了：

nslookup sports.sina.com.cn
Server: ns-px.online.sh.cn
Address: 202.96.209.5

Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses: 61.172.201.222, 61.172.201.223, 61.172.201.224, 61.172.201.225
61.172.201.226, 61.172.201.227, 61.172.201.228, 61.172.201.229, 61.172.201.230
61.172.201.231, 61.172.201.232, 61.172.201.233, 61.172.201.221
Aliases: sports.sina.com.cn, jupiter.sina.com.cn

其他的可以自己试。好了再来看看sohu的情况：

nslookup www.sohu.com
Server: ns-px.online.sh.cn
Address: 202.96.209.5

Non-authoritative answer:
Name: pagegrp1.sohu.com
Addresses: 61.135.132.172, 61.135.132.173, 61.135.132.176, 61.135.133.109
61.135.145.47, 61.135.150.65, 61.135.150.67, 61.135.150.69, 61.135.150.74
61.135.150.75, 61.135.150.145, 61.135.131.73, 61.135.131.91, 61.135.131.180
61.135.131.182, 61.135.131.183, 61.135.132.65, 61.135.132.80
Aliases: www.sohu.com

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

nslookup news.sohu.com
Server: ns-px.online.sh.cn
Address: 202.96.209.5

Non-authoritative answer:
Name: pagegrp1.sohu.com
Addresses: 61.135.150.145, 61.135.131.73, 61.135.131.91, 61.135.131.180
61.135.131.182, 61.135.131.183, 61.135.132.65, 61.135.132.80, 61.135.132.172
61.135.132.173, 61.135.132.176, 61.135.133.109, 61.135.145.47, 61.135.150.65
61.135.150.67, 61.135.150.69, 61.135.150.74, 61.135.150.75
Aliases: news.sohu.com

情况和sina一样，只是从表面来看sohu的IP数要多于sina的IP数，那么sohu上各个频道用的服务器就要多于sina了？当然不能这么说，因为一台服务器可以绑定多个IP，因此不能从IP数的多少来判断用了多少服务器。

从上面这些实验可以基本看出sina和sohu对于频道等栏目都用了相同的技术，即squid来监听这些IP的80端口，而真正的web server来监听另外一个端口。从用户的感觉上来说不会有任何的区别，而相对于将web server直接和客户端连在一起的方式，这样的方式明显的节省的带宽和服务器。用户访问的速度感觉也会更快。

先说那么多了，要去睡觉了，明天还有很多工作要做～有不明白的记得给我留言！！！

前天讲了最基本的推测方法，今天稍微深入一些：）
1. 难道就根据几个域名的ip相同就可以证明他们是使用squid的嘛？
   当然不是，前面都只是推测。下面才是真正的证实我上面的猜测。先nslookup一把sina的体育频道。
nslookup sports.sina.com.cn
Server:  ns1.china.com
Address:  61.151.243.136

Non-authoritative answer:
Name:    taurus.sina.com.cn
Addresses:61.172.201.231, 61.172.201.232, 61.172.201.233, 61.172.201.9
          61.172.201.10, 61.172.201.11, 61.172.201.12, 61.172.201.13, 61.172.201.14
          61.172.201.15, 61.172.201.16, 61.172.201.17, 61.172.201.227, 61.172.201.228
          61.172.201.229, 61.172.201.230
Aliases:  sports.sina.com.cn, jupiter.sina.com.cn

然后直接访问这些ip中的任意一个ip试试看，访问下来的结果应该是如下图所示：

由此可以证明sina是在dns中设置了很多ip来指向域名sqsh-19.sina.com.cn，而其他各种相同性质的频道都只是sqsh-19.sina.com.cn一个别名，用CNAME指定。dns的设置应该是这样的，然后server方面，通过squid 2.5.STABLE5（最新的稳定版为STABLE6）来侦听80端口。上面这些是根据一些信息分析而出的，应该基本正确的。下面一些就是我的个人的猜想：

它的真正的web server也同样是侦听80端口，因为在squid配置文件中有一项是：

httpd_accel_port 80

如果你设成其他端口号（比如88）的话，那上图的错误信息就会变成

While trying to retrieve the URL: http://61.172.201.19:88

工具2：nmap扫描程序：可以用来检查服务器开了什么端口。

我现在用nmap来扫描sina的一个ip：61.172.201.19来进行分析

bash-2.05$ nmap 61.172.201.19

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-07-30 13:31 GMT
Interesting ports on 61.172.201.19:
(The 1657 ports scanned but not shown below are in state: filtered)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap run completed -- 1 IP address (1 host up) scanned in 73.191 seconds

可以看到他对外只开了2个端口，80端口就是刚才我们说的squid打开的，这点刚才已经验证过了。而22端口是用来ssh远程连接的，主要是sa用来远程操作服务器用的安全性非常高的方法。

工具3：lynx或者其他可以读取http头文件的工具及小程序：直接看例子比较好理解：）

HTTP/1.0 200 OK
Date: Fri, 30 Jul 2004 05:49:47 GMT
Server: Apache/2.0.49 (Unix)
Last-Modified: Fri, 30 Jul 2004 05:48:16 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
Cache-Control: max-age=60
Expires: Fri, 30 Jul 2004 05:50:47 GMT
Content-Length: 180747
Content-Type: text/html
Age: 37
X-Cache: HIT from sqsh-230.sina.com.cn
Connection: close

上面是sina的http头的反馈信息。里面有很多有价值的东东哦：）譬如，它后面的apache是用2.0.49，还设了过期时间为2分钟。最后修改时间。这些都是要在编译apache的时候载入的，特别是Last-Modified还需要小小的改一把源码--至少我是这样做的。

综上所述

  sina的架构应该是前面squid，按照现在的服务器2u，2g内存一般每台服务器至少可以跑4个squid2.5stable5. 这样它16个ip就用了4台服务器。后面一层是apache2.0.49应该会用2台。这2台可能用的全是私有ip，通过前面的squid服务器在hosts文件中指定。具体的实现方法我会下次整理出我做实验的文档：）而apache的htdocs可能是有一个或2个磁盘阵列作nfs。apache mount nfs server的时候应该是只读的，然后另外还有服务器转门用来做编辑器服务器，用来编辑人员更新文章。这台服务器应该对nfs server是具有可写的权限。

----这就一套完整的sina所运用的方案，当然很多是靠猜测的，我没有和sina的技术人员有过任何沟通（因为一个也不认识），否则我也就不会写出来了。其他sohu，163应该也有这样的架构。

最后声明：这只是一些静态页面组成频道的一个架构，sina还有很多其他服务器，什么下载，在线更新等不在这个架构中。

Squid是什么?

Web Cache服务器  (web cache server)

 

目前，Internet和Intranet几乎已经遍及到我们生活和工作的各个角落，给我们带来了极大的便利，但有时其缓慢的网络访问速度和较大的时间延迟又会令使用者们大伤脑筋，为了缓解这种局面，许多供应商提出了解决方案，那就是使用Cache技术。
应用Cache技术可以减少访问Internet骨干网的流量，减少重复内容的下载，从而节省宝贵的广域网链路带宽，不仅能够降低企业的成本，甚至也能减少ISP的成本；同时应用Cache技术还能加速用户访问WWW和FTP等资源的时间，增加用户对上网的兴趣。
提到Cache，大家自然会想到计算机里面的高速缓存，实际上，Web Cache的功用远不止存储和提供数据这么简单。Cache是作为基于软件的代理服务器的一部分或专门的硬件（容器appliances）出现的，后者可以提供更好的性能。不同的生产商提供的产品在许多方面存在着差异，其中包括配置和设置的难易程度、使用的协议、安全性能、远程管理、能够用于缓存的Web传输的类型以及价格和售后技术支持等。
以下，我们对目前业界可提供的Cache产品和Cache技术作简单的介绍。
代理型Cache和容器型Cache
到目前为止，至少有16家生产商推出了他们各自的Web Cache产品，其中有几家把Cache作为代理服务器的一部分进行销售，例如CSM-USA、Deerfield Communication、Microsoft、Netscape Communications、Novell和Ositis，另外几家（如Cacheflow、Cisco Systems、Cobalt Networks、Entera、Eolian、IBM、Infolobria和Intel）则把Cache作为容器进行销售。
是什么把Cache分为这两类呢？那就是速度。Proxy Cache在通用的平台上用软件来实现缓存功能，而典型的容器Cache则包含有运行于专用硬件平台上的缓存软件，如Intel公司的Monet系列。相比较而言，容器型的Cache速度更快，性能也更好。这一点，即使是一些代理服务器的生产商也不得不承认。

影响Cache性能的主要指标
假如某个用户要购买Cache，那么他最关心的莫过于两个问题，一个是性能，一个是价格。而价格显然是受性能影响的，只有弄清楚产品的性能，方才知道其价格合理与否。任何Cache的性能都会受到一系列因素的影响（包括线连接速率和网络的拥挤情况等）。用户怎样才能更快、更准确地了解Cache的性能呢？首先，要从生产商那里了解到Cache能够同时支持多少连接、每秒钟能够供应多少对象（object）、它的吞吐量是多少以及平均对象命中率和平均字节命中率是多少等技术指标。获得连接的数目将有助于网络管理员选择适当容量的Cache。
吞吐量是影响性能的另一个重要因素。如果连接到Internet的链路是T3（45Mbps），那么所需的Cache最好能够处理45Mbps的通信量，否则Cache 就会变成瓶颈。现有的容器Cache至少都可以处理一个T1（1.544Mbps），有些生产商声称他们的产品可以处理一个T3。代理服务器Cache的生产商通常不会透露产品的吞吐量，因为吞吐量会受到底层硬件的影响。
　　接下来再看对象命中率和字节命中率。对象命中率是用户从Cache中取到的对象数与所获得的总对象数（包括从Internet上获取的对象数和从Cache中获得的对象数）的比值，字节命中率是用户从Cache中获取对象的平均字节数和从网上获取的全部对象的平均字节数的比值。例如，某个Cache的命中率是50%，就意味着Cache可以满足一半的数据请求，而另外一半数据则需要通过Internet得到。因此，从另外一个角度看，使用Cache意味着节约了带宽，也因此提高了性能。目前大多数Cache的命中率都在30%左右，容量大一些的Cache通常可以达到60%到65%。对于容器Cache而言，硬盘空间和内存容量的大小对Cache命中率的影响很大。一般说来，硬盘的空间越大，Cache中保存的对象就越多，用户所需页面能够在Cache找到的可能性就越大。另一方面，RAM用于存储那些访问频率最高的内容，因为RAM的存取速度要比硬盘快得多。多个硬盘可以提高Cache的性能。硬盘是Cache系统中速度最慢的部件，一块硬盘在某一时刻只能处理一个输入/输出操作，但如果有多个硬盘并行的话，Cache就会以更快的速度工作。
有些影响速度的因素是不能量化的，例如文件系统的组织。组织紧密的文件系统可以大幅度地提高Cache的性能。许多容器Cache的生产商为了提高它们的产品性能，在操作系统和文件系统上都下了很大的功夫。
被动式Cache和主动式Cache
　　如何使Cache内容保持最新也是Cache系统要解决的一个问题。被动式的Cache只有当用户提出信息请求时，Cache中的内容才会更新。主动式的Cache在用户请求数据前就会把Web内容预取到Cache中。所有的生产商都提供被动式的Cache，这可能是因为它是HTTP标准的一部分。
被动式Cache通常会在查看内容是否改变的请求提出时，检查服务器。如果Cache中对象的修改日期早于服务器中对象的修改日期，Cache会从服务器中获取对象的新拷贝。如果服务器上的内容没有改变，Cache就会把本地的副本提供给用户。这一方法可以保证用户总是能够得到最新的数据。但由于每个请求都要对数据进行一次检查，所以响应时间就延长了。解决这个问题的一个办法是调整这种被动的Cache机制。或者是预定方式的（scheduled），或者是自动方式的（automated）。如果使用预定方式的预取方案，网络管理员需要事先决定哪些站点是最流行的，然后明确地设定Cache在特定的时间内去获取这些站点中的对象。
代理式Cache和透明式Cache
　　接下来看一下怎样配置Cache。这里有两种选择：代理模式或透明模式。工作在代理模式的Cache必须对浏览器进行设置，使之直接向服务器提出请求，然后由服务器代表用户把请求发送到Internet上。代理方式的优点在于网络管理员可以控制用户的行为，并且能够知道哪个用户在访问哪些站点；缺点是把每个浏览器与代理服务器通过配置联系在一起是一件非常烦琐的工作，特别是对规模较大的网络来说更是如此。在透明方式下，路由器、负载均衡器和负载均衡交换机可以把通信数据传递给Cache，这样，就无须对浏览器进行改动，而只要对交换机或路由器进行配置就行了。
Cache 的 通 信 类 型
　　能够用于缓存的通信类型是另一个要考虑的问题。由于设计这些产品的本意在于缓存Web传输，所以每种产品都支持HTTP协议。随着Intranet的发展，这种能力可以在拥挤的主干网上有效地节约带宽。Intel公司的产品还可以为NNTP（network news transfer protocol）提供缓存服务。
Cache的群集支持
　　以上讲到了Cache的几个方面。无论Cache怎样设计，它最终都将装满信息，致使效率下降。使用群集技术可以在一定程度上解决这一问题。几乎所有的Cache都能够通过专用或标准的协议实现同一站点Cache 间或不同站点设备间的群集。使用标准协议实现群集能够保证不同生产商的Cache协同工作。这里有两个标准协议：ICP（Internet Caching Protocol）和CARP（Cache Array Routing Protocol）。使用ICP协议实现群集时，会遇到下述情况：当某个Cache收到数据请求，而所请求的数据又不在该Cache中时，它会检查与之群集在一起的所有Cache，以便弄清所请求的数据是否存储在其他的Cache中,这样一来就延长了响应的时间。CARP为了解决这一问题，使用一个运行hash算法的主Cache来决定应该向哪儿发送请求。
如果网络管理员想要建立一个更快的群集系统，那么他可以购买负载均衡产品或Layer 4交换机，并将其安装在Cache前端，这种方法只适用于透明方式。在这种方式下，采用了一种WCCP的协议，这种协议使路由器或Layer3等设备可以与Cache通信以转发请求信息；当然，这还需要Cache也支持WCCP协议才行。这种方案是Cache服务器与相应的路由器或交换机相配合。这里要求与Cache服务器相连的路由器或交换机具有应用层清醒的特性（Application Aware)，它能对经过它的所有数据包进行分析，检查数据包的TCP端口号，如果是配置中制订的端口，它就会重定向（Redirect)到后台与它相连的Cache服务器，这一切对客户端都是透明的。它的好处是这个检查数据包并且重定向的过程一般是用专用的芯片来实现，已近乎第二层的线速完成；另外减轻了Cache服务器的负载，因为并不是所有的数据包都要经过Cache服务器。
我们建议的Intel解决方案是ES550交换机加四个专用Cache服务器：Monet1000。
ES550交换机新的固件Cork7（Firmware2.61)支持上述功能,并且能做到Cache服务器的负载平衡（Cache Server Load Balancing），它会根据HTTP、FTP等请求数据包的目的IP地址来决定将HTTP、FTP等请求重定向到哪一台Cache服务器上，甚至它还支持用户设定DNS域名或IP地址来人工调整Cache服务器的负载。

 

术语扫盲 - SP、CP、ISP、ICP、ASP

昨天和同事无意中聊到CP的概念，我乍一听有点儿蒙。不知道啥是CP。今天看到此文，原来CP就是ICP去掉一个Internet。看来很多角落需要扫盲了……

 

Apache服务器的设置文件位于/usr/local/apache/conf/目录下，传统上使用三个配置文件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/apache/conf

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中，所有的设置都被放在了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类似的功能为PHP等等，只不过由于Apache的开放模式，这些功能是由独立的开发组，作为独立的模块来实现的。但是在评测中，测试人员没有加入相应的模块评测其性能。

HTTP守护进程的运行参数

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

ServerType standalone

ServerType定义服务器的启动方式，缺省值为独立方式standalone，httpd

服务器将由其本身启动，并驻留在主机中监视连接请求。在Linux下将在启动文件 /etc/rc.d/rc.local/init.d/apache中自动启动Web服务器，这种方式是推荐设置。

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

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

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

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

#LockFile /var/run/httpd.lock

LockFile参数指定了httpd守护进程的加锁文件，一般不需要设置这个参数， Apache服务器将自动在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就采用了这样的方式，一次连接结束后，子进程并不退出，而是停留在系统中等待下一次服务请求，这样就极大的提高了性能。

但由于在处理过程中子进程要不断的申请和释放内存，次数多了就会造成一些内存垃圾，就会影响系统的稳定性，并且影响系统资源的有效利用。因此在一个副本处理过一定次数的请求之后，就可以让这个子进程副本退出，再从原始的httpd进程中重新复制一个干净的副本，这样就能提高系统的稳定性。这样，每个子进程处理服务请求次数由MaxRe questPerChild定义。 缺省的设置值为30，这个值对于具备高稳定性特点的Linux系统来讲是过于保守的设置，可以设置为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的动态加载模块只需要设置好Load Module和AddModule参数就可以了，这种特性就是Apache的 DSO（Dynamic Shared Object）特性，然而要想充分使用DSO特性仍然不是一个简单的事情，不适当的改动这里的设置就可能造成服务器不能正常启动。因此如果不是要增加或减少服务器提供的功能，就不要改动这里的设置。

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

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

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

#ExtendedStatus On

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