webový server

PC klienti komunikujúci cez sieť s webovým serverom, ktorý obsluhuje iba statický obsah
Vnútorná a predná strana servera Dell PowerEdge , počítača navrhnutého na montáž do rackového prostredia. Často sa používa ako webový server.
Pre web s vysokou návštevnosťou možno použiť viacero webových serverov.
Farma webových serverov s tisíckami webových serverov používaných pre webové stránky s vysokou návštevnosťou
ADSL modem so zabudovaným webovým serverom slúžiacim na dynamické webové stránky používané na konfiguráciu modemu

Webový server je počítačový softvér a základný hardvér , ktorý prijíma požiadavky cez HTTP ( sieťový protokol vytvorený na distribúciu webového obsahu ) alebo jeho zabezpečený variant HTTPS . Používateľský agent, obyčajne webový prehliadač alebo webový prehľadávač , iniciuje komunikáciu zadaním požiadavky na webovú stránku alebo iný zdroj pomocou HTTP a server odpovie obsahom tohto zdroja alebo chybovou správou . Webový server môže tiež prijímať a ukladať prostriedky odoslané z používateľského agenta, ak je na to nakonfigurovaný. [1] [2]

Hardvér používaný na spustenie webového servera sa môže líšiť v závislosti od objemu požiadaviek, ktoré musí spracovať. Na spodnom konci radu sú vstavané systémy , ako napríklad smerovač , ktorý spúšťa malý webový server ako svoje konfiguračné rozhranie. Internetová webová stránka s vysokou návštevnosťou môže spracovávať požiadavky so stovkami serverov, ktoré bežia na stojanoch vysokorýchlostných počítačov.

Zdrojom odoslaným z webového servera môže byť už existujúci súbor ( statický obsah ), ktorý má webový server k dispozícii, alebo ho môže vygenerovať v čase požiadavky ( dynamický obsah ) iný program , ktorý komunikuje so serverovým softvérom. Prvý z nich je zvyčajne možné obsluhovať rýchlejšie a možno ho ľahšie uložiť do vyrovnávacej pamäte pre opakované požiadavky, zatiaľ čo druhý podporuje širší rozsah aplikácií.

Technológie ako REST a SOAP , ktoré používajú HTTP ako základ pre všeobecnú komunikáciu medzi počítačmi, ako aj podpora rozšírení WebDAV , rozšírili aplikáciu webových serverov výrazne nad rámec ich pôvodného účelu, ktorým je poskytovanie ľudsky čitateľných stránok.

História

Prvý webový návrh (1989) bol vyhodnotený ako „vágny, ale vzrušujúci...“
Prvý webový server na svete, pracovná stanica NeXT Computer s Ethernetom, 1990. Štítok na obale znie: "Tento stroj je server. NEVYPÍNAJTE HO!!"

Toto je veľmi stručná história programov webového servera , takže niektoré informácie sa nevyhnutne prekrývajú s históriou webových prehliadačov , World Wide Web a internetu ; preto v záujme jasnosti a zrozumiteľnosti môžu byť niektoré kľúčové historické informácie uvedené nižšie podobné tým, ktoré sa nachádzajú aj v jednom alebo viacerých z vyššie uvedených článkov o histórii.

Počiatočný WWW projekt (1989–1991)

V marci 1989 Sir Tim Berners-Lee navrhol svojmu zamestnávateľovi CERN nový projekt s cieľom uľahčiť výmenu informácií medzi vedcami pomocou hypertextového systému. Návrh s názvom „HyperText a CERN“ si vyžiadal pripomienky a prečítalo si ho niekoľko ľudí. V októbri 1990 bol návrh preformulovaný a obohatený (spoluautorom Robert Cailliau ) a nakoniec bol schválený. [3] [4] [5]

Medzi koncom roka 1990 a začiatkom roku 1991 projekt viedol k tomu, že Berners-Lee a jeho vývojári napísali a otestovali niekoľko softvérových knižníc spolu s tromi programami, ktoré spočiatku bežali na OS NeXTSTEP nainštalovanom na pracovných staniciach NeXT : [6] [7] [5]

Tieto prvé prehliadače získavali webové stránky napísané v jednoduchej skorej forme HTML z webového servera (serverov) pomocou nového základného komunikačného protokolu s názvom HTTP 0.9 .

V auguste 1991 Tim Berner-Lee oznámil zrod technológie WWW a povzbudil vedcov, aby ju prijali a vyvinuli. [8] Čoskoro potom boli tieto programy spolu so zdrojovým kódom sprístupnené ľuďom, ktorí sa zaujímali o ich použitie. [6] Hoci zdrojový kód nebol formálne licencovaný alebo umiestnený vo verejnej doméne, CERN neformálne umožnil používateľom a vývojárom experimentovať a ďalej sa nad nimi rozvíjať. Berners-Lee začal propagovať prijatie a používanie týchto programov spolu s ich portovaním na iné operačné systémy . [5]

Rýchly a divoký vývoj (1991–1995)

Počet aktívnych webových stránok (1991–1996) [9] [10]

V decembri 1991 bol v SLAC (USA) nainštalovaný prvý webový server mimo Európy . [7] Bola to veľmi dôležitá udalosť, pretože začala medzikontinentálnu webovú komunikáciu medzi webovými prehliadačmi a webovými servermi.

V rokoch 1991–1993 pokračoval aktívny vývoj programu web serverov CERN skupinou www, medzitým sa vďaka dostupnosti jeho zdrojového kódu a verejnej špecifikácii protokolu HTTP začalo vyvíjať mnoho ďalších implementácií web serverov.

V apríli 1993 CERN vydal verejné oficiálne vyhlásenie, v ktorom sa uvádza, že tri komponenty webového softvéru (základný klient s riadkovým režimom, webový server a knižnica bežného kódu), spolu s ich zdrojovým kódom , boli zverejnené . [11] Toto vyhlásenie oslobodilo vývojárov webových serverov od akéhokoľvek možného právneho problému týkajúceho sa vývoja odvodeného diela založeného na tomto zdrojovom kóde (hrozba, ktorá v praxi nikdy neexistovala).

Začiatkom roku 1994 bol medzi novými webovými servermi najvýznamnejší NCSA httpd , ktorý bežal na rôznych operačných systémoch založených na Unixe a mohol slúžiť dynamicky generovanému obsahu implementáciou POSTmetódy HTTP a CGI na komunikáciu s externými programami. Tieto schopnosti spolu s multimediálnymi funkciami prehliadača Mosaic od NCSA (tiež schopného spravovať HTML FORMULÁRE na odosielanie údajov na webový server) zdôraznili potenciál webovej technológie pre publikovanie a distribuované počítačové aplikácie.

V druhej polovici roku 1994 sa vývoj NCSA httpd zastavil do tej miery, že skupina externých vývojárov softvéru, webmasterov a iných profesionálnych osobností, ktorí sa zaujímali o tento server, začala písať a zbierať opravy vďaka zdrojovému kódu NCSA httpd, ktorý bol dostupný verejná doména. Začiatkom roku 1995 boli všetky tieto záplaty aplikované na posledné vydanie zdrojového kódu NCSA a po niekoľkých testoch bol spustený projekt HTTP servera Apache . [12] [13]

Koncom roku 1994 bol vydaný nový komerčný webový server s názvom Netsite so špecifickými funkciami. Bol to prvý z mnohých ďalších podobných produktov, ktoré najprv vyvinul Netscape , potom aj Sun Microsystems a nakoniec Oracle Corporation .

V polovici roku 1995 bola vydaná prvá verzia IIS pre operačný systém Windows NT spoločnosťou Microsoft . To znamenalo vstup do oblasti technológií World Wide Web veľmi dôležitého komerčného vývojára a predajcu, ktorý hral a stále hrá kľúčovú úlohu na oboch stranách webu (klient a server).

V druhej polovici roku 1995 webové servery CERN a NCSA začali klesať (v globálnom percentuálnom využívaní) v dôsledku rozsiahleho prijatia nových webových serverov, ktoré mali oveľa rýchlejší vývojový cyklus spolu s viacerými funkciami, väčším počtom opráv a vyšším výkonom ako predchádzajúce.

Explozívny rast a konkurencia (1996 – 2014)

Počet aktívnych webových stránok (1996-2002) [10] [14]
Sun Cobalt Qube 3 – počítačové serverové zariadenie (2002, ukončená výroba)

Koncom roku 1996 už bolo známych vyše päťdesiat (rôznych) softvérových programov pre webový server, ktoré boli dostupné každému, kto chcel vlastniť názov internetovej domény a/alebo hostiť webové stránky. [15] Mnohé z nich žili len krátko a boli nahradené inými webovými servermi.

Zverejnenie RFC o verziách protokolu HTTP/1.0 (1996) a HTTP/1.1 (1997, 1999) prinútilo väčšinu webových serverov, aby (nie vždy úplne) dodržiavali tieto štandardy. Použitie trvalých pripojení TCP/IP (HTTP/1.1) vyžadovalo, aby webové servery výrazne zvýšili maximálny povolený počet súbežných pripojení a zároveň zlepšili svoju úroveň škálovateľnosti.

Medzi rokmi 1996 a 1999 sa Netscape Enterprise Server a IIS od Microsoftu objavili medzi poprednými komerčnými možnosťami, zatiaľ čo medzi voľne dostupnými a open-source programami si Apache HTTP Server držal prvenstvo ako preferovaný server (kvôli svojej spoľahlivosti a mnohým funkciám).

V tých rokoch existoval aj ďalší komerčný, vysoko inovatívny a teda pozoruhodný webový server s názvom Zeus ( teraz ukončený ), ktorý bol známy ako jeden z najrýchlejších a najviac škálovateľných webových serverov dostupných na trhu, prinajmenšom do prvej dekády roku 2000, napriek jeho nízke percento využitia.

Apache sa stal najpoužívanejším webovým serverom od polovice roku 1996 do konca roku 2015, keď ho po niekoľkých rokoch úpadku prekonal najskôr IIS a potom Nginx. Potom IIS klesol na oveľa nižšie percento využitia ako Apache (pozri tiež podiel na trhu).

V rokoch 2005–2006 začal Apache zlepšovať svoju rýchlosť a úroveň škálovateľnosti zavedením nových funkcií výkonu (napr. MPM udalostí a nová vyrovnávacia pamäť obsahu). [16] [17] Keďže tieto nové vylepšenia výkonu boli pôvodne označené ako experimentálne, používatelia ich dlho neaktivovali, a tak Apache ešte viac trpel konkurenciou komerčných serverov a predovšetkým iných otvorených serverov. zdrojové servery, ktoré už od začiatku svojho vývoja a v čase úpadku Apache dosahovali ďaleko lepšie výkony (hlavne pri obsluhe statického obsahu), boli schopné ponúknuť aj dostatočne dlhý zoznam osvedčených pokročilých funkcií.

V skutočnosti niekoľko rokov po roku 2000 spustili nielen ďalšie komerčné a vysoko konkurenčné webové servery, napr. LiteSpeed ​​, ale aj mnohé iné open-source programy, často vynikajúcej kvality a veľmi vysokého výkonu, medzi ktoré treba spomenúť Hiawatha, Cherokee HTTP sa objavil server , Lighttpd , Nginx a ďalšie odvodené/príbuzné produkty dostupné aj s komerčnou podporou.

Okolo rokov 2007–2008 najpopulárnejšie webové prehliadače zvýšili svoj predchádzajúci predvolený limit 2 trvalých pripojení na hostiteľskú doménu (limit odporúčaný RFC-2616) [18] na 4, 6 alebo 8 trvalých pripojení na hostiteľskú doménu, aby sa urýchlilo urýchliť vyhľadávanie ťažkých webových stránok s množstvom obrázkov a zmierniť problém nedostatku trvalých pripojení určených pre dynamické objekty používané na obojsmerné upozornenia na udalosti na webových stránkach. [19] V priebehu jedného roka tieto zmeny v priemere takmer strojnásobili maximálny počet trvalých pripojení, ktoré museli webové servery spravovať. Tento trend (zvyšovania počtu perzistentných pripojení) dal rozhodne silný impulz k adopcii reverzných proxy pred pomalšími web servermi a dal ešte jednu šancu vznikajúcim novým web serverom, ktoré mohli ukázať všetku svoju rýchlosť a schopnosti. zvládnuť veľmi vysoký počet súbežných pripojení bez potreby príliš veľa hardvérových zdrojov (drahé počítače s množstvom CPU, RAM a rýchlymi diskami). [20]

Nové výzvy (2015 a neskoršie roky)

V roku 2015 RFC zverejnili novú verziu protokolu [HTTP/2] a keďže implementácia nových špecifikácií nebola vôbec triviálna, vznikla dilema medzi vývojármi menej populárnych webových serverov (napr. s percentom využitia nižším ako 1 % .. 2%) o pridaní alebo nepridaní podpory pre túto novú verziu protokolu. [21] [22]

V skutočnosti podpora HTTP/2 často vyžadovala radikálne zmeny ich internej implementácie v dôsledku mnohých faktorov (prakticky vždy vyžadované šifrované spojenia, schopnosť rozlišovať medzi HTTP/1.xa HTTP/2 spojeniami na rovnakom TCP porte, binárna reprezentácia HTTP správ , priorita správ, kompresia HTTP hlavičiek, používanie streamov známych ako TCP/IP sub-spojenia a súvisiace riadenie toku atď.) a tak sa niekoľko vývojárov týchto webových serverov rozhodlo nepodporovať novú verziu HTTP/2 (na najmenej v blízkej budúcnosti) aj z týchto hlavných dôvodov: [21] [22]

  • protokoly HTTP/1.x by prehliadače aj tak podporovali veľmi dlho (možno navždy), aby v budúcnosti neexistovala žiadna nekompatibilita medzi klientmi a servermi;
  • implementácia HTTP/2 sa považovala za mimoriadne zložitú úlohu , ktorá by mohla otvoriť dvere úplne novej triede chýb , ktoré do roku 2015 neexistovali, a preto by si vyžadovala značné investície do vývoja a testovania implementácie nového protokolu;
  • pridanie podpory HTTP/2 by sa dalo urobiť vždy v budúcnosti, ak by bolo úsilie opodstatnené.

Namiesto toho sa vývojári najpopulárnejších webových serverov ponáhľali ponúknuť dostupnosť nového protokolu , a to nielen preto, že mali pracovnú silu a čas na to, aby tak urobili, ale aj preto, že ich predchádzajúca implementácia protokolu SPDY by sa zvyčajne dala znova použiť ako východiskový bod. a pretože väčšina používaných webových prehliadačov ho implementovala veľmi rýchlo z rovnakého dôvodu. Ďalším dôvodom, ktorý prinútil týchto vývojárov konať rýchlo, bolo to, že správcovia webu cítili tlak neustále sa zvyšujúcej návštevnosti webu a naozaj chceli čo najskôr nainštalovať a vyskúšať niečo, čo by mohlo drasticky znížiť počet pripojení TCP/IP a zrýchliť. prístupy k hosťovaným webovým stránkam. [23]

V rokoch 2020–2021 sa dynamika HTTP/2 o jeho implementácii (špičkovými webovými servermi a populárnymi webovými prehliadačmi) čiastočne replikovala po zverejnení pokročilých návrhov budúceho RFC o protokole HTTP/3 .

Technický prehľad

PC klienti pripojení k webovému serveru cez internet

Nasledujúci technický prehľad by sa mal považovať len za pokus uviesť niekoľko veľmi obmedzených príkladov niektorých funkcií , ktoré môžu byť implementované vo webovom serveri, a niektorých úloh, ktoré môže vykonávať, aby bol k danej téme pripravený dostatočne široký scenár.

Program webového servera zohráva úlohu servera v modeli klient-server implementáciou jednej alebo viacerých verzií protokolu HTTP, často vrátane zabezpečeného variantu HTTPS a ďalších funkcií a rozšírení, ktoré sa považujú za užitočné pre jeho plánované použitie.

Zložitosť a efektívnosť programu webového servera sa môže značne líšiť v závislosti od (napr.): [1]

  • implementované spoločné črty;
  • vykonávané bežné úlohy;
  • výkon a úroveň škálovateľnosti zameraná ako cieľ;
  • softvérový model a techniky prijaté na dosiahnutie požadovaného výkonu a úrovne škálovateľnosti;
  • cieľový hardvér a kategória použitia, napr. vstavaný systém, webový server s nízkou strednou návštevnosťou, internetový webový server s vysokou návštevnosťou.

Spoločné znaky

Hoci sa programy webového servera líšia v spôsobe implementácie, väčšina z nich ponúka nasledujúce spoločné funkcie.

Toto sú základné funkcie , ktoré má väčšina webových serverov.

Niekoľko ďalších pokročilejších a populárnych funkcií ( len veľmi krátky výber ) sú nasledujúce.

  • Poskytovanie dynamického obsahu : schopnosť poskytovať klientom dynamický obsah (generovaný za chodu) prostredníctvom protokolu HTTP.
  • Virtuálny hosting : byť schopný obsluhovať mnoho webových stránok ( názvov domén ) iba pomocou jednej IP adresy .
  • Autorizácia: možnosť povoliť, zakázať alebo autorizovať prístup k častiam webových ciest (webových zdrojov).
  • Obsah vyrovnávacej pamäte: schopnosť ukladať statický a/alebo dynamický obsah do vyrovnávacej pamäte s cieľom urýchliť odozvy servera;
  • Podpora veľkých súborov : aby bolo možné obsluhovať súbory, ktorých veľkosť je väčšia ako 2 GB na 32-bitovom OS .
  • Obmedzenie šírky pásma : obmedziť rýchlosť odpovedí obsahu, aby sa nezasýtila sieť a aby bolo možné obslúžiť viac klientov;
  • Prepisovací mechanizmus : na mapovanie častí čistých adries URL (nachádzajúcich sa v požiadavkách klientov) na ich skutočné mená.
  • Vlastné chybové stránky : podpora prispôsobených chybových správ HTTP.

Bežné úlohy

Program webového servera, keď je spustený, zvyčajne vykonáva niekoľko všeobecných úloh , (napr.): [1]

  • spustí, voliteľne načíta a aplikuje nastavenia nájdené v jeho konfiguračnom(ých) súbore (och) alebo inde, voliteľne otvorí log súbor, začne počúvať pripojenia/požiadavky klientov;
  • voliteľne sa snaží prispôsobiť svoje všeobecné správanie podľa svojich nastavení a aktuálnych prevádzkových podmienok;
  • spravuje pripojenia klienta (prijímanie nových alebo zatváranie existujúcich podľa potreby);
  • prijíma požiadavky klientov (čítaním správ HTTP):
    • číta a overuje každú správu HTTP požiadavky;
    • zvyčajne vykonáva normalizáciu URL;
    • zvyčajne vykonáva mapovanie adries URL (ktoré môže byť predvolené na preklad cesty URL);
    • zvyčajne vykonáva preklad adresy URL spolu s rôznymi bezpečnostnými kontrolami;
  • vykoná alebo odmietne požadovanú metódu HTTP:
    • voliteľne spravuje autorizácie URL;
    • voliteľne spravuje presmerovania URL;
    • voliteľne spravuje požiadavky na statické zdroje (obsah súboru):
      • voliteľne spravuje súbory indexu adresárov;
      • voliteľne spravuje bežné súbory;
    • voliteľne spravuje požiadavky na dynamické zdroje :
      • voliteľne spravuje zoznamy adresárov;
      • voliteľne riadi spracovanie programu alebo modulu, kontrolu dostupnosti, spustenie a prípadne zastavenie vykonávania externých programov používaných na generovanie dynamického obsahu;
      • voliteľne riadi komunikáciu s externými programami / internými modulmi používanými na generovanie dynamického obsahu;
  • odpovede na požiadavky klientov posielaním správnych HTTP odpovedí (napr. požadované zdroje alebo chybové správy), prípadne overenie alebo pridanie HTTP hlavičiek k tým, ktoré posielajú dynamické programy/moduly;
  • voliteľne zaznamenáva (čiastočne alebo úplne) požiadavky klienta a/alebo jeho odpovede do externého súboru denníka používateľa alebo do súboru denníka systému pomocou syslog , zvyčajne pomocou bežného formátu denníka ;
  • voliteľne protokoluje správy o zistených anomáliách alebo iných významných udalostiach (napr. v požiadavkách klienta alebo vo svojom internom fungovaní) pomocou syslog alebo iných systémových zariadení; tieto protokolové správy majú zvyčajne úroveň ladenia, varovania, chyby, výstrahy, ktorú možno filtrovať (nezaprotokolovať) v závislosti od niektorých nastavení, pozri tiež úroveň závažnosti ;
  • voliteľne generuje štatistiky o riadenej návštevnosti webu a/alebo jeho výkonoch;
  • iné vlastné úlohy.

Prečítajte si správu so žiadosťou

Programy webového servera sú schopné: [24] [25] [26]

  • na čítanie správy s požiadavkou HTTP;
  • interpretovať to;
  • overiť jeho syntax;
  • identifikovať známe HTTP hlavičky a extrahovať z nich ich hodnoty.

Po dekódovaní a overení správy s požiadavkou HTTP je možné použiť jej hodnoty na určenie, či môže byť táto požiadavka splnená alebo nie. Vyžaduje si to mnoho ďalších krokov vrátane bezpečnostných kontrol .

normalizácia URL

Programy webového servera zvyčajne vykonávajú určitý typ normalizácie URL ( adresa URL sa nachádza vo väčšine správ s požiadavkami HTTP) v poradí:

  • aby cesta k zdroju bola vždy čistá a jednotná cesta z koreňového adresára webovej stránky;
  • znížiť bezpečnostné riziká (napr. jednoduchšie zachytiť pokusy o prístup k statickým zdrojom mimo koreňového adresára webovej lokality alebo o prístup k častiam cesty pod koreňovým adresárom webovej lokality, ktoré sú zakázané alebo vyžadujú autorizáciu);
  • aby boli cesty webových zdrojov lepšie rozpoznateľné pre ľudí a programy na analýzu webových protokolov (tiež známe ako analyzátory protokolov / štatistické aplikácie).

Termín normalizácia adresy URL sa vzťahuje na proces úpravy a štandardizácie adresy URL konzistentným spôsobom. Existuje niekoľko typov normalizácie, ktoré možno vykonať, vrátane konverzie schémy a hostiteľa na malé písmená. Medzi najdôležitejšie normalizácie patrí odstránenie "." a ".." segmenty cesty a pridanie koncových lomiek do neprázdneho komponentu cesty.

mapovanie URL

"Mapovanie URL je proces, pri ktorom sa URL analyzuje, aby sa zistilo, na aký zdroj odkazuje, aby sa tento zdroj mohol vrátiť žiadajúcemu klientovi. Tento proces sa vykonáva s každou požiadavkou, ktorá je odoslaná na webový server, s niektoré z požiadaviek sú obsluhované súborom, ako je napríklad HTML dokument alebo obrázok gif, iné s výsledkami spustenia programu CGI a iné iným procesom, ako je napríklad vstavaný obslužný program modulu, dokument PHP alebo servlet Java." [27] [ potrebuje aktualizáciu ]

V praxi programy webového servera, ktoré implementujú pokročilé funkcie nad rámec jednoduchého poskytovania statického obsahu (napr. nástroj na prepisovanie URL, poskytovanie dynamického obsahu), zvyčajne musia prísť na to, ako sa musí s týmto URL zaobchádzať, napr.

  • ako presmerovanie URL, presmerovanie na inú URL;
  • ako statická požiadavka na obsah súboru ;
  • ako dynamická požiadavka :
    • zoznam adresárov súborov alebo iných podadresárov obsiahnutých v tomto adresári;
    • iné typy dynamických požiadaviek s cieľom identifikovať procesor programu/modulu, ktorý je schopný spracovať tento druh URL cesty a odovzdať mu ďalšie časti URL , tj zvyčajne premenné path-info a reťazec dotazu .

Jeden alebo viacero konfiguračných súborov webového servera môže špecifikovať mapovanie častí URL cesty (napr. počiatočné časti cesty k súboru , prípona súboru a ďalšie komponenty cesty) na špecifický URL handler (súbor, adresár, externý program alebo interný modul). [28]

Keď webový server implementuje jednu alebo viacero z vyššie uvedených pokročilých funkcií, potom sa časť cesty platnej adresy URL nemusí vždy zhodovať s existujúcou cestou súborového systému v strome adresára webovej lokality (súbor alebo adresár v systéme súborov ), pretože môže odkazovať na na virtuálny názov interného alebo externého modulového procesora pre dynamické požiadavky.

Preklad adresy URL do systému súborov

Programy webového servera sú schopné preložiť cestu URL (celú alebo jej časť), ktorá odkazuje na cestu fyzického systému súborov, na absolútnu cestu v koreňovom adresári cieľovej webovej lokality. [28]

Koreňový adresár webovej stránky môže byť špecifikovaný konfiguračným súborom alebo nejakým interným pravidlom webového servera použitím názvu webovej stránky, ktorý je hostiteľskou časťou adresy URL nájdenej v požiadavke klienta HTTP. [28]

Preklad cesty do systému súborov sa vykonáva pre nasledujúce typy webových zdrojov:

  • lokálny, zvyčajne nespustiteľný súbor (statická požiadavka na obsah súboru);
  • lokálny adresár (dynamická požiadavka: výpis adresára generovaný za chodu);
  • názov programu (dynamické požiadavky, ktoré sa vykonávajú pomocou rozhrania CGI alebo SCGI a ktorých výstup načíta webový server a znova ho odošle klientovi, ktorý zadal požiadavku HTTP).

Webový server pripojí cestu nájdenú v požadovanej URL (správa s požiadavkou HTTP) a pripojí ju k ceste ku koreňovému adresáru (hostiteľskej) webovej stránky. Na serveri Apache je to bežne /home/www/website(na strojoch Unix je to zvyčajne: /var/www/website). Pozrite si nasledujúce príklady, ako to môže dopadnúť.

Preklad adresy URL pre požiadavku na statický súbor

Príklad statickej požiadavky na existujúci súbor špecifikovaný nasledujúcou adresou URL:

http://www.example.com/cesta/subor.html

Klientsky užívateľský agent sa pripojí www.example.coma potom odošle nasledujúcu požiadavku HTTP /1.1:

GET /path/file.html HTTP/1.1
Hostiteľ: www.example.com
Spojenie: keep-alive

Výsledkom je zdroj lokálneho systému súborov:

/home/www/www.example.com/cesta/subor.html

Webový server potom prečíta súbor , ak existuje, a odošle odpoveď do webového prehliadača klienta. Odpoveď popíše obsah súboru a bude obsahovať samotný súbor alebo sa vráti chybové hlásenie, že súbor neexistuje alebo je k nemu zakázaný prístup.

Preklad adresy URL pre požiadavku na adresár (bez statického indexového súboru)

Príklad implicitnej dynamickej požiadavky existujúceho adresára špecifikovaného nasledujúcou adresou URL:

http://www.example.com/adresar1/adresar2/

Klientsky užívateľský agent sa pripojí www.example.coma potom odošle nasledujúcu požiadavku HTTP /1.1:

GET /adresár1/adresár2 HTTP/1.1
Hostiteľ: www.example.com
Spojenie: keep-alive

Výsledkom je cesta k lokálnemu adresáru:

/home/www/www.example.com/adresar1/adresar2/

Webový server potom overí existenciu adresára a ak existuje a je k nemu prístupný, pokúsi sa nájsť indexový súbor (ktorý v tomto prípade neexistuje) a tak odovzdá požiadavku internému modulu alebo špeciálnemu programu do výpisov adresárov a nakoniec načíta dátový výstup a odošle odpoveď do webového prehliadača klienta. Odpoveď popíše obsah adresára (zoznam obsiahnutých podadresárov a súborov) alebo sa vráti chybové hlásenie, že adresár neexistuje alebo je k nemu zakázaný prístup.

Preklad adresy URL pre požiadavku dynamického programu

V prípade dynamickej požiadavky by cesta URL špecifikovaná klientom mala odkazovať na existujúci externý program (zvyčajne spustiteľný súbor s CGI), ktorý webový server používa na generovanie dynamického obsahu. [29]

Príklad dynamickej požiadavky pomocou programového súboru na generovanie výstupu:

http://www.example.com/cgi-bin/forum.php?action=view&orderby=thread&date=2021-10-15

Klientsky užívateľský agent sa pripojí www.example.coma potom odošle nasledujúcu požiadavku HTTP /1.1:

GET /cgi-bin/forum.php?action=view&ordeby=thread&date=2021-10-15 HTTP/1.1
Hostiteľ: www.example.com
Spojenie: keep-alive

Výsledkom je lokálna cesta k súboru programu (v tomto príklade programu PHP ):

/home/www/www.example.com/cgi-bin/forum.php

Webový server spustí tento program a odovzdá informácie o ceste a reťazec dotazu action=view&orderby=thread&date=2021-10-15 , aby mal program informácie, ktoré potrebuje na spustenie. (V tomto prípade vráti dokument HTML obsahujúci zobrazenie položiek fóra zoradených podľa vlákna od 15. októbra 2021). Okrem toho webový server načíta údaje odoslané z externého programu a znova ich odošle klientovi, ktorý zadal požiadavku.

Spravovať správu so žiadosťou

Keď je požiadavka prečítaná, interpretovaná a overená, musí byť spravovaná v závislosti od jej metódy, jej URL a jej parametrov, ktoré môžu zahŕňať hodnoty HTTP hlavičiek.

V praxi musí webový server spracovať požiadavku pomocou jednej z týchto ciest odpovede: [28]

  • ak niečo v požiadavke nebolo prijateľné (v stavovom riadku alebo hlavičkách správ), webový server už odoslal chybovú odpoveď;
  • ak má požiadavka metódu (napr. OPTIONS), ktorá môže byť splnená všeobecným kódom webového servera, odošle sa úspešná odpoveď;
  • ak URL vyžaduje autorizáciu, odošle sa chybová správa autorizácie;
  • ak sa adresa URL mapuje na presmerovanie, odošle sa správa o presmerovaní;
  • ak sa URL mapuje na dynamický zdroj (virtuálnu cestu alebo zoznam adresára), potom sa zavolá jeho obslužný program (interný modul alebo externý program) a odovzdá sa mu parametre požiadavky (reťazec dopytu a informácie o ceste), aby bolo možné odpovedať na túto žiadosť;
  • ak sa URL mapuje na statický zdroj (zvyčajne súbor v súborovom systéme), potom sa zavolá interný statický obslužný program na odoslanie tohto súboru;
  • ak metóda požiadavky nie je známa alebo ak existuje nejaký iný neprijateľný stav (napr. zdroj sa nenašiel, interná chyba servera atď.), odošle sa chybová odpoveď.

Poskytovať statický obsah

PC klienti komunikujúci cez sieť s webovým serverom, ktorý obsluhuje iba statický obsah

Ak je program webového servera schopný obsluhovať statický obsah a bol na to nakonfigurovaný, potom je schopný odosielať obsah súboru vždy, keď správa žiadosti obsahuje platnú zhodnú cestu URL (po mapovaní URL, preklade URL a presmerovaní URL), ktoré existujúceho súboru v koreňovom adresári webovej stránky a súbor má atribúty, ktoré sa zhodujú s tými, ktoré vyžadujú interné pravidlá programu webového servera. [28]

Tento druh obsahu sa nazýva statický , pretože ho zvyčajne webový server nemení, keď ho posiela klientom, a pretože zostáva rovnaký, kým nie je upravený (úprava súboru) nejakým programom.

POZNÁMKA: Pri poskytovaní iba statického obsahu program webového servera zvyčajne nemení obsah súborov obsluhovaných webových stránok (pretože sa iba čítajú a nikdy nezapisujú), a preto stačí podporovať iba tieto metódy HTTP :

  • OPTIONS
  • HEAD
  • GET

Odozva obsahu statického súboru môže byť urýchlená pomocou vyrovnávacej pamäte .

Indexové súbory adresárov

Ak program webového servera prijme správu s požiadavkou klienta s adresou URL, ktorej cesta sa zhoduje s jedným z existujúcich adresárov a tento adresár je prístupný a sú povolené indexové súbory adresárov, potom sa program webového servera môže pokúsiť obslúžiť prvý zo známych ( alebo nakonfigurované) názvy statických indexových súborov (bežný súbor) nájdené v tomto adresári; ak sa nenájde žiadny indexový súbor alebo nie sú splnené iné podmienky, vráti sa chybové hlásenie.

Najpoužívanejšie názvy pre statické indexové súbory sú index.html: index.htma Default.htm.

Bežné súbory

Ak program webového servera prijme správu s požiadavkou klienta s adresou URL, ktorej cesta sa zhoduje s názvom súboru existujúceho súboru a tento súbor je prístupný programu webového servera a jeho atribúty zodpovedajú interným pravidlám programu webového servera, potom program webového servera môže odoslať túto súbor klientovi.

Z bezpečnostných dôvodov je väčšina programov webového servera predkonfigurovaná tak, aby poskytovala iba bežné súbory alebo aby sa vyhli používaniu špeciálnych typov súborov , ako sú súbory zariadenia , spolu so symbolickými odkazmi alebo pevnými odkazmi na ne. Cieľom je vyhnúť sa nežiaducim vedľajším účinkom pri obsluhe statických webových zdrojov. [30]

Poskytovať dynamický obsah

PC klienti komunikujúci cez sieť s webovým serverom obsluhujúcim statický a dynamický obsah

Ak je program webového servera schopný obsluhovať dynamický obsah a bol na to nakonfigurovaný, potom je schopný komunikovať so správnym interným modulom alebo externým programom (priradeným k požadovanej URL ceste), aby mu odovzdal parametre požiadavka klienta; potom z neho program webového servera načíta svoju dátovú odpoveď (ktorú vygeneroval, často za chodu) a následne ju odošle klientskemu programu, ktorý zadal požiadavku. [ potrebná citácia ]

POZNÁMKA: Pri poskytovaní statického a dynamického obsahu musí program webového servera zvyčajne podporovať aj nasledujúcu metódu HTTP, aby mohol bezpečne prijímať údaje od klienta (klientov) a aby mohol hostiť aj webové stránky s interaktívnymi formulármi ), ktoré môžu odosielať veľké súbory údajov (napr. veľké množstvo údajov alebo nahrávanie súborov ) na webový server / externé programy / moduly:

  • POST

Aby bol program webového servera schopný komunikovať so svojimi internými modulmi a/alebo externými programami, musí mať implementované jedno alebo viacero z mnohých dostupných rozhraní brány (pozri tiež Rozhrania brány webového servera používané pre dynamický obsah).

Tri štandardné a historické rozhrania brán sú nasledujúce.

CGI
Externý CGI program je spustený programom webového servera pre každú dynamickú požiadavku, potom z neho program webového servera načíta vygenerovanú dátovú odpoveď a potom ju znova odošle klientovi.
SCGI
Externý SCGI program (zvyčajne je to proces) je raz spustený programom webového servera alebo iným programom/procesom a potom čaká na sieťové pripojenia; zakaždým, keď je naň nová požiadavka, program webového servera k nemu vytvorí nové sieťové pripojenie, aby odoslal parametre požiadavky a prečítal jej dátovú odpoveď, potom sa sieťové pripojenie uzavrie.
FastCGI
Externý FastCGI program (zvyčajne ide o proces) je raz spustený programom webového servera alebo iným programom/procesom a potom čaká na sieťové pripojenie, ktoré je trvalo nadviazané webovým serverom; cez toto spojenie sa posielajú parametre požiadavky a odpovede na načítanie dát.
Výpisy adresárov
Výpis adresárov dynamicky generovaný webovým serverom

Program webového servera môže byť schopný riadiť dynamické generovanie (za behu) zoznamu súborov a podadresárov indexu adresárov . [31]

Ak je na to nakonfigurovaný program webového servera a požadovaná adresa URL sa zhoduje s existujúcim adresárom a má povolený prístup a v tomto adresári sa nenašiel žiadny statický indexový súbor, potom sa zobrazí webová stránka (zvyčajne vo formáte HTML), ktorá obsahuje zoznam súborov a/alebo podadresáre vyššie uvedeného adresára, sa generuje dynamicky (za behu). Ak ho nemožno vygenerovať, vráti sa chyba.

Niektoré programy webového servera umožňujú prispôsobenie zoznamov adresárov tým, že umožňujú použitie šablóny webovej stránky (dokument HTML obsahujúci zástupné symboly, napr $(FILE_NAME), $(FILE_SIZE). atď., ktoré sú nahradené hodnotami polí každej položky súboru nájdenej v adresári webovým serverom), alebo index.tplpoužitím HTML a vloženého zdrojového kódu, ktorý sa interpretuje a vykonáva za behu, napr. index.asp, a/alebo podporou používania dynamických indexových programov, ako sú CGI, SCGI, FCGI index.cgi, napr index.php.index.fcgi

Používaniu dynamicky generovaných zoznamov adresárov sa zvyčajne vyhýbame alebo sa obmedzujú na niekoľko vybraných adresárov webovej lokality, pretože toto generovanie vyžaduje oveľa viac prostriedkov operačného systému ako odoslanie statickej indexovej stránky.

Hlavným využitím zoznamov adresárov je umožniť sťahovanie súborov (zvyčajne, keď sa ich názvy, veľkosti, dátumy a časy úprav alebo atribúty súborov môžu meniť náhodne/často) také, aké sú, bez toho, aby bolo potrebné poskytnúť ďalšie informácie žiadajúcemu používateľovi . [32]

Spracovanie programu alebo modulu

Externý program alebo interný modul ( procesná jednotka ) môže vykonávať nejaký druh aplikačnej funkcie, ktorú možno použiť na získanie údajov z jedného alebo viacerých dátových úložísk alebo na ich ukladanie do jedného alebo viacerých dátových úložísk , napr .

  • súbory (systém súborov);
  • databázy (DB);
  • iné zdroje umiestnené v lokálnom počítači alebo v iných počítačoch.

Spracovateľská jednotka môže vrátiť akýkoľvek druh webového obsahu, a to aj pomocou údajov získaných z úložiska údajov , napr .

V praxi vždy, keď existuje obsah, ktorý sa môže líšiť v závislosti od jedného alebo viacerých parametrov obsiahnutých v požiadavke klienta alebo v konfiguračných nastaveniach, potom sa zvyčajne generuje dynamicky.

Odoslať správu s odpoveďou

Programy webového servera sú schopné posielať správy s odpoveďami ako odpovede na správy požiadaviek klienta. [24]

Chybová odpoveď môže byť odoslaná, pretože správu s požiadavkou nebolo možné úspešne prečítať alebo dekódovať alebo analyzovať alebo vykonať. [25]

POZNÁMKA: Nasledujúce časti sú uvedené len ako príklady, ktoré vám pomôžu pochopiť, čo webový server viac či menej robí; tieto oddiely nie sú v žiadnom prípade vyčerpávajúce ani úplné.

Chybná správa

Program webového servera môže odpovedať na žiadosť klienta s mnohými druhmi chybových hlásení, v každom prípade sú tieto chyby rozdelené hlavne do dvoch kategórií:

Keď klientsky prehliadač prijme chybovú odpoveď/správu, potom ak súvisí s hlavnou požiadavkou používateľa (napr. URL webového zdroja, ako je webová stránka), potom sa táto chybová správa zvyčajne zobrazí v niektorom okne prehliadača/správe .

Autorizácia adresy URL

Program webového servera môže byť schopný overiť, či požadovaná cesta URL: [35]

  • môžu byť voľne prístupné pre každého;
  • vyžaduje overenie používateľa (vyžiadanie poverení používateľa, napr. používateľského mena a hesla );
  • prístup je zakázaný niektorým alebo všetkým typom používateľov.

Ak bola implementovaná a povolená funkcia autorizácie / prístupových práv a nie je udelený prístup k webovému zdroju, potom v závislosti od požadovaných prístupových práv program webového servera:

  • môže odmietnuť prístup odoslaním konkrétneho chybového hlásenia (napr. prístup zakázaný );
  • môže odmietnuť prístup odoslaním špecifickej chybovej správy (napr. neoprávnený prístup ), ktorá zvyčajne núti klientsky prehliadač požiadať ľudského používateľa o poskytnutie požadovaných používateľských poverení; ak sú poskytnuté overovacie údaje, program webového servera ich overí a prijme alebo odmietne.

presmerovanie URL

Program webového servera môže mať schopnosť robiť presmerovania URL na nové URL (nové miesta), čo spočíva v odpovedi na správu s požiadavkou klienta správou s odpoveďou obsahujúcou novú URL vhodnú na prístup k platnému alebo existujúcemu webovému zdroju (klient by to mal zopakovať žiadosť s novou adresou URL). [36]

Používa sa presmerovanie adresy URL: [36]

  • opraviť názov adresára pridaním poslednej lomky '/'; [31]
  • dať novú URL pre už neexistujúcu URL cestu novej ceste, kde sa dá nájsť tento druh webového zdroja.
  • na pridelenie novej adresy URL inej doméne, keď je aktuálna doména príliš zaťažená.

Príklad 1: Cesta URL ukazuje na názov adresára , ale nemá koncovú lomku '/', takže webový server odošle klientovi presmerovanie, aby mu dal pokyn, aby zopakoval požiadavku s pevným názvom cesty. [31]

Od
  /directory1/directory2
do:
  /directory1/directory2/

Príklad 2: Celá sada dokumentov bola presunutá na webovú stránku , aby sa reorganizovali cesty ich súborového systému.

Od
  /directory1/directory2/2021-10-08/
do:
  /directory1/directory2/2021/10/08/

Príklad 3: Celá sada dokumentov bola presunutá na novú webovú stránku a teraz je na prístup k nim povinné používať zabezpečené pripojenia HTTPS.

Od
  http://www.example.com/directory1/directory2/2021-10-08/
do:
  https://docs.example.com/directory1/2021-10-08/

Vyššie uvedené príklady sú len niektoré z možných druhov presmerovaní.

Úspešná správa

Program webového servera je schopný odpovedať na platnú správu požiadavky klienta úspešnou správou, ktorá voliteľne obsahuje požadované údaje o webovom zdroji . [37]

Ak sú dáta webového zdroja odoslané späť klientovi, potom to môže byť statický obsah alebo dynamický obsah v závislosti od toho, ako bol získaný (zo súboru alebo z výstupu nejakého programu / modulu).

Obsah vyrovnávacej pamäte

S cieľom zrýchliť odozvy webového servera znížením priemerných časov odozvy HTTP a použitých hardvérových zdrojov mnohé populárne webové servery implementujú jednu alebo viac vyrovnávacích pamätí obsahu , pričom každá sa špecializuje na kategóriu obsahu. [38] [39]

Obsah sa zvyčajne ukladá do vyrovnávacej pamäte podľa jeho pôvodu, napr.

  • statický obsah:
    • vyrovnávacia pamäť súborov;
  • dynamický obsah:
    • dynamická vyrovnávacia pamäť (výstup modulu / programu).

Súborová vyrovnávacia pamäť

Historicky sa statický obsah nachádzajúci sa v súboroch , ku ktorým bolo potrebné pristupovať často, náhodne a rýchlo, ukladal väčšinou na elektromechanické disky od polovice 60. / 70. rokov 20. storočia; žiaľ, čítanie z takýchto zariadení a zápisy na ne sa vždy považovali za veľmi pomalé operácie v porovnaní s rýchlosťou RAM , a preto sa od skorých operačných systémov vyvinuli najprv diskové vyrovnávacie pamäte a potom aj podsystémy súborovej vyrovnávacej pamäte OS na zrýchlenie I/O operácií . často používaných údajov/súborov.

Dokonca aj s pomocou vyrovnávacej pamäte súborov OS sa relatívna / občasná pomalosť I/O operácií zahŕňajúcich adresáre a súbory uložené na diskoch čoskoro stala prekážkou vo zvyšovaní výkonu očakávaného od špičkových webových serverov, najmä od polovice konca 90-tych rokov, keď webový internetový prenos začal exponenciálne rásť spolu s neustálym zvyšovaním rýchlosti internetu / sieťových liniek.

Problém, ako ďalej efektívne zrýchliť obsluhu statických súborov, a tým zvýšiť maximálny počet požiadaviek/odpovedí za sekundu (RPS), sa začal študovať / skúmať od polovice 90. rokov s cieľom navrhnúť užitočné modely vyrovnávacej pamäte, ktoré môžu byť implementované v programoch webového servera. [40]

V súčasnosti v praxi mnoho populárnych / vysokovýkonných programov webového servera obsahuje vlastnú vyrovnávaciu pamäť súborov používateľa , prispôsobenú pre použitie webového servera a využívajúcu ich špecifickú implementáciu a parametre. [41] [42] [43]

Široké používanie RAID a/alebo rýchlych SSD (úložný hardvér s veľmi vysokou I/O rýchlosťou) mierne znížilo, ale samozrejme neodstránilo výhodu, že vo webovom serveri je zabudovaná vyrovnávacia pamäť súborov.

Dynamická vyrovnávacia pamäť

Dynamický obsah, výstup interným modulom alebo externým programom, sa nemusí vždy meniť veľmi často (vzhľadom na unikátnu URL s kľúčmi/parametrami) a tak možno na chvíľu (napr. od 1 sekundy po niekoľko hodín alebo viac) výstup môže byť uložený v pamäti RAM alebo dokonca na rýchlom disku . [44]

Typické použitie dynamickej vyrovnávacej pamäte je, keď má webová stránka dynamické webové stránky o správach, počasí, obrázkoch, mapách atď., ktoré sa často nemenia (napr. každých n minút) a na ktoré za minútu pristupuje veľké množstvo klientov / hodina; v týchto prípadoch je užitočné vrátiť aj obsah uložený vo vyrovnávacej pamäti (bez volania interného modulu alebo externého programu), pretože klienti často nemajú aktualizovanú kópiu požadovaného obsahu vo vyrovnávacej pamäti prehliadača. [45]

Vo väčšine prípadov sú tieto druhy vyrovnávacích pamätí implementované externými servermi (napr. reverzný proxy ) alebo ukladaním dynamických dátových výstupov do samostatných počítačov, spravovaných špecifickými aplikáciami (napr. memcached ), aby nesúťažili o hardvérové ​​zdroje (CPU, RAM , disky) s webovým serverom (servermi). [46] [47]

Webové servery v režime jadra a v používateľskom režime

Softvér webového servera môže byť buď začlenený do operačného systému a spustený v priestore jadra , alebo môže byť spustený v používateľskom priestore (ako iné bežné aplikácie).

Webové servery, ktoré bežia v režime jadra (zvyčajne nazývané webové servery s priestorom jadra ), môžu mať priamy prístup k zdrojom jadra, a tak môžu byť teoreticky rýchlejšie ako tie, ktoré bežia v používateľskom režime; každopádne existujú nevýhody spustenia webového servera v režime jadra, napr.: ťažkosti pri vývoji ( ladení ) softvéru, zatiaľ čo kritické chyby pri behu môžu viesť k vážnym problémom v jadre OS.

Webové servery, ktoré bežia v užívateľskom režime, musia požiadať systém o povolenie použiť viac pamäte alebo viac zdrojov CPU . Nielenže tieto požiadavky na jadro vyžadujú čas, ale nemusia byť vždy uspokojené, pretože systém si vyhradzuje zdroje pre svoje vlastné použitie a je zodpovedný za zdieľanie hardvérových prostriedkov so všetkými ostatnými spustenými aplikáciami. Spustenie v užívateľskom režime môže tiež znamenať použitie väčšieho množstva vyrovnávacej pamäte/kópií údajov (medzi užívateľským priestorom a priestorom jadra), čo môže viesť k zníženiu výkonu webového servera v užívateľskom režime.

V súčasnosti sa takmer všetok softvér webového servera spúšťa v užívateľskom režime (pretože mnohé z vyššie uvedených malých nevýhod boli prekonané rýchlejším hardvérom, novými verziami OS, oveľa rýchlejšími systémovými volaniami OS a novým optimalizovaným softvérom webového servera). Pozrite si tiež porovnanie softvéru webového servera , aby ste zistili, ktoré z nich bežia v režime jadra alebo v používateľskom režime (tiež označované ako priestor jadra alebo používateľský priestor).

Vystúpenia

Na zlepšenie používateľskej skúsenosti (na strane klienta/prehliadača) by webový server mal rýchlo (čo najskôr) odpovedať na požiadavky klientov; pokiaľ nie je odozva obsahu obmedzená (konfiguráciou) pre niektoré typy súborov (napr. veľké alebo veľké súbory), aj vrátený dátový obsah by sa mal odosielať čo najrýchlejšie (vysoká prenosová rýchlosť).

Inými slovami, webový server by mal byť vždy veľmi pohotový , a to aj pri vysokej záťaži webovej prevádzky, aby celkové čakanie používateľa (súčet času prehliadača + času siete + času odozvy webového servera ) na odpoveď bolo čo najnižšie .

Metriky výkonnosti

V prípade softvéru webového servera sú hlavné kľúčové metriky výkonu (merané za rôznych prevádzkových podmienok) zvyčajne aspoň tieto (tj): [48]

  • početpožiadavky za sekundu (RPS, podobne akoQPS, v závislosti od verzie a konfigurácie HTTP, typu požiadaviek HTTP a iných prevádzkových podmienok);
  • počet pripojení za sekundu ( CPS ), je počet pripojení za sekundu akceptovaných webovým serverom (užitočné pri použití HTTP/1.0 alebo HTTP/1.1 s veľmi nízkym limitom požiadaviek / odpovedí na pripojenie, tj 1 .. 20);
  • latencia siete + čas odozvy pre každú novú požiadavku klienta; zvyčajne benchmarkový nástroj ukazuje, koľko požiadaviek bolo uspokojených v rámci škály časových úsekov (napr. v rámci 1 ms, 3 ms, 5 ms, 10 ms, 20 ms, 30 ms, 40 ms) a/alebo najkratší, priemerný a najdlhší čas odozvy;
  • priepustnosť odpovedí v bajtoch za sekundu.

Spomedzi prevádzkových podmienok je dôležitým parametrom počet (1 .. n ) súbežných klientskych pripojení použitých počas testu, pretože umožňuje korelovať úroveň súbežnosti podporovanú webovým serverom s výsledkami testovaných výkonnostných metrík.

Efektívnosť softvéru

Špecifický dizajn a model softvéru webového servera (napr.):

  • jeden proces alebo viac procesov;
  • jedno vlákno (bez vlákna) alebo viacvláknové pre každý proces;
  • používanie korutínov alebo nie;

... a ďalšie programovacie techniky , ako napríklad (napr.):

... používa na implementáciu programu webového servera, môže výrazne ovplyvniť výkon a najmä úroveň škálovateľnosti , ktorú možno dosiahnuť pri veľkom zaťažení alebo pri použití špičkového hardvéru (veľa CPU, diskov a veľa pamäte RAM).

V praxi môžu niektoré softvérové ​​modely webového servera vyžadovať viac zdrojov operačného systému (najmä viac CPU a viac RAM) ako iné, aby mohli dobre fungovať a tak dosiahnuť cieľový výkon.

Prevádzkové podmienky

Existuje mnoho prevádzkových podmienok, ktoré môžu ovplyvniť výkon webového servera; hodnoty výkonu sa môžu líšiť v závislosti od (napr.):

  • nastavenia webového servera (vrátane skutočnosti, že logovací súbor je alebo nie je povolený atď.);
  • verzia HTTP používaná požiadavkami klienta;
  • priemerný typ HTTP požiadavky (metóda, dĺžka HTTP hlavičiek a voliteľné telo);
  • či je požadovaný obsah statický alebo dynamický;
  • či je obsah vo vyrovnávacej pamäti alebo nie (serverom a/alebo klientom);
  • či je obsah komprimovaný za behu (pri prenose), predkomprimovaný (tj keď je súborový zdroj uložený na disku už komprimovaný, takže webový server môže poslať tento súbor priamo do siete s jediným náznakom, že jeho obsah je komprimovaný) alebo nie je stlačený vôbec;
  • či spojenia sú alebo nie sú šifrované;
  • priemerná rýchlosť siete medzi webovým serverom a jeho klientmi;
  • počet aktívnych TCP spojení;
  • počet aktívnych procesov riadených webovým serverom (vrátane externých programov CGI, SCGI, FCGI);
  • hardvérové ​​a softvérové ​​obmedzenia alebo nastavenia OS počítača (počítačov) , na ktorých beží webový server;
  • iné menšie podmienky.

Benchmarking

Výkonnosť webového servera sa zvyčajne porovnáva pomocou jedného alebo viacerých dostupných nástrojov na automatické testovanie záťaže .

Limity zaťaženia

Webový server (inštalácia programu) má zvyčajne preddefinované limity zaťaženia pre každú kombináciu prevádzkových podmienok, a to aj preto, že je limitovaný zdrojmi OS a preto, že zvládne len obmedzený počet súbežných klientskych pripojení (zvyčajne 2 až niekoľko desiatok tisíce za každý aktívny proces webového servera, pozri tiež problém C10k a problém C10M ).

Keď sa webový server blíži alebo prekračuje limity zaťaženia, je preťažený , a preto môže prestať reagovať .

Príčiny preťaženia

Webové servery môžu byť kedykoľvek preťažené v dôsledku jednej alebo viacerých z nasledujúcich príčin (napr.).

  • Nadmerný legitímny webový prenos . Tisíce alebo dokonca milióny klientov sa pripájajú na webovú stránku v krátkom čase, napr. efekt Slashdot .
  • Distribuované útoky odmietnutia služby . Útok odmietnutia služby (DoS útok) alebo distribuovaný útok odmietnutia služby (DDoS útok) je pokus zneprístupniť počítač alebo sieťový zdroj určeným používateľom.
  • Počítačové červy , ktoré niekedy spôsobujú abnormálnu prevádzku kvôli miliónom infikovaných počítačov (nie sú medzi nimi koordinované).
  • XSS červy môžu spôsobiť vysokú návštevnosť kvôli miliónom infikovaných prehliadačov alebo webových serverov.
  • Internetové roboty Prevádzka nie je filtrovaná/obmedzená na veľkých webových stránkach s veľmi malým počtom sieťových zdrojov (napr. šírka pásma ) a/alebo hardvérových zdrojov (CPU, RAM, disky).
  • Internet (sieť) sa spomaľuje (napr. kvôli stratám paketov), ​​takže požiadavky klientov sú obsluhované pomalšie a počet spojení sa zvyšuje natoľko, že sa dosahujú limity servera.
  • Webové servery, obsluhujúce dynamický obsah , čakanie na pomalé odpovede prichádzajúce z koncových počítačov (napr. databáz ), možno kvôli príliš veľkému množstvu dopytov zmiešaných s príliš veľkým počtom vkladov alebo aktualizácií údajov databázy; v týchto prípadoch musia webové servery čakať na odozvy koncových údajov, kým odpovedia HTTP klientom, ale počas týchto čakaní prichádza príliš veľa nových klientskych pripojení/požiadaviek, a tak sú preťažené.
  • Čiastočná nedostupnosť webových serverov ( počítačov ) . Môže k tomu dôjsť v dôsledku potrebnej alebo naliehavej údržby alebo aktualizácie, zlyhania hardvéru alebo softvéru, ako je zlyhanie koncového zariadenia (napr. databázy ); v týchto prípadoch môžu mať zostávajúce webové servery príliš veľkú návštevnosť a môžu byť preťažené.

Príznaky preťaženia

Príznaky preťaženého webového servera sú zvyčajne nasledovné (napr.).

  • Žiadosti sa doručujú s (možno dlhým) oneskorením (od 1 sekundy do niekoľkých stoviek sekúnd).
  • Webový server vráti kód chyby HTTP , ako napríklad 500, 502, [49] [50] 503, [51] 504, [52] 408 alebo dokonca prerušovaný kód 404 .
  • Webový server odmietne alebo obnoví (preruší) TCP spojenia predtým, ako vráti akýkoľvek obsah.
  • Vo veľmi zriedkavých prípadoch webový server vráti iba časť požadovaného obsahu. Toto správanie možno považovať za chybu , aj keď zvyčajne vzniká ako príznak preťaženia.

Techniky proti preťaženiu

Na čiastočné prekonanie nadpriemerných limitov zaťaženia a na zabránenie preťaženiu väčšina populárnych webových stránok používa bežné techniky, ako sú nasledujúce (napr.).

  • Ladenie parametrov OS pre možnosti hardvéru a využitie.
  • Ladenie parametrov webového servera (serverov) na zlepšenie ich bezpečnosti a výkonu.
  • Nasadenie techník webovej vyrovnávacej pamäte (nielen pre statický obsah, ale vždy, keď je to možné, aj pre dynamický obsah).
  • Správa sieťovej prevádzky pomocou:
    • Firewally na blokovanie nechcenej prevádzky prichádzajúcej zo zlých zdrojov IP alebo so zlými vzormi;
    • správcovia prenosu HTTP na vynechanie, presmerovanie alebo prepísanie požiadaviek so zlými vzormi HTTP ;
    • Správa šírky pásma a tvarovanie prevádzky , aby sa vyrovnali špičky v používaní siete.
  • Používanie rôznych názvov domén , IP adries a počítačov na poskytovanie rôznych druhov (statického a dynamického) obsahu; cieľom je oddeliť veľké alebo veľké súbory ( download.*) (táto doména môže byť nahradená aj CDN ) od malých a stredne veľkých súborov ( static.*) a od hlavnej dynamickej stránky (možno tam, kde je nejaký obsah uložený v backendovej databáze ) ( www.*) ; myšlienkou je byť schopný efektívne obsluhovať veľké alebo veľké (nad 10 – 1000 MB) súbory (možno spomaliť sťahovanie) a plne ukladať malé a stredne veľké súbory do vyrovnávacej pamäte bez ovplyvnenia výkonu dynamickej stránky pri veľkom zaťažení pomocou rôznych nastavení pre každú (skupinu) počítačov webového servera, napr.
    • https://download.example.com
    • https://static.example.com
    • https://www.example.com
  • Používanie mnohých webových serverov (počítačov), ktoré sú zoskupené za nástrojom na vyrovnávanie záťaže , takže fungujú alebo sú vnímané ako jeden veľký webový server.
  • Pridanie ďalších hardvérových prostriedkov (napr. RAM , rýchle disky ) do každého počítača.
  • Používanie efektívnejších počítačových programov pre webové servery (pozri tiež: efektívnosť softvéru).
  • Použitie najefektívnejšieho rozhrania brány webového servera na spracovanie dynamických požiadaviek (vytvorenie jedného alebo viacerých externých programov zakaždým, keď sa načíta dynamická stránka, zastavuje výkon).
  • Používanie iných programovacích techník a riešení , najmä ak ide o dynamický obsah, na urýchlenie odpovedí HTTP (tj vyhýbaním sa dynamickým volaniam na načítanie objektov, ako sú šablóny so štýlmi, obrázky a skripty), ktoré sa nikdy nemenia alebo sa nemenia veľmi zriedkavo, kopírovaním tento obsah raz do statických súborov a potom ich synchronizovať s dynamickým obsahom).
  • Používanie najnovších efektívnych verzií HTTP (napr. okrem používania bežného HTTP/1.1 aj povolením HTTP/2 a možno aj HTTP/3 , kedykoľvek dostupný softvér webového servera má spoľahlivú podporu pre posledné dva protokoly), aby sa výrazne znížil počet Pripojenia TCP/IP spustené každým klientom a veľkosť vymieňaných údajov (kvôli kompaktnejšej reprezentácii hlavičiek HTTP a možno aj kompresii údajov).

Výstrahy týkajúce sa používania protokolov HTTP/2 a HTTP/3

Aj keď novšie protokoly HTTP (2 a 3) zvyčajne generujú menšiu sieťovú prevádzku pre každú požiadavku/odpoveď, môžu vyžadovať viac zdrojov OS (tj RAM a CPU) používaných softvérom webového servera (kvôli šifrovaným údajom , množstvu vyrovnávacích pamätí toku a ďalšie podrobnosti o implementácii); okrem toho HTTP/2 a možno aj HTTP/3, v závislosti aj od nastavení webového servera a klientskeho programu, nemusia byť tou najlepšou možnosťou pre nahrávanie dát veľkých alebo veľkých súborov veľmi vysokou rýchlosťou, pretože ich dátové toky sú optimalizované pre súbežnosť žiadostí, a tak v mnohých prípadoch môže použitie pripojení HTTP/1.1 TCP/IP viesť k lepším výsledkom/vyššej rýchlosti nahrávania (vaša vzdialenosť sa môže líšiť) . [53] [54]

Podiel na trhu

Graf:
Trhový podiel všetkých stránok pre najpopulárnejšie webové servery v rokoch 2005–2021
Graf:
Trhový podiel všetkých stránok pre najpopulárnejšie webové servery v rokoch 1995–2005

Nižšie sú uvedené najnovšie štatistiky trhového podielu všetkých stránok špičkových webových serverov na internete od spoločnosti Netcraft .

Webový server: Podiel všetkých stránok na trhu
Dátum nginx (Nginx, Inc.) Apache ( ASF ) OpenResty (OpenResty Software Foundation) Server Cloudflare ( Cloudflare, Inc. ) IIS ( Microsoft ) GWS ( Google ) Iní
október 2021 [55] 34,95 % 24,63 % 6,45 % 4,87 % 4,00 % (*) 4,00 % (*) Menej ako 22 %
február 2021 [56] 34,54 % 26,32 % 6,36 % 5,0 % 6,5 % 3,90 % menej ako 18 %
február 2020 [57] 36,48 % 24,5 % 4,00 % 3,0 % 14,21 % 3,18 % menej ako 15 %
február 2019 [58] 25,34 % 26,16 % N/A N/A 28,42 % 1,66 % Menej ako 19 %
február 2018 [59] 24,32 % 27,45 % N/A N/A 34,50 % 1,20 % menej ako 13 %
február 2017 [60] 19,42 % 20,89 % N/A N/A 43,16 % 1,03 % menej ako 15 %
február 2016 [61] 16,61 % 32,80 % N/A N/A 29,83 % 2,21 % Menej ako 19 %

POZNÁMKA: (*) percento zaokrúhlené na celé číslo, pretože jeho desatinné hodnoty nie sú verejne uvádzané zdrojovou stránkou (v grafe je uvedená iba zaokrúhlená hodnota).

Pozri tiež

Štandardné rozhrania brány webového servera používané pre dynamický obsah :

Niekoľko ďalších rozhraní webového servera ( špecifické pre server alebo programovací jazyk ) používaných pre dynamický obsah:

  • SSI Server Side Zahŕňa zriedkavo používané statické dokumenty HTML obsahujúce direktívy SSI, ktoré serverový softvér interpretuje tak, aby obsahovali malé dynamické údaje za chodu, keď sú stránky obsluhované, napr. dátum a čas, iný obsah statického súboru atď.
  • Aplikačné programové rozhranie servera SAPI :
    • ISAPI Internet Server Application Programming Interface
    • Aplikačné programové rozhranie servera NSAPI Netscape
  • Rozhranie brány webového servera PSGI Perl
  • Rozhranie brány webového servera WSGI Python
  • Rack Rack Rozhranie brány webového servera
  • Rozhranie brány webového servera JSGI JavaScript
  • Java Servlet , JavaServer Pages
  • Active Server Pages , ASP.NET

Referencie

  1. ^ abc Nancy J. Yeager; Robert E. McGrath (1996). Technológia webového servera. Morgan Kaufmann. ISBN 1-55860-376-X. Archivované z originálu 20. januára 2023 . Získané 22. januára 2021 .
  2. ^ William Nelson; Arvind Srinivasan; Murthy Chintalapati (2009). Webový server Sun: Základná príručka. Pearsonovo vzdelávanie. ISBN 978-0-13-712892-1. Archivované z originálu 20. januára 2023 . Získané 14. októbra 2021 .
  3. ^ Zolfagharifard, Ellie (24. novembra 2018). "Otec webu" Sir Tim Berners-Lee o svojom pláne bojovať proti falošným správam . " The Telegraph . Londýn. ISSN  0307-1235. Archivované z originálu 11. januára 2022 . Získané 1. februára 2019 .
  4. ^ "História počítačov a výpočtovej techniky, internet, narodenie, svetová sieť Tima Bernersa-Leeho". history-computer.com . Archivované z originálu 4. januára 2019 . Získané 1. februára 2019 .
  5. ^ Abc Tim Berner-Lee (1992). "História projektu WWW (originál)". CERN (projekt World Wide Web). Archivované z originálu 8. decembra 2021 . Získané 20. decembra 2021 .
  6. ^ Ab Tim Berner-Lee (20. augusta 1991). "K dispozícii je celoplošná hypertextová aplikácia WorldWideWeb (oznámenie)". CERN (projekt World Wide Web). Archivované z originálu 2. decembra 2021 . Získané 16. októbra 2021 .
  7. ^ ab Webový administrátor. „Webová história“. CERN (projekt World Wide Web). Archivované z originálu 2. decembra 2021 . Získané 16. októbra 2021 .
  8. ^ Tim Berner-Lee (2. august 1991). "Kvalifikátory na hypertextových odkazoch ..." CERN (projekt World Wide Web). Archivované z originálu 7. decembra 2021 . Získané 16. októbra 2021 .
  9. ^ Ali Mesbah (2009). Analýza a testovanie jednostránkových webových aplikácií založených na Ajaxe. ISBN 978-90-79982-02-8. Získané 18. decembra 2021 .
  10. ^ ab Robert H'obbes' Zakon. "Hobbesova časová os internetu v5.1 (Rast WWW) POZNÁMKA: do roku 1996 počet webových serverov = počet webových stránok". ISOC. Archivované z originálu 15. augusta 2000 . Získané 18. decembra 2021 .{{cite web}}: CS1 maint: unfit URL (link)
  11. ^ Tim Smith; François Flückiger. "Licencovanie webu". CERN (projekt World Wide Web). Archivované z originálu 6. decembra 2021 . Získané 16. októbra 2021 .
  12. ^ "NCSA httpd". NCSA (webový archív). Archivované z originálu 1. augusta 2010 . Získané 16. decembra 2021 .
  13. ^ „O serveri Apache HTTPd: Ako vznikol Apache“. Apache: Projekt servera HTTPd. 1997. Archivované z originálu 7. júna 2008 . Získané 17. decembra 2021 .
  14. ^ „Prieskum webového servera, POZNÁMKA: Počet aktívnych webových stránok v roku 2000 bol interpolovaný“. Netcraft. 22. decembra 2021. Archivované z originálu 27. decembra 2021 . Získané 27. decembra 2021 .
  15. ^ "Netcraft: softvér webového servera (1996)". Netcraft (webový archív). Archivované z originálu 30. decembra 1996 . Získané 16. decembra 2021 .
  16. ^ "Prehľad nových funkcií v Apache 2.2". Apache: Projekt servera HTTPd. 2005. Archivované z originálu 27. novembra 2021 . Získané 16. decembra 2021 .
  17. ^ "Prehľad nových funkcií v Apache 2.4". Apache: Projekt servera HTTPd. 2012. Archivované z originálu 26. novembra 2021 . Získané 16. decembra 2021 .
  18. ^ "Spojenia, trvalé spojenia: praktické úvahy". RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1. s. 46–47. sek. 8.1.4. doi : 10.17487/RFC2616 . RFC 2616.
  19. ^ "Maximálny počet súbežných pripojení k rovnakej doméne pre prehliadače". 2017. Archivované z originálu 21. decembra 2021 . Získané 21. decembra 2021 .
  20. ^ „Benchmark výkonu webového servera Linux – výsledky za rok 2016“. RootUsers. 8. marca 2016. Archivované z originálu 23. decembra 2021 . Získané 22. decembra 2021 .
  21. ^ ab "Nahradí HTTP/2 HTTP/1.x?". Pracovná skupina HTTP IETF. Archivované z originálu 27. septembra 2014 . Získané 22. decembra 2021 .
  22. ^ ab "Implementácia HTTP/2 v klientskom a serverovom softvéri". Pracovná skupina HTTP IETF. Archivované z originálu 23. decembra 2021 . Získané 22. decembra 2021 .
  23. ^ "Prečo len jedno pripojenie TCP?". Pracovná skupina HTTP IETF. Archivované z originálu 27. septembra 2014 . Získané 22. decembra 2021 .
  24. ^ ab "Správy klienta/servera". RFC 7230, HTTP/1.1: Syntax a smerovanie správ. s. 7–8. sek. 2.1. doi : 10.17487/RFC7230 . RFC 7230.
  25. ^ ab "Spracovanie neúplných správ". RFC 7230, HTTP/1.1: Syntax a smerovanie správ. p. 34. sek. 3.4. doi : 10.17487/RFC7230 . RFC 7230.
  26. ^ "Odolnosť analýzy správ". RFC 7230, HTTP/1.1: Syntax a smerovanie správ. s. 34–35. sek. 3.5. doi : 10.17487/RFC7230 . RFC 7230.
  27. ^ R. Bowen (29. september 2002). "Mapovanie URL" (PDF) . Softvérový základ Apache. Archivované (PDF) z originálu 15. novembra 2021 . Získané 15. novembra 2021 .
  28. ^ abcde "Mapovanie adries URL na umiestnenia systému súborov". Apache: Projekt servera HTTPd. 2021. Archivované z originálu 20. októbra 2021 . Získané 19. októbra 2021 .
  29. ^ "Dynamický obsah s CGI". Apache: Projekt servera HTTPd. 2021. Archivované z originálu 15. novembra 2021 . Získané 19. októbra 2021 .
  30. ^ Chris Shiflett (2003). Príručka pre vývojárov HTTP. Samsovo vydavateľstvo. ISBN 0-672-32454-7. Archivované z originálu 20. januára 2023 . Získané 9. decembra 2021 .
  31. ^ abc ASF Infrabot (22. mája 2019). "Výpisy adresárov". Základ Apache: Projekt servera HTTPd. Archivované z originálu 7. júna 2019 . Získané 16. novembra 2021 .
  32. ^ "Apache: zoznam adresárov na sťahovanie súborov". Apache: HTTPd server. Archivované z originálu 2. decembra 2021 . Získané 16. decembra 2021 .
  33. ^ "Chyba klienta 4xx". RFC 7231, HTTP/1.1: Sémantika a obsah. p. 58. sek. 6.5. doi : 10.17487/RFC7231 . RFC 7231.
  34. ^ "Chyba servera 5xx". RFC 7231, HTTP/1.1: Sémantika a obsah. s. 62-63. sek. 6.6. doi : 10.17487/RFC7231 . RFC 7231.
  35. ^ "Úvod". RFC 7235, HTTP/1.1: Autentifikácia. p. 3. sek. 1. doi : 10.17487/RFC7235 . RFC 7235.
  36. ^ ab "Kódy stavu odpovede: Presmerovanie 3xx". RFC 7231, HTTP/1.1: Sémantika a obsah. s. 53–54. sek. 6.4. doi : 10.17487/RFC7231 . RFC 7231.
  37. ^ "Úspešné 2xx". RFC 7231, HTTP/1.1: Sémantika a obsah. s. 51-54. sek. 6.3. doi : 10.17487/RFC7231 . RFC 7231.
  38. ^ "Sprievodca ukladaním do vyrovnávacej pamäte". Apache: Projekt servera HTTPd. 2021. Archivované z originálu 9. decembra 2021 . Získané 9. decembra 2021 .
  39. ^ "Ukladanie obsahu do vyrovnávacej pamäte NGINX". F5 NGINX. 2021. Archivované z originálu 9. decembra 2021 . Získané 9. decembra 2021 .
  40. ^ Evangelos P. Markatos (1996). "Ukladanie webových dokumentov do hlavnej pamäte". Počítačové siete a ISDN systémy. Archivované z originálu 20. januára 2023 . Získané 9. decembra 2021 .
  41. ^ "Webový server IPlanet 7.0.9: vyrovnávacia pamäť súborov". Oracle. 2010. Archivované z originálu 9. decembra 2021 . Získané 9. decembra 2021 .
  42. ^ "Modul Apache mod_file_cache". Apache: Projekt servera HTTPd. 2021. Archivované z originálu 9. decembra 2021 . Získané 9. decembra 2021 .
  43. ^ "HTTP server: konfigurácia: vyrovnávacia pamäť súborov". GNU. 2021. Archivované z originálu 9. decembra 2021 . Získané 9. decembra 2021 .
  44. ^ "Modul Apache mod_cache_disk". Apache: Projekt servera HTTPd. 2021. Archivované z originálu 9. decembra 2021 . Získané 9. decembra 2021 .
  45. ^ "Čo je dynamická vyrovnávacia pamäť?". Vzdelávacie. 2021. Archivované z originálu 9. decembra 2021 . Získané 9. decembra 2021 .
  46. ^ „Výukový program pre možnosti dynamickej vyrovnávacej pamäte“. Siteground. 2021. Archivované z originálu 20. januára 2023 . Získané 9. decembra 2021 .
  47. ^ Arun Iyengar; Jim Challenger (2000). „Zlepšenie výkonu webového servera ukladaním dynamických údajov do vyrovnávacej pamäte“. Usenix . Získané 9. decembra 2021 .
  48. ^ Jussara M. Almeida ; Virgilio Almeida; David J. Yates (7. júla 1997). "WebMonitor: nástroj na meranie výkonnosti servera World Wide Web". Prvý pondelok . doi : 10.5210/fm.v2i7.539 . Archivované z originálu 4. novembra 2021 . Získané 4. novembra 2021 .
  49. ^ Fisher, Tim; Lifewire. "Získava sa chyba 502 Bad Gateway? Tu je to, čo robiť". Lifewire . Archivované z originálu 23. februára 2017 . Získané 1. februára 2019 .
  50. ^ "Čo je zlá brána 502 a ako ju opravíte?". IT PRO . Archivované z originálu 20. januára 2023 . Získané 1. februára 2019 .
  51. ^ Fisher, Tim; Lifewire. "Získanie chyby nedostupnosti služby 503? Tu je to, čo robiť". Lifewire . Archivované z originálu 20. januára 2023 . Získané 1. februára 2019 .
  52. ^ Fisher, Tim; Lifewire. "Získava sa chyba časového limitu brány 504? Tu je to, čo robiť". Lifewire . Archivované z originálu 23. apríla 2021 . Získané 1. februára 2019 .
  53. ^ veľa (24. januára 2021). "Pomalé nahrávanie s HTTP/2". github. Archivované z originálu 16. novembra 2021 . Získané 15. novembra 2021 .
  54. ^ Junho Choi (24. augusta 2020). „Poskytovanie zlepšení rýchlosti nahrávania HTTP/2“. Cloudflare. Archivované z originálu 16. novembra 2021 . Získané 15. novembra 2021 .
  55. ^ "Prieskum webového servera z októbra 2021". Netcraft . 15. októbra 2021. Archivované z originálu 15. novembra 2021 . Získané 15. novembra 2021 .
  56. ^ "Prieskum webového servera z februára 2021". Netcraft . 26. februára 2021. Archivované z originálu 15. apríla 2021 . Získané 8. apríla 2021 .
  57. ^ "Prieskum webového servera vo februári 2020". Netcraft . 20. februára 2020. Archivované z originálu 17. apríla 2021 . Získané 8. apríla 2021 .
  58. ^ „Prieskum webového servera z februára 2019“. Netcraft . 28. februára 2019. Archivované z originálu 15. apríla 2021 . Získané 8. apríla 2021 .
  59. ^ "Prieskum webového servera z februára 2018". Netcraft . 13. februára 2018. Archivované z originálu 17. apríla 2021 . Získané 8. apríla 2021 .
  60. ^ "Prieskum webového servera z februára 2017". Netcraft . 27. 2. 2017. Archivované z originálu 14. 3. 2017 . Získané 13. marca 2017 .
  61. ^ "Prieskum webového servera z februára 2016". Netcraft . 22. 2. 2016. Archivované z originálu 27. 1. 2022 . Získané 27. januára 2022 .

vonkajšie odkazy

  • Mozilla: čo je webový server?
  • Netcraft: novinky o prieskume webového servera
Retrieved from "https://en.wikipedia.org/w/index.php?title=Web_server&oldid=1211334957"