WO2018192007A1 - 一种数据包传输方法和系统 - Google Patents

一种数据包传输方法和系统 Download PDF

Info

Publication number
WO2018192007A1
WO2018192007A1 PCT/CN2017/082715 CN2017082715W WO2018192007A1 WO 2018192007 A1 WO2018192007 A1 WO 2018192007A1 CN 2017082715 W CN2017082715 W CN 2017082715W WO 2018192007 A1 WO2018192007 A1 WO 2018192007A1
Authority
WO
WIPO (PCT)
Prior art keywords
data packet
request
agent
packet
request data
Prior art date
Application number
PCT/CN2017/082715
Other languages
English (en)
French (fr)
Inventor
康若鹏
范自道
Original Assignee
网宿科技股份有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 网宿科技股份有限公司 filed Critical 网宿科技股份有限公司
Priority to EP17906278.1A priority Critical patent/EP3499845B1/en
Priority to US16/329,461 priority patent/US10979512B2/en
Publication of WO2018192007A1 publication Critical patent/WO2018192007A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management

Definitions

  • the present invention relates to the field of network technologies, and in particular, to a data packet transmission method and system.
  • the network acceleration service for the application has also emerged.
  • the active proxy is when the application initiates the network request.
  • Proactive agent acceleration, passive proxy, also known as local proxy, is to stop specific request packets to the local acceleration service program by some means at the system level, and the local agent performs corresponding acceleration control and then re-packages the packet. send out.
  • the application packet is redirected to the agent by adding a redirection rule, but in some practical applications, it may be impossible to distinguish the application to be accelerated from the proxy by relying only on the redirection rule.
  • the packet sent by the agent will be redirected to the agent again, causing the packet to circulate in the system.
  • an embodiment of the present invention provides a data packet transmission method and system.
  • the technical solution is as follows:
  • a method of data packet transmission comprising:
  • the agent receives the request data packet through the listening port, sets a label for the request data packet, and sends the labeled request data packet;
  • the local system receives the request packet sent by the agent and the application, matches the label in the request data packet, and if the matching succeeds, directly forwards the request data packet, and if the matching fails, redirects the Request a packet to the agent listening port.
  • the agent is the label while setting a label for the request packet Add a mask.
  • the mask ranges from 0x8000000 to 0xfff00000.
  • the local system version is Android 5.0 and above.
  • the agent determines whether the request data packet needs to be accelerated, and if necessary, modifies the destination port and the destination IP address of the request data packet. To the acceleration server.
  • the method for determining whether the request packet needs to be accelerated includes: first whitelist verification, if the verification is successful, the request data packet needs to be accelerated; if the verification fails, determining whether the request data packet is The data packet of the HTTP request, if it is HTTP, judges whether it needs to be accelerated according to the URL and the preset rule.
  • agent and the application run on the local system.
  • the local system kernel is a Linux kernel.
  • a data packet transmission system the system includes a terminal device, an acceleration server, and a source station, where an application program and an agent program are run on a local system of the terminal device; wherein the agent program receives through a listening port Requesting a data packet, after setting a label for the request data packet, sending the labeled request data packet; the local system receiving the requesting data packet sent by the agent program and the application program, matching the request data packet If the matching is successful, the label is directly forwarded to the acceleration server or the source station, and if the matching fails, the request data packet is redirected to the agent listening port.
  • the agent adds a mask to the label while setting a label for the request packet.
  • the mask ranges from 0x8000000 to 0xfff00000.
  • the local system version is Android 5.0 and above.
  • the agent includes an acceleration processing unit, and before the agent sends the tagged request packet, the acceleration processing unit of the agent determines whether the request packet needs to be accelerated, if If necessary, modify the destination port and the destination IP address of the request packet to the acceleration server.
  • the method for the acceleration processing unit of the agent to determine whether the request packet needs to be accelerated includes: first whitelist verification, if the verification is successful, the request data packet needs to be accelerated; if the verification fails, then Determining whether the request packet is a data packet of an HTTP request, and if it is HTTP, determining whether acceleration is required according to a URL and a preset rule.
  • the local system kernel is a Linux kernel.
  • the technical solution provided by the embodiment of the present invention provides the data packet transmission method of the embodiment of the present invention.
  • the agent receives the request data packet through the listening port, sets a label for the request data packet, and sends the labeled label.
  • a request packet the local system receives the request packet sent by the agent and the application, matches a label in the request packet, and if the matching is successful, directly forwards the request packet, and if the matching fails, And redirecting the request packet to the agent listening port; labeling the data packet sent by the agent, so that the local system can distinguish the request packet from the application and the proxy according to the label, and perform corresponding operations. Avoid infinite loops of packets locally.
  • FIG. 1 is a flowchart of a data packet transmission method according to Embodiment 1 of the present invention.
  • FIG. 2 is a flowchart of a data packet transmission method according to Embodiment 2 of the present invention.
  • FIG. 3 is a structural diagram of a data packet transmission system according to Embodiment 3 of the present invention.
  • a first embodiment of the present invention provides a data packet transmission method, where the data packet transmission method involves an agent, an application, and a local system, where the application is a program that provides a specific service for the user, for example, Browsers, music video services, and other functional service programs, the user obtains corresponding services by operating the applications; the agent processes the request packets sent by the application, so that the application enjoying the network acceleration service The request packet sent by the program can be forwarded to the acceleration server; the application and the agent are all running on the local system.
  • the kernel of the local system is a Linux kernel, which can be an Android system. This embodiment is Take the Android system as an example.
  • the data packet transmission method in this embodiment includes steps A101 to A103 and steps S101 to S102, which are described in detail below.
  • Step A101 The agent receives the request packet through the listening port.
  • the agent needs to process the request packet sent by the application. Therefore, when the agent is initialized, a special listening port is set to receive the request packet of the application. For example, the agent's listening port is set to 8123.
  • Step A103 The agent sends the tagged request packet.
  • the tagged request packet sent by the agent will be received by the local system.
  • Step S101 The local system receives the agent program and the request data packet sent by the application.
  • the local system is an Android system
  • the kernel of the Android system is Linux.
  • Kernel as we all know, Netfilter is a software framework in the Linux kernel for managing network packets.
  • Iptables is an extensible user-layer packet management tool based on Netfilter's basic architecture. Most Linux systems have their own iptables module, which filters, intercepts, redirects, etc. network packets.
  • a function such as a firewall, in the embodiment of the present invention, also receives request packets sent by the agent and the application through iptables.
  • Step S102 Match the label in the request data packet, if the matching is successful, directly forward the request data packet, and if the matching fails, redirect the request data packet to the agent listening port.
  • the local system matches the tags in the data packet by setting the iptables mark tag matching rule and the redirection rule. If the matching is successful, the request packet is directly forwarded according to the setting rule, and if the matching fails, the request is redirected. Packet to the agent listening port. For example, to set the iptables mark tag matching rule, the redirection rules are as follows:
  • the request packet sent by the agent includes the Mark tag
  • the local system can distinguish the application and the agent by Mark tag matching, and separately process, thereby avoiding the infinite loop described in the background art.
  • steps A103 and S101 are sequential in the illustration of the embodiment, in practical applications, steps A101-A103 are internal execution steps of the agent, and steps S101-S102 are local systems. The steps of the internal execution and the relationship between the steps are not all so clear. Therefore, the illustrations are only used to illustrate the present embodiment, and the present invention is not limited thereto.
  • the data packet transmission method in this embodiment further includes the step of: the agent determines whether the request packet needs to be accelerated, and if necessary, modifies the destination port and the destination IP address of the request packet to the acceleration server.
  • the agent determines whether the request packet needs to be accelerated, and if necessary, modifies the destination port and the destination IP address of the request packet to the acceleration server.
  • the agent should judge the application that needs to be accelerated, and the specific judgment method includes: If the verification succeeds, it is determined that the request data packet needs to be accelerated, wherein the white list stores the application package name information that needs to be accelerated; if the verification fails, it is determined whether the request data packet is an HTTP request. The data packet, if it is HTTP, judges whether acceleration is needed according to the URL and the preset rule.
  • a second embodiment of the present invention provides a data packet transmission method, where the data packet transmission method involves an agent program, an application program, and a local system, where the application program is a program for providing a specific service service to a user, for example, Browsers, music video services, and other functional service programs, the user obtains corresponding services by operating the applications; the agent processes the request packets sent by the application, so that the application enjoying the network acceleration service The request packet sent by the program can be forwarded to the acceleration server; the application and the agent are all running on the local system.
  • the kernel of the local system is a Linux kernel, which can be an Android system. This embodiment is Take the Android system as an example.
  • the data packet transmission method in this embodiment includes steps A201 to A203 and steps S201 to S202, which are described in detail below.
  • Step A201 The agent receives the request packet through the listening port.
  • the agent needs to process the request packet sent by the application. Therefore, when the agent is initialized, a special listening port is set to receive the request packet of the application. For example, the agent's listening port is set to 8123.
  • Step A203 The agent sends the request packet with the mask tag.
  • the band sent by the agent The request packet for the tag will be received by the local system.
  • Step S201 The local system receives the agent program and the request data packet sent by the application.
  • the local system is an Android system
  • the kernel of the Android system is a Linux kernel.
  • Netfilter is a software framework in the Linux kernel for managing network data packets.
  • Iptables is an extensible user-layer packet management tool based on Netfilter's basic architecture.
  • Most Linux systems have their own iptables module, which filters, intercepts, redirects, etc. network packets.
  • a function such as a firewall, in the embodiment of the present invention, also receives request packets sent by the agent and the application through iptables.
  • Step S202 Matching the mask label in the request data packet, if the matching is successful, directly forwarding the request data packet, and if the matching fails, redirecting the request data packet to the agent listening port.
  • the local system matches the mask label in the data packet by setting the iptables mask label matching rule and the redirection rule. If the matching is successful, the request packet is directly forwarded according to the setting rule. If the matching fails, the local system is heavy. Direct the request packet to the agent listening port. For example, set the iptables mask tag matching rule and the redirection rule as follows:
  • the request packet sent by the agent includes the Mark tag
  • the local system can distinguish the application and the agent by Mark tag matching, and separately process, thereby avoiding the infinite loop described in the background art.
  • the tags in the request packet are masked, it can avoid the problem that the request packet cannot be correctly matched after the tag is modified during the transmission process, specifically, in the system of Android 5.0 and above.
  • Netd in the system will tamper with the label in the data packet. If there is no mask added in the label, the matching cannot be performed correctly.
  • Netd's tampering with a 32-bit label will only affect its low 20bits. Therefore, in this embodiment, the label is masked, and the matching rule is modified at the same time, and the parts that have not been tampered with are matched, thereby avoiding that the label cannot be corrected after being tampered with.
  • the mask value ranges from 0x8000000 to 0xfff00000. It can be understood that, in some other versions of the system, if the corresponding rules are met, the processing may be performed according to the processing ideas of the embodiment, and the present invention is not limited thereto.
  • steps A203 and S201 are sequential relationships in the illustration of the embodiment, in practical applications, steps A201-A203 are internal execution steps of the agent, and steps S201-S202 are local systems. The steps of the internal execution and the relationship between the steps are not all so clear. Therefore, the illustrations are only used to illustrate the present embodiment, and the present invention is not limited thereto.
  • the data packet transmission method in this embodiment further includes the step of: the agent determines whether the request packet needs to be accelerated, and if necessary, modifies the destination port and the destination IP address of the request packet to the acceleration server.
  • the agent determines whether the request packet needs to be accelerated, and if necessary, modifies the destination port and the destination IP address of the request packet to the acceleration server.
  • the agent should judge the application that needs to be accelerated, and the specific judgment method includes: If the verification succeeds, it is determined that the request data packet needs to be accelerated, wherein the white list stores the application package name information that needs to be accelerated; if the verification fails, it is determined whether the request data packet is an HTTP request. The data packet, if it is HTTP, judges whether acceleration is needed according to the URL and the preset rule.
  • a third embodiment of the present invention provides a data packet transmission system, where the data packet transmission system includes a terminal device, an acceleration server, and a source station, where an application program and an agent run on a local system of the terminal device. program.
  • an application is a program that provides a specific business service to a user, such as a browser, a music video service, and other functional service programs, and a user obtains a corresponding service by operating the applications.
  • the application receives the user action and issues a corresponding request packet, the request data
  • the package will go through the agent and the local system and will eventually be sent to the acceleration server or source station for return to the source in response to the user request.
  • the agent processes the request packet sent by the application so that the request packet sent by the application enjoying the network acceleration service can be forwarded to the acceleration server.
  • the agent receives the request packet through the listening port, and after sending the label for the request packet, sends the tagged request packet.
  • a special listening port is set to receive the request packet of the application.
  • the listening port of the agent is set to 8123.
  • create a proxy socket and set the label to the socket using Linux's setsockopt() function, for example, mark 0x12345678.
  • the agent Before sending the tagged request packet, the agent needs to determine whether the request packet needs to be accelerated, and if necessary, modify the destination port and the destination IP address of the request packet to the acceleration server. In this way, when the local system receives the request packet that needs to be accelerated, according to the redirection rule, the request packet is forwarded to the acceleration server according to the destination port and the destination IP address of the request packet, and the acceleration server provides the same. The corresponding network acceleration service. Request packets that do not require acceleration will be forwarded by the local system to the source station based on the original port and IP address.
  • the agent should judge the application that needs to be accelerated, and the specific judgment method includes: If the verification succeeds, it is determined that the request data packet needs to be accelerated, wherein the white list stores the application package name information that needs to be accelerated; if the verification fails, it is determined whether the request data packet is an HTTP request. The data packet, if it is HTTP, judges whether acceleration is needed according to the URL and the preset rule.
  • the local system is an Android system
  • the kernel of the Android system is a Linux kernel.
  • Netfilter is a software framework in the Linux kernel for managing network data packets.
  • Iptables is an extensible user-layer packet management tool based on Netfilter's basic architecture.
  • Most Linux systems have their own iptables module, which filters, intercepts, redirects, etc. network packets.
  • a function such as a firewall, in the embodiment of the present invention, also receives request packets sent by the agent and the application through iptables.
  • the local system matches the tags in the data packet by setting the iptables tag matching rule and the redirection rule. If the matching is successful, the request packet is directly forwarded according to the setting rule, and if the matching fails, the request data is redirected. Packets to the agent listening port, it can be understood that in the embodiment of the present invention, the label set by the local system when setting the iptables tag matching rule is the same as the tag set by the agent for the request packet. Take the mask with the mask as an example. Set the iptables label matching rule and the redirection rules as follows:
  • the purpose of the rule is to redirect the packet to the listener port 8123 of the agent.
  • the request packet sent by the agent includes the Mark tag
  • the local system can distinguish the application and the agent by Mark tag matching, and separately process, thereby avoiding the infinite loop described in the background art.
  • the tags in the request packet are masked, it can avoid the problem that the request packet cannot be correctly matched after the tag is modified during the transmission process, specifically, in the system of Android 5.0 and above.
  • Netd in the system will tamper with the label in the data packet. If there is no mask added in the label, the matching cannot be performed correctly.
  • Netd's tampering with a 32-bit label will only affect its low 20bits. Therefore, in this embodiment, the label is masked, and the matching rule is modified at the same time, and the parts that have not been tampered with are matched, thereby avoiding the problem that the label cannot be correctly matched after being tampered with, correspondingly, in Android 5.0 and above.
  • the mask ranges from 0x8000000 to 0xfff00000. It can be understood that, in some other versions of the system, if the corresponding rules are met, the processing may be performed according to the processing ideas of the embodiment, and the present invention is not limited thereto.
  • the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, ie may be located A place, or it can be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment. Those of ordinary skill in the art can understand and implement without deliberate labor.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Library & Information Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种数据包传输方法，所述方法包括：代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送所述带标签的请求数据包；本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口；对代理程序发送出去的数据包进行标签设置，以使得本地系统可根据标签区分来自应用和代理的请求数据包，并进行相应操作，避免数据包在本地的死循环。本发明还公开了一种数据包传输系统。

Description

一种数据包传输方法和系统 技术领域
本发明涉及网络技术领域，尤其涉及一种数据包传输方法和系统。
背景技术
随着互联网技术的不断发展，各种应用程序如雨后春笋般密集涌现。为了提供更好的用户体验，针对应用程序的网络加速服务也应运而生，以Android应用代理加速为例，可以分为主动代理和被动代理两种方式，主动代理是应用程序在发起网络请求时主动进行代理加速，被动代理，又称本地代理，是在系统层面通过某些手段将特定的请求数据包拦截至本地的加速服务程序，由本地代理程序做相应的加速控制后再将数据包重新发出去。
现有的被动代理中，主要是通过添加重定向规则，将应用数据包重定向到代理程序来实现，但在某些实际应用中，发现仅仅依靠重定向规则可能无法区分待加速应用与经代理程序处理后发出的数据包，代理程序发出的数据包将会再次被重定向至代理程序，造成数据包在系统内死循环。
发明内容
为了解决现有技术的问题，本发明实施例提供了一种数据包传输方法和系统。所述技术方案如下：
一方面，一种数据包传输方法，所述方法包括：
代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送所述带标签的请求数据包；
本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。
进一步的，所述代理程序在为所述请求数据包设置标签的同时，为所述标签 添加掩码。
进一步的，所述掩码的取值范围为0x8000000～0xfff00000。
进一步的，所述本地系统版本为Android 5.0及其以上版本。
进一步的，在所述代理程序发送所述带标签的请求数据包之前，所述代理程序判断所述请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。
进一步的，判断所述请求数据包是否需要进行加速的方法包含：先白名单校验，若校验成功则所述请求数据包需要加速；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。
进一步的，所述代理程序和所述应用程序运行在所述本地系统上。
进一步的，所述本地系统内核为Linux内核。
另一方面，一种数据包传输系统，所述系统包括终端设备、加速服务器和源站，所述终端设备的本地系统上运行有应用程序、代理程序；其中，所述代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送所述带标签的请求数据包；本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包至所述加速服务器或所述源站，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。
进一步的，所述代理程序在为所述请求数据包设置标签的同时，为所述标签添加掩码。
进一步的，所述掩码的取值范围为0x8000000～0xfff00000。
进一步的，所述本地系统版本为Android 5.0及其以上版本。
进一步的，在所述代理程序包含加速处理单元，在所述代理程序发送所述带标签的请求数据包之前，所述代理程序的加速处理单元，判断所述请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。
进一步的，所述代理程序的加速处理单元判断所述请求数据包是否需要进行加速的方法包含：先白名单校验，若校验成功则所述请求数据包需要加速；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。
进一步的，所述本地系统内核为Linux内核。
本发明实施例提供的技术方案带来的有益效果是：本发明实施例的数据包传输方法，代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送所述带标签的请求数据包；本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口；对代理程序发送出去的数据包进行标签设置，以使得本地系统可根据标签区分来自应用和代理的请求数据包，并进行相应操作，避免数据包在本地的死循环。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下， 还可以根据这些附图获得其他的附图。
图1是本发明实施例一提供的一种数据包传输方法的流程图；
图2是本发明实施例二提供的一种数据包传输方法的流程图；
图3是本发明实施例三提供的一种数据包传输系统结构图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。
第一实施例
参见图1所示，本发明第一实施例提供一种数据包传输方法，该数据包传输方法中涉及代理程序、应用程序及本地系统，其中应用程序是为用户提供具体业务服务的程序，例如浏览器、音乐视频服务、及其他功能性服务程序，用户通过对该些应用程序的操作来获取相应的服务；代理程序对应用程序发出的请求数据包进行处理，以使得享受网络加速服务的应用程序所发出的请求数据包能被转发到加速服务器；应用程序及代理程序均运行在本地系统上，本发明的实施例中，本地系统的内核为Linux内核，可以是Android系统，本实施例就是以Android系统为例。
本实施例中的数据包传输方法包括步骤A101～A103和步骤S101～S102，详述如下。
步骤A101：代理程序通过监听端口接收请求数据包。如上所述，代理程序需要对应用程序发出的请求数据包进行处理，故在代理程序初始化时，设置专门的监听端口，用于接收应用程序的请求数据包，例如，代理程序的监听端口设置为8123。
步骤A102：代理程序为所述请求数据包设置标签。具体的，代理程序接收到请求数据包后通过创建代理socket，并使用Linux的setsockopt()函数对socket设置标签，例如mark＝0x12345678。
步骤A103：代理程序发送带标签的请求数据包。代理程序发送出的带标签的请求数据包将被本地系统接收。
步骤S101：本地系统接收所述代理程序和所述应用程序发出的请求数据包。本发明的实施例中，本地系统为Android系统，而Android系统的内核为Linux 内核，众所周知，Netfilter是Linux内核中的一个软件框架，用于管理网络数据包。iptables是基于Netfilter基本架构实现的一个可扩展的的用户层数据包管理工具，大部分Linux系统都自带iptables模块，并通过它对网络数据包进行过滤、拦截、重定向等操作，从而实现系统防火墙等功能，本发明的实施例中，也是通过iptables对代理程序和应用程序发出的请求数据包进行接收。
步骤S102：匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。同样的，本地系统通过设置iptables mark标签匹配规则和重定向规则，对数据包中的标签进行匹配，若匹配成功，根据设置规则则直接转发该请求数据包，若匹配失败，则重定向该请求数据包至代理程序监听端口。例如，设置iptables mark标签匹配规则、重定向规则如下：
iptables-t nat-A OUTPUT-m mark--mark 0x12345678-j RETURN
iptables-t nat-A OUTPUT-p tcp-j REDIRECT--to-port 8123
第一条规则的作用是当数据包具有mark＝0x12345678的标签时，数据包不被重定向，以系统默认方式处理，否则执行第二条规则；第二条规则的作用是将数据包重定向至代理程序的监听端口8123端口。
如此一来，代理程序所发出的请求数据包均包含Mark标签，本地系统可通过Mark标签匹配来区分应用程序和代理程序，并进行分别处理，从而避免了背景技术中描述的死循环现象。
可以理解的是，虽然本实施例的图示中，步骤A103和S101之间是先后关系，但在实际应用中，步骤A101～A103为代理程序内部的执行步骤，而步骤S101～S102为本地系统内部执行的步骤，各步骤之间先后关系并非全部如此明确，故图示仅用于对本实施例进行示意说明，本发明并不以此为限。
更进一步的，本实施例中的数据包传输方法更包含步骤：代理程序判断请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。如此一来，当本地系统接收到需要加速的请求数据包时，根据重定向规则，将会按照该请求数据包的目的端口和目的IP地址转发该请求数据包至加速服务器，加速服务器为其提供相应的网络加速服务。该步骤设置在步骤A103之前。
具体而言，由于本地系统上可能安装了多种应用程序，然而有些应用程序并没有购买相应的加速服务，故代理程序应对需要加速的应用程序进行判断，具体的判断方法包含：先白名单校验，若校验成功则判断所述请求数据包需要加速，其中所述白名单中保存了需要加速的应用程序包名信息；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。
如此一来，可实现对应用程序的分类处理，只对需要加速的应用程序进行处理。
第二实施例
参见图2所示，本发明第二实施例提供一种数据包传输方法，该数据包传输方法中涉及代理程序、应用程序及本地系统，其中应用程序是为用户提供具体业务服务的程序，例如浏览器、音乐视频服务、及其他功能性服务程序，用户通过对该些应用程序的操作来获取相应的服务；代理程序对应用程序发出的请求数据包进行处理，以使得享受网络加速服务的应用程序所发出的请求数据包能被转发到加速服务器；应用程序及代理程序均运行在本地系统上，本发明的实施例中，本地系统的内核为Linux内核，可以是Android系统，本实施例就是以Android系统为例。
本实施例中的数据包传输方法包括步骤A201～A203和步骤S201～S202，详述如下。
步骤A201：代理程序通过监听端口接收请求数据包。如上所述，代理程序需要对应用程序发出的请求数据包进行处理，故在代理程序初始化时，设置专门的监听端口，用于接收应用程序的请求数据包，例如，代理程序的监听端口设置为8123。
步骤A202：代理程序为所述请求数据包设置标签，并为所述标签添加掩码。具体的，代理程序接收到请求数据包后通过创建代理socket，并使用Linux的setsockopt()函数对socket设置标签，并为该标签添加掩码，例如mark＝0x12345678/0xfff00000。
步骤A203：代理程序发送带掩码标签的请求数据包。代理程序发送出的带 标签的请求数据包将被本地系统接收。
步骤S201：本地系统接收所述代理程序和所述应用程序发出的请求数据包。本发明的实施例中，本地系统为Android系统，而Android系统的内核为Linux内核，众所周知，Netfilter是Linux内核中的一个软件框架，用于管理网络数据包。iptables是基于Netfilter基本架构实现的一个可扩展的的用户层数据包管理工具，大部分Linux系统都自带iptables模块，并通过它对网络数据包进行过滤、拦截、重定向等操作，从而实现系统防火墙等功能，本发明的实施例中，也是通过iptables对代理程序和应用程序发出的请求数据包进行接收。
步骤S202：匹配所述请求数据包中的掩码标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。同样的，本地系统通过设置iptables掩码标签匹配规则和重定向规则，对数据包中的掩码标签进行匹配，若匹配成功，根据设置规则则直接转发该请求数据包，若匹配失败，则重定向该请求数据包至代理程序监听端口。例如，设置iptables掩码标签匹配规则、重定向规则如下：
iptables -t nat -A OUTPUT -m mark --mark 0x12345678/0xfff00000 -j RETURN
iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-port 8123
第一条规则的作用是当数据包具有mark＝0x12345678/0xfff00000的掩码标签时，数据包不被重定向，以系统默认方式处理，否则执行第二条规则；第二条规则的作用是将数据包重定向至代理程序的监听端口8123端口。
如此一来，代理程序所发出的请求数据包均包含Mark标签，本地系统可通过Mark标签匹配来区分应用程序和代理程序，并进行分别处理，从而避免了背景技术中描述的死循环现象。
不仅如此，由于请求数据包中的标签均带有掩码，可避免请求数据包在传输过程中，标签被修改后无法正确匹配的问题，具体而言，在Android 5.0及其以上版本的系统中，系统中的Netd会对数据包中的标签进行篡改，若标签中没有增加掩码，则无法正确进行匹配，经仔细研究发现，Netd对于一个32bits的标签的篡改，仅会影响其低20bits，故本实施例中，为标签打上掩码，并同时修改匹配规则，对未被篡改的部分进行匹配，从而避免了标签被篡改后无法正确 匹配的问题，相应的，在Android 5.0及其以上版本的系统中，掩码的取值范围为0x8000000～0xfff00000。可以理解的是，在一些其他版本的系统下，若符合相应规则，也可以根据本实施例的处理思路进行处理，本发明并不以此为限。
可以理解的是，虽然本实施例的图示中，步骤A203和S201之间是先后关系，但在实际应用中，步骤A201～A203为代理程序内部的执行步骤，而步骤S201～S202为本地系统内部执行的步骤，各步骤之间先后关系并非全部如此明确，故图示仅用于对本实施例进行示意说明，本发明并不以此为限。
更进一步的，本实施例中的数据包传输方法更包含步骤：代理程序判断请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。如此一来，当本地系统接收到需要加速的请求数据包时，根据重定向规则，将会按照该请求数据包的目的端口和目的IP地址转发该请求数据包至加速服务器，加速服务器为其提供相应的网络加速服务。该步骤设置在步骤A203之前。
具体而言，由于本地系统上可能安装了多种应用程序，然而有些应用程序并没有购买相应的加速服务，故代理程序应对需要加速的应用程序进行判断，具体的判断方法包含：先白名单校验，若校验成功则判断所述请求数据包需要加速，其中所述白名单中保存了需要加速的应用程序包名信息；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。
如此一来，可实现对应用程序的分类处理，只对需要加速的应用程序进行处理。
第三实施例
参见图3所示，本发明第三实施例提供一种数据包传输系统，所述数据包传输系统包括终端设备、加速服务器和源站，所述终端设备的本地系统上运行有应用程序、代理程序。
具体而言，应用程序是为用户提供具体业务服务的程序，例如浏览器、音乐视频服务、及其他功能性服务程序，用户通过对该些应用程序的操作来获取相应的服务。应用程序接收用户操作，并发出相应的请求数据包，该请求数据 包将经过代理程序和本地系统，最终发送至加速服务器或者源站进行回源，以响应用户请求。
代理程序对应用程序发出的请求数据包进行处理，以使得享受网络加速服务的应用程序所发出的请求数据包能被转发到加速服务器。代理程序通过监听端口接收请求数据包，为请求数据包设置标签后，发送所述带标签的请求数据包。
详细而言，代理程序初始化时，设置专门的监听端口，用于接收应用程序的请求数据包，例如，代理程序的监听端口设置为8123。在接收到请求数据包后，通过创建代理socket，并使用Linux的setsockopt()函数对socket设置标签，例如mark＝0x12345678。代理程序发送出的带标签的请求数据包将被本地系统接收。
值得注意的是，在本发明的一些其他较佳实施例中，代理程序为请求数据包添加的标签为带有掩码的标签，例如mark＝0x12345678/0xfff00000，不仅可以实现标签同样的功能，还能防止在一些版本的系统中，标签被篡改的而无法正确匹配的问题。
例如在Android 5.0及其以上版本的系统中，系统中的Netd会对数据包中的标签进行篡改，若标签中没有增加掩码，则无法正确进行匹配，经仔细研究发现，Netd对于一个32bits的标签的篡改，仅会影响其低20bits，故本实施例中，为标签打上掩码，并同时修改匹配规则，对未被篡改的部分进行匹配，从而避免了标签被篡改后无法正确匹配的问题，相应的，在Android 5.0及其以上版本的系统中，掩码的取值范围为0x8000000～0xfff00000。可以理解的是，在一些其他版本的系统下，若符合相应规则，也可以根据本实施例的处理思路进行处理，本发明并不以此为限。
代理程序在发送带标签的请求数据包之前，还需判断请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。如此一来，当本地系统接收到需要加速的请求数据包时，根据重定向规则，将会按照该请求数据包的目的端口和目的IP地址转发该请求数据包至加速服务器，加速服务器为其提供相应的网络加速服务。而不需要加速的请求数据包将根据原始端口及IP地址被本地系统转发至源站。
具体而言，由于本地系统上可能安装了多种应用程序，然而有些应用程序并没有购买相应的加速服务，故代理程序应对需要加速的应用程序进行判断，具体的判断方法包含：先白名单校验，若校验成功则判断所述请求数据包需要加速，其中所述白名单中保存了需要加速的应用程序包名信息；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。
如此一来，可实现对应用程序的分类处理，只对需要加速的应用程序进行处理。
本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包至所述加速服务器或所述源站，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。
本发明的实施例中，本地系统为Android系统，而Android系统的内核为Linux内核，众所周知，Netfilter是Linux内核中的一个软件框架，用于管理网络数据包。iptables是基于Netfilter基本架构实现的一个可扩展的的用户层数据包管理工具，大部分Linux系统都自带iptables模块，并通过它对网络数据包进行过滤、拦截、重定向等操作，从而实现系统防火墙等功能，本发明的实施例中，也是通过iptables对代理程序和应用程序发出的请求数据包进行接收。
同样的，本地系统通过设置iptables标签匹配规则和重定向规则，对数据包中的标签进行匹配，若匹配成功，根据设置规则则直接转发该请求数据包，若匹配失败，则重定向该请求数据包至代理程序监听端口，可以理解的是，在本发明的实施例中，本地系统在设置iptables标签匹配规则时所设置的标签与代理程序为请求数据包设置的标签相同。以带有掩码的标签为例，设置iptables标签匹配规则、重定向规则如下：
iptables -t nat -A OUTPUT -m mark --mark 0x12345678/0xfff00000 -j RETURN
iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-port 8123
第一条规则的作用是当数据包具有mark＝0x12345678/0xfff00000的掩码标签时，数据包不被重定向，以系统默认方式处理，否则执行第二条规则；第二 条规则的作用是将数据包重定向至代理程序的监听端口8123端口。
如此一来，代理程序所发出的请求数据包均包含Mark标签，本地系统可通过Mark标签匹配来区分应用程序和代理程序，并进行分别处理，从而避免了背景技术中描述的死循环现象。
不仅如此，由于请求数据包中的标签均带有掩码，可避免请求数据包在传输过程中，标签被修改后无法正确匹配的问题，具体而言，在Android 5.0及其以上版本的系统中，系统中的Netd会对数据包中的标签进行篡改，若标签中没有增加掩码，则无法正确进行匹配，经仔细研究发现，Netd对于一个32bits的标签的篡改，仅会影响其低20bits，故本实施例中，为标签打上掩码，并同时修改匹配规则，对未被篡改的部分进行匹配，从而避免了标签被篡改后无法正确匹配的问题，相应的，在Android 5.0及其以上版本的系统中，掩码的取值范围为0x8000000～0xfff00000。可以理解的是，在一些其他版本的系统下，若符合相应规则，也可以根据本实施例的处理思路进行处理，本发明并不以此为限。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (15)

  1. 一种数据包传输方法，其特征在于，所述方法包括：
    代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送所述带标签的请求数据包；
    本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。
  2. 根据权利要求1所述的数据包传输方法，其特征在于，所述代理程序在为所述请求数据包设置标签的同时，为所述标签添加掩码。
  3. 根据权利要求2所述的数据包传输方法，其特征在于，所述掩码的取值范围为0x8000000～0xfff00000。
  4. 根据权利要求2所述的数据包传输方法，其特征在于，所述本地系统版本为Android 5.0及其以上版本。
  5. 根据权利要求1所述的数据包传输方法，其特征在于，在所述代理程序发送所述带标签的请求数据包之前，所述代理程序判断所述请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。
  6. 根据权利要求5所述的数据包传输方法，其特征在于，判断所述请求数据包是否需要进行加速的方法包含：先白名单校验，若校验成功则判断所述请求数据包需要加速；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。
  7. 根据权利要求1所述的数据包传输方法，其特征在于，所述代理程序和所述应用程序运行在所述本地系统上。
  8. 根据权利要求1所述的数据包传输方法，其特征在于，所述本地系统内核为Linux内核。
  9. 一种数据包传输系统，其特征在于，所述系统包括终端设备、加速服务器和源站，所述终端设备的本地系统上运行有应用程序、代理程序；其中，所述代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送所述带标签的请求数据包；本地系统接收所述代理程序和所述应用程序发出 的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包至所述加速服务器或所述源站，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。
  10. 根据权利要求9所述的数据包传输系统，其特征在于，所述代理程序在为所述请求数据包设置标签的同时，为所述标签添加掩码。
  11. 根据权利要求10所述的数据包传输系统，其特征在于，所述掩码的取值范围为0x8000000～0xfff00000。
  12. 根据权利要求10所述的数据包传输系统，其特征在于，所述本地系统版本为Android 5.0及其以上版本。
  13. 根据权利要求9所述的数据包传输系统，其特征在于，在所述代理程序包含加速处理单元，在所述代理程序发送所述带标签的请求数据包之前，所述代理程序的加速处理单元，判断所述请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。
  14. 根据权利要求13所述的数据包传输系统，其特征在于，所述代理程序的加速处理单元判断所述请求数据包是否需要进行加速的方法包含：先白名单校验，若校验成功则所述请求数据包需要加速；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。
  15. 根据权利要求9所述的数据包传输系统，其特征在于，所述本地系统内核为Linux内核。
PCT/CN2017/082715 2017-04-20 2017-05-02 一种数据包传输方法和系统 WO2018192007A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP17906278.1A EP3499845B1 (en) 2017-04-20 2017-05-02 Data packet transmission method and system
US16/329,461 US10979512B2 (en) 2017-04-20 2017-05-02 Method and system of data packet transmission

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710261406.9 2017-04-20
CN201710261406.9A CN107071034B (zh) 2017-04-20 2017-04-20 一种数据包传输方法和系统

Publications (1)

Publication Number Publication Date
WO2018192007A1 true WO2018192007A1 (zh) 2018-10-25

Family

ID=59600454

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/082715 WO2018192007A1 (zh) 2017-04-20 2017-05-02 一种数据包传输方法和系统

Country Status (4)

Country Link
US (1) US10979512B2 (zh)
EP (1) EP3499845B1 (zh)
CN (1) CN107071034B (zh)
WO (1) WO2018192007A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107623634A (zh) * 2017-10-12 2018-01-23 网宿科技股份有限公司 业务流量路由方法及其系统和移动电子设备
CN109450991A (zh) * 2018-10-19 2019-03-08 网宿科技股份有限公司 基于移动应用的数据传输加速方法、相关设备和加速系统
CN109756474B (zh) * 2018-11-23 2021-02-05 国电南瑞科技股份有限公司 一种电力调度自动化系统的服务跨区域调用方法及装置
US11228657B2 (en) * 2019-12-03 2022-01-18 Red Hat, Inc. Hybrid proxying with user space hold
CN111510478B (zh) * 2020-04-07 2022-06-24 支付宝(杭州)信息技术有限公司 请求处理方法、装置、系统及电子设备
CN112583661B (zh) * 2020-12-02 2022-09-02 广州朗国电子科技股份有限公司 对不同网络共享方法、装置、存储介质及一体机设备
CN113507393B (zh) * 2021-09-08 2021-12-07 腾讯科技（深圳）有限公司 数据加速传输方法、装置、计算机设备和存储介质
CN114285794B (zh) * 2021-12-22 2023-08-18 网宿科技股份有限公司 报文转发控制方法、报文传输网络、电子设备及存储介质
CN114710548B (zh) * 2022-03-22 2024-04-05 阿里巴巴（中国）有限公司 报文转发方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6098172A (en) * 1997-09-12 2000-08-01 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with proxy reflection
CN102438016A (zh) * 2011-12-13 2012-05-02 北京星网锐捷网络技术有限公司 获知报文所属进程的方法、访问控制方法、装置及设备
CN102594877A (zh) * 2012-01-19 2012-07-18 网宿科技股份有限公司 结合重定向下载请求和代理服务加速网络服务的方法、系统
CN106130997A (zh) * 2016-06-30 2016-11-16 网宿科技股份有限公司 流量引导的方法和装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6728885B1 (en) * 1998-10-09 2004-04-27 Networks Associates Technology, Inc. System and method for network access control using adaptive proxies
US8943304B2 (en) * 2006-08-03 2015-01-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US8305896B2 (en) * 2007-10-31 2012-11-06 Cisco Technology, Inc. Selective performance enhancement of traffic flows
CA2791523C (en) 2010-09-24 2013-09-10 Pravala Inc. Accessing local network resources in a multi-interface system
CN103974339B (zh) * 2013-01-28 2018-01-16 华为技术有限公司 一种数据缓存的方法和装置
US9241044B2 (en) * 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
US9513926B2 (en) * 2014-01-08 2016-12-06 Cavium, Inc. Floating mask generation for network packet flow
US10021208B2 (en) * 2014-03-04 2018-07-10 Mobophiles, Inc. Dynamic cache allocation and network management
CN105245464A (zh) * 2015-08-27 2016-01-13 北京华夏创新科技有限公司 一种基于安卓系统的网络加速方法
CN105791315B (zh) * 2016-04-25 2019-05-14 网宿科技股份有限公司 一种udp协议加速方法和系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6098172A (en) * 1997-09-12 2000-08-01 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with proxy reflection
CN102438016A (zh) * 2011-12-13 2012-05-02 北京星网锐捷网络技术有限公司 获知报文所属进程的方法、访问控制方法、装置及设备
CN102594877A (zh) * 2012-01-19 2012-07-18 网宿科技股份有限公司 结合重定向下载请求和代理服务加速网络服务的方法、系统
CN106130997A (zh) * 2016-06-30 2016-11-16 网宿科技股份有限公司 流量引导的方法和装置

Also Published As

Publication number Publication date
EP3499845A1 (en) 2019-06-19
CN107071034B (zh) 2019-10-11
EP3499845B1 (en) 2020-11-25
EP3499845A4 (en) 2019-11-06
US20190260837A1 (en) 2019-08-22
CN107071034A (zh) 2017-08-18
US10979512B2 (en) 2021-04-13

Similar Documents

Publication Publication Date Title
WO2018192007A1 (zh) 一种数据包传输方法和系统
US20220030095A1 (en) Methods and apparatus for sharing and arbitration of host stack information with user space communication stacks
CN106936793B (zh) 一种信息拦截处理方法及终端
US11381629B2 (en) Passive detection of forged web browsers
US8209378B2 (en) Methods and apparatus for widget sharing between content aggregation points
US20150156183A1 (en) System and method for filtering network communications
US7418501B2 (en) Dynamic extension of network-accessible services
US20050198493A1 (en) Distribution methods and apparatus for promoting distributed digital content on a local network
CN108259425A (zh) 攻击请求的确定方法、装置及服务器
US20100100605A1 (en) Methods and apparatus for management of inter-widget interactions
US9294463B2 (en) Apparatus, method and system for context-aware security control in cloud environment
JP2001525585A (ja) 通信に関するセキュリティ・ポリシーを順守させる方法およびシステム
CN108243143A (zh) 一种基于web代理的网闸穿透方法及系统
Navas et al. Do not trust your neighbors! A small IoT platform illustrating a man-in-the-middle attack
EP3128713B1 (en) Page push method and system
CN105991640B (zh) 处理http请求的方法及装置
CN109889468B (zh) 网络数据的传输方法、系统、装置、设备及存储介质
CN110995829B (zh) 实例调用方法、装置及计算机存储介质
CN107846381A (zh) 网络安全处理方法及设备
CN104320483B (zh) 辅助应用程序升级的系统及其方法
CN107257352B (zh) 基于dpdk的url认证的重定向系统与方法
KR101521903B1 (ko) 링크정보의 악성코드에 대응한 단말기의 로컬환경 보호방법과 보호시스템
KR102033500B1 (ko) 분산 클라우드 시스템에서 에지 클라우드에 의한 패킷 라우팅 방법
US20200344057A1 (en) Cybersecurity guard for core network elements
US10320751B2 (en) DNS server selective block and DNS address modification method using proxy

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17906278

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017906278

Country of ref document: EP

Effective date: 20190314

NENP Non-entry into the national phase

Ref country code: DE