[HTTP] - HTTP 프로토콜의 특징

인프런 강의 중 모든 개발자를 위한 HTTP 웹 기본 지식이라는 강의에 대한 TIL입니다.

 

HTTP 기본 특징

• 클라이언트 서버 구조
• 무상태(Stateless) 프로토콜
• 비연결성(Connectionless)
• HTTP 메시지

 

1. 클라이언트 서버 구조

HTTP 프로토콜을 쓰기 전에는 클라이언트와 서버가 나뉘지 않았다고 한다. HTTP 프로토콜을 사용하게 됨으로써 클라이언트에서는 Request를 서버에서는 그에 따른 Response를 보내는 구조가 되었다고 한다. 클라이언트와 서버가 나누어지게 되면서 각각의 역할에 더욱더 적합한 기능들에 집중해서 발전시킬 수 있었다.

 

2. 무상태(Stateless) 프로토콜

무상태, 즉 Stateless란 서버가 클라이언트의 상태를 보존하지 않는다는 의미이다. 반대 용어로는 Stateful, 즉 상태 유지이다.

Stateful과 Stateless의 차이를 아래 예시를 통해서 알아보자.

Stateful(상태 유지)

고객: 이 노트북 얼마인가요?
점원: 100만 원입니다.

고객: 2개 구매하겠습니다.
점원: 200만 원입니다. 현금, 카드 중 어느 걸로 구매하시겠습니까?

고객: 카드로 구매하겠습니다.
점원: 200만 원 결제 완료되었습니다.  

 

점원은 고객의 이전 말들을 기억하고 있어야지만 해당 대화가 가능하다. 쉽게 말해, 2개 구매하겠다는 고객의 말을 이해하려면 이전의 노트북을 구매하겠다는 고객의 말을 기억하고 있어야 한다는 말이다. 또한, 카드로 구매하겠다는 고객의 말을 이해하려면 이전의 노트북 2개를 구매하겠다는 고객의 말을 기억, 즉 점원 쪽에서 고객의 상태를 유지하고 있어야 한다는 의미이다.

Stateless(무상태)

고객: 이 노트북 얼마인가요?
점원: 100만 원입니다.

고객: 노트북 2개 구매하겠습니다.
점원: 200만 원입니다. 현금, 카드 중 어느 걸로 구매하시겠습니까?

고객: 노트북 2개를 카드로 구매하겠습니다.
점원: 200만 원 결제 완료되었습니다.

 

이번에는 굳이 점원 쪽에서 고객의 말을 기억하지 않아도 대화가 가능하다. 왜냐하면, 고객의 말에 모든 정보가 담겨있기 때문이다. 이러한 상태를 무상태, 즉 Stateless라고 한다.

 

Stateful과 Stateless의 차이점을 다시 정리해보자면, Stateful은 중간에 다른 점원으로 바뀌면 안 되고, 혹여 바뀌더라도 다른 점원에게 상태 정보를 넘겨줘야 한다. Stateless는 중간에 다른 점원으로 바뀌어도 된다. 따라서 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다. 이는 클라이언트의 요청이 갑자기 증가해도 서버를 대거 투입할 수 있다는 의미이다. 따라서 Stateless는 응답 서버를 쉽게 바꿀 수 있다.

 

만약, 중간에 서버가 장애가 난다면 두 가지 프로토콜은 어떻게 동작될까?

 

출처) https://www.inflearn.com/course/http-웹-네트워크 강의자료

 

위의 그림과 같이 Stateful 프로토콜은 제대로 된 통신을 할 수 없다.

 

출처) https://www.inflearn.com/course/http-웹-네트워크 강의자료

 

반면에 Stateless 프로토콜은 다른 응답 서버를 이용해서 통신을 이어갈 수 있다.

 

이러한 Stateless 프로토콜에도 한계점이 존재한다. 웹 서비스를 설계할 때 무상태로 설계할 수 없을 서비스가 존재하기 때문이다. 로그인이 필요 없는 단순한 서비스 소개 화면이라면 무상태로 설계할 수 있지만, 로그인을 제공하는 서비스라면 사용자가 로그인했다는 상태를 서버에 유지해야만 한다. 일반적으로 웹 브라우저의 쿠키와 서버의 세션 등을 사용해서 로그인 상태를 유지한다고 한다. 이처럼 불가피하게 상태를 유지하는 경우를 제외하면 상태 유지, 즉 Stateful은 최소한만 사용되는 것이 좋다.

 

3. 비연결성(Connectionless) 

HTTP 프로토콜은 기본적으로 연결을 유지하지 않은 네트워크 모델이다. 연결을 유지하는 모델은 통신을 위해서 한 번 요청을 보내면 후에 요청을 보내지 않아도 계속 클라이언트와 서버가 연결되어있다. 계속 연결되어있다는 것은 서버의 자원을 계속 소모하면서 연결을 유지하고 있다는 의미이다. 반면에, HTTP 프로토콜 같이 연결을 유지하지 않는 모델은 한 번의 요청과 응답을 주고받으면 연결을 끊는다. 따라서, 서버는 최소한의 자원만 사용되기에 일반적으로 초 단위 이하의 빠른 속도로 응답할 수 있다. 또한, 1시간 동안 수천 명이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작다. 쉽게 말해, 웹 브라우저의 검색 버튼을 서버에서 처리한다고 했을 때, 검색 버튼이 사용자들에 의해 눌러지기 전까지는 서버의 자원이 소모되지 않고, 수천 명이 동시에 검색 버튼을 누르는 일은 흔하지 않은 일이다.

 

하지만, 한계도 분명히 존재한다. 클라이언트와 서버의 연결이라고 하는 것은 보통 TCP/IP 연결을 의미하는데 TCP/IP 연결은 3 way Handshake 방식 때문에 상대적으로 시간이 오래 걸리는 연결이다. 이러한 연결을 요청이 발생할 때마다 새로 해줘야 하는 것은 비효율적일 수밖에 없다. 또한, 웹 브라우저에서 웹 사이트를 하나 요청하면 HTML 뿐만 아니라, CSS, JavaScript, 추가 이미지 등 수많은 자원이 함께 다운로드되는데 이는 한 번 사이트를 요청할 때 각각의 자원을 따로따로 처리해야 한다는 의미이다. 아래의 그림을 보면 쉽게 이해된다.

 

출처) https://www.inflearn.com/course/http-웹-네트워크 강의자료

 

따라서, 이러한 한계점을 극복하기 위해서 HTTP 지속 연결(Persistent Connections)이 도입되었다.

 

출처) https://www.inflearn.com/course/http-웹-네트워크 강의자료

 

모든 자원을 다 응답받을 때까지 연결을 유지함으로써 시간을 줄일 수 있다.

 

4. HTTP 메시지

HTTP 메시지는 아래의 그림과 같은 구조를 가지고 있다.

 

출처) https://www.inflearn.com/course/http-웹-네트워크 강의자료

 

시작 라인(start-line)

💡 요청 메시지

 

출처) https://www.inflearn.com/course/http-웹-네트워크 강의자료

 

HTTP 요청 메시지에서의 시작 라인은 request-line으로 이루어져 있다. request-line은 아래와 같다.

method SP(공백) request-target SP HTTP-version CRLF(개행)

 

method

HTTP 메서드를 의미한다. 종류로는 GET, POST, PUT, DELETE 등이 있다. HTTP 메서드는 서버가 수행해야 하는 동작을 지정해주는 역할을 한다. 예를 들어, GET은 리소스 조회, POST는 요청 내역을 처리하는 동작을 의미한다.

 

request-target

요청 대상이라고 하는 것은 absolute-path[?query]이다. 리소스의 경로를 의미하는 것 같다.

 

HTTP-version

HTTP 버전을 의미한다.

 

 

💡 응답 메시지

 

출처) https://www.inflearn.com/course/http-웹-네트워크 강의자료

 

HTTP 응답 메시지에서의 시작 라인은 status-line으로 이루어져 있다. status-line은 아래와 같다.

HTTP-version SP status-code SP reason-phrase CRLF

 

status-code

HTTP 상태 코드를 의미한다. 요청에 대한 성공, 실패를 나타낸다. 예를 들어 200은 성공, 400은 클라이언트 요청 오류, 500은 서버 내부 오류를 의미한다.

 

reason-phrase

사람이 이해할 수 있는 짧은 상태 코드 설명 글이다.

 

 

HTTP 메시지 헤더

HTTP 헤더 부분에는 header-field들로 이루어져 있다. header-field는 아래와 같다.

field-name ":" OWS(띄어쓰기 허용) field-value OWS

 

이때, field-name은 대소문자에 대한 구분이 없다. 헤더에는 HTTP 전송에 필요한 모든 부가 정보들이 담겨있다. 예를 들어, HTTP 메시지 바디의 내용과 크기, 압축, 인증, 요청 클라이언트(브라우저)의 정보 등이 담겨 있다. 표준 헤더가 존재해서 표준 헤더 리스트를 참고할 수 있다. 필요시 임의의 헤더도 추가할 수 있다.

 

 

HTTP 메시지 바디

실제 전송할 데이터들로 이루어져 있다. HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터들이 담길 수 있다.