Почему HTTPS - это 443?
У HTTP есть порт 80. У HTTPS - 443.
Это знают практически все, кто хоть раз настраивал веб-сервер. В Nginx достаточно увидеть что-нибудь вроде:
//text
listen 443 ssl;и становится понятно, о чём речь.
Но откуда вообще взялось это число?
Самый очевидный вариант - предположить, что между 80 и 443 есть какая-то связь. Может быть, 443 связан с SSL, из которого потом появился TLS. Или его каким-то образом вычислили из стандартного порта HTTP.
Нет.
443 не нужен TLS для работы. HTTPS вполне можно поднять на 8443:
//text
https://site.ru:8443Если сервер слушает этот порт и настроен на TLS, соединение будет обычным HTTPS.
Значит, число само по себе ничего не делает. Оно просто говорит клиенту, куда подключаться.
Почему тогда появился отдельный порт
Тут есть вполне понятная техническая причина.
HTTP и TLS начинают обмен данными по-разному. После установки TCP-соединения обычный HTTP ждёт HTTP-запрос, а TLS начинает с собственного рукопожатия, первым сообщением которого со стороны клиента является ClientHello.
Поэтому разделить эти подключения по портам было удобно.
Обычный HTTP оставили на 80, а HTTPS стал использовать 443.
RFC 2818, описывающий HTTP over TLS, как раз фиксирует эту схему.
На этом месте возникает небольшая путаница. Теперь понятно, почему HTTPS мог использовать отдельный порт, но всё ещё непонятно, почему этим портом оказался именно 443.
И вот здесь история становится менее определённой.
Про 443 известно меньше, чем кажется
В ранней документации Netscape SSL 443 уже указан в качестве порта для HTTPS. То есть к тому моменту решение существовало.
Дальше номер просто закрепился.
IANA регистрирует HTTPS на 443 и сегодня. Браузеры используют его как стандартный порт для схемы https, веб-серверы настроены соответствующим образом, сетевое оборудование тоже давно знает эту комбинацию.
А вот документа, который объяснял бы происхождение самого числа, нет.
По крайней мере, в основных исторических RFC и ранней документации SSL нет ответа в духе: «443 выбрали по такой причине».
Поэтому версии о том, что число как-то математически связано с 80 или с механизмом шифрования, лучше не повторять как факт.
Можно точно сказать, что 443 исторически закрепился за HTTPS.
Почему первоначально выбрали именно его - другое дело.
443 не является обязательным
Это хорошо видно на любом нестандартном HTTPS-порту.
Например, внутренний сервис вполне может работать здесь:
//text
https://server.site:8443Для TLS нет разницы между 443 и 8443.
Разница появляется для клиента.
Если порт не указан в адресе, браузер использует стандартное значение для соответствующей схемы. Для https это 443.
Поэтому:
//text
https://site.ruфактически означает подключение к стандартному HTTPS-порту, хотя пользователь самого числа не видит.
А здесь:
//text
https://site.ru:8443порт уже задан явно.
Это одна из причин, почему стандартный порт удобен. Публичному сайту не приходится заставлять каждого пользователя писать дополнительное число в адресной строке.
Был вариант и с портом 80
Отдельный порт вообще не был единственным возможным решением.
В RFC 2817 описан механизм Upgrade, с помощью которого соединение, начавшееся как HTTP на порту 80, могло перейти к TLS.
Но схема с отдельным 443 оказалась проще для обычного использования.
По номеру подключения уже можно было понимать, какого поведения ожидать: 80 связан с HTTP, 443 - с HTTPS.
Со временем это стало настолько привычным, что менять такую договорённость практически нет смысла.
Можно придумать новый номер.
Технических препятствий для этого нет.
Проблема в другом: браузеры, серверы, прокси и вся остальная инфраструктура уже ожидают старый.
Номер пережил смену технологий
Самое интересное в этой истории - 443 остался на месте, хотя технологии вокруг него заметно изменились.
SSL давно уступил место TLS.
Появились новые версии HTTP.
А HTTP/3 вообще использует QUIC, работающий поверх UDP.
При этом IANA регистрирует HTTPS на 443 и для TCP, и для UDP.
То есть номер порта оказался не привязан к конкретной транспортной реализации.
Поменялся транспорт - номер остался.
Это хорошо показывает, чем порт отличается от протокола. 443 не шифрует данные, не запускает TLS и не заставляет QUIC работать через UDP. Это просто согласованный номер, по которому принято искать HTTPS.
Так почему именно 443?
Вот здесь честный ответ довольно короткий.
Потому что этот номер исторически закрепился за HTTPS.
Ранние документы SSL уже показывают 443 в этой роли, а последующая стандартизация сохранила его.
Но точной причины первоначального выбора числа в доступной нормативной документации нет.
Поэтому у 443 нет какой-то скрытой математической связи с 80. И TLS не требует именно этого значения.
Сегодня всё выглядит гораздо строже, чем было в начале: есть стандартная схема https, есть её стандартный порт, есть огромное количество программ, которые это соглашение поддерживают.
А начиналось всё с гораздо более простой вещи - с выбора номера, который затем настолько прочно вошёл в сетевую инфраструктуру, что теперь кажется частью самого HTTPS.
Хотя это всего лишь порт.
//text
HTTPS → 443
Комментарии
Чтобы оставить комментарий, войдите в аккаунт.