WO2017185719A1 - 一种udp协议加速方法和系统 - Google Patents

一种udp协议加速方法和系统 Download PDF

Info

Publication number
WO2017185719A1
WO2017185719A1 PCT/CN2016/106055 CN2016106055W WO2017185719A1 WO 2017185719 A1 WO2017185719 A1 WO 2017185719A1 CN 2016106055 W CN2016106055 W CN 2016106055W WO 2017185719 A1 WO2017185719 A1 WO 2017185719A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
acceleration
local
destination address
response
Prior art date
Application number
PCT/CN2016/106055
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 EP16900226.8A priority Critical patent/EP3422656B1/en
Priority to US16/061,265 priority patent/US10742777B2/en
Publication of WO2017185719A1 publication Critical patent/WO2017185719A1/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/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • 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
    • H04L45/745—Address table lookup; Address filtering
    • 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/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers

Definitions

  • the invention relates to a user datagram protocol UDP protocol, in particular to a UDP protocol traffic acceleration method and system.
  • the UDP protocol is a connectionless protocol in the Open System Interconnection OSI Reference Model. It is in the fourth layer, the transport layer, which is the upper layer of the IP protocol. It is used to process data packets, mainly to compress network data traffic. In the form of a packet, it provides a simple transaction-oriented information delivery service. It does not provide packet grouping, assembly, or sorting of packets.
  • the UDP protocol acceleration is usually divided into two parts.
  • the first link directs the UDP protocol traffic to the remote acceleration server, and the second link is performed by the acceleration server to proxy the UDP traffic.
  • the usual practice in the first step is to redirect UDP protocol traffic to the local proxy, where the UDP packets are encapsulated and forwarded to the remote acceleration server.
  • the local agent needs to send the packet and its original destination address to the acceleration server. Since UDP is connectionless communication, when the data packet is redirected to the local proxy, the original destination address cannot be obtained in the user mode through the existing socket socket function.
  • the specific method for accelerating the UDP protocol traffic flowing through the router in the router is to redirect the traffic to the local proxy by setting the Iptables rule, and obtain the original destination address of the UDP packet in the local proxy through the transparent proxy TPROXY module of Linux.
  • the local agent forwards the packet and the original destination address information to the acceleration server. Since the TPROXY module works in the pre-routing PREROUTING chain of the network filter Netfilter, and the traffic generated by the local application does not pass through the PREROUTING link, the solution cannot accelerate the UDP packets generated by the local application.
  • the router can accelerate the traffic flowing through the router, it cannot distinguish the traffic of different terminals; for example, the terminal device, the mobile phone and other terminal devices access the acceleration router as an example, the router cannot distinguish the traffic of different terminal devices. Therefore, it is necessary to install the acceleration function into the terminal.
  • the invention solves the problem of correctly obtaining the original destination address of the data packet after the UDP data packet is redirected to the local proxy during the UDP protocol traffic acceleration process generated by the local application, thereby realizing acceleration of the local UDP protocol traffic in the client.
  • the UDP protocol acceleration method of the present invention includes: obtaining, by a local proxy, a source address of a local application request in a client; querying a connection information table in an operating system of the client to obtain an original destination address; and using the original destination address and the The request is encapsulated and sent to the acceleration server through the acceleration socket; the acceleration server proxy client requests; the home agent receives the response of the acceleration server, and forwards the response to the corresponding local agent.
  • the UDP protocol acceleration system of the present invention includes a client, including a home agent, one or more local applications to be accelerated, and a Netfilter at the IP layer; an acceleration service system; and wherein the home agent recognizes the request after receiving the request Redirecting requests of different applications, and querying the original destination address, and the destination address is encapsulated with the request and sent to the acceleration server, the acceleration server parses out the original destination address, proxy the request, and returns the response.
  • the home agent after receiving the response from the acceleration server, the home agent queries the acceleration record and forwards the response to the corresponding local application.
  • FIG. 1 is a schematic structural view of a system for implementing the present invention
  • FIG. 2 is a flow chart showing the operation of the home agent module of the present invention.
  • the present invention makes it possible to accelerate the UDP protocol traffic generated by the local application in the client by correctly obtaining the destination address after the local UDP protocol packet is redirected.
  • Iptables is used to direct traffic to a local proxy, local
  • the agent obtains the original destination address of the UDP protocol packet and the traffic guidance in the application layer.
  • the acceleration solution does not change the key modules such as Linux's Netfilter and TCP/IP protocol stack.
  • the client 101 includes a local proxy 1012 and one or more local applications 1011 to be accelerated, both at the application layer; the Netfilter in the client 101 belongs to the IP layer, and can redirect the request sent by the local application 1011 to the local proxy. 1012.
  • the local proxy 1012 processes the redirect request from different applications, queries the original destination address, and encapsulates the original destination address with the request and sends it to the acceleration server 102.
  • the local proxy 1012 also saves the acceleration while processing.
  • the acceleration server 102 parses out the original destination address, and proxies the home agent 1012 to issue a request to the source station 103, and then returns the response back to the home agent 1012; after receiving the response packet from the acceleration server 102, the home agent 1012 queries the previous The saved accelerated record is forwarded to the corresponding local application 1011 based on the accelerated record.
  • FIG. 2 there is shown a flow of the operation of a home agent module of a UDP protocol acceleration method in accordance with the present invention.
  • the method begins in step 201.
  • a local agent's listening socket is created, and the listening socket function is a request to process the client application being redirected to the home agent.
  • the listening socket is associated with the first file descriptor.
  • step 203 it is monitored whether the first file descriptor is readable. If the readable representation indicates that the local application issues a request to be redirected to the port monitored by the local agent, the local agent can receive the redirect request for acceleration processing, and thus proceeds to Step 204; if no, return to this step 203 to continue listening.
  • the source address src_ip, src_port of the request is obtained by the home agent through the API interface; then, in step 205, the local agent queries the connection information table /proc/net/ip_conntrack according to the source address src_ip, src_port of the obtained request, Obtaining the original destination addresses dst_ip, dst_port; and in step 206, the local agent creates an acceleration socket to communicate with the remote acceleration server, and simultaneously creates the accelerated socket information and its associated second file descriptor, request
  • the source address src_ip, src_port, original destination address dst_ip, dst_port, and the acceleration record stored at the local agent are used to be sent back to the local application after the response is obtained.
  • the original destination address dst_ip, dst_port, and request are encapsulated by the home agent and sent to the acceleration server through the acceleration socket.
  • step 209 the process returns to step 203 to continue monitoring.
  • the step 205 of obtaining the original destination address by querying the connection information table /proc/net/ip_conntrack according to the source address src_ip of the request, src_port is further implemented by the following steps:
  • the Linux kernel uses the ip_conntrack structure to record the status of incoming netfilter network packets and saves the state information to /proc/net/ip_conntrack.
  • the third field indicates the record survival time in seconds
  • the 4th, 5th, 6th, and 7th fields indicate the tuple[ORIGINAL] information before entering the netfilter (the tuple information before the request is redirected), that is, the original udp packet information;
  • the 8th field indicates the status of the udp packet, and [UNREPLIED] indicates that the server does not respond to the client. If the response has no such field;
  • the fields 9, 10, 11, and 12 represent the tuple information after the tuple [REPLY] information request is redirected after entering the netfilter, that is, the information after the udp packet is redirected;
  • the udp data tuple obtained by the local agent corresponds to the tuple[REPLY] information of the /proc/net/ip_conntrack table. According to this information, the tuple[ORIGINAL] information can be found, and the original destination address can be obtained.
  • the local proxy when a client uses the same socket (fixed ip, port) to send udp data to a plurality of different destination addresses, the local proxy obtains iptables redirected udp data tuple has unique Sex, /proc/net/ip_conntrack table can still find the only match The record gets the exact original destination address. The reason is that the record of /proc/net/ip_conntrack is generated according to the tuple[ORIGINAL] of the udp packet. If there is an element in the tuple[ORIGINAL], a new record will be generated. In this example, although the same socket is used, but the original destination address is different, multiple records are generated.
  • the home agent after the home agent correctly obtains the original destination address of the UDP packet, the home agent can forward the packet information and the destination address information to the remote acceleration server to accelerate the local UDP protocol.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种UDP协议加速方法和系统。该系统包括客户端、加速服务器和源站，其中客户端包括处于应用层的本地代理和待加速的一个或多个本地应用以及处于IP层的网络过滤器。本地代理在收到请求后识别来自不同应用的重定向请求，并查询原始目的地址，将目的地址与请求封装后发送至加速服务器；加速服务器解析出原始目的地址，并代理请求，将响应返送回本地代理；本地代理收到加速服务器的响应后，查询加速记录，将响应转发至对应本地应用。

Description

一种UDP协议加速方法和系统 技术领域
本发明涉及用户数据报协议UDP协议，尤其涉及UDP协议流量加速方法和系统。
背景技术
UDP协议是开放式系统互联OSI参考模型的中的一种无连接协议，处于第四层——传输层中，是IP协议的上一层，用于处理数据包，主要是将网络数据流量压缩成数据包的形式，提供面向事务的简单信息传送服务。它不提供数据包分组、组装，也不能对数据包进行排序。
UDP协议加速通常分为两个环节，第一个环节将UDP协议流量引导至远程加速服务器，第二个环节由加速服务器对UDP流量进行代理。第一个环节的通常做法是将UDP协议流量重定向至本地代理，在本地代理中对UDP数据包进行封装并转发至远程加速服务器。为使加速服务器正确代理UDP协议流量，本地代理需将数据包和其原始目的地址发送至加速服务器。由于UDP是无连接通信，当数据包被重定向至本地代理后，在用户态无法通过现有套接字socket函数获取原始目的地址。
而目前在路由器中对流经路由器的UDP协议流量加速的具体方法是通过设置Iptables规则将流量重定向至本地代理，通过Linux的透明代理TPROXY模块在本地代理中获取UDP数据包的原始目的地址，在本地代理中将数据包和原始目的地址信息转发至加速服务器。由于TPROXY模块工作于网络过滤器Netfilter的路由前PREROUTING链，而本地应用产生的流量并不经过PREROUTING链路，因此该方案不能对本地应用产生的UDP数据包加速。
另一方面，尽管路由器能够加速流经路由器的流量，但无法对不同终端的流量进行区分处理；以机顶盒、手机等终端设备接入加速路由器为例，路由器无法区分不同的终端设备的流量。因此，需要将加速功能安装至终端中。
发明内容
提供本发明内容以便以简化的形式介绍将在以下的具体实施方式中进一步描述的一些概念。本发明内容并不旨在专门标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。
本发明通过解决本地应用产生的UDP协议流量加速过程中UDP数据包重定向至本地代理后正确获取数据包的原始目的地址的问题，实现在客户端中对本地UDP协议流量进行加速。
本发明的UDP协议加速方法包括，在客户端中由本地代理获取本地应用请求的源地址；查询所述客户端的操作系统中的连接信息表获取原始目的地址；将所述原始目的地址和所述请求封装后通过加速套接字发送至加速服务器；由所述加速服务器代理客户端请求；所述本地代理接收所述加速服务器的响应，并将所述响应转发至对应的所述本地代理。
本发明的UDP协议加速系统包括，客户端，包括本地代理、待加速的一个或多个本地应用、以及处于IP层的Netfilter；加速服务系统；以及其中所述本地代理在收到请求后识别来自不同应用的重定向请求，并查询原始目的地址，将目的地址与所述请求封装后发送至所述加速服务器，所述加速服务器解析出所述原始目的地址，代理所述请求，并将响应返送回所述本地代理，所述本地代理收到所述加速服务器的响应后，查询加速记录，并将所述响应转发至对应本地应用。
附图说明
图1是实现本发明的系统结构示意图；
图2是本发明的本地代理模块工作的流程图。
具体实施方式
本发明通过在本地UDP协议数据包被重定向后正确获取其目的地址，使在客户端中对本地应用产生的UDP协议流量加速成为可能。
根据本发明的一个实施例，依靠Iptables将流量引导至本地代理，本地 代理中对UDP协议数据包原始目的地址的获取、流量引导均在应用层中实现。加速方案不改变Linux的Netfilter、TCP/IP协议栈等关键模块。
参见图1，示出了实现本发明的系统结构示意图，该系统包括客户端101、加速服务器102、和源站103。客户端101中包括本地代理1012和待加速的一个或多个本地应用1011，两者均处于应用层；客户端101中的Netfilter属于IP层，可将本地应用1011发出的请求重定向至本地代理1012中。本地代理1012在收到请求后进行处理，识别来自不同应用的重定向请求，查询原始目的地址，并将原始目的地址与请求封装后发送至加速服务器102，在处理的同时本地代理1012还保存加速记录；加速服务器102解析出原始目的地址，并对本地代理1012进行代理以向源站103发出请求，然后将响应返送回本地代理1012；本地代理1012收到加速服务器102的响应包后，查询先前保存的加速记录，并根据加速记录将响应转发至对应本地应用1011。
现在转到图2，其示出了根据本发明的一种UDP协议加速方法的本地代理模块工作的流程。
方法在步骤201开始。
在步骤202，创建本地代理的监听套接字，监听套接字作用是处理客户端应用被重定向至本地代理的请求。该监听套接字关联第一文件描述符。
在步骤203，监听第一文件描述符是否可读，若可读表示有本地应用发出请求被重定向到本地代理监听的端口，那么本地代理即可接收重定向请求以进行加速处理，因而前进到步骤204；如果否，则返回此步骤203继续监听。
在步骤204，由本地代理通过API接口获取请求的源地址src_ip、src_port；接着在步骤205，由本地代理根据所获取的请求的源地址src_ip，src_port通过查询连接信息表/proc/net/ip_conntrack，得到原始目的地址dst_ip、dst_port；并在步骤206，由本地代理创建加速套接字以与远程加速服务器进行通信，同时将所创建的加速套接字信息及其关联的第二文件描述符、请求的源地址src_ip、src_port、原始目的地址dst_ip、dst_port和保存在本地代理处的加速记录中以便用于在得到响应后发回给本地应用。由本地代理将原始目的地址dst_ip、dst_port和请求封装后通过加速套接字发送至加速服务器。
在步骤207，作出加速套接字是否收到请求的判断，若否，方法返回步骤 203，若是，则在步骤208查询加速记录，根据加速记录获取请求的源地址src_ip、src_port，并修改请求的目的地址，接着在步骤209将响应通过本地代理监听套接字转发至请求的源地址src_ip、src_port。
整个进程在步骤209之后，返回步骤203，继续监听。
其中，根据请求的源地址src_ip，src_port查询连接信息表/proc/net/ip_conntrack获取原始目的地址的步骤205进一步通过以下步骤实现：
Linux内核中使用ip_conntrack结构体来记录进入netfilter网络数据包的状态，并把状态信息保存到/proc/net/ip_conntrack中；
/proc/net/ip_conntrack中udp协议记录格式如下：
udp 17 21 src＝192.168.1.121 dst＝27.152.87.177
sport＝35779dport＝6666[UNREPLIED]
src＝127.0.0.1dst＝192.168.1.121
sport＝8122dport＝35779mark＝0use＝2
其中主要字段含义如下：
第3个字段表示记录存活时间，单位为秒；
第4、5、6、7字段表示进入netfilter前的tuple[ORIGINAL]信息(请求被重定向前的元组信息)，即原始udp数据包信息；
第8个字段表示udp数据包状态，[UNREPLIED]表示服务端未响应客户端，若已响应后无该字段；
第9、10、11、12字段表示进入netfilter后的tuple[REPLY]信息请求被重定向后的元组信息)，即udp数据包被重定向后的信息；
本地代理得到的udp数据tuple对应/proc/net/ip_conntrack表的tuple[REPLY]信息，根据此信息可找出tuple[ORIGINAL]信息，即可得到原始目的地址。
根据本发明的一个实施例，当某个客户端使用同一个套接字(固定ip、port)向多个不同的目的地址发送udp数据时，本地代理得到iptables重定向后的udp数据tuple具有唯一性，/proc/net/ip_conntrack表中依然能够查询到唯一匹配的 记录获取准确的原始目的地址。原因是/proc/net/ip_conntrack的记录是根据udp数据包的tuple[ORIGINAL]生成的，tuple[ORIGINAL]中有一个元素不同，即会生成一条新的记录。本例中虽使用同一个套接字，但是原始目的地址不同，因此会生成多条记录。
根据本发明的上述方法，当本地代理正确获得UDP数据包的原始目的地址后，本地代理可将数据包信息和目的地址信息转发至远程加速服务器，实现对本地UDP协议的加速。
已经使用本发明实施例的详细描述来描述了本发明技术，这些实施例是以示例的形式来提供的并且不旨在限制本发明技术的范围。所描述的实施例可包括不同特征，并非所有特征都是本发明技术的所有实施例所需的。本发明技术的一些实施例只利用这些特征中的一些或这些特征的可能组合。本领域的技术人员会想到所描述的本发明技术的各实施例的变型以及本发明技术包括在所描述的各实施例中记录的特征的不同组合的各实施例。本发明技术的范围旨在只由权利要求书来限定，并且权利要求书旨在被解释成包括所有这样的变型和组合。

Claims (5)

  1. 一种UDP协议加速方法，包括：
    在客户端中由本地代理获取本地应用请求的源地址(204)；
    查询所述客户端的操作系统中的连接信息表获取原始目的地址(205)；
    将所述原始目的地址和所述请求封装后通过加速套接字发送至加速服务器(206)；
    由所述加速服务器代理客户端请求(208)；
    所述本地代理接收所述加速服务器的响应，并将所述响应转发至对应的所述本地代理(209)。
  2. 如权利要求1所述的方法，其特征在于，查询所述连接信息表获取原始目的地址的步骤包括：
    由所述本地代理收到UDP请求的元组信息查询所述连接信息表，根据请求被重定向后的元组信息，查询出请求被重定向前的元组信息，从而得到原始目的地址。
  3. 如权利要求1所述的方法，其特征在于，应用请求信息、本地代理与加速服务器连接信息储存在本地代理中，当本地代理收到所述加速服务器的响应时根据所述应用请求信息、本地代理与加速服务器连接信息将响应转发给相应本地应用。
  4. 如权利要求1所述的方法，其特征在于，所述本地代理及客户端应用安装于同一客户端中。
  5. 一种UDP协议加速系统，包括：
    客户端，包括本地代理、待加速的一个或多个本地应用、以及处于IP层的Netfilter；
    加速服务系统；以及
    其中所述本地代理在收到请求后识别来自不同应用的重定向请求，并查询原始目的地址，将目的地址与所述请求封装后发送至所述加速服务器，所述加速服务器解析出所述原始目的地址，代理所述请求，并将响应返送回所述本地代理，所述本地代理收到所述加速服务器的响应后，查询加速记录，并将所述响应转发至对应本地应用。
PCT/CN2016/106055 2016-04-25 2016-11-16 一种udp协议加速方法和系统 WO2017185719A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP16900226.8A EP3422656B1 (en) 2016-04-25 2016-11-16 Udp protocol acceleration method and system
US16/061,265 US10742777B2 (en) 2016-04-25 2016-11-16 UDP protocol acceleration method and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610261388.XA CN105791315B (zh) 2016-04-25 2016-04-25 一种udp协议加速方法和系统
CN201610261388.X 2016-04-25

Publications (1)

Publication Number Publication Date
WO2017185719A1 true WO2017185719A1 (zh) 2017-11-02

Family

ID=56399513

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/106055 WO2017185719A1 (zh) 2016-04-25 2016-11-16 一种udp协议加速方法和系统

Country Status (4)

Country Link
US (1) US10742777B2 (zh)
EP (1) EP3422656B1 (zh)
CN (1) CN105791315B (zh)
WO (1) WO2017185719A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105791315B (zh) * 2016-04-25 2019-05-14 网宿科技股份有限公司 一种udp协议加速方法和系统
CN107071034B (zh) 2017-04-20 2019-10-11 网宿科技股份有限公司 一种数据包传输方法和系统
CN107147588B (zh) * 2017-05-16 2020-03-31 网宿科技股份有限公司 流量引导方法和装置
CN107872545B (zh) * 2017-09-26 2022-12-06 中兴通讯股份有限公司 一种报文传输方法及装置、计算机可读存储介质
CN110971487B (zh) * 2019-11-26 2021-10-26 武汉虹旭信息技术有限责任公司 网络协议识别方法及装置
CN111212088B (zh) * 2020-01-21 2022-05-17 福建星网智慧科技有限公司 一种加速服务器提速rtp报文转发方法以及装置
CN113472621B (zh) * 2020-03-30 2023-05-30 北京沃东天骏信息技术有限公司 网络数据转发方法、装置和系统
CN111800330B (zh) * 2020-06-30 2021-12-03 苏州瑞立思科技有限公司 基于无线接入点的外设网络流量的代理加速方法及系统
CN112600952B (zh) * 2020-12-10 2022-09-27 四川迅游网络科技股份有限公司 一种移动端网络加速分流方法和系统
CN113507393B (zh) * 2021-09-08 2021-12-07 腾讯科技（深圳）有限公司 数据加速传输方法、装置、计算机设备和存储介质
CN114710548B (zh) * 2022-03-22 2024-04-05 阿里巴巴（中国）有限公司 报文转发方法及装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011005394A2 (en) * 2009-06-22 2011-01-13 Citrix Systems, Inc. Systems and methods for a distributed hash table in a multi-core system
CN102244645A (zh) * 2010-05-14 2011-11-16 北京快网科技有限公司 一种基于udp协议的可靠,透明,通用加速网关系统
CN102571928A (zh) * 2011-12-21 2012-07-11 深信服网络科技（深圳）有限公司 根据应用识别选择应用代理的方法及装置
CN103916405A (zh) * 2014-04-25 2014-07-09 厦门享游网络科技有限公司 一种IOS上针对App的TCP/UDP流量引导的方法
CN105072057A (zh) * 2015-07-09 2015-11-18 中国科学院计算技术研究所 一种用于网络数据传输的中间交换设备及网络通信系统
CN105516262A (zh) * 2015-11-27 2016-04-20 深圳市酷士多网络科技有限公司 应用程序远程操控方法及系统
CN105791315A (zh) * 2016-04-25 2016-07-20 网宿科技股份有限公司 一种udp协议加速方法和系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6609159B1 (en) * 1998-11-30 2003-08-19 Semyon Dukach Methods, systems, and machine readable programming for interposing front end servers between servers and clients
US8195823B2 (en) 2000-04-17 2012-06-05 Circadence Corporation Dynamic network link acceleration
US7031314B2 (en) * 2001-05-16 2006-04-18 Bytemobile, Inc. Systems and methods for providing differentiated services within a network communication system
KR100638030B1 (ko) * 2003-05-30 2006-10-23 엘지전자 주식회사 네트워크 전기 기기
US8819242B2 (en) * 2006-08-31 2014-08-26 Cisco Technology, Inc. Method and system to transfer data utilizing cut-through sockets
US8908700B2 (en) * 2007-09-07 2014-12-09 Citrix Systems, Inc. Systems and methods for bridging a WAN accelerator with a security gateway
ES2354344B1 (es) * 2009-05-22 2011-10-05 Telefonica, S.A. Método y sistema de transmisión y recepción de paquetes.
EP2748716B1 (en) * 2011-11-15 2018-05-16 Nicira Inc. Network control system for configuring middleboxes
CN202696653U (zh) * 2012-07-16 2013-01-23 北京国创富盛通信股份有限公司 网络加速系统
US9258335B1 (en) 2012-09-17 2016-02-09 Amazon Technologies, Inc. Connection-aggregation proxy service
CN104639564A (zh) * 2015-03-03 2015-05-20 北京极科极客科技有限公司 一种udp协议的代理方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011005394A2 (en) * 2009-06-22 2011-01-13 Citrix Systems, Inc. Systems and methods for a distributed hash table in a multi-core system
CN102244645A (zh) * 2010-05-14 2011-11-16 北京快网科技有限公司 一种基于udp协议的可靠,透明,通用加速网关系统
CN102571928A (zh) * 2011-12-21 2012-07-11 深信服网络科技（深圳）有限公司 根据应用识别选择应用代理的方法及装置
CN103916405A (zh) * 2014-04-25 2014-07-09 厦门享游网络科技有限公司 一种IOS上针对App的TCP/UDP流量引导的方法
CN105072057A (zh) * 2015-07-09 2015-11-18 中国科学院计算技术研究所 一种用于网络数据传输的中间交换设备及网络通信系统
CN105516262A (zh) * 2015-11-27 2016-04-20 深圳市酷士多网络科技有限公司 应用程序远程操控方法及系统
CN105791315A (zh) * 2016-04-25 2016-07-20 网宿科技股份有限公司 一种udp协议加速方法和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3422656A4 *

Also Published As

Publication number Publication date
US10742777B2 (en) 2020-08-11
CN105791315B (zh) 2019-05-14
CN105791315A (zh) 2016-07-20
EP3422656A4 (en) 2019-03-13
US20180367648A1 (en) 2018-12-20
EP3422656B1 (en) 2020-09-23
EP3422656A1 (en) 2019-01-02

Similar Documents

Publication Publication Date Title
WO2017185719A1 (zh) 一种udp协议加速方法和系统
US10122622B2 (en) Exchanging application metadata for application context aware service insertion in service function chain
EP3259898B1 (en) Message bus service directory
CN107948076B (zh) 一种转发报文的方法及装置
US7769871B2 (en) Technique for sending bi-directional messages through uni-directional systems
CA2968964C (en) Source ip address transparency systems and methods
WO2017140216A1 (zh) 一种网络的负载均衡、控制及网络交互方法和装置
WO2018032399A1 (en) Server and method having high concurrency capability
WO2021073565A1 (zh) 业务服务提供方法及系统
WO2015143802A1 (zh) 业务功能链处理方法及装置
US10708085B2 (en) Cloud network services provider having a gateway for subscriber specified connection to a cloud service provider
EP1528745B1 (en) Communication method and apparatus
EP1701516A1 (en) Method for facilitating application server functionality and access node comprising same
CN114501593B (zh) 网络切片接入方法、装置、系统和存储介质
US10374946B2 (en) Centralized wireless network management system
WO2007019809A1 (fr) Procede et systeme d'etablissement d'un canal direct point par point
KR101451459B1 (ko) 인공 지능 모듈 시퀀싱 방법 및 애플리케이션 서버
US20070002829A1 (en) Internet protocol voice logger
US20030084123A1 (en) Scheme for implementing FTP protocol in a residential networking architecture
WO2019041332A1 (zh) 一种加速网络传输优化方法以及系统
WO2009053878A1 (en) Methods and systems for offload processing
JP2013126219A (ja) 転送サーバおよび転送プログラム
JP5438230B2 (ja) インターネット接続システム
US10212196B2 (en) Interface discovery and authentication in a name-based network
TWI778771B (zh) 虛擬機器運行監控方法、監控系統及監控設備

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2016900226

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2016900226

Country of ref document: EP

Effective date: 20180928

NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 16900226

Country of ref document: EP

Kind code of ref document: A1