Рады Вам сообщить о выходе INDIGO 5.0 – самого масштабного обновления серверной части за всю историю системы.
Мы полностью перестроили её под современные реалии Интернета, разработав собственный высокопроизводительный веб-сервер INDIGO Web Server. Система снова уверенно и быстро работает через Интернет в любых условиях, выдерживает в пять раз больше одновременных пользователей и не теряет скорость с годами, стала устойчивее к сбоям и атакам, а данные защищены по современным стандартам безопасности. При этом она по-прежнему разворачивается за пару минут одним файлом. Ниже – подробный разбор всех изменений.
Главное и самое значимое нововведение версии 5.0 – собственный высокопроизводительный веб-сервер INDIGO Web Server, разработанный нашей командой и встроенный в систему тестирования.
В предыдущих версиях все запросы пользователей из сети первым принимал сторонний веб-сервер Apache. Это проверенный временем вычислительный движок, но он был вынужден делать одновременно всё: принимать сетевые подключения, отдавать скрипты, картинки, шрифты, файлы оформления, обрабатывать программную логику тестов. В современных реалиях такая схема перестала справляться.
Теперь все сетевые запросы принимает наш собственный веб-сервер. Он берёт на себя удержание постоянных подключений, отдачу файлов и защиту. Ядро системы (на котором работает само тестирование) полностью освобождается для своей главной задачи.
Это фундаментальное изменение того, как платформа устроена «под капотом». Система стала значительно быстрее, стабильнее и отлично приспособлена для надёжной работы через Интернет в современных условиях. Эти улучшения почувствуют все, от небольших компаний и учебных центров до крупных организаций с тысячами сотрудников.
Первая критическая проблема: обрывы связи из-за ТСПУ. За последнее время работа веб-сервисов через Интернет резко осложнилась из-за систем фильтрации трафика (ТСПУ), установленных у интернет-провайдеров. В процессе работы, будь то загрузка файлов, переключение между вопросами или сохранение ответов, прежняя архитектура постоянно открывала новые короткие сетевые соединения (по отдельному соединению на каждый запрос). Это классическая схема, по которой веб-серверы работали десятилетиями, и прежде она не создавала никаких проблем. Но теперь именно такие потоки коротких соединений оборудование провайдеров начало жёстко и непредсказуемо обрывать.
Как это выглядело для пользователя. Проблемы могли проявиться в любой момент. У одних первую минуту после входа всё работало нормально, а затем система начинала тормозить и сбоить. У других белая страница появлялась уже при входе, и не спасало даже обновление страницы. Клики по вариантам ответов и переходы между вопросами приводили к долгим ожиданиям и внезапным обрывам связи. На экране постоянно появлялась панель восстановления соединения, а картинки в тестах переставали загружаться, оставляя пустые заглушки. Причём сам процесс тестирования был хотя бы прикрыт автоматическими переподключениями, а вот вход в систему, регистрация, личный кабинет и информационные страницы принимали такие сбои без всякой страховки. По сути, удалённая работа с системой на старой архитектуре стала небезопасной и ненадёжной.
Почему нельзя было просто «починить» старый сервер. Единственное надёжное решение – это удерживать с браузером пользователя одно постоянное соединение. Но прежний веб-сервер (Apache) не позволял включить такой режим, потому что держит каждое подключение в отдельном потоке, а число таких потоков жёстко ограничено памятью. Постоянные соединения быстро исчерпали бы этот лимит. Серверу просто не хватило бы ресурсов, чтобы принимать новые подключения. Это было тупиковое ограничение старой архитектуры.
Почему не подошли готовые решения. В мире Linux эта задача давно решена стандартными инструментами (например, NGINX), но INDIGO работает на Windows (а на Linux внутри Windows-среды Wine), поэтому INDIGO нужны решения именно под Windows, а их фактически нет. NGINX для Windows – это по сути ознакомительный продукт (сами разработчики прямо пишут, что это бета-версия и что «высокой производительности и масштабируемости ожидать не стоит»). Реальный потолок NGINX для Windows составляет около тысячи одновременных подключений. Даже Apache под Linux умеет распределять нагрузку между множеством процессов, но на Windows ему доступен только потоковый режим с тем самым жёстким лимитом. Встроенный в Windows веб-сервер IIS тоже не выход, т.к. это компонент самой операционной системы. Его нельзя поставлять в составе INDIGO, его возможности зависят от редакции Windows, и его невозможно использовать при работе INDIGO на Linux. Наконец, ни в одном рабочем решении под Windows нет умной очереди запросов, то есть механизма, который при пиковой нагрузке придерживает избыточные запросы, а не отбрасывает их с ошибкой (такое умеет разве что платная версия NGINX по ежегодной подписке, и та только под Linux). Поэтому мы прошли весь путь сами, спроектировав и отладив собственные механизмы управления подключениями и очередями, рассчитанные именно на Windows.
Что мы сделали и что это даёт. Так появился INDIGO Web Server. С браузером каждого пользователя он устанавливает единое надёжное соединение и переиспользует его для всех последующих запросов. В результате подключения перестают массово обрываться. Постоянные панели переподключения, пропавшие картинки и долгие ожидания ответа остались в прошлом. Система работает через Интернет ровно и предсказуемо, на любых каналах связи.
И это не только про ТСПУ. Единое стабильное соединение делает работу ровнее на любой проблемной сети: мобильном интернете, слабом Wi-Fi, «моргающем» канале. Сбоев со связью становится кратно меньше, а значит, реже срабатывают переподключения и повторные отправки, которые на плохой связи замедляли работу.
Для всех, кто проводит удалённое тестирование, это самое важное обновление за всю историю платформы. Если же тестирование у Вас проводится только в локальной сети, дальше в описании много важного и для Вас – от ускорения работы и самоочистки базы данных до стабильности и безопасности.
Вторая критическая проблема: резкое замедление мобильного интернета. В последнее время его замечают по всей стране. И это касается не только тех, кто заходит с телефона. Во многих местах, куда физически не дотянуть проводной интернет, через мобильную сеть работают и за обычными компьютерами, в том числе раздавая интернет с телефона. По сути, это проблема любых слабых каналов передачи данных, а не только смартфонов.
Раньше браузер то и дело устанавливал новые подключения к серверу (и при загрузке страницы, и затем при каждом действии во время тестирования). На медленном канале каждое такое подключение добавляло ощутимую задержку. Страница открывалась долго, а ответы на клики приходили с запозданием.
Теперь браузер держит с сервером постоянное соединение и отправляет все запросы через него. Лишние подключения исчезли, и на слабой сети это чувствуется сразу. Страница загружается быстрее, а система живее откликается на каждое действие. И выигрывают все без исключения: удалённые филиалы, учебные центры в регионах и даже те, у кого тестирование проводится в локальной сети. А там, где раньше на замедленном мобильном интернете тестирование почти не открывалось, теперь оно снова работает.
Интерфейс INDIGO – это единое приложение, которое браузер загружает один раз при входе пользователя (скрипты, стили, картинки), а дальше работает без перезагрузки страниц. Раньше эту стартовую загрузку обслуживало то же ядро, что проводит тестирование: оно и сжимало файлы для передачи по сети, и отдавало их. При заходе каждого нового пользователя эта работа ложилась на ядро, отвлекая его от главной задачи.
Теперь всё иначе. Файлы интерфейса отдаёт напрямую новый веб-сервер, вообще не беспокоя ядро. К тому же файлы заранее сжаты по максимуму и лежат уже готовыми, так что при выдаче ничего не пересжимается. Процессор не тратится на упаковку, а файлы уходят к пользователю мгновенно. Даже ответы, которые система формирует на ходу во время тестирования, упаковывает для передачи веб-сервер, а не ядро.
Раньше каждая долгая передача данных занимала один из рабочих потоков ядра, а их число ограничено. Пока пользователь со слабым каналом связи неспешно загружал страницу, скачивал файл или смотрел видео, занятый им поток «висел на проводе» и не мог обслуживать других. Один такой пользователь погоды не делал, но когда медленных передач набирались десятки и сотни, свободные потоки заканчивались, и система начинала тормозить у всех.
Теперь новый веб-сервер работает как надёжный буфер. Он берёт всю долгую пересылку на себя: сам не спеша собирает данные от пользователя с медленной связью и передаёт их ядру мгновенно. А когда ядро отдаёт ответ (например, страницу с текстом, файл для скачивания или обучающее видео), веб-сервер моментально забирает его себе и плавно транслирует пользователю со скоростью его канала связи.
Раньше резкие всплески активности могли превысить технические лимиты системы. Если множество пользователей одновременно загружали страницу, запускали тесты, переключались между вопросами или сохраняли ответы, часть новых подключений отвергалась, вызывая обрывы связи и попытки автоматического переподключения.
Теперь новый веб-сервер работает как строгий диспетчер: он точно знает, сколько запросов ядро готово обработать прямо сейчас. Если нагрузка превышает предел, веб-сервер не сбрасывает новые запросы, а аккуратно выстраивает их во внутреннюю очередь. Вместо обрыва связи запрос просто дожидается своей очереди, и пользователь плавно продолжает работу.
Любой ресурс в Интернете постоянно сканируют боты, которые перебирают служебные адреса и создают паразитную нагрузку. И это опасно даже там, где реальных пользователей немного. У старого сервера было жёстко ограничено число одновременных подключений, и одного вредоносного бота хватало, чтобы исчерпать этот лимит. Тогда сбои начинались даже у тех нескольких человек, кто в этот момент проходил тест. Проблема касалась всех, а не только больших площадок.
Теперь на входе стоит защитный щит: новый веб-сервер отсекает ботов ещё на подходе, не пропуская их к ядру системы.
Раньше при высокой нагрузке ядро системы захватывало оперативную память вплоть до технических лимитов и больше никогда её не возвращало, даже когда тестирование завершалось и сервер полностью простаивал (это особенность работы веб-сервера Apache).
Теперь архитектура переработана: фоновые аппетиты ядра снижены, а основную ударную нагрузку берёт на себя новый веб-сервер. При массовых наплывах пользователей он гибко запрашивает у операционной системы нужные ресурсы, а как только активность спадает, сразу же освобождает их.
Единое постоянное соединение, о котором шла речь в первых пунктах, помогает не только пользователям. Не меньше выигрывает и сам сервер.
Раньше, без переиспользования соединений, при каждом обращении браузера серверу приходилось открывать новое сетевое подключение, а если соединение защищённое, то заново договариваться с браузером о шифровании. Когда систему одновременно использовали сотни человек, это превращалось в поток из сотен новых подключений каждую секунду. Такая нагрузка била сразу по нескольким направлениям. Росла нагрузка на процессор и операционную систему. Переполнялась очередь ожидающих подключений уже на уровне операционной системы, и часть пользователей вообще не могла подключиться.
Вдобавок отработанные подключения не исчезают мгновенно: операционная система ещё несколько минут держит каждое из них в памяти, и при таком потоке в ней скапливались десятки тысяч «хвостов» от уже закрытых соединений. Особенно тяжело приходилось обычным, не серверным версиям Windows, где сетевые лимиты заметно скромнее. В итоге система начинала сыпать сетевыми ошибками даже при умеренном числе пользователей.
Теперь браузер устанавливает соединение один раз и переиспользует его для сотен последующих запросов. Серверу больше не нужно непрерывно создавать, шифровать и закрывать подключения.
Когда пользователь работает по защищённому соединению (HTTPS), все данные между его браузером и сервером шифруются, чтобы их нельзя было перехватить. Такая защита надёжна, но само шифрование требует вычислительных ресурсов. Раньше им занималось само ядро системы, тратя силы на криптографию вместо тестирования.
Теперь всё шифрование выполняет новый веб-сервер, причём по самому современному и быстрому на сегодня протоколу TLS 1.3. Заодно защищённое соединение с пользователем стало устанавливаться быстрее.
Раньше первым удар из Интернета принимал Apache, а его легко «положить» типичными сетевыми атаками. Медленные соединения, которые нарочно растягивают обмен данными и занимают все свободные подключения (Slowloris, Slow POST, Slow Read), и лавины одновременных подключений (флуд) роняли его без труда.
Теперь ядро системы полностью скрыто от Интернета. Снаружи доступен только наш веб-сервер: он стоит на входе как защитный шлюз и принимает первый удар на себя, просто «впитывая» такие атаки. Он же отсекает некорректные и непомерно большие запросы ещё на подходе и для подстраховки закрывает доступ к служебным и конфигурационным файлам. Даже прямое обращение к внутренним компонентам системы просто не пройдёт. Всё это работает автоматически, без какой-либо настройки со стороны администратора.
Раньше для служебных сообщений (например, «доступ ограничен», «страница не найдена» или «система уже открыта в другой вкладке») использовался простой шаблон старого ядра (строчка текста в углу пустой страницы), который к тому же подтягивал весь тяжёлый файл оформления интерфейса. Язык при этом иногда определялся неверно (например, при первом входе с ограничением по IP сообщение всегда выходило на английском).
Теперь все служебные страницы заменены на единую современную страницу. Она аккуратно оформлена, адаптирована под мобильные экраны и при этом предельно лёгкая (это готовый файл, который веб-сервер отдаёт сам, вообще не нагружая ядро). А нужный язык определяется автоматически: если пользователь уже выбирал язык интерфейса, сообщение выводится на нём, а если нет (например, при самом первом обращении), то на языке, установленном в настройках системы.
Раньше потолок задавал Apache. Сервер средней конфигурации держал около 3 000 одновременных пользователей, мощный – около 6 000. Причём упиралось всё именно в веб-сервер, а не в железо. Можно было купить машину в разы мощнее – и получить лишь пару тысяч пользователей сверху. Для по-настоящему массовых тестирований это был тупик: деньгами проблема не решалась.
Теперь все перечисленные архитектурные изменения сняли этот потолок, что мы проверили масштабными нагрузочными испытаниями на тех же самых конфигурациях серверов. Причём проверяли с запасом. Каждый виртуальный пользователь не только непрерывно работал (клики, переходы между вопросами, сохранение ответов), но и держал сразу два постоянных подключения (рабочее и служебное), хотя настоящий браузер открывает второе лишь изредка. В итоге на пике один сервер выдержал 60 000 одновременных живых подключений. Публичных примеров, чтобы веб-система под Windows стабильно держала интерактивную нагрузку такого масштаба на одном сервере, мы не нашли. Похоже, их просто не существует. При этом мы остались верны главному принципу INDIGO – вся эта мощь серверной архитектуры корпоративного уровня по-прежнему разворачивается за пару минут, простой установкой одним файлом, без сложной настройки и навыков системного администрирования. Вы получаете возможности промышленной платформы в привычном и простом в работе продукте.
Любая база данных при многолетней работе постепенно теряет скорость. Дело в устройстве самой СУБД (системы управления базами данных). При изменении данных PostgreSQL не стирает старые версии записей сразу, а лишь помечает их устаревшими (так работают все серьёзные СУБД). Чем активнее используется система тестирования, тем больше такого скрытого технического «мусора» накапливается в таблицах, отчего база всё чаще обращается к диску для поиска нужных данных и начинает ощутимо тормозить.
В INDIGO 5.0 мы глубоко переработали то, как устроена встроенная база данных (PostgreSQL). Теперь система работает одинаково быстро и в первый день после установки, и спустя годы, когда в базе накоплены сотни тысяч результатов и миллионы ответов. Все эти оптимизации уже встроены в обновление и действуют сами: администратору, как и прежде, не нужно ничего настраивать или обслуживать вручную.
Раньше уборка технического мусора работала со стандартными настройками PostgreSQL и запускалась, только когда в таблице накапливался мусор объёмом примерно в пятую часть от её размера. Порог этот процентный, поэтому он растёт вместе с таблицей. Пока данных немного, уборка изредка срабатывает, и всё выглядит нормально. Но чем больше становится таблица, тем больше мусора нужно накопить до следующей уборки: там, где хранятся ответы пользователей и подробные протоколы тестирований, счёт строк со временем идёт на миллионы, и уборка могла не наступать годами. Всё это время таблицы медленно раздувались, а система понемногу теряла скорость.
Теперь пороги уборки настроены для каждой таблицы индивидуально, а для самых крупных снижены в 200 раз. Причём пороги выверены на реальных нагрузках, чтобы сама уборка оставалась незаметной даже на медленных дисках.
Чтобы быстро находить данные, СУБД перед выполнением каждого запроса строит план: как именно искать и по каким индексам идти. Опирается она при этом на внутреннюю статистику о содержимом таблиц. И здесь была та же беда, что с уборкой мусора. Порог обновления статистики тоже процентный, поэтому на крупных таблицах она могла не освежаться годами. База строила планы по безнадёжно устаревшим сведениям и выбирала не самые быстрые пути выполнения запросов.
Теперь статистика обновляется регулярно, а порог её обновления задан отдельно для каждой таблицы. Частоту мы подбирали осторожно, ведь обновление статистики – тяжёлая дисковая операция, и слишком частые запуски на медленных дисках сами создавали бы подтормаживания. Итоговый баланс проверен на реальных нагруженных серверах.
Во время тестирования база непрерывно принимает изменения: каждый ответ пользователя – это новые и обновлённые записи в самых нагруженных таблицах. Раньше новым версиям записей приходилось искать место в конце файла таблицы, из-за чего файлы постепенно росли и фрагментировались, а диск выполнял массу лишней работы.
Теперь самые нагруженные таблицы устроены иначе. Данные в них хранятся небольшими блоками, и в каждом блоке заранее оставляется немного свободного места (маленький резерв не в конце файла, а прямо рядом с данными). Когда запись обновляется, её новая версия ложится в тот же блок, на место рядом с прежней, а не уезжает в конец таблицы.
Каждый открытый браузер раз в несколько секунд посылает серверу короткий сигнал «я на связи», и система обновляет отметку времени только этого пользователя (одну маленькую запись в служебной таблице). Механизм стандартный и сам по себе копеечный, но при сотнях и тысячах одновременных пользователей такие точечные обновления складываются в непрерывный поток. В ходе аудита производительности выяснилось, что устройство этой таблицы не позволяло СУБД выполнять обновления «на месте»: каждое из них заставляло базу перестраивать свои служебные структуры.
Мы изменили устройство таблицы. Служебный индекс, из-за которого каждое обновление обходилось базе так дорого, удалён, а в блоках теперь оставляется небольшой запас свободного места (тот же приём, что в предыдущем пункте). Статусы обновляются мгновенно, прямо на месте и без лишней работы.
Есть в базе и совсем небольшие служебные таблицы, которые система обновляет очень часто (например, текущее состояние веб-сервера). Из-за особенностей хранения в PostgreSQL такая крошечная таблица при постоянных обновлениях могла незаметно разрастись до сотен мегабайт и создавать ощутимую лишнюю нагрузку на диск. Вернуть ей нормальный размер могла только ручная оптимизация базы данных из программы администратора.
Мы настроили для таких таблиц режим обновления «на месте», и теперь они остаются компактными весь срок службы, а ручная оптимизация для этого больше не нужна.
Этот раздел – про окружение, в котором живёт система: сети, сертификаты, браузеры, форматы файлов и операционные системы. Принцип INDIGO неизменен: система должна одинаково хорошо работать в любом окружении, от сетей нового поколения до компьютеров, которым четверть века.
INDIGO официально поддерживает работу на отечественных операционных системах (ALT Linux, РЕД ОС и Astra Linux) через среду Wine. Раньше у этого режима было слабое место – запуск веб-сервера занимал до полутора минут. А стартует он не только вместе с системой. Администратор может перезапустить его кнопкой из программы администратора, и он же перезапускается автоматически при изменении настроек (например, портов или сертификатов). И каждый такой перезапуск превращался в долгое ожидание. Причина крылась в особенностях инициализации криптографических модулей внутри Wine.
Мы разыскали это узкое место и устранили его. Теперь запуск укладывается в 10–12 секунд, почти в 10 раз быстрее. Быстрее стало всё: первый старт после установки, запуск при загрузке операционной системы, ручные перезапуски и применение настроек.
Интернет постепенно переходит на адреса нового поколения – IPv6. Раньше INDIGO поддерживала их лишь частично. В простейших конфигурациях всё работало, но стоило указать в настройках конкретный IPv6-адрес, как начинались ложные ошибки, а в сочетании с HTTPS веб-сервер и вовсе не запускался.
Теперь поддержка IPv6 полноценная: адреса нового поколения можно указывать в настройках сетевых интерфейсов наравне с привычными, они работают и с HTTP, и с HTTPS, а IPv4 и IPv6 живут параллельно и не мешают друг другу. Обновлён и список адресов веб-интерфейса в программе администратора. Теперь он корректно отображает настроенные варианты подключения, включая IPv6-ссылки.
INDIGO умеет автоматически получать и продлевать бесплатные SSL-сертификаты Let's Encrypt. Но у этого механизма было уязвимое место: если администратор ограничивал доступ к системе по IP-адресам (обычная практика в закрытых корпоративных сетях), под блокировку попадал и проверочный бот удостоверяющего центра. Выпуск и продление сертификатов ломались.
Теперь служебный проверочный адрес, по которому удостоверяющий центр подтверждает подлинность домена, всегда остаётся доступным независимо от настроек ограничений (он не содержит никаких данных системы и используется только в момент выпуска сертификата). Отдельно система стала терпеливее к медленным ответам серверов Let's Encrypt (увеличено время ожидания), а журнал выпуска стал чище и понятнее.
Администраторы нередко размещают на сервере системы собственные файлы (инструкции, методички, аудио и видео) и дают на них прямые ссылки из тестов или информационных страниц. Раньше сервер «знал в лицо» лишь 13 типов файлов, а незнакомые отдавал браузеру как безликий поток данных. Из-за этого аудио и видео по прямой ссылке скачивались файлом вместо воспроизведения, векторные изображения не отрисовывались, а некоторые документы открывались нечитаемыми символами.
Теперь сервер различает 35 типов файлов (все популярные форматы аудио, видео, изображений, документов и архивов). Каждый ведёт себя как положено: аудио и видео воспроизводятся прямо в браузере, изображения отображаются, документы и архивы аккуратно скачиваются.
У INDIGO собственная профессиональная локализация, поэтому вмешательство браузерных автопереводчиков ей строго противопоказано: машинный перевод способен исказить надписи, кнопки и даже формулировки вопросов. Базовую защиту от этого система получила ещё в версии 3.7, когда Chrome ошибочно определял язык интерфейса и предлагал его «перевести», а при некоторых настройках браузера переводил и вовсе автоматически, без ведома пользователя. Но браузеры продолжают менять свои алгоритмы, и со временем ложно срабатывать на локализованные тексты начали Safari и Firefox. Они навязчиво предлагали пользователям перевод, а согласие на него искажало интерфейс.
Теперь защита усилена современным стандартом W3C, который прямо запрещает браузеру переводить страницы системы. Он добавлен и в главный интерфейс, и на служебные страницы, в дополнение к прежним механизмам.
INDIGO принципиально поддерживает очень старые компьютеры: парк техники в организациях обновляется медленно, и система обязана работать даже там, где до сих пор стоит Windows XP. В версии 3.10 поддержка отечественных ОС потребовала глубоких изменений, и они случайно задели совместимость с XP. В версии 4.0 мы восстановили её для основных компонентов, но программа установки обновлений оставалась затронутой.
Теперь исправлена и она: механизм инициализации переработан, и совместимость с Windows XP восстановлена полностью, без какого-либо ущерба для работы на современных системах и Linux.
Большая часть серверов INDIGO работает в непростых условиях: недорогие виртуальные серверы с медленными дисками, нестабильные сети, внезапные перезагрузки. В версии 5.0 мы прошлись по всем известным сценариям сбоев (от повреждённых данных в кэше до внезапной остановки посреди тяжёлой операции) и переписали их обработку. Принцип простой: что бы ни случилось, система должна пережить сбой тихо и продолжить работу, а не зависнуть с ошибкой.
Данные активных сеансов (кто вошёл в систему, какой тест выполняется) хранятся в быстром кэше в оперативной памяти, и система обращается к нему при каждом действии пользователя. Раньше обработчик этого кэша был доверчив: он рассчитывал, что кэш всегда отвечает быстро, а данные в нём всегда целы. Если же из-за сбоя на сервере данные повреждались, страница могла зависнуть в долгом ожидании или выдать ошибку.
Теперь обработчик переписан с нуля по принципу «не доверяй и проверяй». Жёсткие лимиты времени не дают системе зависнуть, даже если кэш перестал отвечать. Все данные при чтении проходят многоуровневую проверку целостности, и если сеанс повреждён, система не падает с ошибкой, а тихо сбрасывает его, и пользователь просто заново входит в систему и продолжает работу с новым, здоровым сеансом.
У быстрого кэша сеансов из предыдущего пункта есть строго отведённый объём памяти. Когда она заканчивается, кэш освобождает место, удаляя записи, к которым дольше всего не обращались, и среди удалённых могут оказаться ещё нужные сеансы. Для пользователя это выглядит как внезапный выход из системы. Раньше отведённого объёма хватало с запасом под прежний потолок нагрузки, но версия 5.0 этот потолок заметно подняла. К тому же память расходуется быстрее, если включены длительные сеансы (когда система помнит вошедших пользователей между визитами) или когда сервер заваливают мусорными запросами боты, ведь каждый такой запрос создаёт в кэше новый сеанс.
Теперь объём памяти кэша удвоен, со 100 до 200 МБ. Этого с запасом хватает даже на пиковые 30 000 одновременных пользователей, на длительные сеансы и на случай наплыва ботов.
В прежних версиях скрывалась редкая, но коварная ошибка. При записи некоторых ошибок в журнал могли повреждаться данные активного сеанса тестирования. Интерфейс блокировался, и не помогало даже обновление страницы. Проявлялась ошибка при редком стечении обстоятельств, но на реальных серверах такие случаи фиксировались.
Теперь механизм записи в журнал полностью переработан и надёжно изолирован от данных сеансов. Повредить сеанс тестирования он больше не может.
У браузера есть свой лимит терпения: сколько ждать ответа сервера, прежде чем показать ошибку. Раньше эти лимиты были рассчитаны на идеальные условия. При массовом одновременном тестировании или на медленной связи браузер мог не дождаться ответа и показать ложную ошибку соединения, хотя сервер исправно работал. Хуже того, не дождавшись ответа, браузер отправлял запрос повторно, и тысячи таких повторов дополнительно нагружали сервер в самый неподходящий момент.
Теперь все лимиты ожидания пересчитаны с запасом под реальные условия. Браузер терпеливо дожидается ответа при пиковых нагрузках, а на отправку файла, прикреплённого к ответу-эссе, отведено до десяти минут (прежде тяжёлый файл с медленного мобильного интернета просто не успевал отправиться). Отдельно исправлена обработка ошибок доступа: если раньше при запрете по IP интерфейс уходил в бесконечный цикл переподключений, то теперь пользователь видит понятное сообщение.
Сердце серверной части INDIGO – служба-контроллер, которая управляет всеми компонентами и постоянно обменивается данными с базой. Прежняя схема этого взаимодействия была отлажена годами, но имела редкие изъяны, по большей части теоретические: при неудачном стечении обстоятельств (долгая фоновая операция, медленный диск, внезапная команда на остановку) два обращения к базе могли столкнуться во времени. На практике такое почти не проявлялось, но полагаться на удачу мы не хотели.
Теперь взаимодействие с базой укреплено сразу несколькими независимыми слоями защиты. Специальный предохранитель исключает одновременные обращения из разных частей службы. Любые операции выполняются строго по очереди, даже если команда пришла в разгар тяжёлой работы. Служба постоянно проверяет состояние подключения и при обрыве сети восстанавливает его автоматически, в фоне и незаметно для пользователей. Служебные команды (запуск рассылок, обновление настроек) идут по отдельному выделенному каналу и доставляются мгновенно, даже когда основное подключение занято долгой операцией.
Раньше самым уязвимым моментом было выключение или перезагрузка сервера. Служба не успевала корректно остановить базу данных, та завершалась аварийно и при следующем запуске подолгу восстанавливала себя, особенно на медленных дисках. Были и другие шероховатости: на слабых серверах ручная остановка службы могла ложно выглядеть зависшей, а при неудачном старте отдельных компонентов система уходила в долгие циклы напрасных перезапусков с тревожными уведомлениями.
Теперь жизненный цикл службы переработан полностью. При выключении или перезагрузке сервера выполняется мягкая остановка: закрываются соединения, завершаются фоновые задачи, база данных останавливается штатно, и следующий запуск проходит быстро, без аварийного восстановления. Во время остановки служба обменивается контрольными сигналами с Windows, поэтому ложных «зависаний» больше нет. А при запуске каждый компонент проверяется по фактической готовности. Система дожидается реального ответа, а не угадывает по косвенным признакам.
Хорошая защита незаметна: пользователь её не видит, но она постоянно оберегает и его данные, и сам сервер. В версии 5.0 мы усилили безопасность сразу на нескольких рубежах, действуя на опережение, по современным отраслевым стандартам (в том числе рекомендациям OWASP – международной организации, задающей стандарты защиты веб-приложений). Все меры этого раздела превентивные: они закрывают возможные лазейки заранее, ещё до того, как ими кто-то попытается воспользоваться.
Когда пользователь входит в систему, сервер выдаёт его браузеру уникальный ключ сеанса, по которому система узнаёт человека при каждом следующем действии, не спрашивая пароль заново. Если такой ключ попадёт в чужие руки, злоумышленник сможет действовать от имени пользователя. Определённый риск здесь несут сторонние скрипты, которые нередко подключают к веб-страницам (виджеты, счётчики, внешние сервисы): теоретически такой скрипт мог бы попытаться прочитать ключ.
Теперь ключ сеанса помечен специальным признаком (HttpOnly), который запрещает любым скриптам в браузере даже видеть его. Ключ доступен исключительно самому серверу. Ни сторонний виджет, ни расширение браузера, ни внедрённый вредоносный код не могут его прочитать.
У защиты ключа сеанса есть известный обходной приём: злоумышленник может попытаться выманить ключ через служебный отладочный режим веб-сервера (так называемый HTTP-метод TRACE), в обход описанной выше защиты. Приём этот давно описан, и стандарты безопасности OWASP прямо рекомендуют перекрывать такую лазейку.
Теперь служебный метод TRACE отключён на уровне веб-сервера, и воспользоваться этим обходным путём невозможно.
В разделе о веб-сервере мы рассказывали, что ядро системы скрыто от Интернета. Есть и второй, внутренний рубеж защиты на случай, если какой-то запрос всё же попытается добраться до файлов на сервере. Раньше ядро технически имело доступ ко всему диску и при обработке запроса могло, теоретически, обратиться к файлам за пределами своей рабочей папки. Это классический вектор атак, известный как «выход за пределы каталога» (Path Traversal).
Теперь ядро жёстко заперто в своей рабочей папке. Всё, что за её пределами (остальной диск, системные файлы), для него попросту не существует: обратиться туда оно не может в принципе.
Администраторы могут ограничивать доступ к системе по адресам (например, разрешить вход только из сети организации). Раньше задавать такие ограничения можно было лишь довольно грубо, перечисляя адреса или их части. Для крупных сетей, разбитых на несколько подсетей, это было неудобно.
Теперь система понимает оба привычных способа записи целых подсетей: как краткий формат CIDR (например, 192.168.0.0/24), так и запись через классическую маску подсети (192.168.0.0/255.255.255.0).
Выше мы разобрали главное, но обновление этим не исчерпывается. В INDIGO 5.0 вошли и десятки менее заметных доработок: служба контроллера и программы установки получили множество внутренних исправлений, повышающих надёжность в редких и граничных ситуациях, служебные журналы очищены от мусорных записей ботов-сканеров и ложных предупреждений, наведён порядок в редиректах, убраны случайные рамки вокруг ссылок при кликах в новых версиях Chrome, а в программе администратора ускорен отклик кнопок управления, скорректированы размеры окон и устранены огрехи отображения при увеличенном масштабе экрана.
Некоторые организации выпускают INDIGO в Интернет через собственные промежуточные серверы (NGINX, корпоративные шлюзы, системы фильтрации трафика, внешние сервисы защиты от DDoS). В такой схеме подключения пользователей первым принимает не INDIGO, а Ваш промежуточный сервер, и все сетевые механизмы платформы работают ровно настолько, насколько корректно он настроен. Возможные последствия неудачной конфигурации – ошибки загрузки файлов из-за заниженных лимитов, потеря реальных IP-адресов пользователей и обрывы связи из-за отключённых постоянных соединений. Причём постоянные соединения важны на обоих участках: на внешнем (от браузеров пользователей до Вашего сервера), иначе подключения снова будет обрывать ТСПУ, и на внутреннем (от Вашего сервера до INDIGO), иначе каждый запрос станет открывать новое соединение, создавая задержки и лишнюю нагрузку. Все эти проблемы проявляются на любой версии INDIGO, потому что связаны не с обновлением, а с самой схемой подключения.
INDIGO 5.0 – самое масштабное обновление серверной части за всю историю платформы, и его главные итоги просты. Система снова уверенно и быстро работает через Интернет в любых условиях. Она выдерживает в пять раз больше одновременных пользователей и не теряет скорость с годами. Она стала устойчивее к сбоям, перезагрузкам и атакам, а данные защищены по современным стандартам безопасности. И всё это по-прежнему разворачивается за пару минут одним файлом и не требует от администратора специальных знаний и дополнительной настройки.
За каждым пунктом этого описания стоит большой объём инженерной работы, но весь её смысл умещается в несколько слов. INDIGO 5.0 работает быстро, стабильно и безопасно – на любом оборудовании и в любой сети.
Обновляйтесь и пользуйтесь с удовольствием!
