云计算之路-阿里云上：SLB会话保持的一个坑

冒着被大家厌烦的风险，今天再发一篇“云计算之路-阿里云上”。这是在前一篇发过之后真实发生的事情，我们觉得定位问题的过程值得分享。而且估计园子里不少朋友被这个问题骚扰过，我们有责任让大家知道问题的真正原因。

快下班之前，园区里另外一家公司的朋友说他们公司有的人不能正常访问园子——会出现HTTP Error 400错误，而其他人可以正常访问。这个问题立即引起了我们的警觉，因为之前也有园友反馈过同样的问题，当时什么也没动，后来就好了，以为是他们公司网络代理服务器的问题。由于我们从未遇到过这个问题，而且无法重现，也就无从下手。现在再次出现这个问题，也是有代理服务器的网络环境，难得的机会，我们立即去现场一看究竟。

在遇到这个问题的电脑上，不管用什么浏览器，访问www.cnblogs.com都会出现错误：

Bad Request - Invalid Hostname
HTTP Error 400. The request hostname is invalid.

这是IIS返回的标准400错误，说明请求已经由SLB（阿里云负载均衡）到达了Web服务器。

我们查看了浏览器的请求头，一切正常。

在查看Cookie时发现只有一个名为SERVERID的Cookie，于是我们清除一下这个Cookie，结果html页面出来了，但后续的css/js文件加载时又出现400错误，再刷新浏览器，又变成400错误。

这个SERVERID的Cookie让我们想起了在排查“黑色30秒”问题期间，我们开启了SLB的会话保持，这个Cookie是SLB为了保持会话而产生的。难道与SLB会话保持有关？“Bad Request - Invalid Hostname”时，IIS收到的究竟是什么样的hostname？

带着这些问题，我们回到了自己的办公室，立即想到了IIS的一个重要日志——httperr日志，默认存放位置是C:\Windows\System32\LogFiles\HTTPERR\文件夹，打开一个日志文件一看，满眼都是400错误，错误的原因都是Hostname。

之前我们在偶尔看httperr日志时，也看到过这样的400错误，当时想可能是某些出问题的爬虫引起的，SLB怎么可能会把hostname搞错，也就没深究。

这次一定要找出IIS究竟收到的是什么样的hostname，那如何让IIS在httperr中记录hostname的信息呢？

在网上找到了一篇微软的参考资料：Additional properties are now available for logging in the Httperr#.log file in IIS 6.0 and IIS 7.0。

只需2步操作实现：

1. 在注册表项HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters中添加名为ErrorLoggingFields、类型为REG_DWORD、值为7DFF4E7 （十六进制）的项目。

2. 在命令行中运行命令：net stop http & net start http & iisreset

然后再查看httperr日志，结果让我们惊呆了，cs-host中竟然有这样的值（见下图）：

第1张图中SLB竟然把http header中的max-age=259200当作host的值转发给了IIS。

第2张图片SLB竟然把用户在使用代理服务器的情况下得到的IP信息当作host的值转发给了IIS。

难怪会出现Invalid Hostname的错误！

对于SLB这样的角色，http header失之毫厘，谬以千里。出现这样的问题，真的让人觉得这地方的代码写得很糟糕。

如果SLB的代码是开源的？哪个开发人员敢写出这样的代码？即使敢写，也马上会被人发现。

看来云计算更需要开源，不是把开源变成自己的计算能力，而是把自己的计算能力开源，这样才能更少问题、更让人放心。

禁用SLB的会话保持后，这些400立马消失。

一想到因为这个原因造成很多用户不能正常访问，就有一种说不出的恼火。。。

【更新】

阿里云已于2014年5月22日修复这个问题。