TLS/SSL на http (80) с STARTTLS

Я исследую причину, по которой TLS/SSL не использует HTTP. Другие протоколы, такие как SMTP, POP3, FTP и т. д., могут использоваться на портах SSL (SMTPС, POP3С, FTPС) для первого способа, а второй — использовать опцию STARTTLS в текущем порту с расширением (Пример SMTP) Существует популярный способ использования второго способа (STARTTLS) в протоколах электронной почты, но почему http не использует STARTTLS? я нашел RFC TLS в HTTP/1.1, но в настоящее время не используется (или, может быть, я еще не видел)

Одна из целей Механизм обновления в RFC 2817 был ли предоставлен виртуальный хостинг механизм для HTTP с TLS, как это было в 2000 году:

Механизм Upgrade также решает проблему «виртуального хостинга». Вместо того, чтобы выделять несколько IP-адресов одному хосту, Сервер HTTP/1.1 будет использовать заголовок Host: для устранения неоднозначности предполагаемый веб-сервис. Поскольку использование HTTP/1.1 стало более распространенным, все больше интернет-провайдеров предлагают виртуальный хостинг на основе имени, тем самым задерживая исчерпание адресного пространства.

Индикация имени сервера (СНИ; RFC 3546, 3.1) дал лучшее решение этой проблемы в 2003 году — тот, который все еще используется — так что в этом больше нет необходимости. Обновление заголовок все еще жив, но используется для других целей, таких как переключение с HTTP/1.1 на HTTP/2.0 (RFC 7230, 6.7).

Протокол HTTP также имеет Место расположения заголовок (RFC 7231, 7.1.2) с соответствующими кодами ответов, что позволяет легко перенаправить клиента на другую схему, хост и порт, в отличие от протоколов, которые использовали СТАРТЛС.

Также обратите внимание, что использование СТАРТЛС не было чем-то хорошим и желательным и чем-то, что должно быть принято большим количеством протоколов. Фактически, RFC 8314 теперь устаревает протоколы открытого текста для отправки и доступа к электронной почте, оставляя SMTP MTA-MTA единственным протоколом электронной почты, в котором СТАРТЛС должен быть использован. От раздел 3:

Несмотря на то, что этот механизм был развернут, альтернативный механизм где TLS согласовывается сразу при начале соединения на отдельный порт (упоминаемый в этом документе как «Неявный TLS») были развернуты более успешно. Для поощрения более широкого использования TLS, а также поощрять большую согласованность в отношении того, как TLS используется, эта спецификация теперь рекомендует использовать неявный TLS для POP, IMAP, отправка SMTP и все другие протоколы, используемые между MUA и MSP.

Одной из причин может быть то, что дополнительный STARTTLS добавит больше накладных расходов, поскольку требуется дополнительный круговой путь (запрос + ответ). Однако время от начала соединения до ответа довольно критично для HTTP, и было сделано множество оптимизаций, чтобы сократить это время, например, более короткое рукопожатие TLS или другие протоколы, такие как QUIC.Добавление чего-то вроде STARTTLS вместо этого увеличило бы время и, таким образом, не является хорошей идеей.