Почему не имеет смысла выделять более одного порта TCP / IP для http? Хотя это, по общему признанию, наивно, не слишком ли интуитивно думать, что производительность сервера можно каким-то образом увеличить?
Вы абсолютно правы. Я изменил порт по умолчанию для своих веб-серверов с 80 на 90,91,92 и 93. Нагрузка на сервер резко упала.
Дэвид Хоуд
17
... возможно, потому что ни один клиент больше не может найти сервер?
Маркос Гонсалес
5
80 это просто порт, используемый для http. Когда вы говорите "что-то.com"; (или даже "thing.com "), браузер завершает его, чтобы запросить" нечто.com:80 "; (на 80-м порту, так как это стандартный http-порт по умолчанию). То же самое для https на 443. Если вы решите изменить его, вы должны будете сказать это в URL: "myserver.com:1280"; в противном случае браузер попытается подключиться к порту 80 и не найдет его. Список можно увидеть в Википедии
Оливье Дюлак
6
Извините, Маркос, это была неудачная попытка юмора. Я никогда не был хорош в этом.
Порт 80 является хорошо известным портом, что означает, что он хорошо известен как местоположение, где вы обычно найдете HTTP-серверы. Вы можете найти это документально в HTTP / 1.1 RFC .
Наличие значения по умолчанию полезно именно потому, что вам не нужно вводить его в веб-браузер с помощью URI. Если вы запускаете HTTP-сервер (или фактически любую службу) на нестандартном порту, вы заставляете клиента запоминать, какое произвольное 16-битное число вы выбрали, и вводите его.
В дополнение к этому недружелюбию нет никакого выигрыша в производительности: порт - только одна часть (dst ip:port, src ip:port)4-кортежа, который однозначно идентифицирует соединение TCP. Если два соединения совместно используют dst ip:port, это не значит, что они совместно используют какой-то системный ресурс - они могут находиться в разных потоках или разных процессах.
Теперь, если у вас есть логически различные услуги , которые оба происходят использовать HTTP, нет никаких проблем с запуском их на разных портах. Это просто делает URI немного страшнее.
Это оно! Порт 80 не является ресурсом! Это просто часть кортежа! Спасибо, что выразили это так ясно.
Маркос Гонсалес
2
Также ничего не стоит, что даже для разных сервисов фактическое HTTP-соединение обычно принимается через порт 80 общесистемным драйвером, который выполняет первоначальный анализ протокола, а затем передает его правильному сервису, что позволяет совершенно разным сервисам в разных процессах поделитесь тем же портом.
Месье
1
Пользовательский ответ Бесполезно
Deckard
26
Сервер не тратит ресурсы, обрабатывая соединения в одном или нескольких портах. Ресурсы сервера выделяются для обработки соединений, а номер порта - это просто способ подключения конкретной программы к определенному соединению.
Например: HTTP-сервер знает, что он будет прослушивать соединения, которые приходят через порт 80. И сервер знает, что каждый раз, когда он получает какой-либо запрос на порт 80, он обрабатывает его на http-сервере. После этого http-сервер будет обрабатывать связь, а затем будет потреблять ресурсы.
Я бы добавил к этому ответу, что порт 80 не используется пользователем, отправляющим ему свой запрос. Вот почему использование только порта 80 (или любого другого известного порта для входящего протокола, который вы просматриваете) не является узким местом для масштабируемости.
Крейг Сиркин
1
Это именно то, что я не совсем понял. Даже 100 000 пользователей, подключающихся одновременно к www.example.com:80, не будут использовать порт 80. Спасибо за разъяснения. Я нахожу информацию @Useless ниже также очень полезной.
Маркос Гонсалес
Некоторые программы для веб-серверов имеют ограничения на экземпляры и / или процессы. Иногда может быть хорошей идеей запускать несколько экземпляров, но для этого на одной и той же машине требуется другой порт прослушивания, первый (TCP80 / 443) перенаправляет соединения на первый экземпляр.
Реми Летурно,
22
Вы, кажется, думаете о портах как о чем-то реальном; это просто 16-битное число без знака (0-65535), это метка в заголовке IP-пакета. Это помогает с мультиплексированием на уровне приложений. Когда входящий пакет поступает на сетевую карту, ОС получает уведомление. Он проверяет, на какой порт был направлен входящий пакет, и затем перенаправляет пакет только нужному приложению. Если вы используете свой веб-сервер (nginx) для прослушивания порта 80, только nginx получает пакеты, отправленные на порт 80.
Когда клиент (IP: 100.200.100.200) делает HTTP-запрос к серверу (55.55.55.55), он делает этот запрос к порту назначения 80 на сервере (55.55.55.55:80), но порт источника случайным образом выбирается ОС для веб-браузера (что-то вроде 45490). HTTP-ответ от веб-сервера затем приходит от (55.55.55.55:80), но отправляется адресату (вашему IP) (100.200.100.200:45490). Операционная система вашего компьютера знает, что входящие пакеты через порт 45490 (из 55.55.55.55:80) необходимо передать веб-браузеру, который сделал запрос. Поскольку каждое уникальное подключение к веб-сайту от клиента получает уникальный случайный порт, поэтому вы можете иметь несколько веб-браузеров, подключающихся к одному веб-сайту, и когда страница перезагружается в одном браузере, другие окна не затрагиваются.
Каждый IP-пакет имеет в заголовке IP-адреса источника и назначения и порт, доступный для него. ОС и приложение (веб-браузер или веб-сервер) могут использовать и то, и другое, чтобы выяснить, как выполнить обработку пакета.
Если вы хотите, чтобы веб-сервер прослушивал любые другие порты, пользователи должны вручную добавить порт в URL-адрес, или он должен быть закодирован в любой ссылке на этот конкретный порт.
Кроме того, большинство прокси-серверов и брандмауэров не разрешают подключения к этим портам, если они специально не настроены для этого (без настройки исходящие прокси-серверы не будут прослушивать порты не по умолчанию, поэтому не будут перенаправлять запрос на веб-серверы, в то время как брандмауэры просто блокировать попытки соединения не-TCP80 / 443)
Все это ограничивает то, что можно сделать на уровне TCP / IP
Одним из способов повышения производительности было бы наличие устройства / службы балансировки нагрузки, прослушивающих TCP80 / 443, который затем перенаправлял бы запрос на серверы на разных портах и / или ip (локальное балансирование) или даже на другие удаленные сайты (глобальное балансирование). Но это совсем другая тема
Спасибо за то, что познакомили меня с понятием «балансировка нагрузки».
Маркос Гонсалес
1
Если вы хотите иметь «псевдо» практические идеи и идеи по некоторым концепциям балансировки нагрузки, F5 проведет бесплатное онлайн-обучение в университете. ) обучение, где вы можете увидеть, как это выглядит, и изучить некоторые концепции балансировки нагрузки (например: реальный IP, виртуальный IP, пулы, проверка работоспособности и т. д.)
Реми Летурно,
Хороший совет!
Маркос Гонсалес
9
Добавление дополнительных портов не добавляет дополнительной пропускной способности или чего-то в этом роде, порт является скорее меткой, чем каналом , он может «расти» настолько широко, насколько вам нужно, без замедления из-за переполнения канала.
Если сервер получает слишком много запросов, он, конечно, замедлится, однако это не та проблема, которую можно решить, добавив другой номер порта.
s / label then / label than / - я бы отредактировал, но кажется, что только один символ не является приемлемым для редактирования.
Пол Гир,
7
Если вы используете случайные порты, пользователь должен будет добавлять правильные номера портов каждый раз, когда они заходят на ваш сайт. т.е. www.example.com:80; www.example.com:81; www.example.com:82 и т. д.
Это не увеличило бы производительность, чтобы использовать больше портов. Порты источника для каждого соединения эфемерные порты и так или иначе разные
Каждое TCP / IP-соединение имеет sourceIP: sourcePort и destinationIP: destinationPort.
Когда вы инициируете соединение, вы всегда будете использовать 80 в качестве порта назначения (что имеет смысл, поскольку Серверу нужно прослушивать только порт 80 для HTTP, а не несколько портов). Хитрость в том, что sourcePort является динамическим для каждого соединения.
Не путайте другой порт с другим физическим соединением, более высокой пропускной способностью сети или производительностью сервера. Сервер получает пакеты TCP или UDP, в которых в качестве части адреса указан номер порта. Они по-прежнему проходят по одним и тем же проводам, проходят через одно и то же оборудование и драйвер сетевого интерфейса и так далее.
Если вы должны были отправить два пакета на сервер, с точки зрения ресурсов, которые сервер тратит на обработку этих двух пакетов, не имеет значения, если один из двух имеет разные номера портов или одинаковые номера портов, связанные с ними, внутренняя обработка будет быть близким к идентичному.
Следовательно, это не способ повысить производительность каким-либо образом.
Единственное возможное исключение - это если вы связываете двух разных демонов (или двух копий одного и того же), работающих одновременно, с двумя разными номерами портов, и если каждый из этих демонов чрезвычайно плохо масштабируется с нагрузкой. Что, как правило, не так.
Как упомянул Remi, порты 80 и 443 являются портами по умолчанию для HTTP / HTTPS.
Большинство сетей и брандмауэров не блокируют трафик, проходящий через эти порты. Таким образом, использовать эти порты проще, так как в большинстве случаев вам не нужно беспокоиться о брандмауэрах, блокирующих вашу службу, иначе вам, возможно, придется пройти через перенастройку правил брандмауэра и получить одобрения от соответствия / безопасности для них.
Аминь, веб-сайты, использующие нестандартные порты, - это проклятие существования любого администратора безопасности, одному пользователю вашей работы нужно использовать один веб-сайт со странным портом = смена прокси, смена FW, проверка безопасности и т. Д.
wintermute000
0
Как уже говорили все остальные, в принципе бессмысленно размещать веб-сервер на любом порту, кроме порта 80 ... если только вы не размещаете его из дома. Многие интернет-провайдеры регулируют исходящие TCP / UDP-порты 80 и 443 ( IANA определяет как HTTP и HTTPS соответственно), и в этом случае использование этих портов отвлекает от скорости загрузки сайта и т. Д. Однако IANA назначил 3 порта HTTP-ALT для как TCP, так и UDP. Это: 591, 8008 и 8080. Использование этих портов также допустимо, но жизнь администраторов серверов станет для вас адом.
Ответы:
Порт 80 является хорошо известным портом, что означает, что он хорошо известен как местоположение, где вы обычно найдете HTTP-серверы. Вы можете найти это документально в HTTP / 1.1 RFC .
Наличие значения по умолчанию полезно именно потому, что вам не нужно вводить его в веб-браузер с помощью URI. Если вы запускаете HTTP-сервер (или фактически любую службу) на нестандартном порту, вы заставляете клиента запоминать, какое произвольное 16-битное число вы выбрали, и вводите его.
В дополнение к этому недружелюбию нет никакого выигрыша в производительности: порт - только одна часть
(dst ip:port, src ip:port)4-кортежа, который однозначно идентифицирует соединение TCP. Если два соединения совместно используютdst ip:port, это не значит, что они совместно используют какой-то системный ресурс - они могут находиться в разных потоках или разных процессах.Теперь, если у вас есть логически различные услуги , которые оба происходят использовать HTTP, нет никаких проблем с запуском их на разных портах. Это просто делает URI немного страшнее.
источник
Сервер не тратит ресурсы, обрабатывая соединения в одном или нескольких портах. Ресурсы сервера выделяются для обработки соединений, а номер порта - это просто способ подключения конкретной программы к определенному соединению.
Например: HTTP-сервер знает, что он будет прослушивать соединения, которые приходят через порт 80. И сервер знает, что каждый раз, когда он получает какой-либо запрос на порт 80, он обрабатывает его на http-сервере. После этого http-сервер будет обрабатывать связь, а затем будет потреблять ресурсы.
источник
Вы, кажется, думаете о портах как о чем-то реальном; это просто 16-битное число без знака (0-65535), это метка в заголовке IP-пакета. Это помогает с мультиплексированием на уровне приложений. Когда входящий пакет поступает на сетевую карту, ОС получает уведомление. Он проверяет, на какой порт был направлен входящий пакет, и затем перенаправляет пакет только нужному приложению. Если вы используете свой веб-сервер (nginx) для прослушивания порта 80, только nginx получает пакеты, отправленные на порт 80.
Когда клиент (IP: 100.200.100.200) делает HTTP-запрос к серверу (55.55.55.55), он делает этот запрос к порту назначения 80 на сервере (55.55.55.55:80), но порт источника случайным образом выбирается ОС для веб-браузера (что-то вроде 45490). HTTP-ответ от веб-сервера затем приходит от (55.55.55.55:80), но отправляется адресату (вашему IP) (100.200.100.200:45490). Операционная система вашего компьютера знает, что входящие пакеты через порт 45490 (из 55.55.55.55:80) необходимо передать веб-браузеру, который сделал запрос. Поскольку каждое уникальное подключение к веб-сайту от клиента получает уникальный случайный порт, поэтому вы можете иметь несколько веб-браузеров, подключающихся к одному веб-сайту, и когда страница перезагружается в одном браузере, другие окна не затрагиваются.
Каждый IP-пакет имеет в заголовке IP-адреса источника и назначения и порт, доступный для него. ОС и приложение (веб-браузер или веб-сервер) могут использовать и то, и другое, чтобы выяснить, как выполнить обработку пакета.
источник
Порты 80 и 443 являются портами по умолчанию для HTTP / HTTPS
Это означает, что вам не нужно указывать порт ( http://www.example.com:80 , https://www.example.com:443 ) при использовании веб-браузера.
Если вы хотите, чтобы веб-сервер прослушивал любые другие порты, пользователи должны вручную добавить порт в URL-адрес, или он должен быть закодирован в любой ссылке на этот конкретный порт.
Кроме того, большинство прокси-серверов и брандмауэров не разрешают подключения к этим портам, если они специально не настроены для этого (без настройки исходящие прокси-серверы не будут прослушивать порты не по умолчанию, поэтому не будут перенаправлять запрос на веб-серверы, в то время как брандмауэры просто блокировать попытки соединения не-TCP80 / 443)
Все это ограничивает то, что можно сделать на уровне TCP / IP
Одним из способов повышения производительности было бы наличие устройства / службы балансировки нагрузки, прослушивающих TCP80 / 443, который затем перенаправлял бы запрос на серверы на разных портах и / или ip (локальное балансирование) или даже на другие удаленные сайты (глобальное балансирование). Но это совсем другая тема
источник
Добавление дополнительных портов не добавляет дополнительной пропускной способности или чего-то в этом роде, порт является скорее меткой, чем каналом , он может «расти» настолько широко, насколько вам нужно, без замедления из-за переполнения канала.
Если сервер получает слишком много запросов, он, конечно, замедлится, однако это не та проблема, которую можно решить, добавив другой номер порта.
источник
Если вы используете случайные порты, пользователь должен будет добавлять правильные номера портов каждый раз, когда они заходят на ваш сайт. т.е. www.example.com:80; www.example.com:81; www.example.com:82 и т. д.
Это не увеличило бы производительность, чтобы использовать больше портов. Порты источника для каждого соединения эфемерные порты и так или иначе разные
источник
Каждое TCP / IP-соединение имеет sourceIP: sourcePort и destinationIP: destinationPort.
Когда вы инициируете соединение, вы всегда будете использовать 80 в качестве порта назначения (что имеет смысл, поскольку Серверу нужно прослушивать только порт 80 для HTTP, а не несколько портов). Хитрость в том, что sourcePort является динамическим для каждого соединения.
Пример:
user1: 1.1.1.1:29999 до 2.2.2.2:80
user2: 1.1.1.2:45333 до 2.2.2.2:80
источник
Не путайте другой порт с другим физическим соединением, более высокой пропускной способностью сети или производительностью сервера. Сервер получает пакеты TCP или UDP, в которых в качестве части адреса указан номер порта. Они по-прежнему проходят по одним и тем же проводам, проходят через одно и то же оборудование и драйвер сетевого интерфейса и так далее.
Если вы должны были отправить два пакета на сервер, с точки зрения ресурсов, которые сервер тратит на обработку этих двух пакетов, не имеет значения, если один из двух имеет разные номера портов или одинаковые номера портов, связанные с ними, внутренняя обработка будет быть близким к идентичному.
Следовательно, это не способ повысить производительность каким-либо образом.
Единственное возможное исключение - это если вы связываете двух разных демонов (или двух копий одного и того же), работающих одновременно, с двумя разными номерами портов, и если каждый из этих демонов чрезвычайно плохо масштабируется с нагрузкой. Что, как правило, не так.
источник
Как упомянул Remi, порты 80 и 443 являются портами по умолчанию для HTTP / HTTPS.
Большинство сетей и брандмауэров не блокируют трафик, проходящий через эти порты. Таким образом, использовать эти порты проще, так как в большинстве случаев вам не нужно беспокоиться о брандмауэрах, блокирующих вашу службу, иначе вам, возможно, придется пройти через перенастройку правил брандмауэра и получить одобрения от соответствия / безопасности для них.
источник
Как уже говорили все остальные, в принципе бессмысленно размещать веб-сервер на любом порту, кроме порта 80 ... если только вы не размещаете его из дома. Многие интернет-провайдеры регулируют исходящие TCP / UDP-порты 80 и 443 ( IANA определяет как HTTP и HTTPS соответственно), и в этом случае использование этих портов отвлекает от скорости загрузки сайта и т. Д. Однако IANA назначил 3 порта HTTP-ALT для как TCP, так и UDP. Это: 591, 8008 и 8080. Использование этих портов также допустимо, но жизнь администраторов серверов станет для вас адом.
Источник номеров портов: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.
источник