一种透明代理服务方法及装置

技术领域

本申请涉及网络应用代理领域，具体而言，涉及一种透明代理服务方法及装置。

背景技术

随着网络技术的大力发展，网络应用也越来越复杂，并且有很多时候都需要针对全球广域网(World Wide Web，WEB)级的应用数据进行转发。在现有技术中，当前市面上有Nginx等反向代理软件，可以实现WEB级的应用数据的转发。但是，现有技术中的代理服务方法，在进行代理转发时，需要修改请求IP地址到代理服务器才能实现数据的转发，导致代理转发的效率较低。

发明内容

本申请实施例的目的在于提供一种透明代理服务方法及装置，用以解决代理转发的效率较低的技术问题。

第一方面，本申请实施例提供一种透明代理服务方法，包括：接收客户端发送的网络请求包；其中，所述客户端中预先配置有与目标服务端对应的代理服务端的IP地址信息；根据预先配置好的服务端口信息将所述网络请求包转发至本地代理服务，并利用所述本地代理服务将所述网络请求包转换为应用请求包；根据所述网络请求包中的目标服务端对应的IP地址信息将所述应用请求包转发至所述目标服务端。在上述方案中，可以预先在客户端中配置与目标服务端对应的代理服务端的IP地址信息，以及预先在代理服务端配置好服务端口信息。这样，客户端发送的网络请求包可以基于预先配置好的与目标服务端对应的代理服务端的IP地址信息转发至代理服务端，并基于预先配置好的服务端口信息转发至本地代理服务，从而利用本地代理服务将网络请求包转发至目标服务端。由于客户端发送的网络请求包请求的IP地址可以仍然为目标服务端的IP地址，而不是代理服务端的IP地址，也就是说在代理转发时无需修改请求的IP地址，因此可以提高代理转发的效率。

在可选的实施方式中，所述利用所述本地代理服务将所述网络请求包转换为应用请求包，包括：利用所述本地代理服务对所述网络请求包进行拆包，并获取所述目标服务端对应的IP地址信息；利用所述本地代理服务对拆包后的网络请求包进行封装，得到所述应用请求包。在上述方案中，应用层的本地代理服务在接收到网络请求包之后，可以从应用服务中获取网络请求包真实请求的地址，从而可以将网络请求包封装为应用包后转发给对应的目标服务端。

在可选的实施方式中，所述利用所述本地代理服务对拆包后的网络请求包进行封装，得到所述应用请求包，包括：利用所述本地代理服务根据预设业务逻辑对所述拆包后的网络请求包进行处理，得到处理后的网络请求包；利用所述本地代理服务对处理后的网络请求包进行封装，得到所述应用请求包。在上述方案中，可以在透明代理服务中实现定制业务逻辑，从而拓展透明代理服务的应用场景。代理服务端可以根据预设的业务逻辑对网络请求包进行处理，并将处理后的网络请求包封装为应用包转发给对应的目标服务端。

在可选的实施方式中，所述利用所述本地代理服务根据预设业务逻辑对所述拆包后的网络请求包进行处理，得到处理后的网络请求包，包括：利用所述本地代理服务对所述拆包后的网络请求包中的参数进行记录以及修改，得到处理后的网络请求包。在上述方案中，可以在透明代理服务中实现定制业务逻辑，从而拓展透明代理服务的应用场景。代理服务端可以根据预设的业务逻辑对网络请求包中的参数进行记录以及修改，并将记录以及修改后的参数封装为应用包转发给对应的目标服务端。

在可选的实施方式中，在所述接收客户端发送的网络请求包之前，所述方法还包括：配置目标端口对应的服务端口信息。在上述方案中，可以预先在客户端中配置与目标服务端对应的代理服务端的IP地址信息，以及预先在代理服务端配置好服务端口信息。这样，客户端发送的网络请求包可以基于预先配置好的与目标服务端对应的代理服务端的IP地址信息转发至代理服务端，并基于预先配置好的服务端口信息转发至本地代理服务，从而利用本地代理服务将网络请求包转发至目标服务端。由于客户端发送的网络请求包请求的IP地址可以仍然为目标服务端的IP地址，而不是代理服务端的IP地址，也就是说在代理转发时无需修改请求的IP地址，因此可以提高代理转发的效率。

在可选的实施方式中，在所述根据所述网络请求包中的目标服务端对应的IP地址信息将所述应用请求包转发至所述目标服务端之后，所述方法还包括：接收所述目标服务端根据所述应用请求包返回的结果数据；将所述结果数据转发至所述客户端。在上述方案中，代理服务端可以接收目标服务端根据应用请求包返回的结果数据，并将结果转发给客户端，从而通过透明代理服务实现客户端与目标服务端之间的数据交互。

第二方面，本申请实施例提供一种透明代理服务装置，包括：第一接收模块，用于接收客户端发送的网络请求包；其中，所述客户端中预先配置有与目标服务端对应的代理服务端的IP地址信息；第一转发模块，用于根据预先配置好的服务端口信息将所述网络请求包转发至本地代理服务，并利用所述本地代理服务将所述网络请求包转换为应用请求包；第二转发模块，用于根据所述网络请求包中的目标服务端对应的IP地址信息将所述应用请求包转发至所述目标服务端。在上述方案中，可以预先在客户端中配置与目标服务端对应的代理服务端的IP地址信息，以及预先在代理服务端配置好服务端口信息。这样，客户端发送的网络请求包可以基于预先配置好的与目标服务端对应的代理服务端的IP地址信息转发至代理服务端，并基于预先配置好的服务端口信息转发至本地代理服务，从而利用本地代理服务将网络请求包转发至目标服务端。由于客户端发送的网络请求包请求的IP地址可以仍然为目标服务端的IP地址，而不是代理服务端的IP地址，也就是说在代理转发时无需修改请求的IP地址，因此可以提高代理转发的效率。

在可选的实施方式中，所述第一转发模块具体用于：利用所述本地代理服务对所述网络请求包进行拆包，并获取所述目标服务端对应的IP地址信息；利用所述本地代理服务对拆包后的网络请求包进行封装，得到所述应用请求包。在上述方案中，应用层的本地代理服务在接收到网络请求包之后，可以从应用服务中获取网络请求包真实请求的地址，从而可以将网络请求包封装为应用包后转发给对应的目标服务端。

在可选的实施方式中，所述第一转发模块还用于：利用所述本地代理服务根据预设业务逻辑对所述拆包后的网络请求包进行处理，得到处理后的网络请求包；利用所述本地代理服务对处理后的网络请求包进行封装，得到所述应用请求包。在上述方案中，可以在透明代理服务中实现定制业务逻辑，从而拓展透明代理服务的应用场景。代理服务端可以根据预设的业务逻辑对网络请求包进行处理，并将处理后的网络请求包封装为应用包转发给对应的目标服务端。

在可选的实施方式中，所述第一转发模块还用于：利用所述本地代理服务对所述拆包后的网络请求包中的参数进行记录以及修改，得到处理后的网络请求包。在上述方案中，可以在透明代理服务中实现定制业务逻辑，从而拓展透明代理服务的应用场景。代理服务端可以根据预设的业务逻辑对网络请求包中的参数进行记录以及修改，并将记录以及修改后的参数封装为应用包转发给对应的目标服务端。

在可选的实施方式中，所述透明代理服务装置还包括：配置模块，用于配置目标端口对应的服务端口信息。在上述方案中，可以预先在客户端中配置与目标服务端对应的代理服务端的IP地址信息，以及预先在代理服务端配置好服务端口信息。这样，客户端发送的网络请求包可以基于预先配置好的与目标服务端对应的代理服务端的IP地址信息转发至代理服务端，并基于预先配置好的服务端口信息转发至本地代理服务，从而利用本地代理服务将网络请求包转发至目标服务端。由于客户端发送的网络请求包请求的IP地址可以仍然为目标服务端的IP地址，而不是代理服务端的IP地址，也就是说在代理转发时无需修改请求的IP地址，因此可以提高代理转发的效率。

在可选的实施方式中，所述透明代理服务装置还包括：第二接收模块，用于接收所述目标服务端根据所述应用请求包返回的结果数据；第三转发模块，用于将所述结果数据转发至所述客户端。在上述方案中，代理服务端可以接收目标服务端根据应用请求包返回的结果数据，并将结果转发给客户端，从而通过透明代理服务实现客户端与目标服务端之间的数据交互。

第三方面，本申请实施例提供一种电子设备，包括：处理器、存储器和总线；所述处理器和所述存储器通过所述总线完成相互间的通信；所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行如第一方面所述的透明代理服务方法。

第四方面，本申请实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令被计算机运行时，使所述计算机执行如第一方面所述的透明代理服务方法。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举本申请实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种透明代理服务系统的结构框图；

图2为本申请实施例提供的一种应用于代理服务端的透明代理服务方法的流程图；

图3为本申请实施例提供的一种透明代理服务装置的结构框图；

图4为本申请实施例提供的一种电子设备的结构框图。

具体实施方式

发明人注意到，在进行代理转发时，一般需要修改请求IP地址到代理服务器才能实现数据的转发，从而导致代理转发的效率较低。

以采用Nginx反向代理软件实现代理转发为例，使用Nginx反向代理软件实现代理转发一般可以包括如下步骤：步骤1，在Nginx上配置目标服务端的反向代理；步骤2，客户端选择向上述目标服务端发起请求；步骤3，客户端把实际请求上述目标服务端的IP地址修改为请求Nginx的代理IP地址；步骤4，请求到达Nginx；步骤5，Nginx根据配置将请求转发到上述目标服务端中；步骤6，目标服务端返回数据给Nginx；步骤7，Nginx返回数据给客户端。

可以看出，在使用Nginx反向代理软件实现代理转发的过程中，客户端需要修改请求IP地址到代理服务端，从而导致代理转发的效率较低。

为了缓解代理转发的效率较低的问题，发明人研究发现，可以通过预先在客户端以及代理服务端进行IP地址以及端口信息的配置，从而可以实现在代理转发的过程中，可以基于预先配置的信息进行数据的转发，无需要修改请求IP地址到代理服务端，从而提高代理转发的效率。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

请参照图1，图1为本申请实施例提供的一种透明代理服务系统的结构框图，该透明代理服务系统100可以包括客户端101、代理服务端102以及目标服务端103，客户端101与代理服务端102通信连接，代理服务端102与目标服务端103通信连接。

其中，客户端101用于通过代理服务端102向目标服务端103发送网络请求包；代理服务端102用于接收客户端101向目标服务端103发送的网络请求包，并将上述网络请求包转发给目标服务端103；目标服务端103用于通过代理服务端102接收客户端101发送的网络请求包，并根据网络请求包向客户端101返回对应的响应数据。

可以理解的是，本申请实施例提供的客户端101、代理服务端102以及目标服务端103均可以通过电子设备实现。其中，客户端101、代理服务端102以及目标服务端103可以是类型相同的电子设备(例如：均为电脑等)，也可以是类型不同的电子设备(例如：客户端101以及目标服务端103为电脑，代理服务端102为服务器等)，本申请实施例对此不作具体的限定，本领域技术人员可以根据实际情况进行合适的调整。

除此之外，本申请实施例对透明代理服务系统100中的客户端101、代理服务端102以及目标服务端103的数量也不作具体的限定。

举例来说，透明代理服务系统100中的客户端101、代理服务端102以及目标服务端103的数量可以均为一个，此时，客户端101与代理服务端102，以及代理服务端102与目标服务端103均一一对应；或者，透明代理服务系统100中的客户端101、代理服务端102以及目标服务端103的数量可以部分为一个、部分为多个；或者，透明代理服务系统100中的客户端101、代理服务端102以及目标服务端103的数量可以均为分为多个。本领域技术人员同样可以根据实际情况，对透明代理服务系统100中的客户端101、代理服务端102以及目标服务端103的数量进行合适的调整。

基于上述透明代理服务系统，本申请实施例提供一种应用于客户端的透明代理服务方法、一种应用于代理服务端的透明代理服务方法以及一种应用于目标服务端的透明代理服务方法。下面依次对上述三种方法进行详细的介绍。

首先，介绍应用于客户端的透明代理服务方法。该透明代理服务方法可以包括如下步骤：

第一步，客户端配置与目标服务端对应的代理服务端的IP地址信息。

第二步，客户端根据目标服务端的IP地址信息以及预先配置的与目标服务端对应的代理服务端的IP地址信息，向对应的代理服务端发送网络请求包。

具体的，客户端中事先配置有客户端与目标服务端的路由信息，在此基础上，客户端中可以配置与上述路由信息对应的代理服务端的IP地址信息。

举例来说，假设代理服务端的IP地址为10.36.2.1，服务端1的IP地址为10.36.3.1，服务端2的IP地址为10.36.3.2。针对客户端至服务端1的路由，可以配置对应的代理服务端的IP地址为10.36.2.1；类似的，针对客户端至服务端2的路由，可以配置对应的代理服务端的IP地址为10.36.2.1。

当客户端需要向目标服务端发送网络请求包时，首先客户端查找到与目标服务端对应的路由信息，然后查找与该条路由信息对应的代理服务端的IP地址信息，从而可以根据上述IP地址信息将网络请求包发送给对应的代理服务端。

作为一种实施方式，客户端的配置过程可脚本化，即在客户端配置与目标服务端对应的代理服务端的IP地址信息时，可以通过脚本实现配置过程，从而可以实现客户端的动态配置。

进一步的，在上述客户端根据目标服务端的IP地址信息以及预先配置的与目标服务端对应的代理服务端的IP地址信息，向对应的代理服务端发送网络请求包的步骤之后，本申请实施例提供的应用于客户端的透明代理服务方法还可以包括如下步骤：

客户端接收代理服务端发送的目标服务端基于网络请求包返回的结果数据。

在上述方案中，可以预先在客户端中配置与目标服务端对应的代理服务端的IP地址信息，这样，客户端发送的网络请求包可以基于预先配置好的与目标服务端对应的代理服务端的IP地址信息转发至代理服务端。由于客户端发送的网络请求包请求的IP地址可以仍然为目标服务端的IP地址，而不是代理服务端的IP地址，也就是说在代理转发时无需修改请求的IP地址，因此可以提高代理转发的效率。

接下来，介绍应用于代理服务端的透明代理服务方法。请参照图2，图2为本申请实施例提供的一种应用于代理服务端的透明代理服务方法的流程图，该透明代理服务方法可以包括如下步骤：

步骤S201：代理服务端接收客户端发送的网络请求包。

步骤S202：代理服务端根据预先配置好的服务端口信息将网络请求包转发至本地代理服务，并利用本地代理服务将网络请求包转换为应用请求包。

步骤S203：代理服务端根据网络请求包中的目标服务端对应的IP地址信息将应用请求包转发至目标服务端。

具体的，在执行上述步骤S201之前，本申请实施例提供的应用于代理服务端的透明代理服务方法还可以包括如下步骤：

代理服务端配置目标端口对应的服务端口信息。

其中，代理服务端中可以事先配置本地网络请求包转发到的服务端口信息。作为一种实施方式，在此基础上，可以配置事先代理服务端上的配置持久化，这样在发生代理服务端断电、重启等问题时，不会出现配置消失的情况，进一步的提高代理转发的效率。

举例来说，Iptables配置持久化可以包括如下步骤：步骤1，配置完成Iptables规则；步骤2，保存Iptables规则；步骤3，将Iptables规则写入配置文件中；步骤4，设置rc.local权限。

在客户端以及代理服务端均配置完成后，客户端可以根据预先目标服务端的IP地址信息以及预先配置的与目标服务端对应的代理服务端的IP地址信息，向对应的代理服务端发送网络请求包；代理服务端在接收到上述网络请求包之后，可以根据上述步骤中配置好的服务端口信息将网络请求包转发至本地代理服务，并利用本地代理服务将网络请求包转换为应用请求包。

其中，作为一种实施方式，代理服务端将网络请求包转发至本地代理服务可以基于防火墙的网络地址转换(Network Address Translation，NAT)策略，即可以基于代理服务端自身的防火墙策略配置，实现网络层至应用层的数据转发。

代理服务端在将网络请求包转换为应用请求包的过程中，可以获取到网络请求包中携带的目标服务端对应的IP地址信息，从而可以根据上述目标服务端对应的IP地址信息将应用请求包转发至目标服务端，完成透明代理转发。

在上述方案中，可以预先在客户端中配置与目标服务端对应的代理服务端的IP地址信息，以及预先在代理服务端配置好服务端口信息。这样，客户端发送的网络请求包可以基于预先配置好的与目标服务端对应的代理服务端的IP地址信息转发至代理服务端，并基于预先配置好的服务端口信息转发至本地代理服务，从而利用本地代理服务将网络请求包转发至目标服务端。由于客户端发送的网络请求包请求的IP地址可以仍然为目标服务端的IP地址，而不是代理服务端的IP地址，也就是说在代理转发时无需修改请求的IP地址，因此可以提高代理转发的效率。

进一步的，上述步骤S202具体可以包括如下步骤：

第一步，代理服务端利用本地代理服务对网络请求包进行拆包，并获取目标服务端对应的IP地址信息。

第二步，代理服务端利用本地代理服务对拆包后的网络请求包进行封装，得到应用请求包。

具体的，代理服务端可以利用本地代理服务对网络请求包进行拆包，得到网络请求包中携带的参数(例如：目标服务端对应的IP地址信息等)，然后再利用本地代理服务对上述参数进行封装，得到应用请求包。

作为一种实施方式，上述代理服务端利用本地代理服务对拆包后的网络请求包进行封装，得到应用请求包的步骤具体可以包括如下步骤：

第一步，代理服务端利用本地代理服务根据预设业务逻辑对拆包后的网络请求包进行处理，得到处理后的网络请求包。

第二步，代理服务端利用本地代理服务对处理后的网络请求包进行封装，得到应用请求包。

也就是说，可以提供定制业务逻辑，例如：可以根据需求对拆包后的参数进行修改、记录等处理，从而拓展透明代理服务的应用场景。代理服务端可以根据预设的业务逻辑对网络请求包进行处理，并将处理后的网络请求包封装为应用包转发给对应的目标服务端。

在上述方案中，应用层的本地代理服务在接收到网络请求包之后，可以从应用服务中获取网络请求包真实请求的地址，从而可以将网络请求包封装为应用包后转发给对应的目标服务端。

进一步的，在上述步骤S203之后，本申请实施例提供的应用于代理服务端的透明代理服务方法还可以包括如下步骤：

第一步，代理服务端接收目标服务端根据应用请求包返回的结果数据。

第二步，代理服务端将结果数据转发至客户端。

在上述方案中，代理服务端可以接收目标服务端根据应用请求包返回的结果数据，并将结果转发给客户端，从而通过透明代理服务实现客户端与目标服务端之间的数据交互。

最后，介绍应用于目标服务端的透明代理服务方法。该透明代理服务方法可以包括如下步骤：

第一步，目标服务端接收代理服务端发送的应用请求包。

第二步，目标服务端根据应用请求包生成对应的结果数据。

第三步，目标服务端将结果数据发送给代理服务端。

请参照图3，图3为本申请实施例提供的一种透明代理服务装置的结构框图，该透明代理服务装置300可以应用于代理服务端，具体可以包括：第一接收模块301，用于接收客户端发送的网络请求包；其中，所述客户端中预先配置有与目标服务端对应的代理服务端的IP地址信息；第一转发模块302，用于根据预先配置好的服务端口信息将所述网络请求包转发至本地代理服务，并利用所述本地代理服务将所述网络请求包转换为应用请求包；第二转发模块303，用于根据所述网络请求包中的目标服务端对应的IP地址信息将所述应用请求包转发至所述目标服务端。

在本申请实施例中，可以预先在客户端中配置与目标服务端对应的代理服务端的IP地址信息，以及预先在代理服务端配置好服务端口信息。这样，客户端发送的网络请求包可以基于预先配置好的与目标服务端对应的代理服务端的IP地址信息转发至代理服务端，并基于预先配置好的服务端口信息转发至本地代理服务，从而利用本地代理服务将网络请求包转发至目标服务端。由于客户端发送的网络请求包请求的IP地址可以仍然为目标服务端的IP地址，而不是代理服务端的IP地址，也就是说在代理转发时无需修改请求的IP地址，因此可以提高代理转发的效率。

进一步的，所述第一转发模块302具体用于：利用所述本地代理服务对所述网络请求包进行拆包，并获取所述目标服务端对应的IP地址信息；利用所述本地代理服务对拆包后的网络请求包进行封装，得到所述应用请求包。

在本申请实施例中，应用层的本地代理服务在接收到网络请求包之后，可以从应用服务中获取网络请求包真实请求的地址，从而可以将网络请求包封装为应用包后转发给对应的目标服务端。

进一步的，所述第一转发模块302还用于：利用所述本地代理服务根据预设业务逻辑对所述拆包后的网络请求包进行处理，得到处理后的网络请求包；利用所述本地代理服务对处理后的网络请求包进行封装，得到所述应用请求包。

在本申请实施例中，可以在透明代理服务中实现定制业务逻辑，从而拓展透明代理服务的应用场景。代理服务端可以根据预设的业务逻辑对网络请求包进行处理，并将处理后的网络请求包封装为应用包转发给对应的目标服务端。

进一步的，所述第一转发模块302还用于：利用所述本地代理服务对所述拆包后的网络请求包中的参数进行记录以及修改，得到处理后的网络请求包。

在本申请实施例中，可以在透明代理服务中实现定制业务逻辑，从而拓展透明代理服务的应用场景。代理服务端可以根据预设的业务逻辑对网络请求包中的参数进行记录以及修改，并将记录以及修改后的参数封装为应用包转发给对应的目标服务端。

进一步的，所述透明代理服务装置300还包括：配置模块，用于配置目标端口对应的服务端口信息。

在本申请实施例中，可以预先在客户端中配置与目标服务端对应的代理服务端的IP地址信息，以及预先在代理服务端配置好服务端口信息。这样，客户端发送的网络请求包可以基于预先配置好的与目标服务端对应的代理服务端的IP地址信息转发至代理服务端，并基于预先配置好的服务端口信息转发至本地代理服务，从而利用本地代理服务将网络请求包转发至目标服务端。由于客户端发送的网络请求包请求的IP地址可以仍然为目标服务端的IP地址，而不是代理服务端的IP地址，也就是说在代理转发时无需修改请求的IP地址，因此可以提高代理转发的效率。

进一步的，所述透明代理服务装置300还包括：第二接收模块，用于接收所述目标服务端根据所述应用请求包返回的结果数据；第三转发模块，用于将所述结果数据转发至所述客户端。

在本申请实施例中，代理服务端可以接收目标服务端根据应用请求包返回的结果数据，并将结果转发给客户端，从而通过透明代理服务实现客户端与目标服务端之间的数据交互。

请参照图4，图4为本申请实施例提供的一种电子设备的结构框图，该电子设备400包括：至少一个处理器401，至少一个通信接口402，至少一个存储器403和至少一个通信总线404。其中，通信总线404用于实现这些组件直接的连接通信，通信接口402用于与其他节点设备进行信令或数据的通信，存储器403存储有处理器401可执行的机器可读指令。当电子设备400运行时，处理器401与存储器403之间通过通信总线404通信，机器可读指令被处理器401调用时执行上述透明代理服务方法。

例如，本申请实施例的处理器401通过通信总线404从存储器403读取计算机程序并执行该计算机程序可以实现如下方法：步骤S201：代理服务端接收客户端发送的网络请求包。步骤S202：代理服务端根据预先配置好的服务端口信息将网络请求包转发至本地代理服务，并利用本地代理服务将网络请求包转换为应用请求包。步骤S203：代理服务端根据网络请求包中的目标服务端对应的IP地址信息将应用请求包转发至目标服务端。

处理器401可以是一种集成电路芯片，具有信号处理能力。上述处理器401可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。其可以实现或者执行本申请实施例中公开的各种方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器403可以包括但不限于随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

可以理解，图4所示的结构仅为示意，电子设备400还可包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。于本申请实施例中，电子设备400可以是，但不限于台式机、笔记本电脑、智能手机、智能穿戴设备、车载设备等实体设备，还可以是虚拟机等虚拟设备。另外，电子设备400也不一定是单台设备，还可以是多台设备的组合，例如服务器集群，等等。

本申请实施例还提供一种计算机程序产品，包括存储在非暂态计算机可读存储介质上的计算机程序，计算机程序包括程序指令，当程序指令被计算机执行时，计算机能够执行上述实施例中透明代理服务方法的步骤，例如包括：接收客户端发送的网络请求包；其中，所述客户端中预先配置有与目标服务端对应的代理服务端的IP地址信息；根据预先配置好的服务端口信息将所述网络请求包转发至本地代理服务，并利用所述本地代理服务将所述网络请求包转换为应用请求包；根据所述网络请求包中的目标服务端对应的IP地址信息将所述应用请求包转发至所述目标服务端。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

需要说明的是，功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。