[HTTP] 3-1. HTTP 기본

'모든 개발자를 위한 HTTP 웹 기본 지식' 강의를 보고 정리하였습니다.

 
 이번에는 HTTP의 기본적인 내용들을 정리해 보려고 합니다.
 

HTTP란?

HTTP(HyperText Transfer Protocol)는 Hypertext(HTML) 문서 간의 링크를 통해서 정보를 전송할 수 있는 프로토콜로 시작되었습니다. 그러나 지금은 HTML 뿐만 아니라, JSON, 이미지, 영상, 파일 등 거의 모든 형태의 데이터들을 전송할 수 있게 되었습니다.
 

HTTP의 역사

• HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 x
• HTTP/1.0 1996년: 메서드, 헤더 추가
• HTTP/1.1 1997년: 현재 가장 많이 사용하는 버전 (가장 중요 !)
• HTTP/2 2015년: 성능 개선
• HTTP/3 진행 중: TCP 대신에 UDP 사용, 성능 개선

 

기반 프로토콜

• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3

TCP는 3 way handshake 과정도 거쳐야 하고 또 수많은 데이터도 가지고 있기 때문에, 속도 측면에서 아쉬운 부분이 있을 수밖에 없습니다. 이를 개선하기 위해 HTTP/3에서는 UDP를 사용하여 성능을 최적화 시켰습니다.
 

HTTP의 특징

HTTP의 특징은 크게 3가지로 나눌 수 있습니다.
 

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

HTTP는 클라이언트가 서버에 요청(Request)을 보내면, 서버가 요청에 적절한 응답(Response)을 만들어 클라이언트에 보내는 구조를 가지고 있습니다.
 
옛날에는 클라이언트와 서버의 분리 없이, 한 곳에서 모든 작업을 처리하는 방식이었습니다. 클라이언트와 서버를 분리하고 나서, 서버에서는 비즈니스 로직과 데이터들만 관리하고, 클라이언트에서는 UI, UX만 관리할 수 있도록 역할을 나누었습니다. 이렇게 역할을 나누면 클라이언트와 서버가 각각 독립적으로 진화할 수 있다는 큰 장점 때문에, 클라이언트와 서버를 분리시키는 것이 굉장히 중요합니다.
 

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

무상태 프로토콜(Stateless)이란, 서버가 클라이언트의 상태를 보존하지 않는 프로토콜입니다.
이해하기 쉽도록 바로 상태 유지 프로토콜과의 차이를 살펴보겠습니다.
 

상태 유지(Stateful) vs 무상태(Stateless)

 

상태 유지(Stateful)

상태 유지 프로토콜에서는 클라이언트가 서버에 많은 요청을 여러 차례 나누어 보냅니다. 서버는 순서대로 들어오는 요청을 기억한 상태로 요청에 맞는 응답을 생성합니다. 그런데 만약 클라이언트와 통신 중이던 서버가 고장이라도 난다면 .. 🤦🏻‍♀️ 클라이언트는 서버에 요청을 처음부터 다시 보내야 합니다. 혹은 다른 서버로 교체해야 하는 상황이 온다면, 기존 서버는 클라이언트한테 받았던 요청을 교체될 서버에게 인수인계 해주어야 합니다.
 

무상태(Stateless)

위 같은 문제들을 해결해줄 수 있는 프로토콜이 바로 무상태 프로토콜(Stateless)입니다.
무상태 프로토콜은 클라이언트가 서버에 여러 요청을 보낼 때, 나누어 보내지 않고 한꺼번에 보냅니다. 클라이언트의 요청을 받은 서버는 상태를 보관하지 않고, 요청에 맞는 응답만 생성해 클라이언트에 보냅니다. 이러한 특징으로 무상태 프로토콜은 스케일 아웃(수평 확장)에 유리하다는 장점이 있습니다.
 

무상태 프로토콜의 실무 한계

모든 것을 무상태로 설계할 수 없는 경우도 존재합니다.(예: 회원의 로그인 상태 유지 등) 그렇기 때문에 상태 유지 프로토콜은 필요할 때만 최소한으로 사용하는 것이 좋습니다.
 

3. 비연결성

TCP/IP는 기본적으로 클라이언트와 서버 간 연결을 유지합니다.
 

연결을 유지하는 모델 통신 방식

1. 클라이언트 - 서버 연결
2. 클라이언트가 서버에 요청
3. 서버가 클라이언트에 응답
4. 연결을 유지한 채, 다른 클라이언트들과 통신

이렇게 서버는 통신하고 있지 않은 클라이언트와까지도 연결을 유지하고 있어, 서버 자원이 소모된다는 문제점이 발생합니다.
 

연결을 유지하지 않는(비연결성) 모델 통신 방식

1. 클라이언트 - 서버 연결
2. 클라이언트가 서버에 요청
3. 서버가 클라이언트에 응답
4. 더이상의 요청이 없을 시, 연결을 끊음

비연결성 모델은 클라이언트와 서버 간 통신이 끝나면 연결을 끊어버리기✂️ 때문에, 최소한의 자원을 유지할 수 있습니다.
 
HTTP는 기본적으로 비연결성 모델을 사용하며, 일반적으로 초 단위 이하의 빠른 속도로 응답합니다. 비연결성 모델을 사용함으로써 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리해야 할 요청은 매우 적어지게 됩니다. 이러한 점들로 서버 자원을 매우 효율적으로 사용할 수 있다는 장점이 있습니다.
 

비연결성 모델의 한계와 극복

• TCP/IP 연결을 계속 새로 맺어야 한다. (3 way handshake 시간 추가)
• 수많은 자원을 하나씩 다운받을 때마다 연결하고 종료하는 과정을 거쳐야 한다. 👉🏻 HTTP 지속 연결 (Persistent Connections)으로 해결

👉🏻 이러한 문제점을 개선한 프로토콜이 바로 HTTP/2, HTTP/3입니다.
 

* HTTP 지속 연결(Persistent Connections)이란 ?
HTTP 초기: 클라이언트와 서버가 통신할 때마다 연결, 요청/응답, 종료 과정 모두 거치기 때문에 시간이 낭비됨
HTTP 지속 연결(Persistent Connections): 클라이언트 - 서버 통신 시 연결, 요청/응답만으로 통신한 후, 모든 통신이 끝나면 마지막에 종료하기 때문에 시간이 절약됨

 

서버 개발자들이 어려워하는 업무, Stateless

현재 서버 개발자들이 어려워하는 업무가 바로 '무상태(Stateless)'라고 합니다. 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽(선착순 이벤트, 수강신청 등)이 발생하면 비연결성 모델을 사용해도 소용이 없다고 해요. 그래서 어떻게든 머리를 쥐어 짜내서(?) 최대한 스테이트리스하게 설계하는 것이 중요하다고 합니다. 그렇게 하면 대용량 트래픽이 올 때도 서버를 확 늘려 대응할 수 있는 부분들이 많아진다고 하네요 !
대표적으로 로그인도 필요없는 정적 페이지를 뿌려 사용자들이 그 페이지에서 놀게 한 뒤, 이벤트 참여 버튼을 누를 수 있도록 설계하는 방식을 많이 사용한다고 합니다.
 
저도 얼른 대용량 트래픽을 고민하는 멋진 서버 개발자가 되고 싶습니닷 😆