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

优化后预计支付总耗时=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 优化方案收益说明

文章插图
方案优化耗时项预期收益实际收益机具使用HTTPS长连接DNS解析 TCP握手 TLS握手1. 支付耗时0.6秒：扫码完成时， TLS还未建立完成， 5秒中有0.6秒是建立TLS连接的耗时 2.可保证稳定可控的支付耗时预期1.减少0.6秒(原TLS握手耗时1.2秒中的0.6秒) 2.支付耗时不再受扫码快慢的影响，保证了稳定可控的支付耗时预期后台使用HTTPS访问微信支付后台访问微信支付1.支付耗时减少0.51秒1.支付耗时减少0.49秒精减业务数据包业务数据传输1.支付耗时减少0.48秒1.支付耗时减少0.43秒(GPRS上下行速度并不是固定的1KB/s和10KB/s)支付上行链路预热业务数据传输1.支付耗时减少0.5秒1.支付耗时减少0.5秒