Почему 80 был выбран в качестве порта HTTP по умолчанию, а 443 — в качестве порта HTTPS по умолчанию?
Nov 15, 2015
Облако и Интернет
Хотя многие из нас знакомы с различными портами, назначаемыми для определенных целей или использования, мы можем не знать конкретной причины, по которой они были выбраны. В сегодняшнем посте SuperUser Q&A есть ответы на вопросы любопытного читателя.
Сегодняшняя сессия вопросов и ответов проходит благодаря SuperUser — подразделению Stack Exchange, группы веб-сайтов вопросов и ответов, управляемой сообществом.
Фото любезно предоставлено Родни Льюис (Flickr) .
Вопрос
Читатель SuperUser Сэмюэл Александр хочет знать, почему 80 и 443 были выбраны в качестве портов HTTP и HTTPS по умолчанию:
Почему порт 80 был выбран как порт HTTP по умолчанию, а 443 — как порт HTTPS по умолчанию? Есть ли какая-то конкретная причина или она просто так определена?
Почему 80 и 443 были выбраны в качестве портов HTTP и HTTPS по умолчанию?
Ответ
У участника SuperUser jcbermu есть для нас ответ:
Управление по присвоению номеров в Интернете (IANA) — это подразделение ICANN, некоммерческой частной корпорации, которая наблюдает за глобальным распределением IP-адресов, системой доменных имен (DNS), общеизвестными портами и другими символами и числами, связанными с интернет-протоколом.
В марте 1990 года они опубликовали документ ( RFC 1060 ), где перечислены все известные в то время порты. В этом списке не было протокола, назначенного порту 80 (он перескочил с 79 на 81):
В то время порт 80 был официально свободен. В 1991 году Тим Бернерс-Ли выпустил первую версию HTTP в документе ( HTTP 0.9 ), где он заявил:
Затем, в июле 1992 года, RFC1060 был отменен новым документом ( RFC 1340 ), где появилось следующее:
Этот документ сделал 80 официальным портом для HTTP (www). Однако в этом документе нет ничего о порте 443. В октябре 1994 г. RFC 1700 было опубликовано, и это появилось впервые:
Кажется, это было запрошено Кипп Э. Б. Hickman , который в то время работал в Mosaic, первой компании-разработчике GUI-браузеров, которая позже стала Netscape.
Непонятно, почему был выбран порт 443. Однако в предыдущем документе RFC был пробел от 374 до 512, а в RFC1700 был заполнен пробел от 375 до 451. Скорее всего, номера были даны просто в порядке запроса.
Есть что добавить к объяснению? Отключить звук в комментариях. Хотите узнать больше ответов от других технически подкованных пользователей Stack Exchange? Ознакомьтесь с полной веткой обсуждения здесь .
Главная
Главная- Гостиница
- Столовая и кафе
- Обратная связь
Репортажи о секциях Социальный ролик
ГТО
Бокс
Единоборства
Баскетбол
Хоккей
Теннис
Шахматы
Фехтование
Худ.
гимнастика
Спорт. аэробика
Современ. танцы
Театр танца
Синхронное плавание
Спортивн. плавание
НОВОСТИ
Соревнования
3 часа назад
5 марта в «Спорткомплексе Олимпийской деревни-80» состоялся открытый турнир «GANG CUP» по тхэквондо.
07 марта
Прусакова Ксения стала победителем Всероссийского турнира по боксу на призы заслуженного мастера спорта Софьи Очигавы.
Соревнования
06 марта
Поздравляем нашу воспитанницу Быкову Алису с 1 местом на соревнованиях по фигурному катанию на коньках.
Галерея
Соревнования
3 минуты назад
События
03 октября
Воспитанницы «СК ОД-80» по фигурному катанию (спортивная и оздоровительная группы)
Соревнования
28 июля
Чемпионат России по дзюдо спорта слепых 25-27 июля 2022 г. в «СК ОД-80»
Соревнования
27 мая
Турнир по дзюдо «Будущие звезды дзюдо» 2022
netsh — В чем разница между http://*:80 и http://+:80
спросил
Изменено 4 года, 6 месяцев назад
Просмотрено 13 тысяч раз
Изучая веб-развертывание, я столкнулся с некоторыми командами netsh.
exe, которые говорят о http://+:80 и http://*:80. Что это значит?
- http
- netsh
- webdeploy
Согласно URLPrefix Strings (Windows):
Когда элемент host в UrlPrefix состоит из одного знака плюс (+), UrlPrefix соответствует всем возможным именам хостов в контексте элементов схемы, порта и относительных URI и попадает в категорию сильных подстановочных знаков.
Если звездочка (*) появляется в качестве основного элемента, то UrlPrefix попадает в категорию слабых подстановочных знаков. Этот тип UrlPrefix соответствует любому имени хоста, связанному с указанной схемой, портом и относительным URI, которое еще не было сопоставлено сильным подстановочным знаком, явным или слабым подстановочным знаком UrlPrefix, привязанным к IP. Эта спецификация хоста может использоваться в качестве универсальной по умолчанию в некоторых обстоятельствах или может использоваться для указания большого раздела пространства имен URL-адресов без необходимости использования многих UrlPrefixes.
После этого :80 показывает порт, через который вы получаете доступ к URL-адресу, соответствующему строке подстановки. 80 — один из самых (если не самый) распространенных портов, используемых для доступа к обычным веб-страницам.
0
В нескольких основных словах, «*» обрабатывает запросы, если это не сделал никто другой, а «+»
Хороший пример, взятый из https://stackoverflow.com/a/9459679/6375269
http://*:8080/: получать все HTTP-запросы на порт 8080, которые не уже обрабатывается другим HttpListener.
http://+:8080/: получать все HTTP-запросы на порт 8080, даже если они уже обрабатывается другим HttpListener.
Зарегистрируйтесь или войдите в систему
Зарегистрируйтесь с помощью Google
Зарегистрироваться через Facebook
Зарегистрируйтесь, используя электронную почту и пароль
Опубликовать как гость
Электронная почта
Требуется, но не отображается
Опубликовать как гость
Электронная почта
Требуется, но не отображается
asp.
net core — прослушивание контейнера Docker на http://[::]:80Задавать вопрос
спросил
Изменено 1 год, 11 месяцев назад
Просмотрено 13 тысяч раз
Я работаю над настройкой двух контейнеров Docker с помощью Docker для Windows. Простое веб-приложение на основе узла и приложение API ядра dotnet. Я запускаю оба этих контейнера, используя «docker-compose up». Приложение node запускается отлично, и я могу нажать открытый URL-адрес, однако приложение dotnet, похоже, не работает.
Вывод команды docker-compose up приведен ниже:
application.client_1 | ИНФОРМАЦИЯ: Прием соединений на http://localhost:8080 приложение.api_1 | предупреждение: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35] приложение.api_1 | Шифровщик XML не настроен. Ключ {cc83a8ac-e1de-4eb3-95ab-8c69a5961bf9} может храниться в незашифрованном виде. приложение.api_1 | Среда размещения: Разработка приложение.api_1 | Корневой путь содержимого: /app/application.Api приложение.api_1 | Сейчас слушаю: http://[::]:80 приложение.api_1 | Приложение запущено. Нажмите Ctrl+C, чтобы выключить.
DataProtection.KeyManagement.XmlKeyManager[35]
приложение.api_1 | Шифровщик XML не настроен. Ключ {cc83a8ac-e1de-4eb3-95ab-8c69a5961bf9} может храниться в незашифрованном виде.
приложение.api_1 | Среда размещения: Разработка
приложение.api_1 | Корневой путь содержимого: /app/application.Api
приложение.api_1 | Сейчас слушаю: http://[::]:80
приложение.api_1 | Приложение запущено. Нажмите Ctrl+C, чтобы выключить.
Файл Docker выглядит следующим образом:
ИЗ сборки Microsoft/dotnet AS РАБОЧИЙКАТАЛОГ /приложение ПОРТ ОК = 8081 КОПИРОВАТЬ приложение.Api/application.Api.csproj приложение.Api/ КОПИРОВАТЬ application.Business/application.Business.csproj application.Business/ КОПИРОВАТЬ application.DataAccess/application.DataAccess.csproj application.DataAccess/ КОПИРОВАТЬ application.DataModel/application.DataModel.csproj application.DataModel/ РАБОЧИЙ КАТАЛОГ /app/application.Api ЗАПУСТИТЬ восстановление дотнета РАБОЧИЙКАТАЛОГ /приложение/ КОПИРОВАТЬ приложение.Api/. ./приложение.
Апи/
КОПИРОВАТЬ приложение.Бизнес/. ./приложение.Бизнес/
КОПИРОВАТЬ приложение.DataAccess/. ./приложение.Доступ к Данным/
КОПИРОВАТЬ приложение.DataModel/. ./приложение.МодельДанных/
РАБОЧИЙ КАТАЛОГ /app/application.Api
ВЫПОЛНИТЬ dotnet publish -c Release -o out
Среда выполнения Microsoft/dotnet AS
РАБОЧИЙ КАТАЛОГ /app/application.Api
КОПИРОВАТЬ --from=build /app/application.Api/out .
ТОЧКА ВХОДА ["dotnet", "application.Api.dll" ]
ВЫСТАВИТЬ $PORT
Я не могу получить IP-адрес и поэтому попал на URL-адрес API. Любые мысли будут высоко оценены, так как я новичок в Docker.
ОБНОВЛЕНИЕ 1: Составление YML
версия: «3.4»
услуги:
тонкин.api:
изображение: приложение.api
порты:
- 8081:5000
строить:
контекст: .
докерфайл: Докерфайл
Тонкин.клиент:
изображение: приложение.клиент
порты:
- 8080:8080
строить:
контекст: .
докерфайл: ../application.Client/Dockerfile
- докер
- asp. net-core
- .net-core
- docker-compose
- dockerfile
net-core0
Как они уже упоминали, кажется, что ваш контейнер работает на порту 80. Так что по какой-то причине этот порт открыт.
Может быть, EXPOSE $PORT не возвращает 8081, как вы ожидаете?
Когда вы запускаете контейнер, если вы не укажете, где его сопоставить, он будет доступен только по IP-адресу контейнера на открытом порту (80 в вашем случае). Легко узнать IP этого контейнера, запустив docker inspect
Протестируйте свой образ, выполнив что-то вроде docker run -p 8080:80 yourimage . Вы увидите, что в дополнение к порту 80, который показывает образ, он сопоставляется с вашим локальным портом 8080, так что http://localhost:8080 должен быть доступен.
Посмотрите это, если это поможет вам
Посмотрите этот ответ.
Базовый образ dotnet переопределяет порт пустельги по умолчанию.