[WEB] HTTP란?

LDB·2025년 1월 18일

CS 지식

목록 보기

5/7

작성계기

말하자면 HTTP란 웹 환경에서 데이터를 주고 받기 위한 프로토콜로 이미 지식은 알고 있지만 개인적으로 본인이 잘알고 있다고 평소에 생각하고 있다면 다시한번 확인하여 본인이 정말로 잘알고 있는지 확인하는 작업을 거친다, 그런의미에서 웹에서 가장 기본적인 지식중에 하나인 HTTP에 대해 정리해보겠다.

HTTP

HTTP는 앞에서 말한대로(HyperText Transfer Protocol)의 줄임말로 각 단어의 앞단어를 따와 HTTP라고 한다. HTTP는 주로 웹에서 HTML을 주고 받을 때 사용하는 프로토콜로 처음에는 TCP방식으로 통신했으나 지금은 HTTP/3 버전이 출시하면서 기본적으로 UDP로 통신한다.

HTTP 진화과정

HTTP 0.9 (1991년)

완전 초기 HTTP버전으로 초기 버전을 구분하기위해 부르는 버전이다. 요청은 단일 라인으로 구성되며 리소스에 대한 method는 GET만 존재했다.

응답이 매우 단순했는데 HTML파일만 응답으로 왔다.
Header도 없고 HTML파일만 전송이 가능했다.

HTTP 1.0 (1996년)

여기서부터 우리들이 아는 HTTP헤더의 개념이 도입되었고 요청과 응답에 추가되며, 메타데이터를 주고 받고 프로토콜을 유연하고 확장가능하도록 개선 되었다.

HTTP의 버전정보와 요청 method가 함께 전송되었다.
상태 코드 라인도 응답의 시작에 추가되어 브라우저 요청시 성공과 실패 파악이 가능해졌다.
Context-Type 도입으로 HTML이외의 문서 전송이 가능해졌다.
(예를 들어 CSS, Javascript, csv, xml등)

HTTP 1.1 (1997년)

HTTP 1.0이 가지고있던 한계인 커넥션 하나당 요청 하나와 응답 하나만 가능했다. 이러한 동작으로 서버에 부하 문제로 발전했는데 HTTP 1.1에서 개선되었다.

Persistent Connection을 추가함으로써 지정한 timeout동안 커넥션을 닫지 않는 방법을 통해 커넥션의 성능이 높아졌다.
PipeLining 추가로 첫번째 요청을 보내도 두번째 요청을 보내는 것이 가능하게 되어 통신 지연시간이 단축되었다.

하지만 개선을 했음에도 여전히 문제가 있었다.

Head Of Line Blocking (HOL) : 앞의 요청이 너무 오래걸리면 뒤의 요청은 Blocking 되어버렸다.
Header 구조의 중복 : 연속된 요청의 헤더의 많은 중복이 발생

HTTP 2.0 (2015년)

HTTP 1.1에서 하나의 커넥션에 여러 요청이 있지만, 결국 동시에 요청을 처리해 응답으로 주지는 못했다.

HTTP 메세지 전송방식의 전환되었다.
Binary Framing 계층이 추가해서 보내는 메시지를 프레임이라는 단위로 분할하여 추가적으로 바이너리로 인코딩한다. 이 방식으로 파싱속도 및 전송 속도가 증가하고 오류발생 가능성이 낮아졌다.
Multiplexed Streams 도입
구성된 연결 내에 전달되는 바이트의 양방향 흐름을 의미하는 Stream으로 요청/응답이 교환된다. 하나의 커넥션 안에 여러개의 Stream 존재가 가능해졌다, 프레임(Frame)이 각 요청의 스트림(Stream)을 가질 수 있게되어 다중화(multiplexing)가 가능해졌다.
(그 덕분에 동시에 여러 요청을 처리하는 것이 가능해졌다. 요청 순서에 의미가 없어져서 HOL Blocking이 자연스럽게 해결되었다.)
Stream Prioritization 도입
리소스간 우선순위를 설정하는 기능이다, Stream에 우선순위를 부여해서 끼워넣고 전달하는 것이 가능해졌다.
Server Push 도입
단일 클라이언트 요청에 여러 응답을 보낼 수 있는 특징을 통해 Server에서 client에게 필요한 추가적인 리소스를 push해주는 기능이다.
Header Compression 도입
기존에는 연속되는 요청이 많으면 중복되는 헤더로 오버헤드가 많이 발생했다. 이러한 문제를 Header Compression을 도입하여 헤더 메타데이터를 압축해서 오버헤드를 감소했다.

이러한 개선의 노력에도 문제가 있었다.

Stream으로 구분하여 병렬적으로 다중의 요청을 전송할 수 있었지만 요청상의 HOL Blocking을 해소했을지는 모르지만 결국 TCP로 전송하기에 하나의 Stream이 전송되고 있을 때 유실이 생기거나 Stream에 문제가 생시면 결국 지연현상이 발생했는데 결국 TCP의 태생적인 HOL Blocking은 해결하지 못했다.

HTTP 3.0 (2022년)

기존의 HTTP 2.0의 고질적인 문제인 HOL Blocking을 해결하는 것에 중점을 두었는지 아예 프로토콜의 전송방식을 TCP에서 UDP로 바꾸는 파격적인 변환을 했고 QUIC라는 프로토콜을 새로 만들었다.

QUIC (Quick UDP Internet Connections)
Google에서 개발한 UDP 기반의 전송 프로토콜으로 TCP의 구조적인 문제로 성능 향상이 어렵기에 아예 UDP 기반으로 개발했다. QUIC는 3-way-handshake를 최적화 하는 것에 초점을 두고 개발되었다. 기존에는 TCP의 Stream은 하나의 chain으로 연결되는 것과 다르게 각 독립된 Stream chain을 구성하여 TCP 고유의 HOL Blocking을 해결했다.

그림으로 설명하자면 이렇게 바뀐것이다.

패킷 손실 감지에 걸리는 시간 단축
Stream에 A,B,C의 패킷 프레임이 존재한다고 가정하고 만약 B 패킷이 손실한다면 다른 관련 없는 패킷도 모두 대기를 해야했다. 하지만 QUIC는 헤더에 전송 순서를 나타내는 별도의 패킷 번호 공간을 부여했다, 그 결과 B 패킷이 손실 되어도 다른 A,C는 지킬 수 있게 되었다.
멀티플렉싱 강화
기존에도 존재하는 멀티플렉싱이 강화되었다.
보안 강화
기존에 헤더에서 암호화 대상이 아니던 영역까지 암호화에 포함되어 보안성이 강화되었다.
네트워크가 변경되도 연결유지
아마도 한번씩 겪어 보았을 텐데 모바일에서 WI-FI에서 본인 데이터모드로 변경했을 때 갑자기 동영상 끊김등의 일시적인 지연이 일어난 경험을 했을 것이다. 이유는 클라이언트가 서버에 요청하는 IP가 다르기 떄문이다. 그래서 다시 연결하기위해 핸드 쉐이크 과정을 거치게 되고 그 과정에서 지연시간이 발생했다.

하지만 QUIC는 Connection ID를 이용하여 서버와의 연결을 생성한다. Connection ID는 랜덤 값이기에 클라이언트IP가 갑자기 변경되어도 기존의 연결을 유지할 수 있다. 결과적으로 새로 연결을 생성할 때 마다 거치는 핸드쉐이크 과정을 생략할 수 있게되고 그래서 클라이언트의 IP가 변경되어도 연결이 유지가 된다.

결론

이렇게 HTTP가 최초로 나온 시점부터 현재의 시점까지 정리를 해보았는데 알고 있는 지식도 있었고 새롭게 알게된 지식도 있어서 나름 의미있는 시간이었다. 무엇보다 HTTP 3.0은 존재만 알고 있었고 그 특징은 잘 모르고 있었는데 이번기회에 확실하게 알 수 있었다, 언뜻보면 문제를 많이 보완한 HTTP 3.0이 완벽해 보이지만 단점이 존재한다.