1. если ничего не путаю это про протокол quick и подобные, которые от поддержки браузеров зависят 2. тут не понял, имеется ввиду есть вариант использовать общую таблицу установленных tcp подключений ?
1. chrome умеет http2 поверх udp. 2. Можно и общую таблицу, но это дорого. Чтобы отдавать напрямую с бэкендов - вам надо терминировать сессию на бэкенде, а значит - L3 балансировка. Смешивать ее с L7 конечно не выйдет (на самом деле тоже можно, но вам точно не надо), но они могут работать условно параллельно. Часть трафика можно приземлять в хапрокси, часть - разливать по бэкам.
1. да, но это пока не так широко распространено 2. кажется понял идею, т.е. грубо, назначем нескольким nginx одинаковый ip адрес и с него отвечаем, т.к. на обоих будет один ip адрес они смогут обработать запрос, а на балансере раскидываем трафик между этими nginx хостами.
неоходимо проверить конфигурации, в этом поможет принцип разделения и запуск nginx с ключами -t - тестирование конфигурации -T - тестирование с выводом конфигурации искать надо как указано в ошибке строку с include, как вариант сделай
2. Почти. Один адрес - на лупбэке, не роутящийся. Он же на балансере, на внешнем интерфейсе. Раскидывает по любым адресам бэков, до которых может докинуть пакет.
это как я понял решение с использованием ipvs (lvs) https://itgeans.blogspot.com/2013/04/lvs.html идея интересная буду смотреть подробнее, но она подразумевает что у нас на всех бекендах обслуживаются одинаковые хосты, да и трафик в ответ клиенту пойдет через director (balancer) я правильно понимаю ?
Nope. You can use something like this: set $foo 0; if (<cond1>) { set $foo 1; } if (<cond2>){ set $foo "${foo}1; } if ($foo = 11) { return 444; } But the better way is to use map instead