CN102868627B - Ike协商的拥塞控制方法及装置 - Google Patents

Abstract

本发明公开了一种IKE协商的拥塞控制方法及装置，其中，该方法包括：在接收到对端发来的第一报文之后，从第一报文中获取对端的运算时间，其中，运算时间是解析接收的第二报文以及针对第二报文构造需要回复的第一报文所消耗的时间，或者是构造第一报文所消耗的时间；判断获取到的运算时间是否超过了预设的运算时间阈值；若判断出超过了运算时间阈值，则根据获取到的运算时间确定延迟时间，并在所确定的延时时间到达之后，向对端进行回复，其中，延迟时间与获取到的运算时间正相关。本发明能够有效地、准确地控制对端的拥塞的发生。

Description

IKE协商的拥塞控制方法及装置

技术领域

本发明涉及网络安全技术领域，特别涉及一种IKE协商的拥塞控制方法及装置。

背景技术

IPSec（IPSecurity，IP（InternetProtocol，因特网协议）安全）是IETF（InternetEngineeringTaskForce，因特网工程任务组）制定的为保证在Internet上传送数据的安全加密性能的框架协议。IPSec是一种三层隧道加密协议，为Internet上传输的数据提供了高质量的、可互操作的、基于密码学的安全保证，是一种传统的实现三层VPN（VirtualPrivateNetwork，虚拟专用网络）的安全技术。特定的通信方之间通过建立IPSec隧道来传输用户的私有数据，并在IP层提供数据机密性、数据完整性、数据来源认证以及防重放的安全服务。

IKE（InternetKeyExchange，因特网密钥交换协议）是IPSec的信令协议，为IPSec提供了自动协商交换密钥、建立安全联盟（SecurityAssociation，SA）的服务，能够简化IPSec的使用和管理，大大简化IPSec的配置和维护工作。IKE不是在网络上直接传送密钥，而是通过一系列数据的交换，最终计算出双方共享的密钥，并且即使第三者截获了双方用于计算密钥的所有交换数据，也不足以计算出真正的密钥。IKE具有一套自保护机制，可以在不安全的网络上安全的分发密钥，验证身份，建立IPSec安全联盟。

IKE使用了两个阶段为IPSec进行密钥协商并建立SA，分别称为第一阶段和第二阶段：

（1）第一阶段：在网络上建立IKESA，为其它协议的协商（第二阶段）提供保护和快速协商。通过协商创建一个通信信道，并对该信道进行认证，为双方进一步的IKE通信提供机密性、消息完整性以及消息源认证服务。主要有主模式（MainMode）和野蛮模式（AggressiveMode）两种IKE交换方式。

（2）第二阶段：在第一阶段中建立的IKESA的保护下，为IPSec协商具体的SA，建立用于最终的IP数据安全传输的IPSecSA，采用快速模式（QuickMode）进行协商。

IKE协商过程（包括第一阶段和第二阶段的协商）是比较消耗资源的，包括CPU资源和内存资源，而以CPU资源为主。以IKEv1（IKEversion1，IKE版本1）协议中采用主模式的第一阶段的协商过程为例，协商双方需要进行六条报文的交互（发起端和响应端各自发送三条报文）。由于IKE使用UDP（UserDatagramProtocol，用户数据报协议）协议进行报文发送，而UDP协议是无状态的，因此，IKE协商过程中的状态信息（包括协商双方的身份、协商的标识和算法信息等）都是由协商双方各自的IKE模块自身保存的，通常将用于保存IKE协商过程中的状态信息的数据称为EXCHANGE（简称EXCH），即状态机。状态机是受到报文推动而改变其状态的，每次收到对端的协商报文后，IKE就将一些状态信息保存在对应的EXCH中，并开始构造响应报文，这就形成了一次交互，当所有交互完成后，EXCH就完成了协商过程。

每一次协商都需要创建一个EXCH，如果有多个对端同时与本端进行协商，或者在第一阶段建立的一个IKESA中需要协商多个第二阶段的IPSecSA，那么，系统中就会同时存在多个EXCH，每一个EXCH都会占用一定的CPU资源。当并发存在的EXCH达到了一定的量级时，拥塞就会发生，此时CPU异常繁忙，每一个EXCH都可能需要等待很长的时间才能得到CPU时间，当在一定的时间内（通常这个时间为1分钟左右），协商还未完成，协商就失败了，EXCH中已经记录的信息会被丢弃掉。当拥塞发生时，系统可能仍会不停地创建新的EXCH，而已经存在的EXCH又不能及时完成协商，从而导致最终谁也无法完成协商，系统处于僵死状态。

为了避免上述情况的发生，就需要引入拥塞控制机制，其关键点是：合理控制系统中同时存在的EXCH的个数，保证所有已经创建的EXCH都能够在合理的时间内完成协商。

由于IKE协议自身并没有定义拥塞控制机制，因此，目前各个厂商普遍采用的方式是限制并发的EXCH的个数即，即，限制系统中同时存在的EXCH的个数。具体的，当系统中EXCH的个数达到了预定义的最大EXCH个数时，所有新的协商请求都将被拒绝。由于系统中同时存在的EXCH的个数被严格限制，因此系统进入拥塞状态的可能性被大大降低了。

但是，上述限制并发的EXCH的个数的拥塞控制方法存在以下两个问题：

（1）系统中并发的EXCH的个数无法真实反映出系统当前的繁忙程度，因此，限制并发的EXCH的个数并不能有效地、准确地控制拥塞的发生。

一次IKE协商所消耗的CPU资源是与其使用的加密算法和密钥交换算法相关的，算法越复杂则消耗的CPU时间越多，也更容易造成拥塞。仅仅通过限制并发的EXCH的个数来控制拥塞是无法真实反映出不同EXCH之间的差异的。例如：如果每个EXCH都采用较简单的算法，则即使达到了最大EXCH个数，系统也可能处于空闲状态；相反，如果每个EXCH都采用较复杂的算法，则即使未达到EXCH最大个数，系统也可能已经进入了繁忙状态，甚至是拥塞状态。

（2）没有考虑报文传输时间对协商的影响，因此，限制并发的EXCH的个数无法发挥系统的最大性能。

如果网络带宽较低或者网络本身较繁忙，则IKE协商中的报文需要一个较长的时间才能到达对端，这会导致单位时间内实际可运行的EXCH数较少，此时，即使已经达到了最大EXCH个数，系统亦可能处于空闲状态，无法发挥系统的最大吞吐量。

发明内容

有鉴于此，本发明提供了一种IKE协商的拥塞控制方法及装置，以至少解决现有技术的拥塞控制方法中存在的由于系统中并发的EXCH的个数无法真实反映出系统当前的繁忙程度，因此，限制并发的EXCH的个数并不能有效地、准确地控制拥塞的发生的问题。

本发明的技术方案如下：

一方面，提供了一种IKE协商的拥塞控制方法，包括：在接收到对端发来的第一报文之后，从第一报文中获取对端的运算时间，其中，运算时间是解析接收的第二报文以及针对第二报文构造需要回复的第一报文所消耗的时间，或者是构造第一报文所消耗的时间；判断获取到的运算时间是否超过了预设的运算时间阈值；若判断出超过了运算时间阈值，则根据获取到的运算时间确定延迟时间，并在所确定的延时时间到达之后，向对端进行回复，其中，延迟时间与获取到的运算时间正相关。

另一方面，还提供了一种IKE协商的拥塞控制装置，包括：接收模块，用于接收对端发来的第一报文；获取模块，用于在接收模块接收到第一报文之后，从第一报文中获取对端的运算时间，其中，运算时间是解析接收的第二报文以及针对第二报文构造需要回复的第一报文所消耗的时间，或者是构造第一报文所消耗的时间；判断模块，用于判断获取模块获取到的运算时间是否超过了预设的运算时间阈值；确定模块，用于在判断模块判断出超过了运算时间阈值时，根据获取模块获取到的运算时间确定延迟时间；发送模块，用于在确定模块所确定的延时时间到达之后，向对端进行回复，其中，延迟时间与获取到的运算时间正相关。

本发明的以上技术方案，获取能够反映出对端的繁忙程度的运算时间，判断获取的运算时间是否超过了预设的运算时间阈值，若判断出超过了，则在向对端回复报文时延迟一段时间再回复，延迟的时间与获取的对端的运算时间正相关，由于IKE协商过程是报文驱动的，如果对端收不到本端回复的报文，则本次IKE协商的状态机（即EXCH）实际处于空闲状态，这样，就降低了对端单位时间内活跃的状态机的个数，从而达到了控制拥塞的效果。由于对端的运算时间能够反映出对端当前的真实的繁忙程度，因此，通过延迟回复报文，且延迟时间与对端的运算时间正相关，能够有效地、准确地控制对端的拥塞的发生。

附图说明

图1是根据本发明的实施例一的IKE协商的拥塞控制方法的处理流程图；

图2是根据本发明的实施例二的IKE协商的拥塞控制方法的处理流程图；

图3是根据本发明的实施例三的IKE协商的拥塞控制方法的处理流程图；

图4是根据本发明的实施例的携带发送时间戳或运算时间的报文的载荷的格式示意图；

图5是根据本发明的实施例四的IKE协商过程的流程图；

图6是根据本发明的实施例五的IKE协商的拥塞控制装置的一种结构示意图；

图7是根据本发明的实施例五的IKE协商的拥塞控制装置的另一种结构示意图。

具体实施方式

为了能够有效地、准确地控制IKE协商过程中的拥塞问题，同时最大限度地发挥系统的性能，例如最大吞吐量，达到稳定与性能之间的动态平衡。本发明以下实施例提供了一种IKE协商的拥塞控制方法以及可以应用该方法的装置。该方法可以由IKE协商的发起端和响应端中的任意一端来执行。

本发明以下实施例中使用了传输时间和运算时间这两个概念：

传输时间（TRANSFER_TIME）：报文从一端到达另一端所消耗的时间，即，该接收到该报文的时间与发送该报文的时间的差值。

运算时间（CALCULATE_TIME）：一端主动发送报文时，构造该报文所消耗的时间，或者在接收到一条报文之后，解析该报文以及针对该报文构造需要回复的报文所消耗的时间，包括：报文的加、解密，DH运算等各种算法的运算时间。在IKE协商过程中，无论是第一阶段的协商还是第二阶段的协商，发起端向接收端发送第一条报文时，此为主动发送报文的过程，此时发起端的运算时间为构造该第一条报文所消耗的时间；之后，发起端或响应端接收到对端发来的报文后，向对端回复报文（本发明实施例中回复报文的情况包括：针对接收到的报文回复该报文的响应报文的情况，以及针对接收到的响应报文再发送一条报文的情况），此为回复报文的过程，此时，运算时间即为解析该报文以及针对该报文构造需要回复给对端的报文所消耗的时间。

一个IKE协商过程所消耗的时间主要是由传输时间和运算时间两部分构成，运算时间很长是导致系统拥塞（繁忙）的主要原因。如果一个IKE协商过程所消耗的时间大部分是消耗在传输时间中，则可以认为系统还不繁忙，此时可以加大正在进行的协商（即EXCH）的个数，以提高系统的吞吐量；反之，如果大部分是消耗在运算时间，那么系统就不能再接受更多新的协商了（即更多新的EXCH）了，以免系统进入拥塞状态。本发明以下实施例的核心思想就是根据IKE协商过程中的传输时间和/或运算时间来实时调整协商策略。

实施例一

本发明的实施例一的IKE协商的拥塞控制方法的处理流程，如图1所示，包括以下步骤：

步骤S102，在接收到对端发来的第一报文之后，从第一报文中获取对端的运算时间，其中，运算时间是解析接收的第二报文以及针对第二报文构造需要回复的第一报文所消耗的时间，或者是构造第一报文所消耗的时间；

例如，在IKE协商过程中，发起端或响应端在向对端发送（包括主动发送和回复）一条报文（称为第三报文）时，会将自己的运算时间携带在该第三报文中发送给对端，其中，当该第三报文是发起端发送的第一条报文时，该运算时间是构造该第三报文所消耗的时间，当该第三报文是发起端或响应端在接收到一条报文（称为第四报文）后回复的报文时，该运算时间是解析接收到的第四报文以及针对第四报文构造需要回复的第三报文所消耗的时间。

步骤S104，判断在步骤S102中获取到的运算时间是否超过了预设的运算时间阈值，若判断出超过了运算时间阈值，则进入步骤S106，否则，进入步骤S108；

步骤S106，根据获取到的运算时间确定延迟时间（记为DELAY(x)），并在所确定的延时时间DELAY(x)到达之后，向对端进行回复，即，在回复报文时，延迟DELAY(x)时间回复，其中，延迟时间DELAY(x)与获取到的运算时间x正相关，即x的值越大，则延迟时间DELAY(x)的值越大。

运算时间CALCULATE_TIME是本端评估对端的拥塞（繁忙）程度的依据。如果获取到的对端的运算时间的值很大（即超过了预设的运算时间阈值），则说明对端已经比较繁忙，此时，本端会在回复报文的时候进行一定时间DELAY(x)的延迟，x为获取到的对端的运算时间，DELAY(x)的值为延迟时间。以本端为发起端为例，延迟时间为：DELAY_i(CALCULATE_TIME_r)，即根据响应端的运算时间CALCULATE_TIME_r来获取本端（即发起端）的延迟时间DELAY_i。

在步骤S106中，DELAY(x)的具体运算公式可以根据实际需求以及系统的实时运算情况自动进行调整，例如，DELAY(x)＝α*x，α为参数，本发明对此不做限定。

另外，若本端为发起端，则在步骤S104中还可以不再发起新的到达对端的IKE协商，即，停止向对端发起新的IKE协商，以避免对端进入拥塞状态。

步骤S108，按照现有技术进行回复，即，回复报文时，不进行延迟，而立即回复。

需要说明的是：第一报文、第二报文、第三报文或第四报文并不特指IKE协商过程中发起端或响应端交互的某一条报文，只是为了进行区别而对报文的命名而已。第一报文可以是发起端或响应端主动发送或回复的任意一条报文，而当第一报文是回复的报文时，第一报文是在接收到第二报文后，针对第二报文回复的报文。第三报文也可以是发起端或响应端主动发送或回复的任意一条报文，而当第三报文是回复的报文时，第三报文是在接收到第四报文后，针对第四报文回复的报文。

本发明实施例中，获取能够反映出对端的繁忙程度的运算时间，判断获取的运算时间是否超过了预设的运算时间阈值，若判断出超过了，则在向对端回复报文时延迟一段时间再回复，延迟的时间与获取的对端的运算时间正相关，由于IKE协商过程是报文驱动的，如果对端收不到本端回复的报文，则本次IKE协商的状态机（即EXCH）实际处于空闲状态，这样，就降低了对端单位时间内活跃的状态机的个数，从而达到了控制拥塞的效果。由于对端的运算时间能够反映出对端当前的真实的繁忙程度，因此，通过延迟回复报文，且延迟时间与对端的运算时间正相关，能够有效地、准确地控制对端的拥塞的发生。

实施例二

实施例一中，引入了延迟回复机制可以有效避免系统进入拥塞状态，但这种机制是由对端通过延迟回复报文来控制本端的拥塞问题，而且它无法控制系统中正在进行的协商（即系统中并发的EXCH）的总数，是一种被动防御机制。

本发明实施例二中，通过计算本端的繁忙指数，本端能够识别自身是否已经进入到繁忙状态，当繁忙程度达到了某个预先定义的阈值（即繁忙指数阈值）时，认为本端已经进入了繁忙状态，则可以停止发起或接受新的IKE协商，即，无论是本端主动触发的还是对端触发的新的IKE协商，都将被拒绝。这种机制是在本端实施的主动防御机制，其本质是控制系统中EXCH总数控制。

如图2所示，根据本发明的实施例二的IKE协商的拥塞控制方法的处理流程包括以下步骤：

步骤S202，获取本端当前的繁忙指数；

在实际实施过程中，可以按照以下公式（1）来获取当前的繁忙指数BUSY_EXP：

BUSY_EXP=∑CALCULATE_TIME_x/TIME_CYCLE（1）

其中，TIME_CYCLE为预设的计算周期，CALCULATE_TIME_x为本端中正在进行的第x个IKE协商（即本端中第x个EXCH）在TIME_CYCLE内的消耗的总的运算时间（即在TIME_CYCLE内，各次构造报文，以及，各次解析报文并构造回复报文所消耗的时间的总和），x为变量，x=1,2,...,N，N为本端中正在进行的IKE协商的总数。在实际实施时，TIME_CYCLE可以设置为10秒、20秒、30秒、或60秒等。

由于运算时间能够真实地反映出系统的繁忙程度，通过计算本端系统中所有正在进行的IKE协商在单位时间内的运算时间的总和，作为本端系统当前的繁忙指数，能够真实地反映出本端系统当前的繁忙程度，从而能够在繁忙指数超过预设的繁忙指数阈值时，确定本端系统已经进入了繁忙状态，需要进行相应的拥塞控制，不再向对端发起新的协商以及不再接受对端发起的新的协商，控制了本端系统中正在进行的IKE协商，即并发的EXCH的总数。

步骤S204，判断在步骤S202中获取到的本端当前的繁忙指数的值是否超过了预设的繁忙指数阈值，若是，则进入步骤S206，否则，进入步骤S208；

步骤S206，停止向对端发起新的IKE协商，并停止接受对端发起的新的IKE协商；

步骤S208，按照现有技术，可以继续向对端发起新的IKE协商，并接受对端发起的新的IKE协商。

通过计算系统中所有EXCH在单位时间内的运算时间总和，真实地反映出了系统单位时间内实际运行的EXCH个数，能够充分发挥系统的性能，例如最大吞吐量。

实施例三

EXCH（一个EXCH就对应于一个IKE协商）是为了协商IKESA（在第一阶段的协商中生成）或IPSecSA（在第二阶段的协商中生成）而存在的，正常情况下，本端系统创建EXCH并开始与对端进行报文交互，在所有报文交互均完成之后会生成相应的SA，此时EXCH就完成了使命，会被系统删除，这段时间就是EXCH的存活时间，记为EXCH_DURATION。

因此，应当将系统中每一个EXCH（即系统中正在进行的IKE协商）的EXCH_DURATION控制在一个合理的时间（称为存活时间阈值）内，该存活时间阈值应该满足以下要求：

（1）该时间应该足够长，以便有足够的时间来完成一次完整的IKE协商，如果太短，则协商还未完成而EXCH就被释放了，已经完成的运算就被废弃了，这反而是对系统资源的浪费；

（2）该时间的值应该合理，以便在发生异常的情况下能够及时地释放EXCH。

其中，（1）优先于（2）。

一个EXCH的存活时间阈值EXCH_DURATION(x,y)应该与该EXCH的运算时间和传输时间正相关（成正比例关系），即，传输时间越长、运算时间越长，则该EXCH的存活时间阈值就越长。例如，可以按照以下公式（2）来计算一个EXCH的EXCH_DURATION(x,y)：

EXCH_DURATION(x,y)=T*[1+(x-x1)/x1+(y-y1)/y1]（2）

其中，T为EXCH的存活时间的历史经验值（或平均值），x1为传输时间的历史经验值（或平均值），y1为运算时间的历史经验值（或平均值），x为该EXCH的传输时间，y为该EXCH的运算时间。

显然，也可以使用其他的公式计算一个EXCH的存活时间阈值，具体计算公式本发明并不做限定，可以根据实际需求以及系统的实时运算情况来动态调整。

从而，本发明的实施例三的IKE协商的拥塞控制方法的处理流程包括以下步骤：

步骤S302，针对每一个正在进行的IKE协商（即针对每一个EXCH），判断该IKE协商当前已经存在的时间是否超过了计算得到的该IKE协商的存活时间阈值EXCH_DURATION(x,y)（可以按照上述公式（2）计算得到），若是，则进入步骤S306，否则，返回步骤S302，继续判断下一个EXCH，其中，该计算得到的存活时间阈值EXCH_DURATION(x,y)与该EXCH的运算时间x和传输时间y正相关（即成正比），传输时间为接收到报文的时间与发送该报文的时间的差值；

在实际实施过程中，可以在一个EXCH的报文交互过程中，首次获得了一个x和y后，根据上述公式（2）计算得到该EXCH的EXCH_DURATION(x,y)的值，就固定地使用该值进行步骤S302的判断。也可以在后续得到新的x和y后，使用新的x和y计算得到该EXCH的新的EXCH_DURATION(x,y)值，使用该新的EXCH_DURATION(x,y)值进行步骤S302的判断。本发明对此不做限定。

步骤S306，终止该IKE协商，然后返回步骤S302，继续判断下一个EXCH。

在实际实施时，每一个报文的传输时间的获取方式，可以是发起端或响应端在发送报文时，将报文的发送时间的时间戳携带在该报文中一起发送给对端，对端在接收到该报文时，记录接收到该报文的时间，并将记录的时间与该报文中携带的时间做减法运算，得到两者的差值，该差值即为该报文的传输时间。

本发明的实施例三中，考虑了报文的传输时间，通过一个EXCH的运算时间和传输时间确定了该EXCH的合理的存活时间阈值，并在判断出该EXCH已经存在的时间超过了该存活时间阈值时，终止该EXCH，使得系统中的每一个EXCH能够在发生异常的情况下能够及时地被释放，并释放相应的系统资源。这样，可以通过一个EXCH的运算时间和传输时间，动态调整该EXCH的存活时间阈值，使得一个EXCH的存活时间阈值能够实时地适应该EXCH当前的繁忙程度，从而提高了IKE协商成功的可能性，并为避免拥塞和节约资源做出贡献。

上述的实施例一、二和三，在实际实施时，可以单独实施，也可以任意结合起来实施，本发明对此不做限定。上述实施例一至三中的方法可以应用于各种VPN组网中，例如，星形网络和对等体网络等，并且，与网络协议无关。另外，无论是IKEv1还是IKEv2，亦或是第一阶段的协商或第二阶段的协商，都可以采用上述实施例一至三中的拥塞控制方法。

在实际实施过程中，可以在现有技术的报文中的用于携带厂商相关的信息的VID载荷（VendorID（供应商编号）Payload）中，设置一个特定值，该特定值用于表示本端支持根据本发明的实施例一至三中的拥塞控制方法。例如，该特定值可以为：0x352efb350x7a962dc20x4ecece370xbb03a16e。

如图4所示，本端的运算时间以及发送报文的时间戳可以携带在该报文的载荷中，两者的载荷类型可以定义为234。

其中，TIMETYPE：表示该载荷中记录的是发送时间戳还是运算时间，置为1时，表示该载荷中记录的是发送时间戳；置为2时，表示该载荷中记录的是运算时间；

X_TIME：占用4个字节，表示发送时间戳或运算时间，具体类型由TIMETYPE字段指定。

实施例四

下面以一个具体的例子来说明上述实施例一至三中发起端和响应端获取运算时间和传输时间的方法。

如图5所示，发起端与响应端进行IKE协商的过程如下，其中，仅以交互的前两条报文（第一条报文和第二条报文）为例说明：

1）发起端构建第一条报文，该过程所需的时间记为CALCULATE_TIME_i（发起端的运算时间），该时间记录在第一条报文的载荷中随第一条报文一起传递给响应端，i表示发起端。CALCULATR_TIME_i是响应端评估发起端的繁忙程度的依据；

2）发起端在将构造的第一条报文送入到发送队列后，记录TRANSFER_TIME_i_b（发起端发送报文的时间，即发起端发送的报文的传输时间的起始时间），b表示begin（起始时间）。该时间为发起端传输报文的起始时间，该值记录在第一条报文的载荷中随第一条报文传递给响应端；

3）响应端收到第一条报文，记录TRANSFER_TIME_i_e（发起端发送的报文的传输时间的结束时间，即，响应端接收到该报文的时间），e表示end（结束时间），第一条报文从发起端到响应端的传输时间TRANSFER_TIME_i＝TRANSFER_TIME_i_e-TRANSFER_TIME_i_b。同时，从第一条报文中解析出CALCULATE_TIME_i；

4）解析收到的第一条报文并构建响应报文（第二条报文），这段时间就是CALCULATE_TIME_r，表示响应端的运算时间。该时间记录在载荷中将随第二条报文传递给发起端，CALCULATR_TIME_r是发起端评估响应端的繁忙程度的依据；

5）响应端在将构造的第二条报文送入到发送队列后，记录TRANSFER_TIME_r_b（响应端发送报文的时间，即响应端发送的报文的传输时间的起始时间），b表示begin（起始时间）。该时间为响应端传输报文的起始时间，该值记录在第二条报文的载荷中随第二条报文传递给发起端；

6）发起端收到第二条报文，记录TRANSFER_TIME_r_e（响应端发送的报文的传输时间的结束时间，即，发送端接收到该报文的时间），e表示end（结束时间），第二条报文从响应端到发起端的传输时间TRANSFER_TIME_r＝TRANSFER_TIME_r_e-TRANSFER_TIME_r_b。同时，从载荷中解析出CALCULATE_TIME_r。

至此，发起端获取到了CALCULATE_TIME_r和TRANSFER_TIME_r，而响应端获取到了CALCULATE_TIME_i和TRANSFER_TIME_i。

7）发起端解析第二条报文，并构造第三条报文，后续的过程同上，这里不再赘述。

响应端获取到了CALCULATE_TIME_i之后，就可以判断CALCULATE_TIME_i是否超过了预设的运算时间阈值，若超过了，则响应端延迟一定时间再回复第二条报文，其中，延迟时间与CALCULATE_TIME_i正相关。同时，响应端还可以计算根据各个正在进行的协商的在预设的计算周期内的运算时间来计算系统的繁忙指数，在计算出的繁忙指数超过了预设的繁忙指数阈值时，不再接受发起端发起的新的IKE协商。

同样，发起端获取到了CALCULATE_TIME_r之后，就可以判断CALCULATE_TIME_r是否超过了预设的运算时间阈值，若超过了，则发起端延迟一定时间再回复第三条报文，其中，延迟时间与CALCULATE_TIME_r正相关。同时，发起端还可以计算根据各个正在进行的协商的在预设的计算周期内的运算时间来计算系统的繁忙指数，在计算出的繁忙指数超过了预设的繁忙指数阈值时，不再向响应端发起新的协商。

实施例五

针对本发明的实施例一至四中的方法，本发明的实施例五提供了一种IKE协商的拥塞控制装置，该装置可以是进行IKE协商的设备的一部分，也可以就是进行IKE协商的设备。该装置可以作为发起端（或位于发起端中），也可以作为响应端（或位于响应端中）。在实际应用中，由于进行IKE协商的设备可以是路由器等，因此，该装置可以是路由器，也可以位于路由器中。

如图6所示，该装置可以包括以下模块：接收模块10、获取模块20、判断模块30、确定模块40和发送模块50，其中：

接收模块10，用于接收对端发来的第一报文；

获取模块20，用于在接收模块10接收到第一报文之后，从第一报文中获取对端的运算时间，其中，该运算时间是解析接收的第二报文以及针对第二报文构造需要回复的第一报文所消耗的时间，或者是构造第一报文所消耗的时间；

判断模块30，用于判断获取模块20获取到的运算时间是否超过了预设的运算时间阈值；

确定模块40，用于在判断模块30判断出超过了运算时间阈值时，根据获取模块20获取到的运算时间确定延迟时间；

发送模块50，用于在确定模块40所确定的延时时间到达之后，向对端进行回复，其中，该延迟时间与获取到的运算时间正相关；还用于向对端发送携带有本端的运算时间的第三报文，其中，该运算时间是构造第三报文所消耗的时间，或者是解析接收的第四报文以及针对第四报文构造需要回复的第三报文所消耗的时间。

其中，如图7所示，该装置还可以包括：控制模块60，用于在判断模块30判断出超过了运算时间阈值之后，停止向对端发起新的IKE协商。

另外，获取模块还用于获取本端当前的繁忙指数；判断模块还用于判断获取模块获取到的本端当前的繁忙指数的值是否超过了预设的繁忙指数阈值；控制模块还用于在判断模块判断出超过了预设的繁忙指数阈值时，停止向对端发起新的IKE协商，并停止接受对端发起的新的IKE协商。其中，，获取模块可以按照上述公式（1）获取当前的繁忙指数BUSY_EXP。

另外，判断模块还用于针对每一个正在进行的IKE协商，判断该IKE协商当前已经存在的时间是否超过了计算得到的该IKE协商的存活时间阈值，其中，计算得到的该IKE协商的存活时间阈值与该IKE协商的运算时间和传输时间正相关，传输时间为接收到报文的时间与发送该报文的时间的差值；控制模块还用于在判断模块判断出该IKE协商当前已经存在的时间超过了计算得到的该IKE协商的存活时间阈值时，终止该IKE协商。

综上，本发明以上实施例可以达到以下技术效果：获取能够反映出对端的繁忙程度的运算时间，判断获取的运算时间是否超过了预设的运算时间阈值，若判断出超过了，则在向对端回复报文时延迟一段时间再回复，延迟的时间与获取的对端的运算时间正相关，由于IKE协商过程是报文驱动的，如果对端收不到本端回复的报文，则本次IKE协商的状态机（即EXCH）实际处于空闲状态，这样，就降低了对端单位时间内活跃的状态机的个数，从而达到了控制拥塞的效果。由于对端的运算时间能够反映出对端当前的真实的繁忙程度，因此，通过延迟回复报文，且延迟时间与对端的运算时间正相关，能够有效地、准确地控制对端的拥塞的发生。

本发明能够避免IKE协商过程中的拥塞问题，同时最大限度地发挥系统的性能，达到了稳定与性能之间的动态平衡。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种因特网密钥交换协议IKE协商的拥塞控制方法，其特征在于，包括：

在接收到对端发来的第一报文之后，从所述第一报文中获取所述对端的运算时间，其中，所述运算时间是解析接收的第二报文以及针对所述第二报文构造需要回复的所述第一报文所消耗的时间，或者是构造所述第一报文所消耗的时间；

判断获取到的运算时间是否超过了预设的运算时间阈值；

若判断出超过了所述运算时间阈值，则根据所述获取到的运算时间确定延迟时间，并在所确定的延时时间到达之后，向所述对端进行回复，其中，所述延迟时间与所述获取到的运算时间正相关；

获取本端当前的繁忙指数；

若获取到的本端当前的繁忙指数的值超过了预设的繁忙指数阈值，则停止向所述对端发起新的IKE协商，并停止接受所述对端发起的新的IKE协商。

2.根据权利要求1所述的方法，其特征在于，在判断出超过了所述运算时间阈值之后，还包括：

停止向所述对端发起新的IKE协商。

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

向所述对端发送携带有本端的运算时间的第三报文，其中，该运算时间是构造所述第三报文所消耗的时间，或者是解析接收的第四报文以及针对所述第四报文构造需要回复的所述第三报文所消耗的时间。

4.根据权利要求1至3中任一项所述的方法，其特征在于，

其中，按照以下公式获取当前的繁忙指数BUSY_EXP：

BUSY_EXP＝∑CALCULATE_TIME_x/TIME_CYCLE；

其中，TIME_CYCLE为预设的计算周期，CALCULATE_TIME_x为本端中正在进行的第x个IKE协商在所述TIME_CYCLE内的总的运算时间，x为变量，x＝1,2,...,N，N为本端中正在进行的IKE协商的总数。

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

针对每一个正在进行的IKE协商，判断该IKE协商当前已经存在的时间是否超过了计算得到的该IKE协商的存活时间阈值，其中，所述计算得到的该IKE协商的存活时间阈值与该IKE协商的运算时间和传输时间正相关，所述传输时间为接收到报文的时间与发送该报文的时间的差值；

若判断出超过了所述计算得到的该IKE协商的存活时间阈值，则终止该IKE协商。

6.一种因特网密钥交换协议IKE协商的拥塞控制装置，其特征在于，包括：

接收模块，用于接收对端发来的第一报文；

获取模块，用于在所述接收模块接收到所述第一报文之后，从所述第一报文中获取所述对端的运算时间，其中，所述运算时间是解析接收的第二报文以及针对所述第二报文构造需要回复的所述第一报文所消耗的时间，或者是构造所述第一报文所消耗的时间；

判断模块，用于判断所述获取模块获取到的运算时间是否超过了预设的运算时间阈值；

确定模块，用于在所述判断模块判断出超过了所述运算时间阈值时，根据所述获取模块获取到的运算时间确定延迟时间；

发送模块，用于在所述确定模块所确定的延时时间到达之后，向所述对端进行回复，其中，所述延迟时间与所述获取到的运算时间正相关；

所述获取模块还用于获取本端当前的繁忙指数；

所述判断模块还用于判断所述获取模块获取到的本端当前的繁忙指数的值是否超过了预设的繁忙指数阈值；

所述控制模块还用于在所述判断模块判断出超过了预设的繁忙指数阈值时，停止向所述对端发起新的IKE协商，并停止接受所述对端发起的新的IKE协商。

7.根据权利要求6所述的装置，其特征在于，还包括：

控制模块，用于在所述判断模块判断出超过了所述运算时间阈值之后，停止向所述对端发起新的IKE协商。

8.根据权利要求6所述的装置，其特征在于，

所述发送模块还用于向所述对端发送携带有本端的运算时间的第三报文，其中，该运算时间是构造所述第三报文所消耗的时间，或者是解析接收的第四报文以及针对所述第四报文构造需要回复的所述第三报文所消耗的时间。

9.根据权利要求6至8中任一项所述的装置，其特征在于，

其中，所述获取模块按照以下公式获取当前的繁忙指数BUSY_EXP：

BUSY_EXP＝∑CALCULATE_TIME_x/TIME_CYCLE；

其中，TIME_CYCLE为预设的计算周期，CALCULATE_TIME_x为本端中正在进行的第x个IKE协商在所述TIME_CYCLE内的总的运算时间，x为变量，x＝1,2,...,N，N为本端中正在进行的IKE协商的总数。

10.根据权利要求6至8中任一项所述的装置，其特征在于，

所述判断模块还用于针对每一个正在进行的IKE协商，判断该IKE协商当前已经存在的时间是否超过了计算得到的该IKE协商的存活时间阈值，其中，所述计算得到的该IKE协商的存活时间阈值与该IKE协商的运算时间和传输时间正相关，所述传输时间为接收到报文的时间与发送该报文的时间的差值；

所述控制模块还用于在所述判断模块判断出超过了所述计算得到的该IKE协商的存活时间阈值时，终止该IKE协商。