Эм, а как клиент должен принять ответ в каком-то “левом”

соединении? он то сделал коннект и в нем запрос, и ответ ожидает именно в нем

а ведь и правда, у клиента же не будет установленного соединения с целевым nginx, интересно, а как работают балансеры в том же aws, получается трафик в любом случае должен пройти через балансер

Все будет.

я вспомнил почему мне казалось что так будет работать, протокол dns, если используется udp, клиент принимает ответы с любого адреса, во всяком случае в linux так работало

1. Современный http уже работает поверх udp. 2. Забалансировать таким образом tcp - не составляет проблем, у меня так fix-клиенты отлично жили :)

1. если ничего не путаю это про протокол quick и подобные, которые от поддержки браузеров зависят 2. тут не понял, имеется ввиду есть вариант использовать общую таблицу установленных tcp подключений ?

1. chrome умеет http2 поверх udp. 2. Можно и общую таблицу, но это дорого. Чтобы отдавать напрямую с бэкендов - вам надо терминировать сессию на бэкенде, а значит - L3 балансировка. Смешивать ее с L7 конечно не выйдет (на самом деле тоже можно, но вам точно не надо), но они могут работать условно параллельно. Часть трафика можно приземлять в хапрокси, часть - разливать по бэкам.

1. да, но это пока не так широко распространено 2. кажется понял идею, т.е. грубо, назначем нескольким nginx одинаковый ip адрес и с него отвечаем, т.к. на обоих будет один ip адрес они смогут обработать запрос, а на балансере раскидываем трафик между этими nginx хостами.

2. Почти. Один адрес - на лупбэке, не роутящийся. Он же на балансере, на внешнем интерфейсе. Раскидывает по любым адресам бэков, до которых может докинуть пакет.

это как я понял решение с использованием ipvs (lvs) https://itgeans.blogspot.com/2013/04/lvs.html идея интересная буду смотреть подробнее, но она подразумевает что у нас на всех бекендах обслуживаются одинаковые хосты, да и трафик в ответ клиенту пойдет через director (balancer) я правильно понимаю ?

VRRP/keepalived

Да, все так.

благодарю