技术揭秘：微信付款码是如何完成付款并优化速度的？

微信收款机具在慢速网络中快速收款的技术揭秘，小绿盒在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 和市场主流解决方案对比

产品方案说明DNS解析TCP握手TLS握手业务数据传输+后台处理总耗时竞品短连接+二进制协议0(预埋ip)0.6033.6小绿盒短连接+HTTPS0.60.61.24.46.8

注：单位为秒

4.3 可能的方案

耗时项可能优化方案优点缺点预期收益DNS解析长连接消除DNS查询的耗时机具需要增加长连接处理逻辑降低耗时0.6秒(1RTT)机具缓存IP消除DNS查询的耗时增加缓存IP逻辑降低耗时0.6秒(1RTT)TCP握手长连接消除TCP握手的耗时机具需要增加长连接处理逻辑降低耗时0.6秒(1RTT)UDP消除TCP握手的耗时1.可靠传输，拥塞控制等 2.需要一套完整安全方案：加密和认证，密钥安全等 3.机具程序和后台程序改动量大 4.不是所有的网络环境能使用UDP降低耗时<=0.6秒(1RTT能完成支付则为0.6秒)TLS握手长连接1.消除TLS握手的耗时 2.安全：业界标准机具需要增加长连接处理逻辑降低耗时1.2秒(2RTT)自主加密协议消除TLS握手的耗时1.需要一套完整安全方案：加密和认证，密钥安全等 2.机具程序和后台程序改动量大降低耗时1.2秒(2RTT)业务数据传输精减业务数据改动量小业务协议变化降低耗时和精减字节数有关,1秒/KB(GPRS Wiki)使用二进制协议能最大程度精减机具程序和后台程序改动量大降低耗时和精减字节数有关,1秒/KB后台访问微信支付长连接消除DNS查询+TCP握手+TLS握手的耗时增加长连接维护逻辑降低耗时0.51秒(后台内部建立TLS连接耗时约0.17秒，一共建立3次)签名本地化签名无网络交互业务层面可能不支持降低耗时0.6秒(一次签名，一次验签)

4.4 方案选择

方案选择的考虑点:

• 支付安全性
  
• 支付耗时减少程度
  
• 改动成本
  

综合考虑后选择了3个具体方案：

方案优化耗时项选择原因预期收益机具使用HTTPS长连接访问收单平台DNS解析 TCP握手 TLS握手1.安全性无变化 2.预期耗时优化收益高 3.改动成本小1.支付耗时0.6秒：扫码完成时，TLS还未建立完成，5秒中有0.6秒是建立TLS连接的耗时 2.可保证稳定可控的支付耗时预期(不受扫码快慢影响)后台使用HTTPS访问微信支付后台访问微信支付1.安全性无变化 2.预期耗时优化收益高 3.改动成本小 4.业务层面签名无法本地化1.支付耗时减少0.51秒：建立TLS连接耗时0.17秒，需要建立3次精减业务数据包业务数据传输1.业务数据占HTTP包的80%以上,预期耗时优化收益高 2.改动成本小1.支付耗时减少0.48秒：请求数据包精减470B，上行约1KB/s；应答精减100B，下行约10KB/s

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 优化预期效果

优化项预期减少耗时(秒)耗时计算说明机具使用HTTPS长连接0.65秒中有0.6秒是用于TLS握手后台使用HTTPS访问微信支付0.51建立1次TLS连接耗时0.17秒，一共建立3次精减业务数据包0.48上行减少0.47秒，下行减少0.01秒合计1.59

优化后预计支付总耗时=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点：