CN117354205A - 握手复用方法、设备以及计算机可读介质 - Google Patents

Abstract

本申请提供了一种握手复用方法、设备以及计算机可读介质，该方案中服务端设备可以接收来自客户端设备的client hello消息，其中所述client hello消息携带有session id和session ticket，在接收到client hello消息后，服务端设备根据配置信息，使用所述client hello消息所携带的session id和session ticket中优先级较高的第一信息来进行握手复用，若基于第一信息的握手复用失败时，所述服务端设备可以根据配置信息，使用另一个优先级较低的第二信息再进行握手复用。由此，增加了更多的灵活性，使得服务端设备可以根据配置信息动态选择握手的复用方式，并且可以在任意一种握手复用方式失败时，自动切换成另一种方式再次尝试握手复用，提高了握手复用成功率。

Description

握手复用方法、设备以及计算机可读介质

技术领域

本申请涉及信息技术领域，尤其涉及一种握手复用方法、设备以及计算机可读介质。

背景技术

为了保障互联网信息交互的安全，现如今大部分流量基本采用HTTPS(Hyper TextTransfer Protocol over Secure Socket Layer，基于安全套接字层的超文本传输协议)加密的方式，保证交互信息的安全性。引入HTTPS虽然带来了安全性的保证，但是却引入了更多的交互时延，其原因在于需要在连接建立之前进行SSL(Secure Socket Layer，安全套接字层协议)或TLS(Transport Layer Security，安全传输层协议)握手。其中，TLS 1.2及以下的版本中，完整握手流程需要消耗2个RTT(Round Trip Time，往返时延)，因此为了加快握手过程，通过会话标识(session id)/会话票据(session ticket)的方式进行握手复用，减少一个RTT。

在实际场景中，虽然客户端可以在进行握手的客户端问候消息(client hello消息)中同时携带session id与session ticket，但是服务端在收到同时携带了session id与session ticket的client hello消息时，只会按照固定的方式处理。其处理方式为：只使用其中的session ticket，而忽略session id，若基于session ticket进行握手复用失败，则直接退化成消耗两个RTT的完整握手，而不再尝试使用session id进行握手复用。由此可知，现有的握手复用方式不够灵活，复用率较低。

发明内容

本申请的一个目的是提供一种握手复用方法、设备以及计算机可读介质，至少用以解决现有的握手复用方式不够灵活，复用率较低的问题。

为实现上述目的，本申请的一些实施例提供了一种握手复用方法，所述方法应用于服务端设备，所述方法包括：

所述服务端设备接收来自客户端设备的client hello消息，所述client hello消息携带有session id和session ticket；

所述服务端设备根据配置信息，使用所述client hello消息携带的第一信息进行握手复用，其中，所述第一信息为所述client hello消息所携带的session id和sessionticket中优先级较高的信息；

若基于第一信息的握手复用失败，所述服务端设备根据配置信息，使用所述client hello消息携带的第二信息进行握手复用，其中，所述第二信息为所述clienthello消息所携带的session id和session ticket中优先级较低的信息。

本申请实施例还提供了一种握手复用方法，所述方法应用于配置设备，所述方法包括：

所述配置设备获取服务提供方或服务使用方输入的配置信息；

所述配置设备向服务端设备发送所述配置信息，以使所述服务端设备在接收到来自客户端设备的client hello消息后，根据所述配置信息，使用所述client hello消息携带的第一信息进行握手复用，以及在基于第一信息的握手复用失败时，根据配置信息，使用所述client hello消息携带的第二信息进行握手复用，其中，所述第一信息为所述clienthello消息所携带的session id和session ticket中优先级较高的信息，所述第二信息为所述client hello消息所携带的session id和session ticket中优先级较低的信息。

本申请实施例还提供了一种实现握手复用的服务端设备，所述服务端设备包括：

数据传输模块，用于接收来自客户端设备的client hello消息，所述clienthello消息携带有session id和session ticket；

复用处理模块，用于根据配置信息，使用所述client hello消息携带的第一信息进行握手复用，其中，所述第一信息为所述client hello消息所携带的session id和session ticket中优先级较高的信息；若基于第一信息的握手复用失败，所述服务端设备根据配置信息，使用所述client hello消息携带的第二信息进行握手复用，其中，所述第二信息为所述client hello消息所携带的session id和session ticket中优先级较低的信息。

本申请实施例还提供了一种实现握手复用的配置设备，所述配置设备包括：

输入输出模块，用于获取服务提供方或服务使用方输入的配置信息；

数据传输模块，用于向服务端设备发送所述配置信息，以使所述服务端设备在接收到来自客户端设备的client hello消息后，根据所述配置信息，使用所述client hello消息携带的第一信息进行握手复用，其中，所述第一信息为所述client hello消息所携带的session id和session ticket中优先级较高的信息；若基于第一信息的握手复用失败，所述服务端设备根据配置信息，使用所述client hello消息携带的第二信息进行握手复用，其中，所述第二信息为所述client hello消息所携带的session id和session ticket中优先级较低的信息。

本申请实施例还提供了一种实现握手复用的设备，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行所述的握手复用方法。

本申请实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机程序指令可被处理器执行以实现所述的握手复用方法。

相较于现有技术，本申请实施例提供了一种握手复用方案，该方案中服务端设备可以接收来自客户端设备的client hello消息，其中所述client hello消息携带有session id和session ticket，在接收到client hello消息后，服务端设备根据配置信息，使用所述client hello消息所携带的session id和session ticket中优先级较高的第一信息来进行握手复用，若基于第一信息的握手复用失败时，所述服务端设备可以根据配置信息，使用另一个优先级较低的第二信息再进行握手复用。由此，增加了更多的灵活性，使得服务端设备可以根据配置信息动态选择握手的复用方式，并且可以在任意一种握手复用方式失败时，自动切换成另一种方式再次尝试握手复用，提高了握手复用成功率。

附图说明

图1为本申请实施例提供的一种握手复用方法的处理流程图；

图2为基于session id进行握手复用时服务端设备与客户端设备之间的交互过程示意图；

图3为基于session ticket的进行握手复用时服务端设备与客户端设备之间的交互过程示意图；

图4为本申请实施例中客户端设备首次与服务端设备连接的过程中进行TLS握手时的交互示意图；

图5为本申请实施例中客户端设备再次与服务端设备连接的过程中进行TLS握手时的交互示意图；

图6为本申请实施例提供的一种实现握手复用的服务端设备的结构示意图；

图7为本申请实施例提供的一种实现握手复用的配置设备的结构示意图；

图8为本申请实施例提供的一种实现握手复用的设备的结构示意图。

具体实施方式

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

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请实施例提供了一种握手复用方法，该方法中服务端设备可以接收来自客户端设备的client hello消息，其中所述client hello消息携带有session id和sessionticket，在接收到client hello消息后，服务端设备根据配置信息，使用所述client hello消息所携带的session id和session ticket中优先级较高的第一信息来进行握手复用，若基于第一信息的握手复用失败时，所述服务端设备可以根据配置信息，使用另一个优先级较低的第二信息再进行握手复用。由此，增加了更多的灵活性，使得服务端设备可以根据配置信息动态选择握手的复用方式，并且可以在任意一种握手复用方式失败时，自动切换成另一种方式再次尝试握手复用，提高了握手复用成功率。

在实际场景中，执行上述方法的服务端设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集中的服务器或者是分布式云网络中的服务器等。在此所述分布式云网络由基于云计算(Cloud Computing)的大量主机或网络服务器构成。需要说明的是，分布式云网络可以为CDN(Content Delivery Network，内容分发网络)，该CDN网络中可以包括多个分布式节点。除CDN网络以外，分布式网络也可以为多台服务器按照分布式架构组成的服务器集群，分布式节点为该服务器集群中的任一服务器。在另外一示例中，分布式云网络也可以为边缘云网络，该边缘云网络可以基于云计算技术的核心和边缘计算的能力，构筑在边缘基础设施之上的云计算平台，以形成边缘位置的计算、网络、存储、安全、应用等能力全面的弹性云平台。应当注意的是，本申请实施例并不限制分布式网络具体为何种网络，任意多台计算设备组成的分布式架构的网络均适用于本申请。

图1示出了本申请实施例提供的一种握手复用方法的处理流程，至少包括以下的处理步骤：

步骤S101，所述服务端设备接收来自客户端设备的client hello消息。

所述client hello消息是由客户端设备发送的、用于触发其与服务端设备之间进行TLS握手并建立会话(session)。在实际场景中，client hello消息可以通过携带一些特定信息，如session id或session ticket等，服务端设备即可使用其中的任意一种特定信息，实现握手复用，将之前已经创建的会话用于本次握手，从而提升TLS握手的速度。

在实际场景中，client hello消息中可以同时携带多种能够用于握手复用的消息，例如同时携带有session id和session ticket。现有的握手复用方案中，服务端设备在收到同时携带了session id与session ticket的client hello消息时，只会按照固定的方式处理。其处理方式为：只使用其中的session ticket，而忽略session id，若基于sessionticket进行握手复用失败，则直接退化成消耗两个RTT的完整握手，而不再尝试使用session id进行握手复用，因此握手复用不够灵活，且复用率较低。

在本申请实施例提供的方案中，当服务端设备接收到的client hello消息时，则会采用以下的处理以提升复用过程的灵活性，同时提升复用率，具体如下：

步骤S102，所述服务端设备根据配置信息，使用所述client hello消息携带的第一信息进行握手复用。

所述第一信息为所述client hello消息所携带的session id和session ticket中优先级较高的信息。其中，所述优先级可以基于服务端设备中的配置信息确定，例如用户可以预先将配置信息提供至服务端设备，配置信息中包括了session id和session ticket的优先级。

若在本实施例中，设置了session id的优先级高于session ticket，此时的第一信息即为session id。由此，在本步骤中，服务端设备将使用client hello消息携带的session id进行握手复用。反之，若配置信息中设置的是session ticket的优先级高于session id，则此时服务端设备将使用client hello消息携带的session ticket进行握手复用。

图2示出了基于session id进行握手复用时服务端设备与客户端设备之间的交互过程。服务端设备Server在接收到来自客户端设备Client的ClientHello消息后，可以根据其中携带的session id查找是否有相关的会话。已有的会话是在本次握手之前通过完整的握手建立的，若服务端设备Server查找到了具有相同session id的已有会话，则会允许握手复用，使用之前已建立过的会话完成本次握手。此时，服务端设备将不再进行完整的握手交互过程，而是直接向客户端设备Client发送更换密码规格消息(ChangeCipherSpec消息)和完成消息(Finished消息)。客户端设备Client收到服务端设备Server发来的ChangeCipherSpec消息和Finished消息后，表示会话恢复成功，也发送ChangeCipherSpec消息和Finished消息给服务端设备Server作为回应，由此完成基于session id的握手复用过程。建立连接之后即可交互应用数据。

图3示出了基于session ticket的进行握手复用时服务端设备与客户端设备之间的交互过程。服务端设备Server在接收到来自客户端设备Client的ClientHello消息后，检查客户端设备Client在ClientHello消息中的session ticket扩展是否为空，若sessionticket扩展为非空，则表示其中携带了session ticket，该session ticket包含了会话的相关数据，如会话信息、证书、加密方式和密钥等，使得服务端设备可以基于sessionticket恢复会话。同时，服务端设备Server还会将本次握手更新后的session ticket通过NewSessionTicket消息发送给客户端设备Client，以便于之后的握手复用。并且，服务端设备Server会在随后发送ChangeCipherSpec消息和Finished消息。客户端设备Client收到以后，也发送ChangeCipherSpec消息和Finished消息给服务端设备Server作为回应，由此完成基于session session ticket的握手复用过程。建立连接之后即可交互应用数据。

步骤S103，若基于第一信息的握手复用失败，所述服务端设备根据配置信息，使用所述client hello消息携带的第二信息进行握手复用。由于配置信息中包括了session id和session ticket的优先级，所述第二信息即为所述client hello消息所携带的sessionid和session ticket中优先级较低的信息。

通过上述的方式，使得服务端设备在收到同时携带有session id和sessionticket的client hello消息时，不再按照固定的方式只使用其中的session ticket进行握手复用，而忽略session id，由此增加了握手复用时的灵活性，使得服务端设备可以根据配置信息动态选择握手的复用方式，并且可以在任意一种握手复用方式失败时，自动切换成另一种方式再次尝试握手复用，提高了握手复用成功率。

当第一信息为session id时，第二信息即为session ticket，此时，若基于session id的握手复用失败，所述服务端设备可以使用所述client hello消息携带的session ticket进行握手复用。其中，服务端设备与客户端设备之间基于session id的握手复用失败的原因可能是由于所述session id过期，在实际场景中，服务端设备在生成session id时，会同时生成该session id的有效时间，当有效时间内未收到接收到包含该session id的client hello消息进行握手复用时，则会导致该session id过期，从而导致基于session id的握手复用失败。

此外，服务端设备与客户端设备之间基于session id的握手复用失败的原因还可能是所述服务端设备基于所述session id未查找到对应的会话。例如，当服务端设备接收到包含session id的client hello消息时，检查判定该session id还处于有效时间内，此时会基于该session id查找对应的会话，若服务端设备因一部分存储失效，导致已存储的会话丢失时，将会导致无法基于该session id查找对应的会话。此时，同样会导致基于session id的握手复用失败。

而当第一信息为session ticket时，第二信息即为session id，此时，若基于session ticket的握手复用失败，所述服务端设备可以使用所述client hello消息携带的session id进行握手复用。其中，服务端设备与客户端设备之间基于session ticket的握手复用失败的原因可能是所述session ticket过期。服务端设备在进行握手时，会将session ticket通过NewSessionTicket消息发送给客户端设备，该session ticket有一定的有效时间。客户端设备在收到session ticket后，可以在需要握手复用时，将sessionticket携带于ClientHello消息的session ticket扩展中，若客户端设备在有效时间内未使用该session ticket，则会导致该session ticket过期，从而导致基于session ticket的握手复用失败。

此外，服务端设备与客户端设备之间基于session id的握手复用失败的原因还可能是所述服务端设备基于所述session ticket解密失败。当服务端设备接收到未过期的session ticket时，由于session ticket中携带了恢复会话所需要的密钥等信息，若该密钥错误，则会使得解密失败，从而导致基于session ticket的握手复用失败。

在此，本领域技术人员应当理解上述基于session id或session ticket握手复用失败的原因仅为举例，现有或今后出现的基于类似原理的其它形式如果能够适用于本申请，也应该包含在本申请的保护范围内，并以引用的形式包含于此。

若基于第一信息的握手复用失败，则表示基于第一信息可能因某种原因而出现了错误，为了使得后续的交互过程中可以再次使用第一信息顺利完成握手复用，服务端设备在基于第二信息完成握手复用后，可以根据配置信息生成新的第一信息，并向所述客户端设备返回携带有所述第一信息的server hello消息。由此，使得客户端设备可以在后续的交互过程中可以自由选择使用这两种复用方式，由此提升了复用的灵活性，便于方案根据实际场景的需要灵活的选择复用方式。

在实际场景中，虽然ClientHello消息中的同时携带了session id和sessionticket，但是可能基于两种方式的握手复用均失败，本申请实施例提供的方案在此种情形下将执行完整握手的处理过程。即所述服务端设备在收到携带有session id和sessionticket的ClientHello消息后，首先根据配置信息使用所述client hello消息携带的第一信息进行握手复用，若失败后，再使用所述client hello消息携带的第二信息进行握手复用，若此时也同样失败，则所述服务端设备并不会放弃本次握手，而是会执行完整握手，以确保能够与客户端设备之间建立连接。

而在完整握手的处理过程中，所述服务端设备根据配置信息生成新的session id和/或session ticket，并向所述客户端设备返回携带有所述session id和/或sessionticket的server hello消息，便于后续的交互过程中，客户端设备可以基于新的sessionid和/或session ticket，来进行握手复用。在实际场景中，服务端设备生成并向客户端设备返回的用于后续握手复用的信息可以由配置信息决定，例如配置信息中可以配置在此种情形下仅生成session id并返回给客户端设备，也可以配置在此种情形下仅生成sessionticket并返回给客户端设备，此外也可以同时生成session ticket和session id，并返回给客户端设备。

在实际场景中，客户端设备发送给服务端设备的client hello消息中，除了同时携带session id和session ticket的情况之外，还有可能仅携带了其中的一种信息。此时，若所述client hello消息携带有session id，且未携带session ticket，所述服务端设备可以使用所述session id进行握手复用，并在握手复用成功后，根据配置信息生成sessionticket，并向所述客户端设备返回携带有所述session id和session ticket的serverhello消息。若所述client hello消息携带有session ticket，且未携带session id，则所述服务端设备可以使用所述session ticket进行握手复用，并在握手复用成功后，根据配置信息生成session id，并向所述客户端设备返回携带有所述session id和sessionticket的server hello消息。由此，即使客户端设备在发起握手请求时，仅有一种握手复用方式可以选择，而当握手完成之后，由于服务端设备会提供另一种握手复用方式所对应的信息，客户端设备可以在后续的交互过程中可以灵活选择使用这两种复用方式，由此提升了复用的灵活性，便于方案根据实际场景的需要灵活的选择复用方式。

此外，所述client hello消息中也可能未携带session id和session ticket，此时，所述服务端设备执行完整握手。在执行完整握手的处理过程中，所述服务端设备同样可以根据配置信息生成session id和/或session ticket，并向所述客户端设备返回携带有所述session id和/或session ticket的server hello消息，以便于后续的交互过程中，客户端设备可以基于新的session id和/或session ticket，来进行握手复用。

在本申请的一些实施例中，所述服务端设备还可以向服务提供方或服务使用方提供配置界面。其中，所述服务提供方可以是提供握手复用服务功能的一方，例如可以是服务端设备的运营商，其可以在向用户提供服务之前预先通过配置信息来配置其服务端设备所能够提供的握手复用功能。所述服务使用方可以是实际使用握手复用服务功能的一方，例如可以是与服务端设备建立连接的访问用户，在实际场景中服务提供方可以向服务使用方开放个性化的配置功能，使得服务使用方可以预先通过配置信息对其所使用的握手复用功能的进行配置。

所述配置界面可以是用于实现人机交互的图形用户界面，以便于服务提供方或服务使用方的用户能够基于该配置界面便捷地输入配置信息。例如，所述配置界面中可以设置有session id和session ticket的优先级选项，从而快速设置session id和sessionticket的优先级，此外也可以根据方案的需要设置输入其它配置信息的输入框或备选项等。由此，服务端设备可以获取所述服务提供方或服务使用方基于所述配置界面输入的配置信息，并在执行握手复用方法时使用所述配置信息。

此外，本申请实施例还提供了一种方法应用于配置设备的握手复用方法，该方法中所述配置设备可以获取服务提供方或服务使用方输入的配置信息，然后向服务端设备发送所述配置信息，以使所述服务端设备在接收到来自客户端设备的client hello消息后，根据所述配置信息，使用所述client hello消息携带的第一信息进行握手复用，并且在基于第一信息的握手复用失败时，根据配置信息，使用所述client hello消息携带的第二信息进行握手复用。其中，所述第一信息为所述client hello消息所携带的session id和session ticket中优先级较高的信息，所述第二信息为所述client hello消息所携带的session id和session ticket中优先级较低的信息。

所述配置设备在获取服务提供方或服务使用方输入的配置信息时，可以向服务提供方或服务使用方显示配置界面，该配置界面可以由服务端设备提供，并通过配置设备向服务提供方或服务使用方显示。由此，服务提供方或服务使用方可以通过配置设备所显示的配置界面便捷地完成配置信息的输入，使得配置设备可以获取所述服务提供方或服务使用方基于所述配置界面输入的配置信息，并发送给服务端设备使用，从而实现握手复用。

图4为客户端设备首次与服务端设备连接的过程中进行TLS握手时的交互示意图，首次连接时无法进行握手复用，需要进行完整握手。其交互过程如下：

1)客户端设备首先发送client hello消息，其中未携带session id和sessionticket。

2)服务端设备收到client hello消息后，如果服务端设备中配置了同时使用session id以及session ticket的配置信息，则服务端设备在握手过程中，同时发送session id和session ticket信息至客户端设备。

3)客户端设备保存收到的session id以及session ticket至本地，以便于在后续的建立过程中进行复用。

4)服务端设备与客户端设备结束完整握手过程。

图5为客户端设备再次与服务端设备连接的过程中进行TLS握手时的交互示意图，此时可以进行握手复用。其交互过程如下：

1)客户端设备首先发送client hello消息，由于客户端设备首次连接时在本地保存了session id和session ticket，则可以在本次连接所发送的client hello消息中同时携带session id以及session ticket。

2)服务端设备收到client hello消息后，会有以下的处理方式：

a)如果服务端设备在配置信息中配置了优先使用session ticket，则会先以session ticket的方式进行握手复用，当session ticket复用失败时，服务端设备自动切换成session id的方式进行握手复用，如果session id方式的握手复用也失败，则再进行完整握手过程；

b)如果服务端设备在配置信息中配置了优先使用session id，则会以session id的方式进行握手复用，当session id复用失败时，服务端设备自动切换成session ticket的方式进行握手复用，如果session ticket方式的握手复用也失败，则再进行完整握手过程。

3)服务端设备与客户端设备结束握手过程。

在上述交互过程中，服务端设备可以根据配置信息，使用所述client hello消息所携带的session id和session ticket中优先级较高的第一信息来进行握手复用，若基于第一信息的握手复用失败时，所述服务端设备可以根据配置信息，使用另一个优先级较低的第二信息再进行握手复用。由此，增加了更多的灵活性，使得服务端设备可以根据配置信息动态选择握手的复用方式，并且可以在任意一种握手复用方式失败时，自动切换成另一种方式再次尝试握手复用，提高了握手复用成功率。

本申请实施例还提供了一种实现握手复用的服务端设备，所述服务端设备的结构如图6所示，包括数据传输模块610和复用处理模块620。数据传输模块610用于接收来自客户端设备的client hello消息，所述client hello消息携带有session id和sessionticket。复用处理模块620用于根据配置信息，使用所述client hello消息携带的第一信息进行握手复用，其中，所述第一信息为所述client hello消息所携带的session id和session ticket中优先级较高的信息；若基于第一信息的握手复用失败，所述服务端设备根据配置信息，使用所述client hello消息携带的第二信息进行握手复用，其中，所述第二信息为所述client hello消息所携带的session id和session ticket中优先级较低的信息。

此外，本申请实施例还提供了一种实现握手复用的配置设备，所述配置设备的结构如图7所示，包括输入输出模块710和数据传输模块720。其中，输入输出模块710用于获取服务提供方或服务使用方输入的配置信息。数据传输模块720用于向服务端设备发送所述配置信息，以使所述服务端设备在接收到来自客户端设备的client hello消息后，根据所述配置信息，使用所述client hello消息携带的第一信息进行握手复用，以及在基于第一信息的握手复用失败时，根据配置信息，使用所述client hello消息携带的第二信息进行握手复用，其中，所述第一信息为所述client hello消息所携带的session id和sessionticket中优先级较高的信息，所述第二信息为所述client hello消息所携带的session id和session ticket中优先级较低的信息。

此外，本申请实施例还提供了一种实现握手复用方法的设备，该设备的结构如图8所示，包括用于存储计算机可读指令的存储器810和用于执行计算机可读指令的处理器820，其中，当该计算机可读指令被该处理器执行时，触发所述处理器执行所述握手复用方法。

本申请实施例中的方法和/或实施例可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在该计算机程序被处理单元执行时，执行本申请的方法中限定的上述功能。

需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图或框图示出了按照本申请各种实施例的设备、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的针对硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本申请实施例还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个计算机可读指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案的步骤。

此外，本申请实施例还提供了一种计算机程序，所述计算机程序存储于计算机设备，使得计算机设备执行所述控制代码执行的方法。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (14)

1.一种握手复用方法，所述方法应用于服务端设备，其特征在于，所述方法包括：

所述服务端设备接收来自客户端设备的client hello消息，所述client hello消息携带有session id和session ticket；

所述服务端设备根据配置信息，使用所述client hello消息携带的第一信息进行握手复用，其中，所述第一信息为所述client hello消息所携带的session id和sessionticket中优先级较高的信息；

若基于第一信息的握手复用失败，所述服务端设备根据配置信息，使用所述clienthello消息携带的第二信息进行握手复用，其中，所述第二信息为所述client hello消息所携带的session id和session ticket中优先级较低的信息。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若基于第二信息的握手复用失败，所述服务端设备执行完整握手，其中，执行完整握手的处理过程中，所述服务端设备根据配置信息生成新的session id和/或session ticket，并向所述客户端设备返回携带有所述session id和/或session ticket的server hello消息。

3.根据权利要求2所述的方法，其特征在于，基于session id的握手复用失败，包括：所述session id过期或所述服务端设备基于所述session id未查找到对应的会话；

基于session ticket的握手复用失败，包括：所述session ticket过期或所述服务端设备基于所述session ticket解密失败。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若所述client hello消息未携带session id和session ticket，所述服务端设备根据配置信息执行完整握手，其中，执行完整握手的处理过程中，所述服务端设备生成sessionid和/或session ticket，并向所述客户端设备返回携带有所述session id和/或sessionticket的server hello消息。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若所述client hello消息携带有session id，且未携带session ticket，所述服务端设备使用所述session id进行握手复用；

服务端设备根据配置信息生成session ticket，并向所述客户端设备返回携带有所述session id和session ticket的server hello消息。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若所述client hello消息携带有session ticket，且未携带session id，所述服务端设备使用所述session ticket进行握手复用；

服务端设备根据配置信息生成session id，并向所述客户端设备返回携带有所述session id和session ticket的server hello消息。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若基于第一信息的握手复用失败，服务端设备根据配置信息生成新的第一信息，并向所述客户端设备返回携带有所述第一信息的server hello消息。

8.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述服务端设备向服务提供方或服务使用方提供配置界面，并获取所述服务提供方或服务使用方基于所述配置界面输入的配置信息。

9.一种握手复用方法，所述方法应用于配置设备，其特征在于，所述方法包括：

所述配置设备获取服务提供方或服务使用方输入的配置信息；

所述配置设备向服务端设备发送所述配置信息，以使所述服务端设备在接收到来自客户端设备的client hello消息后，根据所述配置信息，使用所述client hello消息携带的第一信息进行握手复用，以及在基于第一信息的握手复用失败时，根据配置信息，使用所述client hello消息携带的第二信息进行握手复用，其中，所述第一信息为所述clienthello消息所携带的session id和session ticket中优先级较高的信息，所述第二信息为所述client hello消息所携带的session id和session ticket中优先级较低的信息。

10.根据权利要求9所述的方法，其特征在于，所述配置设备获取服务提供方或服务使用方输入的配置信息，包括：

所述配置设备显示配置界面，并获取所述服务提供方或服务使用方基于所述配置界面输入的配置信息。

11.一种实现握手复用的服务端设备，其特征在于，所述服务端设备包括：

数据传输模块，用于接收来自客户端设备的client hello消息，所述client hello消息携带有session id和session ticket；

复用处理模块，用于根据配置信息，使用所述client hello消息携带的第一信息进行握手复用，其中，所述第一信息为所述client hello消息所携带的session id和sessionticket中优先级较高的信息；若基于第一信息的握手复用失败，所述服务端设备根据配置信息，使用所述client hello消息携带的第二信息进行握手复用，其中，所述第二信息为所述client hello消息所携带的session id和session ticket中优先级较低的信息。

12.一种实现握手复用的配置设备，其特征在于，所述配置设备包括：

输入输出模块，用于获取服务提供方或服务使用方输入的配置信息；

数据传输模块，用于向服务端设备发送所述配置信息，以使所述服务端设备在接收到来自客户端设备的client hello消息后，根据所述配置信息，使用所述client hello消息携带的第一信息进行握手复用，其中，所述第一信息为所述client hello消息所携带的session id和session ticket中优先级较高的信息；若基于第一信息的握手复用失败，所述服务端设备根据配置信息，使用所述client hello消息携带的第二信息进行握手复用，其中，所述第二信息为所述client hello消息所携带的session id和session ticket中优先级较低的信息。

13.一种实现握手复用的设备，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行权利要求1至10中任一项所述的方法。

14.一种计算机可读介质，其上存储有计算机程序指令，所述计算机程序指令可被处理器执行以实现如权利要求1至10中任一项所述的方法。