Как известно, для обработки соединений NGINX использует асинхронный событийный подход. Вместо того, чтобы выделять на каждый запрос отдельный поток или процесс (как это делают серверы с традиционной архитектурой), NGINX мультиплексирует обработку множества соединений и запросов в одном рабочем процессе. Для этого применяются сокеты в неблокирующем режиме и такие эффективные методы работы с событиями, как epoll и kqueue.

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

Каждый процесс расходует память и каждое переключение между ними требует дополнительных циклов процессора, а также приводит к вымыванию L-кэшей

У медали есть и обратная сторона. Главной проблемой асинхронного подхода, а лучше даже сказать «врагом» — являются блокирующие операции. И, к сожалению, многие авторы сторонних модулей, не понимая принципов функционирования NGINX, пытаются выполнять блокирующие операции в своих модулях. Такие операции способны полностью убить производительность NGINX и их следует избегать любой ценой.

Но даже в текущей реализации NGINX не всегда возможно избежать блокировок. И для решения данной проблемы в NGINX версии 1.7.11 был представлен новый механизм «пулов потоков». Что это такое и как его применять разберем далее, а для начала познакомимся с нашим врагом в лицо.

В стандартной библиотеке Python 3.4 в своё время появился модуль asyncio, позволивший удобно и быстро писать асинхронный код. А уже к Python 3.5 в синтаксис были добавлены конструкции async/await, окончательно оформившие асинхронность «из коробки» как красивую и гармоничную часть языка.



Хотя asyncio сам по себе и позволяет писать высоконагруженные веб-приложения, оптимизация производительности не была приоритетом при создании модуля.

Один из авторов упомянутого PEP-492 (async/await) Юрий Селиванов (на Хабре — 1st1, его твиттер) взялся за разработку альтернативной реализации цикла событий для asyncio — uvloop. Вчера вышла первая альфа-версия модуля, о чём автор написал развёрнутый пост.

Если вкратце, то uvloop работает примерно в 2 раза быстрее Node.js и практически не уступает программам на Go.

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

Проблема: некоторые пользователи не могли скачать бинарный файл объемом несколько мегабайт. Соединение почему-то обрывалось, хотя файл находился в процессе скачивания. Вскоре мы убедились, что где-то в нашей системе был баг. Воспроизвести проблему можно было достаточно просто единственной командой curl, но исправить ее потребовало невероятных затрат сил и времени.

Доброго времени суток, %username%! Сегодня мы отправимся изучать бесчисленные возможности фреймворка для реверсера — radare2. В виде подопытного я взял первую попавшую бомбу, она оказалась с сайта Университета Карнеги Меллон.

Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.

DaData.ru — сервис автоматической проверки, исправления и дедупликации контактных данных (ФИО, адресов, телефонов, email, паспортов).

У меня в телефоне 453 контакта. Среди них встречаются дубли: один и тот же человек записан то как «Леха», то как «Алексей Мегафон», а то и как «Зиновьев, Алексей Иванович». У Лехи указан скайп и день рождения, у «Алексея Николаевича» — емейл и основной мобильный номер, а у «Мегафона» — запасной номер от понятнокакого оператора.

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

Раньше, у меня довольно часто возникала такая ситуация, когда одновременно работаешь в терминале и, например, в браузере.
После нескольких часов работы начинаешь путаться и в терминале вместо [Ctrl]+[Shift]+[C] нажимаешь [Ctrl]+[C], а в браузере наоборот. В итоге в терминале вы получаете прерывание а в браузере вместо ожидаемого эффекта у вас медленно прогружается дебаггер.
В один прекрасный момент меня это достало и я решил, что пора что-то менять…

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

Сегодня мы поговорим о том, как команда поискового сервиса Algolia пыталась решить внезапно возникшую проблему с SSD-дисками.

Итак, в продолжение предыдущей статьи пишу 2-ю часть, где мы попробуем добраться до того, чтобы написать проволочный рендер. Напоминаю, что цель этого цикла статей — написать сильно упрощенный аналог OpenGL на Rust. В качестве основы используется «Краткий курс компьютерной графики» от haqreu, в своих же статьях я сосредоточиваюсь больше не на графике как таковой, а на особенностях реализации при помощи Rust: возникающие проблемы и их решения, личные впечатления, полезные ресурсы для изучающих Rust. Сама получившаяся программа не имеет особенной ценности, польза от этого дела в изучении нового перспективного ЯП и основ трехмерной графики. Наконец, это занятие довольно таки увлекательно.

Напоминаю также, что поскольку я не являюсь профессионалом ни в Rust ни в 3D-графике, а изучаю эти вещи прямо по ходу написания статьи, то в ней могут быть грубые ошибки и упущения, которые я, впрочем, рад исправить, если мне на них укажут в комментариях.


Машинка, которую мы получим в конце статьи

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Последние пару лет я пишу под ядро Linux и часто вижу, как люди страдают от незнания давнишних, общепринятых и (почти) удобных инструментов. Например, как-то раз мы отлаживали сеть на очередной реинкарнации нашего прибора и пытались понять, что за чудеса происходят с обработкой пакетов. Первым нашим позывом было открыть исходники ядра и вставить в нужные места printk, собрать логи, обработать их каким-нибудь питоном и потом долго думать. Но не зря я читал lwn.net. Я вспомнил, что в ядре есть готовые и прекрасно работающие механизмы трассировки и профилирования ядра: те базовые механизмы, с помощью которых вы сможете собирать какие-то показания из ядра, а затем анализировать их.

Засматриваетесь на 4K UHD-мониторы, но ваш лаптоп не поддерживает высокие разрешения? Купили монитор и миритесь с частотой обновления в 30Гц? Повремените с апгрейдом.

TL;DR: 3840×2160@43 Гц, 3200×1800@60 Гц, 2560×1440@86 Гц на Intel HD 3000 Sandy Bridge; 3840×2160@52 Гц на Intel Iris 5100 Haswell.

Предыстория

Давным-давно, когда все мониторы были большими и кинескопными, компьютеры использовали фиксированные разрешения и тайминги для вывода изображения на экран. Тайминги были описаны в стандарте Display Monitor Timings (DMT), и не существовало универсального метода расчета таймингов для использования нестандартного разрешения. Мониторы отправляли компьютеру информацию о себе через специальный протокол Extended display identification data (EDID), который содержал DMT-таблицу с поддерживаемыми режимами. Шло время, мониторам стало не хватать разрешений из DMT. В 1999 году VESA представляет Generalized Timing Formula (GTF) — универсальный способ расчета таймингов для любого разрешения (с определенной точностью). Всего через 3 года, в 2002 году, его заменил стандарт Coordinated Video Timings (CVT), в котором описывается способ чуть более точного рассчитывания таймингов.

Оба стандарта были созданы с учетом особенностей хода луча в электро-лучевой трубке, вводились специальные задержки для того, чтобы магнитное поле успело измениться. Жидкокристаллические мониторы, напротив, таких задержек не требуют, поэтому для них был разработан стандарт CVT Reduced Blanking (CVT-R или CVT-RB), который является копией CVT без задержек для CRT, что позволило значительно снизить требуемую пропускную способность интерфейса. В 2013 году вышло обновление CVT-R c индексом v2, но, к сожалению, открытого описания стандарта в интернете нет, а сама VESA продает его за $350.

История

Наконец-то настала эра высокой плотности пикселей и на ПК. На протяжении последних нескольких лет, нас встречал театр абсурда, когда на мобильные устройства ставят пятидюймовые матрицы с разрешением 1920×1080, полки магазинов уставлены большими 4K-телевизорами (хоть на них и смотрят с расстояния 2-4 метров), а мониторы как были, так и оставались с пикселями с кулак. Подавляющее большинство говорит, что Full HD выглядит «достаточно хорошо» и на 27" мониторе, забывая, что предыдущее «достаточно хорошо» чрезвычайно быстро ушло после выхода iPad с Retina. Вероятнее всего, такая стагнация произошла из-за плохой поддержки высокой плотности пикселей в Windows, которая более-менее устаканилась только к выходу Windows 8.1.

Столкнулся с тем, что youtube.com «забывает» видео, которые я просмотрел.
Приходится смотреть много образовательных каналов, а потом вспоминать, видел я это или нет.
Посмотрел какую-нибудь лекцию и через несколько дней (месяцев, лет) статус "просмотрено" пропадает.
Или, наоборот, посмотришь 2 минуты какой-нибудь лекции, ляжешь спать, а на утро лекция имеет статус «просмотрено».

Вот и решил взять под контроль информацию о просмотрах на youtube в свои руки.
И хранить эту информацию вне зависимости от ютюба.

Чтобы смотреть видео на ютюбе с разных устройств и быть не привязанным к локальному компу, я выложил сайт в онлайн:
http://memtube.com
И смотрю все оттуда.
У кого есть желание, пожалуйста, присоединяйтесь. На сайте в любой момент можно скачать Excel файл с историей просмотров:

Если хотите сделать свой собственный сайт, то подробности под катом.

Многим из вас знаком Wireshark — анализатор трафика, который помогает понять работу сети, диагностировать проблемы, и вообще умеет кучу вещей.



Одна из проблем с тем, как работает Wireshark, заключается в невозможности легко проанализировать зашифрованный трафик, вроде TLS. Раньше вы могли указать Wireshark приватные ключи, если они у вас были, и расшифровывать трафик на лету, но это работало только в том случае, если использовался исключительно RSA. Эта функциональность сломалась из-за того, что люди начали продвигать совершенную прямую секретность (Perfect Forward Secrecy), и приватного ключа стало недостаточно, чтобы получить сессионный ключ, который используется для расшифровки данных. Вторая проблема заключается в том, что приватный ключ не должен или не может быть выгружен с клиента, сервера или HSM (Hardware Security Module), в котором находится. Из-за этого, мне приходилось прибегать к сомнительным ухищрениям с расшифровкой трафика через man-in-the-middle (например, через sslstrip).

Логгирование сессионных ключей спешит на помощь!

Что ж, друзья, сегодня я вам расскажу о способе проще! Оказалось, что Firefox и Development-версия Chrome поддерживают логгирование симметричных сессионных ключей, которые используются для зашифровки трафика, в файл. Вы можете указать этот файл в Wireshark, и (вуаля!) трафик расшифровался. Давайте-ка настроим это дело.

Примечание: приведённая в статье информация во многом устарела, и предназначена скорее для общего ознакомления. Сейчас можно попробовать использовать утилиты вроде ptproxy для создания туннеля с помощью любого актуального pluggable transport для Tor.

Преамбула

В связи с наметившимися тенденциями решил я обфусцировать свой скромный OpenVPN-туннель, просто чтобы набить руку — мало ли пригодится…

Дано: дешевая VPS с белым IP, работающая под Ubuntu Trusty Server Edition и служащая OpenVPN сервером.
Требуется: по-возможности скрыть OpenVPN туннель, желательно без изобретения велосипедов.

Доброго времени суток, уважаемые товарищи Хабра.
На написание статьи заметки, меня побудила статья: «Мигрируем на HTTPS».

Напоминаю, что китайцы в лице компании WoSign до сих пор раздают бесплатно сертификаты и теперь не обязательно знать китайский язык для того, чтобы его получить. Метод по статье «Бесплатные SSL-сертификаты на 2 года с поддержкой до 100 доменов» на данный момент не работает и за сертификат китайцы хотят от ￥488.

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

На этот раз я хочу подойти к вопросу планирования с другой стороны. А именно, теперь я постараюсь рассказать про планирование не потоков, а их “младших братьев”. Так как статья получилась довольно объемной, в последний момент я решила разбить ее на несколько частей:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

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

Рассказывать я постараюсь подробно, описывая основное API и иногда углубляясь в особенности реализации, особо заостряя внимание на задаче планирования.

Предисловие

Некоторые из вас наверняка недавно проходили Stanford'ские курсы, в частности ai-class и ml-class. Однако, одно дело просмотреть несколько видео-лекций, поотвечать на вопросики quiz'ов и написать десяток программ в Matlab/Octave, другое дело начать применять полученные знания на практике. Дабы знания полученые от Andrew Ng не угодили в тот же тёмный угол моего мозга, где заблудились dft, Специальная теория относительности и Уравнение Эйлера Лагранжа, я решил не повторять институтских ошибок и, пока знания ещё свежи в памяти, практиковаться как можно больше.

И тут как раз на наш сайтик приехал DDoS. Отбиваться от которого можно было админско-программерскими (grep / awk / etc) способами или же прибегнуть к использованию технологий машинного обучения.

Далее пойдёт рассказ о создании нейронной сети на Python 2.7 / PyBrain и её применении для защиты от DDoS'а.

На текущий момент существует единственный официальный способ компиляции под N900 — через Scratchbox. Чем он мне не угодил? Да вот чем. Во-первых, он есть только под i386, со всеми вытекающими из этого весёлостями в виде необходимости держать кучу 32-хбитных библиотек. Во-вторых, ставится оно вопреки всем канонам зачем-то в /scratchbox, попутно прописывая свои модули для binfmt и, вытворяя прочую похабщину, разрушает стройную структуру дистрибутива. В-третьих там достаточно древний qemu, что даёт отнюдь не рекордную скорость компиляции. Ну и в-четвёртых, ставится это чудо очень медленно (я не знаю, где они хостятся, но установщик качал полгига пакетов довольно-таки длительное время. Кстати говоря, весит оно в установленном виде тоже изрядно. А поверх него ещё идёт SDK.
Ну и самое важное. qemu-user не поддерживает весь набор системных вызовов ядра. А, значит, часть софта (в частности, mono), банально не сможет работать. Проблему можно было бы решить, chroot'ясь в окружение из arm-ной системы в режиме полной эмуляции, но см. пункт первый.
В общем, убогое поделие, вообще не представляю, у кого рука поднялась его использовать в серьёзном проекте.

По-идее ещё можно компилить непосредственно на устройстве. Но тут проблема в том, что там стоит busybox, c которым очень плохо дружит тот же dpkg-buildpackage. Соответственно, при переносе rootfs c устройства и попытках оную использовать, эти грабли никуда не исчезают. А заменить его на coreutils не так-то просто, ибо это сломает часть зависимостей и отвалится полсистемы.



И что делать? А мы пойдём другим путём. Изобразим из себя ярых последователей барона Мюнхгаузена и в лучших традициях процедуры bootstrap (поднятие самого себя за шнурки ботинок) установим систему с нуля из пакетов. Как именно, читайте под катом.

Ещё когда Nokia и Intel объявили о создании MeeGo стало ясно, что перспективы Nokia N900 и её Maemo 5 операционной системы не очень хороши. В скоре стало известно, что MeeGo официально не поддерживает N900, то есть сборку этой ОС для девайса делают добровольцы, не имея доступа к закрытым драйверам Nokia (что ведет к ряду проблем, как видно и из работы NITDroid).

Однако прошивка PR1.3 в итоге не стала последней, прошивки выходят каждую неделю! Также и нехватка игр перестала быть проблемой. Всё это произошло буквально за последние 2-3 месяца, и за хабракатом я расскажу, какие же возможности дало устройству сообщество.