【
技术领域：
：】本发明涉及网络通信技
技术领域：
：，特别是涉及一种http转https双向透明代理的方法和装置。
背景技术：
：：随着网络环境的日益复杂，各种代理技术应运而生。从代理的协议层面可以划分为http代理、ssl代理、ftp代理、邮件代理、tcp代理等；从代理服务器位置上，可以划分为正向代理和反向代理；从是否能被感知的角度可以分为透明代理和非透明代理。透明代理又可以分为客户端透明和服务器端透明，客户端透明就是指被代理的用户不需要做任何配置，自己的流量就会被动的接受代理，整个过程用户无感知；服务器端透明指的是，用户访问的目的服务器不会感觉到访问的流量是经过代理服务器的，服务器看到的ip地址是用户的ip地址，而不是中间代理服务器的ip地址。双向透明代理指的是终端用户以及服务器端都不会感受到代理服务器的存在，终端用户不需要做任何代理相关的配置，访问的目标ip也是服务器的真实ip地址，而不是代理服务器的ip；服务器端看到的访问ip地址也是真实的终端用户的ip地址，而不是代理服务器的ip地址。在整个的流量传输过程中，并不会出现中间代理服务器的ip地址，虽然流量经过了代理服务器的处理，但是双方都感知不到流量被代理了，这就是双向透明代理的含义所在。为了实现透明代理，首先需要用户访问服务器的流量要经过代理服务器，也就是说代理服务器部署的位置一定是在终端用户和服务器之间，而且能够访问到它们之间的通信流量。其次需要对报文的转发做一些特殊处理，默认情况下报文只会流向目的ip地址的节点，对于代理服务器来说，由于自身并不是用户要访问的服务器，报文虽然经过代理服务器，但是不会向应用层传递，应用层也没有对应的socket来处理。既然是做代理，那么必须要对报文的路由做一些控制，使本该转发给目标服务器的报文，继续向应用层传递，进而得到处理。另外一个关键的技术是要实现双向透明，即在整个通信过程中要隐藏代理服务器的ip地址，全程只出现终端用户的ip地址和服务器的ip地址。区分各种不同的透明代理服务器，核心就是要区分使用何种技术做的报文路由，使用何种技术实现的ip地址透明。传统的透明代理技术，主要有两种路线：第一种方法是通过修改报文ip地址的方式来实现透明；因为修改了目标ip地址，所以代理路由器的路由系统会把此报文路由到自身，而不是转发走，报文进而就会经过tcp/tp协议栈处理，到达应用层做代理。具体而言，对于到达代理服务器的报文，修改目的ip和目的端口为代理服务器的ip地址和socket端口；对于离开代理服务器的报文，把源ip和源端口从代理服务器的ip地址和端口根据连接的不同类型修改为客户端或者服务器的ip地址和端口。第二种方法是不做ip地址转换，而是使用linux内核的tproxy特性，tproxy是透明代理的简称，它可以不对ip地址做任何变更，就可以实现双向透明代理。目前使用tproxy技术实现的透明代理系统一般都是使用虚拟网桥设备来连接两个或者多个物理网卡，其中一个网卡是上行网口，接客户端流量；另外一个网卡是下行网口，接服务器端流量。透明代理系统，需要把应用层代理程序产生的报文投递到网络上，使用linux网桥设备的透明代理系统，需要给网桥设备配置ip地址，并配置正确的网关地址和路由表，才能实现正确的报文转发。此时往往需要给网桥设备配置有一个ip地址来参与到基于ip地址的路由中来，在某些网络组网环境复杂的情况下，给网桥设备配置ip地址并配置相关的路由表，是非常繁琐的事情，而且很容易出错。鉴于此，克服该现有技术所存在的缺陷是本
技术领域：
：亟待解决的问题。技术实现要素：本发明要解决的技术问题是现有的透明代理系统，需要把应用层代理程序产生的报文投递到网络上，使用linux网桥设备的透明代理系统，需要给网桥设备配置ip地址，并配置正确的网关地址和路由表，才能实现正确的报文转发。此时往往需要给网桥设备配置有一个ip地址来参与到基于ip地址的路由中来，在某些网络组网环境复杂的情况下，给网桥设备配置ip地址并配置相关的路由表，是非常繁琐的事情，而且很容易出错。本发明采用如下技术方案：第一方面，本发明提供了一种http转https双向透明代理的方法，包括：代理系统收到客户端发送的第一http请求后，解析http头部字段，获得host字段，把host字段和内置的域名列表进行比对，并存储所述第一http请求内容；其中，所述域名列表，用于存储满足https重定向的域名；若发现host域名在列表中，代理系统向服务器发起目标端口为443的tcp握手，以便建立第一tcp通道和通过所述第一tcp通道进行tls协商过程；其中，所述tcp握手中使用的客户端的ip地址；代理系统通过tls协商建立的第一tls通道，向服务器发送第一https请求；其中，所述第一https请求中携带所述第一http请求内容经过加密后的内容；代理系统接收服务器返回的第一https响应，代理系统删除第一https响应的http头部字段中cookie字段的secure属性，以及hsts中包含的strict-transport-security字段后，并将第一https响应内容解密为明文后，透传给客户端。优选的，若发现host域名不在列表中，所述方法还包括：代理系统向服务器发起目标端口为80的tcp握手，以便建立第二tcp通道；代理系统通过所述第二tcp通道，向服务器发送第二http请求，所述第二http请求中携带所述第一http请求内容；代理系统接收服务器返回的第二http响应，并检查所述第二http响应是否是https重定向；若发现是https重定向，则代理系统把host加入域名列表中，并丢弃掉所述第二http响应，同时向服务器发送tcpreset报文，关闭所述第一tcp通道。优选的，所述方法还包括：代理系统向服务器发起目标端口为443的tcp握手，以便建立第二tcp通道和通过所述第二tcp通道进行tls协商过程；其中，所述tcp握手中使用的客户端的ip地址；代理系统通过tls协商建立的第二tls通道，向服务器发送第二https请求；其中，所述第二https请求中携带所述第二http请求内容经过加密后的内容；代理系统接收服务器返回的第二https响应，代理系统删除第二https响应的http头部字段中cookie字段的secure属性，以及hsts中包含的strict-transport-security字段后，并将第二https响应内容解密为明文后，透传给客户端。优选的，检查所述第二http响应是否是https重定向，具体包括：检查所述第二http响应的状态码是否在300～399之间，并且，检查重定向的目标地址是原来host的https版本；其中，根据http协议规范，此区间的响应状态码表示重定向。优选的，若发现不是https重定向，所述方法还包括：代理系统将接收到的第二http响应透传给所述客户端。优选的，代理系统包括：数据包收发模块、虚拟网卡模块、数据包路由模块、代理程序模块，具体的：数据包收发模块，用于底层的报文收发，由数据包接收模块和数据包发送模块组成，数据包接收模块负责从物理网卡接收数据包，转发到虚拟网卡上；虚拟网卡模块为工作在传输层的标准的tun虚拟网卡，用于将收到的ip数据包经由操作系统的协议栈进行解析；数据包路由模块，用于将目标报文路由到代理程序模块去处理，数据包路由模块中包括iptables规则配置和策略路由配置。优选的，所述代理程序模块工作在操作系统的应用层，并且支持tproxy机制，具体的：在socket属性上设置ip_transparent参数，使得接受任意目的ip地址的socket连接，同时也可以以任意ip地址为源ip产生数据报文，从而使socket可以绑定任意ip地址。优选的，方法还包括：在iptables规则中添加第一规则：iptables-tmangle-aprerouting-ptcp--dport80-jtproxy--tproxy-mark0x1/0x1--on-port0；所述第一规则表示，把传输协议是tcp，目的端口是80的报文，打上标签值1；在iptables规则中添加第二规则：iptables-tmangle-aprerouting-ptcp--sport443-jmark--set-mark1；所述第二规则表示，把传输协议是tcp，源端口是443的报文，打上标签值1；在iptables规则中添加第三规则：iptables-tmangle-aoutput-ptcp--dport443-jmark--set-mark2；所述第三规则表示，把传输协议是tcp，目的端口是443的报文，打上标签值2；在iptables规则中添加第四规则：iptables-tmangle-aoutput-ptcp--sport80-jmark--set-mark2；所述第四规则表示，把传输协议是tcp，源端口是80的报文，打上标签值2。优选的，方法还包括策略路由配置，具体的：将带有标签值1的报文查询路由表100：ipruleaddfwmark1lookup100；建立编号为100的路由表，设置内容为从代理系统的虚拟网卡路由到代理系统的应用层：iprouteaddlocal0.0.0.0/0devlotable100；配置带有标签值2的报文查询路由表200：ipruleaddfwmark0x2table200；建立号为200的路由表，让报文通过虚拟网卡tun1去发送：iprouteadddefaultvia10.0.0.2devtun1table200。第二方面，本发明还提供了一种http转https双向透明代理的装置，用于实现第一方面所述的http转https双向透明代理的方法，所述装置包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述处理器执行，用于执行第一方面所述的http转https双向透明代理的方法。第三方面，本发明还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个处理器执行，用于完成第一方面所述的http转https双向透明代理的方法。本发明实现了一种针对http转https的双向的透明代理方法和装置，在数据链路层，由程序直接控制报文接收和发送，不改变原始报文的mac地址，在数据链路层对上下游的路由设备实现了双向透明；在ip传输层，可以通过结合虚拟网卡技术和tproxy技术，不改变源ip地址和目的ip地址，实现了客户端方向和服务器方向的双向透明；在应用层上，实现了http转https代理，代理系统和客户端维持一个http连接，同时和服务器端维持一个https连接，实现了应用层的双向透明代理。【附图说明】为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是本发明实施例提供的一种http转https双向透明代理的系统整体架构图；图2是本发明实施例提供的一种报文在代理系统内部的流向示意图；图3是本发明实施例提供的一种http转https双向透明代理的方法流程示意图；图4是本发明实施例提供的一种http转https双向透明代理的方法流程示意图；图5是本发明实施例提供的一种http转https双向透明代理的方法流程示意图；图6是本发明实施例提供的一种数据包接收模块的处理方法流程示意图；图7是本发明实施例提供的一种数据包发送模块的处理方法流程示意图；图8是本发明实施例提供的一种配置流程的处理方法流程示意图；图9是本发明实施例提供的一种代理系统整体工作流程；图10是本发明实施例提供的一种交互流程a的信令图；图11是本发明实施例提供的一种交互流程b的信令图；图12是本发明实施例提供的一种交互流程c的信令图；图13是本发明实施例提供的一种服务器发送给客户端的原始的http响应头部字段内容示意图；图14是本发明实施例提供的一种表示被代理系统修改后的http响应头部内容示意图；图15是本发明实施例提供的一种http转https双向透明代理的装置结构示意图。【具体实施方式】为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。在本发明的描述中，术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作，因此不应当理解为对本发明的限制。本发明中使用的透明代理搭建方法，没有使用ip地址修改，也没有采用网桥设备，而是采用直接从底层读取网卡的数据包，然后结合虚拟网卡技术对数据包进行代理。此方法的特点是，使用程序直接控制数据报文的网卡收发，而不再依赖于操作系统对报文进行路由。这样的好处有两个：一是避免了大量的路由配置工作，如对网桥配置ip地址，配置操作系统路由表，配置网桥默认网关地址，在操作系统中配置默认网关的arp地址等等；二是避免了获取当前代理系统上下游路由节点的相关地址信息，代理系统不需要提前知道数据报文路由的下一跳节点的ip地址和mac地址，因为代理系统内部保留了原始报文的mac地址，在接收和发送报文时，并不会修改原始报文的mac地址，代理系统对于上下游的路由设备来说是透明的，这样一来使得代理系统可以方便的嵌入到复杂的网络环境中。传统针对https的代理，一般只是做tcp层的数据中转，在https客户端和https服务器之间单纯的做数据转发。之所以会这样，是因为https本身是可以防止中间人进行数据修改的，在没有合法证书的情况下，如果中间人对https流量进行代理，会导致https客户端报错，比如典型的https客户端是浏览器，浏览器会对终端用户进行报警，警告用户流量可能受到劫持。为了应对https流量难以解密和代理的问题，本发明提出了一种http转https代理，绕过了https对客户端流量加密的过程，解决了https代理下，客户端端浏览器会由于不信任代理系统的证书而产生的证书告警问题。本发明实现了一种针对http转https的双向的透明代理系统，在数据链路层，由程序直接控制报文接收和发送，不改变原始报文的mac地址，在数据链路层对上下游的路由设备实现了双向透明；在ip传输层，结合虚拟网卡技术和tproxy技术，不改变源ip地址和目的ip地址，实现了客户端方向和服务器方向的双向透明；在应用层上，实现了http转https代理，代理系统和客户端维持一个http连接，同时和服务器端维持一个https连接，实现了应用层的双向透明代理。具体技术方案包含两部分，第一部分是透明代理技术的底层实现，包括报文收发和实现ip地址透明；第二部分是代理系统如何和客户端、服务器端进行报文交互。透明代理底层实现：整体角色分为三类，客户端、代理系统和服务器。代理系统同时维护了两个连接，一个是和客户端建立的连接，一个是和服务器建立的连接，代理系统在两个连接之间中转数据。如图1所示，代理系统整体上分为四大模块，一是数据包收发模块，二是虚拟网卡模块，三是数据包路由模块，四是代理系统模块。数据包收发模块主要是负责底层的报文收发，它由数据包接收模块和数据包发送模块组成，数据包接收模块负责从网卡接收数据包，并且转发到虚拟网卡设备上；虚拟网卡模块是一个工作在传输层的标准的tun虚拟网卡，它主要负责让收到的ip数据包进入操作系统的协议栈进行解析；数据包路由模块主要负责把目标报文路由到代理程序模块去处理，具体包括iptables规则配置，策略路由配置等。默认情况下，操作系统见到目的ip地址不是自身ip的数据包，是不会传递给应用层的，而是丢弃或者转发，由于数据包路由模块配置了本发明定制的路由规则，使得任意目的ip地址的数据包都可以投递到应用层的代理程序模块去处理，这里主要使用了tproxy技术。代理程序模块工作在操作系统的应用层，是一个应用程序，它为了能够处理任意目的ip地址的报文，也就是支持tproxy机制，在socket属性上设置了ip_transparent参数，这样就可以接受任意目的ip地址的socket连接，同时也可以以任意ip地址为源ip产生数据报文，也就是使socket可以绑定任意ip地址。数据包在代理系统内部的流向如图2所示，代理程序模块工作在应用层，它同时和客户端、服务器维持了两个socket连接，编号为1，2，3，4，5，6的几条线所组成的流向代表了代理系统和客户端维持的连接，编号为7，8，9，10，11，12的几条线所组成的流向代表了代理系统和服务器端维持的连接，编号为13的线条，表示非http的流量，不会投递到应用层去处理，而是由网卡直接转发出去。数据包收发模块负责处理的流量是编号为2,5,8,11,13这些流量报文，具体来说，数据包接收模块负责处理编号2,11,13所代表的流量报文，数据包发送模块负责处理编号5，8所代表的流量报文；数据包路由模块负责处理编号为3,4,7,12所代理的流量报文。代理程序模块的报文处理流程：本发明中的http转https代理，本质上是实现了一个http重定向跳转劫持。现代网站逐渐采用https保护传输内容不被修改，但是为了兼容用户默认访问的http流量，一般会同时保留80端口的http服务，当用户访问80端口的http服务时，会利用http协议的重定向机制，向用户发送301/302重定向命令，把用户导向对应的https服务上面，用户的http客户端收到重定向之后，会按照http协议的规范去访问重定向之后的https服务。本发明实现的http转https代理功能，本质上就是利用并劫持了这个重定向机制。代理程序模块对客户端和服务器的报文转发和交互流程：当客户端发起一个http请求时，本发明的代理系统先对目标域名进行探测，具体探测过程是向对应域名发起http请求，并查看http响应状态码是否是301/302等重定向状态码，如果是重定向，而且重定向之后的网址是网址的https版本，那就说明域名满足https重定向条件，就向对应的域名发起https请求，并把返回的https的响应内容，以http通道传递给客户端。通过这样操作，代理系统和客户端维持一个http连接，但是和服务器维持一个https连接，成功的劫持了客户端的302重定向动作，使客户端始终不能升级到https连接。如果探测的结果是目标域名不满足https重定向条件，那么代理系统就同时和客户端、服务器都使用http通道通信，在二者之间中转数据，此时就工作在http代理模式下。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。实施例1:本发明实施例1提供了一种http转https双向透明代理的方法，如图3所示，包括：在步骤101中，代理系统收到客户端发送的第一http请求后，解析http头部字段，获得host字段，把host字段和内置的域名列表进行比对，并存储所述第一http请求内容；其中，所述域名列表，用于存储满足https重定向的域名。在步骤102中，若发现host域名在列表中，代理系统向服务器发起目标端口为443的tcp握手，以便建立第一tcp通道和通过所述第一tcp通道进行tls协商过程；其中，所述tcp握手中使用的客户端的ip地址；其中，所述tls协商过程包括：协商加密套件、传递证书、校验证书和计算秘钥中的一项或者多项过程。在步骤103中，代理系统通过tls协商建立的第一tls通道，向服务器发送第一https请求(在本发明其他实施例中也被表述为http请求，此处是为了直观的表现技术特性，因此描述为https请求)；其中，所述第一https请求中携带所述第一http请求内容经过加密后的内容。在步骤104中，代理系统接收服务器返回的第一https响应，代理系统删除第一https响应的http头部字段中cookie字段的secure属性，以及hsts中包含的strict-transport-security字段后，并将第一https响应内容解密为明文后，透传给客户端。本发明实施例实现了一种针对http转https的双向的透明代理方法，在数据链路层，由程序直接控制报文接收和发送，不改变原始报文的mac地址，在数据链路层对上下游的路由设备实现了双向透明；在ip传输层，可以通过结合虚拟网卡技术和tproxy技术，不改变源ip地址和目的ip地址，实现了客户端方向和服务器方向的双向透明；在应用层上，实现了http转https代理，代理系统和客户端维持一个http连接，同时和服务器端维持一个https连接，实现了应用层的双向透明代理。结合本发明实施例，还存在一种扩展实现方案，作为实施例1中步骤102的并列可选情况，若发现host域名不在列表中，如图4所示，所述方法还包括：在步骤105中，代理系统向服务器发起目标端口为80的tcp握手，以便建立第二tcp通道。在步骤106中，代理系统通过所述第二tcp通道，向服务器发送第二http请求，所述第二http请求中携带所述第一http请求内容。在步骤107中，代理系统接收服务器返回的第二http响应，并检查所述第二http响应是否是https重定向。其中，检查所述第二http响应是否是https重定向，具体包括：检查所述第二http响应的状态码是否在300～399之间(因为重定向功能本身不仅仅是做https重定向，而是可以进行任意url重定向，https重定向只是其中的一种应用)，并且，检查重定向的目标地址是原来host的https版本；其中，根据http协议规范，此区间的响应状态码表示重定向。在步骤108中，若发现是https重定向，则代理系统把host加入域名列表中，并丢弃掉所述第二http响应，同时向服务器发送tcpreset报文，关闭所述第一tcp通道。结合本发明实施例，还存在一种扩展实现方案，如图5所示，在执行完上述步骤108之后，优选的，所述方法还包括：在步骤109中，代理系统向服务器发起目标端口为443的tcp握手，以便建立第二tcp通道和通过所述第二tcp通道进行tls协商过程；其中，所述tcp握手中使用的客户端的ip地址，其中，所述tls协商过程包括：协商加密套件、传递证书、校验证书和计算秘钥中的一项或者多项过程。在步骤110中，代理系统通过tls协商建立的第二tls通道，向服务器发送第二https请求；其中，所述第二https请求中携带所述第二http请求内容经过加密后的内容；在步骤111中，代理系统接收服务器返回的第二https响应，代理系统删除第二https响应的http头部字段中cookie字段的secure属性，以及hsts中包含的strict-transport-security字段后，并将第二https响应内容解密为明文后，透传给客户端。作为完整技术方案实现考虑，若在上述步骤108中判定结果是另一种情况，则相应的技术方案实现内容表现为：若发现不是https重定向，所述方法还包括：代理系统将接收到的第二http响应透传给所述客户端。在本发明实施例中，还提出了一种优选的代理系统框架结构，如图2所示，包括：数据包收发模块、虚拟网卡模块、数据包路由模块、代理程序模块，具体的：数据包收发模块，用于底层的报文收发，由数据包接收模块和数据包发送模块组成，数据包接收模块负责从物理网卡接收数据包，转发到虚拟网卡上；虚拟网卡模块为工作在传输层的标准的tun虚拟网卡，用于将收到的ip数据包经由操作系统的协议栈进行解析；数据包路由模块，用于将目标报文路由到代理程序模块去处理，数据包路由模块中包括iptables规则配置和策略路由配置。默认情况下，操作系统见到目的ip地址不是自身ip的数据包，是不会传递给应用层的，而是丢弃或者转发，由于数据包路由模块配置了特殊的路由规则，使得任意目的ip地址的数据包都可以投递到应用层的代理程序模块去处理，这里主要使用了tproxy技术。所述代理程序模块工作在操作系统的应用层，并且支持tproxy机制，具体的：在socket属性上设置ip_transparent参数，使得接受任意目的ip地址的socket连接，同时也可以以任意ip地址为源ip产生数据报文，从而使socket可以绑定任意ip地址。作为支撑本发明实施例1相关方法步骤实现的底层机制要素，方法还包括：在iptables规则中添加第一规则：iptables-tmangle-aprerouting-ptcp--dport80-jtproxy--tproxy-mark0x1/0x1--on-port0；所述第一规则表示，把传输协议是tcp，目的端口是80的报文，打上标签值1；在iptables规则中添加第二规则：iptables-tmangle-aprerouting-ptcp--sport443-jmark--set-mark1；所述第二规则表示，把传输协议是tcp，源端口是443的报文，打上标签值1；在iptables规则中添加第三规则：iptables-tmangle-aoutput-ptcp--dport443-jmark--set-mark2；所述第三规则表示，把传输协议是tcp，目的端口是443的报文，打上标签值2；在iptables规则中添加第四规则：iptables-tmangle-aoutput-ptcp--sport80-jmark--set-mark2；所述第四规则表示，把传输协议是tcp，源端口是80的报文，打上标签值2。配套上述的iptables规则，还需要对9应的策略路由配置来实现，具体的：将带有标签值1的报文查询路由表100(此处的路由表100仅仅是为了方便下面的指令的呈现，在实际使用过程中，所述100还可以被表述为其他自定义的字符串，因此，不应将其作为本发明保护范围的特殊限定)：ipruleaddfwmark1lookup100；建立编号为100的路由表，设置内容为从代理系统的虚拟网卡路由到代理系统的应用层：iprouteaddlocal0.0.0.0/0devlotable100；配置带有标签值2的报文查询路由表200：ipruleaddfwmark0x2table200；建立号为200的路由表，让报文通过虚拟网卡tun1(实际还可以是其他编号的虚拟网卡，例如tun2，tun5等等，在此不做特殊限定)去发送：iprouteadddefaultvia10.0.0.2devtun1table200。接下来，本发明将通过多个实施例来将本发明中涉及的代理系统中的主要功能模块的方法执行过程进行逐一阐述，在相应的实施例中将不再延续本发明实施例1中的第一、第二表述，需要指出的是，在本发明实施例中所使用的第一、第二、第三前缀，仅仅是为了引述过程中更清楚的区别对象而使用，并不具备特殊的限定意义，而接下来的实施例则可以通过上下文的表述即便不增加第一、第二的标定也能够与本发明实施例中所涉及的相关对象进行关联，在此和后续内容不再一一赘述。实施例2：数据包接收模块的工作流程如图6所示：在s121步骤中，从物理网卡接收报文，此步骤中的网卡同时包括上行网卡和下行网卡，此时程序接收报文并不依赖于操作系统对报文的解析和处理，而是直接从网卡读取报文，此时报文包含以太网头部，ip头部等，是一个完整的报文。在s122步骤中，解析报文，此步骤是对报文进行解析，获取报文的源mac地址，源ip地址，源端口，目的mac地址，目的ip地址，目的端口，同时记录下ip地址和mac地址的对应关系，存储到ip-mac对应表中。在s123步骤中，检查报文是否是目标报文，此步骤的检查条件有两个，一是检查目的端口是否是tcp的80端口，二是检查源端口是否是tcp的443端口，这两个条件是或的关系，换句话说只要有一个条件命中了，此报文就属于目标报文。在s124步骤中，剥除以太网头部，此步骤是把s123步骤中命中的报文的以太网头部剥离掉，只保留ip头部以上的数据部分。在s125步骤中，发送到虚拟网卡，此步骤是把s124步骤中产生的ip数据报文，投递到虚拟网卡设备上。在s126步骤中，发送到对端物理网卡，是指把在s123步骤中没有命中的报文，直接投递给对端的物理网卡。这里对端物理网卡，是指如果报文从上行网卡接收，那么就从下行网卡转出；反之如果报文从下行网卡接收，那么就从上行网卡转出。实施例3：数据包接收模块的工作流程如图7所示：在s131步骤中，从虚拟网卡接收报文，此步骤是指从虚拟网卡设备上读取报文，此时的虚拟网卡是指tun类型的网卡，接收到的报文是带ip头部的ip数据报文，没有以太网头部。在s132步骤中，添加以太网头部，此步骤是指为ip数据报文添加以太网头部，包括源mac和目的mac地址。添加的原则就是，查询数据包接收模块生成的ip-mac对应表，设置源mac为源ip对应的mac地址，设置目的mac为目的ip对应的mac地址。在s133步骤中，检测目标端口是否是443端口，如果报文的目标端口是tcp的443端口，那么就满足判断条件。在s134步骤中，发送到物理网卡-下行口，此步骤是把补全以太网头部的以太网数据报文，发送到下行口的物理网卡上。在s135步骤中，发送到物理网卡-上行口，此步骤是把补全以太网头部的以太网数据报文，发送到上行口的物理网卡上。实施例4：虚拟网卡和路由配置模块，配置过程涉及到路由转发配置，虚拟网卡配置，iptables规则配置，策略路由配置等几个方面，如图8所示。s141是路由转发配置，目的是开启linux系统的路由转发功能。默认情况下，操作系统见到目的ip地址不是自身ip地址的数据报文，会丢弃掉；如果开启了路由转发功能，那么操作系统对目的ip地址不是自身ip的数据包是会做转发处理，而不是丢弃掉，此时相当于操作系统对数据报文做了路由处理。开启路由转发的方法比较简单，可以通过命令的方式进行配置，也可以通过写配置文件的方式进行配置，不同的linux系统发行版本可能网络配置文件的名称和位置也不相同。通过命令行来配置的命令如下：sysctl-wnet.ipv4.ip_forward＝1；s142是虚拟网卡配置，目的是生成一个虚拟网卡，用来接收ip分组报文，使得ip分组进入本机的协议栈进行处理。典型的配置方法如下：首先创建一个tun类型的虚拟网卡设备，命名此设备为tun5:iptuntapaddmodetuntun5；激活此虚拟网卡：iplinksettun5up；为此虚拟网卡添加ip地址：ipaddradd10.0.0.2/24devtun5；这里的虚拟网卡ip地址不会影响整体代理系统的功能，可以任意设置。s143是iptables规则配置，此部分主要目的是给目标数据包打标签。目标数据包包含两部分，第一部分是图2中3号线条和12号线条所代表的流量，第二部分是图2中4号线条和7号线条所代表的流量。给3号线条和12号线条所代表的流量打标签，是为了使目的地址不是本机ip地址的报文可以路由到本机的应用层去处理，而不是被转发走；给4号线条和7号线条所代表的流量打标签，是因为这部分流量查询默认的路由表，是会被路由到物理网卡上的，本发明为了使它路由到虚拟网卡上，所以也打上标签。第一类规则，是为了给图2中3号线条和12号线条所代表的流量打标签，典型的配置方法如下，使用iptables工具添加如下规则：iptables-tmangle-aprerouting-ptcp--dport80-jtproxy--tproxy-mark0x1/0x1--on-port0；这条规则表示，把传输协议是tcp，目的端口是80的报文，打上标签值1，向应用层投递到端口为80的程序去处理，此部分流量匹配的是图2中3号线条所代表的流量。iptables-tmangle-aprerouting-ptcp--sport443-jmark--set-mark1；这条规则表示，把传输协议是tcp，源端口是443的报文，打上标签值1，此部分流量匹配的是图2中12号线条所代表的流量。第二类规则是为了给图2中4号线条和7号线条所代表的流量打标签：iptables-tmangle-aoutput-ptcp--dport443-jmark--set-mark2；iptables-tmangle-aoutput-ptcp--sport80-jmark--set-mark2；s144是策略路由配置，这部分是为了和iptables规则配合使用。主要包含两部分，一是让虚拟网卡的报文可以投递给应用层程序处理，即图2中3号线条和12号线条所代表的流量报文会匹配到这条策略路由；二是让应用程序产生的报文可以投递给虚拟网卡，而不是物理网卡，图2中4号线条和7号线条所代表的流量报文会匹配到这条策略路由。具体配置方法如下，让带有标签值1的报文查询路由表100：ipruleaddfwmark1lookup100；建立编号为100的路由表，设置内容为路由到应用层：iprouteaddlocal0.0.0.0/0devlotable100；配置带有标签值2的报文查询路由表200：ipruleaddfwmark0x2table200；建立号为200的路由表，让报文通过虚拟网卡tun5去发送：iprouteadddefaultvia10.0.0.2devtun5table200。实施例5：图9是代理程序模块对报文的处理过程，代理程序模块同时和客户端、服务器保持http或者https连接，在客户端和服务器之间中转数据。角色：c：client，表示客户端，典型的http客户端是浏览器；p：proxy，表示代理系统；s：server，表示服务器端，典型的http服务器端如访问的各种网站；交互方向：->表示单方向发送报文；<->表示双方相互发送和接收报文；名称解释：tcp：transmissioncontrolprotocol，传输控制协议；http：hypertexttransferprotocol,超文本传输协议；tls：transportlayersecurity，安全传输层协议；hsts：httpstricttransportsecurity,http严格安全传输；tcp握手：是指tcp协议中双方建立连接时，需要执行的三次握手过程；tls握手：是指tls协议中，客户端和服务器端建立tls连接的协商过程，此过程有多个报文交互；httpget：是指http协议中，客户端发起的资源请求；httpresponse:指http协议中，服务器端回复客户端的响应内容；host:是指http请求报文中的一个http头部字段，它的值就是访问的目标域名；如图9所示，代理系统和客户端、服务器的报文交互过程如下：在s201步骤中，客户端和代理系统发起tcp握手，建立tcp连接，目标端口是80端口。在客户端看来，是在和服务器进行tcp连接，但是因为此时的流量已经被路由给代理系统，所以实际上客户端是和代理系统建立了tcp连接。在s202步骤中，客户端向代理系统发起http请求，此时的http是明文请求，目标端口是80端口。在客户端看来，是在向服务器发起http请求，因为此时的流量已经被路由给代理系统，所以实际上客户端是把请求发给了代理系统。在s203步骤中，代理系统受到客户端发送的http请求后，解析http头部字段，获得host字段，并把host字段和内置的域名列表进行比对；这里的域名列表，是指所有满足https重定向的域名，如果一个域名在此列表职工，说明之前已经对此域名进行过https重定向探测，而且此域名会进行https重定向。如果发现host域名在列表中，则进入s204步骤；否则进入s210步骤。在s204步骤中，代理系统向服务器发起tcp握手，目标端口443；此时服务器看到的ip地址就是客户端的ip地址，不会发现代理系统的存在。在s205步骤中，代理系统和服务器进行tls协商过程，此协商过程是基于s204中建立的tcp通道的；tls协商过程，会有多个报文交互，这个过程中，双方会完成协商加密套件，传递证书，校验证书，计算秘钥等工作。在s206步骤中，代理系统向服务器发送http请求，此请求是基于s205步骤中建立的tls通道的，此http请求是一个加密的请求，具体的请求内容是从s202步骤中获取的；在s207步骤中，服务器回复给代理系统http响应内容，此http响应是基于s205步骤中建立的tls通道的，是经过加密的，不是明文的。在s208步骤中，处理http响应。代理系统收到服务器回复的http响应之后，需要对响应内容进行处理，才能发送给客户端。这里之所以要处理http响应，是因为要进行https到http的适配。http头部字段中有些字段的属性涉及到了https传输方式，典型的有两个字段，一是cookie字段的secure属性，此属性表示此cookie只能在https通道中传输，不能在http通道中传输；如果不删除这个属性，会导致此cookie不会在http这种明文传输通道进行传送，会引起各种服务器鉴权问题；二是hsts，hsts的作用是强制客户端使用https与服务器创建连接，hsts的设置方法是在http响应头中包含strict-transport-security字段。http协议规定，非加密传输时设置的hsts字段无效，但是出现在http明文传输通道中的hsts字段会引起客户端的怀疑，所以要删除掉这个字段。在s209步骤中，代理系统向客户端返回http响应，此时的http响应内容，可能是经过s208步骤适配过的，也可能是没有改动过的；如果是从s213步骤来到此步骤，则不需要对http响应内容进行修改。在s210步骤中，代理系统向服务器发起tcp握手，目标端口是80端口。在s211步骤中，代理系统向服务器发送http请求，此请求是基于s210步骤中建立的tcp通道的，此http请求是一个明文的请求，具体的请求内容是从s202步骤中获取的。在s212步骤中，服务器回复给代理系统http响应内容，此http响应是基于s210步骤中建立的tcp通道的，是明文传输的。在s213步骤中，检查http响应是否是https重定向。此步骤主要检查s212步骤中获取的http响应内容，一是检查http响应的状态码是否在300～399之间，根据http协议规范，此区间的响应状态码表示重定向；二是检查重定向的目标地址是否是原来host的https版本，因为重定向功能本身不仅仅是做https重定向，而是可以进行任意url重定向，https重定向只是其中的一种应用。检查后如果发现是https重定向，那么就跳转到s214步骤，否则跳转到s209。在s214步骤中，代理系统和服务器断开tcp连接。代理系统此时发现http响应内容是https重定向，此时代理系统并不去转发此响应给客户端，而是丢弃掉此http响应，同时向服务器发送tcpreset报文，关闭tcp通道；在s215步骤中，把host加入域名列表中。此时，代理系统已经完成了对目标域名的探测，得知目标域名满足https重定向的条件，所以加入域名列表，下次代理系统处理此域名时，直接进行代理即可，不需要重复探测；所有经过代理系统的流量按照不同的情况，可以分为3种交互流程：第一种、交互流程a：http代理模式，即代理系统和客户端使用http连接，和服务器端也使用http连接；代理系统先对服务器进行探测，发现服务器不满足https重定向条件，进而转到http代理模式；第二种、交互流程b：http转https代理模式，即代理系统和客户端使用http连接，和服务器之间使用https连接；代理系统之前对此域名进行过探测，发现它满足https重定向条件，直接进行https代理；第三种、交互流程c：http转https代理模式，叠加初始探测流程；代理系统先对服务器进行探测，发现服务器满足https重定向条件，进而转到https代理；当代理系统使用交互流程a时，工作步骤是s201，s202，s203，s210，s211，s212，s213，s209，报文的交互流程如图10所示。假设客户端使用的ip地址为1.1.1.1，端口为1024；服务器端的ip地址为2.2.2.2，端口为80；代理系统本身的ip地址为3.3.3.3。客户端和代理系统之间的连接使用的ip地址是1.1.1.1和2.2.2.2，端口是1024和80，此时代理系统假装自己是服务器来和客户端建立连接。代理系统和服务器之间的连接使用的ip地址是1.1.1.1和2.2.2.2，端口是2000和80，此时代理系统假装自己是客户端来和服务器建立连接。可以看到在整个通信过程中，不会出现代理系统的自身ip地址，只有源端口发生了改变，因为源端口是随机选择的，所以即使改变了源端口，代理系统仍然是一个双向透明代理系统。经过代理系统后，报文的mac地址，ip地址，http报文内容等是保持不变的，发生改变的是tcp协议的源端口字段。当代理系统使用交互流程b时，工作步骤是s201，s202，s203，s204，s205，s206，s207，s208，s209，报文的交互流程如图11所示。假设客户端使用的ip地址为1.1.1.1，端口为1024；服务器端的ip地址为2.2.2.2，端口为80和443；代理系统本身的ip地址为3.3.3.3。当客户端向服务器发起http访问时，代理系统会使用2.2.2.2的ip地址和80端口和客户端建立起一个http连接，同时代理系统使用1.1.1.1的ip地址和一个随机源端口和真实服务器建立一个https连接。在整个通信过程中，客户端和代理系统之间是一个http连接；代理系统和服务器之间是一个https连接，此连接是一个可信的连接，因为这时代理系统是作为客户端在使用，证书是服务器的证书，是可信的证书。在整个通信过程中，不会出现代理系统的自身ip地址，只有源端口发生了改变，因为源端口是客户端随机选择的，所以即使改变了源端口，代理系统仍然是一个双向透明代理系统。经过代理系统后，报文的mac地址，ip地址是保持不变的，发生改变的是tcp协议的源端口字段，还有就是http协议变成了https协议，可能发生变化的是http头部字段。如图13所示，表示服务器发送给客户端的原始的http响应头部字段；请注意，里面有一个strict-transport-security头部字段，另外就是set-cookie字段对cookie设置了一个secure的属性。如图14所示，表示被代理系统修改后的http响应头部；代理系统删除了cookie的secure属性，同时删除了strict-transport-security头部字段。当代理系统使用交互流程c时，工作步骤是s201，s202，s203，s210，s211，s212，s213，s214，s215，s204，s205，s206，s207，s208，s209，报文的交互流程如图12所示。假设客户端使用的ip地址为1.1.1.1，端口为1024；服务器端的ip地址为2.2.2.2，端口为80和443；代理系统本身的ip地址为3.3.3.3。当客户端向服务器发起http访问时，代理系统会使用2.2.2.2的ip地址和80端口和客户端建立起一个http连接，同时代理系统使用1.1.1.1的ip地址和一个随机源端口和真实服务器建立一个http连接，并对http的响应是否是https重定向进行探测。一旦探测完成，发现服务器满足https重定向条件，代理系统则关闭和服务器之间的http连接，同时使用1.1.1.1的ip地址和一个随机源端口和服务器建立一个https连接。在之后的通信过程中，客户端和代理系统之间是一个http连接，代理系统和服务器之间是一个https连接，此https连接是一个可信的连接，因为这时代理系统是作为客户端在使用。在整体通信过程中，源端口发生了改变，源端口是客户端随机选择的，本身是可以变化的。在代理系统和客户端的连接中，服务器端口是80；在代理系统和服务器的连接中，服务器端口是443，但是在整个通信过程中，不会出现代理系统的自身ip地址，代理系统是一个双向透明代理系统。实施例6：如图15所示，是本发明实施例的http转https双向透明代理的装置的架构示意图。本实施例的http转https双向透明代理的装置包括一个或多个处理器21以及存储器22。其中，图15中以一个处理器21为例。处理器21和存储器22可以通过总线或者其他方式连接，图15中以通过总线连接为例。存储器22作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序和非易失性计算机可执行程序，如实施例1中的http转https双向透明代理的方法。处理器21通过运行存储在存储器22中的非易失性软件程序和指令，从而执行http转https双向透明代理的方法。存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。所述程序指令/模块存储在所述存储器22中，当被所述一个或者多个处理器21执行时，执行上述实施例1中的http转https双向透明代理的方法，例如，执行以上描述的图3-图9所示的各个步骤。值得说明的是，上述装置和系统内的模块、单元之间的信息交互、执行过程等内容，由于与本发明的处理方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(rom，readonlymemory)、随机存取存储器(ram，randomaccessmemory)、磁盘或光盘等。以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。当前第1页12当前第1页12