[HTTP] HTTP란 무엇일까?
HTTP란 무엇일까?
HyperText Transfer Protocol
웹에서 데이터를 주고받기 위해 만들어진 통신 규약
1990년대 초, 팀 버너스리가 월드 와이드 웹(www)을 제안하면서, 문서를 하이퍼링크로 서로 연결해서 보여주는 시스템이 등장했다.
그런데 문서를 서로 주고 받을 때 '이런 형식으로 보낼게'라는 서로 간의 약속이 필요해졌다.
왜 HTTP가 필요했을까?
사람들마다 다른 형식으로 요청을 보내면, 서버도 그때마다 다르게 응답을 보내줘야 된다.
이런 혼란을 막기 위해 요청과 응답의 형식을 통일시키는 것이 필요했다.
그 결과로 만들어진 것이 HTTP이며,
이 규약 덕분에 클라이언트와 서버가 정해진 형식으로 안정적으로 통신할 수 있게 됐다.
현재는 HTTP를 통해 거의 모든 형태의 데이터를 전송할 수 있게 됐다.
ex) HTML, Text, 이미지, 음성, 영상, JSON, XML
HTTP 특징
HTTP는 4가지 특징을 가지고 있다.
1. 클라이언트-서버 구조
2. 무상태성
3. 비연결성
4. HTTP 메시지
1️⃣ 클라이언트-서버 구조
HTTP는 요청(Request) 응답(Response) 구조로 동작한다.
클라이언트에서 요청을 보내면, 서버에서 요청에 따른 결과를 만들어 응답을 보내준다.
2️⃣ 무상태성 (stateless)
stateless란 '클라이언트는 서버의 상태를 보존하지 않는다'를 뜻한다.
위의 문장만 들으면 잘 감이 안 올 것이다.
먼저, 반대 개념인 statefull에 대한 개념을 예시와 함께 설명해 보겠다.
statefull
고객이 노트북을 사기 위해 매장에 방문하였다.
고객: 노트북 얼마인가요?
점원A: 100만 원입니다.
고객: 2개 주세요.
점원A: 200만 원입니다. 결제는 신용카드로 하시나요. 현금으로 하시나요?
고객: 신용카드로 할게요.
점원A: 네, 200만 원 결제하겠습니다.
점원A는 고객의 이전 요청을 기억하고 있기 때문에
고객의 질문에 알맞은 대답을 바로바로 할 수 있다.
이런 방식이 바로 statefull이다.
클라이언트의 이전 요청을 기억하고, 요청을 짧게 보내도 알맞은 응답을 해줄 수 있다.
하지만 동일한 요청을 서로 다른 점원에게 하면 어떤 상황이 발생할까?
고객: 노트북 얼마인가요?
점원A: 100만 원입니다.
고객: 2개 주세요.
점원B: 네? 어떤 제품을 2개 드릴까요?
고객: 신용카드로 할게요.
점원C: 네? 어떤 것을 신용카드로 결제하시는 걸까요?
이전의 맥락을 모르는 점원B와 점원C는 고객의 요청을 알아듣지 못한다.
이게 바로 statefull의 한계이다.
stateless
이제 stateless에 대한 개념을 예시와 함께 설명하겠다.
고객이 서로 다른 점원에게 요청을 하였다.
다만, 이전과 다르게 요청을 할 때 모든 요구사항을 함께 제시하였다.
고객: 노트북 얼마인가요?
점원A: 100만 원입니다.
고객: 노트북 2개 주세요.
점원B: 200만 원입니다. 결제는 신용카드로 하시나요. 현금으로 하시나요?
고객: 노트북 2개 신용카드로 결제할게요.
점원C: 네, 200만 원 결제하겠습니다.
점원이 바뀌어도 요청이 완전하기 때문에 이전 맥락을 몰라도 알맞은 응답을 할 수 있다.
이게 바로 stateless이다.
클라이언트의 이전 맥락을 몰라도 클라이언트 요청에 알맞은 응답을 할 수 있다.
맨 처음에 말한 '클라이언트는 서버의 상태를 보존하지 않는다'과 동일한 내용이다.
stateless의 장단점
stateless는 각각의 장단점을 가지고 있다.
장점: 서버 확장성이 높다.
단점: 클라이언트가 추가 데이터를 전송해야 한다.
서버 확장성이 높다는 것은 위의 예시와 함께 생각해 보면 쉬운 말이다.
완전한 형태의 요청을 보내기만 하면, 어떤 점원에게 물어봐도 원하는 응답을 받을 수 있다.
이걸 서버로 대입해서 생각하면, 클라이언트가 증가해서 수많은 요청이 생길 때 서버를 무한으로 추가해서 대응할 수 있다는 이야기이다.
3️⃣ 비연결성
HTTP는 기본적으로 클라이언트와 서버의 연결을 유지하지 않는 구조이다.
이전 글에서 클라이언트가 서버에게 데이터를 요청하기 위해 TCP 연결이 필요하다고 말했었다.
HTTP에서는 서버가 응답을 완료한 순간, TCP 연결을 유지하지 않고 즉시 끊는다.
이런 구조 덕분에 서버의 자원을 매우 효율적으로 사용할 수 있다.
예를 들어, 1시간 동안 수천 명이 웹 서비스를 이용해도, 실제 서버가 동시에 처리하는 요청은 수십 개 수준에 불과하다.
TCP 연결을 오래 유지하지 않기 때문에 불필요한 자원 낭비를 줄일 수 있는 것이다.
다만 비연결성 구조에는 한계가 존재한다.
연결이 끊어진다는 것은 요청을 보낼 때마다 TCP 연결을 새로 해야 된다는 것을 뜻한다.
서버에서 보낸 자원을 다운로드할 때 HTML뿐만 아니라 Javascript, CSS, 이미지 등 추가적인 리소스를 다운로드하여야 되는데, 그때마다 새롭게 TCP 연결을 하게 된다.
그래서 해당 문제를 해결하기 위해 HTTP 지속 연결(Persistent Connection)이 등장했다.
첫 번째 요청을 처리한 후에도 연결을 끊지 않고, 같은 연결을 재사용해서 여러 요청과 응답을 주고받을 수 있다.
4️⃣ HTTP 메시지
마지막으로 HTTP 메시지에 대해 알아보겠다.
HTTP 메시지는 '요청과 응답을 어떤 형식으로 주고받을지'에 대해 구체적으로 정의한 내용이다.
구조는 다음과 같다.
start-line은 요청 메시지일 때는 request-line, 응답 메시지일 때는 status-line이라고 부른다.
세부적인 내용도 다르다.
request-line: HTTP 메서드 / 요청 대상 / HTTP 버전
status-line: HTTP 버전 / HTTP 상태 코드 / 이유 문구
header에는 HTTP 전송에 필요한 모든 부가 정보가 다 들어있다.
message body에는 실제 전송할 데이터가 들어있다.
마무리
HTTP는 클라이언트와 서버 간에 데이터를 어떻게 주고 받을지 정해놓은 통신 규약이다.
서로 다른 시스템이 안정적이고 일관되게 데이터를 주고 받기 위해 만들어졌다.
HTTP는 무상태성, 비연결성의 특징을 가지고 있으며, 요청과 응답 메시지 형식 또한 명확하게 정해져있다.
구조는 간단하지만 확장 성이 높아 오늘날 대부분의 웹 서비스에서 널리 사용하고 있는 방식이다.
[참고 자료]
김영한님 강의 - 모든 개발자를 위한 HTTP 웹 기본 지식