C# - ASPX lapok kompressziójának engedélyezése a Web-szerveren

Az Internet Information Service (IIS) Web-szerver 5.0 verziójától kezdve elérhető egy szolgáltatás, mely a HTTP Compression nevet viseli, és amelynek segítségével „összenyomhatóak” a webes állományok, mielőtt a hálózaton át eljutnának a kliensoldalra. A funkció opcionális, használata előtt néhány beállítást el kell végeznünk a szerveren. Cikkünkben ennek részleteiről készítettünk egy összefoglalót.
Elve
A HTTP kompresszió – ahogy a bevezetőben is említettük – egy olyan beépített funkció, mely gyors adatátvitelt tesz lehetővé a Web-szerver és a kliens böngészője között úgy, hogy csökkenti a mozgatott adathalmaz mennyiségét. Ezt a lehetőséget elsősorban olyan lassú hálózati kapcsolattal rendelkező kliensek esetén célszerű alkalmazni, mint amilyenek a modemmel csatlakozó felhasználók.
A HTTP kompresszió nem csak „összenyomja”, de átmenetileg tárolja is a statikus állományokat (caching). Ennek a módszernek köszönhetően bizonyos esetekben akár 400%-os átviteli teljesítményjavulás is elérhető.
A HTTP kompresszió a standard ipari GZIP és a Deflate algoritmusokat használja a kimenet méretének csökkentésére, melyek a Windows 2000 és az Internet Explorer 4 verziók óta megtalálhatóak a rendszerekben.
Az algoritmusok a kliensoldalon akkor dekompresszálják a kapott adathalmazt, ha a kliens böngészője a HTTP 1.1 verziót használja, vagyis a böngésző speciális beállítása engedélyezett.
Ezt az Internet Explorer Beállítások – Internetbeállítások menüpontjának megnyomása után megjelenő ablak Speciális fülén engedélyezhetjük.
Az első alkalommal, amikor a HTTP 1.1-képes kliens megkapja a statikus fájlt, akkor a fájl még nem kompresszált. Ekkor a Web-szerver a fájl összenyomott másolatát elmenti egy ideiglenes mappába. A következő alkalommal, amikor egy – a fenti módon engedélyezett – kliens kéri az adott fájlt, akkor már az ideiglenes mappában tárolt változat jut el a kérő oldalra.
Az IIS természetesen megtartja a fájl eredeti, nem összenyomott változatát is, és annak frissülésekor frissíti a kompresszált változatot is. A dinamikus kimenet azonban nem kerül eltárolásra az ideiglenes mappában, helyette minden kéréskor nyomódik össze, és jut el a kliens-oldalra. A kimenet kompressziója nem azonos a klasszikus fájl- vagy könyvtár-tömörítéssel, hiszen a két dolog eltérő célt szolgál. Lássuk, mik is a különbségek:
  • A kimenet kompressziója a statikus fájlokra érvényes, és a hálózati terhelés csökkentése a cél, míg a tömörítés révén helymegtakarítás érhető el a merevlemezen.
  • Az IIS által összenyomott állományok az ideiglenes mappából olvasódnak ki, és ilyen állapotban íródnak a memóriába, míg a kitömörített állományok a merevlemezről töltődnek be ugyanoda.
Felhasználás
A kompresszió bizonyos szituációkban hasznos, máskor inkább gátja az internetes adatmozgatásnak. Vizsgáljuk meg azokat az eseteket, amikor érdemes ezt a megoldást használni:
  • Modemet használó kliensek esetén, ahol a letöltött mennyiség csökkentésével csökkenthető a letöltés ideje is, illetve annak költsége is.
  • Többnyire statikus oldalakat tároló Web- illetve fájl-szerverek esetén, ahol ezáltal a processzor túlterhelése minimalizálható, hiszen a kompresszált állományok egy cache tárban tárolódnak, így csökken a kompresszió/dekompresszió műveletére fordított processzoridő.
Most lássuk azokat az eseteket, amikor nem ajánlatos a használata:
  • Olyan szervereken, ahol a processzor terhelése már 80% fölötti, nem ajánlatos használni, hiszen az összenyomás és annak inverz művelete további időt rabol el a drága processzoridőből.
  • Dinamikus adathalmazt generáló alkalmazásokat futtató szerverek esetén sem ajánlatos, hiszen a dinamikus adathalmaz nem tárolódik ideiglenesen, így az összenyomás és kibontás időigényes.
Engedélyezés az IIS-ben
A műveletet legegyszerűbben manuálisan végezhetjük el a Web-szerver egyik adminisztrációs Script-jének segítségével. A következő művelet végrehajtása előtt érdemes egy mentést végezni a Web-szerverünkön, hiszen a procedúra az IIS metabázisát érinti, amely megsérülhet.
Első lépésként indítsunk el egy Parancssort. Legegyszerűbb, ha a Visual Studio.NET beépített parancssorát indítjuk el, mely a Start menüből megtehető.

Miután ezt megtettük, állítsuk le a Web-szervert, és a hozzá kapcsolódó szervizeket. Ennek utasítása a parancssorból a következő:
net stop iisadmin
Ezt követően lépjünk be az IIS adminisztrációs Script-jeit tartalmazó mappába.
cd <Web-szerver meghajtója>:\InetPub\adminscripts
A következő összetett utasítással átadunk a műveletnek megfelelően néhány parancssori argumentumot az ADSUTIL.VBS VBScript állománynak. Az utasítás engedélyezteti a GZIP algoritmus szerinti kompressziót az .ASP, .DLL, .EXE és .ASPX kiterjesztésű állományokra.
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "dll" "exe" "aspx"
Most a Deflate algoritmus szerinti kompressziót engedélyezzük a fenti típusokra.
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "dll" "exe" "aspx"
Ezt követően indítsuk újra a Web-szervert.
net start w3svc
Megemlítjük, hogy az utolsó művelet nem indította újra az összes kapcsolódó szervizet, melyet eredetileg leállítottunk, így azokat külön kell elindítanunk.
A művelet eredményeképpen az engedélyezés megtörtént, melyet a Web-szerver tulajdonságlapján meg is tekinthetünk.
Ennek érdekében az IIS kezelőkonzoljában keressük meg a Webhelyek csomópontot, majd annak gyorsmenüjében a Tulajdonságok menüpontot.
Az ISAPI szűrők fül alatt megtekinthető a kompresszióért felelős szűrő, róla adatok kaphatók. Látható, hogy a Windows rendszermappájában található D:\WINDOWS\System32\inetsrv\compfilt állomány van betöltve, és hogy a prioritása magas.