[BUGCASE]Phantom服务代码不健壮导致无法发送报表邮件

一、问题描述

广告平台中的发报表邮件功能偶尔会出现发送失败的情况，重启phantom服务之后就好了
查看phantom服务的日志发现，在2017-12-12 03:29:45有访问记录，并且参数是异常的，queryJSON是%257B，经过url decode之后发现是：{

并且之后再进行发邮件操作，phantom不再打日志

不想看分析过程的话，可直接看结论或解决方案

二、原因分析

1.导火线

日志中的url是后台传给phantom服务的，为什么会传一个异常参数的url过来？
很明显不是人为点击发邮件触发的，而且时间发生在凌晨，会不会是安平扫描？
经过和后台同事确认，确实如此！

原来后台没有做session校验，所以被扫描了，导致了这个问题

2.一些猜测

可是这似乎不是根本原因
为什么安平扫描会导致phantom服务停止打日志？
以下是一些猜测：

(1)phantom服务崩溃

一开始猜测是phantom服务接收到异常参数，内部报错，导致服务崩溃

这个想法立即被导师否决了，因为phantom服务的进程还在，并没有崩溃

(2)运维自动重启服务的锅

因为phantom服务接了运维这边的自动重启服务，如果进程挂了会自动拉起

会不会进程拉起的过程有问题，初始的phantom进程不再工作，又拉起了一个新进程，存在两个进程，导致无法发邮件？

(3)进程僵死

会不会是进程僵死了，导致进程虽然还在，实际上却不工作？

(4)进程打开的文件句柄数超出限制

会不会是进程打开的句柄数超过了限制？

由于当时急着把服务重启了，没法获取出错时的上下文环境信息

为了验证这些猜测，需要重现下这个问题，怎么重现呢？

似乎没法真正地模拟安平的扫描过程

当时有同事提供了一个解决方案：
写一个脚本定时给phantom服务发包，然后看phantom服务有没有回包，没有回包说明phantom已经停止工作了，这时把phantom的进程杀死。运维的自动拉起服务这时会拉起phantom服务，如此便可解决这个问题

听起来很有道理，怎么实施呢？

打算先试着找到根本原因吧，实在没法重现这个问题，找不到根本原因再考虑发包的方案

3.分析代码

于是试着从phantom的代码入手
phantom服务拿到后台传过来的url之后，会做一下事情：

• 1.取url中的queryString
• 2.将queryString转化成JSON格式，并取其中的queryJSON参数的值
• 3.将queryJSON的值进行url解码（decodeURIComponent）
• 4.将解码后的queryJSON转化成JSON格式（JSON.parse）JSON.parse
• 5.取其中的platform参数的值
• 6.通过判断platform拼接出不同的targetURL
• 7.用phantom这个headless browser打开这个targetURL，并取其中的HTML内容
• 8.将这个内容传给后台服务

用安平扫描的异常参数模拟一遍上面的流程，发现第4步报错，JSON.parse方法没法解析{左大括号

这个报错会导致程序不再往下执行，但并不会导致phantom服务不可用，下一次传入正确的参数依然可以发邮件


安平扫描有可能会连续扫描多次，会不会是这个原因呢？

4.问题重现

于是打算写一个脚本给phantom服务发多次带错误参数的请求：

for ((i=1;i<=100;i++));
do curl -i "http://ip:port/generateAdsReport?sessionid=&queryJSON=%7B";
done

ip:port是phantom服务的套接字

果然重现了！

5.查看报错环境

这时就可以看上下文环境信息

(1)查看进程情况：

ps -ef | grep phantom

并没有出现之前猜测的两个进程的情况


ps -A -o stat,ppid,pid,cmd | grep -e '^[Zz]'

也没有变成僵尸进程

(2)查看文件句柄数

查看系统默认最大句柄数（单个进程最多允许打开的最大句柄数，默认是1024）
ulimit -n


查看总句柄数
lsof|awk '{print $2}'|wc -l


查看当前进程占用的句柄数
lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more

根据ID产看进程名
ps aef|grep 24204


发现并没有哪个进程超过句柄限制

(3)查看TCP连接数

netstat -nat | grep 10021

问题慢慢浮出水面！！！

6.根本原因

有很多状态为CLOSE_WAIT的TCP连接
CLOSE_WAIT表示等待从本地用户发来的连接中断请求


也就是说有很多TCP连接没有关闭，对照之前的phantom代码，出现报错之后，确实没有在执行任何关闭连接的代码

所以根本原因还是：自己写的代码不健壮，没有捕捉异常，报错了没有及时关闭TCP连接


一句话总结问题的原因：

由于安平的扫描，phantom服务内部将字符串转成JSON时报错，不往下执行后面的代码，也就不会关闭已经建立的TCP连接。未关闭的TCP连接积累到一定的量，超出系统的最大限制，导致phantom服务不再接收和处理之后的请求，最终导致无法发送报表邮件。

三、解决方案

知道问题的根本原因，要解决就容易多了，使用try/catch语句将可能出错的代码包裹起来，如果报错就关闭TCP连接。

try {
    ...
    var jsonParams = JSON.parse(decodedParams);//可能报错的语句
    var platform = jsonParams.platform;
}catch(err) {
    response.close();//关闭TCP连接
}

------------------------------------------------20171219 更新------------------------------------------------

为了弄清楚TCP连接数的限制，在开发环境又测试了下

状态为CLOSE_WAIT的TCP连接大概到了25个时，phantom服务就不再工作

此时phantom占用的文件句柄数是61个

实际上，phantom的最大并发连接数是10个，参考phantom官网

以下是来自phantom官网的截图：

以下是在开发环境上测试出来的TCP连接的边界值

之前的一句话原因总结改为：

结论

由于安平的扫描，phantom服务内部将字符串转成JSON时报错，不往下执行后面的代码，也就不会关闭已经建立的TCP连接。未关闭的TCP连接积累到一定的量，超出phantom的最大并发连接数10个（之前写的是系统的最大限制），导致phantom服务不再接收和处理之后的请求，最终导致无法发送报表邮件。