Авторизация не SSL, если вы имеете ввиду авторизацию по ключу. SSL
просто закрывает http.
Авторизация - получение session id (колбаса из ХХХ сиволов) и брожение с
ней в качестве куки или параметра в сервлете.
Именно push. Его и городим. С таймаутами проблем нет. Если слать нечего,
нужно слать ping. Иначе клиент не будет знать о том соединение живо или
нет, и его какой нить роутер по дороге не пристрелил. И сделать такое
вполне возможно :)
Как сделаю скажу точно можно или нет.
Pipelining хотелось (и выйдет) пользовать для того чтоб соединение было
двунаправленным.
David Mzareulyan wrote:
Hello Kostya,
Под "просто сокетом" панимается установка двунаправленного tcp
соединения. От китайцев спасает ssl, ну по крайей мере я в это верю :)
Ага, так значит фаза авторизации у Вас всё-таки есть, причём недешёвая
(ssl). Тогда о чём весь этот джаз?
Про кроликов - я согласен, но альтернативы не вижу на "пока что".
Ngnix сейчас выступает как ssl+keep alive фронтенд для клиентов, в
ближайшем будущем
сервлеты отдающие изменеия клиенту перестанут закрывать аут и начнут
выталкивать
изменения.
David Mzareulyan wrote:
Hello Kostya,
А вот тут Вы не правы (скажу очень мягко). Это сильно зависит от
бекенда. У меня есть сессия, и мне выгодно иметь персистент
конекшен. Т.к. бекенд никогда не закончит отдавать, он будет писать
в аут до тех пор пока клиент не скажет логаут.
Эта задача, вообще говоря, не требует обязательного персистента с
бэкендом. Но она да, требует некоторой доработки nginx-а. Это
обсуждалось в рассылке, но, к сожалению, Игорь особого интереса к
задаче не проявил.
А можно чуть подробнее? Пока не тестированно. Находится в глубокой
бете. Если бекенд "никогда" не закончит писать, то это не сработает в
случае фронтенда ngnix? Я только несколько дней как читаю эту конфу.
Сработает, скорее всего. Если nginx не отрубит бэкенд по таймауту,
конечно, ну так это настраивается.
А то, о чём я говорю -- это всевозможные сomet- и push-технологии, в
которых гораздо удобнее было бы разделить слой, поддерживающий
соединение с клиентом (nginx, очевидно) и слой, подающий в это
соединение данные (бэкенд). Но сейчас такую конструкцию сделать всё
равно невозможно.
Это дорго каждый раз устанавливать
соединение и т.п. С другой стороны от http тоже никак не уйдеш, есть
клиенты которые сидят за прокси, если прокси забыть то всех бы
спасли
tcp соединения... Но клиенты иногда еще посылают команды серверу. И
очень бы хотелось использовать тот же сокет, тогда на стороне
бекенда
я могу избежать авторизации.
А это уже от корявости архитектуры. Не приспособлен HTTP для
подобного, как не приспособлены кролики для лазанья по деревьям. И
потом, что значит "тот же сокет"? Вы же сами только что о прокси
говорили, за которым хоть миллиард китайцев сидеть может. И будут они
все слать всё в "тот же сокет" без авторизации...
Проблемы тормозов на бекенде и решаем. Просто не хочется выставлять
прямо в инет сам бекенд. Просто страшно.
p.s.
Я думаю господин Сысоев будет несколько обескуражен
основной задачей "как можно быстрее освободить процесс backend для
следующих запросов" :)
Andrew Sitnikov wrote:
Hello Kostya,
KA> Плохо. Даже отвратительно. Ну ладно.
задача nginx как можно быстрее освободить процесс backend для
следующих запросов, keepalive совсем
этому не способствует. имхо вам надо не костыли а стороне frondend
изобретать а решать проблему с вашим
тормозным backend.
