Прежде всего: Servlets API - есть по сути жабный программный интерфейс для работы с HTTP. Вот от этого давайте и плясать.

В чем состоит назначение механизма сессий? По большому счету - в том, чтобы позволить серверу "узнавать" граждан, которые уже приходили раньше. Если мы сможем их узнавать, мы уж как-нибудь разберемся, что с этой инфой делать.

Теперь: что значит узнавать. В HTTP не так много средств, которые позволяют это делать. Спецификация Servlets определяет три механизма отслеживания сессий:

- кукисы:

- URL rewriting:

- SSL сессии.

Самое надежное средство - это SSL сессии, которые используют встроенный в HTTPS механизм идентификации клиента. Но, к сожалению, в большинстве случаев нам нужны решения для простого открытого трафика, поэтому на SSL сессиях можно сразу поставить крест.

Следующий по надежности/удобству метод - это кукисы. Кукисы хороши почти всем, если не считать одной досадной неприятности: некоторые клиенты могут не поддерживать куки, а там, где они поддерживаются, они могут быть выключены юзером.

Теперь очень важный момент: что такое куки и как они работают. Кука - это, грубо говоря, именованная строка текста, которая сассоциирована с адресом URL или его частью. Хотя кукисы не являются частью текущего стандврта HTTP/1.1, они описаны в RFC 2109 (http://www.w3.org/Protocols/rfc2109/rfc2109) от 1997 г. и поддерживаются всеми современными и не очень браузерами.

Так вот, как куки появляются и что с ними происходит дальше. Инициатива по созданию куки принадлежит серверу: когда он возвращает клиенту ответ HTTP (например, содержимое веб-страницы в HTML), он может при этом предварить собственно содержимое одним или несколькими заголовками HTTP. Согласно RFC 2109, одним из таких заголовков может быть Set-Cookie



Согласно все тому же RFC 2109, браузер (если он поддерживает куки и они не выключены юзером) должен в том или ином виде эту принятую куку сохранить. А вот теперь самое интересное. Что происходит, кода юзер тыкает в ссылку? Правильно, браузер отправляет на сервер соответствующим образом оформленный HTTP запрос. Если при этом на URL ресурса распространяется действие ранее сохраненной куки, то браузер автоматически, не дожидаясь особого приглашения, добавляет к запросу заголовок Cookie:



Таким образом, при первом посещении сайта куки на клиенте еще нет - она появится вместе с ответом сервера. Зато при всех последующих посещениях мы уже по содержанию запроса можем узнать, был ли товарищ у нас раньше. Но - внимание! - мы не можем гарантировать, что он точно НЕ БЫЛ. Как мы используем это знание применительно к сессиям? А вот как.

Когда юзер приходит первый раз, и мы решаем открыть сессию, веб контейнер генерит уникальный идентификатор. Потом он создает объект типа сессия и присваивает ему этот идентификатор. Объект типа сессия - это по сути просто расширенный мап с рядом дополнительных свойств для нашего удобства. Что мы туда положим - это уже чисто дело нашей фантазии: можно положить историю хождения в рамках сессии, можно хранить товары для покупки (шоппинг карт) и прочую лабудень.

Теперь нас интересует вопрос, с которого началось обсуждение: что будет, если клиент выключил или не поддерживает куки? А будет то, чего опасался UnicornMirage: поскольку кука с запросом не поступает, сервер не может сказать наверняка, пришел ли товарищ в первый раз или у него просто не работают куки. А сессию, тем не менее, создавать надо, раз в коде сервлета это прописано. Ну вот он и будет их создавать - по сути в мусорную корзину, поскольку воспользоваться этими сессиями никто никогда не придет.

Хорошо, если юзер человеческий: ну сколько он там сможет натыкать? Десяток-другой бесполезных сессий. А что если пришел поисковый робот? Апорт, например, может запросто за несколько минут сделать сотни заходов. И если хороших, добропорядочных роботов можно определить по содержимому заголовка User-Agent, то бывают ведь и недобропорядочные (собиратели емейлов, например). которым никакой robots.txt не писан и которые любят маскироваться под человеческие браузеры. А еще бывают выкачивалки, которые в мгновение ока могут наплодить такую кучу сессий, что любой сервер загнется.

Напрашивается вопрос: а что же делать? А делать надо вот что: создать прослойку в веб приложении (например, в виде фильтра, хотя и необязательно), которая будет заниматься предварительной обработкой запросов и выявлять клиентов, для которых создавать сессию нежелательно. Логика обработки может включать:

- определение известных поисковиков;

- хранение истории все хапросов за определенный период времени (скажем, 30 минут), и выявление деятелей, которые заходят слишком часто (идентифицировать, например, по совпадению IP и содержимого User-Agent);

- ведение черного списка IP, и запросы с этих адресов слать лесом немедленно и без церемоний.

Тут на самом деле можно много чего придумать, при этом следует понимать, что совершенного метода отфильтровки не существует: всегда будут просачиваться плохие клиенты, и всегда найдутся нормальные, которые будут незаслуженно попадать под раздачу. Поэтому задача вебмастера - всегда быть начеку, регулярно анализировать логи, думать о более совершенных алгоритмах - одним словом, ловить мышей.

Трудно? Да, трудно. Но никто ведь и не обещал, что будет легко.

Хорошая новость - в том, что всего этого не следует опасаться на ранних стадиях жизни сайта. Пока ты никому особо не известен и не перешел ничьей дороги, ты будешь как тот неуловимый Джо - нафиг никому не нужен ломать тебя 

На этом можно было бы и поставить точку, но у нас остался нерассмотренным еще один механизм отслеживания сессий: URL rewriting. Если говорить совсем коротко, то вот: НИКОГДА, НИКОГДА не используйте этот механизм. Почему - могу объяснить. Но - отдельно, а то и так пост здоровый получился.