Что делает сервер: обработка запроса

Мы проследили путь запроса до сервера. Теперь разберём, что происходит на серверной стороне — как веб-сервер принимает TCP-соединение, определяет, какому приложению предназначен запрос, и формирует ответ.

Веб-сервер как диспетчер

На сервере первым запрос встречает веб-сервер — программа, которая слушает порт 80 (HTTP) и 443 (HTTPS). Самые популярные:

Nginx — быстрый, асинхронный, используется как reverse proxy.
Apache (httpd) — классический, модульная архитектура.
Caddy — современный, автоматический HTTPS из коробки.

Веб-сервер НЕ занимается бизнес-логикой приложения. Его задача — принять соединение, выполнить TLS-терминацию (расшифровать), определить, куда направить запрос, и передать его дальше.

Путь запроса через сервер

Типичная архитектура современного веб-приложения выглядит так:

Интернет → [Nginx:80/443] → [Приложение:3001] → [База данных:5432]
              ↑                      ↑                   ↑
         Reverse proxy          Бизнес-логика         Хранение

Nginx принимает HTTPS, расшифровывает, проверяет базовые правила (rate limit, размер запроса), и проксирует HTTP-запрос к приложению. Приложение (Node.js, Python, Go) выполняет бизнес-логику. Разберём каждый этап.

Шаг 1: Приём соединения и TLS-терминация

Nginx слушает порт 443. Когда приходит TCP-соединение:

Выполняется TLS-рукопожатие (Nginx отдаёт сертификат).
После рукопожатия Nginx расшифровывает трафик и получает чистый HTTP-запрос.
Дальше внутри сервера (Nginx → приложение) трафик идёт по HTTP без шифрования — это внутренняя сеть, защищённая файрволом.

Почему не сделать TLS до самого приложения? Потому что:

Обработка TLS вычислительно дорога — Nginx делает это эффективнее (на C).
Сертификаты нужно настраивать в одном месте.
Приложение не должно думать о HTTPS — оно работает с обычным HTTP.

Шаг 2: Определение виртуального хоста

Один сервер может обслуживать десятки сайтов. Nginx смотрит на заголовок Host из HTTP-запроса, чтобы понять, к какому сайту обращается клиент:

server {
    server_name example.com;
    root /var/www/example;
    ...
}

server {
    server_name api.example.com;
    location / {
        proxy_pass http://localhost:3001;
    }
}

Шаг 3: Роутинг запроса

Определив сайт, Nginx смотрит на путь запроса и решает, что делать:

Статический файл. /logo.png, /style.css, /main.js. Nginx отдаёт их напрямую с диска, не беспокоя приложение. Очень быстро: одно обращение к файловой системе.
Проксирование в приложение. /api/user, /blog/post. Nginx передаёт запрос бэкенд-приложению через proxy_pass.

location /api/ {
    proxy_pass http://localhost:3001;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto https;
}

Заголовки X-Forwarded-For (IP клиента) и X-Forwarded-Proto (исходный протокол) нужны, чтобы приложение знало реального клиента, а не IP Nginx'а.

Шаг 4: Обработка в приложении

Запрос приходит в приложение (например, Express на Node.js). Здесь происходят:

Middleware-цепочка. Парсинг тела (JSON, form-data), логирование, CORS-заголовки, проверка сессии (расшифровка cookie/JWT).
Роутинг. Сопоставление метода (GET/POST) и пути (/api/user) с обработчиком.
Бизнес-логика. Запрос к базе данных, вычисления, формирование ответа.
Отправка ответа. JSON-объект, HTML-страница или ошибка.

// Упрощённый Express-обработчик
app.get('/api/user', async (req, res) => {
  const user = await db.user.findUnique({ where: { id: req.userId } });
  res.json({ name: user.name, email: user.email });
});

Шаг 5: Ответ клиенту

Сформированный ответ проходит обратный путь:

Приложение → Nginx → (шифрование TLS) → Интернет → Браузер

Nginx может на этом этапе сжать ответ (gzip/brotli), добавить security-заголовки (HSTS, CSP), установить cookie. После отправки ответа TCP-соединение может быть закрыто или оставлено открытым (Keep-Alive) для следующего запроса.

Reverse proxy и масштабирование

Nginx как reverse proxy даёт важные возможности:

Балансировка нагрузки. Несколько экземпляров приложения на портах 3001, 3002, 3003 — Nginx распределяет запросы между ними (round-robin, least-connections).
Кэширование. Nginx может кэшировать ответы приложения для одинаковых запросов.
Сжатие. gzip/brotli на уровне reverse proxy, приложение не тратит на это ресурсы.
Rate limiting. Ограничение количества запросов от одного IP для защиты от DDoS.

Проверь себя

Зачем нужен Nginx перед приложением?
Как сервер узнаёт, к какому сайту обращается клиент, если на одном IP несколько сайтов?
Что означает proxy_pass в конфигурации Nginx?

<details> <summary>Ответы</summary>

Nginx эффективно выполняет TLS-терминацию, раздачу статики, балансировку нагрузки, сжатие и защиту от DDoS. Приложение занимается только бизнес-логикой.
По заголовку Host в HTTP-запросе. Клиент отправляет Host: example.com, и сервер выбирает соответствующий виртуальный хост.
proxy_pass указывает, на какой внутренний адрес (и порт) Nginx должен передать запрос для обработки приложением.

</details>

Что унести с урока

Веб-сервер (Nginx) — точка входа: TLS-терминация, статика, проксирование к приложению.
Host-заголовок определяет, к какому сайту/приложению направляется запрос.
Приложение выполняет middleware → роутинг → бизнес-логику → ответ.
Reverse proxy даёт балансировку, кэширование, сжатие без изменения кода приложения.

В следующем уроке разберём, как браузер превращает полученный HTML в видимую страницу — парсинг HTML, CSS и JavaScript, построение DOM и CSSOM.

Что делает сервер: обработка запроса