HTTP-сервер на net/http

Роутер 1.22: проверил все четыре случая

Завёл в http.ServeMux три шаблона и постучал. GET /users/42 при шаблоне «GET /users/{id}» вернул 200 и id=42 через r.PathValue("id"). POST по тому же адресу вернул 405 с заголовком Allow: GET, HEAD - роутер сам разбирается с методами, руками это писать больше не надо.

Шаблон «GET /files/{path...}» с многоточием ловит остаток пути целиком: запрос /files/a/b/c.txt отдал path=a/b/c.txt. А обычная переменная {id} захватывает ровно один сегмент - /users/42/extra ушёл в 404.

// Сам обработчик - функция с сигнатурой func(w http.ResponseWriter, r *http.Request). Интерфейс http.Handler требует метод ServeHTTP, а http.HandlerFunc - адаптер, превращающий обычную функцию в такой интерфейс.

PathValue

значение переменной пути из шаблона, с 1.22

{path...}

многосегментная переменная: ловит остаток пути

Заголовки после первого Write уже никуда не поедут

Опыт на настоящем сервере: обработчик пишет тело, потом ставит заголовок и зовёт WriteHeader(418). Клиент получил статус 200 и пустой заголовок. А сервер написал в лог: http: superfluous response.WriteHeader call from main.go:31.

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

// Отсюда порядок в любом обработчике: сперва заголовки, потом WriteHeader, потом тело. Особенно это касается ошибок - развилку «а вдруг ошибка» нужно проходить до первой записи.

порядок записи

заголовки, статус, тело - и только в таком порядке

superfluous WriteHeader

сообщение сервера о вызове после первой записи

Прод: таймауты и остановка

Напечатал поля пустого http.Server{}: ReadTimeout 0s, WriteTimeout 0s, IdleTimeout 0s. Ноль означает «без ограничения», то есть по умолчанию медленный или вредный клиент может держать соединение сколько угодно - это и есть атака slowloris. Поэтому все три задают руками, а размер тела ограничивают через http.MaxBytesReader.

Мягкую остановку тоже проверил. Клиент ушёл в запрос на 200 мс, через 30 мс я позвал srv.Shutdown(ctx): вызов вернулся через 280 мс, а клиент получил полный ответ. Сервер перестал принимать новые соединения и дал текущему доработать - без этого каждая выкатка рвёт запросы на середине.

// Таймауты сервера не ограничивают время работы самого обработчика: он может считать что-то вечно. Для этого нужен контекст запроса с дедлайном, и его же протаскивают дальше в базу и соседние сервисы.

graceful shutdown

отказ от новых соединений плюс ожидание текущих

slowloris

удержание соединений медленной отправкой байтов

Как отвечать: «Как устроен HTTP-сервер в Go и что нужно добавить для прода?»

Обработчик это обычная функция с сигнатурой func(w http.ResponseWriter, r *http.Request), интерфейс http.Handler требует метод ServeHTTP, а HandlerFunc - адаптер между ними. Маршрутизацию с версии 1.22 закрывает стандартный ServeMux: в шаблоне пишется метод и переменные пути, например GET /users/{id}, значение достаётся через r.PathValue, и роутер сам отдаёт 405 с заголовком Allow, если метод не совпал. Многоточие в шаблоне ловит остаток пути целиком. На каждое соединение сервер поднимает горутину, поэтому обработчик обязан быть безопасен для конкурентного вызова, а общее состояние - под мьютексом; я замерял, пятьдесят одновременных запросов дали больше двухсот пятидесяти горутин. Для прода добавляю три вещи. Первое - таймауты: у пустого http.Server все три поля нулевые, то есть ограничений нет вообще, и медленный клиент удерживает соединения бесконечно, это классический slowloris. Плюс ограничение размера тела через MaxBytesReader. Второе - мягкую остановку через Shutdown с контекстом: я проверял, вызов ждёт текущий запрос и клиент получает полный ответ, а без этого выкатка рвёт запросы. Третье - проброс r.Context дальше в базу и соседние сервисы, чтобы при отвале клиента не доделывать ненужную работу.

Сильный ответ: база подана коротко и с актуальным роутингом 1.22 вплоть до автоматического 405, а дальше идёт эксплуатационный слой - нулевые таймауты с названной атакой, мягкая остановка с проверенным поведением и проброс контекста. Видно человека, который выкатывал сервис.

На чём валят

• −Не задают таймауты серверу. У пустого http.Server все три нулевые, то есть без ограничений.
• −Пишут заголовки после первого Write. Статус останется 200, а в лог уедет superfluous WriteHeader.
• −Считают обработчик однопоточным и держат общее состояние без мьютекса.
• −Выкатывают без мягкой остановки и рвут запросы на каждом деплое.
• −Не пробрасывают r.Context дальше: клиент ушёл, а работа продолжается.