HTTP #4 특징과 메시지 구조

Hypertext Transfer Protocol, 하이퍼 텍스트 문서(HTML)을 전송하는 통신 규약

웹 브라우저는 HTTP 스펙(표준 인터페이스)를 기준으로 만든 클라이언트 프로그램이다.

즉, 웹 브라우저가 아니더라도 HTTP 스펙을 이용하면 다른 곳과 통신도 가능하다.

# HTTP의 시대

인터넷의 반응속도가 정말 중요한 일부 서버(ex 온라인 PC게임)를 제외하고는 현대의 대부분의 서비스는 HTTP를 이용해 네트워크 통신을 한다. 웹에 사용되는 [HTML, 이미지, 영상]은 기본이고 [Json, XML] 같은 데이터를 네트워크에 전송하고, 여러 서버간에 통신을 할 때도 HTTP 를 사용한다.

HTTP의 역사

HTTP 1.1 부터 제대로 표준화 되기 시작하여 인터넷 통신 표준 프로토콜이 되었다.

유튜브나 페이스북 같이 성능이 중요한 플랫폼들은 HTTP3 (h3) 를 이미 적용한 곳도 많다.

HTTP는 비연결성, 무상태성, 클라이언트-서버 구조를 가진다. 이를 하나씩 알아보자.

# 클라이언트 - 서버 구조

HTTP는 기본적으로 클라이언트-서버 구조를 생각하고 설계되었다. 즉, 서버, 클라 양쪽이 독립적으로 설계된다. 당연한 것 같지만 과거에는 인터넷을 많이 사용하기 전에는 굳이 서버 로직과 클라이언트 로직을 구분지어 분리할 필요가 없었다.

# 상태유지, 무상태성(Stateful, Stateless)

HTTP는 무상태 프로토콜(Stateless)를 지향한다. 즉 서버가 클라이언트의 상태를 몰라도 사용할 수 있게 설계한다.

Stateful, 상태유지
서버에서 세션상태를 유지한다. 즉 클라이언트의 정보를 가지고 계속해서 통신한다.
Stateless, 무상태
서버에서 클라이언트의 이전 상태를 저장하지 않는다. 각각의 HTTP 요청은 독립적으로 실행된다.

우리의 일상은 전부 Stateful하게 진행된다. 예를 들어 신발 가게에 방문하여 원하는 신발을 산다고 가정해보자.

나 : 같은 신발을 2켤레 구매하고 싶은데..
A : 어떤 신발을 원하세요? 빨강과 갈색이 있습니다. (세션상태 : 신발 2)

나: (5분 뒤) 빨강색으로 사이즈 270을 원해요
A : 빨간색 신발는 5만원입니다. 결제는 어떻게 하시겠어요? (세션상태 : 신발 2, 빨간색, 270)

나: 5만원을 신용카드로 결제할게요!
A : 10만원 결제 완료되었습니다. (세션상태 : 신발 2, 빨간색, 270, 신용카드)

이렇게 하면 고객입장에서는 편할 수 있지만, 이를 제공하는 판매원(서버)의 입장에서는 고객당 별도의 세션 상태을 유지해야하고 요청의 분산처리(여러 점원이 도와주기)가 어려워 서버의 확장이 어렵다. 그래서 이러한 문제점을 해결하고 서버 확장을 용이하게 하기 위해 웹 서비스는 Stateless 하게 만든다.

나 : 같은 신발를 2켤레 구매하고 싶습니다.
A : 어떤 신발을 원하세요? 빨강과 갈색이 있습니다.

나 : (5분 뒤) 같은 신발을 2켤레, 빨간색으로 사이즈 270으로 구매하고 싶어요.
B : 빨간색 신발은 5만원입니다. 결제는 어떻게 하시겠어요? (세션 없음. 다른 점원 B가 대신처리가능)

나: 같은 신발을 2켤레, 빨간색으로 사이즈270으로 해서 신용카드로 구매하겠습니다.
C : 10만원 결제 완료되었습니다. (세션 없음. 다른 점원 C가 대신 처리 가능)

이를 점원이 아닌 서버로 말을 바꾸면, 아래와 같은 특징을 지닌다.

stateful 방식은 기능 구현상 편하지만 상태를 계속해서 가지고 있기 때문에 캐시의 활용도가 떨어지고 상태 유지는 서버에 부담을 줄 수 있다. (또한 세션때문에 생기는 보안 취약점도 존재한다.)
대부분의 웹 서버는 웹 서버는 네트워크 비용을 고려한 Stateless가 적합하다. 하지만 MMOPRG와 같이 대규모 사용자가 실시간으로 전투할 때 고성능의 처리능력과 상태 안정성이 보장되어야 하는경우 Stateful Server가 적합하다.
stateless 방식은 매 요청 시마다 상태 정보를 저장해야 하기 때문에 네트워크 리소스를 서버 쪽에서 소모해야 하고 상태 값 저장 기능을 위한 사전 작업이 필요하지만 [서버 장애 대응, 캐싱, 로드밸런싱, 서버 확장]에 용이하다.

@ 상태가 어쩔수없이 필요한 경우도 있다.

그렇다고 Stateless가 만능인건 아니다.

단순 소개화면처럼 무상태가 딱히 필요없는 경우도 있다.
HTTP 에서 여러페이지의 로그인 상태 유지처럼 세션 상태유지가 반드시 필요한 경우도 있다.
➡ 이 경우에는 쿠키와 세션, 그리고 토큰을 이용하여 상태를 유지한다.
다만 이런 특수한 경우를 제외하고 대부분 리소스 요청은 최대한 Stateless로 구현하는 것이 좋은 게 맞다.

# 비연결성(connectionless)

HTTP는 기본적으로 연결을 유지하지 않는 모델이다.

클라이언트의 요청이 들어오면, 해당 요청을 빠르게 응답하고 바로 서버에서는 연결을 끊어버린다.
HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다.
➡ 애초에 웹 서비스에서는 한 사람이 동시에 처리하는 요청이 많지가 않다. (ex. 검색버튼을 초당 10번씩 요청)

하지만 이렇게 연결을 빠르게 끊어버리면, 요청이 들어 올 때마다 TCP/IP연결을 새로 맺어 오버헤드가 발생한다.

HTTP 지속 연결(Persistent Connections)라는 개념을 도입했다.
➡ 웹 브라우저에서 사이트를 요청하면 정해진 시간동안 (HTML, JS, CSS등) 연결을 끊지 않고 응답을 받는다.
이 부분은 HTTP2, HTTP3로 넘어오며 다양한 방법을 이용해 성능을 최적화 시키고 있다.

물론 비연결성도 잠깐동안 연결을 해야 통신을 한다. [한 요청이 끝나면 바로 연결을 끊어버린다]는 의미로 받아들이자.

# HTTP 메시지

HTTP에서는 거의 모든 종류의 데이터를 전송 할 수 있다고 했다. 그렇다면 어떻게 메시지를 만들어 전송할까?

HTTP 헤더와 바디는 공백 라인으로 구분한다. (그래서 공백라인이 필수)

# 1. Start-line (파라메타, 상태코드)

Requset 메시지 : HTTP 메서드, host(예: naver.com)에 보낼 경로와 쿼리문, HTTP 버전등을 표기한다.

GET /search?q=hello&hl=ko HTTP/1.1

Respone 메시지 : HTTP 버전, HTTP 상태코드등을 표기한다.

HTTP/1.1 200 OK

# 2. Header

헤더에는 [ key: value ]로 HTTP 전송에 필요한 모든 부가정보를 전송한다.

한 key에 여러 value를 넣어 리스트로 받아올 수 있다. 다만 잘 사용하는 방법은 아니다.
기본제공 헤더에는 다양한 종류가 있으며, 필요하다면 임의의 헤더값을 추가해서 사용할 수 있다.
➡ Body 타입, 반환받을 타입(Accpet), 메시지 크기, 압축여부, 캐시 정보, 쿠키 등..

Requset 메시지

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

<한줄 띄우고 Body 시작, Body가 없어도 한줄은 반드시 띄워야함.>

Respone 메시지

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length:3423

<한줄 띄우고 Body 시작>

# 3. Body

헤더 입력이 끝나면, 한줄 공백을 띄우고 바로 Body에 넣을 데이터를 적는다.

GET 처럼 단순 리소스 요청에는 Body를 적지 않는다. 최신 HTTP 스펙에는 적을 수 있긴하나, 잘 사용안한다.
만약 Body가 없다면, 헤더 마지막에 공백 한줄만 넣고 비워서 보낸다.
Body는 Text, 이진데이터, HTML, JSON등 거의 모든 타입을 지원하며, 헤더에 Content-type을 명시해서 사용한다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length:3423

<html>
    <body>
    ...실제 전송할 데이터, 바이트로 표현가능한 모든데이터
    압축해서 전송하기도 한다.
    </body>
</html/>

'👀기본 지식 > 웹 기본지식' 카테고리의 다른 글

HTTP #6 기본적인 API 설계 (0)	2021.09.06
HTTP #5 요청 메서드 (0)	2021.09.06
HTTP #3 URI와 웹 브라우저 요청흐름 (0)	2021.07.17
HTTP #2 인터넷 네트워크의 이해 (0)	2021.07.17
웹 프론트엔드와 백엔드 (0)	2021.03.22

블로그의 정보

JiwonDev

HTTP #4 특징과 메시지 구조

# HTTP의 시대

# 클라이언트 - 서버 구조

# 상태유지, 무상태성(Stateful, Stateless)

@ 상태가 어쩔수없이 필요한 경우도 있다.

# 비연결성(connectionless)

# HTTP 메시지

# 1. Start-line (파라메타, 상태코드)

# 2. Header

# 3. Body

'👀기본 지식 > 웹 기본지식' 카테고리의 다른 글

블로그의 정보

활동하기

티스토리툴바

# HTTP의 시대

# 클라이언트 - 서버 구조

# 상태유지, 무상태성(Stateful, Stateless)

@ 상태가 어쩔수없이 필요한 경우도 있다.

# 비연결성(connectionless)

# HTTP 메시지

# 1. Start-line (파라메타, 상태코드)

# 2. Header

# 3. Body

'👀기본 지식 > 웹 기본지식' 카테고리의 다른 글

블로그의 정보

활동하기

공유하기

다른 글

티스토리툴바