作者：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秒以內，整體表現達到業界領先水平，符合商家要求。
參考文章
- GPRS Wiki
- Android微信智能心跳方案
- 用于上行鏈路TBF的提早建立的方法
