欢迎光临小豌豆知识网!
当前位置:首页 > 电学技术 > 电通讯技术> 会话保持方法及装置独创技术39330字

会话保持方法及装置

2021-02-04 19:10:57

会话保持方法及装置

  技术领域

  本申请涉及数据处理技术领域,尤其涉及一种会话保持方法及装置。

  背景技术

  随着信息技术的发展,基于IPv4协议的全球互联网面临网络地址消耗殆尽、服务质量难以保证等问题,为此互联网工程任务组(The Internet Engineering Task Force,简称IETF)设计了IPv6协议(Internet Protocol version 6,网际协议版本6)替换现行的IPv4协议(Internet Protocol version 4,网际协议版本4)。IPv6协议进行了大幅度修改和功能扩展,提供了几乎无限的地址空间、更强的网络安全性等,IPv6逐步替换IPv4已是必然趋势。同时,IPv6和IPv4网络并行将是常态。

  IPv6网络建设推广初期,在IPv6网络不稳定用户IPv6请求超时或者用户网络环境发生切换且切换后的网络不支持IPv6(如4G网络切换到Wifi网络)的场景下,用户上网通道将自动从IPv6切换到IPv4,基于传统Cookie会话保持的请求会被路由到软负载下挂的IPv4服务器(而不是原IPv6网络下的IPv6服务器),使得传统基于Cookie的会话保持失效,交易失败。

  发明内容

  针对现有技术中的问题,本申请提出了一种会话保持方法及装置,能够避免因IPv6和IPv4网络切换而导致的会话保持失效,能够提高会话保持的有效性,进而能够提高用户交易过程的可靠性。

  为了解决上述技术问题,本申请提供以下技术方案:

  第一方面,本申请提供一种会话保持方法,包括:

  接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文;

  根据预设的会话保持表项和所述Cookie信息,确定所述目标IPv6/IPv4双栈客户端对应的目标Web容器,并将所述目标请求报文发送至该目标Web容器,以使所述目标Web容器处理所述目标请求报文,该目标Web容器与处理所述目标IPv6/IPv4双栈客户端的初始请求报文时的Web容器相同;

  将所述目标请求报文的处理结果发送至所述目标IPv6/IPv4双栈客户端。

  进一步地,所述将所述目标请求报文发送至该目标Web容器,包括:根据预设的会话保持表项和所述Cookie信息,确定所述目标IPv6/IPv4双栈客户端对应的目标Web容器;若所述目标Web容器和所述Cookie信息对应的IP地址的IP协议不同,则应用预设的协议转化关系,将所述Cookie信息对应的IP地址的IP协议转化为所述目标Web容器对应的IP地址的IP协议;应用所述Cookie信息对应的IP协议转化后的IP地址,将所述目标请求报文发送至目标Web容器。

  进一步地,在所述接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文之前,还包括:接收所述目标IPv6/IPv4双栈客户端发送的初始请求报文;根据负载均衡算法确定所述目标IPv6/IPv4双栈客户端对应的Web容器,以使所述Web容器处理所述初始请求报文;生成所述目标IPv6/IPv4双栈客户端对应的Cookie信息,并将该Cookie信息和所述初始请求报文的处理结果发送至所述目标IPv6/IPv4双栈客户端。

  进一步地,所述Cookie信息包括:客户端标识和Cookie有效时间;相对应的,在所述生成所述目标IPv6/IPv4双栈客户端对应的Cookie信息之后,还包括:应用所述客户端标识、Cookie有效时间和所述Web容器的容器标识,更新所述会话保持表项。

  进一步地,所述接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文,包括:若所述目标请求报文为基于IPv4协议发送的请求报文,则应用对应的IPv4虚拟地址接收所述目标请求报文。

  进一步地,所述接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文,包括:若所述目标请求报文为基于IPv6协议发送的请求报文,则应用对应的IPv6虚拟地址接收所述目标请求报文。

  第二方面,本申请提供一种会话保持装置,包括:

  接收模块,用于接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文;

  处理模块,用于根据预设的会话保持表项和所述Cookie信息,确定所述目标IPv6/IPv4双栈客户端对应的目标Web容器,并将所述目标请求报文发送至该目标Web容器,以使所述目标Web容器处理所述目标请求报文,该目标Web容器与处理所述目标IPv6/IPv4双栈客户端的初始请求报文时的Web容器相同;

  发送模块,用于将所述目标请求报文的处理结果发送至所述目标IPv6/IPv4双栈客户端。

  进一步地,所述处理模块,包括:协议转化单元,用于若所述目标Web容器和所述Cookie信息对应的IP地址的IP协议不同,则应用预设的协议转化关系,将所述Cookie信息对应的IP地址的IP协议转化为所述目标Web容器对应的IP地址的IP协议;发送单元,用于应用所述Cookie信息对应的IP协议转化后的IP地址,将所述目标请求报文发送至目标Web容器。

  第三方面,本申请提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现所述的会话保持方法。

  第四方面,本申请提供一种计算机可读存储介质,其上存储有计算机指令,所述指令被执行时实现所述的会话保持方法。

  由上述技术方案可知,本申请提供一种会话保持方法及装置。其中,该方法包括:接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文;根据预设的会话保持表项和所述Cookie信息,确定所述目标IPv6/IPv4双栈客户端对应的目标Web容器,并将所述目标请求报文发送至该目标Web容器,以使所述目标Web容器处理所述目标请求报文,该目标Web容器与处理所述目标IPv6/IPv4双栈客户端的初始请求报文时的Web容器相同;将所述目标请求报文的处理结果发送至所述目标IPv6/IPv4双栈客户端,能够避免因IPv6和IPv4网络切换而导致的会话保持失效,能够提高会话保持的有效性,进而能够提高用户交易过程的可靠性;具体地,本申请基于IPv4和IPv6地址的容器在会话保持装置上的混合部署,能够解决IPv6网络不稳定或客户端网络环境发生变化的情况下,客户端交易不能正常处理的问题。其优点如下:1、实现IPv4地址的Web容器和IPv6地址的Web容器的混合部署,形成一个大的地址池暴露给会话保持装置,在客户端发生IP地址漂移时,软负载服务器还可以将客户端请求负载到原来的Web容器,能够提升交易的可用性。2、在IPv6网络建设推广初期,IPv6网络稳定性还不能保证的情况下,通过会话保持装置自动将客户端请求分配到IPv4的地址池中,对客户透明,使得交易可以继续处理,进而能够提升客户交易体验。

  附图说明

  为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

  图1是本申请实施例中会话保持方法的流程示意图;

  图2是本申请实施例中会话保持方法的步骤201至步骤202的流程示意图;

  图3是本申请实施例中会话保持方法的步骤001至步骤004的流程示意图;

  图4是本申请实施例中会话保持装置的结构示意图;

  图5是本申请应用实例中会话保持系统的逻辑示意图;

  图6是本申请应用实例中IPv6/IPv4双栈客户端的结构示意图;

  图7是本申请应用实例中软负载服务器的结构示意图;

  图8是本申请应用实例中Web容器的结构示意图;

  图9是本申请应用实例中会话保持方法的流程示意图;

  图10为本申请实施例的电子设备的系统构成示意框图。

  具体实施方式

  为了使本技术领域的人员更好地理解本说明书中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。

  考虑到传统Cookie会话保持功能不足,本申请提供一种会话保持方法及装置,将IPv6和IPv4的Web容器地址混合部署在一个地址池里,客户端请求第一次访问到达会话保持装置之后,会话保持装置不区分后台IPv4和IPv6不同地址的Web容器,通过负载均衡算法将访问请求分配到后台任意Web容器上。后续访问过程中,如果客户端发生IPv6和IPv4地址切换,会话保持装置根据客户端请求携带的Cookie信息和IP协议转换,识别该请求所属的原Web容器,并将该客户端请求准确路由到原Web容器进行处理,能够解决因IPv6和IPv4网络切换而导致的传统Cookie会话保持失效问题。

  具体地,对外提供服务的虚拟地址是会话保持装置的虚拟地址;会话保持装置后台混合挂载IPv6和IPv4的Web容器。客户端第一次发起访问请求时,由于请求报文中没有携带Cookie信息,会话保持装置按照负载均衡策略(通常有最小链接数、轮询、最短响应时间等)将客户请求分配到后台其中一个Web容器。Web容器完成处理请求后,数据报文返回到会话保持装置,会话保持装置在数据报文中插入Cookie信息后将数据包返回给客户端,客户端将Cookie信息保存在本地。后续交易过程中,客户端请求携带Cookie信息与服务端进行通信,若客户端发生IPv6和IPv4网络切换,在Cookie有效时间内再次访问会话保持装置时,会话保持装置读取Cookie信息后,通过会话保持装置的IPv6和IPv4地址转换将请求转发至同一个Web容器,从而实现会话保持,交易继续处理。

  需要说明的是,本申请公开的会话保持方法和装置可用于金融领域,也可用于除金融领域之外的任意领域,本申请公开的会话保持方法和装置的应用领域不做限定。

  具体通过下述各个实施例进行说明。

  为了避免因IPv6和IPv4网络切换而导致的会话保持失效,提高会话保持的有效性,进而提高用户交易过程的可靠性,本实施例提供一种执行主体是会话保持装置的会话保持方法,该会话保持装置包括但不限于服务器,参见图1,该方法具体包含有如下内容:

  步骤100:接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文。

  具体地,目标IPv6/IPv4双栈客户端配置有IPv6地址和IPv4地址,由客户端操作系统动态分配,一般优选IPv6地址,在IPv6网络不通的情况下自动降级为IPv4网络。所述请求报文可以是一种金融交易请求报文,如转账或支付等。

  步骤200:根据预设的会话保持表项和所述Cookie信息,确定所述目标IPv6/IPv4双栈客户端对应的目标Web容器,并将所述目标请求报文发送至该目标Web容器,以使所述目标Web容器处理所述目标请求报文,该目标Web容器与处理所述目标IPv6/IPv4双栈客户端的初始请求报文时的Web容器相同。

  具体地,所述预设的会话保持表项可以包含有客户端、Web容器与Cookie有效时间之间的对应关系;可以根据所述Cookie信息中的客户端标识,从所述预设的会话保持表项中获取所述目标IPv6/IPv4双栈客户端对应的目标Web容器的容器标识。所述目标Web容器可以是IPv6的Web容器,也可以是IPv4的Web容器。所述目标Web容器与处理所述目标IPv6/IPv4双栈客户端的初始请求报文时的Web容器相同,能够将来自同一个客户端的请求分配到同一个Web容器中。所述目标Web容器可以设置在所述会话保持装置中,也可以设置在独立服务器中。

  所述预设的会话保持表项的表结构可以如表1所示。

  表1

  

  步骤300:将所述目标请求报文的处理结果发送至所述目标IPv6/IPv4双栈客户端。

  为了将不同IP协议对应的请求报文发送至同一Web容器,避免会话中断,提高会话保持的有效性,参见图2,在本申请一个实施例中,步骤200中所述的将所述目标请求报文发送至该目标Web容器包括:

  步骤201:若所述目标Web容器和所述Cookie信息对应的IP地址的IP协议不同,则应用预设的协议转化关系,将所述Cookie信息对应的IP地址的IP协议转化为所述目标Web容器对应的IP地址的IP协议。

  具体地,若所述目标Web容器对应的IP地址和所述Cookie信息对应的客户端IP地址的IP协议不同,则进行协议转化。可以根据所述Cookie信息在所述会话保持装置中确定所述Cookie信息对应的客户端IP地址。

  步骤202:应用所述Cookie信息对应的IP协议转化后的IP地址,将所述目标请求报文发送至目标Web容器。

  具体地,所述IP协议可以是IPv6协议或IPv4协议;所述目标IPv6/IPv4双栈客户端应用IP协议与所述会话保持装置通信,客户端具体应用哪种IP协议由客户端操作系统决定,主流操作系统都是IPv6优先,在IPv6网络不通的情况下自动降级为IPv4网络。所述目标Web容器和所述Cookie信息对应的IP地址的IP协议不同可以包括:所述目标Web容器的IP地址对应的IP协议为IPv4协议,所述Cookie信息对应的IP地址的IP协议为IPv6协议;也可以包括:所述目标Web容器的IP地址对应的IP协议为IPv6协议,所述Cookie信息中的IP地址对应的IP协议为IPv4协议。具体地,所述预设的协议转化关系包含有多个IPv6/IPv4双栈客户端的IP地址分别对应的IPv4虚拟服务器IP地址、IPv6虚拟服务器IP地址与容器标识之间的对应关系,其中,IPv4虚拟服务器IP地址即IPv4虚拟地址,用于接收IPv6/IPv4双栈客户端发送的基于IPv4协议的客户端请求,IPv6虚拟服务器IP地址即IPv6虚拟地址用于接收IPv6/IPv4双栈客户端发送的基于IPv6协议对应的客户端请求。虚拟服务器IP地址可以由域名解析返回给客户端;所述预设的协议转化关系的结构可以如表2所示,实际内容可根据需要进行设置:

  表2

  

  为了进一步提高会话保持的有效性,在本申请一个实施例中,参见图3,在步骤100之前,还包括:

  步骤001:接收所述目标IPv6/IPv4双栈客户端发送的初始请求报文。

  具体地,所述初始请求报文为所述目标IPv6/IPv4双栈客户端第一次访问所述会话保持装置时的访问请求,该访问请求中没有携带Cookie信息。

  步骤002:根据负载均衡算法确定所述目标IPv6/IPv4双栈客户端对应的Web容器,以使所述Web容器处理所述初始请求报文。

  具体地,所述负载均衡算法可以是最小连接数、最短响应时间、轮询和基于优先级中的一种,优选为最小连接数,能够决定分配并处理请求报文的Web容器。所述Web容器可以部署在所述会话保持装置中的Web容器池中,该Web容器池包含有IPv6 Web容器和IPv4 Web容器。

  负载均衡算法的具体说明如表3所示:

  表3

  

  步骤003:生成所述目标IPv6/IPv4双栈客户端对应的Cookie信息,并将该Cookie信息和所述初始请求报文的处理结果发送至所述目标IPv6/IPv4双栈客户端。

  具体地,可以在所述Cookie信息插入所述初始请求报文的处理结果后,将数据包发送至所述目标IPv6/IPv4双栈客户端,将所述Cookie信息存储在客户端本地,以便以下一次访问所述会话保持装置时,应用所述Cookie信息确定该目标IPv6/IPv4双栈客户端对应的Web容器。

  为了进一步提高会话保持表项的可靠性,进而应用该可靠的会话保持表项提高会话保持的有效性,在本申请一个实施例中,所述Cookie信息包括:客户端标识和Cookie有效时间;相对应的,参见图3,在步骤003所述的生成所述目标IPv6/IPv4双栈客户端对应的Cookie信息之后,还包括:

  步骤004:应用所述客户端标识、Cookie有效时间和所述Web容器的容器标识,更新所述会话保持表项。

  具体地,所述客户端标识可以是应用哈希算法生成客户端ID,用于区分不同的客户端;所述容器标识可以是Web容器的“IP地址:端口号”,用于区分不同的Web容器,将所述客户端标识和所述Web容器的容器标识,存储在所述会话保持表项中,便于下一次接收所述目标IPv6/IPv4双栈客户端的请求报文时,应用该更新后的会话保持表项,确定该目标IPv6/IPv4双栈客户端对应的Web容器,以保证同一客户端的处理不同次的请求报文时对应的Web容器相同。所述Cookie有效时间可根据实际需要进行设置,优选为10分钟。

  由于IPv4协议与IPv6协议不兼容,为了保证目标IPv6/IPv4双栈客户端与会话保持装置之间通信的可靠性,进而提高会话保持的有效性,在本申请一个实施例中,步骤100包括:

  若所述目标请求报文为基于IPv4协议发送的请求报文,则应用对应的IPv4虚拟地址接收所述目标请求报文。

  由于IPv4协议与IPv6协议不兼容,为了保证目标IPv6/IPv4双栈客户端与会话保持装置之间通信的可靠性,进而提高会话保持的有效性,所述接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文,包括:

  若所述目标请求报文为基于IPv6协议发送的请求报文,则应用对应的IPv6虚拟地址接收所述目标请求报文。

  为了获取可靠的Cookie信息,进而应用可靠的Cookie信息提高会话保持的可靠性,在本申请一个应用实例中,所述预设的会话保持表项包括:客户端标识、容器标识和Cookie有效时间;

  相对应的,在步骤300之后,还包括:步骤400:更新所述预设的会话保持表项中,所述目标IPv6/IPv4双栈客户端对应的Cookie有效时间;步骤500:将所述Cookie有效时间发送至所述目标IPv6/IPv4双栈客户端,以使所述目标IPv6/IPv4双栈客户端将该Cookie有效时间保存至所述Cookie信息中,并在该Cookie有效时间内发送下一请求报文。

  从软件层面来说,为了避免因IPv6和IPv4网络切换而导致的会话保持失效,提高会话保持的有效性,进而提高用户交易过程的可靠性,本申请提供一种用于实现所述会话保持方法中全部或部分内容的会话保持装置的实施例,参见图4,所述会话保持装置具体包含有如下内容:

  接收模块10,用于接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文。

  处理模块20,用于根据预设的会话保持表项和所述Cookie信息,确定所述目标IPv6/IPv4双栈客户端对应的目标Web容器,并将所述目标请求报文发送至该目标Web容器,以使所述目标Web容器处理所述目标请求报文,该目标Web容器与处理所述目标IPv6/IPv4双栈客户端的初始请求报文时的Web容器相同。

  发送模块30,用于将所述目标请求报文的处理结果发送至所述目标IPv6/IPv4双栈客户端。

  在本申请一个实施例中,所述处理模块,包括:

  协议转化单元,用于若所述目标Web容器和所述Cookie信息对应的IP地址的IP协议不同,则应用预设的协议转化关系,将所述Cookie信息对应的IP地址的IP协议转化为所述目标Web容器对应的IP地址的IP协议。

  发送单元,用于应用所述Cookie信息对应的IP协议转化后的IP地址,将所述目标请求报文发送至目标Web容器。

  本说明书提供的会话保持装置的实施例具体可以用于执行上述会话保持方法的实施例的处理流程,其功能在此不再赘述,可以参照上述会话保持方法实施例的详细描述。

  为了避免因IPv6和IPv4网络切换而导致的会话保持失效,提高会话保持的有效性,进而提高用户交易过程的可靠性,本申请提供一种会话保持系统,参见图5,该会话保持系统包括:IPv6/IPv4双栈客户端1、软负载服务器2和Web容器3;其中,IPv6/IPv4双栈客户端1与软负载服务器2通过IPv6/IPv4双栈网络连接,软负载服务器2与Web容器3通过IPv6/IPv4双栈网络连接,双栈网络包括有线和无线,如WiFi和4G等,Web容器3可以是IPV4 Web容器或IPV6 Web容器,软负载服务器2实现的功能相当于上述会话保持装置。具体描述如下:

  IPv6/IPv4双栈客户端1,用于客户通过双栈网络访问应用系统。

  软负载服务器2,对外暴露虚拟服务器IP地址(Virtual Server,简称VS)接收双栈客户端HTTP请求,将后端IPv6 Web容器(Real Server,简称RS)和IPv4 Web容器混合部署在一个Web容器池时,根据负载均衡算法(如最小连接数、最短响应时间等)将客户HTTP请求分配到后端混合部署的Web容器池,并根据用户配置的会话保持算法,将来自同一个客户端的请求分配到后端同一个Web容器。

  Web容器3,接收软负载设备分配的客户端HTTP请求,处理完成后,将处理结果返回给软负载服务器。

  图6为本应用实例中,IPv6/IPv4双栈客户端1的结构示意图,如图6所示,双栈客户端1包括IPv4地址单元11、IPv6地址单元12和Cookie管理单元13。其中:

  IPv4地址单元11,使用IPv4协议与服务端进行通信,服务端即软负载服务器。双栈客户端本身有两个IP地址(一个IPv4和一个IPv6),由客户端操作系统动态分配。具体使用哪一个IP地址通信由客户端操作系统决定,主流操作系统都是IPv6优先。在IPv6网络不通的情况下自动降级为IPv4网络,对客户透明。IPv4地址单元11使用的IPv4协议和IPv6地址单元12使用的IPv6协议不兼容,无法互相通信。

  IPv6地址单元12,使用IPv6协议与服务端进行通信。双栈客户端本身有两个IP地址(一个IPv4和一个IPv6),由客户端操作系统动态分配。具体使用哪一个IP地址通信由客户端操作系统决定,主流操作系统都是IPv6优先。在IPv6网络不通的情况下自动降级为IPv4网络,对客户透明。IPv6地址单元12使用的IPv6协议和IPv4地址单元11使用的IPv4协议不兼容,无法互相通信。

  Cookie管理单元13,读取本地存储的Cookie信息,若存在有效的Cookie信息,则携带Cookie信息访问软负载服务器。软负载服务器返回的HTTP报文中若包含Set-Cookie的响应头,则更新本地存储的Cookie信息。

  图7为本应用实例中软负载服务器2的结构示意图,如图7所示,软负载服务器包括用户请求接收单元21、负载均衡算法单元22、IP地址混合部署单元23、Cookie插入单元24和Cookie会话保持单元25。

  用户请求接收单元21,对外暴露虚拟服务器IP地址,虚拟IPv6地址用于接收IPv6客户端HTTP请求,虚拟IPv4地址用于接收IPv4客户端HTTP请求。

  负载均衡算法单元22,根据负载均衡算法,如最小连接数、最短响应时间和轮询等,来决定客户端HTTP请求分配给IP地址混合部署单元23管理的Web容器进行处理。

  IP地址混合部署单元23,用于将后端Web容器的IPv4地址和IPv6地址,组合成一个IP混合部署的地址池,该地址池作为客户端HTTP请求处理的分配范围。IP地址混合部署单元23维护IPv4协议的VS地址、IPv6协议的VS地址和后端IPv4、IPv6 Web容器之间的映射关系,当用户请求到达IPv4或IPv6的VS地址后,根据该映射关系分配后端任意IP的Web容器处理客户端请求,如果容器IP协议和客户端IP协议不一致,由负载均衡服务器进行协议转换。通常,IP地址混合部署单元23通过配置管理工具读取Web容器注册信息存储组件中的数据,来获取和实时更新其所维护的IP地址混合池。

  Cookie插入单元24,使用哈希算法生成客户端ID,同时将客户端ID通过Set-Cookie的响应报文写入到HTTP报文中返回给客户端。

  Cookie会话保持单元25,负责将同一个客户端ID的请求分配到同一个Web容器处理,并刷新会话保持有效时间,以实现会话保持。Cookie会话保持单元判断客户端是否携带Cookie信息,读取Cookie信息中的用户ID,获取该用户ID的会话保持表项(如下表所示)。会话保持表项体现客户端与Web容器之间对应关系,Web容器通过“IP地址:端口号”唯一标识,可以是IPv6的Web容器,也可以是IPv4的Web容器。

  图8为本应用实例中Web容器3的结构示意图。如图8所示,Web容器包括用户请求接收单元31、容器寻址单元32和容器请求处理单元33。

  用户请求接收单元31,对外暴露宿主机IP地址+服务端口,用于接收从软负载服务器转发过来的用户请求。

  容器寻址单元32,管理“宿主机IP地址+服务端口”和“容器私有地址+服务端口”的对应关系,用于请求到容器的寻址过程。

  容器请求处理单元33,用于处理用户请求并返回结果。

  结合上述应用实例提供的会话保持系统,本申请还提供一种会话保持方法的应用实例,参见图9,处理流程如下:

  步骤S101:IPv6地址单元使用IPv6地址发送客户端HTTP请求:双栈客户端使用IPv6地址发送HTTP请求。

  步骤S102:用户请求接收单元使用IPv6的虚拟地址接收客户端请求。

  步骤S103:负载均衡算法单元按照负载均衡策略,将请求分配给混合部署的地址池中的一个Web容器。

  步骤S104::Cookie插入单元生成客户端ID,Cookie会话保持单元记录本次客户请求分配结果,更新会话保持表项。

  步骤S105:Web容器接收、处理客户端请求:并将处理结果返回给软负载服务器。

  步骤S106:Cookie插入单元在返回报文中将客户端ID插入Cookie。

  步骤S107:客户端接收负载均衡服务器返回,保存Cookie信息。

  步骤S108:双栈客户端发生IP地址漂移:一次完整交易过程中可能存在多次HTTP请求交互,某一次HTTP请求时网络IPv6网络不稳定,双栈客户端发生了IP地址漂移。

  步骤S109:Cookie管理单元读取本地有效的Cookie信息。

  步骤S110:IPv4地址单元使用IPv4地址发送客户端HTTP请求(含Cookie)。

  步骤S111:用户请求接收单元使用IPv4虚拟地址接收客户端请求。

  步骤S112:Cookie会话保持单元读取HTTP请求中Cookie信息,获取该用户ID对应的会话保持表项。

  步骤S113:负载均衡算法单元按会话保持表项进行分配。

  步骤S114:Web容器接收、处理、返回客户端请求。

  步骤S115:Cookie会话保持单元更新会话保持表项,如Cookie有效时间等。

  步骤S116:客户端接收负载均衡服务器返回并更新本地存储的Cookie信息。

  由上述描述可知,本申请提供的会话保持方法及装置,能够避免因IPv6和IPv4网络切换而导致的会话保持失效,能够提高会话保持的有效性,进而能够提高用户交易过程的可靠性;具体地,本申请基于IPv4和IPv6地址的容器在会话保持装置上的混合部署,能够解决IPv6网络不稳定或客户端网络环境发生变化的情况下,客户端交易不能正常处理的问题。其优点如下:1、实现IPv4地址的Web容器和IPv6地址的Web容器的混合部署,形成一个大的地址池暴露给会话保持装置,在客户端发生IP地址漂移时,软负载服务器还可以将客户端请求负载到原来的Web容器,能够提升交易的可用性。2、在IPv6网络建设推广初期,IPv6网络稳定性还不能保证的情况下,通过会话保持装置自动将客户端请求分配到IPv4的地址池中,对客户透明,使得交易可以继续处理,进而能够提升客户交易体验。

  从硬件层面来说,为了避免因IPv6和IPv4网络切换而导致的会话保持失效,提高会话保持的有效性,进而提高用户交易过程的可靠性,本申请提供一种用于实现所述会话保持方法中的全部或部分内容的电子设备的实施例所述电子设备具体包含有如下内容:

  处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线;其中,所述处理器、存储器、通信接口通过所述总线完成相互间的通信;所述通信接口用于实现所述会话保持装置以及用户终端等相关设备之间的信息传输;该电子设备可以是台式计算机、平板电脑及移动终端等,本实施例不限于此。在本实施例中,该电子设备可以参照实施例用于实现所述会话保持方法的实施例及用于实现所述会话保持装置的实施例进行实施,其内容被合并于此,重复之处不再赘述。

  图10为本申请实施例的电子设备9600的系统构成的示意框图。如图10所示,该电子设备9600可以包括中央处理器9100和存储器9140;存储器9140耦合到中央处理器9100。值得注意的是,该图10是示例性的;还可以使用其他类型的结构,来补充或代替该结构,以实现电信功能或其他功能。

  在本申请一个或多个实施例中,会话保持功能可以被集成到中央处理器9100中。其中,中央处理器9100可以被配置为进行如下控制:

  步骤100:接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文。

  步骤200:根据预设的会话保持表项和所述Cookie信息,确定所述目标IPv6/IPv4双栈客户端对应的目标Web容器,并将所述目标请求报文发送至该目标Web容器,以使所述目标Web容器处理所述目标请求报文,该目标Web容器与处理所述目标IPv6/IPv4双栈客户端的初始请求报文时的Web容器相同。

  步骤300:将所述目标请求报文的处理结果发送至所述目标IPv6/IPv4双栈客户端。

  从上述描述可知,本申请的实施例提供的电子设备,能够避免因IPv6和IPv4网络切换而导致的会话保持失效,提高会话保持的有效性,进而提高用户交易过程的可靠性。

  在另一个实施方式中,会话保持装置可以与中央处理器9100分开配置,例如可以将会话保持装置配置为与中央处理器9100连接的芯片,通过中央处理器的控制来实现会话保持功能。

  如图10所示,该电子设备9600还可以包括:通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是,电子设备9600也并不是必须要包括图10中所示的所有部件;此外,电子设备9600还可以包括图10中没有示出的部件,可以参考现有技术。

  如图10所示,中央处理器9100有时也称为控制器或操作控件,可以包括微处理器或其他处理器装置和/或逻辑装置,该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

  其中,存储器9140,例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息,此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序,以实现信息存储或处理等。

  输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器,但并不限于此。

  该存储器9140可以是固态存储器,例如,只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器,其即使在断电时也保存信息,可被选择性地擦除且设有更多数据,该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142,该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

  存储器9140还可以包括数据存储部9143,该数据存储部9143用于存储数据,例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

  通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100,以提供输入信号和接收输出信号,这可以和常规移动通信终端的情况相同。

  基于不同的通信技术,在同一电子设备中,可以设置有多个通信模块9110,如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132,以经由扬声器9131提供音频输出,并接收来自麦克风9132的音频输入,从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外,音频处理器9130还耦合到中央处理器9100,从而使得可以通过麦克风9132能够在本机上录音,且使得可以通过扬声器9131来播放本机上存储的声音。

  上述描述可知,本申请的实施例提供的电子设备,能够避免因IPv6和IPv4网络切换而导致的会话保持失效,提高会话保持的有效性,进而提高用户交易过程的可靠性。

  本申请的实施例还提供能够实现上述实施例中的会话保持方法中全部步骤的一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,该计算机程序被处理器执行时实现上述实施例中的会话保持方法的全部步骤,例如,所述处理器执行所述计算机程序时实现下述步骤:

  步骤100:接收目标IPv6/IPv4双栈客户端发送的包含有Cookie信息的目标请求报文。

  步骤200:根据预设的会话保持表项和所述Cookie信息,确定所述目标IPv6/IPv4双栈客户端对应的目标Web容器,并将所述目标请求报文发送至该目标Web容器,以使所述目标Web容器处理所述目标请求报文,该目标Web容器与处理所述目标IPv6/IPv4双栈客户端的初始请求报文时的Web容器相同。

  步骤300:将所述目标请求报文的处理结果发送至所述目标IPv6/IPv4双栈客户端。

  从上述描述可知,本申请实施例提供的计算机可读存储介质,能够避免因IPv6和IPv4网络切换而导致的会话保持失效,提高会话保持的有效性,进而提高用户交易过程的可靠性。

  本申请中上述方法的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。相关之处参见方法实施例的部分说明即可。

  本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

  本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

  这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

  这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

  本申请中应用了具体实施例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。

《会话保持方法及装置.doc》
将本文的Word文档下载到电脑,方便收藏和打印
推荐度:
点击下载文档

文档为doc格式(或pdf格式)