Я изучаю файлы cookie, и мне интересно о поддержке браузера при написании веб-приложений, которые полагаются на файлы cookie для хранения состояния.
Для каждого домена/веб-сайта сколько файлов cookie может быть отправлено в браузер и какого размера?
Если несколько файлов cookie отправляются и сохраняются, это влияет на производительность?
Во-первых, я предлагаю вам не беспокоиться об этой проблеме. Существует AMPLE комната для сериализации тонны идентификаторов.
Во-вторых, он не сохраняется web-server, а web-domain - например, www.google.com, а не 100 различных физических серверов, обслуживающих домен Google.
В-третьих, если вам нужно беспокоиться о том, что есть два возможных заголовка файла cookie. Размеры этих заголовков файлов cookie определяются ограничениями программного обеспечения браузера.
Обсуждение дизайна
То, что вы не хотите использовать в заголовке файла cookie, отправляет сведения о сеансе клиента. Например, не пытайтесь заполнить электронное письмо, которое клиент печатает в файл cookie, если вы создаете почтовый интерфейс. Вместо этого вы отправите клиенту куки файл, который представляет его идентификатор + сеанс: вы храните все данные сеансов против этого удостоверения. Вы можете хранить десятки идентификаторов (4-16 байт) для каждого заголовка cookie, и никто не нуждается в более чем 4 из них. Данные cookie (как целое число), как правило, кодируются в base64, что увеличивает количество байтов.
Производительность
Ваш браузер отправляет множество заголовков на веб-сервер. Файл cookie - это всего лишь 100-1000 байт (в основном ближе к 100). В обоих случаях для отправки их на веб-сервер требуется всего лишь небольшая часть времени - при размещении в контексте курса. Вы должны иметь в виду, что Интернет построен на текстовых протоколах.
Не более 50 файлов cookie на домен, максимум 4 КБ на файл cookie (или даже всего 4 КБ, см. Ответ Iain). В IE 6 раньше было 20 файлов cookie на домен.
Обычно рекомендуется сохранять состояние на сервере и использовать куки только для отслеживания сеанса. Они отправляются вместе с каждым запросом, поэтому они создают ненужные издержки, если целью является сохранение состояния сеанса.
Если вы хотите сохранить состояние на клиенте, и вы можете использовать JavaScript, чтобы сделать это, есть варианты. Используйте напрямую API ассортимента хранилища или найдите библиотеку-оболочку, которая абстрагирует детали.
Варианты хранения на стороне клиента:
Устаревшие варианты хранения:
Итак, обычно для клиентского хранилища это зависит от варианта использования:
Пределы размера файлов cookie
Если вы хотите поддерживать большинство браузеров, не превышайте 50 файлов cookie на домен и 4093 байта на домен. То есть размер всех файлов cookie не должен превышать 4093 байта.
Мысли о производительности
Cookies отправляются по каждому запросу для домена, включая изображения. Для аргументов, скажем, у вас есть 30 ресурсов на вашем сайте и 4093 байта файлов cookie. Это означает, что пользователь загружает 122 Кбайт данных. Поэтому, если у меня есть 1 Мбит загрузка, это займет не менее 1 секунды.
Если вы хотите увидеть тестовую страницу cookie, которую я создал, или больше узнать об этом, просмотрите Ограничения Cookie для браузера.
Если вас беспокоит снижение производительности из-за больших файлов cookie, отправляемых при каждом запросе к серверу, хорошей идеей может быть размещение всех ваших статических файлов (изображений, CSS и т.д.) В поддомене вашего сайта, например http://static.yourdomain.com.
Таким образом, всякий раз, когда ваш сайт на www.yourdomain.com запрашивает статический файл, например изображение, браузер больше не отправляет cookie вместе с HTTP-запросом.
Источник: http://developer.yahoo.com/performance/rules.html#cookie_free
У разных челюстей разные размеры на куки. Вот информация для IE. Здесь - это страница с несколькими браузерами.
Куки файлы не сохраняются на сервере, а на основе домена (на сервере может размещаться много доменов или наоборот, ферма серверов может обслуживать один домен).
В общем, я бы избежал сохранения большого количества информации в файлах cookie, поскольку данные отправляются в браузер и из браузера по каждому запросу. Как вы можете предположить в своем вопросе, это может повлиять на производительность.
Обычно один хранит небольшие объемы данных в файле cookie, в основном используется для идентификации пользователя/сеанса, поэтому большее количество данных может быть получено из базы данных или другого ресурса, локального на веб-сервере.
Если вы программируете веб-сайт, рекомендуется не хранить слишком много в cookie, потому что этот файл cookie отправляется на сервер каждый раз, когда пользователь запрашивает страницу с вашего сайта. Гораздо лучшее решение - просто сохранить уникальный идентификатор в файле cookie и позволить серверу вытащить необходимую информацию из базы данных или хранилища файлов на основе этого уникального идентификатора. К сожалению, это решение приводит к тому, что люди беспокоятся о том, что вы отслеживаете о них, поэтому вы можете захотеть, чтобы "политика cookie", выраженная где-то на вашем сайте, говорила о том, почему вы размещаете cookie в своем браузере и что вы делаете, и Не прослеживайте их.
4096 байт Реальная проблема, однако, возникает, когда вы пытаетесь установить файлы cookie с большим размером. В стандартах указано, что браузер должен поддерживать минимум 4096 байт на файл cookie. IE6 этого не делает. Вместо этого он, кажется, имеет максимальный размер 4096 байт для всех файлов cookie из домена.
Здесь действительно хороший сайт с ограничениями на файлы cookie и позволяет протестировать ваш браузер:
CDN приходит к спасению.
Вы можете разгрузить статический контент в CDN или службу хранения файлов, такую как Amazon S3, сохраняя при этом, что статические запросы на файлы cookie должны быть легкими, если вы не создали запись CNAME на субдомене, который принимает файлы cookie с вашего домен верхнего уровня.
Этот Сообщение в блоге хорошо читается для публикации статического контента из домена Cookieless и как мы можем принять эту передовую практику, чтобы повысить нашу производительность на стороне клиента.