HTTP-Header

HTTP-Header

WEB

HTTP 헤더(Header)는 HTTP 요청과 응답에 추가되는 메타데이터입니다.

Header를 통해 클라이언트와 서버는 HTTP 메시지의 내용이나 처리 방식 등에 대한 정보를 교환할 수 있습니다.

 

HTTP Header 유형

주요 HTTP 헤더 유형은 다음과 같습니다.

General Header

메시지 전체에 적용되는 정보 ex) Connection: keep-alive

Request Header

 

요청 정보 ex) User-Agent: agent

 

Response Header

 

응답 정보 헤더(Server, Set-Cookie 등)

Representation Header

 

본문(Body) 해석 정보 헤더(Content-Type, Content-Length 등)

Entity Header

 

리소스 body에 대한 메타데이터(Allow, Content-Encoding 등)

 

이외에도 보안, 인증, 캐시 관리 등을 위한 다양한 Header 가 사용됩니다. Header 값을 조작하거나 추가/삭제할 경우 통신 방식이나 결과가 달라질 수 있습니다.

클라이언트와 서버는 서로 지원하는 Header와 값을 확인하고 알맞게 처리할 수 있어야 합니다. 표준 Header 이외에도 서비스나 애플리케이션 특성에 맞춰 Custom Header를 마음대로 자유롭게 정의하여 사용할 수 있습니다.

 

본문(Body) 해석 정보 헤더(Content-Type, Content-Length 등)

 

Entity Header 

 

리소스 body에 대한 메타데이터(Allow, Content-Encoding 등) 이외에도 보안, 인증, 캐시 관리 등을 위한 다양한 Header 가 사용됩니다. Header 값을 조작하거나 추가/삭제할 경우 통신 방식이나 결과가 달라질 수 있습니다. 클라이언트와 서버는 서로 지원하는 헤더와 값을 확인하고 적절히 처리할 수 있어야 합니다. 표준 헤더 이외에도 서비스나 애플리케이션 특성에 따라 Custom 헤더를 자유롭게 정의하여 사용할 수 있습니다.

Entity

표현

표현 헤더는 본문 데이터를 해석할 수 있는 정보를 제공합니다.

Content-Type

본문 데이터의 미디어 타입(문서, 이미지 등)과 문자 인코딩 방식을 나타냅니다.

Content-Encoding

본문 데이터의 압축 방식을 나타냅니다. identity는 압축하지 않은 상태입니다.

Content-Language 

본문 데이터의 자연어(한국어, 영어 등)를 나타냅니다.

이러한 표현 Header를 통해 클라이언트와 서버가 서로 본문 데이터의 형식, 압축 방식, 사용 언어 등을 이해할 수 있습니다.

클라이언트는 Content-Type에 따라 본문을 해석할 수 있고 Content-Encoding 정보로 압축 해제가 가능합니다. 서버도 마찬가지로 클라이언트의 데이터를 제대로 해석할 수 있습니다.

 

캐시

브라우저에서 자주 사용하게 되는 Data나 값을 복사해서 저장해 놓는 임시 장소입니다.

 

캐시가 없다면 어떻게 될까요?

 

반복된 리소스 다운로드

캐시가 없다면 이미 다운로드가 완료되어 받은 리소스(이미지, CSS, JS 파일 등)도 계속해서 서버에서 다시 받아오게 되어 이는 불필요한 네트워크 트래픽과 지연 시간을 발생시킵니다.

 

높은 서버 부하

캐시가 없다면 모든 요청을 서버로 보내 처리하게 해야 합니다.  이는 서버에 과도한 부하를 주고  서버 스케일 아웃 비용도 증가시키게 됩니다.

나쁜 사용자 경험

캐시가 없다면 페이지 로딩 속도가 느려지고 불필요한 트래픽으로 인해 요금이 올라갈 수 있습니다. 이는 사용자 경험을 나쁘게 만듭니다.

 

캐시

캐시 적용

 

웹 캐시의 동작 원리와 주요 이점, 만료 후 검증 헤더의 필요성에 대해 더 자세히 알아보도록 합시다.

 

웹 브라우저의 캐시 기능은 이미 다운로드한 리소스를 임시 저장소에 보관함으로써  동일 리소스를 다시 서버에 요청하지 않고도 재사용할 수 있도록 하는 기술입니다. 캐시를 적용하면 서버 트래픽과 부하가 대폭 줄어들 뿐 아니라 사용자는 보다 신속한 페이지 로딩 속도를 경험할 수 있습니다. 특히 모바일 네트워크 환경에서 이 같은 이점이 극대화됩니다.

 

하지만 캐시도 영원히 유효한 것은 아닙니다. max-age와 같은 Cache-Control Header를 사용하여 캐시 만료 시점을 결정짓습니다. 문제는 만료 후의 경우입니다. 서버 데이터가 변경되지 않았다면 불필요한 재다운로드를 피할 수 있겠지만, 변경 사실을 클라이언트가 알 방법이 없습니다. 바로 이때 검증 Header(Validators)가 동원되어 캐시와 서버의 리소스 일치 여부를 확인하고 조건부 요청을 통해 트래픽을 최적화할 수 있는 것입니다.

 

ETag

ETag는 웹 캐시 검증을 위한 강력한 도구라고 할 수 있습니다.

Last-Modified 헤더의 타임스탬프 기반 접근에는 한계가 있습니다. 서버 데이터 변경 시점을 놓치거나, 의도하지 않은 캐시 재검증 요청이 발생할 수 있습니다.

 

이를 보완하기 위해 ETag가 도입되었죠. ETag 값은 리소스 별 고유의 지문(fingerprint)과 같은 형태로, 내용의 변경 여부를 더 정확하게 인식할 수 있도록 해줍니다.

 

세부 구현은 전적으로 서버 애플리케이션의 몫입니다. 확장성 있는 캐시 관리 로직을 직접 개발할 수 있고, 콘텐츠 압축 등 복잡한 시나리오에서도 변경 감지를 보장받을 수 있습니다.

 

If-None-Match 헤더를 사용하여 ETag 값을 전달하면, 서버는 조건부 GET을 판단하고 리소스 일치 시 304 Not Modified를 응답으로 보내줍니다.

 

결국 ETag를 통해 서버는 캐시 제어권을 가져가고, 클라이언트는 불필요한 다운로드를 최소화할 수 있는 것입니다.

프록시 캐시

우리가 서버에 데이터를 요청할 때 원(origin) 서버에 접근을 하게 됩니다.  지리적으로 멀리 위치한 원 서버일수록 미약하지만 시간이 더 소요되게 됩니다.

그래서 이 데이터 요청과 응답의 소요시간을 줄이기 위해서 중간에 프록시 캐시 서버를 두어 네트워크 요청이 이루어지게 됩니다.

 

캐시 너무나도 유용한 기능입니다. 개발자가 캐시 사용을 적절하게 한다면 웹 성능과 사용자 경험 향상에 엄청난 효과를 얻을 수 있습니다.