支付宝小程序占用服务器端TCP连接问题分析及解决建议

一、 问题起源：

        我们的系统支持多端，针对不同的端分配了不同的网关集群。通过监控系统发现，支付宝小程序面向的网关上的TCP连接数直线上升，最高到过5万+个连接，同时微信小程序的TCP连接数 仅为1000多个，甚至在支付宝下游服务被切断的情况下仍是有增无减，而实际上微信的用户数与支付宝的用户的比例基本为10:1，我们的工程师认为是支付宝用户量大所导致， 但根据我的经验否定了这个观点，肯定是连接没有释放。  

二、排查过程

       首先确认支付宝小程序是否因为未设置读超时，导致连接一直被保持，经过代码分析及支付宝官方文档中对my.request超时的设置方法，经确认所有的HTTP请求都设置了30秒的超时；其次检查是否有周期性的请求存在，导致连接未释放，经排查未找到。最后，用whireshark抓包进行分析。发现，每次HTTP请求完成后并未释放连接（也就是小程序端发送FIN），后面的请求没有规律，有时会重用已经存在的连接进行请求，请求完成后仍不关不连接，有时发起新请求前会关闭前一个连接，使用新的连接进行HTTP请求。测量了一下时间，发现如果在前一次请求完成后，如果30秒内进行后继的请求，将重用当前的连接，反之则先关闭当前连接，并利用新建立的TCP连接进行HTTP请求。如果一个HTTP请求完成后，后继没有任何的请求，则小程序将一直维持连接，直到服务重启或者小程序进行下一次请求才会释放，除非支付宝转到后台，小程序才会主动拆除连接。所以，只要使用支付宝小程序就并且支付宝在前台就会占用一个长连接，不管有没有请求。

三、技术原理

     在HTTP1.0中，每次HTTP请求都需要建立一个TCP连接，然后GET/POST数据，获取完应答后关闭TCP连接。这样每次HTTP请求，都要进行一次的连接的建立和拆除，在大访问量的情况下效率很低，当然可以通过在HTTP头中的keep-alive，来维持和重用长连接。

    在HTTP1.1中，不需要在HTTP头中设置keep-alive 就可以使用长连接，但应该在合适的时机主动拆除TCP连接，从而减少服务端的资源占用。

四、深层分析

    支付宝小程序使用的阿里的API实现中，没有实现HTTP1.1协议中长连接的优化实现，也就是说在没有请求时，并不释放连接，应该在一次请求后30秒内没有请求时，直接拆除TCP连接。