HTTP 헤더
HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용
표준헤더 보러가기
필요 시 임의의 헤더 추가 가능
헤더 형식
<field-name>:<field-value>
JavaScript
복사
field-name은 대소문자 구분 없음
표현 헤더
표현 데이터를 해석할 수 있는 정보를 제공하는 헤더
요청, 응답 둘 다 사용한다.
•
Content-Type : 표현 데이터의 형식
미디어 타입, 문자 인코딩
ex)
Content-Type: application/json
JavaScript
복사
•
Content-Encoding : 표현 데이터의 압축 방식
데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제
•
Content-Language : 표현 데이터의 자연 언어
ex)
Content-Language: ko
JavaScript
복사
•
Content-Length : 표현 데이터의 길이
Transfer-Encoding(전송 인코딩)을 사용하면 Content-Length 사용하면 안됨
ex)
JavaScript
복사
주요 헤더
Request에서 사용되는 헤더
•
From
유저 에이전트의 이메일 정보
일반적으로 잘 사용하지 않고 검색 엔진에서 주로 사용
•
Referer
현제 요청된 페이지의 이전 웹 페이지 주소
유입경로 수집 가능
•
User-Agent
클라이언트의 애플리케이션 정보 (웹 브라우저 등)
•
Host
요청한 호스트 정보
필수 헤더로 하나의 서버가 여러 도메인을 처리해야할 때 호스트 정보를 명시하기 위해 사용
•
Origin
서버로 요청을 보낼 때, 요청을 시작한 주소를 나타냄
origin이 다르다면 CORS에러가 발생
•
Authorization
인증 토큰을 서버로 보낼 때 사용함
'토큰의 종류 + 실제 토큰 문자'를 전송
Response에서 사용되는 헤더
•
server
요청을 처리하는 Origin 서버의 소프트웨어 정보
•
date
메세지가 발생한 날짜와 시간
•
location
페이지 리디렉션
응답에 Location 헤더가 있으면 Location 위치로 리다이렉트
◦
201(Created): Location 값은 요청에 의해 생성된 리소스 URI
◦
3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
•
allow
허용 가능한 HTTP 메서드
405 (Method Not Allowed) 에서 응답에 포함
•
retry-after
유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
협상 헤더
클라이언트가 선호하는 표현을 요청
요청시에만 사용 가능
협상 헤더에서는 원하는 콘텐츠에 대한 우선순위를 지정할 수 있음
•
Quality Values(q)값 사용
•
0 ~ 1, 클수록 높은 우선 순위
•
생략하는 경우는 1
ex)
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8
JavaScript
복사
종류
•
Accept
클라이언트가 선호하는 미디어 타입 전달
•
Accept-Charset
클라이언트가 선호하는 문자 인코딩
•
Accpet-Encoding
클라이언트가 선호하는 압축 인코딩
•
Accept-Language
클라이언트가 선호하는 자연 언어
캐시
데이터나 값을 미리 복사해놓는 임시 장소
캐시가 없다면?
요청시마다 네트워크를 통해 변경되지 않은 데이터를 다운로드 받아야 함
인터넷 네트워크는 매우 느리고 비쌈 → 비용 증가
같은 데이터를 반복해서 불러오므로 로딩 속도가 상대적으로 느림 → 느린 사용자 경험을 제공
캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있음
브라우저에 캐시를 저장할 때는 헤더에 cache-control 속성을 통해 캐시의 유효한 시간 지정 가능
// 캐시 유효 기간. 초 단위
// Expires를 사용해도 되나 더 유연한 max-age를 권장한다. 같이 사용하면 expires는 무시됨
Cache-Control: max-age=60
// 데이터는 캐시해도 되지만 항상 Origin 서버에 검증하고 사용
Cache-Control: no-cache
// 데이터에 민감한 정보가 있으므로 저장하면 안됨
Cache-Control: no-store
JavaScript
복사
장점
•
캐시 가능 시간동안 네트워크를 사요하지 않아도 됨
•
비싼 네트웨크 사용량 줄임 → 비용 절감
•
브라우저 로딩 속도가 빠름 → 빠른 사용자 경험 제공
검증 헤더
Last Modified / If-Modified-Since
캐시 유효기간이 지났지만 변경이 없기 때문에 데이터를 사용해도 되는 상황이라면 검증 헤더 Last Modified를 이용해 캐시의 수정시간을 알 수 있음
요청에 데이터가 마지막으로 수정된 시간정보를 If-Modified-Since 헤더에 포함시킨다.
이를 위해서는 응답 결과에도 데이터 최중 수정일 정보도 Last-Modified 헤더에 담아 보내야 한다.
요청에 If-Modified-Since (If-Unmodified-Since)헤더를 실어 보냄
데이터가 수정되었는지 검증
서버에 있는 해당 데이터가 수정이 되지 않았을 경우, 바디를 제외한 http 헤더 (Last-Modified 포함)만 전송하고 응답메세지에 수정되지 않았음을 알려준다 → 304(Not Modified)
클라이언트는 응답을 받은 뒤 캐시를 갱신해주어 일정시간동안 유효하게 된다.
장점
네트워크 다운로드는 발생하지만 용량이 적은 헤더 정보만 다운로드하므로 실용적
단점
1초 미만 단위로 캐시 조정 불가능
날짜 기반의 로직 사용
날짜가 다르지만 같은 데이터를 수정해서 데이터 결과가 똑같은 경우를 확인 불가
ETag / If-None-Match
캐시용 데이터에 임의의 고유한 버전 이름을 달고 데이터가 변경되면 이 이름을 바꿔 변경 (Hash)를 다시 생성
ETag만 보내서 같으면 유지하고 다르면 다시 받는다.
요청에 ETag값을 If-None-Match (If-Match) 헤더로 보냄
수정되지 않았다면 (수정되었다면) 바디를 제외한 HTTP 헤더만 전송
응답으로 ETag를 헤더로 보냄
브라우저는 캐시 갱신
서버에서 별도의 캐시 로직을 관리하고 싶은 경우 사용
프록시 서버
클라이언트와 서버 사이에 대리로 통신을 수행하는 서버
클라이언트, 혹은 반대로는 서버가 다른 네트워크에 간접적으로 접속 할 수 있기 때문에, 보안, 캐싱을 통한 성능, 트래픽 분산 등의 장점을 가짐
프록시 캐시
서버가 먼 곳에 위치한 경우 프록시 캐시 서버를 도입해 자료를 가져옴
원서버에 접근하는 것보다 훨씬 빠른 속도로 자료를 가져올 수 잇다.
여러 사람이 찾은 자료일수록 이미 캐시에 등록되어 있기 때문에 빠른 속도로 자료를 가져올 수 있음
이때 클라이언트에서 사용하고 저장하는 캐시를 private 캐시
프록시 캐시 서버의 캐시를 public 캐시라 한다.
// 응답이 public 캐시에 저장되어도 됨
Cache-Control: public
// 응답이 해당 사용자만을 위한 것 private 캐시에 저장해야함
Cache-Control: private
// 프록시 캐시에만 적용되는 max-age
Cache-Control: s-maxage
// 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
Age: 60
// 아래부터는 캐시 무효화하는 헤더
// 데이터는 캐시해도 되지만 항상 원 서버에 검증하고 사용
Cache-Control: no-cache
// 데이터에 민감한 정보가 있으므로 저장하면 안됨
Cache-Control: no-store
// 캐시 기간이 유효하면 캐시 사용
// 캐시 만료 후 최초 조회 시 원 서버에 검증해야함
// 원 서버 접근 실패 시 504
Cache-Control: must-revalidate
// HTTP 1.0 하위 호환
Pragma: no-cache
// 확실하게 캐시 무효화 시키고 싶은 경우 모든 지시어 사용해야함
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
JavaScript
복사
