微信付款码是如何完成付款的( 二 ) 作者：suchengliu

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秒的网络耗时。