[모든 개발자를 위한 HTTP 웹 기본 지식] 7. HTTP 헤더 1 : 일반 헤더

Network . ..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

인프런 김영한 강사님의 [모든 개발자를 위한 HTTP 웹 기본 지식] 을 수강하고 정리한 글입니다.

모든 개발자를 위한 HTTP 웹 기본 지식 강의 - 인프런

 

📌 HTTP 헤더 개요

✅ HTTP 헤더

HTTP 전송에 필요한 모든 부가 정보를 말한다. 

 

이러한 표준 헤더는 정말 많고, 필요시 임의로 개발자가 추가도 가능하다.

이 수 많은 헤더 중, 이번 글에서는 일반적으로 많이 사용하는 헤더들에 대해 공부한다.

  

  

✅ RFC7230

현재 HTTP의 최신 버전은 바로 RFC7230 버전이다.

HTTP는 버전마다 그 구조도 달라져왔다.

 

HTTP RFC7230 모델 구조

 

메시지 본문(= payload, 페이로드)을 통해 표현 데이터를 전달한다.

 

여기서 표현이 무슨 뜻일까?

 

표현은 요청이나 응답에서 전달할 실제 데이터를 말한다.

 

위 사진의 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.

  

  

 

📌 표현

✅ 표현 헤더

표현 헤더의 종류에 대해 알아보자.

 

표현 헤더는 요청, 응답 모두 사용한다.

  

  

✅ Content-Type

Content-Type

 

Content-Type은 표현 데이터의 형식을 설명한다.

 

보통 미디어 타입, 문자 인코딩 등을 여기에 표시한다.

ex>

text/html; charset=utf-8

application/json

image/png

  

  

✅ Content-Encoding

Content-Encoding

 

Content-Encoding은 표현 데이터를 압축하는 방식이다.

 

데이터를 전달하는 쪽에서 압축을 한 후에 그 압축 방식을 표시하고, 읽는 쪽에서는 표시된 압축 방식을 보고 알맞은 방식으로 압축 해제를 진행한다.

 

ex> gzip, deflate, identity

  

  

✅ Content-Language

Content-Length

 

Content-Language는 표현 데이터의 자연 언어를 표시한다.

 

ex> ko, en, en-US

  

  

✅ Content-Length

Content-Length

 

Content-Length는 표현 데이터의 길이를 의미한다.

 

길이는 바이트 단위이다.

  

  

📌 콘텐츠 협상

✅ 협상 (Negotiation)

협상은 클라이언트가 선호하는 표현을 서버에 요청하는 것이다.

 

클라이언트가 선호하는 표현을 서버에 제시하고, 서버는 환경이 되는 한 그 클라이언트의 선호도를 맞춰주려고 노력한다.

이러한 과정이 일상의 협상 처럼 보인다.

 

협상은 클라이언트의 선호를 서버로 요청하기 때문에, 요청 시에만 사용이 가능하다.

 

협상 종류	설명
Accept	클라이언트가 선호하는 미디어 타입
Accept-Charset	클라이언트가 선호하는 문자 인코딩
Accept-Encoding	클라이언트가 선호하는 압축 인코딩
Accept-Language	클라이언트가 선호하는 자연 언어

  

  

✅ Accept-Language의 작동 방식

Accept-Language의 기본적인 작동 방식

 

기본적으로 Accept-Language의 작동 방식은 위와 같다. 

위 예시에서 클라이언트는 한국어를 선호한다고 서버에 알리고, 서버는 본인이 가능한 능력 내에서 한국어를 제공할 수 있으므로 제공한다.

 

서버가 클라이언트의 선호하는 것을 해결해줄 수 없을 때

 

그러나 위처럼 서버가 클라이언트의 선호하는 부분을 맞춰줄 수 없다면, 단순히 서버의 Default 값으로 진행되게 된다.

 

이 문제를 어떻게 해결할까?

  

  

✅ 협상과 우선순위

위에서 클라이언트의 선호 방식을 서버가 해결해줄 수 없을 때 클라이언트의 선호 방식이 맞춰지지 않아 문제가 있었다.

이를 해결하기 위해, 

Quality Values(q)를 사용한다.

 

Quality Value는 0과 1 사이의 유리수로, 우선순위를 표시한다.

1에 가까울 수록 즉, 클수록 우선순위가 높다.

생략하면 기본값으로 1을 지정한다.

 

Quality Value를 통해 위에서 곤란했던 문제도 어느정도 해결된다.

 

Quality Value를 활용한 Accept-Language

 

 

이번엔 Accept-Language 대신 Accept를 보자.

 

Quality Value를 활용하지 않은 Accept

 

위의 경우(Quality Value 사용 X)에는 구체적인 것이 우선된다.

따라서 우선순위는 아래와 같다.

1. text/plain;format=flowed

2. text/plain

3. text/*

4. */*

 

Quality Value를 사용하면 명확해진다.

Quality Value를 활용한 Accept

  

  

📌 전송 방식

✅ 단순 전송

단순 전송

 

단순 전송은 컨텐츠의 길이를 클라이언트가 알고있을 때, 이를 지정해서 전송하는 것을 의미한다.

  

  

✅ 압축 전송

압축 전송

 

압축 전송은 서버에서 메시지를 압축해서 전송하는 것을 말한다.

이 때 압축 방식을 표기하면, 서버에서 표기된 압축 방식을 확인하고 알맞은 방식으로 압축 해제를 진행할 수 있다.

  

  

✅ 분할 전송

분할 전송

 

분할 전송은 메시지를 분할하여 각각 따로 전송하는 방식이다.

  

  

✅ 범위 전송

범위 전송

 

범위 전송은 메시지의 범위를 바이트 단위 기준으로 정하여 그 부분만 전송하는 방식이다.

 

범위 전송은 이럴 때 쓰인다.

원래 보내던 전송이 중간에 끊겼을 때, 다시 처음부터 보내면 낭비가 있으므로 끊긴 부분부터 범위를 설정하여 재전송한다.

  

  

📌 일반 정보

✅ From

From은 유저의 이메일 정보를 말한다.

 

일반적으로 잘 사용되지는 않고, 검색 엔진 같은 곳에서 사용한다.

 

요청에서만 사용한다.

  

  

✅ Referer

Referer은 현재 요청된 페이지의 이전 웹 페이지 주소를 말한다.

 

이 Referer을 사용해서 유입 경로를 분석할 수 있다.

 

요청에서만 사용한다.

  

  

✅ User-Agent

User-Agent

User-Agent는 클라이언트의 애플리케이션 정보를 말한다. (웹 브라우저 정보, 통계 등)

 

User-Agent를 통해 어떤 종류의 브라우저에서 장애가 발생하는지 쉽게 파악할 수 있다.

 

요청에서만 사용한다.

  

  

✅ Server

Server

Server는 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보를 말한다.

 

ORIGIN 서버?
HTTP 통신은 중간에 여러 프록시 서버, 캐시 서버 등을 거친다.
그러한 가짜 서버들 말고, 진짜로 HTTP 요청에 응답해주는 서버를 ORIGIN 서버라고 한다.

 

응답에서 사용한다.

  

  

✅ Date

Date

Date는 메시지가 발생한 날짜와 시간을 말한다.

 

응답에서 사용한다.

  

  

📌 특별한 정보

✅ Host

Host는 요청한 호스트 정보(도메인)을 말한다.

 

HTTP 통신에서 이런 경우가 있다.

• 하나의 서버가 여러 도메인을 처리해야 할 때
• 하나의 IP 주소에 여러 도메인이 적용되어 있을 때

이러한 경우, Host를 활용해서 해결할 수 있다.

 

Host 활용

 

요청에서 필수로 사용해야 한다.

  

  

✅ Location

Location은 페이지 리다이렉션 위치를 말한다.

 

우리는 상태 코드 3XX 에서 Location 헤더에 적힌 위치로 이동시킨다고 배웠었다. 그 때 사용한다.

  

✅ Allow

  Allow는 허용 가능한 HTTP 메서드를 말한다.

Allow

  

  

✅ Retry-After

Retry-After는 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간을 말한다.

 

Retry-After을 통해 서비스가 언제까지 불능인지를 알 수 있다.

 

Retry-After

위 사진처럼 날짜, 초 단위 표기 두 가지 방식이 있다.

  

  

📌 인증

✅ Authorization

Authorization은 클라이언트 인증 정보를 서버에 전달하는 것을 말한다.

 

Authorization

  

  

✅ WWW-Authenticate

WWW-Authenticate는 리소스 접근 시 필요한 인증 방법을 정의한 것을 말한다.

 

WWW-Authenticate

  

  

📌 쿠키

✅ 쿠키 관련 HTTP Header

• Set-Cookie : 서버에서 클라이언트로 쿠키를 전달(응답에 포함)하는 것
• Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청 시에 포함해서 서버에 전달하는 것

  

  

✅ 쿠키 활용

HTTP는 무상태(Stateless)라고 배웠다.

그래서 생겼던 문제가 매번 데이터를 HTTP 요청에 같이 보냈어야 했다.

무상태 HTTP 통신

위 사진처럼 매번 홍길동을 붙여서 보내야한다... 이거 낭비가 크다.

이걸 쿠키가 좀 해결해준다.

 

쿠키를 활용한 로그인

이처럼 처음 로그인할때 서버에서 유저 관련 정보를 Set-Cookie를 통해 쿠키에 저장한다.

그리고 아래처럼 활용한다.

쿠키 활용

쿠키 저장소에 서버가 저장해둔 쿠키를 활용하여 클라이언트에서는 매 HTTP 요청마다 자동으로 쿠키의 유저정보가 실려서 전달된다.

 

그런데 쿠키도 조심해야할 게 있다.

아무래도 노출이 높은 편이다 보니, 보안에 민감한 데이터는 쿠키에 저장하면 안된다.

 

또한 어쨋든 쿠키는 네트워크 트래픽을 추가로 유발한다.

그러므로 최소한의 정보만 활용하자.

만약 서버에 전송하지 않고, 웹 브라우저 내부에서만 데이터를 저장하고 싶다면, 웹 스토리지(LocalStorage, SessionStorage)를 활용하자.

  

  

✅ 쿠키 : 생명주기

Set-Cookie에는 생명주기와 관련된 옵션 두가지가 있다.

 

expires : 만료일이 되면 쿠키 자동 삭제

max-age : 지정 시간 후 쿠키 자동 삭제 (0 또는 음수로 설정하면 즉시 쿠키 삭제)

  

  

✅ 쿠키 : 도메인

도메인은 명시한 문서 기준 도메인에 서브 도메인을 포함하여 명시하는 것을 말한다.

 

예를 들어 domain = example.org로 설정한다면, 

쿠키는 example.org와 dev.example.org 둘다 쿠키에 접근한다. (서브 도메인)

 

반면 별다른 설정을 하지 않으면 example.org 만 쿠키에 접근하고, 서브 도메인은 접근하지 않는다.

  

  

✅ 쿠키 : 경로

쿠키에 경로 옵션을 달면, 

해당 경로를 포함한 하위 경로 페이지에만 쿠키를 접근한다.

  

  

✅ 쿠키 : 보안

보안과 관련된 쿠키의 옵션을 알아보면,

 

Secure

• https인 경우에만 전송한다.

HttpOnly

• HTTP 전송에만 사용할 수 있다.
• JS에서는 접근 불가능하다. (document.cookie 방식)

SameSite

• 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송한다.