HTTP 완벽가이드 - 2. 연결 및 서버 아키텍처

14 분 소요

4장 커넥션 관리

TCP 커넥션

: 패킷 교환 네트워크 프로토콜의 계층화된 집합

연결과정


1. 브라우저가 URL의 호스트명 추출
2. 추출된 호스트명의 IP주소 검색
3. 브라우저가 URL의 포트번호를 취득
4. 취득한 IP주소와 포트로 TCP 커넥션 생성
5. 서버로 HTTP 요청 메세지 전송
6. 서버로부터 HTTP 응답 메세지 수신
7. 브라우저가 커넥션을 종료

특성

명칭	상세
신뢰성	충돌없이 데이터를 순서대로 정확하게 전달 => PC/네트워크에 문제 없는 한 안전한 전송 보장
병렬성	서로 다른 포트를 이용해 여러 TCP 커넥션 구축
유일성	발신지IP + 발신지포트 + 수신지IP + 수신지포트 => 유일한 커넥션 조합

패킷
- 데이터를 세그먼트 단위로 나누고 이를 패킷에 담아 전달
- 참고: TCP헤더구조

계층

HTTP 계층	HTTPS 계층	상세
HTTP	HTTP	어플리케이션 계층
-	TLS/SSL	보안 계층
TCP	TCP	전송계층
IP	IP	네트워크 계층
Network Interface	Network Interface	데이터링크 계층

소켓 API

공통함수

함수	상세
socket()	새로운 소켓 생성 (미연결)
bind()	소켓에 로컬 포트 및 인터페이스 할당
connect()	로컬 소켓과 원격 호스트 사이에 TCP연결 생성
listen()	로컬 소켓이 연결 요청 수신하도록 허용
accept()	로컬포트에 연결 성립되는 걸 대기
read()	소켓이 버퍼에 읽기 시도
write()	소켓이 버퍼에 쓰기 시도
close()	TCP 연결 종료
shutdown()	TCP 연결 입출력만 닫음
getsockopt()	로컬 소켓 설정값 취득
setsockopt()	로컬 소켓 설정값 설정

참고: 파이썬 예제

연결과정

주체	처리
서버	- socket: 소켓생성 - bind: 포트 설정 - listen: 연결 허용 - accept: 연결 대기
클라이언트	- IP/포트 취득 - socket: 소켓생성 - connect: 서버에 연결요청
서버	- 연결성립 통지 - read: 요청 읽기(대기)
클라이언트	- 연결성공 - write: HTTP요청 전송 -read: HTTP응답 읽기(대기)
서버	- HTTP요청 처리 - write: HTTP응답 전송 - close: 연결 닫기
클라이언트	- HTTP응답 처리 - close: 연결 닫기

HTTP 커넥션 지연

HTTP 트랜잭션 지연 요소
- 하드웨어 성능
- 네트워크/서버 전송속도
- 요청/응답 메세지 크기
- 클라이언트-서버 간 거리
- TCP의 기술적 복잡성
TCP 성능 요소

명칭	상세	특성
TCP 커넥션 핸드셰이크	커넥션 생성 위한 SYN/SYN+ACK 패킷 교환	매 생성마다 지연 발생
TCP 확인응답 편승	데이터 송출 패킷 있을 경우 확인응답 패킷을 편승(piggyback)	효율적이나 지연 발생
TCP slow-start	데이터 전송 성공한 커넥션에 높은 속도(전송가능 패킷 수) 허용	혼잡제어 효과
nagle 알고리즘	작은 패킷은 버퍼에 저장해 한꺼번에 전송 <-> silly window synndrome	- 작은 메세지의 긴 지연 - 확인응답 편승 지연 악화 - TCP_NODELAY 파라미터로 off 가능
TIME_WAIT 지연 및 포트 고갈	커넥션 종료 시 일정 기간(2MSL) 재연결 방지	- 이전 커넥션 패킷 유입 방지 - 성능시험 시 발생 가능

silly window syndrome

1 Byte 패킷 대량 전송하는 반사회적 전송행위
포트고갈

초당 요청량이 트랜잭션 처리량 초과시 새로운 포트 이용 불가
=> 가상 IP로 이용가능 커넥션(IP+포트) 조합 증설 필요
2MSL

라우터의 세그먼트 생명주기 * 2 (=2분에서 줄어듬)

HTTP 커넥션 관리

Connection 헤더

트랜잭션 종류 후 연결유지 여부 결정
- close
  
  메세지 전송 후 연결 종료
- 쉼표로 구분된 HTTP 헤더 목록 (보통 keep-alive만 해당)
  
  발신자와 첫 번째 기기와의 연결을 정의 (포워드 시 삭제)
순차처리
- 객체크기 모름 => 로딩 중에 화면 표시 불가 =>사용자가 심리적 지연 느낌

병렬 커넥션: 동시에 여러 개의 TCP 커넥션 이용

장점	단점
대역폭 충분 + 지연시간 겹침 => 총 지연시간 감소 가능	커넥션 생성 지연 메모리 부하 발생 가능

지속 커넥션: 서버나 클라이언트가 연결 종료하기 전까지는 커넥션 재사용
=> 생성 지연 제거 but 커넥션 쌓이지 않도록 관리 필수

명칭	상세
HTTP/1.0+ Keep-Alive	- HTTP1.1에서 제거 - 강제성 없음 (응답헤더에 없으면 거절로 인식) - 본문 길이값 알거나 chunk 전송 인코딩 써야 유지 가능 예) Connection: Keep-Alive Keep-Alive: timeout=120, max=5
HTTP/1.1 Persistent	- 기본값: 종료 헤더 전달 전까지 연결 지속 - 강제성 없음 (Connection: close 없어도 종료 가능) - 본문 길이값 알거나 chunk 전송 인코딩 필요 - 과부하 방지: 클라이언트가 2개 정도 유지하는 게 바람직
HTTP/1.1 Pipelining	- 기본 비활성화: 지속커넥션일 때만 이용 가능 - 응답 기다리지 않고 요청 계속 전달 - 순서대로 비멱등 요청만 발송해야
HTTP/2.0 Multiplexing	-단일 커넥션 내에서 다중화 => 프레임화된 여러 메세지 스트림을 동시적으로 전송

멍청한(dumb) 프록시 문제
- Keep-Alive 이해 못하고 그대로 전달 -> 프록시만 커넥션 종료 대기 -> 행 & 타임아웃
- Proxy-Connection 헤더 이용해도 중간에 멍청한 프록시가 있으면 문제 발생
멱등(idempotent) 요청

연산 여러 번 수행해도 결과 동일한 요청 ex) GET 조회요청
비멱등(nonidempotent) 요청

연산마다 결과 달라질 수 있는 요청 ex) POST 가입요청

구글 HTTP/2 소개
- 바이너리 프레이밍: HTTP 통신을 바이너리 인코딩된 프레임 교환으로 세분화
- 스트림: 연결 내에서 전달되는 양방향 바이트 흐름으로 하나 이상의 메시지 전달 가능
- 메시지: 요청/응답 메시지에 매핑되는 프레임 전체 시퀀스
- 프레임: HTTP/2 통신의 최소 단위
- 프레임 헤더: 프레임의 소속 스트림 식별 위한 최소한의 정보
구글 HTTP/2 optimize 슬라이드
- 리소스의 type/context에 따라 스트림의 우선순위(가중치 및 의존도) 결정됨
- 각 리소스는 발견 즉시 요청이 생성됨 => 서버가 순서대로 데이터 전송해야

커넥션 종료

언제든지 임의/오류로 종료 가능 => 재시도 등 대응 필요 (비멱등 요청은 예외)
Content-Length 불일치 시 서버에 확인 필요

종류

명칭	상세
전체 끊기	close()로 입/출력 채널 모두 종료
절반 끊기	shutdown()으로 입/출력 채널 중 하나만 종료 => 출력채널만 종료 권장 (종료된 입력채널에 쓰기 오류 방지)

connection reset by peer 오류

종료된 입력채널 전송 시 OS가 버퍼에 저장된 읽히지 않은 데이터 모두 삭제

5장 웹 서버

웹 서버

HTTP 요청처리/응답 + TCP 처리 제공 => 리소스 관리 기능 + 서버 관리(설정/통제/확장) 기능
웹 서버 S/W와 H/W 장비 모두 지칭

기능/형태/크기 다양

다목적 소프트웨어 웹 서버

네트워크에 연결된 표준 컴퓨터 시스템에서 동작

Netcraft 웹 서버 시장 점유율 (2020.11)

벤더	점유율	기타
nginx	33.69%	2019.04부터 1위
Apache	26.78%
Microsoft	7.91%
Google	3.71%
Other	28%

임베디드 웹 서버
- 가전제품 등에 내장되는 소형 웹 서버 => 기기를 웹 브라우저로 관리 가능
간단한 서버
- Perl 코드 30줄이면 최소기능 구현 가능

웹 서버 통신 과정

1) 클라이언트 커넥션 수락
- 1-1) 새 커넥션 수립 (지속커넥션 재사용 시 스킵)
  - 요청받은 TCP 커넥션 연결
  - 커넥션에서 IP주소 추출 + 클라이언트 식별 및 인가
  - 연결 성공 시 커넥션 목록에 추가
- 1-2) 클라이언트 호스트명 식별 (hostname lookup)
  - 역방향 DNS 사용해 IP를 호스트명으로 변환
  - 접근제어 및 로깅에 사용
  - 지연 발생 가능 => 특정 리소스로 한정 적용
- 1-3) 클라이언트 사용자 식별
  - IETF ident 프로토콜 지원 시 사용자 이름 확인 가능
    => 서버가 클라이언트에게 사용자 이름을 요청 (포트번호: 113) => 기본값: 하이픈(-)
  - 주의!
    
    지원PC 적음, 지연 발생, 위변조 가능 (폐쇄된 내부망에서만 이용해야)

2) 요청 메시지 수신

데이터 파싱
- 순서: 요청메서드, URI, 버전번호, 메세지 헤더, 본문
- 구분: 개행문자 (CRLF = \r\n)
메세지의 내부 표현
- 요청메세지 조각 포인터/길이: 내부 자료구조에 저장
- 헤더: 룩업테이블에 저장
- => 신속한 처리/접근 가능

커넥션 입/출력 처리 아키텍처

I/O 아키텍처	상세
단일-스레드	요청을 하나씩 순차적으로 처리 => 낮은 성능
멀티스레드	- 여러 요청 동시에 처리 - 메모리/리소스 소비 => 개수제한 필요
다중	- 대량 커넥션을 목록으로 관리 - 처리 필요할 때만 스레드/프로세스 이용
다중 멀티스레드	- 여러 커넥션을 목록으로 관리 - 처리 시 여러 스레드 동시 이용

프로세스: 하나의 독립된 제어흐름
스레드: 프로세스의 독립적인 실행 단위
작업풀: 미리 생성된 스레드 집합이 pool에서 대기
참고: 프로세스 vs 스레드

3) 요청 처리
- 요청의 메소드/리소스/헤더/본문 취득해 처리
4) 리소스 매핑 및 접근
- 문서루트(Docroot)
  - 웹콘텐츠를 위해 예약해둔 서버 파일시스템의 특정 폴더
  - 요청메세지의 URI를 문서루트에 붙여 처리됨
  - 주의!: 상대주소 공격 가능
    ex) http://test.kr/../
  - 가상 Docroot
    
    사이트마다 별도의 문서루트 지정 => IP/호스트명으로 식별 및 처리
  - 사용자홈 docroots
    
    사용자마다 홈 디렉토리에 문서루트 지정 ex) ~diana/index.html
- 디렉토리 목록
  
  폴더 URL에 대한 일반적인 요청 처리
  - 에러 반환
  - index 파일 반환
    ex) Apache DirectoryIndex 설정
  - 탐색된 디렉터리 내용 담은 HTML 반환
    ex) Apache Options 설정
- 동적 리소스 매핑
  
  URI를 요청에 따라 콘텐츠 생성하는 프로그램과 연결해 제공
  ex) Apache의 ScriptAlias, AddHandler 설정
- 서버사이드 인클루드 (SSI)
  
  리소스의 컨텐츠를 전송 전에 처리
  ex) 변수값이나 스크립트 출력값 치환
- 접근제어
  
  각 리소스에 접근제어 할당 가능 ex) IP/비밀번호 등 확인

5) 응답 메세지 생성: 리소스 식별 후 요청메서드의 동작 수행 후 응답메세지 반환

응답 엔티티 구성
- Content-Type 헤더: 응답본문의 MIME타입
- Content-Length 헤더: 응답본문의 길이
- 실제 본문

MIME 타입

명칭	상세
mime.types	확장자에 따라 타입계산
매직 타이핑 Magic typing	패턴테이블(매직파일) 참조 + 파일내용 검사해 타입계산
유형 명시 Explicit typing	특정 파일/폴더내 파일에 타입을 일괄 지정 (확장자 무관)
유형 협상 Type negotiation	한 리소스를 클라이언트에 맞춰 여러 포맷으로 제공 ex) 언어, 이미지형식, 인코딩

리다이렉션

케이스	상세	상태코드
리소스가 영구히 이동	클라이언트에게 북마크 갱신 등 안내	301
리소스가 임시로 이동	리다이렉트 하되 북마크 갱신 방지 안내	303, 307
URL 증강	문맥정보 포함된 완전한 URL로 리다이렉트	303, 307
부하 균형	과부하 시 타 서버로 리다이렉트	303, 307
다른 가까운 서버 존재	클라이언트 정보 지닌 다른 서버로 리다이렉트	303, 307
폴더명 정규화	슬래시(/) 누락 시 추가해 리다이렉트

6) 응답 메세지 송신
- 여러 커넥션 존재 가능 => 커넥션 상태 추적 필요
- 주의!: 지속커넥션은 Content-Length 계산 및 종료 확인해야
7) 로깅
- 트랜잭션이 어떻게 수행되었는지 로그파일에 기록

6장 프록시

프록시의 역할

: 클라이언트와 웹서버 사이의 중개자 => 서버/클라이언틑 역할 모두 수행

공용 프록시
- 중앙집중형 관리 방식이 효율적 => 대부분 공용/공유해 사용
- 공통 요청 처리 시 효율 증가
개인 프록시
- 주로 클라이언트PC에서 직접 실행
- 예) 브라우저 확장 기능
게이트웨이와 차이점
- 프록시는 동일 프로토콜로 통신
- 게이트웨이는 여러 프로토콜 변환 ex) HTTP/POP 메일
- but) 상용 프록시는 게이트웨이 기능 있어 차이 미미

프록시의 기능

보안 개선
- 문서 접근제어
- 보안 방화벽: 응용 레벨 프로토콜 통제/감시
성능 증대
- 대리 프록시(Surrogate)
  
  웹 서버처럼 위장해 콘텐츠 검색 및 제공
- 콘텐츠 라우터
  
  트래픽 조건 및 콘텐츠 종류 따라 특정 서버로 유도 => 맞춤형 서비스
- 트랜스코더
  
  콘텐츠 전달 전 본문포맷 수정/압축/변환 가능
비용 절약
- 프록시 캐시: 서버 접근 비용 불필요
트래픽 감시/수정
- 어린이 필터: 필터링 프록시 이용해 성인콘텐츠 차단
- 익명화 프록시(Anonymizer)
  
  HTTP메세지에서 신원식별정보(OS, From, Referer, Cookie) 제거해 익명성 보장

프록시의 배치

명칭	배치 위치	상세
출구 프록시	LAN의 출구	로컬 네트워크와 외부망 사이 트래픽 제어 가능 ex) 방화벽, 인터넷 요금 절약, 어린이 필터
접근(입구) 프록시	ISP 접근 지점	- ISP 사용자 요청 종합적 처리 가능 - 캐시 이용해 속도 개선 및 비용 절감
대리(리버스) 프록시	웹서버 바로 앞	- 웹서버를 대리해 요청 처리 - 필요시에만 웹서버 자원 요청 - 보안 및 캐시 기능 추가 가능
네트워크 교환 프록시	네트워크 사이 인터넷 피어링 교환 지점	캐시 이용해 트랙픽 혼잡 완화 및 감시

프록시의 구조

프록시 계층
- 서버/클라이언트와의 상대적 거리에 따라 계층 구분
- ex) 서버 -> 인바운드(부모) 프록시 -> 아웃바운드(자식) 프록시 -> 클라이언트

유동적 라우팅: 여러 조건/메세지에 따라 부모/캐시/압축 프록시나 원 서버에 라우팅

조건	상세
부하 균형	부모들의 작업량에 따라 선택
지리적 인접성	원 서버의 지역 담당하는 부모 선택
프로토콜/타입	프로토콜/URI에 따라 부모나 원서버로 라우팅
유료 서비스 가입자	가입자인 경우 대형캐시/압축엔진으로 라우팅

부모 선택 로직은 설정/스크립트언어/플러그인 등에 따라 다르게 구현

트래픽 처리: 클라이언트는 보통 웹서버와 직접 대화 => 프록시를 통하도록 만들어야

방법	상세
클라이언트 설정	클라이언트의 수동/자동 프록시 설정을 이용
네트워크 설정	인터셉트 프록시를 이용해 네트워크의 웹트래픽을 가로채고 프록시로 전송
DNS 이름공간 수정	DNS 이름 테이블을 편집하거나 동적 DNS서버를 이용해 모든 요청을 대리프록시로 전송
웹서버 수정	HTTP 리다이렉션 명령(305코드) 이용해 프록시로 리다이렉트 가능

클라이언트 프록시 설정

방법	상세
수동 설정	프록시 사용을 명시적으로 설정
브라우저 기본 설정	브라우저 벤더가 미리 프록시를 설정
프록시 자동 설정	자바스크립트 PAC(Proxy auto-config) 파일 참조해 프록시 사용여부 동적으로 판단
WPAD 프록시	브라우저가 PAC URI 자동 검색하는 WPAD(web Proxy Autodiscovery) 프로토콜 제공

PAC함수
- 함수명: FindProxyForUrl(url, host)
- 반환문자열
  - DIRECT
  - PROXY host:port
  - SOCKS host:port

프록시 요청의 특징

프록시 URI와 서버 URI의 차이
- 서버 요청 시 스킴/호스트 생략된 URI 요청 사용 (HTTP/1.1 규약위반)
- 프록시 요청 시 완전한 URI 요청 사용
인터셉트/대리 프록시의 비가시성
- 인터셉트/대리 프록시는 클라이언트가 인지 못함 => 불완전한 URI 전송됨

URI 수정 규칙

URI 정보	수정방식
완전한 URI	해당 URI 사용
부분 URI + 호스트헤더	호스트 헤더 이용해 원서버 주소 찾기
부분 URI	- 대리프록시: 프록시 설정의 원서버 주소 참조 - 지나온 인터셉트 프록시의 원서버 주소 정보 참조 - 주소 참조 실패시 에러 반환

주의! 정규화하거나 규칙 엄한 경우 상호운용성 문제 발생 가능

URI 자동 완성 및 호스트명 확장 불가

프록시 없을 경우 입력내용을 바탕으로 URI 자동 확장 가능 (URI Resolution)
- 접두사(www.)와 접미사(.com) 추가해 검색
- 오타교정 및 URI 제시하는 서드파티에 전송
- 현재 도메인 주소 이용해 확장

메시지 추적

via 헤더: 메세지가 지나는 중간 노드 정보 나열

기능
- 메세지 전달 추적
- 메세지 루프 진단 (unique 문자열 검사)
  => 프록시는 unique 문자열을 헤더에 반드시 삽입해야
- 모든 노드의 프로토콜 처리 능력 테스트

문법: 콤마(,)로 구분된 각 Via waypoint는 최대 4개 구성요소 포함
ex) Via: 1.1 proxy-62.ai-isp.com, 1.0 cache.wei-netware.com

명칭	상세	비고
프로토콜명	중개자가 받은 프로토콜	기본값: HTTP, 선택사항
프로코톨 버전	표준 버전 번호 사용 ex) 1.0, 1.1	필수사항
노드이름	중개자의 호스트 및 포트 정보 (보안 위해 가명값 사용 가능)	필수사항
노드코멘트	중개자 노드 서술 코멘트 ex) 벤더, 버전정보, 이벤트 진단정보	선택사항

규칙
- 게이트웨이: 이용 시 프로토콜명 바뀌게 됨
- Server 응답 헤더: 원 서버의 소프트웨어 정보이므로 수정하면 안 됨
- 가명교체: 보안 유지 위해 한 조직 내의 경유지 항목은 하나로 합칠 수 있음

HTTP/1.1 TRACE 메소드
- TRACE 응답 통해 프록시 서버 지나며 변경되는 메세지 관찰/추적 가능
  - Content-Type: message/http
  - 상태코드: 200
- Max-Forwards
  - 무한루프 방지 및 특정 프록시만 체크 시 이용 가능
  - 값이 0보다 크면 메세지 전달 시 1 감소된 값으로 갱신
인증
- 상태코드 407(Proxy Authorization Requred) 반환해 접근자격 확인 가능
- 주의! 널리 구현되지는 않은 기능

프록시 상호운용성

: 중개 시 여러 벤더/환경/버그 등에 대응 가능해야

미지원 헤더/메서드 대응
- 미지원 헤더도 반드시 전달
- 헤더 간 상대적 순서 유지 필요
- 미지원 메소드도 반드시 전달 (HTTP/1.1은 메소드 확장 허용)
OPTIONS 메소드
- 서버/리소스의 지원 기능/메소드 확인 가능
- 형식
  - 서버능력 확인: OPTIONS * HTTP/1.1
  - 특정 리소스 확인: OPTIONS http://www.test.kr/index.do HTTP/1.1
  - 응답: 가능한 기능 서술한 여러 헤더필드 + 200 OK 메세지
Allow 헤더
- 해당 서버/리소스의 지원 메소드 열거되는 헤더 필드
- 지원 메소드 추천 위해 요청 메세지에서도 사용 가능 (지원 의무X)
- ex) Allow: GET, HEAD, PUT

7장 캐시

: 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP장치

혜택
- 불필요한 데이터 전송/비용 절감
- 네트워크 병목 감소 => 응답속도 증대
- 서버에 대한 요청/부하 감소
  - ex) Flash Crowds 대응
- 거리 지연 감소

적중

명칭	상세
캐시 적중 (cache hit)	캐시에 대응 사본 있어 요청 처리되는 경우
캐시 부적중 (cache miss)	대응 사본 없어 요청이 원서버로 전달되는 경우

구분: 응답코드는 200(OK)로 동일하므로 Via, Date, Age 헤더 이용 필요

재검사 (Revalidation): 저장된 사본이 최신인지 서버에게 확인하는 요청

요청
ex) GET If-Modified-Since

응답

종류	상세
성공	응답코드 304 (Not Modified)
실패	응답코드 200 (OK) + 최신 객체
객체없음	응답코드 404 (Not Found)

속도

순수 캐시적중 > 재검사 적중 > 재검사 부적중 = 캐시 부적중
적중률
- 캐시(문서) 적중률 = 순수 캐시 적중 건수 / 모든 요청 건수
- 바이트 적중률 = 순수 캐시 적중 (Byte)/ 모든 요청 (Byte)
- 재검사 적중률 = 재검사 적중 건수 / 모든 요청 건수

캐시 토폴로지

개인 전용 캐시 (private cache)
- 작고 저렴
- 웹브라우저에 내장
공용 프록시 캐시 (public cache)
- 여러 사용자 집단이 자주 이용하는 응답 저장
- 브라우저 설정이나 프록시 자동설정 파일로 이용 가능
- 인터셉트 프록시 이용 시 사용 강제 가능
- 더 큰 부모 캐시 만들어 계층적 구성 가능
  but) 연쇄 지연 발생 가능
캐시망
- 부모 캐시 이용 여부 동적으로 결정
  - 기준: URL, 로컬 사본 존재 여부 등
형제캐시
- HTTP는 피어링 지원 안 하므로 확장 프로토콜 이용 필요
  - ICP (Internet Cache Protocol)
  - HTCP (Hypertext Cache Protocol)

토폴로지: 네트워크 객체들의 배치
참고: 캐시정책

캐시 처리 단계

1) 요청 수신
- 커넥션 감지 및 데이터 수신
- 고성능 캐시의 경우 병렬처리 가능
- 메세지 일부 도착한 상태로 처리시작 가능
2) 메세지 파싱
- URL 및 헤더 파싱해 자료구조에 저장
3) 로컬 복사본 검색
- 로컬 캐시 검색하거나 부모프록시/원서버에 요청
4) 신선도 검사
- 일정 시간 지난 사본은 변경점이 있는지 서버에 재검사 요청

5) 응답헤더 생성

캐시된 원서버 응답 헤더를 기반으로 응답헤더 생성

클라이언트에 맞게 헤더를 조정

용도	동작	대상 헤더
신선도 정보	삽입	Cache-Control, Age, Expires
프록시 캐시 정보	삽입	Via
생성일시(원서버)	수정불가	Date

6) 발송
- 클라이언트에게 응답 발송
- 프록시 캐시는 클라이언트와 연결 유지해야
- 고성능 캐시는 로컬 저장소와 네트워크 I/O 버퍼 사이의 복사 회피하기도
7) 로깅 (선택)
- 로그 파일 및 캐시 사용 통계 관리
- ex) 캐시적중/부적중 횟수, 요청종류, URL 등
- 양식
  - Squid Log Format
  - Netscape Extended Common Log Format

신선도 검사

문서 만료: 응답헤더를 이용해 유효기간을 명시 <- 로컬 시계 정확해야

버전	헤더	상세	예시
HTTP/1.1	Cache-Control	문서의 최대 나이 설정 단위: 초	Cache-Control: max-age=484200
HTTP/1.0+	Expires	절대유효기간 명시	Expires: Fri, 13 Dec 2020, 03:00:00 GMT

서버 재검사: 캐시된 사본의 변경점을 서버에게 확인

변경점 존재 -> 사본 갱신
변경점 없음 -> 만료 헤더만 갱신

조건부 메소드: 조건부 GET 요청 이용해 효율적 재검사 가능

헤더	상세
If-Modified-Since (= IMS요청)	특정 시점 이후 변경점 존재하는 경우에만 전송 Last-Modified 응답헤더와 함께 사용
If-None-Match	일련번호/버전 등의 태그가 불일치하는 경우에만 전송 시간에 따른 변경점이 작거나 부정확한 경우 유용

Etag 참고
약한 검사기 (Weak Validator)

약간의 변경점은 같은 것으로 취급, 접두어 “W/”로 구분
ex) Etag: W/”v2.7”
강한 검사기 (Strong Validator)

모든 변경점을 변경값으로 취급해 값 갱신

캐시 제어

방식

명칭/헤더	상세
Cache-Control: no-store Cache-Control: no-cache Pragma: no-cache	no-store:사본 생성 금지 no-cache: 재검사 필수 Pragma: HTTP/1.0+ 호환용
Cache-Control: max-age=0 Cache-Control: s-maxage=6600	max-age: 최대 나이(초) s-maxage: 공유 캐시에만 적용 0인 경우 캐시/리프레시 금지
Expires: Fri, 13 Dec 2020, 03:00:00 GMT (Deprecated)	실제만료시각(현재 규격 아님) 0 설정 불가
Cache-Control: must-revalidate	신선도 만료 시 재검사 강제 원서버 이용 불가시 504(Gateway Timeout) 반환
휴리스틱 만료	Cache-control/Expires 헤더 없는 경우 경험적으로 최대 나이 계산 ex) LM 인자 알고리즘 (수정시각 최근일수록 나이 짧게 설정)

클라이언트 신선도 제약: 브라우저의 리프레시/리로드 버튼으로 강제 갱신/재검사 요청 가능

헤더	상세
Cache-Control: max-stale = `n`	만료시각이 n만큼 지난 문서도 제공 가능
Cache-Control: min-fresh = `n`	지금으로부터 n초 전까지의 문서만 요청
Cache-Control: max-age = `n`	n초보다 오래되지 않은 문서만 요청
Cache-Control: no-cache Pragma: no-cache	재검사한 문섬나 요청
Cache-Control: no-store	매시에 저장 금지 ex) 민감정보 등
Cache-Control: only-if-cached	캐시에 있는 사본만 요청

보통 유효기간 짧음 => 문서변경 반영 가능
DNS와 달리 HTTP는 클라이언트의 만료일 덮어쓰기 및 강제로딩 허용

캐시 제어 설정

Apache
- mod_headers: 개별 헤더 설정
- mod_expires: 만료시각 설정된 Expires 헤더 자동생성
HTTP-EQUIV
- 웹서버 설정 파일과 상호작용 없이 HTTP 헤더 생성 가능
- HTML 파일만 지원
- 서버부하 가중 및 혼란 초래하므로 많은 S/W에서 무시됨 ```
```

신선도 검사 알고리즘

: 나이 < 신선도수명 여부 계산

나이 계산
- 겉보기 나이: 응답수신시각 - 현재시각
- 보정된 나이: 겉보기 나이와 Age 헤더값 중 큰 값
- 점층적 나이 계산: 보정된 나이 - 네트워크 지연 추정값
- 최종 나이: 캐시에 도착했을 때 나이 - 캐시에 머문 시간
신선도 수명 계산

서버/클라이언트의 제약조건 반영해 계산

캐시와 광고

광고회사의 딜레마
- 캐시 이용 시 콘텐츠 제공 비용 감소하나 실제 접근 횟수 알 수 없음
- 접근 별로 URL 변경해 캐시 무력화
- 무력화 대신 캐시가 서버에 적중 보고하게 해야
  => 트래픽 감소 but) 지연 발생
로그 마이그레이션

대형캐시는 로그를 수동 제공하기도
but) 인증/프라이버시 문제 발생 가능
적중측정 및 사용량 제한
- = Simple Hit-Metering and Usage-Limiting for HTTP
- 특정 URL의 캐시적중 횟수를 Meter 헤더에 실어 정기적으로 서버에 전송
- 서버는 캐시의 문서제공횟수/처리시간 제어 가능

Twitter Facebook LinkedIn

Sooyeun Kim