Nginx изменение картинки по рефереру

В последнее время, стало модным вместо борьбы с хотлинками, выдавать вместо ожидаемого контента несколько другой. Я это заметил на примере мем сайтов, которые при обращение к их картинкам с других сайтов, отдают эту картинку, но приделывают к ней футер с адресом сайта или подобной рекламной информацией.

В целом весьма логично, если раньше все боялись за свой трафик, то теперь вопросы трафика мало кого интересуют, поэтому и приоритеты сместились в другую сторону. Хотя я видел ситуацию, когда на одном из рабочих ресурсов, образовался хотлинк канал японского трафика на 250mb/s.

Попробуйте открыть это изображение в новой вкладке (убедитесь что броузер не закешировал)

раньше тут была картинка

Рассматривая разные решения, я нашел самый простой способ, делать это с помощью nginx и встроенного модуля ngx_http_referer_module.

test_images.conf

server {
        listen 80;
        server_name images.dev;
        root /www/data/test_images;

        location /test_images {
                valid_referers none blocked server_name images.dev;

                if ($invalid_referer) {
                        rewrite ^(.*)/(.*)$ /images_bad/$2 last;
                }

                rewrite ^(.*)/(.*)$ /images_ok/$2;
        }

        location /images_ok {
                internal;
                alias /www/data/images/test_images/ok;
        }

        location /images_bad {
                internal;
                alias /www/data/images/test_images/bad;
        }
}

Собственно механика очень простая. Мы определяем с помощью "valid_referers" список правильных доменов, можно добавить в него домены поисковиков, например, что бы при поиске картинок пользователю показывалась правильная картинка. Потом мы создаем два внутренних location, которые отвечают за показ правильных и не правильных картинок. В случае не правильного реферера, в конструкции if мы делаем редирект на локейшн с картинками, которые должны отдаваться жуликам, которые ленятся скачивать картинку на свой сервер. Ну вот, в общем и все. Осталось только позаботиться, что-бы у нас были необходимые картинки.

Тут можно решать разными путями, например, при создание оригинальной картинки создавать ее "обработанный" вариант. Но мне больше нравится ленивая загрузка, которую я, когда-то давно, делал в iCacher, основная идея проста: при попытке запроса "обработанной" картинки, если ее нету, управление передается скрипту, который проверяет ее оригинал и делает ее "обработанную" копию, которая отдается пользователю. При повторном обращение, запрос не дойдет до скрипта и пользователю отдастся статический файл. Таким образом мы получаем генерацию изображений по требованию. Еще можно добавить крон скрипт, который будет удалять "обработанные" картинки через 30 дней.

Я не уверен, что моя реализация хороший пример и буду рад если вы ее покритикуете. Плюс, я так и не придумал как избавиться от if в данном случае ( вариант хранения файлов в images_ok/1/ считаю уебским ).


banners, cache, images, nginx      

Nginx allow POST static files

dotZero, этим утром выложил свое решение проблемы, но мне оно показалось не правильным, поэтому я предлагаю свой вариант.

Мое решение лучше тем, что оно не требует поднятия второго сервера на отдельном порту и вообще эстетически красивое.

Кратко о проблеме:

Все знают о том что в Facebook'e есть iframe страницы, но не все знают что Facebook эти страницы запрашивает через POST, а не через GET, как делают все остальные. Поэтому все fb:iframe приложения запрашивая у Nginx'а страницы в ответ будут получать ошибку:

405 "Method Not Allowed"

Вариант который предлагает dotZero выглядит примерно вот так ( это я для истории и поисковых запросов оставлю ):

upstream fb_static {
    server localhost:8001;
}

server {
    listen       443;
    server_name  _;

    #allow_static_post on;

    error_page 405 =200 @405;

    location @405 {
        proxy_method GET;
        proxy_pass http://fb_static;
    }
}

server {
    listen 8001;
    server_name _;

    location / {
        root "/var/www/fb";
    }
}

Вариант конечно хороший и самое главное рабочий, но чисто эстетически он убогий. Давайте попробуем так:

server {
    listen  80;
    server_name _;

    # Тут мы описываем поведение
    # для нашей кастомной ошибки
    error_page 405 = $uri;

    # Дефолтный location
    location / {
        access_log off;
        root    /srv/path
        try_files $uri $uri/index.html /index.php$is_args$args;
    }
}

Что тут происходит? Мы складываем весь статический контент который будет запрашивать facebook в отдельную директорию, просто, для красоты. Определяем location для этой директории, который будет всегда возвращать код ошибки, например, 599. И определяем поведение для обработки этой ошибки, как попытку отдать данные по этому урлу.

Вот и все, работает. Читайте мануалы.

UPD: вернул конфиг до состояние обработки напрямую 405 error_page, т.к. поведение описанное до этого, не совсем соответствовало реальности. Таки образом, после запроса файла через POST, будет выдана 405 ошибка, которая обработается в error_page 405 = \$uri и будет отправлена в location /. То есть либо файл найдется и будет отдан, либо управление будет передано в index.php.


facebook, nginx      

7000 rps на Nginx - Achievement unlocked

Вчера, мой уютный сервачок подвергся очередному стресс тесту.

Для тех кто не в теме, у меня тут еще живет сайт и форум группы CENTR, а вчера в Питере проходил концерт HipHop All Stars 2012. Организаторы повели себя достаточно круто и предложили всем заинтересованным смотреть прямую трансляцию с концерта. Мы стали одним из проектов, которые на главной странице разместили флеш плеер, по которому велась трансляция. Что бы людям не было скучно, подключил еще и комментарии от Вконтакте.

Респект Вконтакту, в пиковые моменты комментарии в прямом эфире появлялись со скоростью 3-4 штуки в секунду. Всего за день на странице появилось примерно 15 000 комментариев.

Когда я вечером зашел посмотреть модные графики, то был приятно удивлен. Пиковая нагрузка на MySQL была примерно 3000 rpm, на Nginx \~8000 rps.

mysql

Cудя по логам, ни одного slow request не было, как и не было 404 и 50x страниц.

Пользуясь случаем, еще раз рекламирую свой хостинг, а тем кто станет моим рефералом обещаю оказывать всяческое содействие.


centr, mysql, nginx      

9 million hits/day with 120 megs RAM

Оставлю у себя в закладках.

After checking this for about 9 months, I can tell you this almost always reads that number: 300 microseconds. This is about one third the time a camera flash illuminates. That’s, well, pretty quick. When I started, my software was taking about 0.25 seconds (250 000 microseconds) to produce the front page of my website. I needed to improve performance by over 800x.

Далее


memcache, nginx, php      

Request uri в nginx

Второй раз натыкаюсь.

В первый раз я не мог понять почему на php скрипт приходил GET запрос, хотя я отправлял POST и при этом массив был пустой, но при просмотре php://input нужные мне переменные были видны.

Тут ситуация была простой, но не очевидной, при запросе, я не попадал в нужный location и nginx успешно отправлял меня на @404, в следствие чего, php получал уже GET запрос.

Сейчас, эта фича, помогает работать с ssi включениями, т.к. при сборе "блоков" страницы у нас есть возможность получить оригинальный URL и добраться до нужных нам GET параметров.

Из доков nginx:

$request_uri, эта переменная равна полному первоначальному URI вместе с аргументами;

Пример, вывод $_SERVER из подключенного ssi блока:

[QUERY_STRING] => do=search&action=search
[REQUEST_URI] => /?q=творог&lr=213

Что бы получить нужный нам фэйковый $_GET, можно сделать что-нибудь типо этого:

parse_str( str_replace('/?', '', getenv('REQUEST_URI') ), $original_get );

nginx, php      

Самое простое ускорение сайта

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

Что я предлагаю ?

Давайте засунем главную страницу сайта, в memcache, и настроим nginx что бы он отдавал ее прямо из memcache не обращаясь к интерпретаторам. Будем класть раз в минуту сроком жизни на 60 секунд. Стоит понимать, что данный способ нужно дорабатывать, если у вас на страницах используется динамичные данные, то есть данный способ актуален только для "гостей" сайта, благо nginx умеет работать и cookie.

Пример настройки nginx'a

location / {

    default_type    text/html;

    if ( $request_uri = '/')
    {
        set $memcached_key "index_page";
        memcached_pass 127.0.0.1:11211;

        error_page 404 503 = @fallback;
    }

    error_page 404 = @fallback;
}

Пример cron скрипта, который можно повесить на выполнение.

error_reporting(E_ALL);
ini_set('display_errors', 1);

if( class_exists('Memcache', FALSE))
{
    $mem = new Memcache;

    $mem->connect('localhost', 11211);

    $html = file_get_contents('http://blog.rpsl.info/?asd');

    if(!empty( $html ) )
    {
        //$mem->delete('index_page', 0);
        $mem->set('index_page', $html, 0, 60 );

        //echo $html;
    }
}
else
{
    echo 'no memcache';
}

Стоит обязательно обратить внимание, что бы запрашивая урл страницы, вы точно получали свежий ответ, т.к. возможна ситуация, когда произойдет зацикливание и ваш скрипт будет брать страницу из кэша и класть ее обратно в кэш.

Идею я донес, дальше сами справитесь.


memcache, nginx, web, разработка