HTTP

HyperText Transfer Protocol의 약어인 HTTP는 하이퍼텍스트(HTML)을 전송하는 프로토콜로 시작한 것으로 현재는 이미지, 음성, 영상, 파일, JSON, XML 등 모든 형태의 데이터를 전송하기 위해 사용하고 있다. 서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

HTTP 역사

• HTTP/0.9 1991년 : GET 메소드만 지원하며 HTTP 헤더가 없다.
• HTTP/1.0 1996년 : 다른 메소드와 헤더가 추가됐다.
• HTTP/1.1 1997년 : 가장 많이 사용하는 버전으로 가장 중요한 버전이다.
  해당 버전에 웬만한 기능이 다 들어있고, 2,3 버전은 성능 개선 위주다.
  RFC2068(1997) → RFC2616(1999) → RFC7230 ~ 7235(2014)
• HTTP/2 2015년 : 성능 개선
• HTTP/3 진행 중 : TCP 대신 UDP를 사용, 성능 개선

기반 프로토콜

HTTP 1.1이나 2 버전은 TCP 프로토콜 기반으로 사용하고 3 버전의 경우 UDP 기반으로 사용한다.

HTTP 특징

클라이언트 서버 구조

클라이언트가 서버에 요청을 보내고 응답을 대기하면 서버가 요청에 대한 결과를 만들어서 응답하는 Request Response 구조로 되어있다. 이렇게 구분이 되어있으면 클라이언트는 사용자에게 보여지는 UI에 집중하고 서버는 데이터나 비즈니스 로직에 집중할 수 있게 된다. 각각의 집중해야 할 부분이 구분된다면 각 부분을 더 진화시키는 데 있어 분화될 수 있다.

무상태 프로토콜(Stateless), 비연결성

HTTP는 무상태 프로토콜(Stateless)를 지향한다. 상태 유지를 뜻하는 Stateful과 반대되는 개념으로 서버가 클라이언트의 상태를 유지하지 않는다는 뜻이다. 클라이언트가 서버와 통신에 필요한 요청 정보를 함께 보내기 때문에 중간에 다른 서버가 투입되더라도 문제가 발생하지 않는다. 클라이언트 요청이 갑자기 증가해도 서버를 대거 투입할 수 있고, 응답 서버를 쉽게 교체할 수 있다는 장점이 있다. →스케일 아웃(수평 확장)에 유리하다.

대표적인 예로 HTTP와 UDP가 있다. UDP는 handshake 과정을 거치지 않고 무작정 보내기 때문에 세션 정보를 서버가 저장하지 않는다는 점에서 무상태 프로토콜이라고 말할 수 있다.

💡 스케일 아웃(Scale-out)?
서버를 여러 대 추가하여 시스템을 확장하는 방법이다. 서버가 여러 대가 되기 때문에 각 서버에 걸리는 부하를 균등하게 해주는 로드밸런싱이 필수적으로 동반되어야 한다. 서버 한 대가 장애가 걸려 다운되더라도 다른 서버를 이용할 수 있다는 장점이 있으나, 모든 서버가 동일한 데이터를 가지고 있어야 하므로 데이터 변화가 적은 웹 서버에 적합하다.

💡 Stateful(상태 유지)?
서버가 클라이언트의 이전 상태를 보존하는 것을 말한다. 클라이언트는 이전 상태를 유지하고 있다고 보고 있기 때문에 서버가 중간에 바뀌면 서버에서는 클라이언트의 상태 정보를 저장하고 있지 않기 때문에 다른 서버에 요청에 필요한 정보를 미리 알려줘야 한다. 안 그러면 원하는 응답을 받아낼 수 없게 된다.
대표적인 예로 TCP의 3-way handshake 과정이 있다.

Stateless의 실무 한계 🫠

Stateless는 로그인 상태를 유지해야 하는 것처럼 무상태로는 설계가 안 되는 경우 한계가 있다. 페이지를 이동해서 새로운 요청을 보낼 때마다 로그인 정보가 날아가면 안 되기 때문이다. 그래서 일반적으로 브라우저의 쿠키나 세션에 로그인 정보 같은 유지해야 할 데이터를 담아서 상태 유지를 한다. 그래도 상태 유지는 최소한만 이용하는 것이 좋다.

그리고 무상태로 설계할 때는 매 요청마다 필요한 정보를 함께 보내줘야 하기 때문에 보내는 데이터 양이 많아진다는 단점도 있다.

비연결성

연결을 유지하는 모델은 클라이언트 1~3이 순차적으로 연결이 되어도 먼저 연결된 클라이언트 1의 연결이 끊기지 않는다. 또한 클라이언트 1만 요청을 보내고 있어도 클라이언트 2, 3은 그냥 놀고 있는 상태가 된다. 이때 서버가 연결을 계속 유지하면서 서버의 자원이 계속 소모된다.

연결을 유지하지 않는 HTTP 같은 모델은 요청할 때 서버와 연결을 하고 응답을 받고 나면 서버와 연결을 종료한다. 때문에 서버 자원을 매우 효율적으로 사용할 수 있다. 일반적으로 초 단위 이하의 빠른 속도로 응답이 오고 1시간 안에 수천명이 서비스를 사용해도 실제 서버에 동시에 처리하는 요청은 수십개 정도로 매우 작아진다.

비연결성의 단점 😢

현재 페이지를 보다가 이전 페이지로 돌아가더라도 TCP/IP 연결을 새로 맺어야 하기 때문에 3-way handshake 시간이 추가된다. 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JS, CSS, 추가 이미지 등 많은 자원이 함께 다운로드 된다.

지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결하고 HTTP 2, 3 버전에서 더 많은 최적화가 이루어지고 있다.

HTTP 메시지 구조

• start-line : 시작 라인
• header : 헤더
• empty line : 공백라인 (CRLF)
• message body

HTTP는 위의 구조로 이뤄어져 있다. 요청 메시지와 응답 메시지는 보통 다른 구조로 사용하는데 요청 메시지에는 시작 라인과 헤더, 공백 라인을 갖고 요청 시 보낼 메시지가 없으면 바디 부분은 생략하고 보낸다. 응답 메시지는 시작 라인, 헤더, 공백 라인을 다 갖고 응답에 대한 내용을 메시지 바디에 넣는다.

시작 라인(Start-line)

시작 라인은 크게 request-line과 status-line으로 되어있는데 요청 메시지인 경우 request-line이라고 한다. request-line에는 메소드(GET, POST 등), 공백, request-target(PATH : 요청 대상), 공백, HTTP-version, CRLF(엔터)가 순서대로 들어간다.

응답 메시지인 경우 status-line인데 HTTP-version, 공백, status-code(HTTP 상태코드), 공백, reason-phrase, CRLF 순서로 들어간다.

💡 HTTP 상태코드?
요청의 성공, 실패를 나타내는 코드로 맨 앞 숫자를 가지고 분류한다.

• 1xx (정보) : 요청을 받았으며 프로세스를 계속함.
• 2xx (성공) : 요청을 성공적으로 받았으며 인식했고 수용함.
• 3xx (리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요.
• 4xx (클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없음.
• 5xx (서버 오류) : 서버가 명백히 유효한 요청에 대해 충족을 실패.

헤더

HTTP 헤더는 filed-name”:” OWS field-value OWS 구조로 이루어진다. OWS는 띄어쓰기를 허용한다는 뜻으로 띄어써도 되고 붙여써도 된다.

HTTP header는 전송에 필요한 메시지 바디의 내용, 메시지 바디 크기, 압축, 인증, 요청 클라이언트 정보 등 모든 부가 정보를 담고 있다.

메시지 바디

실제 전송할 데이터를 담는 곳으로 HTML 문서나 JSON, 이미지, 영상 등 바이트(byte)로 표현할 수 있는 모든 데이터가 전송 가능하다.

강의 : 모든 개발자를 위한 HTTP 기본 지식 - 김영한님