[네트워크] HTTP에 대해 (3) - HTTP 기본

HTTP에 대해 공부하며 정리한 글입니다.

 

모든 것이 HTTP

HTTP란?

HyperText Transfer Protocol의 약자로 HTML 문서를 가져올 수 있도록 해주는 프로토콜이지만 이제는 HTTP 메세지에 거의 모든 형태의 데이터(HTML, Image, JSON 등)를 담아 전송합니다. 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용합니다.

HTTP의 역사를 간단히 보면 다음과 같습니다.

• HTTP/0.9 1991년 - GET 메서드만 지원, HTTP 헤더 X
• HTTP/1.0 1996년 - 메서드, 헤더 추가
• HTTP/1.1 1997년 - 가장 많이 사용되며 TCP 프로토콜 기반
• HTTP/2 2015년 - 1.1 버전에서 성능 개선이 되었으며 TCP 프로토콜 기반
• HTTP/3 진행중 - TCP 대신 UDP 프로토콜 사용, 성능 개선

가장 최신버전인 HTTP/3를 많이 사용하지 않는 이유는 무엇일까요? 그리고 HTTP/3는 안정적인 TCP 프로토콜을 왜 사용하지 않았을까요?

HTTP/3 버전의 프로토콜을 많이 사용하지 않는 이유는 다음과 같습니다.

• 하위 호환성
  • 모든 웹 서버나 브라우저가 HTTP/3를 지원하지 않기 때문입니다. 
• 안정성 및 검증
  • 상대적으로 새로운 프로토콜이기에, 모든 케이스에 대한 검증이 충분히 필요합니다.
• HTTP/3에 필요한 프로토콜 지원
  • HTTP/3는 UDP 기반의 QUIC 프로토콜 위에서 구현되는데 일부 기업 네트워크 인프라에서는 UDP 트래픽에 대한 제한, 차단이 있을 수 있습니다.

그리고 TCP 프로토콜은 안정적이지만 단점도 있습니다. UDP 프로토콜에 비해 상대적으로 느린 매커니즘 (3 way handshake)과 비교적 큰 데이터의 크기의 단점이 존재하기에 TCP 프로토콜을 사용하는 것이 항상 정답은 아닙니다.

 

 

HTTP 특징

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

 

1. 클라이언트 서버 구조

클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 이뤄져 있습니다.

• Request Response 구조
• 클라이언트는 서버에 요청을 보내고 응답을 대기
• 서버가 요청에 대한 결과를 만들어 응답

위 구조로 인한 장점은 서버는 비즈니스 로직, 데이터를 담당하고 클라이언트는 UI, 사용성을 담당하게 되면서 서버, 클라이언트가 개념적으로 분리되어 독립적으로 진화할 수 있습니다.

 

2. Stateless

HTTP에서 서버가 클라이이언트의 상태를 보존하지 않는 무상태 프로토콜입니다.
클라이언트는 요청에 대한 모든 정보를 담아서 서버에 요청을 보냅니다.

• 서버가 클라이언트의 상태를 보존 X
• 장점 - 서버 확장성이 높음 (scale-out) → 수평 확장 유리
• 단점 - 클라이언트가 요청에 대한 추가 데이터를 전송

 

위 예시와 같이 Stateful일 경우, 중간에 서버(점원)가 바뀌게 되면 바뀐 서버는 클라언트에 대한 상태를 모르기 때문에 서버 변경시, 클라이언트 상태 정보를 다른 서버에게 미리 알려주거나 클라이언트는 특정 서버하고만 통신을 해야하며 만약 통신하던 서버에 장애가 날 경우, 클라이언트는 요청을 처음부터 다시 해야 한다는 단점이 존재합니다.

하지만 Stateless일 경우, 클라언트는 요청에 대한 모든 정보를 같이 전송하기에 서버가 중간에 바뀌어도 문제가 일어나지 않습니다. 따라서 서버에 장애가 발생해도 중계 서버에서 다른 서버로 연결하면 된다는 장점이 존재합니다.

 

Stateless 한계

• 상태 유지가 필요한 케이스가 존재하기에 모든 것을 무상태로 설계할 수 없음
  • 로그인한 사용자의 경우, 로그인했다는 상태를 서버에 유지 (일반적으로 쿠키 + 세션을 사용해 상태 유지)
• 클라이언트는 요청시, 상태 정보를 서버에 전송해야 하기에 요청 메세지의 데이터 양이 증가합니다.

 

여기서 상태란 무엇을 의미할까요?

데이터는 단지 값을 나타내는 것으로, 일반적으로 정보의 조각이나 숫자, 텍스트, 이미지 또는 기타 형식의 자료를 의미합니다. 데이터는 정적인 형태로 존재하며, 독립적으로는 아무런 의미를 갖지 않습니다.

반면, 상태는 특정 시점에서 시스템이나 개체의 조건을 나타내는 것입니다. 이는 시간과 밀접한 관련이 있습니다.

시스템이나 개체는 시간이 흐름에 따라 변화할 수 있습니다. 따라서, 특정 시점에서의 조건이나 속성을 나타내는 것이 상태입니다. 시간이 지나면서 상태는 변경될 수 있습니다. 예를 들어, 자동차의 상태를 생각해보면, 주행 중인 시점에서는 속도, 연료 수준, 엔진 온도 등이 해당 자동차의 상태를 나타냅니다. 이러한 상태는 시간이 흐름에 따라 계속해서 변화할 수 있습니다. 시간이 지나면서 속도가 증가하거나 연료가 소진되면 상태가 변화하게 됩니다

따라서, 상태는 특정 시점에서의 조건이나 속성을 나타내는데, 시간이 경과함에 따라 변화할 수 있는 개념입니다. 시간은 상태의 변화를 관찰하고 기록하는 데 필수적인 맥락을 제공합니다

 

3.  비연결성 (connectionless)

• HTTP는 기본적으로 연결을 유지하지 않는 모델
  • HTTP 1.0 기준으로 HTTP는 연결을 유지하지 않는 모델
• 일반적으로 초 단위 이하의 빠른 속도로 응답
  • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
  • ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않음
• 효율적인 서버 자원의 사용

 

연결성 VS 비 연결성

• 연결 지향 - 연결을 유지하는 모델
  • TCP/IP의 경우 연결을 유지
  • 클라이언트가 요청을 보내지 않아도 서버는 연결을 계속 유지 → 불필요한 서버 자원 소모
• 비 연결성 - 연결을 유지하지 않는 모델
  • 비 연결성을 가지는 HTTP는 요청을 주고 받을 때만 연결을 유지하고 응답을 받으면 TCP/IP 연결을 끊음
  • 최소한의 자원으로 서버 유지

 

비 연결성의 한계와 극복

• 한계 - 매 요청시 TCP/IP 연결을 새로 맺어야 함
  • 3 way handshake 시간 추가
  • 웹 브라우저로 사이트 요청시 HTML뿐만 아니라 JS, CSS, 이미지 등 수많은 자원이 함께 다운로드되기에 리소스를 다운받을 때마다 3 way handshake 발생
• 극복 - HTTP 지속 연결로 문제 해결, HTTP/2, HTTP/3에서 더 많은 최적화

 

HTTP 지속 연결

• HTTP 초기 - 연결, 종료 낭비
  • HTTP 초기에는 각각의 자원을 다운로드 하기 위해 연결, 종료를 반복해야 했음
• HTTP 지속 연결 (Persistent Connections)
  • HTTP 지속 연결을 통해 연결이 이뤄진 후, 자원 하나를 요청시, 이와 묶여있는 모든 자원들을 요청하기 위해 연결을 유지한 상태
  • 클라이언트는 서버에서 응답이 오기 전에 자원을 연속적으로 요청할 수 있고 서버는 연속적으로 응답할 수 있음 (파이프라이닝)

일반적으로 HTTP 서버는 일정기간(타임아웃) 사용되지 않으면 연결을 닫으며, HTTP/1.0기준으로 클라이언트에서 지속 연결을 원할 경우 Keep-Alive를 헤더에 담아서 요청을 보냈으며 HTTP/1.1 기준으로 달리 명시되어 있지 않으면 모든 연결은 지속 연결로 간주합니다. 하지만 각 서버마다 timeout이 존재합니다.

 

4. HTTP 메세지

HTTP 메세지의 기본 구조와 각 구성 요소에 대해 알아봅니다.

위 사진처럼 HTTP 메세지는 start-line, header, empty line, message body 4가지 구성 요소의 구조로 되어있습니다.

 

 

start-line (시작 라인)

시작 라인의 경우, 요청 메세지와 응답 메세지의 경우 차이점이 있습니다.

• 요청 메세지
  • request-line으로 method, request-target, HTTP version으로 구성되어 있습니다.
  • method - 서버가 수행할 동작을 지정하며 HTTP 메서드로 GET, POST, PUT 등이 있습니다.
  • request-target - 요청 대상으로 path를 전달합니다.
  • HTTP version - 사용하는 http 버전을 명시합니다.
• 응답 메세지
  • status-line으로 HTTP version, status code, reason phrase로 구성되어 있습니다.
  • HTTP version - 사용하는 http 버전을 명시합니다.
  • status code - 응답 결과를 나타냅니다. (2XX - 요청 성공, 응답 반환, 4XX - 클라이언트 오류)
  • reason phrase - 이유 문구로 상태 코드에 대한 짧은 설명을 나타냅니다.

 

header

HTTP 전송에 필요한 모든 부가 정보를 포함하며 header field는 field name: field value로 구성되어 있습니다.

부가 정보로는 body 내용, 크기, 요청한 클라이언트 정보, 인증, 캐시 관리 정보 등이 포함되어 있습니다.

 

body

실제 전송 데이터를 포함하며 HTML, 동영상, JSON 등 byte로 표현할 수 있는 모든 데이터를 전송할 수 있습니다.