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

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

1. 背景說明

1.1 產品簡介

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

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

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

2.問題

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

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

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

3.目標

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

4.優(yōu)化方案

4.1 產品交互說明

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

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

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

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

步驟4：收到后臺返回的支付應答，展示支付結果。

關鍵點總結：

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

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

4.2.1 收款網(wǎng)絡交互時序

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

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

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

4.2.2 耗時分布情況

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

注：單位為秒

4.3 可能的方案

4.4 方案選擇

方案選擇的考慮點:

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

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

4.5 機具HTTPS長連接

4.5.1 如何選擇心跳時間間隔

機具在2G網(wǎng)絡環(huán)境中的網(wǎng)絡拓撲：

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

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

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

4.5.2 如何選擇心跳包內容

主要考慮三方面：

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

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

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

精減前：

三個精減手段：

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

精減后：

精減效果：

• 請求包精減470B，預期減少耗時 = 0.47KB / 1KB/s = 0.47s
• 應答包精減100B，預期減少耗時 = 0.1KB / 10KB/s = 0.01s

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

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

4.8 實驗數(shù)據(jù)分析

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

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

網(wǎng)絡交互時序：

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

簡化后的實驗模型:

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

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

4.9 GPRS上行預熱

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

4.9.1 如何應用這個實驗結果

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

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

主要考慮兩方面：

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

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

4.9.3 服務端主動斷開連接

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

5. 優(yōu)化結果

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

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

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

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

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

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

注：單位為秒

表格內容說明：

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

6.總結

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

當前名稱：微信收款機具在慢速網(wǎng)絡中快速收款的技術揭秘
網(wǎng)站鏈接：http://uogjgqi.cn/article/codseeo.html