HTTP-сервер в Go: что net/http делает сам и чего не делает, пока не попросят

Что здесь на самом деле спрашивают

Лестница почти всегда такая:

1. «Как сделать веб-сервер на Go?» — разминка: http.HandleFunc и ListenAndServe.
2. «Что такое http.Handler и промежуточный слой?» — проверяют, видит ли кандидат за функцией интерфейс.
3. «Как net/http обслуживает конкурентные запросы?» — вопрос, ответ на который объясняет половину остальных.
4. «Какие таймауты задать серверу?» — здесь видно, был ли у кандидата сервер в продакшене.
5. «Что будет с работой, если клиент ушёл?» — про контекст запроса.
6. «Как остановить сервер, не оборвав запросы?» — graceful shutdown, и ловушка в нём.

Стержень у лестницы один: net/http по умолчанию ничего не ограничивает и ничего не дожидается сам. Каждое «ограничить» и «дождаться» — строка, которую пишет разработчик, и вопросы собеседования — ровно про эти строки.

База: Handler, ServeMux и промежуточный слой

Всё в net/http держится на одном интерфейсе:

type Handler interface {
	ServeHTTP(ResponseWriter, *Request)
}

http.HandlerFunc превращает обычную функцию в Handler, ServeMux — тоже Handler, который выбирает другой обработчик по пути, а http.Server берёт один Handler и обслуживает им соединения. Отсюда промежуточный слой (middleware) — функция, которая принимает Handler и возвращает Handler, обернув вызов своим кодом:

func logging(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		start := time.Now()
		next.ServeHTTP(w, r)
		log.Printf("%s %s %v", r.Method, r.URL.Path, time.Since(start))
	})
}

Ответ уровня Junior на «как сделать веб-сервер»: объявить обработчики — функции func(w http.ResponseWriter, r *http.Request) — зарегистрировать их в http.ServeMux и запустить http.Server с этим мультиплексором. Обработчик — это интерфейс http.Handler, поэтому промежуточный слой пишется как функция Handler → Handler. И сразу оговорка, которую стоит произнести: в продакшене не http.ListenAndServe(addr, mux), а свой http.Server — потому что только у него есть поля таймаутов и метод Shutdown.

Механизм 1: горутина на соединение — и никакого встроенного предела

Десять клиентов, каждый на своём соединении, к обработчику, который спит 200 мс:

1) ГОРУТИНА НА СОЕДИНЕНИЕ
─────────────────────────
  10 запросов, обработчик спит 200 мс: всего 209 мс
  обработчиков одновременно, пик: 10

В этом замере каждый запрос шёл по своему соединению. Но соединение — не запрос, и модель «один запрос = одно соединение = одна горутина» неверна в обе стороны:

1) HTTP/1.1 KEEP-ALIVE: ЗАПРОСЫ ПОДРЯД
──────────────────────────────────────
  10 запросов подряд одним клиентом: соединений у сервера 1

2) HTTP/2: ОДНОВРЕМЕННЫЕ ЗАПРОСЫ
────────────────────────────────
  10 одновременных запросов: 202 мс, новых соединений 0, обработчиков одновременно 10, ответ 200 HTTP/2.0

В HTTP/1.1 с keep-alive одно соединение обслуживает запросы по очереди. В HTTP/2 по одному соединению идут одновременные потоки, и горутина обработчика — у каждого потока (прогон bench/gohttp/protocols.go, HTTP/2 без TLS через Server.Protocols go1.24).

Из этого следуют три вещи, которые стоит уметь сказать.

• Обработчики выполняются одновременно. Изменяемое состояние, к которому обработчики обращаются конкурентно и хотя бы один пишет, без мьютекса или атомарных операций — гонка данных (урок о гонках данных). Неизменяемое состояние — конфигурацию, прочитанную при старте, — можно делить свободно.
• Медленный обработчик сам по себе не задерживает другие соединения. Но общий мьютекс, пул соединений к базе или семафор связывают задержки запросов: кто ждёт общий ресурс, тот ждёт и медленного соседа.
• Встроенного предела на число запросов нет. net/http не держит пула обработчиков с фиксированным размером. Пределы есть, но другие: дескрипторы и очередь accept, память, у HTTP/2 — число одновременных потоков на соединение (по документации HTTP2Config — не меньше 100 по умолчанию), балансировщик перед сервером. Ограничивают явно — таймаутами (Механизм 2) или семафором в промежуточном слое.

Механизм 2: четыре таймаута, и все нулевые

У http.Server четыре поля таймаутов, и по умолчанию все — ноль:

Что это значит на деле: клиент открыл соединение, прислал начало заголовков и замолчал.

2) ТАЙМАУТЫ СЕРВЕРА ПО УМОЛЧАНИЮ
────────────────────────────────
  http.Server{}: ReadTimeout=0s ReadHeaderTimeout=0s WriteTimeout=0s IdleTimeout=0s
  клиент прислал начало заголовков и замолчал:
  ReadHeaderTimeout=0s     через 2000 мс: соединение всё ещё открыто
  ReadHeaderTimeout=300ms  через  301 мс: соединение закрыто сервером

2 с — предел ожидания самого клиента в замере; сервер без таймаута ждал бы дольше. Каждое такое соединение держит горутину и дескриптор, а из Механизма 1 мы знаем, что предела им нет.

Какой таймаут что ограничивает — главное, что здесь спрашивают:

• ReadHeaderTimeout — только чтение заголовков. Документация советует именно его: большинство пользователей предпочтут ReadHeaderTimeout, потому что ReadTimeout не даёт обработчику решать, что медленно для тела конкретного запроса;
• ReadTimeout — всё чтение запроса вместе с телом;
• WriteTimeout — отсчитывается от чтения заголовков, значит, покрывает и работу обработчика: долгий обработчик упрётся в него, даже если сам ответ пишется быстро;
• IdleTimeout — простой между запросами на соединении keep-alive.

Практичный набор для короткого API, который называют на собеседовании, — ReadHeaderTimeout и IdleTimeout, плюс WriteTimeout. Это рекомендация, а не правило: для потоковых ответов — SSE, длинных загрузок, долгих соединений — серверный WriteTimeout оборвал бы законный ответ. Там срок записи задают на запрос: http.NewResponseController(w), метод SetWriteDeadline, а для всего соединения оставляют только защиту на чтение заголовков.

Рядом с таймаутами стоит ещё один встроенный предел, и он как раз не ноль: MaxHeaderBytes.

5) MaxHeaderBytes ПО УМОЛЧАНИЮ
──────────────────────────────
  http.DefaultMaxHeaderBytes = 1048576
  заголовок    4096 байт: 200 OK
  заголовок 2097152 байт: 431 Request Header Fields Too Large

Мегабайт заголовков на запрос — много; если сервис их не ждёт, предел опускают.

Про то, почему таймаут ограничивает ожидание, но не работу, и почему таймауты по цепочке сервисов не складываются, — урок о таймаутах и дедлайнах в линии SRE.

Механизм 3: клиент ушёл — контекст отменён, работа идёт

Что сервер делает, когда клиент перестал ждать:

Контекст отменяется, когда сервер обнаружил разрыв или отмену, — это сигнал для кода, а не мгновенное уведомление о том, что клиента нет. И больше сервер ничего не делает. Два обработчика с одинаковой работой на 500 мс, клиент ждёт 100 мс и уходит:

3) КОНТЕКСТ ЗАПРОСА, КОГДА КЛИЕНТ УШЁЛ
──────────────────────────────────────
  клиент ждёт ответа 100 мс и уходит; работа обработчика — 500 мс
  слушает r.Context()    через  101 мс: остановился: context canceled
  не слушает контекст    через  500 мс: доделал работу; контекст: context canceled

Второй обработчик потратил 400 мс на ответ, который никто не прочитает, — хотя его контекст был отменён уже давно. Отмена в Go — кооперативная: остановится только код, который ctx.Done() слушает. Поэтому r.Context() передают дальше — в запрос к базе, в исходящий HTTP-запрос, в долгий цикл. Как устроена отмена контекста, разобрано в уроке о context.

Откуда берётся этот контекст, тоже настраивается: Server.BaseContext задаёт базовый контекст всех запросов сервера, Server.ConnContext — контекст соединения. Через них в обработчики попадают, например, общий сигнал остановки или данные о соединении.

Механизм 4: Shutdown, Close — и ListenAndServe, который не ждёт

Остановить сервер можно двумя методами. Shutdown закрывает слушателей, закрывает простаивающие соединения и ждёт, пока активные станут простаивающими. Close немедленно закрывает слушателей и обычные соединения — новые, активные и простаивающие. Пять запросов по 300 мс, вызов через 100 мс после их старта:

4) ОСТАНОВКА: Shutdown, Close И ВОЗВРАТ ИЗ Serve
────────────────────────────────────────────────
  Shutdown через 100 мс после старта пяти запросов по 300 мс:
    Serve вернул http: Server closed через 0 мс после вызова
    Shutdown вернул управление через 276 мс
    запросы в полёте: 200 — 5, ошибка — 0
    новый запрос после вызова: отклонён
  Close через 100 мс после старта пяти запросов по 300 мс:
    Serve вернул http: Server closed через 0 мс после вызова
    Close вернул управление через 1 мс
    запросы в полёте: 200 — 0, ошибка — 5
    новый запрос после вызова: отклонён

Shutdown дождался всех пяти, Close оборвал все пять. Но смотреть надо на первую строку каждого блока: Serve вернулся через 0 мс — в обоих случаях, когда запросы ещё работали. Документация предупреждает об этом прямо:

Типичный код, который выглядит правильно и обрывает запросы:

go func() {
	<-sigterm
	srv.Shutdown(ctx)
}()
log.Fatal(srv.ListenAndServe()) // вернётся сразу — и main завершится

ListenAndServe вернул ErrServerClosed через 0 мс, log.Fatal завершил процесс — и Shutdown не успел дождаться ни одного запроса. Правильный порядок обратный: ListenAndServe — в горутине, а main ждёт сигнала, зовёт Shutdown с контекстом-дедлайном и дожидается его возврата. ErrServerClosed из ListenAndServe — не ошибка, а штатный сигнал.

Перехваченные соединения — вне жизненного цикла сервера. WebSocket и всё, что обработчик забрал себе через Hijack, ни Close, ни Shutdown не трогают:

4) Close И ПЕРЕХВАЧЕННОЕ СОЕДИНЕНИЕ
───────────────────────────────────
  после srv.Close() перехваченное соединение ответило: "эхо: после Close"

Для них есть RegisterOnShutdown: функция вызывается при Shutdown и должна запустить остановку, специфичную для протокола, — например, разослать клиентам WebSocket кадр закрытия, — но не ждать её завершения. Дождаться самих соединений — отдельная работа приложения.

Что делать до Shutdown — снять экземпляр с балансировщика, дать ему дренироваться, уложиться в льготный срок оркестратора, — не специфика Go, и это разобрано в уроке о graceful shutdown линии SRE.

Глубже: паника в обработчике и шаблоны ServeMux

Паника не роняет процесс. В отличие от паники в обычной горутине, паника в обработчике перехватывается сервером:

5) ПАНИКА В ОБРАБОТЧИКЕ
───────────────────────
  GET /boom: ошибка у клиента: true
  GET /ok после паники: 200
  журнал сервера: http: panic serving 127.0.0.1:…: boom

Клиент ответа не получил, сервер записал стек в журнал и продолжил работу. Что именно стало с соединением, зависит от протокола — документация говорит: сервер либо закрывает сетевое соединение, либо отправляет HTTP/2 RST_STREAM. Тот же обработчик под HTTP/1.1 и под HTTP/2:

3) ПАНИКА В ОБРАБОТЧИКЕ: HTTP/1.1 ПРОТИВ HTTP/2
───────────────────────────────────────────────
  HTTP/1.1: /ok -> 200 HTTP/1.1; /boom -> ошибка; /ok -> 200 HTTP/1.1
            соединение переиспользовано: false, соединений всего 3, обработчик /boom вызван 2 раз
  HTTP/2  : /ok -> 200 HTTP/2.0; /boom -> ошибка; /ok -> 200 HTTP/2.0
            соединение переиспользовано: true, соединений всего 1, обработчик /boom вызван 1 раз

В HTTP/1.1 соединение закрыто, и следующий запрос пошёл по новому. В HTTP/2 сброшен только поток запроса — соединение осталось жить, по нему пошёл следующий запрос. И находка, которой не ждали: под HTTP/1.1 обработчик /boom вызвался дважды — клиентский Transport сам повторил идемпотентный GET после сетевой ошибки на уже использованном соединении. Для обработчика с побочными эффектами на GET это значит два выполнения.

Защита — только для горутины обработчика: если обработчик запустил свою горутину и паника случилась в ней, процесс упадёт (механизм — в уроке о defer, panic и recover). И «последствия ограничены запросом» — предположение сервера, а не гарантия: мьютекс, захваченный до паники и не отпущенный, остаётся захваченным.

Шаблоны ServeMux с Go 1.22 умеют метод и параметр пути:

6) ServeMux С ШАБЛОНАМИ GO 1.22
───────────────────────────────
  GET  /items/42    -> 200 id=42
  POST /items/42    -> 405 Method Not Allowed | Allow: GET, HEAD
  GET  /items/42/x  -> 404 404 page not found

Шаблон GET /items/{id}, значение — через r.PathValue("id"); на чужой метод — 405 с заголовком Allow, без единой строки кода. Если запросу подходят несколько шаблонов, выбирается самый конкретный:

Отсюда ловушка, которую проверяет первая задача практики: 405 сервер отдаёт, только если путь не подходит больше ни под один шаблон.

Как отвечать на собеседовании

Короткий ответ: обработчик — интерфейс http.Handler, ServeMux раскладывает запросы по путям, промежуточный слой — функция Handler → Handler. Сервер обслуживает каждое соединение в своей горутине (в HTTP/2 — каждый поток), поэтому общее изменяемое состояние обработчиков нужно защищать. В продакшене — свой http.Server с таймаутами и остановка через Shutdown.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «какие таймауты» — что по умолчанию. «У http.Server{} все четыре нулевые, то есть их нет. Клиент, не дославший заголовки, у меня держал соединение и через 2 с; с ReadHeaderTimeout 300 мс — закрыт через 301 мс. Минимум — ReadHeaderTimeout и IdleTimeout; WriteTimeout покрывает и работу обработчика».

На «клиент ушёл» — кооперативная отмена. «r.Context() отменяется, но работу останавливает только код, который его слушает: у меня обработчик без проверки контекста доделал 500 мс после того, как клиент ушёл через 100. Контекст запроса передают в базу и исходящие вызовы».

На graceful shutdown — ловушка с возвратом. «Shutdown дожидается запросов, Close обрывает. Но ListenAndServe возвращает ErrServerClosed сразу после вызова Shutdown — у меня через 0 мс. Если main на этом завершается, запросы обрываются. Ждать надо возврата Shutdown».

На «а если обработчик запаникует» — граница. «Сервер перехватит панику, дошедшую до ServeHTTP, и запишет в журнал; процесс жив. В HTTP/1.1 он закроет соединение, в HTTP/2 сбросит только поток. Но паника в горутине, запущенной из обработчика, этой защитой не покрыта и уронит процесс».

На «как сервер обслуживает конкурентные запросы» — «горутина на соединение, а в HTTP/2 — на поток; встроенного пула и предела на число запросов нет: десять запросов по 200 мс на десяти соединениях у меня заняли 209 мс. Соединение — не запрос: keep-alive пропускает по нему запросы по очереди, HTTP/2 — одновременно».

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

mux := http.NewServeMux()
mux.HandleFunc("GET /users/{id}", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "user ", r.PathValue("id"))
})
mux.HandleFunc("/users/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "fallback")
})

200 user 7
200 fallback
200 fallback

200 user 7
405 Method Not Allowed
200 fallback

200 user 7
405 Method Not Allowed
404 404 page not found

200 fallback
200 fallback
200 fallback

Проверка знаний