이 를 위해 서 는 캐 시 를 최대한 사용 하고 캐 시 에서 이전 메 시 지 를 자주 받 아야 한다.다행히도 현재 대부분의 WAP 장 치 는 일정한 등급 의 캐 시 를 가지 고 있 으 며,기본적으로 최대 화 된 캐 시 를 시도 합 니 다.URL 을 가리 키 는 거의 모든 응답 이 캐 시 됩 니 다.[RFC 2616]의 정의 에 따 르 면 캐 시 는'프로그램 에서 메시지 에 응답 하 는 로 컬 저장 소 와 이 메시지 의 저장,재 가 져 오기,삭 제 를 제어 하 는 서브 시스템'입 니 다.캐 시 는 캐 시 할 수 있 는 응답 메 시 지 를 저장 하여 미래의 응답 시간 과 네트워크 대역 폭 소 모 를 줄 이 고 요청 메시지 에 도 적용 합 니 다."WAP 사용자 터미널 캐 시 응답 이 있 을 때 거의 모든 정 보 를 저장 합 니 다.URL,응답 텍스트,메시지 헤더 및 기타 응답 을 검증 할 수 있 는 내용(다음 절'검증 및 과거 기록 스 택'참조).캐 시 된 모든 항목 은 URL 구성 부분(도 메 인 이름,경로,프로 토 콜,파라미터,포트 등)에 따라 유일 하 게 식별 할 수 있 습 니 다.WML 의 DECK 캐 시 를 제어 할 수 있 는 두 가지 HTTP 메시지 헤더 가 있 습 니 다.우리 에 게 가장 중요 한 것 은 Cache-Control 메시지 헤더 입 니 다.모든 캐 시 실 체 를 요청/응답 체인 을 통 해 직접 제어 할 수 있 습 니 다.모든 캐 시 메커니즘 은 이 메시지 헤더 의 정 의 를 준수 해 야 한다.Cach-Control 메시지 헤드 는 보통 장치 의 기본 캐 시 행 위 를 차단 하 는 데 사 용 됩 니 다.그들 은 메시지 체인 에서 전달 할 때 모든 프 록 시 서버 와 게 이 트 웨 이 를 직접 통과 해 야 합 니 다. * Cache-Control: no-cache。사용자 터미널 과 콘 텐 츠 서버 와 사용자 터미널 사이 에 있 는 다른 서버 를 포함 하여 이 옵션 의 URL 을 캐 시 할 수 없습니다.*Cache-Control: max-age=。장치 캐 시 에 저 장 된 URL 의 최 장 시간 을 정의 합 니 다.시간 이 되면 이 실 체 는 캐 시 에서 삭 제 됩 니 다.*Expired: 。캐 시 에 URL 을 저장 할 마지막 날 짜 를 지정 합 니 다.[RFC 1123]는 날짜 의 형식 을 정의 합 니 다.보통 다음 과 같 습 니 다.Expires:Sun,29 October 2000 17:30:47 GMT 는 WAP 애플 리 케 이 션 을 쓸 때 콘 텐 츠 서버 에 정 보 를 가 져 오 는 동작 을 최소 화 할 수 있 도록 사용자 터미널 을 가정 해 야 합 니 다.다음 설명 을 하 겠 습 니 다.1.영구 캐 시 URL WAP 사용자 단말 기 는 보통 캐 시 에 액세스 한 URL 을 최대한 길 게 저장 합 니 다.이'최대한 길 게'는 Phone.com 브 라 우 저 에서 약 30 일 로 정 의 됩 니 다.그러나 URL 의 캐 시 시간 을 최대한 연장 하고 싶 을 수도 있 습 니 다.예 를 들 어 회사 의 로고 등 은 페이지 를 열 때마다 시간 이 줄 어 듭 니 다.다음 두 가지 방법 으로 간단하게 실현 할 수 있 습 니 다.*현재 와 먼 만 료 일 을 지정 합 니 다.예 를 들 어 Expires:Tue,01 Jan 2002 00:00:00 GMT;*캐 시 시간 을 지정 합 니 다.예 를 들 어 Cache-Control:max-age=3153600.이 예 는 URL 을 1 년 동안 캐 시 할 수 있 습 니 다.사용자 터미널 에서 허용 하 는 최대 정 수 는 2,147,483,647 이기 때문에 하나의 URL 을 68 년 이상 저장 할 수 있 습 니 다.물론,그때 가 되면 너의 휴대 전 화 는 벌써 폐기 되 었 다.2.URL 에 대한 캐 시 시간 을 지정 하 는 일반적인 상황 은 하나의 URL 에 대해 캐 시 시간 만 필요 합 니 다.예 를 들 어 주식 견적 시스템,홈 페이지 를 5 분 에 한 번 업데이트 해 야 할 수도 있 습 니 다.그러면 DECK 의 HEAD 부분 에서 Cache-Control:max-age=300 을 지정 하면 됩 니 다.사용자 가 5 분 안에 이 페이지 를 다시 검색 하면 캐 시 에 있 는 웹 페이지 를 볼 수 있 습 니 다.5 분 뒤 면 서버 에서 최신 데 이 터 를 가 져 옵 니 다.또 다른 캐 시 시간 을 제어 하 는 방법 은 앞에서 언급 한 Expires 를 사용 하 는 것 입 니 다.그러나 이 방법 은 사용자 단말기 에 만 알려 줄 수 있 습 니 다.지정 한 시간 이 지나 면 언제든지 페이지 를 방문 할 때 새로 고침 해 야 합 니 다.다음 에 시간 을 조절 하려 면 Expires 의 시간 값 을 바 꿀 수 밖 에 없습니다.3.URL 에 대한 캐 시 를 금지 하고 빠르게 변화 하 는 내용 에 대해 매번 최신 데 이 터 를 얻 기 를 원 합 니 다.따라서 이 럴 때 는 관련 웹 페이지 의 캐 시 를 완전히 금지 해 야 한다.방법 은 세 가지 가 있 습 니 다.*Cache-Control:no-cache 설정;*최대 캐 시 시간 을 0 으로 설정 합 니 다.Cache-Control:max-age=0;*캐 시 만 료 일 을 오래된 날짜 로 설정 합 니 다.Expires:Mon,1 Jan 1990 00:00:00 GMT.사실 뒤의 두 가 지 는 최선 의 선택 이 아니다.우선 터미널 의 처리 시간 을 많이 차지 합 니 다.이 DECK 에 부 딪 혔 을 때 터미널 은 만 료 시간 을 계산 해 야 하기 때 문 입 니 다.그 다음으로 이렇게 하면 바이트 가 많이 차지 하고 표현 에 있어 서도 명확 하지 않다.WAP 표준 은 모든 WAP 장치 에 10 개 항목 을 수용 할 수 있 는 역사 스 택 이 있어 야 한다 고 규정 하고 있다.사용자 가또는 다른 명령 으로 정 의 된 앞 줄(forward)링크 를 누 르 면 URL 이 스 택 에 추 가 됩 니 다.에서 정의 하 는 후퇴(backward)링크 를 누 르 면 URL 이 팝 업 됩 니 다.일반적인 상황 에서 모든 전진 링크 는 검증 되 고 후퇴 링크 는 캐 치 에 있 기 때문에 검증 되 지 않 습 니 다.그러나 우 리 는 때때로 사용자 가 후퇴 버튼 을 눌 렀 을 때 여전히 최신 데 이 터 를 얻 을 수 있 기 를 바란다.터미널 이 항상 검증 되 지 않 으 면 사용 자 는 메 인 메뉴 를 찾 아 그 페이지 에 다시 들 어 갈 수 밖 에 없다.다행히도,우 리 는 Cache-Control:must-revalidate 를 사용 하면 사용자 단말기 가 백 을 눌 렀 을 때 URL 을 검증 하도록 강요 할 수 있 습 니 다.물론 검증 은 이 페이지 가 바로 다시 읽 힌 다 는 것 이 아니 라 그 가 만 료 되 었 는 지 여부 에 따라 결정 된다.만 료 되 지 않 았 다 면,검 증 된 결 과 는 캐 시 에 있 는 페이지 를 표시 합 니 다.만약 백 할 때마다 페이지 를 다시 읽 을 필요 가 있다 면,Cache-Control:must-revalidate,no-cache 로 실행 할 수 있 습 니 다.또한,no-cache 를 max-age=300 으로 바 꾸 면 백 시 300 초 동안 캐 시 된 페이지 를 새로 고 칠 수 있 습 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
