![Как установить тайм-ауты запросов на каждом сетевом переходе](https://rvso.com/image/782617/%D0%9A%D0%B0%D0%BA%20%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%B8%D1%82%D1%8C%20%D1%82%D0%B0%D0%B9%D0%BC-%D0%B0%D1%83%D1%82%D1%8B%20%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%BE%D0%B2%20%D0%BD%D0%B0%20%D0%BA%D0%B0%D0%B6%D0%B4%D0%BE%D0%BC%20%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%BC%20%D0%BF%D0%B5%D1%80%D0%B5%D1%85%D0%BE%D0%B4%D0%B5.png)
Я пытаюсь разобраться с сетевыми тайм-аутами и тем, как их следует устанавливать для каждого перехода данного запроса. Для простоты я не рассматриваю разбивку тайм-аутов соединения, чтения и записи и предполагаю, что «тайм-аут» означает «максимально допустимое общее время от первого полученного пакета до последнего отправленного пакета (или наоборот для клиента). Допустим, в моем потоке запросов есть следующие переходы:
(client) --> (AWS ALB) --> (nginx) --> (server)
…и предположим, что мой сервер настроен на тайм-аут через 10 секунд.
Мой вопрос: какой набор тайм-аутов будет допустимым для каждого перехода?
// A
(client, 13s) --> (AWS ALB, 12s) --> (nginx, 11s) --> (server, 10s)
или
// B
(client, 7s) --> (AWS ALB, 8s) --> (nginx, 9s) --> (server, 10s)
или (С) что-то еще?
Разумеется, мне также интересна логика ваших предложений.
решение1
Если вы смотрите на жесткие тайм-ауты (вы не указываете цель), каждый этап обработки имеетменьшевремени, чем предыдущий. Так что в принципе, А — правильный подход.
Однако путь от клиента к AWSALB находится вне вашего контроля и может быть сравнительно длинным/медленным. Одна секунда на шаг кажется очень щедрой, так что тут нет проблем. Но если вы уменьшите это до 50 или, может быть, 100 мс на шаг, то первому шагу потребуется больше выделения.