참고: https://developer.mozilla.org/ko/docs/Web/HTTP/Compression
압축은 웹 사이트의 성능을 높여주는 중요한 방법 중 하나! 어떤 문서에 대해서는 70% 이상의 사이즈 축소로 대역폭 용량을 줄여주는 효과를 가져다준다. 실제로 웹 개발자들은 압축 매커니즘을 구현할 필요는 없다. 왜냐면 브라우저와 서버가 이미 잘 구현하고 있기 때문. 따라서 개발자는 서버가 잘 구성되어 있는지 확인하면 된다.
압축은 세 개의 서로 다른 계층에서 이뤄진다.
- 먼저 일부 파일 형식이 최적화된 특유의 방법으로 압축
- 그 뒤 HTTP 계층에서 일반적인 암호화가 일어난다. 리소스는 끝단 간에 압축되어 전송된다.
- 압축이 HTTP 커넥션의 두 노드 사이의 커넥션 계층에서 정의된다.
파일 포멧 압축
각각의 데이터 타입은 그 안에서 공간을 낭비하는 몇 가지 중복을 가지고 있다. 텍스트는 일반적으로 60% 정도의 중복을 가진 반면, 오디오나 비디오 같은 미디어 파일들의 중복 비율은 더 높다. 때문에 특정 목적을 위해 설계된 파일 포맷이 사용하는 최적화 압축 알고리즘이 등장했다.
무손실 압축
압축-비압축 사이클이 복원된 데이터를 변경하지 않는 것을 의미. 이미지에에서는 gif나 png가 무손실 압축 방식을 사용한다.
손실 압축
사용자가 인지하기 힘든 방법 내에서 원래의 데이터를 압축 사이클 내에서 바꾸는 방식이다. 웹에서 비디오 포멧은 손실 압축 방식을 사용하며 이미지에서는 jpeg가 사용한다.
일반적으로 손실 압축 알고리즘이 무손실 압축 알고리즘보다 효율적이다.
종단 간 압축
웹 사이트의 가장 큰 성능 이득이 발생하는 구간이다. 종단 간 압축은 서버에 의해 처리되고 클라이언트에 도달할 때까지 변하지 않는 메세지 바디의 압축을 나타낸다.
모든 모던 브라우저와 서버는 종단 간 압축을 지원한다. 단지 설정해주어야할 부분은 압축 알고리즘이다. 종단간 압축에서는 보통 텍스트에 최적화된 압축 알고리즘을 사용한다. 현재는 가장 일반적인 gzip과 새롭게 나타난 br이 적절한 후보군이다.
사용할 알고리즘을 선택하기 위해 브라우저와 서버는 Content-Negotiation을 사용한다. Content-Negotiation 참고: https://developer.mozilla.org/ko/docs/Web/HTTP/Content_negotiation
브라우저는 브라우저가 지원하는 알고리즘과 그 우선순위를 Accept-Encoding 헤더로 서버에 알려준다. 서버에서는 Accept-Encoding을 사용하여 응답으로 보낼 Body를 압축하는데 사용한 뒤 브라우저에 사용한 알고리즘을 Content-Encoding으로 알려준다.
이때 유의해야할 점은 Content-Negotiation이 인코딩에 근거한 표현을 선택하는데 사용되므로 적어도 Content-Encoding에 포함되는 하나의 Vary헤더가 반드시 응답 내 헤더에 포함되어야한다.
종단 간 압축 단계에서는 이미 이미지나 오디오, 비디오 같은 미디어 파일들은 압축되어 있을 것이다.
Hop-by-Hop 압축
종단 간 압축과 비슷하지만 서버에서 리소스에 대한 압축이 일어나지 않고 클라이언트와 서버 사이의 경로 상의 두 노드 사이에서 메세지 바디의 압축이 일어난다. 이 중간 노드 간의 커넥션들은 다른 압축을 적용할수도 있다. (압축 알고리즘을 무조건 하나만 사용할 필요는 없다)
Hop-by-Hop 압축을 사용하기 위해 요청을 전송하는 모든 노드는 노드의 요청이 TE 헤더를 사용하고 있다는 것을 알려줘야한다. 요청을 받은 노드는 알맞은 방법을 선택, 적용 후 Transfer-Encoding 헤더를 사용하여 선택한 내용을 가리킨다.
실제로 Hop-by-Hop은 서버-클라이언트에는 보이지 않으며 드물게 사용된다. Hop 계층에서 Transfer-Encoding헤더와 압축을 사용은 보통 프록시 계층에서 적용한다.
'Web Basic > HTTP' 카테고리의 다른 글
HTTP Redirect (0) | 2019.10.13 |
---|---|
컨텐츠 협상 (Content Negotiation) (0) | 2019.10.13 |
HTTP 캐싱 (0) | 2019.10.06 |
HTTP 세션 (0) | 2019.10.06 |
HTTP 쿠키 (0) | 2019.10.06 |