HTTP 웹 지식 - HTTP 헤더 (일반 헤더)

HTTP 헤더

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

• ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등등..
• 표준 헤더가 무수히 많다.
• 필요시 임의의 헤더를 추가 가능하다. ex) helloworld: hi

HTTP 헤더, 바디의 변화

과거 - RFC2616

헤더를 아래와 같이 분류하였다.

• General 헤더 : 메시지 전체에 적용되는 정보 ex) Connection : close
• Request 헤더 : 요청 정보 ex) User-Agent: Mozila/5.0
• Response 헤더 : 응답 정보 ex) Server: Apache
• Entity 헤더 : 엔티티 바디 정보 ex) Content-Type: text/html, Content-Length: 3423

과거의 HTTP 바디

• 메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용되었다.
• 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터이다.
• 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공한다.
  • 데이터 유형, 데이터 길이, 압축 정보 등등

RFC723x 의 변화

엔티티라는 표현을 없애고 표현(Representation)이라고 한다.

• 표현 Representation = representation Metadata + Representatino Data

• 메시지 본문(message body)을 통해 표현 데이터를 전달한다.
• 메시지 본문 = 페이로드(payload)
• 표현은 요청이나 응답에서 전달할 실제 데이터이다.
• 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.
  • 데이터 유형, 데이터 길이, 압축 정보 등

표현(Representation) 헤더

헤더에는 아래와 같은 정보가 들어간다.

• Content-Type : 표현 데이터의 형식
• Content-Encoding : 표현 데이터의 압축 방식
• Content-Language : 표현 데이터의 자연 언어
• Content-Length : 표현 데이터의 길이

표현 헤더는 전송, 응답 둘 다 사용한다.

Content-Type

표현 데이터의 형식을 나타낸다.

미디어의 타입, 문자 인코딩 방식이 들어간다.

• text/html; charset=utf-8
• application/json
• image/png

Content-Encoding

표현 데이터를 압축하기 위해 사용한다.

데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가하고 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제하는 방식이다.

• gzip
• deflate
• identity

Content-Language

표현 데이터의 자연 언어를 표현한다.

• ko
• en
• en-US

클라이언트에 표현되는 언어를 변경하는 등의 작업을 수행할 수 있다.

Content-Length

표현 데이터의 길이를 나타내며 바이트 단위이다.

Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안된다.

협상(콘텐츠 네고시에이션) 헤더

클라이언트가 원하는 표현을 요청한다.

• Accept : 클라이언트가 선호하는 미디어 타입 전달용도
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연 언어

협상 헤더는 요청시에만 사용한다. 물론 서버는 클라이언트가 요청하는 형태로 100% 줄 수는 없겠지만 최대한 반영하라는 느낌의 요청.

서버는 기본으로 영어를 보내고 한국어도 지원한다. Accept-Language 적용 전에는 클라이언트의 선호 정보가 없기 때문에 기본 언어인 영어로 보내게 된다.

위와 같은 과정이 협상헤더의 간단한 예시이다.

한국어를 원하는 클라이언트, 그러나 서버는 독일어와 영어만 지원.

이런 상황을 위해 우선순위가 필요하다. => Quality Values(q)

협상의 우선순위?

Quality Values(q)

• 0~1 사이의 값이며 클수록 높은 우선순위를 가진다.
• 생략하면 기본값은 1이다.

위의 복잡한 예시에 이렇게 우선순위를 부여해 보낸다고 가정하면 영어를 받게 된다.

• 구체적인 것이 우선한다.
• ex) Accept: text/*, text/plain, text/plain’format=flowed 의 경우의 우선순위
  1. text/plain/format=flowed
  2. text/plain
  3. text/*

HTTP 헤더의 전송 방식

• 단순 전송
• 압축 전송
• 분할 전송
• 범위 전송

단순 전송

단순하게 전체 데이터(3423 길이의)를 바로 담아 보낸다.

압축 전송

압축해서 보내는 방식이다. 이런 경우 Content-Encoding: gzip 처럼 압축 정보를 같이 보내주어야 한다.

분할 전송

어떤 용량이 큰 데이터를 분할해 전송한다. (\r\n은 끝 이라는 의미이다.)

분할 전송의 경우는 Content-Length를 넣으면 안된다. 분할 전송을 할 때 데이터의 길이가 포함되어 있다.

범위 전송

범위를 지정해 전송하는 것을 의미한다.

예를 들어 어떤 이미지를 다운받다가 끊겼는데 남은 용량을 다시 받을 때 처음부터 다시 받으면 낭비가 있으니 그런 경우 이어받는게 효율적이다. 이럴 때 사용한다.

일반 정보

• From: 유저 에이전트의 이메일 정보
  • 일반적으로 잘 사용되지 않는다.
  • 검색 엔진 같은 곳에서 주로 사용한다.
  • 요청에서 사용한다.
• Referer: 이전 웹 페이지 주소
  • 정말 많이 쓰인다.
  • A -> B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청한다.
  • Referer을 사용해 유입 경로를 분석할 수 있다.
  • 요청에서 사용한다.
• User-Agent: 유저 에이전트 애플리케이션 정보
  • user-agent: Mozila/5.0 Chrome/86.0.4240.183
  • 클라이언트의 애플리케이션 정보 (웹 브라우저 정보 등등)
  • 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능하다.
  • 요청에서 사용한다.
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
  • Server: Apache/2.2.22
  • 응답에서 사용한다.
• Date: 메시지가 생성된 날짜
  • Date: Tue, 15 Nov 1994 08:12:31 GMT
  • 응답에서 사용한다.

특별한 정보

• Host: 요청한 호스트 정보(도메인)
  • Host: www.google.com
  • ★필수이다.
  • 요청에서 사용한다.
  • 하나의 IP 주소에 여러 도메인이 적용되어 있는 경우가 있는데 이럴 때 구분지어줄 수 있다.
  • Host가 없다면 IP만으로 통신하기 때문에 어떤 도메인에 들어온 요청인지 구분할 수 없다.
• Location: 페이지 리다이렉션
  • 3xx 응답의 결과에 Location 헤더가 있다면 자동 이동한다.
  • 201(Created)에서는 요청에 의해 생성된 리소스 URI를 의미한다.
• Allow: 허용 가능한 HTTP 메서드
  • 405(Method Not Allowed) 에서 응답에 포함해야 한다.
  • Allow: GET, HEAD, PUT 이런식으로 사용한다. (POST 요청 시 405 발생)
• Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
  • 503 (Service Unavailable) 에서 서비스가 언제까지 불능인지 알려줄 수 있다.

인증 헤더

• Authorization: 클라이언트의 인증 정보를 서버에 전달한다.
  • Authorization: Basic xxxxxxxxxx
• WWW-Authenticate: 리소스 접근시 필요한 인증 방법을 정의한다.
  • 401 Unauthorized 응답과 함께 사용한다.

쿠키

• Set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답)
• Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 자동으로 바로 응답.

쿠키를 사용하지 않는 경우의 예시를 보자.

HTTP는 Stateless 하다. 따라서 클라이언트의 상태를 저장하지 않기 때문에 로그인한 사용자인지 구분할 수 없는 것이다.

물론 모든 요청과 링크에 지속적으로 사용자 정보를 포함하는 방식으로 해결할 수는 있다. 하지만 이는 성능저하, 보안문제 등등 다양한 문제가 발생한다.

이러한 문제를 해결하기 위해 쿠키를 사용한다.

유저가 로그인을 하면 서버에서는 쿠키를 세팅해 Set-Cookie를 통해 key-value 형태의 쿠키를 응답헤더에 담아 보낸다.

쿠키를 받은 클라이언트는 웹 브라우저 내부의 쿠키 저장소에 쿠키를 넣고 다음 요청 시 부터는 매 요청마다 쿠키를 서버에 전달하게 된다.

쿠키의 특징

• 사용처
  • 사용자 로그인 세션 관리
  • 광고 정보 트래킹
• 쿠키 정보는 항상 서버에 전송된다.
  • 네트워크 트래픽의 추가 유발이 있다.
  • 따라서 최소한의 정보만 사용해야 한다. (세션 id, 인증 토큰)
  • 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶다면 웹 스토리지를 사용하면 된다.
• 보안에 민감한 데이터는 저장하면 안된다.

쿠키의 생명 주기

• 쿠키는 생명주기가 있고 Expires, max-age를 통해 직접 설정한다.
  • expires => 지정된 만료일이 되면 쿠키를 삭제한다.
  • max-age => max-age = 3600 (3600초), 0이나 음수를 지정하면 쿠키 삭제.
  • 세션 쿠키: 만료 날짜를 생략한다면 브라우저 종료시 까지만 유지한다.
  • 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지하는 쿠키.

쿠키 - domain

• 쿠키는 도메인을 기준으로 저장된다.
  • domain=example.org
  • 명시를 한다면 문서 기준 도메인 + 서브 도메인을 포함한다. (example.org 라면 dev.example.org도 쿠키 적용)
  • 명시를 하지 않는다면 현재 문서 기준 도메인만 적용한다. (example.org 에서만 쿠키 접근)

쿠키 - path

• path를 지정하면 이 경로를 포함한 하위 경로 페이지만 쿠키를 접근한다.
• 일반적으로는 path=/ 와 같이 루트로 지정한다. 보통은 한 도메인 안에서 쿠키를 전송하기를 원하기 때문이다.
• path=/home 이라면.
  • /home: 가능
  • /home/level1: 가능
  • /home/level1/document: 가능
  • /hello: 불가능

쿠키의 보안

• Secure
  • 쿠키는 http, https를 구분하지 않고 전송한다.
  • Secure를 적용하면 https인 경우에만 전송한다.
• HttpOnly
  • XSS 공격 방지
  • 자바스크립트를 통한 접근 불가
  • HTTP 전송에서만 사용하도록 한다.
• SameSite
  • XSRF 공격 방지
  • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송 가능하도록 한다.