Бисквитки - nginx уеб сървър

nginx уеб сървър. Част 1: Общ преглед и основна настройка

nginx (engine x) е HTTP сървър и IMAP/POP3 прокси за UNIX-подобни платформи (FreeBSD и GNU/Linux). Nginx започва да се разработва от Игор Сисоев, служител на Rambler през пролетта на 2002 г., а през есента на 2004 г. се появява първата публично достъпна версия. Той, както и всички следващи, се разпространява под BSD лиценз.

В момента nginx работи на голям брой силно натоварени сайтове (сред тях са Rambler, Yandex, Vkontakte, wordpress.com, Wrike и други). Текущата версия, 0.6.x, се счита за стабилна по отношение на надеждността, докато версиите от клона 0.7 се считат за нестабилни. В същото време е важно да се отбележи, че функционалността на някои модули ще се промени, в резултат на което директивите също могат да се променят, така че обратната съвместимост в nginx преди версия 1.0.0 не е гарантирана.

Защо nginx е толкова добър и защо администраторите на силно натоварени проекти го харесват толкова много? Защо просто не използвате Apache?

Защо Apache е лош?

Първо, трябва да обясним как работят мрежовите сървъри като цяло. Тези, които са запознати с мрежовото програмиране, знаят, че по същество има три модела на работа на сървъра:

Последователен. Сървърът отваря слушащ сокет и чака да се появи връзка (докато чака, той е в блокирано състояние). Когато пристигне връзка, сървърът я обработва в същия контекст, затваря връзката и чака връзката отново. Очевидно това далеч не е най-добрият начин, особено когато работата с клиент отнема много време и има много връзки. Освен това последователният модел има много повече недостатъци (например невъзможност за използване на множество процесори), а в реални условияпрактически не се използва.
Мултипроцес (многонишков). Сървърът отваря слушащ сокет. Когато пристигне връзка, той я приема, след което създава (или взема от пула от предварително създадени) нов процес или нишка, която може да работи с връзката произволно дълго време и след приключване на работата да прекрати или да се върне в пула. Основната нишка междувременно е готова да приеме нова връзка. Това е най-популярният модел, тъй като е сравнително лесен за изпълнение, позволява извършването на сложни и дълги изчисления за всеки клиент и използва всички налични процесори. Пример за използването му е уеб сървърът Apache. Този подход обаче има своите недостатъци: голям брой едновременни връзки създават много нишки (или, по-лошо, процеси), а операционната система изразходва много ресурси за превключване на контекста. Особено лошо е, когато клиентите много бавно приемат съдържание. В крайна сметка получавате стотици нишки или процеси, които са заети само с изпращане на данни към бавни клиенти, което създава допълнително натоварване върху планировчика на ОС, увеличава броя на прекъсванията и консумира много памет.
Неблокиращи сокети/държавна машина. Сървърът работи в рамките на една нишка, но използва неблокиращи сокети и механизъм за анкетиране. Тези. сървърът, при всяка итерация на безкрайния цикъл, избира от всички сокети този, който е готов да получава / изпраща данни, използвайки извикването select (). След като сокетът бъде избран, сървърът изпраща данни към него или ги чете, но не чака потвърждение, а преминава в първоначално състояние и чака събитие на друг сокет или обработва следващия, в който събитието е възникнало при обработката на предишния. Този модел е много ефективен по отношение на използването на процесора и паметта, но е доста сложен за изпълнение. Освен това,в рамките на този модел обработката на събитие в сокет трябва да бъде много бърза - в противен случай много събития ще се натрупат в опашката и в крайна сметка тя ще препълни. Това е моделът, по който работи nginx. Освен това ви позволява да стартирате няколко работни процеса (т.нар. работници), т.е. може да използва множество процесори.

И така, представете си следната ситуация: 200 клиента се свързват към HTTP сървър с 1 Gbps канал с 256 Kbps канал:

Какво се случва в случай на Apache? Създават се 200 нишки / процеси, които генерират съдържание относително бързо (може да бъдат както динамични страници, така и статични файлове, прочетени от диск), но бавно го дават на клиентите. Операционната система трябва да се справи с куп нишки и блокиране на I/O.

Nginx в такава ситуация изразходва порядък по-малко ресурси на ОС и памет за всяка връзка. Тук обаче излиза наяве едно ограничение на мрежовия модел на nginx: той не може да генерира динамично съдържание в себе си, т.к. това ще доведе до блокировки в nginx. Естествено, има решение: nginx може да прокси такива заявки (за генериране на съдържание) към всеки друг уеб сървър (например същия Apache) или към FastCGI сървър.

Разгледайте механизма на работа на пакета nginx като „основен“ сървър и Apache като сървър за генериране на динамично съдържание:

Nginx приема връзка от клиент и чете цялата заявка от него. Тук трябва да се отбележи, че докато nginx не прочете цялата заявка, тя не я дава на "обработка". Поради това почти всички индикатори за напредъка на качването на файлове обикновено се „счупват“ - възможно е обаче да ги коригирате с помощта на модула upload_progress на трета страна (това ще изисква модификация на приложението).

Следnginx е прочел целия отговор, отваря връзка с Apache. Последният си върши работата (генерира динамично съдържание), след което дава своя отговор на nginx, който го буферира в паметта или във временен файл. Междувременно Apache освобождава ресурси. Освен това nginx бавно предоставя съдържанието на клиента, като същевременно изразходва порядъци по-малко ресурси от Apache.

Тази схема се нарича frontend + backend (frontend + backend) и се използва много често.

защото nginx тепърва започва да навлиза, има някои проблеми с бинарните пакети, така че бъдете готови да го компилирате сами. Обикновено няма проблеми с това, просто трябва внимателно да прочетете изхода на командата ./configure --help и да изберете опциите за компилиране, от които се нуждаете, например:

./configure \ -prefix =/Opt/nginx-0.6.6.x \ # Инсталации на префикс –conf-path =/etc/nginx/nginx.conf \ # Местоположението на конфигурационния файл -pid-path/var/run/nginx.pid # # ... и PID -File —User = nginx \ # Потребителското име, под което ngin x —With-http_ssl_module —With-http_static_module —with-http_stub_status_module \ # списък с необходимите --withutthttt -httttp _SSI_MODULE —WITHOUT-http_userid_Module —WITHOUT-http_autoindex_module —without-http_geo_module —without-http_ referrr ed_module —without-http_limit_zone_module # ... и ненужни модули

След като конфигурирате, трябва да стартирате стандартния make && make install, след което можете да използвате nginx.

Като алтернатива, в Gentoo можете да използвате ebuild от дървото на стандартните портове; на RHEL/CentOS чрез хранилището на epel (съдържа nginx 0.6.x) или srpm за версия 0.7, което може да бъде изтеглено от тук: http://blogs.mail.ru/community/nginx; на Debianможете да използвате пакета nginx от нестабилния клон.

Конфигурационен файл

Конфигурационният файл на nginx е много удобен и интуитивен. Обикновено се нарича nginx.conf и се намира в $prefix/conf/, ако местоположението не е било заменено по време на компилацията. Обичам да го поставям в /etc/nginx/, както и разработчиците на всички пакети, споменати по-горе.

Структурата на конфигурационния файл е както следва:

потребител nginx; # потребителско име с права за стартиране на nginx worker_processes 1; # брой работни процеси събития # този блок определя използвания механизъм за анкетиране (вижте по-долу) и максималния брой възможни връзки >

# и това е начинът, по който можете да дефинирате местоположение, за което можете също така да отмените почти всички директиви, посочени на по-глобални нива location /abcd/ ; > # В допълнение, можете да направите местоположение чрез регулярен израз, като този: location

# друг сървър сървър слуша *:80; име_на_сървър ccc.bbb;

Имайте предвид, че всяка директива трябва да завършва с точка и запетая. Обратно прокси и FastCGI

И така, по-горе разгледахме предимствата на схемата frontend + backend, разбрахме инсталацията, структурата и синтаксиса на конфигурационния файл, сега нека да разгледаме как да внедрим обратно прокси в nginx.

И много просто! Например така:

местоположение / proxy_pass http://1.2.3.4:8080; >

В този пример всички заявки, достигащи местоположение /, ще бъдат проксирани към сървър 1.2.3.4 порт 8080. Това може да бъде Apache или всеки друг http сървър.

Конфигурацията на nginx в този случай изглежда така:

Друг вариант за бекенд е да използвате FastCGI. INВ този случай конфигурацията на nginx ще изглежда така:

# местоположение, където заявките за php скриптове ще попадат локация

# и някои параметри, които трябва да бъдат предадени на fastcgi сървъра, за да разбере кой скрипт да изпълни и с какви параметри: fastcgi_param SCRIPT_FILENAME /usr/www/html$fastcgi_script_name; # име на скрипт fastcgi_param QUERY_STRING $query_string; # низ на заявка # и параметри на заявка: fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; >

# поради факта, че местоположенията на регулярни изрази имат висок "приоритет", всички не-php заявки ще отиват тук.

местоположение / корен /var/www/html/ >

За да заредите по-малко бекенда, по-добре е да давате статични файлове само чрез nginx - той се справя по-добре с тази задача, защото. изразходва значително по-малко ресурси за всяка заявка (няма нужда да създава нов процес и процесът nginx обикновено консумира по-малко памет и могат да бъдат обслужени много връзки).

В конфигурационния файл изглежда така:

слушане на сървър *:80; име_на_сървър myserver.com;

# да предположим, че всички статични файлове са в /files location /files/ root /var/www/html/; # посочете пътя към fs изтича 14d; # добавяне на заглавка Изтича: error_page 404 = @back; # и ако файлът не бъде намерен, изпратете го на посоченото местоположение @back >

# заявки от /files, за които не е намерен файл, се изпращат до бекенда и той може или да генерира желания файл, или да покаже красиво съобщение за грешка location @back proxy_pass ” title=”http://127.0.0.1:80;

Ако цялата статика не е поставенанякаква конкретна директория, след това използвайте регулярен израз:

* ^.+\.(jpgjpeggifpngicocssziptgzgzrarbz2docxlsexepdfppttxttarwavbmprtfjs)$ # подобно на горното, само това местоположение ще получава всички заявки, завършващи с един от посочените суфикси root /var/www/html/; error_page 404 = @back; >

Следва продължение

Продължението на статията вече можете да прочетете в "OpenSource" #042 или в близко бъдеще на този сайт.

Можете да намерите повече информация за nginx тук: