В прошлый раз мы поговорили о «перестройке» IT-монополий, сломе cookie-стен и открытом ПО, а до этого — обсудили непривычную «дистанционку», личную ИБ и то, почему разработчики дороже денег. Сегодня вновь делимся главными моментами из наших избранных материалов.
Компактный обзор хода развития проекта — последних новостей о тестах и представленных имплементациях протокола. Интересующихся темой приглашаем под кат.
QUIC разрабатывают с 2013 года, а с марта 2016-го — к процессу подключились и в IETF (Internet Engineering Task Force). На тот момент в протоколе, рассматриваемом в качестве Читать полностью »
Формат RFC существует с 1969 года — его представили во время обсуждения ARPANET. Тогда инженер Стив Крокер написал RFC 1 о работе программного обеспечения хоста.
С тех пор прошло более 50 лет, но Request for Comments все еще в ходу — опубликовано ~9 тыс. документов по сетевым протоколам, моделям хранения данных и алгоритмам шифрования.
В этом многообразии встречаются RFC, у которых нет практического применения. Их написали по большей части ради шутки. Сегодня расскажем о некоторых находках из этой области.
Привет! Меня зовут Илья. Два года назад я присоединился к работе над мобильным клиентом IMAP. Ранние версии приложения долго загружали список писем и тратили большое количество трафика для обновления ящика. Встал вопрос об оптимизации работы с протоколом и о возможностях этого протокола вообще. О протоколе я не знал ничего и погрузился в чтение документации. Оказывается, все это время клиент использовал протокол напролом и совсем не учитывал особенности реализации. Эти особенности помогли ускорить загрузку почты в 2 — 3 раза. О том что такое IMAP и какие есть фишки для его оптимизации дальше в моей статье.Читать полностью »
Как известно, управление ключами является одной из самых сложных задач в криптографии. Буквально на днях в качестве RFC 8645 опубликован документ “Re-keying Mechanisms for Symmetric Keys” («Механизмы смены симметричных ключей»). Он является результатом двух с половиной лет работы исследовательской группы CFRG, определяющей развитие и использование криптографии в IETF, а в его основу легли многолетние исследования и опыт работы российских специалистов. Далее мы кратко расскажем в чем суть этого RFC и почему он получился именно таким.
Читать полностью »
Новая версия PHP хоть и является минорной, но уже несёт множество новых, без преувеличения, крутых возможностей как для синтаксиса языка, так и для его производительности. Список новшеств не окончательный, но основные изменения уже внесены и приняты. Релиз планируется на декабрь 2019 года.
Ключевые изменения грядущей версии:
Подробнее об этих и других изменениях читайте под катом.
Читать полностью »
Преамбула: в один из дней мы решили подключить к нашему сайту CDN, для того, чтобы радовать пользователей более быстрой загрузкой страниц. После некоторых поисков выбор пал на Highwinds, т.к. они заявляли, что поддерживают весь нужный функционал и с ними удалось договориться на очень вкусную цену. После успешного перевода сайта на работу через Highwinds мы решили— а почему бы не переключить на них и наше REST API для мобильных приложений. И тут начались интересности.
Читать полностью »
Важно ли знать форматы заголовков передаваемых данных? Во многих учебных курсах по сетям разбору заголовков протоколов уделяется больше или меньше времени, но обычно без этого не обходится. Нося по своей природе описательный характер часто их изучение вызывает скуку, а наличие средств автоматического разбора не улучшает картину. Иногда заголовок действительно содержит интересный подход, но в большинстве случаев всё это вписывается в какой-то один принцип и следующий новый формат обычно уже не вызывает удивления. Самое интересное это, конечно, всевозможные сочетания тех опций, которые влияют на функционал, но стоит ли помнить какие опции в каком порядке вписываются в заголовке?
Не могу сказать, что я это помню, ещё не могу сказать что это мне мешает в работе. Я даже не могу сказать, что мне приходится часто видеть заголовки в каком-то необработанном виде, потому что, как правило, сообщения в syslog или на консоли уже переформатированы в связные английские предложения. Но, иногда, приходиться смотреть глубже, например, этот год был урожайный на подобные сообщения:
Ericsson SmartEdge
notification msg sent (nbr 192.0.2.1, context 0x40030044 32 bytes, repeated 89 times, code 3/4 (update: attribute flags error) -
0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed 5bdc 3f01Cisco, то же с другой стороны
NOTIFICATION received from 192.0.2.2 (External AS 64496):
code 3 (Update Message Error) subcode 4 (attribute flags error),
Data: e0 07 08 00 03 02 ed 5b dc 3f 01Попробуем разобрать это руками как написано в RFC4721. Не будем искать причину — просто разбор заголовков. Будет много цитат и, скорее всего, ничего нового для тех кто уже это умеет делать. Для остальных читаем дальше.Читать полностью »
Эта статья о неудаче, создана для того чтобы продемонстрировать как полезно рассказывать о неудачах. Надеюсь она изменит результат на успех благодаря комментариям.
Как это обычно бывает, появляется новая задача, вы её обдумываете и останавливаетесь на каком то решении. Дальше, это решение необходимо воплотить в жизнь и вот тут то начинается самое интересное…
Передо мной встала большая задача перевести инфраструктуру компании и её проектов на автоматизированное управление. Впоследствии длительной мозговой деятельности, было последовательно выбрано использовать ansible и как веб интерфейс к нему jenkins. По мере понимания всех бизнес-процессов и системы работы серверов и сервисов, я уже чётко видел всю картину IaC (Infrastructure as Сode — инфраструктура как код). После пилотных плейбуков и ролей пора было начинать частичное внедрение, для ансибл есть замечательная возможность динамически собирать списки серверов которыми нам требуется управлять. Для хранения большого числа серверов и всех необходимых переменных для них решил на первых этапах использовать наши собственные ДНС серверы почерпнув идею у badoo(чтоб вам икалось ребята).
Когда вы хотели как лучше, а получилось как всегда. Вперёд, вниз в глубины гугловых дебрей. Читать полностью »
Классический DNS, который специфицирован в rfc1034 не пинает только ленивый. При весьма высокой эффективности работы, он действительно никак не защищён, что позволяет злоумышленникам переводить трафик на подставные сайты, путём подмены DNS-ответов для промежуточных кеширующий серверов (отравление кэша). Как-то с этой напастью борется https с его SSL-сертфикатами, которые позволяют обнаружить подмену сайта. Но пользователи обычно ничего не понимают в SSL, и на предупреждения о несоответствии сертификата автоматически кликают «продолжить», вследствие чего время от времени страдают материально.