[Network] #18 HTTP 특성

2024-12-29 4 분 소요

[혼자 공부하는 네트워크↗️], 컴퓨터 네트워킹: 하향식 접근 (제8판), 김영한 HTTP 웹 기본 지식을 바탕으로 정리한 글입니다.

HTTP는 사용자와 밀접하게 맡닿아 있으며, 웹 세상의 기반이 되는 가장 중요한 프로토콜이다.
이번 포스팅에서는 HTTP의 네 가지 중요한 특성에 대해 자세히 알아보도록 하자.

1. HTTP 개요

HTTP는 인터넷에서 데이터를 주고받기 위한 통신 프로토콜이다.
클라이언트는 HTTP 요청 메세지를 생성하고, 해당 서버에 해당 서버의 주소(URL)와 함께 요청을 보낸다.

서버와 클라이언트의 개념은 상대적이다!

아래 사진에서 웹브라우저가 웹서버에 날씨데이터를 요청하고, 웹서버는 다시 기상청 서버에 데이터를 요청 후 리턴을 받아 그 결과를 웹브라우저에게 전달한다.

이때 웹서버는 서버의 역할도 하지만, 데이터를 요청하는 클라이언트의 역할도 한다.

2. HTTP의 네 가지 특성

2.1 요청-응답 기반 프로토콜

HTTP는 클라이언트-서버 구조 기반의 요청-응답 프로토콜이다.

클라이언트는 HTTP 요청 메시지를 서버로 전송하고, 서버는 이에 대한 HTTP 응답 메시지를 반환한다.
HTTP 요청 메시지와 HTTP 응답 메시지는 메시지 형태가 다르다.
웹 브라우저의 개발자 도구 > 네트워크 탭에서 요청과 응답 메시지를 확인할 수 있다.

2.2 미디어 독립적 프로토콜

HTTP는 주고받을 리소스의 종류와 무관하게 동작하는 미디어 독립적 프로토콜이다.

그저 리소스를 주고받을 수단(인터페이스) 역할만 한다.
HTTP를 통해 HTML, JPEG, PNG, JSON, XML, PDF 등 다양한 형식의 리소스를 송수신할 수 있다.

2.2.1 미디어 타입(Media Type)

미디어 타입(Media Type)이란, HTTP에서 리소스의 종류를 나타내는 방식이며 MIME 타입이라고도 불린다.

즉, HTTP는 주고받을 미디어 타입에 특별히 제한을 두지 않고 동작하는 미디어 독립적 프로토콜이다.

2.2.2 미디어 타입의 구성과 종류

슬래시를 기준으로 타입/서브타입 형식으로 구성한다.

타입(type): 데이터의 유형
서브타입(subtype) - 주어진 타입에 대한 세부 유형

미디어 타입에는 부가적인 설명을 위해 선택적으로 매개변수를 포함할 수 있다.

타입/서브타입;매개변수=값의 형식으로 표현된다. (type/subtype;parameter=value)
e.g., type/html; charset=UTF-8

여러 미디어 타입을 통칭하고자 할 때는 와일드카드(*)를 사용하면 된다.

text/*: text 타입의 모든 서브타입
image/*: image 타입의 모든 서브타입
*/*: 모든 미디어 타입

미디어 타입의 종류는 매우 다양하며, 새로운 미디어 타입을 등록할 수도 있다.

2.3 stateless 프로토콜

HTTP는 상태를 유지하지 않는 stateless 프로토콜이다.

서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미이다.
클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주된다.

왜 HTTP는 상태를 유지하지 않을까?

① HTTP 서버는 일반적으로 많은 클라이언트와 동시에 상호 작용을 하기 때문에, 모든 클라이언트의 상태 정보를 유지하는 것은 서버의 큰 부담이 되기 때문이다.

② 특정 클라이언트가 특정 서버에 종속되는 상황을 방지하기 위해서이다.

상태를 유지하지 않으면 서버에 문제가 생겨도 다른 서버로 대체가 용이하다.
HTTP가 상태를 유지하는 프로토콜이라면, 클라이언트는 자신의 상태를 기억하는 특정 서버하고만 통신할 수 있다.

즉, stateless 프로토콜은 서버 확장성과 견고성에 유리하다.
💡 따라서 상태 유지는 최소한으로 사용해야한다. (e.g., 로그인)
일반적으로 브라우저 쿠키와 서버 세션 등을 통해 상태를 유지한다.

2.4 지속 연결을 지원하는 프로토콜

비지속 연결

HTTP는 기본이 연결을 유지하지 않는 연결이다.
- 초기의 HTTP 버전(HTTP 1.0 이하)
일반적으로 초 단위의 이하의 빠른 속도로 응답한다.
서버 리소스를 매우 효율적으로 사용할 수 있다.
하지만, 추가적인 요청-응답을 하기 위해서는 TCP/IP 연결을 새로 맺어야 하기 때문에 3 way handshake 시간이 추가된다.

➡️ 따라서 현재는 지속 연결을 사용한다.

지속 연결(persistent connection) 또는 킵 얼라이브(keep-alive)

최근 대중적으로 사용되는 HTTP 버전(HTTP 1.1 이상)
하나의 TCP 연결상에서 여러 개의 요청-응답을 주고받을 수 있는 기술

3. HTTP 메시지 구조

HTTP 메시지는 시작라인, 필드라인, 메시지 본문으로 구성되어있다.

필드라인은 없거나 여러개 있을 수 있다.
메시지 본문은 없을 수 있다.
필드 라인과 메시지 본문 사이에는 빈 줄바꿈이 있다.

3.1 시작 라인 (start-line)

HTTP 메시지는 HTTP 요청 메시지일 수도 있고, HTTP 응답 메시지일 수도 있다.

HTTP 메시지가 HTTP 요청 메시지일 경우: 시작 라인 = “요청 라인”
HTTP 메시지가 HTTP 응답 메시지일 경우: 시작 라인 = “상태 라인”

3.1.1 시작 라인 - 요청 라인 (요청 메시지)

① 메서드 (method)

클라이언트가 서버의 리소스(요청 대상)에 대해 수행할 작업의 종류를 의미한다.
대표적으로 GET, POST, PUT, DELETE 등이 존재한다.

② 요청 대상 (request-target)

HTTP 요청을 보낼 서버의 리소스를 의미한다.
보통 (쿼리가 포함된) URI의 경로가 명시된다.
- e.g., 클라이언트가 “http://www.example.com/hello?q=world“로 요청 -> 요청 대상은 “hello?q=world”
- 만약 하위 경로가 없더라도 요청 대상은 슬래시(/)로 표기

③ HTTP 버전

사용된 HTTP 버전
HTTP/<버전>이라는 표기 방식을 따르며, HTTP 버전 1.1은 HTTP/1.1 로 표기

3.1.2 시작 라인 - 상태 라인 (응답 메시지)

상태 코드, 이유 구문

상태 코드
- 요청에 대한 결과를 내타내는 세 자리 정수
- e.g., HTTP/1.1 200 OK, HTTP/1.1 404 Not Found
이유 구문
- 상태 코드에 대한 문자열 형태의 설명
- e.g., HTTP/1.1 200 OK, HTTP/1.1 404 Not Found

3.2 필드라인 (= 헤드라인)

0개 이상의 HTTP 헤더가 명시된다.

HTTP 헤더란, HTTP 통신에 필요한 모든 부가 정보를 의미한다.
- e.g., 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 …
콜론(:)을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성된다.

3.3 메시지 본문(바디)

HTTP 요청 혹은 응답 메시지에서 본문이 필요한 경우 선택적으로 메시지 본문에 명시된다.

실제 전송할 데이터를 의미한다.
HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 콘텐츠 타입을 사용할 수 있다.

3.4. HTTP 메시지 구조 정리

HTTP는 미디어 독립적인 프로토콜이므로 메시지 본문에는 어느 데이터가 명시되던 상관이 없다.

따라서 HTTP를 학습할 때에는 시작라인, 필드라인 위주로 학습을 진행해야 한다.
이번 포스팅에서는 요청 라인의 메서드와 상태 라인의 상태 코드, 이유 구문을 중점적으로 알아보도록 하자.

4. HTTP 발전

4.1 HTTP/0.9

현재 거의 사용되지 않는 초창기 HTTP 버전
사용 가능한 메서드: GET
HTTP 헤더 지원 X

4.2 HTTP/1.0

HEAD, POST 등 GET 이외에 메서드 추가
헤더 지원 시작
공식적으로는 지속 연결 미지원

4.3 HTTP/1.1📌

오늘날까지도 널리 사용되는 버전, 가장 많이 사용

지속 연결 공식적 지원
파이프라이닝, 콘텐츠 협상 기능 등 다양한 편의 기능 추가
메시지 본문 = 평문

HTTP 1.1의 고질적 문제, HOL 블로킹(Head-of-line blocking)

같은 큐에 대기하며 순차적으로 처리되는 여러 패킷이 있을 경우,
첫 번째 패킷의 처리 지연으로 인해 나머지 패킷 처리도 모두 지연되는 문제 상황

4.4 HTTP/2.0

HTTP/1.1의 효율과 성능을 높이기 위한 버전

메시지 본문 = 바이너리 데이터
헤더 압축 전송 기능

서버 푸시(sercer push) 기능

클라이언트가 요청하지 않았더라도 미래에 필요할 것으로 예상되는 리소스를 미리 전송하는 기능

HTTP 멀티 플랙싱(multiplexing)을 통한 HOL 블로킹 완화

여러 스트림(stream)을 활용해 병렬적으로 메시지를 주고받는 기술
요청-응답 단위는 하나의 스트림에서 이루어짐
스트림별 독립적인 송수신 가능
별도의 스트림을 통해 여러 데이터를 병렬적으로 주고받으며 HOL 블로킹 완화

4.5 HTTP/3.0

오늘날 점차 사용 확대되는 버전

TCP 대신에 UDP 사용
이전까지의 HTTP 버전 = TCP 기반 동작
HTTP/3.0 = UDP 기반 프롵콜인 QUIC(Quick UDP Internet COnnections) 기반으로 동작
연결형 프로토콜 기반 송수신 속도 < 비연결형 프로토콜 기반 프로토콜 송수신 속도

4.6 HTTP 버전 확인해보기

아래 웹 브라우저는 HTTP/3.0을 사용하고 있는 것을 확인할 수 있다.

박시은