OurApache

解决linux下安装ssl后，apache重启时需要密码

OurApache — Tue, 13 Apr 2010 13:18:24 +0800

解决linux下安装ssl后，apache重启时需要密码的问题。

在帮客户购买的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年09月2号 — HTTP Referer二三事
2009年12月12号 — apache配置（如何禁止列出目录内容）
2009年05月8号 — 用apache实现禁止IP段或者主机对某个目录的访问
2009年01月22号 — 对apache中并发控制参数prefork理解和调优
2009年02月25号 — Apache缓存系统
2009年01月22号 — apache最大连接数性能测试
2009年02月6号 — Apache 模块说明
2009年01月15号 — Apache服务器安全防范
2009年01月6号 — Apache 中KeepAlive 配置的合理使用(优化)
2010年03月9号 — htaccess二级目录重写找不到路径

标签：Apache解错方案, ssl, 密码

HTTP 状态代码解释

OurApache — Tue, 13 Apr 2010 13:17:23 +0800

HTTP 状态代码

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

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

一些常见的状态代码为：

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

1xx（临时响应）

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

代码	说明
100（继续）	请求者应当继续提出请求。服务器返回此代码则意味着，服务器已收到了请求的第一部分，现正在等待接收其余部分。
101（切换协议）	请求者已要求服务器切换协议，服务器已确认并准备进行切换。

2xx（成功）

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

代码	说明
200（成功）	服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。如果您的 robots.txt 文件显示为此状态，那么，这表示 Googlebot 已成功检索到该文件。
201（已创建）	请求成功且服务器已创建了新的资源。
202（已接受）	服务器已接受了请求，但尚未对其进行处理。
203（非授权信息）	服务器已成功处理了请求，但返回了可能来自另一来源的信息。
204（无内容）	服务器成功处理了请求，但未返回任何内容。
205（重置内容）	服务器成功处理了请求，但未返回任何内容。与 204 响应不同，此响应要求请求者重置文档视图（例如清除表单内容以输入新内容）。
206（部分内容）	服务器成功处理了部分 GET 请求。

3xx（已重定向）

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

代码	说明
300（多种选择）	服务器根据请求可执行多种操作。服务器可根据请求者 (User agent) 来选择一项操作，或提供操作列表供请求者选择。
301（永久移动）	请求的网页已被永久移动到新位置。服务器返回此响应（作为对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。您应使用此代码通知 Googlebot 某个网页或网站已被永久移动到新位置。
302（临时移动）	服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 Googlebot 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 Googlebot 某个页面或网站已被移动。
303（查看其他位置）	当请求者应对不同的位置进行单独的 GET 请求以检索响应时，服务器会返回此代码。对于除 HEAD 请求之外的所有请求，服务器会自动转到其他位置。
304（未修改）	自从上次请求后，请求的网页未被修改过。服务器返回此响应时，不会返回网页内容。如果网页自请求者上次请求后再也没有更改过，您应当将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。由于服务器可以告诉 Googlebot 自从上次抓取后网页没有更改过，因此可节省带宽和开销。
305（使用代理）	请求者只能使用代理访问请求的网页。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
307（临时重定向）	服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 Googlebot 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 Googlebot 某个页面或网站已被移动。

4xx（请求错误）

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

代码	说明
400（错误请求）	服务器不理解请求的语法。
401（未授权）	请求要求进行身份验证。登录后，服务器可能会返回对页面的此响应。
403（已禁止）	服务器拒绝请求。如果在 Googlebot 尝试抓取您网站上的有效网页时显示此状态代码（您可在 Google 网站管理员工具中诊断下的网络抓取页面上看到此状态代码），那么，这可能是您的服务器或主机拒绝 Googlebot 对其进行访问。
404（未找到）	服务器找不到请求的网页。例如，如果请求是针对服务器上不存在的网页进行的，那么，服务器通常会返回此代码。如果您的网站上没有 robots.txt 文件，而您在 Google 网站管理员工具“诊断”标签的 robots.txt 页上发现此状态，那么，这是正确的状态。然而，如果您有 robots.txt 文件而又发现了此状态，那么，这说明您的 robots.txt 文件可能是命名错误或位于错误的位置。（该文件应当位于顶级域名上，且应当名为 robots.txt）。如果您在 Googlebot 尝试抓取的网址上发现此状态（位于”诊断”标签的 HTTP 错误页上），那么，这表示 Googlebot 所追踪的可能是另一网页中的无效链接（旧链接或输入有误的链接）。
405（方法禁用）	禁用请求中所指定的方法。
406（不接受）	无法使用请求的内容特性来响应请求的网页。
407（需要代理授权）	此状态代码与 401（未授权）类似，但却指定了请求者应当使用代理进行授权。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
408（请求超时）	服务器等候请求时超时。
409（冲突）	服务器在完成请求时发生冲突。服务器必须包含有关响应中所发生的冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，同时会提供两个请求的差异列表。
410（已删除）	如果请求的资源已被永久删除，那么，服务器会返回此响应。该代码与 404（未找到）代码类似，但在资源以前有但现在已经不复存在的情况下，有时会替代 404 代码出现。如果资源已被永久删除，那么，您应当使用 301 代码指定该资源的新位置。
411（需要有效长度）	服务器不会接受包含无效内容长度标头字段的请求。
412（未满足前提条件）	服务器未满足请求者在请求中设置的其中一个前提条件。
413（请求实体过大）	服务器无法处理请求，因为请求实体过大，已超出服务器的处理能力。
414（请求的 URI 过长）	请求的 URI（通常为网址）过长，服务器无法进行处理。
415（不支持的媒体类型）	请求的格式不受请求页面的支持。
416（请求范围不符合要求）	如果请求是针对网页的无效范围进行的，那么，服务器会返回此状态代码。
417（未满足期望值）	服务器未满足”期望”请求标头字段的要求。

5xx（服务器错误）

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

代码	说明
500（服务器内部错误）	服务器遇到错误，无法完成请求。
501（尚未实施）	服务器不具备完成请求的功能。例如，当服务器无法识别请求方法时，服务器可能会返回此代码。
502（错误网关）	服务器作为网关或代理，从上游服务器收到了无效的响应。
503（服务不可用）	目前无法使用服务器（由于超载或进行停机维护）。通常，这只是一种暂时的状态。
504（网关超时）	服务器作为网关或代理，未及时从上游服务器接收请求。
505（HTTP 版本不受支持）	服务器不支持请求中所使用的 HTTP 协议版本。

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

2010年04月13号 — apache 的AcceptMutex 的理解
2009年04月1号 — 关于HTTP 协议中的 KeepAlive
2008年12月25号 — 使用gzip将你的Apache速度提高十倍
2009年08月12号 — 关于apache的restart和stop, start的问题
2009年02月17号 — 在64位机器上关于Apache 2.2.3版的编译问题
2009年01月5号 — 关于keepalive的解释
2009年02月27号 — 使用mod_headers或mod_expires落实缓存
2009年02月25号 — 查询并禁止apache中异常访问量的用户
2009年03月30号 — 对Apache中并发控制参数prefork理解和调优
2009年02月25号 — Apache 设置web 缓存

标签：Apache基础知识, HTTP相关知识, 状态

apache 的AcceptMutex 的理解

OurApache — Tue, 13 Apr 2010 13:15:48 +0800

当apache监听多个端口或多个ip上的端口时，多个子进程是怎么分工的呢？和只监听一个端口有什么区别吗？

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, 0×81dd334, 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, 0×81dd33a, 1) = 0

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

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

第三步：accept 17

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

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

2009年01月6号 — Apache服务器使用.htaccess实现图片防盗链方法教程
2009年02月12号 — apache core段的DocumentRoot与访问权限
2009年01月5号 — 关于keepalive的解释
2009年08月13号 — Apache和IIS共享80端口的四个方法
2009年02月10号 — Apache和IIS共享80端口的四个方法
2009年01月6号 — htaccess学习笔记
2009年08月13号 — Linux下Apache并发连接数和带宽控制
2009年02月27号 — header Content-Disposition参数说明
2009年06月15号 — 16个简单实用的.htaccess小贴示
2009年02月17号 — 在64位机器上关于Apache 2.2.3版的编译问题

标签：AcceptMutex, Apache基础知识

Apache2中俩种设置PHP的异同

OurApache — Tue, 09 Mar 2010 09:38:09 +0800

Apache2开始引入了Hook方式, 对应的在PHP中也提供了apache2handler这种sapi.

和我之前介绍过的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速度提高十倍

标签：apache2handler, Apache高级应用, Hook, 配置

htaccess二级目录重写找不到路径

OurApache — Tue, 09 Mar 2010 09:36:35 +0800

首先申明一下：使用.htaccess文件，会降低httpd服务器的一点性能.h
我们一般会把客户的网站放在自己的网站的目录下面，
比如FTP：/home/ftp/www，
有一个网站http://www.example.com，
那么新建一个网站的目录为http://www.example.com/newsite/，
我们这个项目是使用qeephp开发的，使用qeephp的路由重写功能，在把网站上传到服务器上，
使用了虚拟目录Alias，因为不想看到类似http://www.example.com/newsite/public/这样的路径，
于是外部访问地址是http://www.example.com/newsite,
在我启用了qeephp的rewrite时，一直说找不到路径，/home/ftp/www/newsite/,很奇怪。
仔细阅读htaccess的文档，发现有一个BaseDir参数
在htaccess 中添加

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的功能及写法

标签：Apache初级应用, htaccess, 路径

使用Apache做负载均衡

OurApache — Sat, 12 Dec 2009 23:38:45 +0800

第一次看到这个标题时我也很惊讶，Apache居然还能做负载均衡？真是太强大了。经过一番调查后发现的确可以，而且功能一点都不差。这都归功于 mod_proxy 这个模块。不愧是强大的Apache啊。

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

一般来说，负载均衡就是将客户端的请求分流给后端的各个真实服务器，达到负载均衡的目的。还有一种方式是用两台服务器，一台作为主服务器(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可能的取值有：

以下是引用片段：
lbmethod=byrequests按照请求次数均衡(默认)
lbmethod=bytraffic按照流量均衡
lbmethod=bybusyness按照繁忙程度均衡(总是分配给活跃请求数最少的服务器)

各种算法的原理请参见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年01月5号 — 重大漏洞, 让Apache上传不安全-php.rar
2009年02月25号 — Apache 两种虚拟主机方式的区别
2009年02月10号 — apache 无法启动故障排查
2009年02月27号 — Apache common-pool, common-dbcp源码解读与对象池原理剖析
2009年01月5号 — 关于keepalive的解释
2009年02月7号 — 使用gzip压缩来压缩网页之apache的相关配置
2009年02月7号 — 在Apache下限制每个虚拟主机的并发数
2009年02月7号 — apache之404错误页面
2009年02月25号 — 网站服务器(Apache)的日志与监视
2009年02月7号 — 使用apache下的301设置来做域名的更换转移

标签：Apache高级应用, 负载均衡

apache配置（如何禁止列出目录内容）

OurApache — Sat, 12 Dec 2009 23:37:21 +0800

只需要将访问目录的Options 内部的Indexes去掉即可。

以下是代码片段：
        <Directory /home/blog/piwigo-2.0.5>
                #Options Indexes FollowSymLinks MultiViews
                Options FollowSymLinks MultiViews
                AllowOverride all
                Order allow,deny
                allow from all
        </Directory>

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

2009年06月7号 — apxs是Apache编译和安装扩展模块的工具
2008年12月27号 — apache禁止使用IP访问的实现方法
2009年02月17号 — 在64位机器上关于Apache 2.2.3版的编译问题
2009年02月18号 — apache和tomcat集成的总结
2009年09月2号 — HTTP Referer二三事
2009年09月2号 — 针对$_SERVER['PHP_SELF']的跨站脚本攻击（XSS）
2009年01月5号 — 关于keepalive的解释
2009年02月25号 — Apache缓存系统
2008年12月27号 — apache中.htaccess的功能及写法
2009年02月6号 — TCP 相关参数解释

标签：Apache基础知识, 目录

.htaccess的301跳转

OurApache — Sat, 12 Dec 2009 23:35:29 +0800

server:linux(ubuntu)

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

以下是引用片段：
Options +FollowSymlinks
RewriteEngine on
rewritecond %{http_host} ^htmldata.cn [nc]
rewriterule ^(.*)$ http://www.htmldata.cn/$1 [r=301,nc]

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的功能及写法

标签：301, Apache基础知识, htaccess, 跳转

网络流量尽在掌控

OurApache — Sun, 06 Sep 2009 00:17:12 +0800

导读:了解网络流量的分布、找到优化网络性能的方法、通过网络管理技术来提升网络效能，同时做好网络流量信息安全方面的防护工作，这是网络流量管理的主要工作内容。

中国移动研究院李洋博士

近十几年来，互联网得到了飞速发展。据统计，互联网目前已成为人类社会最重要的信息基础设施，占人类信息交流的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年06月1号 — 玩转apache之日志
2009年08月13号 — Linux下Apache并发连接数和带宽控制
2009年02月25号 — apache ab压力测试收藏
2009年01月6号 — Apache 中KeepAlive 配置的合理使用(优化)
2009年08月12号 — 关于apache的restart和stop, start的问题
2009年01月15号 — Apache服务器安全防范
2009年02月16号 — Apache、resin、rewrite泛域名、多域名设置
2009年09月2号 — 针对$_SERVER['PHP_SELF']的跨站脚本攻击（XSS）
2009年03月9号 — 监视并记录Apache网站服务器的运行
2009年08月16号 — Apache两种运行方式比较:Standalone和inetd

标签：未分类, 流量

基于资源的HTTP Cache的实现介绍

OurApache — Sun, 06 Sep 2009 00:02:58 +0800

我们都知道浏览器会缓存访问过网站的网页，浏览器通过URL地址访问一个网页，显示网页内容的同时会在电脑上面缓存网页内容。如果网页没有更新的话，浏览器再次访问这个URL地址的时候，就不会再次下载网页，而是直接使用本地缓存的网页。只有当网站明确标识资源已经更新，浏览器才会再次下载网页。

一、什么是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 缓存

标签：cache, Etag, HTTP相关知识