Tehnologii de Optimizare de Viteza pe Internet

Cuprins

Motivația alegerii temei

Înainte de a stabili tema lucrării s-a făcut o cercetare destul de complexă legată de Tehnologii de optimizare de viteza, căutând pe internet metodologii folosite pentru comprimarea fișierelor. Analiza problemei s-a condus la numeroase rezultate, dar dintre acestea niciuna nu s-a găsit destul de performantă, eficace și eficientă, care să corespunde la toate cerințele, deci prin prezenta lucrare s-a încercat să se construiască o tehnică de comprimare mult mai optimă, care nu apelează la resursele sistemului în fiecare dată când fișierele comprimate sunt deservite, realizează inclusiv minimizarea fișierelor înainte de a fi împachetate și ține cont și de reducerea numărului de request-uri HTTP și a pachetelor TCP/IP. Bineînțeles, ca și fiecare metodă, și metoda prezentată are dezavantajele sale legate de crearea fișierelor (fișiere împachetate trebuie să fie create manual din toolul prezentat) și incomoditatea la actualizările batch-urilor ( la orice schimbare în fișierele respective trebuie să se actualizeze și fișierele împachetate, stocate pe server). La evaluarea acestor probleme s-au luat în considerare două fapte:

controlul trebuie acordat cât mai mult programatorului / administratorului paginii (pentru a evita situații în care apar anumite erori în urma unor actualizări programate, executate automat). Restricția impusă de aplicația legată de actualizări asigură în aceeași timp și testarea de către un individ și nu impune probleme de responsabilitate.

de obicei timpul de dezvoltare, implementare și testare a unui modul extern de front-end (care are un impact pe partea de utilizator – fișier CSS și JavaScript în cele mai multe cazuri) reprezintă numai 2-3% din durata totală de viață al acestuia (maxim 5-10% în cazul proiectelor actualizate foarte des). Având în vedere rata de mai sus actualizarea manuală se consideră acceptabilă, accentul fiind pus mai mult pe experiența bună și mulțumirea a utilizatorilor și pe controlarea erorilor decât pe ușurarea muncii programatorului.

Importanta optimizarii de viteza regula de 8 secunde al internetului

La bază lucrării curente stă regula foarte bine cunoscută a paginilor WEB și anume cele de 8 secunde („the 8 seconds rule of the internet” [1]), care poate să fie sintetizată astfel: timpul maxim pe care un utilizator este dispus să aștepte la încărcarea unei pagini este 8 secunde. Fiindcă regula respectivă se bazează mai mult pe experiență din domeniul de vânzări online și nu provine de la o specificare standard de W3C, există mai multe abordări, și anume dacă site-ul trebuie să se încarce în întregime în 8 secunde (toate scripturile externe și imagini), să fie total funcționabil (design și structură construită dar nu toate imagini încărcate) sau să se trimite ceva răspuns sesizabil, chiar dacă pagina încă nu este disponibilă în întregime. În epoca conexiunilor de 12 MBPS regula respectivă poate fi considerată și depășită, limita nouă fiind numai de 4 secunde (pentru încărcarea site-ului funcționabil), conform sondajului făcut de firmă Jupiter Research, comandat de firmă Akamai [2] (sondaj făcut cu peste 1.000 de cumpărători online, în anul 2006). Alte abordări afirmau că o pagină care nu se încarcă în 8 secunde rezultă în vizitatori nemulțumite și că o astfel de pagină pierde un utilizator din 3 din start (33% din utilizatorii părăsesc pagina numai din cauza încărcării lente).

Obiectivele dorite

Pentru aplicațiile de comprimare principiile sunt următoarele:

să se realizeze o aplicație care în același timp:

minimizează sursă fișierelor

grupează fișierele cerute

împachetează fișierele folosind un format suportat de browsere web

să nu se facă câte un apel la modulul de comprimare cu fiecare cerere spre fișierele respective

controlul să rămână la programator și să nu se execute nici o comandă automat sau programat

să se facă javascripturile mai greu de copiat

să se mențină și o versiune comentată despre fișierele grupate

toate funcționarea să fie atât de transparent către programatorii și contributorii cât se poate

să fie ușor de instalat și de folosit

Prezentarea mediului de lucru și a tehnologiilor folosite

Modelul ISO-OSI și modelul TCP/IP

Modelul ISO-OSI de 7 nivele

Pentru a înțelege în adâncime cum funcționează internetul expresia de optimizare a cererilor (“request optimization”) se apelează la modelul propus de Organizația Internațională a Standardelor pentru interschimbarea datelor, și anume modelul ISO-OSI (International Organization for Standardization – Open Systems Interconnection Reference Model) pe care se bazează și funcționalitatea internetului (modelul TCP-IP).

Figura 3.1: schema modelului ISO-OSI

Pe figura 3.1 se prezintă schema modelului cunoscut și prin denumirea modelul OSI de 7 nivele (“OSI seven layer model”) cum era propusă de organizația în 1977. Pe partea dreapta s-a notat formatul informației transmise de la un nivel la celălalt (TPDU se referă la Transfer Protocol Data Unit, SPDU la Session Protocol Data Unit, etc.).

După cum se vede schimbarea propriu-zisă de informație are loc pe nivelul fizic pe un canal de comunicare hardware, în forma de șiruri de biți, controlat de componentă hardware a calculatorului (placă de rețea în cele mai multe cazuri). La acest nivel se stabilesc caracteristicile mecanice, electrice, funcționale și procedurale ale comunicării, ca și nivelele de tensiune (nivelul fizic exprimat în volți și nivelul logic – nivel logic pe 0 sau nivel logic pe 1) , sensul transmiterii (într-o singură direcție la un moment dat sau în mai multe direcții: simplex, duplex, semiduplex, fullduplex), stabilirea conexiunii, deci toate informațiile necesare pentru realizarea transmisiei biților de la emițător la receptor.

La nivelul legăturilor de date se realizează:

construirea cadrelor de date din fluxul primit secvențial

fixarea delimitatoarelor de cadre

detectarea erorilor de transmisie (bit de paritate, verificare de CRC cu un polinom generator – Cyclic Redundancy Check)

prelucrarea / trimiterea cadrelor de confirmare (ca și parte a procesului de hand-shaking)

rezolvarea problemelor legate de cadrele deteriorate, pierdute și duplicate (adică se realizează controlul traficului și tratarea erorilor)

evitarea inundării unui receptor lent cu date de la un emițător rapid (de exemplu prin spațiul tampon / buffer)

la acest nivel se realizează și problema accesului partajată la un canal de comunicație (de exemplu în cazul rețelelor distribuite).

La nivelul de rețea se asigură controlul funcționării subrețelei și se determină modul în care pachetele sunt dirijate de la sursă la destinație (stabilirea traseelor, evitarea supraîncărcării acestora, taxarea traficului pentru fiecare client, dimensiunea maximă a pachetelor, modul de adresare).

Nivelul de transport funcționează ca și un intermediar între rețeaua și nivelul de sesiune. Realizează convertirea datelor între cele două nivele și gestionarea conexiunilor de rețea (în mod normal câte una distinctă pentru fiecare conexiune cerută de nivelul sesiune). Tot pe acest nivel se realizează multiplexarea și demultiplexarea pachetelor, care apar în două situații:

există mai multe conexiuni pentru un singur transport (datele divizate)

există mai multe transporturi pe o singură conexiune

Deci se poate afirma că nivelul de transport este un nivel capăt-la-capăt (de la sursă la destinație).

Nivelul sesiune este responsabil pentru stabilirea sesiunilor între utilizatori de pe mașini diferite. O sesiune permite transportul obișnuit de date și furnizează în același timp servicii îmbunătățite (de exemplu la conectarea la distanță pe un sistem cu divizarea timpului sau la transferul unui fișier între două mașini). Responsabilitățile nivelului sunt:

controlul dialogului (sau în ambele sensuri simultan ori într-un sens odată, în acest caz ținând cont și de emițător căruia îi vine rândul să transmită).

gestionarea jetonului: jetoanele pot circula între mașini (eventual programe), ca cele două părți să nu încerce să realizeze aceeași operație în același timp. Numai partea care deține jetonul are voie să realizeze operația critică.

sincronizare: este o modalitate de a introduce puncte de control în fluxul de date. După un eșec trebuie numai să reia transferul datelor după ultimul punct de control.

În opoziție cu nivelele inferioare care se ocupă numai de transferul sigur al biților nivelul de prezentare se ocupă de sintaxa și semantica informațiilor transmise, adică realizează codificarea datelor într-un mod standard, prestabilit (codurile ASCII sau UNICODE pentru caractere, cod complementar 1 sau 2 pentru numere, etc.). Deci nivelul respectiv convertește datele din codificarea definită pe cablu în reprezentarea internă a mașinii.

Nivelul aplicației cuprinde o varietatea de protocoale care sunt implementate la nivelul aplicațiilor pe sisteme diferite, realizând schimburi de fișiere între diferite sisteme (FTP), terminala virtuală de rețea (telnet) și poșta electronică (e-mail). Clase speciale fiind implementate pentru protocoale respective aproape în orice limbaj de programare orientate pe web (ori în nucleul limbajului ori prin biblioteci încărcabile) ele se pot folosi foarte simplu.

!! atentie la forma !!

Sa fie tot textul TNR la 1 ½ randuri si justified !!

Modelul TCP/IP

Modelul TCP-IP se bazează pe modelul OSI de 7 nivele, chiar dacă nu s-a urmărit strict implementarea fiecărui nivel. Denumirea provine din cele mai importante două protocoale: TCP (Transmission Control Protocol), care realizează trimiterea datelor în formă de pachete și IP (Internet Protocol) care identifică sursa și destinația pachetelor. Pe baza modelului s-a implementat o mulțime de alte protocoale (telnet, FTP, SMTP, DNS, UDP). Pachete respective pot fi trimite în orice rețea; ei circulă independent până la destinație și poate să ajungă într-o ordine diferită față ordinei în care erau trimise, deci modelul realizează o conexiune intactă între două mașini atâta timp cât mașina sursă și destinația funcționează corect.

Diferențele între modelul TCP/IP și modelul OSI sunt asemănătoare cu diferențele între specificările teoretice și rezultatul implementării ale unui proiect, tot din motive asemănătoare: în timp ce modelul propus de ISO era unu teoretic, orientat pe model și pe implementarea acestuia, deja era nevoie de un model funcționabil pentru interconectarea rețelelor de APRANET cu SATNET. Modelul se datează din 1973; era implementat de Vinton Cerf și Bob Kahn, și era încercat pentru prima oară în 1977 când s-a trimis un pachet din San Francisco Bay în Londra urmat să fie trimis la Universitatea din Southern California, călătorind 150.400 kilometri fără să se pierde vreun bit [4].

Fig 3.2: Modelul TCP/IP comparat cu modelul OSI [4] TNR 12 centered !!

După cum se vede pe figura 3.2 în cazul modelului TCP/IP primele două niveluri se fuzionează într-una singură (ca și calculatoarele din zilele curente în care funcționalitatea nivelului legăturilor de date este implementată la nivelul componentei hardware, built-in), iar sarcinile realizate în ultimele trei niveluri superioare sunt preluate de nivelul de aplicații.

Câteva exemple pentru fiecare nivel:

(A)DSL, ISDN și Ethernet la nivelul fizic / legături de date (N1)

IPv4 și IPv6 la nivelul Internet (N2)

TCP, UDP la nivelul de transport (N3)

DNS, FTP, HTTP la nivelul de aplicații (N4)

Pentru a înțelege cum se poate optimiza procesul de trimitere a pachetelor se prezintă structura unui pachet:

Fig. 3.3: Structura unui pachet TCP

Se menționează că elementul de opțiuni este de formatul n x 32 biți = n x 4 octeți și conține informații suplimentare despre datele cerute / deservite. Data reprezintă informație utilă. Mărimea unui pachet se determină prin metoda “Content negotiation” între client și server în funcție de viteza conexiunii. Se variază între 576 și 1500 octeți dar de obicei deja ajunge la 1500 octeți (în cazul conexiunilor rapide > 128Kbps). Dacă din numărul respectiv scad cele 40 de octeți de header și 250-300 octeți pentru header-ul în răspunsul primit se ajunge la 1160 octeți (numărul considerat drept mărimii unei pachet TCP în cazul optimizării de viteză).

Servere WEB și servere DNS

Prin termenul de web-server se poate referi la o componentă hardware și anume la un calculator destinat să deservească cerințele primite prin internet (prin portul fizic LAN RJ45 sau prin alte modalități) și la un software special care se rulează pe un astfel de calculator și deservește cerințele primite pe nivelul de software. Se menționează faptul că pe orice calculator modern se poate instala programe de servere web, totuși pentru funcționalitatea optimă se propune folosirea unui calculator destinat sarcinii respective. Astfel de calculatoarea sunt special construite astfel încât ei pot să răspundă la mai multe cerințe la un moment dat decât calculatoarele obișnuite, având mult mai multe memorii interne și procesoare până la numărul 8.

În continuare, pe parcursul lucrării, curente prin termenul de web-server sau servere web se referă la software-ul destinat și nu la partea de hardware.

Principalul rol al unui server web este de a translata o adresa URI. Asta poate să fie într-un nume de fișier trimițând ulterior fișierul înapoi pe Internet sau într-un nume de program pe care îl rulează și trimite înapoi răspunsul produs de acesta. Cerințele primite de un web server sunt deja prelucrate de servere de DNS (Domain Name System), care dintr-o adresă de internet (a unei pagini prin protocolul http, a unei locații prin protocolul de FTP, adresa de mail, etc.) identifică locația serverului web (adresa IP) și portul pe la care acesta așteaptă conexiunile.

Fig.3.4: distribuția serverelor web; sursă: netcraft.com

De exemplu, când un utilizator apelează la http://www.travelgrove.com:

Se rezolvă host-ul în adresa IP: detectează TLD (top-level-domain) “.com” din care se știe că serverul DNS se află în Statele Unite. Se apelează serverul DNS pentru a returna adresa IP a domeniului travelgrove.com Se primește răspunsul de 216.139.211.239

Se verifică daca s-a specificat un subdomeniu (nu se aplică în cazul respectiv)

Se apelează la adresa IP primit cu URI (numai “/” în acest caz)

Se apelează serverul web Apache, care detectează că fișierul index.php este prezent iar motorul de interpretare PHP rulează

Se deservește request-ul prin index.php se trimite pagina HTML

Se fac request-uri adiționale la serverul dat de IP pentru imagini, scripturi javascript și fișierele CSS (și eventual alt tip de fișiere de pe web).

Pe figura 3.4 s-a prezentat distribuția serverelor web din 1995 până la ziua curentă.

Cele mai importante caracteristici ale unui server web sunt:

Lățimea de bandă (numărul total al octeților care pot fi trimise simultan într-o secundă)

trafic lunar (se aplică la hosting-uri închiriate)

up-time (adică timpul când serverul deservește cererile fără să se prezinte o defectare; se exprimă în procente).

Pentru implementarea aplicațiilor de comprimare s-a folosit serverul web Apache, care după sondajul firmei netcraft s-a găsit cel mai popular din lume. Pentru funcționarea netedă a aplicațiilor două module de Apache trebuie să fie incluse, și anume headers_module și rewrite_module.

Limbajul PHP

Ca mediu de dezvoltare și limbaj de programare pe partea de server s-a folosit limbajul PHP. Denumirea provine din acronimul englez recursiv Personal Home Page Tools Hypertext Preprocessor iar limbajul se consideră o versiune avansată și orientată pe obiectele limbajului de programare PERL (chiar fiind scris de către programatorul PERL, Rasmus Lerdorf). Fiind un produs cu distribuire liberă și un proiect open-source, PHP este cel mai popular limbaj de server-side pentru crearea paginilor HTML dinamice (motorul PHP se rulează pe peste un milion de servere web). Lângă avantajele funcționale (familiaritatea, simplitatea, eficiența, securitatea și flexibilitatea) și faptul că este gratuit, limbajul dispune și o pagină web oficial actualizată zilnic, având una dintre cele mai mari comunități de programatori din lume.

HTML

HTML (HyperText Markup Language) este limbajul predominant utilizat în crearea paginilor web. „Hypertext” se referă la faptul că textul obișnuit este îmbogățit cu caracteristici suplimentare, cum ar fi formatarea textului, adăugarea de imagini, conținutul multimedia sau legături cu alte documente. „Markup” est procesul prin care textului obișnuit îi sunt adăugate caracteristici suplimentare. Fiecare simbol de marcare (markup) este utilizat pentru a specifica browser-ului cum să prezinte informația reprezentată de textul simplu. Fiind un limbaj independent de platformă, relativ structurat și având facilitatea de a realiza legături cu alte documente, HTML se dovedește de a fi un limbaj foarte bun pentru reprezentarea documentelor pe Internet. Documentele HTML sunt documente în format ASCII și prin urmare pot fi create cu orice editor de texte. Au fost dezvoltate convertoare care permit formatarea HTML al documentelor generate (și formatate) cu alte editoare. Evident conversiile nu pot să păstreze decât parțial formatările anterioare deoarece limbajul HTML este încă incomplet. HTML este construit din etichete numite taguri (tags), care sunt delimitate la început de „<” și la final de „>”. HTML-ul poate să descrie, până la un punct, înfățișarea și semantica unui document, dar poate de asemenea să și includă limbaje de scripting care afectează comportamentul browsere-lor web sau ale altor procesoare HTML. Elementele de marcare (markup) sunt construite din următoarele entități: elemente, atribute, tipuri de date și referințe caracter.

Cea mai recentă specificație HTML este cel de 5.0 [5] din 22 ianuarie 2008, dar fiind o specificație atât de nouă încă nu s-a adoptat deloc și cele mai multe browsere urmăresc standardul HTML 4.01. Conținutul în format de HTML poate fi comprimată la fel folosind standardul de zlib, dar acțiunea poate să aibă loc numai on-the-fly, adică în fiecare dată când se solicită fișierul respectiv.

CSS (Cascading Style Sheets)

CSS (Cascading Style Sheets) este un standard pentru formatarea elementelor unui document HTML. Stilurile se pot atașa elementelor HTML prin intermediul unor fișiere externe sau în cadrul documentului, prin elementul <style> și/sau atributul style. Evaluarea acestora are loc în felul următor:

prima dată se aplică stilurile specificate implicit (“inline styles”, prin atributul style)

se aplică stilurile specificate în partea de head al documentului (“internal styles”, prin tagul style)

se aplică regulile din fișiere externe incluse (fișiere cu extensia .css în cele mai multe cazuri, “external style sheets”).

Din procesul de evaluare (“rendering”) se rezumă că asta se poate accelera mult prin eliminarea primelor două etape, folosind numai fișierele externe pentru definirea stilurilor. În acest fel, lângă accelerarea procesului de rendering, se poate separa cât mai bine partea de informație (“data”, HTML în cazul acesta) de la informație legată de apariția acestora (“metadata”, informație despre informație, CSS în cazul respectiv), idea originală a introducerii de Cascading Style Sheets.

Fișierele de stil pot fi utilizate și pentru formatarea elementelor XHTML, XML și SVGL, nu numai pentru formatul HTML. Specificarea curentă de CSS este CSS 2, dar s-a arătat nevoie de specificații pentru generația următoare de CSS 3 [8].

Javascript (JS)

JavaScript este un limbaj de user-side (se rulează pe partea de client) cel mai răspândit (folosit aproape în exclusivitate) pentru adăugea interactivității paginii Web. În scurtul istoric al internetului erau și alte încercări și limbaje de scripting, dar astea nu sunt folosite în practică și nici nu sunt suportate de toate browsere (de exemplu ActiveX Scripting se folosește numai de MicroSoft și numai la anumite pagini, încercând să profite din avantajele platformei windows, accesul la componentele sistemului și compatibilitatea acestora cu obiecte de ActiveX). Limbajul este cunoscut și sub denumirea ECMASCRIPT, fiind standardizată de organizația ECMA (European Computer Manufacturers Association) în anul 1997 în Geneva. Pornind de la specificațiile ECMA ale limbajului JavaScript s-a construit și limbajul ActionScript care se referă la faptul că limbajul se bazează pe acțiuni inițializate de utilizator, realizând astfel conceptul de WEB dinamic (cel mai des folosite în obiecte de Adobe) și Jscript (versiunea de JS implementată de MicroSoft).

JavaScript permite crearea unor interfețe grafice, oferind feedback utilizatorilor în timp ce navighează pe pagină. Cel mai des utilizat exemplu este validarea formularelor înainte de a fi trimise, metoda cu care se poate evita traficul inutil între server și client și se poate economisi capacitatea de calcul al serverului (datele fiind procesate pe partea de utilizator, din JS), chiar dacă validarea trebuie să fie implementată și pe partea de server (din considerații de securitate și pentru utilizatorii care n-au Javascript). Un alt exemplu era tehnica rollover, prin care s-au asigurat acțiuni vizuale ca și răspuns la acțiunea utilizatorului, și anume când se mișcau mouse-ul asupra unor elemente acestea și-au schimbat culoarea, fontul sau alte proprietăți. Tehnica era înlocuită cu selectoare mult mai optime de CSS (hover, link, active) și gruparea imaginilor.

JavaScript oferă posibilitatea de a crea pagini HTML la cerere din mers, în funcție de acțiunea pe care o face utilizatorul. JavaScript controlează browserul pentru a deschide noi ferestre, căsuțe de alertare, plasează mesaje în status bar sau în fereastra browserului. Deoarece JavaScript are un set de caracteristici pentru dată și timp, pot fi generate ceasuri și calendare. De asemenea pot fi gestionate forumuri, setate cookie-urile, crearea paginilor HTML din mers și crearea aplicațiilor bazate pe Web.

Singură incapacitate a limbajului JS este că poate să gestioneze numai datele deja trimise de către server și poate să răspunde la acțiunile utilizatorilor numai în căile predefinite de program; diferența între serverul care procesează și deține toate datele și javascript care răspunde la acțiuni predefinite al utilizatorului este asemănătoare cu diferența între o discuție pe telefon cu o persoană și înregistrarea unui mesaj pe robotul telefonic al persoanei respective. De exemplu cu JavaScript poate verifica dacă o adresă de mail poate să fie o adresă validă (din punct de vedere sintactic și formal), dar nu se poate verifica dacă chiar este o adresa activă și existentă; se poate verifica daca un câmp pentru codul poștal, completat de utilizator conține un număr care poate să fie un cod poștal valid dar nu se poate verifica dacă chiar este. Pentru rezolvarea acestor probleme s-a extins noțiunea de web dinamic, care s-a născut împreună cu limbajul de programare JavaScript, prin adăugarea diferitelor căi de comunicare între server și client, numit AJAX.

Atentie la aliniate si forma !!

DOM, XML, JSON și AJAX

DOM

Prin termenul DOM se înțelege modelul unei pagini web orientate pe obiecte (Document Object Model), care conțin toate elementele paginii într-o structură obiectuală, corespunzătoare paginii. Deci cu alte cuvine structura unei pagini web se poate accesa prin Obiectul de Modelare a Documentului.

Rădăcina arborelui este reprezentată de obiectul Document care reprezintă un document complet formatat. Un analizor XML citește obiectul XML dintr-un fișier sau altă sursă și creează obiectul Document care corespunde documentului XML inițial. Programul client apelează la metode din interfețele asociate, prin aceasta realizând navigarea prin arbore și extragerea de informație utilă. Programele de asemenea pot să manipuleze arborele în memorie, astfel fiind posibilă adăugarea, ștergerea, mutarea sau modificarea nodurilor. Programele pot chiar să creeze documente complet noi în memorie, iar apoi să scrie informația asociată în fișiere XML.

DOM este definit în IDL (Interface Definition Language) ceea ce se traduce prin faptul că este independent de limbaj. Implementări DOM există în majoritatea limbajelor de programare: Java, JavaScript , C#, C++, Python, Perl, PHP, etc.

Fig.3.5: Specificația DOM Nivel 3 al W3C [10]

Prima versiune a DOM-ului denumită DOM nivel 0 nu a fost de fapt o specificație oficială, fiind doar modelul obiect implementat în Netscape Navigator 3 și Internet Explorer 3. Cu cât JavaScript devenea un limbaj din ce în ce mai utilizat și incompatibilitatea dintre modelele obiect implementate în cele două browsere era în creștere, se simțea tot mai acută nevoia existenței unui standard care să definească DOM. Din aceste motive, W3C a lansat W3C DOM Activity și astfel s-a început lucrul la DOM Nivelul 1. În ciuda intervalului de timp foarte scurt pentru implementarea standardului asta s-a dovedit destul de bun și DOM nivel 2 a extins numai modelul prin curățând multe din interfețele DOM 1. Cea mai mare îmbunătățire adusă de DOM 2 a fost suportul pentru namespace (spații de nume). Pe lângă aceasta, DOM 2 a adăugat o mulțime de interfețe suplimentare pentru evenimente, traversarea arborelui, limite, vizualizări și stiluri CSS. DOM 3 era un răspuns la cerințe noi, având un singur avantaj remarcabil față de DOM nivel 2 și anume posibilitatea de a crea un element nou de document.

În DOM, documentele sunt de fapt arbori construiți din diferite tipuri de noduri. Arborele are un singur nod rădăcină și toate nodurile, exceptând acel nod rădăcină au un singur nod părinte. Fiecare nod poate avea mai multe noduri copil. În unele cazuri, lista copiilor poate fi goală, nodul fără copii purtând numele de nod frunză.

Pe figura 3.5 s-a prezentat specificația DOM-ului pe nivel 3 propus de organizația internațională pentru standardizarea web-ului (W3C – World Wide Web Consortium), care include atât modulele pe partea de server cât și modulele pe partea de utilizator – bineînțeles într-un exemplu real nu toate vor fi implementate (de exemplu implementarea modulului MouseEvents sau KeybordEvents pe partea de server nu are nici un sens).

Arborii DOM nu sunt arbori binari, arbori B sau alt tip de arbore special. Din punct de vedere al datelor pe care le înmagazinează, arborii DOM sunt arbori obișnuiți. De aceea, recursivitatea se aplică foarte bine pe arborii DOM. Căutările în adâncime, în lățime, parcurgerile în inordine, postordine și preordine, toate se pot aplica pentru documente DOM.

XML

XML (Extensible Markup Language) este un standard stabilit de W3C pentru marcarea documentelor, care definește o sintaxă generică folosită pentru a marca datele într-o structură simplă, ușor de citită și de manipulată, folosind taguri. XML prezintă informația într-un format standard, care este destul de flexibil pentru a putea fi folosit în diverse domenii, pornind de la site-uri web, schimburi reciproce de date, grafică vectorială, genealogie, listări de toate felurile, serializări de obiecte, RPC (Remote Procedute Call), etc.

După cum arată și numele, când s-a introdus tehnologia AJAX tehnologia XML era destul de populară, și s-a gândit că va fi standardul dominant pentru schimbare de date între browser și server, chiar dacă în realitatea s-a dovedit că formatul JSON e mult mai flexibil și mai mic iar formatul de plain text e mai comod de utilizat. Totuși XML a rămas formatul preferat și cel mai des folosit pentru interschimbarea datelor între servere (pentru cererile SOAP și WSDL), și foarte multe limbaje de descriere (markup) s-au derivat din formatul respectiv.

Vorbind de XML e important să înțelegem că se constituie numai un standard pentru descrierea datelor și nu este un limbaj de programare, o aplicație, un protocol pentru trimiterea datelor sau un tip de pagini web – deci este numai formatul de interschimbare a datelor, dar pentru acest scop fiind ideal.

De asemenea HTML, XML folosește taguri și atribute ca metadate pentru a oferi informații despre datele reprezentate. Deosebirea față de HTML este că tagurile HTML se folosesc pentru a reprezenta modul cum se afișează datele, pe când tagurile XML oferă informații despre datele utile, iar partea de reprezentare a datelor este lăsată în seama altor aplicații. O altă deosebire față de HTML este faptul că XML-ul este un format strict. Adică, o greșeală într-un tag (de exemplu este scris greșit marcajul de încheiere) duce la oprirea analizării documentului și generării unei erori. În schimb, în cazul HTML, browser-ele de obicei trec cu vederea prin anumite greșeli de redactare a documentului și redau documentul făcând presupuneri referitoare la modul cum ar trebui să arate. XML este independent de platformă, suportul este foarte bine consolidat și nu are nevoie de licență. [12] Mulțumit de flexibilitatea și utilizării ușoare va rămâne formatul preferat și în viitorul mai îndelungat al rețelei.

Formatul JSON

Formatul XML reprezintă standardul de interschimbare a datelor, însă nu întotdeauna e cea mai bună soluție. Se spune de multe ori că XML este un format prea „vorbăreț”, adică prea multă metadata este folosită pentru a reprezenta o cantitate mică de date utile.

JSON (“JavaScript Object Notation”) reprezină un format pentru descrierea și interschimbarea datelor folosind JavaScript, înlocuind formatul XML în aplicații dinamice care utilizez tehnologia AJAX. Avantajele formatului în general și față de XML sunt:

Atentie la tip de text !! Forma unitara !!

e mai compact decât formatul XML și ocupă mai spațiul mai puțin

procesul de evaluare (“rendering”) e mult mai rapid în cazul formatului JSON (printr-o singură instrucțiune de eval care returnează obiectul DOM generat în loc de o structură arborescentă XML)

este un format ușor de citit

este un formatul propriu al Javascript-ului

este un format pentru reprezentarea obiectelor structurate

folosind prin AJAX e mai rapid decât XML

Pentru a face o comparație cu XML să considerăm următoarele date reprezentate în ambele formate: nume, nume de utilizator, parola și adresă de mail:

Tab.2.6: exemplu de diferență între formatele XML și JSON

Din acest motiv, JSON a devenit un foarte util instrument de transfer de date între limbaje diferite, cel mai bun exemplu fiind AJAX. Transmiterea de informații asincron între limbajul de pe server și cel de pe partea de client este acum mai facilă ca în cazul folosirii XML.

JSON este construit în principiu din două structuri [11]:

• Obiecte. Obiectele JSON sunt perechi nume – valoare. Obiectele JSON pot fi de diferite tipuri, de la tipuri primitive de date: numere, string, boolean, până la structuri complexe

• O listă ordonată de valori. Acestea sunt vectorii JSON

Tehnologia AJAX

AJAX este acronimul de la Asychronous JavaScript And XML. Nu este o tehnologie în sine, ci este folosit pentru definirea aplicațiilor web ce folosesc un ansamblu de tehnologii, ca și (X)HTML pentru vizualizarea datelor, CSS pentru setarea atributelor vizuale, JavaScript pentru procesarea datelor și obiectul XMLHttpRequest pentru interschimbarea datelor cu server fără reîmprospătarea întregii pagini. La idea de bază a tehnologiei stă comunicația asincronă între serverul și clientul, în afară de comunicația cea obișnuită, când clientul trimite o cerere și primește ca și răspuns întreaga pagină web. Diferența majoră este că serverul (motorul de AJAX) trimite numai anumite informații cerute într-un format predefinit, care urmează să fie prelucrate și vizualizate dacă este cazul pe partea de client prin obiectul XMLHttpRequest. Existau tendințe de web dinamic (cunoscut și sub denumirea de D(ynamic)HTML) și înainte de introducerea obiectului de XMLHttpRequest în 2001, pe baza căruia s-a construit modele funcționale (tehnica frame-ului ascuns, tehnica iframe-ului ascuns, includerea unor fișiere de JS al cărui URI era generat dinamic, specificând și parametrii) care erau modele funcționale și s-a îndeplinit sarcinile, dar în zilele de azi în comparația cu AJAX par ridiculos.

Cu Ajax, aplicațiile web se aseamănă cu aplicațiile desktop, din cauză ca Ajax permite aplicațiilor web să lucreze în spatele scenei, obținând datele de care au nevoie, și afișând datele de care au utilizatorii nevoie. O predicție legat de standarde noi și viitorul internetului în direcția de WEB 3.0 afirmă că în curând va fi imposibil să se facă distincție între aplicațiile desktop și cele care lucrează prin Internet.

Totuși se menționează faptul că în momentul de față Ajax nu poate fi o soluție completă pentru experiențe utilizator bogate. Chiar dacă bibliotecile noi acoperă multe tehnici și metode, sunt câteva lucruri care nu pot fi făcute cu Ajax : Rich media (fiindcă nici cu componentele sale, HTML, CSS și JS nu se poate realiza). Acesta înseamnă că, aplicațiile care vor să ofere caracteristici care includ video și audio, trebuie să apeleze la alte metode pentru le obține, cum ar fi plug-in-ul oferit de Flash. Deocamdată, stategia de aplicație Internet bogată trebuie să cuprindă un amestec dintre Ajax și Flash în defavoarea complexității în testare și integrare.

Se poate afirma că pe partea tehnologică AJAX stă la baza fenomenului de WEB 2.0 și o să se asigură, împreună cu Rich Media support, și platformă pentru WEB 3.

Prezentarea comprimării gzip

Comprimare la nivelul protocolului HTTP

Modul de comprimare gzip și cu modul de comprimare deflate sunt tehnologiile implementate la nivelul protocoalelor al internetului, asigurând o economisire remarcabilă a lățimii de bandă. Pentru a utiliza, bibliotecile de comprimare trebuie să fie disponibile atât pe partea de server cât și pe partea de client, adică ele trebuie să fie instalate atât pe mașină emițător cât și pe mașină receptor, fapt care nu este deloc transparent nici pentru webmasterii nici pentru utilizatorii, pachetele fiind implicit incluse în cele majoritatea serverelor web (Microsoft IIS, Apache HTTP Server, Caucho Resin Professional prin GzipFilter, Sun Java System Web Server, Zeus Web Server, Lighttpd prin mod_compress) și în browsere web curente (Opera 7+, Internet Explorer 5.5+, Firefox 1.0+, Safari, Konqueror, Netscape, etc).

La nivelul protocolului de bază a internetului noțiunea este cunoscută sub denumirea de content-encoding sau HTTP-compression, cunoscut ca și o capabilitate încorporată pentru a utiliza lățimei de bandă într-un mod mult mai eficient, prin comprimarea datelor trimise prin protocolul HTTP. Folosirea comprimării se decide pe baza antetelor (headere):

Fig.4.1: schimbarea de antete între serverul și client (din aplicația Live HTTP Headers)

După cum s-a prezentat mai sus fiecare pachet TCP/IP conține o parte de antet (header), care conține informații despre datele trimise (numit din acest motiv și meta-data).

Clientul trimite lângă altele (tipuri de date acceptate, limbi acceptate a informației, identificatorul browser-ului) modurile acceptate de encodări de către clientul respectiv:

Accept-Encoding: gzip,deflate

Serverul web citește și evaluează headerul respectiv, verifică dacă există vreun mod de comprimare disponibil care e suportat de client și decide dacă trebuie să folosit sau nu (în funcție de setări). În cazul afirmativ se trimite răspunsul comprimat de date într-un format suportat și se specifică formatul respectiv printr-un antet de răspuns:

Content-Encoding: gzip

Pentru a comunica serverelor proxy că datele primite sunt comprimate se trimite un header special “Vary”:

Vary: Accept-Encoding

Prezentarea metodei gzip

Diferențe între metodele gzip și deflate

Tehnologia gzip (GNU zip) a apărut ca și o alternativă gratis pentru encodare LZW (protejat de licențe) pe platformele UNIX, ca și o parte a proiectului GNU.

Diferențe între cele două metode de comprimare sunt foarte minore, folosind aproape același format pentru fișierele comprimate, combinând metoda LZ77 și encodarea Huffman. De fapt encodarea gzip se bazează pe metoda deflate (care folosește biblioteca zlib), deci când se împachetează un fișier folosind gzip se apelează metoda deflate și se mai adaugă anumite date în antetul fișierului (ca și CRC și alte metode de verificări).

Un fișier comprimat cu gzip conține:

un antet de 10 octeți (numărul magic, numărul de versiune și timpul creării)

alte antete opționale (de exemplu numele originală)

corpul fișierului care conține fișierul propriu-zis encodat în formatul deflate

un footer de 8 octeți, care conține polinomul CRC și mărimea fișierului original, necomprimat

Alegerea denumirii de "deflate" nu era prea adecvat, fiindcă se poate confunda ușor cu formatul simplu comprimat (“raw deflate compressed data format” [13]). S-a raportat multe probleme din cauza denumirii cu servere web și bowsere, acestea fiind incapabil să se diferențieze corect formatele, mai ales în cazul serverelor web de la Microsoft. Probleme raportrate s-a condus la la folosirea compresării gzip față de deflate pentru protocolul HTTP 1.0, chiar dacă al doilea s-a dovedit că în cazuri foarte particulare poate să fie chiar mai rapid cu 40%, dar și în general este mai rapid cu 10%:

Se menționează faptul că în lucrearea curentă nu s-a folosit comprimare în timp real, deci nu se pune problema selectării a metodei deloc, fiind indiferent dacă rularea ține 800 de milisecunde sau 1200 ms.

Metoda de comprimare (deflate)

Algoritmul deflate folosită de gzip ( de asemenea și de zip și zlib) este o variație al metodei LZ77 (Lempel-Ziv 1977), combinată cu metoda Huffman. Acesta găsește șirurile de caractere duplicate în datele introduse. Al doilea apariție a șirului de caractere este înlocuită cu un pointer la șirul precedent sub forma unor perechi de distanță și lungime. Distanțele sunt limitate la 32K octeți iar lungimile la 258 octeți. Dacă șirul nu apare nicăieri în ultimele 32 Kocteți, atunci este emisă ca un șir de octeți succesivi (“literal” în continuare. Bineînțeles șiruri de caractere nu refer la șiruri de caractere ASCII propriu-zise, ci reprezintă numai o succesiune de octeți aleasă arbitrar).

Literalii sau lungimile din pereche cu care sunt înlocuite (în cazul dacă era găsite) sunt compresate cu un arbore Huffman iar distanțele cu un alt arbore, tot de tipul Huffman.

Definiția unei arbore binară după afirmația lui Gallager din 1978 este:

"Un arbore binar cu p frunze care au greutăți nenegative este arbore Huffman dacă și

numai dacă următoarele afirmații sunt adevărate:

cele p frunze au greutățile nenegative w1, w2, …, wp și greutatea fiecărui nod intern este egală cu suma greutăților celor doi fii;

nodurilor interne li se pot atașa numere de ordine în ordinea crescătoare a greutăților, astfel încât nodurile cu numerele 2·j-1 și 2·j să fie frați pentru 1≤j≤p – 1 și părintele lor comun să aibă un număr de ordine mai mare[14].

Arborele sunt stocate într-o formă compactă la începutul fiecărei bloc. Blocurile pot avea orice mărime, limitările fiind impuse numai de memoria disponibilă a sistemului curent. Un bloc este terminat când modul deflate stabilește că ar fi folositor începerea unui bloc nou cu arbore noi, acest proces fiind similar cu funcționalitatea metodei LZW (Lempel-Ziv-Welch).

Șirurile duplicate sunt găsite folosind o tabelă hash. Toate șirurile de lungimea de 3 sunt introduse in tabela hash, după care indexul hash este calculată pentru următoarele 3 octeți. Dacă poziția din hash pentru acest index nu este gol, toate șirurile din lanț sunt comparate cu șirul curent introdus și cea mai lungă conformitate este selectată.

Căutarea în lanțurile hash se face începând cu cele mai recente șiruri favorizând distanțele mici și astfel profitând din codificarea Huffman. Lanțurile hash (“hash chain [15]”) sunt construite folosind liste simplu înlănțuite. Nimic nu este eliminat din lanțul hash, algoritmul simplu debarasează rezultatele prea vechi.

Pentru a evita situația celui mai rău caz, lanțuri foarte lungi sunt trunchiate într-un mod arbitrar la o lungime dată, determinată de o opțiune specificată la apelarea metodei (parametrul “run-time” level al deflateInit). Astfel deflate() nu găsește cel mai lung rezultat dar în general găsește un rezultat destul de lung, care reprezintă un compromis acceptabil între rata de comprimare și viteza.

Deflate() amână selectarea rezultatelor cu o evaluare leneșă (“lazy evaluation” [16]). După ce un rezultat de lungimea N a fost găsit, deflate() caută un rezultat mai lung la următorul octet introdus. Dacă un rezultat mai lung este găsit, rezultatul precedent este trunchiată la lungimea de unu (astfel elaborează un singur octet literal) iar procesul de evaluare leneșă începe din nou. Altfel rezultatul original e păstrat și următoarea căutare se încearcă numai cu N pași mai târziu.

Evaluarea leneșă a rezultatelor este de asemenea subiectul unui parametru de timpul funcționării. Dacă rezultatul curent este destul de lung, deflate() renunță de căutarea pentru un rezultat mai lung, astfel accelerând întregul proces. Dacă rata de compresare este mai importantă decât timpul executării, modulul deflate() execută o căutare secundară completă, chiar dacă căutarea primară s-a întors un rezultat destul de lung.

Evaluarea leneșă a rezultatelor nu este efectuată pentru modurile cea mai rapide de compresare (parametrul “level” de valori de la 1 la 3). Pentru aceste moduri rapide (la care viteza de compresare e mai important decât rata de comprimare) șiruri noi sunt introduse în tabela hash numai dacă nu s-a găsit nici un rezultat sau dacă rezultatul nu este destul de lung. Acesta degradează rata compresiunii dar economisește timp pentru că sunt mai puține inserări și mai puține căutări.

Metoda de decomprimare (inflate)

Întrebarea cea mai majoră este, cu un arbore Hoffman dat, cum să se realizeze o decodare cât mai rapidă. Cea mai importantă realizare este că codurile mai scurte sunt mult mai comune decât codurile mai lungi deci trebuie să fim atenți ca decodarea codurilor scurte să fie mai repede și lasă codurile lungi să se decodeze mai lent.

Inflate() creează o tabelă de nivelul întâi ce acoperă câteva număr de biți de intrare, în total mai puține decât lungimea celui mai lung cod. Funcția primește acele biți din flux și le caută în tabela. Pe baza tabelei se determină dacă codul următor coincide cu biților primite sau este mai mic, arătând și valoarea din tabela. Altfel rezultatul căutării în tabela o să arată către tabelul de la nivelul următor, pentru care inflate() continuă căutarea cu mai mulți biți, încercând să se decodeze un cod mai lung.

Trebuie să se găsească compromisul cel mai bun între numărul al biților pentru a face prima căutare și între timpul necesar pentru decodare și construirea o tabelă, acestea fiind invers proporționale. În cazul ideal, când construirea tabelei n-ar lua timp și am avea o memorie infinită ar fi numai o singură tabelă necesară de primul nivel pentru a acoperi toate codurile, chiar și cel mai lung. Dar construirea unei astfel de tabele ține mult mai mult timp, din cauza șirurilor lungi de biți, fiindcă codurile scurte sunt replicate de multe ori. S-a găsit soluția ideală prin folosirea lungimi variabile în prima tabelă, metoda inflate() fiind optimizată pe viteză maximă.

Inflate() trimite arbore noi relativ des, deci eventual el este reglat pe o tabelă mai mică de nivelul întâi decât o aplicație care are un singur arbore pentru toate datele. Pentru inflate, care are 286 coduri posibile pentru arborele literal/de lungime, mărimea primei tabele este de nouă biți, precum și arborele de distanță au 30 de valori posibile iar mărimea primei tabele este cea de șase biți. Se notează faptul că pentru fiecare dintre aceste cazuri, în sfârșit tabela este cu un bit mai lung decât lungimea medie de cod, de exemplu lungimea unui cod cât de cât omogen ar fi un pic mai mult decât 8 biți pentru 286 simboluri și un pic mai puțin decât 5 biți pentru 30 de simboluri.

În fine se ajunge la concluzia că tabela de la primul nivel este mai mult o tabela de căutare (lookup table) pentru primile 9 biți a unui simbol Huffman decât o arbore Huffman. Simbolul poate să fie chiar de la un singur bit până la 15 biți. Dacă, în mod special, un simbol este mai scurt de nouă biți, traducerea acestui simbol este duplicată în toate intrările care încep cu bițile simbolului respectiv. De exemplu, decă simbolul respectiv e de 4 biți, atunci este duplicată de 32 ori într-o tabelă de nouă biți (fiindcă rămân 9-4=5 poziții libere, iar 2 la puterea 5 e 32). Dacă lungimea simbolului este nouă biți apare o singură dată în tabelă. Dacă simbolul este mai lung decât nouă biți, atunci acea intrare din tabelă va indica o altă intrare dintr-o altă tabelă similară pentru biții rămași. Și în tabela secundară po apar intrări duplicate. Ideea este că de cele mai multe ori simbolul va fi destul de scurt și va fi numai o singură căutare tabelă. (În primul rând asta este ideea de bază a compresiunii datelor.) Pentru simbolurile lungi, mai puțin frecvente vor avea loc două căutări. Pentru o metodă de compresiune cu simboluri foarte lungi putem avea atâtea (de multe) nivele de căutări cât este eficiente, dar pentru inflate ajunge două niveluri.

Deci o intrare de tabelă ori indică o altă tabelă (în acest caz nouă biți în exemplul de mai sus sunt încorporate), ori conține traducerea pentru simbolul și numărul de biți. Apoi se ia din nou următorul bit neîncorporat.

Se pune întrebarea că de ce nu se folosește o singură tabelă, de oricât de multe de biți ar fi simbolul cel mai lung. Cauza este că dacă ar fi așa, am petrece mai mult timp cu completare de intrări de simbol duplicate decât cu decodarea totală, cel puțin pentru ieșirea deflate-ului care generează arbore noi pentru fiecare câteva zeci de Kocteți. Putem imagina că completarea uni tabele de intrare de 2^15 (32K) pentru un cod de 15 biți ar ține prea mult și dacă decodăm câțiva mii de simboluri. Cealaltă extremitate ar fi crearea unei tabele noi pentru fiecare bit din cod. De fapt în esență asta ar fi un arbore Huffman. Dar în acest caz, am petrece prea mult timp traversând arborele în timpul decodării chiar și în cazul simbolurilor scurte.

Deci numărul biților la prima tabelă de căutare este compromisul timpului completării tabelei versus timpul petrecut căutând la nivelul al doilea și – și mai sus – a tabelei.

Pentru funcția inflate sensul unui singur simbol e de multe ori mai mult decât o singură literă. Poate să fie un octet („literal”) sau poate fi ori o lungime ori o distanță care indică o valoare de bază și un număr de biți depărtate după codul adăugată la valoarea de bază. Există și un caz special când simbolul semnifică codul special “end-of-block” (sfârșitul blocului).

Importanța comprimării

Chiar în zilele conexiunilor T1 de 12 MBPS importanța optimizării de viteză și astfel eliberarea lățimii de bandă este indiscutabilă. Se zice că orice care poate să reducă timpul de încărcare a unei pagini merită de făcut.

Metoda de comprimare reduce mărimea paginii mediu cu 50%, ceea ce înseamnă că paginile se încarcă de două ori mai rapid decât mai înainte, fără de a schimba orice în structura paginii sau informații trimite, schimbând numai modul, în care serverul și clientul schimbă datele:

Fig.4.3: Ratele de comprimare cu metoda gzip, sursă: sendung.de [18]

Avantajele comprimării sunt numeroase:

reduce viteza de încărcare a unei pagini, realizând astfel o optimizare de viteză

reduce traficul și cantitatea de date trimise de la server, eliberând astfel lățimii de bandă a serverului

micșorează traficul utilizatorului (mai important la conexiuni limitate)

Prezentarea metodelor existente de comprimare

Comprimare la nivelul serverului web

Există o gamă largă de metodele încorporate în servere web (metodele built-in) sau accesibile prin extensii (plug-in). Servere de web care suportă comprimare peste protocolul HTTP în conform cu specificații oficiale [19] sunt:

Microsoft IIS (încorporat sau prin module externe)

Apache HTTP Server (prin module mod_deflate și mod_gzip)

Caucho Resin Professional (prin GzipFilter)

Sun Java System Web Server

Zeus Web Server

Lighttpd (prin mod_compress)

Nginx

RaidenHTTPD

Serenity Server

Serverul web cel mai răspândit Apache are http-compression încorporat de la versiunea 2.0 în sus. Fiindcă se folosește metode gzip și deflate destul de simple flexibilitatea este redusă.

În cazul al doilea serverului web cel mai popular, Microsoft Internet Information Server (IIS) funcționalitatea respectivă a apărut încorporat cu versiunea 4.0 (Windows NT Server), dar s-a dovedit destul de probletic și s-a găsit multe greșeli, din care multe nu s-a corectat nici la versiunea 5.0 (Windows 2000 Server), Windows 2003 Server fiind primul server web de la Microsoft cu suport global de http-compression. Lângă funcțiile încorporate sunt accesibile multe biblioteci încărcabile, ca și IIS Accelerator ISAPI filter module de la firmă Vigos AG.

Chiar dacă este metoda cea mai simplă și ușor configurabilă, comprimarea la nivelul serverului web este și cea mai vulnerabilă având dezavantajele sale. Problema cea mai mare apare la inundația sistemului, compresarea fiind făcută în timp real. Al doilea problemă apare tot din cauza că acțiunea are loc în timpul trimiterii a datelor, la fiecare cerere primită, și anume la stocarea versiunilor temporale pe partea de client a fișierelor comprimate (caching). Fișierele fiind comprimate în timp real nu se trimite antetele în mod corect care controlează stocarea versiunilor temporale pe partea de utilizator (caching).

Lângă problemele menționate metoda nu reprezintă nici un avantaj pentru browserii care nu suportă comprimarea datelor folosind gzip și nu realizează optimizarea numărului cererilor (“request optimization” [21]).

Aplicații de comprimare în timp real

Sunt accesibile și aplicații de timp real scris în limbaje de programare care se rulează pe servere web (ASP, JSP, PHP, Perl, Ruby on rails și altele) pentru a realiza o funcționalitate mai complexă și pentu webmasterii care n-au acces la setări (Yahoo! Web Hosting de exemplu). În continuare se prezintă o aplicație scris în PHP de către un inginer al firmei Yahoo (Anexa A).

Metoda are mai multe puncte slabe, și anume:

pe baza parametrului specificat se generează directoare întregi

se face verificarea în fiecare dată când fișierul este solicitat

nu se realizează optimizarea request-urilor numai în parte

se introduce câte un request intern pe server pentru deservirea fiecărui fișier împachetat

codul prezintă și probleme de vulnerabilitate și securitate; după ce un hacker reușește să se împacheteze un fișier php sau apache pătrunde mult mai ușor pe serverul respectiv,

totuși dezavantajul cel mai mare este timpul de procesare introdusă, care este echivalent cu timpul de citirii unui fișier din PHP, la care se mai adaugă și timpul de generare a fișierelor în cazul când astea nu era deja generate.

Pentru implementarea funcționalității de comprimare s-a folosit biblioteca Zlib din PHP.

YUI compressor și alte aplicații

YUI (Yahoo! User Interface Library) este o bibliotecă încărcabilă de Javascript, publicat de Yahoo, care servește la mărirea interactivității a paginilor, având facilități ca motorul de Ajax pe partea de user, acces la DOM, gestionarea evenimentelor („event management”), crearea animațiilor și altele.

Diferit de YUI, YUI compressor este o bibliotecă scris în Java bazat pe Rheno (javascript implementat în context de Java) folosit pentru minimizarea fișierelor Javascript și CSS. Este cunoscut ca și toolul cel mai eficient, care minimizează fișierele înainte de comprimare, dar fiind scris în Java se consideră destul de greu de folosit.

Mai amintim alte programe ca și JSMIN de la Douglas Crackford și JS-packer de la Dean Edwards dar în afară de cele menționate se poate găsi foarte multe aplicații de minimizare a fișierelor JS și CSS, remarcând faptul că programele respective nu funcționează automat și nu sunt aplicații sine-stătătoare (stand-alone) numai aplicații online cu care se poate optimiza anumite fișiere dar numai cu control uman și la inițiativa programatorului. Ele nu pot fi folosite pentru deservirea automată tuturor fișierelor JS și CSS. Asemănător cu aplicații menționate mai sus nici YUI Compressor nu realizează gruparea cererilor sub nici o formă; reducerea numărului de cereri (“request minimization”) se realizează numai în mod indirect prin reducerea mărimii fișierelor.

Diferențe față de metode prezentate

Minimizarea cererilor (“request minimization”)

Pentru a înțelege în profunzime diferențele cele mai importante față de metodele prezentate la capitolul 3, se apelează la modelul TCP/IP prezentat la subcapitolul 2.1.2 și la figura 2.3. Să presupunem că avem un fișier CSS de 5Kocteți care urmează să fie trimis și pachetele TCP/IP de 1.500 octeți. Conform structura pachetului TCP/IP prezentat la 2.1.2, din 1500 octeți 1160 reprezintă informația utilă (“payload”) și 300 octeți reprezintă antetul („header”). Conform acestuia fișierul este trimis în 5 pachete:

4 pachete cu informație utilă de 1160 octeți

un pachet de 480 octeți de informație utilă

Astfel după combinarea pachetelor mărimea fișierului crește la 6620 octeți (6.46 Kocteți). Se observă că în ultimul pachet se trimite numai 480 de octeți, dar trimiterea unui pachet plin practic ține tot atâta timp, fiindcă fixarea conexiunii și multiplexarea pachetelor ia mai mult timp și nu trimiterea informației propriu-zisă.

Se presupune că se trimite încă un fișier CSS de 7.2 Kocteți, care se trimite în 7 pachete (6 pachete pline și una cu 412 octeți), fiindcă:

7.2 * 1024 = 7.372 octeți și 7372 / 1160 = 6.35 adică 7 pachete.

Se observă că ultimele două pachete trunchiate de la fiecare fișier ar încăpea într-unul singur:

480 + 412 = 892 octeți < 1160 octeți,

Deci numai prin copierea toate fișierele de CSS și JS se obține o optimizare de request-uri, reducând astfel numărul de conexiuni între server și client și numărul de pachetelor trimise, faptul care devine deosebit de important când se aplică limitări asupra numărului de conexiuni la un moment dat între un server și client. Limitarea respectivă se aplică di mai multe cauze:

pentru a evita blocarea browser-ului pe partea de client

pentru a evita atacurile de tip DDoS (Distributed Denial of Service), când un hacker încearcă să se blocheze serverul inundând cu prea multe cereri (anumită servere web refuză conexiunea de la un singur client daca această încearcă să stabilește un număr mai mare de conexiuni).

De exemplu în cazul browserului cel mai popular Firefox 3.0 de la Mozilla numărul maxim admis de conexiuni este 8 (setarea network.http.max-connections-per-server), iar în cazul browser-elor mai vechi limita maximă poate să fie 5 sau chiar 2, ceea ce impune faptul că în cele mai multe cazuri browsere trebuie să aștepte cu inițializarea unei conexiuni noi până când se închide o conexiune care se află în curs de deservire (toate pachetele sunt trimise).

Acest lucru extinde timpul de încărcare a paginii în mod significant, ceea ce indică importanța minimizării de cereri. Aplicații curente prezentate realizează o optimizare de acest tip și în cazul când aplicația clientului nu suportă modalitatea de comprimare gzip, în cazul asta fiind deservit un fișier minimizat conținând toate fișierele cerute.

Minimizarea datelor

Aplicațiile curente realizează și minimizarea datelor atât în cazul fișierelor css cât și la js. La fișiere CSS minimizarea se face folosind un set de expresii regulate, cu care se elimină spații albe, comentariile și expresii care mai pot fi optimizate (' {', '} ', ';}'), iar la aplicația pentru fișierele de javascript s-a folosit o implementarea în PHP orientate pe obiecte al aplicației packer (de la Dean Edwards) [25]. Fiind implementat ca și un pachet extern (plug-in) asta în urmă se poate înlocui cu orice alte aplicație de minimizare. Pentru a asigura funcționalitatea intactă și corectă s-a folosit numai minimizarea sursei fără redenumirea variabilelor și a parametrilor.

După cum se vede din tabelul 5.1, aplicațiile curente realizează atât minimizarea datelor cât și împachetarea acestora, îmbunătățind astfel rata de comprimare până la 70-80%. Deci aplicațiile realizează o optimizare de viteză și în cazul când aplicația pe partea clientului nu suportă modul de comprimare gzip.

Menținerea datelor într-un format ușor de citit

În opoziția cu aplicațiile off-line care fac minimizare pe baza unei encodări 64, prin redenumirea variabilelor sau prin eliminarea spațiilor albe aplicații curente având un fișier de ieșire diferă de cea de intrare are avantajul că menține fișierele și originale pentru editarea ulterioară. Deci de fapt există două versiuni al fișierelor folosite, cea originală cu care pot lucra webmasterii și cea grupată și comprimată, care se trimite la utilizatorii, sincronizarea între acestea fiind făcut de aplicațiile respective.

Deci la partea de utilizator ceea ce apare din fișierele JS este următoarea:

/*js-compress-description:jquery 1.3.2, normal, commented*/

/*white-spaces:1*/

(function(){var window=this,undefined,_jQuery=window.jQuery,_$=window.$,jQuery=window.jQuery=window.$=function(selector,context){return new………………………………………

Toate fișiere fiind grupate într-o singură linie în afară de comentarii interne folosite de tool, iar webmasterul sau programatorul poate să acceseze și să editeze fișierele originale fără probleme, asigurând după modificările făcute că fișierele împachetate să fie reîmprospătate.

Una dintre aspectele cele mai importante este că comentarii în fișierele originale rămân intacte, astfel lăsând programatorilor și contributoriilor să se insereze sugestii, explicații și exemple ca și comentarii. În mare majoritatea a cazurilor scripturile la care se lucrează mai multe persoane sunt supraprogramate având aceași funcționalitate implementate de mai multe ori diferite, fapt care se explică prin lipsa comunicației și înțelegerea a codului.

Reîmprospătarea fișierelor ar putea fi rezolvat destul de ușor dar autorul lucrării curente s-a gândit că pentru a evita problema responsabilității care apar tot timpul în lucrarea în echipă și folosind programe care se execută automat, controlul trebuie acordat cât mai mult programatorului / administratorului paginii. Pe de altă parte, restricția reîmprospătării manuale garantează că modificările făcute vor fi testate de către un individ.

Din experiența se știe faptul că de obicei timpul de dezvoltare, implementare și testare a unui modul extern de front-end (care are un impact pe partea de utilizator – fișiere CSS și JavaScript) reprezintă numai 2-3% din durata totală de viață al acestuia (maxim 5-10% în cazul proiectelor actualizate foarte des). Având în vedere rata de mai sus actualizarea manuală se consideră acceptabilă, accentul fiind pus mai mult pe experiența bună și mulțumirea a utilizatorilor și pe controlarea erorilor decât pe ușurarea muncii programatorului.

Pe tabela 5.1 s-a prezentat diferențele între modalitățile de comprimare prezentate:

Tab. 5.1: tabela comparativă a aplicațiilor existente cu aplicațiile curente

Min. cererilor peste mai multe fișiere: se referă la faptul dacă metoda este aplicată pe mai multe fișiere sau pe una singură. Tabela de mai sus arată clar că se poate obține o rată de comprimare mult mai buna aplicând metoda în același timp pe mai multe fișiere, fapt transparent și din funcționalitatea metodei deflate: pentru același șiruri de caractere se folosește același simbol, care este salvat în tabela corespunzătoare numai o singură dată.

Necesită procesarea ulterioară: se aplică numai în cazul encodării de bază de 64 folosit de packer scris de Dean Edwards. Utilizarea nu este preferată fiindcă rezultă într-o rată mai slabă decât în cazul comprimării cu gzip și adaugă și un timp adițional de procesare, consumând resursele sistemului local (pe partea utilizatorului).

Minimizarea datelor: indică aplicarea unui algoritm de comprimarea datelor prin eliminarea unor caractere, șiruri de caractere sau părți întregi, făcând o comprimare cu pierderi. Astfel de minimizări constă în:

eliminarea comentariilor (CSS, JS)

eliminarea spațiilor albe, care nu fac parte din codul propriu-zis numai ajută la înțelegerea codului, menținând acestea ușor de citit. La această minimizare se elimină caracterele "\r\n", "\r", "\n", "\t" și spații.

minimizarea selectoarelor (numai în cazul fișierelor CSS) prin înlocuirea anumitelor șiruri de caractere, de exemplu:

“ {” “{”

„ }” „}”

„;}” „}”

înlocuirea numelor variabilelor cu nume mai scurte (se aplică numai în cazul fișierelor Javascipt). Metoda de mai sus poate reprezenta vulnerabilități funcționale și astfel poate să ducă la defectări critice, fiindcă poate schimba accesibilitatea codului din exteriorul acestora.

encodare din javascript în bază de 64 (se aplică numai pentru fișierele Javascript). Nici această metodă nu este recomandată fiindcă introduce un timp de evaluare adițională folosind resursele clientului (care poate să ducă la blocarea completă a calculatorului) și rezultă în ratele de comprimare mai slabe decât metoda gzip sau deflate.

În cazul aplicațiilor curente minimizarea datelor s-a folosit pentru preprocesarea datelor înainte de a fi comprimate, dar se poate folosi ca și o tehnologie de optimizare de sine- stătătoare.

Comprimare cu gzip: denota dacă s-a folosit una dintre metodele de comprimare suportată pe web (gzip sau deflate).

!! Atentie la forma !!

Prezentarea si implementarea aplicației

Instalarea aplicației

Aplicația este alcătuită din două părti distincte și anume un compresor de fișiere CSS și una de fișiere JS. cele doua module sunt destul de similare, sinura diferență fiind doar in faptul că la comprimarea fișierelor CSS nu se verifică validitatea fișierului generat și la fișierele JS după generarea fișierului de cache se aplica peste codul JavaScript incă un filtru care elimină comentariile si spațiile albe.

Pe figura 6.1 s-a prezentat idea de bază al funcționării a aplicațiilor:

Fig. 6.1: diagrama al aplicațiilor de comprimare

În diagrama 6.1 este prezentată funcționarea aplicației. Ca primul pas se verifica dacă s-au specificat fișiere ce urmează să fie înpachetate a cărui nume încă nu a fost adăugat in fișierul cache sau nu. În cazul in care nu mai există fișiere care să urmeze să fie procesate, se citește conținutul fiecărui fișier și se concatenează intr-un singur șir de caractere stocată în memorie. Șirul de caractere creat se va comprima în format gzip și se va salva ambele formate (cel comprimat și cel necomprimat) în două fișiere separate.

În cazul în care mai există fișiere care urmează să fie procesate penru crearea numelui de fișier cache, se verifică fișierul ce urmează dacă este valid sau nu (din punct de vedere al tipului, conținutului si numelui său). Dacă nu este valid, se raportează eroarea și se sare la fișierul următor.În cazul în care fișierul este valid, se concatenează numele fișierului curent (desigur, după ce s-au aplicat unele filtre pe numele directoarelor și fișierului) la numele pachetului comprimat. Astfel se va opține un nume de pachet unic pentru un anumit set de fișiere intr-o anumită ordine.

Deci utilizatorul specifică cu ajutorul interfeței fișierele care urmează să fie împachetate. Fișierele deja trebuie să fie disponibile pe server, fiind vorbă de o aplicație pentru optimizarea deservirii a fișierelor existente. După ce utilizatorul a introdus o scurtă descriere pentru bath-ul respectiv, căile de fișiere urmează să fie trimise către server printr-un request Ajax, folosind o interfața web 2.0 (figura 6.2).

Fig. 6.2: autentificare la aplicația de comprimare a fișierelor JS pe interfață web 2.0

Instalarea manuala

De fapt prin instalare manuală se înțelege numai copierea directoarelor necesare undeva pe serverul web (directorul /compressor/), crearea directoarelor pentru fișierele de CSS și JS comprimate (în unele cazuri ele trebuie să fie create cu toate drepturile activate) și copierea fișierelor de .htaccess (foarte important, fiindcă header-ele și tratarea excepțiilor se face prin .htaccess). După ce s-a făcut toate acțiunile necesare se setează constantele corespunzător mediului de lucru după care se poate rula aplicația (de la un browser web). După ce s-a făcut autentificarea (figura 7.2) conform cu numele de utilizator și parola setat în fișierul de configurare Tool-ul trebuie să arate ca și pe figura 7.3 (eventual fără fișierele comprimate).

Setarea corectă a drepturilor de acces a directoarelor unde se vor stoca fișierele cache este foarte important, deoarece la seatrea greșită a permisiunilor, aplicația nu va putea crea fișiere noi in directoarele de cache. Astfel o practica buna la copierea fișierelor este ca să se facă copierea cu același utilizator sub care va rula aplicația dupa instalare. Pe serverele pe bază de cPanel acest lucru nici nu se poate evita, fiindcă prin FTP ne conectăm folosind același utiizator ca și cel folosit de apache pentru rularea scripturilor PHP.

Față de serverele pe bază de cPanel, serverele care folosesc Plesk rulează scripturile PHP cu utilizator diferit față de cel folosit la conectarea prin FTP, astfel trebuie să găsim o altă soluție pentru a crea fișierele sub utilizatorul corect, cum ar fi de exemplu folosirea script-ului de instalare automată.

Instalarea automată

O posibilitate mult mai simplă a setării configurațiilor este de a rula scriptul de instalare automatizată, care crează toate fișierele necesare pentru rularea acurată a aplicației.

Pentru instalarea automată a scriptului trebuie copiat pe server doar un singur fișier PHP intr-un director gol, după ce trebuie sa se ruleze fișierul php. E de notat faptul că fisierul PHP trebuie sa aiba drept de scriere si citire in directorul unde se află in timpul rulării, pentru a putea crea fișierele si directoarele adiționale. În cazul în care se alege instalarea automată, utilizatorul trebuie doar să introducă numele de utilizator și parola cănd este rugat de script-ul de instalare (figura 7.3)

In cazul in care fișierul PHP nu are drept de scriere in directorul respectiv, se va genera mesajul de eroare ca atare si va fi afisat structura sistemului de fisier dorita din directorul de instalare si va fi listat o legătură la fiecare fișier care urmează să fie copiat pe server de utilizator.

Daca utilizatorul are posibilitatea de a schimba permisiunile directorului, poate face si aceasta, dupa ce poate rula din nou scriptul de instalare prin apasarea butonului „Retry instalation”.

Configurare ulterioară

Fiindcă aplicațiile operează cu fișierele sistemului necesită autentificare:

Toate setările locale se poate regla foarte simplu după instalare printr-un fișier de configurare (compressor/config.inc.php). Constantele fișierului se folosesc pentru ajustarea aplicației în mediu de lucru:

LOGINUSERNAME: reprezintă nume de utilizator. Dacă mediu de lucru dispune deja de o funcționalitate de autentificare bazată pe sesiuni (fiind metoda cea mai răspândită) se paote seta același date de autentificare

LOGINPASSWORDMD5: parolă criptată folosind encodarea md5.

JSDIRPATH: calea relativă de la directorul curent, unde s-a instalat aplicația, către directorul în care se dorește să fie salvate fișierele JS comprimate. Poate să fie definit și prin adresarea absolută.

JSHTTPABSDIRPATH: calea absolută către directorul care conține fișierele JS comprimate de la rădăcina domeniului DAR de partea de utilizator

CSSDIRPATH: calea relativă de la directorul curent, unde s-a instalat aplicația, către directorul în care se dorește să fie salvate fișierele CSS comprimate.

CSSHTTPABSDIRPATH: calea absolută către directorul care conține fișierele CSS comprimate de la rădăcina domeniului DAR de partea de utilizator.

PATHTOROOT: calea către rădăcina domeniului, relativ sau absolut

DIRSEPARATOR: simbolul cu care se înlocuiește caracterul “/” din calea fișierelor.

Prima rulare a aplicației trebuie să arată în felul următor:

Fig. 6.3.a: Interfața de administrare a fișierelor comprimate JS

Fig. 6.3.a: Interfața de administrare a fișierelor comprimate CSS

Structura programului de instalare

Programul de instalare este alcătuit dintr-un singur fișier PHP, care va crea toate fișierele folosite de aplicație. Datorită acestui fapt mărimea lui este relativ mare si greu de citit. Fiecare fișier este stocata intr-o constantă, comprimat cu gzip si encodat in base64. Metoda acesta de stocare permite o economisire a spațiului de până la 50% si permite stocarea formatelor binare in format de șir de caractere în interiorul fișierului PHP.

Pentru crearea script-ului de instalare s-a folosit o altă aplicație scrisă în limbajul PHP special pentru acest scop, care va fi discutat mai târziu.

La deschiderea programului de instalare utilizatorul este întrebat de numele de utilizator si parola implicită (figura 6.4). Parola este stocată in fișierul de configurare cu encodare MD5, astfel nu se poate recupera parola. Daca parola se uita, singura soluție de a accesa contul este de a intra in fișierul de configurație si a introduce parola noua encodat MD5.

Pentru a genera hash-ul de MD5 dintr-o parolă se poate folosi mai multe pagini web:

http://www.miraclesalad.com/webtools/md5.php

http://www.adamek.biz/md5-generator.php .

Fig. 6.4: Instalarea aplicației

Dupa ce utilizatorul a introdus numele de utilizator si parola, și a apăsat butonul „Install”, script-ul va incerca să creeze fișierele si directoarele pentru buna functionare. Daca careva dintre fișiere nu poate fi creat din orice motiv (in general lipsa de permisiune), se va afisa intreaga structură de directoare necesară si link-ul spre fișierul care nu s-a putut crea (figura 6.5). Linkul generat de fapt arata spre acelasi fișier de instalare cu un singur parametru (in cazul fișierului de configuratie, legatura contine si numele de utilizator si parola) care marchează fișierul ce urmează sa fie descărcat. Aplicația automat va trimite header-ele neceare pentru a seta corect numele fisierului si care marcheaza ca fișierul urmeaza să fie descărcat (si nu deschis in browser), astfel utilizatorul trebuie să se ocupe doar de crearea corectă a structurii de directoare si de incărcarea fișierelor descărcate la locul potrivit.

Este important de menționat faptul că in cele mai multe situații este mult mai rapid si mai sigur să se acorde privilegiile corecte pentru directorul unde se face instalarea. Daca utilizatorul sub care rulează apache este acelasi cu proprietarul (owner) directorului, este de ajuns să se seteze prvilegiile de 755, altfel trebuie să se seteze privilegiile 777 (după terminarea instalației privilegiile se pot modifica inapoi la 755)

Fig. 6.5: Lista erorilor ce pot apărea in timpul instalării

Generatorul pachetului de instalare

Script-ul care generează pachetul de instalare a aplicației este foarte complex, dar totuși implementarea lui s-a făcut modular.

La baza lui stă ideea de a genera un fișier PHP care va genera la rândul lui un alt set de fișiere PHP, CSS, JS, imagini și orice alt fel de fișier (fig 6.6). Deși sună ideea destul de complicat, dacă ne gândim mai bine, nu este greu de realizat (singurul obstacol fiind doar ințelegerea codului sursă a generatorului).

Fig. 6.6.a: Crearea funcției care generează fișierele

Primul pas ce trebuie făcut ân generator este de a citi structura fișierelor și directoarelor din directorul pentru care se realizează script-ul de instalare. Pentru asta se folosește funcția glob() din PHP, care returnează lista tuturor fișierelor și directoarelor care corespund pattern-ului dat ca parametru la funcția glob().

Fig. 6.6.b: Baza aplicației pentru crearea pachetului de instalare

După acesta se construiește codul sursă a unei liste PHP, care va avea ca cheie numele fișierelor (împreună cu calea relativă) și ca valoare conținutul fișierului (comprimat cu gzip si encodat in base64)

După acesta se generează codul sursă care verifică existența directoarelor și le crează dacă lipsesc. (În caz de eroare se afișează directorul care nu s-a putut crea.) În același timp se crează și fișierele statice într-o buclă foreach. Dacă un fișier nu poate fi creat, se va afișa un link spre fișier, astfel fișierele pot fi descărcate de utilizator și copiate manual.

Al treilea pas este scrierea fișierului de configurație, bazată pe numele de utilizator si parola introdusă de utilizator. Procesul de crearea fișierului este similar cu cel a creării fișierelor statice.

Se introduce un al parulea element in cod, care generează codul de PHP, care va verifica dacă script-ul de instalare trebuie sa returneze sursa unui fișier sau trebuie sa ruleze procesul de instalare, verificarea acțiunii este făcută bazată pe parametrul $file, primit ca variabilă GET. In cazul in care este solicitată fișierul de configurare, script+ul de instalare va primi ca parametru și numele de utilizator si parola.

Ultimul pas la implementarea aplicației de instalare a fost implementarea generatorului de formular pentru introducerea numelui de utilizator si parolă. Acest element a fost plasat după citirea structurii sistemului de fișiere și returnarea unei singur fișier, dar înainte de a crea structura de fișiere. Codul generează un simplu formular HTML pentru introducerea datelor. Desigur, dacă deja au fost introduse datele de conectare, formularul nu mai este afișat pentru ca se rulează procesul de instalare.

Generarea unui pachet nou

Funcționalitatea cea mai importantă a aplicațiilor este crearea bath-urilor noi și deservirea acestora către utilizatorii. La crearea pachetelor JS se poate specifica dacă se dorește și minimizarea adițională (eliminarea spațiilor albe – figura 6.7), conceput ca și o preprocesare a datelor, fiind un proces critic pentru scripturile de tip javascript. Pentru fișierele de tip CSS eliminarea spațiilor albe se face automat.

În cazul fișierelor JS, după sintaxa și specificarea W3C, o linie se termină ori cu caracterul de linie nouă ori cu punct și virgulă (“;”). Deci, codul următor:

#0: a=1

#1: b=2

#2: c=4

care ar rezulta după eliminarea spațiilor albe și caractere inutile în codul următor:

#0: a=1 b=2 c=4

care generează mesajul de eroare: “SyntaxError: illegal character”. O eroare la nivelul fișierelor JavaScript împiedică evaluarea codului care urmează după eroare, deci poate să conducă la probleme grave din punct de vedere al funcționalității pe partea de client.

Pentru a evita situația critică menționată mai sus, dacă opțiunea de minimizare a codurilor este activată se face un request către fișierul respectiv prin AJAX și se evaluează răspunsul primit. Dacă se găsește orice eroare se face un request nou și se împachetează fișierele din nou fără opțiunea de minimizare (figura 6.7 și 6.8):

Fig. 6.7: Crearea unui pachet nou

Fig. 6.8: Crearea unui pachet nou în prezența unei erori de JavaScript

Împrospătarea unui pachet care conține un anumit fișiser sau tuturor pachetelor

Împrospătarea unui pachet se face prin alegerea unei opțiuni din fereastra “Update compressed JS files”:

Fig. 6.8: Împrospătarea unui pachet (update)

Fig. 6.9: Codul JS pentru înprospătarea sau crearea unui pachet nou

Pentru împrospătarea tuturor pachetelor prima opțiune trebuie să fie selectată din lista („update all”). La împrospătarea pachetelor se ține cont și de setările de minimizări, care era salvate împreună cu generarea fișierului, și se aplică aceeași setări ca la generarea fișierului. Împrospătarea fișierelor se face tot pe baza request-urilor AJAX, folosind biblioteca de jQuery pentru gestionarea obiectelor de XMLHttpRequest și sincronizarea activităților.

Operații cu pachete (împrospătarea, vizualizarea informațiilor, ștergerea)

Informații legat de un pachet se poate vizualiza simplu dând un click pe iconul de informație:

Fig. 6.10: Împrospătarea unui pachet (update)

La acțiunea respectivă apare fereastra care conține informații corespunzătoare pachetului (calea cu care se poate include și o descriere scurtă, introdusă de utilizator la generarea fișierului). La fel de simplu se poate reîmprospăta și șterge fișierul respectiv, dând câte un click pe icoanele corespunzătoare.

Suport din partea serverului web

Un component esențial al aplicațiilor este serverul Apache și fișierul .htaccess instalat, care trimite header-ele corecte și tratează excepțiile prin reguli de redirectare (în cazul în care aplicație pe partea de client nu suportă metode de comprimare).

Pentru funcționalitatea corectă a aplicațiilor modulele de mod_rewrite și de mod_headers trebuie să fie activate.

Concluzii

Scopul lucrării prezente era găsirea unei soluții optime pentru optimizarea de viteză și economisirea lățimei de bandă prin compresarea fișierelor JavaScript și CSS, având în vedere mai multe aspecte (al programatorului, al serverului web și bineînțeles al utilizatorului) din diferite perspective.

S-a încercat justificarea și susținerea afirmației că optimizarea de viteză reprezintă un potențial de a îmbunătăți preformanța unei pagini web și în vremea conexiunilor de viteze (incredibil de) mari (T1 high-speed de 18 MBPS).

Prin prezenta lucrare s-a introdus o tehnica nouă care combină avantajele tuturor tehnicilor de optimizare disponibile, și anume gruparea fișierelor, minimizarea codurilor trimise, comprimarea rezultatului primit și stocharea versiunilor temporale pe server.

S-a dovedit că combinând aceste tehnici pornind de la rata de comprimare a metodei gzip (de circa 50%) se poate ajunge până la 80-90%, și în mod unic aplicațiile realizează o optimizare de viteză și în cazul când metodele de comprimare nu sunt suportate pe partea de client.

Cu aplicarea tehnicii prezentate împreună cu alte tehnici de optimizare s-ar putea evita supraîncărcarea serverelor web și prin această întregul internet ar funcționa mult mai rapid (lungimea informației trimisă totală fiind mult mai mică, în mult mai puține pachete). Chiar dacă afirmația precedentă este foarte optimistă tehnologia prezentată ar putea să fie implementată ușor la nivelul aplicațiilor CMS (Content Management Systems) și la bloguri.

Aplicația realizată deschide porțile spre multe alte posibilități ca de exemplu implementarea posibilității de a adăuga si fișiere externe in pachetele de JavaScript sau CSS pentru a elimina si cererile spre serverele exterioare. La fel se poate realiza o înpachetare a numelui de fișier prin folosirea unei tabele MySQL sau unui fișier adițional pentru memorarea componentelor pachetelor. Aceste implementări nu au fost realizate in acest proiect deoarece intenția a fost sa se creeze o aplicație care reduce banda de lățime folosită și numărul cererilor pe un singur server.

Bibliografie

[1] http://en.wikipedia.org/wiki/Network_performance
Network performance, the 8-second rule – consultat la 15.12.2011

[2] http://www.akamai.com/dl/reports/Site_Abandonment_Final_Report.pdf
Consumer Reaction to a Poor Online Shopping Experience, de la Akamai Technologies și JupiterSearch – consultat la 15.12.2011

[3] http://en.wikipedia.org/wiki/ISO/OSI
Open Systems Interconnection Reference Model – consultat la 15.12.2011

[4] http://www.adbh.co.uk/t171/tma4.php
The importance of TCP/IP in the development of the Internet – consultat la 17.12.2011

[5] http://dev.w3.org/html5/html-author/ – HTML 5 Reference – 18.12.2011

[6] http://www.ietf.org/rfc/rfc1945.txt – Hypertext Transfer Protocol – 18.12.2011

[7] http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html
Network Performance Effects of HTTP/1.1, CSS1, and PNG – 18.12.2011

[8] http://www.w3.org/Style/CSS/current-work – Cascading Style Sheets – 18.12.2011

[9] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/DOM3-Core.html
Document Object Model (DOM) Level 3 Core Specification – 05.01.2012

[10] http://www.cssplaza.com/introducere-in-css.php
Introducere in css – 05.01.2012

[11] http://www.json.org/ – Introducing JSON – 05.01.2012

[12] http://www.wut.de/e-5763w-1e-apus-000.php
Control Web – IO Digital with Ajax – 05.01.2012

[13] http://www.gzip.org/zlib/zlib_faq.html#faq38
Frequently Asked Questions about zlib – 10.02.2012

[14] http://www.ginfo.ro/revista/13_1/serial.pdf – Compresia datelor – 10.02.2012

[15] http://en.wikipedia.org/wiki/Hash_chain – Hash chain – 10.02.2012

[16] http://gzip.org/algorithm.txt – Gzip algorithm – 10.02.2012

[17] http://www.codinghorror.com/blog/archives/001178.html
Coding Horror: gzip faster than deflate? – 10.02.2012

[18] http//sendung.de/archives/2007/04/09/web-services-output-formats-and-gzip-compression/
Web Services, Output Formats and GZIP Compression – 10.02.2012

[19] http://www.http-compression.com/rfc2616.txt
Hypertext Transfer Protocol – 21.03.2012

[20] http://www.http-compression.com/ – HTTP Compression – 21.03.2012

[21] http://www.dailyblogtips.com/speed-up-your-site-reduce-the-http-requests/
Speed up your site: reduce the http requests – 21.03.2012

[22] http://www.julienlecomte.net/blogfiles/gz.phps
Julien Lecomte’s gzipping aplication – 30.03.2012

[23] http://developer.yahoo.com/yui/compressor/ – YUI Compressor – 30.03.2012

[24] http://crockford.com/javascript/jsmin
JSMIN by Dougles Crockford – 30.03.2012

[25] http://dean.edwards.name/packer/

[26] http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
Modulul deflate de la Apache – 30.03.2012

[27] http://en.wikipedia.org/wiki/Data_compression

Data compression – 05.01.2012

[28] http://www.askapache.com/htaccess/apache-htaccess.html
Ultimate Htaccess Guide and .htaccess Tutorial –05.01.2012

[29] http://www.vtc.com/products/TCP-IP-Packet-Analysis-Tutorials.htm
TCP/IP Packet Analysis Tutorials – 18.12.2011

[30] http://www.websiteoptimization.com/speed/tweak/css-optimization/
CSS optimization Archives –05.01.2012

[31] http://www.websiteoptimization.com/speed/tweak/suture/

[32] http://www.15seconds.com/Issue/020314.htm

[33] http://www.siteuri.ro/developer/dom-faq.ro.html
Intrebari frecvente despre Document Object Model –11.02.2012

[34] http://www.developer.com/lang/jscript/article.php/10939_3596836_1
Speeding Up AJAX with JSON – 05.01.2012

[35] http://www.json.org/ – JSON – 05.01.2012

[36] http://schroepl.net/projekte/mod_gzip/browser.htm
Which browsers can handle Content-Encoding – 05.01.2012

[37] http://docs.jquery.com/Main_Page – jQuery Javascript Library –10.05.2012

[38] http://php.net/ – PHP: Hypertext preprocessor

[39] http://www.webmasterworld.com/forum21/5794.htm
Does Formatting Code Slow Down The Page? –10.05.2012

[40] http://www.internetworldstats.com/europa.htm#ro
European Union Internet Usage and Population Stats –15.05.2012

[41] http://www.internetworldstats.com/ – Internet World Stats –15.05.2012

[42] http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html
Network Performance Effects of HTTP/1.1, CSS1, and PNG –16.05.2012

[43] http://news.netcraft.com/archives/2009/06/17/june_2009_web_server_survey.html
June 2009 Web Server Survey –16.05.2012

Atentie mare la forma – lucrarea sa fie unitara ca forma !!

Aici la final insereaza declaratia de autenticitate !! Iti trimit un model !!

La partea de teorie neaparat sa faci referire la toate elementele de biliografie !!!