[CS공부] 네트워크 구조(3)-HTTP (1.0부터 3.0까지)

Min Kim·2023년 2월 15일

CS 네트워크

CS 공부

목록 보기

4/15

들어가기 전에

OSI 7계층 중에서 application layer를 배우면서 HTTP 프로토콜에 대한 내용이 워낙 많아서 따로 한 번 정리를 해보았습니다.

1. HTTP의 특징

무상태성(stateless)

HTTP는 상태가 없는 프로토콜입니다.
=> 클라이언트와 서버가 서로 연결되어 있는 것이 아니기 때문에 각각의 통신이 독립적이라는 뜻
상태(로그인 상태 등)를 전송하기 위해 세션, 쿠키 사용합니다.

비연결성(Connectionless)

요청을 주고받을 때만 연결을 유지하고 요청이 끝나면 연결을 끊습니다.
=>연결 유지에 대한 자원을 아낄 수 있습니다.
서버가 클라이언트의 상태를 유지하지 않기 때문에 요청을 보낼 때마다 모든 데이터를 매번 보내야 합니다.

서버-클라이언트 구조

일반적으로 클라이언트는 웹 브라우저를 의미, 서버는 요청의 대상이 되는 서버 컴퓨터를 의미합니다.
서버가 추가 정보를 관리하지 않아도 되고, 클라이언트가 서버에 요청할 때 데이터를 담아서 보내기 때문에 아무 서버나 호출해도 됩니다.

2. HTTP 종류

역사의 흐름 순으로 정리를 하면서 3.0 버전까지 알아보겠습니다.

1) HTTP/0.9

HTTP 초기 버전을 구분하기 위해 부르는 버전. (1991년)
요청은 단일 라인으로 구성되며, 리소스에 대한 method는 GET만 존재.
응답도 극도로 단순. (파일 내용 자체로만 구성)
HTTP 헤더도 없고, HTML파일만 전송 가능했던 것이 특징.
상태 오류 코드도 없었기 때문에 문제가 발생한 경우 특정 HTML 파일을 오류에 대한 설명이 함께 보내짐.

/* 요청 */
GET /mypage.html

/* 응답 */
<HTML>
A very simple HTML page
</HTML>

2) HTTP 1.0

버전 정보가 GET라인에 붙은 형태로 전송되기 시작.(1996년)
상태 코드가 응답의 시작부분에 붙어 전송되었고, 그 결과에 대한 동작이 가능. (요청의 성공과 실패를 파악 가능)
HTTP 헤더 개념이 추가되어 유연하고 확장 가능하도록 개선됨.
Content-Type 도입으로 HTML 이외의 문서 전송 기능이 가능해짐.

😜 추가 지식

한계
- 커넥션 하나당 요청 하나와 응답 하나만 처리 가능했음.
- 매우 비효율적인 동작과 서버 부하의 문제.
- HTTP 1.1에서 개선.
/* 요청 */
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

/* 응답 */
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>
HTML이 아닌 파일인 이미지파일 요청 메세지
GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

3) HTTP 1.1

Persistent Connection 추가됨.
- 지정한 timemout 동안 커넥션을 닫지 않는 방법을 통해 커넥션의 사용성이 높아짐.
Pipelining 추가.
- 앞 요청의 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내고 그 순서에 맞춰 응답을 받는 방식.
- 순차적으로 하나씩 요청 / 응답이 처리되는 기존 방식을 개선.
- 하나의 커넥션에 여러개의 요청이 들어 있을 뿐, 동시에 여러개의 요청을 처리해 응답으로 보내주는 것은 아님. (multiplexing 되지는 않음)

😜 추가 지식

한계
- Head Of Line Blocking (HOL)
  : 결국 앞 요청의 응답이 너무 오래걸리면 뒤 요청은 Blocking 되어버림.
- Header 구조의 중복
  : 연속된 요청의 헤더의 많은 중복이 발생. => 메모리와 cpu리소스를 낭비.

/* 요청 */
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

/* 응답 */
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)

4) HTTP 2.0

기존 HTTP 1.X 버전의 성능 향상에 초점을 맞춘 프로토콜. (2015년 등장)
표준의 대체가 아닌 확장. (표준 : HTTP 1.1)

특징
⑴ HTTP 메시지 전송 방식의 전환
⑵ Multiplexed Streams
⑶ Stream Prioritization
⑷ Server Push
⑸ Header Compression

(1) HTTP 메시지 전송 방식의 전환

기존 : 일반 텍스트 형식
개선
- Binary Framing 계층을 추가해서 보내는 메시지를 프레임(frame)이라는 단위로 분할하며 추가적으로 바이너리로 인코딩을 한다.
  (바이너리 형식 사용으로 파싱속도 및 전송 속도가 빠르고 오류 발생 가능성이 낮아짐.)

(2) Multiplexed Streams

기존 : HTTP 1.1의 Pipelining 으로 하나의 커넥션에 여러 요청이 있지만, 결국 동시에 여러 요청을 처리해 응답으로 주지는 못하였음.
개선
- 구성된 연결 내에 전달되는 바이트의 양방향 흐름을 의미하는 Stream으로 요청 / 응답이 교환됨.
  (하나의 커넥션 안에 여러개의 Stream 존재 가능.)
- 메시지가 이진화된 텍스트인 프레임(frame)으로 나뉘어 요청마다 구분되는 Stream을 통해 전달.
- 즉, 프레임(frame)이 각 요청의 스트림(stream)을 통해 전달되며, 하나의 커넥션 안에 여러개의 스트림(stream)을 가질 수 있게되어 다중화(multiplexing)가 가능해짐.
  -> 동시에 여러 요청을 처리하는 것이 가능해짐.
  -> Stream을 통해서 각 요청의 응답의 순서가 의미가 없어져서 HOL Blocking이 해결됨.

(3) Stream Prioritization

리소스간 우선순위를 설정하는 기능.
Stream에 우선순위를 부여해서 인터리빙되고 전달하는 것이 가능해짐.

😜 추가 지식

인터리빙 : 여러개의 스트림에서 쪼개진 프레임들을 서로 끼워넣는 것.

(4) Server Push

단일 클라이언트 요청에 여러 응답을 보낼 수 있는 특징을 통해 Server에서 client에게 필요한 추가적인 리소스를 push해주는 기능.

(5) Header Compression

기존 : 연속된 요청의 경우 많은 중복된 헤더의 전송으로 오버헤드가 많이 발생했음.
개선
- 요청과 응답의 헤더 메타데이터를 압축해서 오버헤드를 감소.

😜 추가 지식

한계

각 요청마다 Stream으로 구분해서 병렬적으로 처리하지만,
결국 이에는 TCP 고유의 HOL Blocking이 존재.

서로 다른 Stream이 전송되고 있을 때, 하나의 Stream에서 유실이 발생되거나 문제가 생기면 결국 다른 Stream도 문제가 해결될 때 까지 지연되는 현상이 발생. (신뢰성이 보장된 프로토콜이기 때문임.)

즉, 이러한 TCP의 태생적인 HOL Blocking을 해결하기 위해 HTTP3.0 / QUIC이 등장.

5) HTTP 3.0 / QUIC

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