Este greu de imaginat cazul în care administratorul unui server ar dori sa faca disponibil pentru toata lumea sistemul de fisiere al serverului Web. Deci, serverele web atribuie un director radacina (root folder) ca punct de plecare pentru toate cererile GET. Acest termen mai este utilizat si sub forma de home directory, home folder, root directory, HTTP root, document root sau home root.
În cazul în care serverul radacina este
C:\Inetpub\wwwroot
iar serverul a primit o cerere de tip
GET /studenti/grupe/abcd/note.html
serverul web va cauta în realitate si va trimite fisierul
C:\Inetpub\wwwroot\studenti\grupe\abcd\note.html
Modalitatea de a vedea datele ca parte a folderului radacina din serverul web este foarte utila. Chiar daca în realitate datele rezida pe un disc diferit, pentru managementul spatiului, sau chiar pe o masina diferita. Folderele virtuale reprezinta rezolvarea dilemei de mai sus, prin aparitia logica a unui folder din afara directorului radacina a serverului web ca parte din el.
De exemplu, un site care tine anunturile locale într-un folder la
E:\StiriLocale
iar serverul web are radacina în
C:\Inetpub\wwwroot
Administratorul serverului Web poate sa defineasca un folder virtual numit /stiri care sa reprezinte calea E:\StiriLocale. Când serverul Web receptioneaza cererea
GET /stiri/default.html
el va cauta si va trimite catre browser fisierul
E:\StiriLocale\default.html
si nu
C:\Inetpub\wwwroot\stiri\default.html
Un motiv pentru crearea de foldere virtuale este securitatea. Multe servere web utilizeaza folderele virtuale pentru a implementa permisii de acces la nivel de folder.
În cele ce urmeaza vom considera o secventa completa de pasi executati de serverul web pentru procesarea unei interogari receptionate de la clientul web:
browserul web sau alt client web trimite catre serverul web o interogare, cerând anumite resurse. Aceasta interogare este transmisa în format HTTP, în timp ce adresa resursei cerute este specificata în format Uniform Resource Locator (URL). Interogarile sunt facute de obicei utilizînd comanda HTTP Get.
dupa receptionarea interogarii de la client, serverul web determina existenta resursei în cadrul resurselor controlate de serverul respectiv;
în cazul în care resursa este disponibila, serverul web determina drepturile de acces, iar daca aceste drepturi nu au fost încalcate, returneaza catre client continutul resursei dorite;
în cazul în care drepturile de acces au fost încalcate, serverul web respinge interogarea, returnând clientului atentionarea de rigoare;
în cazul în care resurse nu se gaseste pe serverul web, serverul determina informatia despre resursa din fisierele de configuratie, acestea cuprinzând inclusiv o posibila relocare în retea. Daca resursa a fost alocata serverului, dar a fost redirectata temporar catre o alta locatie, serverul informeaza clientul despre acest fapt;
daca serverul web suporta un arbore virtual construit din alte servere web, cautarea va fi redirectionata catre resursele necesare;
daca serverul web este utilizat ca si server proxy, el actioneaza pe de-o parte ca si server web pentru clientul care a transmis interogarea, iar pe de alta parte ca si client web pentru a interoga un alt server web. Acesta este un simplu agent de retransmisie care regaseste si stocheaza în cache pagini web pentru persoanele din interior dar care nu permite accesul vizitatorilor la resursele interne. Pentru a utiliza un server proxy, fiecare browser trebuie configurat sa poata:
a. trimite toate cererile GET catre serverul proxy si nu catre gazda specificata în URL;
b. sa includa întregul URL, inclusiv numele serverului si portul în cererea GET.
dupa returnarea informatiilor catre client, serverul închide conexiune cu acesta.
Figura : Interactiunile dintre client si server.
Figura : Server web pe post de agent de retransmisie (proxy).
În cazul în care resursa obtinuta de la server este un fisier HTML, browserul, prin examinarea marcajului, poate determina cereri pentru alte fisiere. În acest caz, browser-ul le regaseste prin alte comenzi GET. Serverul web trateaza toate cererile GET în mod identic, indiferent de tipul fisierului. Sarcina de asamblare a fisierelor regasite si formatarea paginii revine browser-ului în întregime.
În mod normal, browser-ele mai trimit pe lânga cererea GET si diferite anteturi care includ informatii aditionale despre conexiune. În cererea urmatoare, de exemplu, browser-ul indica ce fel de fisiere poate sa accepte, ce limba prefera (engleza), marimea si adâncimea de culoare pentru ecranul vizitatorului, sistemul de operare al vizitatorului si tipul de procesor, numele si versiunea de browser, numele calculatorului pe care vizitatorul încearca sa-l acceseze si un indicator prin care browser-ul arata ca doreste sa utilizeze aceeasi conexiune pentru mai multe transferuri si nu sa deschida o noua conexiune pentru fiecare fisier:
GET / HTTP/1.1În raspuns la aceasta cerere, serverul raspunde cu un antet pentru fiecare pagina în care sunt indicate: un cod de stare (200 OK, numele si versiunea serverului web, dorinta de a reutiliza conexiunea, data si ora, tipul fisierului (text/html), posibilitatea de a oferi o portiune de bytes a unei pagini, data ultimei modificari a paginii returnate si lungimea paginii returnate în bytes.
HTTP/1.0 200 OKPaginile web ce contin formulare utilizeaza si al doilea tip de cerere numita POST. Metoda POST utilizeaza anteturi HTTP aditionale pentru a transmite numele si valorile câmpurilor dintr-un formular, oferind în acest fel o mai mare flexibilitate si capacitate de manipulare a datelor decât utilizarea metodei GET împreuna cu query string.
Explicarea completa a anteturilor HTTP nu constituie scopul acestei lucrari, dar autorii de pagini web trebuie sa fie constienti de faptul ca browser-ele si serverele web schimba între ele o varietate de informatii despre ele însele. De exemplu, informatiile oferite de browser-e pot fi utilizate de servere pentru a raspunde în mod diferit de la browser la browser.
Serverele web moderne pot fi utilizate pentru rezolvarea unei clase mai largi de probleme, între care enumeram:
suport pentru o baza de date de documente ierarhice, procesarea interogarilor si controlul accesului la informatii pentru programele client-side;
pre-procesarea datelor înainte de a raspunde interogarii;
interactiune cu alte programe externet si alte servere (motoare de cautare, de exemplu).
Securitatea este întotdeauna o problema pe Web, mai ales pentru activitatile care necesita transfer de bani, schimb de numere de carti de credit, numere de conturi bancare sau alte tranzactii financiare. În aceste cazuri, ambele parti ale unei astfel de tranzactii doresc criptarea informatiilor astfel încât nimeni sa nu poata interveni în comunicatie sa modifice sau sa duplice tranzactia, sau sa captureze datele pentru uz fraudulos.
Secure Sockets Layer (SSL) ofera un astfel de criptare pentru Web. SSL este utilizat în felul urmator:
vizitatorul Web trimite un URL având ca protocol de identificare https;
browser-ul contacteaza serverul Web pe portul 443 (portul 80 este implicit pentru trafic normal);
browser-ul si serverul negociaza o cheie de criptare pentru sesiunea curenta. Aceasta cheie cuprinde factori specifici pentru calculatorul vizitatorului, precum adresa IP, facând putin probabil faptul ca alt calculator sa ghiceasca sau sa obtina cheia respectiva;
dupa stabilirea cheii de criptare, toate comunicatiile, inclusiv URL-urile https sunt criptate cu cheia respectiva, dupa care:
a. browser-ul trimite datele criptate catre serviciul SSL pe portul 443;
b. serviciul SSL decripteaza transmisia si o înainteaza, intern, catre serverul si portul cerut;
c. serverul SSL primeste raspunsul serverului Web, îl cripteaza si îl transmite catre browser;
d. browser-ul face decriptarea si afiseaza rezultatele;
Figura : Interactiunea între client si server prin SSL.
Browser-ele sau clientii în general, pot sa initieze întotdeauna o conexiune SSL, dar pentru ca aceasta sa functioneze, serverul web trebuie sa fie corect configurat în ceea ce priveste conexiunile criptate.
Cea mai mare limitate a HTTP este faptul ca nu are stare. Acest lucru semnifica faptul ca o conexiune este închisa imediat dupa ce este transmisa o pagina, iar serverul nu retine informatii folositoare despre acest lucru. Acest fapt devine de-a dreptul suparator când o singura tranzactie necesita câteva pagini Web pentru a fi finalizata. Presupunând ca un vizitator aduce pe ecran prima pagina Web, transmite anumite informatii si apoi el obtine al doilea ecran pentru introducerea altor date. Când vizitatorul trimite cea de-a doua pagina, serverul nu mai stie ce date s-au trimis în prima pagina.
Pentru aceasta dilema exista trei solutii:
serverul trebuie sa scrie toate datele referitoare la o tranzactie pe fiecare pagina web, iar browser-ul sa le transmita înapoi cu fiecare tranzactie. Acest lucru presupune utilizarea de câmpuri ascunse de tip formular pentru fiecare articol;
serverul si browser-ul sa schimbe date referitoare la tranzactii sub forma de cookie-uri. Cookie-urile sunt câmpuri de date pe care browser-ele si serverele le schimba între ele prin intermediul anteturilor HTTP speciale. Cookie-urile pot fi aplicate unei pagini sau unui site, dar cookie-urile dintr-un site nu pot fi vazute de altul;
serverul Web sa mentina datele tranzactiei într-un fisier sau baza de date special conceputa pentru acest lucru. Pentru regasirea datelor se transmite un identificator de tranzactie catre si de la server prin câmpuri ascunse, query string sau cookie-uri.
În mod implicit cookie-urile rezida în memoria browser-ului si sunt sterse în momentul în care vizitatorul îl închide. Cu toate acestea, o pagina web poate preciza faptul ca un cookie sa fie salvat în mod persistent, într-un fisier special de pe discul vizitatorului. Cât timp cookie-ul exista pentru o anumita pagina Web, folder sau site, browser-ul îl transmite catre server odata cu fiecare cerere, pâna la expirarea cookie-ului. Serverul specifica de fiecare data o data de expirare pentru acel cookie.
Contrar credintei potrivit careia toate site-urile încep cu www si se termina într-un nume de domeniu principal, nu exista nici o lege specifica pentru aceasta. Cu toate acestea, vizitatorii asteapta acest lucru, creând probleme atât pentru site-urile mari cât si pentru cele mai mici.
Pentru site-urile Web mari, problema apare în momentul în care se doreste construirea de servere suficient de puternice ca sa raspunda la sute sau mii de cereri pe secunda. Solutia este upgrade-ul software si hardware sau setarea de servere aditionale pentru diferite nivele ale meniurilor din paginile web. Exista, de asemenea, si sisteme care sa distribuie în mod aleator cererile primite catre unul sau mai multe servere configurate în mod identic, chiar daca cererile specifica aceeasi adresa IP.
Pentru site-urile web mici, problema
este costul construirii serverelor web separate, chiar daca numarul
de vizitatori pe zi este mic sau moderat. Solutia normala este
instalarea mai multor site-uri web pe aceeasi masina server,
chiar daca proprietarii de site-uri doresc nume precum www.<nume-site>.ro sau www.<nume-site>.com în loc de www.<provider>.ro/<nume-site>
Serverele virtuale ofera o
solutie eleganta la aceasta problema. Un administrator
seteaza nume DNS si adrese IP diferite pentru fiecare site Web,
configurând software-ul de retea al masinii sa
raspunda la mai multe astfel de adrese. În cele din urma
administratorul configureaza serverul web sa acceseze foldere
radacina diferite, în functie de adresa IP specificata
de cererea vizitatorului. În acest fel site-uri cu nume precum www.<nume-site>.ro sau www.<nume-site>.com pot accesa foldere radacina diferite în aceeasi
masina fizica.
Pentru a se asigura faptul ca fiecare utilizator va atinge destinatia dorita, pentru fiecare site trebuie configurata o identitate unica. Deci, fiecare site web trebuie distins de altul prin cel putin una din modalitatile unice de identificare: un nume pentru antetul gazdei, o adresa IP sau un numar de port TCP.
|
Identificator site web |
Utilizare |
|
Nume pentru antet (host header) |
Recomandata pentru cele mai multe situatii. Prin setarea de anteturi diferite pentru fiecare site, se poate utiliza o adresa IP unica si acelasi port pentru mai multe servere virtuale; |
|
Adresa IP unica |
Utilizata în principal pentru serviciile Web care necesita utilizare HTTPS (Secure Socket Layer) pe serverul local; |
|
Port TCP nestandard |
Nu este în general recomandata utilizarea de porturi TCP nestandard, deoarece conexiunile (majoritatii) utilizatorilor sunt blocate prin intermediul firewall-urilor. Porturile nestandard pot fi folosite atât pentru dezvoltarea de site-uri Web private cât si pentru testarea, dar mai putin pentru productie. |
Tabelul : Modalitati de identificare a site-urilor web.
Prin schimbarea unuia din acesti identificatori se pot crea identitati unice pentru site-uri web multiple fara instalarea unui server dedicat pentru fiecare site. De asemenea, se poate specifica un director radacina pentru fiecare site în parte, atât pe serverul local cât si pe resurse partajate din retea.
Standardizarea unei metode pentru identificarea unica a unui site web la nivel de server (masina) este de preferinta facuta prin intermediul anteturilor unice. Utilizarea unei metode unice standard per server îmbunatateste performanta prin optimizarea cache-ului si a cautarii rutelor pentru adresare. Utilizarea oricarei combinatii de anteturi, adrese unice IP si porturi nestandard conduce la degradarea performantei tuturor site-urilor web de pe un server.
Consolidarea site-urilor web are ca avantaje economisirea resurselor hardware, conservarea spatiului si reducerea costurilor pentru energie.
Trimiterea de pagini gata create catre client este o functie utila, dar generarea de pagini dinamice, "din zbor" ofera o flexibilitate considerabil mai mare. Generarea de pagini cu continut dinamic necesita programare, dar înseamna si faptul ca acelasi URL poate produce rezultate diferite, în functie de data, ora, tipul browser-ului, interactiunea cu utilizatorul sau orice alte informatii disponibile pe serverul de web. Aceeasi tehnologie este utilizata pentru a procesa intrarile din formulare (datele care sunt trimise pe server) si pentru a afisa datele din bazele de date.
Majoritatea serverelor HTTP ofera si facilitati de programare server-side care precum facilitati de cautare în text sau procesarea datelor trimise pe server prin intermediul formularelor.
În continuare, enumeram câteva dintre cele mai populare modalitati de creare de pagini cu continut dinamic:
Common Gateway Interface (CGI);
Internet Server Application Programming Interface (ISAPI);
Active Server Pages (ASP);
ASP.NET;
Java Server Pages;
PHP;
Perl;
Common Gateway Interface (CGI) - în momentul în care un vizitator al unei pagini utilizeaza un hyperlink, URL asociat nu identifica un fisier de pe server care trebuie transmis catre browser ci un program pe care trebuie sa-l execute serverul de web. Aceste programe primesc, de obicei, date de intrare din formularele HTML sau datele adaugate la sfârsitul unui URL si genereaza HTML care va fi trimis catre browser pentru afisare. Prin intermediul acestor programe care se executa pe server se pot actualiza baze de date de pe server, se pot trimite mesaje e-mail sau se pot executa alte actiuni necesare;
Internet Server Application Programming Interface (ISAPI) - aceasta modalitate de creare de pagini HTML dinamice este similara CGI în ceea ce priveste functiile îndeplinite, dar este implementata în mod diferit. Astfel, programele ISAPI sunt biblioteci cu încarcare dinamica (DLL) pe care sistemul de operare trebuie sa le încarce numai o singura data, pentru orice numar de executii. În contrast, aplicatiile CGI sunt fisiere executabile (EXE) care trebuie încarcate, initializate, executate si descarcate din memorie la fiecare cerere. Pentru executia unei aplicatii de tip ISAPI, vizitatorul va trimite catre server o cerere sub forma unui URL ce contine numele unei biblioteci cu încarcare dinamica;
Active Server Pages (ASP) - spre deosebire de CGI si ISAPI, paginile ASP constau din cod HTML amestecat cu codul unui limbaj de programare. Serverul Web interpreteaza si executa codul programului si trimite catre browser rezultatul acestei executii. Pagina web care contine script la nivel de server (server-side) si este creata prin aceasta modalitate are extensia .asp. Programatorii utilizeaza de obicei pentru paginile ASP cod creat utilizând limbajul Microsoft VBScript si JavaScript. Aceste limbaje pot invoca servicii integrate în functiile serverului web, controale ActiveX, applet-uri Java sau alte obiecte.
ASP.NET - paginile ASP.NET constau din programe scrise în diferite limbaje de programare care se executa la nivel de server web, împreuna cu un set de controale ASP.NET la nivel de server si controale HTML care pot fi controlate la nivel de server. Diferenta esentiala fata de versiunea anterioara (ASP) consta în compilarea paginii în momentul primei executii (pagina poate fi compilata si anterior executiei), ducând astfel la o performanta deosebita în comparatie cu scripturile ASP.
|
