一種高并發(fā)認證服務(wù)器的實現(xiàn)

樊揚軻　唐杰

摘要：針對當(dāng)前層出不窮的網(wǎng)絡(luò)安全問題，設(shè)計并實現(xiàn)了一個具有高并發(fā)功能的認證服務(wù)器。該文采用了RSA和DES算法來保證信息傳輸?shù)陌踩裕捎胑poll和線程池技術(shù)來保證其具有高并發(fā)功能。分別設(shè)計了集成測試和壓力測試用例對服務(wù)器的穩(wěn)定性和可靠性進行了測試。實驗結(jié)果表明，認證服務(wù)器在高負載的情況下運轉(zhuǎn)正常。

關(guān)鍵詞：認證服務(wù)器；多線程；對稱加密

中圖分類號：TP309 文獻標識碼：A 文章編號：1009-3044（2015）24-0047-03

Designed and Implemented an Authentication Server with High Concurrency

FAN Yang-ke1， TANG Jie2

（1. College of software Shenyang Normal University，Shenyang 110127， China； 2. Hunan University of arts and Science， Changde 415003， China）

Abstract： In view of the current network security problems emerge in endlessly， designed and implemented an authentication server with high concurrency. This paper adopted the RSA and DES algorithm to ensure the security of information transmission， epoll and thread pool technology is used to ensure the high concurrency. Respectively designed integration test and stress test cases to test the stability and reliability of the server. The experimental results show that the authentication server in the case of high load operating normally.

Key words： authentication server； multithreading； symmetric encryption

為了保障信息的安全性，我們一般都采取了數(shù)據(jù)加密和身份認證的措施。目前，數(shù)據(jù)的加密與認證廣泛地運用在基于http協(xié)議的web服務(wù)器中，比如網(wǎng)站的登錄、網(wǎng)上支付等。自從“棱鏡”事件曝光后，如何在越來越廣的范圍內(nèi)保護我們的隱私，成為了現(xiàn)在的熱點問題。一個高并發(fā)的服務(wù)器是在短時間內(nèi)同時處理大量的來自客戶端請求的一個系統(tǒng)。而現(xiàn)在常用的服務(wù)器如WEB服務(wù)器，游戲服務(wù)器。并發(fā)性都是有限的，因此對服務(wù)器并發(fā)的研究具有很強的現(xiàn)實意義。本文介紹一種高并發(fā)功能的認證服務(wù)器設(shè)計。

1 服務(wù)器端的總體設(shè)計

1.1 系統(tǒng)總體框架

本系統(tǒng)采用C/S設(shè)計模式，其中必不可少的是套接字編程。高并發(fā)認證服務(wù)器的任務(wù)是服務(wù)器對客戶端的身份做一個認證。認證服務(wù)器首先生成一對公私鑰對，在接到客戶端發(fā)來的認證請求后，服務(wù)器將公鑰發(fā)給客戶端，客戶端接到服務(wù)器端的響應(yīng)后，生成DES密鑰，用接收來的服務(wù)器公鑰加密用戶帳號UID，用戶口令USEPASSWORD，用戶的DES密鑰DESKEY等信息，并將其發(fā)送給服務(wù)器，服務(wù)器用私鑰解密數(shù)據(jù)后，驗證用戶身份的合法性，其序列圖如圖1所示：

1.2 服務(wù)端框架

目前基于流式套接字的并發(fā)服務(wù)器是Linux網(wǎng)絡(luò)服務(wù)器主流形式。傳統(tǒng)的基于多進程和select機制的并發(fā)服務(wù)器由于受到系統(tǒng)資源和Linux內(nèi)核版本的限制，已經(jīng)不能滿足高并發(fā)的要求。根據(jù)圖1的描述，本系統(tǒng)采用了epoll和線程池技術(shù)，設(shè)計了一個大并發(fā)認證服務(wù)器。服務(wù)器利用一個監(jiān)聽線程，接受客戶端的請求后放入連接緩沖區(qū)，使用epoll技術(shù)來做事件觸發(fā)，再由線程池中的處理線程處理客戶端發(fā)來的認證請求。處理線程需要將客戶信息解密后與存放在MySQL數(shù)據(jù)庫中的信息進行比對，從而完成認證過程。其總體結(jié)構(gòu)圖如圖2所示。

1.3 epoll服務(wù)器流程

服務(wù)器的主要工作流程是：① 當(dāng)啟動客戶端后，先應(yīng)確保程序的單實例運行，然后初始化運行日志，初始化完成后系統(tǒng)就會讀取服務(wù)器的配置文件，進行命令解析。② 服務(wù)器創(chuàng)建并初始化線程池，創(chuàng)建網(wǎng)絡(luò)環(huán)境并初始化參數(shù)，調(diào)用epoll_create 函數(shù)來創(chuàng)建一個epollfd 的文件描述符。③ 調(diào)用epoll_ctl 函數(shù)將監(jiān)聽套接字注冊到epoll 事件的等待隊列中。④ 設(shè)計在一個“死循環(huán)”中，調(diào)用調(diào)用epoll_wait 阻塞等待注冊在epoll 上的sockfd 事件的發(fā)生，依次處理到來的事件，如果到來的的事件是監(jiān)聽事件，就調(diào)用accept 函數(shù)來產(chǎn)生連接套接字，并且將這個套接字也設(shè)置成非阻塞的狀態(tài)注冊到epoll 的事件等待的隊列中，如果到來的事件是表明有已經(jīng)連接的客戶端的通信數(shù)據(jù)到來，就向線程池中拋入一個任務(wù)。同時喚醒空閑的任務(wù)線程來處理相關(guān)的認證業(yè)務(wù)請求。該設(shè)計最大的好處在于它不會隨著監(jiān)聽fd數(shù)目的增長而降低效率。因為在內(nèi)核中的select實現(xiàn)中，它是采用輪詢來處理的，輪詢的fd數(shù)目越多，自然耗時越多。

1.4 信息處理模塊

主要完成功能是生成RSA公鑰對，通過對用戶類型判斷，驗證客戶身份，回復(fù)客戶端。

1.5 加密設(shè)計模塊

基于“對稱密鑰”的加密算法DES算法，把64位的明文輸入塊變?yōu)閿?shù)據(jù)長度為64位的密文輸出塊，其中8位為奇偶校驗，另外56位作為密碼的長度。

2 關(guān)鍵技術(shù)

2.1 Socket編程服務(wù)器設(shè)計

在本系統(tǒng)中，服務(wù)器的設(shè)計思想如下：

1）首先，在使用socket之前，要首先初始化socket，就是使用socket 函數(shù)來建立一個套接字，用來完成通信的監(jiān)聽。

int socket（int domain，int type，int protocol）；

2）在初始化完成以后，利用bind函數(shù)綁定一個端口和IP地址。

int bind（int sockfd，struct sockaddr * my_addr，int addr，int addrlen）；

3）調(diào)用listen函數(shù)，使服務(wù)器的這個端口和IP處于監(jiān)聽狀態(tài)，等待客戶機的連接。

int listen（int s ，int backlog）；

4）使用accept函數(shù)來接收遠程計算機的連接，建立起與客戶機之間的通信。

int accept（int s，struct sockaddr *addr ，int * addrlen）；

5）在通信的過程中，服務(wù)器端的產(chǎn)生的新的socket會通過一個消息響應(yīng)函數(shù)recv函數(shù)來接收到達的數(shù)據(jù)。數(shù)據(jù)的發(fā)送用send函數(shù)來完成，當(dāng)數(shù)據(jù)傳輸完畢，雙方都調(diào)用close函數(shù)關(guān)閉各自套接字，終止通信。

int recv（int s，void * buf，int len，unsigned int flags）；

2.2 線程池技術(shù)

線程池的作用是有效的降低頻繁創(chuàng)建銷毀線程所帶來的額外開銷。項目中，在服務(wù)器啟動之初便預(yù)先創(chuàng)建一定數(shù)目的任務(wù)線程。在運行的過程中，需要時可以從這些線程所組成的線程池里申請分配一個空閑的線程，來執(zhí)行認證的任務(wù)，任務(wù)完成后，并不是將線程銷毀，而是將它返還給線程池。如果線程池中預(yù)先分配的線程已經(jīng)全部分配完畢，但此時又有新的任務(wù)請求，則線程池會動態(tài)的創(chuàng)建新的線程去適應(yīng)這個請求。其工作流程圖見圖3。

任務(wù)線程是在線程池結(jié)構(gòu)體變量初始化時啟動的線程。任務(wù)線程池中的任務(wù)線程如果檢測到任務(wù)鏈表中的任務(wù)節(jié)點數(shù)不為零就從任務(wù)鏈表尾（T）取出任務(wù)節(jié)點并執(zhí)行相應(yīng)的任務(wù)，同時讓任務(wù)鏈表中的任務(wù)節(jié)點數(shù)減1.如果任務(wù)鏈表中的任務(wù)節(jié)點為零，就使任務(wù)線程掛起，等待主線程向任務(wù)鏈表中拋入一個任務(wù)后，再次喚醒空閑的任務(wù)線程執(zhí)行任務(wù)。

2.3 對稱加密（DES算法）

基于“對稱密鑰”的加密算法主要有DES、TripleDES、RC2、RC4、RC5和Blowfish等。DES算法把64位的明文輸入塊變?yōu)閿?shù)據(jù)長度為64位的密文輸出塊，其中8位為奇偶校驗，另外56位作為密碼的長度。首先，DES把輸入的64位數(shù)據(jù)塊按位重新組合，并把輸出分為L0、R0兩部分，每部分各長32位，并進行前后置換，最終由L0輸出左32位，R0輸出右32位，根據(jù)這個法則經(jīng)過16次迭代運算后，得到L16、R16，將此作為輸入，進行與初始置換相反的逆置換，即得到密文輸出，圖4為算法流程。

3 系統(tǒng)運行及測試

3.1 運行環(huán)境

操作系統(tǒng)：Ubuntu Linux（10.10版本），Linux（內(nèi)核2.6版本）數(shù)據(jù)庫：MySQL

編譯環(huán)境：g++，openssl 庫函數(shù)，ROOT權(quán)限

3.2 系統(tǒng)集成測試

登錄測試，配置好服務(wù)器及服務(wù)器端數(shù)據(jù)庫，為了驗證認證服務(wù)器的加密解密算法的正確性，設(shè)計了一個正常的客戶端程序。該程序首先生成DES密鑰，然后向服務(wù)器發(fā)送認證請求，在接收到服務(wù)器的公鑰后，用公鑰加密自己的用戶ID號、口令和DES密鑰發(fā)送給服務(wù)器。測試的目的是查看服務(wù)器能否正確解密客戶端信息并進行驗證。

系統(tǒng)壓力測試，測試用例1是客戶端先發(fā)送錯誤的UID號（此次測試UID=1234）進行死循環(huán)訪問服務(wù)器，壓力測試的屏幕截圖如圖5所示。從圖中我們可以看到，因為UID錯誤，所以結(jié)果只顯示 connect success，然后直接提示uid error，再關(guān)閉SOCKET，接著循環(huán)繼續(xù)運行，所以效果則是刷屏一樣的不停的顯示， 但是不會因為壓力太大而斷開。服務(wù)器承受錯誤的業(yè)務(wù)運行穩(wěn)定。

測試用例2是在客戶端先發(fā)送正確的UID號（此次測試UID=12345）與密碼（mima=123456789）進行不間斷的死循環(huán)訪問服務(wù)器測試5分鐘。從‘運行結(jié)果和‘運行日志文件兩個地方進行分析推論出

一秒鐘運行超過300次，所以相當(dāng)于對服務(wù)器訪問了300次，所以說服務(wù)器1秒鐘能承受3000次以上正確的UID與mima驗證的訪問壓力。5分鐘的訪問壓力也不會讓服務(wù)器承受不了壓力而斷開或出錯，因此服務(wù)器承受正確的業(yè)務(wù)邏輯穩(wěn)定。

4 結(jié)束語

論述了高并發(fā)認證服務(wù)器的創(chuàng)作思路和整個項目總體設(shè)計，采用了RSA和DES算法來保證信息傳輸?shù)陌踩?，采用epoll和線程池技術(shù)來保證其具有高并發(fā)功能，通過測試，認證服務(wù)器在高負載的情況下運轉(zhuǎn)正常。該系統(tǒng)作為在短時間內(nèi)同時處理大量的來自客戶端請求的研究具有很強的現(xiàn)實意義。

參考文獻：

[1] 車永剛， 柳佳，王正華，等.超級計算機體系結(jié)構(gòu)及應(yīng)用情況[J]. 計算機工程與科學(xué)， 2003， 25（6）： 97-100.

[2] 楊樹軍， 戴水誦. 超大規(guī)模下集群監(jiān)控管理系統(tǒng)的設(shè)計與實現(xiàn)[J]. 高性能計算發(fā)展與應(yīng)用， 2010（2）： 1-4.

[3] Hoffman F， Cluster Monitoring with Ganglia. Linux Magazine[J]. 2003， 5（7）： 46-51.