본문 바로가기

.NET/ASP.NET

실전 HTTP Compression 1 - HTTP 압축의 위험과 해결 방안



 
 
1.    서론
 
HTTP Compression 은 웹사이트의 응답 성능을 향상 시키는데 많은 일조를 합니다. 압축 정도와 데이터의 타입에 따라 압축율은 다르지만, 최소 30% 이상의 체감 속도의 향상을 가져온다고 합니다. 제가 운영하고 있는 [Umc Projects/Umc Blog] - [UmcBlog] 블로그 소스 다운로드 의 메인화면의 HTML 만해도 101,430 Bytes 지만, GZip 압축을 적용한 결과 15,450 Bytes 로 7배 정도로 작아진 트래픽이 발생합니다.
 

[그림1] Umc Blog 메인 화면을 HTTP 압축한 비교표
 
위 압축은 ShartZipLib 를 이용하여 최고 압축율로 압축한 결과 입니다.
자~ 어떻습니까? 이제 HTTP 압축을 자신의 사이트에 도입해 보려고 한다면, 우선 다음의 강좌를 참고하여 선수 지식을 익히시기 바랍니다.
 
최고의 가이드 문서인 유경상님의 HTTP 압축 (1) : 성능 향상을 위한 다른 접근 기법
 
제가 아는 포스팅은 이것 뿐인지, 아니면 제가 못 찾는 것인지 모르겠지만, 어쨌든 왜 써야 하며, 어떻게 구현하는지는 보셔야 다음 내용을 이해할 수 있습니다.
 
 
2.    문제 제기
 
위 내용 중 특히 유경상님의 문서에서 볼 수 있듯이 HTML 과 XML Web Service 에서 압축방법과 압축해제 방법을 너무나 잘 설명해 주셨습니다. (쵝오!) .NET Framework 가 버전업이 되면서 편리한 API 와 옵션들이 추가되어 깊은 이해보다 코드 한 줄로 해결할 수 있는 방법들이 너무나 다양해 졌습니다.
 
좋습니다. 어찌되어건, HTTP Compression 은 서버의 CPU 가 가져가는 부하가 경미하기 때문에 보다 훨씬 많은 이점이 있습니다. 그렇기 때문에, 웹 사이트는 특별한 상황이 아니라면 HTTP Compression 을 활용하도록 해야 합니다.
 
IIS HTTP Compression 을 사용하지 말아야 할 때
IIS 서비스 압축은 기본적으로 DLL 도 GZip 압축 하도록 되어있습니다. 스마트클라이언트 시나리오에서는 클라이언트가 GZip 압축된 어셈블리(*.dll) 등을 다운로드 하였을 때 다운로드 된 클라이언트는 GZip 압축을 복호화 하지 못합니다. 유경상님의 HTTP Compression (III) : IIS Support 을 참고 하세요.
 
자.. 문제는 여기서 부터입니다. HTTP Compression 의 구현은 쉽지만, HTML(CSS/JS) 이나 XML Web Service 에 국한된 포스팅 입니다. 특히, 클라이언트 어플케이션일 경우 의 GZip 압축의 범위가 XML Web Service 에 국한됩니다. 하지만, 불특정 다수의 웹 서비스 사이트를 생각한다면 HTML Compression 만으로 부족한 것을 알 수 있습니다.
 

[그림2] HTML 뿐만 아니라 다양한 데이터를 클라이언트는 내려받습니다 (클릭하면 확대 됩니다)
 
우리가 웹 사이트를 접속하였을 때, 보여지는 것은 HTML/CSS/JS 만 있는 것이 아닙니다. 수십 개의 콘텐츠 중 고작, 10여개의 텍스트 용량을 줄였다고 체감속도가 향상 되었다는 것은 억지에 불과합니다.(그나마 안하는 것보다는 나은듯^^;) 왜냐하면, 웹 사이트를 접속할 때 XML, BMP 등과 같은 압축되지 않은 다양한 콘텐츠도 다운로드 되기 때문 입니다.
 
물론, HTTP Compression 을 하느냐 안하느냐도 중요합니다. 하지만 압축이 전부는 아닙니다. 자신이 개발하거나 관리하는 사이트가 이런 문제로 고민을 한다면 다양한 웹 사이트 최적화 기법을 통해서 빠른 응답을 기대할 수 있습니다.
 
웹 사이트 최적화 튜닝 방법
 
ASP.NET 개발 환경을 무척 편리해 졌습니다. .NET Framework 2.0 부터 추가된 WebResource 와 ScriptResource 를 이용하여 컴포넌트 배포시에 별도의 스크립트 파일이 없이도 동작하도록 어셈블리의 리소스에 포함시킬 수 있게 되었습니다. 무척 배포가 쉬워졌지요.
 
하지만, ASP.NET 웹사이트로 구축된 기업의 인트라넷의 경우 다양한 컴포넌트를 사용하여 개발하게 될 때, 수십여 개의 WebResource 와 ScriptResource 를 뱉어내게 됩니다. 이 리소스들은 압축되었다는 보장을 할 수 없고, 실제로 압축되지 않은 리소스들이 더 많습니다. 이런 웹 사이트의 성능 저하 주 원인이 바로 리소스입니다.
 
문제는 여기에서 생깁니다. 어떻게 이 리소스들을 압축하시겠습니까?
AJAX.NET 의 ScriptManager 컨트롤은 3개의 ScriptResource 를 포함합니다. ScriptResource 는 아무런 작업을 하지 않아도 gzip 압축이 되는데, 특정 컴포넌트의 ScriptResource 는 gzip 압축을 하지 않습니다.
 

[그림3] 아무 작업 없이도 ScriptResource 는 압축이 되기도 합니다.
 
특히 ScriptResource 의 경우는 아무런 생각 없이 압축을 수행하다가는 이미 압축된 리소스가 추가적으로 GZip 압축이 되어, 브라우져는 중복 압축된 콘텐츠를 제대로 복호화 하지 못합니다. 결국 사이트는 바보가 됩니다.