小綠盒在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秒以內，整體表現達到業界領先水平，符合商家要求。