모든 개발자를 위한 HTTP 웹 기본 지식 - HTTP 기본

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

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

 

목차

• 인터넷 네트워크

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

• HTTP 기본

• HTTP 메소드

• HTTP 메소드 활용

• HTTP 상태코드

• HTTP 헤더1(일반헤더)

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

 

HTTP(HyperText TransferProtocol)

과거에는 링크를 통해 문서 간 연결할 수 있는 하이퍼텍스트를 전송하는 데 사용되었지만, 현재는 모든 형태의 데이터를 HTTP로 전송할 수 있다. HTML, 텍스트, 이미지, 음성, 영상, 파일, JSON, XML 심지어 서버 간 데이터를 주고받을 때도 특수한 경우를 제외하면 TCP 가 아닌 HTTP를 사용한다.

 

HTTP 역사

HTTP/1.1이 가장 많이 사용되며, 문서 혹은 책들이  RFC2616 버전을 기준으로 많이 설명하고 있다. HTTP/1.1과 HTTP/2는 TCP를 기반으로 통신하지만 HTTP/3은 UDP를 기반으로 통신한다.

HTTP/0.9 1991년 - 당시 버전 존재x, 정식 버전과 구분을 위해 붙여짐. GET 메서드만 지원, HTTP 헤더 존재 X
HTTP/1.0 (RFC 1945) 1996년 -  메서드, 헤더, HTTP 응답 코드, 리다이렉트, 비지속 연결 등 개념 도입
HTTP/1.1 1997년 - HTTP/1.0기능 향상, 현재 가장 많이 사용
   > 버전 변화 :  RFC2068 (1997) -> RFC2616 (1999)  -> RFC7230 ~ 7235 (2014)

HTTP/2 2015년 - 성능개선
HTTP/3 (진행중) - TCP 대신 UDP 사용, 성능개선

 

HTTP의 특징

1. 클라이언트-서버 구조 동작

클라이언트는 서버에 요청을 보내고 응답을 받을 때까지 대기하며 서버는 요청에 대한 결과를 응답하는 방식으로 동작한다. 클라이언트와 서버가 개념적으로 분리됨으로써 양쪽이 독립적으로 발전할 수 있다는 장점을 가지고 있다.

 

따라서 서버는 비즈니스 로직 또는 데이터를 처리하며 클라이언트는 사용성(사용자 환경)만을 생각하면 된다. 만약, 트래픽이 증가하게 되더라도 클라이언트가 이를 대응할 필요가 없으며 백엔드 언어가 변경되더라도 클라이언트는 해당 사실을 몰라도 된다.

 

2. stateless protocol

전송 과정에서 데이터를 많이 보낸다는 단점이 있지만, 일반적으로 웹 애플리케이션 설계 시 stateless로 설계하며 상태 유지는 최소한으로 한다.

ex) 로그인 상태를 유지하기 위해 브라우저의 쿠키와 서버의 세션을 이용

2.1. Stateful (TCP)

- 서버가 클라이언트의 상태를 유지한다. 

- 클라이언트는 하나의 서버와 계속 통신하며 서버와 연결이 끊기면 다른 서버에서 이전 통신과정을 다시 반복해야 한다.

- 클라이언트가 서버를 점유하고 있기 때문에 서버 증설에 어려움이 있다.

2.2. Stateless (HTTP)

- 서버가 클라이언트의 이전 상태를 보존하지 않는다.

- 서버가 바뀌어도 클라이언트가 이전 통신정보를 함께 요청하기 때문에 응답할 수 있다.

- 트래픽 증가에 따른 스케일 아웃(서버 확장)에 유리하다.

 

3. 비연결성

TCP/IP는 서버에 복수의 클라이언트가 접속해도 기존 클라이언트의 연결을 유지하지만 메시지를 주고받지 않을 때도 연결을 유지하는데 자원이 계속 소모된다는 단점이 있다.

HTTP는  요청-응답이 이루어진 후 연결을 끊어서 연결을 유지하는데 서버 자원이 사용하지 않기 때문에 최소한의 자원으로 서버를 유지할 수 있다.

  ex) 1시간 동안 서비스를 이용하는 사람이 수천 명이라도 수천 명의 사용자가 동시에 접근하지 않기 때문에 서버에서 동시에 처리하는 요청은 수십 개 이하이다.

 

3.1. 비연결성의 한계와 극복

- 연결을 맺을 때마다 TCP/IP 연결 (3 way handshake)을 수행해야한다.

- HTML, css, js, image와 같은 자원을 함께 응답받는다.

- 현재는 HTTP 지속 연결을 이용해 문제 해결 및 HTTP/2, 3에서 최적화가 더 이루어졌다.

 

3.1.1. HTTP 초기 수행 예시

HTML을 읽는 도중 css, js를 얻기 위해 연결/해제를 반복함으로써 연결, 종료에 자원이 낭비된다.

 

3.1.2. HTTP 지속 연결 수행 예시

연결을 일정 시간 유지 HTML 페이지를 모두 받을 때까지 연결이 유지된다. HTTP/3에선 UDP 기반으로 동작하기 때문에 연결이 더 최적화되었다.

3.2. Stateless를 기억하자

같은 시간에 발생하는 대용량 트래픽(수강신청, 선착순, 명절 예약 등)을 처리하는 것은 서버 개발자들이 어려워하는 업무이다. 이때에도 최대한 Stateless설계를 따르면서 서버를 늘려 대응해야 한다.

4.  HTTP 메시지를 통한 통신

HTTP는 하이퍼텍스트 뿐만 아니라 모든 이진 데이터를 메시지로보낼 수 있다. HTTP 메시지는 요청메시지와 응답메시지로 나뉜다.

 

4.1. HTTP 메시지 포맷

HTTP 요청메시지의 시작라인은 request-line, 응답메시지의 시작라인은 status-line으로 칭한다.

4.1.1.시작라인

request-line(요청) ==> HTTP 메소드 SP request-target(=요청대상) SP HTTP-version CRLF(줄바꿈)

status-line (응답)  ==> HTTP-version SP status-code SP reason-phrase(사람이 읽을 수 있는 상태코드 의미) CRLF

*SP : 공백을 의미한다.

 

4.1.2. HTTP 헤더

[필드네임: OWS field-value OWS]  구조를 가진다.

ex) Host: www.google.com (필드네임은 대소문자를 구분하지 않는다.)

*OWS : 띄어쓰기 허용

HTTP 전송에 필요한 부가정보(바디내용, 바디크기, 압축여부, 인증, 요청클라이언트 정보, 캐시관리정보 등)를 모두 포함하며 필요에 따라 임의의 헤더를 추가할 수있다. 추가된 헤더는 약속된 클라이언트와 서버만 이해할 수 있다.

 

4.1.3. message body

실제 전송할 데이터가 들어있다. 압축이 되어져 보낸다면 압축된 형태로 보내진다.

 

5. 구조의 단순함, 확장 가능

HTTP 메시지의 구조는 단순하며 확장 가능한 기술이다.

 

 

함께 보면 좋은 글

HTTP 역사 - 정보통신기술용어해설

RFC - 정보통신기술용어해설

HTTP 메시지포맷 - 정보통신기술용어해설