Трафик

Сегодня после обновления catalina с 15.6 на 15.7, просела скорость интернета что то сильно грузило мою сеть я решил посмотреть сетевую активность.

запустил tcpdump на пару часов:

sudo tcpdump -k NP > ~/log 

И первое что бросилось мне в глаза:

16:43:42.919443 () ARP, Request who-has 192.168.1.51 tell 192.168.1.1, length 2816:43:42.927716 () ARP, Request who-has 192.168.1.52 tell 192.168.1.1, length 2816:43:42.934112 () ARP, Request who-has 192.168.1.53 tell 192.168.1.1, length 2816:43:42.942328 () ARP, Request who-has 192.168.1.54 tell 192.168.1.1, length 2816:43:43.021971 () ARP, Request who-has 192.168.1.55 tell 192.168.1.1, length 28

зачем ему вся моя локальная сеть? Он ее сканирует без конца каждую минуту 192.168.1./255, ладно допустим это служба сетевого обозревателя.

(shadowserver.org) - некоммерческая организация по обеспечению безопасности

16:43:33.518282 () IP scan-05l.shadowserver.org.33567 > 192.168.1.150.rsync: Flags [S], seq 1527048226, win 65535, options [mss 536], length 0

Еще одна стучалка (scanner-12.ch1.censys-scanner.com -> censys.io):

16:44:16.254073 () IP scanner-12.ch1.censys-scanner.com.62651 > 192.168.1.150.8843: Flags [S], seq 1454862354, win 1024, options [mss 1460], length 0

Ладно окей вроде ничего особенного аналитика сканирование локальной сети ну обычное дело но что тогда вот это:

16:15:56.603292 () IP 45.129.33.152.51777 > 192.168.1.150.jpegmpeg: Flags [S], seq 2349838714, win 1024, options [mss 536], length 0

Если перейти по этому ip адресу http://45.129.33.152 можно увидеть это:

Содержание файла temp:

[?1h=[?25l[H[J[mtop - 21:17:26 up 31 days,  6:44,  1 use[m[39;49m[m[39;49m[KTasks:[m[39;49m[1m 144 [m[39;49mtotal,[m[39;49m[1m   1 [m[39;49mrunning,[m[39;49m[1m 143 [m[39;49msleep[m[39;49m[m[39;49m[K%Cpu(s):[m[39;49m[1m  0.8 [m[39;49mus,[m[39;49m[1m  0.0 [m[39;49msy,[m[39;49m[1m  0.0 [m[39;49mni,[m[39;49m[1m 92.0[m[39;49m[m[39;49m[KKiB Mem :[m[39;49m[1m 32681700 [m[39;49mtotal,[m[39;49m[1m 18410244 [m[39;49mfree,[m[39;49m[m[39;49m[KKiB Swap:[m[39;49m[1m 16449532 [m[39;49mtotal,[m[39;49m[1m 16449288 [m[39;49mfree,[m[39;49m[m[39;49m[K[K[7m  PID USER      PR  NI    VIRT    RES [m[39;49m[K[m    1 root      20   0  191072   3924 [m[39;49m[K[m    2 root      20   0       0      0 [m[39;49m[K[m    3 root      20   0       0      0 [m[39;49m[K[m    5 root       0 -20       0      0 [m[39;49m[K[m    7 root      rt   0       0      0 [m[39;49m[K[m    8 root      20   0       0      0 [m[39;49m[K[m    9 root      20   0       0      0 [m[39;49m[K[m   10 root      rt   0       0      0 [m[39;49m[K[m   11 root      rt   0       0      0 [m[39;49m[K[m   12 root      rt   0       0      0 [m[39;49m[K[m   13 root      20   0       0      0 [m[39;49m[K[m   15 root       0 -20       0      0 [m[39;49m[K[m   16 root      rt   0       0      0 [m[39;49m[K[H[mtop - 21:17:29 up 31 days,  6:44,  1 use[m[39;49m[m[39;49m[K%Cpu(s):[m[39;49m[1m  0.0 [m[39;49mus,[m[39;49m[1m  0.0 [m[39;49msy,[m[39;49m[1m  0.0 [m[39;49mni,[m[39;49m[1m100.0[m[39;49m[m[39;49m[KKiB Mem :[m[39;49m[1m 32681700 [m[39;49mtotal,[m[39;49m[1m 18409876 [m[39;49mfree,[m[39;49m[m[39;49m[K[K

Ну и напоследок пачка неизвестных запросов:

16:16:07.022910 () IP 059148253194.ctinets.com.58703 > 192.168.1.150.4244: Flags [S], seq 2829545743, win 1024, options [mss 536], length 016:15:57.133836 () IP 45.129.33.2.55914 > 192.168.1.150.39686: Flags [S], seq 700814637, win 1024, options [mss 536], length 016:15:56.603292 () IP 45.129.33.152.51777 > 192.168.1.150.jpegmpeg: Flags [S], seq 2349838714, win 1024, options [mss 536], length 016:16:15.083755 () IP 45.129.33.154.55846 > 192.168.1.150.7063: Flags [S], seq 4079154719, win 1024, options [mss 536], length 016:15:43.251305 () IP 192.168.1.150.60314 > one.one.one.one.domain: 3798+ PTR? 237.171.154.149.in-addr.arpa. (46)16:16:24.386628 () IP 45.141.84.30.50763 > 192.168.1.150.12158: Flags [S], seq 572523718, win 1024, options [mss 536], length 016:16:44.817035 () IP 92.63.197.66.58219 > 192.168.1.150.15077: Flags [S], seq 4012437618, win 1024, options [mss 536], length 016:15:43.172042 () IP 45.129.33.46.51641 > 192.168.1.150.bnetgame: Flags [S], seq 362771723, win 1024, options [mss 536], length 016:17:02.120063 () IP 45.129.33.23.42275 > 192.168.1.150.11556: Flags [S], seq 3354007029, win 1024, options [mss 536], length 016:16:00.589816 () IP 45.129.33.3.56005 > 192.168.1.150.40688: Flags [S], seq 2710391040, win 1024, options [mss 536], length 0

Если я блокирую эти домены и ip адреса в файле host то в следующем дампе будут те же подсети ip но с другими конечными адресами, и у доменов меняется поддомен.

Мак не понимает маску в файле host *.example.com

Как смотреть пакеты которые передаются и какие процессы или демоны вызывают эти соединения я пока не понял (обладаю маком несколько дней) но уже весело!

Вот он. Наступил. Не заметили?

Речь, конечно, идет о мире, предсказанном Ричардом Столлманом в 1997 году. О мире, о котором нас предупреждал Кори Доктороу.

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

Оказывается, текущая версия macOS отправляет в Apple хэш (уникальный идентификатор) при запуске каждой программы. Многие люди не были в курсе этого, так как хэш передается незаметно и только при наличии выхода в интернет. А сегодня серверы работали очень медленно и не успевали проверять хэши. Как результат, все приложения не открывались, если имелся выход в интернет.

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

Дата, Время, ПК, Провайдер, Город, Штат, Хэш приложения

Apple (или кто-то еще), безусловно, может вычислить эти хэши для обычных программ: для всех программ из App Store, Creative Cloud, браузера Tor, инструментов для взлома или, например, реверс-инжиниринга да для чего угодно!

Это означает, что Apple знает, когда вы дома, а когда на работе. Какие приложения вы открываете и как часто. Они знают, когда вы открыли Premiere в гостях у друга, используя его сеть Wi-Fi, или когда вы сидите в браузере Tor в отеле во время поездки в другой город.

Я часто слышу: Кого это волнует?.

Что ж, волнует не только Apple. Эта информация не задерживается у них:

1. Эти OCSP-запросы передаются в незашифрованном виде. Их могут перехватывать все, кто в сети, включая вашего интернет-провайдера, а также, кто прослушивает интернет-трафик.

2. Эти запросы проходят через стороннюю CDN, управляемой другой компанией, Akamai.

3. С октября 2012 года Apple является партнером Разведывательного сообщества США в рамках государственной программы по шпионажу PRISM, которая предоставляет федеральной полиции и вооруженным силам США беспрепятственный доступ к данным без ордера. В первой половине 2019 года они воспользовались этим правом более 18 000 раз, а во второй половине 2019 года еще более 17 500.

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

До сегодняшнего дня была возможность заблокировать подобное поведение на вашем Mac с помощью программы Little Snitch (на самом деле это единственное, что заставляет меня использовать macOS на данный момент). По умолчанию программа разрешает передачу между компьютером и серверами Apple, но вы можете вручную разрешать или блокировать то или иное соединение. А ваш компьютер продолжит работать нормально, не стуча на вас в Apple.

macOS 11.0 Big Sur получила новые API, которые ломают работу Little Snitch. Они не позволяют программе проверять или блокировать какие-либо процессы на уровне ОС. Кроме того, новые правила в macOS 11 затрудняют работу даже VPN, так что приложения Apple просто обходят их.

Патрик Уордл (Patrick Wardle) сообщил нам, что демон trustd, отвечающий за эти запросы, находится в новом списке исключений ContentFilterExclusionList, что означает, что он не может быть заблокирован никаким пользовательским брандмауэром или VPN. На его скриншоте также показано, что CommCenter (используется для совершения телефонных звонков с вашего Mac) и Карты также будут игнорировать ваши брандмауэр и VPN, ставя потенциально под угрозу ваш голосовой трафик и информацию о будущем или планируемом местоположении.

Помните только что анонсированные красивые Mac на новом процессоре Apple? В три раза быстрее и на 50 % больше времени автономной работы. Они не будут поддерживать ни одну ОС, кроме Big Sur!

Это первые компьютеры общего назначения, когда вам придется сделать выбор: или у вас быстрый и мощный компьютер, или личный. Мобильные устройства Apple работают таким образом уже как пару лет. За исключением использования устройств для фильтрация внешнего сетевого трафика (например, VPN-маршрутизатора), которые контролируете именно вы, на Mac с новым процессором не будет больше возможности загрузиться с какой-либо ОС, чтобы она не "звонила" в Apple. Иначе ОС может вообще не загрузиться из-за аппаратной криптозащиты.

Обновление. 13.11.2020 07:20 UTC

Мне стало известно, что у Mac на процессорах Apple с помощью утилиты bputil можно отключить защиту при загрузке и изменить Signed System Volume (SSV). Один я уже заказал и, как только со всем разберусь, напишу у себя об этом в блоге. Насколько я понимаю, даже после внесения таких изменений по-прежнему можно будет загружать только версии macOS, подписанные Apple. Хотя, возможно, и с некоторыми удаленными или отключенными нежелательными системными процессами. Дополнительные данные появятся, когда система будет у меня в руках.

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

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

Лягушка в кипятке

На этой неделе настал день, о котором нас предупреждали Столлман и Доктороу. Это был постепенный и последовательный процесс, но вот мы наконец-то и приплыли. Вы больше не будете получать оповещений о передаче данных на серверы Apple.

Смотрите также

21 января 2020 г. Apple отказалась от плана по шифрованию резервных копий после жалобы ФБР.

Возможно, не в тему

К другим новостям: Apple незаметно отказалась от сквозной криптографии в iMessage. В настоящее время актуальная iOS будет запрашивать ваш Apple ID во время установки и автоматически включать iCloud и iCloud Backup.

В iCloud Backup не используется сквозное шифрование: резервная копия вашего устройства шифруется с помощью ключей Apple. Каждое устройство с включенным резервным копированием iCloud (а оно включено по умолчанию) загружает резервную копию всей истории iMessage на серверы Apple вместе с секретными ключами iMessage каждую ночь при подключении к сети. Apple может расшифровать и прочитать все данные, даже не притрагиваясь к устройству. Даже если вы отключили резервное копирование в iCloud, вполне вероятно, что тот, с кем вы переписываетесь с помощью iMessage, этого не сделал. Как следствие, ваша переписка загружается на серверы Apple. Еще и через PRISM со свободным доступом для Разведывательного сообщества США, ФБР и др. без ордера или веской на то причины.

Используйте Signal.

FAQ

В.: Это часть собираемой аналитической информации macOS? Будут ли собираться данные, если у меня отключена отправка аналитической информации?

О.: Это не имеет отношения к аналитической информации. Похоже, что это часть кампании Apple по борьбе с вредоносным ПО (и, возможно, по борьбе с пиратством). Это происходит на всех компьютерах Mac с уязвимыми версиями ОС, независимо от каких-либо настроек по сбору аналитической информации. В ОС отсутствует пользовательская настройка для отключения.

В.: Когда это началось?

О.: Это происходит по крайней мере с момента выхода macOS Catalina (10.15.x, выпущена 7 октября 2019 г.). То есть это началось не со вчерашнего выпуска Big Sur, а происходило незаметно как минимум год. По словам Джеффа Джонсона (Jeff Johnson) из Lap Cat Software, все началось с macOS Mojave, выпущенной 24 сентября 2018 года.

Каждую новую версию macOS я устанавливаю начисто, выключаю сбор аналитической информации, не вхожу ни в какие сервисы (как iCloud, App Store, FaceTime или iMessage) и включаю внешнее устройство для мониторинга всего исходящего сетевого трафика. У последних версий macOS наблюдался довольно активный сетевой трафик, даже если вы не используете никакие сервисы Apple. В Mojave (10.14.x) были некоторые проблемы с конфиденциальностью и отслеживанием, но я не помню, существовала ли тогда конкретная проблема с OCSP или нет. Я еще не тестировал Big Sur (следите за обновлениями), но, согласно отчетам тех, кто тестировал, возникают опасения по поводу пользовательских брандмауэров вроде Little Snitch, приложений Apple, которые обходят эти брандмауэры, и VPN-соединений. Догадываюсь, что у меня будет большой список вопросов, когда я установлю Big Sur на тестовую машину на этой неделе.

В.: Как мне защитить свою конфиденциальность?

О.: По-разному. Ваш Mac отправляет тонну трафика на серверы Apple. Если вы беспокоитесь о своей конфиденциальности, можете начать с отключения функций, у которых имеются кнопки: отключите и выйдите из iCloud, отключите и выйдите из iMessage, отключите и выйдите из FaceTime. Убедитесь, что службы геолокации отключены на ваших компьютере, iPhone и iPad. То были значительные слабые места, по которым вас могли отследить и на которые вы уже согласились, но есть простой выход: выключите все.

Что до проблемы с OCSP, я считаю (но еще не тестировал!), что сработает эта команда

echo 127.0.0.1 ocsp.apple.com | sudo tee -a /etc/hosts

Такой трафик я блокирую программой Little Snitch, которая еще работает на версии 10.15.x (Catalina) и ниже. Отключите в Little Snitch все разрешающие правила для служб macOS и службы iCloud, чтобы получать предупреждения, когда ОС пытается связаться с Apple.

Если у вас Mac на Intel (а такой почти у всех сейчас), не беспокойтесь о грядущих изменениях. Если вы хотите изменить пару настроек в ОС, то скорее всего всегда настраивали все предыдущие macOS под себя. Это особенно актуально для немного более старых Mac на Intel, в которых нет чипа безопасности T2. Но вполне вероятно, что даже на таких компьютерах можно будет отключать безопасную загрузку (тем самым позволяя настраивать ОС), как это можно делать сейчас.

Новые Mac на ARM64 (Apple Silicon), которые были выпущены на этой неделе, стали причиной моего беспокойства: еще неизвестно, дадут ли пользователям возможность вообще модифицировать ОС на этих чипах. На других ARM-системах от Apple (iPad, iPhone, Apple TV, Watch) криптографически запрещено отключать такой функционал ОС. Для новых Mac на ARM по умолчанию скорее всего тоже будет запрещено, хотя, надеюсь, продвинутые пользователи смогут отключить некоторые средства защиты и настраивать систему. Я надеюсь, что утилита bputil(1) даст возможность отключить проверку целостности системного тома на новых Mac, что позволит нам удалить определенные системные службы из автозагрузки, не отключая все функции безопасности платформы. Больше информации узнаем в ближайшее время, когда ко мне приедет новый Mac на M1 в этом месяце.

В.: Если тебе не нравится Apple и ты не доверяешь их ОС, то почему ей пользуешься? Почему сказал, что покупаешь новый Mac на ARM?

О.: Простой ответ заключается в том, что без оборудования и программного обеспечения я не могу с уверенностью говорить о том, что они делают или не делают, или о шагах, которые можно предпринять для нивелирования проблем с конфиденциальностью. Длинный ответ заключается в том, что у меня есть более 20 компьютеров с примерно 6 различными архитектурами процессоров. У меня в коллекции имеются все операционные системы, о которых вы слышали, и некоторые из тех, о которых вы, вероятно, и не знали. Например, в моей лаборатории есть 68k Mac (16-битный, почти 32-битный (привет, мой IIcx) и чисто 32-битный), Mac на PowerPC, 32-битный Mac на Intel, 64-битный Mac на Intel (с чипом безопасности T2 и без). Да я бы прослыл последним бездельником, если не много не поковырялся в Mac на ARM64.

В.: Зачем Apple шпионит за нами?

О.: Я не верю, что это было специально разработано как часть телеметрии, но это прекрасно подходит для этой цели. Простое (без злого умысла) объяснение состоит в том, что это часть кампании Apple по борьбе c вредоносным ПО и обеспечению безопасности платформы в macOS. Кроме того, OCSP-трафик, генерируемый macOS, не зашифрован, что делает его идеальным объектом для использования в военных операциях по наблюдению (которые пассивно контролируют всех основных интернет-провайдеров и сетевые магистрали) с целью сбора диагностических данных. И неважно, намеренно ли Apple закладывала такой функционал или нет.

Еще что интересно: недавно Apple с обновлением iOS представила iCloud Backup, добавив закладку в iMessage, чтобы ФБР могло продолжить чтение всех данных на вашем телефоне.

Как говорил Голдфингер: "Один раз случай, два совпадение, три заговор врага". Было всего пару раз, когда Apple (которая, кстати, нанимает крутейших специалистов по криптографии) признавала, что допускала передачу открытого текста или ключей шифрования в открытом виде с устройства в сеть/Apple, и извинилась: Ой, это была случайность. И ей поверили.

Последний раз я сообщал Apple в 2005 году о проблеме, связанной с передачей открытого текста по сети. Тогда они быстро все исправили, но это касалось только поиска слов в словаре. Вскоре после того, как была представлена технология App Transport Security, которая помогает сторонним разработчикам приложений не забивать на сетевое шифрование, Apple усложнила отправку незашифрованных запросов в приложениях из App Store. Поэтому для меня не понятно, почему Apple до сих пор отправляет OCSP-запросы в незашифрованном виде, несмотря на то, что это стандартная практика в отрасли.

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

В.: Зачем ты поднимаешь ложную тревогу? Разве ты не знаешь, что OCSP предназначен только для предотвращения запуска вредоносных программ и обеспечения безопасности ОС, а не для сбора телеметрии?

О.: Побочный эффект в том, что он функционирует как телеметрия независимо от первоначального замысла. Кроме того, даже, несмотря на то, что OCSP-ответы подписаны, OCSP-запросы не зашифрованы, что позволяет любому пользователю сети (включая Разведывательное сообщество США) видеть, какие приложения вы запускаете и когда. А это можно считать крайней степенью халатности.

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

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

В.: Они поместили закладку в сквозное шифрование iMessage? Охренели вообще?!

О: Ага. Технический разбор в моих комментариях тут и тут.

TL;DR: Об этом даже говорится на их сайте: https://support.apple.com/en-us/HT202303.

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

(курсив автора)

Обратите внимание, что само резервное копирование iCloud не имеет сквозного шифрования, что приводит к проблеме условного депонирования ключа iMessage, которая препятствует сквозному шифрованию последнего. На этой веб-странице есть раздел, в котором перечислены материалы, которые используют сквозное шифрование, и вот резервного копирования iCloud там нет.

Как и ваши фотографии в iCloud. Системные администраторы в Apple (а также военные и федералы США) могут спокойно видеть все ваши интимные фотографии в iCloud или iMessage.

Дальнейшее чтение

• https://developer.apple.com/videos/play/wwdc2020/10686/

• https://lapcatsoftware.com/articles/ocsp.html

P. S. Перевел статью целиком только из-за того, что текущий перевод вообще не соответствует уровню статей Хабра.

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

Единственное, о чем мы пожалели что не применили это решение раньше.

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

Два года назад, когда мы переходили с RedShift на ClickHouse, количество собираемых аналитических событий (приложение открылось, приложение запросило ленту контента, пользователь просмотрел контент, пользователь поставил смайл (лайк) и так далее) составляло около 5 млрд в сутки. Сегодня это число приближается к 14 млрд.

Это огромный объём данных, для хранения и обработки которого мы постоянно придумываем решения и лайфхаки, а сервис, их агрегирующий один из самых сложных среди всех наших инфраструктурных сервисов.

Но перед тем, как агрегировать, сохранить и обработать столько данных, их надо сначала принять и с этим есть свои проблемы. Часть описана в статье о переходе на ClickHouse (ссылка на неё была выше), но есть и другие.

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

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

Но ближе к лету непростого 2020 года ей нашлось применение.

Протокол HTTP, помимо сжатия ответов (о котором знают все, кто когда-либо оптимизировал скорость работы сайтов), позволяет использовать аналогичный механизм для сжатия тела POST/PUT-запросов, объявив об этом в заголовке Content-Encoding. В качестве входящего обратного прокси и балансировщика нагрузки мы используем nginx, проверенное и надёжное решение. Мы настолько были уверены, что он сумеет ко всему прочему ещё и на лету распаковать тело POST-запроса, что поначалу даже не поверили, что из коробки он этого не умеет. И нет, готовых модулей для этого тоже нет, надо было как-то решать проблему самостоятельно или использовать скрипт на Lua. Идея с Lua нам особенно не понравилась, зато это знание развязало руки в части выбора алгоритма компрессии.

Дело в том, что давно стандартизированные алгоритмы сжатия типа gzip, deflate или LZW были изобретены в 70-х годах XX века, когда каналы связи и носители были узким горлышком, и коэффициент сжатия был важнее, чем потраченное на сжатие время. Сегодня же в кармане каждого из нас лежит универсальный микрокомпьютер первой четверти XXI века, оборудованный подчас четырёх- и более ядерным процессором, способный на куда большее, а значит алгоритм можно выбрать более современный.

Выбор алгоритма

Требования к алгоритму были простыми:

1. Высокая скорость сжатия. Мы не хотим, чтобы приложения тормозили из-за второстепенной функции.

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

3. Хорошая поддержка, доступность для основных языков программирования.

4. Permissive лицензия.

Сразу отбросили Brotli, предназначенный для одноразового сжатия статического контента на стороне сервера. По схожей причине решили отказаться от bzip, также ориентированного на статику и большие архивы.

В итоге остановились на алгоритме Zstandard, по следующим причинам:

• Высокая скорость сжатия (на порядок больше, чем у zlib), заточенность на небольшие объёмы данных.

• Хороший коэффициент сжатия при щадящем уровне потребления CPU.

• За алгоритмом стоит Facebook, разрабатывавший его для себя.

• Открытый исходный код, двойная лицензия GPLv2/BSD.

Когда мы увидели первым же в списке поддерживаемых языков JNI, интерфейс вызова нативного кода для JVM, доступный из Kotlin мы поняли, что это судьба. Ведь Kotlin является у нас основным языком разработки как на Android, так и бэкенде. Обёртка для Swift (наш основной язык разработки на iOS) завершила процесс выбора.

Решение на бэкенде

На стороне бэкенда задача была тривиальная: увидев заголовок Content-encoding: zstd, сервис должен получить поток, содержащий сжатое тело запроса, отправить его в декомпрессор zstd, и получить в ответ поток с распакованными данными. То есть буквально (используя JAX-RS container):

// Обёртка над Zstd JNIimport org.apache.commons.compress.compressors.zstandard.ZstdCompressorInputStream;// ...if (  containerRequestContext    .getHeaders()    .getFirst("Content-Encoding")    .equals("zstd")) {  containerRequestContext    .setEntityStream(ZstdCompressorInputStream(      containerRequestContext.getEntityStream()    ))}

Решение на iOS

Решили сначала попробовать сжатие аналитических событий на iOS. Команда разработки была свободнее, ну и клиентов на iOS у нас несколько меньше. На всякий случай закрыли этот функционал при помощи feature toggle с возможностью плавной раскатки.

import Foundationimport ZSTDfinal class ZSTDRequestSerializer {    private let compressionLevel: Int32    init(compressionLevel: Int32) {        self.compressionLevel = compressionLevel    }    func requestBySerializing(request: URLRequest, parameters: [String: Any]?) throws -> URLRequest? {        guard let mutableRequest = (request as NSURLRequest).mutableCopy() as? NSMutableURLRequest else {            return nil        }        // ...        mutableRequest.addValue("zstd", forHTTPHeaderField: "Content-Encoding")        if let parameters = parameters {            let jsonData = try JSONSerialization.data(withJSONObject: parameters, options: [])            let processor = ZSTDProcessor(useContext: true)            let compressedData = try processor.compressBuffer(jsonData, compressionLevel: compressionLevel)            mutableRequest.httpBody = compressedData        }        return mutableRequest as URLRequest    }}

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

Впрочем, и снижение объёма трафика было не сильно заметно. Дождавшись, пока новая версия клиента раскатится пошире, мы врубили сжатие на 100% аудитории.

Результат нас, мягко говоря, удовлетворил:

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

То есть мы на четверть сократили весь объём.

Решение на Android

Воодушевлённые, мы запилили сжатие для второй платформы.

// Тут перехватываем отправку события через interceptor и подменяем оригинальный body на сжатый если это запрос к eventsoverride fun intercept(chain: Interceptor.Chain): Response {   val originalRequest = chain.request()   return if (originalRequest.url.toString()               .endsWith("/events")) {      val compressed = originalRequest.newBuilder()            .header("Content-Encoding", "zstd")            .method(originalRequest.method, zstd(originalRequest.body))            .build()      chain.proceed(compressed)   } else {      chain.proceed(chain.request())   }}// Метод сжатия, берет requestBody и возвращает сжатыйprivate fun zstd(requestBody: RequestBody?): RequestBody {   return object : RequestBody() {      override fun contentType(): MediaType? = requestBody?.contentType()      override fun contentLength(): Long = -1 //We don't know the compressed length in advance!      override fun writeTo(sink: BufferedSink) {         val buffer = Buffer()         requestBody?.writeTo(buffer)         sink.write(Zstd.compress(buffer.readByteArray(), compressLevel))      }   }}

И тут нас ждал шок:

Так как доля Android среди нашей аудитории больше, чем iOS, падение составило ещё 45%. Итого, если считать от исходного уровня, мы выиграли суммарно 70% от, напомню, всего входящего трафика в ДЦ.

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

В этот момент мы только могли пожалеть, что не нашли время на внедрение такой рационализации раньше.

Также стало видно, что наши опасения относительно батарейки не оправдались. Наоборот, потратив немного процессорной мощности телефона на сжатие данных, мы экономим намного больше электричества на передаче этих данных в эфир, как на Wi-Fi, так и по сотовой сети.

Два слова, что ещё можно улучшить

У Zstandard есть очень интересная возможность использования предобученного словаря. Если взять достаточно большой объём типичных данных и прогнать по нему сжатие, то можно получить на выходе словарь наиболее высокочастотных вхождений, который затем использовать и при сжатии, и при распаковке.

При этом коэффициент сжатия увеличивается от 10-15% на текстах до 50% на однообразных наборах строк, как у нас. А скорость сжатия даже несколько увеличивается при размере словаря порядка 16 килобайт. Это, конечно, уже не приведёт к такому впечатляющему результату, но всё равно будет приятно и полезно.