HTTP 프로토콜에 대한 심층적인 이해 및 캐싱 원리 분석

3.2 캐시 구현 원리

3.2.1 웹 캐시란

웹 캐시(cache)는 웹서버와 클라이언트 사이에 위치한다.

캐시는 요청에 따라 html 페이지, 사진, 파일과 같은 출력 콘텐츠의 복사본을 저장합니다. 다음 요청이 오면: 동일한 URL인 경우 캐시는 해당 복사본을 직접 사용합니다. 서버는 액세스 요청을 소스로 보내는 대신 응답합니다.

HTTP 프로토콜은 웹 캐싱이 최대한 잘 작동하도록 관련 메시지 헤더를 정의합니다.

3.2.2 캐싱의 장점

응답 지연 시간 감소: 요청이 원본 서버가 아닌 캐시 서버(클라이언트에 더 가까운)에서 응답되므로 이 프로세스에 소요되는 시간이 줄어들고 web 서버가 더 빨리 응답하는 것 같습니다.

네트워크 대역폭 소비 감소: 복제본을 재사용하면 클라이언트의 대역폭 소비가 감소합니다. 고객은 대역폭 비용을 절감하고 대역폭 요구 사항 증가를 제어하며 관리를 더 쉽게 만들 수 있습니다.

3.2.3 캐시 관련 HTTP 확장 헤더

Expires: 응답 내용이 만료되는 시간을 나타냄, Greenwich Mean Time GMT

Cache-Control: 더 자세한 Control이 캐시됨 content

Last-Modified: 응답 내 리소스가 마지막으로 수정된 시간

ETag: 일정 기간 동안 고유하게 식별되는 응답 내 리소스의 확인 값 서버에서.

날짜: 서버 시간

If-Modified-Since: 클라이언트가 액세스한 리소스가 마지막으로 수정된 시간으로 Last-Modified와 동일합니다.

If-None-Match: 클라이언트가 액세스한 리소스의 확인 값으로 ETag와 동일합니다.

3.2.4 클라이언트 캐싱을 적용하기 위한 일반적인 프로세스

서버가 요청을 받으면 리소스의 Last-Modified 및 ETag 헤더를 200OK로 다시 보내고 클라이언트는 리소스를 캐시에 저장하고 이 두 가지 속성을 기록합니다. 클라이언트가 동일한 요청을 보내야 하는 경우 요청에 If-Modified-Since 및 If-None-Match라는 두 개의 헤더가 포함됩니다. 두 헤더의 값은 응답의 Last-Modified 및 ETag 헤더의 값입니다. 서버는 이 두 헤더를 통해 로컬 리소스가 변경되지 않았음을 확인하고 클라이언트는 이를 다시 다운로드할 필요가 없으며 304 응답을 반환합니다. 일반적인 프로세스는 아래 그림과 같습니다.

3.2.5 웹 캐싱 메커니즘

HTTP/1.1에서 캐싱의 목적은 전송 요청을 줄이는 것입니다. 대부분의 경우 완전한 응답을 보낼 필요가 없을 수도 있습니다. 전자는 네트워크 루프 수를 줄입니다. HTTP는 이러한 목적으로 "만료" 메커니즘을 활용합니다. 후자는 네트워크 애플리케이션의 대역폭을 줄입니다. HTTP는 이러한 목적으로 "검증" 메커니즘을 사용합니다.

HTTP는 3가지 캐싱 메커니즘을 정의합니다.

1) 신선도: 원본 서버에서 응답 메시지를 다시 확인할 수 있으며 서버와 클라이언트에서 제어할 수 있습니다. 예를 들어 Expires 응답 헤더는 문서를 사용할 수 없는 시간을 제공합니다. Cache-Control의 max-age 플래그는 캐싱의 최대 시간을 나타냅니다.

2) 유효성 검사: 캐시된 응답이 여전히 사용 가능한지 확인하는 데 사용됩니다. 예를 들어 응답에 Last-Modified 응답 헤더가 있는 경우 캐시는 상황에 따라 요청을 보낼지 여부를 결정하기 위해 If-Modified-Since를 사용할 수 있습니다. 3) 무효화(Invalidation): 캐시를 통한 또 다른 요청에서 가끔 부작용이 발생하는 경우가 종종 있습니다. 예를 들어, URL이 캐시된 응답과 연결되어 있지만 POST, PUT 및 DELETE 요청이 뒤따르면 캐시가 만료됩니다.

3.3 중단점 이력서 다운로드 및 멀티 스레드 다운로드 구현 원칙

HTTP 프로토콜의 GET 메서드는 리소스의 특정 부분만 요청을 지원합니다.

206 부분 콘텐츠 부분 콘텐츠 응답;

Range 요청 리소스 범위;

Content-Range 응답 리소스 범위;

연결이 끊어졌다가 다시 연결되면 클라이언트는 리소스만 요청하고 다운로드는 요청하지 않습니다. 중단점 재개를 달성하기 위해 전체 리소스를 다시 요청하는 대신 해당 부분을 다시 요청합니다.

차단 요청 리소스 인스턴스:

Eg1: 범위: 바이트=306302-: 이 리소스를 306302바이트부터 끝까지 요청합니다.

Eg2: 콘텐츠- 범위: 바이트 306302 -604047/604048: 응답은 리소스의 바이트 306302-604047을 전달하고 리소스의 총 크기는 604048바이트임을 나타냅니다.

클라이언트는 동시 요청을 통해 동일한 리소스를 요청하는 데 사용됩니다. 특정 리소스의 동시 청크 다운로드를 구현합니다. 빠른 다운로드라는 목적을 달성하기 위해. 현재 인기 있는 FlashGet과 Thunder는 기본적으로 이 원리를 사용합니다.

멀티 스레드 다운로드의 원칙:

다운로드 도구는 HTTP 요청을 발행하는 여러 스레드를 엽니다.

각 http 요청은 리소스 파일의 일부만 요청합니다. 콘텐츠 -범위: 바이트 20000-40000/47000;

각 스레드에서 다운로드한 파일을 병합합니다.

3.4 https 통신 프로세스

3.4.1 https

HTTPS(전체 이름: Hypertext Transfer Protocol over Secure Socket Layer)란 단순히 보안을 목표로 하는 HTTP 채널입니다. 즉, HTTP의 보안 버전입니다. 즉, HTTP에 SSL 레이어가 추가된 것입니다. HTTPS의 보안 기반은 SSL이므로 암호화에 대한 자세한 내용은 SSL을 참조하세요.

아래 그림 참고:

https에서 사용하는 포트 번호는 443입니다.