de Preethi Kasireddy

Cum funcționează web Partea II: Modelul client-server și structura unei aplicații web

Cum functioneaza web Partea II Modelul client server si structura unei

In al meu postarea anterioară, ne-am scufundat în modul în care funcționează webul la un nivel de bază, inclusiv interacțiunea dintre un client (computerul dvs.) și un server (un alt computer care răspunde solicitărilor clientului pentru site-uri web).

Pentru acest post – partea a doua dintr-o serie din patru părți – să facem dublu clic pe înțelegerea modului în care clientul, serverul și alte părți ale unei aplicații web de bază sunt configurate de fapt pentru a vă face posibilă experiența de navigare pe web.

Modelul Client-Server

Această idee a unui client și a unui server care comunică printr-o rețea se numește modelul „Client-Server”. Este ceea ce face posibilă vizualizarea site-urilor web (precum acesta) și interacțiunea cu aplicațiile web (cum ar fi Gmail).

Modelul Client-Server este într-adevăr doar o modalitate de a descrie relația de a lua și lua între client și server într-o aplicație web – la fel cum ați putea folosi „iubitul” și „prietena” pentru a vă descrie relațiile personale. Sunt detaliile despre modul în care informațiile trec de la un capăt la altul, acolo unde imaginea se complică.

O configurație de bază a aplicației web

Există sute de moduri de configurare a unei aplicații web. Acestea fiind spuse, majoritatea au aceeași structură de bază: un client, un server și o bază de date.

Clientul

Clientul este ceea ce utilizatorul interacționează. Deci, codul „partea clientului” este responsabil pentru majoritatea a ceea ce vede de fapt un utilizator. Aceasta include:

  1. Definirea structura a paginii web
  2. Setarea arata si simti a paginii web
  3. Implementarea unui mecanism de răspuns la interacțiunile utilizatorilor (clic pe butoane, introducerea textului etc.)

Structura: Aspectul și conținutul paginii dvs. web sunt definite de HTML (de obicei HTML 5 când vine vorba de aplicații web în zilele noastre, dar asta este o altă poveste.)

HTML înseamnă Hyper Text Markup Language. Vă permite să descrieți structura fizică de bază a unui document folosind etichete HTML. Fiecare etichetă HTML descrie un element specific din document.

De exemplu:

Cum functioneaza web Partea II Modelul client server si structura unei
  • Conținutul din eticheta „

    ” descrie titlul.

  • Conținutul din eticheta „

    ” descrie un paragraf.

  • Conținutul din eticheta „
  • Si asa mai departe…

Un browser web folosește aceste etichete HTML pentru a determina modul de afișare a documentului.

Arată și simte: Pentru a defini aspectul unei pagini web, dezvoltatorii web utilizează CSS, care înseamnă Cascading Style Sheets. CSS este un limbaj care vă permite să descrieți modul în care ar trebui să fie stilate elementele definite în HTML, permițând modificări în font, culoare, aspect, animații simple și alte elemente superficiale.

Puteți seta stiluri pentru pagina HTML de mai sus astfel:

1611491469 356 Cum functioneaza web Partea II Modelul client server si structura unei

Interacțiuni cu utilizatorii: În cele din urmă, JavaScript intră în imagine pentru a gestiona interacțiunile utilizatorilor.

De exemplu, dacă doriți să faceți ceva atunci când un utilizator face clic pe butonul dvs., puteți face așa ceva:

1611491469 453 Cum functioneaza web Partea II Modelul client server si structura unei

Unele interacțiuni cu utilizatorii, cum ar fi cea de mai sus, pot fi gestionate fără a fi nevoie să contactați serverul dvs. – de aici termenul „JavaScript de la client”. Alte interacțiuni necesită trimiterea cererilor către serverul dvs. pentru a le gestiona.

De exemplu, dacă un utilizator postează un comentariu pe un fir, poate doriți să stocați acel comentariu în baza de date pentru a păstra toate riff-rafurile organizate într-un singur loc. Așadar, ați trimite cererea către server cu noul comentariu și noul ID de utilizator, iar serverul ar asculta aceste solicitări și le va procesa în consecință.

Vom aprofunda mult mai mult în cererea-răspuns HTTP în următoarea parte a acestei serii.

Server-ul

Serverul dintr-o aplicație web este ceea ce ascultă solicitările primite de la client. Când configurați un server HTTP, îl configurați pentru a asculta un număr de port. Un număr de port este întotdeauna asociat cu adresa IP a unui computer.

Vă puteți gândi la porturi ca la canale separate pe fiecare computer pe care le puteți utiliza pentru a efectua sarcini diferite: un port ar putea naviga www.facebook.com în timp ce altul vă preia e-mailul Acest lucru este posibil deoarece fiecare dintre aplicații (browserul web și clientul de e-mail) utilizează numere de port diferite.

Odată ce ați configurat un server HTTP pentru a asculta un anumit port, serverul așteaptă solicitările clientului care vin la acel port specific, efectuează orice acțiuni declarate de cerere și trimite orice date solicitate printr-un răspuns HTTP.

Baza de date

Bazele de date sunt subsolurile arhitecturii web – majoritatea dintre noi sunt speriați să coboare acolo, dar sunt esențiale pentru o bază solidă. O bază de date este un loc pentru stocarea informațiilor, astfel încât să poată fi accesate, gestionate și actualizate cu ușurință.

De exemplu, dacă creați un site de socializare, puteți utiliza o bază de date pentru a stoca informații despre utilizatori, postări și comentarii. Când un vizitator solicită o pagină, datele inserate în pagină provin din baza de date a site-ului, permițând interacțiunile cu utilizatorii în timp real pe care le considerăm de la sine considerate pe site-uri precum Facebook sau aplicații precum Gmail.

Asta-i tot oameni buni! (Ei bine, sorta …)

Este la fel de simplu ca asta. Tocmai am parcurs toate funcționalitățile de bază ale unei aplicații web.

1611491469 360 Cum functioneaza web Partea II Modelul client server si structura unei

Cum se scalează o aplicație web simplă

Configurația de mai sus este excelentă pentru aplicații simple. Dar pe măsură ce o aplicație crește, un singur server nu va avea puterea de a gestiona mii – dacă nu milioane – de cereri simultane de la vizitatori.

Pentru a scala pentru a satisface aceste volume mari, un lucru pe care îl putem face este să distribuim traficul de intrare pe un grup de servere back-end.

Aici lucrurile devin interesante. Aveți mai multe servere, fiecare cu propria adresă IP. Deci, cum știe serverul de nume de domeniu (DNS) la ce instanță a aplicației dvs. să vă trimită traficul?

Răspunsul simplu este că nu. Modul de a gestiona toate aceste instanțe separate ale aplicației dvs. este prin ceva numit un echilibru de sarcină.

Echilibrorul de sarcină acționează ca un polițist de trafic care direcționează cererile clientului pe servere în cel mai rapid și mai eficient mod posibil.

Deoarece nu puteți difuza adresele IP ale tuturor instanțelor serverului dvs., creați o adresă IP virtuală, care este adresa pe care ați transmis-o public clienților. Această adresă IP virtuală indică echilibratorul de încărcare. Deci, atunci când există o căutare DNS pentru site-ul dvs., acesta va indica spre echilibrarea sarcinii. Apoi, echilibrorul de încărcare intră pentru a distribui trafic în timp real la diferitele servere back-end.

S-ar putea să vă întrebați cum știe echilibratorul de încărcare pe ce server să trimită trafic. Răspunsul: algoritmi.

Un algoritm popular, Round Robin, implică distribuirea uniformă a cererilor primite în ferma serverului dvs. (toate serverele disponibile). De obicei, veți alege această abordare dacă toate serverele dvs. au o viteză și o memorie de procesare similare.

Cu un alt algoritm, Least Connections, următoarea solicitare este trimisă serverului cu cel mai mic număr de conexiuni active.

Există mult mai mulți algoritmi pe care îi puteți implementa, în funcție de nevoile dvs.

Deci, acum fluxul arată astfel:

1611491470 736 Cum functioneaza web Partea II Modelul client server si structura unei

Servicii

Bine, așa că ne-am rezolvat problema de trafic creând grupuri de servere și un echilibru de încărcare pentru a le gestiona. Funcționează grozav, nu?

… Dar simpla replicare a unei serii de servere poate duce la probleme, pe măsură ce aplicația dvs. crește. Pe măsură ce adăugați mai multe funcționalități aplicației dvs., va trebui să păstrați în continuare același server monolitic în timp ce acesta continuă să crească. Pentru a rezolva acest lucru, avem nevoie de o modalitate de a decupla funcționalitatea serverului.

Aici intervine ideea unui serviciu. Un serviciu este doar un alt server, cu excepția faptului că interacționează numai cu alte servere, spre deosebire de un server web tradițional care interacționează cu clienții.

Fiecare serviciu are o unitate de funcționalitate autonomă, cum ar fi autorizarea utilizatorilor sau furnizarea unei funcționalități de căutare. Serviciile vă permit să împărțiți singurul dvs. server web în mai multe servicii, fiecare realizând o funcționalitate discretă.

Principalul avantaj al divizării unui singur server în multe servicii este că vă permite să scalați serviciile complet independent.

Celălalt avantaj aici este că permite echipelor dintr-o companie să lucreze independent la un anumit serviciu, mai degrabă decât să aibă 10, 100 sau chiar 1000 de ingineri care lucrează pe un singur server monolitic, care devine rapid un coșmar de gestionare a proiectelor.

1611491470 298 Cum functioneaza web Partea II Modelul client server si structura unei

Notă rapidă aici: acest concept de echilibrare a încărcării și grupuri de servere și servicii back-end devine foarte dificil pe măsură ce creșteți pentru a adăuga din ce în ce mai multe servere la aplicația dvs. Devine deosebit de dificil cu lucruri precum persistența sesiunii – cum ar fi cum să gestionați trimiterea mai multor cereri de la un client pe același server pe durata unei sesiuni – și cum să implementați soluția de echilibrare a încărcării. Vom lăsa aceste subiecte avansate pentru această postare.

Rețele de livrare de conținut

Toate cele de mai sus funcționează excelent pentru scalarea traficului, dar aplicația dvs. este încă centralizată într-o singură locație. Când utilizatorii dvs. încep să vă viziteze site-ul din alte părți ale țării – sau din cealaltă parte a lumii – s-ar putea să se confrunte cu timpi de încărcare mai mari din cauza distanței crescute între client și server. La urma urmei, vorbim despre „World Wide Web” – nu despre „rețeaua locală de cartier”. 🙂

1611491470 501 Cum functioneaza web Partea II Modelul client server si structura unei

O tactică populară pentru a rezolva acest lucru este utilizarea unei rețele de livrare de conținut (CDN). Un CDN este un sistem mare distribuit de servere „proxy” desfășurate în mai multe centre de date. Un server proxy este doar un server care acționează ca intermediar între un client și un server.

Companiile cu cantități mari de trafic distribuit pot alege să plătească companiilor CDN pentru a-și livra conținutul către utilizatorii finali utilizând serverele CDN. Un exemplu de CDN este Akamai. Akamai are mii de servere situate în locații geografice strategice din întreaga lume.

Să comparăm modul în care funcționează un site web cu și fără un CDN.

Așa cum am vorbit în secțiunea 1, pentru un site web tipic, numele de domeniu al unei adrese URL este tradus la adresa IP a serverului gazdei.

Cu toate acestea, dacă un client folosește Akamai, numele de domeniu al adresei URL este tradus la adresa IP a unui server edge deținut de Akamai. Akamai livrează apoi conținutul web utilizatorilor clientului, fără ca acesta să fie nevoit să atingă serverele clientului.

Akamai poate face acest lucru stocând copii ale elementelor utilizate frecvent, cum ar fi HTML, CSS, descărcări de software și obiecte media de pe serverele clienților.

1611491470 150 Cum functioneaza web Partea II Modelul client server si structura unei

Scopul principal este de a aduce conținutul site-ului dvs. web mai aproape de utilizator. Dacă conținutul nu trebuie să călătorească atât de departe pentru a ajunge la utilizator, înseamnă o latență mai mică, ceea ce, la rândul său, reduce timpul de încărcare.

Ta da! Un site web mai rapid 🙂

Să conduc asta din nou?

În continuare, citește partea 3 unde vom completa detaliile cu o privire mai atentă la HTTP și REST! 🙂