Klient natywny Google — Google Native Client

Klient natywny Google
Deweloper(zy) Google , inne
Pierwsze wydanie 16 września 2011 ; 10 lat temu ( 2011-09-16 )
Wersja stabilna
SDK: Pieprz 45/10 lipca 2015 ; 6 lat temu ( 2015-07-10 )

Klienci: tak samo jak Google Chrome

Magazyn
Napisane w C , C++
System operacyjny Windows , Linux , macOS , Chrome OS
Platforma x86 , ramię , MIPS
Rodzaj Piaskownica w przeglądarkach internetowych dla kodu natywnego
Licencja Nowy BSD
Strona internetowa programista .chrome .com /native-client

Klient natywny Google ( NaCl ) to technologia piaskownicy umożliwiająca uruchamianie podzbioru kodu natywnego Intel x86 , ARM lub MIPS albo przenośnego pliku wykonywalnego w piaskownicy. Umożliwia bezpieczne uruchamianie natywnego kodu z przeglądarki internetowej , niezależnie od systemu operacyjnego użytkownika , co pozwala aplikacjom internetowym działać z prędkością zbliżoną do natywnej, co jest zgodne z planami Google dotyczącymi systemu operacyjnego Chrome . Może być również używany do zabezpieczania wtyczek przeglądarek i części innych aplikacji lub pełnych aplikacji, takich jak ZeroVM .

Aby zademonstrować gotowość tej technologii, 9 grudnia 2011 r. firma Google ogłosiła dostępność kilku nowych wersji gier tylko dla Chrome, znanych z bogatej i wymagającej dużej mocy obliczeniowej grafiki , w tym Bastion (który nie jest już obsługiwany w Chrome Web Store). NaCl obsługuje akcelerowaną sprzętowo grafikę 3D (poprzez OpenGL ES 2.0), lokalne przechowywanie plików w piaskownicy, dynamiczne ładowanie , tryb pełnoekranowy i przechwytywanie myszy . Planowane jest również udostępnienie NaCl na urządzeniach przenośnych.

Portable Native Client (PNaCl) to wersja niezależna od architektury. Aplikacje PNaCl są kompilowane z wyprzedzeniem . W większości przypadków zaleca się stosowanie PNaCl zamiast NaCl. Ogólna koncepcja NaCl (uruchamianie kodu natywnego w przeglądarce internetowej) została już wcześniej zaimplementowana w ActiveX , który będąc nadal w użyciu, ma pełny dostęp do systemu (dysk, pamięć, interfejs użytkownika, rejestr itp.). Klient natywny unika tego problemu, korzystając z piaskownicy.

Alternatywą dla NaCl jest asm.js , który umożliwia również kompilowanie aplikacji napisanych w C lub C++ do uruchamiania w przeglądarce (z prędkością ponad połowy natywnej), a także obsługuje kompilację z wyprzedzeniem, ale jest podzbiór JavaScriptu, a zatem kompatybilny wstecz z przeglądarkami, które nie obsługują go bezpośrednio. Inną alternatywą (choć początkowo może być zasilana przez PNaCl) jest WebAssembly .

W dniu 12 października 2016 r. komentarz dotyczący narzędzia do śledzenia problemów Chromium wskazywał, że zespoły Google Pepper i Native Client zostały pozbawione personelu. 30 maja 2017 r. Google ogłosił wycofanie PNaCl na rzecz WebAssembly . Chociaż początkowo Google planowało usunięcie PNaCl w pierwszym kwartale 2018 roku, a później w drugim kwartale 2019 roku, obecnie planowane jest usunięcie PNaCl w czerwcu 2022 roku (wraz z aplikacjami Chrome).

Przegląd

Klient natywny to projekt typu open source opracowywany przez Google . Do tej pory Quake , XaoS , Battle for Wesnoth , Doom , Lara Croft and the Guardian of Light , From Dust i MAME , a także system przetwarzania dźwięku Csound , zostały przeniesione do Native Client. Klient natywny jest dostępny w przeglądarce internetowej Google Chrome od wersji 14 i jest domyślnie włączony od wersji 31, kiedy został wydany przenośny klient natywny (PNaCl, wymawiane: pinnacle).

ARM realizacja została wydana w marcu 2010. x86-64 , IA-32 i MIPS są również obsługiwane.

Aby uruchomić aplikację przenośnie w PNaCl, należy ją skompilować do niezależnego od architektury i stabilnego podzbioru kodu bajtowego reprezentacji pośredniej LLVM . Pliki wykonywalne nazywane są plikami wykonywalnymi PNaCl (pexes). Łańcuch narzędzi PNaCl tworzy pliki .pexe; Pliki NaCl Toolchain .nex. Magiczna liczba plików .nexe jest 0x7f „E” „L” „F”, który jest ELF . W Chrome są one tłumaczone na pliki wykonywalne specyficzne dla architektury, dzięki czemu można je uruchamiać.

NaCl wykorzystuje wykrywanie i izolację błędów oprogramowania do piaskownicy na x86-64 i ARM. Implementacja klienta natywnego x86-32 wyróżnia się nowatorską metodą sandboxingu, która wykorzystuje rzadko używaną funkcję segmentacji architektury x86 . Klient natywny konfiguruje segmenty x86, aby ograniczyć zakres pamięci, do którego może uzyskać dostęp kod w trybie piaskownicy. Używa weryfikatora kodu, aby zapobiec użyciu niebezpiecznych instrukcji, takich jak te, które wykonują wywołania systemowe. Aby zapobiec przeskakiwaniu kodu do niebezpiecznej instrukcji ukrytej w środku bezpiecznej instrukcji, klient natywny wymaga, aby wszystkie skoki pośrednie były skokami na początek 32-bajtowych bloków, a instrukcje nie mogą przechodzić między tymi blokami. Z powodu tych ograniczeń kod C i C++ musi zostać ponownie skompilowany, aby działał w kliencie natywnym, który zapewnia dostosowane wersje łańcucha narzędzi GNU , w szczególności GNU Compiler Collection (GCC), GNU Binutils i LLVM .

Klient natywny jest licencjonowany na podstawie licencji w stylu BSD .

Klient natywny używa Newlib jako swojej biblioteki C , ale dostępny jest również port biblioteki GNU C (GNU libc).

Pieprz

NaCl oznacza chlorek sodu , zwykłą sól kuchenną ; jako gra słów używano również nazwy pieprz . Pepper API to wieloplatformowy interfejs API typu open source do tworzenia modułów klienta natywnego. Pepper Plugin API lub PPAPI to wieloplatformowy interfejs API dla wtyczek do przeglądarek internetowych zabezpieczonych przez klienta natywnego, najpierw oparty na NPAPI firmy Netscape , a następnie przepisany od podstaw. Jest obecnie używany w Chromium i Google Chrome, aby włączyć wersję PPAPI programu Adobe Flash i wbudowaną przeglądarkę plików PDF .

PPAPI

12 sierpnia 2009 r. strona w Google Code wprowadziła nowy projekt Pepper i powiązany z nim Pepper Plugin API (PPAPI), „zestaw modyfikacji NPAPI, dzięki którym wtyczki są bardziej przenośne i bezpieczniejsze”. To rozszerzenie zostało zaprojektowane specjalnie w celu ułatwienia implementacji wykonywania wtyczek poza procesem . Co więcej, celem projektu jest zapewnienie ram do tworzenia wtyczek w pełni międzyplatformowych. Rozważane tematy obejmują:

  • Jednolita semantyka NPAPI we wszystkich przeglądarkach.
  • Wykonywanie w oddzielnym procesie niż przeglądarka renderująca.
  • Standaryzuj renderowanie za pomocą procesu komponowania przeglądarki.
  • Definiowanie znormalizowanych zdarzeń i funkcji rasteryzacji 2D.
  • Wstępna próba udostępnienia grafiki 3D.
  • Rejestr wtyczek.

Pepper API obsługuje również gamepady (wersja 19) i WebSockets (wersja 18).

Na dzień 13 maja 2010 r. przeglądarka Google o otwartym kodzie źródłowym, Chromium , była jedyną przeglądarką korzystającą z nowego modelu wtyczek do przeglądarki. Od 2020 roku Pepper jest obsługiwany przez przeglądarki oparte na silnikach Chrome, Chromium i Blink, takie jak Opera i Microsoft Edge.

W sierpniu 2020 r. Google ogłosił, że obsługa PPAPI zostanie usunięta z Google Chrome i Chromium w czerwcu 2022 r.

PPAPI w Firefoksie

Twórcy Firefoksa stwierdzili w 2014 roku, że nie będą wspierać Peppera, ponieważ nie ma pełnej specyfikacji API poza jego implementacją w Chrome, który sam jest przeznaczony do użytku tylko z silnikiem układu Blink i ma prywatne API specyficzne dla wtyczki Flash Player, która nie są udokumentowane. W październiku 2016 r. Mozilla ogłosiła, że ​​ponownie rozważyła kwestię włączenia Pepper API i PDFium do przyszłych wersji Firefoksa, jednak nie podjęto takich kroków.

Aplikacje

Jedna strona internetowa używa NaCL na serwerze, aby umożliwić użytkownikom eksperymentowanie z językiem programowania Go w swoich przeglądarkach.

Przyjęcie

Niektóre grupy programistów przeglądarek obsługują technologię klienta natywnego, ale inne nie.

Zwolennicy

Chad Austin (z IMVU ) pochwalił sposób, w jaki Native Client może w bezpieczny sposób wprowadzać wysokowydajne aplikacje do sieci (z około 5% karą w porównaniu z kodem natywnym), jednocześnie przyspieszając ewolucję aplikacji po stronie klienta, dając wybór używanego języka programowania (oprócz JavaScript ).

Id Software „s John D. Carmack pochwalił Native Client na QuakeCon 2012, mówiąc:„Jeśli masz coś zrobić wewnątrz przeglądarki, Native Client jest znacznie bardziej interesujący jako coś, co zaczęło się jako naprawdę cholernie sprytny x86 siekać w drodze że mogą piaskować to wszystko w interesującym trybie użytkownika.Jest to teraz dynamiczna rekompilacja, ale coś, co programujesz w C lub C++ i kompiluje się do czegoś, co nie będzie twoim poziomem optymalizacji -O4 dla całkowicie natywnego kodu, ale dość cholernie blisko do kodu natywnego. Jako twórca gier do metalu możesz robić wszystkie swoje złe pogoń za wskaźnikami i cokolwiek chcesz.

Krytycy

Inni specjaliści IT są bardziej krytyczni wobec tej technologii piaskownicy, ponieważ wiąże się ona z istotnymi lub merytorycznymi problemami z interoperacyjnością.

Wiceprezes Mozilli ds. produktów, Jay Sullivan , powiedział, że Mozilla nie planuje uruchamiania natywnego kodu w przeglądarce, ponieważ „Te natywne aplikacje to tylko małe czarne pola na stronie internetowej. [...] Naprawdę wierzymy w HTML, i na tym chcemy się skoncentrować”.

Christopher Blizzard z Mozilli skrytykował NaCl, twierdząc, że kod natywny nie może ewoluować w taki sam sposób, jak sieć oparta na kodzie źródłowym. Porównał także NaCl do technologii Microsoft ActiveX , nękanej przez DLL Hell .

Håkon Wium Lie , dyrektor ds. technologii w Operze, uważa, że ​​„NaCl wydaje się 'tęsknić za starymi, złymi czasami, przed internetem'” i że „klient natywny polega na budowaniu nowej platformy – lub przenoszeniu starej platformy do sieci”. ..] przyniesie złożoność i problemy z bezpieczeństwem, a także odciągnie uwagę od platformy internetowej”.

Drugie pokolenie

Druga generacja sandboxingu opracowana w Google to gVisor . Ma on na celu zastąpienie NaCl w Google Cloud , a dokładniej w Google App Engine . Google promuje również WebAssembly .

Zobacz też

Bibliografia

Zewnętrzne linki

Przykłady