首页 > 代码库 > 云计算之路-阿里云上:SLB会话保持的一个坑
云计算之路-阿里云上: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立马消失。
一想到因为这个原因造成很多用户不能正常访问,就有一种说不出的恼火。。。