WWW의 믿을수 없는 성장은 무엇 때문이었을까?
- HTTP와 Hypertext Transfer Protocol이 기본적 역할을 했다
- HTTP 의 초기 역할은 문서 전송 -> 다른 문서의 링크 포함한
- 추후에 이미지 비디오도 전송도 가능해 졌다
HTTP1 부터 HTTP2, HTTP3 까지 각각의 한계를 어떻게 해결했는지, 성능 향상, 보안, 유저 경험에 대해 알아보자
HTTP1 - The Foundation
HTTP/1은 1996년 소개되었다
이전의 HTTP/0.9 는 오직 GET 메소드만 헤더 없이 -> HTTP response만 포함하고 있었다
HTTP/1.0은 HTTP/0.9 에서 아래의 항목이 추가 되었다
- 헤더
- 상태 코드
- POST
- HEAD
하지만 매 요청마다 새로운 TCP 연결을 해야 했다
HTTP/1.1 는 HTTP/1.0의 한계를 극복하기 위해 1997년에 소개 되었다
- HTTP1 의 정의 버전이다
- WWW의 성장을 이끌었다
HTTP/1.1 버전은 25년 넘게 장수하고 있는데 이러한 장수의 놀라운 비결은 무엇일까?
1. Persistent Connections
언급된 되로 HTTP는 단일 request, response 로 시작했다
클라이언트에서 서버를 연결하고, request 만들고 response를 받는다
그리고 연결 끝낸다 만약 다음 요청이 있으면 위의 과정을 반복한다.
이는 바쁜 음식점의 단일 웨이터 같다
웹 페이지가 멀티 리소스를 가져와야 할때도 연결과 끝내는 것을 반복해야 한다
또한 HTTP/1 는 3-way handshake 거쳤다 -> 연결의 비용이 높다
이러한 문제를 해결하기 위해 HTTP/1.1은 지속적 연결을 제공하면서 오버헤드를 낮췄다
TCP 연결은 닫으라는 말 없으면 열려 있어야 한다.
- 매 요청마다 닫지 않는다
- 다중의 TCP handshake는 없다
2.Pipelining
HTTP/1.1은 파이프 라인 개념으로도 소개되었다
클라이언트가 다중의 요청을 받는다 응답에 동기화 되지 않고
다음 요청을 보내기 전에 각각의 지연시간을 줄이면서 성능을 향상 시켰다
3. Chunked Transfer Encoding
응답을 작은 청크로 보내는 것도 가능해 졌다 - 전체 응답을 생성하기 전에
초기 페이지의 렌더링을 빠르게하고 유저 경험을 좋게 하였다
4. Caching and Conditional Requests
HTTP/1.1은 세련된 캐싱 메커니즘과 조건부 request로도 소개된다.
헤더에 추가된 Cache-Control, ETag 등을 이용해 클라이언트와 서버가 캐시 데이터를 잘 관리하게 하고 불필요한 전송을 줄였다.
If-Modified-Since, If-None-Match 등을 이용해 수정된 리소스만 전송하고, 대역폭의 성능을 향상시켰다
The Problem with HTTP/1.1
HTTP/1.1 은 20여년 동안 웹의 놀라운 성장을 가능하게 했다
하지만 웹도 많이 진화 했다
네트워크를 통해 더 많은 데이터를 전송, 다운로드 한다
웹 사이트는 80~90의 데이터를 요청하고 2MB의 데이터를 다운로드 받는다
그래서 아래와 같은 문제점이 발생했다
문제점
- 클라이언트가 2개의 이미지를 포함하는 HTML을 요청하고 왕복 100ms가 걸린다고 가정
- HTML을 받고 브라우저는 첫번째 이미지를 요청, 이는 100ms의 추가적 비용을 발생시킨다
- 두번째 이미지를 요청하면 또 100ms의 추가적 비용을 발생시킨다
- 2개의 이미지를 받으면, 페이지 랜더링을 끝낸다
웹 페이지의 리소스가 증가하면 지연시간이 커진다
이 문제를 해결하기 위한 해결책은 무엇일까?
1. Pipelining
- 응답을 기다릴 필요 없이 요청하기 때문에 100ms 를 아낄 수 있다
- 구현의 어려움으로 지원하는 곳이 없다
- head-of-line (HOL) blocking 이라는 문제가 발생할 수 있다
- queue 의 맨 앞이 block 되면 나머지도 전부 block 되는 문제
2. Use Multiple HTTP Connections
HOL blocking 문제는 하나의 도메인에 여러 Http connection 으로 해결이 된다
하지만 요즘 사이트에서는 이것도 충분하지 않다
해결 방법으로 서브 도메인이 정적 리소스를 제공하게 하는 것
- 도메인 샤딩
도메인 샤딩은 완벽해 보이지만 단점이 있다
- TCP 연결 시간
- 서버와 클라이언트의 비용
TCP 는 slow-start 알고리즘이다
- 점점 전송하는 양을 늘린다
3. Make Fewer Requests
다른 해결방법은 요청수를 줄이는 것
- 브라우저는 리소스를 캐싱한다
- 리소스를 결합된 파일의 번들로 제공
하지만 이미지를 다시 고쳐 써야되는 개발 노력이 든다
The Rise of HTTP2
HTTP1 의 성능 문제를 해결하기 위해서
1. Binary Framing Layer
HTTP1 는 사람이 읽을 수 있는 형태로 데이터를 보낸다
HTTP/2 는 binary format -> 프레임이라는 더 작은 단위로 전송 할 수 있게 한다
프레임은 기본적으로 TCP 패킷과 유사한 데이터 패킷
각 프레임은 단일 요청-응답 쌍을 나타내는 특정 스트림에 속한다
HTTP2는 HTTP 요청의 데이터 섹션과 헤더 섹션을 서로 다른 프레임으로 분리
- 데이터 프레임은 페이로드 또는 메시지를 포함
- 헤더 프레임은 메타데이터
프레임으로 나눔으로 효율적 전송이 가능하다
다른 스트림의 멀티 프레임도 같은 커넥션으로 전송 가능함
이럼에도 HTTP1 가 호환된다
장점
- 효율적
- 압축
- 공백, 대문자 등을 처리하기 위해 helper 를 사용하는 HTTP1 보다 에러가 적다
2. Multiplexing
full 요청, 다중의 응답을 허용
- 클라이언트와 서버는 메시지를 독립된 프레임으로 분해 후 다시 조립 가능
HTTP2 는 다중 요청 허용
다른 스트림을 사용하면서 동시에 보내고 받을 수 있다
- 각각의 프레임은 어떤 스트림에 속했는지 표시되어 있음
3. Stream Prioritization
스트림 우선순위도 지원
HTTP1 단일 요청, 응답이기 때문에 우선순위 필요 없음
HTTP2는 서버에서 브라우저로 리소스를 다시 보낼 수도 있음
서버는 우선순위가 높은 요청에 대해 더 많은 프레임을 보낸다
4. Server Push
클라이언트가 요청하기 전에 서버에서 데이터를 전달
클라이언트 관점에서는 데이터를 캐시할지 거부할지 결정
5. Compression
HTTP1 은 기본데이터만 압축하고 헤더는 텍스트로 전송
왜냐하면 헤드는 상당히 작았기 때문에
하지만 현대는 api 요청이 자주있어 문제가 발생
HPACK 를 사용해서 헤드를 작게 만들었다
HPACK
- 헤더를 보고 더 작게 만들 방법을 찾는다
- 이전에 전송한 헤드를 기억해서 다음에는 더 작게 만든다
The Need for HTTP3
웹이 계속 발전해서 HTTP2 와 TCP의 한계가 명확해 졌다
HTTP2 는 상당히 발전했지만 TCP의 의존도가 성능 문제를 야기했다
- 연결 지향
- 패킷 손실 처리
- HOL 차단
그래서 구글에서 QUICK 을 등장 시켰다
- 대기 시간 감소 - 무왕복 연결 설정으로 초기 연결 빨라짐
- 멀티 플랙스 - 한번의 연결로 여러 요청을 처리할 수 있다
- 보안 향상 - 기본적으로 암호화 지원
이는 HTTP3 개발에 길을 열었다
- TCP의 한계를 극복하기 위해
How HTTP3 Works?
HTTP3는 UDP를 사용한다
작동방식
- Connection establishment - 연결시 QUIC handshake
- QUIC and TLS integration - 암호화와 보안을 위해, TLS 핸드셰이크는 QUIC 연결 설정 프로세스 내에서 수행되어 전체 대기 시간을 줄인다
- Sending requests: - UDP를 사용하여 작은 패킷 전송
- Receiving responses: - 서버는 클라이언의 요청을 수신하고 더 작은 패킷으로 응답을 보낸다
- Handling packet loss: - 클라이언트와 서버가 이전에 통신했으면 한번의 왕복 또는 0번으로 통신 할 수 있다
- Handling packet loss: - 패킷이 손실되면 TCP와 달리 타임아웃을 기다리지 않는다
- Parallel data streams: - 동시에 여러 데이터 스트림을 보낼 수 있다
- Connection state - 연결 상태를 추적해 반복적 통신을 막는다
- Closing the connection - 클라이언트와 서버가 요청 응답을 완료하면, 둘 중 하나가 연결을 닫을 수 있다
Comparison and Adoption
HTTP1
- 여전히 HTTP1 버전이 인터넷에서 널리 사용
- 단순성과 호환성이 장점
HTTP2
- HTTP2도 상단히 많이 쓰인다
- 주요 브라우저가 지원해 준다
- 웹 요청의 60%
HTTP3
- 아직 낮은 비율로 사용
Reference
