24.06.2010

Падручнік па кэшаванню

Original by Mark Nottingham

Для вэб-аўтараў і вэбмайстроў

Гэта інфармацыйны дакумент. Хоць тэхнічны характар, ён спрабуе зрабіць канцэпцый зразумелым і дастасоўным у рэальных сітуацыях. З-за гэтага, некаторыя аспекты матэрыялу з’яўляюцца спрошчанымі ці апушчаны, для выразнасці. Калі вы зацікаўлены ў дробязях гэтага пытання, калі ласка, вывучыць даведкавая і іншая інфармацыя у канцы.

1. Што такое Web-кэша? Чаму людзі іх выкарыстоўваць?
2. Выгляды вэб-кэша
   1. Кэш браўзара
   2. Проксі Кэш
3. Не вэб кэш дрэнна для мяне? Чаму я павінен ім дапамагчы?
4. Як вэб кэш працы
5. Як (і як не варта) Кантроль кэш
   1. HTML мета-тэгі супраць Загалоўкі
   2. Pragma HTTP загалоўкі (і чаму яны не працуюць)
   3. Кіраванне Свежасць з Мінае HTTP Header
   4. Control HTTP загалоўкаў кэш
   5. Валідатаров і праверка
6. Рады па стварэнні кэш-Aware сайта
7. Даць кэш-Aware Сцэнары
8. Часта задаваныя пытанні
9. Ажыццяўленне Нататкі – вэб-серверы
10. Ажыццяўленне Нататка – сцэнараў на боку сервера
11. Даведкавая і іншая інфармацыя
12. Пра гэты дакумент

Што такое Web-кэша? Чаму людзі іх выкарыстоўваць?

Вэб кэш знаходзіцца паміж 1 ці некалькі вэб-сервераў (таксама вядомы як паходжанне сервераў) і кліентам ці шмат кліентаў, і гадзіны просіць прыехаць, захаванне копіі адказаў – як HTML старонак, малюнкаў і файлаў (вядомых пад агульнай назвай прадстаўніцтваў) – само за сябе. Тады, калі ёсць яшчэ адзін запыт на той жа URL, ён можа выкарыстоўваць адказ, што ён, замест таго каб прасіць паходжанні сервер для яго зноў.

Ёсць два асноўныя чыннікі, што вэб-кэша выкарыстоўваюцца:

• Каб паменшыць латэнтнасць – Таму што запыт выконваецца з кэша (які знаходзіцца бліжэй да кліента), а не паходжанне сервер, гэта займае менш часу для таго, каб атрымаць уяўленне і адлюстраваць яе. Гэта робіць вэб здаюцца больш спагаднымі.
• Для памяншэнні сеткавага трафіку – Таму што ўяўленні паўторна, ён памяншае колькасць якія перасылаюцца дадзеных ад кліента. Гэта эканоміць грошы, калі кліент плаціць за трафік, а трымае іх патрабаванні да прапускной здольнасці ніжэй і больш кіраваным.

Выгляды вэб-кэша

Кэш браўзара

Калі вы пагледзіце на дыялог налад любога сучаснага вэб-браўзара (напрыклад, Internet Explorer, Safari і Mozilla), вы, верагодна, заўважылі "кэш" налады. Гэта дазваляе вылучыць частку на цвёрдым дыску кампутара для захоўвання ўяўленняў, што вы бачылі, як раз для вас. Кэш браўзара працуе ў адпаведнасці з даволі простых правіл. Ён будзе праверыць, каб пераканацца, што ўяўленні свежыя, як правіла, адзін сеанс (гэта значыць адзін раз у бягучым выкліку браўзара).

Гэты кэш асабліва карысны, калі карыстачы стукнуў кнопку "Назад" ці націсніце на спасылку, каб убачыць старонку, а толькі што разгледзелі. Акрамя таго, калі вы выкарыстоўваеце тыя ж малюнкі, навігацыі на Вашым сайце, яны будуць падаецца з кэш браўзара практычна імгненна.

Проксі Кэш

кэшаў вэб-проксі працаваць па тым жа прынцыпу, але ў значна большым маштабе. Проксі служыць сотняў ці тысяч карыстачоў у такой жа ступені; буйных карпарацый і правайдараў часта задаюць іх на сваіх брандмаўараў, або як аўтаномныя прылады (таксама вядомы як пасроднікаў).

Таму што проксі-кэша не з’яўляюцца часткай кліента ці сервера крыніцы, але замест гэтага на сеткі, просьбы павінны быць накіраваны да іх неяк. Адзін са спосабаў зрабіць гэта складаецца ў выкарыстанні браўзара проксі вашых налад уручную сказаць яму, што проксі выкарыстоўваць, а іншы выкарыстоўвае перахопу. Перахопу проксі ёсць вэб-запыты перанакіроўваюцца на іх асноўных самай сеткі, так што кліенты не павінны быць наладжаны для іх, і нават не ведаюць пра іх.

Проксі кэшы тыпу агульная кэш-памяць, а, хутчэй, чым проста адзін чалавек, які выкарыстоўвае іх, яны, як правіла, вялікая колькасць карыстачоў, а таксама з-за гэтага яны вельмі добрыя на скарачэнне затрымак і сеткавага трафіку. Гэта таму, што папулярныя ўяўленні паўторна некалькі разоў.

Gateway кэш

Таксама вядомая як "зваротны кэша проксі" ці "сурагатнай кэш", кэшаў шлюз таксама пасроднікаў, але замест таго, каб разгарнуць сеткавымі адміністратарамі для эканоміі трафіку, яны, як правіла, разгорнутых Вэбмайстрам сябе, каб зрабіць свае сайты больш якія маштабуюцца, надзейных і і больш эфектыўныя.

Запыты могуць быць накіраваны на шлюз кэш цэлы шэраг метадаў, але, як правіла той ці іншай форме нагрузкі выкарыстоўваецца, каб зрабіць адзін ці некалькі з іх выглядаюць як паходжанне сервер для кліентаў.

Content Delivery Networks (CDNs) распаўсюджваць шлюз кэшаў у Інтэрнэце (ці яго частка) і прадаць зацікаўленым кэшаванні вэб-сайтаў. Speedera і Akamai прыклады CDNs.

Гэты падручнік факусуецца галоўным чынам на браўзар і проксі-кэш, хоць некаторая інфармацыя прызначана для тых, хто цікавіцца шлюза, а таксама кэш.

Не вэб кэш дрэнна для мяне? Чаму я павінен ім дапамагчы?

Вэб-кэшаванне з’яўляецца адным з самых незразумелых тэхналогій у Інтэрнэце. Вэбмайстрам, у прыватнасці, баяцца страціць кантроль над сваім сайтам, бо проксі-кэш можа "схаваць" іх карыстачоў ад іх, што робіць яго цяжка зразумець, хто выкарыстоўвае сайт.

Да няшчасця для іх, нават калі вэб кэша не існуе, Ёсць занадта шмат зменных у Інтэрнэт, каб гарантаваць, што яны будуць мець магчымасць атрымаць дакладную карціну таго, як карыстачы бачаць іх сайце. Калі гэта вялікая цікавасць для вас, гэта кіраўніцтва навучыць вас, як атрымаць статыстыку трэба без вашага сайта кэш-недружалюбныя.

Іншая праблема складаецца ў тым, што кэш можа служыць утрыманне, якое састарэла, або састарэлая. Тым не менш, гэты падручнік можа паказаць вам, як наладзіць сервер для кіравання ўтрыманнем у кэшы.

CDNs з’яўляюцца цікавай падзеяй, таму што ў адрозненне ад шматлікіх кэша проксі-сервера, іх кэш шлюза прыведзены ў адпаведнасць з інтарэсамі дадзенага вэб-сайта будзе захаваны, так што гэтыя праблемы не бачыў. Тым не менш, нават пры выкарыстанні CDN, вы ўсё яшчэ лічыце, што будзе проксі-сервер і браўзар кэш уніз па плыні.

З іншага боку, калі вы плануеце ваш сайт добра, кэш можа дапамагчы вэб-сайта загружаюцца хутчэй, і захаваць нагрузку на сервер і інтэрнэт-сувязь. Розніца можа быць жаласным; сайт, які цяжка кэша можа заняць некалькі секунд для загрузкі, у той час як адзін, што выкарыстоўвае кэшаванне можа здацца імгненнай у параўнанні. Карыстачы ацэняць хутка загрузкі сайта і часцей наведваць.

Думайце пра яго, такім чынам, шматлікія буйныя кампаніі, інтэрнэт марнуюць мільёны даляраў стварэння фермы сервераў па ўсім свеце, каб паўтарыць іх утрыманне, з тым каб зрабіць гэта з такой хуткасцю доступу да магчымасці для сваіх карыстачоў. Кэш зрабіць тое ж самае для вас, і яны нават бліжэй да канчатковага карыстача. Лепш за ўсё, вам не прыйдзецца плаціць за іх.

Справа ў тым, што проксі-сервер і браўзар кэша будзе выкарыстоўвацца падабаецца вам гэта ці няма. Калі вы не наладзіць свой сайт для кэшавання правільна, ён будзе захоўвацца ў кэшы выкарыстоўваючы для гэтага ўсё па змаўчанні адміністратар кэша ў вырашае.

Як вэб кэш працы

Усё схованак набор правіл, якія яны выкарыстоўваюць, каб вызначыць, калі служыць уяўленне з кэша, калі ён даступны. Некаторыя з гэтых правіл усталёўваюцца ў пратаколы (HTTP 1.0 і 1.1), а некаторыя з іх, усталяваных адміністратарам у кэш-памяці (карыстачу кэш браўзара ці проксі-адміністратар).

Наогул кажучы, гэта самыя агульныя правілы, якія вынікаюць (не хвалюйцеся, калі вы не разумееце, дэталі, гэта будзе растлумачана ніжэй):

Разам, свежасць і праверкі найболей важных шляхоў, што кэш працы з кантэнтам. Свежыя ўяўленні будуць даступныя адразу з кэша, у той час праверкі ўяўленне будзе пазбегнуць адпраўкі ўсё ўяўленне зноў, калі ён не змяніўся.

Як (і як не варта) Кантроль кэш

Ёсць некалькі прылад, якія вэб-дызайнераў і вэбмайстроў можна выкарыстоўваць для тонкай налады як схованак будзе лячыць сваіх сайтах. Гэта можа запатрабаваць атрыманні рукі трохі брудны ад канфігурацыі вашага сервера, але вынік таго варта. Падрабязней пра тое, як выкарыстоўваць гэтыя сродкі з вашага сервера, гл. выкананні ніжэйзгаданых частках.

HTML мета-тэгі і загалоўкі HTTP

HTML аўтараў можа паставіць пазнакі ў частцы <HEAD> дакументаў, якія апісваюць яго атрыбутаў. Гэтыя мета-тэгі часта выкарыстоўваюцца ў надзеі, што яны могуць пазначыць дакумент як uncacheable ці міне яго на вызначаны час.

Мета-тэгі простыя ў выкарыстанні, але яны не вельмі эфектыўныя. Гэта таму, што яны толькі гонар некалькі кэш браўзара (які насамрэч чытаць HTML), а не проксі кэш (якія амаль ніколі не чытаў HTML у гэтым дакуменце). Хоць, можа паўстаць спакуса паставіць Pragma: No-кэша метатег на вэб-старонку, тое гэта не абавязкова прывесці да яе быць свежымі.

Калі ваш сайт змесцаваны на інтэрнэт-правайдару ці хостынг ферме, і яны не даюць вам магчымасць усталёўваць адвольныя загалоўкі HTTP (напрыклад, Expires і Cache-Control ), жаляцца гучна гэтыя прылады, неабходныя для выканання вашай працы.

З іншага боку, праўда загалоўкі HTTP даць вам шмат кантроль над тым, як абодва браўзара і проксі кэш апрацаваць вашы ўяўленні. Яны не могуць разглядацца ў HTML, і, як правіла, аўтаматычна ствараюцца вэб-сервера. Тым не менш, вы можаце кіраваць ім у некаторай ступені, у залежнасці ад сервера, які вы выкарыстоўваеце. У наступных частках вы ўбачыце, што загалоўкі HTTP цікава, і як ужываць іх на ваш сайт.

HTTP загалоўкі, якія адпраўляюцца серверам перад HTML, і толькі бачыў у браўзары і любыя прамежкавыя кэшы. Тыповыя загалоўкі HTTP 1,1 адказ можа выглядаць наступным чынам:

HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: "3e86-410-3596fbbc"
Content-Length: 1040
Content-Type: text/html

HTML будзе вынікаць гэтых загалоўкаў, падзеленых пустым радком. Гл. выкананні частак для атрымання інфармацыі пра наладу HTTP загалоўкаў.

Pragma HTTP загалоўкі (і чаму яны не працуюць)

Шматлікія людзі лічаць, што прызначэнне Pragma: no-cache HTTP загаловак уяўленне зробіць uncacheable. Гэта не заўсёды дакладна; спецыфікацыі HTTP не ўсталёўваць якія-небудзь кіраўнічыя прынцыпы для загалоўкаў Pragma адказу, замест гэтага, Pragma загалоўкаў запыту (загалоўкі, у якіх браўзар пасылае на сервер) абмяркоўваюцца. Хоць некаторыя кэшы могуць прыняць гэты загаловак, большасць не будзе, і не будзе мець ніякага эфекту. Выкарыстоўвайце загалоўкі, а не ніжэй.

Кіраванне Свежасць з Мінае HTTP Header

Expires загалоўка HTTP з’яўляецца асноўным сродкам кантролю кэша, ён распавядае ўсе кэшы, колькі злучана ўяўленне свяжэй. Пасля гэтага часу, схованкі заўсёды правярайце з ці сервера крыніцы дакумент зменены. Expires загалоўкі падтрымліваюцца практычна ўсё кэш-памяці.

Большасць вэб-сервераў дазволіць вам усталяваць Expires загалоўкі адказу на шэрагу кірункаў. Як правіла, яны дазволяць усталяванне абсалютнага часу мінае, чакай на падставе дадзеных апошняга часу, што кліент атрымаць уяўленне (час апошняга доступу), ці чакай на падставе дадзеных апошняга часу дакумент зменены на вашым серверы (час апошняга змены) .

Expires загалоўкі асабліва добрыя для стварэння статычных малюнкаў (напрыклад, сродкамі навігацыі і кнопкі) кэшуецца. Таму што яны не моцна зменіцца, вы можаце ўсталяваць надзвычай працяглага тэрміна часу на іх, што робіць ваш сайт з’явіцца значна больш гнуткай для карыстачоў. Яны таксама карысныя для кантролю кэшавання старонкі, якія рэгулярна змянілася. Напрыклад, калі вы абновіце старонку навін разоў у дзень у 6 раніцы, вы можаце ўсталяваць уяўленне мінае ў той момант, так што кэш будзе ведаць, калі, каб атрымаць новую копію, карыстачоў без неабходнасці націсніце "Абнавіць".

Адзінай каштоўнасцю дзейнічае ў Expires загаловак дата HTTP; што-небудзь яшчэ, хутчэй за ўсё, быць вытлумачана як "у мінулым", так што ўяўленне нязменна. Таксама памятаеце, што раз у дзень HTTP гэты час па Грынвічы (GMT), а не па мясцовым часе.

Напрыклад:

 Expires: Fri, 30 Oct 1998 14:19:41 GMT 

Важна, каб пераканацца, што вэб-серверу гадзіны вашага дакладнай, калі вы выкарыстоўваеце Expires загалоўка. Адзін са спосабаў зрабіць гэта складаецца ў выкарыстанні Network Time Protocol (NTP); кажаце з вашым сістэмным адміністратарам, каб пазнаць больш.

Хоць Expires загалоўка карыснай, яна мае некаторыя абмежаванні. Па-першае, таму што дата ўдзел, гадзіны на вэб-серверы і кэш-памяці павінен быць сінхранізаваны, калі яны маюць іншае ўяўленне пра час, чаканыя вынікі не будуць дасягнуты, і кэш можа хібна лічаць чэрствы ўтрыманні, як свежыя.

Іншая праблема з Expires тым, што гэта лёгка забыцца, што вы ўсталявалі некалькі ўтрымання мінае ў вызначаны момант часу. Калі Вы не абновіце Expires час, перш чым ён праходзіць, кожны запыт будзе вярнуцца да вэб-серверу, павелічэнне нагрузкі і затрымкі.

-Control HTTP загалоўкаў кэш

HTTP 1,1 прадставіў новы клас загалоўкі Cache-Control загалоўкі адказу, каб даць Вэб-выдаўцы большы кантроль над іх утрыманнем, і ўліку абмежаванняў Expires .

Карысныя Cache-Control загалоўкі адказу складаюцца з:

• max-age= [секунд] – вызначае максімальная колькасць часу, уяўленне будзе лічыцца свежым. Як і ў Expires, гэта дырэктыва адносна момант запыту, а не абсалютным. [Секунд] гэта колькасць секунд з моманту запыту вы жадаеце ўяўленне набрацца.
• s-maxage= [секунд] – па аналогіі з max-age, акрамя таго, што яно ўжываецца толькі да агульных (напрыклад, проксі-сервер) кэшаў.
• public – адзначае сапраўднасць адказаў, кэшуецца, звычайна, калі HTTP патрабуецца аўтэнтыфікацыя, адказы аўтаматычна дзеляў.
• private – дазваляе кэшаў, якія з’яўляюцца спецыфічнымі для аднаго карыстача (напрыклад, у браўзары), каб захаваць адказ, агульныя кэш (напрыклад, у проксі-сервер) не можа.
• no-cache – кэш сіл, каб прадставіць просьбу пра паходжанне сервер для праверкі перад выпускам захаваную копію, кожны раз. Гэта карысна, каб гарантаваць, што праверка сапраўднасці паважаць (у спалучэнні з шырокай грамадскасці), ці для падтрымання цвёрдага свежасці, не ахвяруючы ўсімі перавагамі кэшавання.
• no-store – інструктуе кэша не захоўваць копію прадстаўніцтва ў любых умовах.
• must-revalidate, – распавядае кэшы, што яны павінны падпарадкоўвацца любому свежасць інфармацыі вы даяце ім пра ўяўленне. HTTP дазваляе кэшы, каб служыць чэрствы ўяўленняў у адмысловых умовах; паказаўшы гэты загаловак, вы кажаце, кэш, які вы жадаеце, каб строга прытрымвацца правіл.
• proxy-revalidate – па аналогіі з must-revalidate, акрамя таго, што яно ўжываецца толькі да проксі-кэшаў.

Напрыклад:

 Cache-Control: max-age=3600, must-revalidate 

Калі вы плануеце выкарыстоўваць Cache-Control загалоўкі, вы павінны глядзець на выдатнай дакументацыяй у HTTP 1.1, гл. Спіс літаратуры і іншая інфармацыя.

Валідатаров і праверка

У вэб-кэш працы мы адзначылі, што праверкі выкарыстоўваецца серверамі і схованак мець зносіны, калі ўяўленне змянілася. Выкарыстоўваючы яго, схованкі ў пазбяганне таго, каб запампаваць усё ўяўленне, калі ў іх ужо ёсць копія на месцах, але яны не ўпэўнены, што гэта яшчэ свежыя.

Валідатаров вельмі важныя, калі адзін не прысутнічае, і няма ніякага свежасць інфармацыі ( Expires ці Cache-Control ) даступная, схованкі не будзе захоўваць прадстаўніцтваў.

Часцей за ўсё Валідатар гэты час, што гэты дакумент апошні раз зменена, пра што было паведамлена ў Last-Modified загалоўка. Калі кэш захоўваецца ўяўленне, што складаецца з Last-Modified загалоўка, можна выкарыстоўваць яго для запытвае сервер, калі ўяўленне не змянілася з моманту апошняга часу было відаць, з If-Modified-Since запыту.

HTTP 1,1 прадставіў новы выгляд Валідатар завецца ETag. ETags унікальныя ідэнтыфікатары, якія генеруюцца на серверы і кожны раз змяніў уяўленне робіць. Паколькі сервер кіруе ETag генеруецца, кэш можа быць дакладным, калі ETag матчы, калі яны робяць If-None-Match запыт, уяўленне насамрэч тое ж самае.

Амаль усе кэшы выкарыстоўваць Last-Modified раз у вызначэнні, калі ўяўленне свяжэй; ETag праверкі таксама становіцца паўсюдным.

Большасць сучасных вэб-серверах будзе генераваць як ETag і Last-Modified загалоўкі для выкарыстання ў якасці Валідатары для статычнага кантэнту (напрыклад, файлы) аўтаматычна, Вам не прыйдзецца нічога рабіць. Тым не менш, яны не ведаюць досыць пра дынамічны кантэнт (напрыклад, CGI, ASP ці базы дадзеных, сайтаў), каб забяспечыць іх; гл. Даць кэш-Aware сцэнараў.

Рады па стварэнні кэш-Aware сайта

Акрамя таго, выкарыстоўваючы інфармацыю свежасці і праверкі, Ёсць шэраг іншых рэчаў, якія вы можаце зрабіць, каб зрабіць ваш сайт больш кэш-дружалюбных.

• Выкарыстанне URL-адрасы паслядоўна – гэта залатое правіла кэшавання. Калі вы служыце таго ж утрыманні на розных старонках, для розных карыстачоў, ці з розных гарадоў, яна павінна выкарыстоўваць той жа URL. Гэта самы просты і самы эфектыўны спосаб зрабіць сайт кэш-дружалюбных. Напрыклад, калі вы выкарыстоўваеце "/ index.html" у HTML у якасці даведкавага адзін раз, заўсёды выкарыстоўваць яго такім чынам.
• Выкарыстанне агульных бібліятэк малюнкаў і іншых элементаў і звярнуцца да іх з розных месцаў.
• Зрабіць кэш захоўвання малюнкаў і старонак, якія не часта змяняюцца з дапамогай Cache-Control: max-age загаловак з вялікім значэннем.
• Зрабіць кэш прызнаць, рэгулярна якія абнаўляюцца старонак, задаўшы адпаведныя макс па старасці ці па заканчэнні часу.
• Калі рэсурсаў (асабліва ў выглядзе загружанага файла) змены, зменіце яго імя. Такім чынам, вы можаце зрабіць гэта мінае ў далёкай будучыні, і ўсе гарантыі, што правільны варыянт падаецца; старонкі, спасылкі на гэта толькі адзін, які неабходна кароткія тэрміны прыдатнасці.
• Не змяняйце файлы без неабходнасці. Калі ды, тое ўсё будзе лжыва маладых Last-Modified дата. Напрыклад, пры абнаўленні сайта, не скапіяваць увесь сайт, проста перамесціце файлы, якія вы змянілі.
• Выкарыстанне кукаў толькі ў выпадку неабходнасці – печыва цяжка кэш-памяці і не патрэбныя ў большасці сітуацый. Калі вы павінны выкарыстоўваць кукі, абмежаваць яго ўжыванне дынамічных старонак.
• Мінімізаваць выкарыстанне SSL – таму што зашыфраваныя старонкі не захоўваюцца ў агульнай кэш, выкарыстоўвайце іх толькі, калі трэба, і малюнкі на старонках SSL эканомна.
• Праверце вашы старонкі з REDbot – гэта можа дапамагчы вам ужыць шматлікія з канцэпцый, у гэтым падручніку.

Даць кэш-Aware Сцэнары

Па змаўчанні, большасць сцэнараў не будзе вяртаць Валідатар ( Last-Modified і ETag загаловак адказу) ці свежасць інфармацыі ( Expires ці Cache-Control ). Хоць некаторыя скрыпты насамрэч з’яўляюцца дынамічнымі (маецца на ўвазе, што яны вяртаюцца іншы адказ на кожны запыт), шматлікія (напрыклад, пошукавых сістэм і на аснове баз дадзеных сайтаў) можа быць з кэш-дружалюбных.

Наогул кажучы, калі скрыпт вырабляе выснову, які прайграваных з той жа просьбай у пазнейшы час (няхай гэта будзе мінуць ці нават дзён), то варта кэшаваць. Калі ўтрыманне сцэнара змены толькі ў залежнасці ад таго, што ў URL, гэта cacheble, калі вынік залежыць ад печыва, праверка сапраўднасці інфармацыі ці іншым вонкавым прыкметам, ён, верагодна, гэта не так.

• Лепшы спосаб зрабіць сцэнар кэш-дружалюбных (а таксама выканаць лепш) гэта на звалку яго ўтрыманне просты файл, калі ён змяняецца. Вэб-сервер можа звяртацца з ёй як і любыя іншыя вэб-старонкі, ствараючы і выкарыстоўваючы Валідатары, што робіць ваша жыццё лягчэй. Не забывайце пісаць толькі файлы, якія былі зменены, таму Last-Modified разоў захаваліся.
• Яшчэ адзін спосаб зрабіць скрыпт кэшуецца ў абмежаваных маштабах з’яўляецца ўсталяванне ўзроставых загаловак, як у далёкай будучыні, як практычны характар. Хоць гэта можа быць зроблена з Expires, верагодна, гэта прасцей за ўсё зрабіць гэта з Cache-Control: max-age, якія зробяць запыт свяжэй прамежак часу пасля запыту.
• Калі вы не можаце рабіць, што вам трэба зрабіць сцэнар стварэння сэрвісу, а затым адказаць на If-Modified-Since і / ці If-None-Match запытаў. Гэта можа быць зроблена шляхам разбору HTTP загалоўкі, а затым аказвальнай 304 Not Modified калі гэта неабходна. Нажаль, гэта не trival задачы.

Некаторыя іншыя рады;

• Не выкарыстоўвайце POST, калі гэта неабходна. Адказы на метад POST не захоўваюцца большасць кэшаў, калі вы адправіць інфармацыю ў шляхі ці запыту (праз GET), таемныя склады зброі могуць захоўваць гэту інфармацыю на будучыню.
• Не ўстаўляць карыстачоў пэўнай інфармацыі ў URL, калі кантэнт зусім унікальным для дадзенага карыстача.
• Не разлічвайце на ўсе запыты карыстачоў з той жа гаспадар, таму што кэш часта працуюць разам.
• Стварыць Content-Length загаловак адказу. Гэта лёгка зрабіць, і гэта дазволіць адказ вашага скрыпту, якія будуць выкарыстоўвацца ў сталае злучэнне. Гэта дазваляе кліентам просьбе шматлікіх уяўленняў на адзін TCP / IP злучэнні, замест стварэння злучэння для кожнага запыту. Гэта робіць вашы сайт, падобна, значна хутчэй.

Гл. Ажыццяўленне адзначае Для атрымання больш пэўнай інфармацыі.

Часта задаваныя пытанні

Якія найболей важныя рэчы, каб кэшаваць?

Добрая стратэгія складаецца ў выяўленні найболей папулярных, найбуйных уяўленняў (асабліва малюнкі) і працаваць з імі ў першую чаргу.

Як я магу зрабіць свае старонкі як мага хутчэй з кэша?

Найболей кэшуемы уяўленне адзін з працяглай свежасці мноства. Праверка сапраўды дапамагае скараціць час, выдаткаванае на атрыманне ўяўлення, але кэш-памяці дагэтуль звязацца з сервера крыніцы, каб убачыць, калі ён свежы. Калі кэш ужо ведае, што гэта свежы, ён будзе абслугоўвацца напроста.

Я разумею, што кэшаванне гэта добра, але я павінен захоўваць інфармацыю пра тое, колькі людзей наведвае маю старонку!

Калі вы павінны ведаць кожны раз, калі старонка доступ, абярыце адзін маленькі пункт на старонцы (ці на самай старонцы), і зрабіць яго uncacheable, надаўшы яму адпаведны загалоўкі. Напрыклад, вы можаце звярнуцца да 1×1 празрыстай uncacheable малюнак з кожнай старонкі. Referer загаловак будзе ўтрымоўваць інфармацыю пра тое, што старонка завецца.

Памятаеце, што нават гэта не дасць сапраўды дакладных статыстычных дадзеных пра карыстачоў, і непрыязнымі ў адносінах да Інтэрнэт і вашы карыстачы, гэта прыводзіць да неабгрунтаванага рухі, і прымушае людзей чакаць, што некэшаваны пункт для загрузкі. Для атрымання дадатковай інфармацыі па гэтай нагодзе, гл. Пра тлумачэнне Даступная статыстыка ў спасылкі.

Як я магу ўбачыць HTTP загалоўкі ва ўяўленні?

Шматлікія вэб-браўзары дазваляюць вам бачыць Expires і Last-Modified загалоўкі ў "інфармацыя пра старонку" ці падобны інтэрфейс. Калі магчыма, гэта дасць вам меню старонкі і якіх-небудзь заяў (напрыклад, малюнкі), злучаныя з ім, разам з іх падрабязней.

Каб убачыць поўны загалоўкі ўяўленне, вы можаце ўручную падлучыцца да вэб-серверу з дапамогай кліента Telnet.

Каб зрабіць гэта, вам можа запатрабавацца ўвесці порт (будзе па змаўчанні, 80) у асобнай вобласці, ці вы, магчыма, запатрабуецца падлучыць да www.example.com:80 ці www.example.com 80 (звернеце ўвагу на прабел). Звернецеся да дакументацыі Telnet кліента.

Пасля таго як вы адкрылі злучэнне з сайтам, увядзіце запыт у прадстаўніцтва. Напрыклад, калі вы жадаеце ўбачыць загалоўкі http://www.example.com/foo.html злучэнне з www.example.com, порт 80, і ўвядзіце:

 GET / HTTP/1.1 foo.html [вярнуцца] Кіроўны: www.example.com [вярнуцца] [вярнуцца] 

Прэс К.ешгп кожны раз, калі вы бачыце [return], пераканаецеся, што націснуць яе двойчы ў канцы. Гэта будзе друкаваць загалоўкі, а затым поўнае ўяўленне. Каб убачыць толькі загалоўкі, замяніць HEAD для GET.

Мой старонак, абароненых паролем; як проксі кэш справа з імі?

Па змаўчанні старонкі абаронены сапраўднасці HTTP лічацца дзелямі, яны не будуць захоўвацца на агульных кэшаў. Тым не менш, вы можаце зрабіць праверку сапраўднасці старонак грамадскасці Cache-Control: грамадскія загалоўку HTTP 1.1-сумяшчальны кэш затым даць ім магчымасць быць змешчана ў кэш.

Калі вы жадаеце такіх старонак будзе кэшаваць, але праверка сапраўднасці для кожнага карыстача, аб’яднаць Cache-Control: public і no-cache загалоўкі. Гэта кажа кэш-памяці, што ён павінен прадставіць сапраўднасці новага кліента інфармацыю пра паходжанне сервера перад выпускам уяўленне з кэша. Гэта будзе выглядаць так:

 Cache-Control: дзяржаўныя, у аператыўнай памяці 

Ці няма, гэта будзе зроблена, то лепш звесці да мінімуму выкарыстанне праверкі сапраўднасці, напрыклад, калі вашы малюнкі не адчувальныя, змесціце іх у асобную тэчку і наладзіць сервер не прымушаць аўтэнтыфікацыі для яго. Такім чынам, гэтыя малюнкі будуць натуральна кэшуецца.

Ці павінен я турбавацца пра бяспеку, калі людзі атрымаць доступ да свайго сайта па кэш?

SSL старонкі не кэшуюцца (ці расшыфраваць) па даверанасці кэша, так што вам не прыйдзецца турбавацца пра гэта. Аднак, паколькі кэш захоўваць без SSL запыты і URL-адрасоў прынеслі праз іх, вы павінны быць асцярожныя незабяспечаныя сайтаў; нядобрасумленных адміністратар можа меркавана збіраць інфармацыю пра сваіх карыстачоў, асабліва ў URL.

Сапраўды, любы адміністратар сеткі паміж вашым серверам і вашы кліенты змогуць збіраць такую інфармацыю. Адна з пэўных праблем, калі CGI сцэнары пакласці імёнаў карыстачоў і пароляў у URL сябе; гэта робіць трывіяльнай для іншых, каб знайсці і іх карыстачоў Лагін.

Калі Вы ведаеце, пытанняў, злучаных вэб бяспекі ў цэлым, вы не павінны мець нейкіх неспадзевак ад проксі-кэшаў.

Я шукаю інтэграванае рашэнне вэб-публікацый. Якія з іх кэш-вядома?

Яна змяняецца. Наогул кажучы, больш складаныя рашэнні, тым больш цяжка кэш-памяці. Горшым з’яўляюцца тыя, якія дынамічна генераваць усё змесціва і не забяспечваюць Валідатары, яны не могуць кэшаваць на ўсіх. Кажаце з тэхнічным персаналам з вашым пастаўшчыком для атрымання больш падрабязнай інфармацыі, а таксама ўбачыць Ажыццяўленне нататках ніжэй.

Мае выявы мінае праз месяц, але мне трэба, каб змяніць іх у кэш цяпер!

Мінае загалоўка нельга абыйсці; калі кэш-памяці (браўзар ці проксі-сервер) выбягае з пакоя і, каб выдаліць уяўленняў, захаваная копія будзе выкарыстоўвацца датуль.

Найболей эфектыўным рашэннем з’яўляецца змена якіх-небудзь сувязяў з імі; такім чынам, зусім новыя ўяўленні будзе загружаны свежы з сервера. Памятаеце, што старонка, якая высылаецца на ўяўленне будзе захоўвацца ў кэшы, а таксама. З-за гэтага, лепш за ўсё рабіць статычныя малюнкі і аналагічных уяўленняў вельмі кэшуецца, пры захаванні HTML старонак, якія высылаюцца на іх на кароткім ланцужку.

Калі вы жадаеце перазагрузіць прадстаўлены пэўныя кэша, вы можаце прымусіць перазагрузкі (у Firefox, утрымліваючы зруху пры націску "Абнавіць" будуць рабіць гэта шляхам выдачы Pragma: no-cache загалоўку запыту) пры выкарыстанні кэш-памяці. Ці, вы можаце выдаляць кэш адміністратара ўяўленне праз іх інтэрфейс.

Я бягу паслуг вэб-хостынгу. Як я магу паведаміць сваім карыстачам публікаваць кэш-дружалюбных старонак?

Калі вы выкарыстоўваеце Apache, разгледзець пытанне пра падаванне імі карыстацца .htaccess файлаў і падаванні адпаведнай дакументацыі.

У адваротным выпадку, вы можаце ўсталяваць загадзя абласцей розных кэшаванні атрыбутаў кожнага віртуальнага сервера. Напрыклад, можна паказаць дырэкторыю / кэш-1м, што будзе захоўвацца ў кэшы на працягу аднаго месяца пасля ўступа, а / у аператыўнай памяці вобласць, якая будзе абслугоўвацца з загалоўкамі інструктаж кэша не захоўваць уяўленняў ад яго.

Што б вы здольныя зрабіць, лепш за ўсё працаваць з буйным кліентам на першым кэшаванні. Большасць зберажэнняў (у прапускной здольнасці і нагрузку на серверы), будзе рэалізаваны з высокім аб’ёмам сайтаў.

Я адзначыў, як на маіх старонках кэшуецца, але мой браўзар захоўвае прасіў іх пры кожным запыце. Як прымусіць кэш трымаць уяўленняў з іх?

Кэш не абавязаны трымаць прадстаўніцтвы і яго паўторнага выкарыстання; яны патрабуецца толькі, каб не захоўваць ці выкарыстоўваць іх у любых умовах. Усе кэшы прымаць рашэнні пра тое, якія ўяўленні трымаць на аснове іх памер, тып файла (напрыклад, малюнак супраць HTML), ці, колькі месца яны пакінулі захоўваць лакальныя копіі. Ваш не можа разглядацца варта пакінуць вакол, у параўнанні з папулярнейшымі і больш уяўленняў.

Некаторыя кэшы дазваляюць рабіць іх адміністратарам усталяваць прыярытэты, якія ўяўленні захоўваюцца, а некаторыя дазваляюць уяўленні будзе "замацаваць" у кэшы, так што яны заўсёды даступныя.

Ажыццяўленне Нататкі – вэб-серверы

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

Apache HTTP Server

Apache выкарыстоўвае дадатковыя модулі ўключаць загалоўкі, уключаючы дзеянні мінуў, Cache-Control. Абодва модуля даступныя ў 1,2 ці большы распаўсюд.

Гэтыя модулі павінны быць пабудаваны ў Apache, хоць яны ўключаны ў дыстрыбутыў, яны не ўключана па змаўчанні. Каб пазнаць, уключаны модулі на серверы, знайсці HTTPD бінарнага і запусціць httpd -l, гэта павінна вывесці спіс даступных модуляў (адзначым, што гэта толькі спісы, модуляў, на пазнейшых версій Apache, выкарыстоўваючы httpd -M, каб уключыць дынамічна загружаных модуляў, а). Модулі мы шукаем з’яўляюцца mod_expires і mod_headers.

• Калі яны не даступныя, і ў вас ёсць адміністрацыйны доступ, вы можаце перакампіляваць Apache, каб уключыць іх. Гэта можа быць зроблена або раскаментаваць адпаведныя радкі ў файле канфігурацыі, ці з выкарыстаннем -enable-module=expires і -enable-module=headers аргументы для налады (1,3 ці больш). Consult INSTALL файл знойдзены з размеркаваннем Apache.

Калі ў вас ёсць Apache з адпаведнымі модулямі, вы можаце выкарыстоўваць mod_expires паказаць, калі ўяўлення павінен мінаць або ў .htaccess файлаў ці ў access.conf файл сервера. Вы можаце паказаць тэрмін або з доступу ці змены часу, і ўжыць яго на тып файла ці па змаўчанні. Гледзіце дакументацыю модуля для атрымання дадатковай інфармацыі, і казаць з вашым мясцовым гуру, Apache, калі ў вас паўсталі праблемы.

Каб ужыць Cache-Control загалоўкі, вы павінны выкарыстоўваць mod_headers модуль, які дазваляе задаваць адвольныя загалоўкі HTTP рэсурсу. Гл. class="offsite" href="http://www.apache.org/docs/mod/mod_headers.html">mod_headers дакументацыі.

Вось прыклад .htaccess файл, які дэманструе выкарыстанне некаторых загалоўкаў.

• .htaccess файл дазваляе вэб-выдаўцам выкарыстоўваць каманды звычайна можна знайсці толькі ў файлах канфігурацыі. Яны ўплываюць на ўтрыманне каталога, яны знаходзяцца і іх падкаталогі. Звернецеся да адміністратара сервера, каб пазнаць, калі яны ўключаны.

### activate mod_expires
ExpiresActive On
### Expire .gif's 1 month from when they're accessed
ExpiresByType image/gif A2592000
### Expire everything else 1 day from when it's last modified
### (this uses the Alternative syntax)
ExpiresDefault "modification plus 1 day"
### Apply a Cache-Control header to index.html
<Files index.html>
Header append Cache-Control "public, must-revalidate"
</Files>

• Звернеце ўвагу, што mod_expires аўтаматычна вылічае і ўстаўкі Cache-Control:max-age загаловак па меры неабходнасці.

2 канфігурацыі Apache вельмі падобна, што і 1,3, гл. 2,2 mod_expires і mod_headers дакументацыі для атрымання дадатковай інфармацыі.

Microsoft IIS

Microsoft 'з Internet Information Server дазваляе лёгка ўсталяваць загалоўкі ў некалькі гнуткім спосабам. Звернеце ўвагу, што гэта магчыма толькі ў версіі 4 сервера, які будзе працаваць толькі на NT Server.

Каб задаць загалоўкі Пляц участку, абярыце яго ў Administration Tools інтэрфейс, і выхоўваць яго ўласцівасці. Пасля выбару HTTP Headers укладку, вы павінны ўбачыць два цікавых раёнаў; Enable Content Expiration і Custom HTTP headers . Першае павінна быць само за сябе, а другі можа быць скарыстаны для ўжывання Cache-Control загалоўкі.

Гл. частку ASP ніжэй для атрымання інфармацыі пра наладу загалоўкаў у Active Server Pages. Акрамя таго, можна ўсталяваць загалоўкі з модуляў ISAPI; спаслацца на MSDN для дэталяў.

Netscape / IPLANET Enterprise Server

Пачынальна з версіі 3.6, Enterprise Server не падае ніякіх відавочных спосабаў усталяваць Мінае загалоўкі. Тым не менш, яна падтрымлівае HTTP 1.1 функцыі, пачынальна з версіі 3.0. Гэта азначае, што HTTP 1,1 кэшаў (проксі-сервер і браўзар), змогуць скарыстацца Cache-Control налады вы робіце.

Для выкарыстання Cache-Control загалоўкі, абраць Content Management | Cache Control Directives у адміністрацыі сервера. Затым, выкарыстоўваючы рэсурс Picker, абраць каталог, дзе вы жадаеце ўсталяваць загалоўкі. Пасля ўсталёўкі загалоўкаў, націсніце кнопку "ОК". Для атрымання дадатковай інфармацыі гл. кіраўніцтва РЭШ.

Ажыццяўленне Нататка – сцэнараў на боку сервера

Адна справа мець на ўвазе, што можа быць прасцей усталяваць HTTP загалоўкаў з вэб-серверам, а не ў мове сцэнараў. Паспрабуйце абодва спосабу.

Паколькі акцэнт у серверных сцэнараў на дынамічны кантэнт, ён не робіць для вельмі кэшуемыя старонкі, нават калі ўтрыманне можа быць змешчана ў кэш. Калі ваш кантэнт змяняецца часта, але не на кожнай старонцы ўдар, разгледзець пытанне пра стварэнне Cache-Control: макс узросту загалоўка, большасць карыстачоў доступ да старонак ізноў у параўнальна кароткі перыяд часу. Напрыклад, калі карыстачы стукнуў кнопку "назад", калі няма ніякіх Валідатаров ці свежасць інфармацыі, ім прыйдзецца чакаць, пакуль старонка загружаецца нанова з сервера, каб убачыць яго.

CGI

CGI скрыптоў адзін з самых папулярных спосабаў для стварэння кантэнту. Вы можаце лёгка дадаць HTTP загалоўкаў адказу, дадаўшы іх перад адпраўкай цела; Большасць CGI рэалізацыі ўжо патрабуюць зрабіць гэта для Content-Type загалоўка. Напрыклад, у Perl;

#!/usr/bin/perl
print "Content-type: text/html\n";
print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n";
print "\n";
### the content body follows...

Since it’s all text, you can easily generate Expires and other
date-related headers with in-built functions. It’s even easier if you use Cache-Control: max-age;

 друк "Cache-Control: Max-узрост = 600 \ п"; 

Гэта зробіць скрыпт кэшуецца на працягу 10 мінуць пасля запыту, так што, калі карыстач націсне кнопку "назад", яны не будуць паўторнай просьбай.

Спецыфікацыя CGI таксама робіць загалоўкі запытаў, што кліент перадае інфармацыю пра даступныя ў асяроддзі сцэнар, кожны загаловак мае "HTTP_ 'пачынаюцца з яго імем. Такім чынам, калі кліент робіць If-Modified-Since запыт, ён будзе адлюстроўвацца як HTTP_IF_MODIFIED_SINCE .

Гл. таксама cgi_buffer бібліятэку, якая аўтаматычна апрацоўвае ETag генерацыі і праверкі, Content-Length пакаленні і GZIP кантэнт-кадаванні для Perl і Python CGI скрыптоў з 1-лайн уключыць. Версія Python могуць быць скарыстаны для абкручвання адвольных сцэнараў CGI з.

Server Side Includes

SSI (часта з пашырэннем. Shtml) з’яўляецца адным з першых шляхоў, што вэб-выдаўцы змаглі атрымаць дынамічны кантэнт на старонкі. З дапамогай адмысловых тэгаў на старонках, абмежаваную форму ў HTML-сцэнараў не было.

Большасць рэалізацый SSI не ўсталяваны Валідатары, і як такія не кэшуецца. Тым не менш, у рэалізацыі Apache гэта дазваляе карыстачам паказваць, якія файлы SSI можна кэшаваць, усталяваўшы групы дазволаў на выкананне адпаведных файлаў, у спалучэнні з XbitHack full дырэктывы. Для атрымання дадатковай інфармацыі гл. mod_include дакументацыі.

PHP

PHP уяўляе сабою серверная мова сцэнараў, які, калі ўбудаваныя ў сервер, могуць быць скарыстаны для ўбудавання сцэнараў усярэдзіне старонкі HTML, як і SSI, але са значна вялікай колькасцю опцый. PHP можна выкарыстоўваць у якасці сцэнара CGI на любым вэб-сервера (Unix ці Windows), ці ў якасці модуля Apache.

Па змаўчанні, уяўленняў апрацоўваюцца PHP не аднесены Валідатары, і, такім чынам uncacheable. Тым не менш, распрацоўнікі могуць набор загалоўкаў HTTP з дапамогай Header() функцыю.

Напрыклад, гэта створыць Cache-Control загалоўка, а таксама загаловак мінае за тры дня ў будучыні:

<?php
 Header("Cache-Control: must-revalidate");

 $offset = 60 * 60 * 24 * 3;
 $ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
 Header($ExpStr);
?>

Памятаеце, што Header() функцыя павінна ісці перад любым іншым выйсцем.

Як вы бачыце, вам прыйдзецца стварыць даты HTTP для Expires загалоўка ўручную, PHP не падае функцыі зробіць гэта за вас (хоць апошнія версіі зрабілі прасцей, гл. дату дакументацыі РНР ). Вядома, можна лёгка ўсталяваць Cache-Control: max-age header, які гэтак жа падыходзіць для большасці сітуацый.

Для атрымання дадатковай інфармацыі гл. кіраўніцтва запіс для загалоўка.

Гл. таксама cgi_buffer бібліятэку, якая аўтаматычна апрацоўвае ETag генерацыі і праверкі, Content-Length пакаленні і GZIP кантэнт-кадаванні для скрыптоў PHP з 1-лайн уключыць.

Cold Fusion

Cold Fusion, па Macromedia з’яўляецца камерцыйным сцэнараў на боку сервера рухавік, з падтрымкай некалькіх вэб-сервераў на Windows, Linux і некалькі разнавіднасцяў Unix.

Cold Fusion дазваляе задаваць адвольныя загалоўкі HTTP адносна лёгка, з CFHEADER пазнакі. Нажаль, іх прыклад для ўсталёўкі Expires загалоўка, як паказана ніжэй, гэта трохі ўводзіць у зман.

 <CFHEADER NAME="Expires" VALUE="#Now()#"> 

Гэта не будзе працаваць, як вы маглі падумаць, таму што часу (у дадзеным выпадку, калі такая просьба) не пераўтворацца ў HTTP-дапушчальнай датай, замест гэтага ён проста атрымлівае друкаваных як уяўленне Дата Cold Fusion, / Час аб’екта. Большасць кліентаў будуць або ігнараваць такія каштоўнасці, ці пераўтварыць яе па змаўчанні, як 1 студзеня 1970.

Тым не менш, Cold Fusion не прадугледжвае фармату даты функцыю, якая будзе рабіць працу; GetHttpTimeString. У спалучэнні з DateAdd , лёгка ўсталяваць Мінае даты, тут мы ўсталёўваны загаловак заявіць, што ўяўленні старонкі мінае на працягу аднаго месяца;

 <cfheader name="Expires" value="#GetHttpTimeString(DateAdd('m', 1, Now()))#"> 

Вы таксама можаце выкарыстоўваць CFHEADER тэгі для ўсталёўкі Cache-Control: max-age і іншыя загалоўкі.

Памятаеце, што загалоўкі вэб-сервера, перадаюцца ў некаторых разгортванні Cold Fusion (напрыклад, CGI), праверце ваш, каб вызначыць, ці можна выкарыстоўваць гэта ў сваіх мэтах, усталяваўшы загалоўкі на серверы, а не ў Cold Fusion.

ASP і ASP.NET

Пры ўсталёўцы HTTP загалоўкаў ад ASPs, пераканаецеся, што там таксама спосаб адказу званкоў перад любым пакаленнем, HTML ці выкарыстоўвайце Response.Buffer у буфер высновы. Адзначым таксама, што ў некаторых версіях IIS усталяваць Cache-Control: private загалоўкам ASPs па змаўчанні, і павінны быць абвешчаны грамадскасці на кэшуецца на агульных кэшаў.

Active Server Pages, убудаваны ў IIS, а таксама для іншых вэб-сервераў, а таксама дазваляе задаць HTTP загалоўкаў. Напрыклад, каб усталяваць час заканчэння тэрміна, вы можаце выкарыстоўваць уласцівасці Response аб’екта;

 <Response.Expires% = 1440%> 

з указаннем колькасці мінуць з моманту паступлення просьбы мінае прадстаўніцтвы. Cache-Control загалоўкі можна дадаць наступным чынам:

 <% Response.CacheControl = "грамадскага"%> 

У ASP.NET, Response.Expires састарэлы, належным чынам усталяваць злучаныя з кэшам загалоўкаў з Response.Cache ;

 Response.Cache.SetExpires (DateTime.Now.AddMinutes (60)); Response.Cache.SetCacheability (HttpCacheability.Public); 

Гледзіце дакументацыю MSDN для атрымання дадатковай інфармацыі.

Даведкавая і іншая інфармацыя

Спецыфікацыя HTTP 1.1

HTTP 1,1 спектру мноства пашырэнняў для стварэння старонак кэшуецца, і аўтарытэтнае кіраўніцтва па ажыццяўленні Пратаколу. Гл. часткі 13, 14,9, 14,21 і 14,25.

Web-Caching.com

Выдатныя ўводзіны ў кэшаванні канцэпцый, спасылкі на іншыя рэсурсы ў Інтэрнэце.

Пра тлумачэнне Даступная статыстыка

інфарматыўны Jeff Гольдберга гучныя словы пра тое, чаму вы не павінны разлічваць на доступ да статыстыкі і стукнуў лічыльшчыкаў.

REDbot

Разглядае HTTP сродкаў для вызначэння, якім чынам яны будуць узаемадзейнічаць з вэб кэш, і наогул, як яны выкарыстоўваюць гэты пратакол.

cgi_buffer бібліятэка

Аднарадковыя ўключыць у Perl CGI, Python CGI і PHP скрыпты аўтаматычна ручкі ETag генерацыі і праверкі, Content-Length пакаленні і GZIP Content-Encoding – правільна. Версія Python таксама можа быць скарыстаны ў якасці абалонкі вакол адвольныя сцэнары CGI.

Пра гэты дакумент

Гэты дакумент Copyright © 1998-2010 Марк Нотынгем <mnot@pobox.com>.
This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.

Усе гандлёвыя маркі ў межах, з’яўляюцца ўласнасцю іх адпаведных уладальнікаў.

Хоць аўтар лічыць, што ўтрыманне дакладнымі на момант публікацыі, не нясём адказнасці за іх, з іх ужываннем ці ўсе вынікаючыя наступствы. Калі які-небудзь скажэнняў, памылак ці іншых неабходнасць удакладнення будзе знойдзены, калі ласка, звяртайцеся неадкладна.

Апошняй рэдакцыі гэтага дакумента заўсёды можна атрымаць з http://www.mnot.net/cache_docs/

Переводы доступны на: кітайскай, чэшскай, нямецкай.