모든 개발자를 위한 HTTP 웹 기본 지식 - HTTP 헤더1(일반헤더)

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

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

 

목차

• 인터넷 네트워크

• URI와 웹 브라우저 요청 흐름

• HTTP 기본

• HTTP 메소드

• HTTP 메소드 활용

• HTTP 상태코드

• HTTP 헤더1(일반헤더)

• HTTP 헤더2 : 캐시와 조건부 요청

 

1. HTTP 헤더 개요

header-filed 문법

filed-name ":" OWS field-value OWS (OWS :  띄어쓰기 허용, filed-name은 대소문자구분이 없다)

강의자료

용도

HTTP 전송에 필요한 모든 부가정보를 전달한다. 필요시 임의의 헤더를 추가할 수도 있다.
부가정보 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등

임의의헤더 예) helloworld: hihi

과거의 헤더분류

과거(RFC2616)에는 메시지 본문이 엔티티 본문을 전달하는데 사용되었으며, 엔티티 헤더는 엔티티 본문 데이터를 해석할 수 있는 정보(데이터타입, 길이, 압축)를 제공했다

 

- General 헤더: 요청/응답에 관계없이 메세지 전체에 적용되는 정보 
- Request 헤더: 요청 정보
- Response 헤더: 응답 정보
- Entity 헤더: 엔티티 바디 정보 (Content-Type, Content-Length)

 

표현(Representation)의 등장

2014년 RFC7230~7235가 등장하면서 엔티티 바디라는 개념이 사라지고 엔티티의 개념은 표현(Representation)으로 변경되었다. 표현은 표현 메타데이터와 표현 데이터의 합친 개념이다.

- 최신 스펙(RFC7230)에선 메시지 본문을 통해 표현 데이터를 전달한다는 개념으로 사용된다.
- 메시지 본문 = 페이로드(payload)
- 표현 : 전달할 실제 데이터
- 표현헤더 : 표현 데이터를 해석할 수 있는 정보(데이터유형, 길이, 압축정보)

 

2. 표현과 관련된 헤더

표현이란 리소스가 전송할 때 데이터 타입을 어떤 방식으로 표현한다는 개념으로 사용된다. 클라이언트-서버 간 데이터를 주고받을 때 데이터 타입은 미리 약속된 형태로 변환해서 주고받게 되는데, 해당리소스를 HTML, XML, JSON 등으로 표현해 전달한다.

헤더 요소 
- Content-Type : 표현 데이터의 형식을 표현한다. 미디어 타입, 문자인코딩 방식이 들어간다.
  ex) Content-Type : text/html;charset=utf8 || application/json || Content-Type : image/png
- Content-Encoding : 표현 데이터의 압축방식(인코딩). 데이터를 전달하는 곳에서 압축해서 보내는 경우 압축에 대한

                                  인코딩정보를 전송, 압축해제시 사용
  ex) Content-Encoding : gzip || deflate || identity
- Content-Language : 표현 데이터의 자연언어. 클라이언트에서 사이트 접속시 언어 변경과 같은 기능을 제공할 수 있다.
  ex) Content-Language : ko || en || en-US
- Content-Length : 표현 데이터의 길이(byte단위). 

표현헤더는 전송,응답에 모두 사용된다.

 

3. 협상헤더(Content Negotiation)

클라이언트가 원하는 표현정보를 담아 요청에 보낸다(요청시에만 사용). 서버는 최대한 클라이언트가 원하는 표현을 만족하는 응답을 주도록 노력한다.

 

헤더 요소

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

 

협상헤더 ex) 한국어 브라우저로 외국 사이트로 이동하는 경우 클라이언트가 협상헤더에 Accept-Language: ko를 보내게 되면 서버가 처리가능한 경우 처음부터 한국어 번역 페이지가 나온다.

강의자료

 

협상과 우선순위, Quality Values(q)

서버측 기본언어가 독일어, 지원언어가 영어인 경우 Accept-Language: ko에 대해 한국어로 번역된 페이지를 제공할 수 없다. 이 때 Accept-Language에 우선순위를 두어 전송하게 되면, 서버가 이를 참고해 영어로된 페이지를 전송해준다.

강의자료

Quality Values(q) 값을 이용하는 경우
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7 (0~1, 클수록 높은 우선순위, 생략시 1,)
1. ko-KR;q=1 (q생략)
2. ko;q=0.9
3. en-US;q=0.8
4. en:q=0.7

 

구체적인 것을 우선하는 경우

Accept: text/*, text/plain, text/plain;format=flowed, */*
1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

 

4. 전송방식

- 단순 전송 : 요청에 대한 응답을 한번에 받는다. Content-Length를 지정해서 전송하기 때문에 Content 길이를 알고있어야한다.

- 압축 전송 : Content-Encoding을 이용해 응답을 전송하는 경우

- 분할 전송 : 용량이 큰 경우 헤더에 Transfer-Encoding: chunked 지정, 메세지를 분할해 전송한다. 클라이언트는 분할되어 보내진 전송 일부를 미리 받아볼 수 있지만 길이를 예상할 수 없으므로 Content-Length사용 불가

- 범위 전송 : 전송 중 오류로 인해 재전송 하는 경우 Content 일부만 전송하도록 요청한다.

  ex) 클라이언트에서 Range: bytes=1001-2000으로 요청한 경우 서버측에선 Content-Range: bytes 1001-2000/2000(끝 길이) 전송

 

5. 일반정보를 공하는 HTTP 헤더

- From : 유저 에이전트의 이메일 정보 제공. 일반적으로 잘 사용되지 않으며 검색엔진에서 주로 사용한다.

- Referer : 현재 요청된 페이지의 이전 웹 페이지 주소정보 제공, 요청에서 사용한다. A -> B 사이트로 이동하는 경우 B를 요청할 때 referer : A를 포함해 요청. 유입경로를 분석할 때 사용된다.

- User-Agent : 클라이언트 애플리케이션 정보(웹 브라우저 정보), 요청에서 사용한다. 서버측에서 로그를 통계분석해 특정 브라우저에서만 발생하는 오류를 발견할 수 있다.

- Server : 요청을 처리하는 ORIGIN 서버의 SW 정보. 응답에서 사용한다.

- Date : 메세지가 발생한 날짜와 시간. 응답에서 사용(과거에는 요청/응답 모두사용)

 

* ORIGIN 서버 : 클라이언트가 보낸 요청에 처음으로 응답한 서버

 

6. 특별한 정보를 제공하는 HTTP 헤더

- Host : 요청에서 사용하는 필수헤더. 하나의 서버가 여러 도메인을 처리중일 때 들어오는 요청을 처리할 도메인을 구분하기 위해 사용한다.

- Location : 3xx 응답결과에 Location 헤더가 있으면 Location 위치로 자동 리다이렉트한다. 201 Created 에서 또한 생성된 리소스 URI를 Location 값으로 전달한다.

- Allow : 허용가능한 HTTP 메서드. 지원하지 않는 메서드로 요청이 들어오는 경우 405 (Method Not Allowd) 에서 응답에 허용하는 메서드 정보를 보내준다.

- Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야하는 시간정보(날짜 혹은 초단위 표기) 제공. 503 (Service Unavailable)오류 시 서비스가 언제까지 불능인지 알려줄 수 있음

 

7. 인증과 관련된 헤더

- Authorization : 클라이언트 인증정보를 서버에 전달한다.

- WWW-Authenticate : 리소스 접근시 필요한 인증방법 정의. 인증에 문제가 있는 경우 401 (Unauthorized) 와 함께 사용.

 

8. 쿠키

쿠키를 사용하지 않을 때 발생하는 문제점과 쿠키의 역할, 보완점을 알아본다.

set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답)
Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고 HTTP 요청시 서버로 전달

 

HTTP는 무상태 프로토콜이므로 전송이 종료되면 서버가 클라이언트의 정보를 가지고 있지 않다. 그렇기 때문에 사용자가 로그인된 상태라도 서버는 요청을 보낸 사용자를 구분할 수 없다. 모든 요청에 사용자 정보를 포함시켜 전송하게되면 이를 해결할 수 있지만, 성능과 보안적측면, 개발의 어려움을 고려하면 바람직한 해결책이라고 볼 수 없다.

 

 

쿠키의 등장
서버가 사용자 정보를 담은 Set-Cookie를 응답에 보낸다. 
웹브라우저는 Set-Cookie정보를 저장하여 해당 서버에 보내는 요청마다 쿠키 저장소에서 저장된 정보를 가져와 Cookie 헤더를 추가해 "자동으로" 보낸다.

그러나 모든 요청에 정보를 보내게되면 보안적인 취약점이 발생할 수 있기 때문에 몇가지 제약(세션ID, 쿠키만료, 허용경로, 허용도메인, 보안정보)을 주어 전송한다.


쿠키 사용처
1) 사용자 로그인 세션 관리
보안적 측면을 고려해 사용자 정보를 그대로 전달하지 않고 세션 키(세션ID)를 서버 DB에 저장해두었다가 클라이언트에 반환해준다. 서버는 클라이언트가 보낸 세션ID와 DB상의 세션 ID를 비교하여 사용자를 식별한다.

2) 광고 정보 트래킹


쿠키의 단점
쿠키는 서버에 항상 전송되기 때문에 네트워크 트래픽을 유발할 수 있다. 이를 방지하기 위해 최소한의 정보만(세션ID, 인증 토큰)을 보내거나 쿠키를 서버에 전송하지 않고 웹브라우저상에 저장해두었다가 사용하는 웹 스토리지를 이용한다.


쿠키 - 생명주기(Expires, max-age)
Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
만료일이 되면 쿠키 삭제
Set-Cookie: max-age=3600 (3600초)
0이나 음수를 지정하면 쿠키 삭제

세션쿠키 : 만료날짜를 생략하면 브라우저 종료시 까지 쿠키 유지
영속쿠키 : 만료날짜 입력시 해당 날짜까지 쿠키 유지


쿠키 - 도메인(Domain)
쿠키를 모든 사이트에 보내지 못하도록 도메인을 지정한다.
도메인을 명시하게되면 명시한 문서 기준 도메인 + 서브 도메인을 포함해 전송

도메인을 생략하게되면 서브(하위)도메인에는 쿠키가 접근하지 못한다.

쿠키 - 경로(Path)
경로를 포함한 하위 경로 페이지만 쿠키접근이 가능하다. 일반적으로 루트 경로를
지정해서 도메인에 모두 접근 가능하도록 한다.


쿠키 - 보안(Secure, HttpOnly, SameSite)

Secure

일반적으로 쿠키는 http, https 를 구분하지 않고 전송하지만. Secure를 지정하게 되면 https인 경우에만 전송한다.

HttpOnly
XSS 공격 방지. JavaScript에서 쿠키로의 접근을 막는다. HTTP 전송에만 사용

SameSite
XSRF 공격 방지. 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송한다.

 

 

 

함께보면 좋은 글

Spring - 세션과 쿠키의 차이점