CN111722979B - 质量监测方法、装置、服务器及存储介质 - Google Patents
质量监测方法、装置、服务器及存储介质 Download PDFInfo
- Publication number
- CN111722979B CN111722979B CN202010525411.8A CN202010525411A CN111722979B CN 111722979 B CN111722979 B CN 111722979B CN 202010525411 A CN202010525411 A CN 202010525411A CN 111722979 B CN111722979 B CN 111722979B
- Authority
- CN
- China
- Prior art keywords
- monitoring
- tcp
- application program
- application
- tcp connection
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 157
- 238000000034 method Methods 0.000 title claims abstract description 66
- 238000012806 monitoring device Methods 0.000 title claims abstract description 7
- 230000006870 function Effects 0.000 claims description 33
- 238000012545 processing Methods 0.000 claims description 30
- 239000004744 fabric Substances 0.000 claims description 19
- 230000015654 memory Effects 0.000 claims description 19
- 230000001360 synchronised effect Effects 0.000 claims description 9
- 238000001514 detection method Methods 0.000 claims description 5
- 239000003550 marker Substances 0.000 claims description 4
- 238000013135 deep learning Methods 0.000 abstract description 2
- 230000010365 information processing Effects 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 12
- 230000008569 process Effects 0.000 description 11
- 238000004590 computer program Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 6
- 238000004891 communication Methods 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000002360 explosive Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 239000004575 stone Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/1734—Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Mathematical Physics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请公开了质量监测方法、装置、服务器及存储介质,涉及包括但不限于云计算、云平台、云服务、云存储、深度学习、图像识别等信息处理技术领域。具体实现方案为:确定针对应用程序的监测开始,创建所述应用程序的第一结构体;将监测开始之后的所述应用程序的数据包的质量信息,添加至所述应用程序的第一结构体中;确定针对所述应用程序的监测结束,基于所述应用程序的第一结构体生成所述应用程序的质量日志信息。
Description
技术领域
本申请涉及计算机技术领域,尤其涉及包括但不限于云计算、云平台、云服务、云存储、深度学习、图像识别等信息处理技术领域。
背景技术
TCP协议栈质量监控技术,是一种能够以TCP连接或应用层协议(例如http协议)为粒度监控并收集TCP质量信息的技术。随着互联网的高速发展,互联网上的流量总量呈爆发式的增长,流量类型、业务场景更加多样化,这些都依赖承载业务的服务器上面的TCP协议栈,所以TCP协议栈是承载业务线网络流量的基石。然而,上述方案中,服务器的内核的TCP协议栈只能看到TCP协议却无法区分应用层协议,因此无法以应用层协议的粒度获取质量信息。
发明内容
本公开提供了一种质量监测方法、装置、服务器及存储介质。
根据本公开的第一方面,提供了一种质量监测方法,包括:
确定针对应用程序的监测开始,创建所述应用程序的第一结构体;
将监测开始之后的所述应用程序的数据包的质量信息,添加至所述应用程序的第一结构体中;
确定针对所述应用程序的监测结束,基于所述应用程序的第一结构体生成所述应用程序的质量日志信息。
根据本公开的第二方面,提供了一种质量监测装置,包括:
第一创建模块,用于确定针对应用程序的监测开始,创建所述应用程序的第一结构体;
数据包处理模块,用于将监测开始之后的所述应用程序的数据包的质量信息,添加至所述应用程序的第一结构体中;
日志生成模块,用于确定针对所述应用程序的监测结束,基于所述应用程序的第一结构体生成所述应用程序的质量日志信息。
根据本公开的第三方面,提供了一种服务器,包括:
至少一个处理器;以及
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行上述方法。
根据本公开的第四方面,提供了一种存储有计算机指令的非瞬时计算机可读存储介质,所述计算机指令用于使所述计算机执行上述方法。
根据本公开的第五方面,提供了一种计算机程序产品,包括计算机程序,所述计算机程序在被处理器执行时实现如上所述的方法。
根据本申请的技术,可以在应用程序的开始监测以及结束监测的数据段进行监测,对监测的数据段获取对应的质量信息并生成对应的质量日志。如此,可以获取到应用程序的一段数据的质量信息,并且这段数据是协议无关的,且长度不限,因此质量信息的监测统计和获取也不必以TCP连接为粒度,从而增加了质量信息获取的灵活性以及通用性。
应当理解,本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征,也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
附图用于更好地理解本方案,不构成对本申请的限定。其中:
图1是根据本申请实施例的质量监测方法流程示意图一;
图2是根据本申请实施例的质量监测方法流程示意图二;
图3是根据本申请实施例的一种处理架构示意图;
图4是根据本申请实施例的一种packet catcher的架构示意图;
图5是根据本申请实施例的质量监测方法流程示意图三;
图6是根据本申请实施例的质量监测方法流程示意图四;
图7是根据本申请实施例的质量监测方法流程示意图五;
图8是根据本申请实施例的质量监测方法流程示意图六;
图9是根据本申请实施例的质量监测处理场景示意图一;
图10是根据本申请实施例的质量监测方法流程示意图七;
图11是根据本申请实施例的质量监测处理场景示意图二;
图12是根据本申请实施例的日志推送处理流程示意图;
图13是根据本申请实施例的质量监测装置组成结构示意图一;
图14是根据本申请实施例的质量监测装置组成结构示意图二;
图15是用来实现本申请实施例的质量监测方法的服务器的框图。
具体实施方式
以下结合附图对本申请的示范性实施例做出说明,其中包括本申请实施例的各种细节以助于理解,应当将它们认为仅仅是示范性的。因此,本领域普通技术人员应当认识到,可以对这里描述的实施例做出各种改变和修改,而不会背离本申请的范围和精神。同样,为了清楚和简明,以下的描述中省略了对公知功能和结构的描述。
本发明的第一实施例提供了一种质量监测方法,如图1所示,包括:
S101:确定针对应用程序的监测开始,创建所述应用程序的第一结构体;
S102:监测开始之后的所述应用程序的数据包的质量信息,添加至所述应用程序的第一结构体中;
S103:确定针对所述应用程序的监测结束,基于所述应用程序的第一结构体生成所述应用程序的质量日志信息。
本实施例提供的方法可以应用与服务器,上述S101-S103具体可以在服务器的内核中完成。
可以在内核的TCP协议栈中在第一TCP连接上接收应用程序对应的数据包。
其中,所述第一TCP连接可以为服务器中的任意一个TCP连接,只要该连接上存在针对目标应用的数据的监测开始标记,即可将其理解为本申请的第一TCP连接。
另外,本实施例中确定针对应用程序的监测开始之前,还提供针对TCP连接的质量监测方法,如图2所示,所述方法还包括:
S201:创建针对第一TCP连接的第二结构体;其中,所述第一TCP连接为所述第一结构体所属的TCP连接;
S202:将所述第一TCP连接上传输的数据包的质量信息添加至所述第二结构体中;
S203:若确定针对第一TCP连接的监测结束,则基于所述第二结构体生成针对所述第一TCP连接的质量日志信息。
结合图3对本实施例前述S101-S103以及S201-S203进行说明,该整体逻辑主要包含三个部分:
一是从原始报文中计算得到中间数据,这个逻辑由图中的内核(或内核空间)的packet catcher模块完成,基于netfilter以及hook部分函数指针实现;
二是应用层协议标记模块,当应用程序需要监测一段数据的时候,需要在write系统调用的前后分别调用setsockopt,用于标记写入的数据段,TCP协议栈会自动记下这段数据的质量信息。
三是日志推送模块,该模块是一个单独的内核线程,负责处理得到的数据,并按照一定的策略写入日志。
推送的日志分为两个部分,一是以TCP为粒度统计的TCP质量日志,此部分直接写入日志;二是以应用层协议(例如http协议)为粒度的质量日志,此部分通过netlink接口发送给应用层,提供给应用程序后续处理。
结合图3对上述S201-S203的整体的工作流程进行说明,可以包括:
S201中,数据包(可以为接收方向的数据包,也可以为发送方向的数据包)进入到内核的packet catcher模块;如果该数据包是同步数据包(syn包),会根据该数据包的TCP五元组创建一个TCP entry(也就是第二结构体)。这里,TCP entry(也就是第二结构体)可以以TCP五元组为标识。
S202中,将TCP五元组对应的TCP entry(也就是第二结构体)插入到packetcatcher维护的一个全局的第一哈希表(hash table)中,属于该条连接的所有数据包,都会找到TCP entry(也就是第二结构体),并将质量信息维护在TCP entry(也就是第二结构体)中。
S203中,确定针对第一TCP连接的监测结束的一种方式可以为TCP连接结束。
也就是当第一TCP连接结束以后,将TCP entry(也就是第二结构体)移动到一个TCP complete list(也就是第二完成列表)中,TCP complete list(也就是第二完成列表)是一个per cpu的链表,所有移动到TCP complete list(也就是第二完成列表)上的TCPentry(也就是第二结构体)表示这个entry的连接已经结束,并且信息已经可以写入日志了。
其中,TCP complete list(也就是第二完成列表)可以有两个。
另外,写日志的工作交给创建的内核线程来完成,内核线程遍历TCP completelist(第二完成列表),将TCP entry(第二结构体)写入日志,随后释放TCP entry(第二结构体)。
结合图3对上述S101-S103的整体的工作流程进行说明,可以包括:
S101中,当应用程序希望监测一段写入数据(写入内核的数据)的时候,需要调用tcp_setsockopt系统调用主动标记一段监测数据;服务器的内核监测到标记开始的时候,可以确定针对应用程序的监测开始,会在内核创建一个request entry(也就是第一结构体)。其中,第一结构体也可以为TCP五元组为标识。
S102中,将属于这个request entry(也就是第一结构体)的所有数据包,都会找到这个request entry,并监测开始之后的应用程序中传输的数据包的质量信息均维护在这个request entry(也就是第一结构体)中。
S103中,确定针对所述应用程序的监测结束之后,会将request entry(也就是第一结构体)移动到request complete list(第一完成列表)中。
其中,request complete list(第一完成列表)与TCP complete list(第二完成列表)完全相同,只是内核线程遍历这个链表的时候,需要将request entry的requestcomplete list(第一完成列表)通过图3中的netlink推送给应用程序。
在相关技术中,应用程序使用write系统调用向协议栈写入数据以后,后续协议栈对这段数据的处理一概不知,且质量信息最小只能以TCP为粒度进行收集。而通过采用上述方案,应用程序可以任意标记一个数据段来告知协议栈需要监测哪段数据,这段数据是协议无关的,且长度不限;质量信息的监测统计和获取也不必以TCP连接为粒度。
再次,本技术采用内核模块实现,支持热加载卸载,部署迭代方便。
本申请的第二实施例,在上述第一实施例的基础上对接收方向的处理进行详细说明。
结合图4来进行说明,图4中可以看出,图3中的内核中包含的Packet Catcher模块中维护了一个哈希表(Hash Table)。将每一个TCP连接的质量信息都存储在一个对应的TCPentry中,针对本实施例来说,可以将每一个TCP连接都先认为是第一TCP连接,也就是通过Packet Catcher模块将第一TCP连接的质量信息都存储在第一TCP连接所对应的第二结构体(也就是图中的TCP entry)。另外,第二结构体(TCP entry)被hash到Hash Table中。
当应用程序使用setsockopt标记一段监测数据的时候,内核空间的协议栈会创建所述目标应用所对应的第一结构体,也就是图中的request entry。
因为一个request entry一定属于一个TCP entry,因此request entry会使用链表链接在TCP entry结构体中。具体的可以为通过一个双向链表将两个结构体链接在一起。同时,为了便于应用程序标记数据段的时候能够方便的查找第一结构体(request entry),第一结构体(request entry)会被hash到一个第二哈希表中,比如可以称为Request HashTable。
图4中的虚线框中,为需要Hook的Function(功能函数),这里需要hook的函数包括tcp_v4_do_rcv,tcp_sendmsg/tcp_sendpage,以及一个netfilter的hook点IP_LOCAL_OUT。
其中,tcp_v4_do_rcv函数,在前后分别增加新的处理逻辑:tcp_v4_do_rcv_pre和tcp_v4_do_rcv_post,负责从接收到的TCP数据包中获取质量信息。
这里针对接收方向上的数据包没有使用netfilter,这是由于skb(数据包结构体)在IP_LOCAL_IN中未进入TCP层,未获取到TCP sock结构,因此只能根据skb获得简单的统计信息:接收到了多少Byte的数据,确认了多少Byte的数据,测量RTT等,rwnd等。而无法获得TCP层的信息:cwnd等。因此这里将hook点的位置上升到TCP层,在tcp_v4_do_rcv函数中,对tcp_v4_do_rcv进行修改,分别在其前后加上一个hook function来实现相应的功能。
具体来说,接收方向数据包处理流程,可以包括:
所述创建针对第一TCP连接的第二结构体,还包括:
根据接收的第一数据包的TCP五元组,查找第一哈希表中是否存在与所述TCP五元组对应的第二结构体;若第一哈希表中不存在与所述TCP五元组对应的第二结构体,则判断所述第一数据包是否为同步数据包,若是同步数据包,则基于所述第一数据包的TCP五元组创建第一TCP连接的第二结构体,并将所述第一TCP连接的第二结构体插入到所述第一哈希表。
其中,第一数据包可以为服务器的内核中接收的任意一个数据包中之一。
上述处理可以基于cp_v4_do_rcv_pre的处理逻辑来实现。
如图5所示,开始进入tcp_v4_do_rcv_pre逻辑,需要根据接收的第一数据包的TCP五元组在Hash Table(也就是前述第一哈希表)中查找到对应的TCP entry(第二结构体);
如果没有在Hash Table(也就是前述第一哈希表)中查找到对应的TCP entry(第二结构体),需要判断该第一数据包是否为syn包,如果不是syn包,则直接返回,结束处理;如果是syn包,则直接根据数据包(也就是上述第一数据包)的五元组创建新的TCP entry(第二结构体),并将新的TCP entry(第二结构体)插入到Hash Table(第一哈希表)中。
进一步,还结合图5来说,如果在Hash Table(也就是前述第一哈希表)中查找到对应的TCP entry(第二结构体)、或者,在创建新的TCP entry(第二结构体),并将新的TCPentry(第二结构体)插入到Hash Table(第一哈希表)中之后,还可以包括:获取TCP entry指针,根据第一数据包的确认序号确定对应的request entry(即第一结构体)。
然后,本实施例还可以包括:
基于第一数据包的质量信息更新所述第一结构体,判断所述应用程序的监测是否结束,若结束,则将所述应用程序所对应的第一结构体移至第一完成列表,基于所述第一完成列表生成应用程序的质量日志信息;
以及,基于第一数据包的质量信息更新所述第二结构体,判断所述针对第一TCP连接的监测是否结束,若结束,则将所述第二结构体移至第二完成列表,基于所述第二完成列表生成第一TCP连接的质量日志信息。
同样再结合图5来说,在获取到TCP entry指针以后,根据所述第一数据包的ack序号同时获得request entry指针(如果用户标记);根据数据包(即第一数据包)的信息获取对应的质量信息,其中质量信息可以包括以下至少之一:发送数据包数量、rtt、rto、连接持续时间等信息。
收集完质量信息后,判断所述第一数据包所属的request entry(第一结构体)和TCP entry(第二结构体)是否监测结束;
相应的,若request entry(第一结构体)监测结束,也就是应用程序的监测结束,则将request entry(第一结构体)移动至第一完成列表(request complete list);
若TCP entry(第二结构体)监测结束,也就是针对第一TCP连接的监测结束,则将TCP entry(第二结构体)移动至第二完成列表(TCP complete list)。
其中,对于TCP entry来说,监测结束的条件是TCP连接四次挥手结束或收到reset报文。
对于request entry,确定针对所述应用程序的监测结束的方式,包括以下之一:
应用程序所属的第一TCP连接的监测结束;
基于针对应用程序的监测结束标记确定针对所述应用程序的监测结束;
检测到其他数据段的开始监测标记。
比如,可以包括当一段时间内没有收到或发出属于TCP entry的数据包的时候,TCP entry会由于超时触发定时器,在定时器中将TCP entry移动到TCP complete list中;
比如,如果在连接持续期间内,没有满足接收到的TCP数据包的确认序号大于request entry的结束序号这个条件,那么在TCP entry移动到TCP complete list的过程中,request entry也会被同时移动到complete list中。
进一步地,本实施例中还可以包括获取第一TCP连接的拥塞控制状态的质量信息,比如可以包括:
若所述应用程序的监测未结束,并且所述第二结构体的检测未结束,则基于所述第一数据包获取第一TCP连接的拥塞控制状态的相关质量信息。
结合图5,tcp_v4_do_rcv_pre逻辑执行结束以后,也就是第一TCP连接的监测结束之后,执行tcp协议栈函数tcp_v4_do_rcv,随后执行tcp_v4_do_rcv_post函数逻辑,这个函数中负责收集与拥塞控制状态有关的质量信息,这部分质量信息需要放到tcp_v4_do_rcv之后来执行的原因是,拥塞控制状态的变化,是在处理完tcp的ack包以后才会发生变化,因此这部分质量信息的收集,就必须放到tcp处理完ack包以后执行。
本实施例提供的方案与现有技术相比,不单单可以获得发送数据包,RTT,RTO等基本信息,也可以对拥塞控制状态信息进行详细统计并输出。通过采用本实施例的方案还可以分析拥塞控制算法的执行情况,指导优化工作。
本申请的第三实施例,在上述第一实施例以及第二实施例的基础上对发送方向的数据处理进行详细说明。
所述创建针对第一TCP连接的第二结构体,包括:
根据待发送的第二数据包的TCP五元组,查找第一哈希表中是否存在与所述TCP五元组对应的第二结构体;
若第一哈希表中不存在与所述TCP五元组对应的第二结构体,则判断所述第二数据包是否为同步数据包,若是同步数据包,则基于所述第二数据包的TCP五元组创建第一TCP连接的第二结构体,并将所述第一TCP连接的第二结构体插入到所述第一哈希表。
也就是说,第二结构体可以为基于发送方向的数据包建立的,也可以为基于接收方向的数据包建立的。
如图4所示,发送方向数据包处理包括两个部分,packet catcher模块中一部分是tcp_sendmsg_fr/tcp_sendpage_fr,另一部分是在netfilter中的IP_LOCAL_OUT hook点。
通过将tcp_sendmsg/tcp_sendpage函数指针替换掉,替换成了tcp_sendmsg_fr/tcp_sendpage_fr,可以在其中增加新的处理逻辑,函数的主要作用是标记skb,即:将已经创建好的request entry指针链接进入skb的结构体成员中。
具体执行流程图,如图6所示,可以包括:
进入到tcp_sendmsg_fr/tcp_sendpage_fr,开始处理发送方向的第二数据包;这里,第二数据包可以为发送方向的多个数据包中的任意一个数据包。
根据该第二数据包的TCP五元组判断是否可以在第一哈希表(Hash Table)中找到第二结构体(tcp entry);这里,若能够找到,则说明这条tcp连接正在被监测,如果没有找到,那么就不需要标记skb,直接执行原始的tcp_sendmsg/tcp_sendpage函数逻辑。
如图6所示,如果在第一哈希表(Hash Table)中找到第二结构体(tcp entry),继续查询应用程序是否正在标记监测数据段。如果正在标记,则需要把已经创建好的requestentry通过链表指针链接在skb之中。
其中,将request entry链接进入skb(包含第二数据包的结构体)中,分为如下几种情况:如果skb已经有数据,且之前没有标记过,或者标记过但与本次要标记的requestentry不同,则不在使用这个skb,创建新的skb,拷贝数据并链接;如果本次没有标记任务,但skb已经有数据,并且已经被标记,则不再使用这个skb,创建新的skb。总之需要保证一个skb的数据,要么是不被标记的,要么是全部被标记的,不能出现一个skb中,一部分数据被标记,一部分没有被标记。
标记skb的目的是当skb进入IP_LOCAL_OUT的netfilter hook点的时候,可以方便,高效的从skb中获得request entry,包括skb发生重传的情况。这样从skb统计质量信息以后,可以方便的将质量信息存储到request entry中。如果不这么做,仅仅从skb的信息,很难查找到request entry。
进一步地,基于待发送的第二数据包的质量信息更新所述第二结构体,判断所述针对第一TCP连接的监测是否结束,若结束,则将所述第二结构体移至第二完成列表,基于所述第二完成列表生成第一TCP连接的质量日志信息。
发送数据包的第二部分是在netfilter中的IP_LOCAL_OUT hook函数,函数执行流程图如图7所示,这部分执行逻辑与图5中的接收数据包流程的tcp_v4_do_rcv_pre基本相同,不同的地方包括:获得request entry的方法,接收数据包是根据ack包的序号遍历查找,而发送数据包是直接从skb的结构体成员获得request entry;第二个地方是发送数据包的时候不需要判断request entry(第一结构体)是否监测结束,也就是不判断应用程序是否结束监测,这部分只在接收方向判断。不再赘述。
本申请的第四实施例,针对如何进行监测数据进行标记进行说明。
所述方法还包括:
应用层通过setsockopt函数对应用程序的数据段设置监测开始标记,和/或监测结束标记;
所述确定针对应用程序的监测开始,包括:
内核通过检测到应用程序的数据段的监测开始标记时,确定针对应用程序的监测开始。
具体来说,应用层如果想开始一段数据的标记,需要使用系统调用通知协议栈,这里直接使用setsockopt函数,内核中增加新的socket option提供给应用程序。比如:
按照上述的使用格式可以开启对一个写入数据段的标记,setsockopt标记数据段,不是以write为粒度的,不需要每次调用write都调用一次,例如:一个http响应分1000次write进行写入,那么只需要在一头一尾至多两次调用即可完成监测。同理,这里的http协议也可以推广为任意的应用层协议,只要应用程序可以确定一段数据的开始和结束即可。
setsockopt为应用程序提供四个socket选项:SO_STARTMON、SO_STOPMON、SO_STARTKEEPMON、SO_STOPKEEPMON。
SO_STARTMON:从现在开始对所有写入该socket的数据进行监测,如果已经有了一段正在进行的监测,将其标记为结束,并开始一段新的监测。
SO_STOPMON:从现在开始停止对写入该socket的数据进行监测。
SO_STARTKEEPMON:从现在开始对所有写入该socket的数据进行监测,如果已经有了一段正在进行的监测,将其标记为结束,并开始一段新的监测;同时表示这是一个持续的监测,该段监测结束后可能还有数据需要继续监测,不要直接将request entry发给用户态。
SO_STOPKEEPMON:从现在开始停止对写入该socket的数据进行监测;同时表示这是一个持续的监测,该段监测结束后可能还有数据需要继续监测,不要直接将requestentry发给用户态。
上述标记中,用于结束标记的SO_STOPMON函数可以不写,如果不写,那么确定应用程序的监测结束的一种方式可以为检测到其他数据段的开始监测标记。也就是,下一次再次调用SO_STARTMON或者SO_STARTKEEPMON的时候,在开始一个新的监测之前,会自动结束对上一段数据的监测。这样主要是为了减少系统调用的考虑的。如果监测数据段是不连续的,那么还是要调用STOPMON标志的系统调用。
所述应用层为所述内核传递以下至少一个参数:
所要监测的应用程序的数据段的标识;
域名信息;
流量类型;
netlink标识信息。
也就是,在使用setsockopt函数标记数据段的时候,应用层需要传递给协议栈的参数包括如下表1所示的内容:
表1
如此,应用程序标记数据段的时候可以通过传入流量类型字段为写入的数据段进行分类,方便后续收集到质量数据以后按照流量类型进行聚类分析,流量类型是应用程序自定义的。
具体来说,setsockopt传入SO_STARTMON选项时,函数内部执行流程图如图8所示,首先需要根据socketID查找sock,也就是查找五元组,根据五元组(即图中所示sock)查找Hash Table(第一哈希表)获得tcp entry(第二结构体);
如果查找不到tcp entry,说明该tcp连接没有被监测,所以不应该标记数据段,直接返回;
如果查找到tcp entry,则根据netlink id判断是否可以查找netlink socket,如果未查到,则说明netlink socket没有提前创建,质量信息不知道该发送给谁,所以直接返回。
如果可以查找netlink socket,根据request id查找request entry(第一结构体),如果没有找到则创建request entry(第一结构体),并设置起始序号;如果找到,则判断request entry(第一结构体)是否持续检测,也就是判断应用程序是否停止监测;若不持续检测,则直接返回,结束处理;
若持续检测,如果在request Hash Table(第二哈希表)中查找到了requestentry(第一结构体),并且这个request entry(第一结构体)是一段持续监测的数据段,则不必创建新的request entry,直接使用查找到的request entry。拿到request entry指针以后,需要查看当前tcp entry中的current_request_entry成员,如果不为空,则说明当前有正在监测的数据段,需要为它设置上结束序号,结束上一个监测;
然后设置current_request_entry指针替换成新的request entry,开始本次数据段的监测。
上述流程处理中,存在两个关键的处理,一是如何根据request id查找得到request entry,在上述处理中在内核中维护一个以request id做为key的Request HashTable,当创建request entry的时候,除了要把request entry链接进入tcp entry之外,还需要将request entry Hash进入Request Hash Table;第二个是为request entry设置起始序号。
进一步的,一个tcp连接可能包含多个监测的数据段,由于应用程序在写入监测数据段的时候,一定是把数据封装成skb并放到发送队列中才会返回,因此一个应用程序在一个TCP连接中只能同时标记一个数据段,不同的数据段彼此不会发生重叠,因此我们可以使用tcp的序号来标识一个request entry的开始和结束。开始序号和结束序号直接使用当前TCP协议栈已经使用到的序号。以图9为例,一个tcp连接的序号假设从0开始到80,已经写入10个Byte之后,开始标记request1,那么用序号10,作为起始序号。
在Packet Catcher模块中,tcp_sendmsg/tcp_sendpage函数中,封装skb以后,如果发现当前有正在监测的数据段,则将current_request_entry指针指向的request entry赋值给skb中的成员,完成标记。
使用SO_STOPMON选项结束数据监测是可选的,下一段数据段的监测的开始就表示本次数据段的监测的结束,如果希望主动的结束一段监测,可以直接调用本函数,该函数的核心逻辑就是为本次监测的request entry设置上结束序号,并设置tcp entry中的current request entry为NULL,表明从此刻开始,没有正在监测的数据段。setsockopt传入SO_STOPMON,选项时函数内部执行流程图如图10所示:
如果函数中发现没有查找到tcp entry、没有查找到netlink socket,则直接返回;如果current request entry为NULL(空),则当前没有正在监测的数据段,也不需要结束,直接返回;如果当前正在监测的request entry的request_id与传入的request_id不同,则说明需要结束的监测数据段不正确,直接返回;如果正在监测的request entry,已经被设置了结束序号,则不需要再设置,直接返回;如果未设置,则设置request entry结束序号,并设置current request entry为NULL,也就是可以确定结束对应用程序的监测。
SO_STARTKEEPMON,SO_STOPKEEPMON这两个标志对于执行流程上没有什么区别,只是在设置request entry的时候需要设置一个flag告诉这个request entry:当全部的监测数据都被ack以后先不要移动到第一完成列表中,后面还有数据需要继续被监测。
如图11所示,Packet Catcher中标记skb,需要查看当前是否有正在监测的数据段,需要使用到已经创建好的request entry。而创建request entry,是在应用程序调用系统调用开始标记数据段中去创建的。
通过本实施例可以看出,监测数据段的粒度可以是应用程序自定义的,并提前告知协议栈的,从而做到了很好的通用性,灵活性和拓展性。
本申请的第五实施例中,针对内核线程与日志写入的处理进行说明:
所述内核从第一完成列表中获取所述应用程序的第一结构体,将所述第一结构体的质量信息写入第一日志缓存,并释放所述第一结构体;当所述第一日志缓存内的字节数达到预设第一门限值时,刷新所述第一日志缓存将所述第一日志缓存内的所述质量信息作为应用程序的质量日志信息推送至应用层;
或者,
所述内核从第二完成列表中获取所述第一TCP连接的第二结构体,将所述第二结构体中的质量信息写入第二日志缓存,并释放所述第二结构体;当所述第二日志缓存内的字节数达到预设第二门限值时,刷新所述第二日志缓存将所述第二日志缓存内的所述质量信息作为第一TCP连接的质量日志信息推送至应用层。
内核中的内核线程的作用是将收集得到的质量信息写入日志或通过netlink推送到应用层。这包含两部工作,一是将tcp entry和request entry收集得到的质量数据进行进一步处理,得到最终输出的字符串格式的日志;二是将tcp entry写入日志,将requestentry通过netlink推送到应用层。这两部分工作都比较耗时,因此将他们放到单独的内核线程中去完成,避免影响性能。
内核线程与日志写入整体架构在图3中,连接结束后tcp entry会被移动到tcpcomplete list(第二完成列表)中,标记数据段结束监测以后,request entry会被移动到tcp complete list中。
以tcp complete list为例,为了提高性能,这里面将这个链表设计成per cpu链表,对于多cpu服务器来说,不同的cpu移动tcp entry的时候只需要移动到本cpu对应的tcpcomplete list即可,不需要与其他cpu进行同步;另外一个设计是将每个cpu的tcpcomplete list设计成两个:tcp complete list[2],所有cpu将连接结束的tcp entry移动到tcp complete list[0],内核线程负责遍历tcp complete list[1],将tcp entry写入日志,如果写入完成,则将tcp complete list[2]的两个链表进行交换,所有cpu将tcp entry移动到tcp complete list[1],而内核线程遍历tcp complete list[0],以此类推,request complete list同理,不再赘述。
内核线程内部代码执行逻辑如图12所示:
内核(内核线程)获取本cpu相关数据结构;对两个第二完成列表进行交换(关于两个列表交换的处理在前述实施例已经提供,这里不再赘述);
从tcp complete list(第二完成列表)中获取一个TCP entry(第二结构体),处理质量数据,将质量数据写入第二日志缓存,比如tcp日志缓存,并同时释放所述TCP entry(第二结构体);
判断tcp日志缓存是否已满,若是,则刷新tcp日志缓存,将缓存内容写入日志;若没有满,则判断tcp complete list(第二完成列表)是否需遍历完成,若没有完成则继续遍历tcp complete list(第二完成列表)。
针对request complete list(第一完成列表)的处理与上述处理类似,也可以包括先交换两个第一完成列表,从request complete list(第一完成列表)获取一个requestentry(第一结构体),将第一结构体内的质量数据写入第一日志缓存,也就是netlink日志缓存,同时释放request entry(第一结构体);若第一日志缓存,也就是netlink日志缓存,已满,则刷新netlink日志缓存,将缓存内容通过netlink推送至应用层。
需要理解的是,无论是tcp entry写日志,还是request entry通过netlink推送到应用层,日志数据都是先写到一个缓存中,缓存字节数累计超过阈值以后,才写入日志或通过netlink推送到应用层。在遍历完本cpu的tcp complete list和request complete list以后,再刷新一次缓存,进行下一次处理。
本申请的第六实施例,对质量信息可以包含的具体内容进行说明,参见以下表格:
表2连接基本信息
表3连接数据包发送信息
表4窗口相关信息
表5时间相关信息
表6数据量相关信息
表7数据量相关信息
对于应用程序主动标记的数据段的质量信息,其统计项与TCP输出的日志信息基本相同。
本申请的第七实施例提供一种质量监测装置,如图13所示,包括:
第一创建模块31,用于确定针对应用程序的监测开始,创建所述应用程序的第一结构体;
数据包处理模块32,用于将监测开始之后的所述应用程序的数据包的质量信息,添加至所述应用程序的第一结构体中;
日志生成模块33,用于确定针对所述应用程序的监测结束,基于所述应用程序的第一结构体生成所述应用程序的质量日志信息。
如图14所示,所述装置还包括:
第二创建模块34,用于创建针对第一TCP连接的第二结构体;其中,所述第一TCP连接为所述第一结构体所属的TCP连接;
所述数据包处理模块32,用于将所述第一TCP连接上传输的数据包的质量信息添加至所述第二结构体中;
所述日志生成模块33,用于若确定针对第一TCP连接的监测结束,则基于所述第二结构体生成针对所述第一TCP连接的质量日志信息。
其中,所述日志生成模块33,用于确定针对所述应用程序的监测结束的方式,包括以下之一:
应用程序所属的第一TCP连接的监测结束;
基于针对应用程序的监测结束标记确定针对所述应用程序的监测结束;
检测到其他数据段的开始监测标记。
所述第二创建模块34,用于根据接收的第一数据包的TCP五元组,查找第一哈希表中是否存在与所述TCP五元组对应的第二结构体;
若第一哈希表中不存在与所述TCP五元组对应的第二结构体,则判断所述第一数据包是否为同步数据包,若是同步数据包,则基于所述第一数据包的TCP五元组创建第一TCP连接的第二结构体,并将所述第一TCP连接的第二结构体插入到所述第一哈希表。
所述日志生成模块33,用于基于第一数据包的质量信息更新所述第一结构体,判断所述应用程序的监测是否结束,若结束,则将所述应用程序所对应的第一结构体移至第一完成列表,基于所述第一完成列表生成应用程序的质量日志信息;
以及,基于第一数据包的质量信息更新所述第二结构体,判断所述针对第一TCP连接的监测是否结束,若结束,则将所述第二结构体移至第二完成列表,基于所述第二完成列表生成第一TCP连接的质量日志信息。
所述数据包处理模块32,用于若所述应用程序的监测未结束,并且所述第二结构体的检测未结束,则基于所述第一数据包获取第一TCP连接的拥塞控制状态的相关质量信息。
所述第二创建模块34,用于根据待发送的第二数据包的TCP五元组,查找第一哈希表中是否存在与所述TCP五元组对应的第二结构体;
若第一哈希表中不存在与所述TCP五元组对应的第二结构体,则判断所述第二数据包是否为同步数据包,若是同步数据包,则基于所述第二数据包的TCP五元组创建第一TCP连接的第二结构体,并将所述第一TCP连接的第二结构体插入到所述第一哈希表。
所述日志生成模块33,用于基于待发送的第二数据包的质量信息更新所述第二结构体,判断所述针对第一TCP连接的监测是否结束,若结束,则将所述第二结构体移至第二完成列表,基于所述第二完成列表生成第一TCP连接的质量日志信息。
所述装置还包括:
应用层处理模块35,用于通过setsockopt函数对应用程序的数据段设置监测开始标记,和/或监测结束标记;
相应的,所述第一创建模块31,用于检测到应用程序的数据段的监测开始标记时,确定针对应用程序的监测开始。
所述应用层处理模块35,用于为所述内核传递以下至少一个参数:
所要监测的应用程序的数据段的标识;
域名信息;
流量类型;
netlink标识信息。
所述日志生成模块33,用于从第一完成列表中获取所述应用程序的第一结构体,将所述第一结构体的质量信息写入第一日志缓存,并释放所述第一结构体;当所述第一日志缓存内的字节数达到预设第一门限值时,刷新所述第一日志缓存将所述第一日志缓存内的所述质量信息作为应用程序的质量日志信息推送至应用层;
或者,
从第二完成列表中获取所述第一TCP连接的第二结构体,将所述第二结构体中的质量信息写入第二日志缓存,并释放所述第二结构体;当所述第二日志缓存内的字节数达到预设第二门限值时,刷新所述第二日志缓存将所述第二日志缓存内的所述质量信息作为第一TCP连接的质量日志信息推送至应用层。
根据本申请的实施例,本申请还提供了一种服务器、一种可读存储介质和一种计算机程序产品。
如图15所示,是根据本申请实施例的质量监测方法的服务器的框图。服务器旨在表示各种形式的数字计算机,诸如,膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。
如图15所示,该服务器包括:一个或多个处理器801、存储器802,以及用于连接各部件的接口,包括高速接口和低速接口。各个部件利用不同的总线互相连接,并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理,包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如,耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中,若需要,可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样,可以连接多个电子设备,各个设备提供部分必要的操作(例如,作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图15中以一个处理器801为例。
存储器802即为本申请所提供的非瞬时计算机可读存储介质。其中,所述存储器存储有可由至少一个处理器执行的指令,以使所述至少一个处理器执行本申请所提供的质量监测方法。本申请的非瞬时计算机可读存储介质存储计算机指令,该计算机指令用于使计算机执行本申请所提供的质量监测方法。
存储器802作为一种非瞬时计算机可读存储介质,可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块,如本申请实施例中的质量监测方法对应的程序指令/模块。处理器801通过运行存储在存储器802中的非瞬时软件程序、指令以及模块,从而执行服务器的各种功能应用以及数据处理,即实现上述方法实施例中的质量监测方法。
存储器802可以包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需要的应用程序;存储数据区可存储根据电子设备的使用所创建的数据等。此外,存储器802可以包括高速随机存取存储器,还可以包括非瞬时存储器,例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中,存储器802可选包括相对于处理器801远程设置的存储器,这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
质量监测方法的服务器还可以包括:输入装置803和输出装置804。处理器801、存储器802、输入装置803和输出装置804可以通过总线或者其他方式连接,图15中以通过总线连接为例。
输入装置803可接收输入的数字或字符信息,以及产生与电子设备的用户设置以及功能控制有关的键信号输入,例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置804可以包括显示设备、辅助照明装置(例如,LED)和触觉反馈装置(例如,振动电机)等。该显示设备可以包括但不限于,液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中,显示设备可以是触摸屏。
此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括:实施在一个或者多个计算机程序中,该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释,该可编程处理器可以是专用或者通用可编程处理器,可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令,并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令,并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的,术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如,磁盘、光盘、存储器、可编程逻辑装置(PLD)),包括,接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。
为了提供与用户的交互,可以在计算机上实施此处描述的系统和技术,该计算机具有:用于向用户显示信息的显示装置(例如,CRT(阴极射线管)或者LCD(液晶显示器)监视器);以及键盘和指向装置(例如,鼠标或者轨迹球),用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的传感反馈(例如,视觉反馈、听觉反馈、或者触觉反馈);并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如,作为数据服务器)、或者包括中间件部件的计算系统(例如,应用服务器)、或者包括前端部件的计算系统(例如,具有图形用户界面或者网络浏览器的用户计算机,用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如,通信网络)来将系统的部件相互连接。通信网络的示例包括:局域网(LAN)、广域网(WAN)和互联网。
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。
应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本申请公开的技术方案所期望的结果,本文在此不进行限制。
上述具体实施方式,并不构成对本申请保护范围的限制。本领域技术人员应该明白的是,根据设计要求和其他因素,可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等,均应包含在本申请保护范围之内。
Claims (22)
1.一种质量监测方法,包括:
确定针对应用程序的监测开始,创建所述应用程序的第一结构体;
将监测开始之后的所述应用程序的数据包的质量信息,添加至所述应用程序的第一结构体中;
确定针对所述应用程序的监测结束,基于所述应用程序的第一结构体生成所述应用程序的质量日志信息,所述基于所述应用程序的第一结构体生成所述应用程序的质量日志信息包括:将所述应用程序所对应的第一结构体移至第一完成列表,基于所述第一完成列表生成应用程序的质量日志信息;
所述方法还包括:
应用层通过setsockopt函数对应用程序的数据段设置监测开始标记,和/或监测结束标记;
相应的,所述确定针对应用程序的监测开始,包括:
内核通过检测到应用程序的数据段的监测开始标记时,确定针对应用程序的监测开始。
2.根据权利要求1所述的方法,其中,所述确定针对应用程序的监测开始之前,所述方法还包括:
创建针对第一TCP连接的第二结构体;其中,所述第一TCP连接为所述第一结构体所属的TCP连接;
将所述第一TCP连接上传输的数据包的质量信息添加至所述第二结构体中;
若确定针对第一TCP连接的监测结束,则基于所述第二结构体生成针对所述第一TCP连接的质量日志信息。
3.根据权利要求2所述的方法,其中,确定针对所述应用程序的监测结束的方式,包括以下之一:
应用程序所属的第一TCP连接的监测结束;
基于针对应用程序的监测结束标记确定针对所述应用程序的监测结束;
检测到其他数据段的开始监测标记。
4.根据权利要求2所述的方法,其中,所述创建针对第一TCP连接的第二结构体,还包括:
根据接收的第一数据包的TCP五元组,查找第一哈希表中是否存在与所述TCP五元组对应的第二结构体;
若第一哈希表中不存在与所述TCP五元组对应的第二结构体,则判断所述第一数据包是否为同步数据包,若是同步数据包,则基于所述第一数据包的TCP五元组创建第一TCP连接的第二结构体,并将所述第一TCP连接的第二结构体插入到所述第一哈希表。
5.根据权利要求4所述的方法,其中,所述方法还包括:
基于第一数据包的质量信息更新所述第一结构体,判断所述应用程序的监测是否结束,若结束,则将所述应用程序所对应的第一结构体移至第一完成列表,基于所述第一完成列表生成应用程序的质量日志信息;
以及,基于第一数据包的质量信息更新所述第二结构体,判断所述针对第一TCP连接的监测是否结束,若结束,则将所述第二结构体移至第二完成列表,基于所述第二完成列表生成第一TCP连接的质量日志信息。
6.根据权利要求5所述的方法,其中,所述方法还包括:
若所述应用程序的监测未结束,并且所述第二结构体的检测未结束,则基于所述第一数据包获取第一TCP连接的拥塞控制状态的相关质量信息。
7.根据权利要求2所述的方法,其中,所述创建针对第一TCP连接的第二结构体,包括:
根据待发送的第二数据包的TCP五元组,查找第一哈希表中是否存在与所述TCP五元组对应的第二结构体;
若第一哈希表中不存在与所述TCP五元组对应的第二结构体,则判断所述第二数据包是否为同步数据包,若是同步数据包,则基于所述第二数据包的TCP五元组创建第一TCP连接的第二结构体,并将所述第一TCP连接的第二结构体插入到所述第一哈希表。
8.根据权利要求7所述的方法,其中,所述方法还包括:
基于待发送的第二数据包的质量信息更新所述第二结构体,判断所述针对第一TCP连接的监测是否结束,若结束,则将所述第二结构体移至第二完成列表,基于所述第二完成列表生成第一TCP连接的质量日志信息。
9.根据权利要求1-8任一项所述的方法,其中,所述应用层通过setsockopt函数对应用程序的数据段设置监测开始标记,和/或监测结束标记时,所述方法还包括:
所述应用层为所述内核传递以下至少一个参数:
所要监测的应用程序的数据段的标识;
域名信息;
流量类型;
netlink标识信息。
10.根据权利要求5或8所述的方法,其中,所述方法还包括:
内核从第一完成列表中获取所述应用程序的第一结构体,将所述第一结构体的质量信息写入第一日志缓存,并释放所述第一结构体;当所述第一日志缓存内的字节数达到预设第一门限值时,刷新所述第一日志缓存将所述第一日志缓存内的所述质量信息作为应用程序的质量日志信息推送至应用层;
或者,
内核从第二完成列表中获取所述第一TCP连接的第二结构体,将所述第二结构体中的质量信息写入第二日志缓存,并释放所述第二结构体;当所述第二日志缓存内的字节数达到预设第二门限值时,刷新所述第二日志缓存将所述第二日志缓存内的所述质量信息作为第一TCP连接的质量日志信息推送至应用层。
11.一种质量监测装置,包括:
第一创建模块,用于确定针对应用程序的监测开始,创建所述应用程序的第一结构体;
数据包处理模块,用于将监测开始之后的所述应用程序的数据包的质量信息,添加至所述应用程序的第一结构体中;
日志生成模块,用于确定针对所述应用程序的监测结束,基于所述应用程序的第一结构体生成所述应用程序的质量日志信息,所述基于所述应用程序的第一结构体生成所述应用程序的质量日志信息包括:将所述应用程序所对应的第一结构体移至第一完成列表,基于所述第一完成列表生成应用程序的质量日志信息;
所述装置还包括:
应用层处理模块,用于通过setsockopt函数对应用程序的数据段设置监测开始标记,和/或监测结束标记;
相应的,所述第一创建模块,用于检测到应用程序的数据段的监测开始标记时,确定针对应用程序的监测开始。
12.根据权利要求11所述的装置,其中,所述装置还包括:
第二创建模块,用于创建针对第一TCP连接的第二结构体;其中,所述第一TCP连接为所述第一结构体所属的TCP连接;
所述数据包处理模块,用于将所述第一TCP连接上传输的数据包的质量信息添加至所述第二结构体中;
所述日志生成模块,用于若确定针对第一TCP连接的监测结束,则基于所述第二结构体生成针对所述第一TCP连接的质量日志信息。
13.根据权利要求12所述的装置,其中,所述日志生成模块,用于确定针对所述应用程序的监测结束的方式,包括以下之一:
应用程序所属的第一TCP连接的监测结束;
基于针对应用程序的监测结束标记确定针对所述应用程序的监测结束;
检测到其他数据段的开始监测标记。
14.根据权利要求12所述的装置,其中,所述第二创建模块,用于根据接收的第一数据包的TCP五元组,查找第一哈希表中是否存在与所述TCP五元组对应的第二结构体;
若第一哈希表中不存在与所述TCP五元组对应的第二结构体,则判断所述第一数据包是否为同步数据包,若是同步数据包,则基于所述第一数据包的TCP五元组创建第一TCP连接的第二结构体,并将所述第一TCP连接的第二结构体插入到所述第一哈希表。
15.根据权利要求14所述的装置,其中,所述日志生成模块,用于基于第一数据包的质量信息更新所述第一结构体,判断所述应用程序的监测是否结束,若结束,则将所述应用程序所对应的第一结构体移至第一完成列表,基于所述第一完成列表生成应用程序的质量日志信息;
以及,基于第一数据包的质量信息更新所述第二结构体,判断所述针对第一TCP连接的监测是否结束,若结束,则将所述第二结构体移至第二完成列表,基于所述第二完成列表生成第一TCP连接的质量日志信息。
16.根据权利要求15所述的装置,其中,所述数据包处理模块,用于若所述应用程序的监测未结束,并且所述第二结构体的检测未结束,则基于所述第一数据包获取第一TCP连接的拥塞控制状态的相关质量信息。
17.根据权利要求12所述的装置,其中,所述第二创建模块,用于根据待发送的第二数据包的TCP五元组,查找第一哈希表中是否存在与所述TCP五元组对应的第二结构体;
若第一哈希表中不存在与所述TCP五元组对应的第二结构体,则判断所述第二数据包是否为同步数据包,若是同步数据包,则基于所述第二数据包的TCP五元组创建第一TCP连接的第二结构体,并将所述第一TCP连接的第二结构体插入到所述第一哈希表。
18.根据权利要求17所述的装置,其中,所述日志生成模块,用于基于待发送的第二数据包的质量信息更新所述第二结构体,判断所述针对第一TCP连接的监测是否结束,若结束,则将所述第二结构体移至第二完成列表,基于所述第二完成列表生成第一TCP连接的质量日志信息。
19.根据权利要求11-18任一项所述的装置,其中,所述应用层处理模块,用于为内核传递以下至少一个参数:
所要监测的应用程序的数据段的标识;
域名信息;
流量类型;
netlink标识信息。
20.根据权利要求15或18所述的装置,其中,所述日志生成模块,用于从第一完成列表中获取所述应用程序的第一结构体,将所述第一结构体的质量信息写入第一日志缓存,并释放所述第一结构体;当所述第一日志缓存内的字节数达到预设第一门限值时,刷新所述第一日志缓存将所述第一日志缓存内的所述质量信息作为应用程序的质量日志信息推送至应用层;
或者,
从第二完成列表中获取所述第一TCP连接的第二结构体,将所述第二结构体中的质量信息写入第二日志缓存,并释放所述第二结构体;当所述第二日志缓存内的字节数达到预设第二门限值时,刷新所述第二日志缓存将所述第二日志缓存内的所述质量信息作为第一TCP连接的质量日志信息推送至应用层。
21. 一种服务器,包括:
至少一个处理器;以及
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行权利要求1-10中任一项所述的方法。
22.一种存储有计算机指令的非瞬时计算机可读存储介质,所述计算机指令用于使所述计算机执行权利要求1-10中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010525411.8A CN111722979B (zh) | 2020-06-10 | 2020-06-10 | 质量监测方法、装置、服务器及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010525411.8A CN111722979B (zh) | 2020-06-10 | 2020-06-10 | 质量监测方法、装置、服务器及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111722979A CN111722979A (zh) | 2020-09-29 |
CN111722979B true CN111722979B (zh) | 2024-02-13 |
Family
ID=72566372
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010525411.8A Active CN111722979B (zh) | 2020-06-10 | 2020-06-10 | 质量监测方法、装置、服务器及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111722979B (zh) |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103297407A (zh) * | 2012-03-02 | 2013-09-11 | 百度在线网络技术(北京)有限公司 | 传递客户端IPv6地址及端口至后端服务器的方法及装置 |
CN103825783A (zh) * | 2014-03-10 | 2014-05-28 | 珠海市君天电子科技有限公司 | 一种测试方法及装置 |
WO2016082371A1 (zh) * | 2014-11-25 | 2016-06-02 | 中国科学院声学研究所 | 一种基于ssh协议的会话解析方法及系统 |
CN106411558A (zh) * | 2015-07-27 | 2017-02-15 | 阿里巴巴集团控股有限公司 | 一种数据流量限制的方法及系统 |
CN108377223A (zh) * | 2018-01-05 | 2018-08-07 | 网宿科技股份有限公司 | 一种多包识别方法、数据包识别方法及流量引导方法 |
CN108462590A (zh) * | 2017-02-20 | 2018-08-28 | 阿里巴巴集团控股有限公司 | 网络流量的监控方法及装置、计算机终端 |
WO2019137208A1 (zh) * | 2018-01-11 | 2019-07-18 | 贵州白山云科技股份有限公司 | 一种底层数据监控方法、介质、设备及装置 |
CN110404267A (zh) * | 2019-08-19 | 2019-11-05 | 福建天晴在线互动科技有限公司 | 一种基于http流量host字段特征的游戏外挂检测方法 |
CN111193608A (zh) * | 2019-11-19 | 2020-05-22 | 腾讯云计算(北京)有限责任公司 | 网络质量探测监控方法、装置、系统和计算机设备 |
-
2020
- 2020-06-10 CN CN202010525411.8A patent/CN111722979B/zh active Active
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103297407A (zh) * | 2012-03-02 | 2013-09-11 | 百度在线网络技术(北京)有限公司 | 传递客户端IPv6地址及端口至后端服务器的方法及装置 |
CN103825783A (zh) * | 2014-03-10 | 2014-05-28 | 珠海市君天电子科技有限公司 | 一种测试方法及装置 |
WO2016082371A1 (zh) * | 2014-11-25 | 2016-06-02 | 中国科学院声学研究所 | 一种基于ssh协议的会话解析方法及系统 |
CN106411558A (zh) * | 2015-07-27 | 2017-02-15 | 阿里巴巴集团控股有限公司 | 一种数据流量限制的方法及系统 |
CN108462590A (zh) * | 2017-02-20 | 2018-08-28 | 阿里巴巴集团控股有限公司 | 网络流量的监控方法及装置、计算机终端 |
CN108377223A (zh) * | 2018-01-05 | 2018-08-07 | 网宿科技股份有限公司 | 一种多包识别方法、数据包识别方法及流量引导方法 |
WO2019137208A1 (zh) * | 2018-01-11 | 2019-07-18 | 贵州白山云科技股份有限公司 | 一种底层数据监控方法、介质、设备及装置 |
CN110404267A (zh) * | 2019-08-19 | 2019-11-05 | 福建天晴在线互动科技有限公司 | 一种基于http流量host字段特征的游戏外挂检测方法 |
CN111193608A (zh) * | 2019-11-19 | 2020-05-22 | 腾讯云计算(北京)有限责任公司 | 网络质量探测监控方法、装置、系统和计算机设备 |
Also Published As
Publication number | Publication date |
---|---|
CN111722979A (zh) | 2020-09-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11252224B2 (en) | Utilizing multiple connections for generating a job result | |
US9634915B2 (en) | Methods and computer program products for generating a model of network application health | |
JP6599538B2 (ja) | ネットワークトラフィックにおけるアプリケーション情報を識別するための方法および装置 | |
US8145859B2 (en) | Method and system for spilling from a queue to a persistent store | |
US8452842B2 (en) | Controlling retention of publications | |
US9154397B2 (en) | Methods and computer program products for transaction relationships between application servers | |
US9197520B2 (en) | Methods and computer program products for transaction analysis of network traffic in a network device | |
US8868727B2 (en) | Methods and computer program products for storing generated network application performance data | |
US8949418B2 (en) | Firewall event reduction for rule use counting | |
US8909761B2 (en) | Methods and computer program products for monitoring and reporting performance of network applications executing in operating-system-level virtualization containers | |
US8589537B2 (en) | Methods and computer program products for aggregating network application performance metrics by process pool | |
US20120204193A1 (en) | Methods and computer program products for monitoring system calls using safely removable system function table chaining | |
JP2018531527A6 (ja) | ネットワークトラフィックにおけるアプリケーション情報を識別するための方法および装置 | |
CA2424006A1 (en) | A technique to generically manage extensible correlation data | |
CA2807759C (en) | Application monitoring | |
US8312138B2 (en) | Methods and computer program products for identifying and monitoring related business application processes | |
CN111722979B (zh) | 质量监测方法、装置、服务器及存储介质 | |
US8346853B2 (en) | Methods, systems, and computer program products for processing an attached command response | |
CN111597026B (zh) | 用于获取信息的方法及装置 | |
CA2831134A1 (en) | Identification of code synchronization points | |
CN118245643A (zh) | 一种流表查询方法、装置、电子设备及存储介质 | |
CN113609094A (zh) | 一种控制数据下刷的方法、系统、设备及介质 | |
But | ANGEL flow meter software architecture design document |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |