[ новости /+++ | форум | теги | ]

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Ключевые слова: nginx, tune, speed, accel, forward, redirect, proxy,  (найти похожие документы)

From: Alexey Kovyrin <http://blog.kovyrin.net>;
Newsgroups: 
Date: Mon, 6 Dec 2007 14:31:37 +0000 (UTC)
Subject: Контролируемые скачивания через X-Accel-Redirect в Nginx

Оригинал: http://blog.kovyrin.net/2006/11/01/nginx-x-accel-redirect-php-rails/lang/ru/

Использование X-Accel-Redirect с Nginx для реализации контролируемых
скачиваний (с примерами для rails и php)

   Иногда   вам   может   быть   нужно  реализовать  т.н.  контролируемое
   скачивание, когда все запросы на скачивание файлов передаются скрипту,
   который решает, как поступить: отправить пользователю какой-либо файл,
   или  показать  стриницу access denied, или, может быть, сделать что-то
   еще. При использовании сервера lighttpd это может быть реализовано при
   помощи  заголовка  X-Sendfile,  возвращаемого  из скрипта. Nginx имеет
   свою  союственную реализацию описанной идеи с использованием заголовка
   X-Accel-Redirect.  В  этой  короткой  статье  я попытаюсь описать, как
   использовать эту возможность из приложений на PHP или Rails.

   Представим, что у вас есть какой-либо сайт, работающий на Apache с PHP
   или  Rails  для  генерации  нинамического  контента.  Если  вы  будете
   использовать  nginx  в  качестве  reverse-proxy  перед  вашим сервером
   Apache, вы получите сразу две положительных возможности:

    1. Вы   сможете   освободить   больше  ресурсов  вашего  сервера  для
       обслуживания  клиентов,  т.к.  nginx  возьмет  на  себя  работу  с
       медленными клиентами (детальнее - здесь, 
       копия в конце статьи).
    2. Вы   сможете  реализовать  контролируемое  скачивание  статических
       файлов с вашего сайта.

   В этой статье я предпологаю, что сайт расположен в каталоге /var/www и
   статические   файлы   (например,   фильмы,   музыка  или  что-то  еще)
   расположены   в  каталоге  /var/www/files.  Apache  слушает  на  порту
   http://127.0.0.1:8080.

   Для начала, давайте рассмотрим нашу конфигурацию сервера nginx:

           http {
               ....
               server {
                   listen       80;
                   server_name  your-domain.com;
                   location / {
                       rewrite ^/download/(.*) /down.php?path=$1 last;
                       proxy_pass         http://127.0.0.1:8080/;
                       proxy_redirect     off;
                       proxy_set_header   Host             $host;
                       proxy_set_header   X-Real-IP        $remote_addr;
                       proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
                       client_max_body_size       10m;
                       client_body_buffer_size    128k;
                       proxy_connect_timeout      90;
                       proxy_send_timeout         90;
                       proxy_read_timeout         90;
                       proxy_buffer_size          4k;
                       proxy_buffers              4 32k;
                       proxy_busy_buffers_size    64k;
                       proxy_temp_file_write_size 64k;
                   }
                   location /files {
                       root /var/www;
                       internal;
                   }
               }
           }


   Как  вы  видите,  у нас есть дополнительная "internal" секция location
   /files.  Это  ключевое  влово  "internal"  позволяет  нам иметь секции
   location,  которые  будут  доступны  для  польщователя только в случае
   внутренних  редиректов  внутри  nginx  и  при  использование заголовка
   X-Accel-Redirect  в ответах от сриптов backend-сервера. Итак, мы можем
   использовать  простой  скрипт  на  PHP или код на Rails для реализации
   контролируемых  скачиваний  с поддержкой заголовков Ranges (докачка) и
   всех  остальных  возможностей,  предоставляемых  при прямом скачивании
   статического контента с серверов под управлением nginx.

   Вот пример очень простого скрипта down.php:

           <?php
           // Get requested file name
           $path = $_GET["path"];
           //...
           // Perform any required security checks, validation
           // and/or stats accounting
           //...
           // And redirect user to internal location
           header("X-Accel-Redirect: /files/" . $path);
           ?>


   В  приложениях  Rails  вы  можете  использовать  следубщий код в вашем
   controller'е:

           // Get requested file name
           path = @params["path"]
           # ...
           # Perform any required security checks, validation
           # and/or stats accounting
           # ...
           # And redirect user to internal location
           @response.headers['X-Accel-Redirect'] = "/files/" + path


   Вот  и все! При помощи описанного подхода вы сможете реализовать очень
   гибкую  и  удивительно эффективную систему раздачи любого статического
   контента!


Использование Nginx Как Reverse-Proxy Сервера На Загруженных Сайтах

   Две  недели  назад  мы запустили новую версию одного из наших оcновных
   веб-проектов  и  начали  массивную  рекламную поддержку этого сайта. В
   результате  рекламы,  исходящий  трафик только с одного сервера достиг
   200-250Mbit/s!  В  данной  статье  я опишу, как построить стабильный и
   эффективный  веб-сайт  с двухуровневой архитектурой обработки запросов
   (с двумя веб-серверами: frontend и backend) или как модифицировать ваш
   текущий  сервер,  чтобы  получить дополнительные ресурсы для обработки
   большего количества запросов.

   Для  начала, опишу типичный процесс обслуживания запроса к веб-серверу
   и структуру самого сервера:
    1. Клиент инициирует запрос к серверу.
    2. Его браузер устанавливает соединение с сервером.
    3. Ваш  сервер  (например,  Apache)  создает  новый поток/процесс для
       обработки запроса.
    4. Если  клиент  запросил  динамический  контент  (например, отправил
       запрос  к  php-скрипту),  веб-сервер создает отдельный CGI-процесс
       или  запускает  модуль  обработки  скриптов  (например, mod_php) и
       ждет,   пока  запрос  будет  обработан.  Как  только  он  получает
       результирующую web-страницу, то она отправляется клиенту.
    5. Если  же  клиент  запросил  статический  файл,  то  сервер  просто
       отправляет этот файл клиенту.
    6. Браузер  клиента получает ответ, закрывает соединение с сервером и
       отображает "ответ".

   Как  видите,  если  к серверу приходит очень много запросов, он должен
   создавать  много параллельных потоков/процессов и держать их в памяти,
   пока  клиент  не  закроет  соединение.  Если  соединение  у клиента не
   быстрое,  то серверные процессы будут висеть в памяти достаточно долго
   и используемые ими ресурсы будут увеличиваться очень быстро.

   Как же решить данную проблему? Простым решением может быть бесконечное
   увеличение   объемов   оперативной   памяти   на   сервере  и  покупка
   дополнительных  или более мощных процессоров в ожидании момента, когда
   сервер умрет под нагрузкой... Но существует более эффективное решение!
   Вы  можете  просто  поместить  небольшую  программку (nginx, например)
   перед  Вашим  большим  веб-сервером  и дать ей возможность обслуживать
   запросы  к  статическим  файлам,  а  запросы к динамике проксировать к
   главному  серверу.  При  таком  решении  Ваш  большой  сервер не будет
   создавать дополнительных процессов для обработки статических страниц и
   файлов  и  будет  отдавать  результаты обработки динамических запросов
   маленькому  frontend-серверу очень быстро, что позволит ему освободить
   ресурсы  для  использования  в  обработке  других  запросов. Маленький
   frontend  же  может ждать сколь угодно долго, пока клиент заберет свой
   "ответ"  и  закроет соединение, а backend не будет тратить ресурсы для
   этого!

   Вот примерная диаграма предложенной конфигурации веб-сервера:

   
   General Data Flow Diagram

   В  дополнение  к описанному, Вы получите еще очень удобную возможность
   так называемых контролируемых закачек, которая будет описана ниже.

   Если  Ваш  сервер содержит какие-то статические ресурсы, которые можно
   скачивать     только     определенной     части     аудитории    сайта
   (контент-провайдеры   могут   предоставлять   возможность   скачивания
   mp3-файлов  только  пользователям  с положительным балансом; некоторые
   сайты  дают  скачивать файлы только зарегистрированным пользователям и
   т.п.),  в  типичном  случае  вам  необходимо  создать некий скрипт для
   обработки  запросов  на  скачивание и создать набор жутких ссылок вида
   http://some.service.com/down.php?file=xxx.mp3...  В дополнение к этому
   Ваши  пользователи  не  будут  иметь  возможность докачки (исключая те
   случаи,  когда  Ваш  скрипт  настолько  сложен, что понимает заголовок
   Ranges в HTTP-запросах)...

   В  конфигурации с использованием nginx как frontend-сервера, Вы имеете
   возможность   создать  простое  правило  для  переписывания  ссылок  в
   запросах так, чтобы все красивые ссылки типа
   http://your.cool-service.com/files/cool.mp3 автоматически направлялись
   на   некоторый   скрипт   /down.php   и,   если  он  вернет  заголовок
   X-Accel-Redirect,  файл  автоматически  отдавался клиенту с поддержкой
   Ranges  и  всех  остальных  прелестей  раздачи статического контента с
   frontend-сервера.  Backend-сервер  в  это  время  сможет  обрабатывать
   другие  запросы.  Ваши  пользователи могут даже не знать о том, что их
   закачки  контролируются Вами. Примерная диаграмма описанного алгоритма
   приведена ниже:

   
   Functional Algorithm

   Позвольте обратить Ваше внимание на важный факт: Если Вам нужно только
   увеличение  производительности  работы сайта с помощью описанной здесь
   техники,  и вы не хотите использовать систему контроля за скачиванием,
   то  Вам  не нужно ничено менять в скриптах на Вашем сервере! Они будут
   работать так же, как и раньше!

   Итак,  последнее,  чем  я  могу помочь Вам в тяжелом труде оптимизации
   использования  ресурсов  Вашего сервера, - это пример конфигурации для
   nginx,  которая  может  быть  использована Вами в качестве базовой при
   конфигурации Вашего сервера:

           server {
                   listen       80;
                   server_name  some-server.com www.server-name.com;
                   access_log  logs/host.access.log  main;
                   # Main location
                   location / {
                       proxy_pass         http://127.0.0.1:8080/;
                       proxy_redirect     off;
                       proxy_set_header   Host             $host;
                       proxy_set_header   X-Real-IP        $remote_addr;
                                            proxy_set_header      X-Forwarded-For
           $proxy_add_x_forwarded_for;
                       client_max_body_size       10m;
                       client_body_buffer_size    128k;
                       proxy_connect_timeout      90;
                       proxy_send_timeout         90;
                       proxy_read_timeout         90;
                       proxy_buffer_size          4k;
                       proxy_buffers              4 32k;
                       proxy_busy_buffers_size    64k;
                       proxy_temp_file_write_size 64k;
                   }
                   # Static files location
                   location ~*
           ^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|\
                xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
                       root   /spool/www/members_ng;
                   }
               }


   Полная версия конфигурационного файла лежит здесь (копия - ниже).

   Замечание:  Если скрипты на Вашем backend-сервере используют IP-адреса
   клиентов  в  каких-то  целях,  то  Вам необходимо установить на сервер
   модуль  mod_rpaf  module,  чтобы  он  использовал  передаваемый  nginx
   заголовок X-Real-IP в качестве основного адреса пользователя.

   Вот  и  все!  Теперь  Вы  можете  установить  себе  на  сервер  nginx,
   отконфигурировать  его  и  получить  возможность  обслуживать  большее
   количество  клиентов  при  использовании меньшего количества ресурсов!
   Все  будет работать абсолютно прозрачно для уже написанных скриптов и,
   если  хотите,  Вы  сможете  организивать контролируемое скачивание при
   помощи метода, который я опишу в одном из следующих постов.


Пример конфигурации

        user  www-data www-data;
        worker_processes  2;

        error_log  logs/error.log debug;

        pid        logs/nginx.pid;

        events {
            worker_connections  1024;
        }

        http {
            include       conf/mime.types;
            default_type  application/octet-stream;

            log_format  main  '$remote_addr - $remote_user [$time_local] $status '
                              '"$request" $body_bytes_sent "$http_referer" '
                              '"$http_user_agent" "http_x_forwarded_for"';

            access_log  logs/access.log  main;

            sendfile        on;
            tcp_nopush     on;
            tcp_nodelay    on;

            server {
                listen       80;
                server_name  some-server.com www.server-name.com;

                access_log  logs/host.access.log  main;

                # Main location
                location / {
                    proxy_pass         http://127.0.0.1:8080/;
                    proxy_redirect     off;

                    proxy_set_header   Host             $host;
                    proxy_set_header   X-Real-IP        $remote_addr;
                    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

                    client_max_body_size       10m;
                    client_body_buffer_size    128k;

                    proxy_connect_timeout      90;
                    proxy_send_timeout         90;
                    proxy_read_timeout         90;

                    proxy_buffer_size          4k;
                    proxy_buffers              4 32k;
                    proxy_busy_buffers_size    64k;
                    proxy_temp_file_write_size 64k;
                }

                # Static files location
                location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
                    root   /spool/www/members_ng;
                }

            }
        }

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

1.1, Юрий (??), 20:39, 23/12/2007 [ответить]   +/– есть оди н момент, а если требуется проверить скачал ли пользователь файл? в скрипте например проверить отдано все или не все легко - как сделать в данном случае ?   1.2, woto (??), 11:09, 03/04/2008 [ответить]   +/– У меня проблема Content-Type всегда text/html. В http директивой include подключается mime.types. Все на месте, не пойму почему не работает как надо, никто не сталкивался?     2.4, Nas_tradamus (ok), 16:08, 10/07/2012 [^] [^^] [^^^] [ответить]   +/– Если вдруг кто поиском нашел эту статью и не смог сделать: Там нужно дополнительно заголовок поставить перед X-Accel-Redirect хэдером. Например так: header("Content-Disposition: attachment; filename=\"$filename\""); header("X-Accel-Redirect: /files/" . "$filename");   1.3, alex (??), 13:03, 10/04/2008 [ответить]   +/– Про использование в lighttpd контролируемых скачек с помощью скриптов можно поподробнее?   1.5, Nas_tradamus (ok), 17:15, 25/03/2013 [ответить]   +/– Вообще, как показал опыт, не нужно никаких location создавать в nginx. Просто передаем header("X-Accel-Redirect: "относительный/путь/к/файлу/от/корня/сайта") и все работает.     2.7, Никита (??), 14:34, 06/11/2013 [^] [^^] [^^^] [ответить]   +/– Как это не нужно? location должен быть internal, чтобы исключить доступ к скачиваемому файлу снаружи по прямой ссылке,   1.6, meloff (?), 18:06, 19/06/2013 [ответить]   +/– В моем случае нужен X-Accel-Redirect для скачивания внешних файлов. Нашел статью: http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/ но не знаю как её применить, т.к. запрос мне нужно послать из php скрипта, а не из руби.. Подскажите, куда копать? :)

Партнёры:

Хостинг: