在帮客户购买的vps上面安装完SSL以后，每次启动apache时都需要输入密码，觉得维护起来非常的麻烦。

客户的vps是ubuntu Sever，其他linux服务器找到相关文件修改

编辑：ssl.conf ,

ubuntu下面的目录：

/etc/apache2/mods-available/ssl.conf

修改ssl.conf

# SSLPassPhraseDialog builtin

SSLPassPhraseDialog exec:/ect/apache2/key.sh

编辑：/ect/apache2/key.sh

!/bin/bash

echo ‘your pass phrase’

注意key.sh的权限755

重启服务器

问题解决

无相关文章，以下随机显示

• 2009年02月17号 -- 在64位机器上关于Apache 2.2.3版的编译问题
• 2009年02月10号 -- Apache高级配置中文详解
• 2009年08月13号 -- Linux下Apache并发连接数和带宽控制
• 2009年08月16号 -- Apache两种常用工作模式比较:prefork和worker
• 2009年01月6号 -- Apache 中KeepAlive 配置的合理使用(优化)
• 2010年04月13号 -- HTTP 状态代码解释
• 2009年08月13号 -- Apache和IIS共享80端口的四个方法
• 2009年02月7号 -- 在Apache下限制每个虚拟主机的并发数
• 2009年02月18号 -- apache和tomcat集成的总结
• 2009年02月25号 -- Apache 设置web 缓存

如果向您的服务器发出了某项请求要求显示您网站上的某个网页（例如，当用户通过浏览器访问您的网页或在 Googlebot 抓取该网页时），那么，您的服务器会返回 HTTP 状态代码以响应该请求。

此状态代码提供了有关请求状态的信息，且为 Googlebot 提供了有关您网站和请求的网页的信息。

一些常见的状态代码为：

200 – 服务器成功返回网页404 – 请求的网页不存在503 – 服务器暂时不可用以下提供了 HTTP 状态代码的完整列表。点击链接可了解详细信息。您也可以访问有关 HTTP 状态代码的 W3C 页来了解详细信息。

1xx（临时响应）

用于表示临时响应并需要请求者执行操作才能继续的状态代码。

2xx（成功）

用于表示服务器已成功处理了请求的状态代码。

3xx（已重定向）

要完成请求，您需要进一步进行操作。通常，这些状态代码是永远重定向的。Google 建议您在每次请求时使用的重定向要少于 5 个。您可以使用网站管理员工具来查看 Googlebot 在抓取您已重定向的网页时是否会遇到问题。诊断下的抓取错误页中列出了 Googlebot 由于重定向错误而无法抓取的网址。

4xx（请求错误）

这些状态代码表示，请求可能出错，已妨碍了服务器对请求的处理。

5xx（服务器错误）

这些状态代码表示，服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。

无相关文章，以下随机显示

• 2009年01月6号 -- Apache 中KeepAlive 配置的合理使用(优化)
• 2009年08月13号 -- linux下查看nginx，apache，mysql，php的编译参数
• 2009年08月13号 -- Apache+Django性能优化之mod_wsgi篇
• 2009年02月27号 -- Apache common-pool, common-dbcp源码解读与对象池原理剖析
• 2009年02月16号 -- Apache、resin、rewrite泛域名、多域名设置
• 2009年01月15号 -- Apache服务器安全防范
• 2009年02月25号 -- Apache 两种虚拟主机方式的区别
• 2010年03月9号 -- Apache2中俩种设置PHP的异同
• 2009年06月15号 -- 16个简单实用的.htaccess小贴示
• 2009年02月10号 -- Apache2运用mod_deflate提升网络页面浏览速度

1. 如果apache的多个进程只监听一个端口，则不需要AcceptMutex，每个apache进程都在执行accept操作，发现请求后就开始执行，执行完继续accept，多个进程之间不会相互干扰，这是由accept的机制来完成的。

2. 如果apache的多个进程只监听socket多于一个，则不能直接accept了，就必须使用select或poll机制来发现知否有请求需要执行，发现之后，再由accept来接受请求；然而select或poll没有accept那么能自动处理互斥的问题，这时候就需要一个“锁”了，就是所谓的AcceptMutex，AcceptMutex的实现形式有多种，这个不属于本文讨论的范围。

下面是apache在监听三个socket（[16 17 18]）时，其中一个进程的表现：

semop(524288, 0x81dd334, 1)             = 0

select(19, [16 17 18], NULL, NULL, NULL) = 1 (in [17])

accept(17, {sa_family=AF_INET, sin_port=htons(52932), sin_addr=inet_addr(“10.55.38.9″)}, [16]) = 29

semop(524288, 0x81dd33a, 1)             = 0

第一步：先获取锁（0x81dd334）， 同一时刻只有一个进程能获取锁

第二步：开始select（对于apache2这里好像是poll，poll的效率更高一些），并且发现17需要处理了

第三步：accept 17

第四步：释放锁，这样其它进程就可以获取锁并处理后续的请求了

无相关文章，以下随机显示

• 2009年02月10号 -- Apache 中内存管理的三种境界
• 2009年02月25号 -- Apache并发控制、查看进程数、TCP连接、压缩功能说明
• 2009年02月10号 -- apache 无法启动故障排查
• 2009年02月10号 -- 谈谈Apache的优化
• 2009年02月26号 -- Apache日志文件（配置和管理）
• 2009年01月6号 -- htaccess学习笔记
• 2009年02月6号 -- gzip 与 deflate
• 2009年02月6号 -- YouTube 架构学习
• 2009年03月9号 -- 监视并记录Apache网站服务器的运行
• 2009年02月6号 -- TCP 相关参数解释

和我之前介绍过的PHP lifecycle不同, 这种情况下的PHP, 通过注册handler钩子, 从而可以在handler hook阶段有机会处理请求, 通过判断请求的handler, 来确定是否需要处理, 如果需要就会调用自身的处理器.

那么, 这种情况下也就有了多种配置方法, 主要考虑如下俩种方式(第二种可以有多种变种):

第一种: AddType application/x-httpd-php .php
第二种:
      <FilesMatch \.php$>
          SetHandler application/x-httpd-php

首先来说, 这俩中方式的起作用的时刻不同, 对于第一种方式来说, 他是在type_check钩子阶段起作用的, 也就是在apache2src/modules/http/mod_mime.c中, 通过注册type_checker钩子, 加入find_ct(content_type), 在find_ct中, 通过配置文件中的mime映射, 或者是通过addType指令增加的映射, 根据文件的扩展来填充请求中的handler字段:

而对于第二种方式, 是在fixup钩子阶段, 通过注册fixups钩子阶段加入core_override_type(apache2src/server/core.c)函数, 来将目录级的配置指令生效.

而fixups钩子是晚于type_checker钩子的, 也是handler钩子之前最后的一个可以利用的钩子. 所以如果同时采用1,2俩种方式, 那么第二种方式会覆盖第一种方式设置的handler.

其次, 俩种方式依赖的数据结构不同, 第一种方式依赖的是一个全局的mime对照表extension_mappings, 这个表由mime配置文件和AddType指令而来.

而对于第二种方式, 它是根据配置文件构造的dir_config而来:

….
  core_dir_config *conf =
        (core_dir_config *)ap_get_module_config(r->per_dir_config,
                                                &core_module);
 
    /* Check for overrides with ForceType / SetHandler
*/
    if (conf->mime_type && strcmp(conf->mime_type, “none”))
        ap_set_content_type(r, (char*) conf->mime_type);
 
    if (conf->handler && strcmp(conf->handler, “none”))
        r->handler = conf->handler;

相关文章

• 2009年02月26号 -- Apache日志文件（配置和管理）
• 2009年02月10号 -- Apache高级配置中文详解
• 2009年01月22号 -- Apache配置文件(httpd.conf)中文说明
• 2008年12月27号 -- apache禁止使用IP访问的实现方法
• 2008年12月27号 -- apache中.htaccess的功能及写法
• 2008年12月27号 -- apache的配置优化
• 2008年12月25号 -- 使用gzip将你的Apache速度提高十倍

RewriteEngine on
RewriteBase /twosisters
 
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

问题就解决.
估计把index.php改成绝对路径也没有问题。

相关文章

• 2009年12月12号 -- .htaccess的301跳转
• 2009年06月15号 -- 16个简单实用的.htaccess小贴示
• 2009年01月6号 -- htaccess学习笔记
• 2009年01月6号 -- Apache服务器使用.htaccess实现图片防盗链方法教程
• 2008年12月27号 -- apache中.htaccess的功能及写法

    废话少说，下面就来解释一下负载均衡的设置方法。

    一般来说，负载均衡就是将客户端的请求分流给后端的各个真实服务器，达到负载均衡的目的。还有一种方式是用两台服务器，一台作为主服务器(Master)，另一台作为热备份(Hot Standby)，请求全部分给主服务器，在主服务器当机时，立即切换到备份服务器，以提高系统的整体可靠性。

    负载均衡的设置

    Apache可以应对上面这两种需求。先来讨论一下如何做负载均衡。首先需要启用Apache的几个模块：

以下是引用片段：
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so

    mod_proxy提供代理服务器功能，mod_proxy_balancer提供负载均衡功能， mod_proxy_http让代理服务器能支持HTTP协议。如果把mod_proxy_http换成其他协议模块（如mod_proxy_ftp），或许能支持其他协议的负载均衡，有兴趣的朋友可以自己尝试一下。

  然后要添加以下配置：

以下是引用片段：
ProxyRequests Off
<Proxy balancer://mycluster>
    BalancerMember http://node-a.myserver.com:8080
    BalancerMember http://node-b.myserver.com:8080
</Proxy>
ProxyPass / balancer://mycluster 

# 警告：以下这段配置仅用于调试，绝不要添加到生产环境中！！！
<Location /balancer-manager>
    SetHandler balancer-manager
    Order Deny,Allow
    Deny from all
    Allow from localhost
</Location> 

    从上面的 ProxyRequests Off 这条可以看出，实际上负载均衡器就是一个反向代理，只不过它的代理转发地址不是某台具体的服务器，而是一个 balancer:// 协议：

以下是引用片段：
ProxyPass / balancer://mycluster

    协议地址可以随便定义。然后，在段中设置该balancer协议的内容即可。BalancerMember指令可以添加负载均衡组中的真实服务器地址。

    下面那段是用来监视负载均衡的工作情况的，调试时可以加上（生产环境中禁止使用！），然后访问 http://localhost/balancer-manager/ 即可看到负载均衡的工作状况。

    OK，改完之后重启服务器，访问你的Apache所在服务器的地址，即可看到负载均衡的效果了。打开 balancer-manager 的界面，可以看到请求是平均分配的。

    如果不想平均分配怎么办？给 BalancerMember 加上 loadfactor 参数即可，取值范围为1-100。比如你有三台服务器，负载分配比例为 7:2:1，只需这样设置：

以下是引用片段：
ProxyRequests Off
<Proxy balancer://mycluster>
    BalancerMember http://node-a.myserver.com:8080 loadfactor=7
    BalancerMember http://node-b.myserver.com:8080 loadfactor=2
    BalancerMember http://node-c.myserver.com:8080 loadfactor=1
</Proxy>
ProxyPass / balancer://mycluster

    默认情况下，负载均衡会尽量让各个服务器接受的请求次数满足预设的比例。如果要改变算法，可以使用 lbmethod 属性。如：

以下是引用片段：
ProxyRequests Off
<Proxy balancer://mycluster>
    BalancerMember http://node-a.myserver.com:8080 loadfactor=7
    BalancerMember http://node-b.myserver.com:8080 loadfactor=2
    BalancerMember http://node-c.myserver.com:8080 loadfactor=1
</Proxy>
ProxyPass / balancer://mycluster
ProxySet lbmethod=bytraffic

    lbmethod可能的取值有：

    各种算法的原理请参见Apache的文档。

    热备份(Hot Standby)

    热备份的实现很简单，只需添加 status=+H 属性，就可以把某台服务器指定为备份服务器：

以下是引用片段：
ProxyRequests Off
<Proxy balancer://mycluster>
    BalancerMember http://node-a.myserver.com:8080
    BalancerMember http://node-b.myserver.com:8080 status=+H
</Proxy>
ProxyPass / balancer://mycluster

    从 balancer-manager 界面中可以看到，请求总是流向 node-a ，一旦node-a挂掉，Apache会检测到错误并把请求分流给 node-b。Apache会每隔几分钟检测一下 node-a 的状况，如果node-a恢复，就继续使用node-a。

无相关文章，以下随机显示

• 2009年02月10号 -- 谈谈Apache的优化
• 2009年02月10号 -- Apache 中内存管理的三种境界
• 2009年02月25号 -- Apache 两种虚拟主机方式的区别
• 2009年03月9号 -- Apache 2.0中prefork.c模块和worker.c模块的比较
• 2009年02月10号 -- apache + resin的多机部署方案实现方法
• 2009年02月27号 -- 使用mod_headers或mod_expires落实缓存
• 2009年02月27号 -- header Content-Type类型
• 2009年02月7号 -- 使用apache下的301设置来做域名的更换转移
• 2010年03月9号 -- htaccess二级目录重写找不到路径
• 2008年12月27号 -- apxs – Apache 扩展工具

无相关文章，以下随机显示

• 2009年01月6号 -- 不再为Apache进程淤积、耗尽内存而困扰
• 2009年02月25号 -- Apache缓存系统
• 2009年09月6号 -- 网络流量尽在掌控
• 2009年02月27号 -- header常用指令
• 2009年02月7号 -- 使用apache下的301设置来做域名的更换转移
• 2009年02月27号 -- Apache common-pool, common-dbcp源码解读与对象池原理剖析
• 2008年12月27号 -- Apache服务器限制并发连接和下载速度
• 2009年04月8号 -- apache软件体系结构
• 2009年02月6号 -- YouTube 架构学习
• 2009年08月13号 -- Linux下Apache并发连接数和带宽控制

add mod_rewrite:1、sudo a2enmod rewrite 2、udo vim /etc/apache2/sites-enabled/000-default

将其中的：

AllowOverride None

修改为：

AllowOverride All

重启生效。

将 htmldata.cn 转换为 www.htmldata.cn

相关文章

• 2010年03月9号 -- htaccess二级目录重写找不到路径
• 2009年06月15号 -- 16个简单实用的.htaccess小贴示
• 2009年02月7号 -- 使用apache下的301设置来做域名的更换转移
• 2009年01月6号 -- htaccess学习笔记
• 2009年01月6号 -- Apache服务器使用.htaccess实现图片防盗链方法教程
• 2008年12月27号 -- apache中.htaccess的功能及写法

中国移动研究院 李洋博士

近十几年来，互联网得到了飞速发展。据统计，互联网目前已成为人类社会最重要的信息基础设施，占人类信息交流的80%。在这种大背景下，面对日益复杂的网络联机及逐渐增加的网络流量，系统和网络管理者必须花更多时间和精力来了解这些网络设备的运作状况，以维持一个企业网络的正常运作。一般来说，网络管理者需要了解各个网段频宽的使用率、网络问题的瓶颈发生于何处，一旦网络发生问题，必须能够很快地分析和判断出问题的发生原因，这些就是网络流量管理的主要工作内容。那么，管理网络流量的时候应该基于什么样的依据，通过什么手段和策略有效地把流量进行识别、分析和管理呢？

网络流量管理的目标

随着网络流量的不断增长以及网络应用的日趋纷繁复杂化，我们不难看到，简单、无限制地增加网络带宽是不能解决网络流量的根本问题的。我们需要对网络流量进行管理，从而保证网络的健康和网络应用的正常服务。

在网络流量管理的过程中，我们首要的问题就要明确网络管理目标。在网络流量管理主要有4个目标： 首先，我们要了解网络流量的使用情况； 其次，要找到优化网络性能的途径；第三，要通过网络管理技术来提升网络效能；最后，还需要做好网络流量信息安全方面的防护工作。

要达到上述4个目标，网络管理员首先要通过有效的分类方式非常明确地知道，我们需要的带宽到底哪些是实际使用的。其次是找到网络性能的瓶颈。网络性能有两个很重要的指标，一个是吞吐量，即网络能够传输的最大数据量，另一个是延迟等。第三，应用成熟的流量监控及控制软件来提升网络性能，从而满足不同的网络应用需求。最后，网管们还可以综合运用入侵检测系统（IDS）、防火墙、统一威胁管理（UTM）设备来对网络流量进行信息安全方面的防护工作。

在日常的网络流量管理中，为了有效实现网络管理4个目标，我们需要采取相应的步骤。这个步骤包括网络流量捕捉和分类、网络流量监视（统计和分析）和控制策略。

1. 网络流量捕捉和分类：这是进行网络流量管理的第一步。只有通过设置捕捉点，对网络流量进行捕捉和分类，才能进行后续的分析和控制工作。这里特别需要强调的是，网络流量分类可以非常宏观化，也可以细化。比如TCP、UDP、ICMP等分类就比较宏观，而HTTP、FTP甚至是诸如Kazza、Skype等P2P流量的分类和识别就比较细化了。在日常工作中，网络管理员可以采用Wireshark、TCPDump等知名的报文捕捉和分析软件进行流量捕捉和分类工作。

2.网络流量监视（分析）：监视用来显示流量的运行状况，帮助找出问题所在和执行相应的管理策略。应用程序和网络管理能够收集分类、展示和收集信息，包括带宽利用率、活跃的主机和网络效率以及活跃的应用程序。该目标可以通过采用市面上常见的NTOP等可视化分析管理工具来协助网络管理员在实际工作中实现。

3. 控制策略：网络流量分析的下一步是根据优先级别分配带宽资源。分配的依据可以是主机、应用等等，特别需要考虑的是注意将消耗资源的P2P程序或者音频视频下载等进行滞后考虑。具体操作时可以应用流行的流量控制工具来进行和实现，如进行分类监视和控制网络流量，这样，我们就可以将网络流量有效管理起来，将原来无序的网络流量变得有序起来。

以下我们具体介绍如何进行网络流量管理工作，包括网络流量的识别、网络流量的分析和控制。

网络流量的识别

流量识别，也叫业务识别（Application Awareness），是网络流量管理的第一步。网络流量识别通过对业务流量从数据链路层到应用层的报文深度检查分析，依据协议类型、端口号、特征字符串和流量行为特征等参数，获取业务类型、业务状态、业务内容和用户行为等信息，并进行分类统计和存储。业务识别的基本目的是帮助网络管理员获得网络层之上的业务层流量信息，如业务类型、业务状态、业务分布、业务流量流向等。

业务识别是一个相对复杂的过程，需要多个功能模块的协同工作，业务识别的工作过程简单描述如下：

1. 识别处理模块采用多通道识别处理，通过对网络流量的源/目的IP地址和源/目的端口号的Hash算法，将网络流量均匀地分配到多个处理通道中。

2. 多处理通道并行执行网络流量的深度报文检查，获取网络流量的特征信息，并与业务识别特征库中的特征进行比对。

3. 将匹配结果送往识别处理模块，并标识特定网络流量。如果存在多个匹配结果，选取优先级较高的匹配结果进行标识。特定网络流量一经识别确定，该网络流量的后续连接将不再进行深度的报文检查，直接将其网络层和传输层信息与已知识别结果进行比对，以提高执行效率。

4. 识别处理模块将网络流量的业务识别结果存储到识别结果存储模块中，为网络流量的统计分析提供依据。

5. 统计分析模块从识别结果存储模块中读取相关信息，并以曲线、饼图、柱状图或者文本的方式将识别结果信息显示或以文件的形式输出。

6. 在结果存储模块中保存的识别结果信息会输出到网络流量管理功能区，为实施网络流量管理提供依据。

目前常用的业务识别技术有两种，即DPI技术和DFI技术。

DPI技术 DPI是深度报文检测（Deep Packet Inspection）的简称。DPI技术之所以称为“深度”的检测技术，是相对于传统的检测技术而言的。传统的流量检测技术仅获取那些寄存在数据包网络层和传输层协议头中的基本信息，包括源/目的IP地址、源/目的传输层端口号、协议号，以及底层的连接状态等。通过这些参数很难获得足够多的业务应用信息，特别是对于当前P2P应用、VoIP应用、IPTV应用被广泛开展的情况，传统的流量检测技术已经不能满足网络流量管理的需要了。

DPI技术对传统的流量检测技术进行了“深度”扩展，在获取数据包基本信息的同时，对多个相关数据包的应用层协议头和协议负荷进行扫描，获取保存在应用层中的特征信息，对网络流量进行精细的检查、监控和分析。

DPI技术通常采用如下的数据包分析方法：

● 传输层端口分析。许多应用使用默认的传输层端口号，例如HTTP协议使用80端口。

● 特征字匹配分析。一些应用在应用层协议头或者应用层负荷中的特定位置包含特征字段，通过特征字段的识别实现数据包检查、监控和分析。

● 通信交互过程分析。对多个会话的事务交互过程进行监控分析，包括包长度、发送的包数目等，实现对网络业务的检查、监控和分析。

该技术如果进行更加详细的划分，还可分为特征字的识别技术、应用层网关识别技术、行为模式识别技术，这三类识别技术分别适用于不同类型的协议，相互之间无法替代，只有综合地运用这三大技术，才能有效、灵活地识别网络上的各类应用，从而实现控制和计费。

DFI技术 DFI是深度流行为检测（Deep Flow Inspection）的简称，也是一种典型的业务识别技术。DFI技术是针对DPl技术的不足提出的，为了解决DPI技术的执行效率、加密流量识别和频繁升级等问题。DFI更关注于网络流量特征的通用性，因此，DFI技术并不对网络流量进行深度的报文检测，而仅通过对网络流量的状态、网络层和传输层信息、业务流持续时间、平均流速率、字节长度分布等参数的统计分析，来获取业务类型、业务状态。

网络流量的统计分析

通过流量统计分析，网络管理者能够知道当前网络中的业务流量的类型、带宽、时间和空间分布、流向等信息。

在管理的过程中，管理员可以采用常见的NTOP工具来协助完成。NTOP工具与传统的tcpdump或ethereal等网络流量捕捉工具有着极大的差异，它主要是提供网络报文的统计数据，而不是报文的内容。此外，NTOP不需要使用Web服务器，它自身就支持HTTP协议。首先，它提供了一种快速容易的方法来得到网络活动的准确信息，并且不使用网络探测或侦听设备。在大多数情况下，网络探测器对追踪网络故障是必需的，而在某些时候可能因为探测器正被使用于监测其他设备而无法获得，就可以使用NTOP工具；其次，在某些给定的网络配置下可能无法与探测器连接，比如两个通过WAN互连的Unix系统，在这种情况下，用户可以应用NTOP工具。

一般说来，使用NTOP工具可以辅助网络管理员完成以下一些工作： 自动从网络中识别有用的信息； 将截获的数据包转换成易于识别的格式；对网络环境中通信失败的情况进行分析； 探测网络环境中的通信瓶颈； 记录网络通信的时间和过程。

NTOP工具可以通过分析网络流量来确定网络上存在的各种问题，也可以用来判断是否有黑客正在攻击网络系统，还可以很方便地显示出特定的网络协议、占用大量带宽的主机、各次通信的目标主机、数据包的发送时间、传递数据包的延时等详细信息。通过了解这些信息，网管员可以对故障做出及时的响应，对网络进行相应的优化调整，以保证网络运行的效率和安全。

网络流量的控制

将流量控制能力添加到网络流量管理中，能够帮助网络管理者对网络资源和业务资源进行带宽控制和资源调度，如对HTTP、FTP、SMTP以及P2P等应用进行管理，尤其是对P2P流量进行抑制来提升传统数据业务的用户体验度。

具备流量控制能力的网络流量管理还能够对严重影响业务运营者收入的未经许可的其他业务进行抑制。比如，对于VoIP业务，我们可以通过对VoIP信令流量和媒体流量的关联检测和统计分析，以及通过截断媒体数据包、伪装信令报文等方式对流量进行管理。还可以通过综合使用网络层、传输层和应用层检测技术，对未经许可的宽带私接用户采取中断连接、主动告警、分时控制等多种管理动作。

流量控制还能够帮助网络流量管理实现业务资源的调度，并能够获得业务资源使用、业务状态的实时情况。当某一网络应用业务服务器负载较大时，可以进行全局的业务资源负载均衡，以平均地承担业务请求；同时也能够对用户的业务请求进行调度，决定是否继续响应用户新的业务请求，并根据用户的优先级优先响应高优先级用户的业务请求，以提升业务运营效率。

流量控制通常的做法是在输出端口处建立一个队列进行流量控制，控制的方式是基于路由，亦即基于目的IP地址或目的子网的网络号。流量控制器基本的功能模块为队列、分类和过滤器。由于目前网络流量种类繁多，网络管理员在管理时通常都采用分类的方式进行。

对于网络流量管理来说，除了应具有上述的流量识别、流量分析和流量控制的功能之外，我们一般还希望其具有和防火墙等网络安全设备协同构建一个主动的安全威胁防御体系的功能，以提升整个网络的安全防护能力，从而更好地保证网络流量。

比如，流量特征识别分析就是一种必要的流量管理手段。它能够主动发现诸如DDoS攻击、病毒和木马等异常流量，较好地弥补其他网络安全设备如防火墙、入侵防护系统（IPS）和统一威胁管理（UTM）等的不足，提升其主动发现安全威胁的能力，并能够及时向其他网络安全设备发出告警，从安全威胁源头开始就进行主动的防御。此外，具备流量识别能力的网络流量管理还能够获取并保存网络流量的网络层信息（例如，源/目的IP地址、应用端口、用户标识ID等信息），通过这些信息，网络管理者能够对安全威胁进行溯源定位。

链接一 DFI技术与DPI技术比较

DFI与DPI两种技术的设计基本目标都是为了实现业务识别，但是两者在实现的着眼点和技术细节方面还是存在着较大区别的。从两种技术的对比情况看，两者互有优势，也都有短处，DPI技术适用于需要精细和准确识别、精细管理的环境，而DFI技术适用于需要高效识别、粗放管理的环境。

从处理速度来看： DFI处理速度相对快，而采用DPI技术由于要逐包进行拆包操作，并与后台数据库进行匹配对比，处理速度会慢些。由于采用DFI技术进行流量分析仅需将流量特征与后台流量模型比较即可，因此，与目前多数基于DPI的带宽管理系统的处理能力仅为线速1Gbit/s相比，基于DFI的系统可以达到线速10Gbit/s，完全可以满足企业网络流量管理的需求。

从维护成本来看： DFI维护成本相对较低，而基于DPI技术的带宽管理系统总是滞后新应用，需要紧跟新协议和新型应用的产生而不断升级后台应用数据库，否则就不能有效识别、管理新技术下的带宽，影响模式匹配效率；而基于DFI技术的系统在管理维护上的工作量要少于DPI系统，因为同一类型的新应用与旧应用的流量特征不会出现大的变化，因此不需要频繁升级流量行为模型。

从识别准确率来看： 两种技术各有所长。由于DPI采用逐包分析、模式匹配技术，因此，可以对流量中的具体应用类型和协议做到比较准确的识别；而DFI仅对流量行为分析，因此只能对应用类型进行笼统分类，如对满足P2P流量模型的应用统一识别为P2P流量，对符合网络语音流量模型的类型统一归类为VoIP流量，但是无法判断该流量是否采用H.323或其他协议。如果数据包是经过加密传输的，采用DPI方式的流控技术则不能识别其具体应用，而DFI方式的流控技术不受影响，因为应用流的状态行为特征不会因加密而根本改变。

链接二 几种常见的网络流量

当前随着网络应用的不断丰富和发展，网络流量也随之变得复杂和种类繁多起来，下面是最为常见的几种网络流量：

1. HTTP流量： HTTP是互联网上使用最为广泛的协议，早就已经取代传统文件下载的主要应用层协议FTP，如今，随着YouTube等视频共享网站的拉动，HTTP协议的网络流量在过去四年里首次超过了P2P应用的流量。

2. FTP流量：从互联网出现的开始，FTP就一直是用户使用频率最高的应用服务之一，重要性仅次于HTTP和SMTP。而随着P2P应用的出现，其重要性地位虽然有所降低，但是仍然是用户们下载文件不可替代的重要应用和途径之一。

3. SMTP流量：电子邮件是整个互联网业务重要的组成部分。据统计，3/4以上的用户上网的主要目的是收发邮件，每天有十数亿封电子邮件在全球传递。特别是由于电子邮件的廉价和操作简便，诱使有人将它作为大量散发自己信息的工具，最终导致了互联网世界中垃圾邮件的泛滥。

4. VoIP流量： 2006年全球IP电话用户从1030万增长到1870万，增幅达83%。2007年VoIP通话量已达到全部通话量的75%。因此，互联网上VoIP的流量也是非常值得管理员关注的。

5. P2P流量：目前网络带宽“消费大户”是P2P文件共享，在中东占据了49%，东欧地区占据了84%。从全球来看，夜间时段的网络带宽有95%被P2P占据。

6. Streaming流量：随着诸如PPLive、PPStream等视频软件的出现，视频直播和点播成为广大互联网用户观看节目和网上娱乐的最佳生活方式，因此其流量也在不断地增加。

无相关文章，以下随机显示

• 2009年02月27号 -- Apache common-pool, common-dbcp源码解读与对象池原理剖析
• 2010年04月13号 -- 解决linux下安装ssl后，apache重启时需要密码
• 2009年12月12号 -- apache配置（如何禁止列出目录内容）
• 2009年02月25号 -- Apache并发控制、查看进程数、TCP连接、压缩功能说明
• 2009年02月17号 -- 在64位机器上关于Apache 2.2.3版的编译问题
• 2009年02月16号 -- Apache、resin、rewrite泛域名、多域名设置
• 2009年02月10号 -- Apache Rewrite 规则详解
• 2009年01月5号 -- 关于keepalive的解释
• 2009年02月25号 -- apache ab压力测试收藏
• 2009年02月12号 -- 让apache支持自定义404页面错误

一、什么是HTTP Cache

对于浏览器的这种网页缓存机制大家已经耳熟能详了，举个例子来说，JavaEye的新闻订阅地址：http://www.javaeye.com/rss/news ， 当浏览器或者订阅程序访问这个URL地址的时候，JavaEye的服务器在response的header里面会发送给浏览器如下状态标识：

Etag “427fe7b6442f2096dff4f92339305444″
Last-Modified Fri, 04 Sep 2009 05:55:43 GMT

Etag “427fe7b6442f2096dff4f92339305444″
Last-Modified Fri, 04 Sep 2009 05:55:43 GMT

这就是告诉浏览器，新闻订阅这个网络资源的最后修改时间和Etag。于是浏览器把这两个状态信息连同网页内容在本地进行缓存，当浏览器再次访问JavaEye新闻订阅地址的时候，浏览器会发送如下两个状态标识给JavaEye服务器：

If-None-Match “427fe7b6442f2096dff4f92339305444″
If-Modified-Since Fri, 04 Sep 2009 05:55:43 GMT

If-None-Match “427fe7b6442f2096dff4f92339305444″
If-Modified-Since Fri, 04 Sep 2009 05:55:43 GMT

就是告诉服务器，我本地缓存的网页最后修改时间和Etag是什么，请问你服务器的资源有没有在我上次访问之后有更新啊？于是JavaEye服务器会核对一下，如果该用户上次访问之后没有更新过新闻，那么根本就不必生成这个RSS了，直接告诉浏览器：“没什么新东西，你还是看自己缓存的网页吧”，于是服务器就发送一个304 Not Modified的消息，其他什么都不用干了。

这就是HTTP层的Cache，使用这种基于资源的缓存机制，不但大大节省服务器程序资源，而且还减少了网页下载次数，节约了很多网络带宽。

二、HTTP Cache究竟有什么作用？

我们通常的动态网站编程，服务器端程序根本就不去处理浏览器发送过来的If-None-Match和If-Modified-Since状态标识，只要有请求就生成网页发送给浏览器。对于一般情况来说，用户不会总是没完没了刷新一个页面，所以大家并不认为这种基于资源的缓存有什么太大的作用，但实际情况并非如此：

1、像Google这种比较智能的网络爬虫可以有效识别资源的状态信息，如果使用这种缓存机制，可以大大减少爬虫的爬取次数。

比方说Google每天爬JavaEye网站大概15万次左右，但实际上JavaEye每天有更新的内容不会超过1万个网页。因为很多内容更新比较快，因此Google就会反复不停的爬取，这样本身就造成了很多资源的浪费。如果我们使用HTTP Cache，那么只有当网页内容发生改变的时候，才会真正进行爬取，其他时候我们直接告诉Google的爬虫304 Not Modified就可以了。这样不但降低了服务器本身的负载和爬虫造成的网络带宽消耗，实际上也大大提高了Google爬虫的工作效率，岂不是皆大欢喜？

2、很多内容更新不频繁的网页，尽管用户不会频繁的刷新，但是从一个比较长的时间段来看使用HTTP Cache，仍然可以起到很大的缓存作用。

比方说一些历史讨论帖子，已经过去了几个月了，这些帖子内容很少更新。用户可能通过搜索，收藏链接，文章关联等方式时不时访问到这个页面。那么只要用户访问过一次以后，后续所有访问服务器直接发送304 Not Modified就可以了，不用真正生成页面。

3、对于历史帖子使用HTTP Cache可以避免爬虫反复的爬取。

比方说JavaEye的论坛帖子列表页面，分页到20页后面的帖子已经很少有人直接访问了，但是从服务器日志去看，每天仍然有大量爬虫反复爬取这些分页到很后面的页面。这些页面由于用户很少去点击，所以基本上没有被应用程序的memcached缓存住，每次访问都会造成很高的资源消耗，爬虫隔一段时间就爬一次，对服务器是很大的负担。如果使用了HTTP Cache，那么只要爬虫爬过一次以后，以后无论爬虫爬多少次，都可以直接返回304 Not Modified了，极大的节省了服务器的负载。

三、如何在应用程序里面使用HTTP Cache

如果我们要在自己的程序里面实现HTTP Cache，是件非常简单的事情，特别是对Rails来说只需要添加一点点代码，以上面的JavaEye新闻订阅来说，只要添加一行代码：

def news
fresh_when(:last_modified => News.last.created_at, :etag => News.last)
end

def news
fresh_when(:last_modified => News.last.created_at, :etag => News.last)
end

用最新新闻文章作为Etag，该文章最后修改时间作为资源的最后修改时间，这样就OK了。如果浏览器发送过来的标识和服务器标识一致，说明内容没有更新，直接发送304 Not Modified；如果不一致，说明内容更新，浏览器本地的缓存太古老了，那么就需要服务器真正生成页面了。

以上只是一个最简单的例子，如果我们需要根据状态做一些更多的工作也是很容易的。比方说JavaEye博客的RSS订阅地址： http://robbin.javaeye.com/rss

@blogs = @blog_owner.last_blogs
@hash = @blogs.collect{|b| {b.id => b.post.modified_at.to_i + b.posts_count}}.hash
if stale?(:last_modified => (@blog_owner.last_blog.post.modified_at || @blog_owner.last_blog.post.created_at), :etag => @hash)
render :template => “rss/blog”
end

@blogs = @blog_owner.last_blogs
@hash = @blogs.collect{|b| {b.id => b.post.modified_at.to_i + b.posts_count}}.hash
if stale?(:last_modified => (@blog_owner.last_blog.post.modified_at || @blog_owner.last_blog.post.created_at), :etag => @hash)
render :template => “rss/blog”
end

这个实现稍微复杂一些。我们需要判断博客订阅所有的输出文章是否有更新，所以我们用博客文章内容最后修改时间和博客的评论数量做一个hash，然后用这个hash值作为资源的Etag，那么只要这些博客文章当中任何文章内容被修改，或者有新评论，都会改变Etag值，从而通知浏览器内容有更新了。

除了RSS订阅之外，JavaEye网站还有很多地方适合使用HTTP Cache，比方说JavaEye论坛的版面列表页面，一些经常喜欢泡论坛的用户，可能时不时会上来刷新一下版面， 看看有没有新的帖子，那么我们就不必每次用户请求的时候都去执行程序，生成页面给他。我们判断一下如果没有新帖子的话，直接告诉他304 Not Modified就可以了，在没有使用HTTP Cache之前的版面Action代码：

def board
@topics = @forum.topics.paginate…
@announcements = (params[:page] || 1).to_i == 1 ? Topic.find :all, :conditions => …
render :action => ‘show’
end

def board
@topics = @forum.topics.paginate…
@announcements = (params[:page] || 1).to_i == 1 ? Topic.find :all, :conditions => …
render :action => ‘show’
end

添加HTTP Cache以后，代码如下：

def board
@topics = @forum.topics.paginate…
if logged_in? || stale?(:last_modified => @topics[0].last_post.created_at, :etag => @topics.collect{|t| {t.id => t.posts_count}}.hash)
@announcements = (params[:page] || 1).to_i == 1 ? Topic.find :all, :conditions…
render :action => ‘show’
end
end

def board
@topics = @forum.topics.paginate…
if logged_in? || stale?(:last_modified => @topics[0].last_post.created_at, :etag => @topics.collect{|t| {t.id => t.posts_count}}.hash)
@announcements = (params[:page] || 1).to_i == 1 ? Topic.find :all, :conditions…
render :action => ‘show’
end
end

对于登录用户，不使用HTTP Cache，这是因为登录用户需要实时接收站内短信通知和订阅通知，因此我们只能对匿名用户使用HTTP Cache，然后我们使用当前所有帖子id和回帖数构造hash作Etag，这样只要当前分页列表页面有任何帖子发生改变或者有了新回帖，就更新页面，否则就不必重新生成页面。

Rails的Controller提供了fresh_when和stale?方法帮助我们实现HTTP Cahe功能，代码写起来已经非常简单了。但是直接在action里面添加Cache代码还是有点难看，所以我们可以用一个第三方插件：easy http cache来进一步简化工作，这样我们仅仅需要添加一个声明就可以了，如下例：

class ListsController < ApplicationController
http_cache :show, :last_modified => :list, :etag => :current_user
enddef show
# expensive stuff
endprotected
def list
@list ||= List.find(params[:id])
enddef current_user
@current_user ||= User.find(params[:user_id])
end

class ListsController < ApplicationController
http_cache :show, :last_modified => :list, :etag => :current_user
enddef show
# expensive stuff
endprotected
def list
@list ||= List.find(params[:id])
enddef current_user
@current_user ||= User.find(params[:user_id])
end

Easy Http Cache插件更多用法可以参考：http://github.com/josevalim/easy_http_cache/tree/master

在给JavaEye网站所有的RSS订阅输出添加了HTTP Cache以后，通过一天的观察发现，超过一半的RSS订阅请求已经被缓存了，直接返回304 Not Modified，所以效果非常明显，由于JavaEye网站每天RSS订阅的动态请求就超过了10万次，因此添加HTTP Cache可以减轻不少服务器的负担和带宽消耗。

相关文章

• 2009年08月12号 -- Etag和Expires
• 2009年02月25号 -- Apache缓存系统
• 2009年02月25号 -- Apache 设置web 缓存

$_SERVER['PHP_SELF']在开发的时候常会用到，一般用来引用当前网页地址，并且它是系统自动生成的全局变量，也会有什么问题么？让我们先看看下面的代码吧：

<form action=”<?php echo $_SERVER['PHP_SELF']; ?>”>
 <input type=”submit” name=”submit” value=”submit” />
</form>

这段代码非常简单，我们想用$_SERVER['PHP_SELF']来让网页提交时提交到它自己，假设代码文件名为test.php，在执行的时候就一定会得到我们期望的地址么？首先试试地址http://…/test.php，结果当然是没有问题的啦，别着急，你再访问一下http://…/test.php/a=1，将会得到如下客户端代码：

<form action=”/fwolf/temp/test.php/a=1″>
 <input type=”submit” name=”submit” value=”submit” />
</form>

显然，这已经超出了我们的期望，web服务器居然没有产生诸如404之类的错误，页面正常执行了，并且在生成的html代码中居然有用户可以输入的部分，恐怖的地方就在这里。别小看那个“a=1”，如果把它换成一段js代码，就显得更危险了，比如这么调用：

http://…/test.php/%22%3E%3Cscript%3Ealert(‘xss’)%3C/script%3E%3Cfoo

是不是看到了js的alert函数执行的效果？检查一下生成的html源代码找找原因吧。

通过这种嵌入js代码的方式，攻击者能夠获得512～4k的代码空间，甚至还可以连接外部网站的js代码或者通过image调用来伪装js代码的方式，那样js代码的长度就不受限制了，然后通过js，他们可以轻松的获取用户的cookie，或者更改当前页面的任何内容，比如更改表单提交的目的地，更改显示的内容（比如给一个<a>链接地址增加一个onclick=…的属性，这样用户点击的时候就会执行攻击者指定的代码，甚至连接到并非此链接地址本身的网站），甚至作出一个ajax效果来也不一定，总之，不要忽视js的威力。

那么，再来看看这个漏洞产生的原理，首先test.php/….这种调用是web服务器允许的，很多cms系统，比如我以前用过的plog，好像也是采用这种方式，在服务器不支持rewrite的情况下实现诸如http://…/index.php/archive/999这样的固定网址的（我以前还以为是对404错误页下的手），所以带“/”的地址无法从web服务器上禁止。然后再看看php中对$_SERVER['PHP_SELF']的识别，他就是一个包含当前网址值的全局变量，天知道用户会输入什么样的网站，在上面的例子中是恶意的，可是在wikipedia这样的网站上，却又是可以正常使用这种方式的地址的。所以，最终的结论要落在开发人员身上了，没有很好的处理与用户交互的数据。

从安全角度来讲，在开发应用尤其是web应用的时候，所有用户提交的数据都是不安全的，这是基本原则，所以我们才不厌其烦的又是客户端验证又是服务端验证。从上面说的这个安全漏洞来讲，不安全的内容中又要增加“网址”一条了。要解决$_SERVER['PHP_SELF']的安全隐患，主要有以下2种方式：

1、htmlentities 用htmlentities($_SERVER['PHP_SELF'])来替代简单的$_SERVER['PHP_SELF']，这样即使网址中包含恶意代码，也会被“转换”为用于显示的html代码，而不是被直接嵌入html代码中执行，简单一点说，就是“<”会变成“&lt;”，变成无害的了。

2、REQUEST_URI 用$_SERVER['REQUEST_URI']来替代$_SERVER['PHP_SELF']，在phpinfo()中可以看到这两个变量的区别：

_SERVER["REQUEST_URI"] /fwolf/temp/test.php/%22%3E%3Cscript%3Ealert(‘xss’)%3C/script%3E%3Cfoo
_SERVER["PHP_SELF"] /fwolf/temp/test.php/”&gt;&lt;script&gt;alert(‘xss’)&lt;/script&gt;&lt;foo

$_SERVER['REQUEST_URI']会原封不动的反映网址本身，网址中如果有%3C，那么你得到的也将会是%3C，而$_SERVER['PHP_SELF']会对网址进行一次urldecode操作，网址中的%3C将会变成字符“<”，所以就产生了漏洞。需要注意的是，在很多情况下，浏览器会对用户输入要提交给web服务器的内容进行encode，然后服务器端程序会自动进行decode，得到相应的原指，在我们进行post或者get操作的时候都是这样。

另外还有两点需要指出，第一是<form action=”">这种写法虽然没有直接用到$_SERVER['PHP_SELF']，但实际效果却是一样的，只是发生的时间错后到了用户提交之后的下一个页面，所以，form的action还是不要留空的好。第二点，除了PHP_SELF之外，其他的$_SERVER变量也许也会有类似的漏洞，比如SCRIPT_URI, SCRIPT_URL, QUERY_STRING, PATH_INFO, PATH_TRANSLATED等等，在使用他们之前一定要先作htmlentities之类的转换。

最后，提供一个地址，里面有很多XSS的例子，可以作为反面教材或者测试工具： XSS (Cross Site Scripting) Cheat Sheet

Update @ 2007-07-31

SCRIPT_URI在cgi方式下或者在某些虚拟主机上无法使用：

Notice: Undefined index: SCRIPT_URI in ……

所以就只能用REQUEST_URI了：

((isset($_SERVER["HTTPS"]) && ‘on’ == $_SERVER["HTTPS"]) ? ‘https://’ : ‘http://’) . $_SERVER["HTTP_HOST"] . $_SERVER['REQUEST_URI'];

无相关文章，以下随机显示

• 2009年09月6号 -- 网络流量尽在掌控
• 2009年01月22号 -- Apache配置文件(httpd.conf)中文说明
• 2009年08月12号 -- Etag和Expires
• 2009年08月13号 -- Apache配置之URL重写
• 2009年01月6号 -- Apache服务器使用.htaccess实现图片防盗链方法教程
• 2009年08月12号 -- 关于apache的restart和stop, start的问题
• 2009年07月14号 -- 初识HTTP中的Referer
• 2008年12月27号 -- apxs – Apache 扩展工具
• 2009年02月19号 -- IE环境下的安全警告汇总收藏
• 2009年02月7号 -- apache之404错误页面

简言之，HTTP Referer是header的一部分，当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。比如从我主页上链接到一个朋友那里，他的服务器就能够从HTTP Referer中统计出每天有多少用户点击我主页上的链接访问他的网站。

Referer其实应该是英文单词Referrer，不过拼错的人太多了，所以编写标准的人也就将错就错了。

我的问题

我刚刚把feed阅读器改变为Gregarius，但他不像我以前用的liferea，访问新浪博客的时候，无法显示其中的图片，提示“此图片仅限于新浪博客用户交流与沟通”，我知道，这就是HTTP Referer导致的。

由于我上网客户端配置的特殊性，首先怀疑是squid的问题，但通过实验排除了，不过同时发现了一个Squid和Tor、Privoxy协同使用的隐私泄露问题，留待以后研究。

Gregarius能处理这个问题么？

答案是否定的，因为Gregarius只是负责输出html代码，而对图像的访问是有客户端浏览器向服务器请求的。

不过，安装个firefox扩展也许能解决问题，文中推荐的”Send Referrer”我没有找到，但发现另外一个可用的：”RefControl“，可以根据访问网站的不同，控制使用不同的Referer。

但是我不喜欢用Firefox扩展来解决问题，因为我觉得他效率太低，所以我用更好的方式——Privoxy。

Privoxy真棒

在Privoxy的default.action中添加两行：

{+hide-referrer{forge}}
.album.sina.com.cn

这样Gregarius中新浪博客的图片就出来了吧？+hide-referrer是Privoxy的一个过滤器，设置访问时对HTTP Referer的处理方式，后面的forge代表用访问地址当作Refere的，还可以换成block，代表取消Referer，或者直接把需要用的Referer网址写在这里。

用Privoxy比用Firefox简单的多，赶紧换吧。

From https to http

我还发现，从一个https页面上的链接访问到一个非加密的http页面的时候，在http页面上是检查不到HTTP Referer的，比如当我点击自己的https页面下面的w3c xhtml验证图标（网址为http://validator.w3.org/check?uri=referer），从来都无法完成校验，提示：

No Referer header found!

原来，在http协议的rfc文档中有定义：

15.1.3 Encoding Sensitive Information in URI’s

…

Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure
protocol.

这样是出于安全的考虑，访问非加密页时，如果来源是加密页，客户端不发送Referer，IE一直都是这样实现的，Firefox浏览器也不例外。但这并不影响从加密页到加密页的访问。

Firefox中关于Referer的设置

都在里，有两个键值：

• network.http.sendRefererHeader (default=2) 设置Referer的发送方式，0为完全不发送，1为只在点击链接时发送，在访问页面中的图像什么的时候不发送，2为始终发送。参见Privacy Tip #3: Block Referer Headers in Firefox
• network.http.sendSecureXSiteReferrer (default=true) 设置从一个加密页访问到另外一个加密页的时候是否发送Referer，true为发送，false为不发送。

利用Referer防止图片盗链

虽然Referer并不可靠，但用来防止图片盗链还是足够的，毕竟不是每个人都会修改客户端的配置。实现一般都是通过apache的配置文件，首先设置允许访问的地址，标记下来：

# 只允许来自domain.com的访问，图片可能就放置在domain.com网站的页面上
SetEnvIfNoCase Referer “^http://www.domain.com/” local_ref
# 直接通过地址访问
SetEnvIf Referer “^$” local_ref

然后再规定被标记了的访问才被允许：

<FilesMatch “.(gif|jpg)”>
Order Allow,Deny
Allow from env=local_ref
</FilesMatch>

或者

<Directory /web/images>
Order Deny,Allow
Deny from all
Allow from env=local_ref
</Directory>

这方面的文章网上很多，参考：

• Apache 下防止盗链的解决办法
• Apache的环境变量设置
• 配置 Apache 实现禁止图片盗链

不要使用Rerferer的地方

不要把Rerferer用在身份验证或者其他非常重要的检查上，因为Rerferer非常容易在客户端被改变，不管是通过上面介绍的Firefox扩展，或者是Privoxy，甚至是libcurl的调用，所以Rerferer数据非常之不可信。

如果你想限制用户必须从某个入口页面访问的话，与其使用Referer，不如使用session，在入口页面写入session，然后在其他页面检查，如果用户没有访问过入口页面，那么对应的session就不存在，参见这里的讨论。不过和上面说的一样，也不要过于相信这种方式的“验证”结果。

个人感觉现在Rerferer除了用在防盗链，其他用途最多的就是访问统计，比如统计用户都是从哪里的链接访问过来的等等。

相关文章

• 2009年07月14号 -- 初识HTTP中的Referer

standalone模式表示Apache进程以一个单独的守护进程方式在后台监听是否有客户端的请求，如果有则生成一个子进程来为其服务。在 standalone模式下，apache进程一次性启动，运行期间一直驻留在内存中，尽管损耗了一定的系统资源，但接入信号反应快；而且子httpd进 程在http请求完毕后并没有直接断掉，这样就可以重新用来接受新的http请求，请参考apache的keepalive指令（请看这里）。由于不存在对每个请求都启动新的apache根进程，所以它的效率更高。

inetd模式表示Apache服务不是以一个单独的守候进程的形式支持。而是由Inetd这个超级守候进程进行代劳，当它监听一个客户端的http请求 的时候，再启动一个httpd进程为其服务。一个由inted运行的服务器进程在它结束对请求服务的同时立刻退出，虽然不占用了系统资源，但是也由此不适 合应用在同时连接数量较多的系统。因为如果请求完毕后就结束httpd进程，会使服务器负担加重。

具体使用如下：

standalone模式

此种模式下，Apache服务器监听特定端口的连接请求。当用户发起特定端口地址的连接请求时，主服务器进程启动子httpd进程来响应该请求。

这样还需要告诉主服务器进程侦听的特定端口地址，使用命令：

Port [number] （缺省值为80）

inetd模式

inetd是监听所有小于1024的端口连接请求的Internet守护进程(一个服务器进程)。与standalone模式不同，当客户系统发出到Apache服务器的连接请求时，inetd启动一个httpd进程，由此进程服务此请求，完成服务后即退出。

如果选择通过inetd服务器来运行Apache，需要编辑/etc/inetd.conf文件为Apache添加一条新的记录：

httpd stream tcp nowait httpd /etc/httpd/bin/httpd –f /etc/httpd/conf/httpd.conf

修改了/etc/inetd.conf文件后，就需要修改/etc/services中添加一行

httpd 80/tcp httpd

做完以上修改后，需要重新启动inetd进程。首先，使用以下命令取得inetd的进程ID：

ps auxw | grep inetd

然后执行命令：kill -HUP pid

无相关文章，以下随机显示

• 2009年02月27号 -- header中的Cache-control参数说明
• 2009年02月10号 -- Apache高级配置中文详解
• 2009年01月22号 -- Apache连接数设置prefork
• 2009年06月15号 -- 16个简单实用的.htaccess小贴示
• 2009年02月12号 -- 泛域名与mod_rewrite
• 2009年03月30号 -- Apache Prefork和Worker模式的性能比较测试
• 2009年03月9号 -- Apache 2.0中prefork.c模块和worker.c模块的比较
• 2009年05月8号 -- 用apache实现禁止IP段或者主机对某个目录的访问
• 2009年02月6号 -- YouTube 架构学习
• 2009年01月6号 -- Apache服务器使用.htaccess实现图片防盗链方法教程

在这里我就prefork和worker两种最为常用的工作模式进行比较：

prefork–Unix平台上的默认（缺省）MPM，使用多个子进程，每个子进程只有一个线程。每个进程在某个确定的时间只能维持一个连接，效率高，但内存占用量比较大。

worker–使用多个子进程，每个子进程有多个线程，每个线程在某个确定的时间只能维持一个连接，内存占用量比较小，适合高流量的http服务器。缺点是假如一个线程崩溃，整个进程就会连同其任何线程一起”死掉”，所以要保证一个程式在运行时必须被系统识别为”每 个线程都是安全的”。

了解了这些个之后，怎么才能知道你的Apache服务器工作在什么状态呢？使用“apachectl -l”命令就可以显示出来。

Apache的默认的工作模式为prefork，如何把它改成worker模式呢？

如果你还未编译安装，那就简单了，在编译的时候加个参数 “–with-mpm=worker”，就好了；

如果你想更改正在运行的Apache的工作模式：

1.将当前的prefork模式启动文件改名

mv httpd httpd.prefork

2.将worker模式的启动文件改名

mv httpd.worker httpd

3.修改Apache配置文件

vi /usr/local/apache2/conf/extra/httpd-mpm.conf

找到里边的如下一段，可适当修改负载等参数：

StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0

4.重新启动服务

/usr/local/apache2/bin/apachectl restart

PS：处于稳定性和安全性考虑，在真正的生产环境，请勿轻易改变其工作模式。

相关文章

• 2009年03月30号 -- Apache的prefork模式和worker模式
• 2009年03月30号 -- Apache Prefork和Worker模式的性能比较测试
• 2009年03月9号 -- Apache 2.0中prefork.c模块和worker.c模块的比较
• 2009年03月30号 -- 对Apache中并发控制参数prefork理解和调优
• 2009年01月22号 -- Apache连接数设置prefork
• 2009年01月22号 -- 对apache中并发控制参数prefork理解和调优

nginx编译参数：

#/usr/local/nginx/sbin/nginx -V
nginx version: nginx/0.6.32

built by gcc 4.1.2 20071124 (Red Hat 4.1.2-42)

configure arguments: –user=www –group=www –prefix=/usr/local/nginx/ –with-http_stub_status_module –with-openssl=/usr/local/openssl

apache编译参数：

# cat /usr/local/apache2/build/config.nice
#! /bin/sh

#

# Created by configure

“./configure” \

“–prefix=/usr/local/apache2″ \

“–with-included-apr” \

“–enable-so” \

“–enable-deflate=shared” \

“–enable-expires=shared” \

“–enable-rewrite=shared” \

“–enable-static-support” \

“–disable-userdir” \

“$@”

php编译参数：

# /usr/local/php/bin/php -i |grep configure

Configure Command => ‘./configure’ ‘–prefix=/usr/local/php’ ‘–with-apxs2=/usr/local/apache2/bin/apxs’ ‘–with-config-file-path=/usr/local/php/etc’ ‘–with-mysql=/usr/local/mysql’ ‘–with-libxml-dir=/usr/local/libxml2/bin’ ‘–with-gd=/usr/local/gd2′ ‘–with-jpeg-dir’ ‘–with-png-dir’ ‘–with-bz2′ ‘–with-xmlrpc’ ‘–with-freetype-dir’ ‘–with-zlib-dir’

mysql编译参数：

# cat “/usr/local/mysql/bin/mysqlbug”|grep configure

# This is set by configure

CONFIGURE_LINE=”./configure ‘–prefix=/usr/local/mysql’ ‘–localstatedir=/var/lib/mysql’ ‘–with-comment=Source’ ‘–with-server-suffix=-H863′ ‘–with-mysqld-user=mysql’ ‘–without-debug’ ‘–with-big-tables’ ‘–with-charset=gbk’ ‘–with-collation=gbk_chinese_ci’ ‘–with-extra-charsets=all’ ‘–with-pthread’ ‘–enable-static’ ‘–enable-thread-safe-client’ ‘–with-client-ldflags=-all-static’ ‘–with-mysqld-ldflags=-all-static’ ‘–enable-assembler’ ‘–without-isam’ ‘–without-innodb’ ‘–without-ndb-debug’”

相关文章

• 2009年01月6号 -- php+mysql+apache编码深度解析
• 2009年06月7号 -- apxs是Apache编译和安装扩展模块的工具
• 2009年02月17号 -- 在64位机器上关于Apache 2.2.3版的编译问题
• 2009年01月5号 -- 重大漏洞, 让Apache上传不安全-php.rar
• 2008年12月27号 -- 单独编译apache的rewrite模块

　　废话少说，下面就来解释一下负载均衡的设置方法。

　　一般来说，负载均衡就是将客户端的请求分流给后端的各个真实服务器，达到负载均衡的目的。还有一种方式是用两台服务器，一台作为主服务器(Master)，另一台作为热备份(Hot Standby)，请求全部分给主服务器，在主服务器当机时，立即切换到备份服务器，以提高系统的整体可靠性。

　　负载均衡的设置

　　Apache可以应对上面这两种需求。先来讨论一下如何做负载均衡。首先需要启用Apache的几个模块：

　　程序代码

　 LoadModule proxy_module modules/mod_proxy.so
　　LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
　　LoadModule proxy_http_module modules/mod_proxy_http.so

　　mod_proxy提供代理服务器功能，mod_proxy_balancer提供负载均衡功能， mod_proxy_http让代理服务器能支持HTTP协议。如果把mod_proxy_http换成其他协议模块(如mod_proxy_ftp)，或许能支持其他协议的负载均衡，有兴趣的朋友可以自己尝试一下。

　　然后要添加以下配置：

　　程序代码

ProxyRequests Off
　　
　　BalancerMember http://node-a.myserver.com:8080
　　BalancerMember http://node-b.myserver.com:8080
　　 　　ProxyPass / balancer://mycluster
　　# 警告：以下这段配置仅用于调试，绝不要添加到生产环境中!!!
　　
　　SetHandler balancer-manager
　　order Deny,Allow
　　Deny from all
　　Allow from localhost
　　

　　从上面的 ProxyRequests Off 这条可以看出，实际上负载均衡器就是一个反向代理，只不过它的代理转发地址不是某台具体的服务器，而是一个 balancer:// 协议：

　　ProxyPass / balancer://mycluster协议地址可以随便定义。然后，在段中设置该balancer协议的内容即可。 BalancerMember指令可以添加负载均衡组中的真实服务器地址。

　　下面那段是用来监视负载均衡的工作情况的，调试时可以加上(生产环境中禁止使用!)，然后访问 http://localhost/balancer-manager/ 即可看到负载均衡的工作状况。

　　OK，改完之后重启服务器，访问你的Apache所在服务器的地址，即可看到负载均衡的效果了。打开 balancer-manager 的界面，可以看到请求是平均分配的。

　　如果不想平均分配怎么办?给 BalancerMember 加上 loadfactor 参数即可，取值范围为1-100。比如你有三台服务器，负载分配比例为 7:2:1，只需这样设置：

　　程序代码

　 ProxyRequests Off
　　
　　BalancerMember http://node-a.myserver.com:8080 loadfactor=7
　　BalancerMember http://node-b.myserver.com:8080 loadfactor=2
　　BalancerMember http://node-c.myserver.com:8080 loadfactor=1
　　 　　ProxyPass / balancer://mycluster

　　默认情况下，负载均衡会尽量让各个服务器接受的请求次数满足预设的比例。如果要改变算法，可以使用 lbmethod 属性。如：

　　程序代码

　ProxyRequests Off
　　
　　BalancerMember http://node-a.myserver.com:8080 loadfactor=7
　　BalancerMember http://node-b.myserver.com:8080 loadfactor=2
　　BalancerMember http://node-c.myserver.com:8080 loadfactor=1
　　 　　ProxyPass / balancer://mycluster
　　ProxySet lbmethod=bytraffic

　　lbmethod可能的取值有：

　　lbmethod=byrequests 按照请求次数均衡(默认)

　　lbmethod=bytraffic 按照流量均衡

　　lbmethod=bybusyness 按照繁忙程度均衡(总是分配给活跃请求数最少的服务器)

　　各种算法的原理请参见[url=http://httpd.apache.org/docs/2.2/en/mod/mod_proxy_balancer.html]Apache的文档[/url]。

　　热备份(Hot Standby)

　　热备份的实现很简单，只需添加 status=+H 属性，就可以把某台服务器指定为备份服务器：

　　程序代码

　ProxyRequests Off
　　
　　BalancerMember http://node-a.myserver.com:8080
　　BalancerMember http://node-b.myserver.com:8080 status=+H
　　 　　ProxyPass / balancer://mycluster

　　从 balancer-manager 界面中可以看到，请求总是流向 node-a ，一旦node-a挂掉， Apache会检测到错误并把请求分流给 node-b。Apache会每隔几分钟检测一下 node-a 的状况，如果node-a恢复，就继续使用node-a。

无相关文章，以下随机显示

• 2009年08月13号 -- Apache+Django性能优化之mod_wsgi篇
• 2009年07月14号 -- 初识HTTP中的Referer
• 2009年12月12号 -- 使用Apache做负载均衡
• 2009年02月7号 -- 使用gzip压缩来压缩网页之apache的相关配置
• 2008年12月27号 -- 单独编译apache的rewrite模块
• 2009年06月1号 -- 玩转apache之日志
• 2009年02月27号 -- header常用指令
• 2009年02月25号 -- Apache 两种虚拟主机方式的区别
• 2010年03月9号 -- Apache2中俩种设置PHP的异同
• 2009年09月2号 -- HTTP Referer二三事

 一、使用mod_limitipconn限制Apache的并发连接数

　　mod_limitipconn可以控制每个IP地址同时连接服务器某一个目录的并发连接数，是一个非常有用的模块，其官方网页是 http://dominia.org/djao/limitipconn.html，最新版本为for Apache 1.3.7的0.04，并且还有支持Apache 2.x的模块下载，由于本人使用Apache 1.3.7版本，所以请使用2.x版本Apache的朋友到其官方网站察看具体的使用方法。

　　mod_limitipconn for Apache 1.3x提供三种安装方式，分别是tar包、rpm安装文件和rpm源文件，由于rpm包只能用在 RedHat 7.x 版本，并且不支持检测代理服务器，所以我们一般都使用tar包的安装方式。

　　以管理员方式登陆服务器，然后在服务器上运行 wget http://dominia.org/djao/limit/mod_limitipconn-0.04.tar.gz 将mod_limitipconn的tar包下载到服务器，然后按照再运行tar zxvf mod_limitipconn-0.04.tar.gz将tar包解压缩，会在当前目录下生成mod_limitipconn-0.04目录，然后cd mod_limitipconn-0.04进入此目录，下一步就是使用apxs将目录中的mod_limitipconn.c编译。这时，我们需要确定自 己的Apache安装在那个目录，并且找到apxs命令放在哪里。

　　通过命令whereis apxs，我们可以确定apxs命令的路径，如我的apxs命令所在为/usr/sbin/apxs，则输入/usr/sbin/apxs -c -i -a mod_limitipconn.c对mod_limitipconn.c进行编译，此命令会自动在你Apache的配置文件httpd.conf中加入 需要的信息，并且将生成的mod_limitipconn.so模块拷贝到Apache的模块目录。不过为了确认此命令是否正常运作，请首先检查自己的 Apache模块目录（我的是/usr/lib/apache），看内部是否含有mod_limitipconn.so文件，没有的话请将 mod_limitipconn-0.04目录中生成的文件拷贝到此处。

　　刚才命令自动生成的httpd.conf可能有些错误，在我的系统中，它将LoadModule limitipconn_module modules/mod_limitipconn.so放在了

LoadModule python_module modules/mod_python.so

之间，而将AddModule mod_limitipconn.c放在了

AddModule mod_python.c

之间，直接造成了mod_limitipconn模块不能正常运行，所以请将这两行分别移动到没 有的相应行中，然后请确认mod_status模块已经加载，并且在 mod_status下添加了ExtendedStatus On这一行。这时我们的mod_limitipconn模块就安装完毕，下一步就是对某个目录进行并发连接数的设置了。

　　mod_limitipconn可以对全局和虚拟主机进行不同的限制，其语法结构都是

#所限制的目录所在，此处表示主机的根目录
MaxConnPerIP 3 #所限制的每个IP并发连接数为3个
NoIPLimit image/* #对图片不做IP限制

#所限制的目录所在，此处表示主机的/mp3目录
MaxConnPerIP 1 #所限制的每个IP并发连接数为1个
OnlyIPLimit audio/mpeg video #该限制只对视频和音频格式的文件

　　当对全局进行限制时，将这段代码放在httpd.conf文件没有VirtualHost的地方，若是对某个虚拟主机进行限制，请将其放 在和之间，我们可以通过更改Location以及 MaxConnPerIP方便的控制所限制的目录和并发连接数。

　　最后，只要重新启动Apache服务，并发连接数的限制就可以生效。

二、使用mod_bandwidth控制Apache的带宽

　　Apache 1.3.7实际上带有mod_bandwidth支持，只是没有此模块的so文件，我们所做的就是下载mod_bandwidth的源文件进行编译，并对mod_bandwidth进行相应的设置。

　　在下载之前，请先确认自己的Apache配置文件httpd.conf中是否含有

LoadModule bandwidth_module modules/mod_bandwidth.so

以及

AddModule mod_bandwidth.c

若是没有，请加上

LoadModule bandwidth_module
libexec/apache/mod_bandwidth.so
AddModule mod_bandwidth.c

　　并且这两行必须分别加在相应区域的最前面，使得这个模块以最低的优先级运行。（不过1.3.7的Apache应该有，呵呵）。

　　确认后，请输入 wget ftp://ftp.cohprog.com/pub/apache/module/1.3.0/mod_bandwidth.c 将源文件下载到服务器，然后请使用apxs对其进行编译，编译方法和mod_limitipconn的基本相同，如我输入/usr/sbin/apxs -c mod_bandwidth.c -o /usr/lib/apache(Apache的模块目录），编译程序会自动将编译成功的mod_bandwidth.so文件放到Apache的模块目 录，您也可以自己确认一下，若是不正常，拷贝过去即可。

　　mod_bandwidth运行时需要一些特定的目录，按照默认情况，请运行以下命令创建并更改目录的权限：

mkdir /tmp/apachebw
mkdir /tmp/apachebw/link
mkdir /tmp/apachebw/master
chmod -R 777 /tmp/apachebw

　　然后再打开httpd.conf文件，加上以下内容

BandWidthDataDir “/tmp/apachebw/”
BandWidthModule on

　　这时，我们就能够对所需要限制带宽的目录进行相应的设置，此处的目录请使用服务器的绝对路径。如我们想限制服务器/home/www /thinkjam/download/soft目录的下载速度，也就是限制网址http://download.thinkjam.org/soft目 录下软件的下载速度，则为httpd.conf文件增加以下内容

BandWidth thinkjam.org 0 #来自thinkjam.org的下载不受速度限制
BandWidth 210.51.21 0 #来自210.51.21网段的下载不受速度限制
BandWidth all 327680 #来自其它网段的速度都限制为327680Byte，即30KB/s

　　设置完毕后，重新启动Apache服务，即可生效。

　　mod_bandwidth还有许多其它有用的参数，如在中间加上MaxConnection 120则可以限制某个目录的最多连接数，当超过指定连接数时，拒绝新的连接，此参数与mod_limitipconn模块结合可以控制某个目录的最多连接人数。

　　其它的参数请朋友们到其官方网站 http://www.cohprog.com/v3/bandwidth/doc-en.html 察看相关的文档。

　　Apache的功能确实强大，很多功能都可以通过添加模块来实现，在 http://modules.apache.org/ 可以找到更多的模块，我们也可以编写自己的模块来实现相应的功能。

无相关文章，以下随机显示

• 2009年04月8号 -- apache软件体系结构
• 2009年08月13号 -- Apache和IIS共享80端口的四个方法
• 2008年12月27号 -- apache中.htaccess的功能及写法
• 2009年01月6号 -- Apache服务器使用.htaccess实现图片防盗链方法教程
• 2009年02月6号 -- YouTube 架构学习
• 2009年02月25号 -- apache ab压力测试收藏
• 2009年02月12号 -- 让apache支持自定义404页面错误
• 2009年02月27号 -- 使用mod_headers或mod_expires落实缓存
• 2009年02月10号 -- 让Apache按日期保存日志数据
• 2010年04月13号 -- HTTP 状态代码解释

什么是Django

Django 是一个开放源代码的Web应用框架，由Python写成，主力开发者是Adrian Holovaty。它采用了MVC的设计模式。

Django 的名字来自于比利时的爵士吉他手Django Reinhardt，他是欧陆爵士乐发展的奠基人，也是爵士史上最伟大的吉他巨匠，中国乐迷称之为“三指琴魔”。

Django 源自一个在线新闻 Web 站点，于 2005 年7月在BSD许可证下发布。Django 框架的核心组件有：

• 用于创建模型的对象关系映射
• 为最终用户设计的管理界面
• 一流的 URL 设计
• 设计者友好的模板语言
• 缓存系统

如何上手Django

新手入门参考Django Step by Step之limodou版。

DjangoProject.com 是 Django 框架的主页。其中的文档包括：

• How to install Django，展示了如何在一台开发机器上设置 Django
• Database API reference，使用 Django ORM 库的指南
• Django template language，为模板作者准备的一份简单指南
• How to serve static files，如何在开发过程中通过设置 Django 来提供静态文件服务的介绍（不要在产品环境中这样做）
• How to use Django with mod_python，这是一份有关利用 mod_python 组合使用 Django 和 Apache 的指南
• Generic views，展示了如何使用 Django 的通用视图更快地实现通用的 Web 应用程序模式

Django+Apache+mod_python 的用法

一般上手搭配 Django 的是 Apache+mod_python ，从这个早年间的翻译文档可以了解 Apache怎样处理请求以及mod_python到底做了什么。

不过，既然 Django 都已经在文档中说“it has been mostly superseded by the simpler mod_wsgi deployment option./mod_python 多半已被更简单的 mod_wsgi 替代了。”那么我们就应该一上手就用 mod_wsgi 。

为何要切换到 mod_wsgi ？

mod_python 其实也不差。

但我一直困惑于 Apache+mod_python 的莫名频繁崩溃，错误日志中会出现大量的如下错误：

[error] [client X.X.X.X] OSError: [Errno 0] Error
[notice] Parent: child process exited with status 3221225477 — Restarting.

这个状态号 3221225477 基本没什么意义，再加上 OSError 0 ，这个异常日志让人很无奈。甚至在 Windows 平台下，Apache 最恶劣情况下竟然会弹出一个崩溃错误框，此时事件日志会报告：

cation Popup:0:29722:26:EVENTLOG_INFORMATION_TYPE:弹出应用程序: Microsoft Visual C++ Runtime Library: Runtime Error!
Program: C:\Apache2.2\bin\httpd.exe
This application has requested the Runtime to terminate it in an unusual way.

一直无法对症下药。于是，期冀 mod_wsgi 能让我摆脱这两个问题。

另一个就是性能。

modwsgi 性能评估中列出这样的数字对比：

Mechanism Requests/sec

mod_cgi (ScriptAlias) 10

mod_python (PythonHandler) 400

mod_wsgi (WSGIDaemonProcess) 700

mod_wsgi (.htaccess/SetHandler) 850

mod_wsgi (WSGIScriptAlias) 900

从数字可以看出，WSGIScriptAlias 是最优选择。当然这个数字也没什么，后面人家说了“任何性能提高，都将被你使用的大型Web框架如Django或TurboGears吃掉，尤其是用了数据库后端，大多数的 overhead 源自Python Web Framework以及任何访问数据库时的瓶颈。mod_wsgi上的 overhead 只是很小的一块，这一小块上的任何性能提高都很难被注意到。”

切换到 mod_wsgi 很容易

郑昀@玩聚RT 20090810

1、下载

可以从 modwsgi 的下载目录 下载你所需要的版本。

对于 Windows 平台，可能需要阅读“Installation On Windows”，并从这个页面上提示的 mod_wsgi_py25_apache22 目录 下载 mod_wsgi.so (即我们的平台是Apache2.2+Python2.5+Django1.0.3)。

2、放置

把 mod_wsgi 放到你的Apache安装目录下的 modules 文件夹内。

3、配置Apache

在Apache配置文件httpd.conf中，增加一行：

LoadModule wsgi_module modules/mod_wsgi.so

4、修改Virtual Host配置

Apache 可以配置很多个 Named-based Virtual Hosts ，可以在一个服务器上部署多个Web Sites。

mod_python 下的 VirtualHost 配置主要复杂在 Python 配置这块，如下所示：

<VirtualHost *:80>
ServerName rt.ju690.com
ServerAlias rt.ju690.cn
DocumentRoot d:/SocialRecommend

<Location “/”>
SetHandler python-program
PythonPath “['d:/SocialRecommend']+sys.path”
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE settings_yourproject
PythonAutoReload Off
PythonDebug Off

</Location>

Alias /static d:/SocialRecommend/static
<Location “/static”>
SetHandler None
</Location>
<Directory “d:/SocialRecommend/static”>
Order Deny,Allow
Allow from all
</Directory>

</VirtualHost>

现在改为 mod_wsgi ，只需要稍加改变即可：

<VirtualHost *:80>
ServerName rt.ju690.com
ServerAlias rt.ju690.cn
DocumentRoot D:/SocialRecommend
WSGIScriptAlias / D:\SocialRecommend\wsgi\yourproject.wsgi
Alias /static d:/SocialRecommend/static
<Location “/static”>
SetHandler None
</Location>
<Directory “d:/SocialRecommend/static”>
Order Deny,Allow
Allow from all
</Directory>
<Directory “d:/SocialRecommend/wsgi”>
Order Deny,Allow
Allow from all
</Directory>
</VirtualHost>

WSGIScriptAlias 的定义参见 modwsgi wiki ，主要是映射一个URL到一个文件系统地址并委派目标文件为WSGI Script。

赋予本地wsgi文件夹Allow from all权限，是因为这样才能执行WSGI Script。

5、建立wsgi script

在你的web site django总目录下新建一个文件夹wsgi。

在 wsgi 文件夹下新建一个文件 yourproject.wsgi ，内容如下所示：

# complete_project.wsgi is configured to live in projects/complete_project/deploy.
# If you move this file you need to reconfigure the paths below.

import os
import sys

# redirect sys.stdout to sys.stderr for bad libraries like geopy that uses
# print statements for optional import exceptions.
sys.stdout = sys.stderr

from os.path import abspath, dirname, join
from site import addsitedir

from django.core.handlers.wsgi import WSGIHandler

sys.path.insert(0, abspath(join(dirname(__file__), “../”)))
sys.path.insert(0, abspath(join(dirname(__file__), “. . /. . /”)))

os.environ["DJANGO_SETTINGS_MODULE"] = “yourprojectname.settings_yourproject” #你的settings module名

application = WSGIHandler()

6、重启Aapche即可。

参考资源：

1、mod_wsgi / mod_python ；

2、Performance Estimates for mod_wsgi ；

3、How to use django with mod_wsgi 。

无相关文章，以下随机显示

• 2009年02月10号 -- Apache2运用mod_deflate提升网络页面浏览速度
• 2009年02月16号 -- Apache、resin、rewrite泛域名、多域名设置
• 2009年02月10号 -- apache 无法启动故障排查
• 2009年02月7号 -- Apache PHP利用HTTP缓存协议原理解析及应用
• 2010年04月13号 -- apache 的AcceptMutex 的理解
• 2009年01月6号 -- php+mysql+apache编码深度解析
• 2009年02月7号 -- 使用gzip压缩来压缩网页之apache的相关配置
• 2009年08月13号 -- Apache负载均衡设置方法: mod_proxy
• 2009年02月27号 -- 使用mod_headers或mod_expires落实缓存
• 2010年03月9号 -- Apache2中俩种设置PHP的异同

方法一：

IIS5，多IP下共存，IIS为192.168.0.1，apache为192.168.0.2

c:\Inetpub\Adminscripts
cscript adsutil.vbs set w3svc/disablesocketpooling true

该命令反馈如下disablesocketpooling : (BOOLEAN) True

重启IIS

Inetpub\AdminScripts>cscript adsutil.vbs set w3svc/disablesocketpooling true

由于 DisableSocketPooling 在 IIS 6.0 元数据库架构 (MBSchema.xml) 中被定义为有效属性，所以，您仍然可以使用 Adsutil.vbs 设置该属性，但这种设置不起作用。IIS 6.0 中的功能是新增的核心级别驱动程序 HTTP.sys 的一部分。要配置 HTTP.sys，您必须使用 Httpcfg.exe

方法二：

IIS6，多IP下共存，IIS为192.168.0.1，apache为192.168.0.2

到2003的CD下的 support/tools/Support.cab。解压出httpcfg.exe文件，COPY到windows/system32/目录下，用法自己看帮助

命令行绑定到某IP：

httpcfg set iplisten -i 192.168.0.1

即命令使用IIS的只监听指定的IP及端口

查看绑定： httpcfg query iplisten
删除绑定： httpcfg delete iplisten -i 192.168.0.1

命令行

net stop Apache2
net stop iisadmin /y
net START Apache2
net START w3svc

保证iis下的ip设置为全局默认，Apache中httpconf设置listen 192.168.0.2:80，就应该可以两个服务同时运行，相互不冲突了。

IIS的访问地址为http://192.168.0.1，Apache访问地址为http://192.168.0.2

提醒：IIS要指定为IP地址192.168.0.1 端口80；Apache 设置listen 192.168.0.2:80。关键是IIS用httpcfg命令绑定后，要重启系统，仅仅重启服务是不行的。

方法三：

将apache设为使用80端口，IIS使用其它端口，比如81，然后将apache作为IIS的代理。

在httpd.conf里面，取消下面四行的注释：

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so

然后建立一个虚拟主机，将该域名的所有访问转向81端口。

ServerName iloves.vicp.net
ProxyPass / http://localhost:81/
ProxyPassReverse / http://localhost:81/

这样，对外就可以只需要一个端口，即可同时使用apache和IIS的功能了

方法四：

网上常用的单IP共用80端口方法，不过不推荐，只是使用Apache的代理，速度有影响将apache设为使用80端口，IIS使用其它端口，比如81，然后将apache作为IIS的代理。

在httpd.conf里面，取消下面四行的注释：

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so

然后建立一个虚拟主机，将该域名的所有访问转向81端口。

ServerName iloves.vicp.net
ProxyPass / http://localhost:81/
ProxyPassReverse / http://localhost:81/

这样，对外就可以只需要一个端口，即可同时使用apache和IIS的功能了

类推，使用第二种方法，你可以在IIS上配置PHP4，Apache2中配置PHP5，只需要IIS中安装PHP4，把php.ini复制到\windows目录即可，这个就不用说了吧，Apache2中，只要把PHP5的php.ini放在PHP5安装目录里面就行了

配置Apache以支持PHP5：

LoadModule php5_module “D:/PHPServer/PHP5/php5apache2.dll”
AddType application/x-httpd-php .php
DirectoryIndex index.html index.php
PHPIniDir “D:/PHPServer/PHP5″

其中最重要的一条就是 PHPIniDir，用来指明php.ini文件所在位置，即PHP5的安装目录，注意所有目录的应该改为D:/PHPServer/PHP5这种格式， 而非D:\PHPServer\PHP5，IIS的访问地址为http://192.168.0.1，Apache访问地址为http: //192.168.0.2

相关文章

• 2009年02月10号 -- Apache和IIS共享80端口的四个方法

1、修改apache的httpd.conf文件，将下面语句前的#去掉

#LoadModule rewrite_module modules/mod_rewrite.so

2、修改apache的httpd.conf文件，将对应的节中的AllowOverride None 改为AllowOverride All，如

<Directory “D:/Local/Apache/htdocs/”>
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>

3、在需url重写的目录下建立.htaccess文件，wordpress在开启永久链接后会只能生成，内容如下：

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

效果就是如此链接http://witmax.cn/apache-url-rewrite.html，其实并不存在这个目录，而是通过url重写由index.php来解析支持。

相关文章

• 2009年06月14号 -- Apache自动添加地址末尾的斜线
• 2009年02月12号 -- 泛域名与mod_rewrite