[HTTP2 In Action] 3. HTTP2로 업그레이드 여정

 

그간 HTTP 1.1 의 한계와 우회적 성능 향상 방법을 정리했다.

 

오늘은 HTTP/1.1 에서 HTTP/2 로 업그레이드된 과정과

 

HTTP/2 기초에 대해 정리하려고 한다.

 

SPDY 의 탄생

 

구글로부터 HTTP/2 의 전신이라고 할 수 있는 SPDY 가 개발되었다.

 

이 SPDY는 HTTPS 처럼 HTTP 를 감싸는 것과 비슷하게 개발되어,

 

HTTP의 근본적인 용도를 변경하지 않고 개발되어 

 

기존의 모든 네트워크, 라우터, 스위치 그 외의 인프라스트럭처는 

 

어떤 변경을 하지 않고 적용할 수 있었다.

 

이 점이 이전에 HTTP/1.1 을 개선하기 위해 진행했던 프로젝트 HTTP-NG 가 실패한 것과 반대로

 

성공할 수 있던 이유가 되었다.

 

SPDY 는 HTTP/1.1 의 근본적인 문제를 해결하기 보다 성능적 향상에 목적을 두었다.

 

이 때 도입한 중요한 개념은 다음과 같다.

 

• 다중화된 스트림
  • 요청 및 응답은 단일 TCP 연결을 사용했으며, 분리된 스트림들의 그룹으로 나눠진 인터리브된 패킷으로 조각남
• 요청 우선순위 지정
  • 모든 요청을 동시에 보내는 것으로 새로운 성능 문제를 발생시키기 않기 위해 요청의 우선순위 개념 도입
• HTTP 헤더 압축
  • 기존엔 HTTP 본문만 압축했다면 이젠 헤더도 압축

 

SPDY 는 기존 텍스트로 통신하던 HTTP/1.1 에서 바이너리로 변경하여

 

작은 여러 메세지를 처리하는데 단일 연결을 사용할 수 있게 되었다.

 

추가적으로 서버가 브라우저에게 리소스를 보낼 수 있는 서버 푸시 기능도 생겼다.

 

이런 SPDY는 거의 즉각적을으로 성공하여

 

HTTP/2 가 승인되고 HTTP/2가 빠르게 지원되기 시작할 수 있었다.

 

정말 HTTP/2 만 적용하면 극적으로 빨라질까?

 

https://www.tunetheweb.com/performance-test-360

HTTP versus HTTPS versus HTTP2 Test

 

실제로 극단적인 예시지만 네트워크 waterfall을 보면 http2 의 이점이 명확해 보인다.

 

http/1.1

 

http/2

 

하지만 실 운영 중인 사이트 중에서

 

실제로 HTTP/2 를 적용하고 나서도

 

성능 해결을 위한 우회 방법을 적용한 사이트라면

 

극적인 변화를 못느끼는 경우가 많다.

 

예를 들어 이미지를 20개 가져오는데

 

10개만 먼저 화면에 그리고

 

10개는 나중에 그린다.

 

이 때는 순차적으로 가져오는 HTTP/1.1 이 20개를 동시에 대역폭을 사용해서 가져오려 하는 HTTP/2 보다 

 

빠르게 가져올 수도 있다.

 

이 점은 아이러니하게도 HTTP/1.1 의 결함이 큰 문제가 아님을 의미한다.

 

하지만

 

이미지 스프라이팅, 인라인 CSS 나 JS과 도메인 샤딩 등을 지원하는 등의

 

노력을 들이지 않고도 비슷한, 그보다 빠른 성능적 이점을 얻을 수 있다는 점은 변함이 없다.

 

따라서

 

HTTP/2 에 대한 과장된 기대는 버리고  HTTP/2 로부터 얻을 수 있는 것이 무엇이고 어느정도인지 분명히 해야한다.

 

HTTP/2 로 업그레이드

HTTP/2 를 적용하기 위해 고려할 것들이 있다.

 

먼저 적용하기 위해 고려해봐야할 것은 

 

1. 브라우저가 잘 지원되는가

2. 인프라스트럭처가 잘 지원되는가

 

이다.

 

만약 잘 지원되지 않는다면 어떻게 해야할지도 알아야 한다.

 

그렇다면 HTTP/2 를 적용하기 위한 방법은 무엇이 있을까?

 

HTTP/2 적용 방법

 

1. 웹 서버에 설치할 수 있고

 

2. 리버스 프록시를 쓸 수 있고

 

3. CDN 을 쓸 수도 있다.

 

웹 서버만 운영하는 경우 웹 서버에 직접 설치할 수 있다. 

 

하지만 이 경우에는 OS를 직접 업그레이드 해줘야하는 문제가 있다.

 

만약 어떠한 문제로 웹 서버에 직접 설치하는 것이 아니라면, 

 

리버스 프록시를 고려해볼 수 있다.

 

역방향 프록시를 둬서 서버 앞의 프록시에서 HTTP2 를 활용화해볼 수 있다.

 

브라우저와 역방향 프록시가 HTTP2 로 통신하고,

 

해당 프록시와 우리 서버는 기존 HTTP/1.1 로 통신하여

 

이점을 가져가는 것이다.

 

이 역방향 프록시는 우리 서버와 멀지 않은 곳에 있고 브라우저가 아니니 6개의 최대 연결 제한도 없어,

 

HTTP/1.1을 쓰더라도 큰 성능 이슈 없이 사용할 수 있다.

 

CDN도 일종의 역방향 프록시 서버이므로 비슷한 원리로 HTTP/2 를 제공한다.

 

 

요약

 

HTTP/2 의 전신인 SPDY가 있었고 다중화된 스트림, 요청 우선순위 지정, 헤더 압축의 개념을 도입하였고 널리 쓰여 HTTP/2 가 빠르게 적용할 수 있는 배경이 되었다.

 

HTTP/2 를 적용할 때 무조건적인 성능 향상이 있을 수 없으니, 잘 따지고 도입하고 테스트해야 한다.

 

HTTP/2 는 다양한 방법을 통해서 적용할 수 있다.

 

서버가 직접 HTTP2 를 처리하도록 설치할 수 있으나 OS 의 버전 관리를 해야할 수도 있다.

 

리버스 프록시를 활용하면 서버의 상황과 관계 없이 HTTP/2를 쉽게 적용할 수 있는데,

 

리버스 프록시와 우리 서버의 통신에서는 브라우저의 제약을 따르지 않고 지리적 이점도 있을테니

 

HTTP/1.1 을 써도 성능상 손실이 없기 때문이다.