[Network] HTTP의 구조와 특징 정리

[김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 학습 후 정리한 내용입니다.]

순서

1. HTTP란?
2. HTTP 특징 - 클라이언트 서버 구조
3. HTTP 특징 - Stateless
4. HTTP 특징 - Connectionless
5. HTTP메시지

 

1. HTTP란?

HTTP(Hypertext Transfer Protocol)는 인터넷에서 웹 페이지를 전송하기 위해 사용되는 프로토콜이다. HTTP는 클라이언트와 서버 사이에서 데이터를 주고받는 데 사용되며, 대부분의 웹 사이트에서 사용된다.

요즘은 HTTP 메시지에 거의 모든 것을 전송한다.

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

1. HTTP의 역사

• HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
• HTTP/1.0 1996년: 메서드, 헤더 추가
• HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
• RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)
• HTTP/2 2015년: 성능 개선
• HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

2. 기반 프로토콜

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

그럼 이제부터 HTTP에 어떠한 특징이 있는지 살펴보자.

 

2. HTTP 특징 - 클라이언트 서버 구조

HTTP는 기본적으로 클라이언트-서버 구조로 되어있다. 클라이언트가 서버에 요청(Request)을 보내고, 서버는 클라이언트의 요청을 받아 로직을 수행한 다음, 결과물을 만들어서 클라이언트에 응답(Response)하는 형태이다.

 

3. HTTP 특징 - Stateless

1. Stateful(상태 유지)

• 서버가 클라이언트의 상태를 보존한다.
• 클라이언트 1과 통신하고 있는 서버A는 서버가 장애가 발생한 경우 서버B로 바뀔 수 없다.
• 따라서, 항상 같은 서버가 유지되어야 한다.

2. Stateless(무상태)

• 서버가 클라이언트의 상태를 보존하지 않는다.
• 클라이언트 1과 통신하고 있는 서버 A는 서버 장애가 발생한 경우 서버 B로 바뀔 수 있다.
• 따라서, 아무 서버나 호출이 가능하다.

Stateless(무상태)는 놀고 있는 서버를 호출해도 아무 문제가 없다. 클라이언트가 서버를 호출할 때, 현재의 상태를 서버에게 모두 넘겨주기 때문이다. 이 경우 요청을 처리하던 서버에 문제가 발생해도, 클라이언트가 다른 서버를 호출해서 처리가 가능하다. 이런 이유, 무상태는 Scale-out(서버의 수평 확장)에 용이하다. 트래픽이 갑자기 몰리는 경우가 있다면, 서버를 잠깐 많이 붙이면 그만이다.

3. Stateless의 한계

모든 것을 무상태로 설계할 수 없는 경우도 있다.

예를 들어, 단순히 보여주기만 하면 되는 화면의 경우는 무상태로 설계가 쉽게 가능하다. 하지만 로그인이 필요한 경우에는, 로그인했다는 상태를 서버에 유지를 해야 한다.

일반적으로는 브라우저 쿠키와 서버 세션 등을 사용하여 상태를 유지한다.

→ 상태 유지를 최소한으로 사용하고, Stateless한 설계를 하는 것이 중요하다.

 

4. HTTP 특징 - Connectionless

위의 그림은 TCP/IP 연결 유지 모델(Connection model)이다. 서버 관점에서 보면 위처럼 계속 연결을 유지하는 것은 서버의 자원이 계속 소모되고 있다고 볼 수 있다. 계속해서 통신을 하고 있는 상황이라면 상관이 없지만 클라이언트 1과 클라이언트 2가 아무런 요청을 하지 않고 놀고 있을 때 연결이 유지되고 있다면, 정말로 자원이 소모되고 있는 것이다.

HTTP는 기본적으로 연결을 유지하지 않는 모델(Connectionless model)이다. 일반적으로 초 단위의 이하의 빠른 속도로 응답한다. 그래서 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다. ex)웹 브라우저에서 연속해서 검색 버튼을 누르지는 않는다. 즉, 필요할 때만 데이터를 연결하여 주고 받기 때문에 서버 자원을 매우 효율적으로 사용할 수 있다.

이러한 비연결성(Connectionless)에는 한계가 있다.

• TCP/IP 연결을 새로 맺어야 한다.(3-way-handshake 시간 추가)
• 웹 브라우저로 사이트를 요청하면 HTML 뿐 아니라 js, css, image 등 수많은 자원 다운로드

이러한 문제는 HTTP 지속 연결(Persistent connections)로 해결할 수 있다. 먼저 연결을 해두고, 연결을 유지한다. 내부적인 로직으로 몇십 초 정도 연결이 유지되는데, 보통은 HTML 페이지 하나를 다 받을 때까지 연결이 유지된다고 한다. 이렇게 요청에 대한 응답을 다 받게 되면 연결이 종료된다.

아래의 초기 HTTP의 비연결 모델의 동작 예시를 살펴보면, 요청을 할 때마다 연결을 해야 하기 때문에 시간이 많이 걸리는 것을 볼 수 있다.

 

다음은 HTTP의 지속연결 모델이다. 몇 초정도 연결이 유지되기 때문에, 한번에 응답을 받고, 종료되어 시간이 절약된다.

 

5. HTTP 메시지

대부분의 Resource는 HTTP를 이용해서 보낼 수 있다. 그렇다면 어떻게 HTTP에 메시지를 저장해서 보낼까? 하나씩 살펴보자.

1. HTTP 메시지의 종류

 

2. HTTP 메시지의 구조

HTTP 메시지의 구조는 요청메시지, 응답메시지 모두 위의 구조를 갖는다. empty line에는 반드시 Enter가 한 칸 들어가야 한다. message body에는 데이터를 넣어도 되고 넣지 않아도 된다.

start-line(시작 라인)

＊요청 메시지의 경우

• HTTP 메서드(GET, POST, PUT, DELETE)
• 요청 대상(/search?q=hello&hl=ko)
• HTTP version

 

＊응답 메시지의 경우

• HTTP version
• HTTP 상태 코드(200, 400, 500 ..)
• 이유 문구(사람이 이해할 수 있는 짧은 상태 코드 설명 글)

 

Header(헤더)

• 헤더에는 HTTP 전송에 필요한 모든 부가정보가 들어가 있다.
• ex) 메시지 body의 내용, 메시지 body의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등)

 

Message body(메시지 바디)

• body에는 실제 전송할 데이터를 넣는다.(HTML, 이미지, 영상, JSON 등 byte로 표현 가능한 모든 데이터)