Summary

Announced: 2010-05-20
Credits: 80sec
Affects: сайты на ngnix+php с возможностью загрузки файлов в директории с fastcgi_pass

Background

Зачастую How-To по настройке связки nginx с php-fpm / php-cgi есть подобные строчки:

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    include fastcgi_params;
}

Однажды мне надоело тыкать закладку Habrastorage в браузере. И я сделал вот что…

Обожаю задачи “на стыке технологий”, это одна из таких.
Задача:

• реализовать geoDNS*
• c возможностью wildcard (*.some.tst. A 1.2.3.4)
• с возможностью менять содержимое зон на ходу, добавлять новые зоны пачками
• без необходимости запускать громоздкие скрипты на каждый запрос “мимо кеша”
• научиться тестить этот реактор (с локалхоста, а не кучи proxy/VDS)

*) под geoDNS я подразумеваю возможность для клиентов из разных регионов отдавать разные, например, адреса сервера/А-записи (для США отдаётся IP сервера в США, для СНГ — в москве, для ЕС — в Европе ...)

Статья описывает

• метод реализации geoDNS
• метод тестирования
• эскизное решение на “чистом nginx”

Если интересно, причём же здесь nginx, прошу под кат.

Уже давно считается хорошим тоном отдавать контент сайта на языке, предпочитаемом пользователем. Некоторые сервера определяют язык по месту нахождения пользователя с помощью модулей геолокации, остальные берут настройки браузера. Языковые предпочтения пользователя часто сохраняются в cookie, и затем используются при повторном визите.

Какой метод определения языка пользователя подходит лучше – вопрос достаточно спорный. Мой личный ранг значимости языковой информации (в порядке убывания): cookie, настройки браузера, регион.

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

Распространенные варианты кодирования языковой информации о ресурсе следующие:

• каждая языковая версия на отдельном субдомене, например en.example.com, ru.example.com
• язык ресурса указывается в префиксе URI, например example.com/en/, example.com/ru
• язык ресурса указывается в GET параметре, например example.com?lang=en, example.com?lang=ru

Первый вариант наиболее радикальный, каждая языковая версия сайта рассматривается как отдельный ресурс. Могут возникнуть сложности с SSL сертификатом, необходимо заранее предусмотреть все возможные варианты в SAN DNS Host Name, или заказать сертификат с маской, например *.example.com.

Второй вариант наиболее практичный, выбор языка входит в URI, значит, не будет проблем с индексацией и копированием ссылки.

Третий вариант выглядит менее привычно, требует дополнительной логики при добавлении остальных GET параметров и может смутить пользователя при копировании ссылки. Не самый лучший вариант для публичных ссылок.

Я расскажу о реализации второго варианта на базе сервера NGINX. При минимальных изменениях можно применить описанные настройки и для первого варианта.

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

Я отметил две проблемы подавляющего числа конфигов nginx'а, попадавших мне на глаза:

• «Всё в одном файле»
• Дублирование настроек

С помощью моего подхода, надеюсь, эти и многие другие проблемы будут устранены.

Существует мнение, что nginx — отличный инструмент для отдачи статики.
Есть статьи, где описываются настройки sendfile или aio для «улучшения» отдачи.
На Хабре есть чего почитать о настройке proxy_store с proxy_cache для минимизации проблем со стороны мозгов сайта.
Еще в QA иногда возникают вопросы про кеширование картинок, например.

Зачем заниматься этой ерундой! — говорят опытные пользователи — OS лучше вас знает как кешировать файлы! С кешем и префетчем в современных OS, точнее FS, проблем нет! Зачем плодить свои кеши и списки популярных материалов и все такое?...

Есть только одно вредное «но» — в среде исполнения nginx (в общем случае Linux) понятие "файл" и вообще «файловая система» — просто понятие.
И однажды, когда я, подмонтировав сервер по sshfs, обновил один скриптик, случилось волшебное:
1. На каждой страничке стало на 4 картинки больше.
2. Сервера сдохли.
Что поделать — картинки хранились на glusterFS. Наступил полный FUSE.

Что такое MPEG-DASH

MPEG-DASH — технология нового поколения, позволяющая вещать адаптивный видео-поток. Данные разбиваются на фрагменты и передаются клиенту по протоколу HTTP. Это позволяет надежно передавать видео через существующую HTTP-инфрастуктуру, преодолевать прокси-сервера, а также безболезненно переносить проблемы с сетью, изменения сетевых адресов итд.

DASH — Dynamic Adaptive Streaming over HTTP. Стандарт DASH ISO/IEC 23009-1:2012 был разработан группой MPEG в 2011 году

Технология MPEG-DASH в целом аналогична другой известной технологии HLS (HTTP Live Streaming), разработанной компанией Apple и широко используемой на мобильных устройствах с iOS и Android. Поток представлен в виде небольших по длительности фрагментов и плейлиста (манифеста), содержащего метаданные потока и ссылки на фрагменты.

Доброго времени суток!

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

Перекопав полчища статей и опробовав множество вариантов, так и не нашел, что помогло бы с защитой. Взяв за основу статьи Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables и (D)DoS Deflate решил написать свой скрипт. Ну вернее не решил, а методом тыка и исправлений он получился сам.

Должен заметить, что статья от Алексея Кузьмина не идеальна, т.к. в логах nginx`a не достаточно копаться, да и обработка логов может потребовать много ресурсов. А именно в моем случае создавались логи более 50 Гиг, плюс запросы шли не «GET / HTTP/1.1», а «GET / HTTP/1.0», плюс, как оказалось, мой сервер сам от себя получал редиректы (127.0.0.1), которые не отображались в логах, которые отображались в запросе

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Хотелось бы сказать, что Stack Overflow — масштабный проект, но это не так. Я имею ввиду мы добились многого, но я не могу назвать наш проект “большим”, ещё рано. Давайте я приведу в пример некоторые цифры — с какой нагрузкой мы имеем дело сейчас. Срез статистики за 24 часа от 12 ноября 2013 года. Это обычный будний день. Отмечу, что здесь представлена информация только по нашим собственным вычислительным мощностям, без CDN.

Проверка на поддержку конкретных технологий браузером с помощью JavaScript по праву считается наилучшей практикой при клиент-сайд разработке (Часто используют другой способ, заключающийся в проверке из какого браузера пользователь просматривает страницу — Прим. пер.), но, к сожалению, такую проверку нельзя было сделать с использованием только лишь CSS. Firefox, Chrome и Opera недавно объявили о поддержке CSS директивы @supports и CSS.supports (JavaScript), которые помогут разработчикам определять справится ли браузер пользователя с CSS свойством или нет. Давайте посмотрим на них в деле!

По просьбе друга пытался сделать онлайн-радио. И вроде все бы ничего, но возникла необходимость транслировать и управлять многими потоками независимо друг от друга…

Для этого я выбрал следующий путь…

Неожиданно поступила задача разобраться почему определенный сайт не работает столь быстро сколь хочется. В основе его CakePHP, в связке с Apache и MySQL. В статье описание процесса поиска узких мест и приведение в порядок на столько, на сколько это возможно.

Название сайта светить не буду — думаю, программисты сами узнают. Скажу лишь, что это приложение для социальной сети нагрузкой 70-150 тысяч посетителей в обычное время. Все усложняется тем, что периодически производится рекламная рассылка, которая привлекает около 200-300 тысяч посетителей за пару часов.

Итак, под катом описание всей борьбы на протяжении 4 дней.

Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

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

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Встроенный Perl.

«Воровство доменов», а точнее, несанкционировнные смены NS-серверов, неправильные регистрации реселлерами, просто ошибки при регистрации — продолжаются. Тема не новая, но, как показывает практика — год из года не теряет своей актуальности.
Постарался собрать в одном месте все советы по правильной регистрации доменов. Заодно — вспомнил несколько мифов о доменах.
Даже если Вы знаете о доменах больше меня, пожалуйста, посмотрите статью — сделаем вместе «Наиболее полное руководство», статья ориентирована на новичков.
Где и как регистрировать домены? Что делать, если домен уже зарегистрирован, но есть сомнения в правильсти его регистрации?

Родное правительство заботится о гражданах и старается предоставить им возможность как можно меньше лично встречаться с собственными представителями. Для этих целей создан портал «Госуслуги», для этого был (есть) проект УЭК, карта «Электронное правительство» (выпускают несколько банков), идут разговоры об электронных паспортах на базе SIM-карт и т.д. и т.п. О том, как заставить «Электронное правительство» работать в Ubuntu, читайте ниже.

оторвался на час от дел и вот он первый пост:

Карты помогают людям найти нужный адрес или составить маршрут, а иногда и просто сориентироваться в пространстве. Это базовая функция любых карт, и она довольно очевидна. Интернет добавляет к ней новые возможности, — например, поиск нужных организаций и информации о них. Теперь организации можно не только искать, но и пользоваться их услугами — сегодня на Яндекс.Картах появилась возможность заказать столик в ресторане, записаться на стрижку или на приём к врачу.

Я люблю слушать музыку и узнавать новых исполнителей. Так получилось, что музыку я слушаю целиком альбомами, а про новых исполнителей узнаю через FunkySouls и LastFM. Некоторое время я слушал музыку через Prostopleer и Muzebra, пока ими можно было пользоваться. А еще я уже один раз делал приложение для ВКонтакте и неплохо поработал с их API. В общем я решил сделать небольшой мэшап и кажется получилось круто.

Listen! — это новое приложение для Google Chrome, в котором можно слушать и искать музыку ВКонтакте, сохранять ее в облако Google Drive для прослушивания без интернета и даже скачивать ее на компьютер (sic!). А с помощью базы данных от LastFM можно знакомиться с альбомами целиком, а также похожими исполнителями.

Примерно год назад появилась задача сделать красивый html5 аудио-плеер. Дизайнеры нарисовали простейшую визуализацию:



Самый простой вариант — рисовать на фоне «шум», никак не связанный с играющей музыкой. Но мы не ищем лёгких путей.

На хабре нашлась статья визуализация аудио в HTML5, в которой подробно рассмотрен вопрос визуализации с помощью javascript. Существует 2 стандарта получения информации об аудио:

• Web Audio API для Chrome,
• Audio Data API для Firefox.

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

Упрощенное демо

После публикации ряда заметок на тему сжатия и объединения JavaScirpt-файлов стоит все же осветить наиболее характерные проблемы этого самого сжатия и объединения.

Начнем с простого: как JS-сжатие способно испортить нам настроение. И как его поднять обратно :)

UPD стартовал конкурс ускорения сайтов. В призах: монитор, веб-камера, мышь. Все гипер-быстрое.

Не секрет, что пользователи любят, когда контент на сайте обновляется чаще, чем раз в год. Эту любовь пользователей к динамическим страничкам разделяют и поисковики. Google, например, умеет определять наличие обновляющихся блоков на страничке и добавляет ей немного кармы (читай, PR).

Однако динамический контент довольно плохо сочетается с большими нагрузками. Для веб-сервера, отдача статической странички — намного более простая задача, чем запуск кода, который сгенерит эту страничку динамически. В некоторых случаях может выручить прегенерация всех возможных вариантов странички, но это не спасёт, если их слишком много, или страница обновляется слишком часто.