Сетевые протоколы и HTTP: как сайт и посетитель договариваются об обмене данными

Что такое сетевой протокол и при чём тут HTTP?

Каждый раз, когда посетитель открывает страницу, его телефон или компьютер обменивается данными с сервером, а между ними стоит оборудование разных производителей на разных системах. Чтобы все эти устройства понимали друг друга, нужен общий стандарт. По объяснению Практикума, сетевой протокол задаёт единые правила для всех участников сети: формат данных, порядок их передачи и реакцию устройства, если пакет не дошёл.

Данные при этом идут не единым потоком. В том же материале сказано, что они разбиваются на пакеты, которые путешествуют по сети самостоятельно и собираются на месте. Если контрольная сумма не совпала, получатель запрашивает повторную отправку конкретного пакета, и весь файл заново не передаётся, поэтому передача остаётся экономной и надёжной.

HTTP отвечает за то, что видит пользователь. По обзору MDN, это протокол для получения ресурсов, например HTML-документов, а клиент и сервер обмениваются отдельными сообщениями. Браузер запрашивает страницу, получает ответ, затем отдельными запросами подтягивает стили, скрипты и картинки. Если вы только знакомитесь с темой, начните с материала про устройство интернета.

Пример из истории сети. По рассказу на Хабре, агентство DARPA построило ARPANET с требованием пережить ядерный взрыв. Когда к нему подключились Великобритания и Франция, каждый участник работал по собственным правилам, потому что стандартов не было. Комитет из трёх стран, Великобритании, Франции и США, свёл эти правила в единую модель из семи уровней, и по ней сеть строили дальше.

Как данные проходят путь от браузера до сервера?

Сначала браузер должен узнать адрес сервера. Человек вводит доменное имя, а числовой адрес находит система доменных имён: по описанию Selectel, DNS-сервер позволяет людям не запоминать адреса устройств. Затем браузер подключается к нужному порту. В том же материале приведены примеры: для SSH используется порт 22, для HTTP 80, для HTTPS 443.

Дальше работает многоуровневая схема. В материале Практикума сказано, что TCP/IP объединяет семь уровней учебной модели OSI в четыре, и именно по ней живёт интернет. HTTP находится на верхнем, прикладном уровне, а в обзоре MDN уточняется, что он использует соединение TCP для пересылки сообщений. Сам запрос проходит несколько шагов.

1. Браузер находит IP-адрес домена через DNS.
2. Открывает TCP-соединение, а для HTTPS ещё договаривается о шифровании.
3. Отправляет запрос: метод, путь к странице и заголовки, например Host.
4. Читает ответ: код статуса, заголовки и содержимое страницы.
5. Закрывает соединение или оставляет его для следующих запросов.

Любой шаг может стать узким местом. Медленный ответ DNS, долгое установление соединения или тяжёлая картинка в ответе добавляют секунды к загрузке, которые видит посетитель. Поэтому разбирать задержку стоит по порядку, от адреса к содержимому: у каждого шага есть свой инструмент проверки, от вкладки Network в браузере до команды curl.

Основные сетевые протоколы и их роли

Протоколов в интернете около 7000, как отмечает Практикум в том же материале, но в повседневной работе сети задействован небольшой набор. Для владельца проекта полезно знать пять ролей, на которых держится обычный сайт.

• HTTP и HTTPS - передача страниц и ответов сервера.
• DNS - перевод доменного имени в IP-адрес.
• TCP и UDP - доставка данных с гарантиями или без них.
• IP - адресация и маршрут пакетов между сетями.
• SSH - защищённый удалённый доступ к серверу, который нужен администратору.

Главная развилка лежит на транспортном уровне. Практикум описывает, что TCP устанавливает связь перед передачей данных: отправитель и получатель обмениваются тремя служебными пакетами, это называется тройным рукопожатием. UDP, наоборот, не устанавливает соединение и не ждёт подтверждений, поэтому работает быстрее, но без гарантий.

Для маркетолога вывод практичный. Страницы, формы заявок и оплата идут по TCP, потому что потеря данных там недопустима. UDP подходит там, где скорость важнее полноты, например в видеозвонках. Если видео в звонке подвисает, а страница при той же связи открывается целиком, это нормальное поведение разных протоколов.

Есть и защитные протоколы. Практикум называет SSH протоколом защищённого удалённого доступа к серверам, а TLS отвечает за шифрование веб-соединений. Администратор, который подключается к серверу хостинга по SSH, а не по открытым каналам, закрывает целый класс рисков, а владелец проекта, который проверяет срок действия сертификата TLS, не получает неожиданных предупреждений браузера у посетителей.

Как работает HTTP: методы, коды ответа и куки

Сообщение в HTTP бывает двух видов: запрос и ответ. В запросе указаны метод, путь к ресурсу и заголовки. По обзору MDN, частые операции - получение ресурса методом GET и отправка формы методом POST. Ответ начинается с кода статуса, и этот код главный сигнал для владельца проекта.

Коды бывают разных групп, от 2xx до 5xx, и по первой цифре видно, что случилось. Справка Google о кодах статуса разбирает, как каждая группа влияет на сканирование. Например, все ошибки 4xx, кроме 429, робот обрабатывает одинаково: считает, что контента на этом адресе нет.

Сам HTTP не помнит прошлых запросов: по MDN, между двумя запросами подряд связи нет. Поэтому корзина интернет-магазина держится на файлах cookie: они позволяют использовать сессии с сохранением состояния. Если корзина пустеет при каждом переходе, проверяйте, доходят ли куки до браузера и не блокирует ли их настройка домена.

Заголовки тоже входят в сообщение и управляют поведением: через них передаются язык, тип содержимого, срок кэширования. По MDN, начиная с HTTP/1.1 заголовок Host позволяет нескольким серверам использовать один и тот же IP-адрес, поэтому десятки проектов могут жить на одном хостинге. Для вас это значит, что при проблемах с адресом стоит смотреть именно заголовки ответа, а не только содержимое страницы.

Отсюда практический вывод для магазина. Если страницу снятого товара оставить с ответом 404, робот Google, как сказано в той же справке, контент таких адресов не использует, и ранее проиндексированный адрес будет удалён из индекса. Когда товар вернётся, адрес нужно вернуть и проверить, что он снова отвечает кодом 200.

Чем HTTPS отличается от HTTP и зачем он нужен?

HTTPS - это HTTP поверх шифрования. Шифрованием занимается TLS: по материалу Практикума, это протокол шифрования соединения между клиентом и сервером, а буква S в HTTPS, SMTPS и SFTP означает именно его. Без шифрования данные формы, включая логины и номера карт, могут прочитать узлы на пути, а браузер пометит страницу как небезопасную.

Для поиска это давно не мелочь. В блоге Google Search Central сообщили, что после тестов HTTPS сделали фактором ранжирования: тогда он имел небольшой вес и учитывался менее чем при 1 % запросов по всему миру, а со временем Google планировал усилить его роль. Сигнал был слабым, но направление задано, и перешедший раньше избавил себя от будущих проблем.

В той же записи перечислены советы для переезда. Они подходят и сегодня как рабочий минимум.

• Выберите тип сертификата: для одного домена, нескольких доменов или групповой.
• По возможности разрешите поисковым системам индексировать страницы.
• Для ресурсов внутри одного защищённого домена задавайте относительные URL.
• Не запрещайте сканирование HTTPS-версии в файле robots.txt.

После подключения сертификата настройте постоянный редирект с http на https и проверьте, что страница не подгружает картинки и скрипты по незащищённому адресу. Технически это правила веб-сервера: как они записываются, объясняет материал про Nginx, а вам важно убедиться, что каждый старый адрес ведёт на новый за один переход.

Что изменили HTTP/2 и HTTP/3

Каждая версия HTTP решала проблему предыдущей. Cloudflare в своём разборе напоминает, что в HTTP/1.0 на каждую пару запрос-ответ создавалось новое TCP-соединение, и каждый запрос платил задержкой на рукопожатие. HTTP/1.1 разрешил использовать соединение повторно, а HTTP/2, по обзору MDN, добавил мультиплексирование: несколько сообщений идут по одному соединению.

У HTTP/2 осталась слабость. По тому же разбору, потеря одного пакета задерживает все запросы на соединении, потому что TCP обязан доставить поток байтов по порядку. HTTP/3 меняет транспорт: вместо TCP он использует QUIC на базе UDP. QUIC совмещает рукопожатие TCP с рукопожатием TLS 1.3, и благодаря этому соединение устанавливается быстрее.

Показательна история внедрения. За год до этого Cloudflare объявила о предварительной поддержке и открыла лист ожидания, а затем сообщила, что QUIC и HTTP/3 доступны в её сети: клиентам из списка оставалось включить функцию переключателем в панели. Вместе с ней выступили Chrome и curl: Chrome Canary и утилита curl уже могли обращаться к серверам Cloudflare по HTTP/3. Это решало проблему курицы и яйца: новый протокол нужен и серверам, и клиентам одновременно, иначе он бесполезен.

HTTP/3 должен сделать веб лучше для всех.

Райан Гамильтон, инженер Google, в том же разборе Cloudflare

Проверить протокол своего проекта можно за минуту. Cloudflare описывает, что версию протокола видно во вкладке Network инструментов разработчика Chrome, а curl с ключом --http3 отправляет запрос по HTTP/3. Включение новой версии обычно настраивает хостинг или CDN, а ваша задача - замерить скорость страниц до и после, не полагаясь на ощущения.

Протоколы и SEO: что проверить и каких ошибок избегать

Для поискового робота код ответа - первое, что он узнаёт о странице. В той же справке Google сказано, что при ошибках 5xx и 429 роботы временно замедляют сканирование, а код 429 трактуется как перегрузка сервера. Поэтому при сбоях хостинга или слишком жёстком ограничении запросов страдает обход всего проекта сразу.

Второй рычаг - редиректы. Допустим, у главной есть несколько вариантов адреса: https://example.com/home, http://home.example.com и https://www.example.com. Google советует выбрать один каноническим и перенаправлять на него остальные. Постоянная переадресация показывает в результатах конечную страницу, а временная исходную, поэтому при переезде на HTTPS нужен именно постоянный редирект.

Длина цепочки тоже важна. По справке о кодах статуса, по умолчанию роботы Google проходят до 10 переходов, но каждый лишний шаг замедляет и посетителя. Соберите правила в одно условие, чтобы http, www и слэш обрабатывались за один переход. Вот ошибки, которые встречаются чаще всего.

• Временный редирект 302 при постоянном переезде.
• Цепочка из трёх и более переходов вместо одного.
• Пустая страница с кодом 200 вместо 404: в Search Console она получит пометку soft 404.
• Смешанное содержимое: страница по https подгружает ресурсы по http.
• Закрытый в robots.txt доступ к HTTPS-версии.

Полезно закрепить процесс: после любой правки конфигурации, переезда или смены хостинга прогоните один и тот же короткий список адресов и сохраните результат. Через месяц у вас будет история ответов, и любое отклонение, будь то новая цепочка редиректов или внезапная ошибка 5xx, станет заметно сразу, а не после падения трафика.

Практический минимум для проверки: откройте код ответа главной, ключевых разделов и заведомо несуществующего адреса, пройдите по цепочке с http на https и убедитесь, что попадаете на каноническую версию за один переход. Общую логику такой технической работы вы найдёте в базовом руководстве по SEO.

Частые вопросы