Чому тільки порт 80 для веб-сервісів?

Чому не доцільно присвятити http декілька портів TCP / IP? Хоча, правда, наївно, чи не є якось інтуїтивно думати, що продуктивність сервера можна якось збільшити?

Порт 80 - це добре відомий порт, а це означає, що він відомий як місце розташування, в якому ви зазвичай знаходите HTTP-сервери. Ви можете знайти це задокументовано в HTTP / 1.1 RFC .

Мати за замовчуванням корисно саме тому, що вам не потрібно вводити його у веб-браузер за допомогою URI. Якщо ви запустите сервер HTTP (або насправді будь-яку службу) на нестандартному порту, ви змусите клієнта запам'ятати, яке довільне 16-бітове число ви вибрали і введіть його.

На додаток до цієї недружніх переваг від продуктивності немає: порт - це лише одна частина (dst ip:port, src ip:port)4-каналу, яка однозначно ідентифікує TCP-з'єднання. Якщо два з'єднання мають спільний a 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 450545490). ОС вашого комп'ютера знає, що вхідні пакети на порт 45490 (від 55.55.55.55:80) потрібно надати веб-браузеру, який зробив запит. Оскільки кожне унікальне підключення до веб-сайту від клієнта отримує унікальний випадковий порт, то ви можете мати кілька веб-браузерів, що підключаються до одного веб-сайту, і коли сторінка перезавантажується в одному браузері, інші вікна не впливають.

Кожен IP-пакет має в заголовку доступні вихідні та цільові IP-адреси та порт. ОС і додаток (веб-браузер або веб-сервер) можуть використовувати як для з'ясування відповідних дій щодо того, як обробити пакет.

Порти 80 та 443 - це порти за замовчуванням для HTTP / HTTPS

Це означає, що вам не потрібно вказувати порт ( http://www.example.com:80 , https://www.example.com:243 ) під час використання веб-браузера.

Якщо ви хочете, щоб веб-сервер прослуховував будь-який інший порт, користувачі повинні вручну додати порт до URL-адреси, або він повинен бути закодований у будь-якому посиланні на цей конкретний порт.

Крім того, більшість проксі-серверів і брандмауерів не дозволять з'єднатись із тими портами, якщо спеціально не налаштовано це (Без конфігурації. Вихідні проксі-сервери не слухатимуть порти за замовчуванням, отже, не пересилатимуть запит веб-серверам, тоді як Firewall просто блокувати спроби з'єднань, які не є TCP80 / 443)

Все це обмежує те, що можна зробити на рівні TCP / IP

Одним із способів підвищення продуктивності є створення пристрою / послуги з балансування навантаження, що прослуховує TCP80 / 443, який потім перенаправлятиме запит на сервери на різні порти та / або ip (локальне балансування) або навіть на різні віддалені сайти (глобальне балансування). Але це зовсім інша тема

Додавання додаткових портів не додає додаткової пропускної здатності чи нічого подібного. Порт - це більше мітка, ніж труба , він може "зростати" настільки широким, як вам потрібно, без повільніше через повну трубу.

Якщо сервер отримує занадто багато запитів, він, звичайно, сповільнюється, однак це не проблема, яку можна виправити, додавши інший номер порту.

Якщо ви використовували випадкові порти, користувачеві доведеться додавати правильні номери портів кожного разу, коли вони заходили на ваш сайт. тобто www.example.com:80; www.example.com:81; www.example.com:82 тощо

Не збільшуватиметься продуктивність використання більше портів. Порти джерела для кожного з'єднання ефемерні порти і так чи інакше

Кожне з'єднання TCP / IP має джерелоIP: sourcePort та призначенняIP: призначенняPort.

Коли ви ініціюєте з'єднання, ви завжди будете використовувати 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, які, як буває, мають номер порту в якості адреси. Вони все ще надходять через однакові дроти, проходять через одне і те ж апаратне забезпечення мережевого інтерфейсу та драйвер тощо.

Якщо ви мали б надіслати два пакети на сервер, з точки зору ресурсів сервер витрачає на обробку цих двох пакетів, не має значення, чи є один з двох різних номерів портів або однакові номери портів, пов'язаних з ними, внутрішня обробка буде бути близьким до ідентичного.

Тому це не спосіб підвищення ефективності будь-яким способом.

Єдиним можливим винятком з цього є те, якби ви пов’язали два різних демони (або дві копії одного і того ж), що працюють одночасно, до двох різних номерів портів, і якщо кожен з цих демонів набув би надзвичайно поганого навантаження. Що зазвичай не так.

Як згадував Ремі, порт 80 і 443 є портами "за замовчуванням" для HTTP / HTTPS.

Більшість мереж і брандмауери не блокують трафік, що проходить через ці порти. Тому користуватися цим портами простіше, оскільки більшу частину часу вам може не потрібно турбуватися про те, що брандмауери блокують вашу послугу, можливо, вам доведеться пройти переконфігурування правил брандмауера та отримання схвалення на відповідність / безпеку для тих же.

Як уже говорили всі, тут, в основному, безглуздо розміщувати веб-сервер на будь-якому порту, окрім порту 80 ..., якщо ви не розміщуєте його вдома. Багато провайдерів перемикають вихідні порти 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