Поездка в Берлин, Роттердам, Дюссельдорф в марте 2017

В марте 2017 съездил в короткое путешествие, чуть больше чем на одну неделю, в Берлин, Роттердам и Дюссельдорф. Маршрут получился не самым оптимальным, слишком много переездов за такой короткий интревал, но все равно интересным: Москва — Берлин — Роттердам — Берлин — Дюссельдорф — Берлин — Москва. Все перемещения кроме поездок из и в Москву это разные местные поезда.

К своему сожалению я забыл дома зарядник от фотоаппарата, а аккумулятор был на нуле. Новый зарядник купил не сразу, поэтому фотки начинаются с Роттердама. Хотя это не страшно, в Берлине я уже бывал дважды в 2012 и 2013, поэтому увидеть что-то новое не рассчитывал.

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

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

Не смотря ни на что, город очень комфортный для жизни: транспортная система гораздо эффективнее чем в Москве и даже в часы пик нет таких толп людей как в московском метро. В городе множество недорогих кафешек, здесь в кафешке Chan я попробовал самый вкусный Том Ям за пределами Таиланда и самый вкусный вок за пределами Азии в какой-то дешевой забегаловке.

Читать дальше ➠

HTTP/2 на этом сайте

Обновил на этом сайте nginx до версии 1.9.5 и включил поддержку HTTP/2. Для теста погонял сайт до и после на WebPagetest. Честно говоря, результат измерений не сильно впечатлил, вот результат до:

а вот после:

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

Ниже информация о том, что нужно сделать для апгрейда nginx в Ubuntu.

Читать дальше ➠

Nginx и HTTP/2

22 сентября 2015 года вышел nginx версии 1.9.5 — это первая стабильная версия nginx с поддержкой HTTP/2.

Какие преимущества дает HTTP/2:

  • мультиплексированные соединения — теперь весь контент с одного домена скачивается в рамках одного TCP-соединения, а не с помощью нескольких keep-alive соединений. Более того, даже контент с нескольких доменов может быть скачан в рамках одного TCP-соединения при условии, что эти домены имеют общий ip-адрес и SSL-сертификат,
  • сжатие HTTP-заголовков,
  • приоритезация — клиент может указать какие из запрашиваемых ресурсов наиболее приоритетны, а ткаже задать зависимости между ресурсами (ресурс Б не будет загружен до тех пор пока не загружен ресурс А),
  • server push — сервер может сам определять какие ресурсы могут быть затребованы клиентом в ближайшее время (например, на основании собранной статистики) и передавать их клиенту заранее. Клиент в свою очередь может отказаться от приема такого контента,
  • flow control — клиент может попросить сервер временно снизить скорость загрузки того или иного ресурса, или остановить загрузку полностью. Это полезно в случае, например, если юзер нажал паузу во время загрузки и просмотра видео.

С новым HTTP/2 устаревают такие best practice из HTTP/1.1 как шардирование доменов (загрузка статического контента с нескольких поддоменов одного домена), использование спрайтов изображений, объединение нескольких маленьких js/css файлов в один. Более того, эти практики теперь превращаются в антипаттерны: шардить домены нет смысла, так как данные будут загружены быстрее в рамках одного соединения с мультиплексированием и приоритезацией, спрайты и объединение файлов мешают кешированию — при обновлении одного из файлов браузеру заново придется загузить весь большой объединенный файл вместо одного изменившегося.

Стандарт HTTP/2 не требует обязательного использования TLS, однако современные браузеры включают HTTP/2 только для шифрованных соединений. Связано это, во-первых, с тем, что на шифрованных соединениях больше выигрыш от использования новой версии протокола, так как TLS handshake это достаточно тяжеловесная операция, а в случае использования HTTP/2 будет установлено всего 1 соединение с одним источником. Во-вторых, браузер и веб-сервер должны как-то сообщить друг другу о поддержке HTTP/2, а это легко сделать в рамках TLS handshake без добавления лишних запросов к серверу.

P.S. Прикрутил сегодня к этому блогу SSL-сертификат и планирую в ближайшее время обновить используемый веб-сервер, чтобы добавить поддержку HTTP/2.

P.P.S С помощью вот этого плагина для Хромиума и всех его форков можно отслеживать какие сайты уже используют HTTP/2 или его предшественника SPDY.

P.P.P.S. Вот ссылка на пост в официальном блоге nginx с описанием возможностей HTTP/2 и ссылками на дополнительные полезные документы.

GNU parallel и xargs. Параллельный запуск нескольких копий команды с разными аргументами

Задача

GNU Parallel

Есть консольная команда вида:

./do-something.sh -x 1

Значение аргумента x может меняться в диапазоне от 1 до 30 000. Выполнение команды для одного аргумента занимает от 30 секунд до 15 минут. Нужно максимально быстро выполнить эту команду для заданного диапазона аргументов на N-ядерном сервере максимально используя ресурсы сервера.

Возможные варианты решения

  1. Простой цикл от 1 до 30 тысяч с запуском команды на каждой итерации будет использовать только 1 ядро. Это решение неприемлемо: оно будет работать слишком долго и не задействует все доступные ресурсы сервера.
  2. Можно вручную разбить диапазон на N частей и запустить N циклов вида:
   for i in `seq 1 1000`
   do
    ./do-something.sh -x $i
   done

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

Читать дальше ➠

Случай в лифте

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

Мы с женой шли по коридору к лифту. Возле лифта уже стоял парень, на вид лет 20, который тоже ждал лифт. Пока мы подходили лифт уже приехал, открыл двери и парень успел в него зайти. Для меня привычно, что в таких ситауциях человек чаще жмет кнопку нужного этажа и уезжает, реже — жмет кнопку “открыть двери” чтобы подождать подходящих людей.

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

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

apache_nginx_tw_cover.png

Apache vs Nginx: практический взгляд

Перевод статьи Джастина Эллингвуда “Apache vs Nginx: Practical Considerations”.

Введение

Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.

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

Общий обзор

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

Apache

Apache HTTP Server был разработан Робертом Маккулом в 1995 году, а с 1999 года разрабатывается под управлением Apache Software Foundation — фонда развития программного обеспечения Apache. Так как HTTP сервер это первый и самый популярный проект фонда его обычно называют просто Apache.

Веб-север Apache был самым популярным веб-сервером в интернете с 1996 года. Благодаря его популярности у Apache сильная документация и интеграция со сторонним софтом.

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

Nginx

В 2002 году Игорь Сысоев начал работу над Nginx для того чтобы решить проблему C10K — требование к ПО работать с 10 тысячами одновременных соединений. Первый публичный релиз был выпущен в 2004 году, поставленная цель была достигнута благодаря асинхронной event-driven архитектуре.

Nginx начал набирать популярность с момента релиза благодаря своей легковесности (light-weight resource utilization) и возможности легко масштабироваться на минимальном железе. Nginx превосходен при отдаче статического контента и спроектирован так, чтобы передавать динамические запросы другому ПО предназначенному для их обработки.

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

Читать дальше ➠

Поездка в Ирландию: гэльский футбол, виски и день святого Патрика

Ирландия — это небольшое государство, занимающее большую часть одноименного острова на севере Европы. Оставшуюся часть острова занимает Северная Ирландия, входящая в состав Великобритании. В столице Ирландии — Дублине — живет около 1 миллиона человек, а мне довелось посетить второй по величине город — Корк — с населением около 250 тысяч (так и хочется добавить “уников в сутки”) человек.

Первое что бросается в глаза еще на подлете это то насколько Ирландия зеленая страна. Весь остров покрыт зеленью и это несмотря на март и температуру около 5 °С. Города в Ирландии малоэтажные, на окраине Корка дома не превышают 2 этажей, ближе к центру редко могут достигать 4-5 этажей. Здесь же, в Корке, находится самое высокое здание в Ирландии — 17 этажей и 71 метр высотой. И это, я напомню, второй по величине город Ирландии. За время моей поездки я успел посетить еще 2 города — Килларни и Мидлтон (до Дублина пока не добрался), здесь таких “небоскребов” и вовсе нет.

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

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

Читать дальше ➠

Ubuntu 14.04 не загружается после установки на ноутбук Sony Vaio с UEFI и предустановелнной Windows 7

Проблема: Ubuntu 14.04 корректно устанавливается на ноутбук Sony Vaio с UEFI и предустановленной Windows 7, но загрузки ОС не происходит, по прежнему грузится только Windows без возможности выбрать другую ОС. Использование из-под Ubuntu (live cd/usb) boot-repair и с дефолтными, и с кастомными настройками не помогают:

sudo add-apt-repository -y ppa:yannubuntu/boot-repair && sudo apt-get update    
sudo apt-get install -y boot-repair && boot-repair

Выполнение из-под Windows команды:

bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi

не помогает.

Нагуглил тут: http://askubuntu.com/questions/150174/sony-vaio-with-insyde-h2o-efi-bios-will-not-boot-into-grub-efi/150640#150640 и тут: http://askubuntu.com/questions/159918/cant-dual-boot-ubuntu-12-04-and-windows-7-on-sony-vaio-s-15-2012, что проблема может быть в том, что виндовый лоадер захардкожен в прошивке ноутбука. По этому проблема решилась заменой виндового .efi файла аналогичным убунтовским (из-под Ubuntu live cd и с предварительным бэкапом первого файла, конечно):

sudo su
mkdir -p /mnt/efi_partition
mount -t vfat /dev/sda3  /mnt/efi_partition
cd /mnt/efi_partion/EFI/Microsoft/Boot
cp bootmgfw.efi bootmgfw.efi.old
cp /mnt/efi_partition/EFI/ubuntu/grubx64.efi bootmgfw.efi
update-grub
reboot

В моем случае больше ничего не понадобилось, но, возможно, потребуется добавить Windows в настройки Grub, для этого в файл /etc/grub.d/40_custom надо добавить:

menuentry "Windows 7" {
    set root='(hd0,gpt3)'
    chainloader /EFI/Boot/bootx64.efi
}

И обновить настройки:

update-grub

Ну и, напоследок, может захотеться поменять порядок загрузки ОС, для этого в /etc/default/grub параметру GRUB_DEFAULT нужно присвоить номер ОС в списке систем, который появляется при загрузке компьютера (и опять не забыть выполнить update-grub).

Update

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

mountvol K: /S

(вместо K: можно подставить любую неиспользуюмую в именах дисков букву). Далее из-под админа копируем файл grubx64.efi на место bootmgfw.efi как это указано в примере с Убунту.

Новые впечатления о Чехии

Пишу продолжение поста Первые впечатления о Праге.

Обмен валюты

С честными обменными пнуктами в центре Праги туго. Все обменники можно разделить на 3 типа. Первый тип обменников берет комиссию с операций от 5 до 20 (!!!) процентов. Второй тип предлагает сильно заниженный курс обмена: при реальной цене примерно в 27,60 крон за евро такие обменники предлагают по 19-20 крон за евро. При этом такие обменники часто завлекают большой надписью типа “комиссия 0%”. И только третий, честный, тип предлагает более или менее адекватный курс (около 27,20 крон за евро) и нулевую комиссию.

Такими драконовскими тарифами на обмен валюты могут похвастаться и обменные пункты под вывеской с громким брендом типа Western Union. Поэтому всегда важно уточнять у кассира сколько крон он даст в обмен на вашу валюту.

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

Читать дальше ➠
csp_shield_logo_cover.jpg

Введение в Content Security Policy (CSP)

Перевод статьи Майка Веста An Introduction to Content Security Policy от 15 июня 2012 года. Несмотря на то, что статье уже больше 2 лет, информация все еще актуальна и полезна. Об интересном опыте внедрения CSP в Яндексе можно почитать в этой статье.


Модель безопасности в вебе базируется на политике одинакового источника (same origin policy). Только код сайта https://mybank.com должен иметь доступ к данным https://mybank.com, а https://evil.example.com ни при каких условиях не должен получить такого доступа. Каждый источник остается изолированным от остального веба, что дает разработчикам безопасную песочницу, в которой можно разрабатывать и экспериментровать. Теоретически, это бриллиант без изъяна, но на практике, злоумышленники могут найти способы обойти эту систему.

Например, такие атаки как межсайтовый скриптинг (Cross-site scripting, XSS) позволяют обойти политику одного источника, обманным путем заставив сайт доставить вредоносный код вместе легитимным контентом. Это большая проблема, так как браузеры доверяют всему коду, который показывается на странице, так как он является частью страницы доставленной из доверенного источника. XSS Cheat Sheet — это старый, но весьма актуальный список методов, которые могут быть использованы злоумышленниками для внедрения зловредного кода. Если злоумышленнику успешно удается внедрить любой код в страницу, то игру можно считать оконченной: данные сессии пользователя становятся скомпроментированными и информация, которая должна оставаться в секрете, попадает в руки к Плохим Парням™. Мы, конечно же, хотим предотвратить такую возможность.

Этот туториал освящает один многообещающий механизм защиты, который может значительно снизить риск и вред от XSS-атак в современных браузерах — Content Security Policy (CSP).

Читать дальше ➠