Network HTTP(HyperText Transfer Protocal) 구조 및 HTTP 메시지 구조

2021-01-21

http, network

웹에서 가장 중요한 요소라고 할 수 있는 HTTP(Hyper Text Transfer Protocal)에 대해서 살펴보도록 하겠습니다.
들어가기 앞서 HTTP가 왜 중요할까요?

클라이언트-서버 구조에서 데이터를 전송하기위해 필수 불가결한 요소입니다. HTTP 메시지에 모든것들을 전송할 수 있기때문입니다.
HTTP는 HTML, TEXT, Image, 음성, 영상, 파일, JSON, XML(API) 거의 모든 형태의 데이터로 전송이 가능하기 때문에 상당히 네트워크에서 중요한 부분을 차지하고 있습니다.

1. HTTP(Hyper Text Transfer Protocal) 흐름

HTTP/0.9 1991년에 GET메서드만 지원하는 형태로 나오게 되었으며 HTTP 헤더는 가지고 있지 않았습니다.
HTTP/1.0 1996년 메서드와 헤더가 추가 되었습니다.
HTTP/1.1 1997년 가장 많이 사용되었으며 현재 우리에게 가장 중요한 버전이라고 할 수 있습니다.(RFC2068 -> RFC2616 -> RFC7230~7235(2014)) 의 스펙으로 진화되어 왔습니다.
HTTP/2 2015년에 성능개선을 이루게 되었습니다.
HTTP/3 현재 개발이 진행되고 있으며 TCP대신에 UDP사용, 성능개선을 이루어 내고 있습니다.

여기서 가장 중요한 부분은 어디일까요?
HTTP표준스펙처럼 자리잡은 HTTP/1.1 버전을 웹에서는 주로 사용하고 있습니다.

2. HTTP(Hyper Text Transfer Protocal) 기반 프로토콜

TCP
HTTP/1.1, HTTP/2
UDP
HTTP/3, HTTP/1.1을 주로사용하고 하고 점차적으로 HTTP/2, HTTP/3의 사용 점유율도 상승되고 있습니다.

이러한것들을 실제로 웹상에서 확인해보고 싶으면, 개발자모드-네트워크도구탭에서 어떠한 HTTP프로토콜이 이용되어져 있고 기반 프로토콜은 무엇을 주로 사용하는지 확인할 수 있습니다.

3. HTTP(Hyper Text Transfer Protocal) 특징

클라이언트-서버 구조를 가지고 있습니다.
무상태성 프로토콜(Stateless), 비연결성
HTTP 메시지
단순함, 확장기능을 가지고 있습니다.

4. 클라이언트(Client)- 서버(Server) 구조

요청(request), 응답(Response) 구조를 가지고 있습니다.
클라이언트는 서버에 요청을 보내고 응답을 대기합니다.
서버가 요청에 대한 결과를 만들어서 응답하게 됩니다.

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

서버가 클라이언트의 상태를 보존하지 않습니다.
서버의 확장성이 매우 높은 장점을 가지고 있습니다.(Scale-out)
클라이언트가 추가 데이터를 전송해야한다는 단점을 가지고 있습니다.

6. Stateful(상태유지) VS Stateless(무상태성)

이커머스 환경에서 제품 구매하는 예제를 들 수 있습니다. 고객이 점원에게 물품을 구매할때 도중에 상태가 변경되거나 Context가 변화하게 되어도 상태를 유지하기가 쉽습니다.(무상태성) 그에 반해 Stateful은 어떤 상태인지 계속 알고 있기때문에 중간에 상태가 변경되거나 Context가 변화가 없도록 하여야 합니다.

차이 정리

Stateful:

중간에 다른상태로 변경되면 X
항상 같은 서버가 유지되어야 합니다.
서버가 터지게 되면 상태보존하는데 보존이 불가능합니다.

Stateless:

중간에 다른상태로 변경 OK
트래픽이 증가해도 다양한 스케일아웃 많은 서버들을 Scale-out이 가능합니다.
Stateless는 응답 서버를 쉽게 변경이 가능하기 때문에 무한한 서버를 증설을 할 수 있습니다.
트래픽이 몰리는경우가 많을 경우 정적페이지를 띄워놓고 요청 트래픽을 분산시킬 수 있는 방식으로 설계해야합니다.
모든것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있습니다.
로그인시 브라우저쿠키나 서버세션을 이용하여 상태를 유지합니다.
상태유지는 최소한만 사용해야합니다.

7. 비연결성(connectionsless)

연결 유지 모델

클라이언트-서버 구조에서는 클라이언트가 요청후 TCP/IP에 연결한후 HTTP 서버요청을 진행합니다.
서버는 연결을 계속 유지함에 따라 서버 자원 소모가 증가될 수 있습니다.

연결 비유지 모델

클라이언트가 요청후 서버에게 응답을 받을때 TCP/IP 연결을 종료시켜버립니다.
서버는 연결을 유지하지 않고, 최소한의 자원을 유지합니다.

8. 비연결성(connectionsless) 특징

HTTP는 기본이 연결을 유지하지 않는 모델입니다.(Default)
초 단위의 이하의 빠른 속도로 응답을 합니다.
실제 서비스에서 서비스를 사용해도 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작습니다.
서버 자원을 매우 효율적으로 사용할 수 있습니다.

9. 비연결성(connectionsless) 한계

자원을 받을때 마다 TCP/IP 연결을 새로 맺어야합니다.(3-way-handshake 시간 증대)
웹 브라우저로 사이트를 요청하면 HTML뿐만 아니라 html,css,js,image files 등 많은 Resource를 다운로드 받습니다.
HTTP/2, HTTP/3에서 더 많은 최적화를 지원합니다.

HTTP초기에는 연결,종료를 낭비가 많았는데 그 이유는 매번 요청마다 분리를 해야했기 때문입니다. 그래서 나온것이 HTTP 지속 연결(Persistent Connections)입니다.

지속 연결의 과정은 요청-> 응답 -> 유지 (내부 매커니즘으로 지속연결을 계속 진행합니다.)

정리

Stateless같은 경우는 동시간에 진행되는 실시간 대용량 트래픽에 매우 용이 합니다.
예를 들면, 수만명의 트래픽이 들어왔다고 가정하면 Stateles 환경에 서버 요청이 많아집니다. 이에 따른 대응방식으로 정적페이지나 HTML을 먼저 렌더링 시켜준후 해당 본 요청 이벤트를 처리하는 로직으로 진행합니다.

10. HTTP 메시지구조

10.1. HTTP 요청메시지 구조

1. start-line 시작라인(HTTP메서드, 요청대상, HTTP Version)
2. header 헤더(표준헤더 많음, 헤더추가도 가능함)
3. empty line 공백라인(CRLF) - RFC7230 표준
4. message body

HTTP 요청메시지 예시

1
2
3

1. GET /search?q=hello&hl=ko HTTP/1.1 (start-line)
2. Host: www.google.com (header)
3. (empty line)

요청메시지도 body본문을 가질수 있습니다.

10.2. HTTP 응답 메시지 구조

1. start-line 시작라인(HTTP버전, HTTP상태코드, 요청 및 성공)
2. header 헤더(표준헤더 많음, 헤더추가도 가능함)
3. empty line 공백라인(CRLF) - RFC7230 표준
4. message body(실제 전송데이터 HTML,이미지,영상,JSON, XML 등 byte표현가능한 모든 데이터)

HTTP 응답메시지 예시

1. HTTP/1.1 200 OK (start-line)
2. Content-Type:text/html;charset=UTF-8    (header)
3. Content-Length: 3423    (empty line)

4.(message body)
<html>                  
    <body>..</body>
</html>

정리

HTTP1.1 기준
클라이언트,서버 구조
무상태 프로토콜(Stateless)
HTTP 메시지 구조