ArrayBuffer, TypedArray и DataView

Я никогда глубоко не работала с бинарными данными в JavaScript. Какое-то время назад стало интересно, что же там есть, как оно работает и для чего используется. Дальше будет мой микроконспект, а также некоторые интересные нюансы работы «под капотом».

ArrayBuffer — это основа всего, просто кусок сырой памяти. Однако работать с ним напрямую нельзя. Для этого существуют TypedArray. Это набор вьюшек поверх ArrayBuffer с конкретной интерпретацией байтов, например:

const buf = new ArrayBuffer(16);
const i32 = new Int32Array(buf);   // 4 элемента по 4 байта
const u8  = new Uint8Array(buf);   // 16 элементов по 1 байту

Здесь команда new ArrayBuffer(16) выделяет непрерывную область памяти размером 16 байт и заполняет её нулями, а обе вьюшки смотрят на одну и ту же память.

Доступных вьюшек много, вот они: Int8Array, Uint8Array, Uint8ClampedArray, Int16Array, Uint16Array, Int32Array, Uint32Array, Float32Array, Float64Array, BigInt64Array, BigUint64Array. По факту все они позволяют отобразить выделенную память в числа разного диапазона и количества байт.

Есть ещё DataView, который позволяет читать разные типы с произвольных смещений:

let dataView = new DataView(buf);
dataView.getUint8(0); // получим 8-битное число на позиции 0
dataView.getUint32(0) // получим 32-битное число на позиции 0
dataView.setUint32(0, 0); // установим 4-байтовое число в 0 на позиции 0

Что происходит под капотом? Из интересного, сырые байты ArrayBuffer, если он больше 64 байт, V8 хранит за пределами кучи. Давайте разберём этот механизм подробнее.

Когда вы создаёте new ArrayBuffer(1024), V8 внутри себя создаёт два объекта:

  1. JS-объект ArrayBuffer — живёт в куче, участвует в сборке мусора
  2. BackingStore — обёртка вокруг указателя на реальный блок памяти

BackingStore знает три вещи: указатель на данные, размер и как эту память освободить. Когда ArrayBuffer собирается GC, BackingStore вызывает деаллокатор внутри V8.

Для маленьких ArrayBuffer (≤ 64 байт) V8 может хранить данные прямо внутри JS-объекта в куче. BackingStore как структура формально существует, но отдельной аллокации памяти за ним нет.

С одной стороны, если бы ArrayBuffer всегда лежал внутри кучи, то память быстрее бы аллоцировалась. Однако V8 не держит большие буфферы там, потому что для использования в postMessage(arrayBuffer) разработчики ожидают zero-copy передачу, которую нельзя позволить из соображений безопасности, если ArrayBuffer хранится в куче. Обсуждение этого можно почитать тут.

И ещё один факт, если вы помните про ElementKinds из моей статьи про V8, то там мы разбирали базовые типы элементов, которые используются чаще всего.

Elements Kinds — внутренние категории V8, определяющие, как именно хранятся элементы массива в памяти и как к ним обращаться.

Однако для TypedArray у движка есть отдельные ElementKinds, причём каждый тип (Int8Array, Float64Array и т.д.) — это отдельный ElementKinds. Всё потому, что для TypedArray тип всегда зафиксирован при создании, в то время как для обычных массивов типы могут меняться в рантайме.

Buffer в Node.js

Buffer — это Node.js-специфичная вещь, в браузере его нет. Технически он наследуется от Uint8Array, то есть это тот же TypedArray, но с дополнительными методами для удобной работы со строками и файлами:

const b = Buffer.from('hello', 'utf8');
b.toString('hex'); // '68656c6c6f'

У Buffer есть три статических метода для аллокации, и они работают принципиально по-разному.

Buffer.alloc(size) — безопасный вариант. Создаёт отдельный ArrayBuffer нужного размера, память заполняется нулями. Пул не используется.

Buffer.alloc(8); // <Buffer 00 00 00 00 00 00 00 00>

Buffer.allocUnsafe(size) — быстрый вариант. Память не обнуляется, в буфере могут быть остатки старых данных. Но самое интересное — это то, как он выделяет память.

Buffer.allocUnsafeSlow(size) — как allocUnsafe, но всегда создаёт отдельный ArrayBuffer, без пула. Зачем — объясню ниже.

Когда вы вызываете Buffer.allocUnsafe(100), Node.js не идёт каждый раз просить систему выделить 100 байт. Вместо этого он заранее выделяет один большой кусок памяти на 8 КБ (пул) и нарезает от него маленькие буферы.

Если запрошенный размер меньше 4096 байт (половина от размера всего пула), Node.js просто двигает указатель внутри пула и создаёт новый view на уже существующий ArrayBuffer. Новой аллокации памяти нет, поэтому это очень быстро.

Если в текущем пуле не хватает места — создаётся новый. Если запрошенный буфер слишком большой (≥ 4096) — пул не используется, создаётся отдельный ArrayBuffer.

Порог в половину пула выбран не случайно: если буфер занимает больше половины, он съест почти весь пул, а оставшийся хвост станет бесполезным.

После каждой нарезки poolOffset выравнивается до границы в 8 байт. Это нужно для производительности: невыровненный доступ к памяти на некоторых архитектурах медленнее.

Все маленькие буферы, нарезанные из одного пула, разделяют один ArrayBuffer. Это значит: пока хотя бы один такой буфер жив, все 8 КБ пула не могут быть собраны GC.

Именно для этого существует Buffer.allocUnsafeSlow(size) — он всегда создаёт отдельный ArrayBuffer. Если вы создаёте много маленьких буферов и удерживаете их надолго (кешируете, складываете в массив), allocUnsafeSlow может быть экономичнее по памяти.

SharedArrayBuffer и история с Spectre

Отдельного разговора заслуживает SharedArrayBuffer и история с его отключением во всех браузерах.

SharedArrayBuffer — почти то же самое, что ArrayBuffer, но с одним принципиальным отличием: его можно передать в несколько Web Workers одновременно, и все они будут работать с одной и той же памятью.

const sab = new SharedArrayBuffer(256);
worker.postMessage(sab); // worker получает доступ к той же памяти

С обычным ArrayBuffer при передаче через postMessage происходит transfer — оригинал становится недоступным, а получатель получает владение. Это сделано намеренно: два потока не должны одновременно писать в одну память без синхронизации. SharedArrayBuffer снимает это ограничение — но тогда синхронизацию нужно делать самостоятельно. Для этого существует объект Atomics. Он предоставляет атомарные операции — гарантированно неделимые чтение-запись:

const sab = new SharedArrayBuffer(4);
const view = new Int32Array(sab);

// В воркере 1:
Atomics.add(view, 0, 1); // атомарный инкремент

// В воркере 2:
Atomics.load(view, 0);   // атомарное чтение

Без Atomics параллельная запись в SharedArrayBuffer приводит к data race — результат непредсказуем. Atomics.add, Atomics.load и другие методы гарантируют, что операция выполнится целиком, без прерывания другим потоком.

Есть и механизм ожидания: Atomics.wait(view, index, expectedValue) блокирует поток, пока значение по индексу равно ожидаемому. Atomics.notify(view, index) будит ждущие потоки.

У SharedArrayBuffer непростая история. В начале 2018 года его отключили во всех браузерах — Chrome, Firefox, Safari, Edge — одновременно. Причина: атака Spectre. Чтобы понять, при чём тут SharedArrayBuffer, нужно разобрать саму атаку — она на самом деле довольно изящная.

Современные процессоры не ждут, пока проверится условие if — они предсказывают результат и выполняют код «наперёд». Если предсказание верное — результат уже готов. Если нет — процессор откатывает результат. Но есть нюанс: данные, которые попали в кеш процессора во время спекуляции, остаются там даже после отката.

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

Шаг 1: атакующий много раз вызывает код с валидным индексом. Предсказатель ветвлений запоминает: «условие всегда true».

Шаг 2: атакующий подаёт индекс, который выходит за границу массива и указывает на секретный байт. Процессор по привычке предсказывает «true» и спекулятивно читает секрет — допустим, значение 42.

Шаг 3: спекулятивный код использует прочитанное значение как индекс в другом массиве — probeArray[42 * 256]. Эта ячейка попадает в кеш. Потом процессор понимает, что условие было false, и откатывает всё. Но кеш не откатывается.

Шаг 4: атакующий перебирает все 256 возможных значений, обращаясь к probeArray[0 * 256], probeArray[1 * 256], …, probeArray[255 * 256], и замеряет время каждого обращения. Одна ячейка отвечает за ~3 наносекунды (из кеша), все остальные — за ~100 наносекунд (из оперативной памяти). Быстрая ячейка выдаёт значение секрета: 42.

Секрет утёк не напрямую, а через побочный канал: значение было использовано как индекс в массиве и он оставил физический след в кеше.

Вся атака стоит на способности различить «3 наносекунды» и «100 наносекунд». Для этого нужен очень точный таймер. performance.now() давал точность ~5 микросекунд — это всё ещё достаточно грубо. А SharedArrayBuffer позволяет собрать самодельный наносекундный таймер буквально в пять строк:

// Воркер-таймер:
const counter = new Uint32Array(sharedBuffer);
while (true) {
  counter[0]++;
}

// Основной поток:
const start = counter[0];
// ... замеряем что-то ...
const elapsed = counter[0] - start;

Один воркер крутит счётчик в бесконечном цикле, другой поток читает его до и после интересующей операции. Разница — время выполнения с точностью вплоть до наносекунд. Этого достаточно, чтобы отличить попадание в кеш от промаха, а значит — достаточно для Spectre.

Сам по себе SharedArrayBuffer не опасен. Опасна возможность построить на нём таймер, который «видит» побочные эффекты спекулятивного выполнения. Именно поэтому браузеры отреагировали двумя мерами: снизили точность performance.now() (например, в Chrome — с 5 до 100 микросекунд) и полностью отключили SharedArrayBuffer.

SharedArrayBuffer вернули, но только для страниц, которые изолированы от остальных. Для этого сервер должен отдавать два HTTP-заголовка:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

COOP: same-origin означает, что страница отказывается от возможности иметь ссылки на окна другого origin (попапы, window.opener). COEP: require-corp означает, что все ресурсы (картинки, скрипты, iframe), загружаемые страницей, должны явно разрешить использование через Cross-Origin-Resource-Policy.

Зачем это нужно? Суть защиты от Spectre — изоляция процессов. Chrome начал изолировать сайты в отдельные процессы ещё в 2018 году. Но без COOP/COEP страница всё ещё может загрузить cross-origin ресурс (картинку, API-ответ) в свой процесс. А если данные другого сайта попали в ваш процесс — Spectre может их прочитать.

COOP/COEP гарантируют, что в процесс попадают только ресурсы, которые явно дали на это согласие. После этого SharedArrayBuffer можно безопасно включить — его таймер может читать только данные из того же (изолированного) процесса.

Проверить, изолирована ли страница, можно так:

if (crossOriginIsolated) {
  const sab = new SharedArrayBuffer(1024);
  // ...
}

Blob

Blob (Binary Large Object) — это иммутабельный объект с сырыми данными и MIME-типом. В отличие от ArrayBuffer, он не даёт прямого доступа к байтам — только асинхронно, через конвертацию:

const blob = new Blob(['<h1>Hi</h1>'], { type: 'text/html' });
const text = await blob.text();
const buf  = await blob.arrayBuffer();

File, который возвращает <input type="file">, наследуется от Blob.

Где Blob хранит данные? Из документации Chromium по blob storage system: данные Blob создаются в процессе рендерера, где JS-код исполняется. Затем они передаются в процесс браузера. Подробнее про процессы можно почитать в моей статье. Если в памяти достаточно квоты — данные хранятся в RAM. Если квота заканчивается или Blob слишком большой, то браузер переносит данные на диск. Вот почему чтение из Blob асинхронное — браузер может возвращать данные с диска. Это также объясняет, почему он иммутабельный: если данные на диске, мутабельность потребовала бы файловой синхронизации, что сильно усложнило бы реализацию.

blob.slice(start, end) не копирует данные, а создаёт новый Blob, который является view на часть существующего. Под капотом хранится ссылка на оригинальный Blob плюс смещение и длина.

const huge = new Blob([bigData]); // 100 МБ
const chunk = huge.slice(0, 1024); // view на первые 1 КБ, без копирования

Есть обратная сторона: пока chunk жив, huge (и все его 100 МБ) не могут быть освобождены. Похожая ситуация с памятью может возникнуть и при создании URL на Blob.

const url = URL.createObjectURL(blob);
// url → "blob:https://example.com/550e8400-e29b-..."
img.src = url;

Браузер внутри себя создаёт маппинг URL → Blob и удерживает Blob в памяти. Этот маппинг живёт, пока вы не вызовете URL.revokeObjectURL(url) или пока не закроется документ.

TextEncoder и TextDecoder

Остались ещё TextEncoder и TextDecoder — пара, которая переводит строки в байты и обратно.

API у них достаточно простое: у одного есть encode(), у другого decode(). Однако своих нюансов в их работу добавляет то, что строки в JavaScript хранятся в UTF-16, а данные вокруг (файлы, сеть и т.д.) почти всегда в UTF-8. Поэтому TextEncoder умеет кодировать только в UTF-8, и других вариантов у него нет, а вот TextDecoder принимает десятки кодировок.

Дальше начинаются суррогатные пары. Символы выше U+FFFF (эмодзи, редкие иероглифы, некоторые математические знаки) не помещаются в один 16-битный код и хранятся как два. Отдельного внимания заслуживает случай, когда суррогат остался без пары, например, строку обрезали ровно посередине символа. Тогда TextEncoder заменит его на U+FFFD (тот самый знаменитый �) и не выбросит никакого исключения.

Дело в том, что в спецификации encode() принимает USVString — строку, в которой суррогатов не бывает по определению. Обычные JS-строки — это DOMString, и при передаче аргумента происходит конвертация одного в другое, при которой каждый одинокий суррогат и заменяется. Таким образом до самого кодировщика битая строка уже не доходит.

Похожая тихая механика, без всяких ошибок, есть и у BOM — метки порядка байтов U+FEFF, которую любят добавлять в начало файла редакторы под Windows. По умолчанию TextDecoder её срезает, и в результирующей строке она не появляется. Опция ignoreBOM работает противоположно тому, что можно предположить по названию: она означает не «игнорировать метку», а «не обрабатывать её специальным образом», то есть оставить в строке как обычный символ.

Последний нюанс касается потокового чтения. Если данные приходят чанками, многобайтовый символ вполне может оказаться разрезанным на границе. Стандартный вызов декодера посчитает такую последовательность некорректной и выдаст всё тот же символ �. Однако если передать { stream: true }, то декодер сохранит незавершённый хвост до следующего вызова, а финальный decode() без аргументов сбросит остаток.

const decoder = new TextDecoder();
decoder.decode(chunk, { stream: true });
decoder.decode();

Заметка собрана из постов в Telegram-канале @startpoint_dev: первый, второй, третий, четвёртый, пятый, шестой.