DTLS 当前（版本 1.2）在RFC 6347中定义，通过解释与 TLS 1.2 ( RFC 5246 ) 的差异。大多数 TLS 元素都被重用，只有最小的差异。

上下文是客户端和服务器想要互相发送大量数据作为“数据报”；他们真的都想发送一个很长的字节序列，有一个定义的顺序，但不享受TCP的奢侈。TCP 为字节提供了可靠的双向隧道，所有字节最终以与发送者使用的顺序相同的顺序到达接收者；TCP 通过确认消息、传输超时和重新发送的复杂组合来实现这一点。这允许 TLS 简单地假设数据在正常情况下不会受到影响；换句话说，TLS 认为足以检测到更改，因为此类更改仅在受到攻击时才会发生。

另一方面，DTLS 处理可能丢失、重复或以错误顺序接收的数据报。为了解决这个问题，DTLS 使用了一些额外的机制和一些额外的宽大处理。

主要区别在于：

1. 显式记录。使用 TLS，您有一个长字节流，TLS 实现决定将其拆分为它认为合适的记录；这种拆分对应用程序是透明的。DTLS 并非如此：每个 DTLS 记录都映射到一个数据报。以记录为基础接收和发送数据，一条记录要么完全接收，要么根本不接收。此外，应用程序必须自己处理路径 MTU 发现。

2. 显式序列号。TLS 记录包括一个保证记录完整性的MAC，MAC 输入包括一个记录序列号，从而验证没有记录丢失、重复或重新排序。在 TLS 中，这个序列号（一个 64 位整数）是隐含的（这总是比前一个记录多一个）。在 DTLS 中，序列号在每条记录中都是明确的（因此每条记录有额外的 8 字节开销——没什么大不了的）。序列号进一步分为 16 位“纪元”和 48 位子序列号，以更好地处理密码套件重新协商。

3. 更改是可以容忍的。数据报可能会丢失、重复、重新排序，甚至被修改。这是 TLS 厌恶的“生活事实”，但 DTLS 接受。因此，客户端和服务器都应该容忍一点滥用；他们使用“窗口”机制来理解“有点早”的记录（如果他们以 1 2 5 3 4 6 的顺序接收记录，则窗口会将记录“5”保留在缓冲区中，直到记录 3 和 4已收到，或接收方决定记录 3 和 4 已丢失，应跳过）。可能会警告重复，以及 MAC 不匹配的记录；但是，一般来说，异常记录（丢失、重复、过早超出窗口范围、太旧、修改......）会被简单地删除。

   这意味着 DTLS 实现不会（并且实际上不能）区分正常的“噪音”（可能发生的随机错误）和主动攻击。他们可以使用一些阈值（如果错误太多，警告用户）。

4. 无状态加密。由于记录可能会丢失，因此加密不能使用随每条记录修改的状态。实际上，这意味着没有 RC4。

5. 没有经过验证的终止。DTLS 没有像 TLS 对close_notify警报消息所做的那样的已验证连接结束的概念。这意味着当接收方停止从对等方接收数据报时，它无法知道发送方是否自愿停止发送，或者其余数据是否丢失。请注意，这样的事情被认为是 SSL 2.0 的大罪之一，但对于 DTLS，这似乎没问题。如果需要，这取决于在DTLS中传输的任何数据格式，以提供显式终止。

6. 碎片化和再发射。握手消息可能会超过自然数据报的长度，因此可能会被拆分为多个记录。握手消息的语法被扩展以管理这些片段。片段处理需要缓冲区，因此 DTLS 实现可能需要比 TLS 实现更多的 RAM（即，针对 RAM 稀缺的嵌入式系统优化的实现；桌面和服务器的 TLS 实现只需分配足够大的缓冲区，DTLS 将对他们来说没有更糟）。重新发送是通过状态机完成的，这比直接的 TLS 握手要复杂一些（但 RFC 对其进行了很好的描述）。

7. 防止 DoS/欺骗。由于数据报可以“按原样”发送，因此会受到 IP 欺骗：作恶者可以发送带有虚假源地址的数据报。特别是一条ClientHello消息。如果 DTLS 服务器在收到 a 时分配资源ClientHello，则有充足的DoS空间。在 TLS 的情况下，aClientHello只发生在 TCP 的三次握手完成之后，这意味着客户端使用了它实际可以接收的源 IP 地址。能够在不显示真实 IP 的情况下对服务器进行 DoS 攻击是一种强大的武器；因此 DTLS 包括一个可选的防御。

   DTLS 中的防御机制是“cookie”：客户端发送它ClientHello的 ，服务器用HelloVerifyRequest包含不透明 cookie 的消息响应该消息，客户端必须将其作为第二个 ClientHellocookie 发送回。服务器应安排一种无需存储状态即可验证的 cookie；即带有时间戳和 MAC 的 cookie（奇怪的是，RFC提到了这种机制，但没有完全指定它——某些实现可能会出错）。

   这种 cookie 机制实际上是对 TCP 三次握手的模拟。它意味着一个额外的往返，即将 DTLS 带回 TLS-over-TCP 性能以进行初始握手。

除此之外，DTLS 类似于 TLS。TLS 的非 RC4 密码套件适用于 DTLS。DTLS 1.2 可以防止类似 BEAST 的攻击，因为与 TLS 1.2 一样，它在使用 CBC 加密时包括每条记录的随机 IV。

总而言之，DTLS 额外功能在概念上是从 TCP 导入的（接收窗口、用序列号重组、重新发送、连接 cookie ......）抛出一个普通的 TLS（一个重要的遗漏是缺少确认消息）。该协议在更改方面更为宽松，并且不包括经过验证的“传输结束”（但 DTLS 应该在无论如何都没有真正意义的情况下使用）。

DTLS 的应用领域确实与 TLS 不同；它旨在应用于损失不如延迟重要的数据流应用，例如 VoIP 或实时视频馈送。对于给定的应用程序，要么 TLS 比 DTLS 更有意义，要么相反；最佳实践是选择适当的协议。

DTLS 和传输层安全 (TLS) 协议之间存在关键差异，应用程序程序员需要注意其他答案未命中/暗示不存在！

DTLS 协议为数据报协议提供通信隐私。与在撰写本文时（存档）时现有的高度评价的 LONG 和一般信息丰富的答案相反，当 TCP 不可用时（由不享受 TCP 奢侈的应用程序使用）不使用DTLS 。主要区别在于，虽然 DTLS 实现确实处理数据包重新排序和丢失的问题，它只这样做用于 DTLS 握手（和密码选择）的数据包。但是，包含有效负载（应用程序数据）的 DTLS 数据包传递其有效负载并不比封装它们的 DTLS 数据包（通常是 UDP）更可靠。好处是 DTLS 交付应用程序数据的速度更快，延迟更低。加分项：这就是为什么 DTLS 用于保护损失不如延迟重要的流媒体应用，例如 VoIP、实时视频馈送和 MMO 游戏。TLS 旨在通过端到端的经过身份验证的加密可靠地传递数据流。DTLS 旨在交付经过身份验证和端到端加密的应用程序数据，但延迟低于保证所有应用程序数据交付时所能实现的延迟。

此外，虽然 DTLS 协议 (v1.2) 源自 TLS 协议 (v1.2) 并声称“提供等效的安全保证”，但它并没有。2 早在 2013 年，研究人员就发现了 DTLS 实施和 DTLS 协议本身的主要安全缺陷，这些缺陷已经得到纠正，至少在 GnuTLS 和 OpenSSL 实施中是这样。2

PS：DTLS 1.3 正在开发中。3