Конспект: зачем nginx перед приложением

Глава отвечает на вопрос, зачем перед приложением ещё один сервер.

Где встаёт nginx

интернет  →  nginx  →  твоё приложение (8000)
                    ↘  файлы с диска

Что снимается с приложения

Что	Почему не приложением
статика	файлы отдаёт тот, кто умеет это быстро и дёшево (`sendfile` - ядро отправляет файл, не читая его в память приложения)
медленные клиенты	nginx собирает запрос целиком и только потом отдаёт бэкенду - воркер приложения не занят три секунды
TLS	шифрование заканчивается на nginx: сертификаты, продление, набор шифров - его забота
один вход для многих сервисов	магазин на 8000, админка на 8001, картинки с диска - снаружи один адрес
живучесть	бэкенд можно перезапускать и добавлять второй, клиент этого не замечает

Правило, которое стоит запомнить сразу

Всё, что не требует твоего кода, должно решаться до того, как запрос дойдёт до приложения. Nginx - это граница, на которой отсекается лишнее.

Числа, которые стоит помнить

Из каждых 31 запросов за страницу код нужен ровно в одном - остальные тридцать это файлы.

Ответ 500 КБ клиенту на 100 Кбит/с: воркер приложения занят 40 секунд без nginx и 54 миллисекунды с ним. Общее время доставки не меняется, меняется то, чей ресурс им занят.

Буферизация: две стороны

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

Чанкованный поток проходит и с включённой буферизацией; копится ответ с объявленным Content-Length и ответ под сжатием.

Отключается точечно - proxy_buffering off; в нужном location либо заголовком X-Accel-Buffering: no от самого приложения.

Чем он не Apache и не IIS

	Apache	nginx
соединение стоит	процесса (`prefork`) или потока (`worker`, `event`)	записи в списке воркера
пересекающиеся правила	складываются по пути каталогов	побеждает один блок
правила рядом с сайтом	`.htaccess`, без перезагрузки	нет вовсе
модули	грузятся из конфига	вкомпилированы или динамические

Замер медленными клиентами: восемь незаконченных запросов кладут Apache и с prefork, и с event (потолок - восемь воркеров или потоков), а nginx с одним воркером отвечает за 0,001 с и на семистах таких соединениях. event вынес в отдельный поток простаивающие keepalive, но не чтение запроса.

Замер конфигом на одном каталоге: ответ на /sub/ получил от Apache и свой заголовок, и общий, а от nginx - только свой. Оставшийся после переезда .htaccess nginx отдаёт как обычный файл с кодом 200.

IIS - мир Windows: web.config, интеграция с доменом и .NET. Caddy берёт простотой и автоматическими сертификатами; HAProxy, Envoy и Traefik - это балансировщики, а не веб-серверы.

Ловушки джокера

«Приложение и так умеет отдавать файлы». Умеет, но каждый логотип занимает воркер, который мог бы считать заказ. На пике это разница между «медленно» и «упало».
«Буферизация всегда хорошо». Там, где ответ идёт потоком, она копит куски у себя, и человек видит пустой экран вместо прогресса.
Ответ не влез в буфер и уехал во временный файл. Сто клиентов на 20 МБ - два гигабайта на диске; каталог временных файлов кончается молча.
Откладывать nginx до второго бэкенда. К моменту, когда бэкендов станет два, выяснится, что раскидывать запросы некому, а обновить сайт без секундного падения нельзя.