предисловие
С развитием и эволюцией мобильной сети, в дополнение к собственным приложениям, теперь мы можем запускать «веб-приложения» на наших мобильных телефонах — их можно использовать сразу и сразу же, как только они будут израсходованы. Отличное веб-приложение может даже иметь функции и возможности, сравнимые с родными приложениями. Частично причина отличной производительности WebApp связана с улучшением технологии хранения в браузере. Функция хранения данных в файлах cookie была сложной для удовлетворения потребностей разработки и постепенно заменяется WebStorage и IndexedDB В этой статье будут представлены различия, преимущества и недостатки этих методов хранения.
Чтобы прочитать больше качественных статей, нажмитеБлог GitHub
1. Файлы cookie
1. Происхождение файлов cookie
Работа куки заключается не в локальном хранении, а в «поддержании состояния».. потому чтоПротокол HTTP не имеет состояния, и сам протокол HTTP не сохраняет состояние связи между запросом и ответом.говоря простым языком, сервер не знает, что пользователь делал в прошлый раз, что серьезно мешает реализации интерактивных веб-приложений. В типичном сценарии онлайн-покупок пользователь просматривает несколько страниц и покупает коробку печенья и две бутылки напитков. В конце оформления заказа из-за безгражданства HTTP сервер не знает, что пользователь купил без дополнительных средств, поэтому родился Cookie. Это одно из «дополнительных средств», используемых для обхода безгражданства HTTP. Сервер может устанавливать или читать информацию, содержащуюся в файлах cookie, тем самым поддерживая состояние сеанса пользователя с сервером.
Мы можем понимать файл cookie как небольшой текстовый файл, хранящийся в браузере, прикрепленный к HTTP-запросу и «летающий» между браузером и сервером. Он может нести информацию о пользователе, и когда сервер проверяет куки, он может получить статус клиента.
Только что в сценарии покупок, когда пользователь покупает первый товар, сервер отправляет файл cookie для записи информации об этом товаре при отправке веб-страницы пользователю. Когда пользователь посещает другую страницу, браузер отправляет файл cookie на сервер, чтобы сервер знал, что он покупал ранее. Пользователь продолжает покупать напитки, а сервер добавляет новую информацию о продукте в исходный файл cookie. При оформлении заказа сервер просто считывает отправленный файл cookie.
2. Что такое cookie и сценарии его применения
Файлы cookie относятся к данным (обычно зашифрованным), которые некоторые веб-сайты сохраняют на локальном терминале пользователя для идентификации личности пользователя. Файлы cookie генерируются сервером и поддерживаются и сохраняются клиентом.. Через файл cookie сервер может узнать, от какого клиента поступил запрос, и может поддерживать состояние клиента.Например, после входа в систему и обновления заголовок запроса будет содержать set-cookie в заголовке ответа при входе в систему, а веб-сервер также получит запрос.Значение файла cookie может быть считано, а информационный статус некоторых пользователей может быть оценен и восстановлен в соответствии с содержанием значения файла cookie.
Как показано на фиг.Файлы cookie существуют в виде пар ключ-значение..
Типичные сценарии применения:
-
Запомните пароль и в следующий раз авторизуйтесь автоматически.
-
Функция корзины.
-
Записывайте данные просмотра пользователей и рекомендуйте продукты (рекламу).
3. Принцип и метод создания файлов cookie
Принцип файлов cookie
Когда вы посещаете веб-сайт в первый раз, браузер отправляет запрос. После того, как сервер ответит на запрос, он добавит параметр Set-Cookie в заголовок ответа и поместит файл cookie в ответный запрос. запрос во второй раз, информация о файлах cookie будет отправлена на сервер через заголовок запроса файлов cookie, и сервер идентифицирует личность пользователя. Кроме того, время истечения срока действия, домен, путь, период действия и применимый сайт cookie можно указать по мере необходимости.
Существует два основных способа создания файлов cookie:
- Способ генерации 1: set-cookie в заголовке ответа http
Мы можем указать значение cookie для сохранения через Set-Cookie в заголовке ответа. По умолчанию для домена установлено имя хоста страницы, которая устанавливает cookie, мы также можем установить значение домена вручную.
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2018 07:28:00 GMT;//可以指定一个特定的过期时间（Expires）或有效期（Max-Age）
Когда установлено время истечения срока действия файла cookie, установленные дата и время относятся только к клиенту, а не к серверу.
- Генерация двумя способами: js cookie может быть прочитан с помощью document.cookie, показывая форму пар ключ-значение
Например, мы можем ввести следующие три строки кода в консоли сообщества Nuggets, чтобы просмотреть сгенерированные файлы cookie на панели приложений Chrome:
document.cookie="userName=hello"
document.cookie="gender=male"
document.cookie='age=20;domain=.baidu.com'
Из приведенного выше рисунка мы можем получить:
Идентификатор домена указывает, какие домены могут принимать файлы cookie.. Если домен не задан, он автоматически привязывается к текущему домену исполняемого оператора. Если установлено значение «.baidu.com», все доменные имена, заканчивающиеся на «baidu.com», могут получить доступ к файлу cookie, поэтому третий код для хранения значения файла cookie не может быть прочитан в сообществе Nuggets.
4. Дефекты файлов cookie
- Печенье недостаточно большое
Размер файла cookie ограничен 4 КБ, что недостаточно для сложных потребностей хранения. Когда размер файла cookie превышает 4 КБ, его ждет обработанная участь. Таким образом, файлы cookie могут использоваться только для доступа к небольшому объему информации. Кроме того, многие браузеры также ограничены файлами cookie сайта.
Обратите внимание: файл cookie каждого браузераname=valueЗначение составляет около 4 КБ, поэтому 4 КБ разделяют не все файлы cookie под доменным именем, а размер имени.
- Слишком большое количество файлов cookie может привести к огромным потерям производительности.
Файлы cookie следуют сразу за доменным именем. Все запросы под одним и тем же доменным именем будут содержать файлы cookie. Только представьте, если мы просто запрашиваем картинку или файл CSS в данный момент, нам тоже приходится бегать с кукой (ключ в том, что информация, хранящаяся в куке, не нужна), это пустая трата денег. Несмотря на небольшой размер файлов cookie, запросов может быть много, а при наложении запросов накладные расходы, вызванные такими ненужными файлами cookie, будут невообразимыми.
Файлы cookie используются для хранения информации о пользователе, и все запросы под доменным именем (доменом) будут нести файлы cookie, но для статических файловых запросов нести информацию о файлах cookie вообще бесполезно.Доменное имя сайта разрешается отдельно.
- Поскольку файлы cookie в HTTP-запросах передаются в виде открытого текста, безопасность является проблемой, если только не используется HTTPS.
5. Файлы cookie и безопасность
Что касается файлов cookie, нам также необходимо обратить внимание на безопасность.
HttpOnly не поддерживает чтение и запись, а браузеры не позволяют сценариям манипулировать document.cookie для изменения файлов cookie. Таким образом, чтобы избежать атак с использованием междоменных сценариев (XSS), к файлам cookie, помеченным HttpOnly, нельзя получить доступ через JavaScript Document.cookie API, их следует отправлять только на сервер. Если файл cookie, содержащий информацию о сеансе на стороне сервера, не предназначен для вызова клиентским JavaScript, он должен быть помечен HttpOnly.
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Файлы cookie, помеченные как безопасные, должны отправляться на сервер только через запросы, зашифрованные протоколом HTTPS. Но даже если установлен флаг «Безопасность», конфиденциальная информация не должна передаваться через файлы cookie, поскольку файлы cookie по своей сути небезопасны, а флаг «Безопасность» не может обеспечить реальную безопасность.
Чтобы компенсировать ограничения файлов cookie и позволить «профессионалам заниматься профессиональными делами», появилось Web Storage.
В HTML5 добавлено новое решение для локального хранения, Web Storage, которое разделено на две категории: sessionStorage и localStorage.. Таким образом, с WebStorage файл cookie может делать только то, для чего он предназначен, — выступать в качестве канала для взаимодействия клиента с сервером и поддерживать состояние клиента.
2. Локальное хранилище
1. Возможности LocalStorage
- Сохраненные данные существуют в течение длительного времени, и при следующем доступе к веб-сайту веб-страница может напрямую прочитать ранее сохраненные данные.
- Размер около 5 м
- Используется только на стороне клиента, не взаимодействует со стороной сервера.
- Улучшенная упаковка интерфейса
Основываясь на вышеперечисленных характеристиках, LocalStorage можно использовать в качестве решения локального кэширования браузера для повышения скорости рендеринга первого экрана веб-страницы (при возврате по первому запросу некоторая инвариантная информация сохраняется непосредственно локально).
2. Хранить / чтение данных
Данные, хранящиеся в localStorage, существуют в виде «пар ключ-значение». То есть каждый элемент данных имеет имя ключа и соответствующее значение. Все данные сохраняются в текстовом формате.
Сохраняйте данные с помощью метода setItem. Он принимает два параметра, первый — это имя ключа, а второй — сохраненные данные.localStorage.setItem("key","value");Для чтения данных используйте метод getItem. Он имеет только один параметр — имя ключа.var valueLocal = localStorage.getItem("key");
Конкретные шаги см. в следующем примере:
<script>
if(window.localStorage){
localStorage.setItem（'name','world'）
localStorage.setItem（'gender','female'）
}
</script>
<body>
<div id="name"></div>
<div id="gender"></div>
<script>
var name=localStorage.getItem('name')
var gender=localStorage.getItem('gender')
document.getElementById('name').innerHTML=name
document.getElementById('gender').innerHTML=gender
</script>
</body>
3. Сценарии использования
LocalStorage не имеет особых ограничений на хранение.Теоретически задачи хранения данных, которые файлы cookie не могут обработать и к которым можно получить доступ с помощью простых пар ключ-значение, могут быть переданы LocalStorage.
Вот вам пример: учитывая, что одной из характеристик LocalStorage является постоянство, иногда мы предпочитаем использовать его для хранения некоторых ресурсов со стабильным содержимым. Например, веб-сайты электронной коммерции с богатым графическим содержимым будут использовать его для хранения строк изображений в формате Base64:
Три, хранилище сессий
Данные, сохраненные sessionStorage, используются для сеанса браузера.Когда сеанс заканчивается (обычно окно закрывается), данные очищаются; особенность sessionStorage в том, что,Даже две страницы под одним и тем же доменным именем не могут совместно использовать содержимое sessionStorage, если они не открыты в одном и том же окне браузера.; localStorage совместно используется всеми окнами одного и того же происхождения; файлы cookie также используются всеми окнами одного происхождения. За исключением продолжительности периода хранения, свойства и методы SessionStorage точно такие же, как у LocalStorage.
1. Возможности хранилища сессий
- Хранилище браузера на уровне сеанса
- Размер около 5 м
- Используется только на стороне клиента, не взаимодействует со стороной сервера.
- Улучшенная упаковка интерфейса
Основываясь на вышеуказанных характеристиках, sessionStorage может эффективно поддерживать информацию формы, например, при обновлении информация формы не теряется.
2. Сценарии использования
sessionStorage больше подходит для хранения информации о времени жизни и уровне сеанса, которую он синхронизирует. Эта информация относится только к текущему сеансу, при запуске нового сеанса ее также необходимо соответствующим образом обновить или освободить. Например, sessionStorage Weibo в основном хранит данные о просмотре вашего сеанса:
lasturl соответствует URL-адресу, который вы посещали в последний раз, и этот адрес является мгновенным. Когда вы переключаете URL-адреса, он обновляется, а когда вы закрываете страницу, действительно нет смысла его оставлять, просто отпустите. Такие данные лучше всего обрабатывать с помощью sessionStorage.
3. Разница между sessionStorage, localStorage и куки
- Общая основа: все они сохраняются на стороне браузера, и все они следуют политике одного и того же источника.
- Разница: разница между жизненным циклом и областью применения
Область действия: localStorage может читать/изменять одни и те же данные localStorage по тому же протоколу, тому же имени хоста и тому же порту. sessionStorage немного строже, чем localStorage, кроме протокола, имени хоста, порта, требует еще такое же окно (то есть вкладку браузера)
Жизненный цикл: localStorage — это постоянное локальное хранилище, хранящиеся в нем данные никогда не устареют, и единственный способ заставить его исчезнуть — это удалить его вручную; в то время как sessionStorage — это временное локальное хранилище, это хранилище уровня сеанса, когда Когда сеанс заканчивается (страница закрывается), сохраненный контент также освобождается.
Веб-хранилище очень просто определить и использовать. Он хранится в виде пар ключ-значение, что немного похоже на объект, но это даже не объект —он может хранить только строки, чтобы получить объект, нам также нужно сначала разобрать строку.
В конце концов, веб-хранилище - это расширение файлов cookie, которое можно использовать только для хранения небольших количеств простых данных. Когда дело доходит до крупномасштабных, сложных данных, веб-хранилище беспомощно. В это время нам нужно знать наш Ultimate Big Boss - IndexedDB!
4. Индексированная БД
IndexedDB — это низкоуровневый API,Для хранения больших объемов структурированных данных (включая файлы и большие двоичные объекты) на стороне клиента.. API использует индексы для обеспечения высокопроизводительного поиска по этим данным. IndexedDB — это нереляционная база данных, которая работает в браузере. Так как это база данных, то это не уровень 5M, а 10M для мелких неприятностей. Теоретически IndexedDB не имеет ограничения на объем хранилища (как правило, не менее 250 МБ). Он может хранить не только строки, но и двоичные данные.
1. Возможности IndexedDB
- Хранение пар ключ-значение.
IndexedDB использует хранилище объектов для внутреннего хранения данных. Все типы данных могут храниться напрямую, включая объекты JavaScript. В хранилище объектов данные хранятся в виде "пар ключ-значение". Каждой записи данных соответствует первичный ключ. Первичный ключ уникален и не может повторяться, иначе будет выдана ошибка.
- асинхронный
IndexedDB не блокирует браузер при работе, и пользователи по-прежнему могут выполнять другие операции, в отличие от LocalStorage, который работает синхронно. Асинхронный дизайн предназначен для предотвращения чтения и записи больших объемов данных, что снижает производительность веб-страниц.
- Поддержка транзакций.
IndexedDB поддерживает транзакции, а это означает, что в серии шагов операции, если один из шагов завершается сбоем, вся транзакция отменяется, и база данных откатывается к состоянию до того, как транзакция произошла, и не бывает ситуации, когда только часть данные перезаписываются.
- ограничение гомологии
На IndexedDB распространяется такое же ограничение по происхождению, и каждая база данных соответствует доменному имени, которое ее создало. Веб-страницы могут обращаться к базам данных только под своими доменными именами, но не могут обращаться к базам данных между доменами.
- Большое место для хранения
Пространство для хранения IndexedDB намного больше, чем у LocalStorage, обычно не менее 250 МБ, и даже нет верхнего предела.
- Двоичное хранилище поддерживается.
IndexedDB может хранить не только строки, но и двоичные данные (объекты ArrayBuffer и объекты Blob).
2. Общие операции IndexedDB
Большинство операций в IndexedDB — это не режим вызова методов и возврата результатов, который мы обычно используем, а режим запрос-ответ.
- Построить Open IndexedDB ----
window.indexedDB.open("testDB")
Эта инструкция не возвращает дескриптор объекта БД, мы получаемIDBOpenDBRequestобъект, а объект БД, который мы хотим получить, находится в его атрибуте результата
Помимо результата, интерфейс IDBOpenDBRequest определяет несколько важных свойств:
onerror: дескриптор функции обратного вызова для сбоя запроса
onsuccess: дескриптор функции обратного вызова для успешного запроса
onupgradeneeded: Запрос дескриптора изменения версии базы данных
<script>
function openDB(name){
var request=window.indexedDB.open(name)//建立打开IndexedDB
request.onerror=function (e){
console.log('open indexdb error')
}
request.onsuccess=function (e){
myDB.db=e.target.result//这是一个 IDBDatabase对象，这就是IndexedDB对象
console.log(myDB.db)//此处就可以获取到db实例
}
}
var myDB={
name:'testDB',
version:'1',
db:null
}
openDB(myDB.name)
</script>
Консоль получает объект IDBDatabase, который является объектом IndexedDB.
- Закрыть IndexedDB----
indexdb.close()
function closeDB(db){
db.close();
}
- удалить IndexedDB----
window.indexedDB.deleteDatabase(indexdb)
function deleteDB(name) {
indexedDB.deleteDatabase(name)
}
3. Различия между WebStorage, файлами cookie и IndexedDB
Как видно из таблицы выше, файлы cookie больше не рекомендуются для хранения. Если вам не нужно много места для хранения данных, вы можете использовать localStorage и sessionStorage. Для данных, которые не сильно меняются, попробуйте использовать для хранения localStorage, в противном случае для хранения можно использовать sessionStorage.
Суммировать
Именно появление и развитие технологий хранения и кэширования в браузерах открыло неограниченные возможности для наших клиентских приложений. В последние годы появились сторонние библиотеки, основанные на технологиях хранения и кэширования, а также были созданы превосходные модели веб-приложений, такие как PWA. Кратко сформулируйте некоторые ключевые моменты этой статьи:
- Работа куки заключается не в локальном хранении, а в «поддержании состояния».
- Веб-хранилище — это механизм хранения данных, предоставляемый HTML5 специально для хранения в браузере, без связи с сервером.
- IndexedDB для хранения больших объемов структурированных данных на стороне клиента
Порекомендуйте полезный инструмент мониторинга ошибок для всехFundebug, добро пожаловать, чтобы попробовать это бесплатно!