![]( "web_page")
Introducere
IntroducereÎn primul rând se impune o precizare din capul locului: articolul care urmează este pentru începătorii într-ale Internetului. Dacă te consideri avansat, îți pierzi timpul. Articolul nu e pentru tine.
Dacă încă citești, să-i dăm drumul!
Îți pornești, deci, programul favorit de navigare pe internet, browserul.
Dacă ești începător sunt șanse foarte mari să folosești Internet Explorer.
Iar dacă ai ceva vechime, probabil ai migrat la un moment dat spre un browser mai răsărit.
Cum ar fi, de exemplu, Mozilla Firefox sau mai tânărul dar vajnicul Google Chrome.
Oricare ți-ar fi browserul, scrii în bara lui de navigare ceva care de obicei începe cu www.
Dai Enter.
Ce se întâmplă când faci asta?
Calculatorul tău și Măria Sa, Internetul, își dau mâna ca să-ți ducă ordinul la îndeplinire.
Și pac, se încarcă pagina dorită.
Simplu și elegant, nu?
Server web
Poate te-ai întrebat ce se ascunde în spatele unui scenariu atât de simplu. A venit momentul să ștergem de praf lupa și să ne uităm mai îndeaproape la secvența de operații care se desfășoară în secret, pe nesimțite, din momentul când dai Enter și până când îți vezi în browser pagina cerută. Pagină care vine de unde? De undeva din marele Internet, nu? Corect, dar prea vag. Pagina ta vine de pe unul din milioanele de servere web din lumea largă.
Ce este un server web? Este un calculator care de obicei stă undeva într-un data center» . Pe calculatorul ăsta se află, printre multe alte pagini web, și pagina pe care vrei tu să o accesezi. Dar de fapt serverul web nu este calculatorul în sine, ci mai exact un program specializat care rulează pe acel calculator. Programul respectiv are rolul de a procesa solicitarea venită prin rețea de la browserul de pe calculatorul tău și de a răspunde furnizând conținutul paginii solicitate. Asta e de fapt un server web: un program care primește prin rețea din partea browserelor utilizatorilor cereri de acces la paginile web din “dotare” și răspunde furnizând conținutul acestor pagini (sau diverse mesaje de eroare în situația în care, din varii motive, nu poate furniza informația solicitată).
Nu e greu de intuit că, atunci când ceri browserului să-ți încarce pagina dorită, el trebuie să identifice mai întâi serverul web pe care se află acea pagină (server care rulează pe un sistem de calcul ce poate fi oriunde în lumea asta mare) și să ia legătura cu respectivul server pentru a-i solicita conținutul paginii.
URL
Dar înainte de a aprinde lanterna, să lămurim ce reprezintă ceea ce scrii tu în bara de navigare când vrei să accesezi o pagină web. Ce scrii tu acolo se numește URL (Uniform Resource Locator) și reprezintă un șir de caractere care identifică pagina dorită. URL-urile au o structură bine definită și, ca să înțelegem mai bine despre ce-i vorba, hai să luăm ca exemplu chiar URL-ul paginii la care te uiți acum (pentru ușurința identificării părților componente le-am scris cu culori diferite):
http://www.it4fans.ro/3767/ce-se-intampla-cand-accesezi-o-pagina-web.html
Identificăm trei părți principale.
Partea întâi, scrisă cu roșu, este metoda prin care se accesează pagina dorită, în cazul nostru http, ceea ce înseamnă că pentru accesarea paginii se va folosi protocolul HTTP» . Partea întâi, metoda de acces, se separă întotdeauna de partea următoare din URL folosind secvența :// (două puncte urmate de două caractere slash).
Partea a doua, scrisă cu verde (www.it4fans.ro), este un nume ce se referă la calculatorul pe care rulează serverul web în “ograda” căruia se află pagina pe care o cauți. El este partenerul de discuție al browserului tău. Este sarcina browserului ca, plecând de la acest nume:
- să caute mai întâi calculatorul pe care rulează serverul web (operație care se numește rezolvarea numelui DNS);
- și apoi să contacteze acel server web folosind metoda specificată (în cazul nostru http) pentru a-i cere conținutul paginii (care este identificată folosind partea a treia din URL).
Partea a treia, scrisă cu albastru (/3767/ce-se-intampla-cand-accesezi-o-pagina-web.html) reprezintă calea de acces spre pagina căutată (în cadrul serverului web). Ea poate sau nu să coincidă cu ultima parte din calea fizică a fișierului de pe discul calculatorului-server ce conține pagina cerută.
Într-un URL, după partea a treia mai pot urma și alte părți prin care pot fi comunicate serverului web informații legate de poziția (din cadrul paginii) unde se află informația ce trebuie accesată (opțiune utilă în cazul paginilor de dimensiuni mari) sau valorile diverșilor parametri pe care serverul trebuie să le cunoască pentru a putea genera pagina de răspuns, dar n-aș vrea să intru în detalii acum pentru că am vrut doar să schițez principalele componente ale unui URL, nu mi-am propus să tratez exhaustiv problematica URL-urilor.
Rezolvarea numelui DNS
Ziceam că browserul, înainte de a putea contacta serverul web pe care se află pagina solicitată, trebuie ca, pornind de la numele DNS din URL (în cazul nostru www.it4fans.ro), să identifice calculatorul pe care rulează acel server web. Și cum se identifică un calculator în tot internetul ăsta mare și lat? Simplu: precizând adresa acelui calculator, numită adresă IP, care este de fapt o secvență de patru numere separate prin punct (.), de exemplu 85.214.23.115. Orice calculator care trebuie să poată fi accesat în internet trebuie să aibă configurată o astfel de adresă IP.
Deci o primă sarcină a browserului ar fi ca, plecând de la numele DNS www.it4fans.ro, să afle adresa IP a calculatorului pe care rulează serverul web, server care nu va putea fi contactat decât dacă se cunoaște această adresă IP. Sarcina asta este pentru browser mai simplă decât pare, pentru că nu el trebuie să-și bată capul să o rezolve. El doar o paseazăsistemului DNS» .
Te-ai putea întreba acum: bine, dar ce rost are toată complicația asta cu numele DNS care pe urmă trebuie convertit în adresă IP folosind complicatul sistem DNS? Nu era mai simplu ca în URL să se specifice direct adresa IP în locul acelui nume DNS? Intr-un fel da, ar fi fost mai simplu așa. Dar adresa IP este o valoare mult prea “tehnică”. În primul rând, spre deosebire de un nume sugestiv, adresa IP nu spune nimic interesant utilizatorului și este greu de ținut minte iar apoi să nu uităm că adresa IP a serverului web se mai poate schimba în decursul timpului (de exemplu dacă administratorul site-ului decide să îl mute la un alt furnizor de găzduire web, caz în care va fi folosită o adresă IP din spațiul de adrese IP al noului furnizor). Dacă adresa IP a serverului ar apărea direct în URL în locul numelui, atunci URL-urile vechi nu ar mai fi valabile după mutarea site-ului la alt furnizor de hosting, situație absolut inacceptabilă. În timp ce, prin folosirea în URL a unui nume DNS, numele rămâne valabil tot timpul și o eventuală schimbare a adresei IP se operează în sistemul DNS și nu în URL-urile paginilor. În acest mod utilizatorii nici nu observă faptul că adresa IP a site-ului s-a schimbat. URL-ul lor îi conduce în continuare la pagina dorită la fel ca înainte.
Contactarea serverului web pentru a-i cere pagina dorită
Odată obținută de la serverul DNS local adresa IP (ex. 85.214.23.115) a serverului web care deține pagina căutată, browserul tău contactează serverul web identificat de respectiva adresă IP. Serverul fiind situat peste mări și țări, sarcina de a-l contacta pare complicată. La fel ca și în cazul interogării DNS, contactarea serverului web este mai simplă decât pare, pentru că sarcina este și de data asta pasată altcuiva: de data asta unui cărăuș de meserie, protocolul TCP/IP» .
Ca să fac o paranteză, același TCP/IP este cel prin intermediul căruia are loc și comunicația browserului cu serverul DNS local despre care vorbeam în secțiunea precedentă, iar serverul DNS local comunică la rândul lui cu alte servere DNS din internet folosind tot TCP/IP. Deci nu exagerez când afirm că TCP/IP este calul de povară al internetului. O să detaliez funcționarea protocolului TCP/IP și a sistemului DNS într-o serie de articole viitoare pentru că înțelegerea lor este esențială ca să poți spune că ai idee despre cum funcționează internetul. Sigur că ambele sunt vechi de peste două decenii însă cu toate astea nu multă lume știe cum funcționează, deci consider subiectul ca fiind unul de actualitate.
Revenind, browserul trimite serverului web solicitarea privind pagina web dorită. Solicitarea identifică pagina specificând porțiunea din URL de după numele DNS (în cazul nostru /3767/ce-se-intampla-cand-accesezi-o-pagina-web.html), este formulată conform regulilor protocolului HTTP și este transmisă serverului web folosind protocolul TCP/IP. Serverul analizează cererea, formulează un răspuns conform regulilor aceluiași protocol HTTP, răspuns pe care îl transmite browserului folosind același protocol TCP/IP. În cazul în care solicitarea este procesată cu succes, serverul comunică browserului succesul operației folosind o notație specială HTTP după care furnizează conținutul paginii solicitate, conținut exprimat în limbajul HTML. Dacă din diverse motive serverul nu poate da curs solicitării HTTP venite de la browser, va adresa browserului tot în termeni HTTP un mesaj de eroare (cum ar fi celebrul 404 Not Found).
Analizând conținutul paginii primit de la serverul web, browserul va identifica imaginile și alte elemente care trebuie afișate în pagină dar al căror conținut nu este inclus în pagina deja primită. Conținutul imaginilor și al eventualelor alte elemente este cerut serverului web printr-o secvență de solicitări HTTP ulterioare. Așa se explică faptul că, dacă dispunem de o conexiune internet mai lentă, observăm cum se încarcă mai întâi pagina cu textul iar imaginile se încarcă abia în secundele următoare.
Una dintre cele mai dificile sarcini care îi revine browserului este cea de a interpreta codul HTML și CSS» și de a-l reprezenta grafic exact în forma dorită de realizatorul respectivei pagini web. Este un subiect sensibil care a cauzat multe frustrări atât în rândul web designerilor cât și în rândul utilizatorilor din cauza faptului că modelele de browsere aflate în largă circulație nu au abordat în mod unitar și coerent aspectele generării paginilor web, ba chiar unele și-au permis să ignore cu tupeu maxim standardele în vigoare. Când vine vorba despre ignorarea standardelor, suspect de mulți web designeri arată cu degetul spre Internet Explorer și știu ei de ce. Același gen de probleme este valabil și cu engine-ul Javascript din browserele de largă circulație. Cum zice românul: câte bordeie, atâtea obiceie. În condițiile astea nu mai miră pe nimeni că băieții de la Google, dacă tot erau hotărâți să marșeze puternic pe Cloud Computing, s-au decis să-și creeze propriul browser, ca să știe o treabă.
Web-ul între trecut și viitor
Modelul cerere-răspuns implementat de protocolul HTTP este și el foarte vechi, la fel ca și protocolul, și nu prea se mai pliază satisfăcător pe cerințele web-ului modern din cauză că este inerent static. Eu îți cer o informație și tu mi-o dai. Asta suna bine la începuturile internetului dar în zilele noastre conceptul e depășit. Un concept adaptat la vremurile noastre dinamice ar fi următorul: eu îți cer o experiență și tu mi-o dai. Ce diferență este între informație și experiență? Aceeași ca și între static și dinamic.
Ceea ce îți dorești în ziua de azi de la un server web nu este o pagină moartă cu un text, câteva poze și eventual vreun filmuleț. Bine, ceea ce aștepți acum este tot o pagină cu text, culoare, sunet, dar o pagină vie, animată, cu care să poți interacționa și care să arate și să se comporte altfel în funcție de acțiunile tale. Este ca o aplicație desktop accesibilă prin intermediul browserului.
Așa s-a ajuns să se vorbească atât de mult despre Web 2.0, care este un web viu, în care utilizatorii care navighează accesează de fapt niște aplicații web care le oferă aceeași senzație de dinamism ca și aplicațiile locale, desktop, și în plus valorifică în același timp potențialul imens al rețelelor:
- posibilitatea de accesare instantanee a unei aplicații fără să fie nevoie ca ea să mai fie instalată pe calculatorul local;
- posibilitatea ca aplicația ce rulează pe server să facă uz de resurse computaționale sau de stocare mult mai mari decât cele disponibile în mod tipic pe calculatorul utilizatorului obișnuit;
- posibilitatea desfășurării unor activități colaborative între mai mulți utilizatori ai aplicației web;
- posibilitatea administratorului serverului de a taxa utilizatorul în funcție de cât de mult utilizează aplicația sau de a injecta publicitate inteligentă, contextuală, în câmpul vizual al utilizatorului, în funcție, de exemplu, de experiența web anterioară a acestuia;
După cum se vede, în Web 2.0 nu mai vorbim despre pagină web ci despre aplicație web. Protocolul HTTP este folosit în continuare pentru comunicarea cu serverul și limbajul HTML este în continuare utilizat pentru descrierea paginilor (cel puțin parțial) însă în Web 2.0 pe partea de server se utilizează adesea servere de aplicații iar pe partea de client se face uz intens de tehnologii care rulează în browser cum ar fi Javascript, Flash, Silverlight, Java. Tot mai mult se aude și de HTML5 care încă nu a ajuns la potențialul maxim, nefiind încă un standard recomandat de World Wide Web Consortium (W3C), fază la care se va ajunge, probabil, abia în toamna anului curent (2010).
Nu mai este demult un secret faptul că tendința contemporană este ca aplicațiile desktop să fie înlocuite de aplicații web care să ruleze pe servere aflate “undeva acolo afară”, adică într-un nor mistic, arhitectură care poartă numele de Cloud Computing și pe marginea căreia au curs râuri de cerneală în presă. Aliniindu-se acestei tendințe, se știe că gigantul Google lansează anul ăsta sistemul de operare Chrome OS, bazat pe GooBuntu (o versiune de Linux adaptată de Google) și care va gravita în jurul browserului vedetă din Mountain View: celebrul de acum Chrome. Chrome OS va fi un sistem de operare pentru care Cloud Computing este un principiu la fel de fundamental cum este legea lui Arhimede pentru vapoare.
