Автор этой фотографии - Павел Васильев, и он утверждает, что ТСПУ занимает «как минимум, пол-стойки оборудования на узле связи».
Далее. Ядро и центральный элемент ТСПУ – это сервер DPI. DPI (англ. Deep Packet Inspection) – технология, подразумевающая глубокий анализ, обработку, фильтрацию и подмену пакетов в режиме реального времени. Слово «глубокий» подразумевает не какую-то аццкую сложность процесса анализа, а просто тот факт, что анализ пакетов будет проводиться на разных уровнях модели OSI, вплоть до той глубины, на которой не окажется шифрование.
Технология DPI возникла и развилась в среде провайдеров интернета. Фактически, для выполнения нескольких чисто коммерческих целей, связанных с наполнением кошельков уважаемых людей.
Первая цель – выявлять и тормозить скорость выкачивания у того числа собственных клиентов, кто действительно много качает. Неважно, что по договору скорость 300 Мбит/c. Важно то, что если на этой скорости клиент будет качать больше n минут, то владелец компании-провайдера будет считать, что лично его обкрадывают. При том, что ничего со стороны клиента не нарушается. В общем, с точки зрения компании-провайдера это недопустимо, и скорость они резали, режут и будут резать, и плевать они хотели на собственный договор. Вот причастные прямо в этом признаются.
Вторая цель – ограничивать конкретно торренты, то есть помочь другим уважаемым людям, которые делают деньги на частном владении продуктами интеллектуальной деятельности всего общества. Тем более если эти уважаемые люди настойчиво об этом просят, используя для этого и механизмы государственного принуждения. Рука руку моет, и провайдеры идут навстречу, особенно учитывая то, что это не противоречит первой цели. Как относиться к ограничению торрентов, каждый решает сам, но когда, к примеру, мультфильмы, нарисованные советскими мультипликаторами, оказываются чьей-то коммерческой собственностью, то через некоторое время собственник ограничивает их бесплатное хождение, и бесплатно (или без рекламы) они оказываются доступны только на торрентах. Как тебе такое, Илон Маск?
Третья цель – внедрять в исходный код страницы рекламу. Когда-то это было прямо заветной мечтой для всех провайдеров. Сейчас, когда страницы в основном зашифрованы, эта ниша поучения прибыли распределена между другими игроками.
К слову, технология DPI позволяет провайдерам закрывать и многие другие текущие операционные потребности, в целом более «травоядные». Анализ трафика используют не только провайдеры, не только государственные учреждения (например, школы) в разных странах, а вообще фактически кто угодно. У кого есть деньги, и кто хочет эти деньги сохранить. Вот, к примеру, и Google использует в своей инфраструктуре глубокий анализ трафика, чтобы не давать создателям контента выкачивать свой собственный контент на площадки-конкуренты (или даже просто на свой личный жесткий диск). Как известно, в деле свободного распространения информации все равны, но некоторые равнее. Им и виднее, кому что разрешать.
В общем, как только технологии DPI стали более-менее работоспособны, как только устаканились производственные мощности, к делу использования DPI не могло не подключиться и государство. Российское, американское, израильское, саудовское, французское, канадское, иранское и любое другое, у которого есть бюджет и цель. Ну хотя бы потому, что открыто не противодействовать сайтам по продаже наркотиков и сайтам, продающим всякие запрещенные уголовные услуги – это как-то нехорошо. Поставить какой-никакой, а барьер, надо. Дальше-больше. И вот под запретами, например, в Саудовской Аравии оказываются Skype, Messenger, WhatsApp и Viber, в Китае Signal, а в России Instagram и Facebook. А крупные IT-гиганты, такие как Cisco (США), Huawei (Китай), Allot Ltd. (Израиль), Procera Networks (США), Nexa Technologies / Amesys / Groupe Bull (Франция) с радостью продают DPI-оборудование по всему миру. Рынок устройств DPI стремительно растет, и в 2019 году он оценивался в 8,7 млрд долларов США, а стабильный ежегодный рост по оценкам составляет около 8%.
Итак, понятно, что краеугольный камень в блокировке Youtube в России – оборудование DPI. Какое же именно оборудование, от каких производителей прямо сейчас используется для этих целей? Чтобы это понять и, по крайней мере, сузить круг поиска, не обойтись без анализа используемых технологий. Этот же анализ позволит предсказать, в каком направлении пойдет вся эта история, и кто в ближайшем будущем станет производить все оборудование для DPI в России.
Технологии для оборудования DPI
Оттолкнемся от задачи. Как уже было доказано, блокировка youtube сводится к тому, чтобы в потоке трафика выделить ClientHello запрос в протоколе TLS, затем в нем найти незашифрованный SNI, содержащий имя сервера, к которому идет подключение -
googlevideo.com. Фактически, упрощая, есть входной буфер ip-пакетов, надо по нему итерационно пробежаться, найти подстроку, затем от места начала подстроки взять некое смещение – и вот он, адрес youtube.
В чем сложность этой задачи? В том, что это надо делать в режиме реального времени на входном потоке большой скорости (речь про десятки и сотни гигабит в секунду). В чем еще? В том, что неплохо бы на будущее иметь возможность легко перенастроить алгоритм (а то вдруг rutube захочется замедлить). В чем еще? В том, чтобы сразу заложить защиту от запутывания систем DPI (например, от GoodbyeDPI), то есть научиться обрабатывать разбитые, фрагментированные пакеты и пакеты с прочими изменениями.
Какие существуют технологии в разработке программно-аппаратных комплексов, которые потенциально могли бы решить подобную задачу? К счастью, немного.
Технология 1. Просто железо.
Когда задача имеет узкие рамки, можно просто сделать микросхему небольшого размера и небольшого энергопотребления. Там может вообще не быть процессора и даже памяти (или очень небольшая). Типа калькулятора, который имеет только функции калькулятора и ничего более. Стоить такая схема будет очень недорого, особенно если массово ее штамповать в Китае. По такому пути идут производители простых роутеров, наушников и прочего ширпотреба. Этот путь решения для текущей задачи точно не подходит, ввиду нерасширяемости по задаче. В общем, проходим мимо.
Технология 2. Обычное компьютерное железо + программа на C/С++.
Можно взять обычный ПК с сетевой картой подороже и на обычном процессоре запускать обработку ip-трафика для целей DPI. Для этого есть даже открытые библиотеки OpenDPI и nDPI. Затраты на программирование, казалось бы, небольшие, а стоимость компьютерного железа приемлемая. Но есть нюансы. Если поток тонкий (скажем, до 100 Мбит/c), его почти наверняка можно обработать почти на любом процессоре в связке с почти любой материнской платой. Скорость в несколько сотен МБит/с тоже потянет почти любой современный процессор с современной материнской платой. А вот дальше начнутся неустранимые проблемы. Проблемы с принятием сокетов операционной системой. Проблемы с доступом к памяти на такой скорости (вы же будете гонять данные из памяти в процессор и обратно кругами, и чем глубже закопаны искомые данные, тем больше). Проблемы с корректным распараллеливанием и снова доступом к памяти. В общем, этот путь возможен, но ограничен теми параметрами, которые дает обычное, не узкоспециализированное железо, то есть связка сетевая карта+материнка+процессор на обычной ОС. Сколько это будет по скорости обработки потока? Сложно сказать, пока не попробуешь. Я удивлюсь, если сможем выжать больше 1 Гбит/с. Этого маловато для решения нашей сверхзадачи, потому идем дальше.
Технология 3. Специальное компьютерное железо + специальное ПО на C/С++.
Творчески разовьем предыдущий подход. Предположим, вместо простой материнки от Asus мы закажем плату с повышенными характеристиками. Распаяем на ней сразу несколько 10-гигабитных портов. А можем раскрыть варежку пошире и выбрать порты помощнее, например QSFP с пропускной способностью 40 Гбит/с. Возьмем также шину помощнее (а то, к примеру, на PCI Express v4.0 x4 больше 64 Гбит/с мы не получим). Для того, чтобы операционная система перестала быть бутылочным горлышком в принятии сетевых пакетов, используем технологию DPDK под Linux. Ну, еще процессор помощнее закупим, типа такого. Или сразу два процессора посадим, если материнская карта будет серверного типа. Обработку ip-трафика будем делать по-прежнему через открытые библиотеки OpenDPI и nDPI. Что по факту получим? Получим неплохую скорость обработки и относительно легкую возможность менять исходный код, подстраиваясь под меняющуюся задачу. Что еще получим? Получим не самое дешевое железо за счет недешевых процессоров и заказной серверной материнской платы (типа такой или такой). Энергоэффективность тоже не лучшая. Что с ограничениями по скорости? Мы в них точно упремся, поскольку мы пытаемся решить узкоспециализированную задачу средствами процессора общего назначения. Именно процессор станет узким местом. Скорость обработки потока оценить крайне сложно, пока не реализуешь задачу полностью на конкретном варианте железа, но предполагаю, что это будет в районе пары-тройки десятков Гбит/c (если железо не совсем космической стоимости). Да еще придется мириться с некоторой непредсказуемостью по скорости обработки. Одна порция данных обработается за X мс, а следующая неожиданно за X * 1.3, например. Задержку трафика тоже оценить проблематично, а уж тем более гарантировать приемлемый минимум. А чего вы хотели от такой общей связки? Но в целом это хороший, годный подход.
Нет комментариев