ABOUT.Series (3) HTTP

 

이번 포스팅에서는 HTTP에 대해 간략히 정리해 보고자 한다.

 

 

< 목차 >

1. HTTP
2. HTTP 특징

 

 

1. HTTP 

HTTP는 HyperText Transfer Protocol의 줄임말로 웹 상에서 정보를 주고 받을 수 있는 프로토콜이다. 

HTTP는 주로 HTML(HyperText Markup Language) 문서를 전송하는 프로토콜로 시작되었으나 지금에 와서는 거의 모든 것을 HTTP 프로토콜에 담아 전송하고 있다.

HTTP 메시지에 거의 모든 것을 전송
-  HTML, Text
-  Image, 음성, 영상, 파일
-  JSON, XML
-  거의 모든 형태의 데이터 전송 가능
-  서버 간 데이터를 주고 받을 때도 대부분 HTTP 사용

HTTP의 역사를 간단하게 훑고 넘어가보자.

• HTTP/0.9  (1991년)  :  GET 메소드만 지원, HTTP 헤더 X
• HTTP/1.0  (1996년)  :  메소드, 헤더 추가
• HTTP/1.1  (1997년)  :  가장 많이 사용 (1.1에 거의 대부분의 기능이 들어가 있음)
• HTTP/2  (2015년)  :  성능 개선
• HTTP/3  (진행중)  :  TCP 대신에 UDP 사용, 성능 개선

HTTP/1.1 과 HTTP/2 같은 경우에는 TCP 위에서 동작하며 HTTP/3의 경우 UDP 기반으로 개발되어 있다. TCP의 경우 3 way handshake도 해야하며 기본적인 메커니즘 자체가 속도가 빠른 메커니즘이 아니다. 그래서 UDP 프로토콜 위에 애플리케이션 레벨에서 성능을 최적화 하도록 새로 설계해서 나온 것이 바로 HTTP/3 라고 생각하면 된다. 현재 HTTP/1.1 을 주로 사용하며 HTTP/2 와 HTTP/3 도 점점 증가하는 추세이다.

기반 프로토콜
TCP  :  HTTP/1.1 , HTTP/2
UDP  :  HTTP/3

 

 

 

2. HTTP 특징 

HTTP는 크게 다음과 같은 특징을 갖는다.

• 클라이언트 / 서버 구조
• 무상태 프로토콜(stateless)
• 비연결성
• HTTP 메시지
• 단순함, 확장 가능

 

👉  클라이언트 / 서버 구조 

• Request / Response 구조
• 클라이언트는 HTTP 메시지를 통해 서버에 요청(Request)을 보냄
• 클라이언트는 서버로부터 응답이 올 때까지 무작정 대기
• 서버가 요청에 대한 결과를 만들어서 응답(Response)
• 서버로부터 응답이 오면 응답 결과를 열어서 클라이언트가 동작

클라이언트와 서버를 분리하는 것은 굉장히 중요하다. 클라이언트와 서버를 개념적으로 분리해내고 비즈니스 로직과 데이터 같은 것들은 서버에 전부 밀어넣는다. 그리고 클라이언트는 UI 와 사용성에 집중한다. 이렇게 할 경우, 클라이언트와 서버 양쪽은 각각 독립적으로 진화할 수 있는 환경을 갖게 된다.

 

👉  무상태 프로토콜 (stateless) 

HTTP는 무상태 프로토콜을 지향한다. 무상태(stateless)의 특징은 다음과 같다.

• 서버가 클라이언트의 상태를 보존하지 않는다
• 장점  :  서버 확장성이 높음 (scale out)
• 단점  :  클라이언트가 추가 데이터 전송

Stateful
-  상태 유지
-  중간에 다른 서버로 바뀌면 안된다. (장애 발생)
-  중간에 다른 서버로 바뀔 때 상태 정보를 다른 서버에게 미리 알려줘야 한다.

Stateless
-  무상태  (상태 유지 X)
-  중간에 다른 서버로 바뀌어도 된다.
-  갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
-  무상태는 응답 서버를 쉽게 바꿀 수 있다.  ->  무한한 서버 증설 가능

Stateless의 경우, 클라이언트가 필요한 데이터를 담아서 요청을 보내게 된다. 서버는 클라이언트의 상태를 보존하지 않고 필요한 응답만을 한다. 이러한 무상태성은 수평 확장(scale out)에 매우 유리하다. 하지만 그렇다고 해서 모든 것을 무상태만으로 설계할 수는 없다. 

무상태 (stateless)
-  로그인이 필요없는 단순한 서비스 소개 화면

상태 유지 (stateful)
-  로그인

로그인 한 사용자의 경우, 로그인 했다는 상태를 서버에 유지할 필요가 있다.
일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지.
상태 유지는 최소한으로만 사용.
웹 애플리케이션 설계시 최대한 무상태로 설계하고 어쩔 수 없는 경우에 한해서만 상태 유지를 한다.

 

👉  비연결성 

• HTTP는 기본적으로 연결을 유지하지 않는 모델
• 일반적으로 초 단위 이하의 빠른 속도로 응답
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
• 서버 자원을 매우 효율적으로 사용할 수 있음

서버는 연결 유지 X
서버는 클라이언트와 요청을 주고 받을 때만 연결을 하고 이후에는 연결을 끊어버린다.

최소한의 자원 사용
연결이 유지되지 않기 때문에, 서버가 유지해야 하는 자원을 최소한으로 할 수 있다.

하지만 이러한 비연결성은 다음과 같은 단점을 갖기도 한다.

• TCP/IP 연결을 새로 맺어야 함  (3 way handshake 시간 추가)
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JavaScript, CSS, 이미지 등 수많은 자원이 함께 다운로드 되는데 이 때마다 연결, 종료를 반복함으로써 낭비가 발생
• 지금은 HTTP 지속 연결 (Persistent Connections) 로 문제 해결
• HTTP/2 , HTTP/3 에서 더 많은 최적화

 

👉  HTTP 메시지 

우선, HTTP 메시지의 구조를 살펴보면 다음과 같다.

HTTP 메시지 구조

1) HTTP 메시지 시작 라인 (start-line)  =  request-line / status-line

요청 메시지의 시작 라인은 request-line, 응답 메시지의 시작 라인은 status-line.

요청 메시지의 시작 라인 : request-line
GET /search?q=hello&hl=ko HTTP/1.1

-  HTTP-method (GET, POST, PUT, DELETE ...)  :  GET
-  request-target (요청 대상)  :  /search?q=hello&hl=ko
-  HTTP-version  :  HTTP/1.1

응답 메시지의 시작 라인 : status-line
HTTP/1.1 200 OK

-  HTTP-version  :  HTTP/1.1
-  status-code (상태 코드)  :  200
-  reason-phrase (이유 문구)  :  OK / 짧은 상태 코드 설명글

 

2) HTTP 헤더 (header)

HTTP 헤더에는 HTTP 전송에 필요한 모든 부가정보가 들어가 있다. 예를 들어 message body의 내용, message body의 크기, 압축 여부, 인증 정보, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등이 있다. (message body를 제외한 필요한 모든 메타 데이터 정보가 들어있다고 보면 된다.)

field-name: field-value
-  필요시 임의의 헤더 추가 가능

요청 메시지 ex)
Host: www.google.com

응답 메시지 ex)
Content-Type: text/html;charset=UTF-8
Content-Length: 6161

 

3) HTTP 메시지 바디 (message body)

message body에는 실제 전송할 데이터가 들어있다.

HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터가 전송 가능하다.