作者：suchengliu，騰訊 TEG 后臺(tái)開發(fā)工程師
小綠盒在2G網(wǎng)絡(luò)環(huán)境下收款速度較慢，影響商戶體驗(yàn)，我們通過網(wǎng)絡(luò)連接優(yōu)化、數(shù)據(jù)傳輸優(yōu)化和后臺(tái)邏輯優(yōu)化等一系列措施，將收款耗時(shí)降低近一半，達(dá)到了業(yè)界領(lǐng)先水平，改善了商戶體驗(yàn)。
微信收款商業(yè)版為了覆蓋更多收款場(chǎng)景，推出小綠盒收款機(jī)具。
小綠盒在2G網(wǎng)絡(luò)下收款速度較慢(因?yàn)樾【G盒收款是窄帶場(chǎng)景，且4G模塊成本是2G的2倍以上，所以小綠盒沒有用4G)。
實(shí)驗(yàn)室情況：在2G實(shí)驗(yàn)室網(wǎng)絡(luò)環(huán)境下，小綠盒收款一筆平均耗時(shí)需要5秒，而市場(chǎng)主流的解決方案只需3秒。
真實(shí)商家反饋：小綠盒收款一筆耗時(shí)基本在5秒以上，有時(shí)達(dá)10秒。收款速度慢，影響商戶使用。
收款一筆的交互過程分4步：
步驟1：在鍵盤上輸入收款金額。
步驟2：按下確認(rèn)鍵后進(jìn)入掃碼狀態(tài)，在此過程中機(jī)具開始預(yù)建立網(wǎng)絡(luò)連接(競(jìng)品做法一致)，涉及DNS查詢，TCP握手和TLS握手。
步驟3：掃碼成功，等連接建立完成后再向支付后臺(tái)發(fā)起支付請(qǐng)求，等待支付應(yīng)答(小綠盒耗時(shí)5秒，競(jìng)品耗時(shí)3秒)。
步驟4：收到后臺(tái)返回的支付應(yīng)答，展示支付結(jié)果。
關(guān)鍵點(diǎn)總結(jié)：
掃碼狀態(tài)(步驟2)期間的預(yù)建網(wǎng)絡(luò)連接，是收款機(jī)具業(yè)界普遍做法。
支付耗時(shí)是指：掃碼成功到收到支付應(yīng)答之間的耗時(shí)(步驟3)，受掃碼快慢的影響，中間可能包括建立連接的部分耗時(shí)。
由圖可知，整個(gè)網(wǎng)絡(luò)交互過程都是基于HTTPS短連接。收款一筆的耗時(shí)項(xiàng)包括：DNS解析、TCP握手、TLS握手、業(yè)務(wù)數(shù)據(jù)傳輸和后臺(tái)處理(微信支付+其它后臺(tái)邏輯)。
可能耗時(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ù)傳輸和后臺(tái)處理兩項(xiàng)為固定耗時(shí)項(xiàng)。
注：?jiǎn)挝粸槊?/p>
方案選擇的考慮點(diǎn):
支付安全性
支付耗時(shí)減少程度
改動(dòng)成本
綜合考慮后選擇了3個(gè)具體方案：
機(jī)具在2G網(wǎng)絡(luò)環(huán)境中的網(wǎng)絡(luò)拓?fù)洌?/p>
一般情況下，機(jī)具引起空閑連接失效的外部因素有2個(gè)：
移動(dòng)網(wǎng)絡(luò)出口NAT空閑連接超時(shí)
支付后臺(tái)http服務(wù)器的keepalive超時(shí)
實(shí)際測(cè)試得知，移動(dòng)2G網(wǎng)絡(luò)出口NAT超時(shí)時(shí)間為5分鐘(Android微信智能心跳方案中也有相關(guān)說明一文也有說明)，支付后臺(tái)http服務(wù)的keepalive_timeout配置也為5分鐘，因此空閑連接?；顣r(shí)間間隔小于5分鐘即可。
主要考慮三方面：
觸發(fā)HTTP服務(wù)器的空閑連接計(jì)時(shí)器重新計(jì)時(shí)，因此需要一個(gè)完整HTTP請(qǐng)求
2G網(wǎng)絡(luò)帶寬小，流量資費(fèi)比較貴，因此應(yīng)該盡量發(fā)送小數(shù)據(jù)包
最好不要觸發(fā)后臺(tái)業(yè)務(wù)邏輯
綜合來看，發(fā)送一個(gè)HTTP HEAD請(qǐng)求是一個(gè)很好的選擇。
精減前：
三個(gè)精減手段：
去除可選字段
多層嵌套改為平鋪
字段名精減
精減后：
精減效果：
請(qǐng)求包精減470B，預(yù)期減少耗時(shí) = 0.47KB / 1KB/s = 0.47s
應(yīng)答包精減100B，預(yù)期減少耗時(shí) = 0.1KB / 10KB/s = 0.01s
優(yōu)化后預(yù)計(jì)支付總耗時(shí)=5秒-1.59秒=3.41秒。未能達(dá)成收款耗時(shí)不超過3秒的目標(biāo)，還需要增加另外優(yōu)化措施。
在2G網(wǎng)絡(luò)環(huán)境下，每間隔0.5秒進(jìn)行一次完整的支付交互(請(qǐng)求BODY為300字節(jié))，發(fā)送請(qǐng)求與收到后臺(tái)ACK的耗時(shí)在0.6秒左右：
如果間隔時(shí)間1秒以上，發(fā)送請(qǐng)求與收到后臺(tái)ACK的耗時(shí)在1.1秒左右：
網(wǎng)絡(luò)交互時(shí)序：
在BODY為300節(jié)字情況下，分別對(duì)不同時(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秒左右。
簡(jiǎn)化后的實(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秒左右。
綜合上述實(shí)驗(yàn)結(jié)果并參考業(yè)界技術(shù)方案(用于上行連接TBF的提早建立的方法)可知，GPRS鏈路如果超過0.5秒沒有上行數(shù)據(jù)，信道將被基站回收，而基站重新分配信道需要耗時(shí)0.5秒左右。
機(jī)具掃碼狀態(tài)時(shí)(即4.2章節(jié)交互流程中的步驟2)，以0.5秒間隔不斷發(fā)送上行數(shù)據(jù)包，進(jìn)行GPRS鏈路的預(yù)建立與保持(預(yù)熱)，機(jī)具掃碼完成后停止發(fā)送預(yù)連接數(shù)據(jù)包，接下來的支付請(qǐng)求傳輸則可預(yù)期減少0.5秒的網(wǎng)絡(luò)耗時(shí)。
主要考慮兩方面：
流量消耗少
不觸發(fā)后臺(tái)處理邏輯
根據(jù)HTTP1.1標(biāo)準(zhǔn)可知，客戶端發(fā)送CRLF給服務(wù)端，服務(wù)端會(huì)忽略收到的CRLF，完全符合要求。
HTTP服務(wù)器收到第一個(gè)CRLF后，在client_header_timeout(默認(rèn)配置為60秒)時(shí)間內(nèi)未收到完整HTTP請(qǐng)求，會(huì)主動(dòng)斷開連接。因此，第一個(gè)CRLF發(fā)送一段時(shí)間后(如50秒)，需要發(fā)送一次完整的HTTP請(qǐng)求，從第4.5章節(jié)可知，發(fā)送一個(gè)HTTPHEAD請(qǐng)求是一個(gè)最好的選擇。
對(duì)比優(yōu)化前的時(shí)序圖，這個(gè)時(shí)序圖中的變化有3點(diǎn)：
小綠盒收款時(shí)不需要重新建立TLS連接。
小綠盒在等待掃碼時(shí)需要不斷發(fā)送上行預(yù)熱數(shù)據(jù)包。
收單后臺(tái)使用HTTPS長(zhǎng)連接訪問第三方支付平臺(tái)。
注：?jiǎn)挝粸槊?/p>
表格內(nèi)容說明：
參考文章
聯(lián)系客服
