Веб-запрос проходит через несколько уровней. Если понимать задачу каждого из них, причины проблем с подключением проще искать по фактам, а не наугад.
1. Проследите путь одного запроса
Когда вы открываете сайт, браузеру нужны адрес сервера, путь через сеть, транспортное соединение и прикладной протокол, который понимают обе стороны. Для адреса HTTPS также необходимы успешное согласование TLS и проверка сертификата. Некоторые шаги могут выполняться параллельно или использовать результаты предыдущей работы. Ответы DNS бывают закешированы, а уже открытое соединение может обслуживать несколько запросов.
Полезно разделять четыре вопроса: где находится получатель, как до него доходят пакеты, как данные передаются между программами и что эти данные означают? IP-адреса, маршрутизация, транспортные и прикладные протоколы отвечают за разные части этой последовательности. Неисправность на любом из уровней для пользователя часто выглядит одинаково: «сайт не загружается».
2. Адреса и маршрутизация
Протокол IP обеспечивает адресацию и доставку пакетов между сетями. IPv4-адрес обычно записывают в виде четырёх десятичных чисел, например 192.0.2.10. В IPv6 пространство адресов больше, а запись шестнадцатеричная, например 2001:db8::10. Эти примеры зарезервированы для документации и не предназначены для обращения к настоящим работающим сервисам.
Узел использует таблицу маршрутизации, чтобы выбрать следующий шаг для пакета. Если получатель находится вне непосредственно подключённой сети, пакет обычно передаётся шлюзу. Маршрутизаторы повторяют такой выбор на всём пути. IP доставляет пакеты без гарантий: они могут теряться, дублироваться, задерживаться или приходить в другом порядке. Приложения, которым нужны более строгие гарантии, опираются на другой протокол либо самостоятельно реализуют восстановление передачи.
Частные IPv4-адреса могут повторно использоваться в отдельных независимых сетях. Домашний маршрутизатор обычно преобразует адреса исходящего трафика с помощью NAT. Поэтому публичный адрес, который видит сервер, может принадлежать общему шлюзу сразу нескольких устройств. Сам по себе IP-адрес не является надёжным идентификатором конкретного человека или отдельного приложения.
3. Порты определяют конечные точки приложений
Транспортный порт помогает операционной системе направить входящий трафик нужному сокету. TCP-сервер на порту 443 и TCP-сервер на порту 8443 — разные конечные точки. У UDP отдельное пространство портов, поэтому TCP- и UDP-службы могут использовать один и тот же номер порта, оставаясь разными сервисами. Процесс также может привязаться только к определённому локальному адресу.
Петлевые адреса 127.0.0.1 и ::1 указывают на сам локальный узел. Служба, привязанная только к петлевому интерфейсу, обычно недоступна напрямую с другой машины. Прослушивание 0.0.0.0 принимает IPv4-соединения на всех локальных интерфейсах с учётом межсетевого экрана и других ограничений. Поведение аналогичной привязки в IPv6 зависит от параметров сокета и настроек операционной системы; одного номера порта недостаточно, чтобы понять доступность службы.
4. TCP, UDP и QUIC
TCP предоставляет упорядоченный поток байтов. Он устанавливает соединение, отслеживает доставку, повторно передаёт потерянные данные и управляет потоком и перегрузкой сети. Границы отдельных записей приложения при этом не сохраняются: само приложение должно определять границы сообщений в потоке. Успешное установление TCP-соединения доказывает, что соединение достигло конечной точки, но не гарантирует успех HTTP-запроса или согласования TLS.
UDP отправляет отдельные дейтаграммы без установления соединения по модели TCP и встроенного восстановления доставки. Более узкий набор функций не означает, что приложения поверх UDP обязаны работать ненадёжно. При необходимости они могут добавлять подтверждения, повторную передачу, шифрование и управление перегрузкой. DNS часто использует UDP, но также может работать через TCP и другие транспорты. Если сводить протокол к одному знакомому порту, эти возможности останутся незамеченными.
QUIC — транспортный протокол поверх UDP. Он включает TLS и предоставляет несколько надёжных потоков с возможностями, рассчитанными на современные приложения. HTTP/3 использует QUIC, а HTTP/1.1 и HTTP/2 обычно работают поверх TCP. Поэтому доступность UDP важна для HTTP/3, однако многие браузеры умеют переходить на другую поддерживаемую версию HTTP. Блокировка UDP на пути не означает, что любое HTTPS-соединение обязательно завершится ошибкой.
5. Имена и прикладные протоколы
DNS сопоставляет имена с записями. Запись A содержит IPv4-адрес, AAAA — IPv6-адрес, а CNAME указывает на другое имя. Ответ DNS кешируется согласно времени жизни записи, хотя политика резолвера и приложения может влиять на наблюдаемый результат. Изменение записи не удаляет мгновенно все ответы, ранее сохранённые в чужих кешах.
HTTP описывает запросы и ответы: методы, пути, коды состояния, заголовки и необязательное тело. Ответ 404 означает, что HTTP-сервер ответил, но не нашёл запрошенный ресурс. Это другая проблема, нежели ошибка определения адреса по DNS или истечение времени ожидания соединения. TLS защищает соединение, но не определяет, существует ли путь к статье на сайте. Об этой части пути подробнее рассказано в заметке об HTTPS и TLS.
6. Проверяйте уровни последовательно
На машине с Linux и установленными утилитами следующие команды только читают состояние и дают разные виды сведений. Используйте имя узла, которым вы управляете или который вам разрешено исследовать. Не включайте приватные токены в вывод терминала, который собираетесь кому-то показать.
ip address show
ip route show
ss -ltn
getent ahosts example.com
curl --head https://example.com/Сначала проверьте локальную адресацию и маршрутизацию. Затем изучите разрешение имён, адреса прослушивания и ответы приложения. Команда ping использует ICMP, а не HTTP: успех даёт полезные сведения об одном пути, но неудача может означать лишь фильтрацию ICMP. Записывайте точную ошибку, адрес назначения и время проверки. Меняйте только одно условие за попытку, чтобы успешное повторение действительно помогло установить причину.