專利名稱：一種協(xié)議代理檢測方法和裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，特別是一種協(xié)議代理檢測方法和裝置。
背景技術(shù)：
IP(Internet Protocol,網(wǎng)絡(luò)之間互連的協(xié)議)地址IP地址是TCP/ IP (Transmission Control Protocol/Internet Protocol，傳輸控制協(xié)議 / 因特網(wǎng)互聯(lián)協(xié)議)通訊協(xié)議中標(biāo)記每臺計算機(jī)的地址，在TCP/IP協(xié)議中，每臺連網(wǎng)計算機(jī)都依靠IP地址來標(biāo)識自己并用該IP地址進(jìn)行交換信息。TCP (Transmission Control Protocol，傳輸控制協(xié)議)傳輸協(xié)議TCP 是 TCP/IP 體系中面向連接的運(yùn)輸層協(xié)議，它提供全雙工和可靠的交付的服務(wù)。一條TCP連接的四元素唯一標(biāo)識為源IP、目的IP、源端口和目的端口。協(xié)議代理協(xié)議代理指的是如HTTP (HyperText Transfer Protoco 1，超文本傳輸協(xié)議)、SOCKS (Protocol for sessions traversal across firewall securely,防火墻安全會話轉(zhuǎn)換協(xié)議)4、S0CKS4A、S0CKS5等代理。(I)HTTP代理HTTP代理指的是客戶端與服務(wù)器端建立連接后(TCP連接)，以請求方法、URI (Uniform Resource Identifier，通用資源標(biāo)志符)、協(xié)議版本等方式向服務(wù)器端發(fā)出請求，該請求包含請求修飾符、客戶信息、及可能的請求體(body)內(nèi)容的 MIME (Multipurpose Internet Mail Extensions，多功能 Internet 郵件擴(kuò)充)類型消息。 服務(wù)器端通過狀態(tài)隊列(status line)來回應(yīng)，內(nèi)容包括消息的協(xié)議版本、成功或錯誤代碼，也包含服務(wù)器信息、實體元信息及實體內(nèi)容的MIME類型消息。HTTP代理發(fā)送的請求行中的Request-URI為絕對統(tǒng)一資源標(biāo)識符(如 GEThttp //www. baidu. com/HTTP/1. 0)，而正常的 http 請求行中的 Request-URI 為相對統(tǒng)一資源標(biāo)識符(如GET/HTTP/1. 0)。代理服務(wù)器以絕對形式接收URI請求，重寫全部或部分消息，并將經(jīng)過改寫的請求繼續(xù)向URI中指定的服務(wù)器處推送。(2) SOCKS S0CKS4A S0CKS5代理圖1出示了客戶端向SOCKS 4代理服務(wù)器發(fā)送的連接請求包的格式(以字節(jié)為單位)其中VN是SOCK版本，應(yīng)該是4 ；CD是SOCK的命令碼，1表示CONNECT請求，2表示BIND請求；DSTP0RT表示目的主機(jī)的端口 ；
DSTIP指目的主機(jī)的IP地址；NULL M 0 ；圖2出示了代理服務(wù)器給客戶端發(fā)送的回應(yīng)包的格式(以字節(jié)為單位)其中VN是回應(yīng)碼的版本，應(yīng)該是0 ；⑶是代理服務(wù)器答復(fù)，有幾種可能90，請求得到允許；91，請求被拒絕或失??；
92，由于SOCKS服務(wù)器無法連接到客戶端的identd( —個驗證身份的進(jìn)程)，請求被拒絕；93，由于客戶端程序與identd報告的用戶身份不同，連接被拒絕。DSTP0RT與DSTIP與請 求包中的內(nèi)容相同，但被忽略。如果請求被拒絕，SOCKS服務(wù)器馬上與客戶端斷開連接；如果請求被允許，代理服務(wù)器就充當(dāng)客戶端與目的主機(jī)之間進(jìn)行雙向傳遞，對客戶端而言，就如同直接在與目的主機(jī)相連。SOCKS 4A是SOCKS 4協(xié)議的簡單擴(kuò)展，允許客戶端對無法解析的目的主機(jī)，進(jìn)行自行規(guī)定，即支持目的為域名地址的代理。而S0CKS5又做了更進(jìn)一步的擴(kuò)展，當(dāng)TCP連接建立后，客戶端和服務(wù)器首先要進(jìn)入?yún)f(xié)商版本和認(rèn)證方法的過程，之后才能發(fā)送代理請求。數(shù)據(jù)包過濾監(jiān)聽技術(shù)個操作系統(tǒng)有一套的網(wǎng)絡(luò)體系結(jié)構(gòu)，通過該體系結(jié)構(gòu)可以控制著整個系統(tǒng)的網(wǎng)絡(luò)行為。如windows操作系統(tǒng)Window NT SP4之后的版本，提供了 NDIS(Network Driver Interface Specification，網(wǎng)絡(luò)驅(qū)動接口規(guī)范)中間層驅(qū)動。中間層驅(qū)動介于協(xié)議層驅(qū)動和小端口驅(qū)動之間，它能夠截獲所有的網(wǎng)絡(luò)數(shù)據(jù)包(如果是以太網(wǎng)那就是以太幀)。圖3出示了簡單操作系統(tǒng)網(wǎng)絡(luò)體系示意圖圖3出示的操作系統(tǒng)網(wǎng)絡(luò)體系架構(gòu)，是對操作系統(tǒng)所有參與網(wǎng)絡(luò)處理的組件以及這些組件協(xié)同工作的統(tǒng)稱，這里并不單指網(wǎng)絡(luò)驅(qū)動程序，也包含參與網(wǎng)絡(luò)行為的應(yīng)用層組件程序。在這些網(wǎng)絡(luò)組件中，可以對本機(jī)發(fā)送和接收的數(shù)據(jù)，按照協(xié)議類型進(jìn)行監(jiān)聽獲取。 還可以通過設(shè)置過濾篩子只獲取本機(jī)發(fā)送和接收的TCP數(shù)據(jù)包，對于其它不關(guān)心的報文則忽略。可以用如下防火墻常用的典型技術(shù)進(jìn)行監(jiān)聽獲取(具體的開發(fā)技術(shù)請參考微軟提供的相關(guān)開發(fā)文檔)Winsock Layered Service Provider (LSP)，微軟提供的在用戶態(tài)下進(jìn)行數(shù)據(jù)包監(jiān)聽獲取的技術(shù)。TDI 過濾驅(qū)動程序(TDI Filter Driver)，TDI 的全稱是 Transport Driver Interface, TDI是一組接口的名字，Windows的上層網(wǎng)絡(luò)組件調(diào)用這些接口來使用協(xié)議驅(qū)動。NDIS中間層驅(qū)動程序(NDIS Intermediate Driver)，系統(tǒng)中所有的網(wǎng)絡(luò)通信都經(jīng)過NDIS中間層驅(qū)動程序，因此它可以用于網(wǎng)絡(luò)數(shù)據(jù)包的監(jiān)聽。不管是HTTP還是SOCKS代理，在這一過程中，主要有3個角色代理客戶端，代理服務(wù)器，代理客戶端想要訪問的服務(wù)器。代理客戶端A通過代理服務(wù)器訪問遠(yuǎn)程服務(wù)器A。圖4是代理行為的流程圖，包括如下步驟S402，代理客戶端和代理服務(wù)器通過TCP三次握手建立起TCP連接；S404,代理客戶端把想要訪問的目的地址和目的端口通過剛才建立的TCP連接按相應(yīng)的代理協(xié)議格式發(fā)送到代理服務(wù)器；S406，代理服務(wù)器按相應(yīng)協(xié)議解析出目的地址和目的端口，按要求去連接該目的地址上的端口；S408，代理服務(wù)器為代理客戶端和代理客戶端訪問的服務(wù)器兩者之間提供數(shù)據(jù)透傳。而目前的對協(xié)議代理的檢測主要有以下幾種解決方法
1、端口掃描法通過掃描 PC上開啟了哪些端口，來判斷是否開啟了代理。但代理服務(wù)器可以修改端口號而避開這種檢測。2、代理軟件掃描法掃描PC機(jī)上是否運(yùn)行了指定的代理軟件，從而判斷是否提供了代理服務(wù)。代理服務(wù)器軟件多樣，當(dāng)出現(xiàn)新的代理服務(wù)器軟件時檢測將失效。3、報文特征分析法比較進(jìn)出以及出進(jìn)的報文的數(shù)據(jù)特征是否匹配來判斷，當(dāng)匹配時則判斷為存在代理行為。多個數(shù)據(jù)報文間需要進(jìn)行兩兩比較，假設(shè)如果有η個數(shù)據(jù)報文，那么比較的次數(shù)為
C2n =(η > = 2)，當(dāng)η選取的太小時，可通會漏報，當(dāng)η選取的太大時，效率太低。
并且可通還會出現(xiàn)誤報的情況。只要出現(xiàn)進(jìn)出的報文或者出進(jìn)的報文數(shù)據(jù)特征匹配就會被判斷為存在代理行為。例如假設(shè)學(xué)生A開發(fā)了一款聊天客戶端和服務(wù)器軟件，A在自己的 PC上運(yùn)行服務(wù)器軟件，學(xué)生B、C分別在另外兩臺PC上運(yùn)行聊天客戶端軟件，B和C的所有聊天信息都通過A的PC上的服務(wù)器軟件進(jìn)行轉(zhuǎn)發(fā)，那么該檢測方法必會檢測到A的PC上存在代理行為，而實際上B、C并不能通過A上外網(wǎng)。

發(fā)明內(nèi)容
本發(fā)明的主要目的在于提供一種協(xié)議代理檢測方法和裝置，以解決現(xiàn)有技術(shù)中對是否采用了代理協(xié)議檢測效率低，且會漏報誤報的問題。根據(jù)本發(fā)明的一個方面，提供了一種協(xié)議代理檢測方法，該方法包括在TCP連接建立時，接收應(yīng)答握手信息的報文；根據(jù)應(yīng)答握手信息的報文判斷TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的；若應(yīng)答握手信息的報文是客戶端發(fā)起的，則接收客戶端發(fā)送的請求信息；判斷請求信息是否是代理請求信息；如果請求信息是代理請求信息，則保存客戶端請求訪問的目的服務(wù)器信息；判斷檢測端是否與保存的請求訪問的目的服務(wù)器建立連接； 若檢測端與保存的請求訪問的目的服務(wù)器建立連接，則檢測出采用了協(xié)議代理。根據(jù)應(yīng)答握手信息的報文判斷TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的步驟包括判斷接收到的應(yīng)答握手信息的報文的目的地址是否與檢測端的地址相符；如果相符，則判斷出TCP連接是檢測端發(fā)起的；如果不相符，則判斷出TCP連接是客戶端發(fā)起的。協(xié)議代理檢測方法還包括在TCP連接建立時，接收TCP報文；判斷TCP報文是否為應(yīng)答握手信息的報文；若TCP報文不是應(yīng)答握手信息的報文，則判斷TCP報文是否是結(jié)束報文，若TCP報文是應(yīng)答握手信息的報文，則根據(jù)應(yīng)答握手信息的報文判斷TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的；若TCP報文不是結(jié)束報文，則判斷TCP報文是否滿足代理協(xié)議特征；若TCP報文滿足代理協(xié)議特征，則保存TCP報文請求訪問的目的服務(wù)器信息。判斷TCP報文是否為應(yīng)答握手信息的報文的步驟包括判斷TCP報文是否為應(yīng)答握手信息的報文；若判斷出TCP報文是應(yīng)答握手信息的報文，則根據(jù)TCP報文的連接四元素生成與TCP報文對應(yīng)的表項，插入到TCP過濾表中，并接收TCP報文；若判斷出TCP報文不是應(yīng)答握手信息的報文，則以TCP報文的TCP連接四元素為索引在TCP過濾表中查找是否有與報文對應(yīng)的表項，并在查找成功時，接收TCP報文。
判斷請求信息是否是代理請求信息的步驟還包括若TCP連接 是客戶端發(fā)起的，則提取應(yīng)答握手信息的報文的TCP連接四元素插入到代理客戶端請求連接表中，判斷接收到的請求信息是否滿足代理協(xié)議特征，并在請求信息滿足代理協(xié)議特征時，保存請求信息的報文請求訪問的目的服務(wù)器信息到代理客戶端請求連接表中；若TCP連接是檢測端發(fā)起的，則提取客戶端的地址和端口在代理客戶端請求連接表中查找，并在查找成功時，檢測出采用了協(xié)議代理。目的服務(wù)器信息包括目的服務(wù)器的目的地址和目的端口。判斷檢測端是否與保存的請求訪問的目的服務(wù)器建立連接的步驟包括判斷接收到的應(yīng)答握手信息的報文的源地址與源端口是否分別與客戶端請求訪問的目的服務(wù)器的目的地址和目的端口相符；如果相符，則判斷出檢測端與保存的請求訪問的目的服務(wù)器建立連接。根據(jù)本發(fā)明的另一方面，提供了一種協(xié)議代理檢測裝置，該裝置包括第一接收單元，用于在TCP連接建立時，接收應(yīng)答握手信息的報文；第一檢測單元，用于根據(jù)應(yīng)答握手信息的報文判斷TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的；第二接收單元，用于在應(yīng)答握手信息的報文是客戶端發(fā)起時，接收客戶端發(fā)送的請求信息；第一判斷單元，用于判斷請求信息是否是代理請求信息；第一保存單元，用于在請求信息是代理請求信息時，保存客戶端請求訪問的目的服務(wù)器信息；第二判斷單元，用于判斷檢測端是否與保存的請求訪問的目的服務(wù)器建立連接；第二檢測單元，用于在檢測端與保存的請求訪問的目的服務(wù)器建立連接時，檢測出采用了協(xié)議代理。第一檢測單元具體用于判斷接收到的應(yīng)答握手信息的報文的目的地址是否與檢測端的地址相符；如果相符，判斷出TCP連接是檢測端發(fā)起的；如果不相符，判斷出TCP連接是客戶端發(fā)起的。協(xié)議代理檢測裝置還包括第三接收單元，用于在TCP連接建立時，接收TCP報文； 第三判斷單元，用于判斷TCP報文是否為應(yīng)答握手信息的報文；第四判斷單元，用于在TCP 報文不是應(yīng)答握手信息的報文時，判斷TCP報文是否是結(jié)束報文；第五判斷單元，用于在 TCP報文不是結(jié)束報文時，判斷TCP報文是否滿足代理協(xié)議特征；第二保存單元，用于在TCP 報文滿足代理協(xié)議特征時，保存TCP報文請求訪問的目的服務(wù)器信息。第三判斷單元包括判斷模塊，用于判斷TCP報文是否為應(yīng)答握手信息的報文；生成模塊，用于在判斷出TCP報文是應(yīng)答握手信息的報文時，根據(jù)TCP報文的連接四元素生成與TCP報文對應(yīng)的表項，插入到TCP過濾表中，并接收TCP報文；第一查找模塊，用于在判斷出TCP報文不是應(yīng)答握手信息的報文時，以TCP報文的TCP連接四元素為索引在TCP過濾表中查找是否有與報文對應(yīng)的表項，并在查找成功時，接收TCP報文。第一判斷單元包括提取模塊，用于在TCP連接是客戶端發(fā)起的時，提取應(yīng)答握手信息的報文的TCP連接四元素插入到代理客戶端請求連接表中，判斷接收到的請求信息是否滿足代理協(xié)議特征，并在請求信息滿足代理協(xié)議特征時，保存請求信息的報文請求訪問的目的服務(wù)器信息到代理客戶端請求連接表中；第二查找模塊，用于在TCP連接是檢測端發(fā)起的時，提取客戶端的地址和端口在代理客戶端請求連接表中查找，并在查找成功時，檢測出采用了協(xié)議代理。
目的服務(wù)器信息包括目的服務(wù)器的目的地址和目的端口。第二判斷單元具體用于判斷接收到的應(yīng)答握手信息的報文的源地址與源端口是否分別與客戶端請求訪問的目的服務(wù)器的目的地址和目的端口相符；如果相符，判斷出檢測端與保存的請求訪問的目的服務(wù)器建立連接。通過本發(fā)明，采用在應(yīng)答握手信息的報文時判斷出TCP連接是誰發(fā)起的，并且根據(jù)發(fā)起端判斷是否采用了代理來進(jìn)行代理協(xié)議的檢測，解決了對是否采用了代理協(xié)議檢測效率 低，且會漏報誤報的問題，進(jìn)而達(dá)到了檢測是否采用協(xié)議代理效率高，檢測結(jié)果準(zhǔn)確的效果。


此處所說明的附圖用來提供對本發(fā)明的進(jìn)一步理解，構(gòu)成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中圖1是根據(jù)相關(guān)技術(shù)的客戶端向SOCKS 4代理服務(wù)器發(fā)送的連接請求包的格式示意圖；圖2是根據(jù)相關(guān)技術(shù)的代理服務(wù)器給客戶端發(fā)送的回應(yīng)包的格式示意圖；圖3是根據(jù)相關(guān)技術(shù)的簡單操作系統(tǒng)網(wǎng)絡(luò)體系示意圖；圖4是根據(jù)相關(guān)技術(shù)的代理行為的流程圖；圖5是根據(jù)本發(fā)明實施例的協(xié)議代理檢測裝置的一種優(yōu)選結(jié)構(gòu)框圖；圖6是根據(jù)本發(fā)明實施例的協(xié)議代理檢測裝置的另一種結(jié)構(gòu)框圖；圖7是根據(jù)本發(fā)明實施例的協(xié)議代理檢測方法的一種優(yōu)選流程圖；圖8是根據(jù)本發(fā)明實施例的協(xié)議代理檢測方法的另一種流程圖。圖9是根據(jù)本發(fā)明實施例的協(xié)議代理檢測方法的又一種示意圖。
具體實施例方式下文中將參考附圖并結(jié)合實施例來詳細(xì)說明本發(fā)明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。實施例1圖5出示了的一種協(xié)議代理檢測裝置的優(yōu)選結(jié)構(gòu)框圖，參見圖5，該裝置包括依次連接的第一接收單元501、第一檢測單元502、第二接收單元503、第一判斷單元504、第一保存單元505、第二判斷單元506以及第二檢測單元507，其中第一接收單元501在TCP連接建立時，接收應(yīng)答握手信息的報文；第一檢測單元502根據(jù)應(yīng)答握手信息的報文判斷TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的；第二接收單元503在應(yīng)答握手信息的報文是客戶端發(fā)起時，接收客戶端發(fā)送的請求信息；第一判斷單元504判斷請求信息是否是代理請求信息；第一保存單元505在請求信息是代理請求信息時，保存客戶端請求訪問的目的服務(wù)器信息；第二判斷單元506判斷檢測端是否與保存的請求訪問的目的服務(wù)器建立連接；
第二檢測單元507在檢測端與保存的請求訪問的目的服務(wù)器建立連接時，檢測出采用了協(xié)議代理。其中，應(yīng)答握手信息的報文指的是三次握手報文中的第2個報文，即參見圖4中的 syn_ack才艮文。上述的目的服務(wù)器信息包括目的服務(wù)器的目的地址和目的端口。其中，第一檢測 單元502具體判斷接收到的應(yīng)答握手信息的報文的目的地址是否與檢測端的地址相符；如果相符，判斷出TCP連接是檢測端發(fā)起的；如果不相符，判斷出TCP 連接是客戶端發(fā)起的。第二判斷單元506具體用于判斷接收到的應(yīng)答握手信息的報文的源地址與源端口是否分別與客戶端請求訪問的目的服務(wù)器的目的地址和目的端口相符；如果相符，判斷出檢測端與保存的請求訪問的目的服務(wù)器建立連接。在本優(yōu)選實施例中，采用在應(yīng)答握手信息的報文時判斷出TCP連接是誰發(fā)起的， 并且根據(jù)發(fā)起端判斷是否采用了代理來進(jìn)行代理協(xié)議的檢測，解決了對是否采用了代理協(xié)議檢測效率低，且會漏報誤報的問題，進(jìn)而達(dá)到了檢測是否采用協(xié)議代理效率高，檢測結(jié)果準(zhǔn)確的效果?；趫D5，圖6出示了協(xié)議代理檢測裝置的另一種結(jié)構(gòu)框圖，該裝置還包括連接第三接收單元508的第三判斷單元509，第三判斷單元509連接第一接收單元501和第四判斷單元510，第四判斷單元510依次連接第五判斷單元511和第二保存單元512、第二保存單元512還連接第二判斷單元506，其中第三接收單元508在TCP連接建立時，接收TCP報文；第三判斷單元509判斷TCP報文是否為應(yīng)答握手信息的報文；第四判斷單元510在TCP報文不是應(yīng)答握手信息的報文時，判斷TCP報文是否是結(jié)束報文；第五判斷單元511在TCP報文不是結(jié)束報文時，判斷TCP報文是否滿足代理協(xié)議特征；第二保存單元512在TCP報文滿足代理協(xié)議特征時，保存TCP報文請求訪問的目的服務(wù)器信息。在本優(yōu)選實施例中，進(jìn)一步判斷不是應(yīng)答握手信息的報文，且不是結(jié)束報文的TCP 報文是否滿足代理協(xié)議，如果滿足代理協(xié)議，同樣可以檢測出采用了協(xié)議代理，從而進(jìn)一步防止漏報和誤報，使檢測結(jié)果更加準(zhǔn)確。同時，第三判斷單元509可以包括判斷模塊5091、連接判斷模塊5091的生成模塊5092和第一查詢模塊5093，生成模塊5092和第一查詢模塊5093分別連接第一接收單元 501，連接第四判斷單元510其中判斷模塊5091判斷TCP報文是否為應(yīng)答握手信息的報文；生成模塊5092在判斷出TCP報文是應(yīng)答握手信息的報文時，根據(jù)TCP報文的連接四元素生成與TCP報文對應(yīng)的表項，插入到TCP過濾表中，并接收TCP報文；第一查找模塊5093在判斷出TCP報文不是應(yīng)答握手信息的報文時，以TCP報文的 TCP連接四元素為索引在TCP過濾表中查找是否有與報文對應(yīng)的表項，并在查找成功時，接收TCP報文。
在本優(yōu)選實施例中，在收到TCP報文之前，對TCP報文進(jìn)行初步判斷，從而在對需要判斷的報文進(jìn)行判斷之前就對不必要處理的報文進(jìn)行了過濾，節(jié)省了從不必要的報文發(fā)送和判斷。第一判斷單元504包括連接第二接收單元503的提取模塊5041和第二查詢模塊 5042，提取模塊5041還連接第一保存單元505。提取模 塊5021在TCP連接是客戶端發(fā)起的時，提取應(yīng)答握手信息的報文的TCP 連接四元素插入到代理客戶端請求連接表中，判斷接收到的請求信息是否滿足代理協(xié)議特征，并在請求信息滿足代理協(xié)議特征時，告知第一保存單元505保存請求信息的報文請求訪問的目的服務(wù)器信息到代理客戶端請求連接表中；第二查找模塊5022在TCP連接是檢測端發(fā)起的時，提取客戶端的地址和端口在代理客戶端請求連接表中查找，并在查找成功時，檢測出采用了協(xié)議代理。在本優(yōu)選實施例中，通過區(qū)分TCP連接是哪一端發(fā)起的，并采用代理客戶端請求連接表進(jìn)行記錄，簡化了判斷流程，提高了判斷速度。值得說明的是，上述第一、第二、第三等等僅僅用來區(qū)分不同的主體，并不用于限定不同的主體，例如第一判斷單元還可以稱為第二判斷單元等。其中，本實施例中的協(xié)議代理檢測裝置可設(shè)置于任何一個通信設(shè)備中，當(dāng)該通信設(shè)備作為代理服務(wù)器時，利用本實施例的協(xié)議代理檢測裝置可以檢測出該通信設(shè)備提供了代理服務(wù)。實施例2圖7出示了協(xié)議代理檢測方法的一種優(yōu)選流程圖，參見圖7，該方法包括S701，在TCP連接建立時，接收應(yīng)答握手信息的報文；S702，根據(jù)應(yīng)答握手信息的報文判斷TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的；S703，若應(yīng)答握手信息的報文是客戶端發(fā)起的，則接收客戶端發(fā)送的請求信息；S704,判斷請求信息是否是代理請求信息；S705，如果請求信息是代理請求信息，則保存客戶端請求訪問的目的服務(wù)器信息；S706，判斷檢測端是否與保存的請求訪問的目的服務(wù)器建立連接；S707,若檢測端與保存的請求訪問的目的服務(wù)器建立連接，則檢測出采用了協(xié)議代理。上述的目的服務(wù)器信息包括目的地址和目的端口。其中步驟S702，根據(jù)應(yīng)答握手信息的報文判斷TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的步驟具體包括判斷接收到的應(yīng)答握手信息的報文的目的地址是否與檢測端的地址相符；如果相符，則判斷出TCP連接是檢測端發(fā)起的；如果不相符，則判斷出TCP連接是客戶端發(fā)起的。步驟S706，判斷檢測端是否與保存的請求訪問的目的服務(wù)器建立連接的步驟具體包括判斷接收到的應(yīng)答握手信息的報文的源地址與源端口是否分別與客戶端請求訪問的目的服務(wù)器的目的地址和目的端口相符；如果相符，則判斷出檢測端與保存的請求訪問的目的服務(wù)器建立連接。
在本優(yōu)選實施例中，采用在應(yīng)答握手信息的報文時判斷出TCP連接是誰發(fā)起的， 并且根據(jù)發(fā)起端判斷是否采用了代理來進(jìn)行代理協(xié)議的檢測，解決了對是否采用了代理協(xié)議檢測效率低，且會漏報誤報的問題，進(jìn)而達(dá)到了檢測是否采用協(xié)議代理效率高，檢測結(jié)果準(zhǔn)確的效果?；趫D7，圖8出示了協(xié)議代理檢測方法的另一種流程圖，參見圖8，檢測協(xié)議代理的方法還包括S708，在TCP連接建立時，接收TCP報文；S709，判斷TCP報文是否為應(yīng)答握手信息的報文；S710，若TCP報文不是應(yīng)答握手信息的報文，則判斷TCP報文是否是結(jié)束報文；S711，若TCP報文不是結(jié)束報文，則判斷TCP報文是否滿足代理協(xié)議特征；若TCP 報文是應(yīng)答握手信息的報文，則執(zhí)行步驟S702，根據(jù)應(yīng)答握手信息的報文判斷TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的；S712，若TCP報文滿足代理協(xié)議特征，則保存TCP報文請求訪問的目的服務(wù)器信
肩、ο在本優(yōu)選實施例中，進(jìn)一步判斷不是應(yīng)答握手信息的報文，且不是結(jié)束報文的TCP 報文是否滿足代理協(xié)議，如果滿足代理協(xié)議，同樣可以檢測出采用了協(xié)議代理，從而進(jìn)一步防止漏報和誤報，使檢測結(jié)果更加準(zhǔn)確。步驟S709，判斷TCP報文是否為應(yīng)答握手信息的報文的步驟包括S7091，判斷TCP報文是否為應(yīng)答握手信息的報文；S7092，若判斷出TCP報文是應(yīng)答握手信息的報文，則根據(jù)TCP報文的連接四元素生成與TCP報文對應(yīng)的表項，插入到TCP過濾表中，并接收TCP報文；S7093，若判斷出TCP報文不是應(yīng)答握手信息的報文，則以TCP報文的TCP連接四元素為索引在TCP過濾表中查找是否有與報文對應(yīng)的表項，并在查找成功時，接收TCP報文。在本優(yōu)選實施例中，在檢測端收到TCP報文之前，對TCP報文進(jìn)行初步判斷，從而在報文到達(dá)檢測端之前就對不必要處理的報文進(jìn)行了過濾，節(jié)省了從不必要的報文發(fā)送和判斷。若TCP報文是應(yīng)答握手信息的報文，則執(zhí)行步驟S702，根據(jù)應(yīng)答握手信息的報文判斷TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的步驟，步驟S703，若應(yīng)答握手信息的報文是客戶端發(fā)起的，則接收客戶端發(fā)送的請求信息，以及步驟S704，判斷請求信息是否是代理請求信息的步驟，其中，步驟S704，判斷請求信息是否是代理請求信息的步驟具體包括若TCP連接是客戶端發(fā)起的，則提取應(yīng)答握手信息的報文的TCP連接四元素插入到代理客戶端請求連接表中，判斷接收到的請求信息是否滿足代理協(xié)議特征，并在請求信息滿足代理協(xié)議特征時，保存請求信息的報文請求訪問的目的服務(wù)器信息到代理客戶端請求連接表中；若TCP連接是檢測端發(fā)起的，則提取客戶端的地址和端口在代理客戶端請求連接表中查找，并在查找成功時，檢測出采用了協(xié)議代理。在本優(yōu)選實施例中，通過區(qū)分TCP連接是哪一端發(fā)起的，并采用代理客戶端請求連接表進(jìn)行記錄，簡化了判斷流程，提高了判斷速度。
值得說明的是，上述第一、第二、第三等等僅僅用來區(qū)分不同的主體，并不用于限定不同的主體，例如第一判斷單元還可以稱為第二判斷單元等。實施例3本實施例提供了協(xié)議代理檢測方法的一個具體實例，在本實施例中，圖9出示了協(xié)議代理檢測方法的又一種示意圖，由圖9可見，協(xié)議代理檢測裝置包括依次連接的驅(qū)動收包模塊和應(yīng)用層報文處理模塊。其中，驅(qū)動收包模塊具體通過如下步驟執(zhí)行功能S901，驅(qū)動收包模塊收到一個TCP報文；S902，判斷該TCP報文是否為三次握手的第2個報文，即應(yīng)答握手信息的報文syn_ ack,若是，則以該報文的TCP連接四元素生成一個表項插入到TCP過濾表中，并把該報文發(fā)送到應(yīng)用層報文處理模塊。若不是，則說明該報文可能為結(jié)束報文可能為數(shù)據(jù)報文還可能為確認(rèn)報文，這時，以該報文的TCP連接四元素為索引在TCP過濾表中查找是否存在該報文的TCP連接四元素，查找成功則把該報文發(fā)送到應(yīng)用層報文處理模塊；查找失敗，則丟棄。由此，驅(qū)動層僅僅對存在在TCP過濾表中的報文進(jìn)行發(fā)送，對不必要處理的報文進(jìn)行過濾，節(jié)省了從驅(qū)動層到應(yīng)用層不必要的報文發(fā)送。也就是說，驅(qū)動收包模塊可執(zhí)行上述第三接收單元508的功能。應(yīng)用層報文處理模塊通過以下步驟執(zhí)行功能S903，應(yīng)用層報文處理模塊收到驅(qū)動收包模塊發(fā)送一個TCP報文；S904，判斷該TCP報文是否為三次握手的第2個報文，即應(yīng)答握手信息的報文syn_ ack,不是則執(zhí)行步驟S905 ；是則根據(jù)接收到的報文的目的MAC地址可以判斷該TCP連接是 “檢測端主動發(fā)起的TCP連接”，還是“另一端主動發(fā)起的TCP連接”。若是“另一端主動發(fā)起的TCP連接”則有可能是代理客戶端發(fā)起的TCP連接，提取該報文的TCP連接四元素插入到“代理客戶端請求連接表”。若是“檢測端主動發(fā)起的TCP連接”，則提取另一端的地址和端口作為代理請求的目的地址和代理請求目的端口在“代理客戶端請求連接表”中查找相應(yīng)表項。若查找失敗， 則說明該條“檢測端主動發(fā)起的連接”沒有提供代理行為，則刪除該TCP過濾表項；若查找成功，則說明該條“檢測端主動發(fā)起的TCP連接”為查找到的TCP連接提供代理服務(wù)，即檢測到代理。S905，判斷接收到的TCP報文是否結(jié)束(final)報文，不是則執(zhí)行步聚S906 ；是則從“代理客戶端請求連接表”中刪除此連接表項，并刪除該TCP過濾表項。S906，判斷該TCP報文是否是數(shù)據(jù)報文，如果不是數(shù)據(jù)報文則丟棄不處理；如果是數(shù)據(jù)報文，則以該報文的TCP連接四元素為索引在“代理客戶端請求連接表”中查找。查找失敗，則刪除該TCP過濾表項；查找成功，則查看該TCP數(shù)據(jù)報文是否滿足代理協(xié)議特征；若不滿足代理協(xié)議特征，則把該連接從“代理客戶端請求連接表”中刪除， 并刪除該TCP過濾表項；若滿足代理協(xié)議特征，則獲取代理請求的目的地址和目的端口，并保存步驟S904查找到的“代理客戶端請求連接表”中。該步驟即可采用第一檢測單元502 執(zhí)行。當(dāng)然，本發(fā)明僅僅對HTTP代理和SOCKS代理為例進(jìn)行的說明，但是在不違背本發(fā)明的精神的前提下，F(xiàn)TP, NNTP代理也應(yīng)視為屬于本發(fā)明的保護(hù)范圍。
13
通過以上描述，可以看出本實施例的優(yōu)點(diǎn)1.通過將TCP連接分為兩大類處理，以及在驅(qū)動收包層動態(tài)設(shè)置監(jiān)聽過濾表，減少了大量報文的分析處理，從而提高了檢測效率。2.通過代理協(xié)議特征分析代理請求的目的地址和端口，適應(yīng)各種代理服務(wù)器軟件，檢測結(jié)果準(zhǔn)確，不會存在誤判和漏判。從以上的描述中，可以看出，本發(fā)明實現(xiàn)了如下技術(shù)效果采用在應(yīng)答握手信息的報文時判斷出TCP連接是誰發(fā)起的，并且根據(jù)發(fā)起端判斷是否采用了代理來進(jìn)行代理協(xié)議的檢測，解決了對是否采用了代理協(xié)議檢測效率低，且會漏報誤報的問題，進(jìn)而達(dá)到了檢測是否采用協(xié)議代理效率高，檢測結(jié)果準(zhǔn)確的效果。顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡(luò)上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種協(xié)議代理檢測方法，其特征在于，包括 在TCP連接建立時，接收應(yīng)答握手信息的報文；根據(jù)所述應(yīng)答握手信息的報文判斷所述TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的； 若所述應(yīng)答握手信息的報文是所述客戶端發(fā)起的，則接收所述客戶端發(fā)送的請求信息；判斷所述請求信息是否是代理請求信息；如果所述請求信息是代理請求信息，則保存所述客戶端請求訪問的目的服務(wù)器信息； 判斷所述檢測端是否與保存的請求訪問的目的服務(wù)器建立連接； 若所述檢測端與保存的請求訪問的目的服務(wù)器建立連接，則檢測出采用了協(xié)議代理。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述根據(jù)所述應(yīng)答握手信息的報文判斷所述TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的步驟包括判斷所述接收到的所述應(yīng)答握手信息的報文的目的地址是否與所述檢測端的地址相符；如果相符，則判斷出所述TCP連接是檢測端發(fā)起的； 如果不相符，則判斷出所述TCP連接是客戶端發(fā)起的。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括 在TCP連接建立時，接收TCP報文；判斷所述TCP報文是否為應(yīng)答握手信息的報文；若所述TCP報文不是應(yīng)答握手信息的報文，則判斷所述TCP報文是否是結(jié)束報文，若所述TCP報文是應(yīng)答握手信息的報文，則根據(jù)所述應(yīng)答握手信息的報文判斷所述TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的；若所述TCP報文不是結(jié)束報文，則判斷所述TCP報文是否滿足代理協(xié)議特征； 若所述TCP報文滿足代理協(xié)議特征，則保存所述TCP報文請求訪問的目的服務(wù)器信息。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述判斷所述TCP報文是否為應(yīng)答握手信息的報文步驟包括判斷所述TCP報文是否為應(yīng)答握手信息的報文；若判斷出所述TCP報文是應(yīng)答握手信息的報文，則根據(jù)所述TCP報文的連接四元素生成與所述TCP報文對應(yīng)的表項，插入到TCP過濾表中，并接收所述TCP報文；若判斷出所述TCP報文不是應(yīng)答握手信息的報文，則以所述TCP報文的TCP連接四元素為索引在所述TCP過濾表中查找是否有與所述報文對應(yīng)的表項，并在查找成功時，接收所述TCP報文。
5.根據(jù)權(quán)利要求3所述的方法，其特征在于，判斷所述請求信息是否是代理請求信息的步驟還包括若所述TCP連接是客戶端發(fā)起的，則提取所述應(yīng)答握手信息的報文的TCP連接四元素插入到代理客戶端請求連接表中，判斷接收到的所述請求信息是否滿足代理協(xié)議特征，并在所述請求信息滿足代理協(xié)議特征時，保存所述請求信息的報文請求訪問的目的服務(wù)器信息到所述代理客戶端請求連接表中；若所述TCP連接是檢測端發(fā)起的，則提取客戶端的地址和端口在所述代理客戶端請求連接表中查找，并在查找成功時，檢測出采用了協(xié)議代理。
6.根據(jù)權(quán)利要求4或5所述的方法，其特征在于，所述目的服務(wù)器信息包括目的服務(wù)器的目的地址和目的端口。
7.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述判斷所述檢測端是否與保存的請求訪問的目的服務(wù)器建立連接的步驟包括判斷接收到的所述應(yīng)答握手信息的報文的源地址與源端口是否分別與所述客戶端請求訪問的目的服務(wù)器的目的地址和目的端口相符；如果相符，則判斷出所述檢測端與保存的請求訪問的目的服務(wù)器建立連接。
8.一種協(xié)議代理檢測裝置，其特征在于，包括第一接收單元，用于在TCP連接建立時，接收應(yīng)答握手信息的報文； 第一檢測單元，用于根據(jù)所述應(yīng)答握手信息的報文判斷所述TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的；第二接收單元，用于在所述應(yīng)答握手信息的報文是所述客戶端發(fā)起時，接收所述客戶端發(fā)送的請求信息；第一判斷單元，用于判斷所述請求信息是否是代理請求信息； 第一保存單元，用于在所述請求信息是代理請求信息時，保存所述客戶端請求訪問的目的服務(wù)器信息；第二判斷單元，用于判斷所述檢測端是否與保存的請求訪問的目的服務(wù)器建立連接； 第二檢測單元，用于在所述檢測端與保存的請求訪問的目的服務(wù)器建立連接時，檢測出采用了協(xié)議代理。
9.根據(jù)權(quán)利要求8所述的裝置，其特征在于，所述第一檢測單元具體用于判斷接收到的所述應(yīng)答握手信息的報文的目的地址是否與所述檢測端的地址相符；如果相符，判斷出所述TCP連接是檢測端發(fā)起的；如果不相符，判斷出所述TCP連接是客戶端發(fā)起的。
10.根據(jù)權(quán)利要求8所述的裝置，其特征在于，還包括 第三接收單元，用于在TCP連接建立時，接收TCP報文；第三判斷單元，用于判斷所述TCP報文是否為應(yīng)答握手信息的報文； 第四判斷單元，用于在所述TCP報文不是應(yīng)答握手信息的報文時，判斷所述TCP報文是否是結(jié)束報文；第五判斷單元，用于在所述TCP報文不是結(jié)束報文時，判斷所述TCP報文是否滿足代理協(xié)議特征；第二保存單元，用于在所述TCP報文滿足代理協(xié)議特征時，保存所述TCP報文請求訪問的目的服務(wù)器信息。
11.根據(jù)權(quán)利要求10所述的裝置，其特征在于，所述第三判斷單元包括 判斷模塊，用于判斷所述TCP報文是否為應(yīng)答握手信息的報文；生成模塊，用于在判斷出所述TCP報文是應(yīng)答握手信息的報文時，根據(jù)所述TCP報文的連接四元素生成與所述TCP報文對應(yīng)的表項，插入到TCP過濾表中，并接收所述TCP報文； 第一查找模塊，用于在判斷出所述TCP報文不是應(yīng)答握手信息的報文時，以所述TCP報文的TCP連接四元素為索引在所述TCP過濾表中查找是否有與所述報文對應(yīng)的表項，并在查找成功時，接收所述TCP報文。
12.根據(jù)權(quán)利要求10所述的裝置，其特征在于，所述第一判斷單元包括提取模塊，用于在所述TCP連接是客戶端發(fā)起的時，提取所述應(yīng)答握手信息的報文的 TCP連接四元素插入到代理客戶端請求連接表中，判斷接收到的所述請求信息是否滿足代理協(xié)議特征，并在所述請求信息滿足代理協(xié)議特征時，保存所述請求信息的報文請求訪問的目的服務(wù)器信息到所述代理客戶端請求連接表中；第二查找模塊，用于在所述TCP連接是檢測端發(fā)起的時，提取客戶端的地址和端口在所述代理客戶端請求連接表中查找，并在查找成功時，檢測出采用了協(xié)議代理。
13.根據(jù)權(quán)利要求11或12所述的裝置，其特征在于，所述目的服務(wù)器信息包括目的服務(wù)器的目的地址和目的端口。
14.根據(jù)權(quán)利要求13所述的裝置，其特征在于，所述第二判斷單元具體用于判斷接收到的所述應(yīng)答握手信息的報文的源地址與源端口是否分別與所述客戶端請求訪問的目的服務(wù)器的目的地址和目的端口相符；如果相符，判斷出所述檢測端與保存的請求訪問的目的服務(wù)器建立連接。
全文摘要
本發(fā)明提供了一種協(xié)議代理檢測方法和裝置，其中，該方法包括在TCP連接建立時，接收應(yīng)答握手信息的報文；根據(jù)應(yīng)答握手信息的報文判斷TCP連接是檢測端發(fā)起的還是客戶端發(fā)起的；若應(yīng)答握手信息的報文是客戶端發(fā)起的，則接收客戶端發(fā)送的請求信息；判斷請求信息是否是代理請求信息；如果請求信息是代理請求信息，則保存客戶端請求訪問的目的服務(wù)器信息；判斷檢測端是否與保存的請求訪問的目的服務(wù)器建立連接；若檢測端與保存的請求訪問的目的服務(wù)器建立連接，則檢測出采用了協(xié)議代理。本發(fā)明解決了對是否采用了代理協(xié)議檢測效率低，且會漏報誤報的問題，進(jìn)而達(dá)到了檢測是否采用協(xié)議代理效率高，檢測結(jié)果準(zhǔn)確的效果。
文檔編號H04L29/06GK102223266SQ20111016320
公開日2011年10月19日 申請日期2011年6月17日 優(yōu)先權(quán)日2011年6月17日
發(fā)明者溫寅豐 申請人:北京星網(wǎng)銳捷網(wǎng)絡(luò)技術(shù)有限公司