SSL 和 TLS 在使用方式上几乎没有什么区别。然而，SSL/TLS 的预先建立和使用诸如以下命令之间存在根本区别：STARTTLS。有时，“TLS”与“SSL”相对，表示“使用 STARTTLS 模式”，但这是不正确的。
预先 TLS/SSL
在这种情况下，客户端会先于其他任何事情启动 TLS/SSL 连接，因此首先发生 SSL/TLS 握手。一旦安全套接字启动，使用它的应用程序就可以开始发送 TLS 之上协议的各种命令（例如 HTTP、此模式下的 LDAP、SMTP）。
在此模式下，SSL/TLS 版本必须在与其普通版本不同的端口上运行，例如：HTTPS 在端口 443 上运行、LDAPS 在端口 636 上运行、IMAPS 在端口 993 上运行，而不是分别在端口 80、389、143 上运行。
实现这些应用程序协议的层几乎不需要知道它们是在 TLS/SSL 之上运行的。有时，它们只是简单地隐藏在诸如sslwrap.
STARTTLS 之后的 TLS（或等效项）
TLS 规范允许握手随时发生，包括在通过同一 TCP 连接以普通 TCP 交换一些数据之后。
一些协议（包括 LDAP）包含一个命令来告诉应用程序协议将进行升级。本质上，LDAP 通信的第一部分以纯文本形式进行，然后是STARTTLS消息被发送（仍然以纯文本形式），这表明当前的 TCP 连接将被重用，但接下来的命令将被包装在 TLS/SSL 层中。在此阶段，发生 TLS/SSL 握手，并且通信“升级”为 TLS/SSL。只有在此之后，通信才通过 TLS/SSL 得到保护，并且客户端和服务器都知道它们必须从 TLS 层包装/解开其命令（通常在 TCP 层和应用程序层之间添加 TLS 库）。
详细如何STARTTLS每个协议中的实现因协议而异（因为这必须在某种程度上与使用它的协议兼容）。
甚至 HTTP 也有一个使用这种机制的变体，尽管它大多不被支持：RFC 2817 在 HTTP/1.1 内升级到 TLS https://www.rfc-editor.org/rfc/rfc2817。这与 HTTPS 的工作方式完全不同（RFC 2818 https://www.rfc-editor.org/rfc/rfc2818），它首先启动 TLS/SSL。
的优点STARTTLS方法是您可以在同一端口上运行安全变体和普通变体，缺点是这样做的后果，特别是潜在的降级攻击或配置中可能的错误。
(EDIT：正如 @GregS 指出的那样，我删除了一个不正确的句子，谢谢。）
(EDIT：我还在中对 SSL 与 TLS 进行了更多介绍ServerFault 上的这个答案 https://serverfault.com/questions/178561/what-are-the-exact-protocol-level-differences-between-ssl-and-tls/179139#179139.)
