В основном: браузер включает имя домена в запрос 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-запроса.
- Запрашиваемый путь
- Любые другие заголовки (куки и т. Д.)
Как вы, наверное, заметили, в наши дни самая распространенная настройка общего хостинга - это размещение нескольких веб-сайтов на одном IP-адресе: комбинации портов, что Host
позволяет различать только веб-сайты.
Это называется виртуальным хостом на основе имен в Apache-land, в то время как Nginx называет их именами серверов в блоках серверов, а IIS предпочитает виртуальный сервер .
Как насчет HTTPS?
HTTPS немного отличается. Все идентично до установления соединения TCP, но после этого должен быть установлен зашифрованный туннель TLS. Цель состоит в том, чтобы не пропускать информацию о запросе.
Чтобы убедиться, что серверу действительно принадлежит этот домен, сервер должен отправить сертификат, подписанный доверенной третьей стороной. Браузер сравнивает этот сертификат с запрашиваемым доменом.
Это представляет проблему. Как сервер узнает, какой сертификат хоста (веб-сайта) отправить, если он должен сделать это до получения HTTP-запроса?
Традиционно это решалось с помощью выделенного IP-адреса (или порта) для каждого веб-сайта, требующего HTTPS. Очевидно, это становится проблематичным, когда у нас заканчиваются адреса IPv4.
Введите SNI (указание имени сервера). Браузер теперь передает имя хоста во время согласования TLS, поэтому сервер имеет эту информацию достаточно рано, чтобы отправить правильный сертификат. На стороне сервера конфигурация очень похожа на настройку виртуальных хостов HTTP.
Недостатком является то, что имя хоста теперь передается в виде обычного текста перед шифрованием, и это, по сути, утечка информации. Обычно это считается приемлемым компромиссом, учитывая, что имя хоста в любом случае обычно указывается в запросе DNS.
Что делать, если вы запрашиваете сайт только по IP-адресу?
То, что делает сервер, когда он не знает, какой конкретный хост вы запросили, зависит от реализации и конфигурации сервера. Обычно указывается сайт «по умолчанию», «catchall» или «запасной вариант», который будет предоставлять ответы на все запросы, которые явно не указывают хост.
Этот сайт по умолчанию может быть собственным независимым сайтом (часто с сообщением об ошибке) или любым другим сайтом на сервере, в зависимости от предпочтений администратора сервера.
Host:
заголовке. В случае общего хостинга провайдер может настроить веб-сервер так, чтобы он обрабатывал это различными способами (например, по умолчанию, перенаправлять на провайдера и т. Д.).