崔陽

文章編號：2096-1472（2022）-02-14-04

DOI：10.19644/j.cnki.issn2096-1472.2022.002.004

摘? 要：首先分析了當(dāng)前掃碼支付系統(tǒng)的性能需求及存在的不足，在此基礎(chǔ)上為掃碼支付系統(tǒng)設(shè)計(jì)了一種基于MQTT協(xié)議、SOCKS5協(xié)議和JSON數(shù)據(jù)格式的數(shù)據(jù)交互層。該交互層優(yōu)化了掃碼支付系統(tǒng)服務(wù)器與商戶終端數(shù)據(jù)庫之間的數(shù)據(jù)交互模式，并集成了訪問代理、身份驗(yàn)證等多項(xiàng)功能，可以使系統(tǒng)的自動化程度進(jìn)一步提高，更靈活地部署于不同的環(huán)境。實(shí)踐結(jié)果表明，在廣東省某連鎖超市使用設(shè)置了數(shù)據(jù)交互層的掃碼支付系統(tǒng)后，響應(yīng)時間明顯縮短，準(zhǔn)確率和安全性也有較大提高。因此，該系統(tǒng)具有較好的推廣價值。

關(guān)鍵詞：掃碼支付系統(tǒng);數(shù)據(jù)交互層;MQTT;SOCKS5

中圖分類號：TP319? ? ?文獻(xiàn)標(biāo)識碼：A

Design and Application of Data-interaction Layer in QR?Code-scanning Payment System based on MQTT

CUI Yang

（College of Applied Technology， China University of Labor Relations， Beijing 100048， China）

cuiyang14@163.com

Abstract： This paper proposes to design a data-interaction layer based on MQTT （Message Queuing Telemetry Transport）， SOCKS5 and JSON （JavaScript Object Notation） for QR （Quick Response） Code-scanning payment system， in view of the performance requirements and the defects of the current QR Code-scanning payment system. The proposed data-interaction layer optimizes data-interaction mode between QR code-scanning payment system server and sellers' terminal database. It also integrates multiple functions such as access agency， identity verification， etc.， which further improves the automation of the system and make the system more flexible to be deployed on different occasions. Practical results show that after using a QR code-scanning payment system with data- interaction layer in a supermarket chain in Guangdong Province， the response time is significantly shortened， and the accuracy and security are also greatly improved. Therefore， the proposed system is quite worthy of promotion.

Keywords： QR code-scanning payment system; data-interaction layer; MQTT; SOCKS5

1? ?引言（Introduction）

掃碼支付是近年正在快速推廣的一種新型購物支付模式。與傳統(tǒng)的支付模式相比，掃碼支付在降低商戶成本、節(jié)省消費(fèi)者時間、建立商戶與消費(fèi)者之間有效聯(lián)系機(jī)制等方面具有極大的優(yōu)勢^[1]。

當(dāng)前很多企業(yè)都推出了自己的掃碼支付系統(tǒng)，但這些系統(tǒng)在應(yīng)用中也逐漸暴露出了一些不足之處，其中之一就是系統(tǒng)的數(shù)據(jù)交互模式仍有待提高。掃碼支付系統(tǒng)以物聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)等為基礎(chǔ)，在這些領(lǐng)域中已經(jīng)有多種比較切實(shí)可用的數(shù)據(jù)交互技術(shù)，例如基于人工蜂群算法的物聯(lián)網(wǎng)數(shù)據(jù)可靠性傳輸方法^[2]、基于微服務(wù)架構(gòu)的物聯(lián)網(wǎng)中間件方法^[3]、“SIP over MQTT”優(yōu)化傳輸機(jī)制^[4]、基于網(wǎng)絡(luò)編碼的能量受限數(shù)據(jù)傳輸機(jī)制^[5]等。本文以這些技術(shù)思想為基礎(chǔ)，為掃碼支付系統(tǒng)設(shè)計(jì)了一個專用的數(shù)據(jù)交互層，以提高掃碼支付系統(tǒng)服務(wù)器與商戶終端機(jī)之間數(shù)據(jù)交互的效率，更好地保障掃碼支付的過程。

2? ?掃碼支付系統(tǒng)的性能分析（Performance analysis of QR code-scanning payment system）

掃碼支付系統(tǒng)的硬件部分主要由服務(wù)器、商戶終端機(jī)、用戶移動設(shè)備等組成。其中，服務(wù)器負(fù)責(zé)處理訂單;商戶終端機(jī)負(fù)責(zé)存儲商品信息、用戶信息和訂單信息;用戶移動設(shè)備負(fù)責(zé)為用戶提供使用掃碼支付系統(tǒng)的界面。系統(tǒng)中大部分的數(shù)據(jù)交互操作發(fā)生在服務(wù)器與商戶終端機(jī)之間。

2.1? ?系統(tǒng)運(yùn)行的基本流程

各種掃碼支付系統(tǒng)雖然在實(shí)現(xiàn)上有所差別，但運(yùn)行過程基本相同：用戶首先通過移動設(shè)備上安裝的APP（或小程序）接入系統(tǒng)，再依次掃描商品包裝上的二維碼生成訂單。訂單信息和付款請求由APP提交到系統(tǒng)服務(wù)器，服務(wù)器收到后根據(jù)自身存儲的商品價格、折扣和用戶級別等信息計(jì)算出訂單應(yīng)付金額，生成支付碼并發(fā)回給APP。APP接收并顯示支付碼，供用戶結(jié)賬使用。之后APP再將支付結(jié)果（成功、異常、失敗等）發(fā)回服務(wù)器。如果訂單已被正確支付，則服務(wù)器還需將訂單信息寫入商戶終端機(jī)的數(shù)據(jù)庫^[6]。

綜合而言，系統(tǒng)以下幾方面的性能對用戶支付體驗(yàn)度有明顯影響：

第一，響應(yīng)速度。自助支付的最大優(yōu)勢在于節(jié)省時間。如果系統(tǒng)每次響應(yīng)和處理訂單的時間過長，會導(dǎo)致用戶的購物意愿降低。因此系統(tǒng)應(yīng)具備一定的實(shí)時性特征，將響應(yīng)速度嚴(yán)格控制在用戶的容忍范圍內(nèi)。

第二，準(zhǔn)確性。商品價格波動比較頻繁，因此系統(tǒng)在處理訂單時必須按最新的商品價格和折扣計(jì)算付款金額，保證用戶和商戶在交易中不會蒙受損失。

第三，安全性。掃碼支付是一種金融活動^[7]，因此過程中涉及的訂單、交易金額和用戶身份等重要數(shù)據(jù)必須保證安全，防止泄露。

2.2? ?當(dāng)前系統(tǒng)存在的不足

目前，很多掃碼支付系統(tǒng)的服務(wù)器仍采用直接訪問商戶終端機(jī)數(shù)據(jù)庫并控制數(shù)據(jù)讀寫的工作模式。這種模式雖然簡單易行，但也可能會導(dǎo)致一些問題：首先是在數(shù)據(jù)讀寫量較大時會加重服務(wù)器的負(fù)載，降低響應(yīng)速度，且不利于數(shù)據(jù)的安全保護(hù)。其次是服務(wù)器中信息的更新難以做到及時和自動化，有時還要依賴人工完成，容易使服務(wù)器在計(jì)算支付金額時因信息過期而出錯。另外，當(dāng)服務(wù)器與數(shù)據(jù)庫處于不同網(wǎng)絡(luò)時，可能會因防火墻設(shè)置等問題出現(xiàn)無法訪問的情況?？梢姡?wù)器與商戶終端機(jī)這種數(shù)據(jù)交互模式對系統(tǒng)的各項(xiàng)性能都有消極影響。

解決這一問題行之有效的方法是為系統(tǒng)增加一個數(shù)據(jù)交互層，將服務(wù)器與數(shù)據(jù)庫操作徹底分離。這樣就可以優(yōu)化系統(tǒng)結(jié)構(gòu)，使系統(tǒng)的響應(yīng)速度、準(zhǔn)確性和安全性三個方面均能得到提高。

3 數(shù)據(jù)交互層的設(shè)計(jì)與實(shí)現(xiàn)（Design and implementation of data-interaction layer）

掃碼支付系統(tǒng)數(shù)據(jù)交互層遵循了物聯(lián)網(wǎng)中間件的設(shè)計(jì)思想，與系統(tǒng)其他部分耦合度低，開發(fā)過程可控且易于部署^[8]。數(shù)據(jù)交互層使系統(tǒng)的服務(wù)器與商戶終端機(jī)之間彼此透明，所有數(shù)據(jù)交互操作均經(jīng)過數(shù)據(jù)交互層完成。

3.1? ?功能設(shè)計(jì)

為更靈活地滿足不同類型客戶端的功能需求，數(shù)據(jù)交互層通常部署在商戶終端機(jī)上。經(jīng)改進(jìn)后，掃碼支付系統(tǒng)的服務(wù)器與數(shù)據(jù)庫工作模式如圖1所示?？梢钥闯?，在增設(shè)數(shù)據(jù)交互層后，以往服務(wù)器與數(shù)據(jù)庫的直接訪問模式就改為服務(wù)器—數(shù)據(jù)交互層—數(shù)據(jù)庫的三級訪問模式。數(shù)據(jù)庫的連接、讀寫等工作都交由數(shù)據(jù)交互層完成，服務(wù)器只需接收或轉(zhuǎn)發(fā)數(shù)據(jù)即可，不再直接干預(yù)低速且頻繁的數(shù)據(jù)庫操作。這樣不但可以減輕服務(wù)器的負(fù)載，而且數(shù)據(jù)上傳和寫入的自動化程度也得到了很大提高。

為了滿足掃碼支付系統(tǒng)的性能需求，數(shù)據(jù)交互層應(yīng)具備以下基本功能：

（1）商戶終端機(jī)身份驗(yàn)證。當(dāng)數(shù)據(jù)交互層在商戶終端機(jī)啟動時，將向服務(wù)器發(fā)送MD5模式加密的身份信息。服務(wù)器驗(yàn)證并確認(rèn)無誤后，數(shù)據(jù)交互層才能與服務(wù)器和數(shù)據(jù)庫建立安全連接，并執(zhí)行后續(xù)操作，從而減少數(shù)據(jù)被劫持的風(fēng)險(xiǎn)。

（2）數(shù)據(jù)定時上傳。商戶終端機(jī)數(shù)據(jù)庫中保存的商品價格、折扣、庫存等信息變化非常頻繁，服務(wù)器在處理訂單時必須以最新信息為依據(jù)，否則會造成支付金額計(jì)算錯誤。數(shù)據(jù)交互層的數(shù)據(jù)定時上傳模塊可以根據(jù)預(yù)先設(shè)定的每次上傳間隔時間，按時自動讀取商戶終端機(jī)數(shù)據(jù)庫中最新的商品信息，并上傳至服務(wù)器，確保服務(wù)器的商品信息能夠及時更新。

（3）訂單寫入。用戶支付成功的訂單需要及時記錄到數(shù)據(jù)庫。數(shù)據(jù)交互層接收服務(wù)器發(fā)送來的訂單信息并寫入商戶終端機(jī)數(shù)據(jù)庫。由于在同一時刻可能會有大量訂單到達(dá)，因此數(shù)據(jù)交互層應(yīng)以異步模式確保所有訂單都正確寫入數(shù)據(jù)庫。

（4）訪問代理。服務(wù)器與商戶終端機(jī)可能在不同的網(wǎng)絡(luò)中，無法相互訪問。這時數(shù)據(jù)交互層的訪問代理功能仍可保證服務(wù)器與商戶終端機(jī)正常建立連接。

3.2? ?實(shí)現(xiàn)過程

數(shù)據(jù)交互層的實(shí)現(xiàn)過程主要包括以下幾個關(guān)鍵模塊：

（1）數(shù)據(jù)交互層與服務(wù)器的通訊。由于數(shù)據(jù)交互層與數(shù)據(jù)庫同在一臺商戶終端機(jī)上，因此以SQL模式訪問即可。與服務(wù)器的通訊則比較復(fù)雜，這里選用的是MQTT協(xié)議。MQTT（Message Queuing Telemetry Transport， 消息隊(duì)列遙測傳輸）協(xié)議是一種構(gòu)建在TCP/IP協(xié)議上、基于發(fā)布/訂閱模式的“輕量級”通訊協(xié)議。該協(xié)議提供了一種一對多的消息發(fā)布模式，定義了發(fā)布者、代理者和訂閱者三種身份^[9]，如圖2所示。

其中，客戶端是消息的發(fā)布者和訂閱者，服務(wù)器是消息的代理者。通過這種機(jī)制，MQTT協(xié)議消除了通訊程序之間的耦合性，將信息冗余降至最小，可以在低開銷、低帶寬的情況下提供實(shí)時可靠的消息服務(wù)^[10]。目前MQTT協(xié)議已被廣泛用于消息推送^[11]、遠(yuǎn)程監(jiān)控[^12]及實(shí)時通信^[13]等領(lǐng)域，其特性非常符合掃碼支付系統(tǒng)應(yīng)用環(huán)境的要求。

在MQTT協(xié)議框架下，數(shù)據(jù)交互層就相當(dāng)于客戶端，向服務(wù)器定時上傳商品信息時充當(dāng)發(fā)布者角色，從服務(wù)器接收訂單時充當(dāng)訂閱者角色。服務(wù)器將用戶成功支付的訂單信息發(fā)送至數(shù)據(jù)交互層，充當(dāng)代理者角色。訂閱/發(fā)布模式可以保證當(dāng)用戶的移動設(shè)備將訂單信息發(fā)送至服務(wù)器時，數(shù)據(jù)交互層能夠自動同步獲取該訂單信息并寫入數(shù)據(jù)庫。在這一過程中，服務(wù)器只需轉(zhuǎn)發(fā)相應(yīng)的訂單信息或接收上傳的商品信息，不再負(fù)責(zé)數(shù)據(jù)庫操作，因此大幅降低了負(fù)載。定義的數(shù)據(jù)交互層與服務(wù)器通訊主題如表1所示。

MQTTnet封裝了一個實(shí)現(xiàn)客戶端與服務(wù)端通訊的類MqttClient，類中定義了一個結(jié)構(gòu)體MqttClientTcpOptions，用于設(shè)置數(shù)據(jù)交互層與服務(wù)器建立MQTT連接的參數(shù)：

public struct MqttClientTcpOptions

{

Server;? ? ? ? ? ? // 服務(wù)器地址

Port;? ? ? ? ? ? ? // 服務(wù)器端口

ClientId;? ? ? ? ? ?// 客戶端ID

UserName;? ? ? ? ?// 用戶名

Password;? ? ? ? ? // 密碼

KeepAlivePeriod;? ? // 保持連接時長

CleanSession;? ? ?// 斷開時是否保留會話

DefaultCommunicationTimeout;

// 默認(rèn)連接超時時長

}

設(shè)置好MqttClientTcpOptions結(jié)構(gòu)體中各項(xiàng)參數(shù)后，就可以調(diào)用MqttClient類的ConnectAsync方法發(fā)起與服務(wù)器的連接，成功后將建立數(shù)據(jù)交互層與服務(wù)器的會話連接。數(shù)據(jù)定時上傳和從服務(wù)器接收訂閱的訂單信息分別使用MqttClient類PublishAsync和SubscribeAsync方法。

由于MQTTnet為開源類庫，因此可以方便地在其中添加對SOCKS5協(xié)議的支持。SOCKS5是一種會話層訪問代理協(xié)議，能夠使數(shù)據(jù)交互層與服務(wù)器的通訊在處于不同網(wǎng)絡(luò)或有防火墻設(shè)置等情況下仍能正常進(jìn)行^[14]?？梢栽贛qttClientTcpOptions結(jié)構(gòu)體中增加ProxyServer和ProxyServerPort參數(shù)，指定代理服務(wù)器的名稱和端口。

（2）數(shù)據(jù)格式的定義。數(shù)據(jù)交互層與服務(wù)器之間通訊的數(shù)據(jù)格式采用JSON格式。相對于XML，JSON的層次結(jié)構(gòu)更為簡潔清晰，解析和傳輸效率較高^[15]。例如，數(shù)據(jù)定時上傳的JSON格式為：

{

"command_type"： " schedule_data"，

"data"：[{

"upc_code"：，

"product_name"： ""，

"price"： ""，

"member_price"： ""，

"unit： ""，

}]

}

當(dāng)數(shù)據(jù)庫中的商品信息發(fā)生變化時，只需在數(shù)據(jù)格式中作相應(yīng)修改即可。

（3）連接異常處理。數(shù)據(jù)交互層在運(yùn)行過程中定時檢測與服務(wù)器的連接狀態(tài)。當(dāng)發(fā)現(xiàn)中斷時，將立即嘗試重新連接服務(wù)器。如果是在數(shù)據(jù)上傳期間發(fā)生中斷，則連接成功后再次進(jìn)行上傳操作，以避免服務(wù)器出現(xiàn)數(shù)據(jù)不一致現(xiàn)象。當(dāng)重新嘗試次數(shù)達(dá)到最大值仍未能恢復(fù)連接時，模塊將向系統(tǒng)管理員發(fā)出警告。

4? 數(shù)據(jù)交互層的應(yīng)用（Application of data-interaction layer）

掃碼支付系統(tǒng)數(shù)據(jù)交互層的開發(fā)環(huán)境為Visual Studio 2018，開發(fā)語言為C#。服務(wù)器和商戶終端機(jī)的運(yùn)行環(huán)境為64 位Windows 10，數(shù)據(jù)庫為SQL Server。

數(shù)據(jù)交互層劃分為服務(wù)器連接、身份驗(yàn)證、數(shù)據(jù)定時上傳、數(shù)據(jù)寫入和MQTT連接監(jiān)測等幾個主要模塊。數(shù)據(jù)交互層啟動后，首先在網(wǎng)絡(luò)連接正常的情況下檢驗(yàn)商戶終端機(jī)與服務(wù)器是否需要啟用代理訪問。之后嘗試與服務(wù)器建立MQTT連接，若成功則向服務(wù)器發(fā)送商戶終端機(jī)名稱、密碼等身份驗(yàn)證信息。若通過則繼續(xù)向服務(wù)器發(fā)送訂閱信息，并完成初始化工作，包括計(jì)時器置0，創(chuàng)建數(shù)據(jù)上傳線程和數(shù)據(jù)寫入線程，以及一些參數(shù)值的設(shè)定等;否則終止之前建立的MQTT連接。在沒有遇到系統(tǒng)退出或故障時，數(shù)據(jù)交互層將一直處于運(yùn)行狀態(tài)。

數(shù)據(jù)交互層開始運(yùn)行時，數(shù)據(jù)上傳線程處于阻塞態(tài)。當(dāng)上傳時間點(diǎn)到達(dá)時，線程恢復(fù)運(yùn)行，以SQL模式連接數(shù)據(jù)庫并讀取數(shù)據(jù)，轉(zhuǎn)換為JSON格式后再根據(jù)預(yù)先設(shè)定的MQTT通訊主題為數(shù)據(jù)添加頭部信息，之后上傳至服務(wù)器。如果線程收到服務(wù)器的確認(rèn)信息，則重新進(jìn)入阻塞態(tài)并開始新一輪計(jì)時，反之則嘗試再次上傳數(shù)據(jù)。當(dāng)重傳次數(shù)達(dá)到最大值時將放棄本次時間點(diǎn)的上傳任務(wù)，并向管理員發(fā)出警告，由管理員決定本次改由人工模式更新還是等待下一次上傳時間點(diǎn)再自動更新。

訂單數(shù)據(jù)寫入過程則略復(fù)雜。由于同一時刻可能有多個商戶終端機(jī)訂閱的數(shù)據(jù)由服務(wù)器轉(zhuǎn)發(fā)至數(shù)據(jù)交互層，為防止出現(xiàn)不同步問題導(dǎo)致的讀寫錯誤，必須設(shè)置一個數(shù)據(jù)緩沖隊(duì)列，作為臨界資源加以保護(hù)。數(shù)據(jù)緩沖隊(duì)列為空時，數(shù)據(jù)寫入線程處于阻塞態(tài)。當(dāng)數(shù)據(jù)到達(dá)時先送入數(shù)據(jù)緩沖隊(duì)列，同時數(shù)據(jù)寫入線程恢復(fù)運(yùn)行，從隊(duì)列中讀取數(shù)據(jù)并解析數(shù)據(jù)頭部信息中的MQTT主題，判斷是否為商戶終端機(jī)訂閱的訂單數(shù)據(jù)，若是則將訂單數(shù)據(jù)轉(zhuǎn)換格式后寫入數(shù)據(jù)庫。圖3給出了完整的掃碼支付系統(tǒng)交互圖。

目前，該系統(tǒng)已在廣東省某大型連鎖超市中得到了應(yīng)用。數(shù)據(jù)交互層的引入改變了以往人工模式更新服務(wù)器信息的情況，且在網(wǎng)絡(luò)連接正常的情況下，每次定時上傳18，000 條商品信息至服務(wù)器數(shù)據(jù)緩沖區(qū)的時間縮短至40—50 秒。同時，數(shù)據(jù)交互層可以正確地將多個用戶發(fā)送至服務(wù)器的訂單依次寫入數(shù)據(jù)庫。實(shí)踐證明，數(shù)據(jù)交互層有效地提高了掃碼支付系統(tǒng)的效率和準(zhǔn)確性，而且對服務(wù)器、商戶終端機(jī)和數(shù)據(jù)庫的運(yùn)行均沒有明顯影響。

5? ?結(jié)論（Conclusion）

掃碼支付系統(tǒng)是“智慧銷售”系統(tǒng)的重要組成部分，數(shù)據(jù)交互層的設(shè)置給出了一種提高掃碼支付系統(tǒng)性能的新思路。實(shí)際情況表明，數(shù)據(jù)交互層使掃碼支付系統(tǒng)在響應(yīng)速度、準(zhǔn)確性和安全性等方面均有所提高。今后的工作主要集中在對數(shù)據(jù)交互層的改進(jìn)和新功能擴(kuò)展等方面。

參考文獻(xiàn)（References）

[1] 陳平，高懷恩，陳炯標(biāo)，等.基于物聯(lián)網(wǎng)的智慧超市[J].電視技術(shù)，2013，37（S1）：57-60.

[2] YI L， PENG Y. internet of things transmission and network reliability in complex environment[J]. Computer Communications， 2020， 150（1）：757-763.

[3] 吳斌峰.基于微服務(wù)架構(gòu)的物聯(lián)網(wǎng)中間件設(shè)計(jì)[J].計(jì)算機(jī)科學(xué)， 2019，46（S1）：580-584，604.

[4] 楊海波，馬榮榮，張偉，等.面向移動互聯(lián)網(wǎng)的“SIP over? MQTT”優(yōu)化傳輸機(jī)制研究[J].小型微型計(jì)算機(jī)系統(tǒng)，2017，38（04）：776-780.

[5] 黃辰，李可維，張偉，等.無線物聯(lián)網(wǎng)中基于網(wǎng)絡(luò)編碼的能量受限數(shù)據(jù)傳輸機(jī)制[J].電子學(xué)報(bào)，2013，41（1）：144-147.

[6] 汪天星，程耕國.基于B/S的掃碼支付平臺的設(shè)計(jì)[J].現(xiàn)代電子技術(shù)，2018，41（22）：49-52，58.

[7] 單美靜.基于AHP法的移動支付安全風(fēng)險(xiǎn)評估[J]計(jì)算機(jī)科學(xué)，2015，42（S2）：368-371.

[8] 王冰，陳庭貴.基于高性能消息管理機(jī)制的物聯(lián)網(wǎng)中間件設(shè)計(jì)方法[J].計(jì)算機(jī)工程與應(yīng)用，2017，53（16）：89-97，186.

[9] 陽旺，樊振宇，吳帆.基于6LoWPAN與MQTT的無線傳感網(wǎng)絡(luò)設(shè)計(jì)[J].國防科技大學(xué)學(xué)報(bào)，2019，41（01）：161-168.

[10] 張玉杰，張海濤，張婷婷.基于MQTT的物聯(lián)網(wǎng)系統(tǒng)消息發(fā)布/訂閱方法研究[J].電視技術(shù)，2017，41（Z3）：83-87.

[11] 姜妮，張宇，趙志軍.基于消息隊(duì)列遙測傳輸?shù)耐扑拖到y(tǒng)[J].計(jì)算機(jī)工程，2015，41（9）：1-6.

[12] 馬匯海，張君燕，孟彥京.基于云平臺的高頻搖振器監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].中國造紙，2018，37（10）：48-53.

[13] 諶建飛，鄧敏，唐俊龍，等.實(shí)時大規(guī)模遠(yuǎn)程實(shí)驗(yàn)通信方案研究[J].計(jì)算機(jī)工程與應(yīng)用，2018，54（19）：94-100.

[14] 俞定國，舒明磊，譚成翔.基于Socks5代理的移動SSL VPN系統(tǒng)研究與實(shí)現(xiàn)[J].計(jì)算機(jī)科學(xué)，2011，38（1）：119-121，144.

[15] 陳瑋，賈宗璞.利用JSON降低XML數(shù)據(jù)冗余的研究[J].計(jì)算機(jī)應(yīng)用與軟件，2012，29（9）：188-189，206.

作者簡介：

崔? ?陽（1979-），男，博士，講師.研究領(lǐng)域：知識工程與知識發(fā)現(xiàn).

基金項(xiàng)目：中國勞動關(guān)系學(xué)院科研項(xiàng)目（20XYJS004）.