之前寫過socks5代理，具體請(qǐng)看這篇文章。

在寫任何代碼代碼之前，一直認(rèn)為只有設(shè)計(jì)好了相應(yīng)的數(shù)據(jù)結(jié)構(gòu)，才能寫好好的算法和框架。從前面的代碼來看，對(duì)socks5協(xié)議的數(shù)據(jù)結(jié)構(gòu)定義還算不錯(cuò)，具有很好的可讀性。正如之前所說，前面版本太過于簡(jiǎn)單，雖然是基于多線程，但是性能上并不是很好，因?yàn)槲乙獙?duì)每一個(gè)請(qǐng)求臨時(shí)創(chuàng)建一個(gè)線程，我們都知道創(chuàng)建新線程，是需要額外的系統(tǒng)資源，假如有很多Request請(qǐng)求時(shí)，過多的開辟線程，可能導(dǎo)致資源耗盡而宕機(jī)。

再者，前面的版本沒有很好的處理TCP狀態(tài)，在linux下通過netstat狀態(tài)查看，有部分socket套接字處于CLOSE_WAIT狀態(tài)，其意思是在沒有數(shù)據(jù)發(fā)出時(shí)，服務(wù)器端沒有主動(dòng)關(guān)閉Socket。

今天，重新設(shè)計(jì)了一下socks5服務(wù)器的框架。

主要設(shè)計(jì)思想如下：

維護(hù)三個(gè)隊(duì)列：Wait_Queue，Ready_Queue和Read_Queue，分別用于存儲(chǔ)剛接收到請(qǐng)求的套接字，用于Select函數(shù)處理的套接字和有數(shù)據(jù)到達(dá)的套接字；

線程A里，有一個(gè)循環(huán)，不斷地接受來自客戶端的請(qǐng)求，將產(chǎn)生的socket壓入Wait_Queue；

線程B里，也有一個(gè)循環(huán)，不斷地Select或epoll Ready_Queue里的套接字，然后將有數(shù)據(jù)可讀的套接字（看是否對(duì)方已經(jīng)關(guān)閉）壓入Read_Queue；

線程組C里，可以利用多線程處理Read_Queue,線程組大小可以開設(shè)定，程序運(yùn)行時(shí)就開辟相應(yīng)的線程數(shù)量，這樣以后就不會(huì)為每個(gè)請(qǐng)求開辟線程了；

其中，線程B和線程組C是生產(chǎn)消費(fèi)模型；即Read_Queue大小不為0時(shí)，線程組就會(huì)進(jìn)行處理數(shù)據(jù)；當(dāng)Read_Queue大小為0后，線程B又會(huì)從新更新Read_Queue的值。

要注意的是，這里涉及到很多數(shù)據(jù)同步的問題，所以需要用到Mutex，生產(chǎn)消費(fèi)模型需要pthread_cond_t。

來，我們驗(yàn)證這個(gè)框架的性能吧，敬請(qǐng)期待。

最后，我用python寫了一下這個(gè)框架，請(qǐng)看我的github?lab，后面還對(duì)這個(gè)框架進(jìn)一步說明。

?

-----------------打造高質(zhì)量的文章 更多關(guān)注 把酒泯恩仇---------------

為了打造高質(zhì)量的文章，請(qǐng)贊一個(gè)吧。。。。謝謝了，我會(huì)寫更多的好文章的。

請(qǐng)關(guān)注sina微博：http://weibo.com/baiyang26

把酒泯恩仇官方博客：http://www.ibaiyang.org?【推薦用google reader訂閱】

把酒泯恩仇官方豆瓣：http://www.douban.com/people/baiyang26/

轉(zhuǎn)載于:https://www.cnblogs.com/ibaiyang/archive/2012/12/07/2807349.html

總結(jié)

以上是生活随笔為你收集整理的#架构#重新设计socks5代理代码框架的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。