모든 브라우저는 gzip을 자동으로 해제할 수 있는가?

(개인의 생각이 포함된 글입니다)

 

웹 기반의 서비스의 성능을 최적화 하는 방법에는 무엇이 있을까?

 

우선 본인이 시도했던 것은 다음과 같다.

• 번들 크기 줄이기
• 코드 스플리팅
• 이미지 최적화(webp를 사용)
• 기타

그렇다면 위에서 했던 다양한 방법들의 궁극적인 목표는 무엇일까?

 

프로그램에 사용되지 않는 코드를 제외하고 각 페이지에서 필요한 코드만 가져올 수 있도록 lazy loading을 적용하거나 차세대 이미지 형식인 webp를 사용하여 이미지의 해상도를 유지하며 용량을 줄이는 방법 모두 전송되는 데이터의 크기를 감소시키는데 목표를 두고 있다.

 

최적화의 목표?

앞서 최적화 중 일부는 더 작은 데이터 크기를 만드는 것을 목표로 하고 있는 것을 확인했다.

 

그렇다면 더 작은 데이터가 의미하는 것은 무엇일까?

 

더 작은 데이터 = 더 빠른 전송 = 더 좋은 사용자 경험을 의미할 것이다.

 

이렇듯 더 작은 데이터는 결국 더 좋은 사용자 경험을 제공하기 위한 좋은 방법이 되는 것이다.

 

그래서 어쩌라고?

gzip에 관한 글인데 왜 최적화 이야기만 하는가?

 

얼마 전 개인적으로 프로젝트를 진행하던 중 신기한 현상을 발견했다.

(물론 당시의 본인 기준이므로 사람에 따라 당연한 내용일 수도 있습니다)

 

당시 아래와 같은 상황이었다.

• 모바일 웹뷰 서비스
• 별도의 서버를 만들고 싶지 않음
• 공공데이터

여기서 공공데이터 포털을 통해 받아온 데이터를 저장하는 과정에서 다음과 같은 생각을 했다.

 

이 서비스에서 별도의 서버를 만들고 싶지 않았으며 (유지비 + 서버 관리를 위한 코드 등)  공공데이터 포털의 API 월별 호출 횟수 제한이 있기 때문에 이를 프론트엔드 코드에 직접 넣고 싶었다.

 

리액트 프로젝트의 경우 public 디렉토리 하위에 정적 리소스를 넣을 수 있었으며 vercel 또는 gitbub pages를 사용한다면 이 정적 리소스를 함께 업로드 할 수 있을 것이라 생각했다.

 

그러던 중 아래와 같은 문제가 발생했다.

전체 json 파일의 개수는 2800개 였으며 이 모든 파일의 용량은 1.17GB를 차지했다.

 

이 데이터들을 vercel 또는 github pages에 업로드 하기에도 무리가 있다고 생각했다.

 

그러던 중 예전 vite를 사용할 때 gzip이라는 키워드를 볼 수 있었으며 이를 활용하면 용량을 줄일 수 있을 것으로 기대했다.

 

결과

용량은 줄었으며 vercel에 업로드 할 수 있었다.

 

데이터가 준비 되었으며 업로드가 성공적인 것을 확인했으니 public에 있는 정적 리소스를 잘 가져오는지 확인하고자 했다.

 

그런데 브라우저에서 압축과 관련된 문제가 발생하지 않고 데이터의 압축이 자동으로 해제된 것 처럼 보였다.

 

분명 확장자에는 .gz라고 쓰여있지만 네트워크 탭에서 압축된 데이터를 읽을 수 있으며 이 데이터를 그대로 사용하는데 문제가 없었다.

 

이 데이터는 .gz 확장자를 갖는 압축된 파일이지만 브라우저에서 그대로 사용할 수 있었으며 이것이 가능한 이유가 무엇인지 궁금했다.

 

또한, 프론트엔드 영역의 최적화 기법중 gzip 압축을 통한 용량을 감소시키는 경우도 있으니 이에 대해 궁금했다.

 

현재 본인은 크롬을 사용하고 있으며 크롬에서만 저 기능이 작동하는 것인지, 모든 브라우저에서 저 동작이 기본으로 지원되는 것인지 알아보기로 했다.

gzip?

https://www.gzip.org/

The gzip home page

gzip is a single-file/stream lossless data compression utility, where the resulting compressed file generally has the suffix .gz.
gzip also refers to the associated compressed data format used by the utility.

gzip은 단일 파일/스트림 무손실 데이터 압축 유틸리티로, 결과 압축 파일에는 일반적으로 .gz라는 접미사가 붙습니다.
gzip은 유틸리티에서 사용하는 관련 압축 데이터 형식을 의미하기도 합니다.

 

gzip 공식 문서에서 gzip은 데이터 압축 유틸리티라고 한다.

 

이 글은 gzip에 관한 구조나 알고리즘을 다루지 않을 예정이기에(추후 기회가 된다면 다시 다루도록 하겠다) 아래 문서들을 참고해 gzip의 구조 또는 특징에 대해 확인하기를 추천한다.

https://old-projects.andromedarabbit.net/src/zip/GzipFileFormat.html

GZIP 파일의 구조

https://products.aspose.com/zip/ko/most-common-archives/what-is-gzip/

GZIP 파일 형식 - 알아야 할 모든 것

 

그렇다면 gzip의 압축 효과는 얼마나 좋을까?

 

위의 데이터를 단순히 gzip으로 압축하는 경우 결과는 아래와 같다.

import { existsSync, mkdirSync, readdir, createReadStream, createWriteStream } from 'fs';
import { createGzip } from 'zlib';
import { resolve, join, extname } from 'path';

// 원본 파일이 있는 디렉토리
const rawDataDirectory = resolve('./rawData');

// 압축된 파일을 저장할 디렉토리
const compressedDataDirectory = resolve('./data');

// 압축된 파일을 저장할 디렉토리가 존재하지 않는 경우 생성
if (!existsSync(compressedDataDirectory)) {
  mkdirSync(compressedDataDirectory);
}

// 파일 목록을 읽어오기
readdir(rawDataDirectory, (err, files) => {
  if (err) {
    console.error('Error reading directory:', err);
    return;
  }

  files.forEach((file) => {
    const filePath = join(rawDataDirectory, file);

    // 파일이 JSON 파일인지 확인
    if (extname(file) === '.json') {
      const gzip = createGzip();
      const input = createReadStream(filePath);
      const output = createWriteStream(join(compressedDataDirectory, `${file}.gz`));

      // 파일을 읽고 gzip으로 압축한 후 저장
      input.pipe(gzip).pipe(output);

      output.on('finish', () => {
        console.log(`Compressed ${filePath} to ${join(compressedDataDirectory, `${file}.gz`)}`);
      });
    }
  });
});

(예제코드)

 

node.js의 내장 모듈을 활용해서 gzip 압축을 할 수 있으며 공식 문서에서 확인한 것과 같이 모든 파일들에 .gz 확장자가 붙은 채로 압축되었다.

 

이렇게 압축된 경우 VSCode를 통해 내용을 확인할 수 없으며 별도의 압축 해제 과정이 필요하다.

 

브라우저는 알아서 해제 하던데요?

이것이 이 글의 핵심이다.

 

나는 gz 데이터를 사용하기 위해 별도의 압축 해제가 필요할 것으로 예상했지만 브라우저는 알아서 이 데이터를 압축 해제 하고 있었다.

 

그렇다면 브라우저는 기본적으로 gzip 압축을 해제하는 기능을 내장하고 있는 것일까?

 

RFC

https://www.ietf.org/process/rfcs/

About RFCs

Software developers, hardware manufacturers, and network operators around the world voluntarily implement and adopt the technical specifications and best practices described by RFCs.

전 세계의 소프트웨어 개발자, 하드웨어 제조업체, 네트워크 운영자는 RFC에서 설명하는 기술 사양과 모범 사례를 자발적으로 구현하고 채택하고 있습니다.

 

RFC는 문서로 쉽게 생각하면 인터넷의 표준 정도 되는 문서다.

 

이 표준을 지키도록 구현함으로써 상호 운용성 보장, 보안 강화, 시스템 신뢰성 향상 등의 이점을 얻을 수 있다.

 

https://datatracker.ietf.org/doc/html/rfc2026

RFC 2026: The Internet Standards Process -- Revision 3

위의 RFC 문서에는 RFC의 목적, 중요성, 표준화 과정 등에 대한 내용등을 담고 있다.

 

주의점

쉽게 생각해서 RFC가 인터넷의 표준을 제시한다고 했지만 실제로 모든 RFC 문서가 인터넷 표준을 의미하지는 않는다.

 

https://datatracker.ietf.org/doc/html/rfc1796

RFC 1796: Not All RFCs are Standards

이 문서의 핵심은 결국 모든 RFC들이 인터넷 표준은 아니라는 것이다.

 

RFC 문서들은 다수의 등급을 가지고 있으며 그 중에서 인터넷 표준으로 선택된 RFC들이 STD라는 새로운 번호를 부여받고 인터넷 표준으로 취급된다.

 

https://www.rfc-editor.org/standards

Official Internet Protocol Standards » RFC Editor

위의 주소에서 STD 번호를 부여받은 RFC 문서들의 목록을 볼 수 있으며 이 문서에 기술된 내용들은 인터넷 표준으로 받아들여지고 있다.

 

혹시 브라우저도?

RFC가 인터넷 표준을 제시하고 개발자 등은 이를 따라야 한다면 브라우저도 이 표준을 따르고 있지는 않을까?

 

우선 gzip에 관한 RFC 문서는 다음과 같다.

https://datatracker.ietf.org/doc/html/rfc1952

RFC 1952: GZIP file format specification version 4.3

 

우선 이 규격의 목적은 다음과 같다.

• 무손실 압축 데이터 포맷을 정의
• CPU 유형, 운영 체제, 파일 시스템, 문자 집합에 독립적이므로 상호 교환에 사용할 수 있습니다.
• 무작위로 액세스할 수 있는 파일이 아닌 데이터 스트림을 압축 또는 압축 해제하여 선험적으로 제한된 양의 중간 저장 공간만 사용하여 다른 데이터 스트림을 생성할 수 있으므로 데이터 통신 또는 Unix 필터와 같은 유사한 구조에 사용할 수 있습니다.
• 현재 사용 가능한 최고의 범용 압축 방법과 비슷한 효율로 데이터를 압축하며, 특히 'compress' 프로그램보다 훨씬 우수합니다.
• 특허의 적용을 받지 않는 방식으로 쉽게 구현할 수 있으므로 자유롭게 실행할 수 있습니다.
• 현재 널리 사용되는 gzip 유틸리티에서 생성된 파일 형식과 호환되며 호환되는 압축 해제 프로그램은 기존 gzip 압축기에서 생성된 데이터를 읽을 수 있습니다.

 

또한, 1.4. Compliance (규정)에는 아래와 같이 명시되어 있다.

 

"아래에 달리 명시되지 않는 한, 호환 압축기는 여기에 제시된 모든 사양을 준수하는 모든 파일을 수용하고 압축을 해제할 수 있어야 하며, 호환 압축기는 여기에 제시된 모든 사양을 준수하는 파일들을 생성해야 합니다"

 

이 문서에 따르면 문서에 정의된 gzip 형식을 수용하고 압축 및 해제를 할 수 있어야 한다.

 

이것은 인터넷 표준을 따르는 브라우저들도 준수해야 할 것이다.

 

gzip과 관련된 STD 문서는?

gzip이 어떤 것인지 알아봤으니 인터넷 표준으로 분류된 문서에서 gzip과 관련된 부분이 있는지 찾아봐야 한다.

 

https://www.rfc-editor.org/rfc/rfc9110.html

RFC 9110: HTTP Semantics

 

STD 97 (RFC 9110) HTTP Semantics 문서에서 이에 관한 내용을 찾을 수 있었다.

 

그 중 8.4. Content-Encoding 섹션을 보면 다음과 같은 문장이 있다.

https://www.rfc-editor.org/rfc/rfc9110.html#section-8.4

RFC 9110: HTTP Semantics

(RFC 7231 3.1.2.2. Content-Encoding과 같은 내용)

 

The "Content-Encoding" header field indicates what content codings have been applied to the representation, beyond those inherent in the media type, and thus what decoding mechanisms have to be applied in order to obtain data in the media type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a representation's data to be compressed without losing the identity of its underlying media type.

"Content-Encoding" 헤더 필드는 미디어 유형에 내재된 것 외에 어떤 콘텐츠 코딩이 표현에 적용되었는지, 따라서 Content-Type 헤더 필드에서 참조하는 미디어 유형의 데이터를 얻기 위해 어떤 디코딩 메커니즘을 적용해야 하는지를 나타냅니다. 콘텐츠 인코딩은 주로 기본 미디어 유형의 정체성을 잃지 않고 표현의 데이터를 압축할 수 있도록 하는 데 사용됩니다.

 

(중략)

 

Unlike Transfer-Encoding (Section 6.1 of [HTTP/1.1]), the codings listed in Content-Encoding are a characteristic of the representation; the representation is defined in terms of the coded form, and all other metadata about the representation is about the coded form unless otherwise noted in the metadata definition. Typically, the representation is only decoded just prior to rendering or analogous usage.

전송-인코딩([HTTP/1.1] 6.1절)과 달리 Content-Encoding에 나열된 코딩은 표현의 특징입니다; 표현은 코딩된 형식의 관점에서 정의되며, 메타데이터 정의에 달리 명시되지 않는 한 표현에 대한 다른 모든 메타데이터는 코딩된 형식에 관한 것입니다. 일반적으로 표현은 렌더링 또는 이와 유사한 사용 직전에만 디코딩됩니다.

 

이 문서를 포함한 다른 문서에서 "반드시 gzip과 같은 압축을 해제해야 한다"라는 문구를 찾을 수는 없었으나 위의 내용을 바탕으로 원하는 답을 얻을 수 있다.

 

콘텐츠 인코딩 = 기본 미디어 유형의 정체성을 잃지 않고 데이터를 압축할 수 있도록 하는 데 사용

Content-Encoding 필드 = 미디어 유형의 데이터를 얻기 위해 어떤 디코딩 메커니즘을 적용해야 하는지 나타냄

디코딩 시점 = 렌더링 또는 이와 유사한 사용 직전에만 디코딩

 

위와 같은 결론을 내릴 수 있을 것으로 보인다.

 

Content-Encoding 필드는 원하는 데이터 압축한 뒤 이 데이터를 디코딩 하기 위해서 어떤 메커니즘을 적용해야 하는지 알려주는 필드이며 이 필드를 참고하여 렌더링과 같이 실제 그 데이터를 사용하는 시점에 정해진 메커니즘으로 디코딩하는 것이다.

 

RFC 문서와 인터넷 표준 문서를 "반드시" 준수해야 하는 것은 아니지만 앞서 언급했듯이 표준을 따르며 다양한 이점이 따라오기 때문에 표준을 준수하는 것이 좋을 것이다.

 

위와 같이 다양한 요소들이 종합되어 브라우저는 gzip의 압축을 자동으로 헤제할 수 있도록 만들어 진 것으로 보인다.

 

실제로 위에서 확인했던 .gz 데이터를 수신할 당시의 헤더는 다음과 같다.

 

위의 내용대로 해석해보면 Content-Type에 해당하는 application/json 파일을 원하고 있으며 이 데이터는 gzip 방식으로 인코딩 되어있다는 것을 알 수 있다.

 

다시 말해 브라우저에서 기대했던 데이터는 json이며 이는 gzip 방식으로 압축되어 있다고 서버에서 응답하는 것이다.

 

브라우저는 자신이 원하는 json을 얻기 위해서는 이를 직접 사용하는 시점(렌더링 등)에 gzip 방식의 디코딩 메커니즘을 사용할 것이다.

 

결론

브라우저가 압축을 해제해야 한다는 명확한 문구는 찾을 수 없었으나 Content-Encoding 필드와 gzip이 관련되어 있다는 것을 알 수 있다.

 

또한, 인터넷 표준이라는 특성상 법적으로 이 표준의 준수가 강제되지 않지만 이를 따르게 되면서 오는 다양한 이점 때문에 이를 준수하고자 노력하고 있을 것이다.

 

결과적으로 현재 운영중인 브라우저들이 모두 웹 표준을 준수하고 있다고 한다면 gzip으로 압축된 데이터가 그 브라우저들에 의해 자동으로 압축이 해제될 것으로 기대해도 될 것으로 보인다.

 

따라서, 서비스 최적화 기법 중 gzip을 사용하더라도 대부분의 브라우저가 이를 자동으로 해제할 수 있음을 기대해도 되는 것이다.