В основному: браузер включає ім'я домену в HTTP-запит, тому веб-сервер знає, який домен був запитаний, і може відповісти відповідно.
HTTP-запити
Ось як відбувається ваш типовий запит HTTP:
Користувач надає URL-адресу у формі http://host:port/path
.
Браузер витягує частину URL-адреси хоста (домену) і при необхідності переводить її в IP-адресу в процесі, відомому як дозвіл імені . Цей переклад може відбуватися через DNS, але це не обов'язково (наприклад, локальний hosts
файл на загальних ОС обходить DNS).
Браузер відкриває TCP-з'єднання до вказаного порту або за замовчуванням до порту 80 за цією IP-адресою.
Браузер надсилає запит HTTP. Для HTTP / 1.1 це виглядає приблизно так:
GET /path HTTP/1.1
Host: example.com
( Host
Заголовок стандартний і потрібен у HTTP / 1.1. Він не був вказаний у специфікації HTTP / 1.0, але деякі сервери його все одно підтримують.)
Звідси веб-сервер має декілька відомостей, які він може використовувати, щоб вирішити, якою має бути відповідь. Зауважте, що один веб-сервер може бути прив’язаний до декількох IP-адрес.
- Запитана IP-адреса від сокета TCP
- IP-адреса клієнта також доступна, але це рідко використовується - іноді для блокування / фільтрації
- Запитаний порт із сокета TCP
- Запитане ім'я хоста, як зазначено в
Host
заголовку браузером у HTTP-запиті.
- Запитаний шлях
- Будь-які інші заголовки (файли cookie тощо)
Як ви, мабуть, помітили, найпоширеніша настройка спільного хостингу в ці дні розміщує декілька веб-сайтів на одній IP-адресі: комбінація портів, залишаючи лише Host
розмежування між веб-сайтами.
Це відоме як Віртуальний хост на основі імен в Apache-землі, в той час як Nginx називає їх Імена серверів у серверних блоках, а IIS віддає перевагу Віртуальний сервер .
Що з HTTPS?
HTTPS трохи інший. Все є ідентичним до встановлення TCP-з'єднання, але після цього повинен бути встановлений зашифрований тунель TLS. Мета - не просочувати жодної інформації про запит.
Для того, щоб переконатися, що серверу фактично належить цей домен, він повинен надіслати сертифікат, підписаний довіреною третьою стороною. Потім браузер порівняє цей сертифікат з доменом, про який він запитував.
Це представляє проблему. Як сервер знає, який сертифікат хоста (веб-сайту) надіслати, якщо це потрібно зробити до отримання HTTP-запиту?
Традиційно це вирішувалося за допомогою спеціальної IP-адреси (або порту) для кожного веб-сайту, що вимагає HTTPS. Очевидно, що це стає проблематичним, коли ми починаємо вичерпати адреси IPv4.
Введіть SNI (Вказівка імені сервера). Зараз браузер передає ім'я хоста під час переговорів щодо TLS, тому сервер має цю інформацію досить рано, щоб надіслати правильний сертифікат. На стороні сервера конфігурація дуже схожа на налаштування віртуальних хостів HTTP.
Недоліком є те, що ім'я хоста зараз передається як звичайний текст перед шифруванням і по суті є просоченою інформацією. Зазвичай це вважається прийнятним компромісом, враховуючи те, що ім'я хоста, як правило, виявляється в запиті DNS.
Що робити, якщо ви запитуєте сайт лише за IP-адресою?
Що робити сервер, коли він не знає, якого конкретного хоста ви запитували, залежить від реалізації та конфігурації сервера. Як правило, вказаний сайт "за замовчуванням", "випадок" або "резервний", який надасть відповіді на всі запити, які чітко не визначають хост.
Цей сайт за замовчуванням може бути власним незалежним сайтом (часто показує повідомлення про помилку), або це може бути будь-який з інших сайтів на сервері, залежно від уподобань адміністратора сервера.
Host:
заголовку. У разі спільного хостингу веб-сервер може бути налаштований провайдером для обробки цього способу різними способами (наприклад, мати за замовчуванням, перенаправити на провайдера тощо).