桓汗晶 北京中創(chuàng)信測信息技術(shù)有限公司監(jiān)測系統(tǒng)產(chǎn)品部產(chǎn)品經(jīng)理

編者按：隨著手機、平板電腦等智能終端以及互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，在短短幾年的時間里，國內(nèi)的移動支付市場持續(xù)保持爆發(fā)式的增長態(tài)勢，而支付成功率則是影響用戶感知的關(guān)鍵因素。本文分享了某市提升移動支付成功率的案例，依托專業(yè)的信令分析工具，通過對移動支付服務器、移動支付服務器端口、現(xiàn)場測試和用戶投訴信令等不同角度進行分析，最終定位并解決了問題，極大地提升了用戶感知?？晒┫嚓P(guān)技術(shù)人員參考。

1 引言

2015年4月，某市移動大量移動支付POS機出現(xiàn)支付失敗投訴，導致數(shù)據(jù)業(yè)務投訴激增，嚴重影響用戶感知。本文借助專業(yè)信令分析工具，對移動支付服務器、移動支付服務器端口、移動支付信令流程和測試情況進行綜合分析，定位問題并提交優(yōu)化，最終完成了本次移動支付專題優(yōu)化分析。

2 移動支付業(yè)務信令流程

通過信令分析平臺對移動支付業(yè)務信令標準流程進行抓取，以此來定位移動支付問題信令點。如圖1所示，針對關(guān)鍵信令點的描述如下：

（1）POS在開機后，使用GPRS網(wǎng)絡進行ATTACH附著，并使用APN為CMNET進行PDP激活。

（2）PDP激活后，POS機向移動支付服務器（211.141.88.164）發(fā)起ping測試，移動支付服務器進行ping響應。

（3）POS機與支付服務器進行TCP三握手連接，目標地址為211.141.88.164，端口號可選為8100或8200，具體使用與POS機設置有關(guān)。

圖1 移動POS支付信令全流程

（4）完成TCP三握手連接后，POS機使用標準TCP協(xié)議向支付服務器發(fā)起業(yè)務請求消息，使用push-ack進行傳輸，支付服務器回復ACK消息對其進行響應，POS收到支付服務器回復的ACK消息后，使用push-ack對其進行響應，完成支付過程。

（5）完成支付過程后，進行TCP拆鏈。

3 某市移動支付投訴分析

2015年4月底某市大量移動支付POS機出現(xiàn)支付失敗投訴，導致數(shù)據(jù)業(yè)務投訴激增。通過信令回放，并和移動支付標準信令流程進行對比發(fā)現(xiàn)，問題可定位為POS機與移動支付服務器進行TCP三握手的環(huán)節(jié)，由于TCP三握手失敗從而導致移動支付失敗。

對具體信令進行分析發(fā)現(xiàn)，移動支付POS機終端在附著和PDP激活成功之后，在與移動支付平臺服務器進行（IP地址為“211.141.88.164”）TCP三握手時失敗，其主要失敗端口為8100，失敗原因為POS機發(fā)起SYN請求后，一直未得到服務器的SYN-ACK響應，從而導致SYN在重發(fā)后超時失敗，導致POS機支付失敗。分別抓取POS支付失敗和成功的信令進行對比，具體如圖2、3所示。

對移動支付服務器全天24h時段TCP建立情況進行跟蹤（見圖4），可見，在業(yè)務閑時段TCP三握手成功率為90%以上；7點后，隨著POS支付業(yè)務量增加，TCP三握手成功率急劇下降為50%左右；在21點后，隨著業(yè)務量下降，其成功率又逐步回升至70%左右?？梢?，服務器整體TCP三握手成功率較低。

圖2 移動POS支付失敗信令流程

圖3 移動POS支付成功信令流程

通過以上分析，確認服務器（211.141.88.164）問題異常并導致用戶投訴，需要協(xié)調(diào)處理該服務器。2015年4月25日，對移動支付服務器和支付端口進行更換，對更換后TCP三握手成功率情況效果驗證如下（見圖5）。

從更換后的TCP三握手成功率來看，更換后通過服務器（211.141.88.164）的TCP三握手成功率明顯提升，忙時TCP三握手成功率由60%提升為80%左右，POS機刷卡成功率明顯改善，但整體成功率依然波動較大，仍需進行詳細分析。

4 移動支付質(zhì)量提升專題分析

4.1 移動支付服務器整體TCP指標分析

從前文分析發(fā)現(xiàn)，目前POS機刷卡的成功率雖有改善，但依然較低，需繼續(xù)進行深入分析。為深入定位TCP三握手成功率低的原因，統(tǒng)計2015年5月20、21日移動支付服務器（211.141.88.164）的TCP三握手趨勢，具體如圖6所示。

可見，隨著業(yè)務次數(shù)（SYN次數(shù)）的增加，TCP網(wǎng)絡側(cè)響應成功率出現(xiàn)急劇下降，由閑時的90%下降為60%左右，但無線側(cè)成功率基本保持穩(wěn)定，因此移動支付服務器TCP成功率與無線側(cè)關(guān)聯(lián)不大。同時，TCP網(wǎng)絡側(cè)成功率和SYN超時次數(shù)存在明顯相關(guān)性。當SYN超時次數(shù)增加時，網(wǎng)絡側(cè)成功率出現(xiàn)明顯下降。因此，需重點分析移動支付服務器在業(yè)務量增加時出現(xiàn)大量SYN超時是否與支付服務器負荷或相關(guān)內(nèi)部參數(shù)設置相關(guān)。

圖4 移動POS支付平臺服務器TCP三握手成功率趨勢

圖5 移動POS支付平臺服務器更換前后TCP三握手成功率趨勢

圖6 移動POS支付平臺服務器TCP三握手成功率趨勢

4.2 移動支付服務器不同端口TCP指標分析

統(tǒng)計使用移動支付服務器（211.141.88.164）的不同支付端口時各個支付端口的TCP指標情況，具體如表1所示?？梢?，當前移動支付服務器主要使用3個端口進行業(yè)務，分別為8001、8100和8200，但這3個端口的網(wǎng)絡側(cè)成功率相差較大，而無線側(cè)成功率基本一致。

通過和POS廠家溝通得知，POS機可以對相關(guān)端口進行設置，其中8001端口為管理端口，可進行相關(guān)簽到、管理操作，而8100和8200為POS支付端口，在進行支付交易時，需采用這兩個端口進行。

從網(wǎng)絡側(cè)成功率分析來看，8100端口網(wǎng)絡側(cè)成功率保持在90%以上，但8001和8200端口成功率僅為60%左右；從3個端口的SYN嘗試次數(shù)來看，某市移動POS機業(yè)務主要集中在8200和8001端口，8100端口業(yè)務量較?。粡年P(guān)聯(lián)SYN超時次數(shù)來看，8200和8001的SYN超時次數(shù)明顯高于8100端口，從而拉低了整體支付服務器的TCP網(wǎng)絡側(cè)成功率。

表1 支付服務器不同端口成功率分析

統(tǒng)計連續(xù)兩天支付服務器不同端口的小時級TCP指標，具體如圖7所示?？梢?，隨著業(yè)務量的增加，8200和8001端口的SYN超時次數(shù)明顯增加，從而引起兩個端口的網(wǎng)絡側(cè)成功率急劇下降；而8100端口隨著業(yè)務量的增加，SYN超時次數(shù)未見明顯增加。

因此，從對支付服務器的不同端口分析來看，8200和8001端口明顯存在異常，需對服務器的端口設置和相關(guān)參數(shù)進行排查。

4.3 移動支付服務器現(xiàn)場測試分析

協(xié)調(diào)相關(guān)人員對某市移動支付POS機進行了相關(guān)測試，通過在GB口對業(yè)務進行信令抓取，現(xiàn)場人員反饋某時間段內(nèi)出現(xiàn)刷卡時延較大，交易完成較慢的情況。通過wireshark對異常時段的測試信令抓包，具體分析如圖8所示?？梢?，當現(xiàn)場測試人員反饋刷卡較慢時，從GB口信令上表現(xiàn)為服務器始終未對SYN包進行響應，導致SYN包不斷進行重發(fā)，從POS發(fā)起SYN請求開始，由于一直未得到服務器端響應，導致SYN重發(fā)6次，整體業(yè)務時延為60s左右。與正常POS支付業(yè)務流程相比，正常支付流程時延僅為10s左右。由此來看，是由于支付服務器問題，導致不能及時對SYN進行響應，從而導致用戶支付時延較大，影響用戶感知。

5 移動支付優(yōu)化方案

5.1 問題定位和優(yōu)化措施

綜上分析可推斷移動支付服務器可能存在部分參數(shù)設置問題，從而導致SYN包超時率較高。通過支付平臺服務器提供商對服務器相關(guān)參數(shù)和設置進行核查發(fā)現(xiàn)，其服務器確實存在對部分TCP握手消息不響應的問題。經(jīng)查為其服務器開啟tcp_timestamps驗證導致。

圖7 移動POS支付平臺服務器不同端口TCP三握手成功率趨勢

圖8 刷卡支付測試抓包信令分析

當服務器端的tcp_tw_recycle和tcp_timestamps都是1的時候，會檢查收到數(shù)據(jù)包TCP選項字段中的的timestamp（TS Value），當來自同一個IP地址（任意源端口號），后來的數(shù)據(jù)包中TCP選項字段如果有timestamp且比前面數(shù)據(jù)包中的timestamp小，則server不做ACK響應。

由于POS機客戶端的業(yè)務請求經(jīng)過2臺NAT服務器轉(zhuǎn)換后，后端服務器會認為是同一個TCP連接，由于開啟了tcp_timestamps驗證，在POS客戶端發(fā)起的業(yè)務請求的時間戳存在不一致情況下，有可能會導致客戶端發(fā)起SYN后，服務器端始終不回應SYN ACK，從而導致SYN超時。

通過優(yōu)化，將移動支付服務器端的Linux內(nèi)核參數(shù)tcp_timestamps由1修改為0，關(guān)閉時間戳驗證后解決了SYN超時問題，從而解決了用戶支付失敗的問題。

5.2 移動支付優(yōu)化效果

5.2.1 整體提升效果

在2015年5月22日16點左右，對移動支付服務器進行了相關(guān)優(yōu)化，統(tǒng)計優(yōu)化前后（5月20—25日）的服務器TCP相關(guān)指標并進行跟蹤，具體如圖9所示。

可見，從優(yōu)化后整體效果來看，移動支付服務器的網(wǎng)絡側(cè)成功率上升明顯，由之前的60%左右提升為90%以上，并連續(xù)保持穩(wěn)定；從SYN超時來看，SYN超時率由28%左右下降為5%左右，SYN超時次數(shù)明顯下降，由優(yōu)化前最高的400次下降為優(yōu)化后10次左右。

對移動支付服務器各端口的網(wǎng)絡側(cè)成功率（見圖10）和SYN超時率（見圖11）指標進行跟蹤，可以看到，8001和8200端口在優(yōu)化后，網(wǎng)絡側(cè)成功率指標提升明顯，兩個端口的網(wǎng)絡側(cè)成功率均在95%以上，較優(yōu)化前提升30%左右。從SYN超時率來看，由優(yōu)化前的35%左右下降為5%以內(nèi)，下降了30%左右。

5.2.2 各TCP端口提升效果

2015年5月20—25日，對優(yōu)化前后的8200（見圖12）和8001端口（見圖13）的小時級TCP指標進行跟蹤，可見，在對服務器端進行相關(guān)參數(shù)優(yōu)化后，8200和8001端口的TCP網(wǎng)絡側(cè)成功率均提升明顯，SYN超時次數(shù)下降明顯，從而顯著改善了用戶感知。

圖9 優(yōu)化前后移動支付服務器TCP指標跟蹤

圖10 優(yōu)化前后移動支付服務器各端口的TCP成功率跟蹤

圖11 優(yōu)化前后移動支付服務器各端口的SYN超時率跟蹤

圖13 優(yōu)化前后移動支付服務器8001端口TCP跟蹤

6 結(jié)束語

依托專業(yè)的信令分析工具，對業(yè)務過程進行全程信令分析，從移動支付服務器、移動支付服務器端口、現(xiàn)場測試和用戶投訴信令等不同角度進行分析，發(fā)現(xiàn)隨著業(yè)務量增加，SYN超時率明顯上升，明顯影響用戶感知，最終定位為由服務器端內(nèi)核參數(shù)設置存在異常導致。依托專業(yè)的信令分析工具，可有效提升現(xiàn)場針對此類問題的解決能力，從而有效提升用戶實際感知。