帖子

目前显示的是 十月, 2014的博文

ATS的HTTPS握手失败的排错经历

我用ATS搭了一个测试网站,然后用curl访问的时候发现CentOS 6可以访问,但是CentOS4就不行。CentOS 4下curl报告:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure然后我用openssl s_client -connect myhost.com:443 -state -debug -tls1 -msg看到的message回复是这样:read from 0xb644fc0 [0xb689760] (5 bytes => 5 (0x5))
0000 - 15 03 01 00 02 .....
read from 0xb644fc0 [0xb689765] (2 bytes => 2 (0x2))
0000 - 02 28其中0x15代表的是alert,而0x28代表的handshake failure然后我在CentOS6下测试用sslv3去连接,发现也不行。curl会报告Cannot communicate securely with peer: no common encryption algorithm(s).我的这个curl用的是NSS而不是Openssl。后来,我找到了一个网站,https://www.ssllabs.com/ssltest/, 可以在线检查ssl server的SSL兼容性。它提示说我,我这个测试服务器只有使用SNI的才能连接。于是我恍然大悟啊。ATS的配置文件ssl_multicert.config中,我以前是这么写的ssl_cert_name=/etc/trafficserver/ssl/server.crt ssl_key_name=/etc/trafficserver/ssl/server.key需要改成:dest_ip=* ssl_cert_name=/etc/trafficserver/ssl/server.crt ssl_key_name=/etc/trafficserver/ssl/server.key其中dest_ip=*的意思是The corresponding certificate will be used as the global default…

当ATS遇上curl: 记ATS的一次故障排查经历

不是最近懒了不写blog,而是每天到家都10点以后了,实在累得没力气。这周花了很多时间排查一个bug。我刚做了一项架构升级,把某个项目所用的http server换成了ATS。这种小破事儿按理说1-2天就可以完成,结果耗费了我3-4周。我把http server替换成ATS后,放在线上用真实流量一跑,发现性能跟不上。大部分请求(超过70%)都因为处理超时而返回5xx类型的错误。而我把压力降低到每秒只有50-100个请求,情况还是如此。在我们这套系统的架构中,ATS后面还有一个后端服务器,ATS主要充当的是反向代理的作用。client <-------> ATS <-------> 后端而经线上测试发现,从client到ATS之间有1万多个已建立(established)的TCP连接,从ATS到后端之间也是。这是极不正常的。因为我们每秒的请求数很低啊!!!!在我们的设计中,ATS和后端之间是短连接,它每收到一个请求都会去连后端,用完后关闭。我第一个反应是,会不会是ATS用完这个连接之后没有关??我给后端的服务进程加了些日志,让它每关闭一条连接都打一条日志。发现,情况并非如此。基本上每秒新建多少就关闭多少,大体上相等。而且,我在测试环境中,用curl把真实的线上请求一条条的发给ATS做测试,也没有发现问题。连接在处理完后被立即断掉了。可见这块代码没什么问题。我认为,既然后端收到了tcp close请求,那么依然存在这么多已建立连接只有一个可能:后端处理太慢。为了验证我的想法,我用netstat查ATS和后端之间已建立的连接有哪些,随便挑一个,然后用lsof找出它的文件描述符(fd),然后去/proc下找到这个fd,就能看到这个连接是什么时候建立的。发现大部分连接都持续了3-5分钟以上。顿时释然。这也就解释了为什么会有几万个连接。于是我继续找瓶颈。很遗憾的是,disk io几乎没有。ATS和后端是处于同一台机器上,走lo接口,所以网络瓶颈不存在。于是我猜是CPU。因为我看见负载飘动在10-20之间。kernel的event进程经常被唤醒,占用了大量CPU。但是这我没法整,我主要看用户态的代码哪里有问题。每秒才几十个HTTP请求,瓶颈怎么也不能出在kernel的TCP栈上,对吧?于是我用perf继续查,然后发现后端的服务器在管理已建立的连接的时候,…