Introducere
Apache și Nginx sunt două dintre cele mai comune servere web open source din lume. Împreună ele sunt responsabile pentru deservirea a peste 50% din traficul de pe internet. Ambele soluții sunt capabile să suporte diverse sarcini de lucru și să lucreze cu alte software-uri pentru a oferi o mulțime de soluții complete.
În timp ce Apache și Nginx împărtășesc multe calități acestea nu ar trebui considerate pe deplin interschimbabile. Fiecare excelează în felul lui și este important să înțelegem situațiile în care va trebui să reevaluăm alegerea serverului web. Acest articol va fi dedicat unei discuții despre modul în care fiecare server se descurcă în diverse domenii.
Privire de Ansamblu
Înainte de a aprofunda diferențele dintre Apache și Nginx, haideți să aruncăm o privire rapidă la baza acestor două proiecte și la caracteristicile lor generale.
Apache
Server-ul Apache HTTP a fost creat de Robert McCool în 1995 și a fost dezvoltat de către Apache Software Foundation din 1999. Din moment ce web server-ul Apache este proiectul inițial al fundației și 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. Datorită popularității sale, Apache beneficiază de o bună documentare și suport integrat din partea altor proiecte software.
Apache este adesea ales de administratori pentru flexibilitate, putere și suportul răspândit. Este extins printr-un sistem dinamic de module de încărcare și poate procesa un număr mare de limbi interpretate fără a se conecta la un alt software.
Nginx
În 2002, Igor Sysoev a început să lucreze la Nginx ca răspuns la problema C10K, care a fost o provocare pentru serverele web pentru a începe manipularea a zece mii de conexiuni concurente ca o cerință pentru web-ul modern. Lansarea inițială a fost făcută în 2004, atingerea acestui obiectiv bazându-se pe o arhitectură asincron condusă de evenimente.
Nginx a crescut în popularitate de la lansare datorită utilizării resurselor reduse și a capacității de a scala cu ușurință a unui hardware minim. Nginx excelează la oferirea rapidă de conținut static și este proiectat pentru a trece solicitările dinamice către alte software care sunt mai potrivite pentru acele scopuri.
Nginx este adesea ales de administratori pentru eficiența utilizării resurselor și capacitatea de reacție în sarcină. Susținătorii urează bun venit concentrării pe nucleul server-ului web și pe caracteristicile de bază.
Arhitectura de Manevrare a Conectivității
Una din marile diferențe dintre Apache și Nginx este modul actual prin care ele își manevrează conexiunile și traficul. Aceasta este probabil cea mai semnificativă diferență în modul cum ele răspund la diferitele condiții de trafic.
Apache
Apache oferă o varietate de module multiple de procesare (Apache le numește MPM) care dictează cum sunt manevrate cererile clienților. Practic, acest lucru le permite administratorilor să schimbe cu ușurință conexiunea în arhitectura de manipulare. Acestea sunt:
- mpm_prefork:
Acest modul de prelucrare a spawns processes (proceselor de început) cu un singur curs fiecare ocupându-se de cerere. Fiecare proces de început se poate ocupa de o singură conexiune la un moment dat. Atâta timp cât numărul cererilor este mai mic decât numărul procesărilor, MPM este foarte rapid. Oricum, performanța scade rapid după ce cererile depășesc numărul procesărilor, așa că acesta nu este o alegere bună în multe scenarii. Fiecare proces are un impact semnificativ asupra consumului de RAM, așa că acest MPM este dificil de măsurat. Este în continuare o bună alegere, dacă este folosit în combinație cu alte componente care nu sunt construite cu mici secvențe în memorie. (with threads in mind). De exemplu, PHP nu are un curs sigur, așa că MPM este recomandat ca fiind singura modalitate sigură de lucru cu mod_php, pentru ca modulul Apache să proceseze aceste fișiere.
- mpm_worker:
Acest modul de spawns processes (procese tinere) pot fiecare gestiona mai multe fire. Fiecare dintre aceste fire poate manevra o singură conexiune. Firele de acțiune sunt mai eficiente decât procesele, ceea ce înseamnă că acest MPM măsoară mai bine decât prefork MPM. Din moment ce acolo sunt mai multe cursuri decât procese, acest lucru înseamnă de asemenea că noile conexiuni pot imediat să urmeze un nou fir în loc să aștepte după un proces liber.
- mpm_event:
Acest modul este similar cu modulul worker în majoritatea situațiilor, dar este optimizat să se ocupe de conexiunile keep-alive. Când utilizăm modulul worker MPM, o conexiune va ține un fir indiferent dacă o cerere este făcută în mod activ atâta timp cât conexiunea persistă. Modulul event MPM se ocupă de conexiunile persistente prin setarea de fire care să mențină conexiunile și să treacă solicitările active către alte fire. Acesta împiedică blocarea modulului în urma cererilor persistente, permițându-i executarea mai rapidă. Acesta a devenit mai stabil odată cu lansarea Apache 2.4.
După cum se poate vedea, Apache oferă o arhitectură mai flexibilă prin alegerea conexiunilor și cererilor care se ocupă de algoritmi. Opțiunea oferită este în special o funcție a evoluției server-ului și a creșterii concurenței de când peisajul internetului s-a schimbat.
Nginx
Nginx a apărut după Apache, cu mai multă grijă în ce privește problemele concurențiale pe care le-ar putea avea site-urile la scalare. Știind acest lucru, Nginx a fost creat de la început să folosească un asincron, fără a bloca, chiar să manipuleze conducerea conexiunilor cu ajutorul algoritmului.
Procesele Nginx spawns worker, pot manevra fiecare sute de conexiuni. Procesele worker realizează acest lucru implementând un mecanism rapid care se rotește continuu verificând procesele evenimentelor. Decuplarea conexiunilor de la lucrul efectiv permite fiecărui lucrător să se preocupe de o conexiune când un nou eveniment a fost declanșat.
Fiecare conexiune manevrată de lucrător este plasată în interiorul evenimentului de rotire unde există cu alte conexiuni. În procesul de rotire, evenimentele sunt procesate asincron, permițând muncii să fie manevrată fără a fi blocată. Când conexiunea se închide este înlăturată din procesul de rotire.
Acest mod de procesare a conexiunii permite Nginx să scaleze incredibil de departe cu resurse limitate. Din moment ce server-ul are un singur curs și procesele nu sunt limitate să se ocupe de fiecare nouă conexiune, memoria și utilizarea procesorului tind să fie relativ consistente chiar și în momente grele de sarcină.
Conținut Dinamic vs Conținut Static
În condiții reale, una dintre cele mai comune comparații dintre Apache și Nginx este modul cum fiecare server manevrează conținutul static și dinamic.
Apache
Serverele Apache pot manevra conținutul static folosind metodele convenționale bazate pe fișiere. Performanța acestor operații este mai mult o funcție a metodelor MPM descrise mai sus.
Apache poate de asemenea procesa conținut dinamic prin integrarea unui procesor al limbii în cauză pentru fiecare dintre situații. Acesta permite să execute conținut dinamic în interiorul server-ului web fără a relaționa cu alte componente din exterior. Aceste procesoare dinamice pot fi activate prin utilizarea modulelor încărcate dinamic.
Abilitatea Apache de a manevra conținut dinamic intern înseamnă că acea configurare a procesului dinamic tinde să fie simplă. Comunicarea nu are nevoie să fie coordonată de o parte adițională a unui software și modulele pot fi ușor schimbate dacă conținutul se schimbă.
Nginx
Nginx nu are abilitatea nativă de a procesa conținut dinamic. Pentru a manevra PHP și alte cereri de conținut dinamic, Nginx trebuie să treacă pe un procesor extern pentru execuție și să aștepte trimiterea conținutului redat. Apoi rezultatele pot fi transmise clientului.
Pentru administratori, acest lucru înseamnă că trebuie să configureze comunicațiile dintre Nginx și procesorul peste unul din protocoalele Nginx care știu (http, FastCGI, SCGI, uWSGI, memcache). Acesta poate complica lucrurile puțin, mai ales când va încerca să anticipeze numărul de conexiuni permise, pentru că o conexiune adițională va fi folosită de fiecare dată de procesor.
Această metodă are de asemenea și avantaje. Din moment ce interpretarea dinamică nu este integrată în procesul de funcționare, partea de deasupra va fi prezentă pentru conținutul dinamic. Conținutul static poate fi servit doar într-o manieră directă și interpretatorul va fi contactat doar la nevoie. Și Apache poate funcționa în acest fel, dar înlăturând beneficiile din secțiunea anterioară.
Configurarea Distribuită vs Configurarea Centralizată
Pentru administratori, una dintre aparentele cele mai evidente dintre aceste două părți de software este dacă configurația la nivel de director este permisă în interiorul conținutului directoarelor.
Apache
Apache include o opțiune care permite configurarea adițională pe fiecare director de bază inspectând și interpretând directivele din fișierele ascunse din interiorul directoarelor. Aceste fișiere sunt cunoscute ca fișiere .htaccess.
Din moment ce aceste fișiere se află în interiorul conținutului directoarelor, când primesc o solicitare, Apache verifică fiecare componentă a părții de fișier cerute pentru un fișier .htaccess și aplică directivele găsite în interior. Acest lucru permite efectiv configurarea descentralizată a server-ului web care este adesea folosită pentru implementarea rescrierilor URL, restricțiilor de acces, autorizare și autentificare, chiar și a politicilor de caching.
În timp ce exemplele de mai sus pot fi configurate în fișierul principal de configurare, fișierele .htaccess au unele avantaje importante. Primul, din moment ce acestea sunt interpretate de fiecare dată când sunt găsite de-a lungul unei căi de solicitare, ele sunt implementate imediat fără a se încărca server-ul. Al doilea, face posibilă permiterea utilizatorilor fără privilegii să controleze aspecte certe ale conținutului web propriu fără a le da control asupra întregului fișier de configurare.
Acest lucru oferă o cale mai ușoară pentru anumite tipuri de software web, cum ar fi sistemele de management al conținutului, configurarea mediului fără să ofere acces la fișierul central de configurare. Acesta este de asemenea folosit de către providerii de web hosting pentru a menține controlul configurației principale, în timp ce le oferă clienților control doar asupra anumitor directoare.
Nginx
Nginx nu interpretează fișierele .htaccess, și nici nu oferă un mecanism pentru evaluarea configurării din afara, pe director, a principalelor fișiere de configurare. Acesta este mai puțin flexibil decât Apache dar are avantajele sale.
Cea mai notabilă îmbunătățire asupra sistemului de configurare la nivelul directorului .htaccess este performanța crescută. Pentru o configurare tipică Apache acesta poate permite accesul .htaccess în orice director, server-ul va verifica existența acestor fișiere în fiecare director principal mergând până la fișierul cerut, pentru fiecare cerere. Dacă unul sau mai multe fișiere .htaccess sunt găsite în timpul acestei căutări, ele trebuie citite și interpretate. Prin nepermiterea directorului de a trece peste, Nginx poate servi cereri mai repede decât ar face-o un singur director și citirea fișierelor pentru fiecare cerere (presupunând că fișierul este găsit în structura convențională a directorului).
Un alt avantaj este legat de securitate. Distribuind configurarea de acces a nivelului directorului distribuie de asemenea și responsabilitatea de securitate a utilizatorilor universali, care pot să nu fie de încredere pentru a manevra această sarcină corect. Asigurarea faptului că administratorul păstrează controlul asupra întregului server web poate preveni unele erori de securitate care pot apărea când accesul este permis altor părți.
Nu uitați că este posibil să dezactivați interpretarea .htaccess în Apache, dacă această preocupare este în rezonanță cu dvs.
Fișier vs Interpretare URI-Based
Modul cum un server web interpretează cererile și hărțile lor la resursele actuale ale sistemului este o altă zonă unde aceste două servere sunt diferite.
Apache
Apache oferă abilitatea de a interpreta o cerere ca pe o resursă fizică din sistemul de fișiere sau ca pe o locație URI care are nevoie de o evaluare mai abstractă. În general, pentru primul Apache utilizatorii de blocuri/grupuri <Directory> sau <Files>, în timp ce se utilizează blocul/grupul <Location> pentru resurse mai abstracte.
Pentru că Apache a fost construit de la început ca un server web, implicit este normal să interpreteze cereri ca resurse ale fișierului de sistem. Începe prin a lua documentul root aplicându-i porțiunea de cerere care urmează găzduirea și numărul de port pentru a încerca să găsească un fișier actual. Practic, ierarhia fișierului de sistem este reprezentată pe internet ca un arbore de documente disponibile.
Apache oferă un număr de alternative pentru când cererea nu se potrivește cu sistemul de fișiere care stau la bază. De exemplu, o directivă Alias poate fi folosită pentru a face o descriere unei locații alternative. Folosind blocul/grupul <Location> este o metodă de a lucra chiar cu URI și nu cu fișierul de sistem. Există, de asemenea, variante obișnuite de expresii care pot fi folosite pentru a aplica configurarea mai flexibilă în tot sistemul de fișiere.
În timp ce Apache are abilitatea de a opera atât în sistemul de fișiere cât și în spațiul web, dar înclină mai mult spre metodele sistemului de fișiere. Acest lucru poate fi văzut în unele decizii de proiectare, inclusiv utilizarea de fișiere .htaccess pentru configurarea directorului. Însăși documentele Apache avertizează împotriva folosirii blocurilor/grupurilor URI-based pentru a restricționa accesul la cererile de mirrors care stau la bază.
Nginx
Nginx a fost creat să fie server web și proxy server. Datorită arhitecturii cerute pentru aceste două roluri, el lucrează la bază cu URI, traducând sistemului de fișiere când este necesar.
Acest lucru poate fi văzut în unele moduri în care fișierele de configurare Nginx sunt construite și interpretate. Nginx nu prevede un mecanism de configurare pentru a specifica un director de sistem de fișiere și în schimb analizează URI.
De exemplu, grupurile/blocurile de configurare primare pentru Nginx sunt grupurile/blocurile server și location. Grupul server interpretează cererea de host ca fiind solicitată, în timp ce grupurile location sunt responsabile cu potrivirea porțiunilor de URI care vin după host și port. În acest punct, cererea este interpretată ca URI și nu ca o locație în sistemul de fișiere.
Pentru fișierele statice, toate solicitările trebuie în cele din urmă să fie schițate într-o locație pe sistemul de fișiere. În primul rând, Nginx selectează grupurile server și locație care vor gestiona cererea și apoi va combina documentul root cu URI, adaptând tot ce este necesar cu acea configurație specificată.
Acesta lucru poate părea similar, dar analizarea cererilor primare ca URI și nu ca locație a fișierului de sistem permite Nginx să funcționeze mai ușor în ambele roluri de web, mail și pe server proxy. Nginx este configurat prin simpla stabilire a modului de a răspunde la diferite modele de cerere. Nginx nu verifică sistemul de fișiere până nu este gata să servească cererea, ceea ce explică de ce nu pune în aplicare în fișierele .htaccess.
Module
Ambele Nginx și Apache se extind prin sisteme de module, dar modul în care acestea funcționează diferă semnificativ.
Apache
Sistemul de module Apache vă permite să încărcați sau să descărcați dinamic module pentru a vă satisface nevoile în timpul rulării server-ului. Baza Apache este mereu prezentă, în timp ce modulele pot fi activate sau dezactivate, adăugarea sau eliminarea de funcționalitate suplimentară și prinderea în server-ul principal.
Apache utilizează această opțiune pentru o gamă largă de sarcini. Datorită vechimii platformei, există o varietate de module disponibile. Acestea pot fi utilizate pentru a modifica o parte din funcționalitatea de bază a server-ului, cum ar fi mod_php, care integrează un interpret în fiecare lucrător de funcționare.
Cu toate acestea, modulele nu sunt limitate la procesarea conținutului dinamic. Printre alte funcții, acestea pot fi folosite pentru a rescrie URL-uri, pentru autentificarea clienților, stabilizarea server-ului, logare, cache-ul, compresia, proxy, rata de limitare și criptarea. Modulele dinamice își pot extinde funcționalitatea considerabil fără muncă suplimentară.
Nginx
De asemenea, Nginx pune în aplicare un sistem modular, dar este destul de diferit de sistemul Apache. În Nginx, modulele nu sunt încărcate dinamic, așa că trebuie să fie selectate și compilate în software-ul de bază.
Pentru mulți utilizatori, acest lucru va face Nginx mai puțin flexibil. Acest lucru este valabil pentru utilizatorii care nu se simt comozi să își mențină propriul software compilat în afara sistemului de ambalare. În timp ce pachetele distribuite tind să includă modulele cele mai des utilizate, dacă solicitați un modul care nu este standard, va trebui să construiți server-ul.
Cu toate acestea, modulele Nginx sunt încă utile și vă permit să cereți ceea ce doriți de la server doar prin includerea funcționalității pe care doriți să o folosiți. Unii utilizatori pot considera acest lucru mai sigur decât componentele arbitrare care sunt cuplate în server. Cu toate acestea, dacă server-ul este pus într-o poziție unde acest lucru este posibil, el este compromis deja.
Modulele Nginx permit tot atâtea capabilități ca și modulele Apache. De exemplu, modulele Nginx pot oferi suport proxy, compresie, rată limitată, logare, rescriere, geo-localizare, autentificare, criptare, flux și funcționalitate de mail.
Suport, Compatibilitate, Ecosistem și Documentare
Un punct major de luat în considerare este actualul proces de noțiuni de bază și funcționare care va oferi o privire de ansamblu asupra suportului și ajutorului disponibil printre alte software-uri.
Apache
Pentru că Apache este popular de așa mult timp, suportul pentru server este destul de răspândit. Există o bibliotecă de documentare disponibilă de primă și a treia parte pentru server-ul de bază și pentru scenarii bazate pe legarea Apache de alte software.
Împreună cu documentarea, multe metode și proiecte web includ metode prin care poate bootstrap în mediul Apache. Acesta se poate include însuși în proiecte sau în pachetele menținute de echipa de distribuție.
Apache, în general, va avea mai mult suport de la proiectele părților terțe, pur și simplu, datorită cotei de piață și a perioadei lungi în care a fost disponibil. Administratorii sunt oarecum mai doritori în a avea o experiență cu Apache nu numai pentru popularitate, dar și pentru că mulți dintre cei care au scenarii de hosting se bazează aproape exclusiv pe Apache datorită posibilităților distribuite de gestionare a .htaccess.
Nginx
Nginx experimentează suport crescut deoarece tot mai mulți utilizatori îl folosesc pentru profilul performant, dar tot mai are unele îmbunătățiri de făcut în anumite zone cheie.
În trecut, era dificil de găsit documentație cuprinzătoare în limba engleză pentru Nginx din cauza faptului că cea mai mare parte din documentația de început era în limba rusă. Pe măsură ce interesul pentru acest proiect a crescut, documentația s-a îmbogățit și acum se găsesc o multitudine de resurse de administrare pe site-ul Nginx și pe alte site-uri terțe.
În ceea ce privește aplicațiile terțe, suportul și documentația devin tot mai disponibile, iar cei care întrețin pachetele încep, în unele cazuri, să ofere posibilitatea de a alege între auto-configurarea pentru Apache și Nginx. Chiar și fără suport, configurarea Nginx cu software alternativ este ușor de realizat atâta timp cât proiectul în sine documentează cerințele (permisiuni, antete, etc.).
Folosind Apache și Nginx împreună
După ce am enumerat beneficiile și limitările ambelor Apache și Nginx, vă veți putea face o mai bună idee despre care server vă este mai potrivit. Cu toate acestea, mulți utilizatori descoperă că este posibil să se folosească de forța comună a celor două servere.
Configurarea convențională a acestui parteneriat este să plasați Nginx în fața Apache ca un proxy invers. Acesta vă permite Nginx să manevreze toate cererile clienților. Acesta profită de avantajul rapidei procesări a lui Nginx și de abilitatea de a manevra un număr mare de conexiuni în mod curent.
Pentru conținut static, lucru la care Nginx excelează, fișierele vor fi servite repede și direct clientului. Pentru conținut dinamic, de exemplu fișiere PHP, Nginx va transfera cererea către Apache, care poate procesa rezultatele întorcându-se la pagina anterioară. Nginx poate da mai departe conținutul clientului.
Această setare funcționează bine pentru mulți oameni pentru că permite Nginx să funcționeze ca o mașină de sortat. Acesta va manevra toate cererile posibile și va transmite acelora care nu au abilitate nativă de a servi. Prin tăierea cererilor, server-ul Apache se poate ocupa de atenuarea unor blocări care se petrec când un curs sau un proces Apache este ocupat.
Aceasta configurare vă permite, de asemenea, să scalați prin adăugarea de servere suplimentare la final. Nginx poate fi configurat să treacă ușor la un grup de servere crescând rezistența la eșec și performanța.
Concluzii
După cum puteți vedea, ambele Apache și Nginx sunt puternice, flexibile și capabile. A decide care server este cel mai bun pentru dvs. este în mare măsură o funcție de evaluare a cererilor specifice și de testare a modelului pe care te aștepți să îl vezi.
Sunt diferențe între aceste proiecte care au un real impact asupra performanței, capabilităților și a implementării timpului necesar pentru a obține fiecare soluție funcțională. Oricum, acestea sunt rezultatele unei serii de compromisuri care nu ar trebui să fie respinse la întâmplare. În cele din urmă, nu este niciun server web care să se potrivească perfect, așa că folosiți cea mai bună soluție care se aliniază obiectivelor dvs.