Днес продължаваме с втора част от поредицата статии за двата най-разпространени уеб сървъри с отворен код - Apache и Nginx. След като вече ви запознахме със създаването им и разликата в процеса на обработката на заявките към сървъра, днес продължаваме с нова порция отличителни характеристики.
Статично vs Динамично съдържание (Static vs Dynamic Content)
Основното сравнение между Apache и Nginx е как те се справят със заявките към статично или динамично съдържание.
- Apache
Apache сървър може да обработи статичното съдържание като използва своя file-based метод. Начинът, по който се извършва, го описахме по-горе в MPM модулите.
Сървърът може да обработи и динамичното съдържание като използва преобразувател на съответния език във всяка една негова работна инстанция. Това позволява обработката на динамичното съдържание в уеб сървъра без той да се обръща към други компоненти.
Тази възможност на Apache позволява лесно конфигуриране и не е нужно процесите да бъдат координирани с други приложения.
- Nginx
От своя страна Nginx не може да обработва динамично съдържание. Необходимо е той да подаде заявките до съответния софтуер, който да я обработи и да върне резултата на Nginx. След това резултатът се поднася на клиента.
Това означава, че администраторите трябва да извършат допълнителна конфигурация между Nginx и други софтуери чрез http, FastCGI, SCGI, uWSGI, memcache. Действието може да доведе до усложнения и допълнителни затруднения.
Методът има предимството, че може да поднесе статичното съдържание на момента, без да се свързва с други приложения. Ако няма динамично съдържание, Nginx не се обръща към приложения, а това подобрява изключително бързодействието му.
Дистрибутирана vs централизирана конфигурация
За администраторите една от най-големите разлики между двата софтуера е дали directory-level конфигурацията е позволена в рамките на директорията за съдържание.
- Apache
Apache притежава опция, която позволява допълнителна конфигурация за определена директория. Ако тя е активирана, могат да се внесат допълнителни промени на директория чрез файла .htaccess.
След като тези файлове са в директориите, където се намира съдържанието на страница, те биват прочитани от Apache. Това позволява допълнителни модификации на локално ниво като URL rewrites, access restrictions, authorization и authentication, както и caching policies.
Тази функция носи със себе си значителни предимства - позволява след промяна на дадени директиви Apache сървърът да не бъде рестартиран. Освен това могат да бъдат дадени права на потребители, които да редактират този файл, без да е нужен достъп до главния Apache конфигурационен файл.
Опцията е изключително полезна за CMS системите, които често изискват поставянето на специфични правила. Тук е моментът да ви напомним, че повечето доставчици на споделен хостинг предоставят тази възможност, като така дават нужната свобода на клиентите си без да застрашават главния .conf файл.
- Nginx
Nginx не поддържа нито .htaccess файла, нито друг с тази функция. При него промените се задават директно в конфигурационния файл. В някои ситуации това може да не е най-удобният вариант, но определено има своите предимства.
Едно от тях е повишената производителност. Тя се дължи на факта, че при Apache системата проверява всички директории преди заявената за файла .htaccess и при наличие на подобен ги прочита. При Nginx няма подобна опция и заявката бива директно насочвана към съответната директория.
Друго основно предимство е човешкият фактор. Тук потребителят няма правомощия да задава специфични правила и затова процентът на грешки или евентуални дупки е сведен до минимум. Ако в даден момент е необходимо да бъдат направени промени, те се извършват от компетентни лица.
Файлова vs URI-базирана интерпретация
Тук ще разгледаме как уеб сървърите интерпретират заявките и ги свързват с конкретния изискван ресурс на системата.
- Apache
Apache предоставя възможността да се интерпретира заявката като физически ресурс или като URI локация. В повечето случаи се задава <Directory> или <Files> блокове, а <Location> служи за по-абстрактни ресурси.
Apache е разработен за уеб сървър и по подразбиране интерпретацията на заявката е зададена като ресурс на файловата система. В началото се взима document root след което host и port, за да бъде намерен действителният файл.
Apache предоставя и няколко алтернативи, в случай че заявката не съответства на основната файлова система. За пример Alias директива може да бъде използван да посочва различна локация. Поставянето на <Location> блока позволява да бъде използван URI вместо файлова система.
Както се вижда Apache предоставя повече от един метод, но както е спомената и в тяхната документация, те изрично препоръчват използването на файлова система, а не URI.
- Nginx
Nginx е разработен както като самостоятелен сървър, така и като proxy. Това е причината той да предоставя възможност за работа и с двата метода. Въпреки това обаче той работи основно с URI, а когато е необходимо - го транслира на файлова система.
Това може да бъде наблюдавано и от самия конфигурационен файл на Nginx, където не могат да се поставят специфични директиви за файлова система, а само за URI.
Например основните блокове са server и location. Блокът server отговаря на host при заявка, а location отговаря за съвпадащия URI, който идва след host и port. Така заявката е интерпретирана като URI, а не като локация на файловата система.
За статичното съдържание заявката достига до фаза файлова локация. Първо Nginx избира server и location блоковете, които ще обработят заявката, в комбинация с document root с URI и адаптира всичко необходимо според конфигурацията му.
Nginx използва URI като основно средство и това му позволява лесно да работи като web, mail или proxy сървър. Nginx не проверява файловата система, докато не е готов да поднесе заявката и поради тази причина не се проверява за файлове като .htaccess.
Модули
И двата сървъра използват модули, които да допринасят за по-добрата им работа, но начинът, по който работят е различен.
- Apache
Модулната система на Apache позволява модули да бъдат зареждани или спирани по всяко едно време в зависимост от нуждите на сървъра. Ядрото на Apache остава незасегнато, а се зареждат само допълнителни модули, които предоставят различни функции.
Тъй като този софтуер е създаден преди много време, съществува голямо разнообразие от наличните модули. Те могат да бъдат използвани както за добавяне на функции, така и за променяне на основните. Например - mod_php, при който се вгражда PHP интерпретатор в процеса.
Тези модули не са ограничени само за динамичното съдържание. Те могат да бъдат използвани и за промяна на URLs адреси, ограничен достъп, компресия, кеширане и други.
- Nginx
В Nginx също могат да бъдат вградени модули, но по различен начин. Тук модулите не се зареждат динамично, а при самата конфигурация на сървъра.
За мнозина този процес не е гъвкав и води до затруднения особено за потребители, които не са запознати как се извършва действието и често използват само стандартните модули в дистрибуцията. Тези модули са напълно достатъчни за нормалната работа на сървъра. Ако искате обаче нестандартен модул, е необходимо да преконфигурирате Nginx.
Допълнителните модули са изключително функционални, а фактът, че не са заредени първоначално е предимство, защото така сървърът има само необходимите неща. От гледна точка на сигурността за някои потребители това е голямо предимство.
Самата функция на модулите е много подобна на Apache модулите, като и те предоставят компресия, ограничен достъп, криптация и други.
В последната част ще ви покажем накратко за поддръжката, екосистемата, съвместимостта и документацията и как можем да използваме двата уеб сървъра съвместно.
