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 .html . 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 Cache-Control , Expires , ETag oraz Last-Modified .

Gdy odwiedzamy jakiś blog WordPress'a po raz pierwszy, szereg jego elementów jest buforowanych w cache przeglądarki. W ten sposób pewne pliki, np. .css, .js 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 nagłówek Cache-Control, Expires, Last-Modified, czy ETag. Gdy w takim nagłówku określimy wysoką wartość max-age , 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 .css 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.

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 oprogramowanie dnsmasq. Zapewnia ono nie tylko wspomniany wyżej serwer DHCP ale także serwer cache'ujący zapytania DNS. Ten drugi z kolei jest niezastąpiony w przypadku przekazywania zapytań o nazwy domen do upstream'owego serwera DNS, który zajmuje się rozwiązywaniem tych nazw na odpowiadające im adresy IP. Bez dnsmasq ogarnięcie naszej sieci przerodziłoby się w istne piekło. Dlatego też w tym artykule przybliżymy sobie nieco konfigurację tego narzędzia.

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 narzędzia dnsmasq.