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

probing

CGI和SSI的安全性

　　允许根据用户的请求而在服务器上运行程序，本身就是一种安全漏洞，因此只有在必要时，才允许用户使用这些功能。

　　对于SSI，安全问题比较简单，可以将其设置为只分析普通标志，不执行外部程序，这必须在配置文件中使用 Options IncludesNOEXEC选项，而非Options Includes选项。就能满足对安全性的一般要求。

　　CGI程序的情况更为复杂。由于CGI可以用两种方式设置，一种为由ScriptAlias设置CGI程序的路径，另一种为通过设置CGI的后缀而设置的。通常只有在信任用户有能力创建没有（或很少）漏洞的CGI程序时，才使用后缀确认CGI程序。否则将会产生一些很糟糕的CGI程序，使得系统很容易被攻击。因此将CGI程序限制在一些固定目录下的做法更为常见，这至少让一个CGI程序经过服务器管理员的一些检查，避免明显的漏洞。

　　CGI程序的另一个问题是，如果CGI程序要保存浏览器客户发布的数据，那么它就要访问系统的文件系统。通常 Apache服务器使用User和Group配置服务器运行的用户和组属性，Apache服务器启动的CGI程序缺省也使用这个用户和组属性运行，也就拥有了这个用户和组的权限，可以存取文件系统中的数据，这就对系统安全造成另一个影响。然而又必须让CGI程序存取数据文件，因此就要适当调整User和Group的设置，使得它能够存取合适的数据文件。

　　即使如此，由于所有的CGI程序都以同样的用户执行，那么不同用户的CGI就能相互操作别的用户的数据文件，从而造成安全问题。为了使得不同的用户以不同的用户身份执行CGI，就需要使用程序的SetUID功能。因为SetUID 会带来极大的系统漏洞问题。因此如非必要，不要使用SetUID程序，尤其是root身份的SetUID程序。设置用户身份的问题可以使用Apache的suEXEC能力来帮助完成，它首先将身份改变为合适的用户，再执行相应的CGI程序。

未完，待续。。。　　

probing

调整服务器性能

　　前面介绍了Apache服务器的基本设置选项，通过调整这些设置，就能使Web服务器达到非常优秀的性能。此外，还可以调整操作系统的设置，包括重新定制整个系统，使之适合高负载的Web服务器。进一步，还可以利用Apache 提供的各种服务器技术，如FastCGI、PHP等，充分发挥Web服务器的作用。

　　调整Web服务器的性能，首先就要调整系统内核的性能，需要定制一个适合服务器要求的内核。此外，不要忘记使用egcc及更大的优化选项来编译Web服务器。

    *
      单服务器性能调整

　　由于Apache服务器具备高度的可配置性，因此通过调整其设置，可以极大的提升服务器的性能。对于Web 服务器，所面对的性能问题主要可以分为两个方面，一个为Web服务器提供静态网页的性能，另一个为产生动态网页时的性能。其中在产生动态网页时的性能下降是影响服务器性能的主要因素。

    * 使用新特性提升性能

　　为了改善产生动态网页时的性能，可以尝试使用Apache能提供的新特性来帮助解决性能问题。虽然CGI和SSI 都能用于产生动态网页，但都各具缺点。CGI需要每次都要启动一个进程，因此增加了运行服务器的负担，而SSI功能简单，不适合大部分需要。因此为了增加服务器的性能，Web服务器的开发者考虑了各种不同的技术，以提高服务器提供动态网页时的运行速度。

　　增加产生动态网页的性能，可以从两个角度出发，一个基于原有的CGI程序，设法使得一个CGI进程能提供多次 CGI服务，而不必每次都重新产生进程，增加服务器负担，基于这种考虑的解决方式的代表为FastCGI，这是由OpenMarket 公司开发了一个基于CGI的新标准，一个FastCGI程序能驻留在系统中，和Web服务器通信，并多次回应CGI请求，而不必重新生成进程。FastCGI程序与标准CGI程序非常类似，仅仅需要简单的修改原有的CGI 程序，就能支持FastCGI。FreeBSD下没有支持FastCGI的Port，因此要支持FastCGI就需要重新手工编译安装。

　　另一个角度是从服务器端分析功能入手，既然SSI功能较弱，可以进一步在服务器内部提供更复杂的功能，PHP 就是一个代表，PHP具备丰富的数据库支持能力，因此非常流行。然而PHP却有相应的Port支持，因此可以使用 Ports Collection轻松安装PHP，同时这个Port还支持和mod_ssl相集成，可以通过选择同时集成 php3和mod_ssl。需要注意的是在安装之前仍然需要清除原有设置文件，以免带来不必要的麻烦。

　　Apache-PHP3具备一个预编译好的二进制软件包，如果不想重新编译Apache，可以直接使用这个软件包。要建立一个复杂的网站，至少要使用这个预编译好的软件包，以提供高效率的动态网页支持。

　　此外，由于CGI程序使用Perl编程的非常之多，因而一个非常有意义的作法为将perl解释器和Apache 集成在一起，这样在执行perl程序时就不需要重新载入Perl解释器了，这样同样也能数倍提高服务器的效率。支持集成perl到Apache中的模块为mod_perl，它充分发挥了perl的强大功能。在这种方式下，不但可以直接执行perl编写的CGI程序，还可以在嵌入perl语句，甚至使用perl控制Apache服务器的行为，包括使用perl来编写Apache的内部功能处理模块。mod_perl同样也没有Port Collection支持，需要自己下载软件重新编译Apache。

　　FastCGI、PHP3和嵌入的perl只是在Apache服务器上最流行的几种新特性，使用它们可以非常高效的完成动态网页的生成。这些新特性对于建立一个高负载的站点是必需的。但是，也没有必要同时都提供支持，不同的使用者会喜欢使用不同的动态网页生成方式。其中PHP3的安装和设置非常简单，它又是服务器端分析方式，因此是在做新站点时的首选方式。而如果有大量原有的CGI程序需要继承，就可以选择FastCGI，perl的忠实拥护者则会选择modperl。

    * 调整系统设置

　　由于Apache服务器是采用传统的生成子进程的方式来提供服务的形式，这种形式比较适合服务比较复杂的情况，但性能却没有单进程的服务器高，尤其在高负载的情况下更是如此。一些使用单进程的Web服务器，都其声称提供静态网页的速度为Apache服务器的几倍，例如能通过Ports Collection安装的boa，或者另一个非常简单的服务器thttpd，它们提供静态网页的速度的确是Apache服务器无法与之相比的。当然，这些服务器除了因为其是单进程的服务，效率较高之外，还因为这些服务器没有提供复杂的特性，包括安全认证等，例如安全认证就需要Web服务器读取其上面各级目录的访问许可，这些额外的文件操作会明显降低服务器的效率。然而，由于执行CGI处理时，服务器都必须启动外部进程，这些简易的服务器就不再具备什么优势了。

　　因此，如果使用者仅仅是想提供简易的静态网页服务，完全可以不必使用Apache服务器，单进程服务器性能更好，但使用者也无法利用Apache服务器提供的各种优秀特性了。然而，即使是使用Apache服务器，对提高效率也提供了很多设置参数，如果能将这些参数调整的合适，就能进一步提高服务器的性能，缩小与单进程服务器性能的差别。

　　有些性能损失，如提供安全控制的特性造成的损失，只能尽量减少，而无法消除。为了减少这些特性造成的损失，对于安全控制，可以在设置文件中针对根目录指定AllowOverrider None禁止查找.htaccess文件，只对于特定需要访问控制的目录才打开访问控制功能。此外，还要设置XbitBack为Off来关闭缺省文档的SSI 功能，只使用AddHandler指令执行SSI文档。

　　除了高级特性找成的性能损失之外，还有的性能损失是由于子进程服务的方式造成的，Apache服务器在这个方面做了很大的努力，由于使用服务器的用户需求多种多样，因此缺省需求并不一定最适合服务器，便需要调整参数设置。

　　为了提升服务器性能，Apache服务器所做的一个有效的改动为使一个子进程能服务多次HTTP请求，这样就不再需要不断生成进程造成的性能损耗。但同时为了避免一个进程服务提供过多的次数的服务造成内存垃圾，Apache定义了一个MaxRequestPerChild来规定一个进程提供服务的次数，缺省设置为30。如果服务器提供的为静态网页，产生内存垃圾的机会就很少，可以将其设置为2000或者更高。即使服务器载入了各种不同的功能模块，产生内存垃圾的机会就多一些，可以相应将这个值的设置降低一些。

　　此外，还可以定义另一个参数MaxClients，用于设置Apache服务器可以同时拥有的最多进程数。进程数目越多，那么占用的内存数量就越大，一旦占用的内存超过系统的物理内存，那么就必须有多余的进程被交换到交换空间中，这样的事情一旦发生，服务器的效率就急剧降低了。因此，即使希望服务器能同时提供较多的服务，也不能超过服务器的物理内存限制进行设置。通常这可以通过计算进行估计，根据每个httpd守护进程占用空间的大小计算出这个数值的上限。或者可以根据系统维护命令，如top等，观察每个子进程占用的空间及系统内存分配情况。一般来讲，Apache服务器占用的空间并不会特别厉害，但一旦载入特别的模块，特别是modperl，它就会使用较多的内存。

　　原则上虽然可以使用物理内存来估算MaxClients的值，但是一方面还要考虑CPU的处理能力，当系统进程过多的时候，系统在进程之间切换造成的资源损失太大，就得不偿失了（top命令中的CPU利用率选项中，有一项sys 就用于标识内核占用的处理器处理时间的比率，这一个比率不应该过大）。另一方面，由于FreeBSD是合并内存和磁盘缓冲区的机制，因此应该给磁盘缓冲区留下一定的大小，毕竟Web服务器中磁盘I/O的性能也非常重要。

　　FreeBSD中，编译时设定了最大的客户进程数为512，这是一个硬性设置，不能通过配置文件来更改的。如果想想将MaxCliets设置为大于512，就必须使用新的HARD_SERVER_LIMIT定义重新编译Apa che服务器。在非Ports Collection编译的Apache版本中，它的缺省设置为256。

　　因此就需要综合考虑这些因素来设置MaxClients，首先要为磁盘缓冲区留下足够的空间，并以不交换到交换设备上为原则，定出一个上限值，然后根据处理器的情况进行分析。如果这个站点主要提供的是静态网页，那么对处理器的要求不大，就可以设置MaxClients为接近内存许可的上限值。如果这个站点有很多CGI程序，尤其是当这些CGI 程序需要执行繁重的处理任务时，那么系统启动过多的CGI程序，都不会迅速结束，反而不如让系统启动较少的CGI程序效率高，因此就要考虑适当降低MaxClients的设置。

　　考虑Maxclients设置的前提是同时有超出现有Maxclients设置的并发请求发生，如果系统本来就没有那么多的并发请求，就不必考虑增加这个设置的值，而应该使用最大并发访问请求数来设置这个参数。

　　为了确定服务器的最优设置，可以通过使用Apache提供的一个性能测试软件ab来进行模拟访问，这个程序缺省被安装到/usr/local/sbin中。例如使用ab向本地服务器的一个网页同时发起50个连接，共进行1000次连接，就执行：

bash-2.02$ /usr/local/sbin/ab -n 1000 -c 50 localhost/
This is ApacheBench, Version 1.2
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/

Server Software:        Apache/1.3.4
Server Hostname:        localhost
Server Port:            80

Document Path:          /
Document Length:        360 bytes

Concurrency Level:      50
Time taken for tests:   3.881 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      607212 bytes
HTML transferred:       360720 bytes
Requests per second:    257.67
Transfer rate:          156.46 kb/s received

Connnection Times (ms)
              min   avg   max
Connect:        0     0     1
Processing:    26   190  1034
Total:         26   190  1035

　　先调整相应的设置，然后使用ab模拟真实情况下的连接，来测试服务器的性能，并进一步调整参数以获得最佳的设置。

　　为了避免服务器进程在系统空闲时被无意义的杀死，可以简单的将MinSpareServers、MaxSpa reServers和StartServers的值设置为与MaxClients的值相同。这种设置方式对于总是处于重负载的专业Web站点的设置方式，对于业余站点，就没有必要如此设置，这些值都可以设置得较小，以便来没有客户访问时，系统负载可以降低，留出处理能力完成其他任务。

未完，待续。。。　　

probing

提升静态网页服务能力的综合方式

　　由于真正的HTTP请求常常是混合了静态请求和动态页面请求，那么很难调整Apache的设置使其既能适合静态网页请求，又能适合动态网页请求。为了提升Web服务的性能，还可以使用多个服务器，来帮助提升服务器性能。

    * 代理服务器的加速模式

　　由于Apache服务器不能够特别高效的提供静态网页服务，那么就可以使用一些辅助手段来帮助Apache服务器来高效的实现静态网页服务。一个有效的方法为使用代理服务器Squid，Squid具备一种加速模式，这个模式下 Squid能将所有的HTTP请求转发给内部的真正Web服务器。然而由于Squid是单进程的服务器，这样就不会因为并发访问而产生大负载，并且它具备对静态网页的缓存功能，使得Squid不必每次都需要访问后端Web服务器。因此使用Squid能明显减轻对静态网页频繁访问造成的负载问题。

　　由于Squid不会带来很大的CPU负载，因此不必要让Squid单独运行在一台服务器上，可以让Squid 和Apache服务器同时运行在一台服务器上，这样通过对磁盘I/O产生一些额外的负载，但能有效的增加静态网页的服务能力。

　　请查看Squid的手册以得到如何设置加速模式的方法，Squid软件包含在FreeBSD的Packages Collection中。

    * 分离静态网页服务器和动态网页服务器

　　由于Apache提供静态网页的服务能力不佳，那么可以将静态请求交给效率较高的服务器软件，如thttpd ，而动态请求较给Apache服务器来执行处理。这样的缺点就是其他的简易Web服务器不能提供Apache服务器一样的丰富功能，因此虽然这样做会提升效率，但一般并不建议这样设置服务器。

　　考虑到Apache服务器的设置因素，如果设置合适，Apache服务器本身就能提供高效的静态页面服务，只是当静态页面和动态页面混合的时候，就无法决定最优设置。尤其是当Apache支持了一些特定模块的时候，这些模块将使用大量的内存（例如一个mod_perl可能占据10M以上的内存空间），使得即使这个服务器是提供静态网页服务时，也要占用那么多内存，这样就使得为动态网页定制的设置完全不适合静态网页。

　　因此为了解决服务器的不同情况下的优化设置不同的问题，就可以在一台计算机同时运行两个Apache服务器，一个比较纯粹，没有支持额外的模块，只是为了和第二个服务器协作，需要支持proxy模块，用于支持静态网页，同时提供对第二个Apache服务器的代理请求，第二个Apache服务器可以载入复杂的模块，以支持动态网页。

　　两个Apache服务器可以根据不同的需要，进行不同的参数调整。第一个Apache服务器只进行静态网页服务和代理服务，因此可以将MaxClients设置的较大，而第二个Apache服务器要提供消耗处理器能力的动态网页服务，因此就要将MaxClients设置的较小。此时在第一个Apache服务器上设置其代理功能，虽然Apache 的代理能力比不上Squid优秀，然而这简化了服务器的种类，并能使用同一的访问控制手段。

　　此时代理服务器是用于代理动态网页请求，和前面使用Squid代理静态网页请求的目的不同。但是也可以适用 Squid，在外部访问静态网页的时候，它代理访问第一个Web服务器，访问动态网页的时候，代理访问第二个Web服务器。

　　当使用这种设置方式的时候，为了使得外部客户访问第一个服务器时能自动代理到第二个服务器上，就需要在第一个 Apache上使用ProxyPass参数进行设置，将用于动态网页的CGI请求转发给第二个服务器。此时就有不同的选择，可以使用两个计算机各自运行一个Web服务器，也可以在一台计算机上安装两个Apache服务器，第一个服务器监听普通的80端口，而第二个服务器监听其他端口，例如3456，在第一个服务器的httpd.conf中设置ProxyPass：

ProxyPass /cgi-/bin/ http://localhost:3456/cgi-bin/

　　当在一个计算机上安装两个Apache服务器的时候，必须注意安装路径的问题。至少有一个服务器不能使用 Ports Collection直接安装，应该更改过路径设置编译安装。

未完，待续。。。　　

probing

负载均衡技术

　　可以使用上面提到的各种技术来提升Apache服务器的性能，同时也可以使用增加硬件性能的方法来提高Web 服务器的性能。但是单台服务器的性能总是有限的，尤其是服务器上需要运行大量的CGI程序时，不可能仅靠上面的调整服务器设置的方法来建立一个面向整个Internet，如同Yahoo等站点一样的高负载Web站点。

　　为了建立一个高负载的Web站点，必须使用多服务器的分布式结构。上面提到的使用代理服务器和Web服务器相结合，或者两个Web服务器相互协作的方式也属于多服务器的结构，但在这些多服务器的结构中，每个服务器所起到的作用是不同的，属于非对称的体系结构。非对称的服务器结构中每个服务器起到的作用是不同的，例如一个服务器用于提供静态网页，而另一个用于提供动态网页等等，这样就使得网页设计时就需要考虑不同服务器之间的关系，一旦要改变服务器之间的关系，就会使得某些网页出现连接错误，不利于维护，可扩展性也差。

　　另外一种多服务器的设计结构为对称结构，在对称结构中每台服务器都具备等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。然后，可以通过某种技术，将外部发送来的请求均匀分配到对称结构中的每台服务器上，接收到连接请求的服务器都独立回应客户的请求。在这种结构中，将外部请求均匀分配到服务器上的技术称为负载均衡技术，由于建立内容完全一致的Web服务器并不困难，因此负载均衡技术就成为建立一个高负载Web站点的关键性技术。

    * 基于DNS的负载均衡

　　最早的负载均衡技术是通过DNS服务中的随机名字解析来实现的。在DNS服务器中，可以为多个不同的地址配置同一个名字，这个数据被发送给其他名字服务器，而最终查询这个名字的客户机将在解析这个名字时随机使用其中一个地址。因此，对于同一个名字，不同的客户机会得到不同的地址，因此不同的客户访问的也就是不同地址的Web服务器，从而达到负载均衡的目的。

　　例如如果希望使用三个Web服务器来回应对www.exampleorg.org.cn的HTTP请� ... �类似的结果：

www1                IN                A                 192.168.1.1
www2                IN                A                 192.168.1.2
www3                IN                A                 192.168.1.3
www                IN                CNAME                www1
www                IN                CNAME                www2
www                IN                CNAME                www3

　　这里先为每个计算机定义一个真实名字，然后再为它们定义同一个别名。直接针对不同地址设置同一个真实名字（A记录）也是可行的，但使用别名的方法易于管理一些。

　　由于此时反向解析只能针对一台计算机，那么每个Web服务器都需要使用ServerName重新定义同一个名字，或者设置名字解析的顺序为hosts文件优先，并在hosts文件中定义本身为www，以保证每个服务器的名字设置保持一致。

　　此后外部的客户机就可能随机的得到对应www的不同地址，那么随后的HTTP请求也就会发送给不同地址了。

　　当使用DNS负载均衡的时候，必须尽量保证不同的客户计算机能均匀获得不同的地址。由于DNS数据是具备一个刷新时间的标志的，一旦超过这个时间限制过期，其他DNS服务器就需要和这个服务器交谈以重新获得地址数据，就有可能获得不同IP地址。因此为了使得地址能随机分配，就应该使得刷新时间尽量短，不同地方的DNS服务器能更新对应的地址，使得地址获得能随机一些。然而将过期时间设置的过低将使得DNS流量大增，而造成额外的网络问题。出于折衷的考虑，一般将刷新时间设置为1个小时。

　　DNS负载均衡的一个问题是一旦某个服务器出现故障，即使及时修改了DNS设置，还是要等待足够的时间（刷新时间）才能发挥作用，在此期间保存了故障服务器地址的客户计算机将不能正常访问服务器。

　　尽管存在多种问题，然而它还是一种非常有效的做法，当前使用在包括Yahoo在内的很多Web站点上。

未完，待续。。。　　

probing

反向代理负载均衡

　　前面提到了使用代理服务器可以将请求转发给内部的Web服务器，使用这种加速模式显然可以提升静态网页的访问速度。然而，也可以考虑这样一种技术，使用代理服务器将请求均匀转发给多台Web服务器上，从而达到负载均衡的目的。

　　Apache开发组的一位成员Ralf S.Engelschall基于Apache的代理模块mod_proxy开发了反向代理模块mod_rproxy，用于实现负载均衡，请参考他的文章Load Balancing Your Web Site： http://www.WebTechniques.com/fea ... l/engelschall.shtml

　　这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部Web服务器，而这种代理方式是代理多个客户访问内部Web服务器，因此也被称为反向代理模式。Squid的加速模式与此相似，但没有实现对多内部服务器的均衡设置。虽然实现这个任务并不能算是特别复杂，然而由于要求特别高的效率，则实现起来并不是十分简单。

　　使用反向代理的好处是，可以将负载均衡和代理服务器的高速缓存技术结合在一起，提供有益的性能。然而它本身也存在不小的问题，首先就是必须为每一种服务都专门开发一个反向代理服务器，这就不是一个轻松的任务了。并且，虽然代理服务器本身虽然可以设计的效率非常高，但是每针对每一次代理，代理服务器就必须维护两个连接，一个对外的连接，一个对内的连接，因此对于特别高的连接请求的时候，代理服务器的负载也就非常之大了。很可能在最后反向代理服务器成为了服务的瓶颈。

未完，待续。。。

probing

基于NAT的负载均衡技术

　　网络地址转换为Internet网关的一个重要功能，它能将内部地址和外部地址进行转换，以使具备内部地址的计算机能访问外部网络。同样外部网络访问网关拥有的某一外部地址时，地址转换网关能将其转发到该地址映射的内部地址的计算机上。

　　因此，可以通过重新修改地址转换程序，使得地址转换网关能将请求均匀转换为内部的多个服务器的内部地址，此后外部网络中的计算机就各自与自己转换得到的内部服务器进行通信了。

　　要实现这个负载均衡软件，仍然需要更改原有的地址转换程序。然而，由于FreeBSD下提供了地址转换工具 natd及其源代码，因此这个任务并不复杂。通过更改natd，可以使得在FreeBSD上实现负载均衡能力。

    * 第四层交换

　　由于地址转换相对来讲比较接近网络的低层，因此就有可能将它集成在硬件设备中，通常这样的硬件设备为局域网交换机。

　　当前先进的局域网交换机开始支持所谓的第四层交换技术，就是按照IP地址和TCP端口进行虚拟连接的交换，直接将数据包发送到目的计算机的相应端口中。通过可以进一步增强它的功能，通过交换机就能将来自外部的初始连接请求，分别与内部的多个地址相联系，此后就能对这些已经建立的虚拟连接进行交换。因此一些具备第四层交换能力的局域网交换机，就能作为一个硬件负载均衡器，完成Web服务器的负载均衡。

　　由于第四层交换基于硬件芯片，因此其性能非常优秀，尤其是对于网络传输的速度，交换的速度远远超过普通的数据包转发。然而正因为它是使用硬件实现的，因此也比较不灵活，仅仅能够处理几种最标准的应用协议的负载均衡，如HTTP 。当前负载均衡主要用于解决Web服务器的处理能力不足的问题，因此并不能充分发挥交换机带来的高网络带宽的优点。

全书完

probing

freebsd和linux都是unix的变体,谁好谁孬不可比,但很多的知识是相通的,最近论坛里很多兄弟都在问有关bsd的问题,所以特地贴出来王波的这本电子书,以便大家查阅,感觉贴到linu其它版也不太合适,所以放到我自己的版块里了,先置顶一个月了,.....

komodo

感谢版主辛苦的一贴一贴的贴出
为了阅读更方便。。。
找来电子书也可以看看 点击FreeBSD

阿涛

对版主的辛苦劳动表示衷心的感谢！！！

NetDust

好累呢.........