Для начало скачиваем последнюю стабильную версию nginx:
wget http://nginx.org/download/nginx-1.4.6.tar.gz tar xzf nginx-1.4.6.tar.gz
Далее с github скачиваем нужные нам модули:
git clone https://github.com/yaoweibin/nginx_cross_origin_module.git git clone https://github.com/arut/nginx-rtmp-module.git git clone -b 2.2 git://github.com/vkholodkov/nginx-upload-module.git git clone https://github.com/masterzen/nginx-upload-progress-module.git
Устонавливаем библиотеку libpcre3-dev:
apt-get install libpcre3-dev
после:
cd nginx-1.4.6/
конфигурируем:
./configure --add-module=../nginx-upload-module --add-module=../nginx-upload-progress-module --add-module=../nginx_cross_origin_module --add-module=../nginx-rtmp-module --prefix=/etc/nginx/ --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --user=nginx --group=nginx --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-file-aio
принеобходимости можно еще добавить доболнительные параметры!
make make install Проверяем что у нас получилось:
root@root:~# nginx -V nginx version: nginx/1.4.6 built by gcc 4.7.2 (Debian 4.7.2-5) TLS SNI support enabled configure arguments: --add-module=../nginx-upload-module --add-module=../nginx-upload-progress-module --add-module=../nginx_cross_origin_module --add-module=../nginx-rtmp-module --prefix=/etc/nginx/ --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --user=nginx --group=nginx --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-file-aio
В данном примере описывается как добавить в автозагрузку nginx? По аналогии добавляем и другие программы!
Для начало нужно задать права на исполнение файла
# chmod +x /etc/init.d/nginx
После заносим в автозагрузку:
# /usr/sbin/update-rc.d -f nginx defaults
Не давно наткнулся на такую проблему. Нужно было просмотреть превью (Preview), на вордпрессе, в котором был относительно большой объем информации, который необходимо хранить в куках. После чего я получаю ошибка сервера 400 Bad Request
Как оказывается, при увеличении размеров cookie, заголовок запроса клиента не уместился в буфер для чтения, размер которого у nginx’а по умолчанию составляет 1K.
Директива: client_header_buffer_size
синтаксис: client_header_buffer_size размер;
умолчание: client_header_buffer_size 1k;
контекст: http, server
Задаёт размер буфера для чтения заголовка запроса клиента. Для большинства запросов достаточно буфера размером в 1K байт. Однако если в запросе есть длинные cookies, или же запрос пришёл от WAP-клиента, то он может не поместиться в 1K. Поэтому, если строка запроса или поле заголовка запроса не помещаются полностью в этот буфер, то выделяются буферы большего размера, задаваемые директивой large_client_header_buffers.
Директива: large_client_header_buffers
синтаксис: large_client_header_buffers число размер;
умолчание: large_client_header_buffer 4 8k;
контекст: http, server
Задаёт максимальное число и размер буферов для чтения большого заголовка запроса клиента. Строка запроса не должна превышать размера одного буфера, иначе клиенту возвращается ошибка 414 (Request-URI Too Large). Поле заголовка запроса также не должно превышать размера одного буфера, иначе клиенту возвращается ошибка 400 (Bad Request). Буферы выделяются только по мере необходимости. По умолчанию размер одного буфера равен 8K байт. Если по окончании обработки запроса соединение переходит в состояние keep-alive, эти буферы освобождаются.
Поэтому, при возникновении 400 ошибки предположительно по описанной причине, увеличиваем буферы чтения (значения подбираются по необходимости). Напр:
server {
...
client_header_buffer_size 4k;
large_client_header_buffers 8 16k;
...
}
Также возможно понадобится отредактировать директивы proxy_buffers и proxy_buffer_size
NGINX - это простой, надежный и быстрый сервер, который не перегружен функциями. Применение веб-сервера NGINX рационально, преимущественно, для статических веб-сайтов, а также в качестве прокси-сервера перед динамическими веб-сайтами.
Достоинствами NGINX являются:
Эффективное обслуживание веб-трафика в условиях высокой конкурентности, т.е. большого количества одновременных TCP-соединений и HTTP-запросов;
Оперативное обслуживание многочисленного количество запросов на установление новых соединений и возможность справляться с неоднородностью трафика, другими словами, обрабатывать большие и маленькие веб-объекты, а также быстрые и медленные клиенты;
NGINX полностью поддерживает протоколы HTTP/1.1, SPDY/2, WebSocket, FastCGI, uwsgi и SCGI, и поэтому позволяет подключать пользователей к таким популярным приложениям, как Joomla, WordPress, Magento, Drupal и других, размещенных на одном сервере или в сети для повышения производительности и большой масштабируемости.
Благодаря своей компактной и предсказуемой памяти и используемого CPU, NGINX чрезвычайно популярное веб-программное обеспечение для использования во всех типах облачных сред, обслуживающий уже более 45% веб-сайтов, размещенных на Amazon AWS.
NGINX обеспечивает простую интеграцию с применением таких рамок, как Rails, Node.js, JBoss, Django или Zend. Заменяя или дополняя конфигурацию устаревших приложений поставляемых вместе с сервером, NGINX позволяет масштабировать и создавать веб-сайты без покупки лишних аппаратных средств.
Основные функции HTTP-сервера:
Акселерированное обратное проксирование с применением кэширования, простейшее распределение нагрузки и устойчивость к отказам;
Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием;
Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, а также кэш дескрипторов открытых файлов;
Модульность, фильтры, включая сжатие (gzip), докачка (byte-ranges), chunked ответы, SSI-фильтр, XSLT-фильтр, конвертация изображений; несколько подзапросов на одной странице, которые могут обрабатываться в SSI-фильтре через прокси или FastCGI и выполняться параллельно;
Поддержка SSL и расширения TLS SNI.
Другие возможности HTTP-сервера:
Apache является самым популярным веб-сервером и одним из самых успешных проектов с открытым исходным кодом. Начиная с апреля 1996-го Apache обслуживает больше веб-сайтов, чем какой-либо другой веб-сервер. Самые большие в мире веб-сайты, включая YouTube, Facebook, Wikipedia и Craigslist обслуживаются Apache, обрабатывающим миллиарды запросов в месяц. За прошедшие много лет использования Apache он показал себя как очень надёжный, безопасный и гибкий веб-сервер. Глядя на мощь и прелесть Apache сам собой напрашивается вопрос: а есть ли в природе что-то с подобной функциональностью, но с лучшей производительностью и более простое в настройке. Это «что-то» существует и называется Nginx.
Nginx (произносится как «Engine X») — это высокопроизводительный веб-сервер и reverse-прокси, созданный Игорем Сысоевым для Rambler.Ru. Начиная с лета 2004-го Rambler.Ru использует Nginx на своих серверах, обслуживающих порядка миллиарда запросов в сутки. Так же, как и Apache, Nginx используется на многих крупных веб-ресурсах, таких как WordPress, Hulu и MuchiMedia. На март 2011 Nginx занимает 4 место по рейтингу Netcraft, пропустив вперёд Apache, IIS и GFE.
Подобно Apache, Nginx предлагает набор возможностей, соответствующий требованиям к современному веб-серверу: