HTTP란 무엇일까?(클라이언트-서버, stateless, connectionless, 메세지)

현재 포스팅은 영한님의 HTTP 강의를 바탕으로 작성한 포스팅입니다 :)

 

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

---

HTTP(HypterTest Transfer Protocol)

HTTP는 웹 상에서 정보를 주고받을 수 있는 프로토콜입니다.

 

처음에는 HyperText(링크로 문서들이 연결된 것)전송을 위해 개발한 프로토콜 이지만, 지금은 HTTP 메세지에 다양한 형태의 리소스(텍스트, 이미지, 음악, 동영상 등등)를 교환하게 되는데, 이런 리소스 교환을 위한 규약이 바로 HTTP입니다.

 

HTTP의 특징에 대해 정리해보자면 다음과 같습니다.

• 클라이언트 서버 구조
• 무상태 프로토콜(스테이트리스), 비 연결성
• HTTP 메세지를 통해 통신
• 단순함, 확장 가능

클라이언트 서버 구조

클라이언트는 사용자의 요청을 서버에 전달하고, 서버로부터 받은 응답을 사용자에게 제공하는 역할을 합니다. 일반적인 웹 브라우저(Chrome, safari 등)는 HTTP 클라이언트의 한 예입니다.

 

서버는 클라이언트의 요청을 받아 이를 처리하고, 그 결과를 클라이언트에게 돌려주는 역할을 합니다. 웹서버(Apache, Nginx 등)가 HTTP 서버의 한 예입니다.

 

클라이언트는 서버에 요청을 보내고, 서버는 이에 대한 클라이언트에게 전송하는 형태로 동작하게 됩니다. 이때 요청 및 응답의 메커니즘은 상태를 유지하지 않는(stateless) 특성을 가집니다. 즉, 각 요청은 독립적이며 서버는 이전 요청에 대한 정보를 기억하지 않습니다.

 

무상태 프로토콜(stateless)

stateless란 서버가 클라이언트의 상태를 보존하지 않는것을 의미합니다!

 

재미있는 예시와 함께 상태를 유지하지 않는다는 것이 무엇인지 같이 알아보겠습니다

아래 예시는 점원이 상태를 유지하고 있는 상태입니다.

만약 점원이 상태를 유지하지 않는다면 어떨까요??

점원이 고객의 상태를 유지하지 않는다면 위와 같이 질문을 해야합니다. 예를들어 노트북 2개 구매하겠습니다 라고 하지 않고, 상태를 유지할때처럼 2개 구매하겠습니다! 라고 한다면 어떤 것을 2개 구매한다는 것인지 점원은 모르는 것이죠

 

Stateful 상태라면 어떤 점을 고려해야할까요??

중간에 다른 점원(서버)로 바뀌는 상황을 고려해야합니다. 만약 바뀐다면 상태 정보를 다른 점원(서버)에게 알려주어야 합니다.

 

만약 Stateless의 경우엔 질문 자체를 상태 유지 여부와 상관없이 이해할 수 있기에, 중간에 다른 점원(서버)로 바뀌어도됩니다.

즉 갑자기 고객이 증가해도 점원을 대거 투입할 수 있는 것입니다.

 

백엔드 입장에서 갑자기 클라이언트의 요청이 확 증가해도 서버를 대거 투입할 수 있다는 것이 Stateless 상태의 장점이라 볼 수 있습니다.

하지만 데이터를 stateful에 비해 많이 보내야 할것입니다(필요한 정보를 다 보내야 하기에)

 

비연결성(Connectionless)

TCP/IP의 경우 기본적으로 연결을 유지하고 있습니다.

 

예를들어 클라이언트1 이후 클라이언트2가 요청을 보내고 서버가 응답한다고 가정해보겠습니다. 이때도 클라이언트1은 접속이 되어있는 상태입니다. 즉 서버는 연결을 계속 유지하면서, 서버 자원을 소모하게 되는 것이죠

 

연결을 유지하지 않는 모델(비연결성 : Connectionless)의 경우엔 응답을 받고나서 TCP/IP 연결을 종료시킵니다.

주고받을때만 연결을 하고 바로 끊어버리기에 자원 유지를 최소한으로 줄인다는 장점이있습니다. HTTP는 기본적으로 연결을 유지하지 않는 모델입니다.

 

하지만 이러한 비연결성 모델의 경우 TCP/IP 연결을 새로 맺어야 하기에 3 way handshake 시간이 추가된다는 점을 고려해야합니다.

 

현재는 HTTP 지속 연결(Persistent Connections)로 문제를 해결하고 있습니다.(HTTP/2, 3에서 더많은 최적화가 이루어진 상태)

 

---

HTTP 메세지

 

HTTP 요청 메세지의 start-line은 다음과 같은 형식을 가지고 있습니다.

method + request-target + Http-version

 

method(GET, POST, PUT, DELETE 등)는 서버가 수행해야 할 동작을 지정합니다. (ex: GET은 리소스 조회, POST는 요청 내역 처리)

request-target은 절대 경로 + 쿼리로 구성되어있습니다(absolute-Path[? query] (절대 경로 + 쿼리))

 

HTTP 응답 메세지의 start-line은 다음과 같이 구성되어 있습니다.

Http-version status-code reason-phrase

status-code는 클라이언트 요청의 성공 실패를 나타냅니다.(200 : 성공, 400 : 클라이언트 오류, 500: 서버 내부 오류)

reason-phrase는 사람이 이해할 수 있는 짧은 상태 코드를 나타냅니다(ex: 200의 경우 -> OK)

 

HTTP 헤더필드는 다음과 같이 구성되어있습니다.

이러한 헤더 필드엔 HTTP 전송에 필요한 모두 부가 정보들이 들어있습니다.(ex: 메세지 바디의 내용 및 크기, 압축, 인증, 요청 클라이언트 정보, 캐시 관리 정보 등등)

 

Messsage Body 부분엔 실제 전송할 데이터가 들어있습니다.

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

 

---