Long Polling: что это, как работает и где используется

Что такое Long Polling

Long Polling — это паттерн взаимодействия в архитектуре клиент-сервер, при котором клиент инициирует HTTP-запрос, а сервер откладывает отправку ответа до момента, когда появятся новые данные или истечёт заданный тайм-аут. После получения ответа клиент немедленно отправляет следующий запрос, создавая эффект непрерывного соединения.

Техника Long Polling появилась как эволюционное развитие Short Polling для снижения количества пустых HTTP-запросов. В традиционном опросе клиент отправляет запросы каждые N секунд, и сервер отвечает даже при отсутствии новых данных. В Long Polling сервер использует механизм удержания соединения, что радикально уменьшает объём бесполезного трафика.

История возникновения Long Polling

До появления WebSocket в 2011 году Long Polling был основным способом организации реального времени в вебе. Такие компании, как Facebook и Gmail, использовали эту технику для своих чатов и уведомлений в начале 2010-х годов. По данным исследования High Performance Browser Networking (Grigorik, 2013), Long Polling обрабатывал до 95% всех соединений реального времени в крупных веб-приложениях того периода.

Базовый принцип Long Polling

Клиент отправляет стандартный HTTP-запрос к серверу. Сервер, получив запрос, не возвращает ответ немедленно — он помещает запрос в очередь ожидания. Когда на сервере происходит событие (новое сообщение, изменение данных), сервер формирует ответ и отправляет его клиенту. Клиент, получив ответ, сразу создаёт новый Long Polling запрос, и цикл повторяется.

Как работает Long Polling

Long Polling работает по следующей последовательности шагов. Клиент отправляет HTTP GET-запрос к серверному endpoint. Сервер, получив запрос, проверяет наличие новых данных в очереди событий. Если данных нет, сервер удерживает запрос в состоянии ожидания, не отправляя ответ немедленно. Механизм удержания зависит от реализации сервера — чаще всего используется асинхронная обработка с колбэками или событийная архитектура.

Когда на стороне сервера происходит событие (например, пользователь отправил сообщение в чат), сервер формирует HTTP-ответ с телом, содержащим эти данные, и завершает соединение. Клиент получает ответ, обрабатывает данные и немедленно инициирует новый запрос. Если за время ожидания данные не появились, сервер отправляет пустой ответ по истечении тайм-аута, и клиент также пересоздаёт соединение. Timeout обычно составляет 30–60 секунд для баланса между нагрузкой и задержкой.

Тайм-ауты и управление соединением

Ключевой параметр настройки Long Polling — тайм-аут ожидания. Слишком короткий тайм-аут (менее 10 секунд) приводит к увеличению числа запросов, приближая технику к Short Polling. Слишком длинный (более 120 секунд) может вызвать разрыв соединения промежуточными прокси и балансировщиками нагрузки. Рекомендуемое значение для большинства сценариев — 30–45 секунд.

Обработка множественных событий

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

Пример реализации Long Polling на JavaScript

Рассмотрим простую реализацию Long Polling на стороне клиента с использованием современного Fetch API. Клиентская функция отправляет запрос и рекурсивно вызывает себя после получения ответа.

async function longPoll(url) {
    try {
        const response = await fetch(url);
        const data = await response.json();

        handleData(data);
        longPoll(url);
    } catch (error) {
        console.error("Long Polling error", error);
        setTimeout(() => longPoll(url), 3000);
    }
}

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("New event:", event);
        });
    }
}

longPoll("/api/events");

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

Серверная реализация на Node.js

На стороне сервера необходимо удерживать запрос до появления события или истечения тайм-аута. Пример реализации с использованием EventEmitter в Node.js демонстрирует этот механизм.

const express = require("express");
const EventEmitter = require("events");
const app = express();

const eventBus = new EventEmitter();

app.get("/api/events", (req, res) => {
    const timeout = setTimeout(() => {
        res.json({ events: [] });
    }, 30000);

    eventBus.once("new-event", (data) => {
        clearTimeout(timeout);
        res.json({ events: [data] });
    });
});

app.post("/api/events", (req, res) => {
    eventBus.emit("new-event", req.body);
    res.send({ status: "ok" });
});

app.listen(3000);

Серверная часть использует EventEmitter для оповещения ожидающих Long Polling соединений при появлении новых данных. При достижении 30-секундного тайм-аута сервер возвращает пустой массив событий, и клиент создаёт новый запрос.

Когда применяется Long Polling

Long Polling применяется в сценариях, где требуется доставка данных в реальном времени, но использование WebSocket невозможно по техническим или инфраструктурным причинам. Наиболее распространённые случаи — корпоративные прокси и файрволы, блокирующие WebSocket-соединения, а также окружения с ограниченной поддержкой протокола на стороне сервера.

• Чаты и мессенджеры — Long Polling обеспечивает доставку сообщений в веб-версиях мессенджеров, работающих через HTTP без WebSocket.
• Панели мониторинга — системы реального времени для DevOps-метрик, логов и алертов, где важна актуальность данных с задержкой 1–5 секунд.
• Уведомления — push-like доставка оповещений в браузере без использования Service Workers и Push API.
• Ленты активности — социальные сети и новостные ленты с автоматическим обновлением контента при появлении новых записей.
• Совместная работа — Google Docs-like редакторы с базовой синхронизацией изменений между пользователями.

Ключевой фактор выбора Long Polling — обратная совместимость. Все HTTP-клиенты и серверы поддерживают этот метод, что делает его универсальным решением для реального времени без дополнительных зависимостей. По данным HTTP Archive (2024), около 8% всех веб-сайтов продолжают использовать Long Polling для базовой функциональности реального времени.

Long Polling vs Short Polling

Long Polling и Short Polling решают одну задачу — доставку данных от сервера к клиенту — но принципиально различаются по механизму и эффективности. Short Polling использует фиксированный интервал опроса, при котором клиент отправляет HTTP-запросы через равные промежутки времени независимо от того, появились ли на сервере новые данные.

Short Polling проще в реализации, но создаёт значительно большую нагрузку на сервер и сеть при одинаковой частоте обновления данных. Если требуется задержка менее 5 секунд, Short Polling порождает десятки запросов в минуту, в то время как Long Polling использует один запрос на событие или тайм-аут. Для приложений с редкими событиями Long Polling на порядок эффективнее по трафику.

Long Polling vs WebSocket

WebSocket — это полноценный двунаправленный протокол реального времени, работающий поверх TCP после начального HTTP-рукопожатия. В отличие от Long Polling, WebSocket устанавливает одно постоянное соединение и позволяет серверу отправлять данные клиенту в любой момент без создания нового HTTP-запроса.

Выбор между Long Polling и WebSocket зависит от нескольких факторов. Совместимость: Long Polling работает через любые прокси и файрволы, WebSocket может быть заблокирован корпоративными сетями. Производительность: WebSocket имеет меньший overhead (2 байта на фрейм против полных HTTP-заголовков), что критично при высокой частоте сообщений. Масштабируемость: Long Polling требует больше ресурсов на стороне сервера из-за удержания множества соединений, WebSocket использует фиксированное соединение на каждую сессию.

• Long Polling — лучший выбор для приложений с низкой частотой событий (1–10 событий в минуту), ограниченной инфраструктурой или необходимостью поддержки старых браузеров.
• WebSocket — оптимальное решение для высоконагруженных приложений реального времени (биржевые данные, онлайн-игры, коллаборативные редакторы) с сотнями сообщений в секунду.
• Гибридный подход — некоторые приложения используют Long Polling как fallback для клиентов, не поддерживающих WebSocket, с автоматическим переключением протокола.

По данным Mozilla Developer Network (2024), WebSocket поддерживается всеми современными браузерами с версий 2011–2015, но корпоративные прокси (например, Symantec Blue Coat) продолжают блокировать его в 15–20% корпоративных сетей, что сохраняет актуальность Long Polling как fallback-решения.