Куки и сеанс предназначены для поддержания статуса доступа к пользователям. С одной стороны, он состоит в том, чтобы облегчить реализацию бизнеса, а с другой стороны, это упростить программирование сервера и улучшить производительность доступа. Куки - это технология клиента (то есть браузер). После настройки файлов cookie каждый раз, когда вы посещаете сервер, файлы cookie будут внесены в запрос; Сеанс - это технология сервера, которая хранит информацию о доступе пользователя на сервере.
Используйте файлы cookie для доставки информации. По мере увеличения количества файлов cookie и увеличения количества посещений, пропускная способность, которую он потребляет, станет больше и больше; При использовании сеанса для сохранения информации самая большая слабость заключается в том, что между несколькими серверами нелегко поделиться.
1 печенье
В терминах Layman, когда пользователь обращается к серверу с помощью HTTP, сервер возвращает некоторую информацию о паре ключевых значений в браузер клиента и добавит некоторые ограничения в эти данные. Когда пользователь встречает ограничения, в следующий раз, когда пользователь обратится к серверу, он ранее принесет информацию о паре ключей cookie. Когда пользователь входит в URL, браузер ищет файлы cookie, связанные с URL -адресом на локальном жестком диске. Если куки существует, браузер отправляет файл cookie на ваш сайт вместе с запросом страницы.
Файлы cookie связаны с веб -сайтами, а не с конкретными страницами. Поэтому, независимо от того, какая страница на сайте браузер и сервер будут обмениваться информацией о файле cookie. Когда пользователь посещает разные сайты, каждый сайт может отправлять файл cookie в браузер пользователя; Браузер хранит все печенье отдельно.
Элемент атрибута cookie
В настоящее время существует 2 версии файлов cookie, версии 0 и версии 1. У них есть 2 типа идентификаторов заголовка ответов, а именно «Set-Cookie» и «Set-Cookie2».
Cookie 0 значение атрибута
Cookie 1 значение атрибута
Пример использования файлов cookie на Java
@OverridePublic void Doget (httpservletRequest, httpservletresponse response) throws ioException {response.setContentType ("text/html; charset = utf-8"); printWriter out = response.getWriter (); cookie [] cookies = recement.getCookies (); == null) {response.addcookie (new cookie ("name", "luoxn28"));} else {System.out.println (имя);} out.println ("hello world");} public Static String getCoodie (cookie [] cookies, string key) {if (if (cookies) {for (cookie [] cookies) (cookie.getName (). Equals (key)) {return cookie.getValue ();}}} return null;}Некоторые меры предосторожности для использования файлов cookie (в качестве примера использования Java)
• Имя и ценность созданных файлов cookie не могут быть неасвязанными символами. Если он китайский, его можно кодировать через rrlencoder, в противном случае будет брошено исключение java.lang.illegalargumentException.
• Когда появляются несколько имен и значения значений, они на самом деле находятся в одном и том же заголовке "cookie".
• Стоимость файлов cookie может сохранить знаки препинания, отличные от «;». Но китайские иероглифы не могут быть сохранены. Мусор появится при сохранении китайских иероглиф.
Некоторые ограничения на файлы cookie
Cookie - это поле в заголовке HTTP. Сам HTTP не имеет ограничений на эту область, но файлы cookie в конечном итоге хранятся в браузере. Различные браузеры имеют некоторые ограничения на хранение файлов cookie, как показано в следующей таблице:
Если вы попытаетесь хранить больше печенья, самые старые печенья будут отброшены.
2 сеанса
Сеанс решает проблему, что, когда количество файлов cookie увеличивается, объем передачи данных между клиентом и сервером увеличивается. Когда один и тот же клиент взаимодействует с сервером, ему не нужно каждый раз передавать все значения cookie, но только значение идентификатора передается. Этот идентификатор генерируется, когда клиент впервые обращается к серверу, и каждый клиент уникален. Этот идентификатор обычно является печеньем, чье зовут jsessionid.
Как сеанс работает на основе файлов cookie? Это может быть основано на параметре пути URL; Это также может быть основано на файлах cookie. Если логотип файлов cookie в контекстном контейнере не изменяется, он также поддерживается по умолчанию. Когда браузер не поддерживает функцию cookie, браузер переписывает пользовательский сеанс, в параметр URL -адреса, запрашиваемый пользователем. Его метод доставки такой как /path /servlet; name = xxx; name2 = xxx2? Name3 = xxx3. SessionCookiEname Если элемент конфигурации сеанса-конфигурации настроен в web.xml, атрибут имени под Cookie-Config является значением этого SessionCookiEname. Если элемент конфигурации сеанса-конфигурации не настроен, по умолчанию SessionCookiEnameJiushi "jsessionId". Обратите внимание, что файлы cookie, связанные с сеансом, ничем не отличаются от других файлов cookie. Если клиент также поддерживает файлы cookie, Tomcat все равно будет анализировать идентификатор сеанса в cookie и перезаписать идентификатор сеанса в URL.
Как работает сеанс
С идентификатором сеанса сервер может создать объект HTTPSession. В первый раз, когда вы называете метод request.getSession (). Если нет соответствующего объекта HTTPSession, будет создан новый объект и добавлен в контейнер сеансов org.apache.catalina.manager будет сохранен. Управление спасением всех жизненных циклов сеанса, сеанс истекает и переработан, сервер закрыт, а сеанс сериализован на диск. Обратите внимание, что клиент соответствует объекту сеанса, который сохраняет значение сеанса, которое мы создали.
Стандарт, вызванный методом request.getSession (), всегда будет существовать, даже если сессия, связанная с этим клиентом, истек. Если он истекает, будет создан новый, но ранее установленное значение сеанса будет потеряно.
3 Сравнение файлов cookie и безопасности сеанса
Файлы cookie передают сохраненные данные от клиента на сервер через заголовок HTTP, а затем от сервера к клиенту. Все данные сохраняются в клиентском браузере. Эти данные можно получить, и файлы cookie могут быть даже добавлены и изменены через плагины. Безопасность всех файлов cookie относительно плохая. Для сравнения, сеанс сохраняет данные на стороне сервера, что гораздо более безопасно. Это требует только файла cookie для передачи идентификатора cookie обратно, поэтому сеанс более подходит для сохранения конфиденциальности пользователей и важных данных.
Распределенная сессионная структура
В крупных интернет -приложениях использование только файлов cookie и сеансов невозможно, потому что использование файлов cookie может хорошо решить распределенную проблему развертывания приложений. Крупная система интернет -приложений имеет сотни машин, и многие различные системы приложений работают вместе. Поскольку файлы cookie хранят данные в браузере пользователя, каждый раз, когда пользователь посещает, данные будут возвращены на сервер, что решает проблему несоответствия файлов cookie, вызванных запросами одного и того же пользователя, обрабатываемых на разных серверах.
Поскольку приложение является кластером, сеанс не может быть сохранен в памяти каждого сервера. Если у каждого сервера есть сотни тысяч пользователей доступа, память сервера не может быть размещена. Даже если это может быть размещено, это не может гарантировать, что сеанс будет синхронизирован с другими серверами. Следовательно, разделение этих сессий требует сохранения их в специальном распределенном кеше, который можно прочитать и записано в любое время. Производительность должна быть достаточно хорошей, чтобы удовлетворить требования, такие как Memcache/Redis или Distributed Framework с открытым исходным кодом Taobao.
Повторяющийся вопрос подачи формы
На сайте есть много мест, которые повторяют представления. Чтобы предотвратить повторные представления форм, необходимо идентифицировать каждый запрос на доступ пользователя, чтобы каждый запрос доступа был уникальным для сервера. Чтобы идентифицировать каждый запрос пользователя, элемент скрытой формы может быть добавлен в поле формы, запрашиваемое пользователем, а его значение - уникальный токен, такой как:
<form id = "form" method = "post"> ... <input type = hidden name = "token" value = "xxx"/> </form>
Уникальный токен генерируется, когда пользователь запрашивает форму и устанавливает ее на сеанс пользователя. Когда пользователь представляет, он проверяет, соответствует ли токен с токеном, сохраненным в сеансе. Если это последовательно, это означает, что нет повторного подчинения. В то же время токен в сеансе обновляется до нового значения токена; В противном случае токен, представленный пользователем, больше не является законным знаком текущего запроса, а представление не удается.
Вышеупомянутые вещи о печенье и сеансах на Java, которые редактор представил вам. Я надеюсь, что это будет полезно для вас. Если у вас есть какие -либо вопросы, пожалуйста, оставьте мне сообщение, и редактор ответит вам вовремя. Большое спасибо за вашу поддержку сайту wulin.com!