Forwarded from Николай Тузов
Таймауты HTTP Server в Go - как работают и зачем нужны
В стандартной библиотеке Go есть замечательный пакет
- ReadHeaderTimeout - время, отводимое на чтение заголовков запроса
- ReadTimeout - максимальная продолжительность чтения полного запроса, включая тело
- WriteTimeout - максимальное время ожидания до окончания записи ответа
- IdleTimeout - максимальное время ожидания следующего запроса, используется keep-alive
Чтобы лучше уложить в голове, как они используются, давайте вспомним, как сервер работает с входящими запросами:
- Борьба с Slowloris атаками: это тип атаки, при которой злоумышленник устанавливает соединение с сервером и отправляет запрос нуу оооочень медленно. Это может приводить к исчерпанию ресурсов сервера и его последующему отказу. Установка
- Отправка больших данных: возможно, клиенты отправляют нам что-то очень большое, и мы не хотим чтобы это заняло слишком много времени. В этом случае помогает
- Ограничение использования ресурсов: При большом количестве запросов, особенно в микросервисных архитектурах, установка
————
☁️ Если я где-то ошибся или был неточен, пожалуйста, напишите об этом в комментах, я всё поправлю
💻 Идея написания этого поста возникла во время записи ролика по REST API, в котором у меня не хватило времени на полноценное объяснение
#гайды #golang #http
В стандартной библиотеке Go есть замечательный пакет
net/http, в котором есть структура http.Server. Это основная структура для написания сервиса, обрабатывающего HTTP запросы. У http.Server довольно много интересных параметров, но здесь нам интересны таймауты:- ReadHeaderTimeout - время, отводимое на чтение заголовков запроса
- ReadTimeout - максимальная продолжительность чтения полного запроса, включая тело
- WriteTimeout - максимальное время ожидания до окончания записи ответа
- IdleTimeout - максимальное время ожидания следующего запроса, используется keep-alive
Чтобы лучше уложить в голове, как они используются, давайте вспомним, как сервер работает с входящими запросами:
1. Подключение установленоЗачем нужно столько таймаутов?
|--- ReadHeaderTimeout (если установлен) ---|
2. Заголовки запроса получены
|--- ReadTimeout (если установлен) ---|
3. Тело запроса получено, начинается обработка запроса
4. Обработка завершена, сервер начинает отправлять ответ
|--- WriteTimeout (если установлен) ---|
5. Ответ полностью отправлен клиенту
|--- IdleTimeout (если установлен и соединение остается открытым) ---|
6. Если не было другого запроса в течение IdleTimeout, соединение закрывается
7. Если новый запрос получен до IdleTimeout, процесс начинается сначала с шага 2
- Борьба с Slowloris атаками: это тип атаки, при которой злоумышленник устанавливает соединение с сервером и отправляет запрос нуу оооочень медленно. Это может приводить к исчерпанию ресурсов сервера и его последующему отказу. Установка
ReadHeaderTimeout и ReadTimeout может помочь.- Отправка больших данных: возможно, клиенты отправляют нам что-то очень большое, и мы не хотим чтобы это заняло слишком много времени. В этом случае помогает
ReadTimeout
- Обратная ситуация - работа с ооочень медленными клиентами: Встречаются клиенты со слабым каналом, которые принимают наш ответ очень долго (например, некоторые устройства IoT или просто регионы со слабым интернет-покрытием). В этом случае, если не установить WriteTimeout, сервер может ждать бесконечно долго, пытаясь отправить ответ, что может привести к исчерпанию ресурсов.- Ограничение использования ресурсов: При большом количестве запросов, особенно в микросервисных архитектурах, установка
IdleTimeout помогает освободить ресурсы от долгоживущих соединений, которые больше не используются.————
#гайды #golang #http
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥28👍16
Прокачали логгер, теперь взялись за HTTP-роутер
https://eli.thegreenplace.net/2023/better-http-server-routing-in-go-122/
- Proposal
- Документация
Пример кода:
1. В первом хэнделере мы видим явное указание HTTP-метода (GET)
2. Во втором - компонент
За ссылку спасибо @batazor
#go_updates #http #mux
https://eli.thegreenplace.net/2023/better-http-server-routing-in-go-122/
- Proposal
- Документация
Пример кода:
package main
import (
"fmt"
"net/http"
)
func main() {
mux := http.NewServeMux()
mux.HandleFunc("GET /path/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "got path\n")
})
mux.HandleFunc("/task/{id}/", func(w http.ResponseWriter, r *http.Request) {
id := r.PathValue("id")
fmt.Fprintf(w, "handling task with id=%v\n", id)
})
http.ListenAndServe("localhost:8090", mux)
}
1. В первом хэнделере мы видим явное указание HTTP-метода (GET)
2. Во втором - компонент
{id} и r.PathValue("id") для получения значенияЗа ссылку спасибо @batazor
#go_updates #http #mux
👍18❤2🔥2
routegroup - легковесная обёртка для группировки и интеграции middleware в
https://github.com/go-pkgz/routegroup
Автор библиотеки: Umputun, один из ведущих подкаста Радио-Т
Описание его словами:
Оригинальный пост: https://t.me/daily_geek_news/218
#library #http #mux
http.ServeMuxhttps://github.com/go-pkgz/routegroup
Автор библиотеки: Umputun, один из ведущих подкаста Радио-Т
Описание его словами:
Смысл этой микро-библиотеки лично для меня в том, чтоб убрать ненужную теперь зависимость на Chi в моих проектах, но не пострадать при этом. Chi мне служил верой и правдой много лет, хотя наши с ним (а точнее с его автором) отношения не всегда были ровными. Однако, после того как в 1.22 завезли улучшения раутинга, почти все, чего мне не хватало в стандартном муксе там появилось. Единственно то, чего не хватило это библиотека добавила, а именно группы раутов с ассоциированными мидлеваре.
Я ее писал с двумя целями в голове - добавить только это и ничего более, и быть полностью совместимым со стандартной библиотекой.
Оригинальный пост: https://t.me/daily_geek_news/218
#library #http #mux
GitHub
GitHub - go-pkgz/routegroup: Lightweight library for route grouping and middleware integration with the standard http.ServeMux
Lightweight library for route grouping and middleware integration with the standard http.ServeMux - go-pkgz/routegroup
🔥23👍5