[HTTP] HTTP 기본

HTTP는 HyperText Transfer Protocol의 약어로, 처음에는 HTML을 전송하는 프로토콜로 시작했지만, 현재는 모든 것을 HTTP 메시지에 담아 전송한다. 아래와 같은 것들이 있다. 

• HTML, TEXT
• 이미지, 영상, 음성, 파일 ...
• JSON, XML(API)
• 거의 모든 형태의 데이터 전송 가능
• 서버 간에 데이터를 주고받을 때도 대부분 HTTP를 사용

가장 많이 사용하고, 우리에게 가장 중요한 버전은 HTTP/1.1이다. HTTP/1.1에 대부분의 모든 기능이 들어있고, HTTP/2나 HTTP/3은 성능 개선에 초점이 맞춰져 있는 버전이다. 

HTTP/1.1, HTTP/2는 TCP 위에서 동작한다. 하지만, HTTP/3는 UDP 기반으로 동작한다. 

HTTP 특징

HTTP의 특징들을 간단히 살펴보자. 

클라이언트-서버 구조

HTTP는 클라이언트-서버 구조로 이루어져 있다. 클라이언트가 HTTP 메시지를 통해 서버에 요청(Request)을 보내고 서버에서 응답이 올 때까지 기다린다. 서버가 요청에 대한 결과를 만들어 응답(Response)을 보내면 클라이언트는 이를 받아 동작을 수행하게 된다.

비즈니스 모델이나 데이터와 같은 것들은 모두 서버에 존재한다. 클라이언트는 사용성, UI와 같은 것들에 집중한다. 이와 같이 클라이언트와 서버가 분리되어 있어 각각 독립적으로 진화할 수 있다.

 

Stateless Protocol (무상태 프로토콜)

HTTP는 무상태 프로토콜을 지향한다. Stateless란, 서버가 클라이언트의 상태를 보존하지 않는다는 것이다. History(이전에 수행했던 것)가 지금 상황에 영향을 끼치지 않는 것을 의미한다. 이렇게 되면 응답 서버를 쉽게 바꿀 수 있게 되고 무한히 서버를 증설할 수 있다.

이 때문에 HTTP는 처음 요청을 보낼 때 필요한 정보를 모두 담아서 보내게 된다. 이것(데이터를 모두 담아 보내면 데이터의 양이 증가한다)이 Stateless의 단점이기도 하다.

 

 하지만, 모든 것을 무상태로 설계할 수는 없다. 단순한 소개 화면 같은 것은 무상태로 설계해도 상관이 없지만, 로그인이 필요한 서비스는 로그인의 상태를 유지해야 하기 때문에 무상태로는 설계할 수 없다. 일반적으로는 이를 브라우저 쿠키와 서버 세션 등을 사용해 상태를 유지한다. 

 

Connectionless (비연결성)

TCP/IP 같은 경우는 기본적으로 연결을 유지한다. 만약 여러 클라이언트가 연결되었다면 서버는 모든 클라이언트와의 연결을 계속 유지할 것이고 이것은 서버의 자원을 소모하는 것이다. 

 하지만 연결을 유지하지 않는 모델(Connectionless) 같은 경우, 서버는 요청을 주고받을 때만 연결하고 이후에는 연결을 유지하지 않고 최소한의 자원만을 유지한다. 만약 이전의 클라이언트가 추가 데이터가 필요하다면 다시 요청을 시도해 연결한다. 

 

HTTP 관점에서 살펴보면, 

HTTP는 기본이 연결을 유지하지 않는 모델이다. 일반적으로는 초 단위 이하의 빠른 속도로 응답을 하고 1시간 동안 수천 명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작다. 예를 들어, 브라우저에서 연속해서 검색 버튼을 누르지 않는 것과 같은 경우이다. 따라서 서버 자원을 매우 효율적으로 사용할 수 있다. 

 

이 비연결성도 단점과 한계가 존재하는데, 매번 TCP/IP 연결을 새로 맺어야 한다는 것이다. 즉, 3-way handshaking이 매 연결마다 필요하다. 또한, 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JavaScript, css, 추가 이미지 등 수많은 자원이 함께 다운로드된다. 
지금은 Persistent Connections으로 이 문제를 해결한다. 간단하게 말하면, 단일 TCP 연결에 여러 Object가 전달될 수 있는 연결 방식이다. 아래 두 그림은 초기 HTTP와 Persistent Connections을 사용한 HTTP의 차이를 보여준다. 

초기 HTTP

Persistent Connection

---

HTTP 메시지

HTTP 메시지의 구조는 다음과 같다. 

시작 라인으로 시작하고 헤더가 따라오며, 공백 라인이 있는데 반드시 필요한 라인이다. 그리고 마지막으로 메시지 바디가 들어간다. 

요청 메시지

HTTP 요청 메시지 예시

위 그림을 살펴보면 시작 라인과 헤더가 주어지고 공백 라인이 따라온다. 메시지 바디에 전송할 것이 없다면 비워놓고 전송하면 된다. 

응답 메시지

응답 메시지는 요청 메시지와 시작 라인이 다르다. 나머지는 동일하다. 

 

이제 하나씩 살펴보자.

시작 라인(Start line)

시작 라인은 크게 Request line과 Status line으로 이루어지는데, 요청 메시지는 request line, 응답 메시지는 Status line이라고 한다. 구조는 다음과 같다.

 

요청 메시지의 구조

Request line = method SP(공백) request-target SP HTTP-version CRLF(엔터)

method는 GET, POST... 와 같은 것들로 서버가 수행해야 할 동작을 지정한다. GET은 리소스를 조회하라는 명령어이고, POST는 요청 내역을 처리해달라는 명령어이다. 

request-target에는 path(경로, 요청하는 대상)가 들어간다. 보통 절대 경로를 사용한다. 

HTTP-version은 말 그대로 HTTP의 버전을 넣는다.

 

응답 메시지의 구조

Status line = HTTP-version SP status-code SP reason-phrase CRLF

HTTP-code는 상태 코드로, 200은 성공, 400은 클라이언트 요청 오류, 500은 서버 내부 오류를 뜻한다. 

 

HTTP-헤더

header-field = field-name":" OWS field-value OWS

구조는 위와 같이 이루어지고, OWS는 띄어쓰기를 해도 되고 안 해도 된다는 의미이다. field-name의 대소문자는 구분하지 않는다.

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 가지고 있다. 메시지 바디를 제외하고 필요한 메타데이터가 모두 들어있다 보면 된다.

표준 헤더가 매우 많고, 필요하다면 임의의 헤더를 추가할 수도 있다. 

 

HTTP-message body

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