Что такое HTTP и как работает протокол передачи гипертекста
Подробное руководство по HTTP: цикл запрос-ответ, структура сообщений, методы, коды состояния, куки, версии протокола и HTTPS. Поймите, как HTTP обеспечивает веб-скрапинг и как прокси взаимодействуют с ним.
Основа веб-коммуникации
HTTP (протокол передачи гипертекста) — это протокол, на котором работает веб. Каждый раз, когда вы загружаете страницу, отправляете форму или запрашиваете API, HTTP определяет, как клиенты (браузеры, скраперы) и серверы обмениваются данными. Понимание его внутреннего устройства необходимо разработчикам, сетевым инженерам и всем, кто работает с прокси.
Цикл запроса и ответа
HTTP — это протокол запроса и ответа. Клиент отправляет запрос серверу, который обрабатывает его и возвращает ответ. Этот цикл — основа всех веб-взаимодействий. Запрос и ответ состоят из трёх частей: стартовой строки, заголовков и необязательного тела.
Структура запроса
Типичный HTTP-запрос выглядит так:
GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Первая строка — это строка запроса, в ней указаны метод (GET), путь (/index.html) и версия протокола (HTTP/1.1). Далее идут заголовки, по одному на строку; список завершается пустой строкой. После заголовков может идти необязательное тело — оно используется с методами вроде POST.Структура ответа
Сервер отвечает строкой состояния:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<html>...</html>
Строка состояния включает версию протокола, код состояния (200) и пояснение (OK). Заголовки и тело устроены так же, как в запросе.
Методы HTTP (глаголы)
HTTP определяет несколько методов, которые указывают желаемое действие с ресурсом. Самые распространённые:
- GET – получить ресурс. Не должен содержать тело. Идемпотентен.
- POST – отправить данные на обработку. Не идемпотентен.
- PUT – полностью заменить ресурс. Идемпотентен.
- DELETE – удалить ресурс. Идемпотентен.
- HEAD – как GET, но возвращает только заголовки, без тела. Полезен для проверки метаданных.
- OPTIONS – возвращает методы, поддерживаемые сервером для указанного URL.
При парсинге сайтов чаще всего используют GET и POST. Прокси передают такие запросы без изменений, но в зависимости от настроек могут добавлять или менять заголовки вроде X-Forwarded-For.
Коды состояния: ответ сервера
Каждый ответ HTTP содержит трёхзначный код состояния, который показывает результат. Они делятся на пять классов:
- 2xx (успех): 200 OK, 201 Created, 204 No Content.
- 3xx (перенаправление): 301 Moved Permanently, 302 Found, 304 Not Modified.
- 4xx (ошибка клиента): 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests.
- 5xx (ошибка сервера): 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.
Для парсеров особенно важен 429: он сигнализирует об ограничении частоты запросов. Прокси помогают распределять запросы, чтобы не вызывать такие ответы.
Протокол без состояния и cookie
Сам по себе HTTP не хранит состояние — каждый запрос независим, и серверы не помнят предыдущие взаимодействия. Чтобы поддерживать состояние (например, сеанс входа), ввели cookie. Сервер отправляет в ответе заголовок Set-Cookie, а клиент передаёт его в последующих запросах через заголовок Cookie. При парсинге через прокси управление cookie критично: каждому прокси может понадобиться собственное хранилище cookie, чтобы избежать конфликтов сеансов.
Версии HTTP: от 1.1 до 3
HTTP/1.1 вышел в 1997 году и до сих пор широко используется. Он поддерживает постоянные соединения, chunked transfer encoding и заголовки кеширования. Однако ему свойственна блокировка начала очереди (head-of-line blocking): один медленный запрос может задерживать другие в том же соединении.
HTTP/2 (2015) решил эту проблему с помощью мультиплексирования: несколько запросов и ответов могут чередоваться в одном TCP-соединении. Он также использует двоичное кадрирование вместо текста, а server push позволяет серверам отправлять ресурсы до того, как их запросят. Для прокси HTTP/2 требует понимания мультиплексирования соединений и может обрабатываться прозрачно.
HTTP/3 (2022) использует QUIC — транспортный протокол на основе UDP вместо TCP. Это ещё сильнее снижает задержку, улучшает мультиплексирование и даёт лучшую производительность в сетях с потерями. Его внедрение растёт, но многие прокси всё ещё работают на уровне HTTP/1.1.
HTTPS: шифрование с помощью TLS
HTTPS (HTTP Secure) оборачивает HTTP в TLS (Transport Layer Security), шифруя все данные при передаче. Это защищает от прослушивания и подмены. При парсинге сайтов HTTPS создаёт сложности: прокси, выполняющие MITM-расшифровку (перехват TLS), видят открытый текст, а прокси без расшифровки видят только зашифрованные данные, что ограничивает изменение заголовков. Большинство публичных прокси поддерживают пропуск TLS без расшифровки (TLS passthrough), но соблюдайте осторожность, если нужно просматривать или менять содержимое запроса.
HTTP и прокси при парсинге сайтов
При использовании HTTP-прокси клиент отправляет запросы прокси, а тот пересылает их целевому серверу. Прокси может менять заголовки (например, добавлять X-Forwarded-For) или обрабатывать аутентификацию. Понимание структуры HTTP помогает находить проблемы: например, ошибку может вызвать неправильная строка запроса или отсутствующий заголовок Host. Прокси также влияют на кеширование и повторное использование соединений. Для надёжного парсинга используйте прокси, который сохраняет исходные заголовки, если только вы не собираетесь их менять.
Всегда помните о безопасности и законности: бесплатные публичные прокси часто работают на стороне третьих лиц и могут записывать или изменять трафик. Соблюдайте robots.txt и условия обслуживания. Используйте HTTPS-соединения для защиты чувствительных данных и никогда не отправляйте личную информацию через недоверенные прокси.
Подробнее о типах прокси — в нашем руководстве по типам прокси. Чтобы проверить, не раскрывает ли прокси ваш IP, воспользуйтесь нашим инструментом What Is My IP. А чтобы проверить анонимность любого прокси, попробуйте Proxy Checker.