🖥 HTTP ( Hyper Text Transfer Protocol )
HTTP라는 용어의 뜻부터 살펴보자
HTTP는 HyperText Transfer Protocol의 약자로 말 그대로 번역하자면 하이퍼텍스트를 변환시켜주는 프로토콜이다 라고 해석해볼 수 있겠다.
그렇다면
HyperText는 뭘까?
간단하게 문서라고 생각하면 편한데, 이 문서가 HTML이 될 수도 있고, 이미지가 될 수도 있고, 음성이나 영상 등.. 다양한 데이터가 될 수 있다.
그렇다면
Protocol은 무슨 뜻이지?
프로토콜은 컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙이다.
정리해보자면 문서를 컴퓨터가 알아먹을 수 있도록 변환시켜주는 규칙이라고 정의할 수 있겠다.
📟 HTTP의 특징
HTTP의 특징은 크게 4가지가 있는데
1. 클라이언트 서버 구조 2. 무상태 프로토콜, 비연결성 3. HTTP 메시지 4. 단순함, 확장 가능
이렇게 정리해볼 수 있다.
1. 클라이언트 서버 구조
클라이언트 서버 구조는 단순하다.
요청(Request), 응답(Response) 구조로 나누어져 있으며 클라이언트는 서버에 요청을 보내고 서버는 요청에 대한 결과를 만들어서 응답하는 구조이다.
이렇게 클라이언트와 서버와 나누어져 있는 게 당연하다고 생각할 수도 있지만 나누어져 있다는 것이 중요하다.
클라이언트에서는 UI적인 부분만 고민하면 되고, 복잡한 비즈니스 로직 같은 경우는 서버에서 고민하면 되는 것이기 때문에
양쪽이 독립적으로 진화할 수 있다는 장점이 있다.
2-1. 무상태 프로토콜 지향 (Stateless)
두 번째는 무상태 프로토콜을 지향한다는 것인데 말 그대로 상태를 보존하지 않는다는 뜻이다.
서버가 클라이언트의 상태를 보존하지 않는다는 것인데 상태 유지와 무상태를 알기 쉽게 비교하면서 알아보자
상태 유지
우리가 카페를 갔다고 생각해보자. 커피를 주문하기 위한 고객과 점원의 대화이다.
이 대화의 과정이 상태 유지라는 것인데,
점원이 고객이 하는 말을 기억하고 보관해놨다는 뜻이다.
이 상황에서 고객과 점원이 1명일 경우에는 상관이 없는데 중간에 점원이 바뀔 경우엔 어떻게 될까?
고객은 같은 말을 하겠지만 점원 A -> 점원 B에게 상황을 전달하지 않는 이상 무슨 말을 하는지 모를 것이다.
정리해보자면
상태 유지는 중간에 다른 점원으로 바뀌면 안 되고, 바뀔 경우에는 상태 정보를 바뀐 점원에게 알려줘야 한다는 특징이 있다.
반대로 무상태는 어떤 걸까?
무상태
무상태의 경우 고객이 요청할 때마다 어떤 것을 얼마나 필요한지에 따라 데이터를 보낸다.
이 경우에는 중간에 직원이 바뀐다면 어떻게 될 까?
위 상황과 다르게 중간에 점원이 바뀌어도 무리 없이 주문이 가능하다.
또한
고객이 많아져도 점원을 추가 투입시키면 된다.
그렇다면 상태 유지와 무상태를 서버와 클라이언트의 상황으로 보면 어떻게 될까?
클라이언트와 서버가 이런 식으로 돌아가고 있다고 생각해보자.
상태 유지의 경우
클라이언트는 서버 1 하고만 통신이 가능하다. 서버와 통신을 하던 중 서버 1에 장애가 나면? 클라이언트는 처음부터 요청을 다시 해야 한다.
하지만 무상태의 경우는
서버 1이 장애가 나더라도 중계서버가 서버 2랑 통신이 가능하게끔만 연결해주면 응답을 받을 수 있다.
또한 클라이언트의 요청이 많아질 경우에는 서버만 추가하면 된다.
하지만 무상태가 장점만 지닌 것도 아니다. 웹은 모든 것을 무상태로 설계하기는 힘들기 때문이다.
상황에 따라 상태 유지가 필요한 경우도 있는데 (로그인 상태 유지) 이 경우에는 브라우저의 쿠키나 세션 스토리지를 사용하여 상태를 유지하는 방법이 있겠다.
하지만 상태 유지는 최소한만 사용해야 한다는 것을 기억하자.
2-2. 비연결성
다음은 비연결성이다.
앞 상황과 같이 연결을 유지하는 모델과 연결을 유지하지 않는 모델을 비교하며 알아보자.
연결을 유지하는 모델
일반적으로 TCP / IP 같은 경우에는 연결을 유지한다.
클라이언트 1이 요청을 하고 서버가 응답을 준다. 그리고 클라이언트 2가 요청을 하고 서버가 응답을 준다.
이 상황에서 클라이언트 1은 할 게 없음에도 서버와 연결을 계속 유지하고 있다.
이 상황이 수백, 수만 개라고 가정해보자. 서버는 통신이 필요 없음에도 계속 연결을 유지하기 때문에 서버의 자원을 계속 소모하게 된다.
반대로 연결을 유지하지 않는 모델을 어떨까?
연결을 유지하지 않는 모델
연결을 유지하지 않는 모델은 클라이언트 1이 요청을 하고 서버가 응답을 주고 나면 연결을 바로 끊어버린다.
이런 식으로 처리를 하게 되면 클라이언트의 요청에 빠르게 응답을 할 수 있고, 서버 자원을 효율적으로 사용 가능하다는 장점이 있다.
하지만 연결을 유지하지 않는 모델도 장점만 있는 것은 아니다.
웹브라우저로 사이트를 요청할 때는 수많은 자원이 함께 다운로드되는데, 이때마다 연결/종료를 반복하게 되면 연결/종료를 반복하는 시간이 추가가 되어 사용자는 로딩 속도가 느리다고 느낄 수 있다.
따라서 현재는 HTTP 지속 연결을 통해 비연결성의 단점을 극복했다.
HTTP 지속 연결
이게 HTTP 지속 연결을 그림으로 나타낸 것인데,
오른쪽 그림이 비연결성 상태의 클라이언트와 서버의 통신을 나타낸 것이다. 데이터가 필요할 때마다 연결/종료를 반복하기 때문에 로딩 시간이 길어질 수밖에 없는 반면
HTTP 지속 연결의 경우
첫 번째 응답이 끝난 후 연결을 끊지 않고 몇 초간 대기한다. 그 안에 새로운 요청이 들어오면 응답을 다시 해주기 때문에 연결에 드는 시간이 줄어들게 된다.
이게 수천만개라고 가정했을 경우 많은 시간이 단축되는 것을 알 수 있다.
참조
https://developer.mozilla.org/ko/docs/Web/HTTP/Overview
https://developer.mozilla.org/ko/docs/Glossary/Protocol
본 내용은
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC 를 공부하며 정리한 글입니다.
'Web' 카테고리의 다른 글
브라우저 주소창에 google.com을 입력했을 때 어떤 일이 일어날까? (0) | 2023.01.20 |
---|---|
REST API 과 GraphQL API 어떤 차이가 있을까? (0) | 2023.01.12 |
[Web] 웹팩이란? (1) - 웹팩의 4가지 속성, Mode (1) | 2022.12.08 |