전단 성능-gzip 압축

압축 은 http 응답 크기 를 줄 여 응답 시간 을 줄 입 니 다.Http 요청 이 더 작은 응답 을 받 으 면 서버 와 브 라 우 저 사이 에 더 적은 패키지 가 전송 되 고 전송 시간 이 줄어든다.
압축 은 어떻게 일 합 니까?
Http/1.1 부터 브 라 우 저 는 http 요청 헤더 에 Accept-Encoding 헤드 를 추가 하여 압축 을 지원 합 니 다.

Accept-Encoding: gzip,deflate

웹 서버 가 요청 헤더 에서 Accept-Encoding 헤드 를 발견 하면 Accept-Encoding 이 지정 한 압축 알고리즘 목록 중 하 나 를 사용 하여 응답 을 압축 할 수 있 습 니 다.웹 서버 는 응답 헤드 의 Content-Encoding 헤드 를 통 해 브 라 우 저 응답 내용 에 어떤 압축 알고리즘 을 사 용 했 는 지 알려 줍 니 다.

Content-Encoding:gzip

Gzip 은 현재 가장 유행 하고 효율 적 인 압축 방법 이다.또 다른 압축 알고리즘 은 deflate 이지 만 약간 비효 율 적 이 고 유행 하지 않 습 니 다.deflate 를 지원 하 는 브 라 우 저 도 gzip 을 지원 하지만 gzip 을 지원 하 는 브 라 우 저 는 deflate 를 지원 하지 않 기 때문에 gzip 는 압축 응답 방법 으로 더욱 적합 합 니 다.
어떤 것 이 압축 되 어야 합 니까?
많은 사이트 에서 그들의 HTML 문 서 를 압축 하지만 스 크 립 트 스 크 립 트 와 stylesheet 스타일 파일 을 압축 하 는 것 은 가치 가 있 습 니 다.
압축 은 하나의 비용 이 있 습 니 다.그것 은 추가 적 인 서버 단 압축 과 클 라 이언 트 압축 을 푸 는 CPU 자원 을 가 져 올 것 입 니 다.이해득실 을 따 지기 위해 서 는 응답 크기,네트워크 대역 폭,서버 와 브 라 우 저 간 의 네트워크 거리 등 요 소 를 고려 해 야 합 니 다.이런 정 보 는 쉽게 얻 을 수 없습니다.따라서 일반적으로 1k 가 넘 거나 2k 가 넘 는 파일 은 압축 할 가치 가 있다.
압축 률
압축 은 보통 응답 70%정도 의 크기 를 줄 일 수 있다.
프 록 시 캐 시
브 라 우 저가 프 록 시 를 거 친 요청 을 보 내 면 상황 이 상대 적 으로 복잡 해진 다.gzip 를 지원 하지 않 는 브 라 우 저 에서 프 록 시 서버 에 첫 번 째 요청 을 한다 고 가정 합 니 다.첫 번 째 요청 이기 때문에 프 록 시 서버 의 캐 시 는 비어 있 습 니 다.프 록 시 는 요청 을 웹 서버 에 전송 하고 웹 서버 는 압축 되 지 않 은 응답 을 합 니 다.이 압축 되 지 않 은 응답 은 프 록 시 캐 시 에 의 해 브 라 우 저 에 보 내 집 니 다.현재 가짜 두 번 째 gzip 압축 을 지원 하 는 요청 을 프 록 시 로 보 냅 니 다.프 록 시 에서 압축 되 지 않 은 데 이 터 를 꺼 내 응답 하면 gzip 를 사용 하 는 능력 을 잃 게 됩 니 다.
더 나 쁜 것 은 gzip 을 지원 하 는 브 라 우 저 에서 첫 번 째 로 요청 하고 두 번 째 로 지원 하지 않 는 브 라 우 저 에서 요청 하면 프 록 시 캐 시 에 콘 텐 츠 의 압축 버 전이 있 으 며 gzip 압축 을 지원 하 든 안 하 든 서 비 스 를 제공 합 니 다.
이 문 제 를 해결 하 는 방법 은 웹 서비스 응답 헤더 에 Vary header 필드 를 추가 하 는 것 입 니 다.웹 서버 알림 프 록 시 는 하나 이상 의 요청 헤더 로 서로 다른 캐 시 응답 을 합 니 다.압축 여 부 는 Accept-Encoding 헤드 를 기반 으로 하기 때문에 웹 서버 의 응답 을 위 한 모든 이유 가 있 는 vary 헤드 필드 에 Accept-Encoding 을 포함 합 니 다.

Vary: Accept-Encoding

이 로 인해 프 록 시 는 요청 헤드 Accept-Encoding 필드 의 모든 값 캐 시 를 기반 으로 서로 다른 응답 내용 버 전 을 만 들 수 있 습 니 다.이전 예 에서 프 록 시 는 응답 하 는 두 가지 버 전 을 캐 시 합 니 다.Accept-Encoding 이 gzip 일 때 압축 된 내용 과 Accept-Encoding 이 지정 되 지 않 았 을 때 압축 되 지 않 은 버 전 입 니 다.브 라 우 저가 Accept-Encoding:gzip 를 프 록 시 에 요청 하면 프 록 시 는 캐 시 에 압축 된 버 전 을 가 져 와 브 라 우 저 에 응답 합 니 다.Accept-Encoding:gzip 헤드 가 없 으 면 브 라 우 저 는 압축 되 지 않 은 버 전 을 받 습 니 다.
대리 변두리 상황
90%의 브 라 우 저 는 gzip 를 지원 한다 고 주장 하지만,그 중 일부 브 라 우 저 는 압축 해제 에 bug 가 존재 할 수 있 습 니 다.압축 을 지원 하 는 브 라 우 저 에 압축 콘 텐 츠 를 제공 하 는 비교적 안전 한 방법 은 IE6+와 Mozilla 5.0+이다.
웹 서버 는 User-agent 의 형식 조건 을 설정 하여 지정 한 압축 보안 브 라 우 저 에 압축 지원 을 제공 할 수 있 습 니 다.예 를 들 어 아파 치 1.3 설정 은 다음 과 같 습 니 다.

mod_gzip_item_include reqheader "User-Agent: MSIE [6-9]"
mod_gzip_item_include reqheader "User-Agent: Mozilla/[5-9]"

캐 시 를 추가 하여 브 라 우 저 를 혼합 하 는 가장 좋 은 방법 은 User-agent 를 Vary 머리 에 추가 하 는 것 입 니 다.

Vary: Accept-Encoding,User-Agent

이렇게 하면 프 록 시 는 요청 한 Accept-Encoding 과 User-agent 의 값 에 따라 서로 다른 웹 서버 응답 버 전 을 캐 시 하여 다음 요청 에 직접 응답 할 수 있 습 니 다.그러나 에이 전 트 는 Accept-Encoding 과 User-agent 요청 헤더 의 조합 캐 시 를 기반 으로 모든 요청 URL 의 응답 내용 을 캐 시 하 는 것 은 불가능 합 니 다.
이 문 제 는 실질 적 으로 균형 적 인 압축 과 캐 시 두 가지 문제 이 고 어떻게 처리 하 느 냐 는 사이트 의 실제 상황 에 근거 해 야 한다.

만약 에 귀하 의 사이트 에 비교적 적은 사용자 가 있 고 그들 이 비교적 작은(예 를 들 어 모두 fireforx 1.5 를 사용)이 라면 가장자리 상황 은 거의 고려 하지 않 고 내용 을 압축 시 키 고 Vary:Accept-Encoding 을 사용 하면 응답 크기 를 줄 이 고 프 록 시 캐 시 를 사용 하여 사이트 의 성능 을 향상 시 킬 수 있 습 니 다.

네트워크 대역 폭 절약 에 더 관심 이 있다 면 콘 텐 츠 를 압축 하고 Vary:Accept-Encoding 을 사용 하 세 요.이렇게 하면 웹 서버 의 네트워크 대역 폭 을 줄 이 고 프 록 시 처리 요청 수량

을 증가 시 켰 다.

만약 에 서로 다른 사용자 가 있다 면 비교적 높 은 대역 폭 비용 과 질 좋 은 평 가 를 부담 하고 내용 을 압축 시 키 며 Cache-Control:Private 을 사용 할 수 있 습 니 다.이것 은 프 록 시 를 더 이상 캐 시 하지 않 지만 가장자리 상황 의 bug

를 피 할 수 있 습 니 다.