http 요청 헤드 의 데 이 터 량 은 요청 헤드 를 분석 하고 요청 할 때마다 추가 데 이 터 를 가 져 왔 습 니 다.다음은 모니터링 하 는 google 요청 헤드 Host www.google.com.hk User-agent Mozilla/5.0(Windows;U; Windows NT 5.2; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTBDFff GTB7.0 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language zh-cn,en-us;q=0.7,en;q=0.3 Accept-Encoding gzip,deflate Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive 115 Proxy-Connect keep-alive 가 되 돌아 오 는 response head Date Sat,17 Apr 2010 08:18:18 GMT Expires-1 Cache-Control private,max-age=0 Content-Type text/html;charset=UTF-8 Set-Cookie PREF=ID=b94a24e8e90a0f50:NW=1:TM=1271492298:LM=1271492298:S=JH7CxsIx48Zoo8Nn; expires=Mon, 16-Apr-2012 08:18:18 GMT; path=/; domain=.google.com.hk NID=33=EJVyLQBv2CSgpXQTq8DLIT2JQ4aCAE9YKkU2x-h4hVw_ATrGx7njA69UUBMbzVHVnkAOe_jlGGzOoXhQACSFDP1i53C8hWjRTJd0vYtRNWhGYGv491mwbngkT6LCYbvg; expires=Sun, 17-Oct-2010 08:18:18 GMT; path=/; domain=.google.com.hk; HttpOnly Content-Encoding gzip Server gws Content-Length 4344 여기 서 보 낸 요청 헤더 의 크기 는 약 420 bytes 이 고 되 돌아 오 는 요청 헤드 는 약 600 bytes 입 니 다.이 를 통 해 매번 요청 할 때마다 추가 정 보 를 가지 고 전송 하 는 것 을 알 수 있 습 니 다.(이번 요청 에 쿠키 가 없 음)요청 한 자원 이 매우 적 습 니 다.예 를 들 어 1k 미 만 의 아이콘 이 있 으 면 request 가 가 져 온 데이터 가 실제 아이콘 의 데이터 보다 많 을 수 있 습 니 다.그래서 요청 이 많 을 수록 네트워크 에서 전송 되 는 데이터 가 많아 지고 전송 속도 가 느 려 집 니 다.사실 리퀘스트 자체 의 데 이 터 량 은 작은 문제 입 니 다.리퀘스트 가 가 져 갈 수 있 는 데 이 터 량 은 한계 가 있 기 때 문 입 니 다.http 연결 비용 은 request 머리 에 남아 있 는 데이터 보다 http 연결 비용 이 더 심각 합 니 다.먼저 사용자 가 URL 1 개 를 입력 하고 다운로드 내용 부터 클 라 이언 트 까지 어떤 단 계 를 거 쳐 야 하 는 지 살 펴 봅 니 다.1.도 메 인 이름 분석 2.TCP 연결 을 엽 니 다.요청 을 보 냅 니 다.4.대기(주로 네트워크 지연 과 서버 처리 시간 포함)5.다운로드 자원 은 요청 할 때마다 대부분의 시간 을 다운로드 자원 에 쓴다 고 생각 할 수 있 습 니 다.블 로그 자바 자원 다운로드 폭포 그림(각 색상 대표 단 계 는 위의 5 단계 와 대응):위의 그림 을 보면 놀 랄 수 있 습 니 다.기다 리 는 단계 에 걸 리 는 시간 이 실제 다운로드 하 는 시간 보다 훨씬 많 습 니 다.위의 그림 은 우리 에 게 1.매번 요청 하 는 대부분의 시간 은 다른 단계 에 있 습 니 다.자원 을 다운로드 하 는 단계 가 아니 라 2.아무리 작은 자원 이라도 다른 단계 에서 많은 시간 을 소비 할 것 이다.다만 다운로드 단계 가 비교적 짧 을 뿐이다(위의 그림 의 여섯 번 째 자원 을 보면 284 Byte).위 에서 언급 한 두 가지 상황 에 대해 우 리 는 어떻게 최적화 해 야 합 니까?다른 단계 의 비용 과 네트워크 에서 전송 되 는 데 이 터 를 줄 이기 위해 요청 수 를 줄 입 니 다.요청 수 1 을 줄 이 고 파일 을 합 치 는 방법 은 많은 JS 파일 을 1 개의 파일 로 합 치 는 것 입 니 다.많은 CSS 파일 을 1 개의 파일 로 합 치 는 방법 은 많은 사람들 이 사 용 했 을 것 입 니 다.여기 서 상세 한 소 개 는 하지 않 고 1 개의 합 치 는 도 구 를 추천 합 니 다.yui copressor 라 는 도구 야후 가 제공 합 니 다.http://developer.yahoo.com/yui/compressor/ 2.그림 통합 은 css sprite 를 이용 하여 배경 그림 의 위 치 를 제어 하여 서로 다른 그림 을 표시 합 니 다.이런 기술 도 모두 가 사용 한 것 입 니 다.상세 한 소 개 는 하지 않 고 온라인 으로 사진 을 합병 하 는 사 이 트 를 추천 합 니 다.http://csssprites.com/ 3.JS,CSS 를 1 개의 파일 위 에 합 치 는 첫 번 째 방법 은 몇 개의 JS 파일 을 1 개의 JS 파일 로 합 치 는 것 입 니 다.몇 개의 CSS 파일 을 1 개의 CSS 파일 로 합 치 는 것 입 니 다.어떻게 CSS 와 JS 를 1 개의 파일 에 합 치 는 지,나의 또 다른 문장 을 보 자.http://www.blogjava.net/BearRui/archive/2010/04/18/combin_css_js.html 4,Image maps Image maps 를 사용 하 는 것 은 여러 개의 그림 을 1 개의 그림 으로 합 친 다음 html 의
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
위의 그림 을 보면 놀 랄 수 있 습 니 다.기다 리 는 단계 에 걸 리 는 시간 이 실제 다운로드 하 는 시간 보다 훨씬 많 습 니 다.위의 그림 은 우리 에 게 1.매번 요청 하 는 대부분의 시간 은 다른 단계 에 있 습 니 다.자원 을 다운로드 하 는 단계 가 아니 라 2.아무리 작은 자원 이라도 다른 단계 에서 많은 시간 을 소비 할 것 이다.다만 다운로드 단계 가 비교적 짧 을 뿐이다(위의 그림 의 여섯 번 째 자원 을 보면 284 Byte).위 에서 언급 한 두 가지 상황 에 대해 우 리 는 어떻게 최적화 해 야 합 니까?다른 단계 의 비용 과 네트워크 에서 전송 되 는 데 이 터 를 줄 이기 위해 요청 수 를 줄 입 니 다.요청 수 1 을 줄 이 고 파일 을 합 치 는 방법 은 많은 JS 파일 을 1 개의 파일 로 합 치 는 것 입 니 다.많은 CSS 파일 을 1 개의 파일 로 합 치 는 방법 은 많은 사람들 이 사 용 했 을 것 입 니 다.여기 서 상세 한 소 개 는 하지 않 고 1 개의 합 치 는 도 구 를 추천 합 니 다.yui copressor 라 는 도구 야후 가 제공 합 니 다.http://developer.yahoo.com/yui/compressor/ 2.그림 통합 은 css sprite 를 이용 하여 배경 그림 의 위 치 를 제어 하여 서로 다른 그림 을 표시 합 니 다.이런 기술 도 모두 가 사용 한 것 입 니 다.상세 한 소 개 는 하지 않 고 온라인 으로 사진 을 합병 하 는 사 이 트 를 추천 합 니 다.http://csssprites.com/ 3.JS,CSS 를 1 개의 파일 위 에 합 치 는 첫 번 째 방법 은 몇 개의 JS 파일 을 1 개의 JS 파일 로 합 치 는 것 입 니 다.몇 개의 CSS 파일 을 1 개의 CSS 파일 로 합 치 는 것 입 니 다.어떻게 CSS 와 JS 를 1 개의 파일 에 합 치 는 지,나의 또 다른 문장 을 보 자.http://www.blogjava.net/BearRui/archive/2010/04/18/combin_css_js.html 4,Image maps Image maps 를 사용 하 는 것 은 여러 개의 그림 을 1 개의 그림 으로 합 친 다음 html 의
