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

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秒
5.4 优化后和市场主流解决方案对比

文章插图
产品方案说明DNS解析TCP握手TLS握手业务数据传输+后台处理总耗时竞品短连接+二进制协议0(预埋ip)0.6033.6小绿盒短连接+HTTPS00033
注：单位为秒
表格内容说明：

已达成不超过3秒的目标。
由于不需要重新建立连接，支付耗时相比竞品更稳定。

6.总结

2G实验室环境达平均耗时不超过3秒，达成目标。
收款耗时不受扫码快慢影响，可保证稳定可控的支付耗时预期。
正式商家使用平均耗时4秒以内，整体表现达到业界领先水平，符合商家要求。

参考文章

携程App网络性能优化实践
Android微信智能心跳方案
用于上行链路TBF的提早建立的方法

作者：suchengliu ，腾讯 TEG 后台开发工程师
出处: