HTTP 프로토콜

HTTP 란?

요청, 응답 메시지에서 부가적인 정보들을 전송하기 위해 사용된다.

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜입니다

HTTP 헤더

http 전송에 필요한 모든 부가정보

• 본문 데이터 관련 정보
• 인증정보
• 브라우저 정보
• 서버 애플리케이션 정보
• 캐시 관련 정보

HTTP 헤더의 구조

Field-Name + : + OWS + Field-Value + OWS

Ows = 띄어쓰기 허용

Field-Name = 대소문자 구문 x

 

HTTP 헤더의 분류

General Header : 메시지 전체에 적용되는 정보

Request Header : 요청 정보

Response Header : 응답 정보

Entity Header : 엔티티 정보(body컨텐츠 정보)

 

General Header

요청 및 응답 메시지 모두에서 사용 가능한 일반 목적의(기본적인) 헤더 항목

Date

HTTP메시지를 생성한 일시

Date: Sat, 2 Oct 2018 02:00:12 GMT

Pragma

캐시제어, HTTP/1.0에서 사용하던 것 HTTP/1.1에서는 Cache-Control이 사용된다.

Cache-Control

캐시를 제어할 때 사용

Connection

클라이언트와 서버 간 연결에 대한 옵션 설정

Ex) Connection: close
현재 HTTP 메시지 직후에 TCP 접속을 끊는다는 것을 알린다.

Ex) Connection: Keep-Alive
현재 TCP 커넥션을 유지한다.

 

connection: keep-alive
- HTTP 1.1버전부터는 keep-alive를 지원한다.
- 하나의 웹사이트에 방문하면 수십개의 자원(css, 이미지, HTML, JS)를 제공한다.
- TCP통신 과정에서 연결 수행/해제 에 리소스가 많이 소요된다. 
- Keep-alive는 이런파일을 하나씩 받기 위해 매번연결을 맺고 끊는것을 방지하고, 정해진 기간동안에 한꺼번에 받아올 수있도록 도와준다.

 

From

유저 에이전트의 이메일정보

Trensfer-Encoding

사용자에게 entity를 안전하게 전송하기 위해 사용하는 인코딩 형식을 지정

Entity Header

본문에 담긴 데이터를 클라이언트와 서버가 서로 잘 이해할 수 있도록 정보를 제공한다.
따라서 메타데이터라고 볼 수 있으며, 전송과 응답 시 모두 사용된다.

Content-Type

표현데이터의 형식

• 미디어타입, 문자인코딩
• text/html, application/json, image/png, charset=utf-8

Content-Encoding

• 데이터를 전달하는 곳에서 압축 후 헤더 추가
• 데이터를 전달받는 곳에서 헤더의 정보로 압축 해제
• gzip deflate identity

Content-Language

표현 데이터의 자연언어

ko en en-US . . .

Content-Length

• Byte 단위 사용
• Transfer-Encoding 사용 시, Content-Length 사용 불가 (이후 설명)

Content-Location

해당 개체의 실제위치를 알려준다.

Content-Disposition

응답 Body를 브라우저가 어떻게 표시해야할지 알려준다.

inline인 경우 웹페이지 화면에 표시, attachment 경우 다운로드한다.

Ex) Content-Disposition: inline
Ex) Content-Disposition: attachment; filename='filename.csv'

default값은 inline으로 web에 전달되는 data라고 생각하면 된다.

다운로드 되길 원하는 파일은 attachment로 값을 설정하고 filename옵션으로 파일명을 지정할 수있다.

Content-Security-policy

• 다른 외부 파일들을 불러오는 경우, 차단할 소스와 불러올 소스를 명시한다.
• XSS 공격에 대한 방어 가능 (허용한 외부 소스만 지정 가능)
• Ex) Content-Security-Policy: default-src https:
  https를 통해서만 파일을 가져온다.
• Ex) Content-Security-Policy: default-src 'self'
  자신의 도메인의 파일들만 가져온다.
• Ex) Content-Security-Policy: default-src 'none'
  파일을 가져올 수 없다.

Location

• 리소스가 리다이렉트(redirect)된 때에 이동된 주소, 또는 새로 생성된 리소스 주소를 명시한다.
• 300번대 응답이나 201 Created 응답일 때 어느 페이지로 이동할지를 알려준다.
  새로 생성된 리소스의 경우
  HTTP 상태 코드 201 Created가 반환된다.
  300번대 응답의 경우
  HTTP/1.1 302 Found Location: /
  이런 응답이 왔다면 브라우저는 / 주소로 redirect한다.

Allow

지원되는 HTTP 요청 메소드

Ex) GET, HEAD, POST

ETag

리소스의 버전을 식별하는 고유한 문자열 검사기 (주로 캐시 확인용)

Last-Modified

리소스를 마지막으로 갱신한 일시 (주로 캐시 확인용)

 

Request Header(요청 헤더)

Host

요청하는 서버 호스트명 및 포트번호

HTTP/1.1 이후부터 Host 필드는 필수 항목이다.

이에 따라 동일 IP 주소를 갖는 단일 서버에 여러 사이트를 구축할 수 있다.

User-Agent

유저 에이전트의 애플리케이션 정보

ex) Mozilla/4.0, Windows NT5.1

Referer

현재 요청된 페이지의 이전 웹 페이지 주소

If-Modified-Since

여기에 쓰여진 시간 이후로 변경된 리소스 취득. 캐시가 만료되었을 때에만 데이터를 전송하는데 사용

Authorization

인증토큰을 서버로 보낼 때 사용하는 헤더

인증 헤더는 인증 정보를 제공하거나, 구체적인 인증 방법 관련 정보를 전달하는 헤더이다

Origin

Origin : 서버로 Post 요청을 보낼 때 요청이 어느 주소에서 시작되었는지 나타내는 값. 경로 정보는 포함하지 않고 서버 이름만 포함

• 이 값으로 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 난다.

Cookie

쿠기 값 key-value로 표현된다.

서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보

Accept

클라이언트가 선호하는 미디어타입

Accept-Charset

클라이언트가 선호하는 문자 인코딩

Accept-Encoding

클라이언트가 선호하는 압축 인코딩

Accept-Language

클라이언트가 선호하는 자연언어

Content Negotiation

협상 헤더는 클라이언트가 선호하는 표현 정보를 요청 시 함께 전달하기 위해 사용한다.

협상 헤더는 요청시에만 사용한다.

• Quality Values 값 사용
• 0 - 1, 클수록 높은 우선순위
• 생략하면 1
• Ex) Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en=0.7
  ( ko-KR > ko > en-US > en 순서로 우선순위가 정해진다.)
• 구체적인 것이 우선한다.
• Accept: text/, text/plain, text/plain;format=flowed, /
  (text/plain;format=flowed > text/plain > text/ > / 순서로 우선순위가 정해진다.)

Transfer Method

단순전송

한번에 요청, 한번에 응답, 데이터의 길이를 알 수 있을때 사용

Content-length를 통해 전송할 데이터의 길이를 명시

압축전송

한번에 요청, 한번에 응답, 데이터를 압축하여 전송할때 사용

Content-length를 통해 전송할 데이터의 길이, Content-Encoding으로 압축방식을 명시

분할전송

Trasnfer-Encoding 헤더에 chunked 명시하여 데이터 분할 여부를 명시

Chunk 단위로 데이터를 분할하여 전송
Content-Length 사용 불가 ❌
\r\n 으로 분할 전송의 끝을 명시

범위전송

요청 시 Range 헤더에 데이터의 범위를 명시하고, 응답 시 Content-Range 헤더에 전송한 데이터의 범위와 총 길이를 명시

데이터의 특정 범위만을 요청 가능
데이터 전송 도중 오류 발생 시, 처음부터 모든 데이터를 다시 요청할 필요가 없음
네트워크 다운로드 용량 절약

 

Response Header(응답헤더)

Server

요청을 처리하는 ORIGIN Server의 소프트웨어 정보

Age

개체가 프록시 캐시에 있었던 시간 정수값.

max-age시간내에서 얼마나 흘렀는지 초 단위로 알려주는 값

Referrer-policy

서버 referrer 정책을 알려주는 값 ex) origin, no-referrer, unsafe-url, strict-origin-when-cross-origin

보안을 위해 사이트요청에 사용할 수 있는 referer데이터를 제한하기 위해서 사용하는 것이 Referrer-Policy

WWW-Authenticate

사용자 인증이 필요한 자원을 요구할 시, 서버가 제공하는 인증 방식

Proxy-Authenticate

요청한 서버가 프록시 서버인 경우 유저 인증을 위한 값

Set-Cookie

서버측에서 클라이언트에게 세션 쿠키 정보를 설정

Expires

• 리소스가 지정된 일시까지 캐시로써 유효함을 나타낸다. 즉, 응답 컨텐츠가 언제 만료되는지를 나타낸다.
• Ex) Expires: Thu, 26 Jul 2018 07:28:00 GMT
• Cache-Control과 별개로 응답에 Expires라는 헤더를 줄 수 있다.
  단, Cache-Control의 max-age가 있는 경우 이 헤더는 무시

Access-Control-Allow-Origin

• 요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 CORS 에러가 발생
  서버에서 이 헤더에 프론트 주소를 적어주어야 에러가 나지 않는다.
• Ex) Access-Control-Allow-Origin: www.zerocho.com
  프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다.
• Ex) Access-Control-Allow-Origin: *
  만약 주소를 일일이 지정하기 싫다면 *으로 모든 주소에 CORS 요청을 허용되지만 그만큼 보안이 취약해진다.

X-Frame-Options

The X-Frame-Options HTTP 응답 헤더는 해당 페이지를 <frame> 또는<iframe>, <object> 에서 렌더링할 수 있는지 여부를 나타내는데 사용됩니다.

• X-Frame-Options: deny
• X-Frame-Options: sameorigin
• X-Frame-Options: allow-from https://example.com/

HTTP 쿠키

쿠키 헤더는 클라이언트와 서버 간 일시적인 연결 유지를 위해 관련 정보를 제공하는 헤더이다.

간단히 정리하면 HTTP 는 Stateless 한 속성을 가지고 있기 때문에 서버의 Scale-out 에서 유리할 수 있지만, 클라이언트와 서버 간 연결 유지가 어렵다는 한계점을 가진다. 따라서 이를 극복하기 위해 쿠키(Cookie)가 등장하게 된 것이다.

HTTP는 무상태(stateless) 프로토콜

• HTTP는 무상태(stateless) 프로토콜이다.
• 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.
• 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.
• 클라이언트와 서버는 서로 상태를 유지하지 않는다.

쿠키 미사용시 대안!

모든요청에 필요한 정보를 포함에서 요청한다.

단점 많은 정보를 요청할때마다 보내야한다.

Set-Cookie

서버에서 클라이언트로 쿠키 정보(세션 ID)를 전달

ex) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure

• 클라이언트가 웹사이트에 요청을 보내면 서버는 해당 클라이언트의 쿠키 정보를 담아 응답 메시지를 전송한다.
• set-cookie 응답 메시지를 받은 클라이언트는 자신의 쿠키 저장소에 쿠키 정보를 저장한다.

Cookie

• 서버로부터 쿠키 정보를 부여받은 클라이언트는 이후 서버에게 요청을 보낼 때마다 해당 정보를 함께 담아 요청 메시지를 전송한다.
• 이 때, 클라이언트는 자신의 쿠키 저장소를 참조하게 된다.
• 다른 페이지로 이동해도 쿠키정보를 얻어올 수있다.
• 자주 사용하는 예 : 사용자 로그인 세션 관리, 광고 정보 트래킹
• 웹 서버는, HTTP 헤더 내 Set-Cookie:란에 셋팅할 쿠키 관련 정보를 실려 보낸다.
  웹 브라우저는, 쿠키를 도메인 서버 이름으로 정렬된 쿠키 디렉토리에 저장한다.

쿠키의 단점

쿠키정보는 항상 서버에 전송됨

• 네트워크 트래픽 추가 유발
• 최소한의 정보만 사용
• 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 사용
• 보안에 민감한 데이터 저장하면 안 됨 (주민번호, 신용카드 번호 등등)

Cookie 관련 파라미터

expires : 쿠키 정보의 만료일

GMT 기준, 초단위로 기재

명시 : 해당 날짜까지 유지 (영속 쿠키)
생략 : 브라우저 종료 시 까지 쿠키 정보 유지 (세션 쿠키)

max-age : 쿠키 정보의 만료일(초단위)

0, 음수(-) : 쿠키 삭제
명시 : 해당 날짜까지 유지 (영속 쿠키)
생략 : 브라우저 종료 시 까지 쿠키 정보 유지 (세션 쿠키)

domain : 쿠키 정보가 적용될 도메인

명시 : 명시한 도메인 + 서브 도메인 모두 적용
생략 : 현재 문서 기준 도메인만 적용

path : 쿠키 정보가 적용될 경로 설정

명시된 경로를 포함한 하위 페이지만 쿠키 적용
일반적으로 path=/ 와 같이 루트로 지정 (한 도메인 안에서 모든 패스에 전송하길 원해서)

보안 관련 옵션들

secure : HTTPS 사용 시에만 쿠키 정보 전달

secure 미적용 시에는 HTTP, HTTPS 구분하지 않음

HttpOnly : 자바스크립트에서 쿠키에 접근 불가

XSS 공격 방지
HTTP 전송에만 사용

samesite : 요청 도메인과 쿠키 정보 내의 도메인이 같은 경우에만 전송

XSRF 공격 방지

캐시

캐시의 장점

• 불필요한 네트워크 다운로드 효과적 감소
• 브라우저 로딩 속도가 빠르다.
• 빠른 사용자 경험

1. 클라이언트가 서버에게 jpg파일을 요청
2. 서버는 body에 파일을 담아 클라이언트로 전송
3. Header, body 포함 메세지 크기 1.1M 가정
4. 클라이언트는 전달받은 파일을 캐시에 저장
5. 이 후 동일한 jpg파일을 요청 시 캐시에서 참조

캐시 관련 헤더

Cache-Control

캐시의 유효시간을 명시하는 헤더, 유효시간이 초과되면 캐시데이터를 사용할수없기 때문에 원칙적으로 다시 네트워크 다운로드를 통해 데이터를 받아와야한다.

• Max-age: 캐시 유효 시간, 초단위
• No-cache: 데이터는 캐시해도 되지만, 항상 origin server에 검증 후 사용
• No-store: 데이터에 민감한 정보가 포함되어있어 저장 불가 혹은 최대한 빨리 삭제
  (보통 캐시를 하면 하드디스크에 저장이 된다. No-store를 사용하면 메모리에서 사용하고 최대한 빨리 삭제)
• Public(프록시 캐시 서버): public 캐시에 저장 가능, 공용이미지
• Private(사용자의 웹 브라우저, 로컬): public캐시에 저장 불가 (기본값)
  사용자 정보
• s-maxage: 프록시 캐시 서버에 적용되는 max-age
• Age : Origin Server 의 응답이 프록시 캐시 서버에 머문 시간(sec)
• must-revalidate : 캐시 만료후 최초 조회시 Origin Server 에 검증

캐시 무효화

캐시를 사용해선 안되는 페이지 경우

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache (HTTP 1.0 하위 호환)

프록시 캐시 에서 원서버로 요청할때 네트워크 단절이 생기는 경우 프록시 캐시서버에서 이전 데이터를 다시 보내주는 경우도 있다.

must-revalidate를 사용하는 경우 프록시캐시서버에서 네트워크 단절이 생기는 경우
504 Gateway timeout를 리턴한다.

검증 헤더

Last-Modified

검증헤더 중 Last-Modified는 데이터의 최종 수정시각을 명시

클라이언트가 캐시 유효기간이 초과된 데이터를 서버에 요청하는 경우,
이를 기준으로 데이터가 수정되었는지 검증할 수 있다.

작동방식

• 캐시에 데이터와 Last-Modified 정보를 저장해 둔다.
• 캐시 마감시간이 끝나면 요청헤더에 if-modified-since 정보로 last-modified 정보를 같이 넘긴다.
• 수정되지 않은경우 응답헤더에 304 not modified로 보낸다.
  (http body가 없음, 수정된게 없기 때문에, 네트워크 부하가 적다.)
• 클라이언트는 전달받은 응답헤더의 유효시간 업데이트, 캐시에 있는 자원을 사용한다.

tip

개발자도구 네트워크 탭에 자원리소스 회색으로 연한건 캐시에서 불러온것이다.

ETag (Entity Tag)

Last-Modified는 단순히 최종시각을 기준으로 검증하기때문에 A -> B -> A 동일한 데이터로 덮어씌어진경우 검증해내지 못한다.

ETag : 해시값 (데이터가 같은경우 같은 해시가 리턴된다. )

ETag를 사용하면 서버에서 별도의 캐시 로직을 관리할 수있다. 클라이언트는 캐시 매커니즘을 모른다.

해시값을 활용하여 콘텐츠를 기반으로 정확하게 검증할수있다.

If-None-Match 와 함께 사용한다.

작동방식

1. 자원 요청시 응답헤더에 ETag를 넣어서 보낸다.
2. 캐시에 유효한 시간과 ETag값을 저장한다.
3. 캐시 시간이 초과한 경우 다시 요청한다. If-None-Match 헤더에 ETag를 포함해서
4. 서버의 Etag와 매치가 되는경우 304응답을 내려준다.

조건부 요청

If-Modified-Since

클라이언트 요청시 사용되며 서버의 데이터 최종 수정 시각과 캐시 데이터의 Last-Modified 를 비교하여 데이터 수정 여부를 확인하기 위해 사용한다.

이 때, 데이터가 수정되지 않았다면 이전 캐시를 재사용하게 되고, 데이터가 수정되었다면 새로운 데이터를 Body 에 담아 전송받게 된다.

If-None-Match

클라이언트 요청시 사용되며 서버의 ETag와 캐시의 ETag를 비교하여 데이터 수정 여부를 확인하기 위해 사용한다.

이 때, 데이터가 수정되지 않았다면 이전 캐시를 재사용하게 되고, 데이터가 수정되었다면 새로운 데이터를 Body 에 담아 전송받게 된다.



참고

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