跳到主要内容

Appendix B. 多个 DTLS 握手的性能

Appendix B. 多个 DTLS 握手的性能​

对于执行内联密钥管理的安全协议, 如 TLS, DTLS 和 SSH, 标准做法是为每个底层网络信道 (TCP 连接, UDP 主机/端口四元组等) 创建单独的安全关联 (security association). 这有两个优点: 简单性, 以及每个信道的安全上下文相互独立.

在 RTP 安全的上下文中, 针对此策略的开销提出了三个担忧:

B.1 公钥操作开销​

第一个担忧是, 为每个信道执行单独的公钥操作会带来额外的性能开销. 此处的常规过程 (TLS 和 DTLS 使用的过程) 是建立一个主上下文, 随后可用它为新的关联派生新的流量密钥. 在 TLS/DTLS 中, 这称为 "session resumption", 并且可以在对等方之间透明协商.

B.2 网络带宽开销​

第二个担忧是, 建立后续连接以及为现有连接重新握手 (用于重新加密钥) 会产生网络带宽开销. 特别是, 有人担心这些信道会只有非常窄的容量需求, 且容量完全分配给媒体, 从而被重新握手流量溢出. 对 TLS 中重新握手 (带恢复) 大小的测量表明, 如果提供完整的密码套件选择, 其大小约为 300-400 字节. (由于证书和密钥材料交换, 完整握手的大小约大 1-2 千字节.)

B.3 额外往返​

第三个担忧是建立第二个, 第三个, ... 信道时相关的额外往返. 在 TLS/DTLS 中, 这些操作都可以并行完成, 但为了利用 session resumption, 它们应在第一个信道建立后执行.

对于两个信道, 这会得到类似下面的梯形图 (括号中的数字是媒体信道编号):

Alice                                   Bob
-------------------------------------------
                  <-       ClientHello (1)
ServerHello (1)    ->
Certificate (1)
ServerHelloDone (1)
                  <- ClientKeyExchange (1)
                      ChangeCipherSpec (1)
                              Finished (1)
ChangeCipherSpec (1)->
Finished         (1)->
                                            <--- Channel 1 ready

                  <-       ClientHello (2)
ServerHello (2)    ->
ChangeCipherSpec(2)->
Finished(2)        ->
                  <-  ChangeCipherSpec (2)
                              Finished (2)
                                            <--- Channel 2 ready

因此, 在 Channel 1 就绪后, Channel 2 就绪前还会额外增加 1 个 RTT (round-trip time). 如果对等方可能愿意放弃恢复, 它们可以交错执行握手, 从而使信道同时就绪.

最后于 更新