本文主要是介绍微信收款机具在慢速网络中快速收款的技术揭秘,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
作者:suchengliu,腾讯 TEG 后台开发工程师
小绿盒在2G网络环境下收款速度较慢,影响商户体验,我们通过网络连接优化、数据传输优化和后台逻辑优化等一系列措施,将收款耗时降低近一半,达到了业界领先水平,改善了商户体验。
1. 背景说明
1.1 产品简介
微信收款商业版为了覆盖更多收款场景,推出小绿盒收款机具。
1.2 我们(收单平台)做了什么
发挥收单平台专业聚合收单能力,为小绿盒提供丰富稳定的收单功能。
提供专业的机具接入方案(支付SDK等),确保机具厂商高效高质量完成接入。
2.问题
小绿盒在2G网络下收款速度较慢(因为小绿盒收款是窄带场景,且4G模块成本是2G的2倍以上,所以小绿盒没有用4G)。
实验室情况:在2G实验室网络环境下,小绿盒收款一笔平均耗时需要5秒,而市场主流的解决方案只需3秒。
真实商家反馈:小绿盒收款一笔耗时基本在5秒以上,有时达10秒。收款速度慢,影响商户使用。
3.目标
2G实验室网络环境下,收款一笔耗时不能超过3秒。
实际商家收款耗时表现达到业界领先水平。
4.优化方案
4.1 产品交互说明
收款一笔的交互过程分4步:
步骤1:在键盘上输入收款金额。
步骤2:按下确认键后进入扫码状态,在此过程中机具开始预建立网络连接(竞品做法一致),涉及DNS查询,TCP握手和TLS握手。
步骤3:扫码成功,等连接建立完成后再向支付后台发起支付请求,等待支付应答(小绿盒耗时5秒,竞品耗时3秒)。
步骤4:收到后台返回的支付应答,展示支付结果。
关键点总结:
扫码状态(步骤2)期间的预建网络连接,是收款机具业界普遍做法。
支付耗时是指:扫码成功到收到支付应答之间的耗时(步骤3),受扫码快慢的影响,中间可能包括建立连接的部分耗时。
4.2 现状态分析
4.2.1 收款网络交互时序
由图可知,整个网络交互过程都是基于HTTPS短连接。收款一笔的耗时项包括:DNS解析、TCP握手、TLS握手、业务数据传输和后台处理(微信支付+其它后台逻辑)。
可能耗时项:由4.1章节的说明可知,DNS解析、TCP握手和TLS握手三项是否影响收款速度,受扫码操作(即步骤2)的快慢以及网络速度影响,扫码越慢,网络越快,建立网络连接(包括DNS查询,TCP握手和TLS握手)有可能在步骤2中就全部完成了。
固定耗时项:业务数据传输和后台处理两项为固定耗时项。
4.2.2 耗时分布情况
4.2.3 和市场主流解决方案对比
注:单位为秒
4.3 可能的方案
4.4 方案选择
方案选择的考虑点:
支付安全性
支付耗时减少程度
改动成本
综合考虑后选择了3个具体方案:
4.5 机具HTTPS长连接
4.5.1 如何选择心跳时间间隔
机具在2G网络环境中的网络拓扑:
一般情况下,机具引起空闲连接失效的外部因素有2个:
移动网络出口NAT空闲连接超时
支付后台http服务器的keepalive超时
实际测试得知,移动2G网络出口NAT超时时间为5分钟(Android微信智能心跳方案中也有相关说明一文也有说明),支付后台http服务的keepalive_timeout配置也为5分钟,因此空闲连接保活时间间隔小于5分钟即可。
4.5.2 如何选择心跳包内容
主要考虑三方面:
触发HTTP服务器的空闲连接计时器重新计时,因此需要一个完整HTTP请求
2G网络带宽小,流量资费比较贵,因此应该尽量发送小数据包
最好不要触发后台业务逻辑
综合来看,发送一个HTTP HEAD请求是一个很好的选择。
4.6 精减业务数据包
精减前:
三个精减手段:
去除可选字段
多层嵌套改为平铺
字段名精减
精减后:
精减效果:
请求包精减470B,预期减少耗时 = 0.47KB / 1KB/s = 0.47s
应答包精减100B,预期减少耗时 = 0.1KB / 10KB/s = 0.01s
4.7 优化预期效果
优化后预计支付总耗时=5秒-1.59秒=3.41秒。未能达成收款耗时不超过3秒的目标,还需要增加另外优化措施。
4.8 实验数据分析
在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秒左右。
4.9 GPRS上行预热
综合上述实验结果并参考业界技术方案(用于上行连接TBF的提早建立的方法)可知,GPRS链路如果超过0.5秒没有上行数据,信道将被基站回收,而基站重新分配信道需要耗时0.5秒左右。
4.9.1 如何应用这个实验结果
机具扫码状态时(即4.2章节交互流程中的步骤2),以0.5秒间隔不断发送上行数据包,进行GPRS链路的预建立与保持(预热),机具扫码完成后停止发送预连接数据包,接下来的支付请求传输则可预期减少0.5秒的网络耗时。
4.9.2 如何选择预热上行数据包内容
主要考虑两方面:
流量消耗少
不触发后台处理逻辑
根据HTTP 1.1标准可知,客户端发送CRLF给服务端,服务端会忽略收到的CRLF,完全符合要求。
4.9.3 服务端主动断开连接
HTTP服务器收到第一个CRLF后,在client_header_timeout(默认配置为60秒)时间内未收到完整HTTP请求,会主动断开连接。因此,第一个CRLF发送一段时间后(如50秒),需要发送一次完整的HTTP请求,从第4.5章节可知,发送一个HTTP HEAD请求是一个最好的选择。
5. 优化结果
5.1 优化后收款网络交互时序
对比优化前的时序图,这个时序图中的变化有3点:
小绿盒收款时不需要重新建立TLS连接。
小绿盒在等待扫码时需要不断发送上行预热数据包。
收单后台使用HTTPS长连接访问第三方支付平台。
5.2 优化前后耗时分布对比
5.3 优化方案收益说明
5.4 优化后和市场主流解决方案对比
注:单位为秒
表格内容说明:
已达成不超过3秒的目标。
由于不需要重新建立连接,支付耗时相比竞品更稳定。
6.总结
2G实验室环境达平均耗时不超过3秒,达成目标。
收款耗时不受扫码快慢影响,可保证稳定可控的支付耗时预期。
正式商家使用平均耗时4秒以内,整体表现达到业界领先水平,符合商家要求。
参考文章
GPRS Wiki
Android微信智能心跳方案
用于上行链路TBF的提早建立的方法
这篇关于微信收款机具在慢速网络中快速收款的技术揭秘的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!