개요
HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다.
HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트 - 서버 프로토콜이기도 하다.
HTTP 프로토콜과 보안성을 높이고 지연 시간을 줄이기 위한 HTTP의 특징을 알아보려고 한다.
하나의 웹 문서는 HTTP 프로토콜로부터 불러온 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등의 하위 문서들로 구성된다.
HTTP란?
1990년대 초에 설계된 HTTP는 계속해서 진화해온 확장 가능한 프로토콜이다.
HTTP는 애플리케이션 계층 즉 OSI 7계층에서 응용 계층에 속하는 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으론 무엇이든 사용이 가능하지만 보통 TCP 혹은 암호화된 TCP인 TLS를 통해 전송된다.
HTTP는 OSI 7계층에서 응용 계층에 속하기 때문에 데이터를 어떤 형식으로 주고받을지 규정하는 역할을 하는 프로토콜이다.
HTTP는 데이터를 주고 받을 때 HTTP 메세지 라는 구조의 프로토콜을 사용한다. HTTP 메세지는 크게 요청(Request)과 응답(Response)로 구성된다.
HTTP 요청 예시
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36
Accept: text/html
HTTP 응답 예시
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 137
<html>
<head><title>Example Page</title></head>
<body><h1>Hello, World!</h1></body>
</html>HTTP의 버전별 특징
HTTP는 0.9 버전부터 시작하였다. 한때 one-line-protocol이었던 HTTP는 현재 버전 3까지 확장되었다.
각 버전별 특징은 다음과 같다.
HTTP/0.9 - one-line-protocol
HTTP의 초기 버전에는 버전 번호가 없었다. 때문에 1.0 이후 버전과 구별하기 위해 0.9로 불리게 되었다.
HTTP/0.9는 극히 단순하다. 요청은 단일 라인으로 구성되며 사용 가능한 메서드는 GET이 유일했다.
요청&응답 예시
요청
GET /mypage.html
응답 또한 극도로 단순하다. 오로지 요청받은 파일 내용만을 응답으로 보낸다.
응답
<html>
A very simple HTML page
</html>
HTTP 헤더도 없다. 이는 HTTP/0.9는 오로지 html 파일만 전송할 수 있으며 다른 유형은 전송될 수 없음을 의미한다.
요즘과 같은 200, 404와 같은 상태나 오류 코드 또한 없다.
문제가 발생한 경우, 특정 HTML 파일이 만들어지고 사람이 처리할 수 있도록 해당 HTML 파일 내부에 문제에 대한 설명이 추가되었다.
HTTP/1.0 - 확장성 만들기
HTTP 1.0부터는 다양한 특징을 가지게 되었다.
- 각 요청 안에 버전 정보가 포함되어 전송되었다.
- 상태 코드(200, 400 등) 라인 또한 응답의 시작 부분에 붙어 전송되었다. 브라우저가 요청에 대한 성공과 실패를 알 수 있고 그 결과에 대한 동작을 할 수 있게 되었다.
- HTTP 헤더 개념이 요청과 응답 둘 다 도입되었다. 메타데이터 전송이 가능해졌고, 프로토콜이 극도로 유연하고 확장성이 높아졌다.
- Content-Type이 추가되었다. 이 덕분에 일반 HTML 파일 외에 다른 문서들을 전송할 수 있다.
HTTP/1.1 - 표준 프로토콜
HTTP/1.1은 HTTP의 첫 번째 표준화 작업이다.
HTTP/1.1은 모호함을 명확하게 하고 많은 개선 사항들을 도입했다.
HTTP/1.1에서 개선된 내용은 다음과 같다.
- 연결을 재사용할 수 있다. 이를 통해 요청 응답 시간을 절약한다. 단일 리소스를 표시하기 위해 여러 번 연결을 열 필요가 없기 때문이다.
- 파이프라이닝을 추가하여 첫 번째 요청에 대한 응답이 완전히 전송되기 전에 두 번째 요청 전송을 가능하게 하여 통신 지연 시간을 단축시켰다.
- 청크된 응답을 지원한다.
- 추가적인 캐시 제어 메커니즘을 도입하였다.
- 언어, 인코딩, 타입과 같은 컨텐츠 협상(Content negotiation)을 도입하여 클라이언트와 서버간 교환하려는 가장 적합한 컨텐츠를 주고 받을 수 있게 되었다.
- Host 헤더를 추가하여 동일 IP 주소에 다른 도메인을 호스트하는 기능을 추가하였다.
HTTP 2.0 이전의 발전
- REST가 설계되었다. 이를 통해 모든 웹 애플리케이션에서 API가 브라우저나 서버를 업데이트 하지 않고도 데이터를 검색하고 수정할 수 있게 되었다.
- 교차 출처 리소스 공유(CORS) 및 컨텐츠 보안 정책(CSP) 가 정의되었다. 이를 헤더에 추가하여 웹 보안을 강화시켰다.
HTTP/2 - 더 나은 성능을 위한 프로토콜
웹 페이지는 과거와 다르게 매우 복잡해졌다. 일부 웹은 그 자체로 애플리케이션이기도 했다.
더 많은 시각적 미디어, 상호작용을 위한 스크립트 코드 양과 크기가 증가하면서 그에 따른 많은 HTTP 요청이 있었고 많은 데이터가 전송되었다.
이때문에 HTTP/1.1 연결에 복잡성과 오버헤드가 많이 발생했다. 즉 지연 시간이 증가했다.
지연 시간을 줄이는 것은 웹 성능 향상을 위한 필수적인 과제이고 이 문제를 해결하기 위해 Google은 프로토콜 SPDY를 개발했다.
SPDY는 응답성을 증가시켰고 중복 데이터 전송 문제를 해결하였다.
HTTP/2의 특징은 다음과 같다.
- 요청과 응답의 완전한 멀티플렉싱(multiplexing)을 가능하게 하여 지연(latency)과 헤드-오브-라인 차단(head-of-line blocking)을 줄인다.HTTP/2는 앞에 시간이 오래걸리는 요청이 있어도 멀티플렉싱을 통해 뒤의 요청을 처리할 수 있도록 하였다. 즉 다중화 프로토콜로 동일 연결임에도 병렬 요청을 수행할 수 있다.
헤드-오브-라인 차단(Head-of-line blocking, 줄여서 HOL 차단)이란, 데이터가 일렬로 처리될 때 앞쪽에 있는 요청 하나가 처리 지연 또는 장애로 인해 막히면, 뒤에 대기하고 있는 모든 요청까지 함께 밀려서 처리가 중단되는 현상이다.
- **HTTP 헤더 필드를 효율적으로 압축(HPACK)**하여 프로토콜 오버헤드를 최소화한다.
- 서버 푸시(Server Push) 메커니즘을 도입했다. 서버 푸시는 클라이언트가 곧 필요할 것으로 예상되는 리소스를 서버가 미리 보내주는 방식이다.(실제 구현이 까다로워 현재 브라우저에서는 대부분 삭제되었다.)
HTTP/3 - QUIC를 통한 HTTP
HTTP/3는 이전 버전의 HTTP와 동일하지만 전송 계층에서 TCP 대신 QUIC를 사용한다.
QUIC는 Google이 개발한 전송 계층 프로토콜로, UDP를 통해 실행된다.
UDP는 TCP보다 빠르기 때문에 TCP와 TLS를 대체한다.
특징은 다음과 같다.
- HTTP 연결에 대해 보다 빠른 설정과 낮은 대기 시간을 제공한다
- UDP를 통해 실행되지만, TCP 프로토콜의 흐름 제어, 오류 제어, 혼잡 제어 등의 기능을 구현하였다.
- UDP의 전송 헤더를 암호화하여 패킷이 변조되지 못하게 한다.
- 네트워크 왕복 시간(RTT)을 줄여 페이지 로드 시간을 개선하였다.
- 방화벽, 라우터, NAT 등 네트워크의 중간에 있는 개체(Middlebox)들이 프로토콜을 변경하는 것을 어렵게 만들었다.
'CS' 카테고리의 다른 글
| [JS] 클로저(Closure)의 개념과 React에서의 활용법 (0) | 2025.04.13 |
|---|---|
| Event Interface and Document Object Model Event (2) | 2025.04.09 |
| 웹 브라우저의 동작 원리와 웹 최적화 (2) | 2025.03.25 |
| [JS] 스코프에 대하여 (0) | 2024.01.03 |