作者：suchengliu，腾讯 TEG 后台开发工程师
小绿盒在2G网络环境下收款速度较慢，影响商户体验，我们通过网络连接优化、数据传输优化和后台逻辑优化等一系列措施，将收款耗时降低近一半，达到了业界领先水平，改善了商户体验。
微信收款商业版为了覆盖更多收款场景，推出小绿盒收款机具。
小绿盒在2G网络下收款速度较慢(因为小绿盒收款是窄带场景，且4G模块成本是2G的2倍以上，所以小绿盒没有用4G)。
实验室情况：在2G实验室网络环境下，小绿盒收款一笔平均耗时需要5秒，而市场主流的解决方案只需3秒。
真实商家反馈：小绿盒收款一笔耗时基本在5秒以上，有时达10秒。收款速度慢，影响商户使用。
收款一笔的交互过程分4步：
步骤1：在键盘上输入收款金额。
步骤2：按下确认键后进入扫码状态，在此过程中机具开始预建立网络连接(竞品做法一致)，涉及DNS查询，TCP握手和TLS握手。
步骤3：扫码成功，等连接建立完成后再向支付后台发起支付请求，等待支付应答(小绿盒耗时5秒，竞品耗时3秒)。
步骤4：收到后台返回的支付应答，展示支付结果。
关键点总结：
由图可知，整个网络交互过程都是基于HTTPS短连接。收款一笔的耗时项包括：DNS解析、TCP握手、TLS握手、业务数据传输和后台处理(微信支付+其它后台逻辑)。
可能耗时项：由4.1章节的说明可知，DNS解析、TCP握手和TLS握手三项是否影响收款速度，受扫码操作(即步骤2)的快慢以及网络速度影响，扫码越慢，网络越快，建立网络连接(包括DNS查询，TCP握手和TLS握手)有可能在步骤2中就全部完成了。
固定耗时项：业务数据传输和后台处理两项为固定耗时项。
注：单位为秒
方案选择的考虑点:
综合考虑后选择了3个具体方案：
机具在2G网络环境中的网络拓扑：
一般情况下，机具引起空闲连接失效的外部因素有2个：
实际测试得知，移动2G网络出口NAT超时时间为5分钟(Android微信智能心跳方案中也有相关说明一文也有说明)，支付后台http服务的keepalive_timeout配置也为5分钟，因此空闲连接保活时间间隔小于5分钟即可。
主要考虑三方面：
综合来看，发送一个HTTP HEAD请求是一个很好的选择。
精减前：
三个精减手段：
精减后：
精减效果：
优化后预计支付总耗时=5秒-1.59秒=3.41秒。未能达成收款耗时不超过3秒的目标，还需要增加另外优化措施。
在2G网络环境下，每间隔0.5秒进行一次完整的支付交互(请求BODY为300字节)，发送请求与收到后台ACK的耗时在0.6秒左右：
如果间隔时间1秒以上，发送请求与收到后台ACK的耗时在1.1秒左右：
网络交互时序：
在BODY为300节字情况下，分别对不同时间间隔做了相同实验，结合实验数据分析得知，如果bc之间的时间间隔为0.5秒，则cd之间的耗时为0.6秒左右；如果bc之间的时间间隔超过0.5秒，则cd之间的耗时为1.1秒左右。
简化后的实验模型:
分别实验了不同BODY大小情况下的耗时情况，均有同样的耗时差别现象。
现象总结：cd之间的耗时受ac之间的时间间隔影响，ac间隔不大于0.5秒，比ac间隔大于0.5秒，cd耗时要少0.5秒左右。
综合上述实验结果并参考业界技术方案(用于上行连接TBF的提早建立的方法)可知，GPRS链路如果超过0.5秒没有上行数据，信道将被基站回收，而基站重新分配信道需要耗时0.5秒左右。
机具扫码状态时(即4.2章节交互流程中的步骤2)，以0.5秒间隔不断发送上行数据包，进行GPRS链路的预建立与保持(预热)，机具扫码完成后停止发送预连接数据包，接下来的支付请求传输则可预期减少0.5秒的网络耗时。
主要考虑两方面：
根据HTTP 1.1标准可知，客户端发送CRLF给服务端，服务端会忽略收到的CRLF，完全符合要求。
HTTP服务器收到第一个CRLF后，在client_header_timeout(默认配置为60秒)时间内未收到完整HTTP请求，会主动断开连接。因此，第一个CRLF发送一段时间后(如50秒)，需要发送一次完整的HTTP请求，从第4.5章节可知，发送一个HTTP HEAD请求是一个最好的选择。
对比优化前的时序图，这个时序图中的变化有3点：
注：单位为秒
表格内容说明：
参考文章
京公网安备 11010802035086号