[Tomcat 구현하기] (4) - HTTP Compression (톰캣에서의 구현)

 

 

 

 

🤔 웹 사이트의 속도는 왜 중요한가

웹 사이트의 속도가 빠르다는 것은 사용자에게 응답이 빠른 속도로 제공된다는 것을 의미합니다.

응답이 사용자에게 빠르게 제공되는 만큼 사용자 경험은 좋아질 것이고, 이를 통해 사용자는 해당 웹 서비스를 계속해서 사용할 확률이 높아집니다.

 

웹 사이트의 성능은 다음과 같은 지표들을 좌우합니다.

• 사용자 유지
• 사용자 전환률 향상
• 사용자 경험

 

 

 

 

 

 

🤔 웹 사이트 성능을 향상시키는 방법

백엔드 개발자라면 아마 SQL 쿼리를 튜닝하거나, 자주 사용되는 조회 쿼리에 대한 캐시를 적용하는 등, 여러 방법을 생각할 수 있을 것입니다.

그러나 이들보다 더 적은 리소스 투자를 통해 큰 성능 효과를 얻을 수 있는 방법이 존재하는데요, 이들은 다음과 같습니다.

• HTTP 압축
• HTTP 캐싱

 

 

 

 

 

 

🤔 HTTP 압축

HTTP 압축이란 HTTP 프로토콜로 주고받는 리소스(예를 들면 html, css, js 등)를 압축하여 전달하는 것을 의미합니다.

압축을 하는 데에 걸리는 시간은 매우 짧으며, 이를 통해 네트워크로 전송되는 데이터의 양을 줄이므로써(일부 문서의 경우 최대 70%까지 압축된다고 합니다.) 성능 향상을 기대할 수 있습니다.

 

압축은 크게 3가지의 계층에서 발생할 수 있으며, 다음과 같습니다.

• 파일 자체에서 압축을 진행할 수 있습니다.
• 서버에서 클라이언트에게 메세지를 보내기 전 압축할 수 있습니다. (가장 효과가 크다고 합니다.)
• HTTP 연결의 두 노드 사이에서 진행될 수 있습니다.

 

이들에 대한 더 상세한 내용은 다음 문서에 나와있습니다.

앞으로는 위 3가지 계층의 압축 중 2번째 압축에 대해서 톰캣은 어떻게 구현되어 있는지를 확인해 보도록 하겠습니다.

 

 

 

Tomcat에서는 gzip을 통한 Compression 기능을 지원하며, 스프링 부트를 사용한다면 다음 옵션을 통해 http 압축 기능을 사용할 수 있습니다.

server:
  compression:
    enabled: true

 

 

 

 

이 기능은 Tomcat 문서에 나와있는 것 처럼, 기본적인 HTTP Connector 클래스가 모두 제공하고 있는 기능입니다.

 

 

 

 

조금 더 자세히 살펴보면 Http11Processor 의 prepareResponse() 메서드 내부에서 다음과 같이 구현되어 있는 것을 확인할 수 있습니다.

(두 부분 사이에 다른 로직이 하나 들어가 있는데 떨어뜨려놓은 이유는 모르겠네용 :( )

 

 

 

 

이때 압축 여부 판단은 protocol에게 위임하여 처리하는데, 해당 프로토콜 클래스는 AbstractHttp11Protocol 입니다.

 

 

 

 

최종적으로, CompressionConfig 클래스에 넘겨 처리되며, 다음과 같이 구현되어 있습니다.

이미 압축되었다면 압축을 진행하지 않는 것을 알 수 있습니다.

 

 

 

 

compressionLevel은 0, 1, 2가 있으며, 0은 압축하지 않음, 1은 압축 사용, 2는 force 옵션입니다.

force 압축을 사용하면 MIME 타입과 컨텐츠의 길이에 상관하지 않고 압축을 진행하도록 하는 부분입니다.

 

 

 

 

이때 압축을 사용하는 경우, 별 다른 설정이 없다면 기본값은 위와 같이 2048(2KB) 입니다. 

이를 변경하고 싶다면 다음 옵션을 통해 변경할 수 있습니다.

server:
  compression:
    min-response-size: 변경하고 싶은 byte

 

 

 

 

 

ETag의 설명을 보면 W/ 로 시작하면 weak validator를 사용한다고 나와있습니다.

weak validator를 사용하지 않으면 compression하지 않는 것 같습니다.

 

 

 

 

 

 

Vary Header를 넣는 부분입니다.

Http Compression의 End to end compression 설명을 보면 Vary 헤더에 Accept-encoding 헤더를 반드시 보내야 한다고 나와있습니다.

(Http Header는 case-insensitive 하므로 accept-encoding도 문제 없습니다.)

 

 

 

 

 

 

웹 클라이언트(브라우저)가 gzip 형식의 압축을 지원하는지를 판단하는 부분입니다.

 

이후 최종적으로 true를 반환하며 압축 사용 여부를 확인합니다.

 

 

이후 압축 사용이 확정되면 아래와 같이 GzipOutputFilter를 추가합니다.

이후 GzipOutputFilter를 통해 Compression을 진행하여 응답합니다.

 

 

 

 

 

 

 

 

🤔 왜 부트는 HTTP Compression을 기본적으로 비활성화 했을까?

HTTP Compression에 대해 공부하다 보니, 기본적으로 enabled로 설정하는 것이 더 좋다고 생각했는데요, 당연하게도 이와 비슷한 생각을 한 사람들이 많았고 하나의 이슈가 3년 전에 생겼었습니다.

왜 기본적으로 비활성화 했는지에 대해서는 해당 이슈에서 확인할 수 있습니다.

https://github.com/spring-projects/spring-boot/issues/21369

 

 

 

 

 

 

 

 

📚 Reference

https://developer.mozilla.org/en-US/docs/Web/HTTP/Compression

Compression in HTTP - HTTP | MDN