C чем едят NaCl

12 январь, 2012 - 12:13Игорь Дериев

Большинство из нас, наверное, помнят из школьного курса химии формулу поваренной соли, но в данном случае речь пойдет не о химии, и даже не о кулинарии. NaCl — официальное сокращение для названия технологии Google Native Client, призванной поднять на новый уровень разработку веб-приложений. Хотя, вероятно, использование этой и других кулинарных аллюзий должно подчеркнуть, что теперь разработчики смогут «приготовить» из своего кода совершенно новые «блюда».

Как можно догадаться из названия, Native Client — некий механизм, который обеспечивает исполнение в браузере машинного (native) кода. Данная инициатива объявлена Google весной 2009 г., в начале 2010-го стартовал проект для архитектуры ARM, а осенью 2011 г. x86-реализация NaCl в браузере Chrome достигла версии 1.0. Надо понимать, что это довольно принципиальная веха, и в связи с ней была даже продемонстрирована некоторая маркетинговая активность, хотя хорошо известно, что номера версий у Google на деле мало что значат. В текущем состоянии NaCl работает только с приложениями из Chrome Web Store, поддержку «доморощенных» разработок необходимо включить на странице about:flags.

C чем едят NaCl

Google Native Client стал штатным механизмом браузера Chrome

Любопытно однако, что данную инициативу не поддержал вообще никто в индустрии, включая даже вроде бы дружественно настроенную Mozilla, тем важнее разобраться с мотивами Google.

В качестве стандартного способа разработки веб-приложений сегодня видится сочетание HTML5 и JavaScript, которое активно развивается фактически всей индустрией (пример редкого единогласия) и постепенно вытесняет промежуточные проприетарные технологии вроде Flash и Silverlight. За последние пару лет JavaScript сделал большой шаг вперед и продолжает совершенствоваться, однако ограничения его тоже хорошо известны. Возможно, они не настолько критичны, если иметь в виду поступательное эволюционное развитие Веба: от отдельных функций страниц — к насыщенным сайтам — к развитым веб-приложениям — к тотальному господству облачных вычислений и браузеров. Другое дело, когда связка HTML5/JavaScript уже сегодня становится основным средством разработки. Хорошим примером здесь является webOS, которая, по словам Пола Мерсера (бывшего старшего директора по разработке ПО в Palm) фактически с самого начала была обречена на провал. В далеком по меркам ИТ 2009 г. миграция на веб-технологии была слишком смелым и, как теперь уже ясно, неоправданным шагом. Приложения для webOS во многих случаях просто не обеспечивали такой производительности и отзывчивости, как их аналоги для iOS. Примечательно также, что в webOS был предложен механизм для использования в сторонних приложениях кода на С/С++, идейно похожий на NaCl. Но, видимо, эта ОС все-таки слишком опередила свое время.

Google на самом деле находится точно в таком же положении, как и Palm/HP. Ведь она развивает не только собственно браузер Chrome, но и построенную вокруг него Chrome OS. Последняя до сих пор не снискала сколько-нибудь заметной популярности, ей еще предстоит сломить целый ряд предубеждений пользователей, что довольно непросто. Огромная проблема заключается в том, что мало сделать эффективное веб-приложение, нужно обеспечить его сносную работу и большую часть функциональности в автономном режиме, когда нельзя положиться на серверную сторону. Вот здесь-то, по задумке Google, и должен прийти на помощь NaCl.

Подобные проблемы, конечно, стоят не только перед Google. Начнем с того, что давным-давно Microsoft разработала аналогичный Native Client механизм ActiveX — также проприетарный (к тому же, естественно, закрытый) и довольно быстро себя дискредитировавший с точки зрения безопасности. Показательно, что, хотя он поддерживается во всех версиях Internet Explorer, никто о нем уже почти не вспоминает, разве что в контексте зашиты браузера. C тех пор Microsoft стала действовать гораздо осторожнее и аккуратнее — скажем, хотя новый интерфейс Metro поощряет применение именно HTML5/JavaScript, разработку для него можно вести и с помощью более привычных технологий.

Google, естественно, постаралась учесть ошибки предшественников. По задумке Native Client должен одновременно обеспечивать производительность и безопасность, удобство разработки и переносимость. Впечатляющая задача! Для ее выполнения NaCl построен на идеях так называемой «программной изоляции ошибок», которые достаточно давно были сформулированы учеными из MIT. Проблема, однако, в том, что на х86 они плохо реализуемы, поэтому потребовался целый ряд дополнительных ухищрений. В частности, NaCl SDK включает модифицированные инструменты GNU (gcc и пр.), которые добавляют в окончательный код специфические проверки адресов, выравнивают инструкции и вообще делают код удобным для дизассемблирования. Google утверждает, что все это «съедает» всего лишь 5% производительности обычного, не адаптированного кода на С/С++ для платформ ARM и x86-32 и 7% — для x86-64. Соответственно, NaCl во многих примерах демонстрирует на порядок более высокую производительность, чем JavaScript. Пока Native Client поддерживает только С и С++, но в перспективе должны добавиться и другие языки.

На текущий момент NaCl SDK генерирует платформенно-зависимый код для трех наиболее распространенных платформ. Однако в разработке находится Portable Native Client (PNaCl), который основывается на так называемой низкоуровневой виртуальной машине LLVM. Последняя умеет транслировать специальный промежуточный байт-код в целевой машинный код для целого ряда процессорных архитектур, что в перспективе обеспечит высочайшую кроссплатформенность (если она, конечно, будет востребована в таких масштабах). С другой стороны, NaCl-код работает на уровне браузера и таким образом не зависит от используемой ОС, доступ к системным функциям и API ему не только не нужен, но и противопоказан — из соображений безопасности. Соответственно, Native Client сам реализует наиболее востребованные программные интерфейсы, к которым на данном этапе относятся файловый ввод-вывод, рендеринг двумерной и трехмерной графики (OpenGL ES 2.0), низкоуровневая работа с аудио и взаимодействие с веб-страницами (скриптами). Для подключения NaCl-модулей используется Pepper Plug-in API (PPAPI) или просто Pepper (соль и перец — самые необходимые специи). Разработка специального API понадобилась в силу того, что NPAPI плохо подходит для внепроцессного подключения модулей, управления событиями и асинхронных взаимодействий.

C чем едят NaCl

Общее представление об архитектуре Native Client

Естественно, использование машинного кода в веб-приложениях открывает перед разработчиками большие возможности, которые могут использоваться как с благими целями, так и с не очень. Поэтому безопасности в Native Client уделено первостепенное значение. Она базируется на так называемой двойной песочнице. Внешняя, в целом, аналогична обычной браузерной песочнице, действует во время исполнения NaCl-кода и пресекает попытки потенциально опасного воздействия на браузер и системную среду. Внутренняя же основывается на статическом анализе кода, т.е. еще до исполнения она верифицирует код на предмет наличия потенциально опасных инструкций и приемов. Вообще говоря, такой анализ труднореализуем (с достаточной эффективностью) для x86 из-за особенностей архитектуры, возможности самомодификации кода и пр. Однако, как говорилось выше, ситуация в значительной степени корректируется адаптированным компилятором, который призван упростить дизассемблирование. Кроме того, в Native Client четко разграничиваются сегменты кода и данных. В целом система безопасности выглядит довольно продуманной, хотя это и не означает, что она совсем лишена недочетов и ошибок. Еще в 2009 г. Google проводила специальный конкурс по поиску уязвимостей в Native Client и надо сказать, что весь призовой фонд в $16К оказался востребованным. Подобные конкурсы больше не проводились, но Google продолжает активное сотрудничество в данном направлении с сообществом независимых разработчиков.

C чем едят NaCl

Принцип действия системы безопасности Native Client

Итак, разобравшись с тем, что из себя представляет Native Client, несложно очертить и круг его наиболее вероятных применений.

Создание игр. Игровое и развлекательное ПО движет потребительским рынком, который сегодня оказался на пике прогресса. Однако для него нынешний Веб — далеко не лучшая программная платформа. До сих пор большинство веб-игр создавались и создаются средствами Flash. Ситуация отчасти исправляется в HTML5, в первую очередь, за счет элемента , аппаратного ускорения графики в нем, поддержки WebGL (Microsoft, как известно, от последнего предсказуемо открестилась). Но до решения всех проблем еще далеко. К тому же NaCl особенно эффективен при переносе в Веб существующих игр. Типичным примером, как обычно, служит Quake. Однако уже существуют и более серьезные (в том числе с коммерческой точки зрения проекты) — к примеру, популярная игра Bastion, прежде доступная только на Windows и Xbox. Надо сказать, что большой разницы между исполнением в родной среде и браузере практически не ощущаются. Также, по сообщению Google, на Native Client портируются игровые платформы Unity и Moai.

C чем едят NaCl

Конечно, игры — наиболее очевидная и заманчивая сфера применения Native Client. Однако новый механизм вполне годится и для более серьезных решений

Мультимедийные приложения. Всевозможные кодеки, а также приложения для интенсивной работы с аудио и видео. Низкоуровневые API и код на С/С++ должны обеспечить достаточную их эффективность. Google портировала на Native Client собственный внутренний H.264-декодер. К 11 тыс оригинальных строк кода на С потребовалось добавить всего лишь еще около 20, в основном для специфической обработки ошибок. Производительность оказалась соизмеримой.

Производительные вычисления. Как уже говорилось, NaCl-код во многих случаях оказывается на порядок (и даже более) быстрее JavaScript. Это может быть критично, к примеру, для криптографических приложений, в том числе, востребованных в корпоративной среде. Кроме того, машинный код позволяет эффективно задействовать различные аппаратные оптимизации, скажем SSE. Встроенный в последнюю версию Chrome инструмент просмотра PDF уже реализован в виде NaCl-модуля — добиться его приемлемой работы на JavaScript, пожалуй, было бы проблематично.

Перенос в Веб настольных приложений. Хорошо известно, как трогательно компании относятся к унаследованному ПО. Желание перенести их в «облака» закономерно наткнется на необходимость портирования клиентской части и мало кто рискнет делать это на JavaScript. В свою очередь NaCl обещает сделать этот процесс сравнительно безболезненным, особенно в тех случаях, когда не использовались обширные сторонние библиотеки и фреймворки. К тому же, последние тоже постепенно могут быть портированы на Native Client, как, к примеру, это происходит сейчас с Mono.

В общем, Native Client выглядит довольно перспективно, во всяком случае, с точки зрения Google, которая с его помощью прежде всего решает свои многочисленные задачи. Как говорилось выше, остальная индустрия NaCl не восприняла. Возможно, сыграло роль существенное снижение интереса к вообще всякого рода вспомогательным механизмам (ActiveX, Flash, Silverlight). Хотя, конечно, существует и объективная критика. Native Client усложняет архитектуру браузера, дополнительные API открывают новые направления для возможных атак и т.д. Есть подозрение, что NaCl-код окажется не таким уж эффективным при работе с внешними данными. Кроме того, возможности оптимизации JavaScript и HTML5 еще явно не исчерпаны, скажем, даже появление в них поддержки SSE уже сократит разрыв с NaCl. Тем не менее, в переходный период (знать бы, откуда и куда) механизм эффективной кросс-платформенной разработки открывает дополнительные возможности по освоению Веба. Завершение Native Client для ARM позволит выйти на мобильный рынок, где средства повышения производительности особенно актуальны. Но и без того можно сказать, что в конце прошлого года лед для NaCl тронулся (и химия здесь не при чем).