HTTP通信データの圧縮アルゴリズムについて

背景

脆弱性診断において大量のHTTP通信データが生成されます。
そのため診断ではHTTP通信データをいかに小さくし、アーカイブ等の運用面でのコストを削減するかという工夫が必要になります。
現状、gzipやbizp2などを使用し圧縮して保管していますが、最近ではwebコンテンツ向けの圧縮アルゴリズム、つまりHTTP通信を圧縮することに適したアルゴリズムが開発されています。
よりよい圧縮率を求めて圧縮アルゴリズムを調査しました。

調査の概要

まず現状のgzip圧縮の圧縮率を調査し、現状把握とします。
次にgzip以外の3つの圧縮アルゴリズムの候補と比較します。
圧縮アルゴリズムの候補はbzip2、brotli、zstandardです。
今回は圧縮率と圧縮にかかる時間について比較しました。
gzipとbzip2はともに汎用的に使うために開発された圧縮アルゴリズムですが、brotliとzstandardはwebコンテンツ向けに開発された圧縮アルゴリズムです。

• https://github.com/google/brotli
• https://facebook.github.io/zstd/

調査の詳細

使用したデータセットは以下のようになっています。

今回のデータセットは1つの診断案件の中に6つのセッション（1つの診断対象リクエストについてクロール～スキャンまでを行う単位）があり、その中にクロールやスキャン時のHTTP通信が含まれています。
セッションごと通信内容の特徴は以下の通りです。

現状はHTTPリクエスト1つにつき1ファイル、HTTPレスポンス1つにつき1ファイルずつgzipで圧縮しています。

今回の調査で使用した環境について説明します。

• OS：Windows 11
• Java：21.0.5
• 使用したJavaライブラリ：
  • brotli4j 1.17.0
    • https://github.com/hyperxpro/Brotli4j
  • bzip2 0.9.1
    • https://code.google.com/archive/p/jbzip2/
  • zstd-jni 1.5.6-4
    • https://github.com/luben/zstd-jni

作成したコード：
圧縮

public static void show(final File srcDir, final Path destDirPath) throws IOException {
   System.out.println("## " + srcDir + " -> " + destDirPath);
   for (File f : srcDir.listFiles()) {
       if (f.isDirectory()) {
           final File nextSrcDir = f.getAbsoluteFile();
           final Path nextDestDirPath = Paths.get(destDirPath.toString(), f.getName());
           Files.createDirectory(nextDestDirPath);
           show(nextSrcDir, nextDestDirPath);
       } else {
           if (f.toString().contains("_")) {
               continue;
           }
           final Path zipFilePath = destDirPath.resolve(f.getName() + ".gz");
           try (
                   InputStream is = Files.newInputStream(f.toPath());
                   GZIPOutputStream bos = new GZIPOutputStream(Files.newOutputStream(zipFilePath, StandardOpenOption.CREATE,
                           StandardOpenOption.TRUNCATE_EXISTING, StandardOpenOption.WRITE))) {
               is.transferTo(bos);
           }
       }
   }
}

展開

public static void show(final File srcDir, final Path destDirPath) throws IOException {
   System.out.println("## " + srcDir + " -> " + destDirPath);
   for (File f : srcDir.listFiles()) {
       if (f.isDirectory()) {
           final File nextSrcDir = f.getAbsoluteFile();
           final Path nextDestDirPath = Paths.get(destDirPath.toString(), f.getName());
           Files.createDirectory(nextDestDirPath);
           show(nextSrcDir, nextDestDirPath);
       } else {
           if (!f.toString().endsWith(".gz")) {
               continue;
           }
           final Path ungzipFilePath = destDirPath.resolve(f.getName().replace(".gz", ""));
           try (
                   GZIPInputStream gis = new GZIPInputStream(Files.newInputStream(f.toPath()));
                   OutputStream os = Files.newOutputStream(ungzipFilePath, StandardOpenOption.CREATE,
                           StandardOpenOption.TRUNCATE_EXISTING, StandardOpenOption.WRITE);) {
               gis.transferTo(os);
           }
       }
   }
}

調査結果

ファイル単位での圧縮

セッション単位での圧縮

圧縮する単位による違い

所要時間

圧縮率はgzip > bzip2 >>> brotli, zstandard という印象でした。
圧縮にかかる時間はbrotli > bzip2 > gzip > zstandard、
解凍にかかる時間はbzip2 > gzip > zstandard > brotliとなりましたが、数回の計測なので作業環境等により変わる可能性があります。

まとめ

圧縮率はやはりwebコンテンツ向けの2つが目立つ結果となりました。
圧縮時間はbrotliが異常なほど時間がかかりましたが、tarでアーカイブして圧縮する回数を減らすことで時間短縮になりました。
圧縮率に差が出た要因として、同じ要素が多く含まれるものだとまとめて圧縮できるそうなのでファイル単位よりフォルダ単位で大きく圧縮するほうが圧縮率が高くなりました。
圧縮時間はbrotliが長かったため原因追跡までできればなおよかったと思いました。
調べた限りではセキュリティ対策ソフトが原因のことがあるようです。