Какие грабли зарыты в IMAP
Уже некоторое время IMAP работает в Почте Mail.Ru в полную силу, и я готов рассказать о том, с какими проблемами мы столкнулись при его запуске. Часть из них была связана с особенностями самого протокола и с его историей, другие были обусловлены спецификой взаимодействия IMAP с нашим хранилищем. Отдельная категория трудностей вызвана многообразием почтовых клиентов.
За подробностями — добро пожаловать под кат.
Нынешний запуск IMAP — наш второй подход к снаряду. В прошлый раз мы взяли сервер Dovecot и попробовали заточить его под себя. Результат нас не устроил: с нашими нагрузками и нашей инфраструктурой он сочетался плохо. В этот раз мы решили выбрать другой путь, и написали собственное решение.
IMAP мы запустили в мае, но анонсировали только в июне. Фактически, майская аудитория — это наши сотрудники и те ользователи, у которых клиенты автоматически определили наличие IMAP в нашей Почте и подключили к нему новые добавленные аккаунты.
Трудности, специфичные для протокола IMAP
1. Громоздкость самого протокола
Первая версия протокола IMAP появилась в 1986 году. В данный момент актуален стандарт IMAP версии 4rev1, который был обновлен в 2003 году. За такой долгий срок стандарт существенно разросся: его текущая версия насчитывает порядка 200 страниц.
Сейчас многие моменты, описанные в стандарте, устарели — в сегодняшних условиях они уже не являются необходимостью. Например, в протоколе предусмотрен возврат количества строк и MD5-суммы частей письма — функционал, который фактически не используется в современных клиентах.
Кроме того, существует множество опциональных расширений протокола. Некоторые из них, по сути, являются необходимыми для удобной работы с почтовым ящиком.
Чтобы побороть историческое наследие, нам пришлось реализовать несколько расширений. Одно из них — UID+: когда мы копируем или добавляем письмо, мы возвращаем ID нового письма, которое появилось на сервере в результате копирования или добавления. Это позволяет нам сэкономить на ресурсоемкой операции поиска, которую приходилось проводить клиенту, чтобы распознать, какое именно письмо было добавлено.
2. Отсутствие стандартного паттерна работы с сервером
IMAP предоставляет множество способов решить одну и ту же задачу и, как следствие, практически у всех клиентов паттерн работы различен. Также важно, что паттерны работы существенно отличаются от того, как работает веб-почта или POP3.
Более половины приходится на долю клиентов под устройства Apple: причина в том, что у них хорошо работает автоопределение IMAP. Outloook же, напротив, по умолчанию работает по POP3, и настраивать IMAP нужно руками.
Здесь можно выделить 2 основные категории: десктопные клиенты, которые сразу запрашивают информацию обо всех письмах в ящике или папке, и мобильные клиенты, которые изначально запрашивают информацию только о самых новых письмах. Далее нам оставалось изучить запросы, которые они делают, чтобы обновить состояние, как именно они вытягивают информацию о письмах.
Почему для нас это было необходимым шагом? При скромных нагрузках (например, если сервер обслуживает корпоративную почту небольшой компании) вопрос оптимальности стоит не так остро. Однако при наших объемах оптимальность становится критичной: следовательно, нам нужно было изучить паттерны работы всего зоопарка почтовых клиентов, обращающихся к хранилищу.
3. Количество одновременных сессий
По стандарту, минимальный таймаут сервера — 30 минут. Кроме того, один клиент может держать сразу несколько соединений к серверу (в протоколе не указано максимальное количество разрешенных соединений). Фактически, в нашем масштабе, это означает, что один сервер должен оптимально работать с десятками тысяч одновременных соединений. При работе в синхронном режиме такое количество соединений просто поглотило бы все ресурсы.
Для решения этой проблемы я написал библиотеку для асинхронной работы, построенную на базе edge-triggered epoll. Изначально я ставил перед собой задачу сделать библиотеку, при помощи которой можно было бы в будущем за пару дней написать свой асинхронный сервер для решения других задач, помимо IMAP; в результате практически весь код можно использовать для написания других сервисов.
4. Невозможность однозначно идентифицировать клиент
Наш сервер поддерживает расширение ID, которое позволяет нам идентифицировать примерно половину клиентов. К сожалению, другая половина об этом расширении не знает (из популярных можно назвать, например, Outlook).
Понимание того, с каким клиентом мы работаем, позволяет обойти его характерные баги, а также предсказать, каким будет паттерн работы в рамках данной сессии и, соответственно, оптимизировать работу. Для нас это критично, поэтому, если клиент не называет ID, мы стараемся идентифицировать его другими путями (в случае Outlook — по тегам).
5. Отсутствие команды перемещения сообщений
В клиентах перемещение реализовано через копирование+удаление. Нам, разумеется, хочется, чтобы при этом копия письма помещалась в нужную папку, а оригинал удалялся и не захламлял корзину. С другой стороны, иногда сам пользователь копирует письмо в новую папку, а затем удаляет оригинал: в этом случае удаленное письмо должно помещаться в корзину.
Чтобы различать эти два кейса, после копирования мы в этой же сессии помечаем письмо специальным внутренним флажком. Когда сам пользователь копирует письмо и удаляет оригинал, клиент, как правило, обновляет список писем. При обновлении флажок автоматически сбрасывается, а удаленное письмо оказывается в корзине. Если же письмо (в рамках перемещения) удаляет клиент, обновления не происходит, и письмо, помеченное флажком, удаляется окончательно.
Трудности, связанные с адаптацией текущего хранилища писем и индексов
1. Идентификация сообщений
Для работы по IMAP необходимо было поддержать два вида идентификаторов сообщений: порядковый номер, который может отличаться от сессии к сессии, а также уникальный номер, который сохраняется на все время жизни сообщения. Оба идентификатора должны удовлетворять довольно строгим критериям, которые не соответствовали схеме, используемой веб-почтой и POP3-сервером.
Наиболее рациональным оказывается держать в оперативной памяти весь набор порядковых номеров, их соответствие внутренним идентификаторам, а также IMAP ID. При открытии папки мы вытягиваем из хранилища список всех писем, наши внутренние идентификаторы, IMAP ID, флажки и размер сообщения — все то, что хочется отдавать без лишних запросов.
Обо всех изменениях порядкового номера в рамках одной сессии мы должны оповещать клиент. Согласно стандарту, последовательность IMAP ID должна соответствовать последовательности порядковых номеров. Порядковые номера мы получим, отсортировав список писем по уникальным номерам. Когда клиент выдает новую команду, мы заново открываем соединение с хранилищем, запрашиваем время последних изменений, которые были сделаны в ящике. Если изменений со времени последнего такого запроса не было, то мы просто возвращаем ответ на команду. В ином случае мы заново запрашиваем список сообщений в папке и сравниваем с аналогичным списком клиента. Далее мы либо возвращаем информацию об изменениях, либо, если протокол не позволяет этого сделать сразу, делаем у себя пометку о том, что письмо удалено, и ждем подходящего момента, чтобы сообщить об этом клиенту.
Из-за такой специфики — письма уже нет в ящике, но клиент об этом еще не узнал — клиент может запросить данные об уже удаленном письме. Более того, некоторые из них испытывали серьезные проблемы, если ответа на их запрос не поступало. Чтобы клиент не ломался, мы в ответ на подобные запросы возвращаем заглушки. Клиент получает нужную ему для нормальной работы информацию, а уже при следующем обновлении списка писем (оно, как правило, происходит сразу же) удаляет из него сообщение.
2. Необходимость оптимально возвращать информацию о MIME-структуре письма
Практически все клиенты запрашивают информацию о структуре письма. Часто в рамках первой сессии они запрашивают такую информацию сразу обо всех письмах в папке. Парсить письмо на каждый такой запрос было бы крайне неоптимально.
Вместо этого мы сделали кэш MIME-структур. Наличие кэша помогло нам побороть сразу несколько трудностей, связанных с особенностями IMAP — в частности, отсутствие стандартного паттерна работы с сервером: поскольку часть информации хранится в кэше, это помогает нивелировать нагрузку, связанную с разными паттернами работы клиентов.
Сейчас мы кэшируем до 50 сообщений. Почему не 2-3? Дело в том, что некоторые клиенты сначала запрашивают структуру письма, а потом тело, причем сразу для нескольких сообщений; максимальное число писем в такой «пачке» обычно составляет 50 штук.
3. Оптимальная отдача частей письма
Часто клиенты просят лишь текстовые части письма, которые могут находиться в конце самого сообщения. Для отображения сниппетов клиенты могут просить текстовые части сразу у 50-200 писем. Читать весь файл сообщения целиком (и обрабатывать 10 МБ письма для того, чтобы отдать 10 КБ текста) при этом не хочется; использовать индекс для определения позиции части внутри файла при каждом запросе также было бы накладно. В этой ситуации также спасает кэш структуры письма.
Преимущества такого подхода особенно наглядны тогда, когда клиент подгружает сниппеты для нескольких десятков писем: если бы мы не использовали кэш структуры, то для этого приходилось бы просмотреть много мегабайт и пожертвовать скоростью.
Для экономии места в наших хранилищах base64-части хранятся в декодированном виде внутри письма: при работе с веб-почтой это позволяет отдавать аттачи без лишнего перекодирования. Нужно было сделать схему отдачи частей с учетом этого перекодирования. Мы написали потоковое перекодирование на IMAP-сервере. Здесь также помог кэш — благодаря ему мы без перечитывания структуры можем понять, в каком виде (бинарном или нет) хранится тот или иной фрагмент.
4. Особенности работы некоторых клиентов
Некоторые клиенты не полностью соответствуют стандарту RFC: например, стандартные клиенты Android версий 2.2 — 2.3 не могут корректно отображать письма без возврата некоторых необязательных полей. Основная трудность заключалась в том, чтобы определить, какие именно поля каждый из таких клиентов считает для себя обязательными: приходилось решать это методом перебора.
Выше уже упоминалось о том, что у клиентов могут быть различные подходы к удалению писем: одни перемещают их в корзину, другие — удаляют сразу и безвозвратно. При этом некоторые клиенты не понимают стандартное расширение XLIST, которое мы поддерживаем, позволяющее определить, какая именно папка является корзиной. Вместо этого они используют в качестве корзины свою папку (так себя ведет, например, Sparrow).
Интересно ведет себя Outlook: по команде удаления письма не перемещаются в корзину, а помечаются как перечеркнутые, и затем удаляются позже. Выяснилось, что для пользователей это выглядит, как баг — многие просто не понимают, что делать дальше и как добиться того, чтобы клиент вел себя привычным образом и письма оказались в корзине.
В условиях такого разнообразия нам также было необходимо эмпирически понять, как ведет себя каждый из клиентов, и подстроиться под эти варианты — причем таким образом, чтобы пользователь мог быть уверен: независимо от того, в каком клиенте он работает, почта отреагирует на его действия привычно и предсказуемо (в данном случае — удаленное письмо окажется к корзине). Решали мы это, пробуя различные ответы через тестовый прокси-сервер и отслеживая реакцию клиента на каждый из вариантов.
То, что мы вынесли для себя: IMAP — достаточно «развесистая» штука, с множеством исторических особенностей, нажитых за 26 лет, которые умножаются на разнообразие почтовых клиентов. При наших нагрузках это выливается в то, что брать готовое решение и пытаться заточить его под себя нерационально: в лучшем случае объем работы будет таким же, как при самостоятельной разработке решения. Этим путем мы и пошли :)
Виктор Стародуб,
команда Почты@Mail.ru
Автор: vstarodub
