专利名称：基于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日
发明者田海燕, 练书成 申请人:瑞斯康达科技发展股份有限公司