用于控制分组传输网络中的握手的方法和装置与流程

本发明涉及用于控制分组传送网络中的握手的方法和装置的领域，诸如——但不限于——数据报传输层安全（DTLS）环境中的握手操作。

背景技术：

互联网协议版本6（IPv6）提供了几乎每一个物理对象与互联网的互连。这导致开发新应用的极大可能性，诸如家庭自动化和家庭安全管理、照明系统、智能能量监控和管理、物品和装运追踪、监视和军事、智能城市、监控监控、物流监控和管理。随着无线传感器网络（WSN）中的低功率无线个域网（6LoWPAN）之上的互联网协议（IP）版本6的引入，资源受限设备可以连接到互联网。互联网和IPv6连接的受限设备的这种混合网络形成所谓的“物联网”（IoT）。与其中设备大多强大的互联网不同并且与其中设备大多资源受限的典型WSN不同，IoT中的事物极其多样化。IoT设备可以是典型的传感器节点、灯泡、微波炉、电表、汽车部件、智能电话、个人计算机（PC）或膝上型电脑、强大的服务器机器或者甚至云。

由于IoT中的无线网络的低功率且有损耗的本性，无连接用户数据报协议（UDP）而不是面向流的传输控制协议（TCP）大多被用在IoT中。同步超文本传输协议（HTTP）被设计用于TCP并且对于在基于UDP的IoT中使用是不可行的。因此，受限应用协议（CoAP），HTTP的子集被标准化为用于IoT的web协议。CoAP针对受限设备且针对机器到机器通信而定制。此外，尽管互联网协议安全（IPsec）可以用在IoT中，但是它并非主要设计用于诸如HTTP或CoAP之类的web协议。对于web协议，传输层安全（TLS）或其前身安全套接层（SSL）是最常见的安全解决方案。然而，面向连接的TLS协议仅可以用在面向流的TCP之上，该面向流的TCP不是用于智能对象的优选通信方法。由于低功率无线网络的有损耗本性，难以维持6LoWPAN网络中的连续连接。

针对UDP的TLS的调适被称为数据报TLS（DTLS）。DTLS通过在传输层与应用层之间操作来保证一个机器上的不同应用的端到端（E2E）安全性。除提供认证、机密性、完整性和重播保护的TLS之外，DTLS还在使用网络追踪器（cookie）的情况下提供抵抗拒绝服务（DoS）攻击的保护。虽然DTLS提供应用级安全性，但是它只能在UDP协议之上使用。用于IoT的安全web协议，安全CoAP（CoAP），授权使用DTLS作为用于CoAP的底层安全解决方案。因此，必要的是，在IoT中使能DTLS支持，例如用于安全问题，诸如自展（bootstrap）。术语“自展”从其自大约2005年以来在IETF的6LoWPAN工作组中的使用导出。它可以被定义为配置节点以使得它能够参与正常网络操作的过程。但是也许更引人注目地，在一般使用中，自展的过程意指从非常原始的事物开始在若干步骤中设立复杂的软件环境（诸如早期计算中的二极管矩阵ROM自展）。将该概念转移成安全自展并且将其与以上定义组合，它可能代表使用一些原始最初建钥材料和安全性过程对鲁棒安全节点配置的设置。

在DTLS握手期间，客户端和服务器就用于建立连接的安全性的各种参数达成一致。作为示例，在基于IP的照明网络中，DTLS握手用于在调试期间调试照明设备。

图1示出了关于在客户端（C）和服务器（S）之间利用证书的典型DTLS握手的信令图。每一个消息部分之后的括号中的数字指示这些部分以字节为单位的各自的长度。

为了设立新的连接并且协商安全参数，使用握手协议。客户端通过向服务器发送ClientHello（客户端问候）消息发起握手。该消息包含所支持的密码套件、散列和压缩算法以及随机数。服务器被料想以ServerHello（服务器问候）做出响应，该ServerHello包含服务器已经从客户端提供的密码套件和算法中选择的密码套件和算法以及还有随机数。除其它数据之外，将使用两个随机数来计算主秘密。如果有必要，服务器可以利用包括其证书的服务器证书消息继续以认证它自己。在那种情况下，它还可以发送CertifcateRequest（证书请求）消息，以驱使客户端也进行认证。对于一些密码套件，附加数据对秘密的计算而言可能是必需的，该附加数据可以利用ServerKeyExchange（服务器密钥交换）消息来发送。由于所提及的最后三个消息是可选的，所以ServerHelloDone（服务器问候结束）消息指示何时没有更多的消息从服务器产生。

握手的这个部分对于无连接传输协议是个问题，因为不存在必要的传输连接设置并且攻击者可能仅仅向服务器发送许多ClientHello。这可以用于针对服务器的拒绝服务（DOS）攻击，其将针对每一个ClientHello开始新的会话，从而分配资源；或者通过将服务器的大得多的响应重定向到另一个受害者从而使攻击者的带宽加倍而用于针对该另一个受害者的拒绝服务攻击。为了防止该问题，DTLS使用附加握手消息，其被称为HelloVerifyRequest（问候验证请求）。它响应于ClientHello消息而被发送并且包含任意数据的所谓cookie，优选地是已签名的。服务器将仅发送该消息而不分配任何资源。客户端然后必须以附带有cookie的ClientHello*消息重复。如果cookie可以被验证，因而签名被验证，则服务器知晓客户端没有使用伪造地址，并且由于HelloVerifyRequest消息是小的并且必须在服务器发送任何更多数据之前得到答复，所以再也没有DOS攻击是可能的。在该验证之后，握手将如之前那样继续。

在ServerHelloDone消息之后，如果服务器请求认证，客户端必须利用ClientCertifcate（客户端证书）消息发送其证书。这随后是ClientKeyExchange（客户端密钥交换）消息，其包含其公共密钥或其它加密数据，这取决于所使用的密码套件。也取决于密码套件的是，用于验证签名的证书的CertifcateVerify（证书验证）消息是否必须发送。在这一点上，两个对等体具有足够的信息以计算主秘密。因而，客户端发送ChangeCipherSpec（改变密码规范）消息以宣布经协商的参数和秘密将从现在起使用。其最后的消息为Finished（完成）消息，其包含在整个握手之上计算的散列值并且已经被加密。服务器也通过发送ChangeCipherSpec和Finished消息来结束握手。

由于DTLS握手的目的是发起安全连接，所以非常关键的是具有成功DTLS握手以开始通信。DTLS握手的性能，诸如延迟和成功率，很大程度上取决于网络状态，诸如拥堵、无线丢失、分组丢失率等。它还取决于DTLS握手的安全模式，例如具有预共享密钥（PSK）、原始公共密钥或者证书的DTLS，因为不同模式具有要传输的不同数目的分组。

延迟随着分组丢失率的增大而增大。对于其中需要传输更多分组的DTLS-证书模式，延迟比其它模式更快地增大。具有返回确认模式的PSK一次发送一个分组并且等待确认的回复。如果不存在返回的ACK，则分组将再次被发送。因此，该模式的延迟比其它PSK方法大得多。

由于DTLS握手的目标是发起安全连接，所以非常关键的是具有成功的DTLS握手以开始通信。当DTLS握手用在UDP通信中时，用于DTLS握手的分组可能在传输中丢失。为了确保可靠的接收，可以使用具有确认（ACK）的DTLS，其中ACK消息由接收器生成和发送。然而，ACK分组也可能丢失。当存在诸如无线丢失或拥堵丢失之类的一些种类的分组丢失时，握手延迟可能延长。当存在诸如证书等之类的更多要发送的消息时，延迟可能大得多，这将降低握手的成功率。因而，具有确认的DTLS生成更多延迟，尤其是在传输更多分组时。此外，信道分组丢失和丢失率不易于测量。

因而，当前DTLS握手模式或策略在不同的分组丢失率中具有不同的性能。分组丢失的原因还对DTLS握手具有显著影响。因此必要的是考虑分组丢失的原因，诸如拥堵丢失以及无线丢失，以实现DTLS握手的更好成功率并且改进DTLS握手的性能。特别地对于具有证书的DTLS握手，存在要在DTLS握手期间交换的更多分组。分组丢失模式和分组丢失率对DTLS的成功率和握手延迟具有巨大影响。

本发明的目标是提出一种动态ACK以缩短延迟并且使用该ACK估计分组丢失并调节传输策略。

技术实现要素：

本发明的目的是提供一种具有改进的性能的握手操作。

该目的通过如权利要求1中要求保护的装置、通过如权利要求11中要求保护的方法并且通过如权利要求12中要求保护的计算机程序产品来实现。

相应地，握手性能可以在基于分组的网络中通过计算网络分组丢失率并且估计网络分组丢失的原因来改进，以便基于对分组丢失和可能原因的检测改变握手策略。作为结果，握手的成功率可以增大并且握手延迟可以减小。

根据第一选项，检测器可以适于基于所接收的分组的序列来检测分组丢失。在更特定的示例性DTLS环境中，检测器可以适于基于DTLS握手信令的ClientHello消息的序列来检测分组丢失。由此，可以提供直截了当的方法以检测分组丢失。

根据可以与第一选项组合的第二选项，检测器可以适于将拥堵丢失估计为所检测的分组丢失的原因，如果所接收的连续分组之间的延迟变化或者如果在所接收的连续分组之间存在混乱的话。该措施使能将拥堵可靠估计为所检测的分组丢失的原因。

根据可以与以上第二选项组合的第三选项，检测器可以适于估计无线丢失，如果所检测的分组丢失随机分布或者如果所接收的连续分组之间的延迟几乎相等的话。该措施使能将无线丢失可靠估计为用于所检测的分组丢失的原因。

根据可以与以上第二选项组合的第四选项，如果检测器已经估计出无线丢失，则控制器可以适于估计分组丢失率，基于分组丢失率估计用于握手的剩余时间，将剩余时间与预定的握手超时进行比较，并且在所估计的剩余时间小于预定的握手超时的情况下与用于握手的所估计的剩余时间和预定的握手超时之间的比率成比例地增大分组传输的传输速率。因而，握手策略可以针对作为分组丢失的原因的无线丢失进行调适以便由此改进握手性能。

根据可以与以上第三选项组合的第五选项，如果检测器（S1，C1）已经估计出拥堵丢失，则控制器可以适于估计分组丢失率，基于分组丢失率来估计用于握手的剩余时间，将剩余时间与预定的握手超时进行比较，并且在所估计的剩余时间小于预定的握手超时增大传输间隔并且减小分组传输的传输速率。因而，握手策略可以针对作为分组丢失的原因的拥堵进行调适以便由此改进握手性能。

根据可以与以上第三或第五选项组合的第六选项，如果检测器已经估计出拥堵丢失并且如果装置位于分组传输的服务器侧上，则控制器可以适于通知分组传输的客户端侧以延长握手超时。由此，在拥堵丢失的情况下延长握手超时以由此降低传输速率以便可能地移除拥堵情形。

根据可以与以上第一到第六选项中的任一个组合的第七选项，控制器可以适于通过计算总传输时间直至接收到预定的握手消息的最后确认并且使用以下等式来估计分组丢失率

其中N_S表示所计算的总传输时间并且P_L表示所估计的分组丢失率。因而，握手性能可以通过以仅要求确认特定握手消息的这种方式使用混合传输方法来改进。具有长分组的消息不需要得到确认，这缩短了握手的延迟。此外，确认可以用于估计分组丢失率。所计算的分组丢失率用于调节传输策略。在特定的基于DTLS的示例中，预定的握手消息可以是DTLS握手信令的ClientHello消息。

要指出的是，以上系统可以基于具有分立硬件组件、集成芯片或芯片模块的布置的分立硬件电路、或者基于由软件例程或程序控制的信号处理设备或芯片而实现，该软件例程或程序存储在存储器中、写入在计算机可读介质上或者从诸如互联网之类的网络下载。

应当理解，权利要求1的系统、权利要求11的方法和权利要求12的计算机程序产品可以具有类似和/或相同的优选实施例，特别地如在从属权利要求中所限定的优选实施例。

应当理解，本发明的优选实施例还可以是从属权利要求或以上实施例与相应独立权利要求的任何组合。

本发明的这些和其它方面将根据下文描述的实施例显而易见并且将参照下文描述的实施例进行阐述。

附图说明

在以下附图中：

图1示出了具有证书的DTLS握手的示意性信令图；

图2示出了根据第一实施例的客户端与服务器之间的非确认分组传输的示意性框图；

图3示出了用于根据第一实施例的客户端与服务器之间的非确认分组传输的切换控制方案的示意性系统架构；

图4示出了用于根据第一实施例的非确认分组传输的切换控制方案的服务器侧处理的流程图；

图5示出了如在第一实施例中使用的ClientHello消息的第一消息结构；

图6示出了用于根据第一实施例的非确认分组传输的切换控制方案的客户端侧处理的流程图；

图7示出了根据第二实施例的客户端与服务器之间的确认分组传输的示意性框图；

图8示出了如在第二实施例中使用的ClientHello消息的第二消息结构；

图9示出了根据第二实施例的客户端与服务器之间的切换交互的信令图；以及

图10示出了用于根据第二实施例的确认分组传输的切换控制方案的服务器侧处理的流程图。

具体实施方式

现在基于具有服务器与客户端之间的适应性改变的握手策略的DTLS握手来描述本发明的实施例。

图2示出了根据第一实施例的客户端（C）10与服务器（S）20之间的非确认分组传输的示意性框图。在图2的情况下，从客户端10向服务器20传输分组15。服务器检查所接收的分组的序列以便确定丢失的分组17。

图3示出了用于根据第一实施例的客户端与服务器之间的非确认分组传输的切换控制方案的示意性系统架构。在服务器和客户端侧二者中，存在两个功能块。第一功能块是用于分组丢失的检测的检测块（或检测器）C1、S1。该功能块基于所接收的分组来检测分组丢失并且估计分组丢失率。第二功能块是控制块（或控制器）C2、S2以用于改变在客户端（C）与服务器（S）之间针对客户端消息CM1和CM2以及针对服务器消息SM1和SM2的传输和接收策略（即，握手策略）。该功能块适于根据所检测的分组丢失来改变握手策略。

因为DTLS握手消息可能丢失，所以DTLS需要用于重传的机制。DTLS使用每一个端点处的单个计时器来实现重传。每一个端点保持重传其最后的消息直至接收到回复。根据DTLS协议，用于预定的握手超时的初始计时器值可以设定成1s（在RFC 2988中限定最小值）并且该值可以在每一个重传处加倍，直到不小于（如在RFC 2988中限定的）60秒的最大值。当前计时器值可以保留直至发生无丢失的传输，在该时间处，该值可以重置为初始值。在长时段的空闲（不小于当前计时器值的10倍）之后，计时器可以重置为初始值。其中这可能发生的一种情形是当在大量数据传递之后使用再握手时。

图4示出了用于根据第一实施例的非确认分组传输的切换控制方案的服务器侧处理的流程图。更具体地，图4的处理涉及服务器侧上的分组丢失检测和策略改变机制。

在步骤S401中，服务器根据DTLS协议（即，DTLS握手）基于握手过程的ClientHello和ClientHello*消息的所接收的分组而检测分组丢失。由于每一个分组具有序列号，所以服务器可以检测来自分组的序列的分组丢失。

然后在步骤S402中，做出关于分组丢失的类型的决定。该过程根据以下准则确定丢失类型：

- 在所接收的ClientHello与ClientHello*消息之间是否存混乱。如果是，则存在拥堵丢失。

- 两个连续接收的分组之间的延迟变化了吗。如果是，则存在拥堵丢失。

- 分组丢失随机地分布或者延迟几乎相等吗。如果是，则存在无线丢失。

如果在步骤S402中确定了无线丢失，则过程分支到步骤S413，在步骤S413中通过使用以下等式基于所接收的分组来估计分组丢失率：

(1)。

然后在步骤S414中，通过使用以下等式来估计用于握手的剩余时间：

(2)

其中 (3)

并且其中τ表示传输间隔且，并且其中R表示传输速率。

在等式（3）中，标示用于通过接收器成功地接收到m个分组的预期传输次数。接收器具有缓冲器以存储所接收的分组。每一个分组具有序号。每一次一起发送m个分组。该传输策略可以在规范RFC 4347“Datagram Transport Layer Security”(http://tools.ietf.org/html/rfc4347)的章节4.2.3中找到。

已知的是，预期传输次数取决于分组丢失率。其可以示出：

(4)

(5)

(6)。

作为可替换方案，用于和的值可以从计算机模拟获得。

然后，在步骤S415中，将所估计的剩余握手时间D_e和预定的握手超时D_r进行比较。如果在步骤S415中确定所估计的剩余握手时间D_e小于预定的握手超时D_r，即D_e<D_r，则过程分支到步骤S416并且传输速率不改变。否则，过程分支到步骤S417并且增大传输速率。作为示例，增大的量可以通过使用以下等式来计算：

(7)。

否则，如果在步骤S402中确定拥堵丢失，则过程分支到步骤S403，在步骤S403中通过使用以上等式（1）基于所接收的分组来估计分组丢失率。在此之后，在步骤S404中，通过使用以上等式（2）和（3）来估计用于握手的剩余时间。

然后，在步骤S405中，将所估计的剩余握手时间D_e和预定的握手超时D_r进行比较。如果在步骤S405中确定所估计的剩余握手时间D_e小于预定的握手超时D_r，即D_e<D_r，则过程分支到步骤S406并且传输速率不改变。否则，过程分支到步骤S407，在步骤S407中以预定的间隔μ一个接一个地发送27个分组，其中μ＞一个节点的过程延迟。然后，增大传输间隔并且减小传输速率。作为示例，减小的量可以通过使用以下等式来计算：

(8)。

此外，可以通知客户端侧以延长握手超时。作为示例，握手超时可以加倍，即。该通知可以限定为DTLS握手的ServerHello消息中的扩展。

图5示出了如在第一实施例中使用的ClientHello消息的第一消息结构。ClientHello消息包含2个字节（2B）长度的协议版本（PV）、具有时间（t）和随机（R）参数的32个字节（32B）长度的随机部段（Rd）、0到32个字节长度的会话身份（S-ID）、2个字节长度的密码套件参数（CS）、1个字节长度的压缩方法（CM）参数、以及具有类型（T）和扩展（Ext）部分的扩展（EXT）字段。

图6示出了用于根据第一实施例的非确认分组传输的切换控制方案的客户端侧处理的流程图。

在步骤S601中，执行客户端侧上的分组丢失确定。客户端侧上的确定可以基于来自服务器侧的关于分组丢失的通知，或者基于在从服务器接收的分组的基础上对分组丢失的直接检测，所述从服务器接收的分组包括服务器消息，诸如HelloVerifyRequest、Certificate（证书）和ServerHelloDone。由于每一个分组具有序列号，客户端可以检测来自分组的序列的分组丢失。

然后，在步骤S602中，做出关于丢失类型的决定。丢失类型可以基于以下准则：

- 两个连续接收之间的延迟变化了吗。如果是，则存在拥堵丢失。

- 分组丢失随机地分布或者延迟几乎相等吗。如果是，则存在无线丢失。

如果在步骤S602中确定无线丢失，则过程分支到步骤S613，在步骤S613中通过使用以上等式（1）基于所接收的分组来估计分组丢失率。

然后，在步骤S614中，通过使用以下等式来估计用于握手的剩余时间：

(9)

其中 (10)

并且其中τ表示传输间隔且，并且其中R表示传输速率。

在等式（10）中，标示用于通过接收器成功接收m个分组的预期传输次数，如以上结合等式（4）至（6）所解释。作为可替换方案，用于的值可以从计算机模拟获得。

然后，在步骤S615中，将所估计的剩余握手时间D_e和预定的握手超时D_r进行比较。如果在步骤S615中确定所估计的剩余握手时间D_e小于预定的握手超时D_r，即D_e<D_r，则过程分支到步骤S616并且传输速率不改变。否则，过程分支到步骤S617并且增大传输速率。作为示例，增大的量可以通过使用以上等式（7）来计算。

否则，如果在步骤S602中确定拥堵丢失，则过程分支到步骤S603，在步骤S603中通过使用以上等式（1）基于所接收的分组来估计分组丢失率。在此之后，在步骤S604中，通过使用以上等式（2）和（3）来估计用于握手的剩余时间。

然后，在步骤S605中，将所估计的剩余握手时间D_e和预定的握手超时D_r进行比较。如果在步骤S605中确定所估计的剩余握手时间D_e小于预定的握手超时D_r，即D_e<D_r，则过程分支到步骤S606并且传输速率不改变。否则，过程分支到步骤S607，在该步骤中以预定的间隔μ一个接一个地发送24个分组，其中μ＞一个节点的过程延迟。然后，增大传输间隔并且减小传输速率。作为示例，减小的量可以通过使用以上等式（5）计算。

此外，握手超时可以延长。作为示例，握手超时可以加倍，即。

图7示出了根据第二实施例的客户端（C）10与服务器（S）20之间的确认分组传输的示意性框图。

在第二实施例中，提出使用动态确认消息或分组（ACK）16来确认分组15的接收并且由此缩短延迟。此外，ACK 16可以用于估计分组丢失并且相应地调节传输策略。在服务器和客户端侧二者中，现在存在三个功能块以改进基于IP的网络中的DTLS性能。第一功能块是用于提供确认的适应性请求的请求块（或者请求器）。第二块是可以计算网络分组丢失率并且例如通过使用以上等式（4）至（6）基于所计算的分组丢失率来估计网络分组丢失的原因的检测模块（或检测器）。第三块是可以基于分组丢失的检测和丢失的可能原因来改变DTLS握手策略的控制块（或控制器）。

图8示出了如在第二实施例中使用的ClientHello消息的第二消息结构。除图5的字段和参数之外，ClientHello消息的第二消息结构包含0到32个字节长度的cookie字段（CK）。针对ACK的适应性请求可以在扩展字段（EXT）中限定和用信号告知，例如作为具有值“0”或“1”的二进制标志。服务器然后可以以下列方式响应于ACK请求的接收而采取动作：

ACK = 1 服务器需要向客户端发送回ACK；

ACK = 0 服务器不需要向客户端发送回ACK。

图9示出了根据第二实施例的客户端与服务器之间的切换交互的信令图。初始ClientHello消息被分成两个部分p1和p2，这二者分别由ACK和HelloVerifyRequest消息确认。此外，随后的ClientHello*消息被分成三个部分p1到p3，其中两个由ACK确认并且最后一个由服务器消息确认，例如ServerHello。

在根据第二实施例的握手交互信令中，仅消息ClientHello和ClientHello*包括ACK请求。客户端和服务器可以使用所发送的分组和所接收的分组的记录来检测分组丢失并且估计分组丢失率。

图10示出了用于根据第二实施例的确认分组传输的切换控制方案的服务器侧处理的流程图。客户端侧可以通过检测ACK和HelloVerifyRequest消息而具有类似方法。

在步骤S1001中，检测分组丢失。以下方法可以用于检测客户端侧和服务器侧二者处的分组丢失。

如果检测到超时，则客户端需要重传分组。客户端可以计算整体传输次数N_c，直到从服务器接收到ClientHello*的最后ACK。

客户端然后可以通过使用以下等式来估计分组丢失率：

(11)

(12)。

在接收到ClientHello消息的第一部分（p1）之后，服务器将发送ACK。如果存在超时，则服务器需要重传分组。服务器可以计算整体传输次数N_s，直到从客户端接收到ClientHello*消息的部分3（p3）。服务器然后可以通过使用以下等式来估计分组丢失率：

(13)

(14)。

客户端和服务器二者然后将根据所检测的分组丢失的结果来改变传输策略。

在步骤S1002中，做出关于丢失类型的决定。该过程根据以下准则确定丢失类型：

- 所接收的ClientHello和ClientHello*消息之间存在混乱吗。如果是，则存在拥堵丢失。

- 两个连续接收的分组之间的延迟变化了吗。如果是，则存在拥堵丢失。

- 分组丢失随机地分布或者延迟几乎相等吗。如果是，则存在无线丢失。

如果在步骤S1002中确定无线丢失，则过程分支到步骤S1013，在步骤S1013中如以上结合等式（13）和（14）解释的那样估计分组丢失率。然后，在步骤S1014中，通过使用以下等式来估计用于握手的剩余时间：

(15)

其中 (16)

并且其中τ表示传输间隔且，并且其中R表示传输速率。

在等式（16）中，标示用于通过接收器成功接收到m个分组的预期传输次数，如以上结合等式（4）至（6）所解释。作为可替换方案，用于和的值可以从计算机模拟获得。

然后，在步骤S1015中，将所估计的剩余握手时间D_e和预定的握手超时D_r进行比较。如果在步骤S1015中确定所估计的剩余握手时间D_e小于预定的握手超时D_r，即D_e<D_r，则过程分支到步骤S1016并且传输速率不改变。否则，过程分支到步骤S1017并且增大传输速率。作为示例，增大的量可以通过使用以上等式（7）来计算。

否则，如果在步骤S1002中确定拥堵丢失，则过程分支到步骤S1003，在步骤S1003中通过使用以上等式（1）基于所接收的分组来估计分组丢失率。在此之后，在步骤S1004中，通过使用以上等式（13）和（14）来估计用于握手的剩余时间。

然后，在步骤S1005中，将所估计的剩余握手时间D_e和预定的握手超时D_r进行比较。如果在步骤S1005中确定所估计的剩余握手时间D_e小于预定的握手超时D_r，即D_e<D_r，则过程分支到步骤S1006并且传输速率不改变。否则，过程分支到步骤S1007，在该步骤中以预定的间隔μ一个接一个地发送分组，其中μ＞一个节点的过程延迟。然后，增大传输间隔并且减小传输速率。作为示例，减小的量可以通过使用以上等式（8）来计算。

此外，可以通知客户端侧以延长握手超时。作为示例，握手超时可以加倍，即。该通知可以限定为DTLS握手的ClientHello*消息的部分3或者ServerHello消息中的扩展。

因而，根据第二实施例，通过以仅ClientHello和ClientHello*要求ACK的这种方式使用混合传输方法来改进DTLS握手性能。具有长分组的消息，诸如Certificate，不需要ACK，这缩短了握手的延迟。此外，分组和ACK用于估计分组丢失率。所计算的分组丢失率用于调节传输策略以便改进DTLS握手的性能。

总而言之，已经描述了用于控制握手操作的方法和装置。DTLS是基于IP的物联网中的重要安全协议。DTLS握手的性能可能受网络状态、通信量和分组丢失率等的显著影响。因此，建议评估分组丢失率并且估计分组丢失的原因。然后，可以基于网络状态和分组丢失的检测适应性地改变DTLS握手策略。作为结果，DTLS握手的成功率和延迟可以得到改进。可以以混合方式使用确认和非确认模式以评估分组丢失率和估计分组丢失的原因并且最终改进DTLS握手的性能。

尽管已经在附图和前面的描述中详细图示和描述了本发明，但是这样的图示和描述将被认为是说明性的或示例性的而非限制性的。本发明不限于所公开的实施例。所提出的握手处理可以应用于其它基于IP的安全协议或IP或照明控制或物联网握手相关应用中并且可能地在这些应用中被标准化。

本领域技术人员在实践要求保护的发明时，通过研究附图、公开内容和随附权利要求，可以理解和实现对所公开的实施例的其它变形。在权利要求中，词语“包括”不排除其它元件或步骤，并且不定冠词“一”或“一个”不排除多个。单个处理器或其它单元可以履行在权利要求中叙述的若干项的功能。在相互不同的从属权利要求中叙述某些措施的仅有事实并不指示这些措施的组合不能用于获益。

前面的描述详述了本发明的某些实施例。然而，将领会到，前面的内容在文本中看起来无论多么详细，本发明都可以以许多方式来实践，并且因此不限于所公开的实施例。应当指出，在描述本发明的某些特征或方面时对特定术语的使用不应当被认为是暗示该术语在本文中重新限定为限于包括该术语与其相关联的本发明的特征或方面的任何特定特性。

单个单元或设备可以履行在权利要求中叙述的若干项的功能。在相互不同的从属权利要求中叙述某些措施的仅有事实并不指示这些措施的组合不能用于获益。

像在图4、6和10中指示的那些操作那样的所述操作可以实现为计算机程序的程序代码构件和/或专用硬件。计算机程序可以存储和/或分布在与其它硬件一起提供或者作为其它硬件的部分提供的适当的介质上，诸如光学存储介质或固态介质，但是也可以以其它形式分布，诸如经由互联网或其它有线或无线电信系统。