Apache vs Nginx: Consideratii practice

Blog: OS
 Apache si Nginx sunt doua dintre cele mai comune servere web open source din lume. Impreuna ele sunt responsabile pentru deservirea a peste 50% din traficul de pe internet. Ambele solutii sunt capabile sa suporte diverse sarcini de lucru si sa lucreze cu alte software-uri pentru a oferi o multime de solutii complete.

Introducere

Apache si Nginx sunt doua dintre cele mai comune servere web open source din lume. Impreuna ele sunt responsabile pentru deservirea a peste 50% din traficul de pe internet. Ambele solutii sunt capabile sa suporte diverse sarcini de lucru si sa lucreze cu alte software-uri pentru a oferi o multime de solutii complete.

In timp ce Apache si Nginx impartasesc multe calitati acestea nu ar trebui considerate pe deplin interschimbabile. Fiecare exceleaza in felul lui si este important sa intelegem situatiile in care va trebui sa reevaluam alegerea serverului web. Acest articol va fi dedicat unei discutii despre modul in care fiecare server se descurca in diverse domenii.

Privire de Ansamblu

Inainte de a aprofunda diferentele dintre Apache si Nginx, haideti sa aruncam o privire rapida la baza acestor doua proiecte si la caracteristicile lor generale.

Apache

Server-ul Apache HTTP a fost creat de Robert McCool in 1995 si a fost dezvoltat de catre Apache Software Foundation din 1999. Din moment ce web server-ul Apache este proiectul initial al fundatiei si de departe cel mai popular software, este adesea numit simplu „Apache”.

Web server-ul Apache a fost cel mai popular server de pe internet din 1996. Datorita popularitatii sale, Apache beneficiaza de o buna documentare si suport integrat din partea altor proiecte software.

Apache este adesea ales de administratori pentru flexibilitate, putere si suportul raspandit. Este extins printr-un sistem dinamic de module de incarcare si poate procesa un numar mare de limbi interpretate fara a se conecta la un alt software.

Nginx

In 2002, Igor Sysoev a inceput sa lucreze la Nginx ca raspuns la problema C10K, care a fost o provocare pentru serverele web pentru a incepe manipularea a zece mii de conexiuni concurente ca o cerinta pentru web-ul modern. Lansarea initiala  a fost facuta in 2004, atingerea acestui obiectiv bazandu-se pe o arhitectura asincron condusa de evenimente.

Nginx a crescut in popularitate de la lansare datorita utilizarii resurselor reduse si a capacitatii de a scala cu usurinta a unui hardware minim. Nginx exceleaza la oferirea rapida de continut static si este proiectat pentru a trece solicitarile dinamice catre alte software care sunt mai potrivite pentru acele scopuri.

Nginx este adesea ales de administratori pentru eficienta utilizarii resurselor si capacitatea de reactie in sarcina. Sustinatorii ureaza bun venit concentrarii pe nucleul server-ului web si pe caracteristicile de baza.

Arhitectura de Manevrare a Conectivitatii

Una din marile diferente dintre Apache si Nginx este modul actual prin care ele isi manevreaza conexiunile si traficul. Aceasta este probabil cea mai semnificativa diferenta in modul cum ele raspund la diferitele conditii de trafic.

Apache

Apache ofera o varietate de module multiple de procesare (Apache le numeste MPM) care dicteaza cum sunt manevrate cererile clientilor.  Practic, acest lucru le permite administratorilor sa schimbe cu usurinta conexiunea in arhitectura de manipulare. Acestea sunt:

  • mpm_prefork:

Acest modul de prelucrare a spawns processes  (proceselor  de inceput) cu un singur curs fiecare ocupandu-se de cerere. Fiecare proces de inceput se poate ocupa de o singura conexiune la un moment dat. Atata timp cat numarul cererilor este mai mic decat numarul procesarilor, MPM este foarte rapid. Oricum, performanta scade rapid dupa ce cererile depasesc numarul procesarilor, asa ca acesta nu este o alegere buna in multe scenarii. Fiecare proces are un impact semnificativ asupra consumului de RAM, asa ca acest MPM este dificil de masurat. Este in continuare o buna alegere, daca este folosit in combinatie cu alte componente care nu sunt construite cu mici secvente in memorie. (with threads in mind). De exemplu, PHP nu are un curs sigur, asa ca MPM este recomandat ca fiind singura modalitate sigura de lucru cu mod_php, pentru ca modulul Apache sa proceseze aceste fisiere.

  • mpm_worker:

Acest modul de spawns processes (procese tinere) pot fiecare gestiona mai multe fire. Fiecare dintre aceste fire poate manevra o singura conexiune.  Firele de actiune sunt mai eficiente decat procesele, ceea ce inseama ca acest MPM masoara mai bine decat prefork MPM. Din moment ce acolo sunt mai multe cursuri decat procese, acest lucru inseamna de asemenea ca noile conexiuni pot imediat sa urmeze un nou fir in loc sa astepte dupa un proces liber.

  • mpm_event:

Acest modul este similar cu modulul worker in majoritatea situatiilor, dar este optimizat sa se ocupe de conexiunile keep-alive. Cand utilizam modulul worker MPM, o conexiune va tine un fir indiferent daca o cerere este facuta in mod activ atata timp cat conexiunea persista. Modulul event MPM se ocupa de conexiunile persistente prin setarea de fire care sa mentina conexiunile si sa treaca solicitarile active catre alte fire.  Acesta impiedica blocarea modulului in urma cererilor persistente, permitandu-i executarea mai rapida. Acesta a devenit mai stabil odata cu lansarea Apache 2.4.
Dupa cum se poate vedea, Apache ofera o arhitectura mai flexibila prin alegerea conexiunilor si cererilor care se ocupa de algoritmi. Optiunea oferita este in special o functie a evolutiei server-ului si a cresterii concurentei de cand peisajul internetului s-a schimbat.

Nginx

Nginx a aparut dupa Apache, cu mai multa grija in ce priveste problemele concurentiale pe care le-ar putea avea site-urile la scalare. stiind acest lucru, Nginx a fost creat de la inceput sa foloseasca un asincron, fara a bloca, chiar sa manipuleze conducerea conexiunilor cu ajutorul algoritmului.

Procesele Nginx spawns worker, pot manevra fiecare sute de conexiuni. Procesele worker realizeaza acest lucru implementand un mecanism rapid care se roteste continuu verificand procesele evenimentelor. Decuplarea conexiunilor de la lucrul efectiv permite fiecarui lucrator sa se preocupe de o conexiune cand un nou eveniment a fost declansat.

Fiecare conexiune manuita de lucrator este plasata in interiorul evenimentului de rotire unde exista cu alte conexiuni. in procesul de rotire, evenimentele sunt procesate asincron, permitand muncii sa fie manevrata fara a fi blocata. Cand conexiunea se inchide este inlaturat din procesul de rotire.

Acest mod de procesare a conexiunii permite Nginx sa scaleze incredibil de departe cu resurse limitate. Din moment ce server-ul are un singur curs si procesele nu sunt limitate sa se ocupe de fiecare noua conexiune, memoria si utilizarea procesorului tind sa fie relativ consistente chiar si in momente grele de sarcina.

Continut Dinamic vs Continut Static

In conditii reale, una dintre cele mai comune comparatii dintre Apache si Nginx este modul cum fiecare server manevreaza continutul static si dinamic.

Apache

Serverele Apache pot manevra continutul static folosind metodele conventionale bazate pe fisiere. Performanta acestor operatii este mai mult o functie a metodelor MPM descrise mai sus.

Apache poate de asemenea procesa continut dinamic prin integrarea unui procesor al limbii in cauza pentru fiecare dintre situatii. Acesta permite sa execute continut dinamic in interiorul server-ului web fara a relationa cu alte componente din exterior. Aceste procesoare dinamice pot fi activate prin utilizarea modulelor incarcate dinamic.

Abilitatea Apache de a manevra continut dinamic intern inseamna ca acea configurare a procesului dinamic tinde sa fie simpla. Comunicarea nu are nevoie sa fie coordonata de o parte aditionala a unui software si modulele pot fi usor schimbate daca continutul se schimba.

Nginx

Nginx nu are abilitatea nativa de a procesa continut dinamic. Pentru a manevra PHP si alte cereri de continut dinamic, Nginx trebuie sa treaca pe un procesor extern pentru executie si sa astepte trimiterea continutului redat. Apoi rezultatele pot fi transmise clientului.

Pentru administratori, acest lucru inseamna ca trebuie sa configureze comunicatiile dintre Nginx si procesorul peste unul din protocoalele Nginx care stiu (http, FastCGI, SCGI, uWSGI, memcache). Acesta poate complica lucrurile putin, mai ales cand va incerca sa anticipeze numarul de conexiuni permise, pentru ca o conexiune aditionala va fi folosita de fiecare data de procesor.

Aceasta metoda are de asemenea  si avantaje. Din moment ce interpretarea dinamica nu este integrata in procesul de functionare, partea de deasupra va fi prezenta pentru continutul dinamic. Continutul static poate fi servit doar intr-o maniera directa si interpretorul va fi contactat doar la nevoie. si Apache poate functiona in acest fel, dar inlaturand beneficiile din sectiunea anterioara.

Configurarea Distribuita vs Configurarea Centralizata

Pentru administratori, una dintre aparentele cele mai evidente dintre aceste doua parti de software este daca configuratia la nivel de director este permisa in interiorul continutului directoarelor.

Apache

Apache include o optiune care permite configurarea aditionala pe fiecare director de baza inspectand si interpretand directivele din fisierele ascunse din interiorul directoarelor. Aceste fisiere sunt cunoscute ca fisiere .htaccess.

Din moment ce aceste fisiere se afla in interiorul continutului directoarelor, cand primesc o solicitare, Apache verifica fiecare componenta a partii de fisier cerute pentru un fisier .htaccess si aplica directivele gasite in interior. Acest lucru permite efectiv configurarea descentralizata a server-ului web care este adesea folosita pentru implementarea rescrierilor URL, restrictiilor de acces, autorizare si autentificare, chiar si a politicilor de caching.

In timp ce exemplele de mai sus pot fi configurate in fisierul principal de configurare, fisierele .htaccess au unele avantaje importante. Primul, din moment ce acestea sunt interpretate de fiecare data cand sunt gasite de-a lungul unei cai de solicitare, ele sunt implementate imediat fara a se incarca server-ul. Al doilea, face posibila permiterea utilizatorilor fara privilegii sa controleze aspecte certe ale continutului web propriu fara a le da control asupra intregului fisiere de configurare.

Acest lucru ofera o cale mai usoara pentru anumite tipuri de software web, cum ar fi sistemele de management al continutului, configurarea mediul fara sa ofere acces la fisierul central de configurare. Acesta este de asemenea folosit de catre providerii de web hosting pentru a mentine controlul configuratiei principale, in timp ce le ofera clientilor control doar asupra anumitor directoare.

Nginx

Nginx nu interpreteaza fisierele .htaccess, si nici nu ofera un mecanism pentru evaluarea configurarii din afara, pe director, a principalelor fisiere de configurare. Acesta este mai putin flexibil decat Apache dar are avantajele sale.

Cea mai notabila imbunatatire asupra sistemului de configurare la nivelul directorului .htaccess este performanta crescuta. Pentru o configurare tipica Apache acesta poate permite accesul .htaccess in orice director, server-ul va verifica existenta acestor fisiere in fiecare director principal mergand pana la fisierul cerut, pentru fiecare cerere. Daca unul sau mai multe fisiere .htaccess sunt gasite in timpul acestei cautari, ele trebuie citite si interpretate. Prin ne permiterea directorului de a trece peste, Nginx poate servi cereri mai repede decat ar face-o un singur director si citirea fisierelor pentru fiecare cerere (presupunand ca fisierul este gasit in structura conventionala a directorului).

Un alt avantaj este legat de securitate. Distribuind configurarea de acces a nivelului directorului distribuie de asemenea si responsabilitatea de securitate a utilizatorilor universali, care pot sa nu fie de incredere pentru a manevra aceasta sarcina corect. Asigurarea faptului ca administratorul pastreaza controlul asupra intregului server web poate preveni unele erori de securitate care pot aparea cand accesul este permis altor parti.

Nu uitati ca este posibil sa dezactivati interpretarea .htaccess in Apache, daca aceasta preocupare este in rezonanta cu dvs.

Fisier vs Interpretare URI-Based

Modul cum un server web interpreteaza cererile si hartile lor la resursele actuale ale sistemului este o alta zona unde aceste doua servere sunt diferite.

Apache

Apache ofera abilitatea de a interpreta o cerere ca pe o resursa fizica din sistemul de fisiere sau ca pe o locatie URI care are nevoie de o evaluare mai abstracta. in general, pentru primul Apache utilizatorii de blocuri/grupuri <Directory> sau <Files>, in timp ce se utiliza blocul/grupul <Location> pentru resurse mai abstracte.

Pentru ca Apache a fost construit de la inceput ca un server web, implici este normal sa interpreteze cereri ca resurse ale fisierului de sistem. incepe prin a lua documentul root aplicandu-i portiunea de cerere care urmeaza gazduirea si numarul de port pentru a incerca sa gaseasca un fisier actual. Practic, ierarhia fisierului de sistem este reprezentata pe internet ca un arbore de documente disponibile.

Apache ofera un numar de alternative pentru cand cererea nu se potriveste cu sistemul de fisiere care stau la baza. De exemplu, o directiva Alias poate fi folosita pentru a face o descriere unei locatii alternative. Folosind blocul/grupul <Location>  este o metoda de a lucra chiar cu URI si nu cu fisierul de sistem. Exista, de asemenea, variante obisnuite de expresii care pot fi folosite pentru a aplica configurarea mai flexibila in tot sistemul de fisiere.

In timp ce Apache are abilitatea de a opera atat in sistemul de fisiere cat si in spatiul web, dar inclina mai mult spre metodele sistemului de fisiere. Acest lucru poate fi vazut in unele decizii de proiectare, inclusiv utilizarea de fisiere .htaccess pentru configurarea directorului. insasi documentele  Apache avertizeaza impotriva folosirii blocurilor/grupurilor URI-based pentru a restrictiona accesul la cererile de mirrors care stau la baza.

Nginx

Nginx a fost creat sa fie server web si proxy server. Datorita arhitecturii cerute pentru aceste doua roluri, el lucreaza la baza cu URI, traducand sistemului de fisiere cand este necesar.

Acest lucru poate fi vazut in unele moduri in care fisierele de configurare Nginx sunt construite si interpretate. Nginx nu prevede un mecanism de configurare pentru a specifica un director de sistem de fisiere si in schimb analizeaza URI.

De exemplu,  grupurile/blocurile de configurare primare pentru Nginx sunt grupurile/blocurile server si location. Grupul server interpreteaza cererea de host ca fiind solicitata, in timp ce grupurile location sunt responsabile cu potrivirea portiunilor de URI care vin dupa host si port. in acest punct, cererea este interpretata ca URI si nu ca o locatie in sistemul de fisiere.

Pentru fisierele statice, toate solicitarile trebuie in cele din urma sa fie schitate intr-o locatie pe sistemul de fisiere. in primul rand, Nginx selecteaza grupurile server si locatie care vor gestiona cererea si apoi va combina documentul root cu URI, adaptand tot ce este necesar cu acea configuratie specificata.

Acesta lucru poate parea similar, dar analizarea cererilor primare ca URI si nu ca locatie a fisierului de sistem permite Nginx sa functioneze mai usor in ambele roluri de web, mail si pe server proxy. Niginx este configurat prin simpla stabilire a modului de a raspunde la diferite modele de cerere. Nginx nu verifica sistemul de fisiere pana nu este gata sa serveasca cererea, ceea ce explica de ce nu pune in aplicare in fisierele .htaccess.

Module

Ambele Nginx si Apache se extind prin sisteme de module, dar modul in care acestea functioneaza difera semnificativ.

Apache

Sistemul de module Apache va permite sa incarcati sau sa descarcati dinamic module pentru a va satisface nevoile in timpul rularii server-ului. Baza Apache este mereu prezenta, in timp ce modulele pot fi activate sau dezactivate, adaugarea sau eliminarea de functionalitate suplimentara si prinderea in server-ul principal.

Apache utilizeaza aceasta optiune pentru o gama larga de sarcini. Datorita vechimii platformei, exista o varietate de module disponibile. Acestea pot fi utilizate pentru a modifica o parte din functionalitatea de baza a server-ului cum ar fi mod_php , care integreaza un interpretor in fiecare lucrator de functionare.

Cu toate acestea, modulele nu sunt limitate la procesarea continutului dinamic. Printre alte functii, acestea pot fi folosite pentru a rescrie URL-uri, pentru autentificarea clientilor, stabilizarea server-ului, logare, cache-ul, compresia, proxy, rata de limitare si criptarea. Modulele dinamice isi pot extinde functionalitatea considerabil fara munca suplimentara.

Nginx

De asemenea, Nginx pune in aplicare, un sistem modular, dar este destul de diferit de sistemul Apache. in Nginx, modulele nu sunt incarcate dinamic, asa ca trebuie sa fie selectate si compilate in software-ul de baza.

Pentru multi utilizatori, acest lucru va face Nginx mai putin flexibil. Acest lucru este valabil pentru utilizatorii care nu se simt comod sa isi mentina  propriul software compilat in afara sistemului de ambalare. in timp ce pachetele distribuite tind sa includa modulele cele mai des utilizate, daca solicitati un modul care nu este standard, va trebui sa construiti server-ul.

Cu toate aceste modulele Nginx sunt inca utile si va permit sa cereti ceea ce doriti de la server doar prin includerea functionalitatii pe care doriti sa o folositi. Uni utilizatori pot considera acest lucru mai sigur decat componentele arbitrare care sunt cuplate in server. Cu toate acestea, daca server-ul este pus intr-o pozitie unde acest lucru este posibil el este compromis deja.

Modulele Nginx permit tot atatea capabilitati ca si modulele Apache. De exemplu, modulele Nginx pot oferi suport proxy, compresie, rata limitata, logare, rescriere, geo-localizare, autentificare, criptare, flux si functionalitate de mail.

Suport, Compatibilitate, Ecosistem si Documentare

Un punct major de luat in considerare este actualul proces de notiuni de baza si functionare care va oferi o privire de ansamblu asupra suportului si ajutorului disponibil printre alte software-uri.

Apache

Pentru ca Apache este popular de asa mult timp, suportul pentru server este destul de raspandit. Exista o biblioteca de documentare disponibila de prima si a treia parte pentru server-ul de baza si pentru scenarii bazate pe legarea Apache de alte software.

Impreuna cu documentarea, multe metode si proiecte web includ metode prin care poate bootstrap in mediul Apache. Acesta se poate include insusi in proiecte, sau in pachetele mentinute de echipa de distributie.

Apache, in general, va avea mai mult suport de la proiectele partilor terte, pur si simplu, datorita cotei de piata si a perioadei lungi in care a fost disponibil. Administratorii sunt oarecum mai doritori in a avea o experienta cu Apache nu numai pentru popularitate, dar si pentru ca multi dintre cei care au scenarii de hosting se bazeaza aproape exclusiv pe Apache datorita posibilitatilor distribuite de gestionare a .htaccess.

Nginx

Nginx experimenteaza suport crescut deoarece tot mai multi utilizatori il folosesc pentru profilul performant, dar tot mai are unele imbunatatiri de facut in anumite zone cheie.

In trecut era dificil de gasit documentatie cuprinzatoare in limba engleza pentru Nginx din cauza faptului ca cea mai mare parte din documentatia de inceput era in limba rusa. Pe masura ce interesul pentru acest proiect a crescut, documentatia s-a imbogatit si acum se gasesc o multitudine de resurse de administrare pe site-ul Nginx si pe alte site-uri terte.

In ceea ce priveste aplicatiile terte, suportul si documentarea  devin tot mai disponibile, iar cei care intretin pachetele incep, in unele cazuri, sa ofere posibilitatea de a alege intre auto-configurarea pentru Apache si Nginx. Chiar si fara suport, configurarea Nginx cu software alternativ este usor de realizat atata timp cat proiectul in sine documenteaza cerintele (permisiuni, antete, etc.)

Folosind Apache si Nginx impreuna

Dupa ce am enumerat beneficiile si limitarile ambelor Apache si Nginx, va veti putea face o mai buna idee despre care server va este mai potrivit. Cu toate acestea, multi utilizatori descopera ca este posibil sa se foloseasca de forta comuna a celor doua servere.

Configurarea conventionala a acestui parteneriat este sa plasati Nginx in fata Apache ca un proxy invers. Acesta va permite Nginx sa manevreze toate cererile clientilor. Acesta profita de avantajul rapidei procesari a lui Nginx si de abilitatea de a manevra un numar mare de conexiuni in mod curent.

Pentru continut static, lucru la care Nginx exceleaza, fisierele vor fi servite repede si direct clientului. Pentru continut dinamic, de exemplu fisiere PHP, Nginx va transfera cererea catre Apache, care poate procesa rezultatele intorcandu-se la pagina anterioara. Nginx poate da mai departe continutul clientului.

Aceasta setare functioneaza bine pentru multi oameni pentru ca permite Nginx sa functioneze ca o masina de sortat. Acesta va manevra toate cererile posibile si va transmite acelora care nu au abilitate nativa de a servi. Prin taierea cererilor server-ul Apache se poate ocupa de atenuarea unor blocari care se petrec cand un curs sau un proces Apache este ocupat.

Acesta configurare va permite de asemenea sa scalati prin adaugarea de servere suplimentare la final. Nginx poate fi configurat sa treaca usor la un grup de servere crescand rezistenta la esec si performanta.

Concluzii

Dupa cum puteti vedea, ambele Apache si Nginx sunt puternice, flexibile si capabile. A decide care server este cel mai bun pentru dvs. este in mare masura o functie de evaluare a cererilor specifice si de testare a modelului pe care te astepti sa il vezi.

Sunt diferente intre aceste proiecte care au un real impact asupra performantei, capabilitatilor si a implementarii timpului necesar pentru a obtine fiecare solutie functionala. Oricum acestea sunt rezultatele unei serii de compromisuri care nu ar trebui sa fie respinse la intamplare. in cele din urma, nu este nici un server web care sa se potriveasca perfect, asa ca folositi cea mai buna solutie care se aliniaza obiectivelor dvs.

Din aceeasi categorie

Te muti la noi?

Migrarea catre un nou furnizor de hosting poate fi extrem de complicata . Fii relaxat si lasa-i expertii nostri sa o faca! Vom muta site-ul existent în 48 de ore, fara intrerupere . Inclus GRATUIT la achizitionarea oricarui pachet de gazduire BTS Telecom.