41. archive/zip, tar и работа с архивами

Философия потоковой обработки и структура архивов

В компьютерных системах упаковка данных — одна из старейших задач. Еще на заре эпохи Unix возникла потребность объединять разрозненные файлы, права доступа и структуру каталогов в единый линейный поток данных для резервного копирования и транспортировки.

Здесь принципиально важно провести четкую границу между двумя концепциями, которые начинающие программисты нередко смешивают в одно понятие:

• Архивация (Контейнеризация): упаковка множества файлов, путей, прав доступа и временных меток в единую структуру данных (форматы TAR, cpio, не сжатый ZIP). За это в стандартной библиотеке Go отвечает ветка пакетов archive/.
• Компрессия (Сжатие данных): математическое устранение энтропийной избыточности в потоке байтов (алгоритмы flate / Deflate, gzip, bzip2, zlib). За это отвечает семейство пакетов compress/.

Архив может быть сжатым (как классический .tar.gz) или несжатым (простой .tar или .zip со стратегией Store). Go бескомпромиссно разделяет эти домены: пакеты archive/zip и archive/tar ничего не знают о сетевых протоколах и низкоуровневых сокетах, они работают исключительно через фундаментальные абстракции io.Reader и io.Writer.

Для бэкенд-инженера высокого уровня работа с архивами — это прежде всего искусство управления памятью и жесткий контроль безопасности:

1. Защита от исчерпания памяти (OOM): Наивная загрузка архива в память через os.ReadFile или вызов zip.Reader.File[i].Open() без лимитов размера неминуемо приведет к падению сервера при первой же атаке типа ZIP-бомба или распаковке стогигабайтного лога.
2. Безопасность файловой системы: Распаковка архива «вслепую» — один из самых частых источников критических уязвимостей типа Path Traversal (Zip Slip) и атак через символические ссылки (Symlink Traversal).

Идиоматичный подход в Go опирается на строгую потоковую обработку, поточные интерфейсы io.Copy / io.CopyN, ленивый парсинг метаданных и бескомпромиссную санитаризацию путей.

Under the hood: ZIP против TAR

Внутренняя компоновка форматов ZIP и TAR кардинально различается. Это фундаментальное архитектурное различие определяет, как и где вы можете применять каждый из них.

ZIP: Центральная директория и произвольный доступ

Формат ZIP создавался во времена персональных компьютеров, когда файлы хранились на дискетах и жестких дисках с поддержкой произвольного позиционирования головки (random access).

Его структура состоит из двух ключевых частей:

1. Local File Header + Data: блоки файлов, каждый из которых содержит локальный мини-заголовок и тело файла.
2. Central Directory (Центральная директория): оглавление архива, которое физически записывается в самом конце файла! В ней хранится полный перечень всех файлов, их атрибуты, контрольные суммы CRC32 и байтовые смещения (offsets) к соответствующим Local Header.

Именно поэтому конструктор zip.NewReader принимает интерфейс io.ReaderAt (обычно реализуемый дескриптором *os.File), а не обычный io.Reader. Чтобы узнать состав архива, archive/zip не читает архив с первого байта — он прыгает (seek) в самый конец файла, считывает Central Directory, мгновенно строит легковесный индекс в оперативной памяти и предоставляет доступ к любому файлу за $O(1)$. При вызове f.Open() происходит мгновенный seek к смещению нужного файла и начинается потоковая декомпрессия.

TAR: Последовательный конкатенированный поток

Формат TAR (буквально Tape Archive) проектировался в Bell Labs для стримеров на магнитных лентах. На магнитной ленте нельзя быстро прыгнуть в конец файла: перемотка ленты занимала минуты. Поэтому TAR — это строго линейный, последовательный поток:

1. Header (512 байт): структурированный блок метаданных (имя, права os.FileMode, владелец, размер в байтах Size), строго выровненный по границе 512 байт.
2. File Data: содержимое файла, дополненное нулями (zero padding) до ближайшей границы, кратной 512 байтам.
3. EOF Marker: в конце архива следуют два последовательных пустых блока по 512 нулевых байт, сигнализирующих о завершении архива (io.EOF).

Пакет archive/tar читает данные строго последовательно от начала к концу. Ему не нужен произвольный доступ io.ReaderAt, он работает с абсолютно любым потоком io.Reader — сокетом net.Conn, пайпом io.Pipe или телом входящего HTTP-запроса http.Request.Body.

flowchart LR
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    A["Вызов tar.NewReader"]:::process --> B["Чтение 512 байт<br>Парсинг заголовка"]
    B --> C{"Имя файла валидно<br>и нет угрозы Traversal?"}
    C -->|"Да"| D["Чтение Data<br>до size из заголовка"]
    D --> E["Пропуск нулевого паддинга<br>до границы 512"]
    E --> F{"Следующий блок<br>не нулевой?"}
    F -->|"Да"| B
    F -->|"Нет"| G["Конец архива<br>EOF"]

    H["Вызов zip.NewReader"]:::process --> I["Seek в конец файла<br>Чтение Central Directory"]
    I --> J["Построение индекса в RAM"]
    J --> K["Возврат списка файлов"]
    K --> L["Открытие конкретного файла<br>Seek к Local Header"]
  

Mechanical Sympathy: Потоки, выравнивание и защита от OOM

Работа с архивами напрямую упирается в системные вызовы ядра Linux, дисковый ввод-вывод и работу сборщика мусора.

1. Аллокации и давление на GC

Каждый файл в архиве TAR или ZIP сопровождается структурой заголовка (tar.Header, zip.FileHeader). Если архив содержит миллионы небольших файлов (например, дамп репозитория кода или кэш зависимостей), создание объектов на каждый файл генерирует миллионы мелких структур в куче, создавая существенный GC pressure.

• Оптимизация: Никогда не складывайте заголовки всех файлов архива в гигантский слайс []*tar.Header. Обрабатывайте файлы строго итеративно в цикле, не удерживая ссылки на прочитанные заголовки, чтобы сборщик мог их утилизировать.

2. Выравнивание и syscall

В формате TAR все блоки выровнены по 512 байт. Если читать или распаковывать файлы прямыми вызовами Read() и Write() небольшими порциями без буферизации, приложение будет совершать тысячи мелких syscall write. Каждый переход между User Space и Kernel Space стоит процессорных тактов.

• Решение: Всегда оборачивайте входящий поток tar.NewReader в bufio.Reader, а целевые файлы при записи — в bufio.Writer. Это амортизирует стоимость переходов в Kernel Space и агрегирует мелкие операции в большие блочные вызовы размером 4–64 КБ, идеально согласующиеся с размером страницы виртуальной памяти и дискового кэша ОС.

3. Защита от ZIP-бомб и Path Traversal

• ZIP/TAR-бомба: Архив размером всего в пару мегабайт (например, рекурсивно сжатые нули) при декомпрессии может развернуться в терабайты данных (гигантский UncompressedSize). Если распаковывать поток через слепой io.Copy(f, tr), сервер моментально исчерпает свободное место на диске или вылетит по OOM. Идиоматичная защита — использование io.CopyN с жестким ограничением максимального количества байтов или обертка через io.LimitReader.
• Уязвимость Path Traversal (Zip Slip): Злоумышленник может поместить в архив файл с именем ../../../etc/passwd или ../../../../home/app/.ssh/authorized_keys. Стандартные пакеты Go намеренно низкоуровневые: они не фильтруют пути автоматически. Защита от этой уязвимости — прямая обязанность разработчика!

Идиомы производства: Безопасное создание и извлечение

Безопасное извлечение TAR

Ниже приведен эталонный промышленный паттерн распаковки архива TAR с тройной защитой: от Path Traversal, от подмены символических ссылок и от архивов-бомб:

package main

import (
    "archive/tar"
    "context"
    "errors"
    "fmt"
    "io"
    "os"
    "path/filepath"
    "strings"
)

// extractTar безопасно распаковывает поток TAR в целевую директорию destDir
func extractTar(ctx context.Context, r io.Reader, destDir string) error {
    tr := tar.NewReader(r)
    cleanDestDir := filepath.Clean(destDir)

    for {
        // Проверяем отмену контекста между файлами
        if err := ctx.Err(); err != nil {
            return err
        }

        header, err := tr.Next()
        if errors.Is(err, io.EOF) {
            break // Штатное завершение архива
        }
        if err != nil {
            return fmt.Errorf("tar next: %w", err)
        }

        // 1. Защита от Path Traversal (Zip Slip)
        target := filepath.Join(cleanDestDir, header.Name)
        cleanTarget := filepath.Clean(target)
        if !strings.HasPrefix(cleanTarget, cleanDestDir+string(filepath.Separator)) && cleanTarget != cleanDestDir {
            return errors.New("tar: illegal path traversal detected")
        }

        // 2. Защита от Symlink атак (запрет создания ссылок, ведущих наружу destDir)
        if header.Typeflag == tar.TypeSymlink || header.Typeflag == tar.TypeLink {
            return errors.New("tar: symlinks are not allowed for security reasons")
        }

        switch header.Typeflag {
        case tar.TypeDir:
            // Создаем директорию с маскировкой прав (безопасный umask)
            mode := os.FileMode(header.Mode & 0777)
            if err := os.MkdirAll(cleanTarget, mode); err != nil {
                return fmt.Errorf("mkdir: %w", err)
            }

        case tar.TypeReg:
            // Гарантируем существование родительской папки
            if err := os.MkdirAll(filepath.Dir(cleanTarget), 0755); err != nil {
                return fmt.Errorf("mkdir parent: %w", err)
            }

            // Открываем файл на запись без следования внешним ссылкам
            mode := os.FileMode(header.Mode & 0777)
            f, err := os.OpenFile(cleanTarget, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, mode)
            if err != nil {
                return fmt.Errorf("open file: %w", err)
            }

            // 3. Защита от архивов-бомб: читаем строго header.Size байт через io.CopyN
            if _, err := io.CopyN(f, tr, header.Size); err != nil {
                f.Close()
                return fmt.Errorf("copy file: %w", err)
            }
            f.Close()
        }
    }
    return nil
}

Создание ZIP в память или поток

При создании ZIP-архива критически важно понимать жизненный цикл структуры zip.Writer:

package main

import (
    "archive/zip"
    "fmt"
    "io"
)

// createZip упаковывает файлы в переданный io.Writer (сеть, файл или буфер)
func createZip(w io.Writer, files map[string][]byte) error {
    zw := zip.NewWriter(w)
    // defer гарантирует запись финальной оглавляющей секции Central Directory!
    defer zw.Close()

    for name, data := range files {
        // fw возвращает io.Writer для потоковой записи данных файла
        fw, err := zw.Create(name)
        if err != nil {
            return fmt.Errorf("create zip entry: %w", err)
        }

        if _, err := fw.Write(data); err != nil {
            return fmt.Errorf("write data: %w", err)
        }
    }

    // Явный вызов zw.Close() необходим, если мы хотим проверить ошибку записи Central Directory
    if err := zw.Close(); err != nil {
        return fmt.Errorf("close zip writer: %w", err)
    }
    return nil
}

Ловушки и вопросы с собеседований

Сравнение с экосистемами других языков

Итог

1. Формат archive/zip требует произвольного доступа через io.ReaderAt для чтения оглавления Central Directory в хвосте архива. Формат archive/tar работает строго потоково через любой io.Reader.
2. Никогда не читайте архив целиком в оперативную память. Используйте потоковую обработку через io.Copy, io.CopyN и итераторы tar.Reader / zip.Reader.
3. При распаковке в production безусловно проверяйте пути на уязвимость Path Traversal (Zip Slip) с помощью filepath.Clean и filepath.Join, а также блокируйте подозрительные символические ссылки (tar.TypeSymlink).
4. Защищайтесь от архивов-бомб: всегда строго ограничивайте объем вычитываемых байт через header.Size или io.LimitReader.
5. При формировании ZIP-архива всегда явно закрывайте zip.Writer методом Close(), чтобы записать финальную секцию Central Directory.
6. Разделяйте концептуальные слои: пакеты archive/ отвечают за структуру контейнера и метаданные, а пакеты compress/ — за математическое сжатие байтов.

Разобрав контейнерные форматы, мы переходим к алгоритмам сжатия, которые экономят место на диске и полосу пропускания сети. Как работают DEFLATE, ZLIB и GZIP под капотом, почему они используют скользящее окно и как интегрировать их в HTTP-потоки без лишних аллокаций? В следующей статье: 42. compress/gzip, zlib, flate.