Вие определено ще трябва да се разбере как HTTP-кеширането. Честно казано, това е необходимо. Вече споменах много пъти, че изборът на HTTP-методи са изключително важно при проектирането на уеб услуги - по-специално, изборът на метода на GET ви дава възможност да се възползват от използването на HTTP-кеширането. Така че: да получите от използването на метода на GET всички ползи, които то може да осигури, че е необходимо да се разбере как работи HTTP-кеширане, и как може да се въведат ефективни, за да се увеличи производителността на вашите услуги.

В тази статия, аз няма да се обясни как да конфигурирате кеширане в уеб сървъра, който използвате, и няма да се описват различните видове кеширане. Ако наистина се интересуват, аз препоръчвам да се запознаят със забележителната учебника на HTTP-кеширането Марк Нотингам.

Първото нещо, което трябва да разберат - какви цели се преследват кеширане модел, използван от HTTP. Една от тези цели - е да се даде възможност на клиента и сървъра да се определят условията, при които се предава документа могат да бъдат взети от кеша. Лесно е да се види, че това само по себе носи определен кеш модел сложност.

В основата на модела за кеширане, използвани в HTTP, образуват валидатори - част от заявката, използван от клиента, за да се гарантира, че кеширана документът все още е валиден (т.е. не остарял). Използването валидатори позволява на клиента или междинен сървър, за да проверите текущото състояние на документа, без да ги прехвърлят на сървър кеширана копие на цялото. Сървърът, на свой ред, ще изпрати документа в отговор, само ако те са получили валидатора, показва наличието на клиентския кеш остаряла (невалидни) копие.

валидатори

Един от най-валидатори, които се използват в HTTP - това е ETag. ETag е хеш ( "отпечатък") байта на документа, ако е в промяна документ, дори и един байт, промяната и ETAG.

Преди да използвате този валидатор, е необходимо най-малко веднъж метод документ заявка GET. ако сървърът поддържа тази функция, заглавната ETag в отговора си ще съдържа хеш на предаваната версия на документа. Клиентът в този случай съхранява в кеш заедно с документа си ETag. и освен това изисква от един и същ документ, използвайки спаси ETAG като валидатора.

Да предположим, че аз попитах за документа за example.org сървър. и аз получих този отговор:

След това следващия път, когато аз питам за един и същ документ, използвайки метода на GET. Мога да използвам валидатор. Забележка: ETag запазена стойност се предава в заглавната If-None-Match.

Ако времето между искания документ не е бил променен, сървърът връща 304 Not Modified.

Ако документът се е променило, сървърът ще върне код 200 и преминава на нова версия на документа в отговора, както и стойността на ETag на тази нова версия.

Cache-Control

Валидатори се използват да се провери дали документът е променило; да управлява копия на кеширана, използвайте удар с глава на Cache-Control. Най-важният от управляващите директиви кеш - макс възраст. това означава, че се съхранява в кеш копието на документа е неактуален чрез макс възраст секунди. Тази директива могат да бъдат използвани в искането, а в отговор - така че и клиента и сървъра може да реши колко дълго ще бъде валидни документи, предадени от тях. Ако сървърът е кеширано отговор е сравнително нова, тя може да се върне директно от кеша; в противен случай се случва процедура валидиране описано по-горе.

Помислете отново ние получихме отговор от сървъра. В него Кеш-Control глава определя макс възраст = 7200. т.е. кеширано копие на документа, престава да бъде валидна след 2 часа.

В допълнение към макс възраст. в кеш-контрол глава оставя много други директиви. Всеки от тях може да се използва в заявки или отговори, или - като макс възраст - и в заявките и отговорите.

Директива разрешено в заявки

Също като задължително трябва да се презавери. но действа само на прокси сървъра.

Помислете примерите заглавие за ползване Cache-Control:

Cache-Control: лично, макс възраст = 3600

Е приемлив в отговора от сървъра; Това означава, че отговорът може да се съхранява само в кеша затворен за един час.

Cache-Control: обществен, трябва опресняването, макс възраст = 7200

Това означава, че отговорът може да се съхранява на открито кеширана за два часа; след изтичане на срока на валидност на резервното копие, трябва да се провери отново за всяка заявка.

Кеш-Control: Трябва-валидността, макс възраст = 0

Силите на клиента, за да провери отново валидността на съхранени копия за всяка заявка; макс възраст = 0 означава, че документът е неактуален веднага след получаването му от клиента. В тази книга, Марк Нотингам «Привличане Мрежата: кеширане» Горният пример на един любопитен случай, в който е възможно да се използва като заглавие.

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

Всички тези примери за използване на кеш-Control глава за това приложение в отговор от сървъра. А сега да разгледаме примери, където заглавието се използва в заявката.

Нарича "пълен" ( «край до край») Актуализация на документа: кеш, достъпни чрез клиентът трябва повторно искане на документа от сървъра, от която е бил закупен.

По този начин клиентът поиска глава документ, който ще остане в сила в продължение на 200 секунди след искането.

Може би се чудите дали кешът се заплете във всички тези ситуации. Например, какво трябва да направи, ако сървърът може да се върне на различни документи за същия URI? За такива случаи, предвидени в HTTP Вари глава. Този удар с глава посочва името на кеша на заглавията на искането, ако се промени, сървърът ще се върне различен документ.

Да приемем, че сървърът се договаря с типа на връщане клиент на документ - тогава различни отговори за едно и също URI може да имат различно заглавна Content-Type. в зависимост от договорения вид документ. След това на сървъра може да добавите в заглавната отговор Вари: приемете. и кеш, за да запазите индивидуални отговори на искания с различна Приеми заглавието.

В този пример, сървърът показва, че отговорът може да бъде записан в кеша за два часа, с индивидуално за заявки с различни заглавия Accept-Encoding и потребителски агент.

връзка

След сървъра успешно потвърждаване на валидността на кешираните резултати, например с помощта на заглавието валидатор If-None-Match. - той отговаря с 304 Not Modified. Още в този случай нищо не се случва, нали? Всъщност, не съвсем: сървърът може да изпрати отговор с 304 Not Modified удар с глава на стойността на документа, за да ги актуализира в кеш паметта. В допълнение, сървърът може да е в заглавието на връзката, за да се изброят имената на тези заглавия, които не се нуждаят, за да стане по-леко.

По подразбиране, някои заглавия не се запаметяват в кеш паметта - така наречените "главните съединения» ( «хоп-по-хоп»): връзка за проверка на връзката, Proxy удостоверите, Proxy-Разрешение, ТЕ, Ремаркета, Трансфер-кодиране и Upgrade , Стойностите на всички други заглавия - "удар с глава на документ» ( «край до край») - кеширана по подразбиране.

В този пример, датата на глава стойност. не-заглавното съединение и на заглавната част на свързване. Тя ще се съхранява в кеш паметта.

Де да беше толкова лесно

Въпреки че всички механизми за кеширане са описани някои сложност за наблюдение, най-малко, те образуват съгласуван логическа система. Естествено, всичко се усложнява от необходимостта да се работи със съществуващите сървъри и клиенти, използващи протокола HTTP 1.0. ; Работят от време - това по-стар протокол други заглавия се използват за управление на кеширане всички тези по-стари заглавия се поддържат в HTTP 1.1 за обратна съвместимост.

Използва се в кеширане модела на HTTP 1.0 е изградена около времето на стареене на документа. Last-Modified валидатора проверява Последната промяна на документа. Cache използва, за да се провери валидността на документ Дата заглавията. Изтича. Last-Modified и If-Modified-Since.

Сега, когато се разбере как кеширане HTTP, вероятно се чудите, ако има такива, за любимите си езикови готови библиотеки с кеширане скрипт. Мога да кажа за Python: за съжаление, все още не. Аз съм много съжалявам, че никой от най-добрите приложения на HTTP-клиенти не е писано в любимия ми език. И ние трябва да се коригира това недоразумение.

Имам удоволствието да ви представя httplib2 библиотека - пълнофункционален HTTP клиент написан на Python. Библиотеката поддържа локален кеш на закрито и разбира всички стъпки в тази статия операции върху тях. В допълнение, той има много функции, обикновено не се срещат в други HTTP библиотеки:

На другите възможности, можете да научите httplib2 страница на проекта.

Следващият път,