GOLANG_DIGEST Telegram 79
Таймауты HTTP Server в Go - как работают и зачем нужны

В стандартной библиотеке 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 помогает освободить ресурсы от долгоживущих соединений, которые больше не используются.

————
☁️ Если я где-то ошибся или был неточен, пожалуйста, напишите об этом в комментах, я всё поправлю

💻 Идея написания этого поста возникла во время записи ролика по REST API, в котором у меня не хватило времени на полноценное объяснение

#гайды #golang #http
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥28👍16



tgoop.com/golang_digest/79
Create:
Last Update:

Таймауты HTTP Server в Go - как работают и зачем нужны

В стандартной библиотеке 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 помогает освободить ресурсы от долгоживущих соединений, которые больше не используются.

————
☁️ Если я где-то ошибся или был неточен, пожалуйста, напишите об этом в комментах, я всё поправлю

💻 Идея написания этого поста возникла во время записи ролика по REST API, в котором у меня не хватило времени на полноценное объяснение

#гайды #golang #http

BY Golang Дайджест


Share with your friend now:
tgoop.com/golang_digest/79

View MORE
Open in Telegram


Telegram News

Date: |

More>> SUCK Channel Telegram "Doxxing content is forbidden on Telegram and our moderators routinely remove such content from around the world," said a spokesman for the messaging app, Remi Vaughn. The court said the defendant had also incited people to commit public nuisance, with messages calling on them to take part in rallies and demonstrations including at Hong Kong International Airport, to block roads and to paralyse the public transportation system. Various forms of protest promoted on the messaging platform included general strikes, lunchtime protests and silent sit-ins. Joined by Telegram's representative in Brazil, Alan Campos, Perekopsky noted the platform was unable to cater to some of the TSE requests due to the company's operational setup. But Perekopsky added that these requests could be studied for future implementation.
from us


Telegram Golang Дайджест
FROM American