[[326682]]

作者：suchengliu，騰訊 TEG 后臺開發工程師

小綠盒在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 和市場主流解決方案對比

 

注：單位為秒

4.3 可能的方案

 

4.4 方案選擇

方案選擇的考慮點:

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

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

 

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 優化預期效果

 

優化后預計支付總耗時=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 優化方案收益說明

 

5.4 優化后和市場主流解決方案對比

 

注：單位為秒

表格內容說明：

• 已達成不超過3秒的目標。
• 由于不需要重新建立連接，支付耗時相比競品更穩定。

6.總結

• 2G實驗室環境達平均耗時不超過3秒，達成目標。
• 收款耗時不受掃碼快慢影響，可保證穩定可控的支付耗時預期。
• 正式商家使用平均耗時4秒以內，整體表現達到業界領先水平，符合商家要求。