微信收款机慢网快速收款的秘密数据传输优化、后台逻辑优化等一系列措施，收款时间缩短近一半，达到行业领先水平，提升商户体验.一、背景描述1.1产品介绍为覆盖更多收款场景，微信支付收款业务版推出了小绿盒收款机。1.2我们（收单平台）做了什么充分发挥收单平台的专业聚合收单能力，提供收单功能丰富稳定的小绿盒。提供专业的设备接入解决方案（支付SDK等），确保设备厂商高效率、高质量完成接入。2.问题是2G网络下小绿盒收款速度慢（因为小绿盒收款是窄带场景，4G模块成本是2G的2倍以上，所以小绿框不使用4G）。实验室情况：在2G实验室网络环境下，小绿盒收到付款平均需要5秒，而市场主流方案只需3秒。真实商家反馈：小绿框收款需要5秒以上，有时长达10秒。收款速度慢，影响商家使用。3.目标在2G实验室的网络环境下，收款时间不超过3秒。商户收款实际耗时性能达到行业领先水平。4.优化方案4.1产品交互说明收款交互过程分为4个步骤：第一步：在键盘上输入付款金额。第二步：按确认键进入扫码状态。在此过程中，机器开始预先建立网络连接（与竞品相同），涉及DNS查询、TCP握手和TLS握手。第三步：扫码成功，建立连接后向支付后台发起支付请求，等待支付响应（绿色小框需要5秒，竞品需要3秒）。第四步：接收后台返回的支付响应，显示支付结果。要点总结：扫码状态下（步骤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.5设备HTTPS长连接4.5.1心跳时间间隔如何选择设备的网络拓扑图2G网络环境：一般造成设备空闲连接失败的外部因素有两种：移动网络出口NAT空闲连接超时实际测试支付后台http服务器的keepalive超时时间，手机2G网络出口NAT为5分钟（安卓微信智能心跳方案也有相关说明），支付后台http服务的keepalive_timeout配置也是5分钟，所以空闲连接保活间隔要小于5分钟。4.5.2如何选择心跳包的内容主要考虑三个方面：HTTP服务器的空闲连接定时器被触发重定时，所以需要一个完整的HTTP请求。2G网络带宽小，流量费用比较贵，所以尽量不要发送小数据包。触发后台业务逻辑一般来说，发送一个HTTPHEAD请求是一个不错的选择。4.6业务数据包缩减缩减前：三种缩减方式：去除optional字段多层嵌套，改成平铺字段名缩减后：缩减效果：请求包减少470B，有望减少耗时=0.47KB/1KB/s=0.47s响应包减少100B，预计减少时间=0.1KB/10KB/s=0.01s4.7优化后的预期效果预计优化后支付总耗时=5秒-1.59秒=3.41秒。收款时间不超过3秒的目标没有实现，需要增加额外的优化措施。4.8实验数据分析在2G网络环境下，每0.5秒进行一次完整的支付交互（请求BODY为300字节），发送请求到收到后台ACK耗时约0.6秒：如果间隔为1秒以上，发送请求到后台接收大约需要1.1秒ACK：网络交互时序：在BODY为300字节的情况下，针对不同的时间间隔做了同样的实验，结合实验数据分析，可知如果bc的时间间隔是0.5秒的话，cd之间的时间大概是0.6秒；如果bc之间的时间间隔大于0.5秒，则cd之间的时间约为1.1秒。简化实验模型：分别测试不同BODY尺寸的耗时情况，发现相同的耗时差异现象。现象总结：cd之间的耗时受ac之间的时间间隔影响，ac间隔不大于0.5秒，cd时间比ac间隔大于0.5秒少0.5秒左右。4.9GPRS上行预热根据以上实验结果，参考业界技术方案（提前建立上行连接TBF的方法）可以看出，如果GPRS链路超过0.5秒没有上行数据，信道会被基站回收，基站重新分配信道大约需要0.5秒。4.9.1如何应用实验结果当设备处于扫码状态时（即4.2章节交互过程中的第2步），每隔0.5秒连续发送上行数据包，预先建立和保持（预热）GPRS链接。扫码后停止发送预连接数据包，下一次支付请求传输可望减少0.5秒网络耗时。4.9.2如何选择预热上行数据包的内容主要考虑两个方面：流量消耗少，无后台处理逻辑根据HTTP1.1标准，客户端向服务器发送CRLF，服务器会忽略接收到的CRLF，完全符合要求。4.9.3服务器主动断开连接。HTTP服务器收到第一个CRLF后，如果在client_header_timeout（默认配置为60秒）内没有收到完整的HTTP请求，会主动断开连接。因此，第一个CRLF发送完一段时间后（比如50秒），需要发送一个完整的HTTP请求。从4.5节可以看出发送HTTPHEAD请求是最好的选择。5.优化结果5.1与优化前的时序图相比，优化后的收款网络交互时序有3个变化：小绿框收款时不需要重新建立TLS连接。小绿框在等待扫码的过程中需要不断发送上行预热数据包。收单后台使用HTTPS长连接访问第三方支付平台。5.2优化前后耗时分布对比5.3优化方案收益说明5.4优化后与市场主流方案对比注：单位为秒表内容说明：已达到不超过3秒的目标。由于无需重新建立连接，支付时间比竞品更稳定。6.小结2G实验室环境平均用时不超过3秒，达到目标。收款耗时不受扫码速度影响，可确保收款耗时预期稳定可控。官方商户平均使用时间不到4秒，整体性能达到行业领先水平，满足商户需求。
