十分的气愤，2月19号左右没的。23号我发现。

hm有三个自动备份，每月，每周，每天，但是呢，每月的备份在20号，每周的备份赶在21号，每天的备份在22号。所以三个备份里都没有我的文件。这什么狗屎的备份策略啊。

气愤之余，发现好像也没什么可做的，告它们？跨洋搞这种事我可没精力，所以唯一做了的就是发了封email，说I will never trust you。然后要求把款给退了。退款倒是还算快，两三个邮件来回就搞定了。

搬到了 photonVPS上，后面打算等yardVPS有货了再搬过去。再也不用虚拟主机了，直接上VPS。不过备份得自己来搞了。

extension_dir = “/a/b/c/d/e/f” 是默认值，经常会替换我的

extension_dir = “/m/n/o/p”

另外，php5模式可以识别

extension=/m/n/o/p/gmp.so

而如果切换到 fcgi模式，那个程序笨死了，会找 /a/b/c/d/e/f//m/n/o/p/gmp.so

当然找不到，就500了。

因此要想个办法，既支持 fcgi, 又支持php5模式，做最大的兼容，达到强大的鲁棒性。

绝对路径指 定 extension已不可能，只好换成相对路径。

在我的p目录下建x目录，再在x下建y软链接指向 /m/n/o/p

这样 /m/n/o/p/x/y 与 /m/n/o/p就是一回事了，同时这样也是6层目录，与默认值一致。

把extension那句改为:

extension = ../../../../../../m/n/o/p/gmp.so

这样，不论是不是偷偷摸摸换掉我的  extension_dir 这一句，相对加载时都是先上6层目录，再从头找gmp.so。

测试了一下,fcgi模式和php5模式都兼容。

收工。

HM真狠，不给换机器，买独立IP也不给换机器，只是在原机器上给网卡加了个IP。

还有一件不爽的事，HM居然把我的php.ini改了，就改了extension_dir那一行，改成默认值了，害得我的gmp extesion不能运行。我晕，先改回去，得关注一下，看看他们是否还会改回去。

一段时间忙着没来看，居然挂了。

于是重新设定了php.ini。把原来老的丢弃，用起hm默认的那个。

发现，我需要用到的gmp模块，升级后的php还是没有。很失望，我上次就要他们加的。

得，还是照老方法，自己加吧。由于可以自定义php.ini，所以加个gmp.so是可以的。

把原来的gmp.so放入对应目录，设定php.ini，不行！报不认识gmp的函数。这一步折腾了我最久，我以为是php版本的问题，又去重新下了对应的版本编译出gmp.so，结果还是不行。又把php.ini改得稀巴乱，照样不行。

也不知是怎么的，最后想到了，是fcgi没有重新加载我修改后的php.ini，尽管我一直在改。因为我把php.ini中的pdo模块都去掉了，phpinfo里还是返回有这个模块。于是想到了，应当想办法让它重新加载php.ini。

把extesion的目录改了一下，以便phpinfo中看到的时候，我可以立即知道已经重新加载了。通过cpanel把fcgi换回普通方式，试了一下，gmp.so可以用了。又换回fcgi，结果丫还是没加载新版的php.ini。回想起来我操作都太急了，没有让机器闲着，也许闲一下它就会重新加载了呢？过了几分钟，它真的重新加载了。试着运行了一下相关用到gmp的功能，正常了。又看了一眼phpinfo，里面出现gmp了。终于，一切又正常了。

起因：买域名需要用支付宝付款，但支付过程实在是太慢了。

其实支付宝慢我几个月前就发现了，只是那一次还可以用财富通付款，所以我就选财富通了。这次只有淘宝可以选了，没办法只有用它付。

首先是尝试等，等了几下出了几次错，都是超时。不能再等了，转钱是件重要的事，如果因为某个步骤超时导致事情办不了，钱又被扣了，就麻烦了。

没办法，研究一下为什么慢吧。

1. 首先是要找出一个慢的场景，这要才可以作下一步的分析，

我试了两下，整出一个场景来，就是访问这个URL很慢：

http://bankacknowledge.alipay.com/payment/e_bank_payment.htm

 刷新了数次，大部分慢，只有一两次快。（注：发现这个慢是本blog域名买之前的事，写本文时访问了此url几次，发现挺快的了，也许是跟时间有关系）

怀疑是IE问题，换ff上，这个页面全打开也是很慢。跟IE一样，刷新多次一两次快，其余慢。

慢的时候，状态栏显示正在等待 img.alipay.com

分析了一下页面结构，要访问多个img.alipay.com上的  url如：

https://img.alipay.com/css/global/v2.0.css

https://img.alipay.com/pimg/icon_fold_3.gif

2. 然后当然是google之，关键词： 淘宝 支付 慢，最后在yahoo找到一篇：

http://ks.cn.yahoo.com/question/1390100028924.html

这里面提到了一件很重要的事，就是img.alipay.com。说要在host里指定一下IP。难道是这个站太慢？不至于马云这样的大财主不做IDC优化吧。

我试着ping 了一下：

 C:\>ping img.alipay.com

Pinging img.alipay.com [121.0.26.16] with 32 bytes of data:

Reply from 121.0.26.16: bytes=32 time=35ms TTL=246
Reply from 121.0.26.16: bytes=32 time=34ms TTL=246
Reply from 121.0.26.16: bytes=32 time=35ms TTL=246
Reply from 121.0.26.16: bytes=32 time=35ms TTL=246

Ping statistics for 121.0.26.16:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 34ms, Maximum = 35ms, Average = 34ms

应该说，速度挺快。又telnet img.alipay.com 443试了一下，立马连上，几次都如此，怀疑不是它的问题。

3. 尝试用wget 取url https://img.alipay.com/pimg/icon_fold_3.gif 查时间。发现手头的wget.exe版本太老，不支持https。

懒得去开linux了，更没时间去找新版的wget.exe了。手头有一个以前练手写的sget.exe，就拿它来试吧。

C:\>sget https://img.alipay.com/pimg/icon_fold_3.gif aa.gif
OK
HTTP code: 200
Date: Sat, 05 Apr 2008 17:28:57 GMT
Server: Apache
Last-Modified: Wed, 16 Jan 2008 14:17:01 GMT
ETag: “1f014c-271-90127140″
Accept-Ranges: bytes
Content-Length: 625
Cache-Control: max-age=604800
Expires: Sat, 12 Apr 2008 17:28:57 GMT
Keep-Alive: timeout=50, max=264
Connection: Keep-Alive
Content-Type: image/gif

还挺快的啊，一下就出来结果了，又运行一次，这次出情况了，一直没有出结果，卡住了，为什么呢？

打开VC编译一把源码开始调试，发现连接函数处：

  if (connect(sock, name, namelen) == 0 &&
   SSL_set_fd(ssl, (int)sock) &&
   SSL_connect(ssl) > 0)
  {
   return true;
  }

SSL_connect函数一直没有返回，这下问题就找到了：

img.alipay.com要么是压力大了承受不了了，要么是有潜在的BUG，在ssl握手时会出现问题，

导致客户端一直要等。导致淘宝ping起来很快，但某些页面访问起来很慢。

而tcp连接还是很快，所以我之前telnet img.alipay.com 443不能发现问题。

4. 原因查明了，方案就容易做了。先看了一下img.alipay.com要拉什么东西，其中.js和.css比较重要，图片就算了。

反复连接img.alipay.com，因为有一定机率很快连接成功，所以可以把它们都下载回来。

下回来后按目录结构放在本地一个文件夹里面。然后配置一下host:

127.0.0.1 img.alipay.com

再配了一下本地的apache，在这个文件夹启用hostname为img.alipay.com的https访问。

尝试访问一下本地的 https://img.alipay.com/css/global/v2.0.css

发现可以成功，唯独变的就是img.alipay.com是127.0.0.1了，还有就是ie会给一个证书错误的警告，选继续就好了。

然后重新刷了下 http://bankacknowledge.alipay.com/payment/e_bank_payment.htm

虽然有几个图不能显示，但是挺快的了。这样可以开始付款了。

打开淘宝付款流程，除了一些图片没有，一切正常，很快就成功打开招行专业版付了款。

搞定收功。可以买下域名了。

后记： 付款是大事，我敢这么做是因为我知道img.alipay.com不会影响付款逻辑。看官们谨慎点，最安全的办法还是等几个小时等到半夜好点。比如现在img.alipay.com就很快。

另外，yahoo上的回答说明已经有人知道这件事情了，虽然那里没有详细说明技术原因。yahoo现在也是马云管，马云应该也知道了，为什么就不做好一下img.alipay.com呢？

最后，像图片这样的东西完全没有必要通过https拉嘛，用http就行了，我知道alipay是为了照顾ie用户，因为混合https和http在一个页面内，IE会给出一个安全警告。

但是，既然你的img.alipay.com都承受不了压力了，这些图片css什么的，为什么就不直接从http拉呢？ie给个警告总比用户付不了款，等几次都超时出问题强吧。

HI团队太sb了。

第一个问题，发出来的邮件，标题编码不对。

编码被配成了so-8859-1，注意是so-8859-1，不是iso-8859-1，那个i字不知被谁给弄没了。

当然，实际上配成iso-8859-1也是不对的。因为它实际的标题编码是gbk。

为什么不把那个so-8859-1换成gb2312或gbk呢，现在它发到我gmail里的邮件，标题全部是长长的=AA=BB这样的乱码，唉。

另一个问题是，早几个月我注册某域名的时候，还可以用腾讯财付通付费。付费过程还比较正常，付完费就不正常了，招行专业版付费成功之后，打开一个ie，里面居然是www.domain.com/xxx/yyy…，我把ie关了去C网站上看，发现钱没有转过来，而财付通这边已经扣了，气得我立马发了个意见过去大骂。不过骂也不顶用啊，那时是晚上，就算是白天我的意见也不会立即被人看到，还是自己先想想办法吧。想起前面这个奇怪的url，后面那一串跟C网页一般的路径特像，会不会是。。。

我立即翻了下IE的历史记录，把这个url找了出来，把www.domain.com换成C的主页网址，然后呢，把整个串往IE地址栏一贴，一按回车，立即就出来个C的页面，告诉我成功接到付款。再登录C一看，钱已经到了。omg，问题在这里！要么财付通，要么C没有把配置配好，一个本来要填C域名的地方，还是默认的www.domain.com，所以C收不到最后的通知，因此不知道收到钱了。那到底谁错了呢？想想C连个email标题编码都配不好，那九成是它的问题了。

问题清楚了之后，我又跑到网页上提反馈的地方，回复了一下我之前提的这一条，告诉他们，你们配置错了，要如何如何。

过了几天之后，C到是回了封信，说看了LOG付款过程正常，是不是我IE设置有问题blabla的，靠，要不是我发现了这个秘密，自己访问了一下新的url，这个付款过程能正常吗。还问我是不是有问题，典型的无技术客服对白痴用户的那一套，就不要套到我身上来了。

这一次又买域名，倒好，连财付通都给关了，显然是用财付通有很多用户遇到问题了，C不得不给关了。怎么不早按我说的改一改配置呢，猪头们。

上次之所以选择财付通不选支付宝，是因为后者太慢了。不是网速慢，是sb淘宝的技术问题。我今天又花时间分析了一把为什么淘宝慢。总算整出来了，且听下回分解吧。

要数字证书用户才能用余额支付，还说是为了我的安全

狗屁，不让我用钱会是为了我的安全？当然是为了你的收入了。