应用包名的获取方法、数据包的传输方法及终端设备与流程

本发明实施例涉及数据处理技术领域，特别涉及一种应用包名的获取方法、数据包的传输方法及终端设备。

背景技术

随着互联网技术的不断发展，各种应用程序不断涌现；为了提供更好的用户体验，针对应用程序的网络加速服务也逐渐兴起。通常的，以android系统为例，终端内的加速代理一般被设计成能够控制对某个应用是否进行加速，且一般通过应用包名来区分不同应用的流量；具体的说，加速代理接收内核空间重定向过来的数据包后，会访问终端的磁盘，从磁盘的数据信息中查询得到数据包的应用唯一标志uid，并根据uid查询数据包对应的应用包名，从而根据应用包名来区分不同应用的流量。

发明人发现现有技术中至少存在如下问题：终端内的加速代理先要通过查询磁盘中的数据信息得到uid，再通过uid获取数据包对应的应用包名。但是，查询磁盘中的数据信息以获得uid的过程会产生大量io调用，且通常查询一次要耗时20-100ms，低效耗时；因此从开始查询到查询得出结果需要较长时间；因此导致获取应用包名的时间较长，不仅会造成代理程序转发数据包延迟，还有可能导致时间太久而数据信息已经被系统删除的情况发生(例如，当查询时时间大于数据包从发起到关闭的时间)。

技术实现要素：

本发明实施方式的目的在于提供一种应用包名的获取方法、数据包的传输方法及终端设备，能够提高应用包名的查询速度，从而提高本地代理转发数据包的速度，并且，可以极大程度地避免由于本地代理转发时间太久，而造成数据信息因超过其存放周期而被系统清除的情况发生。

为解决上述技术问题，本发明的实施方式提供了一种应用包名的获取方法，应用于本地代理，所述方法包括：当接收到本地系统重定向过来的数据包时，向所述本地系统发送日志获取请求；判断是否接收到所述本地系统反馈的至少一日志；若接收到所述本地系统反馈的至少一日志，则判断接收的所述日志中是否存在所述数据包对应的日志；若判定接收的所述日志中存在所述数据包对应的日志时，从所述数据包对应的日志中获取所述数据包对应的身份信息；根据所述身份信息获取所述数据包对应的应用包名。

本发明的实施方式还提供了一种数据包的传输方法，包括：根据上述应用包名的获取方法，获取所述数据包对应的应用包名；判断所述数据包对应的应用包名是否存在于预设的允许加速名单中；若是，则将所述数据包发送至加速服务器，以通过所述加速服务器发送至源站；若否，则将所述数据包发送至所述源站。

本发明的实施方式还提供了一种终端设备，所述终端设备包括本地代理、本地系统、至少一个本地应用；所述本地应用用于生成所述数据包；所述本地系统用于对所述数据包进行拦截，并将所述数据包重定向至所述本地代理；所述本地代理用于执行上述应用包名的获取方法，以获取所述数据包对应的应用包名。

本发明实施方式相对于现有技术而言，当接收到本地系统重定向过来的数据包时，向所述本地系统发送日志获取请求，并且在接收到本地系统反馈的日志时，判断接收的日志中是否存在所述数据包对应的日志。即，当接收到本地系统重定向过来的数据包时，直接访问本地系统，并通过本地系统反馈的日志来获取数据包对应的身份信息，进而获取数据包对应的应用包名。由于对本地系统(即内存)的访问速度相较于现有的对磁盘的访问速度要快很多，因此，可以极大地提高应用包名的查询速度，从而提高本地代理转发数据包的速度；并且，可以极大程度地避免由于本地代理转发时间太久，而造成数据包日志因超过其存放周期而被系统清除中的情况发生。

另外，所述判断是否接收到所述本地系统反馈的至少一日志中，所述至少一日志为一组多个日志，且这组多个日志的数量小于或等于预设值；若判定接收的所述这组多个日志中不存在所述数据包对应的日志，则进入所述向所述本地系统发送日志获取请求的步骤。若未接收到所述本地系统反馈的一组多个日志，则判定不存在所述数据包对应的日志。本实施例中，本地代理一次调用只接收到一组多个日志(而不是所有日志)，且可以通过多次调用来获取所有日志；本地代理会对本次调用获取的这组日志进行判断后再决定是否要继续下次调用，从而，当本次调用获取的这组日志中存在该数据包对应的日志，则可以不用再获取后续的日志。因此，相对于第一实施例而言，第二实施例中的技术方案可以以更快的速度找到该数据包对应的日志，从而能够进一步提高应用包名的查询速度，并能够进一步提高本地代理转发数据包的速度。

另外，所述身份信息包括应用唯一标识和数据包唯一标识。进一步的，所述根据所述身份信息获取所述数据包对应的应用包名，具体包括：判断所述应用唯一标识是否能够用于查询应用包名；若能够，则根据所述应用唯一标识获取所述数据包对应的应用包名；若不能够，则根据所述数据包唯一标识获取所述数据包对应的应用包名。本实施例中，身份信息同时包括uid和inode，由于使用应用唯一标识获取应用包名较使用数据包唯一标识速度快，故优先使用应用唯一标识获取应用包名，只有在应用唯一标识无法查询应用包名时，才使用数据包唯一标识进行查询，因此能够以尽可能快的速度获取到该数据包对应的应用包名。

另外，所述身份信息为应用唯一标识或数据包唯一标识；所述从所述数据包对应的日志中获取所述数据包对应的身份信息，具体包括：从所述数据包对应的日志中获取所述应用唯一标识；判断所述应用唯一标识是否能够用于查询应用包名；若不能够，则从所述数据包对应的日志中获取数据包唯一标识。本实施例提供了使用身份信息获取应用包名的另一种方式。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是根据本申请第一实施例的应用包名的获取方法的流程图；

图2是根据本申请第二实施例的应用包名的获取方法的流程图；

图3是根据本申请第三实施例的应用包名的获取方法的流程图；

图4是根据本申请第四实施例的应用包名的获取方法的流程图；

图5是根据本申请第五实施例的数据包的传输方法的流程图；

图6是根据本申请第六实施例的终端设备的方框示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。

本发明的第一实施方式涉及一种应用包名的获取方法，应用于终端设备中的本地代理。具体而言，终端设备包括本地系统、本地代理以及至少一个应用程序；其中，应用程序用于为用户提供护体业务服务，本地代理可以被设计成能够控制对某个应用程序发送的数据包是否进行加速，本地系统为基于linux内核的android系统，其位于内核空间，而本地代理和应用程序都位于用户空间；且内核空间与用户空间通过netlink通信机制进行通信。需要说明的是，本申请的各实施例中，均以基于linux内核的android系统，netlink通信机制为例进行说明；然本申请对此不作任何限制，凡是能够适用于本申请之技术方案的本地系统以及通信机制均属于本申请所保护的范围内。

本实施方式中的应用包名的获取方法，如图1所示，具体包括如下步骤：

步骤101：判断是否接收到本地系统重定向过来的数据包。若是，则进入步骤102；若否，则重复本步骤。

具体而言，在android系统的应用代理加速中，linux内核会对流量进行拦截，并将流量引导至本地代理，以供本地代理进行相应的处理；即，linux内核会对应用程序发送出来的网络数据包进行拦截，并将需要加速的网络数据包重定向至本地代理。

本地代理在初始化时就会创建监听端口(例如创建监听端口8123)，用于接收linux内核重定向过来的数据包。其中，本实施例中所提到的数据包均是指应用程序发送出来且由linux内核拦截后重定向至本地代理的网络数据包。

步骤102：向本地系统发送日志获取请求。

本地代理在接收到数据包后，向linux内核发送日志获取请求，并等待接收本地系统的反馈；即本地代理在接收到数据包后进行netlink调用。具体而言，本地代理创建netlinksocket(即netlink套接字)，并发送sock_diag_by_family类型的请求至linux内核，以等待linux内核反馈信息；其中，sock_diag_by_family类型的请求是netlink通信机制中专门用于获取网络数据包日志的请求(即本实施中所述的日志获取请求)，linux内核接收到该请求后，就会试图反馈网络数据包日志(linux内核中存在网络数据包日志时就会反馈，不存在时则无反馈)。

步骤103：判断是否接收到本地系统反馈的至少一日志。若是，则进入步骤104；若否，则结束。

步骤104：判断接收的日志中是否存在数据包对应的日志。若是，则进入步骤105；若否，则结束。

其中，本地代理在一次netlink调用后，linux内核反馈的日志可能是一个，也可能是多个，本地代理会对接收的每个日志进行判断，以确定接收的日志中是否存在该数据包对应的日志。这里的日志即使指数据包日志，用于记录数据包的各种信息。

在一个例子中，linux内核反馈的日志为linux内核中的所有日志，即，本地代理通过一次netlink调用可以获取linux内核内的所有日志，然后依次判断接收的各日志是否为该数据包对应的日志。linux内核反馈的日志的具体实现方式为：linux内核获取所有日志对应的链表，将该链表的首地址反馈给本地代理，本地代理根据该链表的链表指针依次查询各日志，以对各日志进行判断。

其中，本地代理通过数据包源端口来判断是否存在该数据包对应的日志，即步骤104具体包括：

首先，从数据包中获取数据包源端口；即，本地代理接收到数据包后，从数据包的socket中获取数据包源端口。

其次，对于接收的每个日志，从日志中获取数据包源端口，并判断从日志中获取的数据包源端口与从数据包中获取的数据包源端口是否匹配；若匹配，则判定存在数据包对应的日志。即，本地代理先获取第一个链表指针，并从第一个链表指针对应的日志中获取数据包源端口，其中在netlink通信机制中，日志为inet_diag_msg结构体，本地代理会对该inet_diag_msg结构体进行解析，并获取数据包源端口inet_diag_msg.id.idiag_sport；然后判断从该日志中获取的数据包源端口与从数据包中获取的数据包源端口是否匹配；如果匹配，表示该日志就是该数据包对应的日志，即判定存在该数据包对应的日志，并将进入步骤105；如果不匹配，本地代理获取第二个链表指针，……；依次类推，直至对链表末尾(最后一个链表指针)；如果没有一个日志与该数据包对应，则表示接收的日志中不存在数据包对应的日志。

需要说明的是，从数据包中获取数据包源端口这个步骤，也可以在接收到本地系统重定向过来的数据包(步骤101)之后，且在判断从日志中获取的数据包源端口与从数据包中获取的数据包源端口是否匹配之前的任一时刻执行。

步骤105：从数据包对应的日志中获取数据包对应的身份信息。

具体而言，本地代理会对该inet_diag_msg结构体(日志)进行解析，并读取该inet_diag_msg结构中的身份信息。

步骤106：根据身份信息获取数据包对应的应用包名。

具体而言，本地代理可以查询磁盘中预存的身份信息与应用包名的对应关系，从而获取该数据包对应的应用包名。其中，该数据包对应的应用包名是指发送该数据包的应用程序的包名。

本实施方式相对于现有技术而言，当接收到本地系统重定向过来的数据包时，向所述本地系统发送日志获取请求，并且在接收到本地系统反馈的日志时，判断接收的日志中是否存在所述数据包对应的日志。即，当接收到本地系统重定向过来的数据包时，直接访问本地系统，并通过本地系统反馈的日志来获取数据包对应的身份信息，进而获取数据包对应的应用包名。由于对本地系统(即内存)的访问速度相较于现有的对磁盘的访问速度要快很多，因此，可以极大地提高应用包名的查询速度，从而提高本地代理转发数据包的速度；并且，可以极大程度地避免由于本地代理转发时间太久，而造成数据包日志因超过其存放周期而被系统清除中的情况发生。

本发明的第二实施方式涉及一种应用包名的获取方法。第二实施方式与第一实施方式大致相同，主要区别之处在于：在第一实施例中，本地代理一次调用获取本地系统内的所有日志；而在第二实施方式中，本地代理可以分多次调用来获取日志，每次调用获取一组多个日志。

如图2所示为第二实施例的具体流程图，其中，步骤201至步骤202、步骤205至步骤206与第一实施例中的步骤101至步骤103、步骤105至步骤106分别对应相似，此处不再赘述，不同之处在于：

步骤203：判断是否接收到本地系统反馈一组多个日志；若是，则进入步骤204；若否，则结束。

步骤204：判断接收的这组多个日志中是否存在数据包对应的日志。若是，则进入步骤205；若否，则返回步骤202。

具体而言，linux内核可以被预先设定为：接收到一次netlink调用时，反馈一组日志；本地代理判断这组日志中是否存在数据包对应的日志，如果存在，则进入步骤205；如果不存在，则本地代理发起下一次netlink调用，linux内核反馈下一组日志；……；依次类推；如果本地代理在某次netlink调用后没有接收到linux内核的日志，则表示linux内核已无日志可反馈了(表示前几次已经反馈了全部日志)。其中，每组日志的数量小于或等于预设值。例如预设值为20，表示每次最多反馈20个日志。

在一个例子中，假设linux内核中总共有115个日志，预设值为20(即每组反馈的日志数量小于或等于20)；则该115个日志可以分为六组，第一组至第五组均包括20个日志，第六组包括15个日志。本地代理在接收到linux内核重定向过来的数据包时，发起第一次netlink调用(即第一次发送日志获取请求)，linux内核反馈第一组日志(第1至第20个日志)，如果第一组日志中存在该数据包对应的日志，则进入步骤205，此时本地代理无需再进行下次一netlink调用(无需再获取第21至第115个日志)；如果第一组日志中不存在该数据包对应的日志，则本地代理发起第二次调用，linux内核反馈第二组日志(第21至第30个日志)，如果第二组日志中存在该数据包对应的日志，则进入步骤205，此时本地代理无需再进行下次一netlink调用(无需再获取第31至第115个日志)；如果第二组日志中不存在该数据包对应的日志，则本地代理发起第三次调用；……；以此类推。

本实施例中的步骤204的具体实现方式与第一实施例中的步骤104类似，对于接收的这组日志，也是通过数据包源端口来判断这组日志中是否存在该数据包对应的日志；较佳的，本实施例中的从数据包中获取数据包源端口这个步骤，放在步骤201和步骤202之间执行，即接收到本地系统重定向过来的数据包后，就从该数据包中获取数据包源端口；这样，从该数据包中获取数据包源端口的步骤只需执行一次，而后续各组日志进行判断时都可使用该次步骤中所获得的数据包源端口。

由上可知，本实施例中，本地代理一次调用只接收到一组多个日志(而不是所有日志)，且可以通过多次调用来获取所有日志；本地代理会对本次调用获取的这组日志进行判断后再决定是否要继续下次调用，从而，当本次调用获取的这组日志中存在该数据包对应的日志，则可以不用再获取后续的日志。因此，相对于第一实施例而言，第二实施例中的技术方案可以以更快的速度找到该数据包对应的日志，从而能够进一步提高应用包名的查询速度，并能够进一步提高本地代理转发数据包的速度。

本发明的第三实施方式涉及一种应用包名的获取方法。第三实施方式与第二实施方式大致相同，主要区别之处在于：第三实施方式提供了根据身份信息获取数据包对应的应用包名的一种具体方式。

第三实施方式中，身份信息包括应用唯一标识uid和数据包唯一标识inode。

如图3所示为第三实施例的具体流程图，其中，步骤301至步骤305与第一实施例中的步骤201至步骤205分别对应相似，此处不再赘述，不同之处在于：第三实施例中的步骤306，根据身份信息获取数据包对应的应用包名，其包含如下子步骤：

子步骤3061：判断应用唯一标识是否能够用于查询应用包名；若是，则进入子步骤3062；若否，则进入子步骤3063。

子步骤3062：根据应用唯一标识获取数据包对应的应用包名。

子步骤3063：根据数据包唯一标识获取数据包对应的应用包名。

本实施例中，linux内核中对不同类型的应用程序的uid有不同的设定；例如，系统应用程序的uid被设定为零，uid为零时无法根据uid获取应用包名；而对于其他应用程序，其uid被设定为非零数值，并可以根据uid获取数据包对应的应用包名。即，本实施例中将uid是否为零作为判断该uid是否能够用于查询应用包名的判断依据；如果获取的数据包对应的uid为零，则表示无法根据uid获取应用包名；此时需要根据inode获取数据包对应的应用包名。如果获取的数据包对应的uid为非零(例如uid＝10015)，则可以根据uid获取数据包对应的应用包名。其中，子步骤3062、子步骤3063的具体实现方式与现有技术类似，此处不再赘述。

需要说明的是，本实施例中是以uid是否为零作为判断该uid是否能够用于查询应用包名的判断依据；然本申请对此不作任何限制；在其他例子中，可以根据本地系统的自身设定而定，如假设被设定为uid为100时表示无法根据uid获取应用包名，那么，可以将uid是否为100作为判断该uid是否能够用于查询应用包名的判断依据。

第三实施例相对于第二实施例而言，提供了根据身份信息获取数据包对应的应用包名的一种具体方式。在第三实施例的技术方案中，uid是发送该数据包的应用程序的唯一表示，在uid能够用于查询应用包名的情况下，可以较快的查询到应用包名(查询过程较快)；inode是该数据包的唯一表示，必定能够查询到数据包对应的应用包名(查询过程相对于使用uid查询来说较慢)。身份信息同时包括uid和inode，优先使用uid获取应用包名，只有在uid无法查询应用包名时，才使用inode进行查询，因此能够以尽可能快的速度获取到该数据包对应的应用包名。另外，第三实施例也可以在第一实施例基础上进行改进，且改进方式与技术效果与在第二实施例基础上的相同。

本发明的第四实施方式涉及一种应用包名的获取方法。第四实施方式与第三实施方式大致相同，主要区别之处在于：在第三实施例中，同时获取uid和inode，uid和inode均作为身份信息，并在后续根据身份信息获取应用包名时决定具体采用uid或inode；而在第四实施方式中，预先决定采用uid或inode作为身份信息。第四实施方式提供了另外一种使用身份信息获取数据包对应的应用包名的实现方式。

第四实施方式中，身份信息包括应用唯一标识uid或者数据包唯一标识inode。如图4所示为第四实施例的具体流程图，其中，步骤401至步骤404、步骤406与第一实施例中的步骤201至步骤204、步骤206分别对应相似，此处不再赘述，不同之处在于：第四实施例中的步骤405，从数据包对应的日志中获取数据包对应的身份信息，其包含如下子步骤：

子步骤4051：从数据包对应的日志中获取应用唯一标识；

子步骤4052：判断应用唯一标识是否能够用于查询应用包名；若能够，则进入步骤406；若不能够，则进入步骤4053，然后进入步骤406。

子步骤4053：从数据包对应的日志中获取数据包唯一标识。

本实施例中，在获取身份信息时，优先获取uid，如果uid能够用于查询应用包名，则将uid作为身份信息；如果uid无法用于查询应用包名时，才获取inode并将inode作为身份信息。其中，本实施例中判断应用唯一标识是否能够用于查询应用包名的具体方式与第三实施例中类似(即子步骤4052与子步骤3061类似)，此处不再赘述。

本发明的第五实施方式涉及一种数据包的传输方法，应用于本地代理。如图5所示为本实施例的数据包的传输方法的具体流程图，包括如下步骤：

步骤501：根据上述应用包名的获取方法，获取数据包对应的应用包名。其中，上述应用包名的获取方法为第一至第四实施例中的任一实施例所述的应用包名的获取方法；

步骤502：判断数据包对应的应用包名是否存在于预设的允许加速名单中。若是，则进入步骤503；若否，则进入步骤504。

具体而言，终端设备内部预先存储有允许加速名单(可以是从网络端同步到本地的)；本地代理查询该允许加速名单，如果允许加速名单中能够查询到该数据包对应的应用包名，则表示发送该数据包的应用程序允许被加速，即该数据包允许被加速，从而进入步骤503；如果允许加速名单中没有查到该数据包对应的应用包名，表示发送该数据包的应用程序不允许被加速，即该数据包不允许被加速，从而进入步骤504。

步骤503：将数据包发送至加速服务器，以通过加速服务器发送至源站。

步骤504：将数据包发送至源站。

本实施例相对于现有技术而言，当接收到本地系统重定向过来的数据包时，向所述本地系统发送日志获取请求，并且在接收到本地系统反馈的日志时，判断接收的日志中是否存在所述数据包对应的日志。即，当接收到本地系统重定向过来的数据包时，直接访问本地系统，并通过本地系统反馈的日志来获取数据包对应的身份信息，进而获取数据包对应的应用包名。由于对本地系统(即内存)的访问速度相较于现有的对磁盘的访问速度要快很多，因此，可以极大地提高应用包名的查询速度，从而提高本地代理转发数据包的速度；并且，可以极大程度地避免由于本地代理转发时间太久，而造成数据包日志因超过其存放周期而被系统清除中的情况发生。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明第六实施方式涉及一种终端设备，如图6所示，包括本地代理10、本地系统11、至少一个本地应用12；

本地应用12用于生成数据包；

本地系统11用于对本地应用生成的数据包进行拦截，并将数据包重定向至本地代理10；

本地代理10用于执行权利要求第一至第四中任一实施例所述的应用包名的获取方法，获取数据包对应的应用包名。

进一步的，本地代理还用于在获取数据包对应的应用包名后，判断数据包对应的应用包名是否存在于预设的允许加速名单中；本地代理还用于在判断出应用包名存在于允许加速名单中时，将数据包发送至加速服务器20，以通过加速服务器发送至源站30；本地代理还用于在应用包名不存在于允许加速名单中，将数据包发送至源站30。

本实施例相对于现有技术而言，当接收到本地系统重定向过来的数据包时，向所述本地系统发送日志获取请求，并且在接收到本地系统反馈的日志时，判断接收的日志中是否存在所述数据包对应的日志。即，当接收到本地系统重定向过来的数据包时，直接访问本地系统，并通过本地系统反馈的日志来获取数据包对应的身份信息，进而获取数据包对应的应用包名。由于对本地系统(即内存)的访问速度相较于现有的对磁盘的访问速度要快很多，因此，可以极大地提高应用包名的查询速度，从而提高本地代理转发数据包的速度；并且，可以极大程度地避免由于本地代理转发时间太久，而造成数据包日志因超过其存放周期而被系统清除中的情况发生。

本发明第六实施方式涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述第一至第四中任一方法实施例。

本发明第七实施方式涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述第五方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。