Как стать автором
Обновить
26
0
Тензин Константин @tenzink

Пользователь

Отправить сообщение

Автономный способ обхода DPI и эффективный способ обхода блокировок сайтов по IP-адресу

Время на прочтение7 мин
Количество просмотров732K
Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.

Существует два распространенных типа подключения DPI: пассивный и активный.

Пассивный DPI

Пассивный DPI — DPI, подключенный в провайдерскую сеть параллельно (не в разрез) либо через пассивный оптический сплиттер, либо с использованием зеркалирования исходящего от пользователей трафика. Такое подключение не замедляет скорость работы сети провайдера в случае недостаточной производительности DPI, из-за чего применяется у крупных провайдеров. DPI с таким типом подключения технически может только выявлять попытку запроса запрещенного контента, но не пресекать ее. Чтобы обойти это ограничение и заблокировать доступ на запрещенный сайт, DPI отправляет пользователю, запрашивающему заблокированный URL, специально сформированный HTTP-пакет с перенаправлением на страницу-заглушку провайдера, словно такой ответ прислал сам запрашиваемый ресурс (подделывается IP-адрес отправителя и TCP sequence). Из-за того, что DPI физически расположен ближе к пользователю, чем запрашиваемый сайт, подделанный ответ доходит до устройства пользователя быстрее, чем настоящий ответ от сайта.
Читать дальше →
Всего голосов 212: ↑212 и ↓0+212
Комментарии352

История успеха «Яндекс.Почты» с PostgreSQL

Время на прочтение13 мин
Количество просмотров53K


Владимир Бородин (на «Хабре» dev1ant), системный администратор группы эксплуатации систем хранения данных в «Яндекс.Почте», знакомит со сложностями миграции крупного проекта с Oracle Database на PostgreSQL. Это — расшифровка доклада с конференции HighLoad++ 2016.

Всем привет! Меня зовут Вова, сегодня я буду рассказывать про базы данных «Яндекс.Почты».

Сначала несколько фактов, которые будут иметь значение в будущем. «Яндекс.Почта» — сервис достаточно старый: он был запущен в 2000 году, и потому мы накопили много legacy. У нас — как это принято и модно говорить — вполне себе highload-сервис, больше 10 миллионов пользователей в сутки, какие-то сотни миллионов всего. В бэкенд нам прилетает более 200 тысяч запросов в секунду в пике. Мы складываем более 150 миллионов писем в сутки, прошедших проверки на спам и вирусы. Суммарный объём писем за все 16 лет — больше 20 петабайт.

О чем пойдет речь? О том, как мы перевезли метаданные из Oracle в PostgreSQL. Метаданных там не петабайты — их чуть больше трехсот терабайт. В базы влетает более 250 тысяч запросов в секунду. Надо иметь в виду, что это маленькие OLTP-запросы, по большей части чтение (80%).

Это — не первая наша попытка избавиться от Oracle. В начале нулевых была попытка переехать на MySQL, она провалилась. В 2007 или 2008 была попытка написать что-то своё, она тоже провалилась. В обоих случаях был провал не столько по технически причинам, сколько по организационным.
Всего голосов 113: ↑111 и ↓2+109
Комментарии119

Как проходят архитектурные секции собеседования в Яндексе: практика дизайна распределённых систем

Время на прочтение25 мин
Количество просмотров137K
Привет, меня зовут Костя Кардаманов, я работаю в отделе технологий разработки Яндекса. Обычно такой же фразой я приветствую и кандидатов на собеседовании. А сегодня я хотел бы рассказать вам, как и зачем мы проводим интервью по дизайну систем с бэкенд-разработчиками. Сразу скажу: для фронтендеров, мобильных разработчиков и ML-инженеров подобный тип собеседований применим слабо, так что эти специальности мы здесь обсуждать не будем.

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

Что такое дизайн информационных систем


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

Опытный читатель может сказать — в мире полно платных и бесплатных решений, из которых я могу собрать систему как из деталей конструктора, зачем мне понимать устройство этих деталей?
Читать дальше →
Всего голосов 67: ↑65 и ↓2+90
Комментарии37

«Надежность и безотказность как в Google» — и не только: перевод статьи «Расчёт надёжности сервиса»

Время на прочтение14 мин
Количество просмотров26K
image

Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса и\или его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.
Читать дальше →
Всего голосов 29: ↑28 и ↓1+27
Комментарии4

Латинский квадрат: вызываем демонов во имя математики

Время на прочтение7 мин
Количество просмотров11K

Привет, Хабр, я Олег, преподаватель Elbrus Bootcamp. Возможно, вы слышали о латинских квадратах. Раньше считали, что они защищают от зла и помогают в магических ритуалах, а теперь их используют в криптографии и играх. Но, несмотря на многовековую историю, генерация таких квадратов — все еще проблема.

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

Решил исправить ситуацию: в этой статье расскажу об алгоритмах генерации и их ограничениях, и покажу, как реализовал один из алгоритмов на JavaScript с классной визуализацией. А еще объясню, почему магический и латинский квадрат — не одно и то же.

Вызвать демона
Всего голосов 11: ↑11 и ↓0+11
Комментарии9

Трансформером по A*, или как уменьшить число итераций самого известного алгоритма поиска пути

Уровень сложностиСредний
Время на прочтение24 мин
Количество просмотров7.8K

Привет! Меня зовут Константин Яковлев, я научный работник и вот уже более 15 лет я занимаюсь методами планирования траектории. Часто эта задача сводится к поиску пути на графе, для чего обычно используется алгоритм эвристического поиска A*. Этот алгоритм был предложен в 60-х годах XX века и с тех пор используется повсеместно. Скорее всего, юнит вашей любимой RTS бежит по карте с помощью той или иной вариации A*. Точно так же, под капотом беспилотного авто вы, наверняка, найдёте A*, хотя там, конечно, не только он.

A* — это хороший алгоритм, но его вычислительная эффективность сильно зависит от эвристической функции, которую должен задать разработчик. Основная проблема стандартных эвристик заключается в том, что они не учитывают расположение препятствий на карте и ведут поиск буквально напролом, тратя на это ресурсы (итерации поиска). Почему бы нам не воспользоваться современными нейросетями для решения этой проблемы, а именно попросить нейросеть посмотреть на карту и подсказать поиску как лучше обходить препятствия, чтобы быстрее (за меньшее число итераций) найти нужный путь?

Этот текст посвящен как самому алгоритму A*, так и попыткам повысить его эффективность с помощью методов искусственного интеллекта. Заодно я расскажу о том, какие новшества в этом направлении придумали мы с коллегами: научная статья на эту тему опубликована в сборнике конференции AAAI 2023.

Читать далее
Всего голосов 34: ↑34 и ↓0+34
Комментарии35

Пилотируемый полет США на Марс в 2039

Уровень сложностиСредний
Время на прочтение14 мин
Количество просмотров14K

Данная статья по большей части является кратким изложением исследования NASA MTAS (Mars Transportation Assessment Study, март 2023). Текст содержит интересные факты о трудностях полета к Красной планете.

Читать далее
Всего голосов 64: ↑64 и ↓0+64
Комментарии46

Хабраюзер, помоги: истории неуспеха

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров9.3K

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

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

Читать далее
Всего голосов 11: ↑8 и ↓3+19
Комментарии6

Одно из самых фундаментальных утверждений математики — теорема Гейне-Бореля-Лебега

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров13K

Сегодня я хочу рассказать Вам про известное утверждение из математического анализа, которое носит имя сразу трех знаменитых математиков 19 и 20 веков: Эмиля Бореля, Анри Лебега и Эдуарда Гейне.

Читать далее
Всего голосов 22: ↑18 и ↓4+22
Комментарии12

Распространённые паттерны опечаток при программировании

Уровень сложностиПростой
Время на прочтение20 мин
Количество просмотров13K

Распространённые паттерны опечаток при программировании


Есть бесконечное количество способов ошибиться при написании кода. Однако иногда можно заметить явные интересные закономерности, как и где ошибаются программисты. Поговорим о коде, который "притягивает" опечатки.


На чём основаны наблюдения


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


Рассматривая все эти ошибки, я постепенно замечаю различные повторяющиеся паттерны опечаток. За редким исключением они не зависят от языка программирования. По крайней мере, они одновременно свойственны коду, написанному на C, C++, C#, Java. В этой статье я опишу 7 паттернов, которые заметил к настоящему моменту:


  1. Эффект последней строки.
  2. Злополучная функция memset.
  3. Неверные функции сравнения.
  4. Неверные функции копирования.
  5. Ошибки работы с датами и временем.
  6. Несчастливые числа: 0, 1, 2.
  7. Ошибка на единицу (off-by-one error).

Заметность закономерностей в ошибках свидетельствует о том, что они крайне распространены. Полезно знать о них, чтобы избегать написания потенциально опасного кода или более эффективно находить их в процессе обзоров кода. Другим словами, вы узнаете, какой код притягивает ошибки, и будете более внимательно его проверять. Конечно, PVS-Studio способен выявить многие подобные ошибки, но не все. Поэтому дополнительное внимание не повредит.

Читать дальше →
Всего голосов 36: ↑35 и ↓1+40
Комментарии23

Самый бесполезный человек в тестировании

Время на прочтение4 мин
Количество просмотров13K

Знакомьтесь. Это Игорь. И он самый бесполезный человек в тестировании.

Так считает он сам и подозревает, что того же мнения о нем коллеги.

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

Читать далее
Всего голосов 19: ↑14 и ↓5+12
Комментарии20

Статистические тесты и проверка гипотез в R

Время на прочтение15 мин
Количество просмотров7.4K

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

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

Читать далее
Всего голосов 11: ↑11 и ↓0+11
Комментарии2

Анатомия асинхронных фреймворков в С++ и других языках

Время на прочтение20 мин
Количество просмотров43K
Привет! В этой статье я расскажу об устройстве асинхронных движков с корутинами и без них. Для начала сосредоточимся не на конкретном движке, а на том, почему во всех популярных языках программирования появились корутины и чем они так хороши. Это может быть интересно не только C++-разработчикам, но и всем, кто занимается разработкой сетевых приложений или интересуется архитектурой современных фреймворков.

Пройдёмся по разным архитектурам построения серверов — от самой простой синхронной к более интересным, посмотрим на типичную архитектуру корутинового движка, а после окунёмся в дебри C++ и взглянем на самое страшное на примере нашего фреймворка userver.

Пишем синхронный сервер


Представьте, что у вашего сервиса очень маленькая нагрузка — 100 rps, и вам дали задачу написать простой сервер, понятный каждому второму школьнику. У вас получится что-то наподобие следующего:

void naive_accept() {
  for (;;) {
    auto new_socket = accept(listener);

    std::thread thrd([socket = std::move(new_socket)] {
      auto data = socket.receive();
      process(data);
      socket.send(data);
    });

    thrd.detach();
  }
}
Читать дальше →
Всего голосов 56: ↑53 и ↓3+63
Комментарии32

Лучшая фантастика последних трех лет по версии Goodreads

Время на прочтение5 мин
Количество просмотров143K

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

Читать далее
Всего голосов 50: ↑46 и ↓4+54
Комментарии184

Самые распространенные логические ошибки

Уровень сложностиПростой
Время на прочтение12 мин
Количество просмотров67K

Изучение логических ошибок помогает в развитии критического мышления, необходимого во всех сферах жизни. School of Thought проделала отличную работу, описав 24 наиболее распространенные логические ошибки.

Читать далее
Всего голосов 68: ↑63 и ↓5+74
Комментарии101

Совпадение? Не думаю

Уровень сложностиПростой
Время на прочтение13 мин
Количество просмотров21K

Представьте себе колоду из 52 карт. Загадайте любую, я дам вам пару секунд. Дайте угадать. Ваша карта: туз червей. Большинство из вас ответило: нет. Но если 1000 человек прочитавших статью решила мне подыграть, и если все карты выбираются с одинаковой вероятностью, то около 19 человек были удивлены: как он это сделал? Невероятно? Или очень даже вероятно, ведь это чистая математика. Однако мы допустили, что люди загадывают все карты одинаково часто, но это не так. Исследования показывают, что некоторые карты люди загадывают гораздо чаще (Например, туз червей, даму червей и туз пик). И это уже психология, а не математика.

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

Проявить любопытство
Всего голосов 60: ↑57 и ↓3+68
Комментарии53

Вычислительная сложность некоторых игр и головоломок (часть 2)

Уровень сложностиПростой
Время на прочтение14 мин
Количество просмотров3.1K

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

В первой статье и правда по справедливому замечанию avsmal «не хватает каких-то более строгих и конкретных утверждений», но не стоит забывать, что любой даже самый нудный материал нужно стараться подать интересно. В прошлый раз я пожертвовал структурой и конкретностью в пользу читабельности и привлечения интереса к теме. Сильно «душные» статьи заходят с большим скрипом и больше отпугивают читателя.

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

Читать далее
Всего голосов 17: ↑17 и ↓0+17
Комментарии4

История T

Уровень сложностиСредний
Время на прочтение25 мин
Количество просмотров4.2K

Олин Шиверс


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

Читать дальше →
Всего голосов 18: ↑18 и ↓0+18
Комментарии1

Выбор структур данных для самописного текстового редактора

Уровень сложностиСредний
Время на прочтение13 мин
Количество просмотров11K

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

Ресурсы


Прежде чем мы приступим к разбору того, что я сделал, важно упомянуть очень полезные ресурсы для создания собственного текстового редактора:

  • Build Your Own Text Editor — наверно, самый фундаментальный пост о создании текстового редактора с нуля, который я видел. Это превосходный туториал на случай, если вы хотите начать писать собственный текстовый редактор. Стоит заметить, что в редакторе из этого туториала в качестве внутренней структуры для текста используется, по сути, вектор строк.
  • Text Editor: Data Structures — отличный обзор множества структур данных, которые можно использовать при реализации текстового редактора. (Спойлер: как минимум одна из них будет рассмотрена в моём посте)
  • Плейлист Ded (Text Editor) на YouTube — это потрясающая серия, в которой @tscoding фиксирует процесс создания с нуля текстового редактора. Эти видео стали для меня источником вдохновения.

Зачем?


Если в сети есть так много хороших ресурсов о создании собственного текстового редактора (не говоря уже о том, что уже существует множество феноменальных текстовых редакторов), то зачем я это пишу? На то есть несколько причин:

  1. Я хотел заняться проектом, непохожим ни на один свой прошлый.
  2. Я хотел создать инструмент, которым смогу пользоваться.
  3. Мне всегда хотелось глубже разобраться с созданием собственных структур данных.
Читать дальше →
Всего голосов 47: ↑46 и ↓1+58
Комментарии18

Поговорим об оптимизирующих компиляторах. Сказ третий: неопределённое поведение и оптимизации

Уровень сложностиСредний
Время на прочтение13 мин
Количество просмотров11K

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

Наверное, многие слышали, что неопределённое поведение (undefined behavior, UB) -- постоянный источник разнообразных багов, иногда очень забавных, иногда довольно жутких. Тема также неоднократно освещалась и на Хабре, навскидку раз, два, три (и даже целый тег есть). Однако чаще всего статьи по данной теме посвящены тому, как можно отстрелить себе ногу, голову или случайно сжечь свой жёсткий диск, исполнив какой-нибудь опасный код. Я же намерен сделать акцент на том, зачем авторы языков программирования надобавляли всей этой красоты, и как оптимизатор может её эксплуатировать. Всё будет проиллюстрировано наглядными примерами из LLVM и присыпано байками из собственного опыта, так что наливайте себе чай, располагайтесь поудобнее, и погнали.

На дно
Всего голосов 52: ↑52 и ↓0+52
Комментарии96

Информация

В рейтинге
Не участвует
Откуда
Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность