[[326682]]

作者：suchengliu，騰訊 TEG 后臺開發(fā)工程師

小綠盒在2G網(wǎng)絡(luò)環(huán)境下收款速度較慢，影響商戶體驗(yàn)，我們通過網(wǎng)絡(luò)連接優(yōu)化、數(shù)據(jù)傳輸優(yōu)化和后臺邏輯優(yōu)化等一系列措施，將收款耗時(shí)降低近一半，達(dá)到了業(yè)界領(lǐng)先水平，改善了商戶體驗(yàn)。

1. 背景說明

1.1 產(chǎn)品簡介

微信收款商業(yè)版為了覆蓋更多收款場景，推出小綠盒收款機(jī)具。

1.2 我們(收單平臺)做了什么

• 發(fā)揮收單平臺專業(yè)聚合收單能力，為小綠盒提供豐富穩(wěn)定的收單功能。
• 提供專業(yè)的機(jī)具接入方案(支付SDK等)，確保機(jī)具廠商高效高質(zhì)量完成接入。

2.問題

小綠盒在2G網(wǎng)絡(luò)下收款速度較慢(因?yàn)樾【G盒收款是窄帶場景，且4G模塊成本是2G的2倍以上，所以小綠盒沒有用4G)。

實(shí)驗(yàn)室情況：在2G實(shí)驗(yàn)室網(wǎng)絡(luò)環(huán)境下，小綠盒收款一筆平均耗時(shí)需要5秒，而市場主流的解決方案只需3秒。

真實(shí)商家反饋：小綠盒收款一筆耗時(shí)基本在5秒以上，有時(shí)達(dá)10秒。收款速度慢，影響商戶使用。

3.目標(biāo)

• 2G實(shí)驗(yàn)室網(wǎng)絡(luò)環(huán)境下，收款一筆耗時(shí)不能超過3秒。
• 實(shí)際商家收款耗時(shí)表現(xiàn)達(dá)到業(yè)界領(lǐng)先水平。

4.優(yōu)化方案

4.1 產(chǎn)品交互說明

收款一筆的交互過程分4步：

步驟1：在鍵盤上輸入收款金額。

步驟2：按下確認(rèn)鍵后進(jìn)入掃碼狀態(tài)，在此過程中機(jī)具開始預(yù)建立網(wǎng)絡(luò)連接(競品做法一致)，涉及DNS查詢，TCP握手和TLS握手。

步驟3：掃碼成功，等連接建立完成后再向支付后臺發(fā)起支付請求，等待支付應(yīng)答(小綠盒耗時(shí)5秒，競品耗時(shí)3秒)。

步驟4：收到后臺返回的支付應(yīng)答，展示支付結(jié)果。

關(guān)鍵點(diǎn)總結(jié)：

• 掃碼狀態(tài)(步驟2)期間的預(yù)建網(wǎng)絡(luò)連接，是收款機(jī)具業(yè)界普遍做法。
• 支付耗時(shí)是指：掃碼成功到收到支付應(yīng)答之間的耗時(shí)(步驟3)，受掃碼快慢的影響，中間可能包括建立連接的部分耗時(shí)。

4.2 現(xiàn)狀態(tài)分析

4.2.1 收款網(wǎng)絡(luò)交互時(shí)序

由圖可知，整個網(wǎng)絡(luò)交互過程都是基于HTTPS短連接。收款一筆的耗時(shí)項(xiàng)包括：DNS解析、TCP握手、TLS握手、業(yè)務(wù)數(shù)據(jù)傳輸和后臺處理(微信支付+其它后臺邏輯)。

可能耗時(shí)項(xiàng)：由4.1章節(jié)的說明可知，DNS解析、TCP握手和TLS握手三項(xiàng)是否影響收款速度，受掃碼操作(即步驟2)的快慢以及網(wǎng)絡(luò)速度影響，掃碼越慢，網(wǎng)絡(luò)越快，建立網(wǎng)絡(luò)連接(包括DNS查詢，TCP握手和TLS握手)有可能在步驟2中就全部完成了。

固定耗時(shí)項(xiàng)：業(yè)務(wù)數(shù)據(jù)傳輸和后臺處理兩項(xiàng)為固定耗時(shí)項(xiàng)。

4.2.2 耗時(shí)分布情況

4.2.3 和市場主流解決方案對比

注：單位為秒

4.3 可能的方案

4.4 方案選擇

方案選擇的考慮點(diǎn):

• 支付安全性
• 支付耗時(shí)減少程度
• 改動成本

綜合考慮后選擇了3個具體方案：

4.5 機(jī)具HTTPS長連接

4.5.1 如何選擇心跳時(shí)間間隔

機(jī)具在2G網(wǎng)絡(luò)環(huán)境中的網(wǎng)絡(luò)拓?fù)洌?/p>

一般情況下，機(jī)具引起空閑連接失效的外部因素有2個：

• 移動網(wǎng)絡(luò)出口NAT空閑連接超時(shí)
• 支付后臺http服務(wù)器的keepalive超時(shí)

實(shí)際測試得知，移動2G網(wǎng)絡(luò)出口NAT超時(shí)時(shí)間為5分鐘(Android微信智能心跳方案中也有相關(guān)說明一文也有說明)，支付后臺http服務(wù)的keepalive_timeout配置也為5分鐘，因此空閑連接?；顣r(shí)間間隔小于5分鐘即可。

4.5.2 如何選擇心跳包內(nèi)容

主要考慮三方面：

• 觸發(fā)HTTP服務(wù)器的空閑連接計(jì)時(shí)器重新計(jì)時(shí)，因此需要一個完整HTTP請求
• 2G網(wǎng)絡(luò)帶寬小，流量資費(fèi)比較貴，因此應(yīng)該盡量發(fā)送小數(shù)據(jù)包
• 最好不要觸發(fā)后臺業(yè)務(wù)邏輯

綜合來看，發(fā)送一個HTTP HEAD請求是一個很好的選擇。

4.6 精減業(yè)務(wù)數(shù)據(jù)包

精減前：

三個精減手段：

• 去除可選字段
• 多層嵌套改為平鋪
• 字段名精減

精減后：

精減效果：

• 請求包精減470B，預(yù)期減少耗時(shí) = 0.47KB / 1KB/s = 0.47s
• 應(yīng)答包精減100B，預(yù)期減少耗時(shí) = 0.1KB / 10KB/s = 0.01s

4.7 優(yōu)化預(yù)期效果

優(yōu)化后預(yù)計(jì)支付總耗時(shí)=5秒-1.59秒=3.41秒。未能達(dá)成收款耗時(shí)不超過3秒的目標(biāo)，還需要增加另外優(yōu)化措施。

4.8 實(shí)驗(yàn)數(shù)據(jù)分析

在2G網(wǎng)絡(luò)環(huán)境下，每間隔0.5秒進(jìn)行一次完整的支付交互(請求BODY為300字節(jié))，發(fā)送請求與收到后臺ACK的耗時(shí)在0.6秒左右：

如果間隔時(shí)間1秒以上，發(fā)送請求與收到后臺ACK的耗時(shí)在1.1秒左右：

網(wǎng)絡(luò)交互時(shí)序：

在BODY為300節(jié)字情況下，分別對不同時(shí)間間隔做了相同實(shí)驗(yàn)，結(jié)合實(shí)驗(yàn)數(shù)據(jù)分析得知，如果bc之間的時(shí)間間隔為0.5秒，則cd之間的耗時(shí)為0.6秒左右;如果bc之間的時(shí)間間隔超過0.5秒，則cd之間的耗時(shí)為1.1秒左右。

簡化后的實(shí)驗(yàn)?zāi)Ｐ?

分別實(shí)驗(yàn)了不同BODY大小情況下的耗時(shí)情況，均有同樣的耗時(shí)差別現(xiàn)象。

現(xiàn)象總結(jié)：cd之間的耗時(shí)受ac之間的時(shí)間間隔影響，ac間隔不大于0.5秒，比ac間隔大于0.5秒，cd耗時(shí)要少0.5秒左右。

4.9 GPRS上行預(yù)熱

綜合上述實(shí)驗(yàn)結(jié)果并參考業(yè)界技術(shù)方案(用于上行連接TBF的提早建立的方法)可知，GPRS鏈路如果超過0.5秒沒有上行數(shù)據(jù)，信道將被基站回收，而基站重新分配信道需要耗時(shí)0.5秒左右。

4.9.1 如何應(yīng)用這個實(shí)驗(yàn)結(jié)果

機(jī)具掃碼狀態(tài)時(shí)(即4.2章節(jié)交互流程中的步驟2)，以0.5秒間隔不斷發(fā)送上行數(shù)據(jù)包，進(jìn)行GPRS鏈路的預(yù)建立與保持(預(yù)熱)，機(jī)具掃碼完成后停止發(fā)送預(yù)連接數(shù)據(jù)包，接下來的支付請求傳輸則可預(yù)期減少0.5秒的網(wǎng)絡(luò)耗時(shí)。

4.9.2 如何選擇預(yù)熱上行數(shù)據(jù)包內(nèi)容

主要考慮兩方面：

• 流量消耗少
• 不觸發(fā)后臺處理邏輯

根據(jù)HTTP 1.1標(biāo)準(zhǔn)可知，客戶端發(fā)送CRLF給服務(wù)端，服務(wù)端會忽略收到的CRLF，完全符合要求。

4.9.3 服務(wù)端主動斷開連接

HTTP服務(wù)器收到第一個CRLF后，在client_header_timeout(默認(rèn)配置為60秒)時(shí)間內(nèi)未收到完整HTTP請求，會主動斷開連接。因此，第一個CRLF發(fā)送一段時(shí)間后(如50秒)，需要發(fā)送一次完整的HTTP請求，從第4.5章節(jié)可知，發(fā)送一個HTTP HEAD請求是一個最好的選擇。

5. 優(yōu)化結(jié)果

5.1 優(yōu)化后收款網(wǎng)絡(luò)交互時(shí)序

對比優(yōu)化前的時(shí)序圖，這個時(shí)序圖中的變化有3點(diǎn)：

• 小綠盒收款時(shí)不需要重新建立TLS連接。
• 小綠盒在等待掃碼時(shí)需要不斷發(fā)送上行預(yù)熱數(shù)據(jù)包。
• 收單后臺使用HTTPS長連接訪問第三方支付平臺。

5.2 優(yōu)化前后耗時(shí)分布對比

5.3 優(yōu)化方案收益說明

5.4 優(yōu)化后和市場主流解決方案對比

注：單位為秒

表格內(nèi)容說明：

• 已達(dá)成不超過3秒的目標(biāo)。
• 由于不需要重新建立連接，支付耗時(shí)相比競品更穩(wěn)定。

6.總結(jié)

• 2G實(shí)驗(yàn)室環(huán)境達(dá)平均耗時(shí)不超過3秒，達(dá)成目標(biāo)。
• 收款耗時(shí)不受掃碼快慢影響，可保證穩(wěn)定可控的支付耗時(shí)預(yù)期。
• 正式商家使用平均耗時(shí)4秒以內(nèi)，整體表現(xiàn)達(dá)到業(yè)界領(lǐng)先水平，符合商家要求。