<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Cache on Morfitronik</title>
    <link>https://morfikov.github.io/tags/cache/</link>
    <description>Recent content in Cache on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Mon, 01 Aug 2016 18:50:48 +0000</lastBuildDate><atom:link href="https://morfikov.github.io/tags/cache/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Cache-Control, Last-Modified, ETag i Expires w Apache2</title>
      <link>https://morfikov.github.io/post/cache-control-last-modified-etag-i-expires-w-apache2/</link>
      <pubDate>Mon, 01 Aug 2016 18:50:48 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/cache-control-last-modified-etag-i-expires-w-apache2/</guid>
      <description>&lt;p&gt;Każda przeglądarka internetowa potrafi buforować dane w swoim cache w celach optymalizacji
przeglądanych stron www. Dzięki temu, szereg elementów odwiedzonych już witryn nie musi być
ponownie pobieranych z serwera. Zyskuje na tym nie tylko serwer ale również i sam klient, któremu
strona ładuje się parokrotnie szybciej. Pod ten mechanizm podpadają nie tylko pliki graficzne ale
również style CSS, skrypty JS, a nawet pliki &lt;code&gt;.html&lt;/code&gt; . Generalnie rzecz ujmując, wszystko co serwer
www jest w stanie przesłać przeglądarce. Problemem może jednak się okazać zbyt krótki/długi okres
ważności cache. Jeśli ten czas jest za krótki, to elementy strony będą niepotrzebnie utylizować
łącze, nie tylko nasze ale również i serwera www. Z kolei, jeśli okres ważności będzie za długi,
to będziemy odwiedzać nieaktualną stronę. Optymalnym rozwiązaniem byłaby taka konfiguracja serwera
www, gdzie dla konkretnych elementów strony sami moglibyśmy ustalić czas ważności cache. Apache2
daje nam taką możliwość przez ustawienie nagłówków HTTP &lt;code&gt;Cache-Control&lt;/code&gt; , &lt;code&gt;Expires&lt;/code&gt; , &lt;code&gt;ETag&lt;/code&gt; oraz
&lt;code&gt;Last-Modified&lt;/code&gt; .&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>WordPress: Wersja plików .css/.js na blogu</title>
      <link>https://morfikov.github.io/post/wordpress-wersja-plikow-css-js-na-blogu/</link>
      <pubDate>Fri, 29 Jul 2016 13:08:24 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/wordpress-wersja-plikow-css-js-na-blogu/</guid>
      <description>&lt;p&gt;Gdy odwiedzamy jakiś blog WordPress&#39;a po raz pierwszy, szereg jego elementów jest buforowanych w
cache przeglądarki. W ten sposób pewne pliki, np. &lt;code&gt;.css&lt;/code&gt;, &lt;code&gt;.js&lt;/code&gt; czy też obrazki, nie są pobierane
bezpośrednio z serwera www, bo mamy je lokalnie u siebie na dysku. Takie rozwiązanie zapewnia
szybsze załadowanie się strony przez minimalizowanie ruchu sieciowego. Niemniej jednak, jako że te
pliki siedzą w cache, to muszą mieć ustawiony pewien czas ważności. Może on być różny, a my możemy
go sobie dostosować dla poszczególnych elementów ustawiając im &lt;a href=&#34;https://morfikov.github.io/post/cache-control-last-modified-etag-i-expires-w-apache2/&#34;&gt;nagłówek Cache-Control, Expires,
Last-Modified, czy
ETag&lt;/a&gt;. Gdy w takim
nagłówku określimy wysoką wartość &lt;code&gt;max-age&lt;/code&gt; , przeglądarka klienta może przez bardzo długi czas nie
być świadoma faktu, że któreś elementy strony uległy zmianie. W efekcie może i pojawiła się nowa
wersja pliku &lt;code&gt;.css&lt;/code&gt; ale klienci odwiedzający nasz serwis i tak nie zaobserwują żadnej różnicy do
momentu wygaśnięcia cache lub też odświeżenia strony z przytrzymanym klawiszem Shift . Możemy jednak
dodać numer wersji do określonych plików i uzależnić go od czasu modyfikacji danego zasobu na
serwerze. Jeśli zmianie ulegnie plik, klient automatycznie pobierze zmodyfikowany zasób.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>DHCP i DNS, czyli konfiguracja sieci w OpenWRT</title>
      <link>https://morfikov.github.io/post/dhcp-dns-czyli-konfiguracja-sieci-w-openwrt/</link>
      <pubDate>Mon, 02 May 2016 16:21:20 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/dhcp-dns-czyli-konfiguracja-sieci-w-openwrt/</guid>
      <description>&lt;p&gt;Rutery WiFi są w stanie zorganizować przewodową i/lub bezprzewodową sieć w naszych domach. By taka
sieć działała bez zarzutu, potrzebna jest odpowiednia adresacja wszystkich komputerów wewnątrz niej.
W obecnych czasach już praktycznie nie stosuje się statycznej konfiguracji, bo to zadanie zostało
zrzucone na barki serwera DHCP. W OpenWRT do tego celu oddelegowane jest &lt;a href=&#34;http://www.thekelleys.org.uk/dnsmasq/doc.html&#34;&gt;oprogramowanie
dnsmasq&lt;/a&gt;. Zapewnia ono nie tylko wspomniany wyżej serwer DHCP ale także serwer cache&#39;ujący
zapytania DNS. Ten drugi z kolei jest niezastąpiony w przypadku przekazywania zapytań o nazwy domen
do upstream&#39;owego serwera DNS, który zajmuje się rozwiązywaniem tych nazw na odpowiadające im adresy
IP. Bez &lt;code&gt;dnsmasq&lt;/code&gt; ogarnięcie naszej sieci przerodziłoby się w istne piekło. Dlatego też w tym
artykule przybliżymy sobie nieco konfigurację tego narzędzia.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Cache DNS, czyli włączenie buforowania zapytań</title>
      <link>https://morfikov.github.io/post/cache-dns-buforowania-zapytan/</link>
      <pubDate>Mon, 16 Nov 2015 20:13:06 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/cache-dns-buforowania-zapytan/</guid>
      <description>&lt;p&gt;Większość z nas wie, że standardowe instalacje systemu linux nie buforują żadnych zapytań do
serwerów DNS. Dzieje się tak dlatego, że te systemy domyślnie nie mają zainstalowanego żadnego
oprogramowania, które by im to umożliwiało. Niesie to ze sobą zwiększenie opóźnień transakcji
krótkoterminowych, np. tych w protokole http czy https. Za każdym razem gdy odwiedzamy jakiś serwis
www, musimy wykonać szereg zapytań DNS, by rozwiązać nazwy domen na adresy IP. W przypadku gdybyśmy
mieli cache DNS, to te nazwy nie musiałyby być za każdym każdym razem rozwiązywane na nowo,
przynajmniej nie przez odpytywanie zdalnego serwera DNS, do którego RTT wynosi jakieś 20-40ms.
Przydałoby się zatem nieco poprawić wydajność stron www i w tym wpisie postaramy się zaimplementować
prosty cache DNS z wykorzystaniem &lt;a href=&#34;http://www.thekelleys.org.uk/dnsmasq/doc.html&#34;&gt;narzędzia dnsmasq&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
