说说前面文章提到的为什么支付宝慢的原因吧。
起因：买域名需要用支付宝付款，但支付过程实在是太慢了。
其实支付宝慢我几个月前就发现了，只是那一次还可以用财富通付款，所以我就选财富通了。这次只有淘宝可以选了，没办法只有用它付。
首先是尝试等，等了几下出了几次错，都是超时。不能再等了，转钱是件重要的事，如果因为某个步骤超时导致事情办不了，钱又被扣了，就麻烦了。
没办法，研究一下为什么慢吧。
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=246Ping 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给个警告总比用户付不了款，等几次都超时出问题强吧。