基於http的客戶端類型的識別方法和裝置的製作方法

2023-04-26 07:52:41

專利名稱：基於http的客戶端類型的識別方法和裝置的製作方法
技術領域：
本發明涉及網絡技術領域，特別涉及一種基於HTTP的客戶端類型的識別方法和裝置。
背景技術：
隨著計算機和網絡技術的快速發展，計算機網絡與人們生活越來越密切，用戶可以通過網絡下載資源，以供學習、休閒及娛樂等。最簡單的下載方法就是在瀏覽器上直接下載資源，如ΙΕ6、ΙΕ7、ΙΕ8、firefox,360瀏覽器等。使用瀏覽器下載資源通用性強，但其下載速度慢、不支持斷點續傳等。為了加快下載速度，用戶通常藉助下載工具來實現資源的下載，常用的下載工具如網絡快車(FlashGet)、迅雷、qq超級旋風等。超文本傳輸協議(HyperText Transfer Protocol,HTTP)是計算機之間交換數據的方式,是客戶端和伺服器端請求和響應的標準。它是一種從WEB伺服器下載超文本到本地瀏覽器的一種傳輸協議。多數下載工具採用HTTP協議連接資源，以進行資源下載。但資源下載過程中，會佔用大量網絡帶寬，容易導致網絡擁塞或中斷，大大降低了網絡性能，防礙了正常的網絡業務的開展；在下載的同時，還容易使病毒入侵內部網絡，造成嚴重的內部網絡安全隱患，因此，需要高效地識別出網絡中的各種應用，從而進行帶寬限速和應用協議阻斷等處理。目前，常採用深度包檢測(Deep Packet Inspection, DPI)以識別出網絡中的各種應用。在採用DPI進行客戶端類型的識別時，一般是基於HTTPheader (頭部)消息和HTTPbody (實體)消息中的特有特徵與本地存儲的特有特徵進行匹配，這樣就需要較大的內存空間用於存儲HTTP header消息和HTTP body消息，以及大量的特有特徵；由於需要對大量的特有特徵進行匹配，導致處理效率低。綜上所述，現有客戶端類型識別過程中，需要較大的存儲空間，且處理效率低。

發明內容
本發明實施例提供了一種基於HTTP的客戶端類型的識別方法和裝置，用於解決現有客戶端類型識別過程中，需要較大的存儲空間，且處理效率低的問題。本發明實施例提供了一種基於HTTP的客戶端類型的識別方法，包括根據預先設定的參考頭域順序與客戶端類型的對應關係，確定接收到的來自客戶端的請求消息的消息頭中與所述對應關係中各參考頭域相同的頭域，其中，所述請求消息包括消息頭和消息體，所述消息頭中包含多個頭域；根據確定的頭域在所述消息頭中的排列順序以及所有對應關係中的參考頭域順序，確定所述客戶端的類型。本發明實施例提供了一種基於HTTP的客戶端類型的識別設備，該設備包括確定模塊，用於根據預先設定的參考頭域順序與客戶端類型的對應關係，確定接收到的來自客戶端的請求消息的消息頭中與所述對應關係中各參考頭域相同的頭域；匹配模塊，用於根據確定的頭域在所述消息頭中的排列順序以及所有對應關係中的參考頭域順序，確定所述客戶端的類型；其中，所述請求消息包括消息頭和消息體，所述消息頭中包含多個頭域。本發明實施例通過預設的多個參考頭域順序與客戶端類型之間的對應關係，確定請求消息的消息頭中與對應關係中的參考頭域相同的頭域在該消息頭中的排列順序，井根據確定的排列順序與對應關係中參考頭域順序進行匹配，以確定客戶端的類型。由於僅需要存儲每個請求消息的消息頭中部分或全部頭域的信息，而不需要存儲每個請求消息的消息體，也不需要存儲大量的特有特徵，從而節省了內存空間；由於不需要進行大量特有特徵的匹配，從而有效提高了處理效率。


圖I為本發明實施例一種基於HTTP的客戶端類型的識別方法的流程示意
圖3為本發明實施例另ー種基於HTTP的客戶端類型的識別方法的流程示意圖；圖4為本發明實施例基於HTTP的客戶端類型的識別設備的結構示意圖。
具體實施例方式本發明通過預設的多個參考頭域順序與客戶端類型之間的對應關係，確定請求消息的消息頭中與對應關係中的參考頭域相同的頭域在該消息頭中的排列順序，井根據確定的排列順序與對應關係中參考頭域順序進行匹配，以確定客戶端的類型。從而節省了內存空間，提聞了處通效率。本發明實施例可以應用於不同類型客戶端發送的HTTP協議請求消息的消息頭中相同的頭域的排列順序不同的情況，也可以應用於不同類型客戶端發送的HTTP協議請求消息的消息頭中相同順序的頭域的具有的特有特徵不同的情況。在使用客戶端進行下載資源的過程中，客戶端向伺服器發送請求消息，其中，請求消息包括消息頭(message-header)及消息體(message-body);消息頭中包括多個頭域,常見的頭域包括但不限於下列中的ー種或多種Get，用於指示所用的請求方法；Accept，用於指示客戶端能夠接收的內容類型；Cache-Control,用於指定請求和響應遵循的緩存機制；Connection,用於指示是否需要持久連接；Content-Length,用於指定請求的內容長度；Content-Type,用於指定請求的與實體對應的MIME信息；From,用於指定發出請求的用戶的Email ；Host，用於指定請求的伺服器的域名和埠號；Pragma，用於指定包含實現特定的指令；Date，用於表示消息發送的時間；Referer,用於允許客戶端指定請求uri的源資源地址；Expect，用於指定請求的特定的伺服器行為；User_agent,其內容包含發出請求的用戶信息。
下面結合說明書附圖對本發明實施例作進一步詳細描述。如圖I所示，本發明實施例基於HTTP的客戶端類型的識別方法，包括以下步驟步驟101、根據預先設定的參考頭域順序與客戶端類型的對應關係，確定接收到的客戶端發送的請求消息中的消息頭中與對應關係中各參考頭域相同的頭域，其中，請求消息包括消息頭和消息體，消息頭中包含多個頭域；步驟102、根據確定的頭域在該消息頭中的排列順序與所有對應關係中的參考頭域順序，確定發送請求消息的客戶端的類型。在實施中，需要先建立不同客戶端類型所屬的對應關係，每個對應關係都是通過對已識別的客戶端發送的大量的HTTP協議請求消息的消息頭包含的各頭域的排列順序及具有的特有特徵，進行分析得到的，其中，對應關係中的參考頭域為已識別的客戶端對應的 所有頭域中的部分或全部。需要說明的是，建立的各種對應關係中任意兩個對應關係包含的參考頭域順序不同，或者在有至少兩個對應關係中包含的參考頭域順序相同時，該至少兩個對應關係中至少存在一個相同的參考頭域具有的特徵不同。在實施中，建立的所有對應關係米用哈希表的形式表不;其中，哈希表中的每個對應關係中的每個參考頭域都對應至少一個狀態信息和至少一個特徵信息，且將每個參考頭域的一個狀態信息與一個特徵信息作為一組，該組中的狀態信息與特徵信息是一一對應的；其中，哈希表中的狀態信息用於表示該參考頭域在該對應關係包含的所有參考頭域中的排列順序；例如，若該狀態信息的值為2，則表示該狀態信息所屬的參考頭域在該對應關係包含的所有參考頭域中排在第二個；哈希表中的特徵信息用於表示該參考頭域對應的特徵；例如，若對應關係中的某個參考頭域具有特徵(該特徵為該客戶端區別於其他客戶端的特徵)，則該參考頭域對應的特徵信息的值為該特徵；若對應關係中的某個參考頭域不具有特徵，則該參考頭域對應的特徵信息的值為「null (空值)」。以三種類型的客戶端(參考客戶端A、參考客戶端B及參考客戶端C)為例，每種客戶端對應的對應關係，如表I所示的哈希表，需要說明的是，為了說明方便，表I中以三種對應關係為例進行說明，該數量只是說明性的，而非限制性的。其中，表I所示的哈希表中每個對應關係中的每個參考頭域包括四個狀態信息和四個特徵信息，其中，一個狀態信息與一個特徵信息組成一組，且每組中的狀態信息與特徵信息是--對應的；狀態信息可以採用u8類型、ul6類型或u32類型等表示；若對應關係中的某個參考頭域具有特徵A，則可將該特徵A註冊到哈希表中該參考頭域對應的特徵信息中；例如，參考客戶端B對應的參考頭域「USer_agent」具有特徵「MSIE 6. O ;ffindows NT 5. I; SVl; 」，則可將該特徵添加至參考客戶端B對應的參考頭域「User_agent」的特徵信息中，即該參考頭域對應的特徵信息的值為「MSIE 6. O;Windows NT
5.I; SVl; 」 ;若對應關係中的某個參考頭域不具有特徵，則該參考頭域對應的特徵信息的值為「null (空值)」。為了提高識別處理的效率，各對應關係中具有特徵的參考頭域的數量應該儘量少ー些。表I所示的哈希表中的處理函數主要包括檢測狀態、特徵匹配及判斷當前處理的參考頭域是否為該對應關係中的最後ー個參考頭域；其中，檢測狀態是指，對某個參考頭域在其所屬的對應關係中的排列順序及消息頭中與該參考頭域對應的頭域在消息頭中的排列順序進行匹配，若兩者相同，則匹配成功；若兩者不同，則匹配失敗；特徵匹配是指，在某個對應關係中的某個參考頭域具有特徵，且消息頭中與該參考頭域對應的頭域具有特有特徵時，判斷該頭域具有的特有特徵是否包含該參考頭域的特徵，若是，則匹配成功；若否，則匹配失敗；如果某個參考頭域不具有特徵(即哈希表中該參考頭域對應的特徵信息的值為「null」)，則不需要進行該參考頭域的特徵匹配處理。
f狀態信息和特徵信息I
參考頭域名稱--- 處理函數
參考客戶端A 參考客.戶端B 參考客戶端C
I ,null: I..null; l，nuil;0,nul丨； I ,null;0,null; 檢測狀態和特
^jet0,rmll;0;null; 0,null;0;null; 0,null;0;null;徵匹配
.、2,null;2,null; 2,null;0,null; 3,null;0,null; 檢測狀態和特
ノ し cePt0,null ;0,null; 0jiull;0,null; 0.;nul1;0;null;徵匹配
3,nuli;3.rmll; 3,nu!l;0,null; 0,nuII;0jiu!I; 檢測狀態和特 acie_contio 0,null;0,null; 0;null:0,null; 0,null;0.null;徵匹配
「 .4，null;4,mill; 4,null;0;null; (^nulhOjiuII; 4 僉測狀態和特
onnection Ojmil;0,null; 0,nuii;0,null; 0,nul!;0,null;徵匹兩己
H5,null;5,null; 5，mill;0，mxll; 2,null;0,null; 檢測狀態和特
°St0,nuIl;0,niill; 0,niill;,inili; 0,mi[l;0,null;徵匹 1
^6,nuil;6;null; 6;nuii;0,null; 0,nul!;0,null; 檢測狀態和特
rayna0jiull;0,null; 0;null:0,null; 0,null;0.null;徵匹配
O5Imll ス null; 7,null;0 null; 45null;0 null; 檢測狀態和特 し eier0 null;0juill; 0,nuil;0.null; 0,nuIi;0,nuiI;4正匹面己
8，{MSIE 6.0;
Ut 7,null;8,null; ^mclSVl-fT 5,null;0,nuil;檢測狀態和特
LbU-a en0,null;0,rmll;'' ^ ル」， 0,null;0,nuil;徵匹配
0,null ;0,null表I其中，對應關係中的參考頭域順序以每個參考頭域的狀態信息的值表示，每個參考頭域的同一組狀態信息表示一種參考頭域順序，以參考客戶端A為例，其所屬的對應關係中包含兩種不同的參考頭域順序，每個參考頭域的第一組狀態信息和特徵信息中的狀態信息所表不的參考頭域順序為 Get — Accept — Cache_control — Connection — Host — Pragam — User_agent ;姆個參考頭域的第二組狀態信息和特徵信息中的狀態信息所表示的參考頭域順序為 Get — Accept — Cache_control — Connection — Host — Pragam — Referer — User_agent ；需要說明的是，若某個參考客戶端類型的對應關係中包含兩種或兩種以上的參考頭域順序，則在進行狀態信息的匹配時，只要滿足其中任一一種參考頭域順序即認為待識別的客戶端發送的請求消息的頭域滿足該對應關係。進ー步，若對應關係中的部分或全部參考頭域具有特徵，則步驟102中在確定發送請求消息的客戶端的類型進一歩包括根據確定的頭域在該消息頭中的排列順序與所有對應關係中的參考頭域順序，以及與具有特徵的參考頭域對應的頭域具有的特有特徵，確定發送請求消息的客戶端的類型。進ー步，步驟102中根據確定的頭域在該消息頭中的排列順序與所有對應關係中的參考頭域順序，確定發送請求消息的客戶端的類型，包括以下四種情況 第一種情況步驟101中確定的頭域在該消息頭中的排列順序僅與某ー個對應關係中的參考頭域順序相同；進ー步包括以下兩種情況一、與頭域排列順序相同的參考頭域順序所屬的對應關係中的所有參考頭域都不具有特徵，則確定發送請求消息的客戶端的類型為該對應關係中的客戶端類型；ニ、與頭域排列順序相同的參考頭域順序所屬的對應關係中的部分或全部參考頭域具有特徵，則在消息頭中與具有特徵的參考頭域對應的頭域具有的特有特徵包含該參考頭域的特徵時，確定發送請求消息的客戶端的類型為該對應關係中的客戶端類型；在消息頭中與具有特徵的參考頭域對應的頭域具有的特有特徵不包含該參考頭域的特徵，或在消息頭中與具有特徵的參考頭域對應的頭域不具有特有特徵時，確定本次識別失敗。例如，以表I所示的三種對應關係為例，若請求消息中消息頭中包括的頭域為Get、Accept、Connection、Host、Referer及User_agent,且各頭域在消息頭中的排列順序為 Get — Host — Accept — Referer — User_agent — Connection,即與第三種對應關係中的參考頭域順序相同，且第三種對應關係中的各參考頭域的特徵信息的值均為「null」，因此不需要進行特徵匹配，則確定發送該請求消息的客戶端的類型為參考客戶端C ；若請求消息中消息頭中的頭域的數量大於對應關係中參考頭域的數量，例如該消息頭中包括的頭域為Get、Date、Accept、Connection、Host、Referer及User_agent,其排列順序為 Get — Date — Host — Accept — Referer — User_agent — Connection,則確定的消息頭中與對應關係中的參考頭域相同的頭域為Get、Accept、Connection、Host、Referer及User_agent,該些頭域在該消息頭中的排列順序為Get — Host — Accept — Referer — User_agent — Connection,可見，該排列順序與第三種對應關係中的參考頭域順序相同，且第三種對應關係中的各參考頭域的特徵信息的值均為「null」，因此不需要進行特徵匹配，則確定發送該請求消息的客戶端的類型為參考客戶
端Co第二種情況步驟101中確定的頭域的排列順序與至少兩個對應關係中的參考頭域順序相同，且該至少兩個對應關係中某個第一參考頭域具有互不相同的特徵，其中，定義第一參考頭域為該至少兩個對應關係中相同的參考頭域；
進一步，步驟102中確定發送請求消息的客戶端的類型包括確定請求消息的消息頭中與第一參考頭域對應的第一頭域，其中，第一頭域為請求消息的消息頭中與第一參考頭域相同的頭域；若第一頭域具有特有特徵，且該第一頭域的特有特徵包含該至少兩個對應關係中某個對應關係的對應的第一參考頭域的特徵，則確定發送請求消息的客戶端的類型為該對應關係中的客戶端類型；若第一頭域具有特有特徵，且該第一頭域的特有特徵不包含該至少兩個對應關係中任一對應關係的對應的第一參考頭域的特徵，則確定本次 識別失敗；若第一頭域不具有特有特徵，則確定本次識別失敗。第三種情況步驟101中確定的頭域的排列順序與至少兩個對應關係中的參考頭域順序相同，且該至少兩個對應關係中某個第一參考頭域中，有一個對應關係的第一參考頭域不具有特徵，其餘對應關係中的該個第一參考頭域具有互不相同的特徵，其中第一參考頭域為該至少兩個對應關係中相同的參考頭域；進一步，步驟102中確定發送請求消息的客戶端的類型包括確定請求消息的消息頭中與第一參考頭域對應的第一頭域，其中，第一頭域為請求消息的消息頭中與第一參考頭域相同的頭域；若第一頭域具有特有特徵，且該第一頭域的特有特徵包含該至少兩個對應關係中某個對應關係的對應的第一參考頭域的特徵，則確定客戶端的類型為該對應關係中的客戶端類型；若第一頭域具有特有特徵，且該第一頭域的特有特徵不包含該至少兩個對應關係中任一對應關係的對應的第一參考頭域的特徵，則確定客戶端的類型為不具有特徵的第一參考頭域所屬的對應關係中的客戶端類型；若第一頭域不具有特有特徵，則確定客戶端的類型為不具有特徵的第一參考頭域所屬的對應關係中的客戶端類型。以表I所示的哈希表的三種對應關係為例，若確定的請求消息中消息頭包含的頭域在該消息頭中的排列順序與第一種對應關係及第二種對應關係中的參考頭域順序相同，則對確定的排列順序中最後一個頭域進行特徵匹配，若該頭域具有的特有特徵中包含「MSIE 6. 0;ffindows NT 5. I; SVl ; 」，則確定發送該請求消息的客戶端的類型為第二種對應關係中的客戶端B ;若該頭域具有的特有特徵中不包含「MSIE 6. O ;ffindows NT 5. I; SVl ；"則確定發送該請求消息的客戶端的類型為第一種對應關係中的客戶端A;若該頭域不具有特有特徵，則確定發送該請求消息的客戶端的類型為第一種對應關係中的客戶端A ;又如，若確定的頭域的排列順序與三個對應關係中參考頭域順序相同，且第一個對應關係中某一個參考頭域具有特有特徵A，第二個對應關係中同一個參考頭域具有特有特徵B，第三個對應關係中同一個參考頭域不具有特有特徵，則請求消息的消息頭中與該參考頭域對應的第一頭域，若該第一頭域中具有特有特徵，且該特有特徵的內容包含特徵信息A，則確定發送請求消息的客戶端的類型為第一個對應關係中的客戶端類型；若該第一頭域中具有的特有特徵包含特徵信息B，則確定發送請求消息的客戶端的類型為第二個對應關係中的客戶端類型；若該第一頭域中具有的特有特徵不包含特徵信息A和特徵信息B，則確定發送請求消息的客戶端的類型為第三個對應關係中的客戶端類型；若該第一頭域中不具有任何特有特徵，則確定發送請求消息的客戶端的類型為第三個對應關係中的客戶端類型。第四種情況步驟101中確定的頭域的排列順序與每個對應關係中的參考頭域順序都不相同，則確定本次識別失敗。進ー步，在部分或全部對應關係中的某個或某些參考頭域具有特徵時，步驟102中確定發送請求消息的客戶端的類型，包括以下兩種方式方式I、針對請求消息的消息頭中每個頭域，在某個或某些對應關係中包含與該頭域對應的參考頭域，且該頭域在已確定的與該個或該些對應關係中的參考頭域對應的頭域中的排列順序，與該個或該些對應關係中的部分或全部對應關係中已確定的參考頭域的排列順序相同時，若該個或該些對應關係中的部分或全部對應關係中與該頭域對應的參考頭域具有特徵，則對該參考頭域與該頭域進行特徵匹配；
其中，特徵匹配具體包括若該頭域中具有特有特徵，且該特有特徵包含對應的參考頭域的特徵，則匹配成功；若該頭域中具有特有特徵且該特有特徵不包含對應的參考頭域的特徵，或該頭域中不具有特有特徵，則匹配失敗。在消息頭中與某個對應關係中包含的參考頭域對應的頭域的排列順序，與該對應關係中參考頭域排列順序相同，且消息頭中與具有特徵的參考頭域對應的頭域的特有特徵，包含與其對應的參考頭域的特徵時，確定發送請求消息的客戶端類型為該對應關係中的客戶端類型。例如，以表I所示的哈希表為例對方式I的識別過程進行說明本方式的識別過程包括首先檢測消息頭中的第一個頭域，判斷哈希表中的各對應關係中是否包含該頭域對應的參考頭域；若是，則對該頭域及與其對應的參考頭域進行匹配處理，其中，匹配處理包括檢測狀態和特徵匹配(若該參考頭域不具有特徵，則不需要進行特徵匹配)，若匹配的結果是，該頭域與某一個或多個對應關係中對應的參考頭域匹配成功，則針對該個或該些匹配成功的對應關係，對消息頭中的下一個頭域進行匹配，直至最後ー個頭域匹配成功，則確定發送請求消息的客戶端的類型為與消息頭中的頭域匹配成功的對應關係中的客戶端類型；否貝U，確定本次識別失敗；若否，即消息頭中包含某個頭域，但哈希表中的各對應關係中不包含與其對應的參考頭域(如消息頭中包含頭域Date，而哈希表中各對應關係不包含Date對應的參考頭域)，則忽略該頭域，繼續對消息頭中的下一個頭域進行匹配。方式2、確定請求消息的消息頭中與對應關係中的每個參考頭域對應的頭域，在確定的所有頭域在該消息頭中的排列順序與某個或某些對應關係中的參考頭域順序相同之後，對具有特徵的參考頭域及消息頭中與該參考頭域對應的頭域進行特徵匹配；在消息頭中與某個對應關係中包含的參考頭域對應的頭域的排列順序，與該對應關係中參考頭域排列順序相同，且消息頭中與具有特徵的參考頭域對應的頭域的特有特徵，包含與其對應的參考頭域的特徵時，確定發送請求消息的客戶端類型為該對應關係中的客戶端類型。
例如，仍以表I所示的哈希表為例對方式2的識別過程進行說明本方式的識別過程包括先確定消息頭中與對應關係中的每個參考頭域對應的頭域及其在消息頭中的排列順序；再確定該排列順序與某個或某些對應關係中的參考頭域順序是否相同；若是，則判斷該個或該些對應關係中的參考頭域是否具有特徵(即判斷哈希表中該參考頭域對應的特徵信息的值是否不為「null」)；若某個或某些參考頭域具有特徵，則對該個或該些參考頭域及其對應的消息頭中的頭域進行特徵匹配，直至排列順序匹配成功的對應關係中某個對應關係的具有特徵的參考頭域及消息頭中與其對應的頭域的特徵匹配也成功後，確定發送請求消息的客戶端類型為該對應關係對應的客戶端；否則，確定本次識別失敗。優選的，根據已識別的客戶端對應的請求消息的消息頭中各頭域的排列順序及各頭域具有的特有特徵，周期性對預先設定的對應關係進行更新，以提高匹配的成功率；其中，對預先設定的對應關係進行更新包括以下兩種情況 —是對已有的對應關係進行更新，包括增加或減少已有的對應關係中的參考頭域的數量、更新已有的對應關係中各參考頭域的排列順序、更新已有的對應關係中部分或全部參考頭域的特徵信息的值等；二是增加新的對應關係。若本發明實施例中的對應關係以哈希表的形式表示，則該哈希表可以存儲於本地存儲設備或其他存儲設備中，也可以預先存儲各參考客戶端對應的參考頭域的狀態信息及參考頭域的特徵信息，在需要進行識別時，將各參考客戶端對應的參考頭域的狀態信息、特徵信息及對應的處理函數註冊至哈希表中。相應的，參見圖2，在步驟101之前，本發明實施例基於HTTP的客戶端類型的識別方法還包括以下步驟步驟201、讀取包含各對應關係及處理函數的配置文件，其中，配置文件包括各個參考客戶端對應的消息頭中每個參考頭域的名稱、狀態信息(用於標識各頭域的順序的信息)、對應的特徵信息及對應的處理函數(處理函數包括檢測狀態和特徵匹配)，該配置文件可預先存儲於指定的目錄下。其中，通過分析已識別的客戶端發送的大量的HTTP協議的請求消息，得到該已識別的客戶端對應的消息頭中各頭域的排列順序，並將已識別的客戶端作為參考客戶端，將已識別的客戶端對應的所有頭域中的部分或全部作為參考頭域。步驟202、根據配置文件的內容將每個參考客戶端對應的參考頭域的名稱、狀態信息、特徵信息和對應的處理函數註冊到哈希表中。下面以表I所示的三種對應關係為例，對本發明實施例基於HTTP的客戶端類型的識別過程進行詳細說明，參見圖3，包括以下步驟步驟S301、從TCP協議的報文中準確的識別出HTTP協議；步驟S302、在HTTP協議私有結構中設置兩個變量status和HTTP_proto，其中，變量status用於標識當前處理的請求消息的消息頭中與對應關係中的參考頭域相同的頭域的狀態信息的值，變量status可以採用u8類型，在初始狀態下，status的值為0，即status=0 ；變量HTTP_proto用於記錄各對應關係中的客戶端類型，變量HTTP_proto可以採用u8類型，也可以擴展為u32類型；
以表I所示的對應關係為例，變量HTTP_pix)t0可以按位標識三種的客戶端類型，例如，變量HTTP_pix)t0的第一位標識客戶端A、第二位標識客戶端B、第三位標識客戶端C，初始狀態下，變量HTTP_pix)t0的每一位都置為I。步驟303、在接收到客戶端發送的請求消息後，採用哈希算法查找請求消息的消息頭中與對應關係中的參考頭域相同的頭域，井根據每個參考頭域對應的狀態信息和特徵信息，以及與每個參考頭域對應的頭域在消息頭中的排列順序及具有的特有特徵，確定發送請求消息的客戶端的類型；其中，確定發送請求消息的客戶端的類型包括以下方法A、若請求消息的消息頭中與參考頭域對應的頭域在該消息頭中的排列順序僅與某一個對應關係中的參考頭域順序相同，且該頭域具有的特有特徵包含與其對應的參考頭域的特徵，則本次識別成功，並確定發送請求消息的客戶端的類型為該對應關係中的客戶端類型，執行步驟304。方法B、若確定的頭域的排列順序僅與某ー個對應關係中的參考頭域順序相同，且 該頭域具有的特有特徵不包含與其對應的參考頭域的特徵，則本次識別失敗，結束流程並返回失敗。方法C、若確定的頭域的排列順序與至少兩個對應關係中的參考頭域順序相同，則對該至少兩個對應關係中某個第一參考頭域及消息頭中與該第一參考頭域對應的第一頭域進行特徵匹配，以確定發送請求消息的客戶端的類型；具體的，方法C進ー步包括以下兩種方法Cl、該至少兩個對應關係中某個第一參考頭域具有互不相同的特徵，即該至少兩個對應關係中的每個對應關係的該第一參考頭域的特徵信息的值均不為空，且互不相同；則若消息頭中與該第一參考頭域對應的第一頭域具有特有特徵，且該特有特徵包含該至少兩個對應關係中的某個對應關係中的第一參考頭域的特徵信息的值，則匹配成功，並確定客戶端類型為特徵匹配成功的第一參考頭域所屬的對應關係中的客戶端類型，執行步驟304 ；若消息頭中與該第一參考頭域對應的第一頭域具有特有特徵，但該特有特徵不包含該至少兩個對應關係中的任一對應關係中的第一參考頭域的特徵信息的值，則匹配失敗，結束流程並返回失敗；若第一頭域不具有特有特徵，則匹配失敗，結束流程並返回失敗。方法C2、該至少兩個對應關係中的某個第一參考頭域中，有ー個對應關係的第一參考頭域不具有特徵，其餘對應關係中的該個第一參考頭域具有互不相同的特徵；則若消息頭中與該第一參考頭域對應的第一頭域具有特有特徵，且該第一頭域的特有特徵包含該至少兩個對應關係中某個對應關係的對應的第一參考頭域的特徵，則匹配成功，確定客戶端的類型為該對應關係中的客戶端類型，執行步驟304 ；若第一頭域具有特有特徵，且該第一頭域的特有特徵不包含該至少兩個對應關係中任一對應關係的對應的第一參考頭域的特徵，則匹配成功，確定客戶端的類型為不具有特徵的第一參考頭域所屬的對應關係中的客戶端類型，執行步驟304 ；若第一頭域不具有特有特徵，則匹配成功，確定客戶端的類型為不具有特徵的第一參考頭域所屬的對應關係中的客戶端類型，執行步驟304。方法D、若確定的頭域的排列順序與任一對應關係中的參考頭域順序均不相同，則本次識別失敗，結束流程並返回失敗。在具體處理過程中，根據請求消息的消息頭中與對應關係中的參考頭域相同的頭域在消息頭中的排列順序，改變狀態變量staus的值，當查找到消息頭中的某個頭域後，則進入處理函數；處理函數的具體處理包括依次檢測請求消息的消息頭中與哈希表中包含的參考頭域相同的頭域，在確定當前頭域對應的狀態變量status時要先將當前狀態變量status的值加1，再與對應的參考頭域的狀態信息的值進行匹配，若匹配成功(即頭域的狀態變量staus的值與哈希表中對應的參考頭域的狀態信息的值相同)，則繼續檢測下一個對應的 頭域，直至檢測到最後一個對應的頭域；若哈希表中某個對應關係的參考頭域具有特徵(即哈希表中，該參考頭域對應的特徵信息的值不為空)，則處理函數的具體處理還包括將與具有特徵的參考頭域對應的頭域及該參考頭域進行特徵匹配，若匹配成功(即該頭域具有的特有特徵包含該參考頭域具有的特徵)，則繼續檢測下一個對應的頭域，直至檢測到最後一個對應的頭域。例如以表I所示的三種對應關係為例，當檢測到請求信息的消息頭中的頭域GET時，先將頭域的狀態變量status的值加I (由於GET頭域為消息頭中與參考頭域相同的第一個頭域，因此，狀態變量status加I後的值為I,即Status=(Hl),再將當前頭域對應的狀態變量的值與三種對應關係中對應的參考頭域GET狀態信息的值進行比較，由於客戶端A對應的參考頭域順序中參考頭域GET的第一組和第二組狀態信息的值均為1，且客戶端B和客戶端C對應的參考頭域順序中參考頭域GET的第一組狀態信息的值均為I (即參考頭域GET在三種類型客戶端對應的所有參考頭域中排在第一位)，則頭域GET匹配成功，並將狀態變量status的值置為I ;其中，哈希表中該第一種對應關係中的參考頭域GET對應的第一組和第二組特徵信息的值均為「null」，且第二種對應關係和第三種對應關係中的參考頭域GET對應的第一組特徵信息的值也均為「null」，因此，不需要對頭域GET和參考頭域GET進行特徵匹配；繼續進行下一個頭域的檢測，當檢測到頭域Accept時,先將狀態變量status加I (由於Accept頭域為消息頭中與參考頭域相同的第二個頭域，因此，狀態變量status加I後的值為2，即status=l+l)，再將當前頭域Ac^pt的狀態變量的值與三種對應關係中對應的參考頭域的第一組狀態變量的值進行比較，由於客戶端A對應的參考頭域Ac^pt的第一組和第二組狀態信息的值均為2，且客戶端B對應的參考頭域Accept的第一組狀態信息的值為2，而客戶端C對應的參考頭域Ac^pt的第一組狀態信息的值為3，因此，第三種對應關係匹配失敗，則將客戶端C排除掉，即將HTTP_pix)t0的第三位置為O ;依次類推，直至匹配完成對應關係中的最後個參考頭域；在完成最後一個參考頭域的檢測狀態後，確定消息頭中對應的頭域的排列順序與第一種對應關係中的第二組狀態信息對應的參考頭域順序相同，且與第二種對應關係中的第一組狀態信息對應的的參考頭域順序相同，並對最後一個參考頭域及其對應的頭域進行特徵匹配；
具體的，如表I所示，第一種對應關係中最後ー個參考頭域對應的第二組特徵信息的值為「null」，而第二種對應關係中最後ー個參考頭域對應的第一組特徵信息的值為「MSIE 6. 0; Windows NT 5. I; SVl ;」，則若消息頭中對應的頭域具有的特有特徵包含「 MSIE6.0; Windows NT 5. I; SVl ;」，則確定發送請求消息的客戶端的類型為客戶端B，若消息頭中對應的頭域不具有特有特徵，或該頭域具有特有特徵且不包含「MSIE 6.0;ffindows NT
5.I; SVl; 」，則確定發送請求消息的客戶端的類型為客戶端A ;同時，更新變量HTTP_pix)t0。假設在檢測狀態及特徵匹配都成功後，HTTP_proto的第一位為0，第二位為1，第三位為0，確定客戶端為客戶端B並發協議事件。步驟304、在與客戶端的會話上標記出確定出的客戶端類型，並將會話的狀態變量status置為初始值0，並返回步驟301。基於同一發明構思，本發明實施例中還提供了一種基於HTTP的客戶端類型的識 別設備，由於該設備解決問題的原理與上述基於HTTP的客戶端類型的識別方法相似，因此該設備的實施可以參見方法的實施，重複之處不再贅述。如圖4所示，本發明實施例基於HTTP的客戶端類型的識別設備，包括確定模塊41，用於根據預先設定的參考頭域順序與客戶端類型的對應關係，確定接收到的來自客戶端的請求消息的消息頭中與對應關係中各參考頭域相同的頭域；匹配模塊42，用於根據確定的頭域在消息頭中的排列順序以及所有對應關係中的參考頭域順序，確定客戶端的類型；其中，請求消息包括消息頭和消息體，消息頭中包含多個頭域。進ー步，在建立各種不同的對應關係時，若至少兩個對應關係中的參考頭域順序相同，該至少兩個對應關係中至少有ー個對應關係中的至少ー個參考頭域具有特徵信息，以使任意兩個對應關係之間都存在區別，例如，任意兩個對應關係中的參考頭域順序不同、或任意兩個對應關係中的同一個參考頭域的特徵信息不同；其中，任意兩個對應關係中同一個參考頭域的特徵信息不同包括以下兩種情況一是該兩個對應關係中同一個參考頭域的特徵信息包含的內容不同；ニ是該兩個對應關係中的ー個對應關係中的某ー個參考頭域具有特徵信息，另一個對應關係中的同ー個參考頭域不具有特徵信息。優選的，匹配模塊42具體用於針對請求消息的消息頭中每個頭域，在某個或某些對應關係中包含與該頭域對應的參考頭域，且該頭域在已確定的與該個或該些對應關係中的參考頭域對應的頭域中的排列順序，與該個或該些對應關係中的部分或全部對應關係中已確定的參考頭域的排列順序相同時，若該個或該些對應關係中的部分或全部對應關係中與該頭域對應的參考頭域具有特徵，則對具有特徵的參考頭域及所述消息頭中與該參考頭域對應的頭域進行特徵匹配；在消息頭中與某個對應關係中包含的參考頭域對應的頭域的排列順序，與該對應關係中參考頭域排列順序相同，且消息頭中與具有特徵的參考頭域對應的頭域的特有特徵，包含與其對應的參考頭域的特徵時，確定發送請求消息的客戶端類型為該對應關係中的客戶端類型。優選的，匹配模塊42具體用於確定消息頭中與對應關係中的每個參考頭域對應的頭域，在確定的所有頭域在該消息頭中的排列順序與某個或某些對應關係中的參考頭域順序相同後，對具有特徵的參考頭域及所述消息頭中與該參考頭域對應的頭域進行特徵匹配；在消息頭中與某個對應關係中包含的參考頭域對應的頭域的排列順序，與該對應關係中參考頭域排列順序相同，且消息頭中與具有特徵的參考頭域對應的頭域的特有特徵，包含與其對應的參考頭域的特徵時，確定發送請求消息的客戶端類型為該對應關係中的客戶端類型。進一步，匹配模塊42具體用於若所有對應關係中的所有參考頭域均不具有特徵，且確定的頭域的排列順序僅與某一個對應關係中的參考頭域順序相同，確定客戶端的類型為與確定的頭域的排列順序相同的參考頭域順序所屬的對應關係中的客戶端類型。進一步，匹配模塊42具體用於
若確定的頭域的排列順序僅與某一個對應關係中的參考頭域順序相同，且該對應關係中某個或某些參考頭域具有特徵，在確定與具有特徵的參考頭域對應的頭域具有的特有特徵包含該特徵時，確定客戶端的類型為該對應關係中的客戶端類型。進一步，匹配模塊42具體用於若確定的頭域的排列順序與至少兩個對應關係中的參考頭域順序相同，且該至少兩個對應關係中某個第一參考頭域具有不同的特徵，其中第一參考頭域為該至少兩個對應關係中相同的參考頭域，確定消息頭中與第一參考頭域對應的頭域，並將確定的頭域作為第一頭域；在第一頭域具有特有特徵，且第一頭域的特有特徵包含某個對應關係中的第一參考頭域的特徵時，確定客戶端的類型為該對應關係中的客戶端類型。進一步，匹配模塊42具體用於若確定的頭域的排列順序與至少兩個對應關係中的參考頭域順序相同，且該至少兩個對應關係中某個第一參考頭域中，有一個對應關係的第一參考頭域不具有特徵，其餘對應關係中的第一參考頭域具有不同的特徵，其中第一參考頭域為該至少兩個對應關係中相同的參考頭域，確定消息頭中與第一參考頭域對應的頭域，並將確定的頭域作為第一頭域；在第一頭域具有特有特徵，且第一頭域的特有特徵包含某個對應關係中的第一參考頭域的特徵，確定客戶端的類型為該對應關係中的客戶端類型；在第一頭域具有特有特徵，且第一頭域的特有特徵不包含該至少兩個對應關係中的第一參考頭域的特徵，確定客戶端的類型為不具有特徵的第一參考頭域所屬的對應關係中的客戶端類型；在第一頭域不具有特有特徵，確定客戶端的類型為不具有特徵的第一參考頭域所屬的對應關係中的客戶端類型。需要說明的是，本發明實施例基於HTTP的客戶端類型的識別設備獨立於客戶端和伺服器，由該識別設備接收客戶端向伺服器發送的請求消息，並根據該請求消息確定客戶端的類型，並根據需要對收到的請求消息進行處理，例如，若需要阻斷該客戶端時，則丟棄該請求消息；若不需要阻斷該客戶端，則將該請求消息發送至伺服器進行處理；本發明實施例基於HTTP的客戶端類型的識別設備的各功能模塊還可以集成於伺服器中，則在確定了發送請求消息的客戶端的類型後，可根據需要對收到的請求消息進行處理，例如，若需要阻斷該客戶端時，則丟棄該請求消息；若不需要阻斷該客戶端，則根據請求消息返迴響應消息。儘管已描述了本發明的優選實施例，但本領域內的技術人員一旦得知了基本創造性概念，則可對這些實施例作出另外的變更和修改。所以，所附權利要求意欲解釋為包括優選實施例以及落入本發明範圍的所有變更和修改。本發明實施例通過預設的多個參考頭域順序與客戶端類型之間的對應關係，確定請求消息的消息頭中與對應關係中的參考頭域相同的頭域在該消息頭中的排列順序，井根據確定的排列順序與對應關係中參考頭域順序進行匹配，以確定客戶端的類型。由於僅需要存儲每個請求消息的消息頭中部分或全部頭域的信息，而不需要存儲每個請求消息的消息體，也不需要存儲大量的特有特徵，從而節省了內存空間；由於不需要進行大量特有特徵的匹配，從而有效提高了處理效率。 由於本發明實施例的對應關係中還包括少數幾個參考頭域對應的特徵信息，在根據頭域排列順序無法識別客戶端的類型時，只需要對具有特徵信息的參考頭域進行特徵匹配，即可確定客戶端的類型，從而提高了匹配成功率。顯然，本領域的技術人員可以對本發明進行各種改動和變型而不脫離本發明的精神和範圍。這樣，倘若本發明的這些修改和變型屬於本發明權利要求及其等同技術的範圍之內，則本發明也意圖包含這些改動和變型在內。
權利要求
1.一種基於HTTP的客戶端類型的識別方法，其特徵在於，該方法包括 根據預先設定的參考頭域順序與客戶端類型的對應關係，確定接收到的來自客戶端的請求消息的消息頭中與所述對應關係中各參考頭域相同的頭域，其中，所述請求消息包括消息頭和消息體，所述消息頭中包含多個頭域； 根據確定的頭域在所述消息頭中的排列順序以及所有對應關係中的參考頭域順序，確定所述客戶端的類型。
2.如權利要求I所述的方法，其特徵在於，根據下列方式確定所述客戶端的類型 針對請求消息的消息頭中每個頭域，在某個或某些對應關係中包含與該頭域對應的參考頭域，且該頭域在已確定的與該個或該些對應關係中的參考頭域對應的頭域中的排列順序，與該個或該些對應關係中的部分或全部對應關係中已確定的參考頭域的排列順序相同時，若該個或該些對應關係中的部分或全部對應關係中與該頭域對應的參考頭域具有特徵，則對具有特徵的參考頭域及所述消息頭中與該參考頭域對應的頭域進行特徵匹配；在所述消息頭中與某個對應關係中包含的參考頭域對應的頭域的排列順序，與該對應關係中參考頭域排列順序相同，且消息頭中與具有特徵的參考頭域對應的頭域的特有特徵，包含與其對應的參考頭域的特徵時，確定發送請求消息的客戶端類型為該對應關係中的客戶端類型。
3.如權利要求I所述的方法，其特徵在於，根據下列方式確定所述客戶端的類型 確定所述消息頭中與對應關係中的每個參考頭域對應的頭域，在確定的所有頭域在該消息頭中的排列順序與某個或某些對應關係中的參考頭域順序相同後，對具有特徵的參考頭域及所述消息頭中與該參考頭域對應的頭域進行特徵匹配； 在所述消息頭中與某個對應關係中包含的參考頭域對應的頭域的排列順序，與該對應關係中參考頭域排列順序相同，且消息頭中與具有特徵的參考頭域對應的頭域的特有特徵，包含與其對應的參考頭域的特徵時，確定發送請求消息的客戶端類型為該對應關係中的客戶端類型。
4.如權利要求2或3所述的方法，其特徵在於，所述特徵匹配具體包括 若該頭域中具有特有特徵，且該特有特徵包含對應的參考頭域的特徵，則匹配成功； 若該頭域中具有特有特徵且該特有特徵不包含對應的參考頭域的特徵，或該頭域中不具有特有特徵，則匹配失敗。
5.如權利要求r3任一所述的方法，其特徵在於，所有對應關係以哈希表的形式表示。
6.如權利要求f3任一所述的方法，其特徵在於，所述確定所述客戶端的類型具體包括 若所有對應關係中的所有參考頭域均不具有特徵，且所述確定的頭域的排列順序僅與某一個對應關係中的參考頭域順序相同，確定所述客戶端的類型為與所述確定的頭域的排列順序相同的參考頭域順序所屬的對應關係中的客戶端類型。
7.如權利要求r3任一所述的方法，其特徵在於，所述確定所述客戶端的類型包括 若所述確定的頭域的排列順序僅與某一個對應關係中的參考頭域順序相同，且該對應關係中某個或某些參考頭域具有特徵，在確定與具有特徵的參考頭域對應的頭域具有的特有特徵包含該特徵時，確定所述客戶端的類型為該對應關係中的客戶端類型。
8.如權利要求r3任一所述的方法，其特徵在於，若確定的頭域的排列順序與至少兩個對應關係中的參考頭域順序相同，且該至少兩個對應關係中某個第一參考頭域具有互不相同的特徵，所述第一參考頭域為該至少兩個對應關係中相同的參考頭域，所述確定所述客戶端的類型包括 確定所述消息頭中與所述第一參考頭域對應的頭域，並將確定的頭域作為第一頭域； 在所述第一頭域具有特有特徵，且所述第一頭域的特有特徵包含某個對應關係中的第一參考頭域的特徵時，確定所述客戶端的類型為該對應關係中的客戶端類型。
9.如權利要求r3任一所述的方法，其特徵在於，若確定的頭域的排列順序與至少兩個對應關係中的參考頭域順序相同，且該至少兩個對應關係中某個第一參考頭域中，有一個對應關係的第一參考頭域不具有特徵，其餘對應關係中該個第一參考頭域具有互不相同的特徵，所述第一參考頭域為該至少兩個對應關係中相同的參考頭域，所述確定所述客戶端的類型包括 確定所述消息頭中與第一參考頭域對應的頭域，並將確定的頭域作為第一頭域； 在所述第一頭域具有特有特徵，且所述第一頭域的特有特徵包含該至少兩個對應關係中某個對應關係的對應的第一參考頭域的特徵，確定所述客戶端的類型為該對應關係中的客戶端類型； 在所述第一頭域具有特有特徵，且所述第一頭域的特有特徵不包含該至少兩個對應關係中任一對應關係的對應的第一參考頭域的特徵，確定所述客戶端的類型為不具有特徵的第一參考頭域所屬的對應關係中的客戶端類型； 在所述第一頭域不具有特有特徵，確定所述客戶端的類型為不具有特徵的第一參考頭域所屬的對應關係中的客戶端類型。
10.一種基於HTTP的客戶端類型的識別設備，其特徵在幹，該設備包括 確定模塊，用於根據預先設定的參考頭域順序與客戶端類型的對應關係，確定接收到的來自客戶端的請求消息的消息頭中與所述對應關係中各參考頭域相同的頭域； 匹配模塊，用於根據確定的頭域在所述消息頭中的排列順序以及所有對應關係中的參考頭域順序，確定所述客戶端的類型； 其中，所述請求消息包括消息頭和消息體，所述消息頭中包含多個頭域。
11.如權利要求10所述的設備，其特徵在於，所述匹配模塊具體用於 針對請求消息的消息頭中每個頭域，在某個或某些對應關係中包含與該頭域對應的參考頭域，且該頭域在已確定的與該個或該些對應關係中的參考頭域對應的頭域中的排列順序，與該個或該些對應關係中的部分或全部對應關係中已確定的參考頭域的排列順序相同時，若該個或該些對應關係中的部分或全部對應關係中與該頭域對應的參考頭域具有特徵，則對具有特徵的參考頭域及所述消息頭中與該參考頭域對應的頭域進行特徵匹配； 在所述消息頭中與某個對應關係中包含的參考頭域對應的頭域的排列順序，與該對應關係中參考頭域排列順序相同，且消息頭中與具有特徵的參考頭域對應的頭域的特有特徵，包含與其對應的參考頭域的特徵時，確定發送請求消息的客戶端類型為該對應關係中的客戶端類型。
12.如權利要求10所述的設備，其特徵在於，所述匹配模塊具體用於 確定所述消息頭中與對應關係中的每個參考頭域對應的頭域，在確定的所有頭域在該消息頭中的排列順序與某個或某些對應關係中的參考頭域順序相同後，對具有特徵的參考頭域及所述消息頭中與該參考頭域對應的頭域進行特徵匹配； 在所述消息頭中與某個對應關係中包含的參考頭域對應的頭域的排列順序，與該對應關係中參考頭域排列順序相同，且消息頭中與具有特徵的參考頭域對應的頭域的特有特徵，包含與其對應的參考頭域的特徵時，確定發送請求消息的客戶端類型為該對應關係中的客戶端類型。
13.如權利要求1(Γ12任一所述的設備，其特徵在於，所述匹配模塊具體用於 若所有對應關係中的所有參考頭域均不具有特徵，且所述確定的頭域的排列順序僅與某一個對應關係中的參考頭域順序相同，確定所述客戶端的類型為與所述確定的頭域的排列順序相同的參考頭域順序所屬的對應關係中的客戶端類型。
14.如權利要求1(Γ12任一所述的設備，其特徵在於，所述匹配模塊具體用於 若所述確定的頭域的排列順序僅與某一個對應關係中的參考頭域順序相同，且該對應關係中某個或某些參考頭域具有特徵，在確定與具有特徵的參考頭域對應的頭域具有的特有特徵包含該特徵時，確定所述客戶端的類型為該對應關係中的客戶端類型。
15.如權利要求1(Γ12任一所述的設備，其特徵在於，所述匹配模塊具體用於若確定的頭域的排列順序與至少兩個對應關係中的參考頭域順序相同，且該至少兩個對應關係中某個第一參考頭域具有互不相同的特徵，所述第一參考頭域為該至少兩個對應關係中相同的參考頭域，確定所述消息頭中與所述第一參考頭域對應的頭域，並將確定的頭域作為第一頭域； 在所述第一頭域具有特有特徵，且所述第一頭域的特有特徵包含某個對應關係中的第一參考頭域的特徵時，確定所述客戶端的類型為該對應關係中的客戶端類型。
16.如權利要求1(Γ12任一所述的設備，其特徵在於，所述匹配模塊具體用於 若確定的頭域的排列順序與至少兩個對應關係中的參考頭域順序相同，且該至少兩個對應關係中某個第一參考頭域中，有一個對應關係的第一參考頭域不具有特徵，其餘對應關係中該個第一參考頭域具有互不相同的特徵，所述第一參考頭域為該至少兩個對應關係中相同的參考頭域，確定所述消息頭中與第一參考頭域對應的頭域，並將確定的頭域作為第一頭域； 在所述第一頭域具有特有特徵，且所述第一頭域的特有特徵包含該至少兩個對應關係中某個對應關係的對應的第一參考頭域的特徵，確定所述客戶端的類型為該對應關係中的客戶端類型； 在所述第一頭域具有特有特徵，且所述第一頭域的特有特徵不包含該至少兩個對應關係中任一對應關係的對應的第一參考頭域的特徵，確定所述客戶端的類型為不具有特徵的第一參考頭域所屬的對應關係中的客戶端類型； 在所述第一頭域不具有特有特徵，確定所述客戶端的類型為不具有特徵的第一參考頭域所屬的對應關係中的客戶端類型。
全文摘要
本發明實施例涉及網絡技術領域，特別涉及一種基於HTTP的客戶端類型的識別方法和裝置，用於解決現有客戶端類型識別過程中，需要較大的存儲空間，且處理效率低的問題。本發明實施例的方法包括根據預先設定的參考頭域順序與客戶端類型的對應關係，確定接收到的來自客戶端的請求消息的消息頭中與對應關係中各參考頭域相同的頭域；根據確定的頭域在該消息頭中的排列順序以及所有對應關係中的參考頭域順序，確定客戶端的類型。本發明實施例節省了內存空間，提高了處理效率。
文檔編號H04L29/08GK102833327SQ201210292628
公開日2012年12月19日 申請日期2012年8月16日 優先權日2012年8月16日
發明者田海燕, 練書成 申請人:瑞斯康達科技發展股份有限公司