嘻嘻哈哈的部落格(blog)

怎样用基于域名的虚拟主机来标识不同的ssl的虚拟主机呢？
奇了怪了
前面不是已经否定了这个可能性了吗
怎么还出来Howto的问题呢？
不是我不明白，这世界变化快
原来的ssl协议是不支持的
但自打tls出来
支持个叫SNI(Server Name Indication)的feature之后
做基于域名的ssl的虚拟主机已经不再是天方夜谭
让我们还以apache+mod_ssl为例来说明问题
我们先看官方文档怎么说的

It is possible, but only if using a 2.2.12 or later web server, built with 0.9.8j or later OpenSSL. This is because it requires a feature that only the most recent revisions of the SSL specification added, called Server Name Indication (SNI).

这一段是摘自于最新的apache官方文档
写的很明白
只要apache的版本大于等于2.2.12
OpenSSL的版本大于等于0.9.8j
就可以支持
顺手再写个ssl虚机的例子：

<VirtualHost 127.0.0.1:443>
    SSLEngine On
    ServerName sni.ssl.xxx.com:443
    DocumentRoot /var/www/htdocs/
    SSLCertificateChainFile /var/www/ssl/root.pem
    SSLCertificateFile /var/www/ssl/root.crt
    TransferLog /var/www/logs/access.log
</VirtualHost>

以前用mod_ssl+apache配ssl服务器碰到过这个问题
别人直接用ip:443端口直接访问
就显示了缺省的https的站点
按照我们配http服务器的逻辑
肯定是想把443端口和某一个域名绑定起来用的
这样别人不知道域名就无法访问到真正的https站点内容
但是直接在apache里用

这样搞是不行的
系统总是只认第一个虚机
然后把所有https到443端口的访问都丢到里面
看了下(apache)官方的文档
里面是这样解释的：

Why can’t I use SSL with name-based/non-IP-based virtual hosts?
The reason is very technical, and a somewhat “chicken and egg” problem. The SSL protocol layer stays below the HTTP protocol layer and encapsulates HTTP. When an SSL connection (HTTPS) is established Apache/mod_ssl has to negotiate the SSL protocol parameters with the client. For this, mod_ssl has to consult the configuration of the virtual server (for instance it has to look for the cipher suite, the server certificate, etc.). But in order to go to the correct virtual server Apache has to know the Host HTTP header field. To do this, the HTTP request header has to be read. This cannot be done before the SSL handshake is finished, but the information is needed in order to complete the SSL handshake phase. Bingo!

金步国同学翻译如下：
为什么不能在基于域名的虚拟主机上使用SSL?
原因很技术化，有点类似于”鸡和蛋”的问题。SSL协议层位于HTTP协议层之下，HTTP协议是被封装在SSL协议中的，当一个SSL连接(HTTPS)请求到来的时候，Apache/mod_ssl必须和客户端协商SSL协议参数(握手)，所以，mod_ssl必须查看虚拟主机的配置信息(例如允许使用哪些加密算法、服务器证书是哪个等等)，然后才能完成SSL会话通道的建立；但另一方面，为了确切知道究竟应该查看哪个虚拟主机，Apache又必须知道HTTP请求头的Host字段的内容，而这在完成SSL握手之前是不可能知道的。

今天用到LogLevel于VirtualHost中了
查了文档确认了一下
特此记录

nginx是个http的服务器和代理服务器
我们拿过来做web server
nginx有个特别的模块儿：empty_gif
当你请求的url资源跟你设置为empty_gif的匹配上的话
服务器直接返回给你一个1×1的空白图片
看出来了吧
这里最大特点在于：
服务器根本不去查所请求资源的情况，而是直接返回一个很小的、内存中的图片
这正是我们应用所要的
我们的客户端产品经常会有些信息发回来
比如有个用户刚点播了某个节目
有个用户刚点了客户端的某个广告什么的
客户端都会通过请求特定web服务器的特定资源
而且还带有特定的参数
这边喉动态的程序通过分析web服务器的access_log
就能大致了解用户行为
以前的web服务器是用1.3.xx的apach去掉了n多无用的模块儿后做的
在pingback来的量大的时候是有些性能问题的
这下nginx的empty_gif模块儿
仿佛就是为我们的需求定做的
我们的web服务器不需要正确返回，甚至于不需要返回
他只需要接受请求，并写到log里就行
有了nginx的empty_gif
web服务器都可以不读盘了

高兴之余
我又想到
其实如果假设pingback请求的都是同一个资源
比如a.gif
那么就算是用apache的话
系统存在这个a.gif，其是一个1×1的空白gif图
那么除了第一次访问以外
以后每次访问其也是从内存里读(不用读盘)
这样其实跟nginx的empty_gif是一样的！

说到这里
再说说nginx用作我们的pingback的web服务器的缺点
就是nginx不能disable掉KeepAlive
我们的pingback都所以一条一条单独的
根本就不需要服务器开keepalive
但nginx不支持disable掉keepalive
55555555555555555555

朋友装了个discuz6.0
系统是linux+httpd2.2+mod_rewrite
一开启页面静态化
页面都变成404找不到了
然后去官网看了看
知道是没有rewrite规则
于是在discuz的目录下touch了一个.htaccess
在里面加上：

# 将 RewriteEngine 模式打开
RewriteEngine On

# 修改以下语句中的 /discuz 为你的论坛目录地址，如果程序放在根目录中，请将 /discuz 修改
为 /
RewriteBase /

# Rewrite 系统规则请勿修改
RewriteRule ^archiver/((fid|tid)-[\w\-]+\.html)$ archiver/index.php?$1
RewriteRule ^forum-([0-9]+)-([0-9]+)\.html$ forumdisplay.php?fid=$1&page=$2
RewriteRule ^thread-([0-9]+)-([0-9]+)-([0-9]+)\.html$ viewthread.php?tid=$1&extra=page\%3D$3&page=$2
RewriteRule ^space-(username|uid)-(.+)\.html$ space.php?$1=$2
RewriteRule ^tag-(.+)\.html$ tag.php?name=$1

这里没啥可说的，唯一要注意的是RewriteBase
如果你的discuz是http://xxx.xxx.xx.xxx/discuz这样来访问的话
这里应该设成discuz
如果是http://xxx.xxx.xxx.xxx/这样的话
就应该设成/

.htaccess的方法是最灵活的解决方法
但是你需要先确认系统支持在.htaccess里写这些rewrite规则
(缺省一般是不让的)
于是还要在apache的配置文件里加上

<Directory /path/todiscuz>
AllowOverride Fileinfo
</Directory>

重写规则之类的语句只需要Fileinfo即可
然后重起apache
再起用静态化
就OK了

昨天产品报某台机器的80口慢
而且比较诡异的是同一个apache开的8080口却不慢
这种情况以前从来没有碰到过
于是我拷贝了8080端口的一个虚机配置为80口
再试
发现这个80口的速度还行，比较快
跟原来8080的一样
于是我就得出结论
访问速度快慢应该跟端口没有关系
而应该跟DocumentRoot有关系

后来的事实证明
我求证问题的方法是正确的
但是结论确是下错了

正确结论应该是：“慢的那个80口的virtualhost的配置导致了其访问慢”
而这里的配置
除了DocumentRoot跟8080的不一样外
还有
80的虚机里开了个反向代理
问题是反向代理开得有问题
不仅用了ProxyPass和ProxyPassReverse作反向代理
还打开了ProxyRequests
真正的问题就出在这里
打开了ProxyRequests，就等于是让apache支持了proxy功能
成了一个open proxy server
除非在 里进行限制
而恰恰这里配的限制也赔错了，没有起作用
故而有很多人把80口的这个虚机当成proxy server来用
当然正常的80口访问速度就慢了呀

最后解决：
把ProxyRequests关掉，再重起apache
即解决问题

当浏览器的地址栏里输入的url里如果含有中文字符的话
会被客户端(浏览器)先编码在送往服务器端
缺省状况下
浏览器(ie何firefox)都是设成用utf8编码url
但是服务器端(apache)却无从可知url采用的编码格式
因此也无法对其用正确的编码格式来解码
所以他就会直接去文件系统里按照你请求的url（编过码的）去取资源
如果文件系统里带有中文字符的资源的编码格式正好是客户端对url的编码格式的话
那么访问自然是没有问题
否则
就会出404的错误

公司手头有几台apache(httpd2.x)的机器
主要是往外吐一堆的xml的
其中最主要是一个300多k的大xml
原来为了节省流量
在服务器上打开了mod_deflate
但后来发现机器负载巨重(load>100甚至于更多)
于是就把mod_deflate关掉(mod_deflate的缺点导致的)
但是显然一把mod_deflate关掉，流量又得猛涨
难道就没有一种折衷的方案吗？
记得在n年前，sina的同学们说发布的内容页都是提供2个版本对外服务(一个压缩过的，一个未压缩的)
于是我就想能不能把这些巨大的xml文件预先压缩一下
来请求了局让apache直接取这个压过的版本呢？
于是就开始想办法
最后发现有n种方式可以实现

1. Enable pre-compression with mod_gzip;http://schroepl.net/projekte/mod_gzip/config.htm#precompressed
2. Use Apache rewrite rules to redirect requests (index.html) to the pre-compressed version (index.html.gz):http://www.webmasterworld.com/apache/3387947.htm
3. Use PHP to redirect to the pre-compressed version;http://www.phpbuilder.com/tips/item.php?id=1128
4. Use Apache feature MultiViews and apache module mod_negotiation

这个直接导致了我在apache里设置的对xml文件的压缩(deflate)未能成功
因为我的配置文件里是这么写的：

AddOutputFilterByType DEFLATE text/html text/plain text/xml

而且这种配置在系统自带的apache里是没有问题的
后来仔细查了查
发现系统自带的apache
用的是/etc/mime.types文件
而源代码编译的
用的则是conf/mime.types文件
这两个文件对xml文件的internet media type解释就是不一样：
一个认为是text/xml
另外一个则认为是application/xml
知道原因了
解决问题起来就顺利多了
把配置文件里AddOutputFilterByType那句后面加上application/xml
再重启就ok了

自打用上这里的用于cacti监控apache的模块儿apachestats后
总觉得还行，能用（也有些小问题，主要是图上显示的细节问题）
但最近发现有个问题比较大
就是有的服务器的监控图明显不对
我们有好些web server的机器(跑的apache)，访问量很大，httpd进程经常被打到2000个，被打满(2048)
但是在这些服务器的监控图上一般最多能显示1000个httpd进程
为了查这个问题
我仔细的看了下这个模块儿的实现过程
import进来的每一个Data Templates和Graph Templates都看过了
最后发现是新生成的那个叫”WebServer – Apache Statistics”的Data Templates有问题
这里面的几乎每一个Data Source Item的“Maximum Value”都设的偏小
这样出来的监控图自然当数据小的时候都没什么
但数据一大，马上出问题！
知道原因了
再改正就快了
重新把数据设大
再删掉所有的用这些Templates建的图
再进rra目录删掉所有相关的rra文件（这步貌似非必须的：）
再重建新图
最后看图：终于搞定了
最后把改过的xml文件贴上来，以免大家重复劳动
改过的apachestats0.4的模板文件