%20%E4%B8%8A%E8%BF%9B%E8%A1%8C%20TLS%2FSSL.png)
我正在研究为什么 TLS/SSL 不能通过 HTTP 使用。其他协议（如 SMTP、POP3、FTP 等）可以在 SSL 端口上使用（SMTP年代、POP3年代, FTP年代) 为第一种方式，第二种方式是在当前端口使用 STARTTLS 选项，并添加扩展名 (SMTP 示例) 在电子邮件协议上，有一种流行的方法是使用第二种方式（STARTTLS），但为什么 http 不使用 STARTTLS？我发现HTTP/1.1 中的 RFC TLS，但现在没有使用（或者也许我还没有看到）
答案1
的一个目的升级机制在RFC 2817是提供一个虚拟主机HTTP 与 TLS 的机制与 2000 年的情况类似：
升级机制还解决了“虚拟主机”问题。HTTP/1.1 服务器将使用 Host: 标头来消除目标 Web 服务的歧义，而不是为单个主机分配多个 IP 地址。随着 HTTP/1.1 的使用越来越普遍，越来越多的 ISP 提供基于名称的虚拟主机，从而延缓 IP 地址空间耗尽。
这服务器名称指示（新加坡国家信息中心；RFC 3546, 3.1) 在 2003 年为这个问题提供了一个更好的解决方案——至今仍在使用——所以不再需要这个了。该Upgrade标头仍然存在，但用于不同的目的，例如从 HTTP/1.1 切换到 HTTP/2.0（RFC 7230, 6.7）。
HTTP 协议还具有Location标头（RFC 7231, 7.1.2) 以及相关的响应代码，从而可以轻松地将客户端重定向到另一个方案、主机和端口，这与使用的协议不同STARTTLS。
还要注意的是，使用STARTTLS并不是一件好事，也不值得，应该被更多的协议采用。事实上，RFC 8314现在已淘汰了用于电子邮件提交和访问的明文协议，只留下 MTA 到 MTA SMTP 成为唯一STARTTLS应使用的电子邮件协议。从第3节：
– – 虽然已经部署了此机制，但另一种机制（即在连接开始时在单独的端口上立即协商 TLS）已更成功地部署（本文档中称为“隐式 TLS”）。为了鼓励更广泛地使用 TLS，并鼓励在 TLS 的使用方式上更加一致，本规范现在建议对 POP、IMAP、SMTP 提交以及 MUA 和 MSP 之间使用的所有其他协议使用隐式 TLS。
答案2
一个原因可能是额外的 STARTTLS 会增加更多开销，因为需要额外的往返（请求 + 响应）。从连接开始到响应的时间对于 HTTP 来说相当关键，并且已经进行了许多优化来减少此时间，例如更短的 TLS 握手或不同的协议（如 QUIC）。添加像 STARTTLS 这样的东西反而会增加时间，因此不是一个好主意。