HTTP 한 페이지 요약
글을 끝까지 읽으면 HTTP란 무엇인지, 어떤 특징을 가지며
백엔드, 프론트 개발을 하는데 있어서 왜 이걸 배워야하는지를 알 수 있다.
목차
1. HTTP 의 개념
2. HTTP 의 발전 과정
3. HTTP 의 특징 3가지
1. HTTP 의 개념
HTTP = HyperText Transfer Protocal 의 약자.
= 클라이언트와 서버가 데이터를 주고 받기 위해 사용하는 규칙이다.
택배에 비유를 해보겠다.
우리가 일상에서 택배를 보내거나 받을 때, 택배 상자나 포장지를 통해 물건을 취급한다.
그리고 '도로명 주소'나 '지번 주소' 시스템에 포함되는 주소를 적어서 택배를 보내야만 한다.
이러한 규칙이 지켜져야 택배가 원활하게 전달 된다.
데이터 전송도 이와 같다.
택배에서 송수신자가 물건를 주고 받기 위해서 규칙이 필요하듯이
데이터 전송도 클라이언트와 서버 간에 이러한 규칙이 필요하며
이 때 사용하는 규칙을 HTTP라고 하는 것이다.
백엔드, 프론트엔드 개발자는 클라이언트에게 데이터를 전송하거나 서버에 데이터를 요청하는 기능을 개발해야 한다. 택배를 보내기 위해서 최소한의 규칙들을 지켜줘야 물건이 제대로 도착하듯이, 데이터 전송에 관한 규칙인 HTTP 를 알아둬야 제대로 된 개발을 할 수 있다.
2. HTTP의 발전 과정
HTTP의 개념이 뭔지 설명은 들었는데 아직 파악이 안되었을 수도 있다. HTTP를 좀 더 알아보기 위해 HTTP의 과거를 파헤쳐보자.
초기 HTTP는 매우 단순한 형태였으며 계속해서 발전해왔다.
기준이 되는 버전은 HTTP/1.1 이며, HTTP/2 와 HTTP/3 은 HTTP/1.1을 기능 개선한 것으로 생각하면 된다.
초기 버전 HTTP부터 특징을 살펴보자.
HTTP / 0.9 (1991)
- GET 메서드만 지원
- 헤더가 없음
- HTML 문서만 전송 가능
HTTP / 1.0 (1996)
- 메서드 추가(POST, PUT 등)
- 헤더가 추가되었고, 헤더에 HTTP 버전 정보 포함
- content-type 이 추가되어서 HTML 문서 이외의 파일(이미지, 텍스트 등)도 전송 가능
- 응답에 상태 코드가 추가
HTTP / 1.1 (1997)
- Persistent Connection : 이전 버전에서는 [커넥션 1번 = 요청-응답이 1번씩] 하고 연결을 끊었기 때문에 다시 커넥션을 만들려면 비용이 발생하느 단점이 있었다. 이를 해결하기 위해 특정 시간동안 커넥션을 유지하여 계속 사용하도록 개선했다.
- Pipelining : 요청 > 응답 > 요청 > 응답 이렇게 동기식으로 보내는 것이 아니라 요청1 > 요청 2 > 요청 3 이렇게 요청대로 보내고, 요청의 순서대로 응답을 보내는 방식이다. pipelining은 HOL 문제를 야기한다.
- HOL(Head Of Line Blocking) : 요청의 순서대로 응답을 보내기 때문에 특정 응답의 시간이 오래걸리 뒤의 응답들이 밀려버리는 현상이 발생.
HTTP / 2 (2015)
HTTP 1.1 에서 성능 개선이 된 버전. 아래 Binary Frame과 Multiplexting 을 통해 HOL 문제를 해결하였다.
- Binary Frame : 문자열로 표현되었던 HTTP 메시지를 0,1 로 변환하여 보내서 효율성을 향상시켰다.
- Multiplexing : 하나의 커넥션에 여러 스트림을 만들어서 요청의 순서에 상관 없이 응답이 가능하도록 하였다.
- HPACK 사용 : 헤더를 압축하여 중복을 방지
HTTP / 3 (진행중)
이전 TCP를 기반으로 하지 않고 UDP를 개선한 QUIC를 기반으로 구현한다.
TCP는 3-way-handshaking 을 통해 신뢰성을 보장하지만 3번의 통신을 해줘야하는 단점이 존재한다. 반면 UDP의 경우 3-way-handshaking을 하지 않기 때문에 신뢰성은 떨어지지만 빠르다는 특징이 있다. 이러한 UDP의 특성에 오류시 데이터를 재전송해줌으로써 신뢰성을 추가한 것이 QUIC(Quick UDP Internet Connections)이다.
QUIC 을 기반으로 하기 때문에 빠르고 신뢰성 있는 통신이 가능하다.
3. HTTP 특징 3가지
HTTP 의 발전 과정을 통해 HTTP가 어떤 녀석인지 알 수 있었다.
복잡하고 양이 많지만 그중 가장 중요한 특징 3가지를 정리해보자.
1. 클라이언트 - 서버 구조
2. Stateless (무상태)
3. Connectionless(비연결성)
1. 클라이언트 - 서버 구조
첫번째 특징은 클라이언트 - 서버 구조로 이뤄져있다는 것이다. HTTP는 data를 제공하는 서버와 data를 사용하려하는 클라이언트, 이 두 그룹으로 구성되어 있다. 클라이언트가 data를 요청하면 서버가 그에 대한 응답을 한다.
유튜브로 예를 들자면, 영상을 보려고 하는 사용자(클라이언트)는 유튜브(서버)에 영상을 달라고 요청하고, 유튜브(서버)는 요청에 대한 응답으로 사용자(클라이언트)에게 영상을 보여준다.
2. Stateless (무상태성)
두번째 특징은 Stateless 이다.
Stateless란 서버에 값을 저장해두지 않는 대신, 필요한 데이터를 요청에 모두 떼려 박아서 각 요청이 독립적으로 수행 될 수 있도록 하는 것이다.
이와 반대로 Stateful 은 서버에 값을 저장해놓고, 요청에는 최소한의 정보만을 담아서 전송한다.
스터디룸 근무자(서버)가 고객(클라이언트)에게 예약을 받는 상황으로 설명하겠다.
<Stateless 한 상황>
근무자는 아무런 정보를 가지고 있지 않고( = 서버에 데이터를 저장하지 않고),
대신에 각 고객들이 예약을 할 때 이름, 핸드폰 번호, 예약 시간을 매번 말해줘서 예약을 진행한다.(요청에 필요한 데이터를 모두 기입)
<Stateful 한 상황>
근무자가 고객에 대한 모든 정보를 가지고 있고(서버에 값이 저장되어 있는 상황) 고객이 이름만 얘기해주면 예약이 된다(요청에는 최소한의 정보만 담겨있음)
언뜻보면 적게 말하면 되는 Stateful한 상황이 더 편해보일 수 있지만 단점이 존재한다. 만약 고객에 대한 정보가 없는 새로운 근무자가 예약을 받는다면 예약이 원활이 진행될 수 없다. 서버도 마찬가지이다. 기존 서버가 아닌 새로운 서버를 통해서 작업이 이뤄질 경우 요청이 원활하게 수행되지 않을 수 있다. 이 때문에 서버에 의존하지 않도록 하고 요청이 독립적으로 수행되는 Stateless 라는 특징을 갖는다.
3. Connectionless (비연결성)
마지막 특징으로는 Connectionless 이다.
클라이언트와 서버의 연결은 기본적으로 연결되지 않다가 필요시에 연결을 한다
사용하지도 않는데 통화 연결을 유지한다고 생각하면 얼마나 비용이 많이 들까?
클라이언트와 서버의 연결도 마찬가지이다.
초기 HTTP는 한번의 요청 - 그에 대한 응답이 진행되면 연결을 바로 끊었다. 한 마디씩 말하면 통화가 끊기는거다. 매번 다시 연결을 시도해야하는 비효율성이 발생하기에 HTTP/1.1 이후에는 Persistent Connection(지속적 연결) 을 통해 timeout 동안 연결을 계속 사용하도록 개선했다.
결론적으로, HTTP는 평소에 연결하지 않고 요청시 연결하여 필요 시간동안 유지하고 다시 연결을 해제하는 Connectionless 특징을 갖는다.
마무리
클라이언트 - 서버 사이의 데이터 전송을 위한 규칙인 HTTP의 발전 과정과 대표적인 3가지 특징에 대해 정리해보았다.
양이 워낙 방대해서 얘기하지 못한 부분도 있다. 계속해서 관련 글 업로드를 하여 링크를 남기도록 하겠다.
출처